Problem with C++ wrapper and gpgme
dshaw at jabberwocky.com
Sat May 31 18:32:02 CEST 2003
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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
$ time gpg --with-colons --list-keys > /dev/null
388 keys on that keyring. Where is the problem?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-cvs (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Gnupg-devel