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
* 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 --
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 w
* 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
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
Hi
I am working on a software package alike to Debian's debian-archive-keyring.
Within that, public keys are stored in a jetring-compatible format. At build
time, these keys are essentially read/imported and concatenated in a
non-kbx-keyring.
Maintainers, for sanity, are supposed to build the ke
