4 ms·

I wish someone would mint a user-friendly GPG wrapper for signing releases and quorum-based publishing. Dealing with raw GPG to sign releases is doable but a p

I wish someone would mint a user-friendly GPG wrapper for signing releases and quorum-based publishing. Dealing with raw GPG to sign releases is doable but a pain. And we need quorum publishing to guard against supply-chain attacks. But simple and user-friendly UX design is hard. As a user of `pass`, I'm grateful for what I have.

tialaramex 5y ago
For the signing problem, both signify (and its clones) and modern OpenSSH (ssh-keygen -Y) do what you want today without all the baggage of OpenPGP, obviously that would mean explicitly choosing to migrate off OpenPGP signatures, but that does not seem unreasonable.
- rectang 5y ago
  I just looked into signify, and I read this: https://www.openbsd.org/papers/bsdcan-signify.html https://www.openbsd.org/papers/bsdcan-signify.html > There are no key servers for signify. No web of trust. Just keys. I'm not sure how that would work for quorum publishing, which guards against any single set of credentials being compromised by requiring multiple trusted signatories. The idea is that packages are signed by multiple identities, and if as a downstream user, you trust enough of those identities to form a quorum (2, or 3, or some score-based criteria), then you consider the release trustworthy enough to accept automatically. (The underlying theory is just multifactor auth.) Downstream users need some way of determining how to trust keys, and that mechanism should be decentralized. This seems to be at odds with the priority the BSD authors place on key rotation: > After each release of OpenBSD, we generate a new key pair for the release after next. That's plus two. For example, after 5.6 was released, keys for 5.8 were generated. This way, the 5.8 keys are then included in the 5.7 release. So, if you upgrade every release, you will have an unbroken chain of keys back to your initial installation. So it sounds like there's a single set of keys for each release, which has to be kept safe. I'm sure that the OpenBSD folks take great care, but the idea of quorum publishing is to require multiple factors so that an attacker has to compromise multiple identities to spoof a release.

tialaramex 5y ago

For the signing problem, both signify (and its clones) and modern OpenSSH (ssh-keygen -Y) do what you want today without all the baggage of OpenPGP, obviously that would mean explicitly choosing to migrate off OpenPGP signatures, but that does not seem unreasonable.

rectang 5y ago
I just looked into signify, and I read this: https://www.openbsd.org/papers/bsdcan-signify.html https://www.openbsd.org/papers/bsdcan-signify.html > There are no key servers for signify. No web of trust. Just keys. I'm not sure how that would work for quorum publishing, which guards against any single set of credentials being compromised by requiring multiple trusted signatories. The idea is that packages are signed by multiple identities, and if as a downstream user, you trust enough of those identities to form a quorum (2, or 3, or some score-based criteria), then you consider the release trustworthy enough to accept automatically. (The underlying theory is just multifactor auth.) Downstream users need some way of determining how to trust keys, and that mechanism should be decentralized. This seems to be at odds with the priority the BSD authors place on key rotation: > After each release of OpenBSD, we generate a new key pair for the release after next. That's plus two. For example, after 5.6 was released, keys for 5.8 were generated. This way, the 5.8 keys are then included in the 5.7 release. So, if you upgrade every release, you will have an unbroken chain of keys back to your initial installation. So it sounds like there's a single set of keys for each release, which has to be kept safe. I'm sure that the OpenBSD folks take great care, but the idea of quorum publishing is to require multiple factors so that an attacker has to compromise multiple identities to spoof a release.