3 ms·

go’s lockfiles include cryptographic hashes which prevent even Google from maliciously replacing packages in the cache.

by sneak 1y ago

ocdtrekkie 1y ago
A malicious actor could, however, quite trivially add one to the version number. ;)
- arccy 1y ago
  No technical solution is going to save you from an upstream going rogue and you blindly updating. The only way is to properly review your dependencies.
  - dwattttt 1y ago
    The problem isn't an upstream going rogue; it's an upstream going dark, and someone taking advantage of that. Upstreams going dark happens much more often than them going rogue. A system that requires you to prove more than you just control a domain isn't as vulnerable to this problem.
junon 1y ago
This doesn't address availability or discoverability though. There are no upsides other than a fleeting sense of "decentralization", without any of the securities of a real decentralized protocol.
tsimionescu 1y ago
For a given version, yes. But the security risk here is about publishing a new (malicious) version of a previously trusted package, by taking control of an expired domain. Say I'm using mydomain.org/abc and it's a perfectly fine package. I'm currently using v1.25.7. Two months later, I see a new version of mydomain.org/abc, v1.25.8. I will likely update to it and use it relatively confidently. But, unbeknownst to me, mydomain.org's registration expired one month ago, and a malicious actor has grabbed it in the meantime; and they have now released a malicious version of this package. Nothing in Go's security model prevents this type of attack, except that Google's package "cache" (the package repo that Go downloads things from) can be configured by Google to not provide that malicious package. This is a major design flaw with the silly idea of using an extremely imparmenent identifier - DNS names, which can only be leased for a limited time and are automatically auctioned off after they expire - as the main identifier for something as long lived as Go packages. No other package ecosystem has this terrible design concept - even when they do use DNS, they use it only for an initial authentication, not as the only identifier. For example, in Java's Maven repo, to publish a package org.mydomain.abc from a Maven Central account, you need to prove that you have ownership of abc.mydomain.org once when associating this package. Afterwards, the package name remains associated with your Maven Central account, forever. If you lose access to that domain name and someone else obtains, they can't go through the same steps, Maven Central won't let them, since that package name is already tied to your account.

go’s lockfiles include cryptographic hashes which prevent even Google from maliciously replacing packages in the cache.

by sneak 1y ago

go’s lockfiles include cryptographic hashes which prevent even Google from maliciously replacing packages in the cache.

ocdtrekkie 1y ago

A malicious actor could, however, quite trivially add one to the version number. ;)

arccy 1y ago
No technical solution is going to save you from an upstream going rogue and you blindly updating. The only way is to properly review your dependencies.
- dwattttt 1y ago
  The problem isn't an upstream going rogue; it's an upstream going dark, and someone taking advantage of that. Upstreams going dark happens much more often than them going rogue. A system that requires you to prove more than you just control a domain isn't as vulnerable to this problem.

junon 1y ago

This doesn't address availability or discoverability though. There are no upsides other than a fleeting sense of "decentralization", without any of the securities of a real decentralized protocol.

tsimionescu 1y ago

For a given version, yes. But the security risk here is about publishing a new (malicious) version of a previously trusted package, by taking control of an expired domain. Say I'm using mydomain.org/abc and it's a perfectly fine package. I'm currently using v1.25.7. Two months later, I see a new version of mydomain.org/abc, v1.25.8. I will likely update to it and use it relatively confidently. But, unbeknownst to me, mydomain.org's registration expired one month ago, and a malicious actor has grabbed it in the meantime; and they have now released a malicious version of this package. Nothing in Go's security model prevents this type of attack, except that Google's package "cache" (the package repo that Go downloads things from) can be configured by Google to not provide that malicious package. This is a major design flaw with the silly idea of using an extremely imparmenent identifier - DNS names, which can only be leased for a limited time and are automatically auctioned off after they expire - as the main identifier for something as long lived as Go packages. No other package ecosystem has this terrible design concept - even when they do use DNS, they use it only for an initial authentication, not as the only identifier. For example, in Java's Maven repo, to publish a package org.mydomain.abc from a Maven Central account, you need to prove that you have ownership of abc.mydomain.org once when associating this package. Afterwards, the package name remains associated with your Maven Central account, forever. If you lose access to that domain name and someone else obtains, they can't go through the same steps, Maven Central won't let them, since that package name is already tied to your account.