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
