assuan_read_from_server() and return value

Ben Kibbey 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 mailing list