Page MenuHome GnuPG

gpgme-1.5.3 and gnupg-2 (gpgsm) incompatible?
Closed, ResolvedPublic

Description

Hello,

The OPTION with-secret=0 command is sent to gpgsm even if gpgsm-2.0 does not
support that option, gpgsm-2.1 does.

Reproduce using:
gpa-0.9.7
gpgme-1.5.3
gnupg-2.0.26

$ mkdir /tmp/h1
$ GPGME_DEBUG=1024:/tmp/gpgme.log GNUPGHOME=/tmp/h1/ gpa

GPGME 2014-12-26 01:12:58 <0x5f44> chan_12 -> OPTION with-secret=0
GPGME 2014-12-26 01:12:58 <0x5f44> _gpgme_io_recvmsg: check: 4f4b0a4552522035
3033333138323220 OK.ERR 50331822
GPGME 2014-12-26 01:12:58 <0x5f44> _gpgme_io_recvmsg: check: 556e6b6e6f776e20
6f7074696f6e203c Unknown option <
GPGME 2014-12-26 01:12:58 <0x5f44> _gpgme_io_recvmsg: check: 477067534d3e0a

GpgSM>.

Details

Version
1.5.3

Event Timeline

I guess that is possible. gpgsm does not get much attention these days.

The error return from sending this option is not checked on purpose. We do the
same for all such options.

werner claimed this task.
werner added a project: Not A Bug.

I am unsure I understand, this causes gpgme to fail.

GPGME 2014-12-26 01:12:58 <0x5f44> _gpgme_run_io_cb: call: item=0xd2e804f5b00,
handler (0xd2e804f5970, 13)
GPGME 2014-12-26 01:12:58 <0x5f44> chan_12 <- ERR 50331822 Unknown option <GpgSM>

GPGME 2014-12-26 01:12:58 <0x5f44> gpgme:status_handler: call:
gpgsm=0xd2e804f5970, fd 0xd: ERR line - mapped to: Unknown option

Thanks for the log. This reveals a bug which has been with us since the support
for gpgsm: If there is no status line handler but a status line is received
anyway the command handling loop terminates and thus the command/answer order
gets out of sync. In this concrete case this is triggered by sending an option
which starts the agent and that starting emits a "PROGRESS" status line.

My solution is not to stop reading after a status line but record a possible
error code and return that only after OK or ERR.

This will go into 1.5.5 which I am already preparing.

werner removed a project: Testing.