Generating bitwise identical keyrings with GnuPG 1 + 2

[Werner Koch]

On Mon, 16 Sep 2019 15:41, ionic at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190916/08303da7/attachment.sig>