The last 9 months of GnuPG development

Werner Koch wk at
Mon Sep 20 12:32:07 CEST 2010


I feel that I should give you a quick heads up on what's going on with
GnuPG development.  I have been quite silent the last months and only
those following the commit list may have noticed the changes.

In short Marcus and me ported GnuPG and related software to WindowsCE;
to be more exact to Windows Mobile 6.5, testing on a HTC Touch pro 2.
Obviously this is not something we would have done voluntary but someone
convinced us by shifting money to the g10 Code account.  As a side
effect of this port we were able to clean up the code, fixing a couple
of lingering bugs, introducing new bugs and also partly working on some
stuff we had in mind for a long time.

Let's have a look at the current NEWS list for the 2.1 development
version (SVN trunk):

 * The GPGSM --audit-log feature is now more complete.

This allows to better see what is going on with X.509 (S/MIME)
certificate chain verification, CRL checks and so on.

 * The G13 tool for disk encryption key management has been added.

This was already done last autumn.  G13 is the forthcoming tool for disk
encryption using OpenPGP key management.  For now we only support EncFS
but there are plans do do more.  The general goal is to allow random
access to encrypted data files managed with OpenPGP keys.

 * Support DNS lookups for SRV, PKA and CERT on W32.

This was somehow missing for quite some time.

 * New and changed passphrases are now created with an iteration count
   requiring about 100ms of CPU work.

Already backported to 2.0.

 * Support for Windows CE.

The stuff which took up most of the time.

 * If the agent's --use-standard-socket option is active, all tools
   try to start and daemonize the agent on the fly.  In the past this
   was only supported on W32; on non-W32 systems the new configure
   option --enable-standard-socket may now be used to use this feature
   by default.

I think that this is important.  I hope that it will make it easier to
install and use GnuPG-2.

 * Dirmngr is now a part of this package.  Dirmngr is now also
   expected to run as a system service and the configuration
   directories are changed to the GnuPG name space.

Dirmngr is used to retrieve and check CRLs and do OCSP checking on
behalf of GPGSM.  For historic reasons it was a separate package but has
now been merged into GnuPG-2, proper.

 * Given sufficient permissions Dirmngr is started automagically.

We can do that only on some platforms; i.e. on mobile devices.  Standard
systems should start it like every other system service.

 * GPG does not anymore use secring.gpg but delegates all secret key
   operations to gpg-agent.  The import command moves secret keys to
   the agent.

That is something which should have happened much earlier. It makes the
GPG code less complicate and thus eases maintenance. Note that in the
past the gpg-agent was used by gpg-agent only for passphrase caching;
now Gpg-Agent does all secret key operations (generate, sign, decrypt)
for GPGSM and for GPG.

This part is not finished; for example I am currently working on the
OpenPGP export command and I also need to make some changes for

 * The OpenPGP import command is now able to merge secret keys.

This is a direct consequence of the above item.  We get it more or less
for free.  A little drawback - but also something which has been asked
for - is that importing a secret key now requires the user to enter the
passphrase (because gpg-agent needs to re-protect it).

There are some more tasks required before a first 2.1 release:

 * Let Dirmngr replace the key server helpers.  This also prepares the
   infrastructure for queuing key retrieval (think of revocations).

 * Finish the GPG export command.

 * Decide whether GPG should auto-migrate secret keys to gpg-agent.

 * Implement a persistent passphrase cache.  That is to allow users of
   gpg-agent to store passphrases along with meta information under a
   master key.  The idea is that other applications can use this as a
   crypto key/value store.

 * Merge Andrey's ECC for OpenPGP code.

I would also like to implement the new key storage backend for public
keys but that might be too many changes at once.  Thus I plan to do a
first 2.1 release using the old pubring.gpg format.  2.1.x will be a
development series anyway.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gnupg-devel mailing list