Package: apt Version: 3.0.3 Severity: wishlist [en blanco] For a
repository whose Release file has no Valid-Until, apt by default puts
no limit on how old that file may be. The one limit there was, the
gpgv method refusing a signature by a key that has expired since, went
away when sqv became the default method (da9a05e0), and nothing
replaced it. I reported this privately to security@debian.org on 8
October 2026, and it was closed on 12 October: sqv judges a key's
expiry at the time of the signature by design, and I am not asking to
change that. The row from that report, run again on 21 October with
apt 3.0.3, no lists yet and a file:// repository: an InRelease dated
and signed on 1 June 2025 by a key that expired on 1 January 2026 is
refused under the gpgv method (EXPKEYSIG) and accepted under the sqv
method, sixteen months after its Date, without a warning. The controls
come out the same under both methods: a signature made that day by a
key that does not expire is accepted, and one made after its key
expired is refused. Acquire::Max-ValidTime, or Valid-Until-Max in
sources.list, sets such a limit: set to a week, it makes the sqv
method refuse that InRelease as expired and still accept one dated
that day. Its default is 0, "valid forever". apt could warn, or
refuse, by default when a Release file without Valid-Until is older
than some threshold measured against the current date; either would
make the case in the original report visible. Debian's own trixie
InRelease has no Valid-Until; trixie-updates and trixie-security have
seven days. Christian Ramos Norte Software chris@nortesoftware.dev

Not sure where the paragraphs went, so I reformatted this for you.

This is being discussed but we run into a fundamental issue where Ubuntu
or Debian stable releases do not get resigned (Debian does until point
release), and the end of life may want to be bumped so there's no clear
end of life date to set.

We should, going forward, establish a maximum validity for repositories,
and tighten this progressively. I believe I good idea could be to say
that we define a cut-off date and all repositories will expire on:

    max(30 days after issuing time,a year after the cut-off date)

[30 days just for the sake of argument, further consultation to follow]

Unfortunately that's a significant shift that will also require some
additional infrastructure work on archive operators; and especially for
Debian stable releases, which are signed with offline keys currently
it is a significant shift in expectations.