4 ms·

Fillipo said here (https://abyssdomain.expert/@filippo/111393097818470743 https://abyssdomain.expert/@filippo/111393097818470743) > It is IMHO the strongest se

Fillipo said here (https://abyssdomain.expert/@filippo/111393097818470743 https://abyssdomain.expert/@filippo/111393097818470743) > It is IMHO the strongest security guarantee you can offer without forcing each module author to manage keys. Outsourcing the problem to DNS still forces module authors to manage keys. Not keys to sign code, but keys to sign TLS certs nonetheless. Granted, authors can further delegate managing TLS keys to other people, but you cannot escape the ultimate issue of managing control of the domain (passwords at registries at least). If we cannot get rid of key management anyway, can we split the problem into 1) Code Signing and 2) Code Distribution? Once we get the Code Signing done right, Code Distribution will be much easier with robust solutions (e.g. content addressable storage and various kinds of proxies/caches for high availability). Now code signing, lots of schools of thoughts… On the extreme end of decentralization, PGP/GPG people will say Web of Trust and Crypto/web3 people will say hardware wallets; while on the other end of centralization we seem to be getting by just fine with publishing public keys on GitHub and various social networks. Just pick a place where you Feel Good Enough™ :p

withinboredom 3y ago
Code signing certs expire though. So you basically limit any code's usefulness to some arbitrary date. Then you need to maintain that code cert, continue to pay for it, renew it, etc, which you can realistically only do until you get hit by a bus, die of old age, or just fall on hard times. This is a worse (very real) problem vs. some domain thing that probably won't ever happen for the majority of modules.
Bognar 3y ago
Provenance artifacts via something like SigStore would go a long way, since it solves both key management and the linking of artifacts to their build process. For Go where you're just publishing sources with a build necessarily, you could opt for SigStore git signing so you can at least validate the author via a 2FA auth provider's OIDC token.
rob74 3y ago
This is a largely academic discussion - I assume over 95% of modules are hosted on some kind of "forge" (mostly GitHub nowadays), so the users don't have to worry about keys/certificates, just about the forge's continued existence and their account not being removed. Any attempt to switch to code signing would raise the barriers of contributing to the Go ecosystem quite a bit, so (if at all) it should be introduced as an alternative or supplement to the existing system, not a replacement.

withinboredom 3y ago

Code signing certs expire though. So you basically limit any code's usefulness to some arbitrary date. Then you need to maintain that code cert, continue to pay for it, renew it, etc, which you can realistically only do until you get hit by a bus, die of old age, or just fall on hard times. This is a worse (very real) problem vs. some domain thing that probably won't ever happen for the majority of modules.

Bognar 3y ago

Provenance artifacts via something like SigStore would go a long way, since it solves both key management and the linking of artifacts to their build process. For Go where you're just publishing sources with a build necessarily, you could opt for SigStore git signing so you can at least validate the author via a 2FA auth provider's OIDC token.

rob74 3y ago

This is a largely academic discussion - I assume over 95% of modules are hosted on some kind of "forge" (mostly GitHub nowadays), so the users don't have to worry about keys/certificates, just about the forge's continued existence and their account not being removed. Any attempt to switch to code signing would raise the barriers of contributing to the Go ecosystem quite a bit, so (if at all) it should be introduced as an alternative or supplement to the existing system, not a replacement.