Closed basak closed 12 months ago
The primary key fingerprint is used to uniquely identify the keyfile in /etc/apt/keyrings
. The well-intentioned purpose of the restrictive test was just to protect against doing the "wrong" thing because none of our typical test keys had more than one fingerprint (this is the first time this issue has been reported, from what I can tell, although it's fairly used in both Snapcraft and Rockcraft).
But as you say, subkeys are the default and we can just update the code to look for the right fingerprint; it should be the first one, and it's the fpr:
record that relates to a pub:
key (as opposed to a sub:
) key.
Thanks!
this is the first time this issue has been reported, from what I can tell, although it's fairly used in both Snapcraft and Rockcraft
FWIW, git-ubuntu CI uses the snapcraft stable snap, and this started breaking on Friday. So I think this has only been live via Snapcraft since Friday?
Fixed by #86
git-ubuntu CI started failing on Friday with:
The key I'm using is generated like this:
I've tested this just now, and it works perfectly fine with apt on Jammy if I export it and stick it in
trusted.gpg.d
.The issue seems to be that you see multiple fingerprints. For example:
Then
install_key
seems to think that's unacceptable for some reason, even though a key with a subkey is gpg's default, results in multiple fingerprints, and apt doesn't have a problem with it.This is frustrating because I'm deep in the workaround of a workaround to build git-ubuntu already and snapcraft seems to delivered a behaviour-breaking change.
@lengau or @sergiusens please could you take a look?