assuan_read_from_server() and return value

Ben Kibbey bjk at
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
3019 F5FC AA33 5BC7 BE9F 09D2 393E DBD2 40D5 FA7E

More information about the Gnupg-devel mailing list