Questions about GPGME / GnuPG library

[Olaf Trygve Berglihn]

Taral <taral at taral.net> writes:

> On  5 Dec, Werner Koch wrote:
> 
> >>  Personally, I'd like to have a gnupg library, not a wrapper
> >>  around it. Really I don't undestand why it can not be done. It
> > 
> > Not again :-(
> 
> This is becoming a FAQ. For those who haven't looked at the archives,
> this has been rehashed so many times as to be tiresome. GPG _cannot_ be
> made a library because libraries do not provide sufficient security
> guarantees. GPG very closely constrains its environment in order to
> prevent any leakage of private key data, and it cannot do this as a
> library. There are plans to produce a coprocess/service-type mode in GPG
> which will enable programs to do what they need to do via an RPC-type
> mechanism.
> 
> PLEASE don't ask for GPG to be a library. It's not going to happen.

Yes, again! :-D

As a professional programmer, I must really have missed out on
something here. I would think that the cleanest way to (re)implement
gnupg would be to have core functionality accessed by some
(g)ui-frontend. If you are afraid of dynamically linked libraries, so
link your application statically then.

I consider it a more serious threat that gnupg should be setuid
root. This is the last thing i want. The next to last is a separate
gnupg-daemon with a rpc-interface. Have you at all considered the
vulnerabilities i rpc-calls?

Root is root is root is root, i.e. if you can exploit to become root,
then you could swap the gnupg-binary, the shell-binary or
whatever.

Sure, protected memory would be fine, but root is root is ...

Bottom line is that I think the current gnupg-developers are taking
great care, or at least are venting opinions that go in the direction
as to protect programmers from themselves. That provokes me a little.

Olaf
-- 
Olaf Trygve Berglihn <olafb at pvv.org>