Page MenuHome GnuPG

add a parameter to GOT_IT to communicate any errors
Closed, ResolvedPublic

Description

Merely by looking add --status-fd, one cannot distinguish whether "addkey"
actually started the key-generation workflow or not; GOT_IT is output in both
cases. Obviously, I should not be expected to read the error message from the TTY.

$ gpg2 --expert --command-fd 0 --status-fd 3 3>&1 2>/dev/null >/dev/null
--edit-key dkg
[..]
[GNUPG:] GET_LINE keyedit.prompt
addkey
[GNUPG:] GOT_IT
Need the secret key to do this.

Anyway the error can be something else. Probably no-one will expect this one:

$ gpg2 --expert --command-fd 0 --status-fd 3 3>&1 2>/dev/null >/dev/null
--edit-key infinity0
Secret key is available.
[..]
[GNUPG:] GET_LINE keyedit.prompt
addkey
[GNUPG:] GOT_IT
Secret parts of primary key are not available.

Details

Version
2.1.0

Event Timeline

Please read the docs and sample code (I suggest gpa and gpgme). GOT_IT
indicates that a line has been received in response to a GET_xxx status.

infinity0 renamed this task from addkey claims success (GOT_IT) even when no secret key to add a parameter to GOT_IT to communicate any errors.Sep 26 2014, 12:45 AM
infinity0 removed a project: Bug Report.
infinity0 added a project: Feature Request.

I could not easily figure out what I was supposed to infer from the source code
of gpa or gpgme, but after playing about with it, I suppose I can detect the
error by noticing that the next GET_LINE issues a keyedit.prompt rather than
continuing with the workflow. This means I will have to write some state-keeping
logic instead of merely switching on the GET_LINE, and all users of this
interface will need to implement a similar thing.

To reduce the complexity for scripters here, might I suggest adding an extra
parameter to GOT_IT to explicitly communicate to the client script about any
errors? At least from the gpa/gpgme code it seems there is a generic parser that
can cope with extra parameters to any status line.

If anyone is affected by this (I don't know of others using this interface),
they can easily rewrite their parsing code to cope with both the old and new
GOT_IT lines (with or without a parameter).

BTW, this is the sort of thing that documentation would be helpful for.

werner claimed this task.

GOT_IT merely tells that a line was received. There is and can't be any more
semantics.