It now looks like this problem's root cause was a keyring that got corrupted while I was debugging some problems with refreshing pacman's keyring. That is to say, it looks like I do not have a genuine "in the wild" key collision. It looks like my own public key became copied to both me and one of the TUs in the keyring.
With that said though, I suppose it's still not impossible for long key IDs to genuinely collide.
On Mon, Apr 24, 2017 at 11:06:05AM +1000, Allan McRae wrote:
Can you tell me what happens both before and after this patch with ambiguous key IDs.
Please find attached two log files before and after. As you can see, pacman used to blindly run ahead, trying to check the signature even though it could not get the key from the keychain. A quick look at a backtrace (not attached) shows this to be a segmentation fault after control is passed to libgpgme.
Also, what happens if you only have one of the keys in the keyring and want to match the other?
I cannot test this, since it turns out to be a corrupt keyring where the key in question looks to be attached to two people and is exactly the same.
Perhaps we also need to look at matching the whole key fingerprint...
If the issue with collisions comes up again and doesn't end up being put down to a corrupt keyring, this would be a good idea. For now, it seems like seeing this in the wild too narrow a possibility, but there is still a clear hiccup with tht way pacman behaves before this patch.