right, that's my point.
not everyone will have the patience to inspect gpg output from 13 consecutive sig checks, it's very off-putting for anyone who has low or zero experience of this kind of thing. I appreciate though that this is a chicken and egg paradox; people can't understand the process without experience, but people are disinclined to attain the experience without understanding the process.
Most users will be inspecting the gpg output rather than relying on the exit code since bash doesn't tell you the exit code after the command is run. A script can be easily modified to deal with this situation too, and I would expect that anyone capable of writing a script in the first place is also capable of figuring this out.not everyone will have the patience to inspect gpg output from 13 consecutive sig checks, it's very off-putting for anyone who has low or zero experience of this kind of thing. I appreciate though that this is a chicken and egg paradox; people can't understand the process without experience, but people are disinclined to attain the experience without understanding the process.
But yes, I agree that is an issue and it would be nice if gpg had an option for "verify at least one signature".
maybe it might be an idea to be sure that all signers (which as you say means all guix builders publishing their build hashes) have their keys on all keyservers, at least for the sake of redundancy?
It is difficult to do that since there are a lot of keyservers, and not all accept new keys. When guix signatures are verified, we do always ask for the key if it is not immediately obvious where it is, so we could potentially maintain a location for keys, but that could be troublesome to maintain.Jon Atack's key was not on keyserver.ubuntu.com (when I tried), and Hennadii Stepanov's key maybe was on keys.openpgp.org, but gpg --recv-keys refused to import it because some field in the data was somehow non-standard, which is essentially the same as the key being not on the server (to me at least).
I do not know the exact reason why my gpg version choked on that key, but some searching unravelled a whole bunch of stuff involving competing pgp infrastructure ideologies/protocols (GDPR has somehow become a factor, apparently...
), which to me boils down to: "I'll only be interested in the details once you people have figured out a consensus"
It seems there's 2 proprietary solutions (openpgp.org, keybase.io), and on top of that, 2 protocols (SKS and WKD). All competing, and none appear to be dominant (and it's highly undesirable that either proprietary solution became dominant anyway)
Unfortunately the PGP community has not unified behind a single solution. At this point, SKS is basically non-functional (and that's why keys aren't getting to keyservers). A lot of SKS keyservers have not been able to sync with each other due to attacks on their infrastructure, and other reasons that I don't know about. WKD is nice but it basically requires having your own domain name. Since the vast majority of people use email services, WKD is pretty much a non-starter as it would require the major email providers (google) to setup WKD infrastructure, and that's unlikely to happen. keys.openpgp.org has been the most reliable keyserver thus far, but it doesn't use SKS (so no syncing with other keyservers). So the current recommendation to all guix builders is to make sure their key is on keys.openpgp.org.I do not know the exact reason why my gpg version choked on that key, but some searching unravelled a whole bunch of stuff involving competing pgp infrastructure ideologies/protocols (GDPR has somehow become a factor, apparently...
), which to me boils down to: "I'll only be interested in the details once you people have figured out a consensus"It seems there's 2 proprietary solutions (openpgp.org, keybase.io), and on top of that, 2 protocols (SKS and WKD). All competing, and none appear to be dominant (and it's highly undesirable that either proprietary solution became dominant anyway)
One of the nice things about keys.openpgp.org is that they verify the email(s) before listing the key. So there's at least some guarantee that the key you are retrieving belongs to who it claims to belong to.
all I'm saying is: support all or most of these options until things change (especially any keyservers operating using the open protocols). Apparently, the Bitcoin project supports using 1 domain and 1 keyserver, which is rather too similar to my (joke) suggestion to distribute the keys with the release files.
That's not too different from 1 signature and 1 key as we used to do. 
)
