Mailing List Archive

No key data exported by gpgme_op_export_keys()
Hello,

could someone please explain why an attached test program (loosely based on gpgme tests)
is able to echo back my test key but refuses to zero output bytes for Fedora 33 primary one?

$ gcc -Wall -O2 $(pkg-config --cflags gpgme) -g t-gpgme-import.c -o t-gpgme-import $(pkg-config --libs gpgme)
$ ./t-gpgme-import RPM-GPG-KEY-test
1 key(s) found
read 4443 bytes of key(s) data:
-----BEGIN PGP PUBLIC KEY BLOCK-----
...actual data follows...
-----END PGP PUBLIC KEY BLOCK-----
$ ./t-gpgme-import RPM-GPG-KEY-fedora-33-primary
1 key(s) found
read 0 bytes of key(s) data:
???

Observed on gnupg2-2.2.27 + gpgme-1.15.1, if that matters.

Thanks,
Dmitry
Re: No key data exported by gpgme_op_export_keys() [ In reply to ]
On Donnerstag, 15. April 2021 16:30:12 CEST Dmitry Antipov via Gnupg-devel
wrote:
> Hello,
>
> could someone please explain why an attached test program (loosely based on
> gpgme tests) is able to echo back my test key but refuses to zero output
> bytes for Fedora 33 primary one?

I'm getting
1 key(s) found
read 0 bytes of key(s) data:
for both files. Are both keys in your actual public key ring?

My guess is that the export needs the actual key data and that's not part of
the result of the key list. The result of the key list only tells
gpgme_op_export_keys() which keys you want to export. gpgme_op_export_keys()
then calls gpg to retrieve the actual public key data. Obviously, this only
works for keys that are in your public key ring.

Try running your program with
GPGME_DEBUG=<debug level>
with one of the debug levels in src/debug.h

Regards,
Ingo
Re: No key data exported by gpgme_op_export_keys() [ In reply to ]
On 4/15/21 7:59 PM, Ingo Kl?cker wrote:

> Are both keys in your actual public key ring?

$ gpg --list-packets < RPM-GPG-KEY-test
# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
version 4, algo 1, created 1616661966, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
keyid: 1D66A1789477C523
# off=528 ctb=b4 tag=13 hlen=2 plen=38
:user ID packet: "CloudLinux, Inc. <info@cloudlinux.com>"
# off=568 ctb=89 tag=2 hlen=3 plen=596
:signature packet: algo 1, keyid 1D66A1789477C523
version 4, created 1616661966, md5len 0, sigclass 0x13
digest algo 8, begin of digest b6 63
hashed subpkt 33 len 21 (issuer fpr v4 10DFA0450487D8E6631738D41D66A1789477C523)
hashed subpkt 2 len 4 (sig created 2021-03-25)
hashed subpkt 27 len 1 (key flags: 01)
hashed subpkt 9 len 4 (key expires after 2y0d0h0m)
hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID 1D66A1789477C523)
data: [4095 bits]
# off=1167 ctb=b4 tag=13 hlen=2 plen=40
:user ID packet: "Dmitry Antipov <dantipov@cloudlinux.com>"
# off=1209 ctb=89 tag=2 hlen=3 plen=596
:signature packet: algo 1, keyid 1D66A1789477C523
version 4, created 1616662046, md5len 0, sigclass 0x13
digest algo 8, begin of digest b7 7b
hashed subpkt 33 len 21 (issuer fpr v4 10DFA0450487D8E6631738D41D66A1789477C523)
hashed subpkt 2 len 4 (sig created 2021-03-25)
hashed subpkt 27 len 1 (key flags: 01)
hashed subpkt 9 len 4 (key expires after 2y0d0h0m)
hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID 1D66A1789477C523)
data: [4096 bits]
# off=1808 ctb=b9 tag=14 hlen=3 plen=397
:public sub key packet:
version 4, algo 1, created 1616662014, expires 0
pkey[0]: [3072 bits]
pkey[1]: [17 bits]
keyid: AAD128E49907EA1B
# off=2208 ctb=89 tag=2 hlen=3 plen=1010
:signature packet: algo 1, keyid 1D66A1789477C523
version 4, created 1616662014, md5len 0, sigclass 0x18
digest algo 8, begin of digest 8c ca
hashed subpkt 33 len 21 (issuer fpr v4 10DFA0450487D8E6631738D41D66A1789477C523)
hashed subpkt 2 len 4 (sig created 2021-03-25)
hashed subpkt 27 len 1 (key flags: 02)
hashed subpkt 9 len 4 (key expires after 2y0d0h0m)
subpkt 16 len 8 (issuer key ID 1D66A1789477C523)
subpkt 32 len 435 (signature: v4, class 0x19, algo 1, digest algo 8)
data: [4095 bits]

$ ./t-gpgme-import RPM-GPG-KEY-test
1 key(s) found
read 4443 bytes of key(s) data:
-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBGBcTc4BEADF7NC6a5RPC0m6s6OXS4CEkkK6EKna7Vm9+dmSMWWuonZWQGH3
VG3Kd8GDymFHAAO8zBfm49XEt1qKi2tXghnsXKQVo4fj/vHCcGzzd3D62SFqkOr0
Q0DlNoNZGzht94ihmm095hegOLoQfyuFQ6wyn8ZK1Mg0dCgWwY5tq834FjMyeWJN
bweiQ+n/JvmOnM7ETO3p3vCXTPWdr/9i64CGbvnVDqhyl77TFj9GCPIvikKgePtq
Y0h9Rvh8F9jabzxE+vHNcLRQWjAqhs90gZK0ag78dXiPSt/lVmQ40GtScRqk8zgZ
csGfVqVOELUAVXbNOq1pBK36K5eNMrwHzPFNggIpxA2V2ccigfblghe7DnbqypxD
uXkf46lmAJBmPhBlH2O6dY61U6VGKA5RdULhrLvmAOfDhxLhXYHuAkcgbPSP0Udu
z3ECgaE+enaiJAPYIzEMBd4e4j8VxQzpXKrOLFt4wzO1mUJRuePpWyBO/DJPyia6
9WbeBLbJGCyHooyrSG8MxE6672ZSP9zbDEkDAO9Tx8V3mz3oJ32+6dl+ogxt0Bsy
umrLs7tlZZonlSBUkY9nuTlClTw7aCqkEbxFbBEBOsApkCOCVM5jT8gzouotCOcL
vtEyXwGKWf9zao2rbOpwG7JJwl0AC2AIw2yVvVgiXf4Bgh96NAogmrv41wARAQAB
tCZDbG91ZExpbnV4LCBJbmMuIDxpbmZvQGNsb3VkbGludXguY29tPokCVAQTAQgA
PhYhBBDfoEUEh9jmYxc41B1moXiUd8UjBQJgXE3OAhsBBQkDwmcABQsJCAcCBhUK
CQgLAgQWAgMBAh4BAheAAAoJEB1moXiUd8UjtmMP/26n9BaMLefvRsFYRIYIFQ6A
f8by+WNYgTZ3eAWq3jUuIAK5YzHUt6/ep8apYqAhAJa+lKsnGSnVCMyml4uByeN7
YtxzeJuTN6aUt2wc/y8zxj6TuQuisyO7CV7CroGd6wNX+8TARjHOL3ZfMDuBUege
v6cbPVLAj7G4sxj6gqG8NDWV9l+g9I+50D5v9eLd+cuM9QcdQSvckJAOBi37ITdK
1KDIWkiV45uSK9LoFWe6fcy6Y3FMw5IMxCpaYMcRr3ZUNCKvT+8Fltti/dRS8p9c
UKJdBQ36XffyoZ66HpOTOGBaAb91F6EnifrFsepY0SWsYiFnjUTQ1h082jPOBFB8
Yn4diPjB28BrOnWXcpdvfuOM5S5+06OCTn6rzvR3E0oyBn7ZAsdHqwTmHh8mPPxN
NGtmtScjOXhGfUDlHnEy5e2PbudFZKybTCnHMjKH3/OeZtDfZzPbxrPcidT2hvcj
ndTP5KoG6xuv44jK/a4SAFMQLb9bxCmqx8cAq34X2fB4+5Mf3AhSid6dbnw+4hdV
TJi2gpm33UJUhOWscKBJtUNW2lpivF0AO5Ov3QDCNjPEckbb7R+b/XcQB4PAqVk0
d9UQjbNAe6/KpWZc2VrNKRqv0zep75Uufd/NeZXCahuOcSyEuhVRVI6tFAE15fs3
qY5R5hL4uhtcTQ+fehNwtChEbWl0cnkgQW50aXBvdiA8ZGFudGlwb3ZAY2xvdWRs
aW51eC5jb20+iQJUBBMBCAA+FiEEEN+gRQSH2OZjFzjUHWaheJR3xSMFAmBcTh4C
GwEFCQPCZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQHWaheJR3xSO3exAA
iKfqKGyrIWLR9Nr7q1/Cxq2IuJJFtzJw+QZlBTSECQPPCzIHBjxaN8YaoUUn6odR
Hsr5tq5VYnLH78eSOzG72FFGbdUrXHA32ghSmMPlM7DIRZnB2tKb23UIQCn20U21
J7E2/YCSk3yxrJgGA55t6DXKLQ69K2c+2OYiJVv0CqNhVW9KhCAzwC/uHG7WqBiM
GTfnWJyziuxntDeuc0RYJE1pAeja0FwqsZdOT7YPPugrOyhOYqz/jum2oMePn3gz
U0bMFos+uP/3H6JDTBMtxyRgQOTu423dmQX9oDCkvMWXrdmB5VzZLtEMDotbjx4X
tQy38RBfvP7ngAlVcXXgW8kGVDQnTfhPLMWRMvczlCb6/esMJVih3ehAAo2XNfVK
QHAnEo5P8gtmX2R2d7C1I0TZhHeZZVhh9I/bm0PvpQmL/EMHpKv6Svn/2la6o1Pq
Yi3Ddeinba7EHzWJbSMOvZvfUBE+9eKR2G+t1xhu/NtiBFjc53ZXK6BKQ1tbRcAj
2p6xi3MksS6ZIy5qxQJwY3H4nVoSdAFSjM4as4NXtSwL8g88KNmhQg/6+8NQenYj
dtrFDNpmvjatP1YbAL62b7fT6hudzq+tQ9DBTMRJTj2fYVuR+JyMqWfEy8h6oWlF
dzsN8kj7e8x37tLLjjaRPHjui6ovNaW0Tu+bPjBwi0y5AY0EYFxN/gEMALT7wVFV
xbqa86e6puRATlVe2F7WfletD634s3jxS7QjW6ZY6pjVoU07lsBLMi0btdNwDijX
puql/9LjNYmRQtQZRC38V21jD/N8rETRkqVNeXv8g1z18G4FdVuU6wO1+oAYXU4y
waumo2WBwgTcPBl5hV10/LHDuqAqnRp2oOTNbXlCChLMiXiwVkjYbE5AjxqJxXSW
rpAmg33WPpxJSLX/eiVkdv4LVd9ywmetXaL2P6WaI/8Tac2aCyJ4YVqu1T7OoPoa
gLk0SDdnXMbKWydZ73sXoH+Axn7zh0CZURV1XvexQeML4zB4H3Lk6sX9uiV0u7B1
Bix+dovb/23zrvKHUah+yyaeZbM3850XOawf4D4QKE2pifwpzKCwbxlfmlUhoVhq
PiUwmQaDrAcqPsOy8KI5SzrtuTXRHKO3sGRk879g+oj2ua2XAg2l27DoJy18KiMM
l3PTQWer9uLFPPj4FUwEiVn9/4V9hx9pKcpm/7I8TpjlTOAfqU4rXsJIRwARAQAB
iQPyBBgBCAAmFiEEEN+gRQSH2OZjFzjUHWaheJR3xSMFAmBcTf4CGwIFCQPCZwAB
wAkQHWaheJR3xSPA9CAEGQEIAB0WIQRuOq6OcbjbnltBgjqq0SjkmQfqGwUCYFxN
/gAKCRCq0SjkmQfqG0l8C/9qZ0H2NlcQZwtUOr8bHe+dLiZEl61tS4laPVK3wK/S
TRHpwxGr0kf4tP3vbm4GL6LCFP8bIUdIany1Q6/q5ortD3BOsVISngduk8NWFF+A
2E9aG7OR8KV4YTzM2d/f/WFPdxbwcCddADjYJs+EPhqB2wDZ3LTMzAmjoi63DEuL
uRsUA1LlXwGFBJDEP4DTKVQXUIDuq2A8INIHcHmsi10KOpFDcxaqz5MOSZ27Aybf
PaHQ+GlRp/HBy07GfpLEsp7ZnyfY220IuMbRZ9Uv/pRqoHEwRzL4FkzaTGA8sb4o
5pM9OdcUKSu2Pv1AXg4XGyCT/+OQHcPh9W2OPmuQZwUskjElfCe34SgnrIYKg2dW
df+kkiA7GuyXkltwTn3QK8WlxmjfIdoKeVniOrn2sQPDq4u9R8/PsSqGcp5Adgm0
MbCT92ne80PEWyNlLg3jnJ2kEErfWefz+m21e8E1PIzh91/M9qA5kd35Y+ElUugk
FOyGtoqvNVwaJ2C8Zj7af1aMyg//QQU3dOZyeoKUMh4Ajkq+bq+57IOGaDJE76En
VY4NRnOP434Hej/Fv/1cZSJPUERmz8LvxK7uxw0OdxcObTCLmp6Tjtp5i275knB6
fp5ex1dcRVHte5UjIoOS6FA5zfjCoVjau/2wOiBXiKsIzgDzxzxGXuYiOtbUVTrz
pBkuQXE+BRIgC2bzARZ8hKU7uUEshHGHRYq6BZkhbaG54czKrFvVHym1kmxKohSy
d5l1+AtFUaWpokyojgIG1hsvr6Sf1/m5KeBunU9RmlkwPSD98vzD3QKkKHggbDQh
8ltqze6pEFDWJkdYtPKpbObJ3Gu0dxjIibJiWWdiJDCm6Bu8hDJnWVAfclhsaOFg
y00SbkFfnDbWqGiFFWVAL2LkWZBsuuXGOStntrxt9vOWoBes+iZdX/MPSMm8Oy7H
9IB4LIltvhtnyyzn8sFfqfLXaotXr0+YlxZ4PhxxsTi9apJ4N2r5t4/6fOE7dNNh
nY77Uh7PYMXWgLAHPi8JcGP0wxiv8SlLh/9etpfbhew3gtnw+8qxuRyK3IMWZx0s
YvJAsk3NBQZVi1hh/xOOTLt/ezVy5iefKD8E/N26fnmFnhXlnaydx5pKpgorsegH
kNaUOsFFtc8QZRsB5H00MTw1eRhwmCREdPjJBobPKLHWeoHQfCWgx7j0mq7EtOrP
Syc7ScA=
=g1MT
-----END PGP PUBLIC KEY BLOCK-----

$ gpg --list-packets < RPM-GPG-KEY-fedora-33-primary
# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
version 4, algo 1, created 1580205819, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
keyid: 49FD77499570FF31
# off=528 ctb=b4 tag=13 hlen=2 plen=49
:user ID packet: "Fedora (33) <fedora-33-primary@fedoraproject.org>"
# off=579 ctb=89 tag=2 hlen=3 plen=568
:signature packet: algo 1, keyid 49FD77499570FF31
version 4, created 1580205819, md5len 0, sigclass 0x13
digest algo 2, begin of digest 99 b6
hashed subpkt 2 len 4 (sig created 2020-01-28)
hashed subpkt 27 len 1 (key flags: 0F)
hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID 49FD77499570FF31)
data: [4095 bits]

$ ./t-gpgme-import RPM-GPG-KEY-fedora-33-primary
1 key(s) found
read 0 bytes of key(s) data:

> My guess is that the export needs the actual key data and that's not part of
> the result of the key list. The result of the key list only tells
> gpgme_op_export_keys() which keys you want to export.

If so, it seems that the API is just designed to shoot yourself in the foot.

> Try running your program with
> GPGME_DEBUG=<debug level>
> with one of the debug levels in src/debug.h

Thanks, will try it as well.

Dmitry



_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: No key data exported by gpgme_op_export_keys() [ In reply to ]
On Donnerstag, 15. April 2021 19:28:53 CEST Dmitry Antipov via Gnupg-devel
wrote:
> On 4/15/21 7:59 PM, Ingo Kl?cker wrote:
> > Are both keys in your actual public key ring?

You didn't answer my question. I bet
$ gpg -k 1D66A1789477C523
returns your key while
$ gpg -k 49FD77499570FF31
returns nothing because the Fedora key is not in your key ring.

> > My guess is that the export needs the actual key data and that's not part
> > of the result of the key list. The result of the key list only tells
> > gpgme_op_export_keys() which keys you want to export.
>
> If so, it seems that the API is just designed to shoot yourself in the foot.

It seems that you did not fully understand what
gpgme_op_keylist_from_data_start() (and friends) and gpgme_op_export_keys()
do.

If you check
https://www.gnupg.org/documentation/manuals/gpgme/Key-objects.html
then you will see that the gpgme_key_t structures returned by
gpgme_op_keylist_next() do not contain the actual public key data. Those
structures only contain information on the keys. In particular, they contain
their fingerprints which is then use by gpgme_op_export_keys() to know which
keys you want to export. The actual key data to export is then read from the
key ring.

I do agree that the documentation of gpgme_op_export_keys()
https://www.gnupg.org/documentation/manuals/gpgme/Exporting-Keys.html
is a bit misleading. I can see how "The keys to export are taken form the NULL
terminated array keys." can be misunderstood, but it says "The keys to export
[...]" and not "The key data to export [...]". It's like "The people to call
are taken from the list of contacts." A contact identifies a person (more or
less), but it certainly isn't the person.

Regards,
Ingo
Re: No key data exported by gpgme_op_export_keys() [ In reply to ]
On 4/15/21 10:50 PM, Ingo Kl?cker wrote:

> You didn't answer my question. I bet
> $ gpg -k 1D66A1789477C523
> returns your key while
> $ gpg -k 49FD77499570FF31
> returns nothing because the Fedora key is not in your key ring.

Yes.

> It seems that you did not fully understand what
> gpgme_op_keylist_from_data_start() (and friends) and gpgme_op_export_keys()
> do.

Absolutely. I've expected that

err = gpgme_data_new_from_file (&in, argv[1], 1);
fail_if_err (err);

err = gpgme_op_keylist_from_data_start (ctx, in, 0);
fail_if_err (err);

uses data from file (i.e. argv[1]) to create a kind of key ring in CTX.

I'm calling (something which looks like and pretends to be) a library
function and so expecting a behavior of a library function - do something
with arguments and return the result. But the whole thing here looks
like a call to strcmp() which sends an e-mail to Microsoft.

Dmitry


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel