From sachin.t at ibm.com  Mon Dec  1 06:05:10 2025
From: sachin.t at ibm.com (Sachin T)
Date: Mon, 1 Dec 2025 05:05:10 +0000
Subject: [PATCH libgcrypt] Add support for IBM z/OS
In-Reply-To: <87y0nr7xzt.fsf@haruna.fsij.org>
References: <CO1PR15MB5003C030F26294F7E3D0F32F9775A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87y0nr7xzt.fsf@haruna.fsij.org>
Message-ID: <CO1PR15MB5003B45F4F7EE8379AB58CEF97DBA@CO1PR15MB5003.namprd15.prod.outlook.com>

Hello,

Thanks for reviewing the changes.

The wrapper approach worked for me.
I also wanted to mention that libgpg-error already uses EXTRA_LIBS_FOR_BUILD in its configure.ac for z/OS, so using the same method in libgcrypt would keep things consistent across both projects.

I can go with the approach you recommend.

Regards,
Sachin


From: NIIBE Yutaka <gniibe at fsij.org>
Date: Friday, 28 November 2025 at 6:51?AM
To: Sachin T <sachin.t at ibm.com>
Cc: GNU Libgcrypt Development <gnupg-devel at gnupg.org>
Subject: [EXTERNAL] Re: [PATCH libgcrypt] Add support for IBM z/OS

Hello,

I have a comment about EXTRA_LIBS_FOR_BUILD.

Sachin T wrote:
>   1.
[...]
> EXTRA_LIBS_FOR_BUILD via pkg-config/zoslib for external library linking
>   2.
[...]
> cipher/Makefile.am, doc/Makefile.am: Append $(EXTRA_LIBS_FOR_BUILD) to
> gost-s-box and yat2m link lines so build-host helper programs link
> correctly with z/OS-specific libraries during the build.

If I were developing/maintaining those packages for a POSIX-like
Operating System which needs to care about specific libraries and/or
headers, I'd consider about a compiler script to use as CC (and put
linking procedure with specific libraries into that script).  Then, I'd
specify CC=<THE_PATH_TO_THE_SCRIPT> for configure (or CC_FOR_BUILD).

Or else, it would end up to ask all software to put similar patches.

Could you please consider this approach?
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251201/b6992242/attachment-0001.html>

From gniibe at fsij.org  Tue Dec  2 07:51:45 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 02 Dec 2025 15:51:45 +0900
Subject: [PATCH libgcrypt] Add support for IBM z/OS
In-Reply-To: <CO1PR15MB5003B45F4F7EE8379AB58CEF97DBA@CO1PR15MB5003.namprd15.prod.outlook.com>
References: <CO1PR15MB5003C030F26294F7E3D0F32F9775A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87y0nr7xzt.fsf@haruna.fsij.org>
 <CO1PR15MB5003B45F4F7EE8379AB58CEF97DBA@CO1PR15MB5003.namprd15.prod.outlook.com>
Message-ID: <87pl8xs7em.fsf@haruna.fsij.org>

Hello, again,

Sachin T <sachin.t at ibm.com> wrote:
> Thanks for reviewing the changes.

I pushed other changes (libtool macro, longlong.h and secmem.c).
Let me have some time for configure.ac.

> The wrapper approach worked for me.

Good.  Please go ahead with the wrapper approach.

If the EXTRA_LIBS_FOR_BUILD is only for GnuPG, it would be acceptable.
My concern is that it will be for (almost) all packages you build.

> I also wanted to mention that libgpg-error already uses
> EXTRA_LIBS_FOR_BUILD in its configure.ac for z/OS, so using the same
> method in libgcrypt would keep things consistent across both projects.

I see.  If the wrapper approach will be found good, we can consider
about reverting the part of libgpg-error change.
-- 


From gniibe at fsij.org  Wed Dec  3 03:58:41 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 03 Dec 2025 11:58:41 +0900
Subject: [PATCH libgcrypt] Add support for IBM z/OS
In-Reply-To: <87pl8xs7em.fsf@haruna.fsij.org>
References: <CO1PR15MB5003C030F26294F7E3D0F32F9775A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87y0nr7xzt.fsf@haruna.fsij.org>
 <CO1PR15MB5003B45F4F7EE8379AB58CEF97DBA@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87pl8xs7em.fsf@haruna.fsij.org>
Message-ID: <87zf806zku.fsf@haruna.fsij.org>

NIIBE Yutaka <gniibe at fsij.org> wrote:
> Let me have some time for configure.ac.

Attached is a patch for the change of configure.ac.  If no objection,
I'll push this change to master.

It includes your changes (except the one for the EXTRA_LIBS_FOR_BUILD).

Please note that the detection of -lpthread is a bit complicated.  On
z/OS, IIUC, no -lpthread is required *and* it should not be added to the
compiler option.  On GNU/Linux, it is not required any more (with newer
glibc), but it is still OK to have -lpthread option.

Here, libgcrypt only needs to know if pthread API is available or not.
For actual linking, it uses GPG_ERROR_MT_LIBS (see tests/Makefile.am).

GPG_ERROR_MT_LIBS is from libgpg-error and it is libgpg-error which
checks pthread API more deeply and pthread linking at its build time.
It uses libgpg-error/m4/threadlib.m4 from gnulib.
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-build-Add-support-for-IBM-z-OS-fixing-lpthread-check.patch
Type: text/x-diff
Size: 2537 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251203/111749f0/attachment.patch>

From sachin.t at ibm.com  Wed Dec  3 07:39:48 2025
From: sachin.t at ibm.com (Sachin T)
Date: Wed, 3 Dec 2025 06:39:48 +0000
Subject: [PATCH libgcrypt] Add support for IBM z/OS
In-Reply-To: <87zf806zku.fsf@haruna.fsij.org>
References: <CO1PR15MB5003C030F26294F7E3D0F32F9775A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87y0nr7xzt.fsf@haruna.fsij.org>
 <CO1PR15MB5003B45F4F7EE8379AB58CEF97DBA@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87pl8xs7em.fsf@haruna.fsij.org> <87zf806zku.fsf@haruna.fsij.org>
Message-ID: <CO1PR15MB50038EFC833A061030FFA8DC97D9A@CO1PR15MB5003.namprd15.prod.outlook.com>

Hello,

Thanks. I tested your configure.ac change on z/OS and it configures and builds cleanly here. No objection to the change

Thanks
Sachin

From: NIIBE Yutaka <gniibe at fsij.org>
Date: Wednesday, 3 December 2025 at 8:28?AM
To: Sachin T <sachin.t at ibm.com>
Cc: GNU Libgcrypt Development <gnupg-devel at gnupg.org>
Subject: [EXTERNAL] RE: [PATCH libgcrypt] Add support for IBM z/OS

NIIBE Yutaka <gniibe at fsij.org> wrote:
> Let me have some time for configure.ac.

Attached is a patch for the change of configure.ac.  If no objection,
I'll push this change to master.

It includes your changes (except the one for the EXTRA_LIBS_FOR_BUILD).

Please note that the detection of -lpthread is a bit complicated.  On
z/OS, IIUC, no -lpthread is required *and* it should not be added to the
compiler option.  On GNU/Linux, it is not required any more (with newer
glibc), but it is still OK to have -lpthread option.

Here, libgcrypt only needs to know if pthread API is available or not.
For actual linking, it uses GPG_ERROR_MT_LIBS (see tests/Makefile.am).

GPG_ERROR_MT_LIBS is from libgpg-error and it is libgpg-error which
checks pthread API more deeply and pthread linking at its build time.
It uses libgpg-error/m4/threadlib.m4 from gnulib.
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251203/84da39ee/attachment.html>

From giacomo at tesio.it  Wed Dec  3 11:38:04 2025
From: giacomo at tesio.it (Giacomo Tesio)
Date: Wed, 3 Dec 2025 11:38:04 +0100
Subject: GPGME: locate-keys: how identify that different keys were returned
 by keyservers
Message-ID: <20251203113804.21c3fe3c@hermes.development.it>

Hi, while trying to improve the usability of key lookup in Claws-Mail
with a contextual menu that let you search for pgp keys over any email,
upstream developers proposed an interesting scenario I would not know
how to handle, despite looking at the GPGME documentation.

The scenario is running "gpg --locate-keys email at example.org" with the
configured keyservers returning different keys for that email address.

While I do not know if such scenario is technically possible, and I was
unable to replicate it to test by myself (sorry), I wonder how GPGME
would behave in such situation (in particular, gpgme_get_key).

Maybe all returned keys would be added to the keyring and
GPG_ERR_AMBIGUOUS_NAME would be returned?
Or maybe GPG_ERR_AMBIGUOUS_NAME would be returned but the keyring would
stay unchanged?
Or maybe the first key returned by the keyserver "wins", and all other
keys get discarded?

In general, is this something that might happen?
And if so, how gpg handles the case?


Thanks for your help.


Giacomo


From bwalzer at 59.ca  Wed Dec  3 18:22:36 2025
From: bwalzer at 59.ca (Bruce Walzer)
Date: Wed, 3 Dec 2025 11:22:36 -0600
Subject: GPGME: locate-keys: how identify that different keys were
 returned by keyservers
In-Reply-To: <20251203113804.21c3fe3c@hermes.development.it>
References: <20251203113804.21c3fe3c@hermes.development.it>
Message-ID: <aTBx3FDrY6YrpBjN@watt.59.ca>

On Wed, Dec 03, 2025 at 11:38:04AM +0100, Giacomo Tesio wrote:
> Hi, while trying to improve the usability of key lookup in Claws-Mail
> with a contextual menu that let you search for pgp keys over any email,
> upstream developers proposed an interesting scenario I would not know
> how to handle, despite looking at the GPGME documentation.
> 
> The scenario is running "gpg --locate-keys email at example.org" with the
> configured keyservers returning different keys for that email address.

In PGP world, identities are denoted with a hex number. A key
fingerprint or the shortened key ID. These identities can normally be
considered to unique. The email address on the other hand is really
just a convenience feature tacked on to the identity. It is not only
possible, but reasonably common for there to be two PGP keys with the
same email address. For example, that can happen when someone abandons
a PGP key and starts over with another one with the same email
address. So the problem seems intrinsic to me. The user will
eventually be expected to determine which key fingerprint/ID is
correct.

Bruce