AptKeyManager.install_key() is unnecessarily restrictive
Metadata
Current evaluation
Fixed by merged PR canonical/craft-archives#86 (commit 9a9706b), making AptKeyManager.install_key() handle keys with primary and subkey fingerprints.
Resolution: closed resolved
Reason: PR #86 was merged as commit 9a9706b and updated install_key() to distinguish primary-key fingerprints from subkeys, resolving the overly restrictive multiple-fingerprint failure.
Evaluated by: mr-cal-bot
No scores available.
Issue body
git-ubuntu CI started failing on Friday with:
```
File "/snap/snapcraft/9362/lib/python3.8/site-packages/snapcraft_legacy/internal/project_loader/_config.py", line 304, in get_build_packages
self.install_package_repositories()
File "/snap/snapcraft/9362/lib/python3.8/site-packages/snapcraft_legacy/internal/project_loader/_config.py", line 288, in install_package_repositories
refresh_required |= key_manager.install_package_repository_key(
File "/snap/snapcraft/9362/lib/python3.8/site-packages/craft_archives/repo/apt_key_manager.py", line 257, in install_package_repository_key
self.install_key(key=key_path.read_text())
File "/snap/snapcraft/9362/lib/python3.8/site-packages/craft_archives/repo/apt_key_manager.py", line 170, in install_key
raise errors.AptGPGKeyInstallError(
craft_archives.repo.errors.AptGPGKeyInstallError: Failed to install GPG key: Key must be a single key, not multiple.
```
[The key I'm using is generated like this](https://git.launchpad.net/git-ubuntu/tree/snap.sh):
```
gpg --batch --gen-key <<EOF
%no-protection
Key-Type:1
Key-Length:2048
Subkey-Type:1
Subkey-Length:2048
Name-Real: git-ubuntu build script apt repo
Name-Email: ubuntu-devel-discuss@lists.ubuntu.com
Expire-Date:0
EOF
```
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:
```
# gpg --batch --with-colons --import-options show-only --import < ../gnupg/foo.asc
gpg: WARNING: unsafe permissions on homedir '/root/gnupg2'
gpg: keybox '/root/gnupg2/pubring.kbx' created
gpg: /root/gnupg2/trustdb.gpg: trustdb created
pub:-:2048:1:9A9F07F9BD49CB1D:1687185792:::-:::escaESCA::::::23::0:
fpr:::::::::5849B0FE4021A4199CAA35C49A9F07F9BD49CB1D:
uid:-::::1687185792::999DBCEE6A5EB95471D20030B66D691AE0F70E85::git-ubuntu build script apt repo <ubuntu-devel-discuss@lists.ubuntu.com>::::::::::0:
sub:-:2048:1:FE10EAAB3091D15B:1687185792::::::esa::::::23:
fpr:::::::::D8FE8335189761979D45A039FE10EAAB3091D15B:
```
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](https://bugs.launchpad.net/snapcraft/+bug/1918969) of a [workaround](https://bugs.launchpad.net/snapcraft/+bug/1918968) to build git-ubuntu already and snapcraft seems to delivered a behaviour-breaking change.
@lengau or @sergiusens please could you take a look?
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha | — | closed resolved | Fixed by merged PR canonical/craft-archives#86 (commit 9a9706b), making AptKeyManager.install_key() handle keys with primary and subkey fingerprints. | |
| stealth/space-bunny-alpha | — | closed resolved | Fixed by merged PR #86 (commit 9a9706b): install_key() now recognizes primary GPG fingerprints and accepts keys with subkeys, resolving the CI failure. | |
| qwen/qwen3.6-35b-a3b | — | — | Fixed by PR #86. AptKeyManager.install_key() incorrectly rejected GPG keys with subkeys due to a restrictive fingerprint check. The code now correctly identifies the primary key fingerprint, resolving the CI failure. | |
| qwen/qwen3.6-35b-a3b | — | — | AptKeyManager.install_key() rejected GPG keys with subkeys due to a restrictive fingerprint check. Validation was updated to extract the primary key fingerprint. The issue was closed after being fixed by PR #86. | |
| qwen/qwen3.6-35b-a3b | — | — | Fixed by PR #86. AptKeyManager.install_key() incorrectly rejected GPG keys with subkeys due to multiple fingerprints. The code now correctly identifies the primary key fingerprint, resolving the unnecessary restriction. |
Update history
No update history recorded yet.
Related work
-
Likely Fixed By:
canonical/craft-archives#86
(confidence 100%)
Merged PR titled "keys: make AptKeyManager.install_key() more robust"; its change was recorded as commit 9a9706b.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #85 keys: make AptKeyManager.install_key() more robust | craft-archives | closed | Closed unmerged; the intended AptKeyManager.install_key() robustness work landed in craft-archives#86 via commit 9a9706b. | |
| #86 keys: make AptKeyManager.install_key() more robust | craft-archives | merged | Merged as 9a9706b: AptKeyManager.install_key() now accepts multi-key input, tolerates GPG diagnostics, and can verify a target fingerprint. |