For developers like myself who work across distributions, it is very
valuable to have a secure, simple and transparent way to bootstrap one
distro from another without relying on external trust anchors that
have to be verified manually.
This is exemplified by the presence of $distro keyrings in
$other_distros. For example, the Ubuntu keyring is available in
Debian, Arch, Gentoo and others. The Debian keyring is available in
Ubuntu, Fedora, CentOS and others. This allows one to run debootstrap,
or dnf, or zypper, or pacman natively on a distro, knowing that the
chain of trust is verified like any other package shipped by your
distro, and get a root filesystem of another distro. This is
especially useful for image building tools.
This requires updating the keyrings from time to time. For example,
until recently the Ubuntu keyring was outdated in Debian, and after
lots of nagging :-) Dimitri updated it (thanks Dimitri!). As another
example, Fedora does 2 releases a year, and each one requires a
keyring update as a new key is used for a new release.
We are now in such a time of the year, as a new Fedora release is
being prepared. So I filed a Launchpad bug, and asked a patch pilot
for help and Lena kindly helped with the task (thanks Lena!). This was
uploaded as an SRU (note that I'd be fine with stable-backports too,
but I do appreciate the extra effort of course).
At this point an objection was raised Robie, quoting directly from Launchpad:
"I'm declining to process these without consensus amongst Ubuntu
developers that constant SRUs of these packages is the right
architecture to use."
As far as I can understand, the concern seems to be around future
maintenance costs. All keyring packages are the same: they ship a set
of keys, with no running code, or scripts, or build required, simply
move a set of files into a package and ship it. They are all
maintained in git, on Salsa. Updates means new keys are added upstream
by the respective owners - Debian keyring owners, Ubuntu keyring
owners, Archlinux keyring owners, RPM distro keyring owners. The
package structure is extremely unlikely to change. Regressions are
likewise unlikely: there is no running code, neither at build time nor
at runtime.
As the maintainer in Debian, I am ok with preparing and testing these
updates, before asking for a sponsored upload.
It is also important to note that these are separate and independent
packages, maintained independently by different people, the actual
owners of each keyring - and it's important that it's the owner of the
keyrings that manage them, for trust reasons - imagine if someone who
is not an Ubuntu developer or a Canonical employee was sending around
the Ubuntu key, asking others to trust it! It would not be, let's say,
an optimal arrangement. The RPM distros are quite good at
collaborating, so distribution-gpg-keys is the single source that is
needed for all RPM based distros. Ubuntu, Debian and Arch each have
their own repository, independently, so independent packages are
needed.
Given all of this, the costs appear minor, especially compared to
other updates that are part of point releases. Is there perhaps some
angle or detail that I am missing here? I appreciate Robie
double-checking that this is the right way to do it. I hope I was able
to explain that the architecture is the one commonly used and would
expect adding a different Ubuntu-only alternative would likely be a
costly approach, for little benefit. Therefore I wanted to ask if we
can agree on this kind of sporadic updates being ok? If it is helpful
we could even draft something to be added to
https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases
so anyone involved in the future can refer to it more easily.
Thanks!
https://bugs.launchpad.net/ubuntu/+source/distribution-gpg-keys/+bug/2075505
https://bugs.launchpad.net/ubuntu/+source/archlinux-keyring/+bug/2076416
https://tracker.debian.org/pkg/distribution-gpg-keys
https://tracker.debian.org/pkg/archlinux-keyring
--
Kind regards,
Luca Boccassi
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
