From paaguti at gmail.com  Sun Apr  2 13:00:13 2023
From: paaguti at gmail.com (Pedro Andres Aranda Gutierrez)
Date: Sun, 2 Apr 2023 13:00:13 +0200
Subject: gpg-error not detected when compiling libksba:
Message-ID: <CAO48Bk-sJazKW3DG4w9Mx9xkw_0P6Tr4w84K0PEvmmmoMzEDWA@mail.gmail.com>

I'm trying to compile libksba ad I get the following error:

checking whether the visibility attribute is supported... no
checking for gpg-error-config... no
checking for gpgrt-config... /usr/local/bin/gpgrt-config
checking for GPG Error - version >= 1.8... no
configure: error: libgpg-error is needed.
                See ftp://ftp.gnupg.org/gcrypt/libgpg-error/ .

Whoever, gpg-error is installed and I can find the .pc file:

libksba-build ? ls /usr/local/lib/pkgconfig/*gpg*
                                               git:master*
/usr/local/lib/pkgconfig/gpg-error.pc

libksba 1.6.2 and libgpg-error 1.46



-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet


From noloader at gmail.com  Sun Apr  2 17:04:05 2023
From: noloader at gmail.com (Jeffrey Walton)
Date: Sun, 2 Apr 2023 11:04:05 -0400
Subject: gpg-error not detected when compiling libksba:
In-Reply-To: <CAO48Bk-sJazKW3DG4w9Mx9xkw_0P6Tr4w84K0PEvmmmoMzEDWA@mail.gmail.com>
References: <CAO48Bk-sJazKW3DG4w9Mx9xkw_0P6Tr4w84K0PEvmmmoMzEDWA@mail.gmail.com>
Message-ID: <CAH8yC8mX+D9ZyqMNAD7FMRCBfr6NuPow_S=YMEeJAK98BBh1fA@mail.gmail.com>

On Sun, Apr 2, 2023 at 8:11?AM Pedro Andres Aranda Gutierrez via
Gnupg-devel <gnupg-devel at gnupg.org> wrote:
>
> I'm trying to compile libksba ad I get the following error:
>
> checking whether the visibility attribute is supported... no
> checking for gpg-error-config... no
> checking for gpgrt-config... /usr/local/bin/gpgrt-config
> checking for GPG Error - version >= 1.8... no
> configure: error: libgpg-error is needed.
>                 See ftp://ftp.gnupg.org/gcrypt/libgpg-error/ .
>
> Whoever, gpg-error is installed and I can find the .pc file:
>
> libksba-build ? ls /usr/local/lib/pkgconfig/*gpg*
>                                                git:master*
> /usr/local/lib/pkgconfig/gpg-error.pc
>
> libksba 1.6.2 and libgpg-error 1.46

Ensure pkg-config package is installed. Then, set PKG_CONFIG_PATH
before invoking configure.

Jeff


From gniibe at fsij.org  Mon Apr  3 04:21:30 2023
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 03 Apr 2023 11:21:30 +0900
Subject: gpg-error not detected when compiling libksba:
In-Reply-To: <CAO48Bk-sJazKW3DG4w9Mx9xkw_0P6Tr4w84K0PEvmmmoMzEDWA@mail.gmail.com>
References: <CAO48Bk-sJazKW3DG4w9Mx9xkw_0P6Tr4w84K0PEvmmmoMzEDWA@mail.gmail.com>
Message-ID: <87zg7pu2mt.fsf@akagi.fsij.org>

Hello,

Pedro Andres Aranda Gutierrez wrote:
> libksba 1.6.2 and libgpg-error 1.46

Please try libksba 1.6.3, which has a change for libgpg-error detection.
-- 


From paaguti at gmail.com  Mon Apr  3 07:29:56 2023
From: paaguti at gmail.com (Pedro Andres Aranda Gutierrez)
Date: Mon, 3 Apr 2023 07:29:56 +0200
Subject: gpg-error not detected when compiling libksba:
In-Reply-To: <87zg7pu2mt.fsf@akagi.fsij.org>
References: <CAO48Bk-sJazKW3DG4w9Mx9xkw_0P6Tr4w84K0PEvmmmoMzEDWA@mail.gmail.com>
 <87zg7pu2mt.fsf@akagi.fsij.org>
Message-ID: <CAO48Bk9JHk79xYW+KmBK-XydTY_Ee6DY_jH8wrEAGuibXB_T2Q@mail.gmail.com>

Thank you so much. That was the real solution to the problem :-)

BR,/PA


On Mon, 3 Apr 2023 at 04:21, NIIBE Yutaka <gniibe at fsij.org> wrote:
>
> Hello,
>
> Pedro Andres Aranda Gutierrez wrote:
> > libksba 1.6.2 and libgpg-error 1.46
>
> Please try libksba 1.6.3, which has a change for libgpg-error detection.
> --



--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet


From paaguti at gmail.com  Wed Apr  5 09:08:51 2023
From: paaguti at gmail.com (Pedro Andres Aranda Gutierrez)
Date: Wed, 5 Apr 2023 09:08:51 +0200
Subject: gpg-error not detected when compiling libksba:
In-Reply-To: <CAO48Bk9JHk79xYW+KmBK-XydTY_Ee6DY_jH8wrEAGuibXB_T2Q@mail.gmail.com>
References: <CAO48Bk-sJazKW3DG4w9Mx9xkw_0P6Tr4w84K0PEvmmmoMzEDWA@mail.gmail.com>
 <87zg7pu2mt.fsf@akagi.fsij.org>
 <CAO48Bk9JHk79xYW+KmBK-XydTY_Ee6DY_jH8wrEAGuibXB_T2Q@mail.gmail.com>
Message-ID: <CAO48Bk9NwVip7UMG6+ZqUEq-XzAX74qEeAPvfV0jeTCiNuMwZQ@mail.gmail.com>

Hi again

I'm currently experiencing the same problem with libgcrypt 1.10.1
I have the same libgpg-error as with libksba and then:

tar -xvf libgcrypt-1.10.1.tar.bz2
cd libgcrypt-1.10.1
./autogen.sh
make

And I get

checking for gpg-error-config... no
checking for gpgrt-config... /usr/local/bin/gpgrt-config
checking for GPG Error - version >= 1.27... no
configure: error: libgpg-error is needed.
                See ftp://ftp.gnupg.org/gcrypt/libgpg-error/ .


despite having libgpg-error installed and accessible:

libgcrypt-1.10.1 ? gpgrt-config
Please use --libdir=LIBDIR option or set PKG_CONFIG_LIBDIR
Or set PKG_CONFIG_PATH

Thank you for any help...
/PA


On Mon, 3 Apr 2023 at 07:29, Pedro Andres Aranda Gutierrez <
paaguti at gmail.com> wrote:

> Thank you so much. That was the real solution to the problem :-)
>
> BR,/PA
>
>
> On Mon, 3 Apr 2023 at 04:21, NIIBE Yutaka <gniibe at fsij.org> wrote:
> >
> > Hello,
> >
> > Pedro Andres Aranda Gutierrez wrote:
> > > libksba 1.6.2 and libgpg-error 1.46
> >
> > Please try libksba 1.6.3, which has a change for libgpg-error detection.
> > --
>
>
>
> --
> Fragen sind nicht da um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
> run a leader-deposed hook here, but we can't yet
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20230405/25fcac5a/attachment.html>

From cllang at redhat.com  Wed Apr  5 10:48:49 2023
From: cllang at redhat.com (Clemens Lang)
Date: Wed, 5 Apr 2023 10:48:49 +0200
Subject: gpg-error not detected when compiling libksba:
In-Reply-To: <CAO48Bk9NwVip7UMG6+ZqUEq-XzAX74qEeAPvfV0jeTCiNuMwZQ@mail.gmail.com>
References: <CAO48Bk-sJazKW3DG4w9Mx9xkw_0P6Tr4w84K0PEvmmmoMzEDWA@mail.gmail.com>
 <87zg7pu2mt.fsf@akagi.fsij.org>
 <CAO48Bk9JHk79xYW+KmBK-XydTY_Ee6DY_jH8wrEAGuibXB_T2Q@mail.gmail.com>
 <CAO48Bk9NwVip7UMG6+ZqUEq-XzAX74qEeAPvfV0jeTCiNuMwZQ@mail.gmail.com>
Message-ID: <5941988F-4F6B-45C4-832C-6FC66F7EC101@redhat.com>

Hi,

Pedro Andres Aranda Gutierrez via Gnupg-devel <gnupg-devel at gnupg.org> wrote:

> Hi again
>
> I'm currently experiencing the same problem with libgcrypt 1.10.1
> I have the same libgpg-error as with libksba and then:
>
> tar -xvf libgcrypt-1.10.1.tar.bz2
> cd libgcrypt-1.10.1
> ./autogen.sh
> make
>
> And I get
>
> checking for gpg-error-config... no
> checking for gpgrt-config... /usr/local/bin/gpgrt-config
> checking for GPG Error - version >= 1.27... no
> configure: error: libgpg-error is needed.
>                 See ftp://ftp.gnupg.org/gcrypt/libgpg-error/ .
>
>
> despite having libgpg-error installed and accessible:
>
> libgcrypt-1.10.1 ? gpgrt-config
> Please use --libdir=LIBDIR option or set PKG_CONFIG_LIBDIR
> Or set PKG_CONFIG_PATH
>
> Thank you for any help...

Try again with

   https://dev.gnupg.org/rCbcf5922eaac274f5ace991ecace01e718a9fe964

That fixed the issue in CentOS 8.


HTH,
Clemens

-- 
Clemens Lang
RHEL Crypto Team
Red Hat





From paaguti at gmail.com  Thu Apr  6 07:28:32 2023
From: paaguti at gmail.com (Pedro Andres Aranda Gutierrez)
Date: Thu, 6 Apr 2023 07:28:32 +0200
Subject: gpg-error not detected when compiling libksba:
In-Reply-To: <5941988F-4F6B-45C4-832C-6FC66F7EC101@redhat.com>
References: <CAO48Bk-sJazKW3DG4w9Mx9xkw_0P6Tr4w84K0PEvmmmoMzEDWA@mail.gmail.com>
 <87zg7pu2mt.fsf@akagi.fsij.org>
 <CAO48Bk9JHk79xYW+KmBK-XydTY_Ee6DY_jH8wrEAGuibXB_T2Q@mail.gmail.com>
 <CAO48Bk9NwVip7UMG6+ZqUEq-XzAX74qEeAPvfV0jeTCiNuMwZQ@mail.gmail.com>
 <5941988F-4F6B-45C4-832C-6FC66F7EC101@redhat.com>
Message-ID: <CAO48Bk-A2uGBjP91iXAHJvPoEdf4N8XbC6j0q2mvtOHDypjrWA@mail.gmail.com>

Could you please provide a patch against libgcrypt-1.10.1. I tried myself,
but without any luck.

Thx a ton.
/PA

On Wed, 5 Apr 2023 at 10:48, Clemens Lang <cllang at redhat.com> wrote:

> Hi,
>
> Pedro Andres Aranda Gutierrez via Gnupg-devel <gnupg-devel at gnupg.org>
> wrote:
>
> > Hi again
> >
> > I'm currently experiencing the same problem with libgcrypt 1.10.1
> > I have the same libgpg-error as with libksba and then:
> >
> > tar -xvf libgcrypt-1.10.1.tar.bz2
> > cd libgcrypt-1.10.1
> > ./autogen.sh
> > make
> >
> > And I get
> >
> > checking for gpg-error-config... no
> > checking for gpgrt-config... /usr/local/bin/gpgrt-config
> > checking for GPG Error - version >= 1.27... no
> > configure: error: libgpg-error is needed.
> >                 See ftp://ftp.gnupg.org/gcrypt/libgpg-error/ .
> >
> >
> > despite having libgpg-error installed and accessible:
> >
> > libgcrypt-1.10.1 ? gpgrt-config
> > Please use --libdir=LIBDIR option or set PKG_CONFIG_LIBDIR
> > Or set PKG_CONFIG_PATH
> >
> > Thank you for any help...
>
> Try again with
>
>    https://dev.gnupg.org/rCbcf5922eaac274f5ace991ecace01e718a9fe964
>
> That fixed the issue in CentOS 8.
>
>
> HTH,
> Clemens
>
> --
> Clemens Lang
> RHEL Crypto Team
> Red Hat
>
>
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20230406/56a2b551/attachment.html>

From tmz at pobox.com  Fri Apr  7 03:46:47 2023
From: tmz at pobox.com (Todd Zullinger)
Date: Thu, 6 Apr 2023 21:46:47 -0400
Subject: gpg-error not detected when compiling libksba:
In-Reply-To: <CAO48Bk-A2uGBjP91iXAHJvPoEdf4N8XbC6j0q2mvtOHDypjrWA@mail.gmail.com>
References: <CAO48Bk-sJazKW3DG4w9Mx9xkw_0P6Tr4w84K0PEvmmmoMzEDWA@mail.gmail.com>
 <87zg7pu2mt.fsf@akagi.fsij.org>
 <CAO48Bk9JHk79xYW+KmBK-XydTY_Ee6DY_jH8wrEAGuibXB_T2Q@mail.gmail.com>
 <CAO48Bk9NwVip7UMG6+ZqUEq-XzAX74qEeAPvfV0jeTCiNuMwZQ@mail.gmail.com>
 <5941988F-4F6B-45C4-832C-6FC66F7EC101@redhat.com>
 <CAO48Bk-A2uGBjP91iXAHJvPoEdf4N8XbC6j0q2mvtOHDypjrWA@mail.gmail.com>
Message-ID: <ZC92B8ixEhKDzTqP@pobox.com>

Pedro Andres Aranda Gutierrez via Gnupg-devel wrote:
> On Wed, 5 Apr 2023 at 10:48, Clemens Lang <cllang at redhat.com> wrote:
>> Try again with
>>
>>    https://dev.gnupg.org/rCbcf5922eaac274f5ace991ecace01e718a9fe964
>
> Could you please provide a patch against libgcrypt-1.10.1.
> I tried myself, but without any luck.

There is a trivial conflict in the Last-changed: line of the
two-line patch.  I did the following:

    $ git switch -c temp libgcrypt-1.10.1

    $ git cherry-pick -x c118a8dd
    Auto-merging m4/gpg-error.m4
    CONFLICT (content): Merge conflict in m4/gpg-error.m4
    error: could not apply c118a8dd... m4: Update gpg-error.m4.
    [...]

Edit m4/gpg-error.m4 to remove the conflicting lines:

    <<<<<<< HEAD
    # Last-changed: 2022-02-15
    =======

and

    >>>>>>> c118a8dd (m4: Update gpg-error.m4.)

leaving '# Last-changed: 2023-04-01'.

Finish the cherry-pick:

    $ git add m4/gpg-error.m4
    $ git cherry-pick --continue --no-edit

Generate a patch:

    $ git format-patch -1
    0001-m4-Update-gpg-error.m4.patch

The result is attached (unless the list software strips it
off), in which case the instructions should make it easy to
recreate. :)

-- 
Todd
-------------- next part --------------
From 9c33a38a5bee3e51933a2418a9ec7ef24627a62b Mon Sep 17 00:00:00 2001
From: NIIBE Yutaka <gniibe at fsij.org>
Date: Sat, 1 Apr 2023 11:23:34 +0900
Subject: [PATCH] m4: Update gpg-error.m4.

* m4/gpg-error.m4: Update from libgpg-error master.

--

Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
(cherry picked from commit c118a8ddd0224f951f26ae78d58d0eed5ee35779)
---
 m4/gpg-error.m4 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/m4/gpg-error.m4 b/m4/gpg-error.m4
index 4b5cd40b..070b749d 100644
--- a/m4/gpg-error.m4
+++ b/m4/gpg-error.m4
@@ -10,7 +10,7 @@
 # WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
 # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 #
-# Last-changed: 2022-02-15
+# Last-changed: 2023-04-01
 
 
 dnl AM_PATH_GPG_ERROR([MINIMUM-VERSION,
@@ -135,6 +135,7 @@ AC_DEFUN([AM_PATH_GPG_ERROR],
       AC_MSG_NOTICE([Use gpgrt-config with $gpgrt_libdir as gpg-error-config])
       gpg_error_config_version=`$GPG_ERROR_CONFIG --modversion`
     else
+      gpg_error_config_version=`$GPG_ERROR_CONFIG --version`
       unset GPGRT_CONFIG
     fi
   elif test "$GPG_ERROR_CONFIG" != "no"; then
-- 
2.40.0

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

From lists at sapience.com  Sun Apr 16 22:06:26 2023
From: lists at sapience.com (Genes Lists)
Date: Sun, 16 Apr 2023 16:06:26 -0400
Subject: libgcrypt got a 'make check' error
Message-ID: <b3618755-8527-2ba5-0c8b-8f66ac4b431d@sapience.com>


FYI:

  libgcrypt git master has 1 fail 'make check' after today's commit:

   commit 30840c2c45d718e0fd93cfd40771fbefa50e31f5 (HEAD -> master,
     origin/master, origin/HEAD)
   Author: Werner Koch <wk at gnupg.org>
   Date:   Sun Apr 16 20:28:03 2023 +0200

     cipher: Fix edge case for SET_ALLOW_WEAK_KEY.


make check now has this fail:

    basic: ecb-algo:302-tv:3-data:0, expected gcry_cipher_setkey to fail,
                                     but got: Success
    FAIL: basic

best

gene



From wk at gnupg.org  Mon Apr 17 15:17:48 2023
From: wk at gnupg.org (Werner Koch)
Date: Mon, 17 Apr 2023 15:17:48 +0200
Subject: libgcrypt got a 'make check' error
In-Reply-To: <b3618755-8527-2ba5-0c8b-8f66ac4b431d@sapience.com> (Genes Lists
 via Gnupg-devel's message of "Sun, 16 Apr 2023 16:06:26 -0400")
References: <b3618755-8527-2ba5-0c8b-8f66ac4b431d@sapience.com>
Message-ID: <87r0si641v.fsf@wheatstone.g10code.de>

On Sun, 16 Apr 2023 16:06, Genes Lists said:

> make check now has this fail:

see https://dev.gnupg.org/T6451

I will probably revert that change.


Shalom-Salam,

   Werner

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

From lists at sapience.com  Mon Apr 17 15:55:09 2023
From: lists at sapience.com (Genes Lists)
Date: Mon, 17 Apr 2023 09:55:09 -0400
Subject: libgcrypt got a 'make check' error
In-Reply-To: <87r0si641v.fsf@wheatstone.g10code.de>
References: <b3618755-8527-2ba5-0c8b-8f66ac4b431d@sapience.com>
 <87r0si641v.fsf@wheatstone.g10code.de>
Message-ID: <c299ed8e-5352-4eb9-476a-68b1589bb5b7@sapience.com>

On 4/17/23 09:17, Werner Koch wrote:

> ...
> I will probably revert that change.
> ...

Thanks for the info.

best

gene



From patrick at enigmail.net  Tue Apr 18 17:50:47 2023
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Tue, 18 Apr 2023 17:50:47 +0200
Subject: Invitation to the 7th OpenPGP Email Summit
Message-ID: <da144edf-c63c-d44e-b88b-223ef4bd7d18@enigmail.net>

I'm happy to announce the 7th OpenPGP Email Summit which will take place

        Friday, May 26 & Saturday, May 27, 2023
  in Geneva (Switzerland) at the offices of Proton AG


REGISTRATION
============

If you want to attend, please add yourself to the following cryptpad:
https://cryptpad.fr/pad/#/2/pad/edit/Jf4Qo-XjTcrFG7JvzdLruReI/


ABOUT THE OpenPGP EMAIL SUMMIT
==============================

This is an event open for anybody involved in the development of email
clients using OpenPGP for encryption, and related software.

We already had 6 OpenPGP Email Summits at various locations in Europe.
These are meetings by technical experts of projects and tools dealing
with OpenPGP with a focus on email encryption. The goals are to better
get to know each other, and to discuss and work on several technical
issues that hopefully improve certain aspects of OpenPGP-based email
encryption. For details, see
   https://wiki.gnupg.org/OpenPGPEmailSummit202305



NOTES
=====
This is a meeting of those who develop software. Thus, we will have a
lot of tech talk about key servers, key exchange, subject encryption,
password recovery, etc.

Thus, feel free to join us if you are working in the area of
- TECHNICAL DETAILS
- for SENDING or PROCESSING ENCRYPTED EMAILS
- with OpenPGP
- in a project or product.

Note that this is neither a well-organized conference nor a commercial
meeting. The agenda will be driven by the attendees. Anyone may propose
any topic for discussion, as long as he/she is ready to lead the discussion.

All details including the agenda are available on the web site:
https://wiki.gnupg.org/OpenPGPEmailSummit202305


Looking forward to meeting you in Geneva
-Patrick


-- 
Patrick Brunschwig
mailto:patrick at enigmail.net
PGP fingerprint: 4F9F 89F5 505A C1D1 A260 631C DB11 87B9 DD5F 693B

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

From gregor.duester at agdsn.de  Tue Apr 25 08:48:35 2023
From: gregor.duester at agdsn.de (=?UTF-8?Q?Gregor_D=c3=bcster?=)
Date: Tue, 25 Apr 2023 08:48:35 +0200
Subject: Questions on gpg-wks-server
Message-ID: <63c6a7c6-e090-c04f-ae16-b158fe77c237@agdsn.de>

Hi there,

I'm currently in the process of setting up a Web Key Service and have 
some questions on the behaviour of gpg-wks-server:

How does gpg-wks-server determines which domains should be processed?
My best guess would be it uses the top level directories for domains 
(e.g. at the default /var/lib/gnupg/wks or at the path specified with -C).

Does gpg-wks-server strip UIDs from the submitted keys from domains that 
are not configured?

How does gpg-wks-server deal with multiple user IDs in general?  Will it 
send out multiple confirmation requests provided the domains are configured?

Does gpg-wks-server drop a publication request if a key has no UIDs with 
any of the configured domains?


Kind regards

-- 
Gregor D?ster

Arbeitsgemeinschaft Dresdner Studentennetz (AG DSN)

https://agdsn.de

StuRa der TU Dresden
AG DSN
Helmholtzstra?e 10
01069 Dresden


-------------- 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/20230425/32f96c4c/attachment.sig>

From bernhard at intevation.de  Wed Apr 26 15:19:44 2023
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 26 Apr 2023 15:19:44 +0200
Subject: Standards: IETF WG proposing incompatible despite implementations and
 objections
Message-ID: <202304261519.53946.bernhard@intevation.de>

Hi,

what happened the overhauled specifications of OpenPGP?

It seems that the IETF working group 
plans to publish their proposal of an updated OpenPGP specification
a) even with objections present
b) and three major implementations 
 RNP (used by Thunderbird)
 GnuPG and
 OpenPGP.js (used by Mailvelope)
present that have deployed and are using a set of new functions
that GnuPG has documented and considered a rough consensus until 2021.

Some technical arguments on this mailing lists have been brought up
in the last months, but I am not sure if they have been considered by the 
working group. The email discussion archived end of march at
  https://mailarchive.ietf.org/arch/msg/openpgp/pNkkw2r16G-q_O0Nd6eL-JFLMXU/
just shows procedural arguments refering to a resolution in September.

A good paths forward would be, if the technical arguments would be 
re-considered, and deployed implementations.

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

From bernhard at intevation.de  Wed Apr 26 14:43:48 2023
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 26 Apr 2023 14:43:48 +0200
Subject: Questions on gpg-wks-server
In-Reply-To: <63c6a7c6-e090-c04f-ae16-b158fe77c237@agdsn.de>
References: <63c6a7c6-e090-c04f-ae16-b158fe77c237@agdsn.de>
Message-ID: <202304261443.49155.bernhard@intevation.de>

Hi Gregor,

Am Dienstag 25 April 2023 08:48:35 schrieb Gregor D?ster via Gnupg-devel:
> I'm currently in the process of setting up a Web Key Service

very cool.

> and have some questions on the behaviour of gpg-wks-server:

It maybe that you need to consult the source code for some of the details
and do your own tests.

The service to let email client set their public keys
that are distributed via the web key directory is the more difficult part.

So you are doing both togehter, I guess as
  gpg-wks-client --verbose --supported agdsn.de
gpg-wks-client: provider for 'foo at agdsn.de' does NOT support the Web Key 
Directory


Regards
Bernhard

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

From kaie at kuix.de  Wed Apr 26 16:34:23 2023
From: kaie at kuix.de (Kai Engert)
Date: Wed, 26 Apr 2023 16:34:23 +0200
Subject: Standards: IETF WG proposing incompatible despite implementations
 and objections
In-Reply-To: <202304261519.53946.bernhard@intevation.de>
References: <202304261519.53946.bernhard@intevation.de>
Message-ID: <6a4ae410-03f2-f914-1ce3-3cd50f9c8ee5@kuix.de>

Hello Bernhard,

On 26.04.23 15:19, Bernhard Reiter wrote:
> It seems that the IETF working group
> plans to publish their proposal of an updated OpenPGP specification
> a) even with objections present
> b) and three major implementations
>   RNP (used by Thunderbird)
>   GnuPG and
>   OpenPGP.js (used by Mailvelope)
> present that have deployed and are using a set of new functions
> that GnuPG has documented and considered a rough consensus until 2021.

what are the new functions that RNP/GnuPG/OpenPGP.js use that you are 
referring to?

Could you please list the issues that you see regarding these functions 
and the proposed IETF OpenPGP specification?

Regards
Kai


From look at my.amazin.horse  Wed Apr 26 18:26:29 2023
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Wed, 26 Apr 2023 18:26:29 +0200
Subject: Standards: IETF WG proposing incompatible despite implementations
 and objections
In-Reply-To: <202304261519.53946.bernhard@intevation.de>
References: <202304261519.53946.bernhard@intevation.de>
Message-ID: <15232152-1c3b-6745-334c-46b9a6bda895@my.amazin.horse>

Hi Bernhard and list,

On 26.04.23 15:19, Bernhard Reiter wrote:
> Some technical arguments on this mailing lists have been brought up
> in the last months, but I am not sure if they have been considered by the
> working group. The email discussion archived end of march at
>    https://mailarchive.ietf.org/arch/msg/openpgp/pNkkw2r16G-q_O0Nd6eL-JFLMXU/
> just shows procedural arguments refering to a resolution in September.
The linked thread is months after the decision was made. You can refer
to the lengthy thread where the decision was made here:

https://mailarchive.ietf.org/arch/msg/openpgp/PWp3ZcZ_qnDNLhuT-zR7gA2ddeg/

Ultimately the decision is a culmination of issues that were boiling
unaddressed for many years. The least subtle indicator of these that
I'm aware of is my email to the list asking Werner to step down as an
editor, that I have already pointed you towards several times now.

> A good paths forward would be, if the technical arguments would be
> re-considered, and deployed implementations.

The single one big argument is that of compatibility. And it's a really
strong argument. So strong in fact, that some folks worry that going
ahead with the new spec despite it may spell the death of OpenPGP.
And indeed - it just might.

But if you read through the thread linked above, a large part of the working
group felt that the OpenPGP community effectively maneuvered itself into
being held hostage by this argument. The options on the table seemed to
be declaring Werner dictator for life over the OpenPGP specification, or
taking the hit of the compatibility argument and try to establish an actual
working group again.

Sounds pretty extreme, I know.

But considering these extremes - I have never had the impression that 
Werner,
or you for that matter, have stepped back from their position of GnuPG power
to say - whoa, if this many people are going to such lengths and are 
willing to
risk so much in order to change course here - maybe it's not just all of 
them
being stupid?

 ?- V



From bwalzer at 59.ca  Thu Apr 27 01:52:56 2023
From: bwalzer at 59.ca (Bruce Walzer)
Date: Wed, 26 Apr 2023 18:52:56 -0500
Subject: Standards: IETF WG proposing incompatible despite
 implementations and objections
In-Reply-To: <202304261519.53946.bernhard@intevation.de>
References: <202304261519.53946.bernhard@intevation.de>
Message-ID: <ZEm5WORtUSYM8AGP@watt.59.ca>

On Wed, Apr 26, 2023 at 03:19:44PM +0200, Bernhard Reiter wrote:
> Hi,
> 
> what happened the overhauled specifications of OpenPGP?
> 
> It seems that the IETF working group 
> plans to publish their proposal of an updated OpenPGP specification

I am not sure that that would be a politically valid act at this
time. It is obvious that there is no working consensus and that the
current draft is not usable in its present form. Or at least the last
I looked. At that time there was some bikeshedding about the name of
the standard that I thought might actually be a riff on the
bikeshedding complaints as a kind of a joke. I did not pay any
attention past that.

BTW, I just checked draft 8 and discovered that it was a serious
proposal and that the name of the standard is shown as changed to
"OpenPGP".

[...]

> Some technical arguments on this mailing lists have been brought up
> in the last months, but I am not sure if they have been considered by the 
> working group. The email discussion archived end of march at
>   https://mailarchive.ietf.org/arch/msg/openpgp/pNkkw2r16G-q_O0Nd6eL-JFLMXU/
> just shows procedural arguments refering to a resolution in September.
> 
> A good paths forward would be, if the technical arguments would be 
> re-considered, and deployed implementations.

My impression is that the ITEF process has deteriorated to the point that
meaningful change is not possible. An example from Draft 8 that is
near and dear to my heart[1]:

There was a complaint that there were too many block encryption modes
in one of the earlier drafts. There was OCFB, OCFB-MDC, OCB, EAX, and
GCM. My understanding was that EAX was only there because of the
uncertain patent status of OCB. Then GCM was added. The patent status
of OCB is very clear now and has been for something like 3 years. If
the process is capable of making substantive changes then EAX should
be removed by now, thus at least partially reflecting the concern
about too many block modes.

I checked Draft 8 and the EAX mode is still there...

Bruce Walzer

[1] https://articles.59.ca/doku.php?id=pgpfan:no_new_ae


From bernhard at intevation.de  Thu Apr 27 09:21:46 2023
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 27 Apr 2023 09:21:46 +0200
Subject: Standards: IETF WG proposing incompatible despite implementations
 and objections
In-Reply-To: <6a4ae410-03f2-f914-1ce3-3cd50f9c8ee5@kuix.de>
References: <202304261519.53946.bernhard@intevation.de>
 <6a4ae410-03f2-f914-1ce3-3cd50f9c8ee5@kuix.de>
Message-ID: <202304270921.53858.bernhard@intevation.de>

Hello Kai,

Am Mittwoch 26 April 2023 16:34:23 schrieb Kai Engert via Gnupg-devel:
> On 26.04.23 15:19, Bernhard Reiter wrote:
> > It seems that the IETF working group
> > plans to publish their proposal of an updated OpenPGP specification
> > a) even with objections present
> > b) and three major implementations
> >   RNP (used by Thunderbird)
> >   GnuPG and
> >   OpenPGP.js (used by Mailvelope)
> > present that have deployed and are using a set of new functions
> > that GnuPG has documented and considered a rough consensus until 2021.
>
> what are the new functions that RNP/GnuPG/OpenPGP.js use that you are
> referring to?

the ones that were implemented and put to use after RFC4880 (from 2007) 
and which seems to have been a rough consensus in the IETF working group
until 2021. 

I think Werner tries to document them and useful additions in
https://www.ietf.org/archive/id/draft-koch-openpgp-2015-rfc4880bis-01.txt
(See his email from February to this list.)

Note that I am not an authoritative source, while I do talk to folk from 
g10code on a regular basis, in this matter I try to find out what the 
situation is myself and document it.

> Could you please list the issues that you see regarding these functions
> and the proposed IETF OpenPGP specification?

I wish I could, even the post-2021 working group does not offer an overview
and why they deviate from those major implementations. I think it would be 
most useful if those who propose something else what to what is implemented 
do explain their proposal. Did you ask them?

Nevertheless there have been quite a few points posted on this list in the 
last months. One example was rececked by Bruce Walzer in his previous mail:
 * Too many block encryption modes and EAX still in without rational.

Best Regards
Bernhard

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

From bernhard at intevation.de  Thu Apr 27 10:04:09 2023
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 27 Apr 2023 10:04:09 +0200
Subject: Standards: IETF WG proposing incompatible despite implementations
 and objections
In-Reply-To: <15232152-1c3b-6745-334c-46b9a6bda895@my.amazin.horse>
References: <202304261519.53946.bernhard@intevation.de>
 <15232152-1c3b-6745-334c-46b9a6bda895@my.amazin.horse>
Message-ID: <202304271004.18543.bernhard@intevation.de>

Hi Vincent,

Am Mittwoch 26 April 2023 18:26:29 schrieb Vincent Breitmoser via Gnupg-devel:
> The linked thread is months after the decision was made. You can refer
> to the lengthy thread where the decision was made here:
>
> https://mailarchive.ietf.org/arch/msg/openpgp/PWp3ZcZ_qnDNLhuT-zR7gA2ddeg/
>
> Ultimately the decision is a culmination of issues that were boiling
> unaddressed for many years.

maybe, but wouldn't it make sense to re-consider 
if substancial arguments come up?

Just to consider the point Bruce brought up: Why is EAX still in?
Where can I read up on the argument on this?
(I used to read some PEPs of the python community and while there were hard 
arguments made, they try to write them down for a way forward.)

> > A good paths forward would be, if the technical arguments would be
> > re-considered, and deployed implementations.
>
> The single one big argument is that of compatibility. And it's a really
> strong argument. So strong in fact, that some folks worry that going
> ahead with the new spec despite it may spell the death of OpenPGP.
> And indeed - it just might.

Both true, but it is not necessarily a "big" argument in my view. 
Compatibility issues can often be addressed in parts or little steps. Or with 
a plan over time. The question is: where do we want to head?

> But if you read through the thread linked above, a large part of the
> working group felt that the OpenPGP community effectively maneuvered itself
> into being held hostage by this argument. The options on the table seemed
> to be declaring Werner dictator for life over the OpenPGP specification, or
> taking the hit of the compatibility argument and try to establish an actual
> working group again.
>
> Sounds pretty extreme, I know.

If what you write is a representative summary, 
then the reason for the decision would not be a good argumentation
from this fraction of the working group. It would be about argumentation 
style. And however you like or dislike an argumentation style, the argument
itself does not change. So keeping EAX in the proposed spec will be a 
disadvantage or not, independently of who proposes it.
 
What you are saying is that the working group wants to oppose Werner for 
showing that they have the power and need to be taken seriously. 
It maybe that those people feel this is necessary, but it is hard to see
how a technical specification will benefit from this. For this to work, they 
would need to reject arguments that Werner supports just because he supports 
them, not on the basis of a technical argument. In a sense they would be more 
forced by Werner's views if they just based their proposal on arguments 
alone.

> But considering these extremes - I have never had the impression that
> Werner, or you for that matter, have stepped back from their position
> of GnuPG power to say - whoa, if this many people are going to such lengths
> and are  willing to risk so much in order to change course here 
> - maybe it's not just all of them being stupid?

My view on this "power" mechanism is quite different. While I have seen power
being used (and sometimes for the bad, but often for the good) I have found 
Werner sometimes to be defensive initially, but later in almost all cases, 
open to follow an understandable argument. I have seen this so often over 
more than 20 years that I trust Werner to have a outstanding knowledge and 
development intuition about real-world usable and widely deployed public key 
cryptography and its implementation. He was so often right long before I 
could understand why.

I am personally are interested in getting a good standard and Free Software 
implementations that help everybody. I make up my own mind and will criticise
Werner's arguments if I believe they are flawed. You will find a number of 
public examples on this list. As for the OpenPGP standard:
When I have noticed the problematic situation growing, I have started looking 
a bit at the situation myself to make up my mind, and I hope we get the 
arguments in an overview so that more people can evaluate them. So yes, it is 
very well possible that the post-2021 working group people have very good 
points, and I need to keep looking for those.

It also is possible in general that many people are wrong about something that 
they are fiercely fighting for. (There examples in general sciences.)

What is the case here, I don't know for sure. My current state of mind is
the summary I've posted yesterday. (A personal situtation had me unable to 
work or a number of weeks where I was out of the loop.)

Do you have a suggestion what I could do?

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

From andrewg at andrewg.com  Thu Apr 27 13:41:38 2023
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 27 Apr 2023 12:41:38 +0100
Subject: Standards: IETF WG proposing incompatible despite implementations
 and objections
In-Reply-To: <202304271004.18543.bernhard@intevation.de>
References: <202304261519.53946.bernhard@intevation.de>
 <15232152-1c3b-6745-334c-46b9a6bda895@my.amazin.horse>
 <202304271004.18543.bernhard@intevation.de>
Message-ID: <385808A8-A86A-468D-A5BE-5B1F0D71A65B@andrewg.com>

On 27 Apr 2023, at 09:04, Bernhard Reiter <bernhard at intevation.de> wrote:
> 
> Just to consider the point Bruce brought up: Why is EAX still in?
> Where can I read up on the argument on this?

AFAICT it?s still in mainly because it?s optional and nobody has formally proposed to remove it - Bruce has brought it up a few times but nearly always in conjunction with other points that don?t have consensus; there doesn?t appear to have been a specific proposal on the WG list to only remove EAX but keep everything else as is. It may be worth removing EAX if nobody intends to implement it, but if nobody implements EAX there?s no urgent need to remove it either.

>> The single one big argument is that of compatibility. And it's a really
>> strong argument. So strong in fact, that some folks worry that going
>> ahead with the new spec despite it may spell the death of OpenPGP.
>> And indeed - it just might.
> 
> Both true, but it is not necessarily a "big" argument in my view.
> Compatibility issues can often be addressed in parts or little steps. Or with
> a plan over time. The question is: where do we want to head?

The competing proposals are not contradictory; the version bump has avoided that. It is possible for individual implementations to support both ?v5? and ?v6", even if only partially (e.g. read-only support for the ?wrong? format). This would seem to me to be the most productive compromise path forward at this point, however the WG cannot officially suggest such a thing. :-)

> What you are saying is that the working group wants to oppose Werner for
> showing that they have the power and need to be taken seriously.

This is not fair. Most people on the WG have come around to the current position with extreme reluctance. If there were some way to reconcile the competing proposals even at this late stage, there would be great rejoicing.

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20230427/491a576b/attachment-0001.sig>

From bernhard at intevation.de  Thu Apr 27 17:16:10 2023
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 27 Apr 2023 17:16:10 +0200
Subject: Standards: IETF WG proposing incompatible despite implementations
 and objections
In-Reply-To: <385808A8-A86A-468D-A5BE-5B1F0D71A65B@andrewg.com>
References: <202304261519.53946.bernhard@intevation.de>
 <202304271004.18543.bernhard@intevation.de>
 <385808A8-A86A-468D-A5BE-5B1F0D71A65B@andrewg.com>
Message-ID: <202304271716.18694.bernhard@intevation.de>

Am Donnerstag 27 April 2023 13:41:38 schrieb Andrew Gallagher via Gnupg-devel:
> On 27 Apr 2023, at 09:04, Bernhard Reiter <bernhard at intevation.de> wrote:
> > Just to consider the point Bruce brought up: Why is EAX still in?
> > Where can I read up on the argument on this?
>
> AFAICT it?s still in mainly because it?s optional and nobody has formally
> proposed to remove it - Bruce has brought it up a few times but nearly
> always in conjunction with other points that don?t have consensus; there
> doesn?t appear to have been a specific proposal on the WG list to only
> remove EAX but keep everything else as is. It may be worth removing EAX if
> nobody intends to implement it, but if nobody implements EAX there?s no
> urgent need to remove it either.

What would someone, e.g. Bruce, 
need to do to remove EAX from the current draft?
I mean a simpler specification is better, so if an optional thing
is not needed, it SHOULD be taken out. 

> The competing proposals are not contradictory; the version bump has avoided
> that. It is possible for individual implementations to support both ?v5?
> and ?v6", even if only partially (e.g. read-only support for the ?wrong?
> format). This would seem to me to be the most productive compromise path
> forward at this point, however the WG cannot officially suggest such a
> thing. :-)

Thanks for pointing this out. Again I am trying to understand the situation.

[me responding to Vincent]
> > What you are saying is that the working group wants to oppose Werner for
> > showing that they have the power and need to be taken seriously.
>
> This is not fair. Most people on the WG have come around to the current
> position with extreme reluctance. 

I merely infered from Vincent's impression here. I am happy you are presenting 
a different view on it.

> If there were some way to reconcile the competing proposals
> even at this late stage, there would be great rejoicing.

What would need to be done to do this?
With Werner's emails and new draft since Februrary, there seems to be 
something to work on and put forward arguments. Do you know if they have been 
discussed in the working group since then?

The way I see is that someone digs into the technical arguments; at least to 
document why different groups come to their suggestions.
Personally I may not have the time nor the expertise to really go into the 
cryptographic details. who could?

Best Regards
Bernhard

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

From noloader at gmail.com  Thu Apr 27 18:44:33 2023
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 27 Apr 2023 12:44:33 -0400
Subject: Standards: IETF WG proposing incompatible despite implementations
 and objections
In-Reply-To: <ZEm5WORtUSYM8AGP@watt.59.ca>
References: <202304261519.53946.bernhard@intevation.de>
 <ZEm5WORtUSYM8AGP@watt.59.ca>
Message-ID: <CAH8yC8nWeVVaGkgCh=Jn8rEnf2yZPqwFSWm6G+-TbYfBzypjzQ@mail.gmail.com>

On Wed, Apr 26, 2023 at 8:37?PM Bruce Walzer <bwalzer at 59.ca> wrote:
> [...]
> There was a complaint that there were too many block encryption modes
> in one of the earlier drafts. There was OCFB, OCFB-MDC, OCB, EAX, and
> GCM. My understanding was that EAX was only there because of the
> uncertain patent status of OCB. Then GCM was added. The patent status
> of OCB is very clear now and has been for something like 3 years. If
> the process is capable of making substantive changes then EAX should
> be removed by now, thus at least partially reflecting the concern
> about too many block modes.

EAX was one of my favorite modes back in the early 2000s. It had a lot
of benefits with little downside. Cf.,
https://www.cryptopp.com/wiki/AEAD_Comparison .

To play devil's advocate... how does one decrypt an old message or
file encrypted using EAX mode if EAX mode is removed?

If EAX is going to be removed, then there has to be a path forward for
users. I think it is a bad idea to simply cut them off. That's bad
design and bad usability.

Perhaps it would be better to deprecate EAX mode, and suggest it not
be used for new messages. It might even be enforced by making it
runtime configurable, and defaulting to off.

Jeff


From andrewg at andrewg.com  Thu Apr 27 19:04:02 2023
From: andrewg at andrewg.com (Andrew Gallagher)
Date: Thu, 27 Apr 2023 18:04:02 +0100
Subject: Standards: IETF WG proposing incompatible despite implementations
 and objections
In-Reply-To: <202304271716.18694.bernhard@intevation.de>
References: <202304261519.53946.bernhard@intevation.de>
 <202304271004.18543.bernhard@intevation.de>
 <385808A8-A86A-468D-A5BE-5B1F0D71A65B@andrewg.com>
 <202304271716.18694.bernhard@intevation.de>
Message-ID: <22323288-A99B-4644-8CE6-FA2DC8965A6A@andrewg.com>

On 27 Apr 2023, at 16:16, Bernhard Reiter <bernhard at intevation.de> wrote:
> 
> What would someone, e.g. Bruce,
> need to do to remove EAX from the current draft?
> I mean a simpler specification is better, so if an optional thing
> is not needed, it SHOULD be taken out.

Join the IETF openpgp mailing list and say ?I propose to remove EAX from the current draft?.

Bruce has been an active participant on the list and has expressed skepticism about AEAD modes in general but IIRC did not object to EAX in particular. Werner and Daniel Huigens (and perhaps others, I didn?t search thoroughly) did indicate that they regard EAX as redundant but did not specifically propose that it be removed from the crypto-refresh draft, although Werner did later remove it from draft-koch. Daniel drew up a list of the differences between draft-koch and crypto-refresh, in which EAX was a line item, but it was never properly followed up on afterwards (that I can see).

AFAICT it?s just an oversight. I suspect there isn?t a good understanding of exactly how many real-world messages exist that use EAX. Daniel and Werner seem to think there are few enough.

>> If there were some way to reconcile the competing proposals
>> even at this late stage, there would be great rejoicing.
> 
> What would need to be done to do this?
> With Werner's emails and new draft since Februrary, there seems to be
> something to work on and put forward arguments. Do you know if they have been
> discussed in the working group since then?


Without some resolution to the fundamental technical sticking point (whether GCM should be tolerated) I don?t see a viable landing zone at this time.

The relevant thread starts here: https://mailarchive.ietf.org/arch/msg/openpgp/_SjXfSOOtdy20nhVv79NBsDBJTc/ , it covers pretty much all the bases.

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20230427/26d70c6a/attachment.sig>

From look at my.amazin.horse  Thu Apr 27 19:58:08 2023
From: look at my.amazin.horse (Vincent Breitmoser)
Date: Thu, 27 Apr 2023 19:58:08 +0200
Subject: Standards: IETF WG proposing incompatible despite implementations
 and objections
In-Reply-To: <22323288-A99B-4644-8CE6-FA2DC8965A6A@andrewg.com>
References: <202304261519.53946.bernhard@intevation.de>
 <202304271004.18543.bernhard@intevation.de>
 <385808A8-A86A-468D-A5BE-5B1F0D71A65B@andrewg.com>
 <202304271716.18694.bernhard@intevation.de>
 <22323288-A99B-4644-8CE6-FA2DC8965A6A@andrewg.com>
Message-ID: <bc72c464-20e6-be98-6b7f-afa0572f624a@my.amazin.horse>

Hey Andrew and list,

On 27.04.23 19:04, Andrew Gallagher via Gnupg-devel wrote:
> Join the IETF openpgp mailing list and say ?I propose to remove EAX from the current draft?.

That is correct. You can also make an MR on the repo and have it 
reviewed, considered,
edited, and merged.

And crucially, this wasn't the case before, but is now. That is the core 
issue of it all.

 ?- V



From bernhard at intevation.de  Fri Apr 28 09:56:18 2023
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 28 Apr 2023 09:56:18 +0200
Subject: Deprecating or removing EAX mode (Re: Standards: IETF WG proposing
 incompatible despite implementations and objections)
In-Reply-To: <CAH8yC8nWeVVaGkgCh=Jn8rEnf2yZPqwFSWm6G+-TbYfBzypjzQ@mail.gmail.com>
References: <202304261519.53946.bernhard@intevation.de>
 <ZEm5WORtUSYM8AGP@watt.59.ca>
 <CAH8yC8nWeVVaGkgCh=Jn8rEnf2yZPqwFSWm6G+-TbYfBzypjzQ@mail.gmail.com>
Message-ID: <202304280956.18806.bernhard@intevation.de>

Bruce, Jeff,

Am Donnerstag 27 April 2023 18:44:33 schrieb Jeffrey Walton via Gnupg-devel:
> Perhaps it would be better to deprecate EAX mode, and suggest it not
> be used for new messages. It might even be enforced by making it
> runtime configurable, and defaulting to off.

can any of you, or both, propose this on the OpenPGP WG mailinglist,
like Andrew suggested?

It maybe a minor point afterall, but at least one clarified.

Best Regards,
Bernhard


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

From bernhard at intevation.de  Fri Apr 28 09:59:28 2023
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 28 Apr 2023 09:59:28 +0200
Subject: Standards: IETF WG proposing incompatible despite implementations
 and objections
In-Reply-To: <bc72c464-20e6-be98-6b7f-afa0572f624a@my.amazin.horse>
References: <202304261519.53946.bernhard@intevation.de>
 <22323288-A99B-4644-8CE6-FA2DC8965A6A@andrewg.com>
 <bc72c464-20e6-be98-6b7f-afa0572f624a@my.amazin.horse>
Message-ID: <202304280959.29252.bernhard@intevation.de>

Hey Vincent,

Am Donnerstag 27 April 2023 19:58:08 schrieb Vincent Breitmoser You can also 
> make an MR on the repo and have it reviewed, considered,
> edited, and merged.
>
> And crucially, this wasn't the case before, but is now.
> That is the core issue of it all.

do I understand you right in that not having merge requests
available was the core issue?
If so, why?

Thanks,
Bernhard

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

From bernhard at intevation.de  Fri Apr 28 10:03:44 2023
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 28 Apr 2023 10:03:44 +0200
Subject: draft fundamental points (pointer) (Re: Standards: IETF WG proposing
 incompatible despite implementations and objections)
In-Reply-To: <22323288-A99B-4644-8CE6-FA2DC8965A6A@andrewg.com>
References: <202304261519.53946.bernhard@intevation.de>
 <202304271716.18694.bernhard@intevation.de>
 <22323288-A99B-4644-8CE6-FA2DC8965A6A@andrewg.com>
Message-ID: <202304281003.44996.bernhard@intevation.de>

Am Donnerstag 27 April 2023 19:04:02 schrieb Andrew Gallagher via Gnupg-devel:
> On 27 Apr 2023, at 16:16, Bernhard Reiter <bernhard at intevation.de> wrote:
> > What would someone, e.g. Bruce,
> > need to do to remove EAX from the current draft?

> Join the IETF openpgp mailing list and say ?I propose to remove EAX from
> the current draft?.
[..] 

Thanks for explaining.

[getting drafts and groups to converge again]
> Without some resolution to the fundamental technical sticking point
> (whether GCM should be tolerated) I don?t see a viable landing zone at this
> time.
>
> The relevant thread starts here:
> https://mailarchive.ietf.org/arch/msg/openpgp/_SjXfSOOtdy20nhVv79NBsDBJTc/
> , it covers pretty much all the bases.

Again thanks for the pointer, I'll do some reading.

Regards,
Bernhard

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

From wk at gnupg.org  Fri Apr 28 10:17:29 2023
From: wk at gnupg.org (Werner Koch)
Date: Fri, 28 Apr 2023 10:17:29 +0200
Subject: Standards: IETF WG proposing incompatible despite implementations
 and objections
In-Reply-To: <CAH8yC8nWeVVaGkgCh=Jn8rEnf2yZPqwFSWm6G+-TbYfBzypjzQ@mail.gmail.com>
 (Jeffrey Walton via Gnupg-devel's message of "Thu, 27 Apr 2023
 12:44:33 -0400")
References: <202304261519.53946.bernhard@intevation.de>
 <ZEm5WORtUSYM8AGP@watt.59.ca>
 <CAH8yC8nWeVVaGkgCh=Jn8rEnf2yZPqwFSWm6G+-TbYfBzypjzQ@mail.gmail.com>
Message-ID: <87zg6s1kva.fsf@wheatstone.g10code.de>

On Thu, 27 Apr 2023 12:44, Jeffrey Walton said:

> To play devil's advocate... how does one decrypt an old message or
> file encrypted using EAX mode if EAX mode is removed?

Use GnuPG or RNP.  For GnuPG I see no reason to remove EAX support for
decryption: it won't remove much code and EAX is fairly easy to
maintain.  Of course we don't use it anymore encryption even if the
preferences say so.  In fact GnuPG will entirely ignore the AEAD
Preferences and check only the Feature Flags to see whether all
recipients support OCB.

Do you see any reason to encrypt using EAX?  AFAIK all deployed
implementations which supported EAX also supported OCB.


Salam-Shalom,

   Werner

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

From wk at gnupg.org  Fri Apr 28 15:47:52 2023
From: wk at gnupg.org (Werner Koch)
Date: Fri, 28 Apr 2023 15:47:52 +0200
Subject: [Announce] GnuPG 2.4.1 released
Message-ID: <87mt2s15kn.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce the availability of a new stable GnuPG
release: version 2.4.1.  This version fixes some minor regressions
introduced with 2.4.0 and also adds a couple of new features.  See
below for details.


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

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

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

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

Three different series of GnuPG are actively maintained:

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

- Version 2.2 is our LTS (long term support) version and guaranteed to
  be maintained at least until the end of 2024. Only a small subset of
  features from 2.4 has been back-ported to this series.  See
  https://gnupg.org/download/index.html#end-of-life

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


Noteworthy changes in version 2.4.1
===================================

  * If the ~/.gnupg directory does not exist, the keyboxd is now
    automagically enabled.  [rGd9e7488b17]

  * gpg: New option --add-desig-revoker.  [rG3d094e2bcf]

  * gpg: New option --assert-signer.  [rGc9e95b8dee]

  * gpg: New command --quick-add-adsk and other ADSK features.
    [T6395, https://gnupg.org/blog/20230321-adsk.html]

  * gpg: New list-option "show-unusable-sigs".  Also show
    "[self-signature]" instead of the user-id in key signature
    listings.  [rG103acfe9ca]

  * gpg: For symmetric encryption the default S2K hash is now SHA256.
    [T6367]

  * gpg: Detect already compressed data also when using a pipe.  Also
    detect JPEG and PNG file formats.  [T6332]

  * gpg: New subcommand "openpgp" for --card-edit.  [T6462]

  * gpgsm: Verification of detached signatures does now strip trailing
    zeroes from the input if --assume-binary is used.  [rG2a13f7f9dc]

  * gpgsm: Non-armored detached signature are now created without
    using indefinite form length octets.  This improves compatibility
    with some PDF signature verification software.  [rG8996b0b655]

  * gpgtar: Emit progress status lines in create mode.  [T6363]

  * dirmngr: The LDAP modifyTimestamp is now returned by some
    keyserver commands.  [rG56d309133f]

  * ssh: Allow specification of the order keys are presented to ssh.
    See the man page entry for --enable-ssh-support.  [T5996, T6212]

  * gpg: Make list-options "show-sig-subpackets" work again.
    Fixes regression in 2.4.0.  [rG5a223303d7]

  * gpg: Fix the keytocard command for Yubikeys.  [T6378]

  * gpg: Do not continue an export after a cancel for the primary key.
    [T6093]

  * gpg: Replace the --override-compliance-check hack by a real fix.
    [T5655]

  * gpgtar: Fix decryption with input taken from stdin.  [T6355]

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


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

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

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

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

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.1.tar.bz2 (7169k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.4.1.tar.bz2.sig

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

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.4.1_20230428.exe (5305k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.4.1_20230428.exe.sig

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

A new release of Gpg4win including this version of GnuPG will soon be
announced.


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

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

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

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

     sha1sum gnupg-2.4.1.tar.bz2

   and check that the output matches the next line:

d7d021101361a5e1166a6c0cc1731276e7134547  gnupg-2.4.1.tar.bz2
ddef13a3d099b72e4136d76918e9e11a27e58472  gnupg-w32-2.4.1_20230428.tar.xz
4fcd84cb78c84970bc874c123d223f6521c1e566  gnupg-w32-2.4.1_20230428.exe


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

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


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

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

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

or can be downloaded as PDF at

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

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

In case of build problems specific to this release please first check
https://dev.gnupg.org/T6454 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.


Job Opportunity
===============

We are looking for an experienced technical person for the g10 Code
office in Erkrath.  Your duties would be help with system administration
and to extend our technical support team.  Although we are running
completely on free software, most of our customers are running Windows;
thus experience with Windows management will be of advantage as well as
a reasonable proficiency in German.  If you are interested in a full
time employment please contact us my mail.



Thanks
======

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

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

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

*Thank you all*

   Your GnuPG hackers


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

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

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

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

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

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

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


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20230428/b1ceadb0/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From ralph at ml.seichter.de  Sat Apr 29 07:36:48 2023
From: ralph at ml.seichter.de (Ralph Seichter)
Date: Sat, 29 Apr 2023 07:36:48 +0200
Subject: [Announce] GnuPG for OS X 2.4.1
Message-ID: <87edo3w8pb.fsf@ra.horus-it.com>

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

The disk image signature key is available via public keyservers, and it
can also be downloaded from https://www.seichter.de/pgp/gpgosx-signing.asc .

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

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

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

-Ralph


From wk at gnupg.org  Sun Apr 30 13:39:26 2023
From: wk at gnupg.org (Werner Koch)
Date: Sun, 30 Apr 2023 13:39:26 +0200
Subject: Questions on gpg-wks-server
In-Reply-To: <63c6a7c6-e090-c04f-ae16-b158fe77c237@agdsn.de> ("Gregor
 =?utf-8?Q?D=C3=BCster?=
 via Gnupg-devel"'s message of "Tue, 25 Apr 2023 08:48:35 +0200")
References: <63c6a7c6-e090-c04f-ae16-b158fe77c237@agdsn.de>
Message-ID: <87354h1tw1.fsf@wheatstone.g10code.de>

Hi!

On Tue, 25 Apr 2023 08:48, Gregor D?ster said:

> How does gpg-wks-server determines which domains should be processed?
> My best guess would be it uses the top level directories for domains
> (e.g. at the default /var/lib/gnupg/wks or at the path specified with
> -C).

That is correct.  Requests with no domain configured below that
directory are ignored.  For example for gnupg.org we have

$ ls -l /var/lib/gnupg/wks/gnupg.org/
drwxr-sr-x 3 webkey webkey 4096 Mar 11  2019 hu
drwx--S--- 2 webkey webkey 4096 Jul  5  2021 pending
-rw-r--r-- 1 webkey webkey    0 Nov 14  2017 policy
-rw-r--r-- 1 webkey webkey   21 Aug 31  2016 submission-address

and we have a daily cronjob running "gpg-wks-server -v --cron" to clean
up pending requests after 3 days.

> Does gpg-wks-server strip UIDs from the submitted keys from domains
> that are not configured?

Confirmation requests are sent for all addresses found in the submitted
key as long as the domain is configured.  However, gpg-wks-client sends
the keys only with one user id.

> How does gpg-wks-server deal with multiple user IDs in general?  Will
> it send out multiple confirmation requests provided the domains are
> configured?

Exactly.

> Does gpg-wks-server drop a publication request if a key has no UIDs
> with any of the configured domains?

Yes.


Salam-Shalom,

   Werner

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