Enhancing cross-distro collaboration via foreign archive keyring availability

[Luca Boccassi]

On Wed, 4 Sept 2024 at 11:31, Neal Gompa <ngompa13 at gmail.com> wrote:
>
> On Wed, Sep 4, 2024 at 6:27 AM Luca Boccassi <luca.boccassi at gmail.com> wrote:
> >
> > Hi,
> >
> > 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
> >
>
> At least with distribution-gpg-keys, it might help with the churn if
> the "distribution-gpg-keys-copr" package was not shipped in Debian or
> Ubuntu. I don't ship it in openSUSE either[1].

Yeah of course, updates that only touch that "side" keyring would
never qualify for backports, as it's not really worth it, the
important one is the "main" keyring, which ships distro keys.