[Announce] GPGME 1.1.6 released

[Marcus Brinkmann]

At Thu, 10 Jan 2008 18:49:00 +0200,
"Alon Bar-Lev" <alon.barlev at gmail.com> wrote:
> > > For example, if you have webmail that holds gpg keys on behalf of its
> > > users... Current implementations enables users to specify passphrase
> > > using html dialog, and pipe the passphrase into the gpg application.
> > > Agent mode is not suitable for this kind of operation.
> >
> > That's a very specialized application domain which requires a ton of
> > further considerations, and a lot of effort to get it "right"
> > (arguably, your assumptions already restrict the feasible security
> > that can be achieved).  Under such circumstances, I don't think it is
> > unreasonable to require some extra effort in choosing an appropriate
> > pinentry solution.  The gpg2 framework allows for a number of
> > solutions here, but which one is best requires careful considerations
> > to the specific requirements.
> 
> This answer is political and not technical... There are working
> applications *NOW* and you are going to break them.

Consider applications using GPGME.  These applications will register a
passphrase callback handler, but with gpg2 it will simply not be used,
and for the application it looks like no passphrase is required to use
the key.

I suggest that if you know about specific applications that work with
gpg but break with gpg2, you let us know about the details and we work
something out in each particular case.  This invitation extends to all
software developers and distribution maintainers, of course.  We are
in fact very concerned about backward compatibility, which you can see
by our track record in maintaining the libgcrypt and GPGME API/ABI,
for example.

> But again... this is irrelevant now... from experience you guys will
> do whatever you like, forwarding the issue to distribution
> maintainers.

We want to work together with you and other distribution maintainers,
but we can not promise to never change anything, as that would
preclude useful and important improvements in the architecture.  If
you are concerned about particular problems, we are very interested in
hearing about them.

The issue at hand is, by the way, deeply technical: We want to move to
an architecture where secret key management is unified and properly
encapsulated.  That this makes sense can be seen from the important
use case of smart card readers with number pads, where the pin is
never even seen by the host computer.

This is not a new development.  For example, we have for years refused
to extend GPGME by secret key management interfaces (apart from the
generic edit interface as a work around), specifically because of the
architectural problems such interfaces would create.

Thanks,
Marcus