5 ms·

This needs to be resolved by every damned language. Just make signed dependencies a universal default, point to an https page for the package vendor and use the

by yarg 3y ago

This needs to be resolved by every damned language. Just make signed dependencies a universal default, point to an https page for the package vendor and use the signing key from there. Neither node nor maven ever bothered to solve this, so we end up wandering the Wild West wondering when it will be that HR, or legal, or architecture comes knocking on the door to ask what we were thinking having a dependency on a dynamic version of Left Pad. I'd kinda like to see what Cloudflare and Let's Encrypt could come up with if they worked together on at very least a white paper and an MVP POC.

lesuorac 3y ago
I don't think that's the real solution. Pay somebody either internally or externally to maintain a repo of all your dependencies and point your code at that. You won't get a left-pad incident. You won't get a malicious .so incident (unless you mirror binaries instead of source code). Like if you ran out of screws to make your product with do you walk around the street and scrounge up some? No, you go to a trusted vendor and buy the screws.
- yarg 3y ago
  I'm not suggesting scrounging. I'm suggesting that the guys who've repeatedly proven themselves technically competent around security at scale might have a couple of useful ideas regarding how the industry might go about crawling its way out of this little security clusterfuck. And perhaps even stop treating something as simple as a BOM as an enterprise feature, given that the overhead on such things is damned near zilch and the security implications are staggering. https://www.cisa.gov/sbom https://www.cisa.gov/sbom
- cmrdporcupine 3y ago
  There's reasons why Google projects don't go out on the internet to get their 3rd party deps. They're all checked into Google3 (or chromium, etc.). One version only. With internal maintainers responsible for bringing it in and multiple people vetting it, and clear ownership over its management. E.g. you don't just get to willy nilly depend on a new version -- if you want to upgrade what's there, you gotta put a ring on it. If you upgrade it, you're likely going to be upgrading it for everyone, and the build system will run through the dependent tests for them all, etc. And the consequence is more responsible use of third party deps and less sprawling dependency trees and less complexity. And additional less security concerns as the code is checked in, its license vetted, and build systems are hunting around on the Internet for artifacts.
- kmiller96 3y ago
  I actually really like this idea. The community just needs to align on a good, simple, standard approach to mirroring repos...
spullara 3y ago
To be fair, all the dependencies in the maven central repository require a signature to publish them.
- yarg 3y ago
  That's a workaround. I'm not a fan of those - if the engine's in the wrong place, then why the hell did you fucking put it there? Don't hack a patch into place to stop people from holding it wrong; design it in such a way that it's impossible to hold wrong in the first place.
lmm 3y ago
Maven has signing and you can check the signatures on your dependencies if you care to. Most don't, sadly.

by yarg 3y ago

lesuorac 3y ago

I don't think that's the real solution. Pay somebody either internally or externally to maintain a repo of all your dependencies and point your code at that. You won't get a left-pad incident. You won't get a malicious .so incident (unless you mirror binaries instead of source code). Like if you ran out of screws to make your product with do you walk around the street and scrounge up some? No, you go to a trusted vendor and buy the screws.

yarg 3y ago
I'm not suggesting scrounging. I'm suggesting that the guys who've repeatedly proven themselves technically competent around security at scale might have a couple of useful ideas regarding how the industry might go about crawling its way out of this little security clusterfuck. And perhaps even stop treating something as simple as a BOM as an enterprise feature, given that the overhead on such things is damned near zilch and the security implications are staggering. https://www.cisa.gov/sbom https://www.cisa.gov/sbom
cmrdporcupine 3y ago
There's reasons why Google projects don't go out on the internet to get their 3rd party deps. They're all checked into Google3 (or chromium, etc.). One version only. With internal maintainers responsible for bringing it in and multiple people vetting it, and clear ownership over its management. E.g. you don't just get to willy nilly depend on a new version -- if you want to upgrade what's there, you gotta put a ring on it. If you upgrade it, you're likely going to be upgrading it for everyone, and the build system will run through the dependent tests for them all, etc. And the consequence is more responsible use of third party deps and less sprawling dependency trees and less complexity. And additional less security concerns as the code is checked in, its license vetted, and build systems are hunting around on the Internet for artifacts.
kmiller96 3y ago
I actually really like this idea. The community just needs to align on a good, simple, standard approach to mirroring repos...

spullara 3y ago

To be fair, all the dependencies in the maven central repository require a signature to publish them.

yarg 3y ago
That's a workaround. I'm not a fan of those - if the engine's in the wrong place, then why the hell did you fucking put it there? Don't hack a patch into place to stop people from holding it wrong; design it in such a way that it's impossible to hold wrong in the first place.

lmm 3y ago

Maven has signing and you can check the signatures on your dependencies if you care to. Most don't, sadly.