Re: Generating bitwise identical keyrings with GnuPG 1 + 2
On Mon, 16 Sep 2019 15:41, io...@ionic.de said: > * 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. I just checked the code and I can't see how they get exported. In the loop over the packets you find: /* Make sure that ring_trust packets never get exported. */ if (node->pkt->pkttype == PKT_RING_TRUST) continue; which should skip them while exporting. Can you please provide a test keyring and tell us the exact gpg 1.4 version you are using? > 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. Yes it is the interchange format as specified by RFC-4880. > I basically need to find a way to > - either make gpg 1.4 NOT output trust packets The solution is simple; Do not use gpg 1.4 except for decrypting legacy data which either does not use MDC or is encrypted with a v3 key. There is no other use case for gpg 1.4. > 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, They are implementation defined and thus do not go into the key interchange format (transferable public/secret key). The backup/restore options are an exception for, well, backup and restore of *GnuPG*'s internal key data storage. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Generating bitwise identical keyrings with GnuPG 1 + 2
* 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.gpg12019-09-16 11:58:56.506758876 +0200 +++ keyringdump.gpg22019-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 " -# 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 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Generating bitwise identical keyrings with GnuPG 1 + 2
On Fri, 13 Sep 2019 21:28, io...@ionic.de said: > Either way, my best guess is that GPG 2.2+ drops the trust packets > because the trust is not explicitly set (i.e., default value) - as an The trust packets are for internal use of gpg and are never exported. 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. gnupg/doc/DETAILS tells this about the trust packets: * Format of the OpenPGP TRUST packet According to RFC4880 (5.10), the trust packet (aka ring trust) is only used within keyrings and contains data that records the user's specifications of which key holds trusted introducers. 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. GnuPG uses this packet in several additional ways: - 1 octet :: Trust-Value (only used by Subtype SIG) - 1 octet :: Signature-Cache (only used by Subtype SIG; value must be less than 128) - 3 octets :: Fixed value: "gpg" - 1 octet :: Subtype - 0 :: Signature cache (SIG) - 1 :: Key source on the primary key (KEY) - 2 :: Key source on a user id (UID) - 1 octet :: Key Source; i.e. the origin of the key: - 0 :: Unknown source. - 1 :: Public keyserver. - 2 :: Preferred keyserver. - 3 :: OpenPGP DANE. - 4 :: Web Key Directory. - 5 :: Import from a trusted URL. - 6 :: Import from a trusted file. - 7 :: Self generated. - 4 octets :: Time of last update. This is a a four-octet scalar with the seconds since Epoch. - 1 octet :: Scalar with the length of the following field. - N octets :: String with the URL of the source. This may be a zero-length string. If the packets contains only two octets a Subtype of 0 is assumed; this is the only format recognized by GnuPG versions < 2.1.18. Trust-Value and Signature-Cache must be zero for all subtypes other than SIG. If you use "--export-options backup" these trust packets are exported anyway so that they can be imported with "--import-otions restore". Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Generating bitwise identical keyrings with GnuPG 1 + 2
* On 9/6/19 12:33 AM, Ángel wrote: I'm baffled by this. Could you run gpg2 --list-packets on both keyrings and compare their outputs? That should hint which packets are being included by 1.4 that are not by 2.2 Hmm, interesting indeed. The output is *almost* the same. A diff looks like that (truncated, but you'll get the general idea): --- keyringdump.gpg22019-09-13 20:50:26.839951269 +0200 +++ keyringdump.gpg12019-09-13 20:50:44.186005825 +0200 @@ -19,13 +19,15 @@ hashed subpkt 23 len 1 (keyserver preferences: 80) subpkt 16 len 8 (issuer key ID E1F958385BFE2B6E) data: [2046 bits] -# off=635 ctb=b9 tag=14 hlen=3 plen=269 +# off=635 ctb=b0 tag=12 hlen=2 plen=2 +:trust packet: sig flag=00 sigcache=03 +# off=639 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=907 ctb=89 tag=2 hlen=3 plen=287 +# off=911 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 @@ -33,7 +35,9 @@ hashed subpkt 27 len 1 (key flags: 0C) subpkt 16 len 8 (issuer key ID E1F958385BFE2B6E) data: [2044 bits] -# off=1197 ctb=99 tag=6 hlen=3 plen=418 +# off=1201 ctb=b0 tag=12 hlen=2 plen=2 +:trust packet: sig flag=00 sigcache=03 +# off=1205 ctb=99 tag=6 hlen=3 plen=418 :public key packet: version 4, algo 17, created 1234173545, expires 0 pkey[0]: [1024 bits] It looks like the gpg1 output has additional "trust" packets. Are that owner trust values? I wonder why gpg2 doesn't generate these packets? According to RFC 4880 these are really owner trust values that SHOULD NOT be exported to files that are supposed to be handed to other users, but GPG can't determine whether such a keyring file will be used locally or not. Either way, my best guess is that GPG 2.2+ drops the trust packets because the trust is not explicitly set (i.e., default value) - as an optimization. Can I instruct gpg2 to not do that? --export-ownertrust doesn't seem appropriate and then there's also the special concept of a trustdb, so I don't quite understand why trust packets would be exported to keyrings in the first place? Mihai ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Generating bitwise identical keyrings with GnuPG 1 + 2
On 2019-08-18 at 08:24 +0200, Mihai Moldovan wrote: > So, to summarize, if I process a keyring file generated by gpg 2.2 > with a 1.4 binary, i.e., read-in the former, export all keys and > import it again, gpg 1.4 generates exactly the same file as it would > when importing the keys directly. I'm baffled by this. Could you run gpg2 --list-packets on both keyrings and compare their outputs? That should hint which packets are being included by 1.4 that are not by 2.2 Best regards ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
