-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AptKeyManager.install_key() is unnecessarily restrictive #83
Comments
The primary key fingerprint is used to uniquely identify the keyfile in 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 |
Thanks!
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? |
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
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?
The text was updated successfully, but these errors were encountered: