Generating bitwise identical keyrings with GnuPG 1 + 2

[Mihai Moldovan]

* On 9/15/19 3:56 PM, Werner Koch wrote:
> The trust packets are for internal use of gpg and are never exported.

But... that's the whole point. gpg 1.4 seems to export them, while gpg 2.x does not.


> These packets are one of the reasons why we stated for decades that the 
> interface is "gpg --export" and that the files in ~/.gnupg are internal to
> gnupg.

I understand that this might be considered implementation defined, but getting
unreproducible output for a specific operation is a bit weird. I don't know if
the format GnuPG generates with the --export command is considered stable, though.


> The RFC also states that the format of this packet is _implementation
> defined_ and SHOULD NOT be emitted to output streams or should be ignored on 
> import.

So it looks like GnuPG 1.x didn't adhere to this recommendation, while GnuPG 2.x
does.


> If you use "--export-options backup" these trust packets are exported anyway
> so that they can be imported with "--import-otions restore".

That might be a valid workaround for gpg >= 2.1.18 to make it spit out trust
packets.

I basically need to find a way to
 - either make gpg 1.4 NOT output trust packets
 - or make gpg 2.x generate them.

Initially, I thought about using --export-options export-minimal, because it's
supported by even ancient 1.4 versions and could have been the better solution
here, given that a package archive keyring doesn't need to ship additional
signatures (other than the most recent selfsigs). This said, I tried that option
and it does not seem to force gpg 1.4 to drop trust packets, so that's sadly not
a viable option. Haven't any other option that would stop gpg 1.4 from
generating them either.


Using --export-options backup, which seems to be supported by at least gpg
2.1.18+, made gpg 2.2 write out trust packets alright, but... more than gpg 1.4
generates. :(


1.4 seems to generate trust packets *only* after signatures, while 2.2, when
used with the --export-options backup option, generates trust packets after key,
user and signature packets.

Excerpt:

--- keyringdump.gpg1    2019-09-16 11:58:56.506758876 +0200
+++ keyringdump.gpg2    2019-09-16 12:02:14.967564877 +0200
@@ -4,9 +4,13 @@
        pkey[0]: [2048 bits]
        pkey[1]: [17 bits]
        keyid: E1F958385BFE2B6E
-# off=272 ctb=b4 tag=13 hlen=2 plen=46
+# off=272 ctb=b0 tag=12 hlen=2 plen=12
+:trust packet: key upd=0 src=0
+# off=286 ctb=b4 tag=13 hlen=2 plen=46
 :user ID packet: "X2go Debian/Ubuntu Packaging <debian at x2go.org>"
-# off=320 ctb=89 tag=2 hlen=3 plen=312
+# off=334 ctb=b0 tag=12 hlen=2 plen=12
+:trust packet: uid upd=0 src=0
+# off=348 ctb=89 tag=2 hlen=3 plen=312
 :signature packet: algo 1, keyid E1F958385BFE2B6E
        version 4, created 1299793310, md5len 0, sigclass 0x13
        digest algo 2, begin of digest a8 73
@@ -19,15 +23,15 @@
        hashed subpkt 23 len 1 (keyserver preferences: 80)
        subpkt 16 len 8 (issuer key ID E1F958385BFE2B6E)
        data: [2046 bits]
-# off=635 ctb=b0 tag=12 hlen=2 plen=2
+# off=663 ctb=b0 tag=12 hlen=2 plen=6
 :trust packet: sig flag=00 sigcache=03
-# off=639 ctb=b9 tag=14 hlen=3 plen=269
+# off=671 ctb=b9 tag=14 hlen=3 plen=269
 :public sub key packet:
        version 4, algo 1, created 1299793310, expires 0
        pkey[0]: [2048 bits]
        pkey[1]: [17 bits]
        keyid: 71F21F68F489CDCF
-# off=911 ctb=89 tag=2 hlen=3 plen=287
+# off=943 ctb=89 tag=2 hlen=3 plen=287
 :signature packet: algo 1, keyid E1F958385BFE2B6E
        version 4, created 1299793310, md5len 0, sigclass 0x18
        digest algo 2, begin of digest 77 f5


Looks like I'm stuck.

The source code is also enlightening - build_packet_and_meta (which is used with
backup) creates trust packets for KEY, SIG, and USER packets, while keyring.c in
1.4 ignores/skips over any trust packets but those coming right after a SIG packet.



Mihai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190916/def2c2d5/attachment-0001.sig>