canonical / craft-archives

A library for handling archives/repositories in Craft applications
https://canonical-craft-archives.readthedocs-hosted.com
GNU Lesser General Public License v3.0
0 stars 7 forks source link

AptKeyManager.install_key() is unnecessarily restrictive #83

Closed basak closed 12 months ago

basak commented 1 year ago

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:

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 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?

tigarmo commented 1 year 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.

basak commented 1 year ago

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?

tigarmo commented 12 months ago

Fixed by #86