FS#35478 - pacman-key tries to disable invalid keyids
Attached to Project:
Pacman
Opened by Pierre Schmitz (Pierre) - Sunday, 26 May 2013, 07:39 GMT
Last edited by Allan McRae (Allan) - Thursday, 06 June 2013, 03:39 GMT
Opened by Pierre Schmitz (Pierre) - Sunday, 26 May 2013, 07:39 GMT
Last edited by Allan McRae (Allan) - Thursday, 06 June 2013, 03:39 GMT
|
Details
When suppling a *-revoked file containg keyids to be
disabled, pacman-key uses gpg --list-keys which does not
only contain keyids.
See archlinux-keyring >= 20130525-1 |
This task depends upon
Closed by Allan McRae (Allan)
Thursday, 06 June 2013, 03:39 GMT
Reason for closing: Fixed
Additional comments about closing: git commit d080a469
Thursday, 06 June 2013, 03:39 GMT
Reason for closing: Fixed
Additional comments about closing: git commit d080a469
# Read the revoked key IDs to an array. The conversion from whatever is
# inside the file to key ids is important, because key ids are the only
# guarantee of identification for the keys.
...and to be honest, I don't see why it does the conversion in the first place. I mean, it immediately gives the "converted" key IDs to the *same* GnuPG which converted them in the first place... wouldn't it achieve exactly the same by using each line from foo-revoked directly with `gpg --edit-key`?
Not to mention that `archlinux-revoked` currently contains the full 160-bit fingerprint of the revoked key. It is a *better* identifier than a 64-bit key ID, so requiring foo-revoked lists to have the fingerprints would be better than wasting time with the conversion.
Also: atm the script fails silently when trying to disable invalid keys. It would be better to bail on any error here. It's quite important to know that disabling a key way successful.
+1 to interpreting data from -revoked file as real IDs. I see no reason that we should be leaving these up to "interpretation".