GPGME and Weird Keys
Robert J. Hansen
rjhansen at inav.net
Sun Mar 17 08:28:02 CET 2002
I've got a strange bug which is most likely either a bug in GPGME, or
else a bizarre key that GPG is able to show just fine, but GPGME can't.
(Of course, my own code is utterly bug-free and has never known the
slightest defect or fault... :) )
I've been tearing my head out over this one for days now; there are two
keys which will sometimes render correctly, but which more often than
not will render incorrectly. I can query everything about these keys
except for their names, which strikes me as really strange--for every
given key at index 0 there ought to be a valid name/email/etc. So
finally in despair, I used gpg_key_get_as_xml(foo) to dump out key data
of each key as I was querying it.
A GpgmeKey with queryable names, after having been run through
gpgme_key_get_as_xml():
<GnupgKeyblock>
<mainkey>
<keyid>3D8AF1B209AC0A6A</keyid>
<fpr>7A1A407FB1CA7E4EAE85E7303D8AF1B209AC0A6A</fpr>
<algo>17</algo>
<len>1024</len>
<created>900443902</created>
</mainkey>
<userid>
<revoked/>
<raw>L. Sassaman <rabbi at NO.SPAM.quickie.net></raw>
<name>L. Sassaman</name>
<email>rabbi at NO.SPAM.quickie.net</email>
</userid>
<< given this is Len's key, many many more userids deleted... >>
<subkey>
<keyid>D9CE865681451634</keyid>
<algo>16</algo>
<len>2048</len>
<created>900443903</created>
</subkey>
</GnupgKeyblock>
... and a keyblock which apparently only has queryable keyID,
fingerprint, algorithm, length and creation date, after being run
through gpgme_key_get_as_xml():
<GnupgKeyblock>
<mainkey>
<keyid>1E419D60B21D6AA7</keyid>
<fpr>32002537B225D1613F1008B0C3F666DE</fpr>
<algo>0</algo>
<len>2048</len>
<created>924419219</created>
</mainkey>
</GnupgKeyblock>
... Now, when I do "gpg --list-key B21D6AA7", I get:
pub 2048R/B21D6AA7 1999-04-18 Ted Parvu <NO.SPAM.tparvu at nai.com>
uid Ted Parvu <NO.SPAM.tjp at infinet-is.com>
uid Ted Parvu <NO.SPAM.tedp at pgp.com>
(All email addresses are spamblocked. The spamblocking isn't in the
native data, o'course.)
... So apparently there's some information stuck in the key data which
GPGME simply isn't getting, isn't reading, isn't--well, something isn't
getting processed/handled appropriately.
Is this a known bug? Are there any workarounds?
More information about the Gnupg-devel
mailing list