Mailing List Archive

Hi *,

I had to notice that I ported my application in the wrong way from gpgme-1.9.0
to 1.13.1 some years ago (now using latest, of course).

GPGME-1.10.0 introduced the new key deletion flag GPGME_DELETE_FORCE and the new
function gpgme_op_delete_ext, but somehow I failed to use the new function.
Instead, my code looked like this:

gpgme_error_t err = gpgme_op_delete (ctx,
key,
GPGME_DELETE_ALLOW_SECRET | GPGME_DELETE_FORCE);
if (err) {
handle_error(...);
}

Unluckily, both gpgme_op_delete and the newer gpgme_op_delete_ext have an
integer type as third parameter, and therefore the GCC compiler didn't warn
either, not even with -Wextra.

As an effect, GPGME does not add the '--yes' option to the gpg call.
Well, it was like that, but I was surprised to see that gpgme_op_delete does
not return an error while the underlying `gpg` call fails:

$ gpg --disable-dirmngr --batch --pinentry-mode=loopback --no-tty \
--delete-secret-and-public-key -- E7C0CD48F8BB8CFF481AC5D4408E548D1D380ED9
gpg: can't do this in batch mode without "--yes"
gpg: E7C0CD48F8BB8CFF481AC5D4408E548D1D380ED9: delete key failed: End of file
$ echo $?
2

Shouldn't gpgme_op_delete better propagate this error from GPG back to the caller?
With that, I'd have detected my above porting fault much earlier.

'gpgme.trace' attached.

Thanks & have a nice day,
Berny