Am Fri, Jul 24, 2026 at 06:15:07PM +0200, schrieb Michael Prokop: > 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.
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
signature.asc
Description: PGP signature
