Page MenuHome GnuPG
Create Task
Maniphest T7351

2.2.45 exitcode 2 when importing revocation cert for expired key
Open, NormalPublic
Actions

Description

Hello,

this came up as part of ostree's testsuite. Minimal testcase:

#!/bin/sh

MYGPGHOME=`mktemp -d`

cp -a /tmp/ostree-2024.8/tests/gpghome/* ${MYGPGHOME}/
gpg --homedir=${MYGPGHOME}  --version
# The GPG private keyring in gpghome is in the older secring.gpg
# format, but we're likely using a newer gpg. Normally it's
# implicitly migrated to the newer format, but this test hasn't
# signed anything, so the private keys haven't been loaded. Force
# the migration by listing the private keys.
gpg --homedir=${MYGPGHOME} -K > /dev/null

gpg --verbose --homedir=${MYGPGHOME} \
	--quick-set-expire 5E65DE75AB1C501862D476347FCA23D8472CDAFA seconds=1
echo DEBUG quick-expire exit status $?
sleep 2
gpg --verbose --homedir=${MYGPGHOME} --import \
	/tmp/ostree-2024.8/tests/gpghome/revocations/key1.rev
echo DEBUG import rev exit status $?
rm -rf ${MYGPGHOME}

The import of the revocation cert exits with error code 2 for 2.2.45 but exited with success for 2.2.44 and also exits with success for 2.4.5.

Just grab the ostree tarball from here to get the examle certs: http://deb.debian.org/debian/pool/main/o/ostree/ostree_2024.8.orig.tar.xz

cu Andreas

Details

External Link
https://bugs.debian.org/1086140
Version
2.2.45

Revisions and Commits

rG GnuPG
rG48aa9e826579 gpg: Do not fail with an error for a "Note:" diagnostic

Event Timeline

ametzler1 created this task.Sun, Oct 27, 6:18 PM
• werner added a subscriber: • werner.Mon, Oct 28, 9:46 AM

Indeed, gpg fixes a long standing bug in that expired trusted-keys were not correctly handled. Thus this error message

gpg: Note: ultimately trusted key 7FCA23D8472CDAFA expired

according a message in the Debian tracker. which forces a failure exit status due to the use of log_error(). Without erroring out ppl will ignore the message and latter wonder why things don't work as expected. I'd say better fix that test.

ametzler1 added a comment.Tue, Oct 29, 6:13 PM

Hello,
I have a hard time to agree that is the right thing for gnupg to throw an error if it successfully imported a revocation certificate for an expired key. This is a meaningful (and not useless) change even if the key is expired.

cu Andreas

• werner added a comment.Wed, Oct 30, 8:08 AM

Hi!

I reviewed this and there are actually two changes. The first chnage
is a simple string change from

-  public key of ultimately trusted key %s not found
+  Note: ultimately trusted key %s not found

The second is what triggers your regression test:

+  Note: ultimately trusted key %s expired

right after the code has figured that the key exists. Now in the way
we use those keys an expired key should lead to the the same behaviour
as a non-existent key. In this regard the use of log_error instead of
log_info is correct. The question is whether the use of the first
log_error for the not found which was introduced 20 years ago or so is
also wrong.

Of course a diagnostic starting with "Note:" does not look like an error
message.

This can be argued but I will change both to log_info in master.
Whether you want to add yet another patch to Debian's 2.4 is of course
up to you. We will backport this only if our own testing with
Kleopatra et al. will show that such a change is needed. Application
using gpgme may not be affected because due to double-forking we
can't rely on the exit code anyway (some code paths may check the
final error status, though).

• werner added a commit: rG48aa9e826579: gpg: Do not fail with an error for a "Note:" diagnostic.Wed, Oct 30, 8:14 AM
• werner triaged this task as Normal priority.Wed, Oct 30, 8:32 AM