Add distribution-gpg-keys 1.104+ds-2 to noble

[Luca Boccassi]

[Impact]

distribution-gpg-keys is a package in Oracular that provides an archive of GPG keys for RPM-based distributions.

As stated by the reporter, this package allows users to bootstrap and build RPM distributions, useful for CI and image building purposes.

The package should be added to noble as well to provide the functionality to LTS users.

[Test Plan]

To test, the package should be installed on noble, and gpg keys should be checked. This can be done with the following commands:

$ sudo apt update
$ sudo apt upgrade
$ sudo apt install distribution-gpg-keys distribution-gpg-keys-copr
$ gpg --import /usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-CentOS-10
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 05B555B38483C65D: public key "CentOS (CentOS Official Signing Key) <email address hidden>" imported
gpg: Total number processed: 1
gpg: imported: 1
$ gpg --import /usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-CentOS-9
gpg: key 05B555B38483C65D: "CentOS (CentOS Official Signing Key) <email address hidden>" 1 new signature
gpg: Total number processed: 1
gpg: new signatures: 1

etc.

The package should also be tested by using its gpg keys for image building, such as with mkosi.

[Where problems could occur]

Since the package will be new to noble, it has not yet been tested in that version. Therefore if problems were to occur, it would most likely be in interactions with other packages. This could show up as conflicts in the /usr/share directory, or failures when using the contained gpg keys.

[Original Description]
Impact

This package was introduced in Oracular and is a simple archive of GPG keys for RPM-based distributions like Fedora, CentOS, Azure Linux and many more. It ships nothing but these keys, in a package-specific subdirectory.
It is useful to bootstrap and build those distributions on Noble, like we do in the systemd upstream CI using the mkosi image builder.
A simple rebuild with a new changelog entry is sufficient.

Scope

Backport version 1.104+ds-2 from oracular to noble-backports

Other Info

The package has no reverse dependencies in noble as it's new in oracular, so risk is very low. The GPG archive is updated a few times a year and might use follow-ups to update the keys.

[Lena Voytek (lvoytek)]

Thanks for the bug report Luca! As discussed on ubuntu-devel I will update this from a backports bug to SRU bug so we can include it as a new noble package in the archive. I created a PPA for noble here: https://launchpad.net/~lvoytek/+archive/ubuntu/distribution-gpg-keys-noble

[Robie Basak (racb)]

The SRU review queues are backed up at the moment and future updates to this package will take time, too. Is there any reason this can't go into noble-backports instead, or indeed remain outside the official archive for whatever outside-Ubuntu CI needs you have? That way, updates would be much quicker for you.

[Robie Basak (racb)]

And similarly if there's a security revocation required, then this wouldn't be an additional burden on the Ubuntu security team, either.

[Luca Boccassi (bluca)]

It would provide more value in noble proper, however if there are external reasons like a long review queue, I am perfectly ok with having this in noble-backports.

I'd like to have it in the archive though rather than out of tree, as this is useful for users of image building tool in general, to provide a fully verified way of retrieving the keyrings. It's a good thing that all distributions ship the keys for all other distributions, so that you can securely bootstrap one from another. ubuntu-archive-keyring is available in Debian and Fedora, for example.

[Robie Basak (racb)]

Also see bug 2076416.

I'm declining to process these without consensus amongst Ubuntu developers that constant SRUs of these packages is the right architecture to use.

[Luca Boccassi (bluca)]

> I'm declining to process these without consensus amongst Ubuntu developers that constant SRUs of these packages is the right architecture to use.

I don't think "constant" is an accurate description, I don't plan to ask for a backport for every release (there's one once a month on average or so), but only a couple of times a year. I will do the same in Debian stable, where I am the maintainer.
Also there's not really any "architecture" here, it's just a collection of keys, shipped as inert data. There's no running code, no scripts, no clients, nothing that changes, it's simply inert data that is shipped and is updated from time to time. The clients are zypper and dnf, and they are maintained separately and independently.

[Luca Boccassi (bluca)]

https://lists.ubuntu.com/archives/ubuntu-devel/2024-September/043098.html