4 ms·

So: >Versions are only importable from tags (semver style) Tags are mutable in git, which sometimes causes problems. Not that I think they had much choice he

by Groxx 5y ago

So: >Versions are only importable from tags (semver style) Tags are mutable in git, which sometimes causes problems. Not that I think they had much choice here - git and tags are the de-facto community standard, they're just using it like everyone else. >There is no NPM or PyPi like host, sources originate from code hosts >Modules are prefixed with a domain name (avoid dep confusion) Agreed, I like this quite a bit... but it comes with the significant risk of domain name or hosting changes. Github probably won't add the metadata to redirect your old module name to your new non-github name, for instance. I've watched several modules fight through this sequence, and the end result is always "can't do anything, contact your users yourself / hope they read the readme". You win some, you lose some. In large part I think this part of Go modules is better than others'. >Hashes are calculated on the module, it will fail if it is not correct Nearly all lock-file-based dependency systems do this, Cargo included. >GoProxy has a global transparency log (like a blockchain, but not) so that everyone is contributing and sharing hashes Publishing a log now doesn't make it any safer tomorrow, it's purely about convincing you to trust them. This is precisely the same attack target as an NPM or PyPi. The same party hosts the tar'd source files + documentation + checksums: if it ever gets changed there, it's changed for everyone. Lock and go.sum files will only protect you from changes to your previously-known dependencies. They've done a pretty good job making goproxy/gosum easy to run yourself, and you can skip past the goproxy and download directly from the module's owner (which is a domain name, which works great here), which mitigates this specific risk at least. But no, they're absolutely running a pypi, they just don't let repo owners make changes directly (only by committing changes, e.g. module revocation).

tapirl 5y ago
> Publishing a log now doesn't make it any safer tomorrow, it's purely about convincing you to trust them. That is true. The global transparency log is just to prevent a package version change after it has been recorded in the log.
verdverm 5y ago
RE: git, if the package has been fetched through Go Proxy once before the tag change, the new tag will never pass validation > if it ever gets changed there, it's changed for everyone sum.golang.org has a hash chain, so you have to change everything that comes after a malicious hash change. So it does seem safer the more time that passes. Go uses zip files, as a fyi. I've had more trouble with custom domain based Go mods than the major code hosts. I've come to avoid those on custom domains as much as possible.
- Groxx 5y ago
  >sum.golang.org has a hash chain, so you have to change everything that comes after a malicious hash change. So it does seem safer the more time that passes. Is there a work-factor attached to these? I kinda don't think so, the only reference I can see is "sha256" (I have not checked the code.... nor is the public proxy the same thing they run, though it should be good enough for this purpose). Unless it's "costly", the time needed to recompute the whole history of every module is probably well below one second. The chain just makes it so you don't need to do that on every single update. It's a good structure for making attacks more noticeable (you can't change any piece of history without everyone who already has that history noticing), and it enables efficient and trustworthy partial updates (backfills? meh), so I think it's a very solid addition and I'm glad it exists. But it really doesn't protect against much in the way of practical attacks - it's a canary, not a preventative measure, mostly serving to say "see? we've been trustworthy, you can trust us going forward". (edit: I'll completely believe there's a small niche of attacks that it prevents... but I can't think of any that aren't massively overshadowed by other also-possible attacks in the same situation) >I've had more trouble with custom domain based Go mods than the major code hosts. I've come to avoid those on custom domains as much as possible. Yeah, custom domain ones have definitely had more problems - the proxy helps a fair bit there :) I don't mean to imply I'm unhappy they're running a PyPi-alike; I'm absolutely thrilled that they finally admitted they need it, and it's a decent implementation too. But that's pretty much all it is.
  - verdverm 5y ago
    You can reproduce it if there is no private key or cert chain involved. I'm not clear on the details, but they where basing it on The Update Framework (TUF) so there may be some cert chains involved

by Groxx 5y ago

tapirl 5y ago

> Publishing a log now doesn't make it any safer tomorrow, it's purely about convincing you to trust them. That is true. The global transparency log is just to prevent a package version change after it has been recorded in the log.

verdverm 5y ago

RE: git, if the package has been fetched through Go Proxy once before the tag change, the new tag will never pass validation > if it ever gets changed there, it's changed for everyone sum.golang.org has a hash chain, so you have to change everything that comes after a malicious hash change. So it does seem safer the more time that passes. Go uses zip files, as a fyi. I've had more trouble with custom domain based Go mods than the major code hosts. I've come to avoid those on custom domains as much as possible.

Groxx 5y ago
>sum.golang.org has a hash chain, so you have to change everything that comes after a malicious hash change. So it does seem safer the more time that passes. Is there a work-factor attached to these? I kinda don't think so, the only reference I can see is "sha256" (I have not checked the code.... nor is the public proxy the same thing they run, though it should be good enough for this purpose). Unless it's "costly", the time needed to recompute the whole history of every module is probably well below one second. The chain just makes it so you don't need to do that on every single update. It's a good structure for making attacks more noticeable (you can't change any piece of history without everyone who already has that history noticing), and it enables efficient and trustworthy partial updates (backfills? meh), so I think it's a very solid addition and I'm glad it exists. But it really doesn't protect against much in the way of practical attacks - it's a canary, not a preventative measure, mostly serving to say "see? we've been trustworthy, you can trust us going forward". (edit: I'll completely believe there's a small niche of attacks that it prevents... but I can't think of any that aren't massively overshadowed by other also-possible attacks in the same situation) >I've had more trouble with custom domain based Go mods than the major code hosts. I've come to avoid those on custom domains as much as possible. Yeah, custom domain ones have definitely had more problems - the proxy helps a fair bit there :) I don't mean to imply I'm unhappy they're running a PyPi-alike; I'm absolutely thrilled that they finally admitted they need it, and it's a decent implementation too. But that's pretty much all it is.
- verdverm 5y ago
  You can reproduce it if there is no private key or cert chain involved. I'm not clear on the details, but they where basing it on The Update Framework (TUF) so there may be some cert chains involved