From jcb62281 at gmail.com  Sun Feb  1 05:40:41 2026
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Sat, 31 Jan 2026 22:40:41 -0600
Subject: [PATCH 1/3] tests: Cast to void to suppress warnings about unused
 variables
In-Reply-To: <87jywxeggw.fsf@gmail.com>
References: <aX1aRra1Gy17hKiA@abf3d4a53bee> <87bji9x5oq.fsf@jacob.g10code.de>
 <CAH8yC8m+wBzSB9yDhpO0cc5+FPi5Vh1NJEWDb9pGX-z+BRAckw@mail.gmail.com>
 <87jywxeggw.fsf@gmail.com>
Message-ID: <7bad5af1-879d-4b64-bcf9-f518b7f6265f@gmail.com>

On 1/31/26 13:21, Collin Funk via Gnupg-devel wrote:
> Jeffrey Walton via Gnupg-devel <gnupg-devel at gnupg.org> writes:
>
>> On Sat, Jan 31, 2026 at 8:36?AM Werner Koch via Gnupg-devel <
>> gnupg-devel at gnupg.org> wrote:
>>> On Sat, 31 Jan 2026 01:26, Rudi Heitbaum said:
>>>> Address compiler warning when variable is unused because it?s used
>>>> only in assert.
>>> Anyone who defines NDEBUG does not known what s/he does.  An assert is
>>> there for a reason.  It is plain stupid to use an assert but disable it
>>> for production.
>> Asserts are a debugging and diagnostic tool.  Confer, <
>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/assert.html>.
>> Asserts should not be enabled in production software.
> I generally agree, but there is some benefit to having a program crash
> instead of continuing in an undefined state.

There is also the small matter that we are talking about assertions in a 
testsuite, not the main program that will actually be installed.? These 
programs help to validate that the main program was probably actually 
compiled correctly.

Maybe adding "#undef NDEBUG" to each C source file in the testsuite 
would be a more appropriate solution to these warnings?

>> If an assert triggers, it usually causes a program to crash.  Sensitive
>> data can leave the app's security boundary and be egressed through the
>> crash dump or report.  Companies like Apple, Canonical, Google and
>> Microsoft could have access to the sensitive data.
>>
>> I've even seen asserts used in BitCoin wallets, and the crash reports
>> uploaded to Microsoft App Center Diagnostics.  The private keys for the
>> wallets were burned!
>>
>> I've never seen a project document that private keys and shared secrets
>> should be rotated after a program crashes due to an assert.
> Yeah, that is bad.

GPG also has its own assertion infrastructure for checks that remain 
effective in production builds, and presumably kills the process in a 
controlled manner that avoids potentially including sensitive 
information in a crash dump.

Remember that GPG has a "secmem" facility for storing sensitive data.? I 
would be surprised to see a similar feature in a typical BitCoin wallet, 
just as I would be very surprised if Werner Koch had not considered and 
addressed this risk in GPG years ago.


-- Jacob




From bernhard at intevation.de  Tue Feb  3 10:27:57 2026
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 3 Feb 2026 10:27:57 +0100
Subject: git.gnupg.org access does not work 404
Message-ID: <202602031028.04123.bernhard@intevation.de>

Hi,
https://git.gnupg.org/ gives me 404
  Not Found
  The requested URL was not found on this server.

Linked from https://gnupg.org/download/git.html
where they point here for reporting.

Regards,
Bernhard
-------------- 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/20260203/d2e34642/attachment.sig>

From bernhard at intevation.de  Tue Feb  3 10:57:41 2026
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 3 Feb 2026 10:57:41 +0100
Subject: GPGME: locate-keys: how identify that different keys were
 returned by keyservers
In-Reply-To: <aTBx3FDrY6YrpBjN@watt.59.ca>
References: <20251203113804.21c3fe3c@hermes.development.it>
 <aTBx3FDrY6YrpBjN@watt.59.ca>
Message-ID: <202602031057.48019.bernhard@intevation.de>

Hi,

Am Mittwoch 03 Dezember 2025 18:22:36 schrieb Bruce Walzer via Gnupg-devel:
> > The scenario is running "gpg --locate-keys email at example.org" with the
> > configured keyservers returning different keys for that email address.
>
> So the problem seems intrinsic to me. The user will
> eventually be expected to determine which key fingerprint/ID is
> correct.

note that if you restrict your request to WKD (web key directory)
you can use all pubkeys you will get. Which will be one.
So there is no interaction necessary in the common case,
you can just encrypt to the pubkey you get from WKD for an email address.


gpg  --locate-keys --auto-key-locate clear,nodefault,wkd 
bernhard.reiter at intevation.de 

or gpg  --locate-external-keys --auto-key-locate clear,nodefault,wkd 
bernhard.reiter at intevation.de

should help you test this. (Should be possible via GPGME as well.)

WKD should be enabled and used by default
and Claws can do some more steps to do that right from the start.

See:
 https://wiki.gnupg.org/EMailClients/ClawsMail
 https://wiki.gnupg.org/WKD/BachelorThesisIncreaseWKDUsage2021
 https://wiki.gnupg.org/WKD/DistributionOfWKD
 https://wiki.gnupg.org/WKD/UsabilityOfWKD  <- mentions Claws test

Best,
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/20260203/6bbf55ac/attachment.sig>

From kloecker at kde.org  Tue Feb  3 13:23:40 2026
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Tue, 03 Feb 2026 13:23:40 +0100
Subject: git.gnupg.org access does not work 404
In-Reply-To: <202602031028.04123.bernhard@intevation.de>
References: <202602031028.04123.bernhard@intevation.de>
Message-ID: <2207257.9o76ZdvQCi@daneel>

On Dienstag, 3. Februar 2026 10:27:57 Mitteleurop?ische Normalzeit Bernhard 
Reiter via Gnupg-devel wrote:
> Hi,
> https://git.gnupg.org/ gives me 404
>   Not Found
>   The requested URL was not found on this server.
> 
> Linked from https://gnupg.org/download/git.html
> where they point here for reporting.

You can thank AI scrapers for this. Werner had to take the web service down. A 
less radical solution is being worked on.

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

From bernhard at intevation.de  Tue Feb  3 13:30:26 2026
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 3 Feb 2026 13:30:26 +0100
Subject: git.gnupg.org down until further notice
In-Reply-To: <2207257.9o76ZdvQCi@daneel>
References: <202602031028.04123.bernhard@intevation.de>
 <2207257.9o76ZdvQCi@daneel>
Message-ID: <202602031330.27163.bernhard@intevation.de>

Am Dienstag 03 Februar 2026 13:23:40 schrieb Ingo Kl?cker:
> > https://git.gnupg.org/ gives me 404

> You can thank AI scrapers for this. Werner had to take the web service
> down. A less radical solution is being worked on.

Thanks for the info!
Do you have a ticket that can be followed?
(Should be mentioned on https://gnupg.org/download/git.html)

Bernhard
ps.: Can you point me to your updated pubkey?
I haven't found it on keyserver and the version I have expired.


-- 
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/20260203/3e4a55a6/attachment.sig>

From wk at gnupg.org  Tue Feb  3 17:30:13 2026
From: wk at gnupg.org (Werner Koch)
Date: Tue, 03 Feb 2026 17:30:13 +0100
Subject: GPGME: locate-keys: how identify that different keys were
 returned by keyservers
In-Reply-To: <202602031057.48019.bernhard@intevation.de> (Bernhard Reiter via
 Gnupg-devel's message of "Tue, 3 Feb 2026 10:57:41 +0100")
References: <20251203113804.21c3fe3c@hermes.development.it>
 <aTBx3FDrY6YrpBjN@watt.59.ca>
 <202602031057.48019.bernhard@intevation.de>
Message-ID: <87fr7hu6wa.fsf@jacob.g10code.de>

On Tue,  3 Feb 2026 10:57, Bernhard Reiter said:

> gpg  --locate-keys --auto-key-locate clear,nodefault,wkd 

Please use

  gpg  --locate-external-keys foo at example.org

to get a fresh copy.  It does the same as above but is easier to
remember.  Since 2.2.17 (summer 2019).


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: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260203/b20511d4/attachment.sig>