[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#763419: apt ignoring check-valid-until flag

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


[1]: https://wiki.debian.org/SecureApt#Debian_archive_key_expiry

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: