On Fri, 2020-12-18 at 01:15 +0000, Paul Wise wrote: > On Thu, Dec 17, 2020 at 10:03 AM Ansgar wrote: > > > (Bonus points if this keeps the original signature if possible.) > > Two separate signatures is possible for Release+Release.gpg, just > rename the latter to .old, but what can you do for InRelease? Is it > possible to have multiple signatures in one blob of signing data? Is > it possible to take an existing signature and add a second one to it? > Can the same thing be done for Release.gpg? Do apt, gpg and gpgv cope > with this sort of thing? > Okay, so maybe my deep dive into old Debian versions was worth it. If you look at Etch, you will see a Release.gpg with two signatures. Per the Etch-era Debian Wiki page on this[1], that's because it was decided that Etch should be signed with both the 2005 and the 2006, to keep an upgrade path in place. Now, due to a bug in apt (fixed in 0.6.43.1), the systems began to expect both keys to be present, but assuming that there hasn't been any regressions in that, I believe Apt will work as intended if we add new signatures by appending them onto the release.gpg. Apt was totally fine processing the Etch release file when I tested it: it complained separately about each key being expired, implying that it would work of a third, unexpired key was in that list. Calum [1]: https://wiki.debian.org/SecureApt#Debian_archive_key_expiry
Attachment:
signature.asc
Description: This is a digitally signed message part