Mark H Weaver <[email protected]> skribis: > IMO, we should rather be going in the other direction, to formalize and > automate the checking of signatures. IMO, our 'origin' objects should > include a set of fingerprints of acceptable GPG signing keys for that > package, as well as information on how to find the signature (in cases > where it cannot be guessed).
I thought about it (it used to be in TODO), but this design has several problems. One of them is that a keyring is needed if we are to verify signatures; where do we get it? Another one is that, inherently, the daemon already handles integrity checks for fixed-output derivations, and authentication should really be made beforehand by the packager. Most of the time the authentication model is trust-on-first-download: The packager fetches upstream’s public key when they first download a tarball (so this particular phase is subject to MiTM), and subsequent downloads are checked against the key that’s already in the packager’s keyring. > This would have several beneficial effects: > > * If the packager downloaded a key belonging to a man-in-the-middle > (quite possible given that we rarely have a validated chain of trust > to the developer), then that bad key will be stored in our git repo > for all to see, allowing someone to notice that it's the wrong key. So you’re suggesting to put the keyring under version control in a way, right? It sounds like a good idea, provided we at least the Git commits that add/modify the keyring are signed. There’s a couple of issues: unless it can be stored in a plain-text format, it’ll be hard to audit changes that are made; it would quickly end up containing hundreds of public keys, so there’s a scalability issue: how do we keep it up-to-date? how do we decide who’s authorized to update it, etc.? First step would be to be able to do something meaningful with the GNU keyring. It’s at ftp.gnu.org/gnu/gnu-keyring.gpg, but it’s currently unsigned; previous attempts to do something about it haven’t gone anywhere, but we could try again. > * When the package is later updated, it will not be possible for a new > man-in-the-middle attack to be made on us. If a new signing key is > used, we cannot fail to notice it. It will raise a red flag and we > can investigate. > > * It would strongly encourage packagers to do these checks, and make it > obvious to reviewers or users when the packager failed to do so. It > would also make it easy to find unsigned packages, so that we can > encourage upstream to start signing the packages, at least for the > most important ones. As Andreas notes, outside of gnu.org, savannah.gnu.org, kernel.org, and a few others, it’s very frequent for packages to not be signed at all. > Also, our linter should download and check the signature, so that it's > easy for others to independently check the verification done by the > original packager. ‘guix import gnu’ and ‘guix refresh’ already do that, but only for GNU packages. I have been thinking that ‘guix download’ could also automatically look for .sig, .sign, and .asc files. That’s easily done, and already an improvement. Thoughts? Ludo’.
