3 ms·

yeah - in many other dependency systems, you only get protection for versions you use, as those are in your lockfile. the public gosumdb helps prevent a few mo

by Groxx 5y ago

yeah - in many other dependency systems, you only get protection for versions you use, as those are in your lockfile. the public gosumdb helps prevent a few more cases of re-releasing something + you upgrading + pulling it from a different provider (... which is mostly relevant due to its more-distributed setup, if it treated goproxy as canonical it'd be unnecessary because it wouldn't contain that re-release), but not "downloaded module does not match repository". I do think the sumdb setup is worth others copying, it's relatively cheap to maintain and it does clamp down on some issues. It also makes it much harder to revoke things though, as you can't remove anything from it ever - after a couple versions, Go finally added "redacted" versions, but the need for that is partly a consequence of having the permanently-immutable sumdb + not having a canonical source. Unique self-inflicted pain -> unique workaround, though it's all relatively reasonable and I think a net benefit.

verdverm 5y ago
Sigstore & Cosign are worth looking into as well. GoReleaser supports those for compiled binaries. SLSA is another https://sigstore.dev/ https://sigstore.dev/ https://slsa.dev/ https://slsa.dev/
- Groxx 5y ago
  That seems like just code-signing? If so: yeah, definitely, that should be supported by every packaging system. And it's largely ridiculous that it isn't. It removes the need to trust the packaging-host, so it's no longer a giant target for exploits that can modify every package at once. Go, using domain names, is probably in the best position to take advantage of this, as it allows you to lean on domain ownership (and maybe even use the same ssl certificate) rather than having to trust-on-first-use or something.
  - verdverm 5y ago
    Cosign also has a global signature chain, so new signatures secure older entries. It uses Trillian iirc. I also think that anyone can come along and submit a signature for any project. So in that sense, you could get an entity that verifies and signs widely used packages. They could build trust over time and be relied upon to validate deps so you don't have to inspect every dep yourself. Granted it supports containers and binary blobs currently, but if you had a reproducible way to zip any repo, you could sign that.
    - Groxx 5y ago
      Yeah, definitely. A "X has read this and claims it is safe to use" certificate would be a huge boon in a lot of cases, and is automation-friendly. Then you could pick reviewers you trust, and find (or exclusively use) packages that are covered by them. I'd love it, "curators" can be significant contributors to an ecosystem.

by Groxx 5y ago

verdverm 5y ago

Sigstore & Cosign are worth looking into as well. GoReleaser supports those for compiled binaries. SLSA is another https://sigstore.dev/ https://sigstore.dev/ https://slsa.dev/ https://slsa.dev/

Groxx 5y ago
That seems like just code-signing? If so: yeah, definitely, that should be supported by every packaging system. And it's largely ridiculous that it isn't. It removes the need to trust the packaging-host, so it's no longer a giant target for exploits that can modify every package at once. Go, using domain names, is probably in the best position to take advantage of this, as it allows you to lean on domain ownership (and maybe even use the same ssl certificate) rather than having to trust-on-first-use or something.
- verdverm 5y ago
  Cosign also has a global signature chain, so new signatures secure older entries. It uses Trillian iirc. I also think that anyone can come along and submit a signature for any project. So in that sense, you could get an entity that verifies and signs widely used packages. They could build trust over time and be relied upon to validate deps so you don't have to inspect every dep yourself. Granted it supports containers and binary blobs currently, but if you had a reproducible way to zip any repo, you could sign that.
  - Groxx 5y ago
    Yeah, definitely. A "X has read this and claims it is safe to use" certificate would be a huge boon in a lot of cases, and is automation-friendly. Then you could pick reviewers you trust, and find (or exclusively use) packages that are covered by them. I'd love it, "curators" can be significant contributors to an ecosystem.