Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

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
Task Type Bug Report
Category General
Status Closed
Assigned To Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version 4.1.1
Due in Version 4.1.2
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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
Comment by Mantas Mikulėnas (grawity) - Sunday, 26 May 2013, 09:59 GMT
pacman-key should be checking that the first field is "pub", instead of ignoring it, but I'm more interested in this comment...

# 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.
Comment by Pierre Schmitz (Pierre) - Sunday, 26 May 2013, 10:09 GMT
I agree that requiring the complete key id makes sense here.

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.
Comment by Dave Reisner (falconindy) - Monday, 03 June 2013, 16:48 GMT
Sadly, gpg can't tell you when disabling the key fails in batch mode. It simply doesn't output anything when it fails. We'll have to figure out something a little more clever here, even if it's something as stupid as checking the status of the key post-disabling.

+1 to interpreting data from -revoked file as real IDs. I see no reason that we should be leaving these up to "interpretation".

Loading...