From mehdisabwat at gmail.com  Thu Jun  3 01:25:24 2021
From: mehdisabwat at gmail.com (Mehdi Sabwat)
Date: Thu,  3 Jun 2021 01:25:24 +0200
Subject: [PATCH 1/1] wasm32-emscripten: add lock-obj header
Message-ID: <20210602232524.3888821-1-mehdi@videolabs.io>

From: Mehdi Sabwat <mehdi at videolabs.io>

This was generated with emsdk toolchain.

```
emsdk install latest && emsdk activate latest && source emsdk/emsdk_env.sh
cd libgpg-error/
emconfigure ./configure
cd src
emmake make gen-posix-lock-obj
node --experimental-wasm-threads --experimental-wasm-bulk-memory gen-posix-lock-obj
```
---
 .../lock-obj-pub.wasm32-unknown-emscripten.h  | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 src/syscfg/lock-obj-pub.wasm32-unknown-emscripten.h

diff --git a/src/syscfg/lock-obj-pub.wasm32-unknown-emscripten.h b/src/syscfg/lock-obj-pub.wasm32-unknown-emscripten.h
new file mode 100644
index 0000000..1651518
--- /dev/null
+++ b/src/syscfg/lock-obj-pub.wasm32-unknown-emscripten.h
@@ -0,0 +1,24 @@
+## lock-obj-pub.wasm32-unknown-emscripten.h
+## File created by gen-posix-lock-obj - DO NOT EDIT
+## To be included by mkheader into gpg-error.h
+
+typedef struct
+{
+  long _vers;
+  union {
+    volatile char _priv[28];
+    long _x_align;
+    long *_xp_align;
+  } u;
+} gpgrt_lock_t;
+
+#define GPGRT_LOCK_INITIALIZER {1,{{0,0,0,0,0,0,0,0, \
+                                    0,0,0,0,0,0,0,0, \
+                                    0,0,0,0,0,0,0,0, \
+                                    0,0,0,0}}}
+##
+## Local Variables:
+## mode: c
+## buffer-read-only: t
+## End:
+##
-- 
2.31.1



From bjk at luxsci.net  Wed Jun  9 05:51:07 2021
From: bjk at luxsci.net (Ben Kibbey)
Date: Tue,  8 Jun 2021 20:51:07 -0700
Subject: [PATCH] Wipe potentially sensitive stack memory.
Message-ID: <1623210671-2124970.82305647.f1593p8Rc029687@rs161.luxsci.com>

* src/util.h: Add wipememory macro from cJSON.c.
* src/data.c (_gpgme_data_inbound_handler): Wipe buffer before return.
* src/engine-assuan.c (inquire_cb): Ditto.

Signed-off-by: Ben Kibbey <bjk at luxsci.net>
---
 src/cJSON.c         | 10 +---------
 src/data.c          |  2 ++
 src/engine-assuan.c |  3 +++
 src/util.h          |  9 +++++++++
 4 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/src/cJSON.c b/src/cJSON.c
index 7769b0eb..f73e25a3 100644
--- a/src/cJSON.c
+++ b/src/cJSON.c
@@ -49,6 +49,7 @@
 #include <gpg-error.h>
 
 #include "cJSON.h"
+#include "util.h"
 
 /* Only use calloc. */
 #define CALLOC_ONLY 1
@@ -56,15 +57,6 @@
 /* Maximum recursion depth */
 #define MAX_DEPTH 512
 
-/* To avoid that a compiler optimizes certain memset calls away, these
-   macros may be used instead. */
-#define wipememory2(_ptr,_set,_len) do { \
-        volatile char *_vptr=(volatile char *)(_ptr); \
-        size_t _vlen=(_len); \
-        while(_vlen) { *_vptr=(_set); _vptr++; _vlen--; } \
-    } while(0)
-#define wipememory(_ptr,_len) wipememory2(_ptr,0,_len)
-
 /* We use malloc function wrappers from gpgrt (aka libgpg-error).  */
 #include <gpgrt.h>
 #define xtrycalloc(a,b) gpgrt_calloc ((a), (b))
diff --git a/src/data.c b/src/data.c
index 70595907..07e279a9 100644
--- a/src/data.c
+++ b/src/data.c
@@ -594,6 +594,8 @@ _gpgme_data_inbound_handler (void *opaque, int fd)
       buflen -= amt;
     }
   while (buflen > 0);
+
+  wipememory (buffer, sizeof (buffer));
   return TRACE_ERR (0);
 }
 
diff --git a/src/engine-assuan.c b/src/engine-assuan.c
index ab9d05a9..a8c65dca 100644
--- a/src/engine-assuan.c
+++ b/src/engine-assuan.c
@@ -467,6 +467,9 @@ inquire_cb (engine_llass_t llass, const char *keyword, const char *args)
               if (err)
                 break;
             }
+
+          wipememory(buf, sizeof(buf));
+
           /* Tell the caller that we are finished with the data
            * object.  The error code from assuan_send_data has
            * priority over the one from the cleanup function. */
diff --git a/src/util.h b/src/util.h
index bc78c9b8..97bc1da2 100644
--- a/src/util.h
+++ b/src/util.h
@@ -41,6 +41,15 @@
 
 #define DIM(v) (sizeof(v)/sizeof((v)[0]))
 
+
+/* To avoid that a compiler optimizes certain memset calls away, these
+   macros may be used instead. */
+#define wipememory2(_ptr,_set,_len) do { \
+        volatile char *_vptr=(volatile char *)(_ptr); \
+        size_t _vlen=(_len); \
+        while(_vlen) { *_vptr=(_set); _vptr++; _vlen--; } \
+    } while(0)
+#define wipememory(_ptr,_len) wipememory2(_ptr,0,_len)
 
 
 /*-- {posix,w32}-util.c --*/
-- 
2.30.2



From wk at gnupg.org  Thu Jun 10 20:15:13 2021
From: wk at gnupg.org (Werner Koch)
Date: Thu, 10 Jun 2021 20:15:13 +0200
Subject: [Announce] GnuPG 2.2.28 (LTS) released
Message-ID: <87wnr1y4b2.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG LTS release:
version 2.2.28.  This release brings a couple of new features and fixes
the usual bugs.  The new features have been backported from the stable
series 2.3.


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.28 (2021-06-10)
=================================================

  * gpg: Auto import keys specified with --trusted-keys.
    [e7251be84c79]

  * gpg: Allow decryption w/o public key but with correct card
    inserted.  [e53f6037283e]

  * gpg: Allow fingerprint based lookup with --locate-external-key.
    [2af217ecd7e4]

  * gpg: Lookup a missing public key of the current card via LDAP.
    [b59af0e2a05a]

  * gpg: New option --force-sign-key.  [#4584]

  * gpg: Use a more descriptive password prompt for symmetric
    decryption.  [03f83bcda5d1]

  * gpg: Do not use the self-sigs-only option for LDAP keyserver
    imports.  [#5387]

  * gpg: Keep temp files when opening images via xdg-open.
    [0441ed6e1c]

  * gpg: Fix mailbox based search via AKL keyserver method.
    [22fe23f46d31]

  * gpg: Fix sending an OpenPGP key with umlaut to an LDAP keyserver.
    [7bf8530e75d0]

  * gpg: Allow ECDH with a smartcard returning only the x-coordinate.
    [b203325ce1]

  * gpgsm: New option --ldapserver as an alias for --keyserver.  Note
    that configuring servers in gpgsm and gpg is deprecated; please
    use the dirmngr configuration options.

  * gpgsm: Support AES-GCM decryption.  [b722fd755c77]

  * gpgsm: Support decryption of password protected files.
    [6f31acac767f]

  * gpgsm: Lock keyboxes also during a search to fix lockups on
    Windows.  [#4505]

  * agent: Skip unknown unknown ssh curves seen on
    cards. [bbf4bd3bfcb5]

  * scdaemon: New option --pcsc-shared.  [5eec40f3d827]

  * scdaemon: Backport PKCS#15 card support from GnuPG 2.3
    [7637d39fe20e]

  * scdaemon: Fix CCID driver for SCM SPR332/SPR532.  [#5297]

  * scdaemon: Fix possible PC/SC removed card problem.  [9d83bfb63968]

  * scdaemon: Fix unblock PIN by a Reset Code with KDF.  [#5413]

  * scdaemon: Support compressed points.  [96577e2e46e4]

  * scdaemon: Prettify S/N for Yubikeys and fix reading for early
    Yubikey 5 tokens.  [f8588369bcb0,#5442]

  * dirmngr: New option --ldapserver to avoid the need for the
    separate dirmngr_ldapservers.conf file.

  * dirmngr: The dirmngr_ldap wrapper has been rewritten to properly
    support ldap-over-tls and starttls for X.509 certificates and
    CRLs.  [39815c023f03]

  * dirmngr: OpenPGP LDAP keyservers may now also be configured using
    the same syntax as used for X.509 and CRL LDAP servers.  This
    avoids the former cumbersome quoting rules and adds a flexible set
    of flags to control the connection.  [2b4cddf9086f]

  * dirmngr: The "ldaps" scheme of an OpenPGP keyserver URL is now
    interpreted as ldap-with-starttls on port 389.  To use the
    non-standardized ldap-over-tls the new LDAP configuration method
    of the new attribute "gpgNtds" needs to be used.  [55f46b33df08]

  * dirmngr: Return the fingerprint as search result also for LDAP
    OpenPGP keyservers.  This requires the modernized LDAP schema.
    [#5441]

  * dirmngr: An OpenPGP LDAP search by a mailbox now ignores revoked
    keys.  [b6f8cd7eef4b]

  * gpgconf: Make runtime changes with non-default homedir work.
    [c8f0b02936c7]

  * gpgconf: Do not translate an empty string to the PO file's meta
    data.  [#5363]

  * gpgconf: Fix argv overflow if --homedir is used.  [#5366]

  * gpgconf: Return a new pseudo option "compliance_de_vs".
    [9feffc03f364]

  * gpgtar: Fix file size computation under Windows.  [198b240b1955]

  * Full Unicode support for the Windows command line.  [#4398]

  * Fix problem with Windows Job objects and auto start of our
    daemons.  [#4333]

  * i18n: In German always use "Passwort" instead of "Passphrase" in
    prompts.

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


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

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

GnuPG 2.2.28 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.28.tar.bz2 (7049k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.28.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.28_20210610.exe (4380k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.28_20210610.exe.sig

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

New versions of the GnuPG VS-Desktop(tm) and Gpg4win featuring this
version of GnuPG will be released shortly.


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

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

     sha1sum gnupg-2.2.28.tar.bz2

   and check that the output matches the next line:

5f92b7b32d594cf21ea2b48cdaa2e460daccd6e3  gnupg-2.2.28.tar.bz2
8fe406980d09e80812fe8fee3f616765e1a4a526  gnupg-w32-2.2.28_20210610.tar.xz
9d53a8092c4f470831417b8f850943960a9fe857  gnupg-w32-2.2.28_20210610.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
=========================

If you used GnuPG in the past you should read the description of
changes and new features at doc/whats-new-in-2.1.txt or online at

  https://gnupg.org/faq/whats-new-in-2.1.html

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/T5482 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 in 2021,

   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/20210610/a2bedbba/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From gnupg-devel at spodhuis.org  Thu Jun 10 23:20:28 2021
From: gnupg-devel at spodhuis.org (Phil Pennock)
Date: Thu, 10 Jun 2021 17:20:28 -0400
Subject: 2.2.28 doesn't honor --disable-ldap?
Message-ID: <YMKCHNAkRjcNIVUb@fullerene.field.pennock-tech.net>

On 2021-06-10 at 20:15 +0200, Werner Koch via Gnupg-devel wrote:
> We are pleased to announce the availability of a new GnuPG LTS release:
> version 2.2.28.
[...]
>   * gpg: Lookup a missing public key of the current card via LDAP.
>     [b59af0e2a05a]

My package builds pass `--disable-ldap` to the configure line for GnuPG;
this does not appear to be honored any more?

Resuming a failed build docker container and trying again, it's failing
at:

make[1]: Entering directory '/root/src/gnupg-2.2.28/dirmngr'
gcc -std=gnu99 -I/opt/gnupg/include -I/opt/gnupg/include -I/opt/gnupg/include -I/opt/gnupg/include -I/opt/gnupg/include  -I/opt/gnupg/include -Wall -Wno-format-zero-length -Wno-pointer-sign -Wpointer-arith -g -O2  -L/opt/gnupg/lib -Wl,-R/opt/gnupg/lib -o dirmngr dirmngr.o server.o crlcache.o crlfetch.o certcache.o domaininfo.o workqueue.o loadswdb.o cdblib.o misc.o ocsp.o validate.o dns-stuff.o http.o http-common.o http-ntbtls.o ks-action.o ks-engine-hkp.o ks-engine-http.o ks-engine-finger.o ks-engine-kdns.o dns.o  ../common/libcommonpth.a -lresolv  -lassuan -L/opt/gnupg/lib -lgpg-error -L/opt/gnupg/lib -lgcrypt -lgpg-error -L/opt/gnupg/lib -lksba -lgpg-error -L/opt/gnupg/lib -lnpth -lpthread  -L/opt/gnupg/lib -lgnutls
dirmngr.o: In function `parse_rereadable_options':
/root/src/gnupg-2.2.28/dirmngr/dirmngr.c:747: undefined reference to `ldapserver_parse_one'
/root/src/gnupg-2.2.28/dirmngr/dirmngr.c:753: undefined reference to `ldapserver_list_free'
collect2: error: ld returned 1 exit status

The config.log confirms:

  $ ./configure --prefix=/opt/gnupg --disable-nls --disable-ldap --enable-noexecstack --enable-key-cache=32768 --enable-wks-tools --with-pinentry-pgm=/opt/gnupg/bin/pinentry-curses --with-libgpg-error-prefix=/opt/gnupg --with-libassuan-prefix=/opt/gnupg --with-libgcrypt-prefix=/opt/gnupg --with-ksba-prefix=/opt/gnupg --with-npth-prefix=/opt/gnupg

I can't spend time writing a patch on this right now, so I'm posting in
the hope that the maintainers might fix this for me, so I can add an
upstream patch to my build.  :)

Thanks,
-Phil


From wk at gnupg.org  Fri Jun 11 07:50:47 2021
From: wk at gnupg.org (Werner Koch)
Date: Fri, 11 Jun 2021 07:50:47 +0200
Subject: 2.2.28 doesn't honor --disable-ldap?
In-Reply-To: <YMKCHNAkRjcNIVUb@fullerene.field.pennock-tech.net> (Phil Pennock
 via Gnupg-devel's message of "Thu, 10 Jun 2021 17:20:28 -0400")
References: <YMKCHNAkRjcNIVUb@fullerene.field.pennock-tech.net>
Message-ID: <87a6nxx83s.fsf@wheatstone.g10code.de>

On Thu, 10 Jun 2021 17:20, Phil Pennock said:

> My package builds pass `--disable-ldap` to the configure line for GnuPG;
> this does not appear to be honored any more?

Sorry, for not having tested this.  LDAP is currently pretty important
to us, so did not even thought about it.  Thanks for reporting, Gniibe
already pushed some fixes.

FWIW: Not for 2.2 but for 3.3 the plan is to move all LDAP stuff to
dirmngr_ldap so that we can get rid of the possible linking of two
different libgcrypt versions or linking to yet another crypto library
(if OpenLDAP is build against Nettle).  The other reason is that we can
properly implement a timeout for LDAP. The OpenPGP LDAP keyserver code
does not yet handle a timeout correcly because OpenLDAP has no way to to
that (e.g. during a connet attempt).  dirmngr_ldap would then run as a
co-process to keep state.


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/20210611/75a59c53/attachment-0001.sig>

From wk at gnupg.org  Fri Jun 11 07:56:57 2021
From: wk at gnupg.org (Werner Koch)
Date: Fri, 11 Jun 2021 07:56:57 +0200
Subject: [PATCH] Wipe potentially sensitive stack memory.
In-Reply-To: <1623210671-2124970.82305647.f1593p8Rc029687@rs161.luxsci.com>
 (Ben Kibbey via Gnupg-devel's message of "Tue, 8 Jun 2021 20:51:07
 -0700")
References: <1623210671-2124970.82305647.f1593p8Rc029687@rs161.luxsci.com>
Message-ID: <875yylx7ti.fsf@wheatstone.g10code.de>

Hi Ben,

On Tue,  8 Jun 2021 20:51, Ben Kibbey said:
> * src/data.c (_gpgme_data_inbound_handler): Wipe buffer before return.

Is that intended for passphrase callbacks or secret key export?  Would a
flag flagging such a data object holding sensitive data not be better?

BTW, I plan to allow for lager buffers in this function to reduce the
overhead for certain callers which don't work well with small data
blocks.  Thus a new data object flag will anyway be added.


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/20210611/2b209231/attachment.sig>

From bjk at luxsci.net  Sat Jun 12 05:25:43 2021
From: bjk at luxsci.net (Ben Kibbey)
Date: Fri, 11 Jun 2021 20:25:43 -0700
Subject: [PATCH] Wipe potentially sensitive stack memory.
In-Reply-To: <875yylx7ti.fsf@wheatstone.g10code.de>
References: <1623210671-2124970.82305647.f1593p8Rc029687@rs161.luxsci.com>
 <875yylx7ti.fsf@wheatstone.g10code.de>
Message-ID: <1623468345-2540142.52921005.f15C3PiFc085508@rs161.luxsci.com>

On Fri, Jun 11, 2021 at 07:56:57AM +0200, Werner Koch wrote:
> Hi Ben,
> 
> On Tue,  8 Jun 2021 20:51, Ben Kibbey said:
> > * src/data.c (_gpgme_data_inbound_handler): Wipe buffer before return.
> 
> Is that intended for passphrase callbacks or secret key export?  Would a
> flag flagging such a data object holding sensitive data not be better?

It is used for gpg IO during gpgme_op_decrypt_*() and other app
engines. Although normally not key material, what remains in the buffer is
decrypted data which could be anything including key material for some
other purpose. I didn't push the patch because I wasn't sure what you or
others thought about the cost/overhead of wipememory() on every call.
But I think (I'm not an ASM or CPU expert) most CPU's have a register
(MMX, SSE, etc) to help with zeroing things out and the overhead of
doing so is not very much, if any. Although it may all depend on the
libc implementation, too.

> BTW, I plan to allow for lager buffers in this function to reduce the
> overhead for certain callers which don't work well with small data
> blocks.  Thus a new data object flag will anyway be added.

OK cool.

-- 
Ben Kibbey
-------------- 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/20210611/cc7b2fd6/attachment.sig>

From wk at gnupg.org  Sat Jun 12 23:27:07 2021
From: wk at gnupg.org (Werner Koch)
Date: Sat, 12 Jun 2021 23:27:07 +0200
Subject: [PATCH] Wipe potentially sensitive stack memory.
In-Reply-To: <1623468345-2540142.52921005.f15C3PiFc085508@rs161.luxsci.com>
 (Ben Kibbey via Gnupg-devel's message of "Fri, 11 Jun 2021 20:25:43
 -0700")
References: <1623210671-2124970.82305647.f1593p8Rc029687@rs161.luxsci.com>
 <875yylx7ti.fsf@wheatstone.g10code.de>
 <1623468345-2540142.52921005.f15C3PiFc085508@rs161.luxsci.com>
Message-ID: <87bl8awz84.fsf@wheatstone.g10code.de>

On Fri, 11 Jun 2021 20:25, Ben Kibbey said:

> It is used for gpg IO during gpgme_op_decrypt_*() and other app
> engines. Although normally not key material, what remains in the buffer is
> decrypted data which could be anything including key material for some
> other purpose. I didn't push the patch because I wasn't sure what you or

Okay.  Most work will however go into the caller to keep it safe there ;-)

>> BTW, I plan to allow for lager buffers in this function to reduce the
>> overhead for certain callers which don't work well with small data
>> blocks.  Thus a new data object flag will anyway be added.
>
> OK cool.

So let me do it in the course of that patch.  I guess I can do that next
week.


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/20210612/520318bb/attachment.sig>

From jelle at vdwaa.nl  Thu Jun 24 22:56:41 2021
From: jelle at vdwaa.nl (Jelle van der Waa)
Date: Thu, 24 Jun 2021 22:56:41 +0200
Subject: [PATCH gnupg 1/2] doc: Fix typo 'usuallay' in wks docs
Message-ID: <20210624205642.13609-1-jelle@vdwaa.nl>

From: Jelle van der Waa <jelle at vdwaa.nl>

--

Signed-off-by: Jelle van der Waa <jelle at vdwaa.nl>
---
 doc/wks.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/wks.texi b/doc/wks.texi
index ad239f132..48e534b7d 100644
--- a/doc/wks.texi
+++ b/doc/wks.texi
@@ -57,7 +57,7 @@ Directory.
 
 @mansect description
 The @command{gpg-wks-client} is used to send requests to a Web Key
-Service provider.  This is usuallay done to upload a key into a Web
+Service provider.  This is usually done to upload a key into a Web
 Key Directory.
 
 With the @option{--supported} command the caller can test whether a
-- 
2.32.0



From jelle at vdwaa.nl  Thu Jun 24 22:56:42 2021
From: jelle at vdwaa.nl (Jelle van der Waa)
Date: Thu, 24 Jun 2021 22:56:42 +0200
Subject: [PATCH gnupg 2/2] doc: start new sentence with an uppercase
In-Reply-To: <20210624205642.13609-1-jelle@vdwaa.nl>
References: <20210624205642.13609-1-jelle@vdwaa.nl>
Message-ID: <20210624205642.13609-2-jelle@vdwaa.nl>

From: Jelle van der Waa <jelle at vdwaa.nl>

--

Signed-off-by: Jelle van der Waa <jelle at vdwaa.nl>
---
 doc/wks.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/wks.texi b/doc/wks.texi
index 48e534b7d..23a9a7640 100644
--- a/doc/wks.texi
+++ b/doc/wks.texi
@@ -381,7 +381,7 @@ Finally run
   $ gpg-wks-server --list-domains
 @end example
 
-to create the required sub-directories with the permissions set
+To create the required sub-directories with the permissions set
 correctly.  For each domain a submission address needs to be
 configured.  All service mails are directed to that address.  It can
 be the same address for all configured domains, for example:
-- 
2.32.0



From kloecker at kde.org  Thu Jun 24 23:37:26 2021
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Thu, 24 Jun 2021 23:37:26 +0200
Subject: [PATCH gnupg 2/2] doc: start new sentence with an uppercase
In-Reply-To: <20210624205642.13609-2-jelle@vdwaa.nl>
References: <20210624205642.13609-1-jelle@vdwaa.nl>
 <20210624205642.13609-2-jelle@vdwaa.nl>
Message-ID: <2565296.gX9a5BLuFe@breq>

On Donnerstag, 24. Juni 2021 22:56:42 CEST Jelle van der Waa wrote:
> @@ -381,7 +381,7 @@ Finally run
>    $ gpg-wks-server --list-domains
>  @end example
> 
> -to create the required sub-directories with the permissions set
> +To create the required sub-directories with the permissions set
>  correctly.  For each domain a submission address needs to be

This change is not correct because the full sentence reads

```
Finally run

@example
  $ gpg-wks-server --list-domains
@end example

to create the required sub-directories with the permissions set
correctly.
```

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/20210624/6a735ad4/attachment.sig>

From deloptes at gmail.com  Fri Jun 25 00:12:04 2021
From: deloptes at gmail.com (deloptes)
Date: Fri, 25 Jun 2021 00:12:04 +0200
Subject: recommendation for key servers
Message-ID: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>

Hi, we heard that sks-keyservers.net will be depreciated
so we were wondering what service we should use in the application default
settings
We I mean TDE devs

where do we go from here?

thank you in advance
BR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210625/04655409/attachment.html>

From vollkorn at cryptobitch.de  Fri Jun 25 08:00:11 2021
From: vollkorn at cryptobitch.de (Jan Girlich)
Date: Fri, 25 Jun 2021 08:00:11 +0200
Subject: recommendation for key servers
In-Reply-To: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
References: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
Message-ID: <8ec992faf73fcde4c358eb9af0817df660ed395d.camel@cryptobitch.de>

Hi BR,

Am Freitag, den 25.06.2021, 00:12 +0200 schrieb deloptes via Gnupg-
devel:
> Hi, we heard that sks-keyservers.net will be depreciated
> so we were wondering what service we should use in the application
> default
> settings
> We I mean TDE devs

most PGP tools default to keys.openpgp.org these days.

Cheers,
Jan



From wk at gnupg.org  Fri Jun 25 12:08:26 2021
From: wk at gnupg.org (Werner Koch)
Date: Fri, 25 Jun 2021 12:08:26 +0200
Subject: recommendation for key servers
In-Reply-To: <8ec992faf73fcde4c358eb9af0817df660ed395d.camel@cryptobitch.de>
 (Jan Girlich's message of "Fri, 25 Jun 2021 08:00:11 +0200")
References: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
 <8ec992faf73fcde4c358eb9af0817df660ed395d.camel@cryptobitch.de>
Message-ID: <87r1gql0it.fsf@wheatstone.g10code.de>

On Fri, 25 Jun 2021 08:00, Jan Girlich said:

> most PGP tools default to keys.openpgp.org these days.

Which unfortunately is a non-OpenPGP compliant keyserver and not syncing
with other keyservers.  It has the same problems as the PGP.com keyserver
from the early 2000 years.  I would suggest not to use keyservers for key
discovery but install a web key directory or an internal LDAP server or
use the AD.


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/20210625/741ab60b/attachment.sig>

From andrewg at andrewg.com  Fri Jun 25 16:00:45 2021
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Fri, 25 Jun 2021 15:00:45 +0100
Subject: recommendation for key servers
In-Reply-To: <87r1gql0it.fsf@wheatstone.g10code.de>
References: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
 <8ec992faf73fcde4c358eb9af0817df660ed395d.camel@cryptobitch.de>
 <87r1gql0it.fsf@wheatstone.g10code.de>
Message-ID: <d95abcef-51bc-ef12-cbaf-a59c91e56786@andrewg.com>

On 25/06/2021 11:08, Werner Koch via Gnupg-devel wrote:
> On Fri, 25 Jun 2021 08:00, Jan Girlich said:
> 
>> most PGP tools default to keys.openpgp.org these days.
> 
> Which unfortunately is a non-OpenPGP compliant keyserver and not syncing
> with other keyservers.  It has the same problems as the PGP.com keyserver
> from the early 2000 years.  I would suggest not to use keyservers for key
> discovery but install a web key directory or an internal LDAP server or
> use the AD.

I agree, WKD should be the first choice method to publish your own key, 
so long as you or someone PGP-friendly is in charge of your email domain 
(it's no use for gmail addresses, for example). But implementing WKD 
yourself does not help you discover other people's keys, unless you both 
belong to the same organisation (same applies to AD, LDAP etc).

Most modern software will check WKD regardless of your keyserver 
settings, so if it is in use by your correspondent's email domain, it 
should Just Work. But for the majority of users, you still have to fall 
back to another discovery method.

The keystore trilemma is not yet solved. You can have two out of three 
of decentralisation, universality, and abuse-resistance. WKD is 
decentralised and abuse-resistant but is not universal. keys.openpgp.org 
is universal and abuse-resistant but highly centralised (and 
functionally limited). Synchronising keyservers (SKS and Hockeypuck) are 
decentralised and universal but abuse-prone.

Signature attestations will help tackle many of the abuse (and 
functional limitation) issues, if we can get them standardised in a 
future openpgp update (rfc4880tris?). But we will probably have to live 
with more than one system for the foreseeable future, given the 
different compromises required.

-- 
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/20210625/ff0c10b0/attachment.sig>

From deloptes at gmail.com  Fri Jun 25 17:29:31 2021
From: deloptes at gmail.com (deloptes)
Date: Fri, 25 Jun 2021 17:29:31 +0200
Subject: recommendation for key servers
In-Reply-To: <d95abcef-51bc-ef12-cbaf-a59c91e56786@andrewg.com>
References: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
 <8ec992faf73fcde4c358eb9af0817df660ed395d.camel@cryptobitch.de>
 <87r1gql0it.fsf@wheatstone.g10code.de>
 <d95abcef-51bc-ef12-cbaf-a59c91e56786@andrewg.com>
Message-ID: <CAJJ4RaL0pxjH0GQmNunjhYvUGmXkseGRkny73UUseH2ESxwMOg@mail.gmail.com>

Hi and thank you for your responses!

On Fri, Jun 25, 2021 at 4:03 PM Andrew Gallagher via Gnupg-devel <
gnupg-devel at gnupg.org> wrote:

> On 25/06/2021 11:08, Werner Koch via Gnupg-devel wrote:
> > On Fri, 25 Jun 2021 08:00, Jan Girlich said:
> >
> >> most PGP tools default to keys.openpgp.org these days.
> >
> > Which unfortunately is a non-OpenPGP compliant keyserver and not syncing
> > with other keyservers.  It has the same problems as the PGP.com keyserver
> > from the early 2000 years.  I would suggest not to use keyservers for key
> > discovery but install a web key directory or an internal LDAP server or
> > use the AD.
>
> I agree, WKD should be the first choice method to publish your own key,
> so long as you or someone PGP-friendly is in charge of your email domain
> (it's no use for gmail addresses, for example). But implementing WKD
> yourself does not help you discover other people's keys, unless you both
> belong to the same organisation (same applies to AD, LDAP etc).
>
> Most modern software will check WKD regardless of your keyserver
> settings, so if it is in use by your correspondent's email domain, it
> should Just Work. But for the majority of users, you still have to fall
> back to another discovery method.
>
>
Our GPG Client (actually many of you may know the old KGpg client) has the
option to search for keys on a specific server by default.
>From what I hear, we can conclude that this is good by option and we have
to replace with something, but we still do not know with what :/

I would not consider it as modern software :D at least no one has the time
to work on the client and add features. So this is why I am asking here
what to do, so that the very small developers team on TDE could take the
right decision and not burn resources in vain.


> The keystore trilemma is not yet solved. You can have two out of three
> of decentralisation, universality, and abuse-resistance. WKD is
> decentralised and abuse-resistant but is not universal. keys.openpgp.org
> is universal and abuse-resistant but highly centralised (and
> functionally limited). Synchronising keyservers (SKS and Hockeypuck) are
> decentralised and universal but abuse-prone.
>
> Signature attestations will help tackle many of the abuse (and
> functional limitation) issues, if we can get them standardised in a
> future openpgp update (rfc4880tris?). But we will probably have to live
> with more than one system for the foreseeable future, given the
> different compromises required.
>
>
So to put it short in the future there will be no openpgp server(s) because
of the GDRP?
I was wondering who is objecting the existence of the SKS server. In the
mail thread (from 2018) and the message from this month, it says only about
more and more complains.
Could it be potential attack on the opengpg community - I could not follow
until the end. Can you summarize who and how took the decision to take this
server down?
Couple of years ago, I thought finally someone took care of GPG and did the
right thing, so that one can have a single server, to look for and upload
keys - now it seems it is over

thank you in advance

BR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210625/5ced014f/attachment.html>

From wk at gnupg.org  Fri Jun 25 23:06:11 2021
From: wk at gnupg.org (Werner Koch)
Date: Fri, 25 Jun 2021 23:06:11 +0200
Subject: [PATCH gnupg 1/2] doc: Fix typo 'usuallay' in wks docs
In-Reply-To: <20210624205642.13609-1-jelle@vdwaa.nl> (Jelle van der Waa's
 message of "Thu, 24 Jun 2021 22:56:41 +0200")
References: <20210624205642.13609-1-jelle@vdwaa.nl>
Message-ID: <871r8plkn0.fsf@wheatstone.g10code.de>

On Thu, 24 Jun 2021 22:56, Jelle van der Waa said:

> -Service provider.  This is usuallay done to upload a key into a Web
> +Service provider.  This is usually done to upload a key into a Web

Thanks.  I fixed that en passant.


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/20210625/bca28b78/attachment.sig>

From justus at sequoia-pgp.org  Sat Jun 26 10:55:00 2021
From: justus at sequoia-pgp.org (Justus Winter)
Date: Sat, 26 Jun 2021 10:55:00 +0200
Subject: recommendation for key servers
In-Reply-To: <d95abcef-51bc-ef12-cbaf-a59c91e56786@andrewg.com>
References: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
 <8ec992faf73fcde4c358eb9af0817df660ed395d.camel@cryptobitch.de>
 <87r1gql0it.fsf@wheatstone.g10code.de>
 <d95abcef-51bc-ef12-cbaf-a59c91e56786@andrewg.com>
Message-ID: <87sg15c8ez.fsf@europ.lan>

Andrew Gallagher via Gnupg-devel <gnupg-devel at gnupg.org> writes:

> Signature attestations will help tackle many of the abuse (and
> functional limitation) issues, if we can get them standardised in a
> future openpgp update (rfc4880tris?).

First-party attested third-party certifications (1pa3pc) as described by
Werner, Vincent, and dkg in RFC4880bis-10 are implemented in DKGPG,
PGPy, and Sequoia.  Command-line frontends for DKGPG and Sequoia can be
used to attest to certifications.

As of Thursday, keys.openpgp.org serves attested third-party
certifications in accordance with the principle of primary key
sovereignty.

I'm happy to answer any questions related to this.

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

From look at my.amazin.horse  Sat Jun 26 19:31:52 2021
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Sat, 26 Jun 2021 19:31:52 +0200
Subject: recommendation for key servers
In-Reply-To: <87r1gql0it.fsf@wheatstone.g10code.de>
References: <87r1gql0it.fsf@wheatstone.g10code.de>
 <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
 <8ec992faf73fcde4c358eb9af0817df660ed395d.camel@cryptobitch.de>
Message-ID: <20NVA9K0SPPE2.3OT3PI3V840FD@my.amazin.horse>


> Which unfortunately is a non-OpenPGP compliant keyserver

This phrasing understates the contention that exists around this point.

For those who want to read up on it and form their own opinion, a lot of
discussion happened on the GnuPG issue tracker: https://dev.gnupg.org/T4393

 - V



From wk at gnupg.org  Sun Jun 27 13:04:59 2021
From: wk at gnupg.org (Werner Koch)
Date: Sun, 27 Jun 2021 13:04:59 +0200
Subject: recommendation for key servers
In-Reply-To: <20NVA9K0SPPE2.3OT3PI3V840FD@my.amazin.horse> (Vincent Breitmoser
 via Gnupg-devel's message of "Sat, 26 Jun 2021 19:31:52 +0200")
References: <87r1gql0it.fsf@wheatstone.g10code.de>
 <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
 <8ec992faf73fcde4c358eb9af0817df660ed395d.camel@cryptobitch.de>
 <20NVA9K0SPPE2.3OT3PI3V840FD@my.amazin.horse>
Message-ID: <87im1zk1pg.fsf@wheatstone.g10code.de>

On Sat, 26 Jun 2021 19:31, Vincent Breitmoser said:

> This phrasing understates the contention that exists around this point.

I can only repeat that stripping the User-ID from a key is Bad Thing and
more of a willfully created tombstone for OpenPGP.  The pleaded GDPR
issue is artificial and entirely ignores the fact that the key or its
fingerprint is as well personal data (?any information which [is]
related to an identified or identifiable natural person?) and thus
subject to the GDPR rules.

But that is all no problem if the user consented to store the data on a
public server (for example by means of a warning dialog).  There are
other exceptions as well, for example the legal requirement to protect
the communication can be be viewed as an exception for an explicit
consent.  This is why some mail providers only allow the mail address as
user ID in a key because that is the only technically required part of
the user id (see the long standing German principle of
Datensparsamkeit).


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/20210627/430601fb/attachment.sig>

From tobias.wendorff at tu-dortmund.de  Sun Jun 27 13:20:43 2021
From: tobias.wendorff at tu-dortmund.de (Tobias Wendorff)
Date: Sun, 27 Jun 2021 13:20:43 +0200
Subject: recommendation for key servers
In-Reply-To: <87im1zk1pg.fsf@wheatstone.g10code.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>
Message-ID: <bea92fba-eb33-65b3-f0dc-7250716afa96@tu-dortmund.de>

Am 27.06.2021 um 13:04 schrieb Werner Koch via Gnupg-devel:
 > But that is all no problem if the user consented to store the data
 > on a public server (for example by means of a warning dialog).

Actually right now, you can upload any public-key from anyone, at least 
on https://keys.openpgp.org/upload and https://pgp.mit.edu/ (without a 
GPDR message, just some terms of use or FAQ).

So maybe sign the contenting process using the private key in future?


From look at my.amazin.horse  Sun Jun 27 22:14:31 2021
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Sun, 27 Jun 2021 22:14:31 +0200
Subject: recommendation for key servers
In-Reply-To: <87im1zk1pg.fsf@wheatstone.g10code.de>
References: <87im1zk1pg.fsf@wheatstone.g10code.de>
 <87r1gql0it.fsf@wheatstone.g10code.de>
 <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
 <8ec992faf73fcde4c358eb9af0817df660ed395d.camel@cryptobitch.de>
 <20NVA9K0SPPE2.3OT3PI3V840FD@my.amazin.horse>
Message-ID: <27Q19XPL97L7I.3UN4YYRHUXJ93@my.amazin.horse>


Hi Werner,

> I can only repeat that stripping the User-ID from a key is Bad Thing

I've actually never seen this argument in full. I just checked T4393 again, the
only explanation you give is "to avoid problems we had with PGP2". Would you
care to elaborate?

> The pleaded GDPR issue is artificial

IIRC Kristian very much doesn't believe in the GDPR, and yet he *just*
discontinued the pool because it caused him too much GDPR legal trouble, which
is a direct consequence of SKS publishing email addresses without explicit
consent. Perhaps I'm misunderstanding what you are describing as "artificial"?

> and entirely ignores the fact that the key or its fingerprint is as well
> personal data (?any information which [is] related to an identified or
> identifiable natural person?) and thus subject to the GDPR rules.

I'm inclined to agree on this one, actually. :) Maybe I'll rephrase the privacy
policy of keys.o.o one of these days, but so far it worked out ok.

 - V



From jharris at widomaker.com  Mon Jun 28 01:41:16 2021
From: jharris at widomaker.com (Jason Harris)
Date: Sun, 27 Jun 2021 19:41:16 -0400
Subject: recommendation for key servers
In-Reply-To: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
References: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
Message-ID: <2E8218E9-5680-4F4B-BE6F-3F7EE7CD96EA@widomaker.com>


There are still SKS servers running, but several are unsynchronized, including, apparently, pgp.mit.edu.  Of course, they have the same key import/poisoning problems already mentioned on these lists?

Here are the hockeypuck servers I could find, all synchronizing properly and apparently exchanging data (minus the unwanted packets) with the SKS servers that are synchronized:
http://keys.andreas-puls.de/pks/lookup?op=stats
http://keys2.andreas-puls.de/pks/lookup?op=stats
http://keys3.andreas-puls.de/pks/lookup?op=stats
http://pgp.cyberbits.eu/pks/lookup?op=stats
http://pgp.re:11371/pks/lookup?op=stats
https://pgpkeys.eu/pks/lookup?op=stats
https://keybath.trifence.ch/pks/lookup?op=stats
https://keyserver.trifence.ch/pks/lookup?op=stats
HTH.  (Please excuse the HTML.)

Sent from my iPad

> On Jun 24, 2021, at 7:19 PM, deloptes via Gnupg-devel <gnupg-devel at gnupg.org> wrote:
> 
> ?
> Hi, we heard that sks-keyservers.net will be depreciated 
> so we were wondering what service we should use in the application default settings
> We I mean TDE devs
> 
> where do we go from here?
> 
> thank you in advance
> BR
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210627/92b51b85/attachment.html>

From andrewg at andrewg.com  Mon Jun 28 10:42:42 2021
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 28 Jun 2021 09:42:42 +0100
Subject: recommendation for key servers
In-Reply-To: <2E8218E9-5680-4F4B-BE6F-3F7EE7CD96EA@widomaker.com>
References: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
 <2E8218E9-5680-4F4B-BE6F-3F7EE7CD96EA@widomaker.com>
Message-ID: <cab7e50d-498a-296b-8d0a-47f4026c74d9@andrewg.com>

On 28/06/2021 00:41, Jason Harris via Gnupg-devel wrote:
 >
> Here are the hockeypuck servers I could find, all synchronizing properly 
> and apparently exchanging data (minus the unwanted packets) with the SKS 
> servers that are synchronized:
> 
>   * http://keys.andreas-puls.de/pks/lookup?op=stats
>   * http://keys2.andreas-puls.de/pks/lookup?op=stats
>   * http://keys3.andreas-puls.de/pks/lookup?op=stats
>   * http://pgp.cyberbits.eu/pks/lookup?op=stats
>   * http://pgp.re:11371/pks/lookup?op=stats
>   * https://pgpkeys.eu/pks/lookup?op=stats
>   * https://keybath.trifence.ch/pks/lookup?op=stats
>   * https://keyserver.trifence.ch/pks/lookup?op=stats

To these you can add:

* https://east.keyserver.us (stats page is misleading; it does sync)
* https://west.keyserver.us
* https://keyserver.dobrev.eu (down right now, but is normally reliable)
* https://openpgp.circl.lu (stats page is misleading; it does sync)
* https://keyserver.snt.utwente.nl

> HTH. ?(Please excuse the HTML.)

De-HTMLified. ;-)

-- 
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/20210628/0d5296f8/attachment.sig>

From andrewg at andrewg.com  Mon Jun 28 11:00:51 2021
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Mon, 28 Jun 2021 10:00:51 +0100
Subject: recommendation for key servers
In-Reply-To: <CAJJ4RaL0pxjH0GQmNunjhYvUGmXkseGRkny73UUseH2ESxwMOg@mail.gmail.com>
References: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
 <8ec992faf73fcde4c358eb9af0817df660ed395d.camel@cryptobitch.de>
 <87r1gql0it.fsf@wheatstone.g10code.de>
 <d95abcef-51bc-ef12-cbaf-a59c91e56786@andrewg.com>
 <CAJJ4RaL0pxjH0GQmNunjhYvUGmXkseGRkny73UUseH2ESxwMOg@mail.gmail.com>
Message-ID: <9d390945-2380-8d18-3931-acad5e572647@andrewg.com>

On 25/06/2021 16:29, deloptes via Gnupg-devel wrote:
> 
> So to put it short in the future there will be no openpgp server(s) 
> because of the GDRP?

I wouldn't go that far, but GDPR does pose technical challenges - many 
of which were already known.

> I was wondering who is objecting the existence of the SKS server. In the 
> mail thread (from 2018) and the message from this month, it says only 
> about more and more complains.
Anyone making a data deletion request under GDPR should not have their 
email address widely shared, so we do not (and should not) know the 
details of who has been contacting Kristian directly.

> Could it be potential attack on the opengpg community - I could not 
> follow until the end. Can you summarize who and how took the decision to 
> take this server down?

Kristian has been running sks-keyservers.net by himself for quite some 
time as a service to the community. Progressively more software is using 
keys.openpgp.org by default, so the cost/benefit ratio of keeping 
sks-keyservers.net alive has changed. There have been sabotage attempts 
against the keyserver network (malicious or misguided, it's not clear) 
but we should not assume that people exercising their rights under data 
protection law are in any way associated with those.

> Couple of years ago, I thought finally someone took care of GPG and did 

> the right thing, so that one can have a single server, to look for and 
> upload keys - now it seems it is over

You are probably thinking of keys.openpgp.org. It isn't the final answer 
either, it just weighs its compromises differently...

-- 
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/20210628/ff0e59a1/attachment-0001.sig>

From jeanjacquesbrucker at gmail.com  Mon Jun 28 11:41:43 2021
From: jeanjacquesbrucker at gmail.com (Jean-Jacques Brucker)
Date: Mon, 28 Jun 2021 11:41:43 +0200
Subject: recommendation for key servers
In-Reply-To: <2E8218E9-5680-4F4B-BE6F-3F7EE7CD96EA@widomaker.com>
References: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
 <2E8218E9-5680-4F4B-BE6F-3F7EE7CD96EA@widomaker.com>
Message-ID: <9db62a14-4605-0636-bd61-83ceafb1d271@gmail.com>


"Hell is paved with good intention."

GDPR came from the laudable intention of limiting the power of GAFAMs 
and other data brokers, inside our private lives.

But the text maintains a confusion between personal data and private 
data. Some personal data is not and should not be private. Email could 
be one of them, if everyone used a web of trust, which would allow us to 
know more precisely who is the sender, and to fight more effectively 
against SPAM.

(NB: In addition, the text annoys small organizations more than large 
groups which have the means to circumvent it, via internationalization 
and lobbying)

I have a public email, and i would like to have a email service or 
client which may delete automatically unsigned messages, and give me the 
feature to order received email depending from a "proximity" regarding 
the WOT, or a "confidence" regarding my trustdb.

About the keystore, I imagined 9 years ago that a key server receiving a 
certificate update, not signed by its owner, could send a message to the 
owner (by default 1 time per day), in order to ask it to validate, or 
not, the modifications, before synchronizing the updated certificate, 
signed by its owner, on other key servers.

So I had to write a draft and start implementing a new MIME type for 
HTTP for these purposes, to upgrade HKP protocol :

https://github.com/Open-UDC/open-udc/blob/master/docs/rfc/HTTP_OpenPGP_Authentication.draft.txt

https://github.com/Open-UDC/thttpgpd

But unfortunately I was perhaps too shy to talk about these ideas on an 
international mailing list, and they received little echo in my French 
environment :

https://linuxfr.org/users/jbar/journaux/thttpgpd-ou-comment-openudc-a-ressuscite-le-bon-vieux-thttpd


Today WKD / WKS seems to me a good compromise for the trilemma keystore, 
and probably the best way to get the last version of 
"first-party-attested" certificates, which fresh uid / sub-keys updates 
and revocations.

But it's only today that I discovered your git repository 
https://gitlab.com/openpgp-wg/rfc4880bis and your idea of 
??"first-party-attested third-party certifications" (1pa3pc).

I therefore apologize if I do not add anything new or interesting to the 
debate today.

----
Jean-Jacques B.


Le 28/06/2021 ? 01:41, Jason Harris via Gnupg-devel a ?crit?:
>
> There are still SKS servers running, but several are unsynchronized, 
> including, apparently, pgp.mit.edu. ?Of course, they have the same key 
> import/poisoning problems already mentioned on these lists?
>
> Here are the hockeypuck servers I could find, all synchronizing 
> properly and apparently exchanging data (minus the unwanted packets) 
> with the SKS servers that are synchronized:
>
>   * http://keys.andreas-puls.de/pks/lookup?op=stats
>   * http://keys2.andreas-puls.de/pks/lookup?op=stats
>   * http://keys3.andreas-puls.de/pks/lookup?op=stats
>   * http://pgp.cyberbits.eu/pks/lookup?op=stats
>   * http://pgp.re:11371/pks/lookup?op=stats
>   * https://pgpkeys.eu/pks/lookup?op=stats
>   * https://keybath.trifence.ch/pks/lookup?op=stats
>   * https://keyserver.trifence.ch/pks/lookup?op=stats
>
> HTH. ?(Please excuse the HTML.)
>
> Sent from my iPad
>
>> On Jun 24, 2021, at 7:19 PM, deloptes via Gnupg-devel 
>> <gnupg-devel at gnupg.org> wrote:
>>
>> ?
>> Hi, we heard that sks-keyservers.net <http://sks-keyservers.net> will 
>> be depreciated
>> so we were wondering what service we should use in the application 
>> default settings
>> We I mean TDE devs
>>
>> where do we go from here?
>>
>> thank you in advance
>> BR
>> _______________________________________________
>> Gnupg-devel mailing list
>> Gnupg-devel at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210628/32529101/attachment-0001.html>
-------------- 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/20210628/32529101/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/20210628/32529101/attachment-0001.sig>

From bernhard at intevation.de  Tue Jun 29 15:16:13 2021
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 29 Jun 2021 15:16:13 +0200
Subject: recommendation for key servers
In-Reply-To: <d95abcef-51bc-ef12-cbaf-a59c91e56786@andrewg.com>
References: <CAJJ4RaKGVBfmRj8Bcz-ajx5-scxuJ8Zswe_gFrivcNQw94GiEA@mail.gmail.com>
 <87r1gql0it.fsf@wheatstone.g10code.de>
 <d95abcef-51bc-ef12-cbaf-a59c91e56786@andrewg.com>
Message-ID: <202106291516.13539.bernhard@intevation.de>

Am Freitag 25 Juni 2021 16:00:45 schrieb Andrew Gallagher via Gnupg-devel:
> Synchronising keyservers (SKS and Hockeypuck) are
> decentralised and universal but abuse-prone.

It seems possible to get the abuse-potential of synchronising keyservers unter 
control. (While the abuse-potential of central and validating keyservers is 
also there, but in a different are.)

I've outlined the concepts how this could be done here:
 Preserving non-central and privacy with a "permission recording keyserver"
    [Reiter 2019-07 a]
 https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034399.html

  Preserving third party signatures distribution [Reiter 2019-07 b]
 https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034394.html

Overall there has not been enough efforts going into preserving
the decentral network of public keyservers.

> Signature attestations will help tackle many of the abuse (and
> functional limitation) issues, if we can get them standardised

That is a possible puzzle piece of the solution.
(While I am not usre if it depends on standardisation.)

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/20210629/029c9bdf/attachment.sig>

From wk at gnupg.org  Tue Jun 29 19:27:17 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 29 Jun 2021 19:27:17 +0200
Subject: recommendation for key servers
In-Reply-To: <bea92fba-eb33-65b3-f0dc-7250716afa96@tu-dortmund.de> (Tobias
 Wendorff's message of "Sun, 27 Jun 2021 13:20:43 +0200")
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: <87tulgfuoa.fsf@wheatstone.g10code.de>

On Sun, 27 Jun 2021 13:20, Tobias Wendorff said:

> So maybe sign the contenting process using the private key in future?

Casey Marshall wrote in the Hockeypuck 2.1 announcement [1]:

  - Authenticated key management. This adds a couple of extra endpoints
    which allow a key owner to replace and delete their key,
    authenticated by signing the armored key in the request. This allows
    a key owner to still update their own key once it has been inflated
    beyond the key length limit.

  Blacklists and auth key management may also be of interest to keyserver
  operators subject to GDPR-related requests.

However there was not much followup on this.  If there is something in
GnuPG we can do to support these features, we should do that sooner than
later.

In the meantime I will release 2.2.29 with the default keyserver changed
from the sks pool to the Ubuntu keyserver.  I considered to use the
classic pgp.surfnet.nl server but that one would again require a
dedicated certificate which does not seem to be appropriate for
intermediate change of the default.  I also considered several other
Hockeypuck servers but most of them return garbled OpenPGP keyblocks
which can't be used by GnuPG.


Shalom-Salam,

   Werner


[1]
https://lists.gnupg.org/pipermail/gnupg-users/2020-December/064434.html
-- 
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/20210629/76062ae8/attachment.sig>

From andrewg at andrewg.com  Wed Jun 30 00:00:16 2021
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Tue, 29 Jun 2021 23:00:16 +0100
Subject: recommendation for key servers
In-Reply-To: <87tulgfuoa.fsf@wheatstone.g10code.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>
 <87tulgfuoa.fsf@wheatstone.g10code.de>
Message-ID: <3d7c96e1-4733-d7fc-6e3e-5d0ccb94180c@andrewg.com>

On 29/06/2021 18:27, Werner Koch via Gnupg-devel wrote:
> I also considered several other
> Hockeypuck servers but most of them return garbled OpenPGP keyblocks
> which can't be used by GnuPG.

Hi, Werner.

Can you be more specific? Is this all keys on some keyservers, specific 
keys on all servers? Is it reproducible?

-- 
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/20210629/5d00a7d1/attachment.sig>

From justus at sequoia-pgp.org  Wed Jun 30 12:18:23 2021
From: justus at sequoia-pgp.org (Justus Winter)
Date: Wed, 30 Jun 2021 12:18:23 +0200
Subject: recommendation for key servers
In-Reply-To: <87tulgfuoa.fsf@wheatstone.g10code.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>
 <87tulgfuoa.fsf@wheatstone.g10code.de>
Message-ID: <87v95v3bbk.fsf@europ.lan>

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

> On Sun, 27 Jun 2021 13:20, Tobias Wendorff said:
>
>> So maybe sign the contenting process using the private key in future?
>
> Casey Marshall wrote in the Hockeypuck 2.1 announcement [1]:
>
>   - Authenticated key management. This adds a couple of extra endpoints
>     which allow a key owner to replace and delete their key,
>     authenticated by signing the armored key in the request. This allows
>     a key owner to still update their own key once it has been inflated
>     beyond the key length limit.
>
>   Blacklists and auth key management may also be of interest to keyserver
>   operators subject to GDPR-related requests.
>
> However there was not much followup on this.  If there is something in
> GnuPG we can do to support these features, we should do that sooner than
> later.

I fear that the mechanism has not been very well designed.  In short, I
believe it is not complete, not functional, and dangerous:

https://github.com/hockeypuck/hockeypuck/issues/136

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

From andrewg at andrewg.com  Wed Jun 30 12:25:43 2021
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 30 Jun 2021 11:25:43 +0100
Subject: recommendation for key servers
In-Reply-To: <87tulgfuoa.fsf@wheatstone.g10code.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>
 <87tulgfuoa.fsf@wheatstone.g10code.de>
Message-ID: <ece4702a-129b-d075-36a2-8bbe6204ae20@andrewg.com>

On 29/06/2021 18:27, Werner Koch via Gnupg-devel wrote:
> In the meantime I will release 2.2.29 with the default keyserver changed
> from the sks pool to the Ubuntu keyserver.

I think a large part of the problem is having to decide on *the* default 
keyserver. If it was possible to supply a list of preferred keyservers, 
it would remove a single point of failure from the system.

-- 
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/20210630/8a9259b4/attachment.sig>

From andrewg at andrewg.com  Wed Jun 30 19:35:25 2021
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Wed, 30 Jun 2021 18:35:25 +0100
Subject: recommendation for key servers
In-Reply-To: <202106291516.13539.bernhard@intevation.de>
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>
Message-ID: <5f14a423-30c5-4ee6-98cf-00610c961f33@andrewg.com>

On 29/06/2021 14:16, Bernhard Reiter wrote:
> 
> It seems possible to get the abuse-potential of synchronising keyservers unter
> control. (While the abuse-potential of central and validating keyservers is
> also there, but in a different are.)
> 
> I've outlined the concepts how this could be done here:
>   Preserving non-central and privacy with a "permission recording keyserver"
>      [Reiter 2019-07 a]
>   https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034399.html

I think you meant to link to the previous message... ;-)

https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034388.html

The "permission-recording keyserver" as described here requires the 
various keyserver operators to trust each other to validate these 
permissions correctly. 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. But how this interplays with the sync process, 
particularly with the subjectivity of trust relationships, gets tricky.

The use of arbitrary data in IDs is problematic; even IDs that validate 
as "correct" email addresses can still be abused. I don't think we need 
to solve all of these issues straight away, but some of the low hanging 
fruit (e.g. UATs containing abusive images) could be eliminated very 
quickly if we collectively agreed.

Deletion due to either RTBF or abusive behaviour is possible through 
blacklisting, as implemented now in Hockeypuck. This has knock-on 
effects on sync (again due to subjectivity) but they are manageable for now.

I think the best way to approach user IDs is to think of keystores 
(including keyservers, but also WKD, DANE etc) as performing two 
separate functions: discovery and refresh. Discovery is a 
human-to-machine operation that finds key material and certifications 
based on the user ID, and refresh is a purely machine (and preferably 
automated) operation that finds key material and certifications based on 
the fingerprint.

The main reason we are having GDPR problems now is that the original 
design of the PGP public key did not properly separate these functions. 
At no point in any reasonable scenario do we need to find all user IDs 
of a key based solely on knowing the fingerprint, nor do we ever need to 
find a third-party sig made by a key that we do not already have or 
trust. But the design encourages (and in some cases forces) us to bundle 
all of this data together, effectively as a blob.

We need to unpick this, and work with much smaller atoms of key 
material, bigger than packets but smaller than entire "public keys" 
(such unfortunate terminology that we're now stuck with), so we can be 
more selective about what we distribute in a given context.

>    Preserving third party signatures distribution [Reiter 2019-07 b]
>   https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034394.html

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.

> Overall there has not been enough efforts going into preserving
> the decentral network of public keyservers.

I agree. I think hockeypuck and hagrid are approaching the same problem 
from opposite ends - the optimum is somewhere in the middle, if we can 
find it.

>> Signature attestations will help tackle many of the abuse (and
>> functional limitation) issues, if we can get them standardised
> 
> That is a possible puzzle piece of the solution.
> (While I am not usre if it depends on standardisation.)

Wide adoption is the goal, and while I think standardisation can help 
with that, it is not strictly necessary of course.

-- 
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/20210630/24b4cb8f/attachment-0001.sig>

From wk at gnupg.org  Wed Jun 30 19:45:29 2021
From: wk at gnupg.org (Werner Koch)
Date: Wed, 30 Jun 2021 19:45:29 +0200
Subject: recommendation for key servers
In-Reply-To: <87v95v3bbk.fsf@europ.lan> (Justus Winter's message of "Wed, 30
 Jun 2021 12:18:23 +0200")
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>
 <87tulgfuoa.fsf@wheatstone.g10code.de> <87v95v3bbk.fsf@europ.lan>
Message-ID: <87czs3fdqe.fsf@wheatstone.g10code.de>

On Wed, 30 Jun 2021 12:18, Justus Winter said:

> I fear that the mechanism has not been very well designed.  In short, I
> believe it is not complete, not functional, and dangerous:
>
> https://github.com/hockeypuck/hockeypuck/issues/136

Find below a copy of Justus' comment


Salam-Shalom,

   Werner


===
teythoon commented 8 hours ago

I have grave concerns regarding the authenticated key replacement
mechanism as proposed by HIP-1 and implemented in current hockeypuck
versions. I believe it to be not complete, not functional, and
dangerous.

First, because it uses OpenPGP's detached signature mechanism, it
requires a signing-capable (sub)key. Therefore, the mechanism fails to
protect OpenPGP certificates without signing-capable (sub)key. The
solution is not complete.

Second, after a key has been replaced with a clean version, presumably
to get rid of a flood of certifications, an attacker can simply re-add
the certifications. The replacement mechanism does not assure
sovereignty, only a momentarily relief. Therefore, the solution is not
functional.

I haven't looked into how gossiping plays into that, but if gossiping
uses the same policy as updates using hkp, then gossiping will also
re-add any third party certifications.

Third, the pair of keytext and keysig are a capability to reset the copy
of the certificate on the server to keytext. If a malicious party ever
gets hold of such a pair, then they have the ability to remove updates
from the certificate stored on the server. Undoing an update that
extends the validity period of a certificate leads to an DoS because the
certificate can no longer be used (e.g. for encryption). Undoing an
update that revokes a key leads to a certificate being used even though
it shouldn't, compromising authenticity and confidentiality. Therefore,
I conclude that the mechanism is dangerous.


-- 
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/20210630/8f4c900e/attachment.sig>