Bernd's comments on GPGME

[Werner Koch]

On Mon, 21 Jul 2003 19:14:01 +0200, Bernd Eckenfels said:

> great manpower in werners company and even the community here in the lists
> have not convinced me, that GPG could have repeated the success of 2.6 PGP.

I don't see a success of PGP 2 anywhere else except in the cyberpunks
community and its neighborhood.  Same thing for OpenPGP of course.

However, we now have a standard and multible implementations of
OpenPGP so there must be some value in the products.  I know a couple
of very large companies, using OpenPGP to protect their internal
communications.  Ever asked yourself why Glueck&Kanja developed their
own OpenPGP implementation (CryptoEx) or why GnuPG is working under
the hood of a lot of other products (e.g. by Utimaco or GENUA)?  At
least in the Unix world OpenPGP is heavily used for not always visible
purposes.

> This may be due to the complicated OpenPGP, this may be due to some
> license

OpenPGP isn't complicated.  We have the luck that it is based on a
working implementation and not a protocol thrown together from
different vendors implementions to create a commitee standard. 

BTW, PGP 2 has a couple of design flaws and no specification allowing
to write compatible applications.  Watch out for all the kludges in
GnuPG to make it compatible with the different version of PGP 2-7.

> And with Crypto libs like bouncy castle or cryptix, at least in Java there
> is no need for such a command line wrapping.

You are taling about command line wrapping.  It seems that you did not
understand the goal of GPGME: That command line wrapping (as you call
it; despite that this is a basic Unix feature) is something internal
to GPGME; an application don't need to care about it.  We can at any
time switch to an alternative IPC method and we actually did this
already for gpgsm - the GPGME aware application does not known about
it but gains improvements when we change to a more perfomant way of
internal communication.  Hard linking of libraries is not walys a
sound descision.  Small and independently testable modules do have
their advantages.  Nevertheless, the fork/exec approach does not
create a performance penalty for the majority of applications.


Salam-Shalom,

   Werner

-- 
Werner Koch                                      <wk at gnupg.org>
The GnuPG Experts                                http://g10code.com
Free Software Foundation Europe	                 http://fsfeurope.org