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

We do that for stable's InRelease and Release.gpg: it is signed by keys
held by ftp-master and stable release team and we merge the signatures.
For detached signatures you can even just concatenate two ascii-armored
signatures and GnuPG will find all signatures (we did that for older
releases). InRelease requires merging them.

For GnuPG to check multiple signatures they must all use the same
message digest (i.e. all signatures must use SHA-256, not one SHA-256
and another SHA-512 or similar), but for a signature-refreshing service
we probably don't want new signatures for old Release files to use MD5
or SHA-1 even when the old signature did.

For our use case consumers must accept when /any/ signature is valid
for this (not /all/!); this doesn't make it less secure as we just
require a single signature anyway so an attacker having one could drop
additional signatures.  Other applications might want to explicitly
require more than one valid signature.


Reply to: