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