Hello,

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

Thank you,
micah

Hi,

* Micah Anderson [Thu Apr 24, 2014 at 11:50:35AM -0400]:

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 <demo@example.org>
| […]
| 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 <demo@example.org>
| W: Failed to fetch https://demo.example.org/custom/dists/trixie/InRelease  The following signatures were invalid: EXPKEYSIG BEFORE1FAILS2342 Automatic Signing Key <demo@example.org>
| 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.

regards
-mika-

Am Fri, Jul 24, 2026 at 06:15:07PM +0200, schrieb Michael Prokop:

If apt were to exit non-zero in these situations you would "see too many
unpatched + hacked systems" as unattended upgrades from the main
(and security) repositories of your distribution are not applied thanks
to some tiny long forgotten 3rd party repo the user might not even have
any packages installed from any longer…

So, I don't think there is a trivial black-or-white answer.

I also note that with `--error-on=any` nowadays you can make these types
of problems result in a non-zero exit code. There exists currently no
way of programmatically knowing the difference through.


Best regards

David Kalnischkies

Hi,

* David Kalnischkies [Mon Jul 27, 2026 at 11:48:12AM +0200]:
[...]

Ah good point, thanks.

Hm, couldn't we consider 'apt update' + 'apt upgrade' two separate
steps, so even if 'apt update' returns with an exit code other than
zero, its consecutive 'apt upgrade' gets still executed/applied
(with only the repositories considered that do *not* raise an
error)?

Maybe I'm missing something, but isn't it already
apt-daily.service's "/usr/lib/apt/apt.systemd.daily update" which
does the update part, and unattended-upgrades.service (from
unattended-upgrades) which does the actual upgrade part then (so the
exit code not actually being relevant)?

regards
-mika-

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.

* Julian Andres Klode [Thu Jul 30, 2026 at 07:41:05PM +0200]:

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-