On Fri, Jul 24, 2026 at 06:15:07PM +0200, Michael Prokop wrote: > Hi, > > * 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. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
