Package: snapshot.debian.org
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

Excellent idea, documenting it in the bug tracker.

It doesn't seem too complicated to implement and could be developed
independent from snapshot.d.o:

If any Release.gpg/InRelease file is requested:

- Retrieve the original Release+Release.gpg/InRelease files.
- If there is a valid signature from any previous archive key:
  - Generate new signature (Release.gpg/InRelease) and store it in 
    some cache.
    (Bonus points if this keeps the original signature if possible.)
  - Return the generated Release.gpg/InRelease.
- Otherwise:
  - Return some HTTP error? Or the unmodified Release.gpg/InRelease?

Any other files:

- Redirect to normal snapshot.d.o

Only some storage for recently-requested Release.gpg/InRelease files
would be needed.  The service could run independent from snapshot.d.o
and redirect most requests there.

Maybe the same could be done for archive.d.o?

I might be interested to experiment with this as it seems reasonably
small project to implement. :-)

Ansgar

Hi Ansgar!

That would be fantastic and a huge improvement in user experience.

Adrian

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

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.

Ansgar