Hi folks,
following the discussion in the bug below (cross-posting with
the bug probably provides a worse experience).
# Key take away for ftp/release
Introducing a maximum validity will make it infeasible for Debian
stable releases to be signed offline with multiple keys as is the
practice now.
# Introduction and rationale
We had this discussion internally a bunch of times and it's only
coming up more and more:
We need to introduce a maximum validity for repositories. As security
requirements from audits and such are increasing steadily, allowing
repositories without a meaningful expiration becomes a liability.
Also key expiry is no longer the same thing with Sequoia, an expired
key is not revoked and continues to be trusted for signatures prior to
the expiry.
# Proposal
My proposal is that a repository is only valid for 30 days. This
strikes a good balance between ensuring that (mostly 3rd party)
repositories are not mismanaged and users receive updates.
However, introducing a 30 day maximum validity immediately would
create undue work on repository operators, therefore my proposal
is to limit this such that old repositories:
(1) A repository without a `Valid-Until:` field receives an implicit
Valid-Until of `max(2028-02-05, Date + 30 days)`.
- Date values up to 2028-01-05 (approx) expire on 2028-02-05
- Date values starting 2027-01-06 expiry 30 days later
A diagnostic is issued with `apt --audit update` for such
repositories indicating that an explicit Valid-Until field
is best practice.
February 5 is chosen to align with Sequoia's deprecation
schedule.
(2) A repository with a `Valid-Until` field after 2028 is ill-formed
if the `Valid-Until - Date > 30 days`, produces a warning, and
is capped to 30 days.
(The concrete mechanism should probably be discussed further on
the bug though, this email is mostly around the infrastructure
side issue).
----- Forwarded message from Julian Andres Klode <[email protected]> -----
Date: Wed, 21 Oct 2026 11:43:42 +0200
From: Julian Andres Klode <[email protected]>
To: Christian Noé Ramos López <[email protected]>,
[email protected]
Subject: Re: Bug#1151504: apt: no default age limit for a Release file
without Valid-Until
Message-ID: <[email protected]>
Mail-Followup-To: Julian Andres Klode <[email protected]>, Christian Noé Ramos
López <[email protected]>, [email protected]
Accept-Language: de-DE, de, en-GB, en-US, en
Tags: lists lists/apt sent
Not sure where the paragraphs went, so I reformatted this for you.
On Tue, Oct 20, 2026 at 11:31:54PM -0600, Christian Noé Ramos López wrote:
> 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 [email protected] 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.
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.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
----- End forwarded message -----
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
