gpgme as an GnuPG-API (API and windows support) (Was: begging for pyme name change)

Bernhard Reiter bernhard at
Wed Oct 19 08:31:21 CEST 2016


Am Dienstag 18 Oktober 2016 21:02:02 schrieb Vinay Sajip:
> many users expect to use Microsoft toolchains for Windows and not mingw or
> other free options.

I'd say that they expect that their toolchain is supported by the API.
Which is what gpgme on windows aims for (in my understanding).

It is of minor importance how gpgme itself is build. Because it is a cross 
plattform API, folks helping with its maintenance will need to learn about
cross plattform pecularities anyway.

> It's not technically impossible (AFAIK) to have libgpgme built using a
> Microsoft toolchain, is what I meant. 

In my experience, Werner's main concerns are long term maintainabiliy.
For the last ten years this mean that he personally will have to be able to
do the maintenance if nobody else wants to. As a single person his preferance 
of a development environment that gets things done thus have a strong
influence. If you could convince him that there is a long term maintainability
in supporting a different build environment and there is a legitimate use case 
for it, it may be possible. However that is difficult for the reasons 

> Of course, wrapping gpg.exe avoids these issues altogether.

But gets you other robustness and maintenance problems.
With gpgme you are getting a much more stable API for future changes.

> Another thing you said was that "not all features of gpg will be supported
> by GPGME". If that is the case, it seems to mean that wrapping over gpg.exe
> will be needed to get access to all features of GnuPG, or have I
> misunderstood?

My reading is: There is no promise for 100% coverage. 
Which actually is a good thing. It guards against: "Hey, I found one thing
I can do with gpg2.exe I cannot do with gpgme, this must be a bug!"
There are some deprecated, largely unused or debugging only features in
gpg2 that nobody really needs in an API. 
On the other hand: If there is are legitimate use case for a GnuPG-API,
it makes sense to extend gpgme. This has been done many times in the past
and will continue. Once we learn about what GnuPG-API users really need, 
there is a clear aim to support this with at least one good way.

Best Regards,

--   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20161019/42f0d2b6/attachment.sig>

More information about the Gnupg-devel mailing list