From konstantin at linuxfoundation.org  Sun Sep  1 01:21:55 2024
From: konstantin at linuxfoundation.org (Konstantin Ryabitsev)
Date: Sat, 31 Aug 2024 19:21:55 -0400
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
Message-ID: <20240831-practical-gray-mackerel-ed137d@lemur>

On Sat, Aug 31, 2024 at 06:29:17PM GMT, T. S. wrote:

The same thought did occur to me, which is why the patch attestation process
used by many in the kernel development community uses DKIM-like signatures:

https://github.com/mricon/patatt

However, this is limited to signing -- I don't believe this mechanism can be
extended to message encryption.

-K


From mm at dorfdsl.de  Sun Sep  1 06:47:25 2024
From: mm at dorfdsl.de (Marco Moock)
Date: Sun, 1 Sep 2024 06:47:25 +0200
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
Message-ID: <20240901064725.4659b93c@zbook>

Am Sat, 31 Aug 2024 18:29:17 +0200
schrieb "T. S." <tfasnetamot at emailn.eu>:

> Is somethings similar available for GPG/PGP?

I don't know about such an implementation, but if you want to create
one, everybody can publish RFCs at IETF, so feel free to create such a
technology.

If you want something unofficial, use the X- headers.


From stuartl at longlandclan.id.au  Sun Sep  1 06:46:58 2024
From: stuartl at longlandclan.id.au (Stuart Longland)
Date: Sun, 1 Sep 2024 14:46:58 +1000
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
Message-ID: <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au>

On 1/9/24 02:29, T. S. wrote:
> after looking into DKIM details, I started searching, why the same procedure
> cannot be used for gpg?

DKIM signs emails that are sent server-to-server.  It does not perform 
encryption of the email (that is done by the sending server sending the 
`STARTTLS` SMTP command and the pair negotiating a cipher).

Crucially, DKIM does not:

1. end-to-end digitally sign the email, the email is not signed until it 
is transmitted by your mail server, malicious code (or users) on the 
server can still manipulate it before sending.

2. perform any encryption, DKIM is about verifying sender *identity* 
(the I).  "Sender" being the server, not you the user.  Emails may be 
passed between servers via TLS, but the messages themselves will be 
stored clear-text at each hop.

For end-to-end encryption/signing, you need to apply this before your 
outgoing SMTP server receives it? that's where S/MIME and OpenPGP come in.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.



From mm at dorfdsl.de  Sun Sep  1 07:42:25 2024
From: mm at dorfdsl.de (Marco Moock)
Date: Sun, 1 Sep 2024 07:42:25 +0200
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au>
Message-ID: <20240901074225.2cc2e28f@dorfdsl.de>

Am 01.09.2024 um 14:46:58 Uhr schrieb Stuart Longland via Gnupg-users:

> 1. end-to-end digitally sign the email, the email is not signed until
> it is transmitted by your mail server, malicious code (or users) on
> the server can still manipulate it before sending.

It would be possible to sign DKIM at the MUA, but this is not common.

With the selectors, each user could have its own selector and private
key.

-- 
kind regards
Marco


From stuartl at longlandclan.id.au  Sun Sep  1 07:51:57 2024
From: stuartl at longlandclan.id.au (Stuart Longland)
Date: Sun, 1 Sep 2024 15:51:57 +1000
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <20240901074225.2cc2e28f@dorfdsl.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au>
 <20240901074225.2cc2e28f@dorfdsl.de>
Message-ID: <41e19c78-20ad-47df-b607-fc63bf7b3718@longlandclan.id.au>

On 1/9/24 15:42, Marco Moock wrote:
> It would be possible to sign DKIM at the MUA, but this is not common.
> 
> With the selectors, each user could have its own selector and private
> key.

Given the public key is published in DNS records, could you imagine the 
hot mess that'd create for domains with lots of users?  Either lots of 
DNS records, or lots of users sharing the same private key.

Neither is a good look.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.



From mm at dorfdsl.de  Sun Sep  1 07:55:26 2024
From: mm at dorfdsl.de (Marco Moock)
Date: Sun, 1 Sep 2024 07:55:26 +0200
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <41e19c78-20ad-47df-b607-fc63bf7b3718@longlandclan.id.au>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au>
 <20240901074225.2cc2e28f@dorfdsl.de>
 <41e19c78-20ad-47df-b607-fc63bf7b3718@longlandclan.id.au>
Message-ID: <20240901075526.13a1add7@dorfdsl.de>

Am 01.09.2024 um 15:51:57 Uhr schrieb Stuart Longland:

> Given the public key is published in DNS records, could you imagine
> the hot mess that'd create for domains with lots of users?  Either
> lots of DNS records, or lots of users sharing the same private key.

Is there a limit for DNS records?
I don't see a problem here, especially if they are provisioned in an
automatic way.

-- 
Gru?
Marco


From stuartl at longlandclan.id.au  Sun Sep  1 08:17:59 2024
From: stuartl at longlandclan.id.au (Stuart Longland)
Date: Sun, 1 Sep 2024 16:17:59 +1000
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <20240901075526.13a1add7@dorfdsl.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <6df9205d-045c-411e-be2d-e6532fd6cf49@longlandclan.id.au>
 <20240901074225.2cc2e28f@dorfdsl.de>
 <41e19c78-20ad-47df-b607-fc63bf7b3718@longlandclan.id.au>
 <20240901075526.13a1add7@dorfdsl.de>
Message-ID: <1da1b417-04c7-4d5b-bd12-b90b730c3573@longlandclan.id.au>

[Re-send with correct from: address? apologies to the moderators for the 
noise]

On 1/9/24 15:55, Marco Moock via Gnupg-users wrote:
> Is there a limit for DNS records?

In theory, probably not.  In practice, most definitely, especially if 
you don't "own" the DNS server.

> I don't see a problem here, especially if they are provisioned in an
> automatic way.

Again, not everyone has that luxury.  There exist many web hosting 
providers whose only means of updating DNS is a crummy web application. 
CheaperDomains for example does this, and allows just 4 TXT records.

https://community.cloudflare.com/t/dns-record-limit/169997 suggests a 
limit of 1000 records for CloudFlare for example (and its import 
instructions limit the zone file to 256KiB).
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.


From hfollmann at itcfollmann.com  Sun Sep  1 10:07:19 2024
From: hfollmann at itcfollmann.com (Henning Follmann)
Date: Sun, 1 Sep 2024 04:07:19 -0400
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <1da1b417-04c7-4d5b-bd12-b90b730c3573@longlandclan.id.au>
References: <1da1b417-04c7-4d5b-bd12-b90b730c3573@longlandclan.id.au>
Message-ID: <271E02CF-5198-4523-A6BA-5A4639B10C3F@itcfollmann.com>



> On Sep 1, 2024, at 02:18, Stuart Longland via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> ?[Re-send with correct from: address? apologies to the moderators for the noise]
> 
>> On 1/9/24 15:55, Marco Moock via Gnupg-users wrote:
>> Is there a limit for DNS records?
> 
> In theory, probably not.  In practice, most definitely, especially if you don't "own" the DNS server.
> 
>> I don't see a problem here, especially if they are provisioned in an
>> automatic way.
> 
> Again, not everyone has that luxury.  There exist many web hosting providers whose only means of updating DNS is a crummy web application. CheaperDomains for example does this, and allows just 4 TXT records.
> 
> https://community.cloudflare.com/t/dns-record-limit/169997 suggests a limit of 1000 records for CloudFlare for example (and its import instructions limit the zone file to 256KiB).
> --
> 

And on top of that you need the unprotected private key for each user. 
That is probably a bad idea.

-H

From andrewg at andrewg.com  Sun Sep  1 12:24:40 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sun, 1 Sep 2024 11:24:40 +0100
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
Message-ID: <ABE99A3F-63E6-4302-879D-5F41A1A646D3@andrewg.com>

On 31 Aug 2024, at 23:35, T. S. <tfasnetamot at emailn.eu> wrote:
> 
> Hello,
> 
> after looking into DKIM details, I started searching, why the same procedure cannot be used for gpg?
> With gpg a lot of people from get confused, when they receive signed mails either because of the -----BEGIN PGP SIGNED MESSAGE----- strings, or because the unknown attachments in MIME message.
> 
> When now looking to DKIM, this looks much more advanced. There is a Header in the mail, containing the signature all details to the signature and information about header items included in the signature:
<snip>
> Is somethings similar available for GPG/PGP?
> 
> Currently I found nothing, but I expect that this could help for much better acceptance for signed mails.  Receivers, who don't know anything about gpg getting not confused, as the Header is totally invisible.
> With such an implementation I would start again sending all my mails automatically signed, as I have not longer to answer questions about my weird looking mails.

You?re essentially talking about defining a new cleartext signing mechanism, so that people using PGP-unaware mail clients can remain blissfully unaware, while also allowing for a graceful upgrade to signed mail for those who can.

Unfortunately, history has taught us that any cleartext sent over email *will* be mangled, and this will break the signature. MTAs are in general really bad at preserving the content of email messages. The only reliable way we know of to protect your signed plaintext is to encode it in something more robust, such as base64. Even then, if it is encoded as a base64 MIME part, MTAs have been known to mangle the MIME headers, which breaks the signature. And if you don?t sign over the MIME headers, your email is dangerously malleable (see efail). 

So for the foreseeable future at least, it seems you can have trustworthy signed emails or you can have backwards-compatible cleartext signing, but not both. 

A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240901/73643277/attachment.html>

From mm at dorfdsl.de  Mon Sep  2 06:49:37 2024
From: mm at dorfdsl.de (Marco Moock)
Date: Mon, 2 Sep 2024 06:49:37 +0200
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
Message-ID: <20240902064937.43bfc02b@zbook>

Am Sat, 31 Aug 2024 18:29:17 +0200
schrieb "T. S." <tfasnetamot at emailn.eu>:

> If someone could provide me with information, if such header
> implementations are already somewhere discussed, I would be glad.

I've now seen an implementation for signing control messages for Usenet:

ftp://ftp.isc.org/usenet/control/hispagatos/hispagatos.hacking.exploits.gz


MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="signcontrol"
Content-Transfer-Encoding: 8bit
X-PGP-Sig: GnuPG_v2 Subject,Control,Message-ID,Date,Injection-Date,From
        iQHIBAABCAAyFiEE/G5Aphyycx8BqrxkqP6aHcFxsyAFAmbRFmYUHG5ld3NAaGlz
        cGFnYXRvcy5vcmcACgkQqP6aHcFxsyDlYAwAuEZAjR7V/k9e73rkONzMAS24HWeQ
        6l5hraveKcUQKpvWu3BxQ5iVn2rxEixbHqsUi7CTXHThYGc85s0veqCTROE8AVC2
        11fSd0sQVz/1Gq2/Us/Dk3E6yttGEnJhBGsftQ/+BnTyhZ7Nr2iPUtBgZ8/B21B6
        Se9e0DJUozyFO/dLjSrd73aoMNW0p3Ay+jqvA0zO01lhrSkVRoqRggyIbZYRSiWX
        UkajMq5LglfVbWDhnT59p6D4tJBtVCYfDxBVMNN21ERFPy19pVhxgjjBgqf5OKZi
        Xu0dfruQcLDGhVuVH71gDc0TWC5gYzNKM46hZndPWrpx+IyAWJ/RwK2fsBNzNOpF
        Fc7RGKbKx7xdMX8ICHcSKxJzjBAYWw032ybWejodTl6C2ytqnDBbvrCMueZpoN1I
        NtWdPDflgapCtSL66I6JEV/HeaPVE8ZX5W2TRLPP67uTzfrmU03y2AW0VKQC77gb
        0F5Uxka7ThKOv64WgQcukidfaWBmeA3nGw49
        =tU9d


From wk at gnupg.org  Mon Sep  2 09:00:53 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 02 Sep 2024 09:00:53 +0200
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de> (T. S.'s
 message of "Sat, 31 Aug 2024 18:29:17 +0200")
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
Message-ID: <87wmju7d5m.fsf@jacob.g10code.de>

On Sat, 31 Aug 2024 18:29, T. S. said:

> either because of the -----BEGIN PGP SIGNED MESSAGE----- strings, or because
> the unknown attachments in MIME message.

Don't use those legacy inline PGP encryption.  Use PGP/MIME, a 28 year
old standard (RFC-2015).  You should give that unnamed attachment a
name, for example

  Content-Type: application/pgp-signature;
           name="openpgp-digital-signature.asc"

which clearly shows what kind of attachment this is.

> When now looking to DKIM, this looks much more advanced. There is a Header in
> the mail, containing the signature all details to the signature and

<the_usual_rant> You may want to go back to the year ~2000 when DKIM was
first presented at the IETF in Paris.  It was then a quick hack from the
sendmail authors and it took only a few hours until an attack on this
was found.  DKIM also broke with the long standing rule of being able to
work in a pipeline (iirc, this is called an online algo these days).
Instead of doing all that DKIM stuff it would have been easier to
directly use S/MIME or PGP/MIME and include copies of important headers
in a signed attachment.  But well, attachments are ugly for some people.
</>



Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240902/2f04bcc9/attachment.sig>

From jb-gnumlists at wisemo.com  Wed Sep  4 14:33:28 2024
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Wed, 4 Sep 2024 14:33:28 +0200
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <271E02CF-5198-4523-A6BA-5A4639B10C3F@itcfollmann.com>
References: <1da1b417-04c7-4d5b-bd12-b90b730c3573@longlandclan.id.au>
 <271E02CF-5198-4523-A6BA-5A4639B10C3F@itcfollmann.com>
Message-ID: <8601fff5-27bb-8e3f-d1ef-0f249d1de5db@wisemo.com>

On 2024-09-01 10:07, Henning Follmann wrote:
>
>> On Sep 1, 2024, at 02:18, Stuart Longland via Gnupg-users <gnupg-users at gnupg.org> wrote:
>>
>> ?[Re-send with correct from: address? apologies to the moderators for the noise]
>>
>>> On 1/9/24 15:55, Marco Moock via Gnupg-users wrote:
>>> Is there a limit for DNS records?
>> In theory, probably not.  In practice, most definitely, especially if you don't "own" the DNS server.
>>
>>> I don't see a problem here, especially if they are provisioned in an
>>> automatic way.
>> Again, not everyone has that luxury.  There exist many web hosting providers whose only means of updating DNS is a crummy web application. CheaperDomains for example does this, and allows just 4 TXT records.
>>
>> https://community.cloudflare.com/t/dns-record-limit/169997 suggests a limit of 1000 records for CloudFlare for example (and its import instructions limit the zone file to 256KiB).
>> --
>>
> And on top of that you need the unprotected private key for each user.
> That is probably a bad idea.
Not anymore than for any other signing.? In particular, only automated
server-side signing would need (somewhat) unprotected key access.
Signing in the MUA asdiscussed above could protect the key in a GPG
card, but is entirely hypotheticaland antithetical to the idea of DKIM.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From jb-gnumlists at wisemo.com  Wed Sep  4 14:41:38 2024
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Wed, 4 Sep 2024 14:41:38 +0200
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <87wmju7d5m.fsf@jacob.g10code.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <87wmju7d5m.fsf@jacob.g10code.de>
Message-ID: <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>

On 2024-09-02 09:00, Werner Koch via Gnupg-users wrote:
> On Sat, 31 Aug 2024 18:29, T. S. said:
>
>> either because of the -----BEGIN PGP SIGNED MESSAGE----- strings, or because
>> the unknown attachments in MIME message.
> Don't use those legacy inline PGP encryption.  Use PGP/MIME, a 28 year
> old standard (RFC-2015).  You should give that unnamed attachment a
> name, for example
>
>    Content-Type: application/pgp-signature;
>             name="openpgp-digital-signature.asc"
>
> which clearly shows what kind of attachment this is.
>
>> When now looking to DKIM, this looks much more advanced. There is a Header in
>> the mail, containing the signature all details to the signature and
> <the_usual_rant> You may want to go back to the year ~2000 when DKIM was
> first presented at the IETF in Paris.  It was then a quick hack from the
> sendmail authors and it took only a few hours until an attack on this
> was found.  DKIM also broke with the long standing rule of being able to
> work in a pipeline (iirc, this is called an online algo these days).
> Instead of doing all that DKIM stuff it would have been easier to
> directly use S/MIME or PGP/MIME and include copies of important headers
> in a signed attachment.  But well, attachments are ugly for some people.
> </>
Using S/MIME for server to server protection would involve heavy mangling
of mail bodies, unlike the header-only placement of DKIM signatures.? It
is true that DKIM generation and validation needs the entire mail in some
kind of storage, such as the mail spool of a resend-capable MTA, which is
a key reliability requirement for non-spam mail servers anyway.

As a mail admin I see a lot of buggy 3rd party mail servers built by rather
large companies, but the traditional line mangling so common before MIME
seems a thing of the past, while Base64 encoding mail bodies has become
the realm of buggy software and/or spam (I happen to use such a buggy big
name SMTP library for mailing webshop receipts etc.)

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From andrewg at andrewg.com  Wed Sep  4 15:05:28 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 4 Sep 2024 14:05:28 +0100
Subject: Signing (and Encrypting) Mails with gpg like DKIM
In-Reply-To: <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <87wmju7d5m.fsf@jacob.g10code.de>
 <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>
Message-ID: <FD3723E3-3979-4D67-8F50-91C3B8AD8AB7@andrewg.com>

On 4 Sep 2024, at 13:41, Jakob Bohm via Gnupg-users <gnupg-users at gnupg.org> wrote:
> 
> As a mail admin I see a lot of buggy 3rd party mail servers built by rather
> large companies, but the traditional line mangling so common before MIME
> seems a thing of the past,

As I mentioned already in an (accidental) off-list message to the OP, I have one regular correspondent who sees my signatures as broken if I send email from my laptop, because some as yet unknown MTA on the path between us is normalising a double newline into a single newline between the MIME headers of the inner multipart and the inner MIME plaintext part. I?m sure I?m not the only person to experience this.

A

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240904/6e8bf717/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240904/6e8bf717/attachment.sig>

From dkg at fifthhorseman.net  Thu Sep  5 17:04:23 2024
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 05 Sep 2024 11:04:23 -0400
Subject: Signing Mails with OpenPGP like DKIM [was: gpg like DKIM]
In-Reply-To: <FD3723E3-3979-4D67-8F50-91C3B8AD8AB7@andrewg.com>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <87wmju7d5m.fsf@jacob.g10code.de>
 <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>
 <FD3723E3-3979-4D67-8F50-91C3B8AD8AB7@andrewg.com>
Message-ID: <87jzfqw39k.fsf@fifthhorseman.net>

On Wed 2024-09-04 14:05:28 +0100, Andrew Gallagher via Gnupg-users wrote:

> As I mentioned already in an (accidental) off-list message to the OP,
> I have one regular correspondent who sees my signatures as broken if I
> send email from my laptop, because some as yet unknown MTA on the path
> between us is normalising a double newline into a single newline
> between the MIME headers of the inner multipart and the inner MIME
> plaintext part. I?m sure I?m not the only person to experience this.

I think that's me!  We should really try to debug that further at some
point, Andrew, but not at the risk of distracting from or delaying any
of the many other projects we're collaborating on at the moment ?

Back to the topic at hand: it seems like there are several orthogonal
questions that are being discussed in this thread, and it would be best
to tease them apart if anyone wants to make progress.  I *do* think
progress is achievable here and might be worthwhile on at least some
of these ideas, but it would happen on a matter of years, not months.

Let's break out the distinct things that people might want from "using
OpenPGP like DKIM"

? Who is doing the DKIM signing?  DKIM signatures are typically done by
  the server (the MTA), but this thread includes some discussion about
  them being done by the user (the MUA).  The *recipient* of course,
  can't tell whether the DKIM signing key is held by the MUA or the MTA,
  so this doesn't really give the recipient any clear end-to-end
  assurances.  I'm personally not that interested in the idea of giving
  DKIM signing keys to end users, but this is one possible project.

? Doing something DKIM-like, but for encryption: i don't think this is a
  coherent goal.  DKIM is signatures-only, and trying to repurpose it
  for encryption doesn't make sense.

? Putting end-user OpenPGP certificates in the DNS: this one is already
  done!  See RFC 7929 (https://datatracker.ietf.org/doc/html/rfc7929)

? Creating a new structure for signed-only mail that would be capable of
  improving on (and at some point supplanting) PGP/MIME
  multipart/signed: This is where i think it gets interesting.  If you
  want to pursue this, i'd recommend identifying the specific flaws of
  PGP/MIME multipart/signed that you want to ameleiorate, and the
  tradeoffs that you're willing to accept to fix them.  You probably
  want to find a proper venue for discussion (e.g. The IETF OpenPGP or
  LAMPS or perhaps MAILMAINT lists).

  I would avoid trying to mix this mechanism into encrypted+signed mail,
  as we already have standards for doing that safely that don't have the
  drawbacks that multipart/signed has.

  I think you could specify such a mechanism relatively quickly if you
  make use of existing DKIM message canonicalization rules and header
  structure (but without calling it "DKIM") and replacing the DKIM
  signature blob with a base64-encoded binary OpenPGP signature object.

  You'd want to make sure that all of the headers applied by the sending
  MUA are included in the signature, so that you don't cause a
  regression from draft-ietf-lamps-header-protection mechanisms.

  And you'd need to recruit a few MUA developers who would be willing to
  verify signatures structured in this way, and to be capable of
  producing them.

  And finally, you'd need to think about the UX concerns: should the end
  user be responsible for selecting which kind of signed-only message to
  produce?  I don't think that's a reasonable question to ask of end
  users, who just want to send mail.  Do you need a
  signalling/negotiation mechanism so that MUAs can automatically choose
  the "best" signing format for any given outbound message?  Or can you
  frame the tradeoffs such that a MUA can at some point just
  unilaterally choose to emit the new format and be confident that their
  signed-only messages will be acceptable?

  Such a deployment would probably be helped along by leaning into
  recommendation (common to both DKIM and to
  draft-ietf-lamps-e2e-mail-guidance) that a message with a broken
  signature be presented in no more scary a form than a message with no
  signature whatsoever.


If you're interested in doing this kind of work but have never done
interoperable standardization before, i'd be happy to give you some
pointers and help nudge this along where i can.  This has been on my
list of things to clean up in the ecosystem for a while, and it just
needs someone to drive it forward.

      --dkg

PS for the record, i think there is one major concern about PGP/MIME
   multipart/signed: for users of MUAs that don't understand PGP/MIME,
   the signature shows up as a mystery attachment.  I can't tell you the
   number of times that i get a response from a colleague that says "i
   can't open your attachment, please re-send".  That happens often
   enough that i deliberately do not sign mail unless i know the
   recipient won't do that.  That means i don't sign most of my mail,
   which means i can't expect anyone to expect that all my mail will be
   signed.  If a mechanism like this was available, and especially if it
   didn't automatically cause warnings on the receiving end when the
   signature failed to validate, i'd use it to sign *all* of my
   cleartext mail.  Once i am comfortable signing all of my cleartext
   mail, i would be happy to start opting into something like
   https://datatracker.ietf.org/doc/draft-dkg-lamps-expect-signed-mail/

   This is a multi-stage process to get to the point where at least some
   people can have robust e2e cryptographic authenticity protections for
   their mail, but i think the work described above would be a great
   start.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 324 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240905/ea1a7f40/attachment.sig>

From wk at gnupg.org  Fri Sep  6 11:26:30 2024
From: wk at gnupg.org (Werner Koch)
Date: Fri, 06 Sep 2024 11:26:30 +0200
Subject: [Feature request] Please make it easier to check
 success/failure from scripts
In-Reply-To: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com> (Jakob Bohm via
 Gnupg-users's message of "Tue, 27 Aug 2024 17:37:03 +0200")
References: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com>
Message-ID: <87wmjpb0ah.fsf@jacob.g10code.de>

Hi!

On Tue, 27 Aug 2024 17:37, Jakob Bohm said:

> status-fd output for a multitude of situation specific strings.?
> Sometimes it is even necessary to check if the expected signing key is
> mentioned in specific ways.

Right.  That is because there are a lot of use cases for signatures
which required different handling depending on the signature (e.g. time
created) and meta data from the key.

For OpenPGP we wrote gpgv to handle one common task; which was
originally Debian package signing.

Only recently we added --assert-signer to gpg which actually can replace
gpgv.  The plan is to add a few other --assert options for example to
check the time the signature was made.

> I know this because I have a script that uses gpgsm to do pipelined
> check of a large CMS signed system log, which is signed by the server
> to prevent later malicious changes.? gpgsm is used because of its
> specific support for streamed processing.

Cool.  I didn't expected that someone really has this use case.  But it
makes sense.  See T7286: Add --assert-signer also to gpgsm.

> Another, related, feature would be the ability to run the gnupg tools
> in a mode that doesn't talk to any part of the environment, neither
> the gnupg config dir, nor the various helper programs (directory,
> password prompt etc.), but instead acts predicatably based only on the
> command line options.

That is too hard to implement.  We have keys, trust models, ownertrust,
and compliance modes which is quite some data.  For this it is better to
use a separate GNUPGHOME.  The --assert-signer requires a fingerprint or
the list of fingerprints and thus the import of the to-be-tested keys
prior to running a verification.  It might be possible to combine the
import and the verification and even make the imported keys ephemeral
so that they don't clutter the keyring.  However, some file system write
access will be required unless we can find a way to keep the keys in a
memory only database.  A RAM based file system and ephemeral storage of
keys would be an easier solution.


Shalom-Salam,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240906/aa268f49/attachment.sig>

From wk at gnupg.org  Fri Sep  6 14:00:53 2024
From: wk at gnupg.org (Werner Koch)
Date: Fri, 06 Sep 2024 14:00:53 +0200
Subject: Signing Mails with OpenPGP like DKIM
In-Reply-To: <87jzfqw39k.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via
 Gnupg-users's message of "Thu, 05 Sep 2024 11:04:23 -0400")
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <87wmju7d5m.fsf@jacob.g10code.de>
 <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>
 <FD3723E3-3979-4D67-8F50-91C3B8AD8AB7@andrewg.com>
 <87jzfqw39k.fsf@fifthhorseman.net>
Message-ID: <87seudat56.fsf_-_@jacob.g10code.de>

On Thu,  5 Sep 2024 11:04, Daniel Kahn Gillmor said:

> PS for the record, i think there is one major concern about PGP/MIME
>    multipart/signed: for users of MUAs that don't understand PGP/MIME,
>    the signature shows up as a mystery attachment.  I can't tell you the

See 
GpgOL: Add filenames for PGP/MIME parts
https://dev.gnupg.org/T4258

on how to solve that.  Complaints about strange attachments dropped to
nearly zero after we deployed that change 5 years ago.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240906/7983ecd2/attachment.sig>

From dkg at fifthhorseman.net  Fri Sep  6 16:00:09 2024
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 06 Sep 2024 10:00:09 -0400
Subject: Signing Mails with OpenPGP like DKIM
In-Reply-To: <87seudat56.fsf_-_@jacob.g10code.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <87wmju7d5m.fsf@jacob.g10code.de>
 <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>
 <FD3723E3-3979-4D67-8F50-91C3B8AD8AB7@andrewg.com>
 <87jzfqw39k.fsf@fifthhorseman.net> <87seudat56.fsf_-_@jacob.g10code.de>
Message-ID: <877cbox4pi.fsf@fifthhorseman.net>

On Fri 2024-09-06 14:00:53 +0200, Werner Koch wrote:
> See 
> GpgOL: Add filenames for PGP/MIME parts
> https://dev.gnupg.org/T4258
>
> on how to solve that.  Complaints about strange attachments dropped to
> nearly zero after we deployed that change 5 years ago.

This is a great idea, and certainly an improvement over an unnamed MIME
part.  That said, i suspect you have a more technical userbase than the
pool of people i correspond with.

Receiving an uninterpretable attachment named
"openpgp-digital-signature.asc" or "smime.p7s" would get me responses
like "what's an .asc file?" or "I don't know how to open a .p7s file!"
or "what does openpgp-digital-signature have to do with [subject of
message]?"

The less visible the signature is for people who can't use it, the
better.

           --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 324 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240906/3bf0979e/attachment-0001.sig>

From wk at gnupg.org  Fri Sep  6 18:10:54 2024
From: wk at gnupg.org (Werner Koch)
Date: Fri, 06 Sep 2024 18:10:54 +0200
Subject: Signing Mails with OpenPGP like DKIM
In-Reply-To: <877cbox4pi.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via
 Gnupg-users's message of "Fri, 06 Sep 2024 10:00:09 -0400")
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <87wmju7d5m.fsf@jacob.g10code.de>
 <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>
 <FD3723E3-3979-4D67-8F50-91C3B8AD8AB7@andrewg.com>
 <87jzfqw39k.fsf@fifthhorseman.net>
 <87seudat56.fsf_-_@jacob.g10code.de>
 <877cbox4pi.fsf@fifthhorseman.net>
Message-ID: <87o750bw4x.fsf@jacob.g10code.de>

On Fri,  6 Sep 2024 10:00, Daniel Kahn Gillmor said:

> part.  That said, i suspect you have a more technical userbase than the
> pool of people i correspond with.

ROFL

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240906/64acf376/attachment.sig>

From steffen at sdaoden.eu  Fri Sep  6 21:17:36 2024
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 06 Sep 2024 21:17:36 +0200
Subject: Signing Mails with OpenPGP like DKIM
In-Reply-To: <87o750bw4x.fsf@jacob.g10code.de>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <87wmju7d5m.fsf@jacob.g10code.de>
 <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>
 <FD3723E3-3979-4D67-8F50-91C3B8AD8AB7@andrewg.com>
 <87jzfqw39k.fsf@fifthhorseman.net> <87seudat56.fsf_-_@jacob.g10code.de>
 <877cbox4pi.fsf@fifthhorseman.net> <87o750bw4x.fsf@jacob.g10code.de>
Message-ID: <20240906191736.7MrPzlzy@steffen%sdaoden.eu>

Werner Koch via Gnupg-users wrote in
 <87o750bw4x.fsf at jacob.g10code.de>:
 |On Fri,  6 Sep 2024 10:00, Daniel Kahn Gillmor said:
 |
 |> part.  That said, i suspect you have a more technical userbase than the
 |> pool of people i correspond with.
 |
 |ROFL

There is btw also Content-Description:.  (Depends on the mailer if
it is used it seems (superficial knowledge), but especially so if
filename is set as is in the patch.)
(I think of all this rather as a more political issue, anyway.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From harish.chandrasekar16 at gmail.com  Sat Sep  7 19:52:34 2024
From: harish.chandrasekar16 at gmail.com (Harish Chandrasekar)
Date: Sat, 7 Sep 2024 23:22:34 +0530
Subject: PGP Linux OS Upgrade Issue
Message-ID: <CAMvz1jrOFsEAPNLHELwYsrP-GuOTBkY5YoyixtvPmdP8hVW4zQ@mail.gmail.com>

Hi,

Recently our servers were migrated from Linux REHL 7 to 9. We have PGP
encryption/decryption done as part of our apps using java which runs the
gpg command . The issue is after upgradation we have installed gnupg 2 2.3
v and pinentry 1.1 but 1st time when the script runs popup of passphrase is
displayed .(manually checked by running command in terminal since we were
reciving timout when run through application). How to stop this pop up
since passphrase is already part of the command.

gpg --homedir ~/.gnupg/ --batch --yes --no--tty --receipient <value>
--passphrase <value> --output <value> --decrypt --value

Googled and found couple of suggestions to add loopback entry in pgp.conf
and pgp-agent.conf. So have created files  under .gngpg and made entries as
well.Restarted the deamon. Nothing worked.


I would highly appreciate if anyone can help on this issue?


Regards,
C.Harish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240907/c531f529/attachment.html>

From dkg at fifthhorseman.net  Mon Sep  9 05:47:38 2024
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 08 Sep 2024 23:47:38 -0400
Subject: [Feature request] Please make it easier to check
 success/failure from scripts
In-Reply-To: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com>
References: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com>
Message-ID: <87wmjlv679.fsf@fifthhorseman.net>

On Tue 2024-08-27 17:37:03 +0200, Jakob Bohm via Gnupg-users wrote:
> Another, related, feature would be the ability to run the gnupg tools in 
> a mode that doesn't talk to any part of the environment, neither the 
> gnupg config dir, nor the various helper programs (directory, password 
> prompt etc.), but instead acts predicatably based only on the command 
> line options.

Given this request for statelessness, You might be interested in the
"stateless openpgp command line interface", or "sop", which is designed
in many ways for the types of operations you're talking about:

    https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/

(disclaimer: I've been shepherding the specification, but there are a
half-dozen high quality implementations in the wild and several more in
incubation)

For signature verification specifically, the "sopv" verification-only
subset is intended specifically to integrate well with other POSIX
commands.  A sopv implementation that wraps gpgv and handles all the
status-fd checking as documented is also available at:

    https://gitlab.com/dkg/sopv-gpgv

I see that you're using S/MIME and/or CMS (i.e. gpgsm) instead of the
OpenPGP equivalents, and i don't know that anyone has produced something
comparable for S/MIME or CMS, unfortunately.  But the rough shape of the
problem space is the same.  I'd be very surprised if you couldn't move
your administrative tooling over to using OpenPGP and making it work
successfully with any of the available sop implementations.

Regards,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 324 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240908/26718de8/attachment.sig>

From wk at gnupg.org  Mon Sep  9 15:13:07 2024
From: wk at gnupg.org (Werner Koch)
Date: Mon, 09 Sep 2024 15:13:07 +0200
Subject: [admin] This is a GnuPG related ML
In-Reply-To: <87wmjlv679.fsf@fifthhorseman.net> (Daniel Kahn Gillmor via
 Gnupg-users's message of "Sun, 08 Sep 2024 23:47:38 -0400")
References: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com>
 <87wmjlv679.fsf@fifthhorseman.net>
Message-ID: <877cblas2k.fsf_-_@jacob.g10code.de>

Hi!

Just a short reminder that this mailing list's topic is GnuPG.

Advertisement for other applications, like a Python wrapper around a
long standing command line API (going all the way back to pgp 2), is
thus off-topic.  It feels more like a SEO strategy than as helpful
information.  Please don't confuse users; search engines already deliver
too much misinformation on best gpg practices.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240909/59e2fcaf/attachment.sig>

From andrewg at andrewg.com  Wed Sep 11 10:18:02 2024
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 11 Sep 2024 09:18:02 +0100
Subject: Signing Mails with OpenPGP like DKIM [was: gpg like DKIM]
In-Reply-To: <87jzfqw39k.fsf@fifthhorseman.net>
References: <e692b965dc9f391cee92daf1c8eab40b@mail.emailn.de>
 <87wmju7d5m.fsf@jacob.g10code.de>
 <a2febef6-623f-f03a-d4fd-10e5d1e0f19f@wisemo.com>
 <FD3723E3-3979-4D67-8F50-91C3B8AD8AB7@andrewg.com>
 <87jzfqw39k.fsf@fifthhorseman.net>
Message-ID: <B0B95AC8-0F09-4603-B0DF-B3835F0AE3E5@andrewg.com>

On 5 Sep 2024, at 16:04, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> 
> PS for the record, i think there is one major concern about PGP/MIME
>   multipart/signed: for users of MUAs that don't understand PGP/MIME,
>   the signature shows up as a mystery attachment.  I can't tell you the
>   number of times that i get a response from a colleague that says "i
>   can't open your attachment, please re-send".  That happens often
>   enough that i deliberately do not sign mail unless i know the
>   recipient won't do that.  That means i don't sign most of my mail,

I?ve been signing all my email (from my laptop anyway) for twenty years, and the last time I had complaints about mystery attachments was in the early 2000s. That said, there are a lot of automated systems (e.g. bug trackers) that treat the attachment as a file that needs to be recorded for posterity, e.g. attaching it to a ticket on every emailed comment/reply (although this also applies to HTML email signature footers, which is more annoying). So I do think that moving from an attachment-based cleartext format to a header-based one has some advantages.

A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240911/545c6fef/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240911/545c6fef/attachment-0001.sig>

From wk at gnupg.org  Thu Sep 12 14:02:41 2024
From: wk at gnupg.org (Werner Koch)
Date: Thu, 12 Sep 2024 14:02:41 +0200
Subject: [Announce] GnuPG 2.5.1 released
Message-ID: <87wmjh6pwe.fsf@jacob.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
version 2.5.1.  This release is the second of a series of public testing
releases eventually leading to a new stable version 2.6.

The main features in the 2.6 series are improvements for 64 bit Windows
and the introduction of a PQC encryption algorithm.

The 2.6 series will not differ a lot from 2.4 because the majority of
changes are internal to make use of newer features from the supporting
libraries. 


What is GnuPG
=============

The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation
of the OpenPGP and S/MIME standards.

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  The separate library GPGME provides
a uniform API to use the GnuPG engine by software written in common
programming languages.  A wealth of frontend applications and libraries
making use of GnuPG are available.  As an universal crypto engine GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.

GnuPG is Free Software (meaning that it respects your freedom).  It can
be freely used, modified and distributed under the terms of the GNU
General Public License.


Noteworthy changes in version 2.5.1 (2024-09-12)
================================================
         [compared to version 2.5.0]

  * gpg: The support for composite Kyber+ECC public key algorithms
    does now use the final FIPS-203 and LibrePGP specifications.  The
    experimental keys from 2.5.0 are no longer supported.  [T6815]

  * gpg: New commands --add-recipients and --change-recipients.
    [T1825]

  * gpg: New option --proc-all-sigs.  [T7261]

  * gpg: Fix a regression in 2.5.0 in gpgme's tests.  [T7195]

  * gpg: Make --no-literal work again for -c and --store.  [T5852]

  * gpg: Improve detection of input data read errors.  [T6528]

  * gpg: Fix getting key by IPGP record (rfc-4398).  [T7288]

  * gpgsm: New option --assert-signer.  [T7286]

  * gpgsm: More improvements to PKCS#12 parsing to cope with latest
    IVBB changes.  [T7213]

  * agent: Fix KEYTOCARD command when used with a loopback pinentry.
    [T7283]

  * gpg-mail-tube: Make sure GNUPGHOME is set in vsd mode.  New option
    --as-attach.  [rG4511997e9e1b]

  * Now uses the process spawn API from libgpg-error.  [T7192,T7194]

  * Removed the --enable-gpg-is-gpg2 configure time option.
    [rG2125f228d36c]

  * Die Windows version will now be build for 64-Bit Windows and with
    the corresponding changes to the installation directory and
    Registry keys.

  Release-info: https://dev.gnupg.org/T7191


Getting the Software
====================

Please follow the instructions found at <https://gnupg.org/download/> or
read on:

GnuPG may be downloaded from one of the GnuPG mirror sites or direct
from its primary file server.  The list of mirrors can be found at
<https://gnupg.org/download/mirrors.html>.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.1.tar.bz2 (7936k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.1.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.1_20240912.exe (5449k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.1_20240912.exe.sig

Note that these Windows binaries are exceptionally not AuthentiCode
signed and not well tested.  The source used to build this Windows
installer is available at

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.1_20240912.tar.xz (16M)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.1_20240912.tar.xz.sig

This Windows source tarball may also be used to download all required
libraries at once to build a Unix version on any modern system.  See the
included README but replace the make target "native" by "this-native".
  


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.5.1.tar.bz2 you would use this command:

     gpg --verify gnupg-2.5.1.tar.bz2.sig gnupg-2.5.1.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See the end of this mail for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.5.1.tar.bz2, you run the command like this:

     sha1sum gnupg-2.5.1.tar.bz2

   and check that the output matches the next line:

1336f00a6d9ff9806a2187bb06e8faf59391b5a2  gnupg-2.5.1.tar.bz2
4237371dbe5ebafaa015da2f3681f466b65c9742  gnupg-w32-2.5.1_20240912.tar.xz
772dda3a41f7cafd07cad66340fa17becc77687d  gnupg-w32-2.5.1_20240912.exe


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), Czech, French, German, Italian,
Japanese, Norwegian, Polish, Russian, Turkish, and Ukrainian
being almost completely translated.


Documentation and Support
=========================

The file gnupg.info has the complete reference manual of the system.
Separate man pages are included as well but they miss some of the
details available only in the manual.  The manual is also available
online at

  https://gnupg.org/documentation/manuals/gnupg/

or can be downloaded as PDF at

  https://gnupg.org/documentation/manuals/gnupg.pdf

You may also want to search the GnuPG mailing list archives or ask on
the gnupg-users mailing list for advise on how to solve problems.  Most
of the new features are around for several years and thus enough public
experience is available.  https://wiki.gnupg.org has user contributed
information around GnuPG and relate software.

In case of build problems specific to this release please first check
https://dev.gnupg.org/T7191 for updated information.  

Please consult the archive of the gnupg-users mailing list before
reporting a bug: https://gnupg.org/documentation/mailing-lists.html.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at https://bugs.gnupg.org.  If you need commercial
support go to https://gnupg.com or https://gnupg.org/service.html.

If you are a developer and you need a certain feature for your project,
please do not hesitate to bring it to the gnupg-devel mailing list for
discussion.


Thanks
======

Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH
and has mostly been financed by donations.  Several full-time employed
developers and contractors are working exclusively on GnuPG and closely
related software like Libgcrypt, GPGME, Kleopatra and Gpg4win.

Fortunately, and this is still not common with free software, we have
established a way of financing the development while keeping all our
software free and freely available for everyone.  Our model is similar
to the way RedHat manages RHEL and Fedora: Except for the actual binary
of the MSI installer for Windows and client specific configuration
files, all the software is available under the GNU GPL and other Open
Source licenses.  Thus customers may even build and distribute their own
version of the software as long as they do not use our trademarks
GnuPG Desktop? or GnuPG VS-Desktop?.

We like to thank all the nice people who are helping the GnuPG project,
be it testing, coding, translating, suggesting, auditing, administering
the servers, spreading the word, answering questions on the mailing
lists, or helped with donations.

*Thank you all*

   Your GnuPG hackers


p.s.
This is an announcement only mailing list.  Please send replies only to
the gnupg-users at gnupg.org mailing list.

List of Release Signing Keys:
To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are signed by one or more
of these four keys:

  rsa3072 2017-03-17 [expires: 2027-03-15]
  5B80 C575 4298 F0CB 55D8  ED6A BCEF 7E29 4B09 2E28
  Andre Heinecke (Release Signing Key)

  ed25519 2020-08-24 [expires: 2030-06-30]
  6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
  Werner Koch (dist signing 2020)

  ed25519 2021-05-19 [expires: 2027-04-04]
  AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
  Niibe Yutaka (GnuPG Release Key)

  brainpoolP256r1 2021-10-15 [expires: 2029-12-31]
  02F3 8DFF 731F F97C B039  A1DA 549E 695E 905B A208
  GnuPG.com (Release Signing Key 2021)

The keys are available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed by a different key.

-- 
Arguing that you don't care about the right to privacy because you have
nothing to hide is no different from saying you don't care about free
speech because you have nothing to say.                - Edward Snowden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240912/e20011a8/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From alx at kernel.org  Thu Sep 12 13:28:37 2024
From: alx at kernel.org (Alejandro Colomar)
Date: Thu, 12 Sep 2024 13:28:37 +0200
Subject: Text (non-binary) keyring format
Message-ID: <eiecwibyxdcdzxnc5ywsxa35akdcppomgzkelx5ipyom2iesed@wsjm2kgisgbt>

Hi,

I have my ~/.gnupg keyring under git source control, which helps
creating and updating backups, and also having a history of the changes.
I find that having the contents in binary format is odd, and think it
would be much better if it was all stored in text files.  I would be
able to understand the diffs, and if a failure happens before a backup,
I'd probably be able to at least diff(1) the contents of the keyring and
recover something.

Would you consider developing a new format for the keyring, where stuff
is divided in small text files, just like most Unix stuff?

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240912/b503470e/attachment.sig>

From steffen at sdaoden.eu  Thu Sep 12 23:00:08 2024
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 12 Sep 2024 23:00:08 +0200
Subject: Text (non-binary) keyring format
In-Reply-To: <eiecwibyxdcdzxnc5ywsxa35akdcppomgzkelx5ipyom2iesed@wsjm2kgisgbt>
References: <eiecwibyxdcdzxnc5ywsxa35akdcppomgzkelx5ipyom2iesed@wsjm2kgisgbt>
Message-ID: <20240912210008.k4szuwdl@steffen%sdaoden.eu>

Alejandro Colomar via Gnupg-users wrote in
 <eiecwibyxdcdzxnc5ywsxa35akdcppomgzkelx5ipyom2iesed at wsjm2kgisgbt>:
 |I have my ~/.gnupg keyring under git source control, which helps
 |creating and updating backups, and also having a history of the changes.
 |I find that having the contents in binary format is odd, and think it
 |would be much better if it was all stored in text files.  I would be
 |able to understand the diffs, and if a failure happens before a backup,
 |I'd probably be able to at least diff(1) the contents of the keyring and
 |recover something.

I do that too.  (In fact i even have three different PGP
directories, ehem, all 1.4 still, i am sorry, but these are
pgp-nosecrets.git (no secring, only public key), pgp.git
(mutilated private key, for creating signatures, but which cannot
be exported or whatever, and has its own specific password; thanks
again for this great idea and fantastic possibility!), and
~/sic/pgp.git (there it is).)

 |Would you consider developing a new format for the keyring, where stuff
 |is divided in small text files, just like most Unix stuff?

And how about using a LMDB database.
Seriously, i also hate it, but even more seriously, how about
exporting at times stuff via "--list-keys/--list-sigs --with-
colons --verbose", and then further process the output if you
want?  Ie hop from ^pub to ^pub, use "--list-key ID" and then even
"--armor --export ID".

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From ralph at ml.seichter.de  Fri Sep 13 02:22:06 2024
From: ralph at ml.seichter.de (Ralph Seichter)
Date: Fri, 13 Sep 2024 02:22:06 +0200
Subject: Text (non-binary) keyring format
In-Reply-To: <eiecwibyxdcdzxnc5ywsxa35akdcppomgzkelx5ipyom2iesed@wsjm2kgisgbt>
References: <eiecwibyxdcdzxnc5ywsxa35akdcppomgzkelx5ipyom2iesed@wsjm2kgisgbt>
Message-ID: <87ttekpfm9.fsf@ra.horus-it.com>

* Alejandro Colomar via Gnupg-users:

> I have my ~/.gnupg keyring under git source control, which helps
> creating and updating backups, and also having a history of the
> changes.  I find that having the contents in binary format is odd, and
> think it would be much better if it was all stored in text files.

I have my GnuPG keyrings and config under version control as well.
However, I think that the key material does not really lend itself
to text-based inspection with something like 'diff', in contrast to
config files.

For recovery, I have sometimes accessed historic keyrings, but only as a
whole. and then exported a certain key, to be re-imported into my newer
keyring. I don't see myself accessing some part of a keyring without
using the GnuPG binary, so I wonder what tanglibe benefit a text-based
storage format would bring to the table?

-Ralph


From wk at gnupg.org  Fri Sep 13 13:39:08 2024
From: wk at gnupg.org (Werner Koch)
Date: Fri, 13 Sep 2024 13:39:08 +0200
Subject: Text (non-binary) keyring format
In-Reply-To: <eiecwibyxdcdzxnc5ywsxa35akdcppomgzkelx5ipyom2iesed@wsjm2kgisgbt>
 (Alejandro Colomar via Gnupg-users's message of "Thu, 12 Sep 2024
 13:28:37 +0200")
References: <eiecwibyxdcdzxnc5ywsxa35akdcppomgzkelx5ipyom2iesed@wsjm2kgisgbt>
Message-ID: <87seu37pgj.fsf@jacob.g10code.de>

Hi!

On Thu, 12 Sep 2024 13:28, Alejandro Colomar said:

> I have my ~/.gnupg keyring under git source control, which helps
> creating and updating backups, and also having a history of the changes.

That is not a good idea because the key database (pubring.gpg,
pubring.kbx, or keyboxd DB) are a binary format which also stores meta
data which is only used by gnupg itself and not part of an official
API (e.g. the signature cache).

Thus if you want to put something under version control, it is better to
do this with exported files.  You may use "--export-option backup" so
that you get all the internal infos and also non-exportable signed
signatures ("--export-option export-local-sigs" would be sufficient
here.

Although I really like text files, it will be somewhat hard to diff them
because any property update of a key also requires a new signature and
that give a lot of diff overhead.  This is similar to Libreoffice's fodt
format - in theory a way to diff things but in practice it is useless.

We actually moved to an SQL database to speed up things.  If you have
hundreds of keys with thousands of key signatures it is very helpful to
have indices; it really speeds up things.

OpenPGP keys do not allow a rollback by design.  For documentation
writing a (sorted) key listing to a file might thus be more useful than
plain text files.



Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240913/92296f1d/attachment.sig>

From wk at gnupg.org  Fri Sep 13 16:42:04 2024
From: wk at gnupg.org (Werner Koch)
Date: Fri, 13 Sep 2024 16:42:04 +0200
Subject: [Feature request] Please make it easier to check
 success/failure from scripts
In-Reply-To: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com> (Jakob Bohm via
 Gnupg-users's message of "Tue, 27 Aug 2024 17:37:03 +0200")
References: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com>
Message-ID: <87ed5n62f7.fsf@jacob.g10code.de>

Hi!

GnuPG 2.5.1 has the option --assert-signer and 2.4.6 will have this
option as well:

   --assert-signer fpr_or_file
   
     This option checks whether at least one valid signature on a file
     has been made with the specified key.  The key is either specified
     as a fingerprint or a file listing fingerprints.  The fingerprint
     must be given or listed in compact format (no colons or spaces in
     between).  As of now only SHA-1 fingerprints are allowed.  This
     option can be given multiple times and each fingerprint is checked
     against the sign? ing key as well as the corresponding primary key.
     If fpr_or_file specifies a file, empty lines are ignored as well as
     all lines start? ing with a hash sign.  With this option gpgsm is
     guaranteed to return with an exit code of 0 if and only if a
     signature has been encoun? tered, is valid, and the key matches one
     of the fingerprints given by this option.


Tarcked as https://dev.gnupg.org/T7286

Hope that helps a bit.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240913/22fe6004/attachment-0001.sig>

From alx at kernel.org  Fri Sep 13 14:02:54 2024
From: alx at kernel.org (Alejandro Colomar)
Date: Fri, 13 Sep 2024 14:02:54 +0200
Subject: Text (non-binary) keyring format
In-Reply-To: <87seu37pgj.fsf@jacob.g10code.de>
References: <eiecwibyxdcdzxnc5ywsxa35akdcppomgzkelx5ipyom2iesed@wsjm2kgisgbt>
 <87seu37pgj.fsf@jacob.g10code.de>
Message-ID: <mrko6hqnsfcplkv7scrx5nsj3kxbce3a44gxrgesvqfjffunwm@p2ebxurrfqcm>

Hi Werner,

On Fri, Sep 13, 2024 at 01:39:08PM GMT, Werner Koch wrote:
> Hi!
> 
> On Thu, 12 Sep 2024 13:28, Alejandro Colomar said:
> 
> > I have my ~/.gnupg keyring under git source control, which helps
> > creating and updating backups, and also having a history of the changes.
> 
> That is not a good idea because the key database (pubring.gpg,
> pubring.kbx, or keyboxd DB) are a binary format which also stores meta
> data which is only used by gnupg itself and not part of an official
> API (e.g. the signature cache).

Maybe you could split the pubring as a directory with many files, have
most of them as text files, and a few that need to be binary could be
kept as binary.

> Thus if you want to put something under version control, it is better to
> do this with exported files.  You may use "--export-option backup" so
> that you get all the internal infos and also non-exportable signed
> signatures ("--export-option export-local-sigs" would be sufficient
> here.

I prefer having the actual keyring under version control, although will
consider that option.

> Although I really like text files, it will be somewhat hard to diff them
> because any property update of a key also requires a new signature and
> that give a lot of diff overhead.

If we had one text file per contact (just like we have now one text file
per private key under `~/.gnupg/private-keys-v1.d`), I wouldn't mind the
diff for the contact to look like an entire (or almost entire) rewrite
of the contact.  That's already better than
"Binary files a/pubring.kbx and b/pubring.kbx differ".

>  This is similar to Libreoffice's fodt
> format - in theory a way to diff things but in practice it is useless.
> 
> We actually moved to an SQL database to speed up things.  If you have
> hundreds of keys with thousands of key signatures it is very helpful to
> have indices; it really speeds up things.
> 
> OpenPGP keys do not allow a rollback by design.  For documentation
> writing a (sorted) key listing to a file might thus be more useful than
> plain text files.

I don't use git to be able to roll back, but rather to know at which
state a backup is.  For example, I gave a backup to a family member last
time I saw him, and I know that backup is N commits behind my current
keyring.

> 
> 
> 
> Shalom-Salam,
> 
>    Werner

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240913/bd095a52/attachment.sig>

From tmz at pobox.com  Sat Sep 14 00:56:18 2024
From: tmz at pobox.com (Todd Zullinger)
Date: Fri, 13 Sep 2024 18:56:18 -0400
Subject: Text (non-binary) keyring format
In-Reply-To: <mrko6hqnsfcplkv7scrx5nsj3kxbce3a44gxrgesvqfjffunwm@p2ebxurrfqcm>
References: <eiecwibyxdcdzxnc5ywsxa35akdcppomgzkelx5ipyom2iesed@wsjm2kgisgbt>
 <87seu37pgj.fsf@jacob.g10code.de>
 <mrko6hqnsfcplkv7scrx5nsj3kxbce3a44gxrgesvqfjffunwm@p2ebxurrfqcm>
Message-ID: <ZuTDEgh-hyLbWybU@teonanacatl.net>

Alejandro Colomar via Gnupg-users wrote:
> I don't use git to be able to roll back, but rather to know at which
> state a backup is.  For example, I gave a backup to a family member last
> time I saw him, and I know that backup is N commits behind my current
> keyring.

As a random idea (which you may have already had), you could
include the output of a keyring listing along with the
commit.

Putting that data in git notes is an option if you don't
want the commit message to be too large.  While that doesn't
improve the diff between things, it does make it easier to
know the state of the keyring at each commit.

For diffing, you could also use a script to dump the keyring
(via git show or whatever) and pipe it to gpg to list.  That
could make comparing the revisions a little easier.

I've thought about doing some similar to track a collection
of binary music files -- but have never gotten around to
doing it. :)

-- 
Todd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240913/380e4035/attachment.sig>

From ralph at ml.seichter.de  Sat Sep 14 01:20:37 2024
From: ralph at ml.seichter.de (Ralph Seichter)
Date: Sat, 14 Sep 2024 01:20:37 +0200
Subject: Text (non-binary) keyring format
In-Reply-To: <mrko6hqnsfcplkv7scrx5nsj3kxbce3a44gxrgesvqfjffunwm@p2ebxurrfqcm>
References: <eiecwibyxdcdzxnc5ywsxa35akdcppomgzkelx5ipyom2iesed@wsjm2kgisgbt>
 <87seu37pgj.fsf@jacob.g10code.de>
 <mrko6hqnsfcplkv7scrx5nsj3kxbce3a44gxrgesvqfjffunwm@p2ebxurrfqcm>
Message-ID: <87jzffqgxm.fsf@ra.horus-it.com>

* Alejandro Colomar via Gnupg-users:

> I don't use git to be able to roll back, but rather to know at which
> state a backup is.  For example, I gave a backup to a family member last
> time I saw him, and I know that backup is N commits behind my current
> keyring.

Looks like none of this depends on the keyring being stored in a binary
or textual format, does it? Even knowing only the date of having passed
on a backup would be enough to figure out the commits made after handing
over the backup. Then there are commit comments, tags, branchs... Maybe
think of the process of creating and handing over a backup like a
software release?

In any case, as far as I am concerned, the increased performance of
using a binary keyring in daily GnuPG use far outweighs any perceived
convenience of a text-based format, especially when that text-based
format can be easily generated using the "gpg" binary. Note that I am
saying that as a true fan of text-based formats myself.

-Ralph


From dkg at fifthhorseman.net  Tue Sep 10 19:40:45 2024
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 10 Sep 2024 13:40:45 -0400
Subject: [admin] This is a GnuPG related ML
In-Reply-To: <877cblas2k.fsf_-_@jacob.g10code.de>
References: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com>
 <87wmjlv679.fsf@fifthhorseman.net> <877cblas2k.fsf_-_@jacob.g10code.de>
Message-ID: <87jzfjl84i.fsf@fifthhorseman.net>

On Mon 2024-09-09 15:13:07 +0200, Werner Koch via Gnupg-users wrote:
> Advertisement for other applications, like a Python wrapper around a
> long standing command line API (going all the way back to pgp 2), is
> thus off-topic.

Jakob specifically asked how he could use GnuPG while relying on the
return code.  I pointed to some tooling that is designed to do that
specifically, not to avoid the use of GnuPG.

In particular, the command line API for GnuPG tools is itself quite
idiosyncratic, as "long standing" CLIs tend to be.

> It feels more like a SEO strategy than as helpful information.  Please
> don't confuse users; search engines already deliver too much
> misinformation on best gpg practices.

I agree that there is a lot of misinformation in the wild about how to
"best" use gpg.  I think if the GnuPG interface lent itself to the type
of straightforward system integration like Jakob was asking for, there
would probably be fewer workarounds, not-quite-complete shell scripts,
or ambitious-yet-flawed guidance floating around about the project.

Tooling that deliberately transforms GnuPG's idiosyncratic interface
into a simpler, easier-to-integrate DWIM syntax/semantics is intended as
a contribution to the GnuPG project, so that people who want to rely on
GnuPG can do so safely.

Sorry if it didn't read that way from the outset.

All the best,

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 324 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240910/e84e5dfc/attachment.sig>

From jb-gnumlists at wisemo.com  Mon Sep 16 12:47:35 2024
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Mon, 16 Sep 2024 12:47:35 +0200
Subject: [Feature request] Please make it easier to check success/failure
 from scripts
In-Reply-To: <87ed5n62f7.fsf@jacob.g10code.de>
References: <4a38f4e8-783e-4bf0-8e2d-20558291bb84@wisemo.com>
 <87ed5n62f7.fsf@jacob.g10code.de>
Message-ID: <72ed0b77-c138-6f24-7f1d-9d0c0c31bf65@wisemo.com>

On 2024-09-13 16:42, Werner Koch wrote:
> Hi!
> 
> GnuPG 2.5.1 has the option --assert-signer and 2.4.6 will have this
> option as well:
> 
>     --assert-signer fpr_or_file
>     
>       This option checks whether at least one valid signature on a file
>       has been made with the specified key.  The key is either specified
>       as a fingerprint or a file listing fingerprints.  The fingerprint
>       must be given or listed in compact format (no colons or spaces in
>       between).  As of now only SHA-1 fingerprints are allowed.  This
>       option can be given multiple times and each fingerprint is checked
>       against the sign? ing key as well as the corresponding primary key.
>       If fpr_or_file specifies a file, empty lines are ignored as well as
>       all lines start? ing with a hash sign.  With this option gpgsm is
>       guaranteed to return with an exit code of 0 if and only if a
>       signature has been encoun? tered, is valid, and the key matches one
>       of the fingerprints given by this option.
> 
> 
> Tarcked as https://dev.gnupg.org/T7286
> 
> Hope that helps a bit.
> 
> 

This is a very partial solution, and only for bleeding edge Gnupg .  It
might be usable when combined with scripting that identifies the hash of
the DER certificate expected, but still at the (security, stability and
performance) cost of still invoking ?gyptian bureaucracy of GPG specific
versions of the overall X.509 infrastructure in the OS (typically based
on derivatives of old SSLeay code or Microsoft CryptoAPI 1.x) .


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From jb-gnumlists at wisemo.com  Mon Sep 16 14:06:03 2024
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Mon, 16 Sep 2024 14:06:03 +0200
Subject: Text (non-binary) keyring format
In-Reply-To: <87seu37pgj.fsf@jacob.g10code.de>
References: <eiecwibyxdcdzxnc5ywsxa35akdcppomgzkelx5ipyom2iesed@wsjm2kgisgbt>
 <87seu37pgj.fsf@jacob.g10code.de>
Message-ID: <4dce2525-8e92-e628-c1c9-4be2446adaf4@wisemo.com>

On 2024-09-13 13:39, Werner Koch via Gnupg-users wrote:
> Hi!
>
> On Thu, 12 Sep 2024 13:28, Alejandro Colomar said:
>
>> I have my ~/.gnupg keyring under git source control, which helps
>> creating and updating backups, and also having a history of the changes.
> We actually moved to an SQL database to speed up things.  If you have
> hundreds of keys with thousands of key signatures it is very helpful to
> have indices; it really speeds up things.
This isn't the first time GnuPG prematurely optimized pubring access.

Years ago, I noticed that the certificate validation cache prematurely
optimized when the problem was a linear search of the pubring itself,
not the cryptographic validation.? Obvious solution at the time would
have been to keep a hash table of file offsets for key fingerprints .

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From wk at gnupg.org  Tue Sep 17 10:21:27 2024
From: wk at gnupg.org (Werner Koch)
Date: Tue, 17 Sep 2024 10:21:27 +0200
Subject: Text (non-binary) keyring format
In-Reply-To: <4dce2525-8e92-e628-c1c9-4be2446adaf4@wisemo.com> (Jakob Bohm via
 Gnupg-users's message of "Mon, 16 Sep 2024 14:06:03 +0200")
References: <eiecwibyxdcdzxnc5ywsxa35akdcppomgzkelx5ipyom2iesed@wsjm2kgisgbt>
 <87seu37pgj.fsf@jacob.g10code.de>
 <4dce2525-8e92-e628-c1c9-4be2446adaf4@wisemo.com>
Message-ID: <8734ly4rnc.fsf@jacob.g10code.de>

On Mon, 16 Sep 2024 14:06, Jakob Bohm said:

> not the cryptographic validation.? Obvious solution at the time would
> have been to keep a hash table of file offsets for key fingerprints .

Which conflicted with the demand for having several keyring; actually we
once had experimental support for a hash table.  But because some sites
insisted on using several keyrings this did not worked very well.

With the keyboxd we finally started to drop support for several
keyrings.  Due to the ubiquity and maturity of SQLite keyboxd does not
anymore use a custom database but relies on SQLite.



Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240917/7853410c/attachment.sig>

From nils.schween at mpi-hd.mpg.de  Tue Sep 17 21:49:55 2024
From: nils.schween at mpi-hd.mpg.de (Nils Schween)
Date: Tue, 17 Sep 2024 21:49:55 +0200
Subject: Error: Bad length of salt (32) for AES when importing a p12
 certificate
Message-ID: <87msk6ukkc.fsf@mpi-hd.mpg.de>

Dear gpg community,

I had difficulties to import a p12 certificiate with gpgsm --import
cert.p12

I got the following error message:

gpgsm: bad length of salt (32) for AES
gpgsm: parse_shrouded_key_bag(shrouded_key_bag.pkcs5PBES2-params): lvl=16 (tlv_expect_octet_string): Success - Invalid length
gpgsm: parse_bag_data(data.oid): lvl=16 (tlv_expect_octet_string): Success - Invalid length
gpgsm: p12_parse(bag.data): @6724 lvl=16 tlv_expect_octet_string: Success - Invalid length
gpgsm: error parsing or decrypting the PKCS#12 file
gpgsm: total number processed: 4
gpgsm:              unchanged: 4


I searched the internet and I found the following bug report

https://dev.gnupg.org/T6757#182217

I checked with the lenght of the salt in my certificate with the command
command

openssl pkcs12 -info -nokeys -noout -in smime_eyJpZCI6MzYzNTkwMSwidHlwZSI6IlNNSU1FIn0_.p12

The output was

MAC: sha256, Iteration 20000
MAC length: 32, salt length: 64

In agreement with the error message and along the lines of the mentioned
bug report I changed the following lines in the sm/minip12.c :

static int
parse_bag_encrypted_data (struct p12_parse_ctx_s *ctx, tlv_parser_t tlv)
{
  gpg_error_t err = 0;
  const char *where;
  const unsigned char *oid;
  size_t oidlen;
  const unsigned char *data;
  size_t datalen;
  int intval;
-  char salt[32];
+  char salt[64];
 
static gpg_error_t
parse_shrouded_key_bag (struct p12_parse_ctx_s *ctx, tlv_parser_t tlv)
{
  gpg_error_t err = 0;
  const char *where;
  const unsigned char *oid;
  size_t oidlen;
  const unsigned char *data;
  size_t datalen;
  int intval;
-  char salt[20];  
+  char salt[64];
...

After recompiling I could import the certificate without issues. I do
not know if I did something risky from the security perspective and I am
sorry for not reporting it directly in bug tracker, but I do not have an
account there.

Please let me, if this change is going to make into one of the next
versions of gpg.

Best regards,
Nils Schween
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5989 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240917/5782906c/attachment-0001.bin>

From nils.schween at mpi-hd.mpg.de  Tue Sep 17 21:45:36 2024
From: nils.schween at mpi-hd.mpg.de (Nils Schween)
Date: Tue, 17 Sep 2024 21:45:36 +0200
Subject: Bad salt length AES
Message-ID: <87tteeukrj.fsf@mpi-hd.mpg.de>


Dear gpg community,

I had difficulties to import a p12 certificiate with gpgsm --import
cert.p12

I got the following error message:

gpgsm: bad length of salt (32) for AES
gpgsm: parse_shrouded_key_bag(shrouded_key_bag.pkcs5PBES2-params): lvl=16 (tlv_expect_octet_string): Success - Invalid length
gpgsm: parse_bag_data(data.oid): lvl=16 (tlv_expect_octet_string): Success - Invalid length
gpgsm: p12_parse(bag.data): @6724 lvl=16 tlv_expect_octet_string: Success - Invalid length
gpgsm: error parsing or decrypting the PKCS#12 file
gpgsm: total number processed: 4
gpgsm:              unchanged: 4


I searched the internet and I found the following bug report

https://dev.gnupg.org/T6757#182217

I checked with the lenght of the salt in my certificate with the command
command

openssl pkcs12 -info -nokeys -noout -in smime_eyJpZCI6MzYzNTkwMSwidHlwZSI6IlNNSU1FIn0_.p12

The output was

MAC: sha256, Iteration 20000
MAC length: 32, salt length: 64

In agreement with the error message and along the lines of the mentioned
bug report I changed the following lines in the sm/minip12.c :

static int
parse_bag_encrypted_data (struct p12_parse_ctx_s *ctx, tlv_parser_t tlv)
{
  gpg_error_t err = 0;
  const char *where;
  const unsigned char *oid;
  size_t oidlen;
  const unsigned char *data;
  size_t datalen;
  int intval;
-  char salt[32];
+  char salt[64];
 
static gpg_error_t
parse_shrouded_key_bag (struct p12_parse_ctx_s *ctx, tlv_parser_t tlv)
{
  gpg_error_t err = 0;
  const char *where;
  const unsigned char *oid;
  size_t oidlen;
  const unsigned char *data;
  size_t datalen;
  int intval;
-  char salt[20];  
+  char salt[64];
...

After recompiling I could import the certificate without issues. I do
not know if I did something risky from the security perspective and I am
sorry for not reporting it directly in bug tracker, but I do not have an
account there.

Please let me, if this change is going to make into one of the next
versions of gpg.

Best regards,
Nils Schween
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5989 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240917/47783a30/attachment.bin>

From nils.schween at mpi-hd.mpg.de  Thu Sep 19 09:07:11 2024
From: nils.schween at mpi-hd.mpg.de (Nils Schween)
Date: Thu, 19 Sep 2024 09:07:11 +0200
Subject: Error: Bad length of salt (32) for AES when importing a p12
 certificate
In-Reply-To: <87msk6ukkc.fsf@mpi-hd.mpg.de> (Nils Schween's message of "Tue,
 17 Sep 2024 21:49:55 +0200")
References: <87msk6ukkc.fsf@mpi-hd.mpg.de>
Message-ID: <87jzf8rujk.fsf@mpi-hd.mpg.de>

A short follow up: I did some more tests and I found that the change of
the length of the salt array in the function 'parse_shrouded_key_bag'
suffices to import the certificate. It is actually enough to increase
the value from 20 to 32. Here is the git diff of my change of minip12.c
(version 2.5.1 )

diff --git a/minip12.c-original b/minip12.c
index 028be91..00ba26d 100644
--- a/minip12.c-original
+++ b/minip12.c
@@ -1248,7 +1248,7 @@ parse_shrouded_key_bag (struct p12_parse_ctx_s *ctx, tlv_parser_t tlv)
   const unsigned char *data;
   size_t datalen;
   int intval;
-  char salt[20];
+  char salt[32];
   size_t saltlen;
   char iv[16];
   unsigned int iter;

Regards,
Nils

Nils Schween <nils.schween at mpi-hd.mpg.de> writes:

> Dear gpg community,
>
> I had difficulties to import a p12 certificiate with gpgsm --import
> cert.p12
>
> I got the following error message:
>
> gpgsm: bad length of salt (32) for AES
> gpgsm: parse_shrouded_key_bag(shrouded_key_bag.pkcs5PBES2-params): lvl=16 (tlv_expect_octet_string): Success - Invalid length
> gpgsm: parse_bag_data(data.oid): lvl=16 (tlv_expect_octet_string): Success - Invalid length
> gpgsm: p12_parse(bag.data): @6724 lvl=16 tlv_expect_octet_string: Success - Invalid length
> gpgsm: error parsing or decrypting the PKCS#12 file
> gpgsm: total number processed: 4
> gpgsm:              unchanged: 4
>
>
> I searched the internet and I found the following bug report
>
> https://dev.gnupg.org/T6757#182217
>
> I checked with the lenght of the salt in my certificate with the command
> command
>
> openssl pkcs12 -info -nokeys -noout -in smime_eyJpZCI6MzYzNTkwMSwidHlwZSI6IlNNSU1FIn0_.p12
>
> The output was
>
> MAC: sha256, Iteration 20000
> MAC length: 32, salt length: 64
>
> In agreement with the error message and along the lines of the mentioned
> bug report I changed the following lines in the sm/minip12.c :
>
> static int
> parse_bag_encrypted_data (struct p12_parse_ctx_s *ctx, tlv_parser_t tlv)
> {
>   gpg_error_t err = 0;
>   const char *where;
>   const unsigned char *oid;
>   size_t oidlen;
>   const unsigned char *data;
>   size_t datalen;
>   int intval;
> -  char salt[32];
> +  char salt[64];
>  
> static gpg_error_t
> parse_shrouded_key_bag (struct p12_parse_ctx_s *ctx, tlv_parser_t tlv)
> {
>   gpg_error_t err = 0;
>   const char *where;
>   const unsigned char *oid;
>   size_t oidlen;
>   const unsigned char *data;
>   size_t datalen;
>   int intval;
> -  char salt[20];  
> +  char salt[64];
> ...
>
> After recompiling I could import the certificate without issues. I do
> not know if I did something risky from the security perspective and I am
> sorry for not reporting it directly in bug tracker, but I do not have an
> account there.
>
> Please let me, if this change is going to make into one of the next
> versions of gpg.
>
> Best regards,
> Nils Schween
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users

-- 
Nils Schween
PhD Student

Phone: +49 6221 516 557
Mail: nils.schween at mpi-hd.mpg.de
PGP-Key: 4DD3DCC0532EE96DB0C1F8B5368DBFA14CB81849

Max Planck Institute for Nuclear Physics
Astrophysical Plasma Theory (APT)
Saupfercheckweg 1, D-69117 Heidelberg
https://www.mpi-hd.mpg.de/mpi/en/research/scientific-divisions-and-groups/independent-research-groups/apt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5989 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240919/91fc474e/attachment.bin>

From wk at gnupg.org  Thu Sep 19 11:29:31 2024
From: wk at gnupg.org (Werner Koch)
Date: Thu, 19 Sep 2024 11:29:31 +0200
Subject: Error: Bad length of salt (32) for AES when importing a p12
 certificate
In-Reply-To: <87jzf8rujk.fsf@mpi-hd.mpg.de> (Nils Schween's message of "Thu,
 19 Sep 2024 09:07:11 +0200")
References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de>
Message-ID: <875xqs2dqc.fsf@jacob.g10code.de>

On Thu, 19 Sep 2024 09:07, Nils Schween said:
> A short follow up: I did some more tests and I found that the change of
> the length of the salt array in the function 'parse_shrouded_key_bag'
> suffices to import the certificate. It is actually enough to increase
> the value from 20 to 32. Here is the git diff of my change of minip12.c

Thanks for looking into this.

Do have have a sample P12 file we can put into our regression tests?  In
case you don't want to see that in a public repo we also have an
internal collection of p12 files, in this case mail it to me privately -
of course only if that is test data and not real key material.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240919/e58d425d/attachment.sig>

From nils.schween at mpi-hd.mpg.de  Thu Sep 19 13:42:29 2024
From: nils.schween at mpi-hd.mpg.de (Nils Schween)
Date: Thu, 19 Sep 2024 13:42:29 +0200
Subject: Error: Bad length of salt (32) for AES when importing a p12
 certificate
In-Reply-To: <875xqs2dqc.fsf@jacob.g10code.de> (Werner Koch's message of "Thu, 
 19 Sep 2024 11:29:31 +0200")
References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de>
 <875xqs2dqc.fsf@jacob.g10code.de>
Message-ID: <877cb7swd6.fsf@mpi-hd.mpg.de>


Thanks for replying.

> Do have have a sample P12 file we can put into our regression tests?

I asked our IT department and unfortunately it is not allowed to issue
test certificates with dummy email addresses.

If it is necessary, I can try to create a certificate with openssl, that
reproduces the error.

Greetings,
Nils

Werner Koch <wk at gnupg.org> writes:

> On Thu, 19 Sep 2024 09:07, Nils Schween said:
>> A short follow up: I did some more tests and I found that the change of
>> the length of the salt array in the function 'parse_shrouded_key_bag'
>> suffices to import the certificate. It is actually enough to increase
>> the value from 20 to 32. Here is the git diff of my change of minip12.c
>
> Thanks for looking into this.
>
> Do have have a sample P12 file we can put into our regression tests?  In
> case you don't want to see that in a public repo we also have an
> internal collection of p12 files, in this case mail it to me privately -
> of course only if that is test data and not real key material.
>
>
> Salam-Shalom,
>
>    Werner

-- 
Nils Schween
PhD Student

Phone: +49 6221 516 557
Mail: nils.schween at mpi-hd.mpg.de
PGP-Key: 4DD3DCC0532EE96DB0C1F8B5368DBFA14CB81849

Max Planck Institute for Nuclear Physics
Astrophysical Plasma Theory (APT)
Saupfercheckweg 1, D-69117 Heidelberg
https://www.mpi-hd.mpg.de/mpi/en/research/scientific-divisions-and-groups/independent-research-groups/apt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5989 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240919/f4b43060/attachment-0001.bin>

From wk at gnupg.org  Thu Sep 19 15:02:17 2024
From: wk at gnupg.org (Werner Koch)
Date: Thu, 19 Sep 2024 15:02:17 +0200
Subject: Error: Bad length of salt (32) for AES when importing a p12
 certificate
In-Reply-To: <877cb7swd6.fsf@mpi-hd.mpg.de> (Nils Schween's message of "Thu,
 19 Sep 2024 13:42:29 +0200")
References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de>
 <875xqs2dqc.fsf@jacob.g10code.de> <877cb7swd6.fsf@mpi-hd.mpg.de>
Message-ID: <87setv23vq.fsf@jacob.g10code.de>

On Thu, 19 Sep 2024 13:42, Nils Schween said:

> If it is necessary, I can try to create a certificate with openssl, that
> reproduces the error.

Given the brittleness of pkcs#12/minip12.c I would really appricate to
have a sample file.  But the worst thing which could happen is that the
64 bit salt does not work anymore in the future.  It is unlikey, though.

Please give me some days to apply the patch.


Salam-Shalom,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240919/95f6c4d0/attachment.sig>

From nils.schween at mpi-hd.mpg.de  Fri Sep 20 12:02:09 2024
From: nils.schween at mpi-hd.mpg.de (Nils Schween)
Date: Fri, 20 Sep 2024 12:02:09 +0200
Subject: Error: Bad length of salt (32) for AES when importing a p12
 certificate
In-Reply-To: <87setv23vq.fsf@jacob.g10code.de> (Werner Koch's message of "Thu, 
 19 Sep 2024 15:02:17 +0200")
References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de>
 <875xqs2dqc.fsf@jacob.g10code.de> <877cb7swd6.fsf@mpi-hd.mpg.de>
 <87setv23vq.fsf@jacob.g10code.de>
Message-ID: <878qvmzlr2.fsf@mpi-hd.mpg.de>


> Given the brittleness of pkcs#12/minip12.c I would really appricate to
> have a sample file.  But the worst thing which could happen is that the
> 64 bit salt does not work anymore in the future.  It is unlikey, though.

I do understand. I tried to create one this morning, but I was not able
to reproduce the error when importing my self created certificate.

I used the following commands to create the certificate:

openssl req -newkey rsa:4096 -nodes -keyout key.pem -x509 -sha384 -days 365 -out certificate.pem

openssl pkcs12 -inkey key.pem -in certificate.pem -export -macsaltlen 64 -iter 20000 -out certificate.p12 

To compare my own certificate with the one issued by the certificate
provider I used the following two commands:

openssl pkcs12 -in certificate.p12 -noout -info
openssl x509 -text -noout -in certificate.p12

I could not find any significant difference in the output. Though the
one from the certificate provider causes the error when imported with
gpgsm while my own certificate does not.

Since I am not very knowledgeable when it comes to S/MIME certificates,
it is riddle to me why the error appears: My certificate and the one
from the provider have a salt length of 64bit and that was the only
thing I changed in minip12.c

So, I have to say that I am sorry, I cannot reproduce the error with a
self-created certificate.

> Please give me some days to apply the patch.

No hurry, for now I have a personal work around.

Thank you,
Nils

Werner Koch <wk at gnupg.org> writes:

> On Thu, 19 Sep 2024 13:42, Nils Schween said:
>
>> If it is necessary, I can try to create a certificate with openssl, that
>> reproduces the error.
>
> Given the brittleness of pkcs#12/minip12.c I would really appricate to
> have a sample file.  But the worst thing which could happen is that the
> 64 bit salt does not work anymore in the future.  It is unlikey, though.
>
> Please give me some days to apply the patch.
>
>
> Salam-Shalom,
>
>    Werner

-- 
Nils Schween
PhD Student

Phone: +49 6221 516 557
Mail: nils.schween at mpi-hd.mpg.de
PGP-Key: 4DD3DCC0532EE96DB0C1F8B5368DBFA14CB81849

Max Planck Institute for Nuclear Physics
Astrophysical Plasma Theory (APT)
Saupfercheckweg 1, D-69117 Heidelberg
https://www.mpi-hd.mpg.de/mpi/en/research/scientific-divisions-and-groups/independent-research-groups/apt


From jb-gnumlists at wisemo.com  Fri Sep 20 17:13:56 2024
From: jb-gnumlists at wisemo.com (Jakob Bohm)
Date: Fri, 20 Sep 2024 17:13:56 +0200
Subject: Error: Bad length of salt (32) for AES when importing a p12
 certificate
In-Reply-To: <878qvmzlr2.fsf@mpi-hd.mpg.de>
References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de>
 <875xqs2dqc.fsf@jacob.g10code.de> <877cb7swd6.fsf@mpi-hd.mpg.de>
 <87setv23vq.fsf@jacob.g10code.de> <878qvmzlr2.fsf@mpi-hd.mpg.de>
Message-ID: <d1732ceb-9765-abb4-b114-de362ea9330e@wisemo.com>

Dear Nils,

Given the error message in the subject line above, the step to reproduce 
may be to pass 32 instead of 64 to the openssl command that makes the 
test certificate.

Otherwise, look for a command that can dump out the formatting details 
of the (non-distributable) problematic pkcs12 file to see what values it 
actually uses.

On 2024-09-20 12:02, Nils Schween wrote:
>> Given the brittleness of pkcs#12/minip12.c I would really appricate to
>> have a sample file.  But the worst thing which could happen is that the
>> 64 bit salt does not work anymore in the future.  It is unlikey, though.
> I do understand. I tried to create one this morning, but I was not able
> to reproduce the error when importing my self created certificate.
>
> I used the following commands to create the certificate:
>
> openssl req -newkey rsa:4096 -nodes -keyout key.pem -x509 -sha384 -days 365 -out certificate.pem
>
> openssl pkcs12 -inkey key.pem -in certificate.pem -export -macsaltlen 64 -iter 20000 -out certificate.p12
>
> To compare my own certificate with the one issued by the certificate
> provider I used the following two commands:
>
> openssl pkcs12 -in certificate.p12 -noout -info
> openssl x509 -text -noout -in certificate.p12
>
> I could not find any significant difference in the output. Though the
> one from the certificate provider causes the error when imported with
> gpgsm while my own certificate does not.
>
> Since I am not very knowledgeable when it comes to S/MIME certificates,
> it is riddle to me why the error appears: My certificate and the one
> from the provider have a salt length of 64bit and that was the only
> thing I changed in minip12.c
>
> So, I have to say that I am sorry, I cannot reproduce the error with a
> self-created certificate.
>
>> Please give me some days to apply the patch.
> No hurry, for now I have a personal work around.
>
> Thank you,
> Nils
>
> Werner Koch <wk at gnupg.org> writes:
>
>> On Thu, 19 Sep 2024 13:42, Nils Schween said:
>>
>>> If it is necessary, I can try to create a certificate with openssl, that
>>> reproduces the error.
>> Given the brittleness of pkcs#12/minip12.c I would really appricate to
>> have a sample file.  But the worst thing which could happen is that the
>> 64 bit salt does not work anymore in the future.  It is unlikey, though.
>>
>> Please give me some days to apply the patch.
>>
>>
>> Salam-Shalom,
>>
>>     Werner

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



From nils.schween at mpi-hd.mpg.de  Fri Sep 20 22:33:36 2024
From: nils.schween at mpi-hd.mpg.de (Nils Schween)
Date: Fri, 20 Sep 2024 22:33:36 +0200
Subject: Error: Bad length of salt (32) for AES when importing a p12
 certificate
In-Reply-To: <d1732ceb-9765-abb4-b114-de362ea9330e@wisemo.com> (Jakob Bohm via
 Gnupg-users's message of "Fri, 20 Sep 2024 17:13:56 +0200")
References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de>
 <875xqs2dqc.fsf@jacob.g10code.de> <877cb7swd6.fsf@mpi-hd.mpg.de>
 <87setv23vq.fsf@jacob.g10code.de> <878qvmzlr2.fsf@mpi-hd.mpg.de>
 <d1732ceb-9765-abb4-b114-de362ea9330e@wisemo.com>
Message-ID: <87cykycbfj.fsf@mpi-hd.mpg.de>


Thanks for joining the discussion. I changed the value of the salt length
to 32. That did not change anything. However, I tried to get some more
information. I used gpsm -vv --import for both certificates and a
difference appeared:

When I am importing the self-created certificate the import process is
skipping shrouded_key_bag.attribute_set when reaching the private key.
Here the output:

gpgsm: enabled compatibility flags:
gpgsm: processing bag.encryptedData
gpgsm: 1536 bytes of AES256 encrypted text
gpgsm: processing certBag
gpgsm: certificate already in DB
gpgsm: skipping bag.attribute_set
gpgsm: processing bag data
gpgsm: processing shrouded_key_bag
gpgsm: 2384 bytes of AES256 encrypted text
gpgsm: skipping shrouded_key_bag.attribute_set

Whereas the import of the (non-distributable) certificate yields

gpgsm: bad length of salt (32) for AES
gpgsm: parse_shrouded_key_bag(shrouded_key_bag.pkcs5PBES2-params): lvl=16 (tlv_expect_octet_string): Erfolg - Ung?ltige L?nge
gpgsm: parse_bag_data(data.oid): lvl=16 (tlv_expect_octet_string): Erfolg - Ung?ltige L?nge
gpgsm: p12_parse(bag.data): @6724 lvl=16 tlv_expect_octet_string: Erfolg - Ung?ltige L?nge
gpgsm: error parsing or decrypting the PKCS#12 file

The import is not skipping shrouded_key_bag.attribute_set.

That the error goes away when I change the salt array length in
parse_shrouded_key_bag, makes from sense from this perspective.

Unfortunately, I do not know how I can change my self-created certificate
such that the gpgsm --import command does not skip the shrouded_key_bag
attribute when importing the private key. Do you have any idea what
options I need to set when creating the key or the p12 file to set the
shrouded_key_bag attribute? 

Thank you.
Nils

Jakob Bohm via Gnupg-users <gnupg-users at gnupg.org> writes:

> Dear Nils,
>
> Given the error message in the subject line above, the step to reproduce may be
> to pass 32 instead of 64 to the openssl command that makes the test certificate.
>
> Otherwise, look for a command that can dump out the formatting details of the
> (non-distributable) problematic pkcs12 file to see what values it actually uses.
>
> On 2024-09-20 12:02, Nils Schween wrote:
>>> Given the brittleness of pkcs#12/minip12.c I would really appricate to
>>> have a sample file.  But the worst thing which could happen is that the
>>> 64 bit salt does not work anymore in the future.  It is unlikey, though.
>> I do understand. I tried to create one this morning, but I was not able
>> to reproduce the error when importing my self created certificate.
>>
>> I used the following commands to create the certificate:
>>
>> openssl req -newkey rsa:4096 -nodes -keyout key.pem -x509 -sha384 -days 365 -out certificate.pem
>>
>> openssl pkcs12 -inkey key.pem -in certificate.pem -export -macsaltlen 64 -iter 20000 -out certificate.p12
>>
>> To compare my own certificate with the one issued by the certificate
>> provider I used the following two commands:
>>
>> openssl pkcs12 -in certificate.p12 -noout -info
>> openssl x509 -text -noout -in certificate.p12
>>
>> I could not find any significant difference in the output. Though the
>> one from the certificate provider causes the error when imported with
>> gpgsm while my own certificate does not.
>>
>> Since I am not very knowledgeable when it comes to S/MIME certificates,
>> it is riddle to me why the error appears: My certificate and the one
>> from the provider have a salt length of 64bit and that was the only
>> thing I changed in minip12.c
>>
>> So, I have to say that I am sorry, I cannot reproduce the error with a
>> self-created certificate.
>>
>>> Please give me some days to apply the patch.
>> No hurry, for now I have a personal work around.
>>
>> Thank you,
>> Nils
>>
>> Werner Koch <wk at gnupg.org> writes:
>>
>>> On Thu, 19 Sep 2024 13:42, Nils Schween said:
>>>
>>>> If it is necessary, I can try to create a certificate with openssl, that
>>>> reproduces the error.
>>> Given the brittleness of pkcs#12/minip12.c I would really appricate to
>>> have a sample file.  But the worst thing which could happen is that the
>>> 64 bit salt does not work anymore in the future.  It is unlikey, though.
>>>
>>> Please give me some days to apply the patch.
>>>
>>>
>>> Salam-Shalom,
>>>
>>>     Werner
>
> Enjoy
>
> Jakob

-- 
Nils Schween
PhD Student

Phone: +49 6221 516 557
Mail: nils.schween at mpi-hd.mpg.de
PGP-Key: 4DD3DCC0532EE96DB0C1F8B5368DBFA14CB81849

Max Planck Institute for Nuclear Physics
Astrophysical Plasma Theory (APT)
Saupfercheckweg 1, D-69117 Heidelberg
https://www.mpi-hd.mpg.de/mpi/en/research/scientific-divisions-and-groups/independent-research-groups/apt


From nils.schween at mpi-hd.mpg.de  Sat Sep 21 14:50:33 2024
From: nils.schween at mpi-hd.mpg.de (Nils Schween)
Date: Sat, 21 Sep 2024 14:50:33 +0200
Subject: Error: Bad length of salt (32) for AES when importing a p12
 certificate
In-Reply-To: <87cykycbfj.fsf@mpi-hd.mpg.de> (Nils Schween's message of "Fri,
 20 Sep 2024 22:33:36 +0200")
References: <87msk6ukkc.fsf@mpi-hd.mpg.de> <87jzf8rujk.fsf@mpi-hd.mpg.de>
 <875xqs2dqc.fsf@jacob.g10code.de> <877cb7swd6.fsf@mpi-hd.mpg.de>
 <87setv23vq.fsf@jacob.g10code.de> <878qvmzlr2.fsf@mpi-hd.mpg.de>
 <d1732ceb-9765-abb4-b114-de362ea9330e@wisemo.com>
 <87cykycbfj.fsf@mpi-hd.mpg.de>
Message-ID: <87bk0hjhly.fsf@mpi-hd.mpg.de>

I just did some more tests. I noticed that if I export the private key
and the certificates contained in the (non-distributable) p12 file with
the following commands

openssl pkcs12 -nokeys -in client.p12 > certs.pem
openssl pkcs12 -nocerts -in client.p12 > keys.pem

and then create an new p12 file with

openssl pkcs12 -in certs.pem -inkey keys.pem -export -out client_new.p12

I can import it without any issues using gpgsm --import

To investigate what the difference between the newly created p12 file
and the old one is I diffed the output of

openssl pkcs12 -in old.p12 -nodes -info
and
openssl pkcs12 -in new.p12 -nodes -info

The result is the following

47c47
< Bag Attributes: <Empty Attributes>
---
> Bag Attributes: <No Attributes>
89c89
< Bag Attributes: <Empty Attributes>
---
> Bag Attributes: <No Attributes>
124c124
< Bag Attributes: <Empty Attributes>
---
> Bag Attributes: <No Attributes>

This means that in the old p12 file the string "Empty Attributes" is
used to indicate that there are no attributes, whereas in the newly
created p12 file they use "No Attributes"

I do not know how gpgsm checks if there are additional attributes. May this
observation also hints into the direction of the error. 

Regards,
Nils

Nils Schween <nils.schween at mpi-hd.mpg.de> writes:

> Thanks for joining the discussion. I changed the value of the salt length
> to 32. That did not change anything. However, I tried to get some more
> information. I used gpsm -vv --import for both certificates and a
> difference appeared:
>
> When I am importing the self-created certificate the import process is
> skipping shrouded_key_bag.attribute_set when reaching the private key.
> Here the output:
>
> gpgsm: enabled compatibility flags:
> gpgsm: processing bag.encryptedData
> gpgsm: 1536 bytes of AES256 encrypted text
> gpgsm: processing certBag
> gpgsm: certificate already in DB
> gpgsm: skipping bag.attribute_set
> gpgsm: processing bag data
> gpgsm: processing shrouded_key_bag
> gpgsm: 2384 bytes of AES256 encrypted text
> gpgsm: skipping shrouded_key_bag.attribute_set
>
> Whereas the import of the (non-distributable) certificate yields
>
> gpgsm: bad length of salt (32) for AES
> gpgsm: parse_shrouded_key_bag(shrouded_key_bag.pkcs5PBES2-params): lvl=16 (tlv_expect_octet_string): Erfolg - Ung?ltige L?nge
> gpgsm: parse_bag_data(data.oid): lvl=16 (tlv_expect_octet_string): Erfolg - Ung?ltige L?nge
> gpgsm: p12_parse(bag.data): @6724 lvl=16 tlv_expect_octet_string: Erfolg - Ung?ltige L?nge
> gpgsm: error parsing or decrypting the PKCS#12 file
>
> The import is not skipping shrouded_key_bag.attribute_set.
>
> That the error goes away when I change the salt array length in
> parse_shrouded_key_bag, makes from sense from this perspective.
>
> Unfortunately, I do not know how I can change my self-created certificate
> such that the gpgsm --import command does not skip the shrouded_key_bag
> attribute when importing the private key. Do you have any idea what
> options I need to set when creating the key or the p12 file to set the
> shrouded_key_bag attribute? 
>
> Thank you.
> Nils
>
> Jakob Bohm via Gnupg-users <gnupg-users at gnupg.org> writes:
>
>> Dear Nils,
>>
>> Given the error message in the subject line above, the step to reproduce may be
>> to pass 32 instead of 64 to the openssl command that makes the test certificate.
>>
>> Otherwise, look for a command that can dump out the formatting details of the
>> (non-distributable) problematic pkcs12 file to see what values it actually uses.
>>
>> On 2024-09-20 12:02, Nils Schween wrote:
>>>> Given the brittleness of pkcs#12/minip12.c I would really appricate to
>>>> have a sample file.  But the worst thing which could happen is that the
>>>> 64 bit salt does not work anymore in the future.  It is unlikey, though.
>>> I do understand. I tried to create one this morning, but I was not able
>>> to reproduce the error when importing my self created certificate.
>>>
>>> I used the following commands to create the certificate:
>>>
>>> openssl req -newkey rsa:4096 -nodes -keyout key.pem -x509 -sha384 -days 365 -out certificate.pem
>>>
>>> openssl pkcs12 -inkey key.pem -in certificate.pem -export -macsaltlen 64 -iter 20000 -out certificate.p12
>>>
>>> To compare my own certificate with the one issued by the certificate
>>> provider I used the following two commands:
>>>
>>> openssl pkcs12 -in certificate.p12 -noout -info
>>> openssl x509 -text -noout -in certificate.p12
>>>
>>> I could not find any significant difference in the output. Though the
>>> one from the certificate provider causes the error when imported with
>>> gpgsm while my own certificate does not.
>>>
>>> Since I am not very knowledgeable when it comes to S/MIME certificates,
>>> it is riddle to me why the error appears: My certificate and the one
>>> from the provider have a salt length of 64bit and that was the only
>>> thing I changed in minip12.c
>>>
>>> So, I have to say that I am sorry, I cannot reproduce the error with a
>>> self-created certificate.
>>>
>>>> Please give me some days to apply the patch.
>>> No hurry, for now I have a personal work around.
>>>
>>> Thank you,
>>> Nils
>>>
>>> Werner Koch <wk at gnupg.org> writes:
>>>
>>>> On Thu, 19 Sep 2024 13:42, Nils Schween said:
>>>>
>>>>> If it is necessary, I can try to create a certificate with openssl, that
>>>>> reproduces the error.
>>>> Given the brittleness of pkcs#12/minip12.c I would really appricate to
>>>> have a sample file.  But the worst thing which could happen is that the
>>>> 64 bit salt does not work anymore in the future.  It is unlikey, though.
>>>>
>>>> Please give me some days to apply the patch.
>>>>
>>>>
>>>> Salam-Shalom,
>>>>
>>>>     Werner
>>
>> Enjoy
>>
>> Jakob

-- 
Nils Schween
PhD Student

Phone: +49 6221 516 557
Mail: nils.schween at mpi-hd.mpg.de
PGP-Key: 4DD3DCC0532EE96DB0C1F8B5368DBFA14CB81849

Max Planck Institute for Nuclear Physics
Astrophysical Plasma Theory (APT)
Saupfercheckweg 1, D-69117 Heidelberg
https://www.mpi-hd.mpg.de/mpi/en/research/scientific-divisions-and-groups/independent-research-groups/apt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5989 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240921/07ec30d7/attachment-0001.bin>

From mm at dorfdsl.de  Sun Sep 22 08:52:05 2024
From: mm at dorfdsl.de (Marco Moock)
Date: Sun, 22 Sep 2024 08:52:05 +0200
Subject: website charset encoding for manual
Message-ID: <20240922085205.43f172b6@ryz.dorfdsl.de>

Hello!

https://gnupg.org/gph/de/manual/f20.html#AEN33
doesn't seem to have any charset encoding information.
If the charset in the browser isn't set to "western", it won't display
many special characters like "?" properly.

In the HTTP inspector I also can't find any encoding info.

Content-Type:"text/html"


-- 
kind regards
Marco


From ciohb at outlook.com  Mon Sep 23 07:14:54 2024
From: ciohb at outlook.com (ciohb)
Date: Mon, 23 Sep 2024 13:14:54 +0800
Subject: bugtracker account
In-Reply-To: <ee0e1596-19e2-4869-874e-c48983cdc7e5@langfeldt.net>
References: <ee0e1596-19e2-4869-874e-c48983cdc7e5@langfeldt.net>
Message-ID: <OSZPR01MB70044C3DA08DA061433FB550B36F2@OSZPR01MB7004.jpnprd01.prod.outlook.com>

Hi(????)??

I'd like an account on dev.gnupg.org please.

   * Handle : Dallying5371
   * Display name: Dallying
   * Email:ciohb at outlook.com


Thanks,

  ? ciohb


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240923/1fe514a1/attachment.html>

From phill at thesusis.net  Wed Sep 25 23:17:16 2024
From: phill at thesusis.net (Phillip Susi)
Date: Wed, 25 Sep 2024 17:17:16 -0400
Subject: Upgrade woes
Message-ID: <87v7yjl9gj.fsf@vps.thesusis.net>

So I upgraded to the new release of Debian a while back.  I just
realized I forgot to migrate my gpg keys to the new system.  Old one was
running 2.2.27, and now I am running 2.2.40.  I tried copying the .gnupg
directory to the new system, but gpg -k wouldn't show any keys.  I seem
to remember the last time I upgraded, I had to export and import the
keys to get them to be recognized.

I chrooted into the old system and tried to export the keys, but it just
keeps commplaining: error receiving key from agent, permission denied.

Is there a way to get it to stop using this dang agent stuff and just
prompt me for the password normally like it used to?


From wk at gnupg.org  Thu Sep 26 15:50:12 2024
From: wk at gnupg.org (Werner Koch)
Date: Thu, 26 Sep 2024 15:50:12 +0200
Subject: Upgrade woes
In-Reply-To: <87v7yjl9gj.fsf@vps.thesusis.net> (Phillip Susi's message of
 "Wed, 25 Sep 2024 17:17:16 -0400")
References: <87v7yjl9gj.fsf@vps.thesusis.net>
Message-ID: <87r096wmln.fsf@jacob.g10code.de>

Hi!

On Wed, 25 Sep 2024 17:17, Phillip Susi said:

> realized I forgot to migrate my gpg keys to the new system.  Old one was
> running 2.2.27, and now I am running 2.2.40.  I tried copying the .gnupg

There is no difference in the architecture between 2.2.27 and 2.2.40.
However, Debian has a lot of intrusive patches on top of GnuPG and thus
you can't compare a stock GnuPG with what Debian delivers.

If you copy ~/.gnupg make sure to copy also subdirectories and hidden
files (cp -a).  You also need to stop any running agent but gpg will
show you a warning if you forget this.

> I chrooted into the old system and tried to export the keys, but it just
> keeps commplaining: error receiving key from agent, permission denied.

That are the private keys which you might have not copied
(~/.gnupg/private-keys-v1.d)

> Is there a way to get it to stop using this dang agent stuff and just
> prompt me for the password normally like it used to?

No.  We use the agent for more than 20 years and you used it with
2.2.27 too.  


Shalom-Salam,

   Werner

-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240926/f71f7c19/attachment.sig>

From phill at thesusis.net  Fri Sep 27 15:23:11 2024
From: phill at thesusis.net (Phillip Susi)
Date: Fri, 27 Sep 2024 09:23:11 -0400
Subject: Upgrade woes
In-Reply-To: <87r096wmln.fsf@jacob.g10code.de>
References: <87v7yjl9gj.fsf@vps.thesusis.net> <87r096wmln.fsf@jacob.g10code.de>
Message-ID: <87bk098c3k.fsf@vps.thesusis.net>

Werner Koch <wk at gnupg.org> writes:

> If you copy ~/.gnupg make sure to copy also subdirectories and hidden
> files (cp -a).  You also need to stop any running agent but gpg will
> show you a warning if you forget this.

I used midnight commander to copy.  I think it included everything and
was set to preserve attributes.  I'll try again with cp -a.

>> I chrooted into the old system and tried to export the keys, but it just
>> keeps commplaining: error receiving key from agent, permission denied.
>
> That are the private keys which you might have not copied
> (~/.gnupg/private-keys-v1.d)

What copy?  I said I chrooted into the original system.

>> Is there a way to get it to stop using this dang agent stuff and just
>> prompt me for the password normally like it used to?
>
> No.  We use the agent for more than 20 years and you used it with
> 2.2.27 too.  

Then how do you convince the agent to work in a chroot?  At first it
just keep saying inappropriate ioctl for the device.  I tried bind
mounting /sys, /proc, /dev, and /dev/pts into the chroot and it changed
to the permission denied error without any prompting for my password.



From buo.ren.lin at gmail.com  Sat Sep 28 20:48:45 2024
From: buo.ren.lin at gmail.com (=?UTF-8?B?5p6X5Y2a5LuBQnVvLXJlbiBMaW4=?=)
Date: Sun, 29 Sep 2024 02:48:45 +0800
Subject: Concerns regarding T3065 dirmngr: proxy issues with dnslookup causing
 failure
Message-ID: <CADyC1h0NWz2a-qE4i=5Vb8KyuOYwGCTs=cb0OTTaeBDp7siy5A@mail.gmail.com>

Hello list,

I want to express my concerns over the following closed ticket:

? T3065 dirmngr: proxy issues with dnslookup causing failure
https://dev.gnupg.org/T3065

I can reproduce the same issue: dirmngr is unable to function properly
if the DNS resolution is not working on the host system but has an
otherwise functioning HTTP proxy configuration.  The Internet access
worked for most of the applications on the system(as they delegate the
task of DNS resolution to the proxy service) except for GnuPG and a
very few others.

Here are the dirmngr log entries that were generated when I ran the
following command in a terminal:

```
gpg2 --keyserver hkps://keyserver.ubuntu.com --keyserver-options
"timeout=40 http-proxy=$http_proxy" --recv-keys
409B6B1796C275462A1703113804BB82D39DC0E3
```

```
Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: resolve_dns_addr for
'keyserver.ubuntu.com': '[2620:2d:4000:1007::d43]'
Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: resolve_dns_addr for
'keyserver.ubuntu.com': '[2620:2d:4000:1007::70c]'
Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: resolve_dns_addr for
'keyserver.ubuntu.com': '185.125.188.27'
Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: resolve_dns_addr for
'keyserver.ubuntu.com': '185.125.188.26'
Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: number of system provided CAs: 146
Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: can't connect to
'192.168.49.1': no IP address for host
Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: error connecting to
'https://[2620:2d:4000:1007::d43]:443': Unknown host
Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: marking host
'[2620:2d:4000:1007::d43]' as dead
Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: can't connect to
'192.168.49.1': no IP address for host
Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: error connecting to
'https://[2620:2d:4000:1007::70c]:443': Unknown host
Sep 29 02:41:15 brlin-fw13 dirmngr[182307]: marking host
'[2620:2d:4000:1007::70c]' as dead
Sep 29 02:41:16 brlin-fw13 dirmngr[182307]: TLS handshake failed: The
TLS connection was non-properly terminated.
Sep 29 02:41:16 brlin-fw13 dirmngr[182307]: error connecting to
'https://185.125.188.27:443': Network error
Sep 29 02:41:16 brlin-fw13 dirmngr[182307]: marking host
'185.125.188.27' as dead
Sep 29 02:41:16 brlin-fw13 dirmngr[182307]: TLS handshake failed: The
TLS connection was non-properly terminated.
Sep 29 02:41:16 brlin-fw13 dirmngr[182307]: error connecting to
'https://185.125.188.26:443': Network error
Sep 29 02:41:16 brlin-fw13 dirmngr[182307]: marking host
'185.125.188.26' as dead
Sep 29 02:41:16 brlin-fw13 dirmngr[182307]: command 'KS_GET' failed:
Network error <Unspecified source>
```

According to werner's comment in the thread:

> If you specify a pool of keyservers dirmngr selects a keyserver on its own from the pool. This is so that it can use its own heuristics to detect whether a keyserver is dead and then retry another one. Now the default is a pool and your specified keyserver.ubuntu.com is also a pool (of two servers). So if your DNS resolver does not tell us the IP addresses, we can't do anything about it.

IMHO as the actual DNS resolution may not be available in a networking
environment that provides internet access over an HTTP proxy service,
dirmngr should:

* Treat the requested keyserver as the single server in the pool and
avoid checking the availability.
* Access the keyserver by name instead of IP address, and delegate the
name resolution task to the configured proxy service.
* Avoid resolving the host address of the proxy service itself if the
supplied proxy address is an IP address.

Thanks for your time and attention,
???(Buo-ren Lin)
buo.ren.lin at gmail.com

Note: Please CC me when replying as I only subscribed the list in
digest mode, thank you.