Problem with C++ wrapper and gpgme

David Shaw dshaw at
Sat May 31 18:32:02 CEST 2003

Hash: SHA1

On Sat, May 31, 2003 at 04:39:36PM +0400, Yenot wrote:
> On Friday 30 May 2003 07:58 pm, David Shaw wrote:
> >
> > Note there is a gotcha here.  When parsing raw key data, there is
> > no assurance that some items are valid or not without actually
> > verifying the self-signatures.  To really use raw data in a key
> > manager, you'd need to add signature verification and trustdb
> > calculations, and pretty soon you've recreated GnuPG. ;)
> Wouldn't the verification that GnuPG does when adding keys to the 
> keyring be sufficient for key-display by a keymanager?

It is sufficient so long as the keymanager does not display trust and
validity for the keys.  When importing a key, GnuPG verifies its
self-signatures - that's all.  That is sufficient to know (for
example) that the user IDs are at least internally consistent.
However, OpenPGP does not require this so GnuPG can turn even that
minimal check off with --allow-non-selfsigned-uid.

More importantly, it does not rebuild the trust database and integrate
the new key into it.

> Displaying not yet imported keys is also the job of a keymanager.  How 
> to hand off this key verification task to GnuPG without importing the 
> key is not simple, but I think possible.

Displaying keys is pretty easy:

  gpg --with-colons the_key.gpg

It is harder if you want to verify the signatures before importing the
key, but I'm not sure how useful that is, or what the point would be.

  gpg --no-default-keyring --keyring ./temp-keyring.gpg --import the_key.gpg
  gpg --no-default-keyring --keyring ./temp-keyring.gpg --with-colons --list-keys 
  rm ./temp-keyring.gpg

> If GnuPG could export its own trust calculations as a trust packet (a 
> special feature only for axillary programs), keymanagers would not 
> have to do their own trust calculations.  Would it be possible for 
> GnuPG to add such information to its raw --export output without 
> slowing down the export process?

Not easily.  One of the reasons --export is so fast is that it doesn't
hit the trustdb at all.  If GnuPG had to do a validity lookup for each
key, it would slow things down a lot.  At that point, you're pretty
much at the same speed as --with-colons so haven't gained anything.

It is theoretically possible to build the trustdb directly into the
keyring, but now we're talking about a serious rewrite of a lot of

> Using raw OpenPGP as the GUI<->GnuPG data exchange format isn't ideal, 
> but it may be the only practical solution for a fast and 
> full-featured GUI keymanager.

What, exactly, is the real problem here that would prompt such major
changes?  The speed of --list-keys --with-colons ?

$ time gpg --export > /dev/null

real    0m0.766s
user    0m0.690s
sys     0m0.080s

$ time gpg --with-colons --list-keys > /dev/null

real    0m0.974s
user    0m0.910s
sys     0m0.060s

388 keys on that keyring.  Where is the problem?

Version: GnuPG v1.2.3-cvs (GNU/Linux)


More information about the Gnupg-devel mailing list