From alsaiditransport0 at gmail.com  Mon Nov  3 22:00:57 2025
From: alsaiditransport0 at gmail.com (Alsaiditransport)
Date: Mon, 3 Nov 2025 23:00:57 +0200
Subject: =?UTF-8?B?2K7Yr9mF2KfYqiDZhtmC2YQg2KfZhNi52YHYtCDZgdmKINiu2YXZitizINmF2LTZiti3?=
Message-ID: <CAEeabLNL6AkLmy1DSyjR6GFr6Fuwztbh87Go8-67nfeB=qA7kw@mail.gmail.com>

???? ????? *??? ?????* ????? ?? ???? ??????? ?????? ???? ?? ????? ???????
??? *???? ????* ?*????? ????* ?*????*? ??? ?????? ???? ???????? ??? ???????
???????? ???? ?????. ??? ??? ??????? ???? ????? ?????? ???? ?????? ????????
??????? ????? ?? ????? ????? ????? ????? ????? ?????? ?? ??????? ???
???????.

????? ???? ??? ??? ????? ????
<https://al-saiditransport.info/%D8%B4%D8%B1%D9%83%D8%A9-%D9%86%D9%82%D9%84-%D8%B9%D9%81%D8%B4-%D8%A8%D8%AE%D9%85%D9%8A%D8%B3-%D9%85%D8%B4%D9%8A%D8%B7/>
????? ??????? ??????? ?? ??? ?????? ???? ???????? ??? ????? ??? ???? ?????
??? ????. ??? ???? ????? ????? ???? ?? ?? ?????? ??????? ?????? ???????
??????? ?????????? ???????? ???? ????? ??????? ?????? ??? ????? ??? ??????
????? ?????? ?? ??????. ??? ????? ?????? ?? ???????? ?????? ??? ?????
?????? ?????? ??????? ??? ?? ???? ?? ??????.

??? *????? ????*? ???? ???? ??? ??? ?????? ????
<https://al-saiditransport.info/%D8%A7%D9%81%D8%B6%D9%84-27-%D8%B4%D8%B1%D9%83%D8%A9-%D9%86%D9%82%D9%84-%D8%B9%D9%81%D8%B4-%D8%A8%D9%85%D8%AD%D8%A7%D9%8A%D9%84-%D8%B9%D8%B3%D9%8A%D8%B1/>
???????? ??????? ???? ????? ??? ????????. ????? ?????? ??? ???? ??????
????? ?????? ?????? ?? ???? ????? ???? ????? ??????? ??? ???? ??????? ???
???? ??????? ?????? ??????? ??????. ??? ???? ?????? ?????? ?????? ?????
????? ????? ??????? ??? ?? ?????? ?? ???? ??????? ??????????? ?? ?????.

??? ???? ??? ??? ????
<https://al-saiditransport.info/%D8%A7%D9%81%D8%B6%D9%84-27-%D8%B4%D8%B1%D9%83%D8%A9-%D9%86%D9%82%D9%84-%D8%B9%D9%81%D8%B4-%D9%81%D9%8A-%D8%A8%D9%8A%D8%B4%D8%A9/>
??? ????? ???? ?? ???? ???????? ?? ??????? ???? ???????? ??? ?????? ?????
?? ????? ????????? ?? ????? ??? ???? ????? ?? ???? ???? ?????????. ????
?????? ????? ????? ???? ??????? ???? ?????? ?? ????? ???? ???? ??? ??????
???????. ??? ????? ??????? ??? ??????? ?? ???????? ??????? ??? ??? ???????
???????? ???????? ?????? ?????.

????? ??? ??????? ?????? ??? ??? ????: *????? ???? ??? ??? ???????? ?????
?? ???????*. ??? ?? ????? ?????? ???? ?? ???? ?????? ???? ?????? ?? ????
????? ?? ???? ????????? ????. ???? ??? ??????? ????? ??? ??????? ?? *????
????* ?? *????? ????* ?? *????* ???? ????? ??? ????? ?????? ??????? ??????
?? ??????? ??? ???????.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251103/b36a8cde/attachment-0001.html>

From kloecker at kde.org  Fri Nov  7 10:02:53 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Fri, 07 Nov 2025 10:02:53 +0100
Subject: GPGMEPP and C++ antipatterns
In-Reply-To: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
References: <13fbd315-e6ba-453a-8403-4286976d3d0a@sixdemonbag.org>
Message-ID: <3583157.sQuhbGJ8Bu@daneel>

Hi Robert,

thanks for your email. Let's move this to the gnupg-devel at gnupg.org mailing 
list. I hope I'm using the correct email address of yours. mailman has 
replaced your address in the From header with "Robert J. Hansen via Gnupg-
users" <gnupg-users at gnupg.org> (probably because of SPF & friends).

On Donnerstag, 6. November 2025 20:53:26 Mitteleurop?ische Normalzeit Robert 
J. Hansen via Gnupg-users wrote:
> After using GPGMEPP for a week or so, I'm pleased with it. Somebody 
> clearly put some thought into how to make it a properly C++ library, 
> rather than just a thin wrapper around a C one. Whoever's responsible 
> for that (Ingo?), thank you.

Thanks, but that was long before I took over.

> However, I do have a couple of minor nits. (Of course I do. It's me.)

Believe me, I have more than just a couple of minor nits about the API. The 
problem is that we do guarantee ABI stability which makes it nigh to 
impossible to fix errors of the past or to modernize the API.

> First, a number of functions accept unsigned ints as a parameter. This 
> involves a minor pain point for those of us working in environments that 
> require us to follow the MISRA C++ guidelines. Admittedly, it's a 
> one-letter fix:
> 
> 	(*ctx).setKeyListMode(0);
> 
> 		|
> 
> 	     becomes
> 
> 		|
> 
> 		V
> 	(*ctx).setKeyListMode(0U);
> 
> but it would be nice if we could find some way to avoid one letter of 
> syntactic sugar and let us express code in the most natural way.
> 
> Second, MISRA has ? I can only call them _opinions_, shall we say ? on 
> the subject of pointers. Look at, e.g., creating a new Context:
> 
> 	auto ctx = unique_ptr<Context>(OpenPGP);
> 	if (nullptr == ctx) {
> 	    // handle the error
> 	}

See below for Robert correcting the above example.

> Here there are two problems. The first is that GPGMEPP is using 
> old-style enums rather than modern C++ class enums, which means they're 
> not typesafe and it's harder for static analysis tools to detect when 
> you're feeding in garbage.

Looking at the history the first registered commit in the current gpgmepp repo 
is from early 2004, i.e. almost a decade before the modernization of C++ 
started. (The commits that predate this date are lost in an old branch that's 
probably still available in some backup.)

Regarding class enums, I'm not yet sure how/when to use them properly. In my 
understanding they are unsuitable for bit flags and many of gpgmepp enums are 
bit flags.

> The second is that per MISRA, unique_ptrs and 
> shared_ptrs should be created only by calls to make_unique and/or 
> make_shared, not by direct application of the constructor.

I wholeheartedly agree with you and MISRA. But wait: There's
static std::unique_ptr<Context> create(Protocol proto);
since many years. What's missing is a function that returns a shared_ptr.

> Hence, two more suggestions. First, replace all enums with C++ class 
> enums, and second, make createForProtocol take a template parameter of 
> the type of pointer to return, whether unique, shared, or raw.

I'd appreciate if you would propose patches for this. I'm not sure how we can 
make those changes API- and ABI-compatible.

For "pure" enums (like Protocol) the problem is that converting them to "class 
enums" makes them, by definition, scoped which is ABI-compatible but not source 
compatible.

For enums that are used as bit flags I'm at a loss how class enums and bit flags 
can work. The internet seems to suggest that one should simply overload 
operator| to avoid the compiler's complaints, but to me (and others) this 
feels like forcing something to fit which doesn't fit.

For createForProtocol/create the easiest would probably be a new method with a 
different name that replaces the old methods. Too bad that the best name 
"create" is already taken. What about adding a non-templated createShared 
method to complement the existing createForProtocol and create? For version 
3.0 (which I'm not sure will ever happen) we could then clean this up. I'm 
open for alternative suggestions, i.e. we can still add a templated variant if 
you have a good suggestion for a name.

Regarding the implementation of create we can easily make create use 
make_unique internally.

> These minor problems aren't creating any obstacles to my development, 
> just requiring me to fill out a small amount of paperwork documenting 
> the deviations from MISRA. All in all I quite like GPGMEPP. Thanks for 
> the code, guys. :)

Thanks! It's nice to hear that it's useful for others.

On Donnerstag, 6. November 2025 22:00:52 Mitteleurop?ische Normalzeit Robert 
J. Hansen via Gnupg-users wrote:
> >      auto ctx = unique_ptr<Context>(OpenPGP);
> 
> 
> Gah! I was literally looking at my code while copying it and still 
> somehow managed to goof it.
> 
> "auto ctx = unique_ptr<Context>(Context::createForProtocol(OpenPGP));"

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/20251107/ccd40702/attachment.sig>

From max.allan at chainguard.dev  Fri Nov  7 11:08:16 2025
From: max.allan at chainguard.dev (Max Allan)
Date: Fri, 7 Nov 2025 10:08:16 +0000
Subject: GPG 2.4.7 locking problem
Message-ID: <CA+T1A2hnD7c7V21UnMg1h93+vb_DWR9XxvbZDY-FNoFZQWn6VQ@mail.gmail.com>

Hi,
I wanted to report this as a bug but it says I need to get permission to
raise bugs from a mailing list. So here I am.

When using GPG 2.4.7 or 2.4.8 in a Docker build process to add a key, the
gpg command will start keyboxd and gpg-agent. And keyboxd creates a lock
file. ( I tried going back to a 2.2 version and it works without creating a
keyboxd or a lockfile)

When those processes are killed the lock file remains. EVEN if you ran the
import with "--lock-never"

When the image is used, any gpg commands will fail because the hostname is
different and there is no longer a process 8.

You can see this problem without Docker:

/ # ps -ef

PID   USER     TIME  COMMAND

    1 root      0:00 /bin/sh

   41 root      0:00 ps -ef

/ # ls -l ~/.gnupg

ls: /root/.gnupg: No such file or directory

/ # gpg --import --lock-never me.gpg

gpg: directory '/root/.gnupg' created

gpg: /root/.gnupg/trustdb.gpg: trustdb created

gpg: key CECCAAB88A9758B4: public key "argo <argo at example.com>" imported

gpg: Total number processed: 1

gpg:               imported: 1

/ # ls -l ~/.gnupg/public-keys.d/pubring.db.lock

-rw-r--r--    2 root     root            24 Nov  7 09:56
/root/.gnupg/public-keys.d/pubring.db.lock

/ # ps -ef

PID   USER     TIME  COMMAND

    1 root      0:00 /bin/sh

   45 root      0:00 keyboxd --homedir /root/.gnupg --daemon

   49 root      0:00 gpg-agent --homedir /root/.gnupg --use-standard-socket
--daemon

   53 root      0:00 ps -ef

/ # kill -9 45 49

/ # ls -l ~/.gnupg/public-keys.d/pubring.db.lock

-rw-r--r--    2 root     root            24 Nov  7 09:56
/root/.gnupg/public-keys.d/pubring.db.lock



If you were in an "image build" process the keyboxd and gpg-agent processes
would be killed. And they don't remove the lockfile. And when the image is
used the hostname could be anything so it can't break the lock.

This feels like 2 bugs to me.
First: --lock-never still creates a lock.
Second: Terminating the process (without using gpgconf) does not remove the
unwanted lockfile.

I did ask on Stackoverflow  with a full example in Alpine, but didn't get
any responses yet.
https://stackoverflow.com/questions/79811273/using-gpg-in-docker-build-step-is-there-an-easier-way-or-option-to-autokill-the/79811281#79811281


Thanks,
Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251107/a5ce0f5a/attachment.html>

From giacomo at tesio.it  Sat Nov  8 15:29:09 2025
From: giacomo at tesio.it (Giacomo Tesio)
Date: Sat, 8 Nov 2025 15:29:09 +0100
Subject: GPGME: gpgme_get_key bug
Message-ID: <20251108152909.7a46add3@hermes.development.it>

Hi, while working on a patch for Claws-Mail, I realized that
gpgme_get_key ignores context configuration set with either
gpgme_set_ctx_flag or gpgme_set_offline.

Looking at the source code in gpgme/src/keylist.c, I saw that a new
listctx is created "to avoid the user's I/O callback handlers" and 
part of the calling ctx's configuration is copied there.

However, imho, at least "auto-key-locate" ctx flag and offline mode
should be copied too, to actually serve the caller's request, as
they may impact the key retrieval.


You can find a patch attached.


Cheers,


Giacomo

PS: I tried to report this on bugzilla, but the registration page
suggest to ask here for credentials. Feel free to use "giacomo" as
handle, "Giacomo Tesio" as shown name, and this address as email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-gpgme_get_key-respect-caller-s-ctx-configuration.patch
Type: text/x-patch
Size: 1150 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251108/363534fb/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: Firma digitale OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251108/363534fb/attachment-0001.sig>

From her at sorah.jp  Sun Nov  9 15:24:04 2025
From: her at sorah.jp (Sorah Fukumori)
Date: Sun, 9 Nov 2025 23:24:04 +0900
Subject: Requesting backport of read_key_file memory leak fix to 2.4
In-Reply-To: <87ed16du7r.fsf@akagi.fsij.org>
References: <20250113122821.2587166-2-her@sorah.jp>
 <87ed16du7r.fsf@akagi.fsij.org>
Message-ID: <CA+wiQwtHmQmOgZJ8zdMint3tXUHTQ3EZDO=NwvBcMrRixBkqpw@mail.gmail.com>

Hello,

Can the commit 137481fa1002c417cd2c0661b9eefd893b0149d3 have a review
for backport to the stable branch (STABLE-BRANCH-2-4)?
This bug can be reproduced on 2.4.8, and I'd like to get it fixed on
2.4 before it reaches EOL.

# I am unsure of a formalized way to request backports, pardon me if
I'm doing it wrong.

Thanks,
Sorah

---------- Forwarded message ---------
From: NIIBE Yutaka <gniibe at fsij.org>
Date: Tue, 14 Jan 2025 at 11:07
Subject: Re: [PATCH gnupg] agent: Fix a memory leak
To: Sorah Fukumori <her at sorah.jp>, <gnupg-devel at gnupg.org>


Hello,

Sorah Fukumori wrote:
> * agent/findkey.c (read_key_file): Free the buffer,
>   which were forgotten to be freed at commit 434a641d40c on T6944.
>   Otherwise the 'keyinfo --list' agent command gradually leads to
>   memory exhaustion.

Thank you, good catch.  I applied it to master, in the commit:

        137481fa1002c417cd2c0661b9eefd893b0149d3
--


-- 
Sorah Fukumori https://sorah.jp/


From wk at gnupg.org  Mon Nov 10 09:35:32 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 10 Nov 2025 09:35:32 +0100
Subject: GPGME: gpgme_get_key bug
In-Reply-To: <20251108152909.7a46add3@hermes.development.it> (Giacomo Tesio's
 message of "Sat, 8 Nov 2025 15:29:09 +0100")
References: <20251108152909.7a46add3@hermes.development.it>
Message-ID: <87jyzyxp2j.fsf@jacob.g10code.de>

Hi!

On Sat,  8 Nov 2025 15:29, Giacomo Tesio said:

> However, imho, at least "auto-key-locate" ctx flag and offline mode
> should be copied too, to actually serve the caller's request, as
> they may impact the key retrieval.

I agree and applied your patch.  Thanks.


Shalom-Salam,

   Werner


ps.
I created the account for you.  Sorry for the trouble but we have
more and more problems with AI slop

-- 
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/20251110/27669232/attachment.sig>

From wk at gnupg.org  Mon Nov 10 09:37:01 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 10 Nov 2025 09:37:01 +0100
Subject: Requesting backport of read_key_file memory leak fix to 2.4
In-Reply-To: <CA+wiQwtHmQmOgZJ8zdMint3tXUHTQ3EZDO=NwvBcMrRixBkqpw@mail.gmail.com>
 (Sorah Fukumori via Gnupg-devel's message of "Sun, 9 Nov 2025 23:24:04
 +0900")
References: <20250113122821.2587166-2-her@sorah.jp>
 <87ed16du7r.fsf@akagi.fsij.org>
 <CA+wiQwtHmQmOgZJ8zdMint3tXUHTQ3EZDO=NwvBcMrRixBkqpw@mail.gmail.com>
Message-ID: <87framxp02.fsf@jacob.g10code.de>

Hi!

On Sun,  9 Nov 2025 23:24, Sorah Fukumori said:
> Can the commit 137481fa1002c417cd2c0661b9eefd893b0149d3 have a review
> for backport to the stable branch (STABLE-BRANCH-2-4)?

We can do this.  However, there might be no further 2.4 release.


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

From wk at gnupg.org  Mon Nov 10 14:51:01 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 10 Nov 2025 14:51:01 +0100
Subject: GPG 2.4.7 locking problem
In-Reply-To: <CA+T1A2hnD7c7V21UnMg1h93+vb_DWR9XxvbZDY-FNoFZQWn6VQ@mail.gmail.com>
 (Max Allan via Gnupg-devel's message of "Fri, 7 Nov 2025 10:08:16
 +0000")
References: <CA+T1A2hnD7c7V21UnMg1h93+vb_DWR9XxvbZDY-FNoFZQWn6VQ@mail.gmail.com>
Message-ID: <87ms4uvvwa.fsf@jacob.g10code.de>

On Fri,  7 Nov 2025 10:08, Max Allan said:

> When those processes are killed the lock file remains. EVEN if you ran the
> import with "--lock-never"

Oh, I forgot about this old option.  This may lead to all kind of
problems because it entirely disables the locking module for all kind of
locks.  We use file locks to protect the launching of daemons (gpg-agent,
keyboxd, dirmngr) as weel as to protect pubring.gpg and pubring.kbx
files.

> -rw-r--r--    2 root     root            24 Nov  7 09:56
> /root/.gnupg/public-keys.d/pubring.db.lock

and also to lock the sqlite database pubring.db so that only one keyboxd
process may use it.  There should be only one which is assured by using
a lock when launching keyboxd.

On Unix you may cat the file to see which process holds the lock.

> If you were in an "image build" process the keyboxd and gpg-agent processes
> would be killed. And they don't remove the lockfile. And when the image is

That depends on how you kill them; SIGKILL will for sure not clean them
up.  However we employ a stale lock removal method which works if the
lockfile has ben created on the same node (using uname(2)) but the
process does not anymore exist.

> Second: Terminating the process (without using gpgconf) does not remove the
> unwanted lockfile.

Try "gpgconf -K all" or send the SIGTERM more than 2 times to each
daemon.

> I did ask on Stackoverflow  with a full example in Alpine, but didn't get
> any responses yet.

Sorry, no time to read the log.


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/20251110/b9376538/attachment.sig>

From gniibe at fsij.org  Tue Nov 11 03:30:30 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 11 Nov 2025 11:30:30 +0900
Subject: Requesting backport of read_key_file memory leak fix to 2.4
In-Reply-To: <CA+wiQwtHmQmOgZJ8zdMint3tXUHTQ3EZDO=NwvBcMrRixBkqpw@mail.gmail.com>
References: <20250113122821.2587166-2-her@sorah.jp>
 <87ed16du7r.fsf@akagi.fsij.org>
 <CA+wiQwtHmQmOgZJ8zdMint3tXUHTQ3EZDO=NwvBcMrRixBkqpw@mail.gmail.com>
Message-ID: <877bvx47y1.fsf@haruna.fsij.org>

Hello,

Sorah Fukumori wrote:
> This bug can be reproduced on 2.4.8, and I'd like to get it fixed on
> 2.4 before it reaches EOL.

Sorry, I should have done earlier.  Ahyhow, applied and pushed to
2.4 branch.
-- 


From me at chandlerdavis.cc  Thu Nov 13 14:04:48 2025
From: me at chandlerdavis.cc (Chandler Davis)
Date: Thu, 13 Nov 2025 13:04:48 +0000
Subject: [PATCH gpgme]: Remove duplicate field description from gpgme_subkey_t
 in manual
Message-ID: <IAnpb7D6uyRhqIBj82DWCsyPhKM5V-ygPkHYzUDGGVrFFctbquV_Tex6bTN7R13Ok98VcuHJs8CMSUja1dM1-NyoL3dA79Gpj7jrxRJroW8=@chandlerdavis.cc>

Hello,

I was referred here from gnupg-users to submit a patch for the gpgme docs. I've done my best to follow the guidelines in the HACKING document, but please let me know if there's anything I missed or should keep in mind for the future.

Also, I'd like to request an account for the bug tracker. My handle is "bitcrshr", full name is "Chandler Davis", and email is "me at chandlerdavis.cc". Apologies if this is already being worked on from my previous email in the users list.

As an aside, I'm new to contributing via mailing list and am largely unfamiliar with the etiquette / norms. I was wondering if there is a GnuPG resource for that somewhere, or if you think it would be worthwhile for me to take a shot at creating one as I get familiarized. In the meantime, I'll dig into more general resources.

Many thanks, and have a good one!

Best,
Chandler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-doc-Remove-duplicate-is_cardkey-from-gpgme_subkey_t.patch
Type: application/octet-stream
Size: 1030 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251113/4df7cf0f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DCO
Type: application/octet-stream
Size: 1271 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251113/4df7cf0f/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251113/4df7cf0f/attachment.sig>

From wk at gnupg.org  Thu Nov 13 16:32:29 2025
From: wk at gnupg.org (Werner Koch)
Date: Thu, 13 Nov 2025 16:32:29 +0100
Subject: [PATCH gpgme]: Remove duplicate field description from
 gpgme_subkey_t in manual
In-Reply-To: <IAnpb7D6uyRhqIBj82DWCsyPhKM5V-ygPkHYzUDGGVrFFctbquV_Tex6bTN7R13Ok98VcuHJs8CMSUja1dM1-NyoL3dA79Gpj7jrxRJroW8=@chandlerdavis.cc>
 (Chandler Davis via Gnupg-devel's message of "Thu, 13 Nov 2025
 13:04:48 +0000")
References: <IAnpb7D6uyRhqIBj82DWCsyPhKM5V-ygPkHYzUDGGVrFFctbquV_Tex6bTN7R13Ok98VcuHJs8CMSUja1dM1-NyoL3dA79Gpj7jrxRJroW8=@chandlerdavis.cc>
Message-ID: <87a50qrlrm.fsf@jacob.g10code.de>

Hi!

On Thu, 13 Nov 2025 13:04, Chandler Davis said:

> docs. I've done my best to follow the guidelines in the HACKING
> document, but please let me know if there's anything I missed or
> should keep in mind for the future.

Thanks for the patch. I merely changed the "(doc) ..." to "doc: ... and
aded a line with "--" so that this change won't show up in the generated
ChangeLog.

> Also, I'd like to request an account for the bug tracker. My handle is
> "bitcrshr", full name is "Chandler Davis", and email is

Created.  You should receive a password reset mail.  But take care: we
are often under AI scraper siege so don't wonder when you see error
mails.

> As an aside, I'm new to contributing via mailing list and am largely
> unfamiliar with the etiquette / norms. I was wondering if there is a
> GnuPG resource for that somewhere, or if you think it would be

I don't think so.  We do it like we do this for decades.  Sending
patches as an attschment is just fine.  If you have a larger patch and
won't to break it up into several ones, "git format-patch" has the
options to do that.  However, an initial mail describing what you want
to do is a good idea.

Oh and yes: No ABI or ABI breaks - if that is required a longer
discussion will be needed.


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

From rjh at sixdemonbag.org  Sat Nov 15 05:04:38 2025
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 14 Nov 2025 23:04:38 -0500
Subject: Linking error with G++ 15.2
Message-ID: <e435463a-5936-40b4-a22e-a219316be247@sixdemonbag.org>

/* This code should not be used as an example of good style.

    This code does nothing useful and may even import garbage
    into your keyring. It is to be compiled as an example of
    a linker failure, not actually executed.

    System: Apple M4 Macbook (aarch64) running Tahoe 26.1.

    First, using Apple Clang++ 17.0.0, everything compiles cleanly:

$ clang++ foo.cc \
`pkg-config --cflags --libs gpgmepp` -o foo -O2 -Wall --std=c++23

    ? but GNU C++ 15.2.0 can't link:

$ g++-15 foo.cc \
`pkg-config --cflags --libs gpgmepp` -o foo -O2 -Wall --std=c++23

Undefined symbols for architecture arm64:
   "GpgME::Error::asStdString[abi:cxx11]() const", referenced from:
       _main in cc3RBL1t.o
ld: symbol(s) not found for architecture arm64
collect2: error: ld returned 1 exit status
*/

#include "gpgme++/context.h"
#include "gpgme++/data.h"
#include "gpgme++/importresult.h"
#include <memory>
#include <print>

const char* data = "this should not be imported";

int main()
{
     GpgME::initializeLibrary();
     const std::unique_ptr<GpgME::Context> ctx {
         GpgME::Context::createForProtocol(GpgME::OpenPGP)
     };
     auto buffer = GpgME::Data(data, strlen(data), true);
     auto errcode = ctx->importKeys(buffer);
     if (errcode.error().isError()) {
       std::println(stderr, "Couldn?t import key: {}",
         errcode.error().asStdString());
     }
     return 0;
}



From sachin.t at ibm.com  Mon Nov 17 11:23:33 2025
From: sachin.t at ibm.com (Sachin T)
Date: Mon, 17 Nov 2025 10:23:33 +0000
Subject: [PATCH libgpg-error] Add patch to support IBM z/OS
In-Reply-To: <CO1PR15MB50031C958422B60B4EFB1C409746A@CO1PR15MB5003.namprd15.prod.outlook.com>
References: <CO1PR15MB50039CCFA359517238A1577B9773A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87bjql30df.fsf@jacob.g10code.de>
 <CO1PR15MB500318A7CFB04F14F4FE363E977CA@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87cyay1jw5.fsf@jacob.g10code.de>
 <CO1PR15MB50031C958422B60B4EFB1C409746A@CO1PR15MB5003.namprd15.prod.outlook.com>
Message-ID: <CO1PR15MB5003A9BCCC4F5F837F7C0ADC97C9A@CO1PR15MB5003.namprd15.prod.outlook.com>

Hi,

This patch provides two z/OS fixes:

  1.
configure.ac: Correct the build_os name and use pkg-config to find zoslib on z/OS and set EXTRA_LIBS_FOR_BUILD to the actual linker flags returned by pkg-config; fail with a clear error if zoslib.pc is not found.
  2.
src/spawn-posix.c: rename the gpgrt_spawn_actions member environ to env.  This avoids a name collision with the global symbol ?environ? (defined as a macro on z/OS), which cause build issues.

Thanks

Signed-off-by: Sachin T <sachin.t at ibm.com>
---
 configure.ac      | 8 +++++---
 src/spawn-posix.c | 8 ++++----
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/configure.ac b/configure.ac
index 9792cba..359cc29 100644
--- a/configure.ac
+++ b/configure.ac
@@ -144,11 +144,13 @@ esac

 # Set some variables for building build platform helpers.
 case "$build_os" in
-    *zOS*)
-        EXTRA_LIBS_FOR_BUILD=zoslib
+    *openedition*)
+        PKG_CHECK_MODULES([ZOSLIB], [zoslib],
+                          [EXTRA_LIBS_FOR_BUILD="$ZOSLIB_LIBS"],
+                          [AC_MSG_ERROR([zoslib not found. Please ensure zoslib.pc is in PKG_CONFIG_PATH.])])
         ;;
     *)
-        EXTRA_LIBS_FOR_BUILD=
+        EXTRA_LIBS_FOR_BUILD=""
 ?????;;
 esac
 AC_SUBST(EXTRA_LIBS_FOR_BUILD)
diff --git a/src/spawn-posix.c b/src/spawn-posix.c
index 8cdd032..73cef10 100644
--- a/src/spawn-posix.c
+++ b/src/spawn-posix.c
@@ -63,7 +63,7 @@
 struct gpgrt_spawn_actions {
   int fd[3];
   const int *except_fds;
-  char **environ;
+  char **env;
   const char *const *envchange;
   void (*atfork) (void *);
   void *atfork_arg;
@@ -432,8 +432,8 @@ my_exec (const char *pgmname, const char *argv[], gpgrt_spawn_actions_t act,
   if (pgmname == NULL)
     return 0;

-  if (act->environ)
-    execve (pgmname, (char *const *)argv, act->environ);
+  if (act->env)
+    execve (pgmname, (char *const *)argv, act->env);
   else
     execv (pgmname, (char *const *)argv);

@@ -534,7 +534,7 @@ void
 _gpgrt_spawn_actions_set_environ (gpgrt_spawn_actions_t act,
                                   char **environ_for_child)
 {
-  act->environ = environ_for_child;
+  act->env = environ_for_child;
 }

 void
--
2.51.0

From: Sachin T <sachin.t at ibm.com>
Date: Monday, 30 June 2025 at 10:25?PM
To: Werner Koch <wk at gnupg.org>, Sachin T via Gnupg-devel <gnupg-devel at gnupg.org>
Subject: Re: [EXTERNAL] Re: [PATCH libgpg-error] Add patch to support IBM z/OS

Hi,

Apologies for the delayed response.

Thank you for the suggestions. I will look into both options and follow up with a patch once I have a solution prepared.
Regards
Sachin

On 20/06/25, 9:31?PM, "Werner Koch" <wk at gnupg.org> wrote:
On Fri, 20 Jun 2025 10:44, Sachin T said:

> zoslib consists of two static libraries and one separate object
> file. Due to a z/OS linker limitation, the .o file can?t be included
> inside an archive , it may get ignored unless one of its symbols is
> explicitly referenced.

I think we have something like this also for an older SunOS or so.  The
solution was to explictly reference the symbol for the main code.  I
think this was/is in Libgcrypt but I can't remember.  But no problem if
you already have a solution.

> Or would you prefer this logic be handled entirely within configure.ac?

I think it better to put this into configure.ac - this also documents
the need for them.

+case "$build_os" in
+    *zOS*)
+        EXTRA_LIBS_FOR_BUILD=-lzoslib -lzoslib-supp <lib_path>/celquopt.s.o
+        ;;

Is there any standard <lib_path> or can this be figured out at configure
run time?

Another option would be to add it to autogen.rc and extend autogen.sh
with a --build-zos option like we did for Windows.


Shalom-Salam,

   Werner

--
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein

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

From me at chandlerdavis.cc  Tue Nov 18 23:05:14 2025
From: me at chandlerdavis.cc (Chandler Davis)
Date: Tue, 18 Nov 2025 22:05:14 +0000
Subject: Poldi, GPGME, and Auth Keys
Message-ID: <cHw9_Jpom1Jic-FA4wYe6IuDTiccG5ASJFrQgxgS5F6RLkeqZW_aSIkNIP8xaQeQpmtDEWuLeYlc8iCOXSrVKPnviTIHxbtr93RDNfDt3ug=@chandlerdavis.cc>

null
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251118/92275956/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251118/92275956/attachment.sig>

From me at chandlerdavis.cc  Wed Nov 19 02:08:24 2025
From: me at chandlerdavis.cc (Chandler Davis)
Date: Wed, 19 Nov 2025 01:08:24 +0000
Subject: Poldi, GPGME, and Auth Keys
In-Reply-To: <cHw9_Jpom1Jic-FA4wYe6IuDTiccG5ASJFrQgxgS5F6RLkeqZW_aSIkNIP8xaQeQpmtDEWuLeYlc8iCOXSrVKPnviTIHxbtr93RDNfDt3ug=@chandlerdavis.cc>
References: <cHw9_Jpom1Jic-FA4wYe6IuDTiccG5ASJFrQgxgS5F6RLkeqZW_aSIkNIP8xaQeQpmtDEWuLeYlc8iCOXSrVKPnviTIHxbtr93RDNfDt3ug=@chandlerdavis.cc>
Message-ID: <DoxL7FiaFsFOeKTBDwoGYJnJIu5B0FbPYU_KRIvhxfhAUbsjZU8yZ6taL5C2XJmAewvd15OfNFtt2KhoeHKutaxTS3ihqTSBmHFFhafD-Kw=@chandlerdavis.cc>

Apologies for the email blunder. I have included the original content of the message below. If this happens again, I'll switch to a better email client.

---

Hello all,

I've been thinking a lot about GPG as an authentication mechanism. Of course this isn't a new idea--I've so far been able to find it being used via gpg-agent for SSH auth, as well as in the poldi project for PAM. However, I was surprised to find that not much else leveraged it.

I'm primarily interested in getting PAM working for me, but while spelunking I noticed a few potential opportunities to contribute:

1. It seems poldi has had only a few commits in the past few years, and that there's not much prose about it outside the repo. I also had some trouble getting it to build (though that may well be a skill issue). I'm considering giving it some love, but with that:

2. I wonder if poldi would benefit from using the gpgme library instead of directly going through assuan. If that seems reasonable, it follows that perhaps gpgme would benefit from being able to sign and verify challenges using the auth key on a smart card. I don't believe its currently possible to use the auth key at all via gpgme, but please correct me if I'm wrong. This would make it easier for other things outside of poldi to leverage GPG for auth (without using the signing key, which feels hacky and wrong but is probably workable?).

Maybe as a start, it could be good to hack on a reasonable addition to the gpgme interface for auth?

I'll probably end up fleshing this out to some extent for my own experimentation and learning, but wanted to share the ideas and discuss before I get too deep.

Thanks for humoring me, and wishing everyone a happy holiday season (or otherwise, a tolerable rest of the year)!

Best,
Chandler Davis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - me at chandlerdavis.cc - 0x806B3070.asc
Type: application/pgp-keys
Size: 1279 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251119/99992bd3/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251119/99992bd3/attachment.sig>

From gniibe at fsij.org  Wed Nov 19 06:02:48 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 19 Nov 2025 14:02:48 +0900
Subject: [PATCH libgpg-error] Add patch to support IBM z/OS
In-Reply-To: <CO1PR15MB5003A9BCCC4F5F837F7C0ADC97C9A@CO1PR15MB5003.namprd15.prod.outlook.com>
References: <CO1PR15MB50039CCFA359517238A1577B9773A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87bjql30df.fsf@jacob.g10code.de>
 <CO1PR15MB500318A7CFB04F14F4FE363E977CA@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87cyay1jw5.fsf@jacob.g10code.de>
 <CO1PR15MB50031C958422B60B4EFB1C409746A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <CO1PR15MB5003A9BCCC4F5F837F7C0ADC97C9A@CO1PR15MB5003.namprd15.prod.outlook.com>
Message-ID: <874iqqaa2v.fsf@haruna.fsij.org>

Hello,

Sachin T wrote:
> This patch provides two z/OS fixes:
>
>   1.
> configure.ac:

I leave this part to Werner or others.  Just I wonder if the
use/dependency to pkg-config is OK for your system.

>   2.
> src/spawn-posix.c: rename the gpgrt_spawn_actions member environ to env.

I applied this, modifying the field to "envp".  That's because it's not
a pointer to an environment variable, but an array of pointers to
strings.

I pushed the commit:
	26d740f940b3cbda43e0b06a45c86f21ebc236ed
-- 


From wk at gnupg.org  Wed Nov 19 14:29:31 2025
From: wk at gnupg.org (Werner Koch)
Date: Wed, 19 Nov 2025 14:29:31 +0100
Subject: [PATCH libgpg-error] Add patch to support IBM z/OS
In-Reply-To: <874iqqaa2v.fsf@haruna.fsij.org> (NIIBE Yutaka via Gnupg-devel's
 message of "Wed, 19 Nov 2025 14:02:48 +0900")
References: <CO1PR15MB50039CCFA359517238A1577B9773A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87bjql30df.fsf@jacob.g10code.de>
 <CO1PR15MB500318A7CFB04F14F4FE363E977CA@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87cyay1jw5.fsf@jacob.g10code.de>
 <CO1PR15MB50031C958422B60B4EFB1C409746A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <CO1PR15MB5003A9BCCC4F5F837F7C0ADC97C9A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <874iqqaa2v.fsf@haruna.fsij.org>
Message-ID: <87bjkytakk.fsf@jacob.g10code.de>

On Wed, 19 Nov 2025 14:02, NIIBE Yutaka said:

> I leave this part to Werner or others.  Just I wonder if the
> use/dependency to pkg-config is OK for your system.

I applied the patch but changed the error to a warning which has less
regression risk on other platforms.  Frankly I wonder whether
"openedition" is indeed unique term and has not been used in the past on
other Unices.

commit f090f07f1065dca26a013e173f132d39eda973c1

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

From wk at gnupg.org  Wed Nov 19 14:37:37 2025
From: wk at gnupg.org (Werner Koch)
Date: Wed, 19 Nov 2025 14:37:37 +0100
Subject: Poldi, GPGME, and Auth Keys
In-Reply-To: <DoxL7FiaFsFOeKTBDwoGYJnJIu5B0FbPYU_KRIvhxfhAUbsjZU8yZ6taL5C2XJmAewvd15OfNFtt2KhoeHKutaxTS3ihqTSBmHFFhafD-Kw=@chandlerdavis.cc>
 (Chandler Davis via Gnupg-devel's message of "Wed, 19 Nov 2025
 01:08:24 +0000")
References: <cHw9_Jpom1Jic-FA4wYe6IuDTiccG5ASJFrQgxgS5F6RLkeqZW_aSIkNIP8xaQeQpmtDEWuLeYlc8iCOXSrVKPnviTIHxbtr93RDNfDt3ug=@chandlerdavis.cc>
 <DoxL7FiaFsFOeKTBDwoGYJnJIu5B0FbPYU_KRIvhxfhAUbsjZU8yZ6taL5C2XJmAewvd15OfNFtt2KhoeHKutaxTS3ihqTSBmHFFhafD-Kw=@chandlerdavis.cc>
Message-ID: <877bvmta72.fsf@jacob.g10code.de>

On Wed, 19 Nov 2025 01:08, Chandler Davis said:
> Apologies for the email blunder. I have included the original content

:-)

> used via gpg-agent for SSH auth, as well as in the poldi project for
> PAM. However, I was surprised to find that not much else leveraged it.

I don't think that we want to continue with Poldi.  However, Gniibe
wrote back in 2022 gpg-auth, which is a proper part of GnuPG.  This
should make it easier to use a token for authentication and drop the
need for a password.  It needs to be integrated into the display
managers.  Another idea is to use your tokenized ssh key to open the
lock of your entrance door.

Our ticket is https://dev.gnupg.org/T5862


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/20251119/7e82e6e9/attachment.sig>

From me at chandlerdavis.cc  Wed Nov 19 15:48:42 2025
From: me at chandlerdavis.cc (Chandler Davis)
Date: Wed, 19 Nov 2025 14:48:42 +0000
Subject: Poldi, GPGME, and Auth Keys
In-Reply-To: <877bvmta72.fsf@jacob.g10code.de>
References: <cHw9_Jpom1Jic-FA4wYe6IuDTiccG5ASJFrQgxgS5F6RLkeqZW_aSIkNIP8xaQeQpmtDEWuLeYlc8iCOXSrVKPnviTIHxbtr93RDNfDt3ug=@chandlerdavis.cc>
 <DoxL7FiaFsFOeKTBDwoGYJnJIu5B0FbPYU_KRIvhxfhAUbsjZU8yZ6taL5C2XJmAewvd15OfNFtt2KhoeHKutaxTS3ihqTSBmHFFhafD-Kw=@chandlerdavis.cc>
 <877bvmta72.fsf@jacob.g10code.de>
Message-ID: <Ux16F2HtaADdDM_Z3p82CUoQnar0ULLn0FmOaMrWhypDsN0gasYp_Gvv4aF6L9y9A6bHsi82H52n049T3K_YHlVlDcc5G6KDTuz9j75tAwU=@chandlerdavis.cc>


On 11/19/25 8:37 AM, Werner Koch wrote:

> However, Gniibe wrote back in 2022 gpg-auth, which is a proper part of GnuPG.

Ha, and to think I had an original thought!

> Our ticket is https://dev.gnupg.org/T5862

Excellent, I'll dig through that and see what I can come up with. Thanks for pointing me in the right direction!

--?
Best,
Chandler Davis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - me at chandlerdavis.cc - 0x806B3070.asc
Type: application/pgp-keys
Size: 1279 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251119/f7aee7df/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251119/f7aee7df/attachment.sig>

From m at gnupg.org  Wed Nov 19 15:51:17 2025
From: m at gnupg.org (Meik Michalke)
Date: Wed, 19 Nov 2025 15:51:17 +0100
Subject: Poldi, GPGME, and Auth Keys
In-Reply-To: <877bvmta72.fsf@jacob.g10code.de>
References: <cHw9_Jpom1Jic-FA4wYe6IuDTiccG5ASJFrQgxgS5F6RLkeqZW_aSIkNIP8xaQeQpmtDEWuLeYlc8iCOXSrVKPnviTIHxbtr93RDNfDt3ug=@chandlerdavis.cc>
 <DoxL7FiaFsFOeKTBDwoGYJnJIu5B0FbPYU_KRIvhxfhAUbsjZU8yZ6taL5C2XJmAewvd15OfNFtt2KhoeHKutaxTS3ihqTSBmHFFhafD-Kw=@chandlerdavis.cc>
 <877bvmta72.fsf@jacob.g10code.de>
Message-ID: <67843284.WN2fNfrBaD@kasidy>

hi,

Am Mittwoch, 19. November 2025, 14:37:37 CET schrieb Werner Koch via Gnupg-
devel:
> I don't think that we want to continue with Poldi.  However, Gniibe
> wrote back in 2022 gpg-auth, which is a proper part of GnuPG.  This
> should make it easier to use a token for authentication and drop the
> need for a password.  It needs to be integrated into the display
> managers.

i would like to make things more complicated, if i may ;)

i'd love to use a token for login. however, i also have my home directory 
encrypted using fscrypt, a feature of the ext4 file system:

  https://github.com/google/fscrypt

this works well with passwords, because you can use your login password to 
also decrypt an fscrypt directory, and there is a PAM module for fscrypt that 
can do so automatically at login.

so if i used a token for login, i'd end up in an encrypted home (the same is 
also true for logins with fingerprint sensors). so i would either need a 
method to also type my password next to the token to unlock the file system, 
or fscrypt would need to somehow support token auth as a method to unlock 
encrypted file systems. the second approach feels much more elegant to me, 
because i'd like to be able to use a token for unlocking file systems anyway.

fscrypt uses the password as a so called "protector". protectors encrypt the 
actual encryption key for the file system. this way you can have multiple 
protectors for the same file system, just like GnuPG can encrypt the same 
symmetric encryption key for an email with various recipient keys. so it 
should be possible to add a new protector class to fscrypt, like encrypting 
the FS encryption key with gpg.

alternatively, after successful token auth, gpg-auth could decrypt a file in 
memory containing the necessary password and hand it over to the existing 
fscrypt PAM module? at that point, it wouldn't even have to be the login 
password any longer but could be any kind of secret that was used as a 
protector password.


viele gr??e :: m.eik
-------------- 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/20251119/54205140/attachment-0001.sig>

From sachin.t at ibm.com  Wed Nov 19 16:29:43 2025
From: sachin.t at ibm.com (Sachin T)
Date: Wed, 19 Nov 2025 15:29:43 +0000
Subject: [PATCH libgpg-error] Add patch to support IBM z/OS
In-Reply-To: <87bjkytakk.fsf@jacob.g10code.de>
References: <CO1PR15MB50039CCFA359517238A1577B9773A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87bjql30df.fsf@jacob.g10code.de>
 <CO1PR15MB500318A7CFB04F14F4FE363E977CA@CO1PR15MB5003.namprd15.prod.outlook.com>
 <87cyay1jw5.fsf@jacob.g10code.de>
 <CO1PR15MB50031C958422B60B4EFB1C409746A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <CO1PR15MB5003A9BCCC4F5F837F7C0ADC97C9A@CO1PR15MB5003.namprd15.prod.outlook.com>
 <874iqqaa2v.fsf@haruna.fsij.org> <87bjkytakk.fsf@jacob.g10code.de>
Message-ID: <CO1PR15MB50035B2F01068F21948C421B97D7A@CO1PR15MB5003.namprd15.prod.outlook.com>

Thanks for reviewing and merging the patches.

On 19/11/25, 6:56?PM, "Werner Koch" <wk at gnupg.org> wrote:

On Wed, 19 Nov 2025 14:02, NIIBE Yutaka said:

> I leave this part to Werner or others.  Just I wonder if the
> use/dependency to pkg-config is OK for your system.

I applied the patch but changed the error to a warning which has less
regression risk on other platforms.  Frankly I wonder whether
"openedition" is indeed unique term and has not been used in the past on
other Unices.

commit f090f07f1065dca26a013e173f132d39eda973c1

Salam-Shalom,

   Werner

--
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein

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

From wk at gnupg.org  Thu Nov 20 11:44:42 2025
From: wk at gnupg.org (Werner Koch)
Date: Thu, 20 Nov 2025 11:44:42 +0100
Subject: Poldi, GPGME, and Auth Keys
In-Reply-To: <67843284.WN2fNfrBaD@kasidy> (Meik Michalke via Gnupg-devel's
 message of "Wed, 19 Nov 2025 15:51:17 +0100")
References: <cHw9_Jpom1Jic-FA4wYe6IuDTiccG5ASJFrQgxgS5F6RLkeqZW_aSIkNIP8xaQeQpmtDEWuLeYlc8iCOXSrVKPnviTIHxbtr93RDNfDt3ug=@chandlerdavis.cc>
 <DoxL7FiaFsFOeKTBDwoGYJnJIu5B0FbPYU_KRIvhxfhAUbsjZU8yZ6taL5C2XJmAewvd15OfNFtt2KhoeHKutaxTS3ihqTSBmHFFhafD-Kw=@chandlerdavis.cc>
 <877bvmta72.fsf@jacob.g10code.de> <67843284.WN2fNfrBaD@kasidy>
Message-ID: <87h5uprnj9.fsf@jacob.g10code.de>

On Wed, 19 Nov 2025 15:51, Meik Michalke said:

> also true for logins with fingerprint sensors). so i would either need a 
> method to also type my password next to the token to unlock the file system, 

You should use the same token to encrypt your file system g13 with its
dmcrypt backend is what you want.  However, if you prefer fscrypt, it is
possible to support this also in g13.

> fscrypt PAM module? at that point, it wouldn't even have to be the login 

PAM and security does not work weel together ;-)


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/20251120/c341dbd5/attachment.sig>

From m at gnupg.org  Thu Nov 20 12:28:18 2025
From: m at gnupg.org (Meik Michalke)
Date: Thu, 20 Nov 2025 12:28:18 +0100
Subject: Poldi, GPGME, and Auth Keys
In-Reply-To: <87h5uprnj9.fsf@jacob.g10code.de>
References: <cHw9_Jpom1Jic-FA4wYe6IuDTiccG5ASJFrQgxgS5F6RLkeqZW_aSIkNIP8xaQeQpmtDEWuLeYlc8iCOXSrVKPnviTIHxbtr93RDNfDt3ug=@chandlerdavis.cc>
 <67843284.WN2fNfrBaD@kasidy> <87h5uprnj9.fsf@jacob.g10code.de>
Message-ID: <125988054.vexVRKEVTs@kasidy>

Am Donnerstag, 20. November 2025, 11:44:42 CET schrieb Werner Koch:
> You should use the same token to encrypt your file system g13 with its
> dmcrypt backend is what you want.

that would encrypt the whole filesystem, wouldn't it? i don't want to give 
each user a full partition. instead, each user should be able to encrypt their 
own directory individually.

> However, if you prefer fscrypt, it is possible to support this also in g13.

that would be awesome.

> > fscrypt PAM module? at that point, it wouldn't even have to be the login
> 
> PAM and security does not work weel together ;-)

i mentioned PAM because gpg-auth does already provide a PAM mechanism. are 
there better alternatives to decrypt a users' own home directory automatically 
at login?


viele gr??e :: m.eik
-------------- 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/20251120/2f6e0050/attachment.sig>

From sachin.t at ibm.com  Thu Nov 27 10:37:01 2025
From: sachin.t at ibm.com (Sachin T)
Date: Thu, 27 Nov 2025 09:37:01 +0000
Subject: [PATCH libgcrypt] Add support for IBM z/OS
Message-ID: <CO1PR15MB5003C030F26294F7E3D0F32F9775A@CO1PR15MB5003.namprd15.prod.outlook.com>

Hello Maintainers,

Please review the required changes for libgcrypt on z/OS platform.

Patch details as explained below.

  1.
configure.ac: Add z/OS detection to set a printable OS name, hint pthread availability, obtain EXTRA_LIBS_FOR_BUILD via pkg-config/zoslib for external library linking, and disable mmap detection so configure and generated Makefiles behave correctly on z/OS.
  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.
  3.  m4/libtool.m4: Add openedition* case setting lt_cv_deplibs_check_method=pass_all to accommodate z/OS/libtool dependency-check behavior.
  4.
mpi/longlong.h: Exclude the s390x GCC inline-assembly path on z/OS (MVS) because the inline asm is written for GAS-style syntax used on Linux on Z (LoZ) and is not compatible with z/OS.
Rationale: although both targets use the same s390x architecture, z/OS uses HLASM (IBM High Level Assembler) with different syntax/semantics while LoZ uses GAS-style inline asm, so the GAS-formatted asm must be avoided on z/OS.
  5.
src/secmem.c: Make secure-memory locking a no-op on z/OS  because the platform lacks the same secure memory primitives.

---

Signed-off-by: Sachin T <sachin.t at ibm.com>
---
 cipher/Makefile.am |  2 +-
 configure.ac       | 30 +++++++++++++++++++++++++++++-
 doc/Makefile.am    |  2 +-
 m4/libtool.m4      |  4 ++++
 mpi/longlong.h     |  2 +-
 src/secmem.c       |  4 ++++
 6 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/cipher/Makefile.am b/cipher/Makefile.am
index bbcd518a..fc8966f8 100644
--- a/cipher/Makefile.am
+++ b/cipher/Makefile.am
@@ -175,7 +175,7 @@ gost-sb.h: gost-s-box$(EXEEXT_FOR_BUILD)

 gost-s-box$(EXEEXT_FOR_BUILD): gost-s-box.c
 ?????$(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) \
-?????    $(CPPFLAGS_FOR_BUILD) -o $@ $(srcdir)/gost-s-box.c
+?????    $(CPPFLAGS_FOR_BUILD) -o $@ $(srcdir)/gost-s-box.c $(EXTRA_LIBS_FOR_BUILD)


 if ENABLE_O_FLAG_MUNGING
diff --git a/configure.ac b/configure.ac
index f5e78077..c7070169 100644
--- a/configure.ac
+++ b/configure.ac
@@ -290,6 +290,10 @@ case "${host}" in
                   [defined if we use posix_spawn in test program])
         AC_CHECK_HEADERS(spawn.h)
         ;;
+    *-openedition*)
+?????      # The z/OS C runtime includes pthread support, and linking is handled automatically at build time.
+        have_pthread=yes
+        ;;
     *)
       ;;
 esac
@@ -299,7 +303,6 @@ if test "$have_w32_system" = yes; then
 fi
 AM_CONDITIONAL(HAVE_W32_SYSTEM, test "$have_w32_system" = yes)

-
 # A printable OS Name is sometimes useful.
 case "${host}" in
     *-*-mingw32*)
@@ -318,11 +321,29 @@ case "${host}" in
         PRINTABLE_OS_NAME="GNU/Linux"
         ;;

+    *-openedition*)
+        PRINTABLE_OS_NAME="IBM z/OS"
+        ;;
+
     *)
         PRINTABLE_OS_NAME=`uname -s || echo "Unknown"`
         ;;
 esac

+# Set some variables for build platform helpers.
+
+case "$build_os" in
+    *openedition*)
+        PKG_CHECK_MODULES([ZOSLIB], [zoslib],
+                          [EXTRA_LIBS_FOR_BUILD="$ZOSLIB_LIBS"],
+                          [AC_MSG_ERROR([zoslib not found. Please ensure zoslib.pc is in PKG_CONFIG_PATH.])])
+         ;;
+    *)
+        EXTRA_LIBS_FOR_BUILD=""
+?????;;
+esac
+AC_SUBST(EXTRA_LIBS_FOR_BUILD)
+
 NAME_OF_DEV_RANDOM="/dev/random"
 NAME_OF_DEV_URANDOM="/dev/urandom"

@@ -3029,6 +3050,13 @@ AC_CHECK_FUNCS(stpcpy strcasecmp)
 # We have replacements for these in src/g10lib.h
 AC_CHECK_FUNCS(strtoul memmove stricmp atexit raise)
 # Other checks
+case "$host_os" in
+    *openedition*)
+        # mmap is not fully supported on z/os.
+        ac_cv_func_mmap=no
+        ;;
+esac
+
 AC_CHECK_FUNCS(strerror rand mmap getpagesize sysconf waitpid wait4)
 AC_CHECK_FUNCS(gettimeofday getrusage gethrtime clock_gettime syslog)
 AC_CHECK_FUNCS(syscall fcntl ftruncate flockfile getauxval elf_aux_info)
diff --git a/doc/Makefile.am b/doc/Makefile.am
index 2501e5da..f5432700 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -40,7 +40,7 @@ myman_pages   = hmac256.1
 man_MANS = $(myman_pages)

 yat2m$(EXEEXT_FOR_BUILD): yat2m.c
-?????$(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) \
+?????$(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) $(EXTRA_LIBS_FOR_BUILD) \
 ?????    $(CPPFLAGS_FOR_BUILD) -o $@ $(srcdir)/yat2m.c

 .fig.png:
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 102e884d..d4b52744 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -3348,6 +3348,10 @@ openbsd*)
   fi
   ;;

+openedition*)
+  lt_cv_deplibs_check_method=pass_all
+  ;;
+
 osf3* | osf4* | osf5*)
   lt_cv_deplibs_check_method=pass_all
   ;;
diff --git a/mpi/longlong.h b/mpi/longlong.h
index 9e60592a..46de33a8 100644
--- a/mpi/longlong.h
+++ b/mpi/longlong.h
@@ -1505,7 +1505,7 @@ extern USItype __udiv_qrnnd (USItype *, USItype, USItype, USItype);
 /***************************************
  *********** s390x/zSeries  ************
  ***************************************/
-#if defined (__s390x__) && W_TYPE_SIZE == 64 && __GNUC__ >= 4
+#if defined (__s390x__) && !defined (__MVS__) && W_TYPE_SIZE == 64 && __GNUC__ >= 4
 # define add_ssaaaa(sh, sl, ah, al, bh, bl) \
   __asm__ ("algr %1,%5\n"                                               \
 ?????   "alcgr %0,%3\n"                                              \
diff --git a/src/secmem.c b/src/secmem.c
index 19cf1ad4..7c5cac76 100644
--- a/src/secmem.c
+++ b/src/secmem.c
@@ -365,6 +365,10 @@ lock_pool_pages (void *p, size_t n)
      * this whole Windows !@#$% and their user base are inherently insecure. */
   (void)p;
   (void)n;
+#elif defined (__MVS__)
+  /* On z/OS secure memory locking is not implemented */
+  (void)p;
+  (void)n;
 #else
   (void)p;
   (void)n;
--
2.51.0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20251127/ef34aaa1/attachment-0001.html>

From wk at gnupg.org  Thu Nov 27 14:02:20 2025
From: wk at gnupg.org (Werner Koch)
Date: Thu, 27 Nov 2025 14:02:20 +0100
Subject: [Announce] GnuPG 2.5.14 released
Message-ID: <87y0nrocgz.fsf@jacob.g10code.de>

Hello!

We are pleased to announce the availability of a new GnuPG release:
Version 2.5.14.  This release adds new features and fixes a couple of
bugs.

Note that this 2.5 series is fully supported and thus ready for
production use.  This means we won't break anything but may add some
more features before 2.6.

The main features in the 2.5 and 2.6 series are improvements for 64 bit
Windows and the introduction of Kyber (aka ML-KEM or FIPS-203) as PQC
encryption algorithm.  Other than PQC support the 2.6 series will not
differ a lot from 2.4 because the majority of changes are internal to
make use of newer features from the supporting libraries.  Please be
aware that the 2.4 series will reach end of life in June next of year.


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

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

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

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


Noteworthy changes in version 2.5.14 (2025-11-19)
=================================================
         [compared to version 2.5.13]
         
  * gpg: Fix possible memory corruption in the armor parser.  [T7906]

  * gpgsm: Fix output of card serial number in colon listing.  [T7914]

  * agent:ssh: Fix RSA signature handling for newer spec.  [T7882]

  * gpg: Improve/relax the checking of preference options.
    [rG6570700fdd]

  * gpg: Fix the check for the END armor line.  [rG62b8bf2f39]

  * gpg: Do not present a default when asking for another output
    filename.  [T7908]

  * gpg: Include ADSK keys in key listings specified by fingerprints.
    [T7892]

  * agent: Fix a decryption failures if the pinentry dialog for the
    first tried recipient is canceled.  Regression since 2.5.7.
    [T7893, T7649]

  * keyboxd: Fix schema of the fingerprint table.  [T7892]

  * dirmngr: Fix OCSP next-update check.  [rG9ef87bcdb0]

  * gpg: New "pfc" record in colons key listings.  [T7897]

  * gpg: Allow import and export of Kyber secret keys.  [T7315]

  * gpg: Escape characters with the high bit set in NOTATION status
    lines.  [T7896]

  * gpg: New import option "force-update".  [T7892,rGf6237ccd31]

  * agent: Accept a trustlist with a missing LF at the end.
    [rG1b4ac98de7]

  * agent: Support protection for Kyber keys.  [T6638,rGaea62817f3]

  * scd:nks: Make newer TCOS signature cards work.  [rG17596e830f]

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


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 file 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.5.14.tar.bz2 (8065k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.14.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.5.14_20251119.exe (5563k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.14_20251119.exe.sig

The source used to build this installer for 64-bit Windows is available as

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.14_20251119.tar.xz (15M)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.14_20251119.tar.xz.sig

This source tarball may also be used to download all required libraries
at once to build a Unix version on any modern system.  See the included
README.


Debian Packages
===============

We also provide Debian style packages for a couple of Debian variants.
See https://repos.gnupg.org/deb/gnupg/trixie-devel/ or use the menu to
switch to other distros/releases.  If you encounter packaging problems
please report them to the gnupg-devel mailing list.  Due to the upcoming
end-of-life of the current stable version (2.4) the use of the fully
supported -devel versions is suggested.


Windows Installer
=================

A new beta version of Gpg4win is this time not available.  Please wait
for the upcoming Gpg4win 5.0 release.



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

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

     sha1sum gnupg-2.5.14.tar.bz2

   and check that the output matches the next line:

ce1ab578256b93340320f5b46d0f5e6cb7eab89a  gnupg-2.5.14.tar.bz2
f0f9754346dae7ee1788cf6affa95f3fbac0b9b1  gnupg-w32-2.5.14_20251119.tar.xz
e0b8c042dfd22d9c33ccf97c9fcbe2b979815e57  gnupg-w32-2.5.14_20251119.exe



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

This version of GnuPG has support for 26 languages with Chinese, Czech,
Dutch, French, German, Italian, Japanese, Norwegian, Polish, Portuguese,
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/T7869 for updated information.  We are sorry that
due to ongoing DoS on this service, you may end up at a "is under
maintenance page".

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 has mostly been financed by donations.  A team of full-time employed
developers and contractors are working exclusively on GnuPG and related
software like Libgcrypt, GPGME, Kleopatra, Okular, 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:

    ed25519 2020-08-24 [SC] [expires: 2030-06-30]
    6DAA 6E64 A76D 2840 571B  4902 5288 97B8 2640 3ADA
    Werner Koch (dist signing 2020)
  
    ed25519 2021-05-19 [SC] [expires: 2027-04-04]
    AC8E 115B F73E 2D8D 47FA  9908 E98E 9B2D 19C6 C8BD
    Niibe Yutaka (GnuPG Release Key)
  
    rsa3072 2025-05-09 [SC] [expires: 2033-03-03]
    3B76 1AE4 E63B F351 9CE7  D63B ECB6 64CB E133 2EEF
    Alexander Kulbartsch (GnuPG Release Key)
  
    brainpoolP256r1 2021-10-15 [SC] [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.

* Debian Package Signing Key:
  The new Debian style packages are signed using this key:

  ed25519 2025-07-08 [SC] [expires: 2035-07-14]
  3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355
  GnuPG.org Package Signing Key <package-maintainers at gnupg.org>

  See the package website (https://repos.gnupg.org/deb/gnupg) for a list
  of supported distributions and a download link for the key.

-- 
Arguing that you don't care about the right to privacy because you have
nothing to hide is no different from saying you don't care about free
speech because you have nothing to say.                - Edward Snowden
-------------- 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/20251127/521f020a/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From gniibe at fsij.org  Fri Nov 28 02:21:42 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 28 Nov 2025 10:21:42 +0900
Subject: [PATCH libgcrypt] Add support for IBM z/OS
In-Reply-To: <CO1PR15MB5003C030F26294F7E3D0F32F9775A@CO1PR15MB5003.namprd15.prod.outlook.com>
References: <CO1PR15MB5003C030F26294F7E3D0F32F9775A@CO1PR15MB5003.namprd15.prod.outlook.com>
Message-ID: <87y0nr7xzt.fsf@haruna.fsij.org>

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