Enhancing cross-distro collaboration via foreign archive keyring availability

[Neal Gompa]

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].

[1]: https://code.opensuse.org/package/distribution-gpg-keys/blob/master/f/distribution-gpg-keys.spec



-- 
真実はいつも一つ！/ Always, there's only one truth!