assuan interface for gpgme

[Werner Koch]

On Wed, 18 Feb 2009 18:54, marcus.brinkmann at ruhr-uni-bochum.de said:

> It doesn't matter if the interface is similar to the assuan interface, as long
> as it is the correct interface from GPGME's point of view.

>From a pragmatic point of view a similar interface makes life easier.
You can just take the code from GnuPG and use it in a GUI application.
OTOH, we try to get hackers to use GPGME and thus this advantage is more
one for me than for a wide group of developers.

> Yes, it complicates the data flow.  Unfortunately, the simple data flow
> doesn't work reliably for asynchronous operation.  We can not allow sending

I have not really considered asynchronous operations.  So better get the
API right instead of fixing it later.

> However, here is another idea:  The user could return a gpgme_data_t object to
> the inquire call, and GPGME could handle the flow control transparently.  This
> is flexible, and relatively easy for the application.  For simple inquiries,
> this is more overhead, but for bulk data it is simpler.  Of course, we could

Okay, let me give it a shot.

> Just from the top of my head, we may want to provide a log of the transaction,
> some statistics, debug information (audit log), or the server's welcome
> message with a version info.

I don't see that....

> In any case, consistency alone is reason enough to not use a different
> semantics for the _result function.

... but I agree that this is a valid point.

> A specific end function is more reliable, as it can do consistency checks.  It
> can also try to terminate the server connection nicely.  This does not
> preclude adding a reset function, but specifying that is more work.

We need a reset function anyway and if there will ever arise a problem
from not having an end connection function we can add one later without
too much trouble.

> I don't understand why you think that this is not part of the API.  It most
> definitely is.  OPTION is a regular command and PINENTRY_LAUNCHED is a regular

Right, OPTION is one but not the specific options we use with gpg-agent.
Given that GPGME has the goal to make access to GnuPG easier it really
should do so and not require the user to code extra boilerblate stuff
all the time or even think about how to do it.  Accessing gpg-agent will
be the major service requested, things are easier if the default is to
make it really easy.

> Let's separate the issues. The OPTIONs can be put into the init function I
> prototyped above.  The pinentry_launched is actually not particular to
> gpg-agent, it could be passed through several other applications (and in fact
> it is!).  In fact, it is not even clear that the current process is the right
> one to allow the set foreground call.  It may need to be forwarded.  In fact,

It is correct for almost all applications but I agree that there may
eventually be services which need access to this inquiry.

> Thus, I think automatic or external (ie application-level) handling of
> PINENTRY_LAUNCHED  should be a special flag for the gpgme context, shared by
> assuan and gpgsm operations.  The interface should be a configurable

Agreed, the default should be a handle it assuming that the application
is the actual foreground GUI task.

> only pass fixed strings).  Also, parsing strings in C is not very good (source
> for bugs, no type safety, no compile time checks, ...)

We parse strings all the time.  For now there is just one option and the
parser is primitive.  If we eventually add more options, I promise to
write a regression test for the parser.

> I feel pretty strongly about interface consistency.  I do not feel too
> strongly about asynchronous operation at this moment, but I think that we
> should prepare the interfaces for it to be possible.

Okay, let me hack on it and we see where we are going.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.