No GnuPG library for now (was: Feature Suggestion)

[Russ Allbery]

Werner Koch <wk@gnupg.org> writes:
  
>   * Shared libraries might be better but in the end it is still one
>     program with not so well defined interfaces.  Building programs
>     based on shared libraries is causing a lot of headache - ever
>     tried to build Mozilla or Evolution?
  
>   * Unix was successul because of KISS (Keep it simple and small).
>     All the small, quite well tested modules/programs/components do
>     work (more or less) nicely together and we can develop and
>     maintain small modules and modules which utilize other modules.
>     It is far from perfect but a rock solid foundation for many
>     tasks.

I'm not sure I'm completely following what you're saying, but there are
some real problems with the separate program approach in practice.  A fork
consumes a lot of resources and can be difficult to manage well.

My experience in this area is with writing news servers, which currently
often use PGP to authenticate newsgroup control messages (create, remove,
etc.) by checking their signatures.  We've found from hard experience that
forking off a control message handler for each incoming control message
makes the system extremely vulnerable to denial of service attacks.

INN, to take a concrete example, is a long-running server that tends to
allocate 50MB or more of memory for various memory caches, temporary
article storage, and the like, and in addition memory maps often upwards
of 500MB of databases.  Forking an external handler on some systems means
reserving hundreds of MB of swap (which thankfully due to copy on write
aren't actually used, but the reservation process itself can be
expensive) and closing hundreds of open file descriptors that are marked
close on exec (and also invalidating all those memory maps, although one
would hope that was reasonably efficient).  One also has to then manage
the forked process, reap it properly, and limit how frequently one is
willing to fork processes in order to keep from forking the system to
death.

For newsgroup control messages, you can deal with this by having INN fork,
when it starts, a separate handler process that just deals with newsgroup
control messages and forks the verification program and so forth.  This
handler process is nice and small and can churn through requests handling
them one at a time.  But that only works for things like newsgroup control
messages which INN accepts, hands off, and forgets about.

We'd like to expand the authentication features of Usenet to cover
moderated newsgroups as well, but trying to do this by forking an external
process for every post to a moderated newsgroup is going to basically be a
non-starter and this can't be handled using the method described above.
INN has to get back an accept or reject decision from the validator; it
can't just dispatch the message off to some handler and then forget about
it.  It's possible that GnuPG is the wrong tool to even look at for doing
this and we should be using OpenSSL and a certificate system instead, but
I'd hate to disqualify GnuPG for non-crypto-based reasons.  Some way of
verifying signatures via a library interface that does not involve a fork
would be *very* nice.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>