From christoph-klassen at mail.de  Fri Nov  5 14:41:26 2021
From: christoph-klassen at mail.de (Christoph Klassen)
Date: Fri, 5 Nov 2021 14:41:26 +0100
Subject: WKD: Subdomain openpgpkey
Message-ID: <e6015355-2e67-1261-f3ae-2a97f47c32e6@mail.de>

Hello,

in the draft of Werner Koch about WKD there is this paragraph:

There are two variants on how to form the request URI: The advanced
and the direct method.  Implementations MUST first try the advanced
method.  Only if the required sub-domain does not exist, they SHOULD
fall back to the direct method. [1]

I think it needs to be clarified what it means that the sub-domain 
doesn't exist. If a server doesn't offer this sub-domain, it doesn't 
exist .. check. But what, if it does offer this sub-domain and the 
server isn't available for some reason? Does that case count as "does 
not exist"?

[1] https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/


Greetings,

Christoph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20211105/b21656db/attachment-0001.html>

From dashohoxha at gmail.com  Sun Nov  7 05:29:32 2021
From: dashohoxha at gmail.com (Dashamir Hoxha)
Date: Sun, 7 Nov 2021 05:29:32 +0100
Subject: WKD: Subdomain openpgpkey
In-Reply-To: <e6015355-2e67-1261-f3ae-2a97f47c32e6@mail.de>
References: <e6015355-2e67-1261-f3ae-2a97f47c32e6@mail.de>
Message-ID: <CAMucfLzRStakZrKQBwrPFkM=nJ60xxRR_C2HFThwYQuE70orug@mail.gmail.com>

Thanks for starting this discussion Christoph, because it allows me to
add something else that has bothered me.

In my presentations about WKD (https://cloud.fs.al/s/5TNQm4sJyYN8qi4)
I try to explain it by thinking how a client would locate the key
through WKD.
I say that the client first looks for the presence of the "policy"
file with the advanced method, and if not found, looks for the
presence of the "policy" file with the direct method.
This allows the client to find out (discover) which method is
available/supported. After that, it tries to download the key with the
method (advanced or direct) that was discovered in the first step.
These steps are repeated each time that the client needs to download a
key (maybe each time that it needs to use it), so there is no problem
if there is a temporary failure, next time that it will try to
retrieve the key it will work.

What bothers me is that the way that I describe it, it does not depend
on the existence of domains or subdomains, it only checks for the
presence of the "policy" file. And I am not sure if this is completely
correct.

On Fri, Nov 5, 2021 at 3:59 PM Christoph Klassen via Gnupg-devel
<gnupg-devel at gnupg.org> wrote:
>
> Hello,
>
> in the draft of Werner Koch about WKD there is this paragraph:
>
> There are two variants on how to form the request URI: The advanced
> and the direct method.  Implementations MUST first try the advanced
> method.  Only if the required sub-domain does not exist, they SHOULD
> fall back to the direct method. [1]
>
> I think it needs to be clarified what it means that the sub-domain doesn't exist. If a server doesn't offer this sub-domain, it doesn't exist .. check. But what, if it does offer this sub-domain and the server isn't available for some reason? Does that case count as "does not exist"?
>
> [1] https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/
>
>
> Greetings,
>
> Christoph
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel


From rainer.perske at uni-muenster.de  Sun Nov  7 14:10:11 2021
From: rainer.perske at uni-muenster.de (Rainer Perske)
Date: Sun, 07 Nov 2021 14:10:11 +0100 (CET)
Subject: PKCS#12 password length limit in sm/minip12.c
Message-ID: <permail-20211107131011f110c661000022b8-perske@message-id.uni-muenster.de>

Hello, everyone

Currently, GnuPG cannot import PKCS#12 files protected with passwords 
longer than 31 bytes, giving a long series of error messages while 
trying to interpret the given password with all implemented character 
sets.

Before I file a bug report: Is there any good reason for limiting the 
password length for PKCS#12 files to 63/2 = 31 bytes in line 354 of 
"sm/minip12.c"?

Neither in the comments nor in the code below I can find any reason for 
a limit smaller than 63 bytes, and other software like OpenSSL allows 
for even longer passwords.

Should there be no such reason, I'd suggest to modify the limit in line 
354 of "sm/minip12.c". I did not test it, but as far as I can see, the 
rest of the code can handle up to 63 bytes, so this might be a 
reasonable limit forced by the current implementation.

Best regards
-- 
Rainer Perske
Systemdienste + Leiter der Zertifizierungsstelle (WWUCA)
-- 
Westf?lische Wilhelms-Universit?t (WWU) M?nster
WWU IT
Rainer Perske, Systemdienste
R?ntgenstra?e 7-13, Raum 006
48149 M?nster
Tel.: +49 251 83-31582
E-Mail: rainer.perske at uni-muenster.de
Website: www.uni-muenster.de/it

Zertifizierungsstelle (WWUCA):
Tel.: +49 251 83-31590
E-Mail: ca at uni-muenster.de
WWW: www.uni-muenster.de/wwuca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5454 bytes
Desc: S/MIME cryptographic signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20211107/a6e61f7d/attachment.bin>

From bjk at luxsci.net  Sun Nov  7 19:43:44 2021
From: bjk at luxsci.net (Ben Kibbey)
Date: Sun, 7 Nov 2021 10:43:44 -0800
Subject: gpgme: [PATCH] tests: Fix pthread linking error.
Message-ID: <1636310625-7258591.69525139.f1A7IhiDm652481@rs6161.luxsci.com>

Second revision since I forgot to add ax_pthread.m4.

-- 
Ben Kibbey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-tests-Fix-pthread-linking-error.patch
Type: text/x-diff
Size: 26340 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20211107/0494394f/attachment-0001.patch>

From bjk at luxsci.net  Sun Nov  7 19:37:39 2021
From: bjk at luxsci.net (Ben Kibbey)
Date: Sun,  7 Nov 2021 10:37:39 -0800
Subject: [PATCH] tests: Fix pthread linking error.
Message-ID: <1636310261-2589598.78334045.f1A7IbeeE648296@rs6161.luxsci.com>

* m4/ax_pthread.m4: Add.
* configure.ac: Test for pthreads via AX_PTHREAD.
* tests/Makefile.am: Add @PTHREAD_LIBS@ and @PTHREAD_CFLAGS at .
* tests/gpg/Makefile.am: Ditto.

--

Fixes linking issue for Android on arm64 and possibly others.

Signed-off-by: Ben Kibbey <bjk at luxsci.net>
---
 configure.ac          |  1 +
 tests/Makefile.am     |  4 +++-
 tests/gpg/Makefile.am | 16 ++++++++++++----
 3 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 296553e3..5f320312 100644
--- a/configure.ac
+++ b/configure.ac
@@ -142,6 +142,7 @@ int main (void) { return 0; }
 esac
 AC_SUBST([LDADD_FOR_TESTS_KLUDGE])
 
+AX_PTHREAD
 AH_VERBATIM([_REENTRANT],
 [/* To allow the use of GPGME in multithreaded programs we have to use
   special features from the library.
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 8950e965..e1727c8d 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -37,8 +37,10 @@ noinst_PROGRAMS = $(TESTS) run-keylist run-export run-import run-sign \
 		  run-verify run-encrypt run-identify run-decrypt run-genkey \
 		  run-keysign run-tofu run-swdb run-threaded
 
-run_threaded_LDADD = ../src/libgpgme.la -lpthread @GPG_ERROR_LIBS@ \
+run_threaded_LDADD = ../src/libgpgme.la @GPG_ERROR_LIBS@ \
 		     @LDADD_FOR_TESTS_KLUDGE@
+run_threaded_CFLAGS = @PTHREAD_CFLAGS@
+run_threaded_LDFLAGS = @PTHREAD_LIBS@
 
 if RUN_GPG_TESTS
 gpgtests = gpg json
diff --git a/tests/gpg/Makefile.am b/tests/gpg/Makefile.am
index bab9dd9a..b53884a4 100644
--- a/tests/gpg/Makefile.am
+++ b/tests/gpg/Makefile.am
@@ -68,10 +68,18 @@ BUILT_SOURCES = gpg.conf gpg-agent.conf pubring-stamp \
 AM_CPPFLAGS = -I$(top_builddir)/src @GPG_ERROR_CFLAGS@
 AM_LDFLAGS = -no-install
 LDADD = ../../src/libgpgme.la @LDADD_FOR_TESTS_KLUDGE@
-t_thread1_LDADD = ../../src/libgpgme.la -lpthread @LDADD_FOR_TESTS_KLUDGE@
-t_thread_keylist_LDADD = ../../src/libgpgme.la -lpthread @LDADD_FOR_TESTS_KLUDGE@
-t_thread_keylist_verify_LDADD = ../../src/libgpgme.la -lpthread @LDADD_FOR_TESTS_KLUDGE@
-t_cancel_LDADD = ../../src/libgpgme.la -lpthread @LDADD_FOR_TESTS_KLUDGE@
+t_thread1_LDADD = ../../src/libgpgme.la @LDADD_FOR_TESTS_KLUDGE@
+t_thread1_CFLAGS = @PTHREAD_CFLAGS@
+t_thread1_LDFLAGS = @PTHREAD_LIBS@
+t_thread_keylist_LDADD = ../../src/libgpgme.la @LDADD_FOR_TESTS_KLUDGE@
+t_thread_keylist_CFLAGS = @PTHREAD_CFLAGS@
+t_thread_keylist_LDFLAGS = @PTHREAD_LIBS@
+t_thread_keylist_verify_LDADD = ../../src/libgpgme.la @LDADD_FOR_TESTS_KLUDGE@
+t_thread_keylist_verify_CFLAGS = @PTHREAD_CFLAGS@
+t_thread_keylist_verify_LDFLAGS = @PTHREAD_LIBS@
+t_cancel_LDADD = ../../src/libgpgme.la @LDADD_FOR_TESTS_KLUDGE@
+t_cancel_CFLAGS = @PTHREAD_CFLAGS@
+t_cancel_LDFLAGS = @PTHREAD_LIBS@
 
 # We don't run t-genkey and t-cancel in the test suite, because it
 # takes too long
-- 
2.33.0



From wk at gnupg.org  Tue Nov  9 08:31:54 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 09 Nov 2021 08:31:54 +0100
Subject: PKCS#12 password length limit in sm/minip12.c
In-Reply-To: <permail-20211107131011f110c661000022b8-perske@message-id.uni-muenster.de>
 (Rainer Perske's message of "Sun, 07 Nov 2021 14:10:11 +0100 (CET)")
References: <permail-20211107131011f110c661000022b8-perske@message-id.uni-muenster.de>
Message-ID: <87tugldbth.fsf@wheatstone.g10code.de>

On Sun,  7 Nov 2021 14:10, Rainer Perske said:

> Before I file a bug report: Is there any good reason for limiting the 
> password length for PKCS#12 files to 63/2 = 31 bytes in line 354 of 
> "sm/minip12.c"?

Sorry, I can't remember why I write it this way 18 years ago.  Maybe we
had different specs back then or the limit was a shortcut to not
implement the whole thing.  But in the latter case there should have
been a note in the code.

To tell more, I would need to revisit the specs.


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/20211109/1534bb3a/attachment.sig>

From wk at gnupg.org  Tue Nov  9 08:33:48 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 09 Nov 2021 08:33:48 +0100
Subject: WKD: Subdomain openpgpkey
In-Reply-To: <e6015355-2e67-1261-f3ae-2a97f47c32e6@mail.de> (Christoph Klassen
 via Gnupg-devel's message of "Fri, 5 Nov 2021 14:41:26 +0100")
References: <e6015355-2e67-1261-f3ae-2a97f47c32e6@mail.de>
Message-ID: <87pmr9dbqb.fsf@wheatstone.g10code.de>

On Fri,  5 Nov 2021 14:41, Christoph Klassen said:

> exist .. check. But what, if it does offer this sub-domain and the
> server isn't available for some reason? Does that case count as "does
> not exist"?

No.  If you get an IP address to connect to, the server exists.  I'll
add a note to the specs to clarify this.



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/20211109/82c322d2/attachment.sig>

From wk at gnupg.org  Tue Nov  9 08:49:39 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 09 Nov 2021 08:49:39 +0100
Subject: [PATCH] draft-koch-openpgp-webkey-service
In-Reply-To: <ce0a6819-22d2-cdf0-8e11-8402d872bfab@suse.de> (Bernhard
 M. Wiedemann's message of "Sat, 23 Oct 2021 15:32:42 +0200")
References: <ce0a6819-22d2-cdf0-8e11-8402d872bfab@suse.de>
Message-ID: <87lf1xdazw.fsf@wheatstone.g10code.de>

On Sat, 23 Oct 2021 15:32, Bernhard M. Wiedemann said:
> and got this trivial patch:
>
> -practise
> +practice

Please no British / American fixes ;-)

> Another wks issue: I noticed insufficient dir permissions.
> That should be fixed by
> https://github.com/gpg/gnupg/pull/15.patch

Thanks.  Applied to 2.3. and 2.2


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/20211109/b07e6125/attachment.sig>

From rainer.perske at uni-muenster.de  Tue Nov  9 10:21:40 2021
From: rainer.perske at uni-muenster.de (Rainer Perske)
Date: Tue, 09 Nov 2021 10:21:40 +0100 (CET)
Subject: PKCS#12 password length limit in sm/minip12.c
In-Reply-To: <87tugldbth.fsf@wheatstone.g10code.de>
Message-ID: <permail-2021110909214076b60d22000042b7-perske@message-id.uni-muenster.de>

Hello,

> > Before I file a bug report: Is there any good reason for limiting the
> > password length for PKCS#12 files to 63/2 = 31 bytes in line 354 of
> > "sm/minip12.c"?

> Sorry, I can't remember why I write it this way 18 years ago.  Maybe we
> had different specs back then or the limit was a shortcut to not
> implement the whole thing.  But in the latter case there should have
> been a note in the code.

thank you so far!

> To tell more, I would need to revisit the specs.

Two of our users hit the limit, this is why this problem popped up.

I know that you are busy with more urgent problems but I'd be glad if 
you could put it on your to-do list :-)

Beste Gr??e und Herzlichen Dank aus M?nster
-- 
Rainer Perske
Systemdienste + Leiter der Zertifizierungsstelle (WWUCA)
-- 
Westf?lische Wilhelms-Universit?t (WWU) M?nster
WWU IT
Rainer Perske, Systemdienste
R?ntgenstra?e 7-13, Raum 006
48149 M?nster
Tel.: +49 251 83-31582
E-Mail: rainer.perske at uni-muenster.de
Website: www.uni-muenster.de/it

Zertifizierungsstelle (WWUCA):
Tel.: +49 251 83-31590
E-Mail: ca at uni-muenster.de
WWW: www.uni-muenster.de/wwuca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5454 bytes
Desc: S/MIME cryptographic signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20211109/0a8c48a9/attachment.bin>

From gniibe at fsij.org  Thu Nov 11 02:26:54 2021
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 11 Nov 2021 10:26:54 +0900
Subject: gpgme: [PATCH] tests: Fix pthread linking error.
In-Reply-To: <1636310625-7258591.69525139.f1A7IhiDm652481@rs6161.luxsci.com>
References: <1636310625-7258591.69525139.f1A7IhiDm652481@rs6161.luxsci.com>
Message-ID: <87ilwzxz1d.fsf@akagi.fsij.org>

Ben Kibbey <bjk at luxsci.net> wrote:
> Fixes linking issue for Android on arm64 and possibly others.

Thank you for the report.

I think that this is an issue of libc/libpthread usage.

In fact, newer GNU C library has similar issue, as pthreads
implementation is now integraged into libc (no need for -lpthread).

In GnuPG libraries, we handled this issue in libgpg-error.

Because GPGME uses libgpg-error, I change tests/Makefile.am to fix.

Please test if it works for your case.

-- 

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 8950e965..e4346576 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -37,8 +37,9 @@ noinst_PROGRAMS = $(TESTS) run-keylist run-export run-import run-sign \
 		  run-verify run-encrypt run-identify run-decrypt run-genkey \
 		  run-keysign run-tofu run-swdb run-threaded
 
-run_threaded_LDADD = ../src/libgpgme.la -lpthread @GPG_ERROR_LIBS@ \
-		     @LDADD_FOR_TESTS_KLUDGE@
+run_threaded_CPPFLAGS = -I$(top_builddir)/src @GPG_ERROR_MT_CFLAGS@
+run_threaded_LDADD = ../src/libgpgme.la \
+		     @GPG_ERROR_MT_LIBS@ @LDADD_FOR_TESTS_KLUDGE@
 
 if RUN_GPG_TESTS
 gpgtests = gpg json


From bjk at luxsci.net  Thu Nov 11 04:31:53 2021
From: bjk at luxsci.net (Ben Kibbey)
Date: Wed, 10 Nov 2021 19:31:53 -0800
Subject: gpgme: [PATCH] tests: Fix pthread linking error.
In-Reply-To: <87ilwzxz1d.fsf@akagi.fsij.org>
References: <1636310625-7258591.69525139.f1A7IhiDm652481@rs6161.luxsci.com>
 <87ilwzxz1d.fsf@akagi.fsij.org>
Message-ID: <1636601514-6939545.1690508.f1AB3VsZE2248400@rs6161.luxsci.com>

On Thu, Nov 11, 2021 at 10:26:54AM +0900, NIIBE Yutaka wrote:
> Ben Kibbey <bjk at luxsci.net> wrote:
> > Fixes linking issue for Android on arm64 and possibly others.
> 
> Thank you for the report.
> 
> I think that this is an issue of libc/libpthread usage.
> 
> In fact, newer GNU C library has similar issue, as pthreads
> implementation is now integraged into libc (no need for -lpthread).
> 
> In GnuPG libraries, we handled this issue in libgpg-error.

That's good to know.

> Because GPGME uses libgpg-error, I change tests/Makefile.am to fix.
> 
> Please test if it works for your case.

Thanks. The build is good now except the forgotten tests/gpg tests:

diff --git a/tests/gpg/Makefile.am b/tests/gpg/Makefile.am
index bab9dd9a..00613b48 100644
--- a/tests/gpg/Makefile.am
+++ b/tests/gpg/Makefile.am
@@ -68,10 +68,18 @@ BUILT_SOURCES = gpg.conf gpg-agent.conf pubring-stamp \
 AM_CPPFLAGS = -I$(top_builddir)/src @GPG_ERROR_CFLAGS@
 AM_LDFLAGS = -no-install
 LDADD = ../../src/libgpgme.la @LDADD_FOR_TESTS_KLUDGE@
-t_thread1_LDADD = ../../src/libgpgme.la -lpthread @LDADD_FOR_TESTS_KLUDGE@
-t_thread_keylist_LDADD = ../../src/libgpgme.la -lpthread @LDADD_FOR_TESTS_KLUDGE@
-t_thread_keylist_verify_LDADD = ../../src/libgpgme.la -lpthread @LDADD_FOR_TESTS_KLUDGE@
-t_cancel_LDADD = ../../src/libgpgme.la -lpthread @LDADD_FOR_TESTS_KLUDGE@
+t_thread1_CPPFLAGS = @GPG_ERROR_MT_CFLAGS@
+t_thread1_LDADD = ../../src/libgpgme.la @GPG_ERROR_MT_LIBS@ \
+		  @LDADD_FOR_TESTS_KLUDGE@
+t_thread_keylist_CPPFLAGS = @GPG_ERROR_MT_CFLAGS@
+t_thread_keylist_LDADD = ../../src/libgpgme.la @GPG_ERROR_MT_LIBS@ \
+			 @LDADD_FOR_TESTS_KLUDGE@
+t_thread_keylist_verify_CPPFLAGS = @GPG_ERROR_MT_CFLAGS@
+t_thread_keylist_verify_LDADD = ../../src/libgpgme.la @GPG_ERROR_MT_LIBS@ \
+				@LDADD_FOR_TESTS_KLUDGE@
+t_cancel_CPPFLAGS = @GPG_ERROR_MT_CFLAGS@
+t_cancel_LDADD = ../../src/libgpgme.la @GPG_ERROR_MT_LIBS@ \
+		 @LDADD_FOR_TESTS_KLUDGE@
 
 # We don't run t-genkey and t-cancel in the test suite, because it
 # takes too long

-- 
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/20211110/4a6f74e6/attachment.sig>

From christoph-klassen at mail.de  Fri Nov 12 14:35:48 2021
From: christoph-klassen at mail.de (Christoph Klassen)
Date: Fri, 12 Nov 2021 14:35:48 +0100
Subject: WKD: Subdomain openpgpkey
In-Reply-To: <87pmr9dbqb.fsf@wheatstone.g10code.de>
References: <e6015355-2e67-1261-f3ae-2a97f47c32e6@mail.de>
 <87pmr9dbqb.fsf@wheatstone.g10code.de>
Message-ID: <5057d01c-c24b-f454-0067-b00941aeb04f@mail.de>

On 09.11.21 08:33, Werner Koch wrote:
> No.  If you get an IP address to connect to, the server exists.  I'll
> add a note to the specs to clarify this.

It could also be that the DNS name can be resolved, but no web server 
exists or the server is offline.

There are these cases:

*A request for a pubkey gets a response with status 200.
*A request for a pubkey gets a response, but with a negative status like 
404.
*A request isn't successful because of a NetworkError. In this case it's 
not possible to say, if the DNS name couldn't be resolved or if there is 
not web server.

A suggestion is that the direct method will be only used, if the third 
case occures. Resolving DNS names would make it more difficult to 
implement WKD (which was thought of as an easy solution to retrieve 
pubkeys) and maybe it's not always possible. For example I'm not sure, 
if extensions for internet browsers can do this.


Greetings,

Christoph





From wk at gnupg.org  Sat Nov 13 21:07:36 2021
From: wk at gnupg.org (Werner Koch)
Date: Sat, 13 Nov 2021 21:07:36 +0100
Subject: WKD: Subdomain openpgpkey
In-Reply-To: <5057d01c-c24b-f454-0067-b00941aeb04f@mail.de> (Christoph Klassen
 via Gnupg-devel's message of "Fri, 12 Nov 2021 14:35:48 +0100")
References: <e6015355-2e67-1261-f3ae-2a97f47c32e6@mail.de>
 <87pmr9dbqb.fsf@wheatstone.g10code.de>
 <5057d01c-c24b-f454-0067-b00941aeb04f@mail.de>
Message-ID: <87bl2nq0on.fsf@wheatstone.g10code.de>

On Fri, 12 Nov 2021 14:35, Christoph Klassen said:

> pubkeys) and maybe it's not always possible. For example I'm not sure,
> if extensions for internet browsers can do this.

The whole mess we had to implement (instead of proper SRV records) is
due to browser vendors who don't understand why SRV records are useful
and refuse to implement support for them.


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/20211113/f3d19eb9/attachment.sig>

From bernhard at intevation.de  Wed Nov 17 14:45:22 2021
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 17 Nov 2021 14:45:22 +0100
Subject: PKCS#12 password length limit in sm/minip12.c
In-Reply-To: <permail-2021110909214076b60d22000042b7-perske@message-id.uni-muenster.de>
References: <permail-2021110909214076b60d22000042b7-perske@message-id.uni-muenster.de>
Message-ID: <202111171445.22763.bernhard@intevation.de>

Hello Rainer,

Am Dienstag 09 November 2021 10:21:40 schrieb Rainer Perske:
> > > Before I file a bug report: Is there any good reason for limiting the
> > > password length for PKCS#12 files to 63/2 = 31 bytes in line 354 of
> > > "sm/minip12.c"?

> I'd be glad if you could put it on your to-do list :-)

usually it is helpful if you actually open a task on dev.gnupg.org
and link or quote helpful information.
For example the latest RKCS#12 specs section that deals with it or so.
This helps Werner and other devs to be fast when they have timeslot
to work on the issue in the future.

Patches are also welcome, but would need to have a DCO.

BTW: https://wiki.gnupg.org/X.509
also has a remark and a workaround that seem to be related.
Maybe you can add a link to the new issue there.

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/20211117/e93e378c/attachment.sig>

From bernhard at intevation.de  Wed Nov 17 15:49:01 2021
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 17 Nov 2021 15:49:01 +0100
Subject: WKD: Subdomain openpgpkey
In-Reply-To: <87bl2nq0on.fsf@wheatstone.g10code.de>
References: <e6015355-2e67-1261-f3ae-2a97f47c32e6@mail.de>
 <5057d01c-c24b-f454-0067-b00941aeb04f@mail.de>
 <87bl2nq0on.fsf@wheatstone.g10code.de>
Message-ID: <202111171549.08180.bernhard@intevation.de>

Werner,
when talking about this, Christoph and I thought about how to implement
a WKD request without using GnuPG (in places where it is not easily 
available).

We found that the current WKD draft [1] in practical terms seems to demand an 
explicit DNS resolve attempt in many situations. The reason is that
some connection libraries would not allow to easily make a distinction
between a failed connection for network error from a name resolution error or 
for a different reason.

An example in
Python 3.7.3 (default, Jan 22 2021, 20:04:44) 
>>> import requests
>>> requests.__version__
'2.21.0'
>>> r= 
requests.get('https://openpgpkey.intevation.de/.well-known/openpgpkey/intevation.de/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe')
[..]
requests.exceptions.ConnectionError: 
HTTPSConnectionPool(host='openpgpkey.intevation.de', port=443): Max retries 
exceeded with 
url: /.well-known/openpgpkey/intevation.de/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe 
(Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection 
object at 0x7fcb0d9ec208>: Failed to establish a new connection: [Errno -2] 
Name or service not known'))

This has the information in the string, so we would need to match
 "Name or service not known" to make the distinction.
Which is possible but not nice.

And additional call would be better, like
  import socket
  try:
    socket.getaddrinfo("openpgpkey.intevation.de", "443")
  except socket.gaierror:
    # try direct method

In a browser console (chromium  95.0.4638.69) we have not yet found how to get
that information at all:

url='https://openpgpkey.intevation.de/.well-known/openpgpkey/intevation.de/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe'
p = fetch(url)
Promise {<pending>}
VM398:1 GET 
https://openpgpkey.intevation.de/.well-known/openpgpkey/intevation.de/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe 
net::ERR_FAILED
VM398:1 
 Uncaught (in promise) TypeError: Failed to fetch
    at <anonymous>:1:5
console.log(p)

The console shows part of the into in the "net::ERR_FAILED" message, but this 
is not directly available from the variable p.
The documentation says
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#checking_that_the_fetch_was_successful
"A fetch() promise will reject with a TypeError when a network error is 
encountered or CORS is misconfigured on the server-side, although this 
usually means permission issues or similar "

Maybe this is the same in other libraries as well: the return of a TLS 
connection attempt may not be structured well enough that it can be (easily 
or at all) seen that it the DNS resolved okay, but something else (like TLS, 
CORS, network connection problems) has happened. A clear test would need a 
different (library) function call.

For browser extentions like Mailvelope there is no way to know in Chromium.
It could do a new dns.resolve() now, but see the nonexistent support in other
browsers:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/dns

Even if the environement of the WKD request implementation offers a DNS
resolve function, in the case of a DNS not resolving because of a network 
error, we still cannot be sure that no DNS entry exists.

Would'nt it be easier then to say:
  * Try to resolve the advanced WKD request for the email address in
    question. And if the network connection fails, you SHOULD try the direct
    method.

We considered using the mentioned test 
     WELLKNOWN/policy
     Clients may use this file to check for Web Key Directory support.
as a test for the advanced method, but this would be one additional request
each time the attempt to get one specific pubkey via advanced WKD fails
before the direct method could be tried. Or one connection attempt each time 
before trying the advanced method. But this would not be enough for the 
current criteria of selecting the direct method in the draft.
Wouldn't it be an improvement to be more symmetric here? E.g. like if a 
network request to the advanced method policy file fails, try the direct 
method policy file and if that network request fails, assume no support for 
WKD (for now.)

Best Regards,
Bernhard


[1]  https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/13/
reads

 Implementations MUST first try the advance method. 
 Only if an address for the required sub-domain does not
 exist, they SHOULD fall back to the direct method.  A non-responding
 server does not mean that the fall back should be carried out.

-- 
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/20211117/792336f0/attachment.sig>

From wk at gnupg.org  Thu Nov 18 10:37:21 2021
From: wk at gnupg.org (Werner Koch)
Date: Thu, 18 Nov 2021 10:37:21 +0100
Subject: WKD: Subdomain openpgpkey
In-Reply-To: <202111171549.08180.bernhard@intevation.de> (Bernhard Reiter's
 message of "Wed, 17 Nov 2021 15:49:01 +0100")
References: <e6015355-2e67-1261-f3ae-2a97f47c32e6@mail.de>
 <5057d01c-c24b-f454-0067-b00941aeb04f@mail.de>
 <87bl2nq0on.fsf@wheatstone.g10code.de>
 <202111171549.08180.bernhard@intevation.de>
Message-ID: <87czmxiz3i.fsf@wheatstone.g10code.de>

On Wed, 17 Nov 2021 15:49, Bernhard Reiter said:

> Would'nt it be easier then to say:
>   * Try to resolve the advanced WKD request for the email address in
>     question. And if the network connection fails, you SHOULD try the direct
>     method.

I currently don't think so.  The direct method should go away anyway.

It is just a relic from the time we started with this thing.  Sure
there is an additional burden to have a certificate for the subdomain
but given the slow acceptance of the Web Key Directory I would not
consider the direct method a real help for anyone.  Those who run their
own webserver and might use the direct method, will also be able to
setup a subdomain.


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/20211118/4d0dd397/attachment-0001.sig>

From bernhard at intevation.de  Thu Nov 18 11:16:48 2021
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 18 Nov 2021 11:16:48 +0100
Subject: WKD: Subdomain openpgpkey
In-Reply-To: <87czmxiz3i.fsf@wheatstone.g10code.de>
References: <e6015355-2e67-1261-f3ae-2a97f47c32e6@mail.de>
 <202111171549.08180.bernhard@intevation.de>
 <87czmxiz3i.fsf@wheatstone.g10code.de>
Message-ID: <202111181116.54563.bernhard@intevation.de>

Am Donnerstag 18 November 2021 10:37:21 schrieb Werner Koch via Gnupg-devel:
> On Wed, 17 Nov 2021 15:49, Bernhard Reiter said:
> > Would'nt it be easier then to say:
> >   * Try to resolve the advanced WKD request for the email address in
> >     question. And if the network connection fails, you SHOULD try the
> > direct method.
>
> I currently don't think so.  The direct method should go away anyway.
>
> It is just a relic from the time we started with this thing.  Sure
> there is an additional burden to have a certificate for the subdomain
> but given the slow acceptance of the Web Key Directory I would not
> consider the direct method a real help for anyone.  Those who run their
> own webserver and might use the direct method, will also be able to
> setup a subdomain.

As we want to further usage, I'd say we should keep supporting
the direct method for quite a while, because it means more communication 
partners and we reward early adopters (as they do not need to do any change.)
And there are implementation out there, facing them to change often without
major reason is a drawback for adoption.

So if we would recommand moving fully to the advanced method at some time
in the future. It would make even more sense to me to make it easier and be 
pragmatic about when to fall back to the direct method for the time being.

There is one more feedback from Thomas about the empty DNS record:
He guesses that some people who manage DNS via a webbased interface
of their DNS provider may not be able to set an empty TXT record.
(Okay, this whole decision problem would go away if only the advanced method 
is used in the future.)

One advantage I see in the direct method is that it leans toward recommending
do to this decentrally for each server and not using a central WKD service
or a number of sites.

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/20211118/b9a85af6/attachment.sig>

From wk at gnupg.org  Tue Nov 23 13:22:33 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 23 Nov 2021 13:22:33 +0100
Subject: [Announce] GnuPG 2.2.33 (LTS) released
Message-ID: <87pmqr83jq.fsf@wheatstone.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG LTS release:
version 2.2.33.  This release fixes a few minor problems and brings a
few new options to ease user support and large scale installations.

The LTS (long term support) series of GnuPG is guaranteed to be
maintained at least until the end of 2024.  See
https://gnupg.org/download/index.html#end-of-life


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 can be freely used, modified and distributed under the terms of
the GNU General Public License.


Noteworthy changes in version 2.2.33 (2021-11-23)
=================================================

  * gpg: New option --min-rsa-length.  [rG6ee01c1d26]

  * gpg: New option --forbid-gen-key.  [rG985fb25c46]

  * gpg: New option --override-compliance-check.  [T5655]

  * gpgconf: New command --show-configs.  [rG8fe3f57643]

  * agent,dirmngr: New option --steal-socket.  [rG6507c6ab10]

  * scd: Improve the selection of the default PC/SC reader.  [T5644]

  * gpg: Fix printing of binary notations.  [T5667]

  * gpg: Remove stale ultimately trusted keys from the trustdb.  [T5685]

  * gpgsm: Detect circular chains in --list-chain.  [rGc9343bec83]

  * gpgconf: Create the local option file even if the global file
    exists.  [T5650]

  * dirmngr: Make reading resolv.conf more robust.  [T5657]

  * gpg-wks-server: Fix created file permissions.  [rGf54feb4470]

  * scd: Support longer data for ssh-agent authentication with openpgp
    cards.  [T5682]

  * Support gpgconf.ctl for NetBSD and Solaris.  [T5656,T5671]

  * Silence "Garbled console data" warning under Windows in most
    cases.

  * Silence warning about the rootdir under Unices w/o a mounted /proc
    file system.

  * Fix possible build problems about missing include files.  [T5592]

  * i18n: Replace the term "PIN-Cache" by "Passswort-Cache" in the
    German translation. [rgf453d52e53]

  * i18n: Update the Russian translation.

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

  The provided Windows installer is now build against Libgpg-error 1.43
  and thus features versatile meta options for the config file.  For
  example, it is possible to read and use option values from the
  Registry or from environment variables.  More on this is in a not
  published written blog article.


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

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

GnuPG 2.2.33 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.33.tar.bz2 (7068k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.33.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.33_20211123.exe (4424k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.33_20211123.exe.sig

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

A new version of Gpg4win 3 will not be published.  Gpg4win users may
instead install this version on top of 3.1.16 or wait for Gpg4win 4.


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

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

     sha1sum gnupg-2.2.33.tar.bz2

   and check that the output matches the next line:

70053b799a79139e0e7889282805fc889dd22540  gnupg-2.2.33.tar.bz2
6bf876e04ba00bebb64dffe7d2224206521948a7  gnupg-w32-2.2.33_20211123.tar.xz
c67151e92fc82bd4138ef441dbeba61e9bf4de5f  gnupg-w32-2.2.33_20211123.exe


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

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


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

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

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

or can be downloaded as PDF at

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

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

In case of build problems specific to this release please first check
https://dev.gnupg.org/T5641 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 until this year 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 have been possible to keep GnuPG
in a good and secure shape and to address all the small and larger
requests made by our users.  Thanks.


Happy hacking,

   Your GnuPG hackers


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

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

--
Please read

  Nils Melzer: Der Fall Julian Assange

It is really important to know the background of the Assange case to
understand the massive perils to free journalism.  The book is right
now only available in German: https://dev.gnupg.org/u/melzerassang
-------------- 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/20211123/ac760ce2/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From nathbappai at gmail.com  Sat Nov 27 20:22:54 2021
From: nathbappai at gmail.com (Biswapriyo Nath)
Date: Sun, 28 Nov 2021 00:52:54 +0530
Subject: libgpg-error: [PATCH] w32: Fix handle to pid macro
Message-ID: <CALK-3mLUh5bY2nJPt5X0qA1C3=k61-27asqT+hgQe1G3wSFxsg@mail.gmail.com>


-------------- next part --------------
From 62894c52bdd162fa7308c8f70deefc0795021607 Mon Sep 17 00:00:00 2001
From: Biswapriyo Nath <nathbappai at gmail.com>
Date: Sun, 28 Nov 2021 00:46:11 +0530
Subject: [PATCH] w32: Fix handle to pid macro

This fixes the warning: cast from pointer to integer of different size

Signed-off-by: Biswapriyo Nath <nathbappai at gmail.com>
---
 src/spawn-w32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/spawn-w32.c b/src/spawn-w32.c
index 3ede1f2..3489801 100644
--- a/src/spawn-w32.c
+++ b/src/spawn-w32.c
@@ -78,7 +78,7 @@
  * fit within 32-bit range on 64-bit machine.
  */
 #define pid_to_handle(a) ((HANDLE)(a))
-#define handle_to_pid(a) ((int)(a))
+#define handle_to_pid(a) ((int)(intptr_t)(a))
 
 
 /* Return the maximum number of currently allowed open file
-- 
2.34.1


From tmz at pobox.com  Sat Nov 27 21:08:51 2021
From: tmz at pobox.com (Todd Zullinger)
Date: Sat, 27 Nov 2021 15:08:51 -0500
Subject: [PATCH gnupg] sm (gpgsm_verify): Use gpg_err_code() instead of -1
Message-ID: <20211127200851.1848923-1-tmz@pobox.com>

* sm/verify.c (gpgsm_verify): use gpg_err_code instead of 'rc == -1'
comparison.
--

In ed6ebb696e (sm: Implement initial support for keyboxd., 2020-09-10),
the return of keydb_search() was changed to use gpg_err_code().  Adjust
gpgsm_verify() to use it.  This provides a nicer error message to users
when a certificate is not found -- the same error that is seen from 2.2.

Prior to this change, when a cert was not found, gpgsm output:

    gpgsm: failed to find the certificate: Not found

as opposed to the more human-readable message from 2.2:

    gpgsm: certificate not found

They now return the same message.

Signed-off-by: Todd Zullinger <tmz at pobox.com>
---
 sm/verify.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sm/verify.c b/sm/verify.c
index fe111c32a..3dc494beb 100644
--- a/sm/verify.c
+++ b/sm/verify.c
@@ -428,7 +428,7 @@ gpgsm_verify (ctrl_t ctrl, int in_fd, int data_fd, estream_t out_fp)
       rc = keydb_search_issuer_sn (ctrl, kh, issuer, serial);
       if (rc)
         {
-          if (rc == -1)
+          if (gpg_err_code (rc) == GPG_ERR_NOT_FOUND)
             {
               log_error ("certificate not found\n");
               rc = gpg_error (GPG_ERR_NO_PUBKEY);


From angel at pgp.16bits.net  Mon Nov 29 03:08:37 2021
From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=)
Date: Mon, 29 Nov 2021 03:08:37 +0100
Subject: WKD: Subdomain openpgpkey
In-Reply-To: <202111171549.08180.bernhard@intevation.de>
References: <e6015355-2e67-1261-f3ae-2a97f47c32e6@mail.de>
 <5057d01c-c24b-f454-0067-b00941aeb04f@mail.de>
 <87bl2nq0on.fsf@wheatstone.g10code.de>
 <202111171549.08180.bernhard@intevation.de>
Message-ID: <4ca63ed98932d48b62d7013419887a9782dd055c.camel@16bits.net>

On 2021-11-17 at 15:49 +0100, Bernhard Reiter wrote:
> Even if the environement of the WKD request implementation offers a DNS
> resolve function, in the case of a DNS not resolving because of a network 
> error, we still cannot be sure that no DNS entry exists.
> 
> Wouldn't it be easier then to say:
>   * Try to resolve the advanced WKD request for the email address in
>     question. And if the network connection fails, you SHOULD try the direct
>     method.


> We considered using the mentioned test 
>      WELLKNOWN/policy
>      Clients may use this file to check for Web Key Directory support.
> as a test for the advanced method, but this would be one additional request
> each time the attempt to get one specific pubkey via advanced WKD fails
> before the direct method could be tried. Or one connection attempt each time 
> before trying the advanced method.

You could cache for X time that domain Y has no advanced WKD support.

> But this would not be enough for the 
> current criteria of selecting the direct method in the draft.
> Wouldn't it be an improvement to be more symmetric here? E.g. like if a 
> network request to the advanced method policy file fails, try the direct 
> method policy file and if that network request fails, assume no support for 
> WKD (for now.)

+1. Sorry, Werner, but I think it should check if there is a WKD
repository there, not just a DNS entry. Of course, no DNS entry allows
you to skip it directly, but for detection, checking if there is an
actual WKD there (by existence of the keys and/or the policy file)
would simplify both the keys as well as the administration, by
simplifying the need to insert additional rr to remove disable wildcard
DNS.

I don't see a huge gain on forcing the fetch to fail for a non-
responsive *potential* advanced server, rather than falling back.
There's a potential leak of the request to those running the apex
server, but you can avoid that if you first check that there is a
policy file in the DIRECT method.
You might choose a different policy if you have reason to think that
there is an advanced server (e.g. you contacted it before) but just the
DNS entry is fragile by itself

Regards