From patrick at enigmail.net  Sun Jul  3 17:54:15 2022
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Sun, 3 Jul 2022 17:54:15 +0200
Subject: Looking for new Maintainer for gpgOSX
In-Reply-To: <69d13c70-ef12-1092-2368-c46d17fcacf8@enigmail.net>
References: <69d13c70-ef12-1092-2368-c46d17fcacf8@enigmail.net>
Message-ID: <286c6e29-d5d9-3aeb-ff2d-fe77a4433c27@enigmail.net>

I'm happy to announce that Ralph Seichter has taken over the lead for
gpgOSX. Ralph already started to work on the code, and I transferred the
 ownership of the project to him.

Many thanks to Ralph for takin over so quickly!

-Patrick

Patrick Brunschwig wrote on 26.06.2022 18:12:
> gpgOSX is a free pre-packaged install-able distribution of standard
> GnuPG 2.x  for macOS. I am maintaining it since the release of GnuPG
> 2.1.0 back in 2014.
> 
> As many of you know, I'm also maintaining Enigmail. Since OpenPGP
> support is part of Thunderbird, my involvement with Enigmail has reduced
> a lot, and so has my involvement with GnuPG. Furthermore, I don't have a
> Mac anymore, and it has become more and more difficult and cumbersome to
> continue maintaining and building gpgOSX. I am therefore looking for
> someone who would want to step in and take over the project.
> 
> If you're interested, then please get in touch with me.
> 
> Thanks,
> Patrick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220703/c83029eb/attachment.sig>

From montel at kde.org  Mon Jul  4 12:47:46 2022
From: montel at kde.org (Laurent Montel)
Date: Mon, 04 Jul 2022 12:47:46 +0200
Subject: Patch for gpgme "Remove duplicate QGpgmeConfig.cmake.in.in in
 EXTRA_DIST"
Message-ID: <4668629.XBTh7YsiXq@localhost.localdomain>

Hi,
I created a patch for removing duplicate entry in EXTRA_DIST

Could you apply it please ?
Thanks
-- 
Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer 
KDAB (France) S.A.S., a KDAB Group company
Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr
KDAB - The Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile_am.diff
Type: text/x-patch
Size: 875 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220704/f5ca0434/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220704/f5ca0434/attachment-0001.sig>

From montel at kde.org  Mon Jul  4 12:48:45 2022
From: montel at kde.org (Laurent Montel)
Date: Mon, 04 Jul 2022 12:48:45 +0200
Subject: First patch for helping to build against qt6
Message-ID: <1916681.hjKRzH8lug@localhost.localdomain>

Hi,
This patch will help to build against qt6
We need to include <QStringList> vs using forward declaration

Could you apply it please ?
thanks
-- 
Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer 
KDAB (France) S.A.S., a KDAB Group company
Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr
KDAB - The Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: include_qstringlist.diff
Type: text/x-patch
Size: 2121 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220704/60751762/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220704/60751762/attachment.sig>

From montel at kde.org  Mon Jul  4 12:51:31 2022
From: montel at kde.org (Laurent Montel)
Date: Mon, 04 Jul 2022 12:51:31 +0200
Subject: GPGME Developer's Certificate of Origin" as found in the file "DCO"
Message-ID: <14189175.RP4MHXMM3Z@localhost.localdomain>

GPGME Developer's Certificate of Origin.  Version 1.0
=====================================================

By making a contribution to the GPGME project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the free software license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the
    best of my knowledge, is covered under an appropriate free
    software license and I have the right under that license to
    submit that work with modifications, whether created in whole
    or in part by me, under the same free software license
    (unless I am permitted to submit under a different license),
    as indicated in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including
    all personal information I submit with it, including my
    sign-off) is maintained indefinitely and may be redistributed
    consistent with this project or the free software license(s)
    involved.

Signed-off-by: Laurent Montel <montel at kde.org>

-- 
Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer 
KDAB (France) S.A.S., a KDAB Group company
Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr
KDAB - The Qt, C++ and OpenGL Experts
-- 
Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer 
KDAB (France) S.A.S., a KDAB Group company
Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr
KDAB - The Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220704/95c60198/attachment.sig>

From joeyberkovitz at gmail.com  Tue Jul  5 13:29:44 2022
From: joeyberkovitz at gmail.com (Joey Berkovitz)
Date: Tue, 5 Jul 2022 07:29:44 -0400
Subject: DCO
Message-ID: <CAKz+fXOKg3XDXbtHUo74Hmzo=h-AqBftLNGqF2nyAo+_Az+XCw@mail.gmail.com>

Attached please find my DCO.
-------------- next part --------------
GnuPG Developer's Certificate of Origin.  Version 1.0
=====================================================

By making a contribution to the GnuPG project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the free software license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the
    best of my knowledge, is covered under an appropriate free
    software license and I have the right under that license to
    submit that work with modifications, whether created in whole
    or in part by me, under the same free software license
    (unless I am permitted to submit under a different license),
    as indicated in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including
    all personal information I submit with it, including my
    sign-off) is maintained indefinitely and may be redistributed
    consistent with this project or the free software license(s)
    involved.

Signed-off-by: Joey Berkovitz <joeyberkovitz at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dco.txt.sig
Type: application/octet-stream
Size: 119 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220705/4cf6dfcf/attachment.obj>

From joeyberkovitz at gmail.com  Tue Jul  5 13:29:59 2022
From: joeyberkovitz at gmail.com (Joey Berkovitz)
Date: Tue, 5 Jul 2022 07:29:59 -0400
Subject: [PATCH gnupg] dirmngr: Interrogate LDAP server when base DN specified
Message-ID: <CAKz+fXPLSV+E-7_cjY8ayHT9gEyhu0SPEJyaW1OeXggkRV0hnw@mail.gmail.com>

Patch attached, related to https://dev.gnupg.org/T6047

Description copied below:
* dirmngr/ks-engine-ldap.c
(interrogate_ldap_dn): refactored out of my_ldap_connect
(my_ldap_connect): interrogate LDAP server when basedn specified

--
This patch implements the first proposed solution in bug 6047. Using
the old logic, if a base DN is specified in dirmngr, then dirmngr would
force usage of schema version 1 instead of checking if the LDAP server
is capable of version 2. With the new functionality, dirmngr will first
check if the provided base DN has a `cn=PGPServerInfo` as a direct
descendant. If the PGPServerInfo entry is not found immediately, it
then does a search again in the parent DN. The second search is useful
for backwards compatibility since any users that had specified a base
DN likely were pointing directly to the pgp keyspace DN, which is
commonly a sibling of PGPServerInfo.

Note that dirmngr does not seem to update/replace LDAP entries, so if a
user wants to update their keys from schema V1 to V2, they will need to
manually delete the entry before re-sending the keys.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dirmngr-Interrogate-LDAP-server-when-base-DN-specifi.patch.sig
Type: application/octet-stream
Size: 119 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220705/9f64d4e3/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dirmngr-Interrogate-LDAP-server-when-base-DN-specifi.patch
Type: application/octet-stream
Size: 7931 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220705/9f64d4e3/attachment-0003.obj>

From ralph at ml.seichter.de  Thu Jul  7 05:03:18 2022
From: ralph at ml.seichter.de (Ralph Seichter)
Date: Thu, 07 Jul 2022 05:03:18 +0200
Subject: Looking for new Maintainer for gpgOSX
In-Reply-To: <286c6e29-d5d9-3aeb-ff2d-fe77a4433c27@enigmail.net>
References: <69d13c70-ef12-1092-2368-c46d17fcacf8@enigmail.net>
 <286c6e29-d5d9-3aeb-ff2d-fe77a4433c27@enigmail.net>
Message-ID: <87r12x1v61.fsf@ra.horus-it.com>

* Patrick Brunschwig:

> Many thanks to Ralph for takin over so quickly!

Thank you for faithfully taking care of GnuPG for OS X for many years,
even though in the end you did not own a Mac anymore. I hope you will
continue your excellent work on Enigmail.

-Ralph


From simon at josefsson.org  Sat Jul  9 10:00:51 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 09 Jul 2022 10:00:51 +0200
Subject: Including non-selfsigs in WKD?
Message-ID: <87ilo67m18.fsf@latte.josefsson.org>

Hi

I'm reading

https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service-14

with the background that the OpenPGP web of trust has a problem that
many services now do not offer non-selfsig of the keys they return,
making it difficult to get hold of them and then build a web of trust
confidence in the key that was retrieved.

My hope was there would (or: could) be guidance on this matter in this
document, but I don't see any -- am I missing it?

I think it would be nice if this topic should be discussed in the
document, possibly as a security considerations and with
recommendations.

How about the following strawman that illustrate what I'm after?

  OpenPGP keys can contain signatures from others, that may aid in
  determining the trustworthyness of a certain key (the web of trust).
  Including these signatures in the published file is therefor
  RECOMMENDED.  The primary reason for not doing so may be due to size
  constraints or when permission to publish a third-party personal
  identifier has not been granted.

What do you think?

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220709/a9eb5d28/attachment.sig>

From dashohoxha at gmail.com  Sat Jul  9 12:31:45 2022
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Sat, 9 Jul 2022 12:31:45 +0200
Subject: Including non-selfsigs in WKD?
In-Reply-To: <87ilo67m18.fsf@latte.josefsson.org>
References: <87ilo67m18.fsf@latte.josefsson.org>
Message-ID: <CAMucfLzR8KBJifZm+AfDBsAh6PD0Cskf+WzXifddeJGiJxZXgw@mail.gmail.com>

On Sat, Jul 9, 2022 at 11:09 AM Simon Josefsson via Gnupg-devel <
gnupg-devel at lists.gnupg.org> wrote:

> Hi
>
> I'm reading
>
> https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service-14
>
> with the background that the OpenPGP web of trust has a problem that
> many services now do not offer non-selfsig of the keys they return,
> making it difficult to get hold of them and then build a web of trust
> confidence in the key that was retrieved.
>

The question of publishing the signatures of a public key, along with the
public key itself, is interesting. I never thought about it.
Now that I think about it, it seems to me that it is completely up to the
user how to export the key and how to publish it.
For example, instead of using a command like:

    gpg --no-armor --export \
            user at example.org > nmxk159crbcuk3imqiw13gkjmfwd8mqj

You can use a command like this to avoid exporting any signatures:

    gpg --no-armor --export \
            --export-options export-minimal \
            user at example.org > nmxk159crbcuk3imqiw13gkjmfwd8mqj

By default, the signatures are exported with the public key. Or you can use
the option "export-clean" instead, in order to avoid exporting the
signatures that are not usable.
For more details see:
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Input-and-Output.html

My hope was there would (or: could) be guidance on this matter in this
> document, but I don't see any -- am I missing it?
>
> I think it would be nice if this topic should be discussed in the
> document, possibly as a security considerations and with
> recommendations.
>
> How about the following strawman that illustrate what I'm after?
>
>   OpenPGP keys can contain signatures from others, that may aid in
>   determining the trustworthyness of a certain key (the web of trust).
>   Including these signatures in the published file is therefor
>   RECOMMENDED.  The primary reason for not doing so may be due to size
>   constraints or when permission to publish a third-party personal
>   identifier has not been granted.
>
> What do you think?
>

I agree that these things should be discussed and explained somewhere, in
user guides, tutorials, etc. But maybe not in the spec. The spec does not
even mention the command `gpg --export`, how can it describe and detail
export options?

Regards,
Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220709/d413cf1b/attachment.html>

From simon at josefsson.org  Sat Jul  9 14:44:44 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 09 Jul 2022 14:44:44 +0200
Subject: Including non-selfsigs in WKD?
In-Reply-To: <CAMucfLzR8KBJifZm+AfDBsAh6PD0Cskf+WzXifddeJGiJxZXgw@mail.gmail.com>
 (Dashamir Hoxha via Gnupg-devel's message of "Sat, 9 Jul 2022 12:31:45
 +0200")
References: <87ilo67m18.fsf@latte.josefsson.org>
 <CAMucfLzR8KBJifZm+AfDBsAh6PD0Cskf+WzXifddeJGiJxZXgw@mail.gmail.com>
Message-ID: <8735fa78w3.fsf@latte.josefsson.org>

Dashamir Hoxha via Gnupg-devel <gnupg-devel at lists.gnupg.org> writes:

> The question of publishing the signatures of a public key, along with the
> public key itself, is interesting. I never thought about it.
> Now that I think about it, it seems to me that it is completely up to the
> user how to export the key and how to publish it.

Yes, that's how it looks today, and we could leave it at that and let
users decide this themselves, probably guided by tutorials or
implementation defaults.  I changed my own way of doing things from
publishing a minimal key to one with signatures in it yesterday, so that
clients are able to get my non-self sigs in a reliable way now that key
servers are unreliable.

This feels a bit sub-optimal though.  I think if my suggested text was
in the specification, we would likely end up with a better world than
without the text: one where the OpenPGP web of trust is slightly more
likely to work.  I may be missing something though, so more discussion
would be good.

> I agree that these things should be discussed and explained somewhere, in
> user guides, tutorials, etc. But maybe not in the spec. The spec does not
> even mention the command `gpg --export`, how can it describe and detail
> export options?

The spec can speak about what data should go into the file, that's the
point of a specification.  It shouldn't speak about
implementation-specific commands of course.  Right now it says any
OpenPGP public key for the particular user is valid, but I don't think
it says anything either way about which sub-packets of that public key
are permitted, encouraged or forbidden in the WKD published data.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220709/74aa7073/attachment.sig>

From kloecker at kde.org  Sat Jul  9 16:36:29 2022
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Sat, 09 Jul 2022 16:36:29 +0200
Subject: Including non-selfsigs in WKD?
In-Reply-To: <8735fa78w3.fsf@latte.josefsson.org>
References: <87ilo67m18.fsf@latte.josefsson.org>
 <CAMucfLzR8KBJifZm+AfDBsAh6PD0Cskf+WzXifddeJGiJxZXgw@mail.gmail.com>
 <8735fa78w3.fsf@latte.josefsson.org>
Message-ID: <3681351.kQq0lBPeGt@daneel>

On Samstag, 9. Juli 2022 14:44:44 CEST Simon Josefsson via Gnupg-devel wrote:
> Dashamir Hoxha via Gnupg-devel <gnupg-devel at lists.gnupg.org> writes:
> > I agree that these things should be discussed and explained somewhere, in
> > user guides, tutorials, etc. But maybe not in the spec. The spec does not
> > even mention the command `gpg --export`, how can it describe and detail
> > export options?
> 
> The spec can speak about what data should go into the file, that's the
> point of a specification.  It shouldn't speak about
> implementation-specific commands of course.  Right now it says any
> OpenPGP public key for the particular user is valid, but I don't think
> it says anything either way about which sub-packets of that public key
> are permitted, encouraged or forbidden in the WKD published data.

The preferred way to "export" the key data to publish via WKD (not by the 
spec, but by WKD's inventor) is to use gpg-wks-client.

The point of WKD is that your trust in the domain owner replaces the nerdy 
web-of-trust. WKD is supposed to provide small keys, not gigantic keys with 
1000s of third-party signatures. But in the end it's up to you what you 
publish. But don't expect gpg to import via WKD anything and everything you 
publish, e.g. it strips all user IDs not matching the looked up email address 
and it imports at most 5 keys.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220709/e6ad32a1/attachment.sig>

From dashohoxha at gmail.com  Sun Jul 10 13:11:50 2022
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Sun, 10 Jul 2022 13:11:50 +0200
Subject: Including non-selfsigs in WKD?
In-Reply-To: <3681351.kQq0lBPeGt@daneel>
References: <87ilo67m18.fsf@latte.josefsson.org>
 <CAMucfLzR8KBJifZm+AfDBsAh6PD0Cskf+WzXifddeJGiJxZXgw@mail.gmail.com>
 <8735fa78w3.fsf@latte.josefsson.org> <3681351.kQq0lBPeGt@daneel>
Message-ID: <CAMucfLzr6d3-GmjiHz5PU+WqzNQV2H+dsxyFvCzOhapkcuC5Fw@mail.gmail.com>

On Sun, Jul 10, 2022 at 10:27 AM Ingo Kl?cker <kloecker at kde.org> wrote:.

>
> The preferred way to "export" the key data to publish via WKD (not by the
> spec, but by WKD's inventor) is to use gpg-wks-client.
>

WKD and WKS are different things (as far as I know), so "gpg-wks-client" is
probably not a suitable name for the tool. It may cause some confusion to
the users.

The point of WKD is that your trust in the domain owner replaces the nerdy
> web-of-trust. WKD is supposed to provide small keys, not gigantic keys with


My understanding is that the point of WKD is to make public keys
discoverable automatically, thus being an alternative (or replacement) for
the keyserver infrastructure.
I don't see why it should replace the web-of-trust, even if it is nerdy.
Also I don't see why the keys should be small, as long as their size is
under the user's control.

1000s of third-party signatures. But in the end it's up to you what you
> publish. But don't expect gpg to import via WKD anything and everything
> you
> publish, e.g. it strips all user IDs not matching the looked up email
> address
> and it imports at most 5 keys.
>

Maybe it makes sense, but I still don't understand why it should strip the
other user IDs, even if they are useless or redundant.
Also I don't understand the meaning of "it imports at most 5 keys", and why
such a limit is necessary (or why it is a good practice).

Regards,
Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220710/ed5ea27c/attachment-0001.html>

From kloecker at kde.org  Sun Jul 10 19:04:33 2022
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Sun, 10 Jul 2022 19:04:33 +0200
Subject: Including non-selfsigs in WKD?
In-Reply-To: <CAMucfLzr6d3-GmjiHz5PU+WqzNQV2H+dsxyFvCzOhapkcuC5Fw@mail.gmail.com>
References: <87ilo67m18.fsf@latte.josefsson.org> <3681351.kQq0lBPeGt@daneel>
 <CAMucfLzr6d3-GmjiHz5PU+WqzNQV2H+dsxyFvCzOhapkcuC5Fw@mail.gmail.com>
Message-ID: <21532291.EfDdHjke4D@daneel>

On Sonntag, 10. Juli 2022 13:11:50 CEST Dashamir Hoxha wrote:
> On Sun, Jul 10, 2022 at 10:27 AM Ingo Kl?cker <kloecker at kde.org> wrote:.
> 
> > The preferred way to "export" the key data to publish via WKD (not by the
> > spec, but by WKD's inventor) is to use gpg-wks-client.
> 
> WKD and WKS are different things (as far as I know), so "gpg-wks-client" is
> probably not a suitable name for the tool. It may cause some confusion to
> the users.

Well, WKS is a service providing keys via the WKD protocol. gpg-wks-client is 
meant to be used with a WKS. Hence its name. Incidentally, it provides a 
command for exporting a key suitable for uploading to a WKS (or some other WKD 
provider).

> > The point of WKD is that your trust in the domain owner replaces the nerdy
> > web-of-trust. WKD is supposed to provide small keys, not gigantic keys
> > with
> 
> My understanding is that the point of WKD is to make public keys
> discoverable automatically, thus being an alternative (or replacement) for
> the keyserver infrastructure.
> I don't see why it should replace the web-of-trust, even if it is nerdy.

It doesn't replace it, but, depending on your trust model, i.e. if you trust 
the domain owner that only people controlling a certain email address for that 
domain can upload OpenPGP keys for this email address, it can make the web-of-
trust superfluous.

> Also I don't see why the keys should be small, as long as their size is
> under the user's control.

Because I don't want to download 1000s of certifications by third-parties I 
don't even know. But do as you wish.

> > publish. But don't expect gpg to import via WKD anything and everything
> > you
> > publish, e.g. it strips all user IDs not matching the looked up email
> > address
> > and it imports at most 5 keys.
> 
> Maybe it makes sense, but I still don't understand why it should strip the
> other user IDs, even if they are useless or redundant.

Because WKD is a proof-of-control over an email address (if the domain owner 
does it right). gpg takes note from where it imported a key/user ID and in the 
future it might add a trust model that gives user IDs retrieved via WKD more 
than "unknown" validity. Moreover, it prevents users from being tricked into 
using wrong keys for some email addresses.

> Also I don't understand the meaning of "it imports at most 5 keys",

The "meaning" can be found in the source code. The code doing the import 
simply ignores the rest of the data after five keys have been imported.

> and why such a limit is necessary (or why it is a good practice).

Why would you want to provide more than five keys for the same email address? 
gpg will only ever use one of those keys when encrypting a message to some 
email address. By the way, WKD recommends to provide only a single key. The 
exception is also providing some older key(s) to ease certificate rollover.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220710/9599547c/attachment.sig>

From simon at josefsson.org  Mon Jul 11 12:29:44 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 11 Jul 2022 12:29:44 +0200
Subject: Including non-selfsigs in WKD?
In-Reply-To: <3681351.kQq0lBPeGt@daneel> ("Ingo =?iso-8859-1?Q?Kl=F6cker?=
 =?iso-8859-1?Q?=22's?= message of "Sat, 09
 Jul 2022 16:36:29 +0200")
References: <87ilo67m18.fsf@latte.josefsson.org>
 <CAMucfLzR8KBJifZm+AfDBsAh6PD0Cskf+WzXifddeJGiJxZXgw@mail.gmail.com>
 <8735fa78w3.fsf@latte.josefsson.org> <3681351.kQq0lBPeGt@daneel>
Message-ID: <87h73ovt5z.fsf@latte.josefsson.org>

Ingo Kl?cker <kloecker at kde.org> writes:

> On Samstag, 9. Juli 2022 14:44:44 CEST Simon Josefsson via Gnupg-devel wrote:
>> Dashamir Hoxha via Gnupg-devel <gnupg-devel at lists.gnupg.org> writes:
>> > I agree that these things should be discussed and explained somewhere, in
>> > user guides, tutorials, etc. But maybe not in the spec. The spec does not
>> > even mention the command `gpg --export`, how can it describe and detail
>> > export options?
>> 
>> The spec can speak about what data should go into the file, that's the
>> point of a specification.  It shouldn't speak about
>> implementation-specific commands of course.  Right now it says any
>> OpenPGP public key for the particular user is valid, but I don't think
>> it says anything either way about which sub-packets of that public key
>> are permitted, encouraged or forbidden in the WKD published data.
>
> The preferred way to "export" the key data to publish via WKD (not by the 
> spec, but by WKD's inventor) is to use gpg-wks-client.

Does it export signatures of the key?

> The point of WKD is that your trust in the domain owner replaces the nerdy 
> web-of-trust. WKD is supposed to provide small keys, not gigantic keys with 
> 1000s of third-party signatures. But in the end it's up to you what you 
> publish. But don't expect gpg to import via WKD anything and everything you 
> publish, e.g. it strips all user IDs not matching the looked up email address 
> and it imports at most 5 keys.

Yes, stripping all user IDs not matching the looked up email is
important, but does it strip signatures from others for that user ID?
That doesn't make sense to me, and I'd be surprised if it did?

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220711/8f2da9ee/attachment.sig>

From kloecker at kde.org  Mon Jul 11 13:24:27 2022
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Mon, 11 Jul 2022 13:24:27 +0200
Subject: Including non-selfsigs in WKD?
In-Reply-To: <87h73ovt5z.fsf@latte.josefsson.org>
References: <87ilo67m18.fsf@latte.josefsson.org> <3681351.kQq0lBPeGt@daneel>
 <87h73ovt5z.fsf@latte.josefsson.org>
Message-ID: <4729061.GXAFRqVoOG@daneel>

On Montag, 11. Juli 2022 12:29:44 CEST Simon Josefsson wrote:
> Ingo Kl?cker <kloecker at kde.org> writes:
> > On Samstag, 9. Juli 2022 14:44:44 CEST Simon Josefsson via Gnupg-devel 
wrote:
> >> Dashamir Hoxha via Gnupg-devel <gnupg-devel at lists.gnupg.org> writes:
> >> > I agree that these things should be discussed and explained somewhere,
> >> > in
> >> > user guides, tutorials, etc. But maybe not in the spec. The spec does
> >> > not
> >> > even mention the command `gpg --export`, how can it describe and detail
> >> > export options?
> >> 
> >> The spec can speak about what data should go into the file, that's the
> >> point of a specification.  It shouldn't speak about
> >> implementation-specific commands of course.  Right now it says any
> >> OpenPGP public key for the particular user is valid, but I don't think
> >> it says anything either way about which sub-packets of that public key
> >> are permitted, encouraged or forbidden in the WKD published data.
> > 
> > The preferred way to "export" the key data to publish via WKD (not by the
> > spec, but by WKD's inventor) is to use gpg-wks-client.
> 
> Does it export signatures of the key?

From a quick glance at the code third-party signatures seem to be included in 
the export. And that makes sense because you probably want to publish your own 
cross-certifications when you do a key rollover.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220711/6225744f/attachment.sig>

From simon at josefsson.org  Mon Jul 11 13:40:21 2022
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 11 Jul 2022 13:40:21 +0200
Subject: Including non-selfsigs in WKD?
In-Reply-To: <4729061.GXAFRqVoOG@daneel> ("Ingo =?iso-8859-1?Q?Kl=F6cker?=
 =?iso-8859-1?Q?=22's?= message of "Mon, 11
 Jul 2022 13:24:27 +0200")
References: <87ilo67m18.fsf@latte.josefsson.org> <3681351.kQq0lBPeGt@daneel>
 <87h73ovt5z.fsf@latte.josefsson.org> <4729061.GXAFRqVoOG@daneel>
Message-ID: <877d4jx4gq.fsf@latte.josefsson.org>

Ingo Kl?cker <kloecker at kde.org> writes:

> On Montag, 11. Juli 2022 12:29:44 CEST Simon Josefsson wrote:
>> Ingo Kl?cker <kloecker at kde.org> writes:
>> > On Samstag, 9. Juli 2022 14:44:44 CEST Simon Josefsson via Gnupg-devel 
> wrote:
>> >> Dashamir Hoxha via Gnupg-devel <gnupg-devel at lists.gnupg.org> writes:
>> >> > I agree that these things should be discussed and explained somewhere,
>> >> > in
>> >> > user guides, tutorials, etc. But maybe not in the spec. The spec does
>> >> > not
>> >> > even mention the command `gpg --export`, how can it describe and detail
>> >> > export options?
>> >> 
>> >> The spec can speak about what data should go into the file, that's the
>> >> point of a specification.  It shouldn't speak about
>> >> implementation-specific commands of course.  Right now it says any
>> >> OpenPGP public key for the particular user is valid, but I don't think
>> >> it says anything either way about which sub-packets of that public key
>> >> are permitted, encouraged or forbidden in the WKD published data.
>> > 
>> > The preferred way to "export" the key data to publish via WKD (not by the
>> > spec, but by WKD's inventor) is to use gpg-wks-client.
>> 
>> Does it export signatures of the key?
>
> From a quick glance at the code third-party signatures seem to be included in 
> the export.

Indeed, then this implementation is behaving like I would want it to,
and what is missing is guidance in the specification so that other
implementations will behave the same.

> And that makes sense because you probably want to publish your own
> cross-certifications when you do a key rollover.

It would be possible to separate third-party signatures from
cross-certifications, but I don't think that should be done.

/Simon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220711/ed89ed81/attachment.sig>

From aheinecke at gnupg.org  Mon Jul 11 14:53:17 2022
From: aheinecke at gnupg.org (Andre Heinecke)
Date: Mon, 11 Jul 2022 14:53:17 +0200
Subject: GnuPG 2.3.7 released
Message-ID: <2424321.n8N17B9FeY@hopper>

Hello!

We are pleased to announce the availability of a new GnuPG release: 2.3.7.
This release fixes CVE-2022-34903 which could be used to inject wrong status 
information in signatures.  The status information could then be abused to 
display a wrong validity in Kleopatra and other users of GPGME.

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.

Three different series of GnuPG are actively maintained:

- Version 2.3 is the current stable version with a lot of new features
  compared to 2.2.  This announcement is about the latest release of
  this series.

- Version 2.2 is our LTS (long term support) version and guaranteed to
  be maintained at least until the end of 2024.
  See https://gnupg.org/download/index.html#end-of-life

- Version 1.4 is only maintained to allow decryption of very old data
  which is, for security reasons, not anymore possible with other GnuPG
  versions.

Noteworthy changes in version 2.3.7 (2022-07-11)
------------------------------------------------

  * gpg: Fix possibly garbled status messages in NOTATION_DATA.  This
    bug could trick GPGME and other parsers to accept faked status
    lines.  [T6027, CVE-2022-34903]

  * gpg: Look up user ID to revoke by UID hash.  [T5936]

  * gpg: Setup the 'usage' filter property for export.  [rG7aabd94b81]

  * gpg,w32: Allow Unicode filenames for iobuf_cancel.  [rG4ee2009083]

  * gpg: Fix reading AEAD preference.  [T6019]

  * gpgsm: New option --compatibility-flags.  [rGf0b373cec9]

  * gpgsm: Rework the PKCS#12 parser to support DFN issued keys.
    [T6037]

  * agent: New option --no-user-trustlist and --sys-trustlist-name.
    [T5990]

  * agent: Pop up dialog window for confirmation, when specified so.
    [T5099]

  * agent: Show "Label:" field of private key when prompt the
    insertion.  [T5986]

  * agent: Handle USAGE information in KEYINFO.  [rG295a6a7591]

  * agent,ssh: Make not-inserted OpenPGP.3 keys available for SSH.
    [T5996]

  * agent,ssh: Support "Use-for-ssh" flag in private key.  [T5985]

  * agent: New field "Prompt" to prevent asking card key insertion.
    [T5987]

  * agent: Support --format=ssh option for READKEY.  [T6012]

  * agent: Add KEYATTR command.  [T5988]

  * agent: Flush before calling ftruncate.  [T6035]

  * agent: Do not consider --min-passphrase-len for the magic wand.
    [rGae2f1f0785]

  * kbx: Fix a race condition which results no status report.  [T5948]

  * scd:openpgp: Fix a segv for cards supporting unknown curves.
    [T5963]

  * scd:p15: Fix reading certificates without length info.

  * scd:p15: Improve the displayed S/N for Technology Nexus cards.

  * scd:openpgp: Add workaround for ECC attribute on Yubikey.  [T5963]

  * scd,piv: Fix status report of KEYPAIRINFO.  [rG64c8786105]

  * scd:nks: Support the Telesec ESIGN application.  [T5219, T4938]

  * scd: Fix use of SCardListReaders for PC/SC.  [T5979]

  * scd: Support automatic card selection for READCERT with keygrip.
    [T6003]

  * scd: Support specifying keygrip for learn command.  [T6002]

  * dirmngr: Fix for Windows when build against GNUTLS.  [T5899]

  * gpg-connect-agent: Add --unbuffered option.

  * gpg-connect-agent: Add a way to cancel an INQUIRE.  [T6010]

  * gpgconf: New short options -V and -X

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

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 FTP 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.3.7.tar.bz2 (7421k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.3.7.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.3.7_20220711.exe (4761k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.3.7_20220711.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.


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.3.7.tar.bz2 you would use this command:

     gpg --verify gnupg-2.3.7.tar.bz2.sig gnupg-2.3.7.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.3.7.tar.bz2, you run the command like this:

     sha1sum gnupg-2.3.7.tar.bz2

   and check that the output matches the next line:

9255a70a984bfbfa5312a9a52a1cf47cb0d1fc84 gnupg-2.3.7.tar.bz2
00a8f8d18681604eba4fa6e5437be30a66879456  gnupg-w32-2.3.7_20220711.tar.xz
ef971b8add3894536ae4738c98dd220550b1ac9f  gnupg-w32-2.3.7_20220711.exe


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

This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), Czech, French, German, Italian,
Japanese, Norwegian, Polish, Russian, 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/T5654 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.  Three full-time employed
developers as well as two contractors exclusively work on GnuPG and
closely related software like Libgcrypt, GPGME and Gpg4win.

Fortunately, and this is still not common with free software, we have
now 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 trademark
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 helping with donations.

*Thank you all*

   Your GnuPG hackers


p.s
Those of you with standing SEPA donations, please cancel them or
consider to redirect your funds to other projects which are more in
need of financial support.  The donations done via Stripe or PayPal
have already been canceled.

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

p.p.s
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.

Since Werner Koch is currently only partially available this Announcement was 
signed by Andre Heinecke.

-- 
GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf.  VR 11482 D?sseldorf
Vorstand: W.Koch, B.Reiter, A.Heinecke        Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-211-28010702
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 5655 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220711/8ccbbc6d/attachment-0001.sig>

From aheinecke at gnupg.org  Mon Jul 11 14:53:17 2022
From: aheinecke at gnupg.org (Andre Heinecke)
Date: Mon, 11 Jul 2022 14:53:17 +0200
Subject: [Announce] GnuPG 2.3.7 released
Message-ID: <2424321.n8N17B9FeY@hopper>

Hello!

We are pleased to announce the availability of a new GnuPG release: 2.3.7.
This release fixes CVE-2022-34903 which could be used to inject wrong status 
information in signatures.  The status information could then be abused to 
display a wrong validity in Kleopatra and other users of GPGME.

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.

Three different series of GnuPG are actively maintained:

- Version 2.3 is the current stable version with a lot of new features
  compared to 2.2.  This announcement is about the latest release of
  this series.

- Version 2.2 is our LTS (long term support) version and guaranteed to
  be maintained at least until the end of 2024.
  See https://gnupg.org/download/index.html#end-of-life

- Version 1.4 is only maintained to allow decryption of very old data
  which is, for security reasons, not anymore possible with other GnuPG
  versions.

Noteworthy changes in version 2.3.7 (2022-07-11)
------------------------------------------------

  * gpg: Fix possibly garbled status messages in NOTATION_DATA.  This
    bug could trick GPGME and other parsers to accept faked status
    lines.  [T6027, CVE-2022-34903]

  * gpg: Look up user ID to revoke by UID hash.  [T5936]

  * gpg: Setup the 'usage' filter property for export.  [rG7aabd94b81]

  * gpg,w32: Allow Unicode filenames for iobuf_cancel.  [rG4ee2009083]

  * gpg: Fix reading AEAD preference.  [T6019]

  * gpgsm: New option --compatibility-flags.  [rGf0b373cec9]

  * gpgsm: Rework the PKCS#12 parser to support DFN issued keys.
    [T6037]

  * agent: New option --no-user-trustlist and --sys-trustlist-name.
    [T5990]

  * agent: Pop up dialog window for confirmation, when specified so.
    [T5099]

  * agent: Show "Label:" field of private key when prompt the
    insertion.  [T5986]

  * agent: Handle USAGE information in KEYINFO.  [rG295a6a7591]

  * agent,ssh: Make not-inserted OpenPGP.3 keys available for SSH.
    [T5996]

  * agent,ssh: Support "Use-for-ssh" flag in private key.  [T5985]

  * agent: New field "Prompt" to prevent asking card key insertion.
    [T5987]

  * agent: Support --format=ssh option for READKEY.  [T6012]

  * agent: Add KEYATTR command.  [T5988]

  * agent: Flush before calling ftruncate.  [T6035]

  * agent: Do not consider --min-passphrase-len for the magic wand.
    [rGae2f1f0785]

  * kbx: Fix a race condition which results no status report.  [T5948]

  * scd:openpgp: Fix a segv for cards supporting unknown curves.
    [T5963]

  * scd:p15: Fix reading certificates without length info.

  * scd:p15: Improve the displayed S/N for Technology Nexus cards.

  * scd:openpgp: Add workaround for ECC attribute on Yubikey.  [T5963]

  * scd,piv: Fix status report of KEYPAIRINFO.  [rG64c8786105]

  * scd:nks: Support the Telesec ESIGN application.  [T5219, T4938]

  * scd: Fix use of SCardListReaders for PC/SC.  [T5979]

  * scd: Support automatic card selection for READCERT with keygrip.
    [T6003]

  * scd: Support specifying keygrip for learn command.  [T6002]

  * dirmngr: Fix for Windows when build against GNUTLS.  [T5899]

  * gpg-connect-agent: Add --unbuffered option.

  * gpg-connect-agent: Add a way to cancel an INQUIRE.  [T6010]

  * gpgconf: New short options -V and -X

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

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 FTP 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.3.7.tar.bz2 (7421k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.3.7.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.3.7_20220711.exe (4761k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.3.7_20220711.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.


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.3.7.tar.bz2 you would use this command:

     gpg --verify gnupg-2.3.7.tar.bz2.sig gnupg-2.3.7.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.3.7.tar.bz2, you run the command like this:

     sha1sum gnupg-2.3.7.tar.bz2

   and check that the output matches the next line:

9255a70a984bfbfa5312a9a52a1cf47cb0d1fc84 gnupg-2.3.7.tar.bz2
00a8f8d18681604eba4fa6e5437be30a66879456  gnupg-w32-2.3.7_20220711.tar.xz
ef971b8add3894536ae4738c98dd220550b1ac9f  gnupg-w32-2.3.7_20220711.exe


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

This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), Czech, French, German, Italian,
Japanese, Norwegian, Polish, Russian, 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/T5654 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.  Three full-time employed
developers as well as two contractors exclusively work on GnuPG and
closely related software like Libgcrypt, GPGME and Gpg4win.

Fortunately, and this is still not common with free software, we have
now 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 trademark
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 helping with donations.

*Thank you all*

   Your GnuPG hackers


p.s
Those of you with standing SEPA donations, please cancel them or
consider to redirect your funds to other projects which are more in
need of financial support.  The donations done via Stripe or PayPal
have already been canceled.

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

p.p.s
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.

Since Werner Koch is currently only partially available this Announcement was 
signed by Andre Heinecke.

-- 
GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf.  VR 11482 D?sseldorf
Vorstand: W.Koch, B.Reiter, A.Heinecke        Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-211-28010702
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 5655 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220711/8ccbbc6d/attachment-0002.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From ralph at ml.seichter.de  Mon Jul 11 22:22:50 2022
From: ralph at ml.seichter.de (Ralph Seichter)
Date: Mon, 11 Jul 2022 22:22:50 +0200
Subject: [Announce] GnuPG for OS X 2.3.7 released
In-Reply-To: <2424321.n8N17B9FeY@hopper>
References: <2424321.n8N17B9FeY@hopper>
Message-ID: <87v8s3bdr9.fsf@ra.horus-it.com>

GnuPG for OS X / macOS release 2.3.7 is now available for download via
https://sourceforge.net/p/gpgosx/docu/Download/ .

The disk image signature key was uploaded to keyservers on 2022-07-07
and should now be widely available. It can also be downloaded using
https://www.seichter.de/pgp/gpgosx-signing.asc .

pub ed25519/FD56297D9833FF7F 2022-07-07 [SC] [expires: 2027-07-06]
    Key fingerprint = EAB0 FE4F F793 D9E7 028E  C8E2 FD56 297D 9833 FF7F
uid [ultimate] Ralph Seichter (GnuPG for OS X signing key)

Important:

Starting with this release, GnuPG 2.3.x is installed in /usr/local/gnupg-2.3
instead of the previously hardcoded directory /usr/local/gnupg-2.2. This
enables installing both stable and LTS releases of GnuPG for OS X side by
side, for advanced users' needs.

The one caveat is that the latest installation will replace existing
soft links in /usr/local/{bin,lib}. Please use absolute paths like
/usr/local/gnupg-2.2/bin/gpg2 if necessary.

-Ralph


From ulrich.b at gmx.at  Tue Jul 12 11:45:20 2022
From: ulrich.b at gmx.at (Ulrich Buchgraber)
Date: Tue, 12 Jul 2022 11:45:20 +0200
Subject: Back-port of 'keygen.keygrip' via '--command-fd' to 2.2
Message-ID: <CAGxq=N836-u7N429=KMgxsKUyHGKC8RWb7_iZ8gHh_WxCMBEOg@mail.gmail.com>

The 'keygen.keygrip' input has been missing for '--command-fd' and
this is already fixed in 2.3 with commit 19b1a28621.

There referenced GnuPG-bug-id is 5771.

Would it be okay to back-port this to the stable 2.2 branch?

I don?t see a breaking change because the keygen.algo=keygrip answer
wouldn?t work anyways without this fix (would just stop with a tty
input for the keygrip).

Greetings, Ulrich


From bernhard at intevation.de  Wed Jul 13 09:56:30 2022
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 13 Jul 2022 09:56:30 +0200
Subject: Announcement Mail fpr 2.2.36 (LTS) missing
Message-ID: <202207130956.30490.bernhard@intevation.de>

Just noted that there was no announcement for 2.2.36
even with holidays, it would probably be good to have an announcement there,
maybe a short one?

Archive Q3
https://lists.gnupg.org/pipermail/gnupg-announce/2022q3/thread.html

Bernhard

-- 
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220713/b4127672/attachment-0001.sig>

From aheinecke at gnupg.org  Wed Jul 13 11:29:58 2022
From: aheinecke at gnupg.org (Andre Heinecke)
Date: Wed, 13 Jul 2022 11:29:58 +0200
Subject: Announcement Mail fpr 2.2.36 (LTS) missing
In-Reply-To: <202207130956.30490.bernhard@intevation.de>
References: <202207130956.30490.bernhard@intevation.de>
Message-ID: <1693171.lJof0hJ1LJ@hopper>

Hi,

On Wednesday 13 July 2022 09:56:30 CEST Bernhard Reiter wrote:
> Just noted that there was no announcement for 2.2.36
> even with holidays, it would probably be good to have an announcement there,
> maybe a short one?
> 
> Archive Q3
> https://lists.gnupg.org/pipermail/gnupg-announce/2022q3/thread.html

2.2.35 was similarly not announced. I guess the packagers of the LTS version 
see the tags and note the upload and for everyone else the modern Version
2.3.x is what should be used and relevant so the announcements are done only 
for 2.3.x

Best Regards,
Andre

-- 
GnuPG e.V., Rochusstr. 44, D-40479 D?sseldorf.  VR 11482 D?sseldorf
Vorstand: W.Koch, B.Reiter, A.Heinecke        Mail: board at gnupg.org
Finanzamt D-Altstadt, St-Nr: 103/5923/1779.   Tel: +49-211-28010702
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 5655 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220713/265b5225/attachment.sig>

From wk at gnupg.org  Mon Jul 25 15:19:33 2022
From: wk at gnupg.org (Werner Koch)
Date: Mon, 25 Jul 2022 15:19:33 +0200
Subject: Back-port of 'keygen.keygrip' via '--command-fd' to 2.2
In-Reply-To: <CAGxq=N836-u7N429=KMgxsKUyHGKC8RWb7_iZ8gHh_WxCMBEOg@mail.gmail.com>
 (Ulrich Buchgraber via Gnupg-devel's message of "Tue, 12 Jul 2022
 11:45:20 +0200")
References: <CAGxq=N836-u7N429=KMgxsKUyHGKC8RWb7_iZ8gHh_WxCMBEOg@mail.gmail.com>
Message-ID: <87fsipqqhm.fsf@wheatstone.g10code.de>

On Tue, 12 Jul 2022 11:45, Ulrich Buchgraber said:
> The 'keygen.keygrip' input has been missing for '--command-fd' and
> this is already fixed in 2.3 with commit 19b1a28621.

Will be in 2.2.37 in about 2 weeks.

Thanks,

  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: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220725/4402e5f4/attachment.sig>

From wk at gnupg.org  Mon Jul 25 15:27:17 2022
From: wk at gnupg.org (Werner Koch)
Date: Mon, 25 Jul 2022 15:27:17 +0200
Subject: Including non-selfsigs in WKD?
In-Reply-To: <4729061.GXAFRqVoOG@daneel> ("Ingo
 \=\?utf-8\?Q\?Kl\=C3\=B6cker\=22'\?\=
 \=\?utf-8\?Q\?s\?\= message of "Mon, 11 Jul 2022 13:24:27 +0200")
References: <87ilo67m18.fsf@latte.josefsson.org> <3681351.kQq0lBPeGt@daneel>
 <87h73ovt5z.fsf@latte.josefsson.org> <4729061.GXAFRqVoOG@daneel>
Message-ID: <878rohqq4q.fsf@wheatstone.g10code.de>

On Mon, 11 Jul 2022 13:24, Ingo Kl?cker said:
> From a quick glance at the code third-party signatures seem to be included in 
> the export. And that makes sense because you probably want to publish
> your own

No, they should not be included.  gpg-wks-cleint uses

  --export-options export-minimal which does 

   Export the smallest key possible. This removes all signatures except
   the most recent self-signature on each user ID. This option is the
   same as running the --edit-key command "minimize" before export
   except that the local copy of the key is not modified. Defaults to
   no.

I could imagine to add a feature to keep third-party signatures from
keys which are flagged with fully trust.  However, this leaks the
owneertrust information which we try to keep local.

A reliable keyserver network with lookup only by fingerprint seems to be
a better solution to me.


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: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220725/28609386/attachment.sig>

From ulrich.b at gmx.at  Mon Jul 25 18:52:02 2022
From: ulrich.b at gmx.at (Ulrich Buchgraber)
Date: Mon, 25 Jul 2022 18:52:02 +0200
Subject: Back-port of 'keygen.keygrip' via '--command-fd' to 2.2
In-Reply-To: <87fsipqqhm.fsf@wheatstone.g10code.de>
References: <CAGxq=N836-u7N429=KMgxsKUyHGKC8RWb7_iZ8gHh_WxCMBEOg@mail.gmail.com>
 <87fsipqqhm.fsf@wheatstone.g10code.de>
Message-ID: <CAGxq=N80nNOf5XV4jCj9x414JHe_2ncWcJwiOD86kLqk5hdiUg@mail.gmail.com>

Oh, wow. That's super nice.

Many thanks, Werner!

Greetings,
Ulrich

On Mon, 25 Jul 2022 at 15:20, Werner Koch <wk at gnupg.org> wrote:
>
> On Tue, 12 Jul 2022 11:45, Ulrich Buchgraber said:
> > The 'keygen.keygrip' input has been missing for '--command-fd' and
> > this is already fixed in 2.3 with commit 19b1a28621.
>
> Will be in 2.2.37 in about 2 weeks.
>
> Thanks,
>
>   Werner
>
> --
> The pioneers of a warless world are the youth that
> refuse military service.             - A. Einstein


From demi at invisiblethingslab.com  Mon Jul 25 19:10:55 2022
From: demi at invisiblethingslab.com (Demi Marie Obenour)
Date: Mon, 25 Jul 2022 13:10:55 -0400
Subject: Including non-selfsigs in WKD?
In-Reply-To: <878rohqq4q.fsf@wheatstone.g10code.de>
References: <87ilo67m18.fsf@latte.josefsson.org> <3681351.kQq0lBPeGt@daneel>
 <87h73ovt5z.fsf@latte.josefsson.org> <4729061.GXAFRqVoOG@daneel>
 <878rohqq4q.fsf@wheatstone.g10code.de>
Message-ID: <Yt7OogrhgnLHXhdg@itl-email>

On Mon, Jul 25, 2022 at 03:27:17PM +0200, Werner Koch via Gnupg-devel wrote:
> On Mon, 11 Jul 2022 13:24, Ingo Kl?cker said:
> > From a quick glance at the code third-party signatures seem to be included in 
> > the export. And that makes sense because you probably want to publish
> > your own
> 
> No, they should not be included.  gpg-wks-cleint uses
> 
>   --export-options export-minimal which does 
> 
>    Export the smallest key possible. This removes all signatures except
>    the most recent self-signature on each user ID. This option is the
>    same as running the --edit-key command "minimize" before export
>    except that the local copy of the key is not modified. Defaults to
>    no.
> 
> I could imagine to add a feature to keep third-party signatures from
> keys which are flagged with fully trust.  However, this leaks the
> owneertrust information which we try to keep local.

What about using attestation signatures?  Only signatures that have been
attested to would be published.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-------------- 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-devel/attachments/20220725/033668a2/attachment.sig>

From wk at gnupg.org  Tue Jul 26 13:56:38 2022
From: wk at gnupg.org (Werner Koch)
Date: Tue, 26 Jul 2022 13:56:38 +0200
Subject: Including non-selfsigs in WKD?
In-Reply-To: <Yt7OogrhgnLHXhdg@itl-email> (Demi Marie Obenour's message of
 "Mon, 25 Jul 2022 13:10:55 -0400")
References: <87ilo67m18.fsf@latte.josefsson.org> <3681351.kQq0lBPeGt@daneel>
 <87h73ovt5z.fsf@latte.josefsson.org> <4729061.GXAFRqVoOG@daneel>
 <878rohqq4q.fsf@wheatstone.g10code.de> <Yt7OogrhgnLHXhdg@itl-email>
Message-ID: <87y1wgnl3d.fsf@wheatstone.g10code.de>

On Mon, 25 Jul 2022 13:10, Demi Marie Obenour said:

> What about using attestation signatures?  Only signatures that have been
> attested to would be published.

This is some proposed feature but not implemented.  I Actually doubt
that it makes sense.  The public web of trust is more or less dead and
it has inherent problems scalability.  In well defined setting it still
makes sense but attestation signature are then not needed.


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: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220726/53697941/attachment-0001.sig>

From bernhard at intevation.de  Wed Jul 27 08:45:53 2022
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 27 Jul 2022 08:45:53 +0200
Subject: Announcement Mail for 2.2.36 (LTS) missing
In-Reply-To: <1693171.lJof0hJ1LJ@hopper>
References: <202207130956.30490.bernhard@intevation.de>
 <1693171.lJof0hJ1LJ@hopper>
Message-ID: <202207270846.00145.bernhard@intevation.de>

Am Mittwoch 13 Juli 2022 11:29:58 schrieb Andre Heinecke via Gnupg-devel:
> 2.2.35 was similarly not announced. I guess the packagers of the LTS
> version see the tags and note the upload and for everyone else the modern
> Version 2.3.x is what should be used and relevant so the announcements are
> done only for 2.3.x

From my perspective we should announce the LTS versions as well.
It is more consistent with other announcements and provides an opportunity
for people interested to see what work is done.

It also is a good example use for notifications by email and us being
in contact with our usage community.

Not all Free Software Initiatives maintain stable versions, we do
and it is of good value, so we should talk about it.

Best Regards,
Bernhard


-- 
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220727/64aca845/attachment.sig>

From bernhard at intevation.de  Wed Jul 27 15:32:44 2022
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 27 Jul 2022 15:32:44 +0200
Subject: Including non-selfsigs in WKD?
In-Reply-To: <878rohqq4q.fsf@wheatstone.g10code.de>
References: <87ilo67m18.fsf@latte.josefsson.org> <4729061.GXAFRqVoOG@daneel>
 <878rohqq4q.fsf@wheatstone.g10code.de>
Message-ID: <202207271532.52736.bernhard@intevation.de>

Am Montag 25 Juli 2022 15:27:17 schrieb Werner Koch via Gnupg-devel:
> ?gpg-wks-client uses
>
> ? --export-options export-minimal which does
>
> ? ?Export the smallest key possible. This removes all signatures except
> ? ?the most recent self-signature on each user ID. 

> I could imagine to add a feature to keep third-party signatures from
> keys which are flagged with fully trust. ?However, this leaks the
> owneertrust information which we try to keep local.

I can also see that adding third party signatures to a pubkey
delivered by WKD is good.

It needs a way for users to control which signatures,
which the simplest would be all in my keyring up to a limit in numbers.
(This has the drawback that I cannot just update my own pubkey from
keyservers without some attendance. But I guess I shouldn't do this blindly 
anyway.)

> A reliable keyserver network with lookup only by fingerprint seems to be
> a better solution to me.

Both would profit from each other.
(I think the web of trust still has some merits, although in a new form.)

Regards
Bernhard

-- 
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20220727/b01d84b4/attachment.sig>