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. regards -mika-
signature.asc
Description: PGP signature
