| 00:20.59 | *** join/#uphpu infobot (ibot@208.53.50.136) |
| 00:20.59 | *** topic/#UPHPU is Meeting: Thursday Jan 14th - SkiPHP Jan 14th & 15th | Utah PHP Users Group | uphpu.org |
| 00:20.59 | *** mode/#UPHPU [+v infobot] by ChanServ |
| 14:42.20 | *** join/#uphpu josephscott (~josephsco@c-174-52-11-31.hsd1.ut.comcast.net) |
| 19:13.47 | josephscott | remember how unpopular my stance on builds/deploying was? it is because of things like this - https://github.com/eslint/eslint-scope/issues/39 - that I say you only ever deploy what is in your repo |
| 19:14.05 | josephscott | if your deploy process involves downloading things from the internet, you've already lost |
| 21:01.05 | tierra | I'm a bit confused, are you saying you should commit your 3rd party dependencies to your own VCS alongside your project? |
| 21:02.22 | tierra | Think I'd just prefer that repositories actually put some work into implementing package signing |
| 21:03.51 | tierra | I mean, even if you commit your deps to your own repo, how do you know the libraries you're downloading on your own box and commiting to the repo weren't already compromised? |
| 21:04.06 | tierra | doesn't really seem to mitigate anything |
| 21:11.41 | josephscott | that is exactly what I'm saying |
| 21:12.16 | josephscott | that way at least a dev has a chance to review changes in 3rd party code, instead of letting a build process do it automatically |
| 21:13.21 | josephscott | not saying it is going to magically solve 100% of the problem, but it gives you an opportunity to catch it, which is something you don't have if your build does it for you |
| 21:14.29 | tierra | that just seems like a really inefficient way to manage your VCS, and many times, I struggle even reviewing the actual app code changes, let alone 3rd party code changes during upgrades |
| 21:15.01 | tierra | just saying, there's better solutions, one of them being package signing, and just better security practices for the repo |
| 21:15.30 | josephscott | package signing would be a help, though it doesn't address the issue of looking at what changed between versions |
| 21:16.06 | tierra | sounds like it would have caught this eslint-scope issue |
| 21:31.19 | jsmith | josephscott: "if your deploy process involves downloading things from the internet, you've already lost" -- I couldn't agree more! |
| 21:33.25 | jsmith | josephscott: In the specific case of NPM modules, I strong suggest making devs use an artifact proxy, and being able to filter/limit/block packages (or specific package versions) in that proxy. It's a bit of a big hammer to put on devs, but it's saved my bacon countless times. |
| 21:35.34 | josephscott | or at least pinning to specific versions, so that a tool doesn't try to automagically upgrade an lib from 2.1.2 to 2.1.5 -- that is the type of decision a dev should make, and tracked by a commit |