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
<http://g10code.com>.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.




More information about the Gnupg-devel mailing list