C/C++ API for GnuPG

Joseph Bruni jbruni@mac.com
Sat Apr 19 04:32:01 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm not a GPG-specific programmer, but I'd like to weigh in on this 
since I am a Unix programmer. Please indulge me if I'm off base here.

I like the idea of GPG running in its own protected, non-swapable 
address space with a strictly well-defined communication interface 
provided by the anonymous pipe of stdin and stdout, environment 
variables, and command-line arguments. If I were a library programmer, 
(especially a security library), I would want to make sure that nothing 
could accidentally step on the code that I've spent a lot of time 
making robust. A GPG co-process lives in its own protected address 
space which (if set up properly) cannot be paged because it is 
setuid-root on many systems. As an application programmer, I would not 
want some library creating weakness in my application either.

A linkable library, on the other hand, would be completely at the mercy 
of the library user (application programmer), just as the application 
is at the mercy of the library.

In Unix, just as userland applications are "quarantined" from (and by) 
the kernel in order to provide security and stability, and are only 
able to communicate with the kernel through well-defined and checked 
APIs, so would the application and GPG be protected from each other by 
acting as co-processes in a client-server model which provides a great 
deal of robustness.



On Thursday, April 17, 2003, at 11:53 AM, Tony_Mione@peoplesoft.com 
wrote:

> I have looked at Gpgme. I like it to some degree but I do not like the
> fact that it forks another process and calls gpg at the command line. 
> I am
> trying to avoid that type of interface. I would use libgcrypt for my
> project but it ONLY implements the crypto and I can really use the
> packet processing features of the source code in g10.
>
> So, what are the security holes that may be openned if this is made
> into a library? Do people involved with Gpg believe that the same
> holes [may] exist in the PGP SDK marketed by PGP, Inc. then NAI, and 
> soon
> PGP International?
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iEYEARECAAYFAj6gtX0ACgkQ4rg/mXNDwePCSQCfe7NWYakSuZzYx6reuJ2/CB++
4pkAoJggK6vorGt5JoPcX3nZ5v9LCcf/
=T5fU
-----END PGP SIGNATURE-----