assuan_read_from_server() and return value
bjk at luxsci.net
Sat Jan 5 20:01:03 CET 2008
On Mon, Dec 17, 2007 at 05:10:37PM +0100, Marcus Brinkmann wrote:
> Ah, so now we are talking about the _assuan_read_from_server at the
> "again:" label in _assuan_transact?
> In this case, the ERR should set OKAY to 0 and OFF to the offset of
> the error code, and then assuan_transact should execute:
> if (!okay)
> rc = atoi (line);
> if (rc > 0 && rc < 100)
> rc = _assuan_error (ASSUAN_Server_Fault);
> else if (rc > 0 && rc <= 405)
> rc = _assuan_error (rc);
> Thereby returning the error code as it should. Why is that code not
> working for you?
Didn't see this code. Sorry. This works as it should.
If there is no error source set (which pinentry doesn't do)
_assuan_error() will return the unmasked error code, and for the
application (which uses gpg-error), it is impossible to determine if the
error is an ASSUAN_ or GPG_ERR error code. So the problem (in my case)
is with pinentry not setting an error source.
I have an app that uses gpg-error codes. The app connects to pinentry
via assuan_pipe_connect(). I call assuan_transact() to send the GETPIN
command to pinentry. If I cancel the pinentry by selecting the Cancel
button, assuan_transact() returns ASSUAN_Canceled (111). But for an app
that uses gpg-error, the error is seen as GPG_ERR_INV_CARD (111). So in
my app I have to test for both GPG_ERR_ASS_CANCELED and ASSUAN_Canceled.
If nobody else is doing it, I could patch pinentry to use libgpg-error.
I'm not sure how this would affect other clients though?
Thanks, and sorry for the confusion.
Benjamin J. Kibbey bjk at luxsci.net/jabber/freenode
3019 F5FC AA33 5BC7 BE9F 09D2 393E DBD2 40D5 FA7E
More information about the Gnupg-devel