From andrewg at andrewg.com  Thu Jul  1 02:39:14 2021
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 1 Jul 2021 01:39:14 +0100
Subject: Web of Trust spam prevention (was: Re: recommendation for key
 servers)
In-Reply-To: <60DD05D4.4060508@gmail.com>
References: <60DD05D4.4060508@gmail.com>
Message-ID: <F5B3CBDD-89BD-4EA5-97E9-B2C2DDD76A57@andrewg.com>


> On 1 Jul 2021, at 01:01, Jacob Bachmeyer <jcb62281 at gmail.com> wrote:
> 
> As I see the problem, links in the Web of Trust should be symmetric:  if Alice has verified Bob's key, Bob should have also verified Alice's key.  Enforcing this would eliminate spam signatures, but would also require some way for the system to recognize the intermediate state where Bob has uploaded his signature for Alice's key but Alice has not yet uploaded her signature for Bob's key.

The intermediate state doesn?t have to use keyservers at all. Bob signs Alice?s key and simply emails it back to her. She then has the option of attesting Bob?s signature and publishing it, or not, as she ses fit. 

A

From jcb62281 at gmail.com  Thu Jul  1 02:01:24 2021
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Wed, 30 Jun 2021 19:01:24 -0500
Subject: Web of Trust spam prevention (was: Re: recommendation for key servers)
In-Reply-To: <5f14a423-30c5-4ee6-98cf-00610c961f33@andrewg.com>
References: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
 <87r1gql0it.fsf@wheatstone.g10code.de>
 <d95abcef-51bc-ef12-cbaf-a59c91e56786@andrewg.com>
 <202106291516.13539.bernhard@intevation.de>
 <5f14a423-30c5-4ee6-98cf-00610c961f33@andrewg.com>
Message-ID: <60DD05D4.4060508@gmail.com>

Andrew Gallagher via Gnupg-devel wrote:
> I think the third-party sig issues raised in this post are best 
> tackled with attestations, as discussed already. The trick is to get 
> the end-user workflow cleaned up and into as many clients as possible.

As I see the problem, links in the Web of Trust should be symmetric:  if 
Alice has verified Bob's key, Bob should have also verified Alice's 
key.  Enforcing this would eliminate spam signatures, but would also 
require some way for the system to recognize the intermediate state 
where Bob has uploaded his signature for Alice's key but Alice has not 
yet uploaded her signature for Bob's key.  Perhaps you have 30 days to 
upload your signature after certifying a key?  Unidirectional signatures 
would not be publicly shown until the "other half" of the link is 
uploaded and would be dropped after the keyservers have held them for 30 
days if the link is not completed?

There would still be possibility to build an entire fake "troll" Web of 
Trust with fake keys cross-certifying each other, but I do not have any 
ideas to solve that issue yet.


-- Jacob



From rjh at sixdemonbag.org  Thu Jul  1 08:13:01 2021
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 1 Jul 2021 02:13:01 -0400
Subject: Web of Trust spam prevention (was: Re: recommendation for key
 servers)
In-Reply-To: <60DD05D4.4060508@gmail.com>
References: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
 <87r1gql0it.fsf@wheatstone.g10code.de>
 <d95abcef-51bc-ef12-cbaf-a59c91e56786@andrewg.com>
 <202106291516.13539.bernhard@intevation.de>
 <5f14a423-30c5-4ee6-98cf-00610c961f33@andrewg.com>
 <60DD05D4.4060508@gmail.com>
Message-ID: <5b30ea1d-1970-17a6-5fef-e2e65227ca65@sixdemonbag.org>

> As I see the problem, links in the Web of Trust should be symmetric:? if 
> Alice has verified Bob's key, Bob should have also verified Alice's 
> key.

"Should" virtually always means "I can't personally think of a use case 
to the contrary", which is a lot different from there actually being no 
use cases to the contrary.

Hint: if Alice issues Bob his certificate, Alice obviously has verified 
Bob's certificate.  But has Bob verified anything about Alice?


From andrewg at andrewg.com  Sun Jul  4 17:02:48 2021
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Sun, 4 Jul 2021 16:02:48 +0100
Subject: recommendation for key servers
In-Reply-To: <bea92fba-eb33-65b3-f0dc-7250716afa96@tu-dortmund.de>
References: <87r1gql0it.fsf@wheatstone.g10code.de>
 <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
 <8ec992faf73fcde4c358eb9af0817df660ed395d.camel@cryptobitch.de>
 <20NVA9K0SPPE2.3OT3PI3V840FD@my.amazin.horse>
 <87im1zk1pg.fsf@wheatstone.g10code.de>
 <bea92fba-eb33-65b3-f0dc-7250716afa96@tu-dortmund.de>
Message-ID: <5c492cef-87cb-c56c-4677-049997d3e29f@andrewg.com>

On 27/06/2021 12:20, Tobias Wendorff wrote:
> So maybe sign the contenting process using the private key in future?

But this just states that the person in control of the private key 
consents. This is not necessarily the person whose information is 
contained in the UID.

-- 
Andrew Gallagher

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210704/8584b28a/attachment.sig>

From wk at gnupg.org  Sun Jul  4 17:43:46 2021
From: wk at gnupg.org (Werner Koch)
Date: Sun, 04 Jul 2021 17:43:46 +0200
Subject: [Announce] GnuPG 2.2.29 (LTS) released
Message-ID: <87tulaaxu5.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG LTS release:
version 2.2.29.  This release fixes a few minor regression recently
introduced with 2.2.28 and changes the default OpenPGP keyserver.


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.2.29 (2021-07-04)
=================================================

  * Fix regression in 2.2.28 for Yubikey NEO.  [#5487]

  * Change the default keyserver to keyserver.ubuntu.com.  This is a
    temporary change due to the shutdown of the SKS keyserver pools.
    [47c4e3e00a]

  * gpg: Let --fetch-key return an exit code on failure.  [#5376]

  * dirmngr: Fix regression in KS_GET for mail address pattern.
    [#5497]

  * Add fallback in case the Windows console can't cope with Unicode.
    [#5491]

  * Improve initialization of SPR532 in the CCID driver and make the
    driver more robust.  [#5297,b90c55fa66db]

  * Make test suite work in presence of a broken Libgcrypt
    installation.  [#5502]

  * Make configure option --disable-ldap work again.

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


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

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

GnuPG 2.2.29 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.2.29.tar.bz2 (7046k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.29.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.2.29_20210704.exe (4381k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.29_20210704.exe.sig

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

A new version of Gpg4win will probably not be published.  Users affected
by one of the fixed bugs may instead install this version on top of
Gpg4win 3.1.16.


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

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

     sha1sum gnupg-2.2.29.tar.bz2

   and check that the output matches the next line:

55393b89cfe520087f4fe55ade2d573e245af58b  gnupg-2.2.29.tar.bz2
12ac77a653bfd36a836e7ccd1de95e08a81c9f6d  gnupg-w32-2.2.29_20210704.tar.xz
5ca4348a20b52250d7ff962667d47f5da65ca679  gnupg-w32-2.2.29_20210704.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 thee 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/T5498 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 still mostly 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.

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, or answering questions on the mailing
lists.

Many thanks to our numerous financial supporters, both corporate and
individuals.  Without you it would not be possible to keep GnuPG in a
good and secure shape and to address all the small and larger requests
made by our users.  Thanks.


Happy hacking,

   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.

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:

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

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

  rsa2048 2011-01-12 [expires: 2021-12-31]
  Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
  Werner Koch (dist sig)

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.

-- 
"If privacy is outlawed, only outlaws will have privacy."
                                               - PRZ 1991
-------------- 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/20210704/1585b982/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From marex at denx.de  Fri Jul  9 21:04:44 2021
From: marex at denx.de (Marek Vasut)
Date: Fri,  9 Jul 2021 21:04:44 +0200
Subject: [PATCH] applygnupgdefaults: Remove SIG prefix from signal names used
 in trap
Message-ID: <20210709190444.65013-1-marex@denx.de>

From: Fedor Ross <fedor.ross at ifm.com>

In bourne shell, the SIG prefix is optional for signal names used with
trap built-in. For example in dash, signal names with SIG prefix are not
supported at all. Drop the SIG prefix to make the script compatible with
both bash, dash, and possibly other bourne shell implementations.

No functional change.

Signed-off-by: Fedor Ross <fedor.ross at ifm.com>
Signed-off-by: Marek Vasut <marex at denx.de>
---
 tools/applygnupgdefaults | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/applygnupgdefaults b/tools/applygnupgdefaults
index 316509faf..60525a260 100755
--- a/tools/applygnupgdefaults
+++ b/tools/applygnupgdefaults
@@ -33,7 +33,7 @@ cleanup ()
 {
     [ -n "$errorfile" -a -f "$errorfile" ] && rm "$errorfile"
 }
-trap cleanup EXIT SIGINT SIGHUP SIGPIPE
+trap cleanup EXIT INT HUP PIPE
 errorfile=$(mktemp "/tmp/$PGM.log.XXXXXX")
 [ -n "$errorfile" -a -f "$errorfile" ] || exit 2
 
-- 
2.30.2



From bernhard at intevation.de  Tue Jul 13 10:15:17 2021
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 13 Jul 2021 10:15:17 +0200
Subject: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released
In-Reply-To: <87tulaaxu5.fsf@wheatstone.g10code.de>
References: <87tulaaxu5.fsf@wheatstone.g10code.de>
Message-ID: <202107131015.24257.bernhard@intevation.de>

Am Sonntag 04 Juli 2021 17:43:46 schrieb Werner Koch via Gnupg-devel:
> ? * Change the default keyserver to keyserver.ubuntu.com. ?This is a
> ? ? temporary change due to the shutdown of the SKS keyserver pools.

Does it make sense to change the list of servers behind
keys.gnupg.net as well?

https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html
"The keyserver hkp://keys.gnupg.net uses round robin DNS to give a different 
keyserver each time you use it."

Bernhard

-- 
www.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, Dr. Jan-Oliver Wagner
-------------- 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/20210713/619203e3/attachment.sig>

From bernhard at intevation.de  Tue Jul 13 10:42:07 2021
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 13 Jul 2021 10:42:07 +0200
Subject: recommendation for key servers
In-Reply-To: <5f14a423-30c5-4ee6-98cf-00610c961f33@andrewg.com>
References: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
 <202106291516.13539.bernhard@intevation.de>
 <5f14a423-30c5-4ee6-98cf-00610c961f33@andrewg.com>
Message-ID: <202107131042.19290.bernhard@intevation.de>

Am Mittwoch 30 Juni 2021 19:35:25 schrieb Andrew Gallagher via Gnupg-devel:
> The "permission-recording keyserver" as described here requires the
> various keyserver operators to trust each other to validate these
> permissions correctly. 

Not quite.
It is designed the other way around without "mandatory validation":
it allows for later opt-out or finding the party that publishes
unwanted information. So it can work at first try.

And email servers also do not trust each other fully, they just delegate
and assume some initial trust.

> Technically, this could be done if the validating 
> keyserver signs the user IDs that it has personally checked, and each of
> its peers verifies this third-party sig against their own trusted
> keyservers list.

This comes with too much power for the "validating keyserver" to me.
My feeling is that this is unneeded.

Best Regards,
Bernhard

-- 
www.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, Dr. Jan-Oliver Wagner
-------------- 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/20210713/125ed096/attachment.sig>

From kloecker at kde.org  Tue Jul 13 18:26:24 2021
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Tue, 13 Jul 2021 18:26:24 +0200
Subject: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released
In-Reply-To: <202107131015.24257.bernhard@intevation.de>
References: <87tulaaxu5.fsf@wheatstone.g10code.de>
 <202107131015.24257.bernhard@intevation.de>
Message-ID: <6559495.4FfYX22H5t@daneel>

On Dienstag, 13. Juli 2021 10:15:17 CEST Bernhard Reiter wrote:
> Am Sonntag 04 Juli 2021 17:43:46 schrieb Werner Koch via Gnupg-devel:
> >   * Change the default keyserver to keyserver.ubuntu.com.  This is a
> >     temporary change due to the shutdown of the SKS keyserver pools.
> 
> Does it make sense to change the list of servers behind
> keys.gnupg.net as well?

Already changed (in the 2.2 branch):
https://dev.gnupg.org/source/gnupg/change/STABLE-BRANCH-2-2/dirmngr/server.c;47c4e3e00a7ef55f954c14b3c237496e54a853c1

> https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.
> html "The keyserver hkp://keys.gnupg.net uses round robin DNS to give a
> different keyserver each time you use it."

This needs to be updated. DNS isn't used anymore. See comment in code:
https://dev.gnupg.org/source/gnupg/browse/STABLE-BRANCH-2-2/dirmngr/server.c$2127

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/20210713/7e575685/attachment.sig>

From gnupg-devel at spodhuis.org  Tue Jul 13 22:09:25 2021
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Tue, 13 Jul 2021 16:09:25 -0400
Subject: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released
In-Reply-To: <6559495.4FfYX22H5t@daneel>
References: <87tulaaxu5.fsf@wheatstone.g10code.de>
 <202107131015.24257.bernhard@intevation.de>
 <6559495.4FfYX22H5t@daneel>
Message-ID: <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>

On 2021-07-13 at 18:26 +0200, Ingo Kl?cker wrote:
> On Dienstag, 13. Juli 2021 10:15:17 CEST Bernhard Reiter wrote:
> > Does it make sense to change the list of servers behind
> > keys.gnupg.net as well?

> > https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.
> > html "The keyserver hkp://keys.gnupg.net uses round robin DNS to give a
> > different keyserver each time you use it."
> 
> This needs to be updated. DNS isn't used anymore. See comment in code:
> https://dev.gnupg.org/source/gnupg/browse/STABLE-BRANCH-2-2/dirmngr/server.c$2127

GnuPG has many released versions, which various distributions are using,
which will still be using the public hostname.

Updating what the DNS points at will benefit many people just using the
defaults, with their old distribution.  Not updating is not likely to
encourage them to update, it will just reinforce the perception that PGP
is broken and a different ecosystem should be used.

It's the classic dilemma, "product" or "service".  The hostname is part
of a long-term service which needs to cater to more than the current
product.  It's probably unfunded, but it's also just some DNS.

What it probably needs is a decent stable pool to point to, or something
else which keeps it from being a weekly task of asking the software
maintainers to update DNS yet again.


In case it helps: a decade ago, I wrote an SKS spider for building a
graph of all the available servers, after a while, I rewrote from Python
to Go, and that can be found at
<https://github.com/philpennock/sks_spider>; it was a weekend rewrite
and is not clean Go and is not a good example of the language, but if
anyone wants a basis for getting started with building a graph for
publishing DNS records, this one works.

I had DNS zone-building running via cron which pulled from the API
exposed by this code.  I was first to implement a few features which led
Kristian to add/improve the "official" sks-keyservers DNS logic, but I
never tried to get anyone to use my hostnames and kept them on
deliberately annoying hostnames, so as to not split people: it was
friendly feature competition, not service usage competition.

So if anyone wants to start up a DNS pool which spiders and
auto-filters, etc, then the above might be a reasonable starting point;
and even if it's not, seeing the filtering logic might at least help you
figure out what to do differently.

-Phil


From kloecker at kde.org  Wed Jul 14 09:47:35 2021
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Wed, 14 Jul 2021 09:47:35 +0200
Subject: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released
In-Reply-To: <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
References: <87tulaaxu5.fsf@wheatstone.g10code.de> <6559495.4FfYX22H5t@daneel>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
Message-ID: <7201645.5QdGYcIf76@daneel>

On Dienstag, 13. Juli 2021 22:09:25 CEST Phil Pennock wrote:
> On 2021-07-13 at 18:26 +0200, Ingo Kl?cker wrote:
> > On Dienstag, 13. Juli 2021 10:15:17 CEST Bernhard Reiter wrote:
> > > Does it make sense to change the list of servers behind
> > > keys.gnupg.net as well?
> > > 
> > > https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Opti
> > > ons. html "The keyserver hkp://keys.gnupg.net uses round robin DNS to
> > > give a different keyserver each time you use it."
> > 
> > This needs to be updated. DNS isn't used anymore. See comment in code:
> > https://dev.gnupg.org/source/gnupg/browse/STABLE-BRANCH-2-2/dirmngr/server
> > .c$2127
>
> GnuPG has many released versions, which various distributions are using,
> which will still be using the public hostname.
> 
> Updating what the DNS points at will benefit many people just using the
> defaults, with their old distribution.  Not updating is not likely to
> encourage them to update, it will just reinforce the perception that PGP
> is broken and a different ecosystem should be used.

Well, `dig keys.gnupg.net`, `nslookup keys.gnupg.net`, and `ping 
keys.gnupg.net` all agree that there is no DNS entry for keys.gnupg.net. 
Consequently, *updating* what the DNS points at makes no sense because there 
is nothing to update.

Of course, you could argue that the DNS pointers should be re-established to 
support those old distributions. But then again, nobody seems to have noticed 
that keys.gnupg.net is gone since I don't know when.

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

From kloecker at kde.org  Wed Jul 14 10:55:34 2021
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Wed, 14 Jul 2021 10:55:34 +0200
Subject: Pinentry for Qt4 still needed?
Message-ID: <13671845.3YjHFcD8Ao@daneel>

Hi all,

I'm currently working on (usability) improvements for pinentry-qt and I'm 
wondering whether pinentry-qt still needs to build with Qt4 or whether we can 
drop support for Qt4 and slowly start to add support for Qt6.

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/20210714/102388e3/attachment-0001.sig>

From noloader at gmail.com  Wed Jul 14 11:51:18 2021
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 14 Jul 2021 05:51:18 -0400
Subject: Pinentry for Qt4 still needed?
In-Reply-To: <13671845.3YjHFcD8Ao@daneel>
References: <13671845.3YjHFcD8Ao@daneel>
Message-ID: <CAH8yC8kFfUydUGu0pYcLA6OQGzMLoomN=xb16Xf4ex78++GUYw@mail.gmail.com>

On Wed, Jul 14, 2021 at 4:56 AM Ingo Kl?cker <kloecker at kde.org> wrote:
>
> I'm currently working on (usability) improvements for pinentry-qt and I'm
> wondering whether pinentry-qt still needs to build with Qt4 or whether we can
> drop support for Qt4 and slowly start to add support for Qt6.

Ubuntu 20.04 (LTS) has Qt5. I was looking at it a few hours ago for
some unrelated testing. According to apt-cache, it lacks both Qt4 and
Qt6.

It may be a good idea to use the default version of Qt that comes with
the platform.

Jeff


From kloecker at kde.org  Wed Jul 14 14:26:30 2021
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Wed, 14 Jul 2021 14:26:30 +0200
Subject: Pinentry for Qt4 still needed?
In-Reply-To: <CAH8yC8kFfUydUGu0pYcLA6OQGzMLoomN=xb16Xf4ex78++GUYw@mail.gmail.com>
References: <13671845.3YjHFcD8Ao@daneel>
 <CAH8yC8kFfUydUGu0pYcLA6OQGzMLoomN=xb16Xf4ex78++GUYw@mail.gmail.com>
Message-ID: <6284871.APD8kbOTIN@daneel>

On Mittwoch, 14. Juli 2021 11:51:18 CEST Jeffrey Walton via Gnupg-devel wrote:
> On Wed, Jul 14, 2021 at 4:56 AM Ingo Kl?cker <kloecker at kde.org> wrote:
> > I'm currently working on (usability) improvements for pinentry-qt and I'm
> > wondering whether pinentry-qt still needs to build with Qt4 or whether we
> > can drop support for Qt4 and slowly start to add support for Qt6.
> 
> Ubuntu 20.04 (LTS) has Qt5. I was looking at it a few hours ago for
> some unrelated testing. According to apt-cache, it lacks both Qt4 and
> Qt6.
> 
> It may be a good idea to use the default version of Qt that comes with
> the platform.

Sure, Qt5 would still be supported for quite some time.

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/20210714/0aad9e15/attachment.sig>

From andrewg at andrewg.com  Wed Jul 14 18:48:51 2021
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 14 Jul 2021 17:48:51 +0100
Subject: recommendation for key servers
In-Reply-To: <202107131042.19290.bernhard@intevation.de>
References: <202107131042.19290.bernhard@intevation.de>
Message-ID: <0D505C70-1142-46B0-9C31-C8E41F0D6748@andrewg.com>


> On 13 Jul 2021, at 09:43, Bernhard Reiter <bernhard at intevation.de> wrote:
> 
> ?Am Mittwoch 30 Juni 2021 19:35:25 schrieb Andrew Gallagher via Gnupg-devel:
>> The "permission-recording keyserver" as described here requires the
>> various keyserver operators to trust each other to validate these
>> permissions correctly. 
> 
> Not quite.
> It is designed the other way around without "mandatory validation":
> it allows for later opt-out or finding the party that publishes
> unwanted information. So it can work at first try.

If there is no cryptographic verification, then Mallory can trivially fake the recorded permissions, rendering the entire proposal pointless.

> And email servers also do not trust each other fully, they just delegate
> and assume some initial trust.

Yes, and this opened the spam floodgates, which is why DKIM had to be invented.

Speaking of which, perhaps we could piggyback the provenance verification on DKIM, since most public keyserver operators would presumably be admins of their own domains. That way we wouldn?t need to have a pre-approved list of ?good? keyservers. 

>> Technically, this could be done if the validating 
>> keyserver signs the user IDs that it has personally checked, and each of
>> its peers verifies this third-party sig against their own trusted
>> keyservers list.
> 
> This comes with too much power for the "validating keyserver" to me.
> My feeling is that this is unneeded.

Some form of spam prevention is needed, and I don?t see how that is possible without cryptographic verification of provenance. What form that takes is debatable. 

A

From dgouttegattat at incenp.org  Wed Jul 14 21:20:29 2021
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Wed, 14 Jul 2021 20:20:29 +0100
Subject: Pinentry for Qt4 still needed?
In-Reply-To: <13671845.3YjHFcD8Ao@daneel>
References: <13671845.3YjHFcD8Ao@daneel>
Message-ID: <20210714192029.xpua4bfxbxam3kcb@dynein.local.incenp.org>

Hi,

On Wed, Jul 14, 2021 at 10:55:34AM +0200, Ingo Kl?cker wrote:
>I'm currently working on (usability) improvements for pinentry-qt and 
>I'm wondering whether pinentry-qt still needs to build with Qt4 or 
>whether we can drop support for Qt4

For what it?s worth [1], my take on this is that by now support for Qt4 
should be on a "best-effort" basis. That is, as long as continuing to 
support Qt4 is not too much of a hassle, we might as well do it, but if 
it becomes a burden (and, in particular, if it starts to get in the way 
of usability improvements), I wouldn't have too many qualms about 
dropping it.

(The only GNU/Linux distribution I know of that still does not provide 
Qt5 is the last release of Slackware (14.2, released in 2016), and even 
though I am a proud Slacker, I wouldn?t be too concerned about it. Many 
Slackers use -current (where Qt5 is available), and for those that still 
use 14.2, they have other problems ? such as the fact that they are 
basically stuck with GnuPG 2.0?)


> and slowly start to add support for Qt6.

I believe this should be quite uncontroversial.

Regards,

- Damien

[1] Even though I did the last release of pinentry, my contributions to 
GnuPG recently have alas been few and far between, so don?t take my 
words as those of a maintainer. It?s only the opinion of a (very) 
irregular contributor.
-------------- 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-devel/attachments/20210714/72c6c5ee/attachment.sig>

From noloader at gmail.com  Wed Jul 14 23:31:23 2021
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 14 Jul 2021 17:31:23 -0400
Subject: Pinentry for Qt4 still needed?
In-Reply-To: <20210714192029.xpua4bfxbxam3kcb@dynein.local.incenp.org>
References: <13671845.3YjHFcD8Ao@daneel>
 <20210714192029.xpua4bfxbxam3kcb@dynein.local.incenp.org>
Message-ID: <CAH8yC8mJSZ1wHdWELNZ4AGB_fX9unMhMw1OPXSJu0DsjryBBMQ@mail.gmail.com>

On Wed, Jul 14, 2021 at 4:39 PM Damien Goutte-Gattat via Gnupg-devel
<gnupg-devel at gnupg.org> wrote:
>
> On Wed, Jul 14, 2021 at 10:55:34AM +0200, Ingo Kl?cker wrote:
> >I'm currently working on (usability) improvements for pinentry-qt and
> >I'm wondering whether pinentry-qt still needs to build with Qt4 or
> >whether we can drop support for Qt4
>
> For what it?s worth [1], my take on this is that by now support for Qt4
> should be on a "best-effort" basis. That is, as long as continuing to
> support Qt4 is not too much of a hassle, we might as well do it, but if
> it becomes a burden (and, in particular, if it starts to get in the way
> of usability improvements), I wouldn't have too many qualms about
> dropping it.
>
> (The only GNU/Linux distribution I know of that still does not provide
> Qt5 is the last release of Slackware (14.2, released in 2016), and even
> though I am a proud Slacker, I wouldn?t be too concerned about it. Many
> Slackers use -current (where Qt5 is available), and for those that still
> use 14.2, they have other problems ? such as the fact that they are
> basically stuck with GnuPG 2.0?)

Another data point... CentOS 7 (and probably Red Hat) provides Qt3 and
Qt5. CentOS6 provides Qt3.

CentOS6 is still used in the field. I saw a bug report on it a couple
of months ago.

I'm not a fan of Red Hat's model. But the reality of it is, you are
going to see older versions of some packages.

Jeff


From dirkx at webweaving.org  Wed Jul 14 22:44:10 2021
From: dirkx at webweaving.org (Dirk-Willem van Gulik)
Date: Wed, 14 Jul 2021 22:44:10 +0200
Subject: Pinentry for Qt4 still needed?
In-Reply-To: <20210714192029.xpua4bfxbxam3kcb@dynein.local.incenp.org>
References: <20210714192029.xpua4bfxbxam3kcb@dynein.local.incenp.org>
Message-ID: <5C6164F4-3417-4D10-A016-0CD19EA51987@webweaving.org>



> On 14 Jul 2021, at 22:41, Damien Goutte-Gattat via Gnupg-devel <gnupg-devel at gnupg.org> wrote:
> 
> ?Hi,
> 
>> On Wed, Jul 14, 2021 at 10:55:34AM +0200, Ingo Kl?cker wrote:
>> I'm currently working on (usability) improvements for pinentry-qt and I'm wondering whether pinentry-qt still needs to build with Qt4 or whether we can drop support for Qt4
> 
> For what it?s worth [1], my take on this is that by now support for Qt4 should be on a "best-effort" basis. That is, as long as continuing to support Qt4 is not too much of a hassle, we might as well do it, but if it becomes a burden (and, in particular, if it starts to get in the way of usability improvements), I wouldn't have too many qualms about dropping it.
> 
> (The only GNU/Linux distribution I know of that still does not provide Qt5 is the last release of Slackware (14.2, released in 2016), and even though I am a proud Slacker, I wouldn?t be too concerned about it. Many Slackers use -current (where Qt5 is available), and for those that still use 14.2, they have other problems ? such as the fact that they are basically stuck with GnuPG 2.0?)

Macosx also relies on it until 2 revs ago  - though that is not far of of going qt5 now as apple eols sometime later this year. 

Dw. 


From ilf at zeromail.org  Thu Jul 15 10:28:36 2021
From: ilf at zeromail.org (ilf)
Date: Thu, 15 Jul 2021 10:28:36 +0200
Subject: Pinentry for Qt4 still needed?
In-Reply-To: <20210714192029.xpua4bfxbxam3kcb@dynein.local.incenp.org>
References: <13671845.3YjHFcD8Ao@daneel>
 <20210714192029.xpua4bfxbxam3kcb@dynein.local.incenp.org>
Message-ID: <YO/xtLvaNndFluEx@zeromail.org>

Distros with old Qt (and other dependencies) also ship old Pinentry. 
This is the past.

Development is for the future. New packages of Pinentry will be built 
with new Qt (and other dependencies).

Damien Goutte-Gattat via Gnupg-devel:
> (The only GNU/Linux distribution I know of that still does not provide 
> Qt5 is the last release of Slackware (14.2, released in 2016)

-- 
ilf

If you upload your address book to "the cloud", I don't want to be in it.


From sanczes at gmail.com  Mon Jul 19 00:29:25 2021
From: sanczes at gmail.com (=?UTF-8?B?SmnFmcOtIEsu?=)
Date: Mon, 19 Jul 2021 00:29:25 +0200
Subject: [gpgme] Memory leaks fixes
Message-ID: <CAHcvn+5BM02G_3Y8GHCHQUPcqbB+FYbmAF0MG-LN7WvCse2qFw@mail.gmail.com>

Hello,

the following patch[1] contains fixes of several memory leaks found by
static code analyzers (mainly Coverity and Clang). Please feel free to
merge.

Regards
Jiri Kucera

[1] https://github.com/i386x/gpgme/compare/master..rleaks.patch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210719/06d3a26a/attachment-0001.html>

From bernhard at intevation.de  Mon Jul 19 10:21:49 2021
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 19 Jul 2021 10:21:49 +0200
Subject: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released
In-Reply-To: <7201645.5QdGYcIf76@daneel>
References: <87tulaaxu5.fsf@wheatstone.g10code.de>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
 <7201645.5QdGYcIf76@daneel>
Message-ID: <202107191021.50286.bernhard@intevation.de>

Am Mittwoch 14 Juli 2021 09:47:35 schrieb Ingo Kl?cker:
>  But then again, nobody seems to have noticed
> that keys.gnupg.net is gone since I don't know when.

I've noticed and it isn't that long gone.
(I guess several months, the problem with this is, that keys.gnupg.net
always was not sure to get you to a working server, so you didn't know if it 
was a bad server you were getting or keys.gnupg.net not working at all.)

If it wasn't a DNS entry, maybe can can create a round robin one.

Regards,
Bernhard

-- 
www.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, Dr. Jan-Oliver Wagner
-------------- 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/20210719/b7e9892b/attachment.sig>

From andrewg at andrewg.com  Mon Jul 19 12:00:47 2021
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 19 Jul 2021 11:00:47 +0100
Subject: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released
In-Reply-To: <202107191021.50286.bernhard@intevation.de>
References: <87tulaaxu5.fsf@wheatstone.g10code.de>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
 <7201645.5QdGYcIf76@daneel> <202107191021.50286.bernhard@intevation.de>
Message-ID: <3f1022da-0c6a-bd77-e84e-d0ee1cafe98b@andrewg.com>

On 19/07/2021 09:21, Bernhard Reiter wrote:
> Am Mittwoch 14 Juli 2021 09:47:35 schrieb Ingo Kl?cker:
>>   But then again, nobody seems to have noticed
>> that keys.gnupg.net is gone since I don't know when.
> 
> I've noticed and it isn't that long gone.
> (I guess several months, the problem with this is, that keys.gnupg.net
> always was not sure to get you to a working server, so you didn't know if it
> was a bad server you were getting or keys.gnupg.net not working at all.)

Indeed. Even with regular spidering of the graph, the sks-keyservers 
pools were slow to react to unresponsive servers - and there were 
seemingly infinite forms of vague unreliability that didn't trigger 
removal from the pool. DNS is too clunky for load balancing. And that's 
before considering the (legal and other) issues arising from using your 
own domain name to front a service that you have no control over.

> If it wasn't a DNS entry, maybe can can create a round robin one.

I'd strongly caution against DNS round robin for the aforementioned 
reasons. Much better to pick a trustworthy, reliable, single (or 
properly load-balanced) keyserver and point directly to it.

(If you want to run an actual keyserver that syncs with the rest of the 
graph, I'd be happy to help.)

-- 
Andrew Gallagher

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

From wk at gnupg.org  Tue Jul 20 18:07:18 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 20 Jul 2021 18:07:18 +0200
Subject: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released
In-Reply-To: <7201645.5QdGYcIf76@daneel> ("Ingo
 \=\?utf-8\?Q\?Kl\=C3\=B6cker\=22'\?\=
 \=\?utf-8\?Q\?s\?\= message of "Wed, 14 Jul 2021 09:47:35 +0200")
References: <87tulaaxu5.fsf@wheatstone.g10code.de> <6559495.4FfYX22H5t@daneel>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
 <7201645.5QdGYcIf76@daneel>
Message-ID: <875yx5c6kp.fsf@wheatstone.g10code.de>

On Wed, 14 Jul 2021 09:47, Ingo Kl?cker said:

> Well, `dig keys.gnupg.net`, `nslookup keys.gnupg.net`, and `ping 
> keys.gnupg.net` all agree that there is no DNS entry for keys.gnupg.net. 

I removed the CNAMES along with the last 2.2. release and added a TXT
record:

host -t txt keys.gnupg.net
keys.gnupg.net descriptive text "GnuPG uses an internal mapping for this name, see dirmngr/server.c."

This internal mapping was a consequence of CNAME and pool problems since 2.1.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210720/e709e982/attachment.sig>

From simon at josefsson.org  Fri Jul 23 19:45:59 2021
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 23 Jul 2021 19:45:59 +0200
Subject: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released
In-Reply-To: <875yx5c6kp.fsf@wheatstone.g10code.de> (Werner Koch via
 Gnupg-devel's message of "Tue, 20 Jul 2021 18:07:18 +0200")
References: <87tulaaxu5.fsf@wheatstone.g10code.de> <6559495.4FfYX22H5t@daneel>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
 <7201645.5QdGYcIf76@daneel> <875yx5c6kp.fsf@wheatstone.g10code.de>
Message-ID: <877dhg3ovc.fsf@latte.josefsson.org>

Werner Koch via Gnupg-devel <gnupg-devel at gnupg.org> writes:

> On Wed, 14 Jul 2021 09:47, Ingo Kl?cker said:
>
>> Well, `dig keys.gnupg.net`, `nslookup keys.gnupg.net`, and `ping 
>> keys.gnupg.net` all agree that there is no DNS entry for keys.gnupg.net. 
>
> I removed the CNAMES along with the last 2.2. release and added a TXT
> record:
>
> host -t txt keys.gnupg.net
> keys.gnupg.net descriptive text "GnuPG uses an internal mapping for this name, see dirmngr/server.c."
>
> This internal mapping was a consequence of CNAME and pool problems since 2.1.

Should keys.gnupg.net continue to be used or not?  What is the best
generic recommendation these days?  The announce-gen script in gnulib
[1] still uses '--keyserver keys.gnupg.net', and its output ends up in
many release announcements of GNU projects.  Is there anything better
than that?  Of course, how to locate PGP keys for a single individual
will differ, but it would be nice if there were a best recommended
approach, which is what keys.gnupg.net has been (is?) as far as I can
tell.

/Simon

https://git.savannah.gnu.org/cgit/gnulib.git/tree/build-aux/announce-gen#n550
-------------- 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/20210723/3822ff0c/attachment.sig>

From cloos at jhcloos.com  Sat Jul 24 20:32:53 2021
From: cloos at jhcloos.com (James Cloos)
Date: Sat, 24 Jul 2021 14:32:53 -0400
Subject: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released
In-Reply-To: <875yx5c6kp.fsf@wheatstone.g10code.de> (Werner Koch via
 Gnupg-devel's message of "Tue, 20 Jul 2021 18:07:18 +0200")
References: <87tulaaxu5.fsf@wheatstone.g10code.de> <6559495.4FfYX22H5t@daneel>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
 <7201645.5QdGYcIf76@daneel> <875yx5c6kp.fsf@wheatstone.g10code.de>
Message-ID: <m3o8artve2.fsf@carbon.jhcloos.org>

>>>>> "WK" == Werner Koch <wk at gnupg.org> writes:

WK> keys.gnupg.net descriptive text "GnuPG uses an internal mapping for this name, see dirmngr/server.c."

WK> This internal mapping was a consequence of CNAME and pool problems since 2.1.

afaict, that (ie make_keyserver_item()) still points to names under
pool.sks-keyservers.net.

which is gone from dns.

(sks-keyservers.net. still has soa, ns and a, but pool is gone.)

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6


From jeanjacquesbrucker at gmail.com  Mon Jul 26 00:13:13 2021
From: jeanjacquesbrucker at gmail.com (Jean-Jacques Brucker)
Date: Mon, 26 Jul 2021 00:13:13 +0200
Subject: random passphrase generator
Message-ID: <7a82e32b-90f4-2ed8-25dd-282fe394e84b@gmail.com>


Just to tell you I made I little random passphrase generator using 
aspell : https://github.com/foopgp/bash-libs/blob/main/bin/bl-security#L177

Such feature should IMHO interest some people it this mailing list, and 
may be also proposed when generating or changing secret passphrase.

I would like to make one day some Debian package of this "bash-libs". Do 
you think it may be a good idea ?


Thanks for your attention :-)


Jean-Jacques.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xA3983A40D1458443.asc
Type: application/pgp-keys
Size: 40225 bytes
Desc: OpenPGP public key
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210726/93c340ac/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210726/93c340ac/attachment-0001.sig>

From kloecker at kde.org  Mon Jul 26 09:31:07 2021
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Mon, 26 Jul 2021 09:31:07 +0200
Subject: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released
In-Reply-To: <m3o8artve2.fsf@carbon.jhcloos.org>
References: <87tulaaxu5.fsf@wheatstone.g10code.de>
 <875yx5c6kp.fsf@wheatstone.g10code.de> <m3o8artve2.fsf@carbon.jhcloos.org>
Message-ID: <3461070.1igTtVX2Sn@daneel>

On Samstag, 24. Juli 2021 20:32:53 CEST James Cloos via Gnupg-devel wrote:
> >>>>> "WK" == Werner Koch <wk at gnupg.org> writes:
> WK> keys.gnupg.net descriptive text "GnuPG uses an internal mapping for this
> name, see dirmngr/server.c."
> 
> WK> This internal mapping was a consequence of CNAME and pool problems since
> 2.1.
> 
> afaict, that (ie make_keyserver_item()) still points to names under
> pool.sks-keyservers.net.
> 
> which is gone from dns.

Yes and no. In master it still points to those names, but in the 2.2 branch, 
which the original message in this thread refers to, it has been changed.

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/20210726/c3dc5d1b/attachment.sig>

From sanczes at gmail.com  Mon Jul 26 13:52:14 2021
From: sanczes at gmail.com (=?UTF-8?B?SmnFmcOtIEsu?=)
Date: Mon, 26 Jul 2021 13:52:14 +0200
Subject: [gpgme] glibc 2.34 introduces closefrom()
Message-ID: <CAHcvn+5d5reA5+zgrGJ=hWmMyyU-qqVeO1KpM4muv+DsqRkaOg@mail.gmail.com>

Hello,

the next release of glibc, glibc 2.34, introduces closefrom(). Since the
glibc's implementation is FreeBSD/OpenBSD compatible, this patch[1]
prevents the build failing once glibc 2.34 will be released.

Regards,
Jiri K.

[1]
https://github.com/i386x/gpgme/commit/ed9939afc0bc1ef6a0a2dccaae62f19bc30b363d.patch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210726/3a336a8e/attachment.html>

From wk at gnupg.org  Tue Jul 27 10:45:34 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 27 Jul 2021 10:45:34 +0200
Subject: Update keys.gnupg.net?
In-Reply-To: <877dhg3ovc.fsf@latte.josefsson.org> (Simon Josefsson via
 Gnupg-devel's message of "Fri, 23 Jul 2021 19:45:59 +0200")
References: <87tulaaxu5.fsf@wheatstone.g10code.de> <6559495.4FfYX22H5t@daneel>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
 <7201645.5QdGYcIf76@daneel> <875yx5c6kp.fsf@wheatstone.g10code.de>
 <877dhg3ovc.fsf@latte.josefsson.org>
Message-ID: <878s1sb0wh.fsf_-_@wheatstone.g10code.de>

On Fri, 23 Jul 2021 19:45, Simon Josefsson said:

> many release announcements of GNU projects.  Is there anything better
> than that?  Of course, how to locate PGP keys for a single individual

The new default is the Ubuntu keyserver which seems to be the best
maintained one.  There is also the mayfirst server which I use regularly.

keys.gnupg.net was introduced even before the sks pools and allowed to
update the default keyserver for gnupg by changing the zone.  However
with the introduction of the sks pools and with TLS a CNAME did not
worked anymore and thus GnuPG was changed to use a hardwired mapping of
keys.gnuypg.net to the SKS pool

Web Key Directory seems to be the best fit but it does not allow to make
use of the Web of Trust.  But that is the same for keyservers also
(since some time).


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210727/8d4232b2/attachment.sig>

From wk at gnupg.org  Tue Jul 27 10:53:56 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 27 Jul 2021 10:53:56 +0200
Subject: [gpgme] glibc 2.34 introduces closefrom()
In-Reply-To: <CAHcvn+5d5reA5+zgrGJ=hWmMyyU-qqVeO1KpM4muv+DsqRkaOg@mail.gmail.com>
 (=?utf-8?B?IkppxZnDrQ==?= K. via Gnupg-devel"'s message of "Mon, 26 Jul
 2021 13:52:14 +0200")
References: <CAHcvn+5d5reA5+zgrGJ=hWmMyyU-qqVeO1KpM4muv+DsqRkaOg@mail.gmail.com>
Message-ID: <874kcgb0ij.fsf@wheatstone.g10code.de>

On Mon, 26 Jul 2021 13:52, Ji?? K. said:

> the next release of glibc, glibc 2.34, introduces closefrom(). Since the

Yeah, finally a useful new API for glibc.

> glibc's implementation is FreeBSD/OpenBSD compatible, this patch[1]
> prevents the build failing once glibc 2.34 will be released.

Thanks for the patch.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210727/ce2e8aca/attachment.sig>

From simon at josefsson.org  Tue Jul 27 11:15:01 2021
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 27 Jul 2021 11:15:01 +0200
Subject: Update keys.gnupg.net?
In-Reply-To: <878s1sb0wh.fsf_-_@wheatstone.g10code.de> (Werner Koch's message
 of "Tue, 27 Jul 2021 10:45:34 +0200")
References: <87tulaaxu5.fsf@wheatstone.g10code.de> <6559495.4FfYX22H5t@daneel>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
 <7201645.5QdGYcIf76@daneel> <875yx5c6kp.fsf@wheatstone.g10code.de>
 <877dhg3ovc.fsf@latte.josefsson.org>
 <878s1sb0wh.fsf_-_@wheatstone.g10code.de>
Message-ID: <8735s0glt6.fsf@latte.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> On Fri, 23 Jul 2021 19:45, Simon Josefsson said:
>
>> many release announcements of GNU projects.  Is there anything better
>> than that?  Of course, how to locate PGP keys for a single individual
>
> The new default is the Ubuntu keyserver which seems to be the best
> maintained one.  There is also the mayfirst server which I use regularly.
>
> keys.gnupg.net was introduced even before the sks pools and allowed to
> update the default keyserver for gnupg by changing the zone.  However
> with the introduction of the sks pools and with TLS a CNAME did not
> worked anymore and thus GnuPG was changed to use a hardwired mapping of
> keys.gnuypg.net to the SKS pool
>
> Web Key Directory seems to be the best fit but it does not allow to make
> use of the Web of Trust.  But that is the same for keyservers also
> (since some time).

Yeah, I also came to the conclusion of WKS:

https://gitlab.com/libidn/libidn2/-/issues/98#note_635780242

However --locate-external-keys is a new command, and not even present in
Debian buster.  To solve the use-case of refreshing any expired local
keys, the following appears to work:

gpg --auto-key-locate=clear,wkd,nodefault --locate-key simon at josefsson.org

How does GnuPG select which key is shown when running that command?

It used to look like this:

jas at latte:~$ gpg --auto-key-locate=clear,wkd,nodefault --locate-key simon at josefsson.org
gpg: key EDA21E94B565716F: "Simon Josefsson <simon at josefsson.org>" not changed
gpg: key 0664A76954265E8C: "Simon Josefsson <simon at josefsson.org>" not changed
gpg: key D73CF638C53C06BE: "Simon Josefsson <simon at josefsson.org>" not changed
gpg: Total number processed: 3
gpg:              unchanged: 3
pub   rsa1280 2002-05-05 [SC] [expired: 2014-11-10]
      0424D4EE81A0E3D119C6F835EDA21E94B565716F
uid           [ expired] Simon Josefsson <simon at josefsson.org>

jas at latte:~$ 

So it picked my oldest key...

I reordered the keys in my exported file on the server, and now it looks
like this:

jas at latte:~$ gpg --auto-key-locate=clear,wkd,nodefault --locate-key simon at josefsson.org
gpg: key 0664A76954265E8C: "Simon Josefsson <simon at josefsson.org>" not changed
gpg: key D73CF638C53C06BE: "Simon Josefsson <simon at josefsson.org>" not changed
gpg: key EDA21E94B565716F: "Simon Josefsson <simon at josefsson.org>" not changed
gpg: Total number processed: 3
gpg:              unchanged: 3
pub   rsa3744 2014-06-22 [SC] [expires: 2022-05-17]
      9AA9BDB11BB1B99A21285A330664A76954265E8C
uid           [ultimate] Simon Josefsson <simon at josefsson.org>
sub   rsa2048 2014-06-22 [S] [expires: 2022-05-17]
sub   rsa2048 2014-06-22 [E] [expires: 2022-05-17]
sub   rsa2048 2014-06-22 [A] [expires: 2022-05-17]

jas at latte:~$ 

The server has my Ed25519 key first, but still GnuPG is showing my RSA
key anyway.

Could the logic be to show the newest non-expired key?

Alternatively, show short summary output of all retrieved keys.  That is
probably the best?

/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/20210727/657a10cd/attachment.sig>

From wk at gnupg.org  Tue Jul 27 19:44:24 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 27 Jul 2021 19:44:24 +0200
Subject: Update keys.gnupg.net?
In-Reply-To: <8735s0glt6.fsf@latte.josefsson.org> (Simon Josefsson via
 Gnupg-devel's message of "Tue, 27 Jul 2021 11:15:01 +0200")
References: <87tulaaxu5.fsf@wheatstone.g10code.de> <6559495.4FfYX22H5t@daneel>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
 <7201645.5QdGYcIf76@daneel> <875yx5c6kp.fsf@wheatstone.g10code.de>
 <877dhg3ovc.fsf@latte.josefsson.org>
 <878s1sb0wh.fsf_-_@wheatstone.g10code.de>
 <8735s0glt6.fsf@latte.josefsson.org>
Message-ID: <87h7gfabyf.fsf@wheatstone.g10code.de>

On Tue, 27 Jul 2021 11:15, Simon Josefsson said:

> However --locate-external-keys is a new command, and not even present in
> Debian buster.  To solve the use-case of refreshing any expired local

Its Debian and they anyway had lots of changes on their own in it.
FWIW: The command is available since 2.2.17 (2019-07-09)

> gpg --auto-key-locate=clear,wkd,nodefault --locate-key simon at josefsson.org

Yep.

> How does GnuPG select which key is shown when running that command?

gpg merges the received key into a possible existing key.  You may use
some "--import-options show-only" to avoid that.  --locate-key does in
principle the same as if you woould do

  gpg -er foo at example.org

and the key for foo at example.org does not exist.

> I reordered the keys in my exported file on the server, and now it looks
> like this:

Ah well, there should be only one key on the server.  More are allowed
for key rollover, but we don't have useful maintanence tools for that.

> The server has my Ed25519 key first, but still GnuPG is showing my RSA
> key anyway.

The logic on how gpg considers what the best key to use is a bit
complicated.  In case you want to look at it, start at
get_best_pubkey_byname.  Note that logic kicks in only if you provide a
mail address. 

> Could the logic be to show the newest non-expired key?

That should be the case with --locate-key but not with
--locate-external-key becuase the latter does not look into the local
keystore.

> Alternatively, show short summary output of all retrieved keys.  That is
> probably the best?

Well, the idea was to have just one key and use that.  What shall one do
if several keys for the same mail address are available and valid?
Encrypt to all these keys?


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210727/d3b832a9/attachment.sig>

From simon at josefsson.org  Wed Jul 28 12:28:08 2021
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 28 Jul 2021 12:28:08 +0200
Subject: Update keys.gnupg.net?
In-Reply-To: <87h7gfabyf.fsf@wheatstone.g10code.de> (Werner Koch via
 Gnupg-devel's message of "Tue, 27 Jul 2021 19:44:24 +0200")
References: <87tulaaxu5.fsf@wheatstone.g10code.de> <6559495.4FfYX22H5t@daneel>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
 <7201645.5QdGYcIf76@daneel> <875yx5c6kp.fsf@wheatstone.g10code.de>
 <877dhg3ovc.fsf@latte.josefsson.org>
 <878s1sb0wh.fsf_-_@wheatstone.g10code.de>
 <8735s0glt6.fsf@latte.josefsson.org>
 <87h7gfabyf.fsf@wheatstone.g10code.de>
Message-ID: <87eebig2br.fsf@latte.josefsson.org>

Werner Koch via Gnupg-devel <gnupg-devel at gnupg.org> writes:

>> I reordered the keys in my exported file on the server, and now it looks
>> like this:
>
> Ah well, there should be only one key on the server.  More are allowed
> for key rollover, but we don't have useful maintanence tools for that.

My key rollover from RSA to Ed25519 seems to take years, due to problems
getting Debian and ftp-upload at gnu to accept my new key.  It seems like a
neat thing to have all my keys in there, in case someone wants to verify
old signatures.  Is this forbidden? As far as I can tell from wks draft
-12 it is permitted: 'Note that the key may be revoked or expired - it
is up to the client to handle such conditions.'.

Having the order of keys on the server matter for the client was a bit
strange though.

/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/20210728/5bc15475/attachment-0001.sig>

From bernhard at intevation.de  Wed Jul 28 15:58:23 2021
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 28 Jul 2021 15:58:23 +0200
Subject: Only one pubkey to be delivered by WKD (Re: Update keys.gnupg.net?)
In-Reply-To: <87eebig2br.fsf@latte.josefsson.org>
References: <87tulaaxu5.fsf@wheatstone.g10code.de>
 <87h7gfabyf.fsf@wheatstone.g10code.de> <87eebig2br.fsf@latte.josefsson.org>
Message-ID: <202107281558.30598.bernhard@intevation.de>

Am Mittwoch 28 Juli 2021 12:28:08 schrieb Simon Josefsson via Gnupg-devel:
> It seems like a
> neat thing to have all my keys in there, in case someone wants to verify
> old signatures. ?Is this forbidden? As far as I can tell from wks draft
> -12 it is permitted: 'Note that the key may be revoked or expired - it
> is up to the client to handle such conditions.'.

Yes, in my reading it is "forbidden" to have more than one non-revoked pubkey 
in a WKD reponse.

Citing from 
https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/12/

   The HTTP GET method MUST return the binary representation of the
   OpenPGP key for the given mail address.  The key needs to carry a
   User ID packet ([RFC4880]) with that mail address.  Note that the key
   may be revoked or expired - it is up to the client to handle such
   conditions.  To ease distribution of revoked keys, a server may
   return revoked keys in addition to a new key.  The keys are returned
   by a single request as concatenated key blocks.

It is singular "the key" and "in addition to a new key".

Additionally ss Werner wrote: it would defy the purpose otherwise. :)

Best Regards,
Bernhard

-- 
www.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, Dr. Jan-Oliver Wagner
-------------- 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/20210728/4f302160/attachment.sig>

From bernhard at intevation.de  Wed Jul 28 15:59:59 2021
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 28 Jul 2021 15:59:59 +0200
Subject: Update keys.gnupg.net? Re: [Announce] GnuPG 2.2.29 (LTS) released
In-Reply-To: <875yx5c6kp.fsf@wheatstone.g10code.de>
References: <87tulaaxu5.fsf@wheatstone.g10code.de> <7201645.5QdGYcIf76@daneel>
 <875yx5c6kp.fsf@wheatstone.g10code.de>
Message-ID: <202107281559.59927.bernhard@intevation.de>

Am Dienstag 20 Juli 2021 18:07:18 schrieb Werner Koch via Gnupg-devel:
> I removed the CNAMES along with the last 2.2. release and added a TXT
> record:
>
> host -t txt keys.gnupg.net
> keys.gnupg.net descriptive text "GnuPG uses an internal mapping for this
> name, see dirmngr/server.c."

But what is with the elder stable releases of GnuPG that are out there on 
various platforms and still have keys.gnupg.net configured?

> This internal mapping was a consequence of CNAME and pool problems since
> 2.1.

Best Regards,
Bernhard
-- 
www.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, Dr. Jan-Oliver Wagner
-------------- 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/20210728/84c4ec93/attachment.sig>

From wk at gnupg.org  Wed Jul 28 17:24:12 2021
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Jul 2021 17:24:12 +0200
Subject: Update keys.gnupg.net?
In-Reply-To: <87eebig2br.fsf@latte.josefsson.org> (Simon Josefsson via
 Gnupg-devel's message of "Wed, 28 Jul 2021 12:28:08 +0200")
References: <87tulaaxu5.fsf@wheatstone.g10code.de> <6559495.4FfYX22H5t@daneel>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
 <7201645.5QdGYcIf76@daneel> <875yx5c6kp.fsf@wheatstone.g10code.de>
 <877dhg3ovc.fsf@latte.josefsson.org>
 <878s1sb0wh.fsf_-_@wheatstone.g10code.de>
 <8735s0glt6.fsf@latte.josefsson.org>
 <87h7gfabyf.fsf@wheatstone.g10code.de>
 <87eebig2br.fsf@latte.josefsson.org>
Message-ID: <871r7ia2cj.fsf@wheatstone.g10code.de>

On Wed, 28 Jul 2021 12:28, Simon Josefsson said:

> My key rollover from RSA to Ed25519 seems to take years, due to problems

Ed25519 is supported since 2.1.0 from 2014 so I wonder why you have a
problem with the key?  Still someone using 2.0 or - shudder - 1.4 ?


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210728/7a6bf48e/attachment.sig>

From simon at josefsson.org  Wed Jul 28 17:36:54 2021
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 28 Jul 2021 17:36:54 +0200
Subject: Only one pubkey to be delivered by WKD (Re: Update
 keys.gnupg.net?)
In-Reply-To: <202107281558.30598.bernhard@intevation.de> (Bernhard Reiter's
 message of "Wed, 28 Jul 2021 15:58:23 +0200")
References: <87tulaaxu5.fsf@wheatstone.g10code.de>
 <87h7gfabyf.fsf@wheatstone.g10code.de>
 <87eebig2br.fsf@latte.josefsson.org>
 <202107281558.30598.bernhard@intevation.de>
Message-ID: <87pmv24fhl.fsf@latte.josefsson.org>

Bernhard Reiter <bernhard at intevation.de> writes:

> Am Mittwoch 28 Juli 2021 12:28:08 schrieb Simon Josefsson via Gnupg-devel:
>> It seems like a
>> neat thing to have all my keys in there, in case someone wants to verify
>> old signatures. ?Is this forbidden? As far as I can tell from wks draft
>> -12 it is permitted: 'Note that the key may be revoked or expired - it
>> is up to the client to handle such conditions.'.
>
> Yes, in my reading it is "forbidden" to have more than one non-revoked pubkey 
> in a WKD reponse.
>
> Citing from 
> https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/12/
>
>    The HTTP GET method MUST return the binary representation of the
>    OpenPGP key for the given mail address.  The key needs to carry a
>    User ID packet ([RFC4880]) with that mail address.  Note that the key
>    may be revoked or expired - it is up to the client to handle such
>    conditions.  To ease distribution of revoked keys, a server may
>    return revoked keys in addition to a new key.  The keys are returned
>    by a single request as concatenated key blocks.
>
> It is singular "the key" and "in addition to a new key".

The start of the paragraph talks about 'the key' but the end of the
paragraph talks about 'the keys', in plural.  I don't think it is
terribly clear that it MUST NOT be more than one key.  What is the
problem with serving more than one key?  It seems like a useful thing to
do during key roll-over, or even during extended periods to make it
easier for people to verify older signatures.

/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/20210728/a9448c3a/attachment.sig>

From simon at josefsson.org  Wed Jul 28 17:50:44 2021
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 28 Jul 2021 17:50:44 +0200
Subject: Update keys.gnupg.net?
In-Reply-To: <871r7ia2cj.fsf@wheatstone.g10code.de>
References: <87tulaaxu5.fsf@wheatstone.g10code.de> <6559495.4FfYX22H5t@daneel>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
 <7201645.5QdGYcIf76@daneel> <875yx5c6kp.fsf@wheatstone.g10code.de>
 <877dhg3ovc.fsf@latte.josefsson.org>
 <878s1sb0wh.fsf_-_@wheatstone.g10code.de>
 <8735s0glt6.fsf@latte.josefsson.org> <87h7gfabyf.fsf@wheatstone.g10code.de>
 <87eebig2br.fsf@latte.josefsson.org> <871r7ia2cj.fsf@wheatstone.g10code.de>
Message-ID: <5b94b0b0cc4a2176e870c8efe64e38f8f6b96ee1.camel@josefsson.org>

ons 2021-07-28 klockan 17:24 +0200 skrev Werner Koch:
> On Wed, 28 Jul 2021 12:28, Simon Josefsson said:
> 
> > My key rollover from RSA to Ed25519 seems to take years, due to
> > problems
> 
> Ed25519 is supported since 2.1.0 from 2014 so I wonder why you have a
> problem with the key?? Still someone using 2.0 or - shudder - 1.4 ?

Yeah, ftp-upload at gnu and/or Savannah uses GnuPG 1.x and don't support
Ed25519.  I think Savannah has been upgraded since last autumn when I
heard this (upload a Ed25519 to Savannah now works), but ftp-upload at gnu
still haven't upgraded as far as I know (I asked them last during
spring).  Debian requires signatures for my new key, and I haven't been
travelling lately, and I haven't found two Debian developers locally to
sign it... :-(

/Simon




From wk at gnupg.org  Wed Jul 28 17:57:33 2021
From: wk at gnupg.org (Werner Koch)
Date: Wed, 28 Jul 2021 17:57:33 +0200
Subject: Update keys.gnupg.net?
In-Reply-To: <5b94b0b0cc4a2176e870c8efe64e38f8f6b96ee1.camel@josefsson.org>
 (Simon Josefsson via Gnupg-devel's message of "Wed, 28 Jul 2021
 17:50:44 +0200")
References: <87tulaaxu5.fsf@wheatstone.g10code.de> <6559495.4FfYX22H5t@daneel>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
 <7201645.5QdGYcIf76@daneel> <875yx5c6kp.fsf@wheatstone.g10code.de>
 <877dhg3ovc.fsf@latte.josefsson.org>
 <878s1sb0wh.fsf_-_@wheatstone.g10code.de>
 <8735s0glt6.fsf@latte.josefsson.org>
 <87h7gfabyf.fsf@wheatstone.g10code.de>
 <87eebig2br.fsf@latte.josefsson.org>
 <871r7ia2cj.fsf@wheatstone.g10code.de>
 <5b94b0b0cc4a2176e870c8efe64e38f8f6b96ee1.camel@josefsson.org>
Message-ID: <87k0la8m8i.fsf@wheatstone.g10code.de>

On Wed, 28 Jul 2021 17:50, Simon Josefsson said:

> spring).  Debian requires signatures for my new key, and I haven't been
> travelling lately, and I haven't found two Debian developers locally to

That's pretty obvious for most of us :-(.  Shall we do a video call with
Gniibe and I can vouch for you?


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210728/1f5dba88/attachment.sig>

From steffen at sdaoden.eu  Wed Jul 28 17:04:19 2021
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 28 Jul 2021 17:04:19 +0200
Subject: 2.3.1: compilation result without dirmngr (due to
 --disable-ldap?)
Message-ID: <20210728150419.DEIXG%steffen@sdaoden.eu>

Hello.

I had a shallow memory of seeing this problem fly by, but from
looking over the archive headlines i saw nothing, and the
bugtracker also did not show up anything related for dimngr
yesterday (from the headlines).  On CRUX-Linux there is

  # Depends on: libgcrypt libksba pinentry npth
  ..
  name=gnupg
  version=2.3.1
  release=1
  source=(https://gnupg.org/ftp/gcrypt/$name/$name-$version.tar.bz2)

  build () {
    cd $name-$version

    ./configure --prefix=/usr \
      --libexecdir=/usr/lib \
      --disable-nls \
      --disable-ldap

    make
    make DESTDIR=$PKG install
  ...

and the compilation does not include dirmngr, making the entire
installation useless.  (I personally still use gpg (GnuPG) 1.4.23,
but just had the idea of doing WKD for my key yesterday.  P.S.:
i have not looked at the protocol, but sigh that not
a standardized checksum over the email address was chosen, like
sha256 or blake2, so that everybody could easily create the thing
by just hashing the address and exporting the key.  But so it is.)

Ciao,

--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 bernhard at intevation.de  Wed Jul 28 18:23:46 2021
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 28 Jul 2021 18:23:46 +0200
Subject: Only one pubkey to be delivered by WKD (Re: Update
 keys.gnupg.net?)
In-Reply-To: <87pmv24fhl.fsf@latte.josefsson.org>
References: <87tulaaxu5.fsf@wheatstone.g10code.de>
 <202107281558.30598.bernhard@intevation.de>
 <87pmv24fhl.fsf@latte.josefsson.org>
Message-ID: <202107281823.57805.bernhard@intevation.de>



Am Mittwoch 28 Juli 2021 17:36:54 schrieb Simon Josefsson via Gnupg-devel:
> he start of the paragraph talks about 'the key' but the end of the
> paragraph talks about 'the keys', in plural. 

In context that makes sense, because the revoked keys are added to "the key".
(In my reading it is fine, that this is why you are given feedback. :) )

> I don't think it is terribly clear that it MUST NOT be more than one key. 

Thanks for pointing this out, I think Werner will clarify this further
in the next draft revision.

> What is the problem with serving more than one key? 

The idea is to find the one key that the owner of that email address
want to get emails (and potentially other communication) encrypted and send to 
right now.

There is quite some discussion about the design rationale in the wiki, e.g.
https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept

> It seems like a useful thing to 
> do during key roll-over, or even during extended periods to make it
> easier for people to verify older signatures.

Those problems are not fully addressed (yet) by WKD.
We wanted to start lean and solve the most important use case now:
Sending emails to new communication partners with good user experience.

It is thinkable to enchange WKD for more use-cases in the future.
To discuss the rollover situation a bit:
Of course you will sign the new pubkey with your old one
and then put it up on your WKD. Now a person that already
has your old pubkey can verify the new pubkey with the signature
and does not need the old one. On the other hand, if you do not have the old 
pubkey, it does not help to get it for trusting the new one.

For signatures that does not work. One way could be to also sign
the old key with the new pubkey, so if you can discover the old key
via other methods, you can transfer a bit of trust.

Two more ideas:
1. You could use a second email address and a second pubkey for this,
if you need to have completely different pubkeys.
2. You could, in theory, deliver different pubkeys with each WKD request you 
get, and if they are all cross-signed, others would discover them over time. 
>;) (Okay, that is a bit too inventive I guess, you probably should'nt do 
this, but just pointing it out)

Best Regards,
Bernhard


-- 
www.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, Dr. Jan-Oliver Wagner
-------------- 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/20210728/f286da12/attachment.sig>

From bernhard at intevation.de  Wed Jul 28 18:32:31 2021
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 28 Jul 2021 18:32:31 +0200
Subject: recommendation for key servers
In-Reply-To: <0D505C70-1142-46B0-9C31-C8E41F0D6748@andrewg.com>
References: <202107131042.19290.bernhard@intevation.de>
 <0D505C70-1142-46B0-9C31-C8E41F0D6748@andrewg.com>
Message-ID: <202107281832.32268.bernhard@intevation.de>

Am Mittwoch 14 Juli 2021 18:48:51 schrieb Andrew Gallagher via Gnupg-devel:
> If there is no cryptographic verification, then Mallory can trivially fake
> the recorded permissions, rendering the entire proposal pointless.

If one keyserver K has recorded permissions and you get a pubkey from this 
server via TLS, then there is cryptographic verification that you've got this 
permission from K. If someone comes running at you with justified or 
unjustified legal claim, you can point them to K.

If you believe that the claim is legitimate, you may yourself record a 
barring or permission and give that to other servers.

The decentral point here is: Your server has good reason to believe that users 
have a change to get their right uphold, but if there are any legal 
difference, which there will be between global spheres, you can live with it.

> > And email servers also do not trust each other fully, they just delegate
> > and assume some initial trust.

> Yes, and this opened the spam floodgates, which is why DKIM had to be
> invented.

I'll have to look this up further, but my understanding was that this is bound 
to PKIX and domain records, it would verify a server not a single email 
sender. Of course in a decentral world with pubkey-servers, those would 
exchange pubkeys cryptographically secured, so you cannot fake that you've 
gotten that pubkey (and its permission) from a different server.

Best Regards,
Bernhard

-- 
www.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, Dr. Jan-Oliver Wagner
-------------- 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/20210728/63234e68/attachment.sig>

From gnupg-devel at spodhuis.org  Thu Jul 29 18:52:24 2021
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Thu, 29 Jul 2021 12:52:24 -0400
Subject: Update keys.gnupg.net?
In-Reply-To: <871r7ia2cj.fsf@wheatstone.g10code.de>
References: <6559495.4FfYX22H5t@daneel>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
 <7201645.5QdGYcIf76@daneel> <875yx5c6kp.fsf@wheatstone.g10code.de>
 <877dhg3ovc.fsf@latte.josefsson.org>
 <878s1sb0wh.fsf_-_@wheatstone.g10code.de>
 <8735s0glt6.fsf@latte.josefsson.org>
 <87h7gfabyf.fsf@wheatstone.g10code.de>
 <87eebig2br.fsf@latte.josefsson.org>
 <871r7ia2cj.fsf@wheatstone.g10code.de>
Message-ID: <YQLcyDcLK2TxQ7PO@hill.local>

On 2021-07-28 at 17:24 +0200, Werner Koch via Gnupg-devel wrote:
> Ed25519 is supported since 2.1.0 from 2014 so I wonder why you have a
> problem with the key?  Still someone using 2.0 or - shudder - 1.4 ?

Is WKD being designed to only be useful for the next five years, or
should it also be useful when people are trying to migrate to an
algorithm not yet implemented in GnuPG, years from now when WKD is the
ubiquitous infrastructure for pulling keys?

I have both an RSA key and an Ed25519 key.  Every time I think I can
just use the Ed25519 key, I encounter a new system where that assumption
fails, so even for $work I ended up having to create an RSA key too.

I've been publishing both.  My assumption is "these are the sets of keys
for talking with me; any which is not revoked is fit for use, use
whichever one you can" and that clients will filter out those they can't
use and end up picking one.  For `gpg --locate-external-keys` it would
import them all.

The demarcation of responsibility in making choices is that I get to say
"any of these are fit for use, from my point-of-view" and others get to
decide which of those are fit for them.

One day, I expect to have an OpenPGP key where the signature is some
quantum-and-magic-resistant signing system, and to then spend the next
15 years waiting while support for that spreads through various
ecosystems.  Client implementations will end up having tiered preference
systems, with quantum-resistant first tier, Ed25519 second tier, etc.

Can we please not restrict WKD to be more inflexible than it has to be?

-Phil
-------------- 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-devel/attachments/20210729/5bf6e14e/attachment.sig>

From wk at gnupg.org  Sat Jul 31 12:01:39 2021
From: wk at gnupg.org (Werner Koch)
Date: Sat, 31 Jul 2021 12:01:39 +0200
Subject: Update keys.gnupg.net?
In-Reply-To: <YQLcyDcLK2TxQ7PO@hill.local> (Phil Pennock via Gnupg-devel's
 message of "Thu, 29 Jul 2021 12:52:24 -0400")
References: <6559495.4FfYX22H5t@daneel>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
 <7201645.5QdGYcIf76@daneel> <875yx5c6kp.fsf@wheatstone.g10code.de>
 <877dhg3ovc.fsf@latte.josefsson.org>
 <878s1sb0wh.fsf_-_@wheatstone.g10code.de>
 <8735s0glt6.fsf@latte.josefsson.org>
 <87h7gfabyf.fsf@wheatstone.g10code.de>
 <87eebig2br.fsf@latte.josefsson.org>
 <871r7ia2cj.fsf@wheatstone.g10code.de> <YQLcyDcLK2TxQ7PO@hill.local>
Message-ID: <87pmuy7qf0.fsf@wheatstone.g10code.de>

On Thu, 29 Jul 2021 12:52, Phil Pennock said:

> I have both an RSA key and an Ed25519 key.  Every time I think I can
> just use the Ed25519 key, I encounter a new system where that assumption
> fails, so even for $work I ended up having to create an RSA key too.

So what you are saying is that there are implementations with Web Key
Directory support but no support for Ed25519?

> ecosystems.  Client implementations will end up having tiered preference
> systems, with quantum-resistant first tier, Ed25519 second tier, etc.

I don't think so.  This would soon get two complicated.  My current idea
for PQC is to have a single algorrithm id describing the first and
second tier with just one identifier (e.g. NTRU, RSA).


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210731/d37fd971/attachment.sig>

From noloader at gmail.com  Sat Jul 31 17:14:25 2021
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 31 Jul 2021 11:14:25 -0400
Subject: Update keys.gnupg.net?
In-Reply-To: <87pmuy7qf0.fsf@wheatstone.g10code.de>
References: <6559495.4FfYX22H5t@daneel>
 <YO3y9ZyyHaqMC3fB@fullerene.field.pennock-tech.net>
 <7201645.5QdGYcIf76@daneel> <875yx5c6kp.fsf@wheatstone.g10code.de>
 <877dhg3ovc.fsf@latte.josefsson.org> <878s1sb0wh.fsf_-_@wheatstone.g10code.de>
 <8735s0glt6.fsf@latte.josefsson.org> <87h7gfabyf.fsf@wheatstone.g10code.de>
 <87eebig2br.fsf@latte.josefsson.org> <871r7ia2cj.fsf@wheatstone.g10code.de>
 <YQLcyDcLK2TxQ7PO@hill.local> <87pmuy7qf0.fsf@wheatstone.g10code.de>
Message-ID: <CAH8yC8mXFb_ujn5jvVBVn-LND4COv+=cgb+3+oSuReYxGppG2w@mail.gmail.com>

On Sat, Jul 31, 2021 at 6:05 AM Werner Koch via Gnupg-devel
<gnupg-devel at gnupg.org> wrote:
>
> On Thu, 29 Jul 2021 12:52, Phil Pennock said:
>
> > I have both an RSA key and an Ed25519 key.  Every time I think I can
> > just use the Ed25519 key, I encounter a new system where that assumption
> > fails, so even for $work I ended up having to create an RSA key too.
>
> So what you are saying is that there are implementations with Web Key
> Directory support but no support for Ed25519?
>
> > ecosystems.  Client implementations will end up having tiered preference
> > systems, with quantum-resistant first tier, Ed25519 second tier, etc.
>
> I don't think so.  This would soon get two complicated.  My current idea
> for PQC is to have a single algorithm id describing the first and
> second tier with just one identifier (e.g. NTRU, RSA).

How about something like X.509 basic constraints?

You would have a structure with a blob in it. The blob could be a RSA
key, Ed25519 key, etc. However, the blob would also have a bit that
could be set as critical. A client can ignore a blob not marked as
critical. A client must fail if a blob is marked as critical but the
client does not understand it.

X.509's basic constraints have the benefit of being forward
compatible. You can keep adding stuff without worry about breaking
down-level clients.  The client can skip things it does not understand
that are non-critical. The client will fail if it encounters something
it does not understand that is marked critical.

The client is also free to implement its own set of client side
policies, like rejecting a RSA key and requiring an Ed25519 signing
key. Or a client can choose to ignore something marked as critical
(probably a bad idea, but that's choice for you). I would not worry
too much about client side policies. That's up to the user/client to
choose.

Jeff