Suhail Singh <suhailsingh...@gmail.com> writes: > Tomas Volf <~@wolfsden.cz> writes: > >> Currently Guix uses *intersection* of keys from all parents. I would >> like to suggest modifying the check to use an *union* of: >> >> 1. *Intersection* of keys from all parents (the current logic). >> 2. Keys listed in $GUIX_AUTHENTICATE_EXTRA_KEYS. >> >> (and, if you are soft-forking Guix, you could also add your key to:) >> >> 3. Keys listed in new variable ((@ (guix git-authenticate) extra-keys). >> >> This, while much less elegant compared to your solution, seems much >> easier to reason about. > > Agreed. I think it's important to not change 1. Adding an additional > "allow list" is an effective approach to allow soft-forks without > compromising security. > >> It still requires you to add the actual keys to keyring branch, but >> that branch does not use authentication, so that should not be a >> problem. > > +1 > >> It would *not* be an error to have a key listed in the environment >> variable which does not have actual key material (on the keyring >> branch), it would just be silently skipped. > > To be clear, when you say "silently skipped", it's as if said key had > not been a part of 2 above?
Correct, but applying both to parts 2. and 3. In other words, the additional whitelisted keys are added to the set of valid keys for a commit only if the key material exists on the keyring branch. This is necessary in order to allow running an authentication check on repository you did *not* soft-fork (and so did not add your key's material to the keyring branch) while having your key added into the $GUIX_AUTHENTICATE_EXTRA_KEYS (e.g. in the ~/.profile). Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature
