4 ms·

It's hard for the enterprise world because they need to mirror everything internally. (That's a doable problem and I believe Google proxies all Golang installs

It's hard for the enterprise world because they need to mirror everything internally. (That's a doable problem and I believe Google proxies all Golang installs already.) There are still issues with things like history being re-written if you're pinned to a tag instead of a commit... since potentially the hash might change and you can't necessarily understand what changed unless you have a copy of the original code still. That said, I feel like the bigger challenge here is with transitive dependencies (and a large total number of dependencies) because they create more places for malware to "hide", so to speak. If every time I bump a package, it bumps 50 others... am I really going to notice/review the changes in all of those? Odds are I'm just trying to ship some feature or do something else! The libraries are rarely the center of my focus. (Maybe you get a PR with a security fix that you land it without thinking. Surprise, malware!) It's an insidious problem without a very clear cut solution. Do we stop using Open Source code? Probably not. So how do we adapt? TBD!

verdverm 4y ago
I don't understand how a registry eliminates any of your critiques. The packages on registries come from git anyway, by way an unknown packaging process, rather than getting the source directly. > If every time I bump a package, it bumps 50 others... am I really going to notice/review the changes in all of those? Is there a difference between registry and codehost here? > That said, I feel like the bigger challenge here is with transitive dependencies This seems to be more a result of the stdlib and ecosystem, Node & NPM being the poster child for this > There are still issues with things like history being re-written if you're pinned to a tag instead of a commit... The Go team runs a sumdb server to catch this, and NPM does something to prevent tag drift, though we don't do this with our container images. It is trivial to move an image tag on docker hub or any image registry. You should have a go.sums committed next to the go.mods file which also checks that the code at the tag is the same as you expect, so the sumdb is not necessarily needed if you trust the hash you originally downloaded and committed to git. > It's hard for the enterprise world because they need to mirror everything internally. We explored this, NPM and PyPi present the same issues as Go, the shear volume and maintenance makes it practically not worth it. --- What about having additional accounts with a registry/hub in the software supply chain, that have been demonstrated to be vulnerable to account take over? Adding this extra middle layer in the supply chain seems like an inefficiency and increases risk.

verdverm 4y ago

I don't understand how a registry eliminates any of your critiques. The packages on registries come from git anyway, by way an unknown packaging process, rather than getting the source directly. > If every time I bump a package, it bumps 50 others... am I really going to notice/review the changes in all of those? Is there a difference between registry and codehost here? > That said, I feel like the bigger challenge here is with transitive dependencies This seems to be more a result of the stdlib and ecosystem, Node & NPM being the poster child for this > There are still issues with things like history being re-written if you're pinned to a tag instead of a commit... The Go team runs a sumdb server to catch this, and NPM does something to prevent tag drift, though we don't do this with our container images. It is trivial to move an image tag on docker hub or any image registry. You should have a go.sums committed next to the go.mods file which also checks that the code at the tag is the same as you expect, so the sumdb is not necessarily needed if you trust the hash you originally downloaded and committed to git. > It's hard for the enterprise world because they need to mirror everything internally. We explored this, NPM and PyPi present the same issues as Go, the shear volume and maintenance makes it practically not worth it. --- What about having additional accounts with a registry/hub in the software supply chain, that have been demonstrated to be vulnerable to account take over? Adding this extra middle layer in the supply chain seems like an inefficiency and increases risk.