Page MenuHome GnuPG
Create Task
Maniphest T1795

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

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

alonbl added a subscriber: alonbl.Dec 26 2014, 12:20 AM

539_gpgme.log209 KBDownload

alonbl added projects: Bug Report, gpgme.Dec 26 2014, 12:20 AM
alonbl set Version to 1.5.3.
• werner added a subscriber: • werner.Jan 2 2015, 5:27 PM

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

• werner added a project: gnupg (gpg20).Jan 2 2015, 5:27 PM
• werner added a comment.Jun 5 2015, 2:39 PM

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

• werner closed this task as Resolved.Jun 5 2015, 2:39 PM
• werner claimed this task.
• werner added a project: Not A Bug.
alonbl added a comment.Jun 5 2015, 7:00 PM

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

alonbl reopened this task as Open.Jun 5 2015, 7:00 PM
• werner added a comment.Jun 8 2015, 12:28 PM

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 added a project: Restricted Project.Jun 8 2015, 12:28 PM
• werner removed a project: Not A Bug.
• werner added a comment.Jun 8 2015, 7:56 PM

1.5.5 has been released.

• werner closed this task as Resolved.Jun 8 2015, 7:56 PM
• werner removed a project: Restricted Project.