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

Michael Prokop <[email protected]> Wed, 12 Aug 2026 20:25:38 +0200

Newsgroups	gmane.linux.debian.apt.devel
Message-ID	<2026-08-12T20-18-58__13909.685744305$1786559252$gmane$org@devnull.michael-prokop.at>

* Julian Andres Klode [Thu Jul 30, 2026 at 07:41:05PM +0200]:
> On Fri, Jul 24, 2026 at 06:15:07PM +0200, Michael Prokop wrote:
> > * Micah Anderson [Thu Apr 24, 2014 at 11:50:35AM -0400]:
> > 
> > > 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 apt-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
> > 
> > IMO we should clearly exit with non-zero in case of failures in apt
> > in such situations.
> > 
> > The behavior in apt v3.0.3 is still like this:
> > 
> > | % sudo apt update
> > | […]
> > | Err:5 https://demo.example.org/custom trixie InRelease
> > |   The following signatures were invalid: EXPKEYSIG BEFORE1FAILS2342 Automatic Signing Key <[email protected]>
> > | […]
> > | 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 invalid: EXPKEYSIG BEFORE1FAILS2342 Automatic Signing Key <[email protected]>
> > | W: Failed to fetch https://demo.example.org/custom/dists/trixie/InRelease  The following signatures were invalid: EXPKEYSIG BEFORE1FAILS2342 Automatic Signing Key <[email protected]>
> > | W: Some index files failed to download. They have been ignored, or old ones used instead.
> > | % echo $?
> > | 0
> > | %
> > 
> > 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.

Hm, but how does a Valid-Until entry help here if the repository itself
is still valid/supported/active, but only the key that's being used
on the client system expired?

(Greetings from after troubleshooting yet another system today,
having keyring issues because the keyring file was deployed as
/etc/apt/keyrings/foo.gpg while it should have been
/etc/apt/keyrings/foo.asc, and apt reporting exit code 0,
so it went unnoticed and the recent package updates were missing.)

regards
-mika-

signature.asc (application/pgp-signature, 833 B)