Bug#745735: apt: Provide meaningful exit codes for gpg failures

Julian Andres Klode <[email protected]> Thu, 30 Jul 2026 19:41:05 +0200
Newsgroups gmane.linux.debian.apt.devel
Message-ID <20260730194012.GA111681__12895.4014204041$1785433407$gmane$org@debian.org>
On Fri, Jul 24, 2026 at 06:15:07PM +0200, Michael Prokop wrote:
> Hi,
>=20
> * Micah Anderson [Thu Apr 24, 2014 at 11:50:35AM -0400]:
>=20
> > It seems like from reading the code that the gpg signature verification=
 process doesn't
> > provide meaningful exit codes when bad things happen. This results in a=
pt-get update
> > providing an exit code of zero, even if there was a BADSIG. It would be=
 very useful
> > if we could get an exit code when these bad situations happen:
> >
> > BADSIG
> > NO_PUBKEY
> > KEYEXPIRED
> > REVKEYSIG
> > NODATA
>=20
> IMO we should clearly exit with non-zero in case of failures in apt
> in such situations.
>=20
> The behavior in apt v3.0.3 is still like this:
>=20
> | % sudo apt update
> | [=E2=80=A6]
> | Err:5 https://demo.example.org/custom trixie InRelease
> |   The following signatures were invalid: EXPKEYSIG BEFORE1FAILS2342 Aut=
omatic Signing Key <[email protected]>
> | [=E2=80=A6]
> | W: An error occurred during the signature verification. The repository =
is not updated and the previous index files will be used. GPG error: http:/=
/demo.example.org/custom trixie InRelease: The following signatures were in=
valid: EXPKEYSIG BEFORE1FAILS2342 Automatic Signing Key <[email protected]>
> | W: Failed to fetch https://demo.example.org/custom/dists/trixie/InRelea=
se  The following signatures were invalid: EXPKEYSIG BEFORE1FAILS2342 Autom=
atic Signing Key <[email protected]>
> | W: Some index files failed to download. They have been ignored, or old =
ones used instead.
> | % echo $?
> | 0
> | %
>=20
> I've seen too many unpatched + hacked systems which ended up as such
> due to expired GPG keys in their (usually 3rd party) Debian
> repositories. IMO this might even warrant a CVE.

APT's behavior is correct, a key failure keeps the previous state
around and if that state has no Valid-Until expiry, that's a repository
problem.

--=20
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en