OpenPGP library?

[Dr. Evil]

I think gpgme still fork()s off a gnupg process.  This means it
wouldn't be usable in a high-performance application such as
OpenPGP-signing web pages, for instance.  We really do need an OpenPGP
library.  There is an obscure comment somewhere in the FAQ that using
OpenPGP as a library instead of as a separate binary would be
insecure, but this is factually incorrect, so I don't really
understand it.  It seems like it wouldn't be too enormous of a task to
make GPG into a library, and it would be a tremendous help for any
kind of automated task.
 
If you want performance and stability, you don't want to do a fork()
call with every request that comes in.
 
In my case, I want to be able to do something like this in my DB:

Generate a signed report:
 
SELECT openpgp_sign((SELECT ...), my_key);

Verify a datum before inserting it:

IF openpgp_checksig(string, userkey) THEN
   INSERT ...

The only way this is going to work well is with a library, not having
the database backend fork off a process all the time.  There's
absolutely no security reason to not have this capability.  What it
comes down to is there are two types of operating systems today:
non-Mandatory Access Control (which includes Linux, *BSD, and almost
everything else) and Mandatory Access Control (which includes the
NSA's SELinux, the Trusted BSD project, the EROS project, and some
specialized versions of Solaris, and a few others).

The bottom line is if a user on a non-MAC OS gets superuser access, he
wins, 100%, and whether you keep your super-seekrit stuff in binaries
or libraries or in RAM or on disk won't make a bit of difference.  The
corollary to this bottom line is that basically none of the non-MAC
OSes can absolutely prevent ordinary users from breaking root, so if
you are doing high-value secret stuff on a non-MAC OS, you MUST do it
machine which has only trusted users, and not on a general-use machine
with untrusted users.

If you want to do any kind of secure crypto on a machine with any
access from untrusted users, you need a MAC OS, but unfortunately,
there are not many easily accessible choices in that area right now.

Also in the GPG FAQ it says stuff like "absolutely never use GPG over
a network".  This is ridiculous.  There is absolutely no such thing as
a universally-applicable security policy.  Your software should
support whatever security policy you want to use, within its scope of
abilities.  Here's an example of a few different categories of users:

1. The President is handling nuclear launch keys.

2. Amazon.com is accepting credit cards and selling stuff.

3. Researchers at a university are studying the performance of an
   encrypted network using automated load generators (this is actually
   a common thing to do for testing various types of server
   performance).

Case 1: The security policy is going to be as extreme as you can get.
Nothing is ever done over a public network, no untrusted users
anywhere near it, they use one-time pads, tamper resistant devices,
etc.  A data leak could be the end of modern civilization.

Case 2: Security is tight, but there are multiple sysadmins who can
access the secure machines, and they do it over a network.  A data
leak would be expensive and embarassing for Amazon.

Case 3: There is no need for security; no meaningful or valuable data
are being protected.  A data leak would have no consequences.
Encryption is used only because it affects the performance of the
system which is being studied.

GPG should be designed to work in a range of policies, including
policies of no security, like Case 3, and polices like Case 2, where
there is high security, but things need to be automated.  Of course,
it's the wrong tool for Case 1, but that's a different matter.

Anyway, enough ranting.  Security is very poorly understood by most
people who deal with it, and the idea of the "unversal security
policy" is one of the biggest misconceptions.  Any kind of built-in
security policy is based on the idea that there should be some kind of
universal security policy that's applicable everywhere.  There isn't.
Security policy should be clearly and cleanly separated from the
software itself as much as possible.  That's not to say there
shouldn't be a reasonably secure default installation, but it should
all be configurable.