Looking for GnuPG-compatible library for server application

Werner Koch wk at gnupg.org
Mon Oct 22 16:50:03 CEST 2012

On Sat, 20 Oct 2012 13:35, bernd at wauland.de said:

> Am I correct that each server thread requires its own GPGME/GnuPG
> instance? If that is the case, it would be nice if instances can be
> pooled as threads come and go frequently.

As of now each gpgme_ctx_t context object uses its own instance of an
engine (e.g. a gpg process).  Thus you can setup your own CPU mapping by
using one context per CPU.  There is however only one gpg-agent running;
if you handle only short messages, gpg-agent will be bottleneck, because
it is not multi-threaded but serializes all requests from all running
gpg processes.  It should be possible to change the system so that it
works with several gpg-agents and may this way distribute the workload
onto several CPUs.

Pooling at the gpgme level can be done by the application.  Due to the 1-to-1
relation between a context object and an engine, the caller may put a
context object into a pool (instead of releasing it) and later pick it
up from another thread.

> environment where there are some 20'000 *private* keys (and counting).
> From our experience gpg2 does not scale well with increasing number of
> private keys (although I have to admit that the project uses a very

That depends a bit on how you use it.  If you do a key listing for each
operation, this might be a problem: Neither gpg, nor gpg-agent cache the
check for the private key file.  20000 private keys are not a very
common usage pattern.

Given that the private key check is is nothing more than an access(3)
with some IPC glue code; I doubt that the number of private keys is
actually the problem.  The actual problem is the access to public key,
which still requires a linear search and parsing of the entire keyring.
We can do much faster here but the code is not yet complete (no real
need).  Eventually we may add a DB backend to access the keys; the code
is well layered and can thus easily extended.

> I appriciate your offer to help. I will describe the problem, financial
> issues and timetables in a private email. I have to travel a lot the
> next five days (including meetings), so I am not sure if I can send that
> email before the next weekend. Hope you don't mind.

No problem.  You may also phone me during office hours



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-devel mailing list