4 ms·
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
by 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 agoCosign 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 agoYeah, 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.