maintainers/maintainer-list.nix: add PGP/GPG fingerprints

[oxij]

Motivation for this change

A first tiny step towards NixOS/rfcs#34

Things done

• It evaluates.

[zimbatm]

Mine is rsa2048/0x71BAF6D40C1D63D7 and 2603 53B9 93F8 CE16 752E F48C 71BA F6D4 0C1D 63D7 and

[oxij]

Hm, do you want to include the key type there too? It might be useful, if just for statistics.

[zimbatm]

Actually the short ID is considered insecure so we might as well drop it (I think it's still too easy to generate collisions)

[zimbatm]

That would also allow to simplify the instruction to gpg --fingerprint <email>

[tilpner]

Should there be support for multiple fingerprints per person? (I have multiple, but I admit to not always following best practices)

[oxij]

@zimbatm Yes, but it is useful for fetching keys from keyservers.

@tilpner Do both keys have the same email? Should we also support multiple emails then?

[tilpner]

@oxij That's correct, they all have the same name and email. I currently have three signing subkeys, one for each device I sign things from. My motivation was to be able to revoke a single device on compromise, instead of having to re-do all of them.

[Mic92]

Is there a way to check keys against the github API?

[tilpner]

There is https://api.github.com/users/tilpner/gpg_keys in the v3 API. This might indeed be useable for the initial population of this list

Edit: Unfortunately, it seems GH processes the public key into some other format. I have no idea how to convert it back into something gpg can handle

[oxij]

See the new version.

[oxij]

@tilpner if you use per device subkeys AFAIK you can specify the fingerprint and id of the master key. But multiple keys should be useful anyway, e.g. when expiring a key.

[oxij]

Hm, thinking some more about this. - Key id is indeed superfluous, it probably only needs a key type and the fingerprint. - Borrowing ideas from git-signatures we can also include self-signatures directly into this file. ``` # large echo "rsa2048/514BB966B46E3565050886E80E6CA66E5C557AA8 githubhandle Full Name <email>" | gpg --compress-algo none --sign --armor --local-user 514BB966B46E3565050886E80E6CA66E5C557AA8 # large-ish echo "rsa2048/514BB966B46E3565050886E80E6CA66E5C557AA8 githubhandle Full Name <email>" | openssl sha256 -binary | gpg --compress-algo none --sign --local-user 514BB966B46E3565050886E80E6CA66E5C557AA8 | openssl base64 -A ``` ``` that | openssl base64 -A -d | gpg -d ``` That way we can easily produce a usable gpgparticipants(1)-like list for a key signing-party. I'm assuming we would want to do https://en.wikipedia.org/wiki/Zimmermann%E2%80%93Sassaman_key-signing_protocol but with git commit author names taken from git-blame instead of government-issued IDs (because you should care if that $USER owns the same key they use in this repository, not that they carry government-issued IDs; one can argue this might be a valid case for using the comment field, see https://www.debian-administration.org/users/dkg/weblog/97, or we can just ask people to add "github:handle" UID to their key, or just ignore the issue). git-blame certifies that you commited that line under the correct git author, by adding self-signature here you would certify that you own the secret key in question, thus we can compute the second check of Zimmermann-Sassaman automagically. You would then certify in person at the party that you did actually do both yourself and the fingerprint is correct. Thoughts?

[zimbatm]

I know it's getting complicated but how about adding an expiry date for the key? That way if there are multiple listed it makes it clearer which one is only there for historical reason (and that no new stuff should be signed with it).

[oxij]

That would make sense, I agree, but I'm against "expires" field (because it's a good practice to set expiration short and updating this file all the time would be counterproductive), but I'm all for "expired" field that would mark already expired key you don't want to resign with a new expiration date.

[joachifm]

Probably self-evident, but maybe stipulate that the commit that adds a key be signed by that key?

[7c6f434c]

@joachifm Not sure for multi-device setups: maybe adding multiple keys can be signed by just one of them?

@oxij should I merge it as-is today? I don't see any objections or drawbacks.

[zimbatm]

/cc @grahamc

[oxij]

Well, this can be merged as is, but I fear if we do that people will start treating this file as a source of truth for keys, which, I think, is bad if we only list the keys there and nothing else. Sure, we can require git commit signature as @joachifm said, but that's a bit hard to verify automatically. Ideally, I think, we want this file to be an input file for key signing parties. And nobody would want to semi-manually verify all the commits before each party. Surely, people will get lazy. So, I think, at least some self-signature hackery as above #47663 (comment) is required. Those values are easy to verify with a simple script (I planned to write it, but got sidetracked by other stuff), but, true, they are a bit large. So, I'd like to hear some feedback on that issue before merging this. If we do those signatures then the question of what exactly should be signed and in what format is also relevant.