3 ms·

The lead is buried at the bottom of the article (imo). > "While being flooded with spam is never good, it gets immediately noticed and mitigated. It's harder f

The lead is buried at the bottom of the article (imo). > "While being flooded with spam is never good, it gets immediately noticed and mitigated. It's harder for open source projects to spot and stop rare one-offs" This is the real problem that NPM and other ecosystems face. A determined attacker that is trying to "poison" a popular Open Source package just has to feign as a maintainer long enough to succeed[0]. Defeating these types of attacks will require rethinking how we think about trust of packages. Projects like Deno are one approach (fork the ecosystem) while projects like Packj (mentioned elsewhere here), Socket.dev, and LunaTrace[1] are taking the other angle (make it harder to install malware). It's hard to say which approach is better right away. (Probably a hybrid of both, realistically) It's just non-trivial to fix this in one clean swoop. It's messy. 0: https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets https://www.trendmicro.com/vinfo/us/security/news/cybercrime... 1: https://github.com/lunasec-io/lunasec https://github.com/lunasec-io/lunasec

verdverm 4y ago
Go's take is to fetch from the code host, so there is no module registry at all. Curious if others find this reassuring in light of registry attacks?
- junon 4y ago
  No. The tradeoffs don't make any sense. With a registry you have some sort of guarantees, mirrors, etc. The same isn't true with individually owned repositories.
- freeqaz 4y ago
  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.
- EE84M3i 4y ago
  I thought go fetched from a centralized proxy? https://proxy.golang.org/ https://proxy.golang.org/
  - verdverm 4y ago
    it typically does, but this can be disabled with an env var, and it really is only a cache, no accounts or anything, new modules will come from source
classified 4y ago
You don't have to bury lead. It's so heavy that it sinks on its own. https://www.merriam-webster.com/words-at-play/bury-the-lede-versus-lead https://www.merriam-webster.com/words-at-play/bury-the-lede-...
- freeqaz 4y ago
  Much appreciated!

verdverm 4y ago

Go's take is to fetch from the code host, so there is no module registry at all. Curious if others find this reassuring in light of registry attacks?

junon 4y ago
No. The tradeoffs don't make any sense. With a registry you have some sort of guarantees, mirrors, etc. The same isn't true with individually owned repositories.
freeqaz 4y ago
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.
EE84M3i 4y ago
I thought go fetched from a centralized proxy? https://proxy.golang.org/ https://proxy.golang.org/
- verdverm 4y ago
  it typically does, but this can be disabled with an env var, and it really is only a cache, no accounts or anything, new modules will come from source

classified 4y ago

You don't have to bury lead. It's so heavy that it sinks on its own. https://www.merriam-webster.com/words-at-play/bury-the-lede-versus-lead https://www.merriam-webster.com/words-at-play/bury-the-lede-...

freeqaz 4y ago
Much appreciated!