From wk at gnupg.org Mon Jun 2 18:10:17 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 02 Jun 2025 18:10:17 +0200
Subject: [Announce] GnuPG 2.5.7 released
Message-ID: <877c1ucefq.fsf@jacob.g10code.de>
Hello!
We are pleased to announce the availability of a new GnuPG release:
version 2.5.7. This release is another one in a series of public
testing releases eventually leading to a new stable version 2.7.
The main features in the 2.6 series are improvements for 64 bit Windows
and the introduction of Kyber (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.
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.7 (2025-06-02)
================================================
[compared to version 2.5.6]
* gpg: Allow updating a SHA-1 key certification w/o using
the --force-sign-key option. [T7663]
* gpg: The group key flag has now been fully implemented.
[rG8833a34bf0]
* gpg: Make combination of show-only-fpr-mbox and show-unusable-uid
work. [rGd5a4a2dc89]
* gpg: Do not allow compressed key packets on import. [T7014]
* gpgsm: Allow an empty subject DN also during import. [T7171]
* agent: Recover the old behavior with max-cache-ttl=0. [T6681]
* agent: Fix ECC key on smartcard for composite KEM with PQC.
[T7648]
* scd: Fix a harmless read buffer over-read in a function used by
PKCS#15 cards. [T7662]
* gpg-mail-tube,wks: Support templates for mail content. [T7381]
* Use the KEM interface of Libgcrypt for encryption/decryption.
[T7649]
* Fix a glitch in socket handling in Windows in case of a nonce
mismatch. [rG645cf7d8fc]
Release-info: https://dev.gnupg.org/T7671
Getting the Software
====================
Please follow the instructions found at 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
. 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.7.tar.bz2 (8009k)
https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.7.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.7_20250602.exe (5520k)
https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.7_20250602.exe.sig
The source used to build this installer for 64-bit Windows is available at
https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.7_20250602.tar.xz (15M)
https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.7_20250602.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.
Windows Installer
=================
A new *Beta* version of Gpg4win, our full featured Windows installer
including this version of GnuPG as well as the Kleopatra GUI and a PDF
will be released in a few days.
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.7.tar.bz2 you would use this command:
gpg --verify gnupg-2.5.7.tar.bz2.sig gnupg-2.5.7.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.7.tar.bz2, you run the command like this:
sha1sum gnupg-2.5.7.tar.bz2
and check that the output matches the next line:
4bc48750f6e5471a1606a82142f7742bd8414b2f gnupg-2.5.7.tar.bz2
f2d9106fdd8a6f905bc0688fdb828d583cc41bd0 gnupg-w32-2.5.7_20250602.tar.xz
49dc9af39d01ce26da2fbfba807fdc75fbb1bc19 gnupg-w32-2.5.7_20250602.exe
Internationalization
====================
This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), Czech, 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/T7671 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 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.
--
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: 247 bytes
Desc: not available
URL:
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce
From pschwabauer at intevation.de Wed Jun 4 08:41:18 2025
From: pschwabauer at intevation.de (Paul Schwabauer)
Date: Wed, 4 Jun 2025 08:41:18 +0200
Subject: [gpgmepy] Release a new version?
Message-ID:
There have been many changes to the|gpgmepy|bindings recently. While not
all issues are resolved yet, it would be helpful to tag a new release.
This would allow to update the PyPI entry, making it easier for others
to test the current state and identify any issues in their workflows.
Some fixes might unintentionally break things for other users, so I
believe it's a good time to release a version that still allows building
a working source distribution package.
I'm not familiar with the release process, so I'd appreciate it if
someone else could handle the release.
From kloecker at kde.org Wed Jun 4 10:52:57 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Wed, 04 Jun 2025 10:52:57 +0200
Subject: [gpgmepy] Release a new version?
In-Reply-To:
References:
Message-ID: <26916990.1r3eYUQgxm@daneel>
On Mittwoch, 4. Juni 2025 08:41:18 Mitteleurop?ische Sommerzeit Paul
Schwabauer via Gnupg-devel wrote:
> There have been many changes to the|gpgmepy|bindings recently. While not
> all issues are resolved yet, it would be helpful to tag a new release.
> This would allow to update the PyPI entry, making it easier for others
> to test the current state and identify any issues in their workflows.
>
> Some fixes might unintentionally break things for other users, so I
> believe it's a good time to release a version that still allows building
> a working source distribution package.
>
> I'm not familiar with the release process, so I'd appreciate it if
> someone else could handle the release.
Before we can consider a release you need to make sure that `make distcheck`
succeeds. Currently, it fails because the following code in all-local
```
for f in $(EXTRA_DIST); do \
cp -v $(srcdir)/$$f $(builddir)/; \
done
```
is run for each run of make and this fails because `make distcheck` makes the
copied files read-only. After moving these lines to the `copystamp` target this
problem is solved, but then `make distcheck` fails with
```
ERROR: files left in build directory after distclean:
./README
./MANIFEST.in
./VERSION
./autogen.sh
./autogen.rc
./gpgme.i
./helpers.c
./helpers.h
./private.h
./pyproject.toml
./libtool-patch.sed
./DCO
./HACKING
```
Please look into this. I think adding the files to CLEANFILES should help, but
you cannot simply add $(EXTRA_DIST) because the simple for-loop that copies
the files loses the directories (e.g. doc/HACKING -> HACKING). It might be
better to list the files that actually need to be copied explicitly instead of
copying all files listed in EXTRA_DIST. Or you need to fix the for-loop so that
it preserves the directories when copying the files.
Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL:
From pschwabauer at intevation.de Wed Jun 4 18:05:03 2025
From: pschwabauer at intevation.de (Paul Schwabauer)
Date: Wed, 4 Jun 2025 18:05:03 +0200
Subject: [gpgmepy] Release a new version?
In-Reply-To: <26916990.1r3eYUQgxm@daneel>
References:
<26916990.1r3eYUQgxm@daneel>
Message-ID: <3654a418-67a4-4189-afea-1c9145439824@intevation.de>
I tried fixing this issue, but I get the following error on
2711b5e7a918fbca650acac7570581d83b32a5a8:
ERROR: files left after uninstall:
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/EGG-INFO/native_libs.txt
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/EGG-INFO/PKG-INFO
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/EGG-INFO/dependency_links.txt
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/EGG-INFO/not-zip-safe
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/EGG-INFO/SOURCES.txt
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/EGG-INFO/top_level.txt
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/gpgme.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/core.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/_gpgme.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/errors.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/version.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/__init__.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/_gpgme.cpython-312-aarch64-linux-gnu.so
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/__pycache__/gpgme.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/__pycache__/version.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/__pycache__/core.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/__pycache__/callbacks.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/__pycache__/__init__.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/__pycache__/errors.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/__pycache__/results.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/__pycache__/util.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/__pycache__/_gpgme.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/results.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/create.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/tofu/__init__.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/tofu/policy.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/tofu/__pycache__/policy.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/tofu/__pycache__/__init__.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/event.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/status.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/data/encoding.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/data/__init__.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/data/__pycache__/__init__.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/data/__pycache__/encoding.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/pk.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/__init__.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/keylist/mode.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/keylist/__init__.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/keylist/__pycache__/mode.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/keylist/__pycache__/__init__.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/protocol.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/import_type.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/__pycache__/keysign.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/__pycache__/sigsum.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/__pycache__/validity.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/__pycache__/status.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/__pycache__/pk.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/__pycache__/__init__.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/__pycache__/create.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/__pycache__/md.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/__pycache__/import_type.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/__pycache__/event.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/__pycache__/protocol.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/md.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/validity.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/sigsum.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/keysign.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/sig/mode.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/sig/__init__.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/sig/__pycache__/notation.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/sig/__pycache__/mode.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/sig/__pycache__/__init__.cpython-312.pyc
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/constants/sig/notation.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/util.py
./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/gpg/callbacks.py
make[1]: *** [Makefile:783: distuninstallcheck] Error 1
make[1]: Leaving directory
'/home/***/gpgmepy/build/gpgmepy-2.0.0-beta19/_build/sub'
make: *** [Makefile:729: distcheck] Error 1
Am 04.06.25 um 10:52 schrieb kloecker at kde.org (Ingo Kl?cker):
> On Mittwoch, 4. Juni 2025 08:41:18 Mitteleurop?ische Sommerzeit Paul
> Schwabauer via Gnupg-devel wrote:
>> There have been many changes to the|gpgmepy|bindings recently. While not
>> all issues are resolved yet, it would be helpful to tag a new release.
>> This would allow to update the PyPI entry, making it easier for others
>> to test the current state and identify any issues in their workflows.
>>
>> Some fixes might unintentionally break things for other users, so I
>> believe it's a good time to release a version that still allows building
>> a working source distribution package.
>>
>> I'm not familiar with the release process, so I'd appreciate it if
>> someone else could handle the release.
> Before we can consider a release you need to make sure that `make distcheck`
> succeeds. Currently, it fails because the following code in all-local
> ```
> for f in $(EXTRA_DIST); do \
> cp -v $(srcdir)/$$f $(builddir)/; \
> done
> ```
> is run for each run of make and this fails because `make distcheck` makes the
> copied files read-only. After moving these lines to the `copystamp` target this
> problem is solved, but then `make distcheck` fails with
> ```
> ERROR: files left in build directory after distclean:
> ./README
> ./MANIFEST.in
> ./VERSION
> ./autogen.sh
> ./autogen.rc
> ./gpgme.i
> ./helpers.c
> ./helpers.h
> ./private.h
> ./pyproject.toml
> ./libtool-patch.sed
> ./DCO
> ./HACKING
> ```
>
> Please look into this. I think adding the files to CLEANFILES should help, but
> you cannot simply add $(EXTRA_DIST) because the simple for-loop that copies
> the files loses the directories (e.g. doc/HACKING -> HACKING). It might be
> better to list the files that actually need to be copied explicitly instead of
> copying all files listed in EXTRA_DIST. Or you need to fix the for-loop so that
> it preserves the directories when copying the files.
>
> Regards,
> Ingo
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 228 bytes
> Desc: This is a digitally signed message part.
> URL:
>
From kloecker at kde.org Fri Jun 6 09:47:02 2025
From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=)
Date: Fri, 06 Jun 2025 09:47:02 +0200
Subject: [gpgmepy] Release a new version?
In-Reply-To: <3654a418-67a4-4189-afea-1c9145439824@intevation.de>
References:
<26916990.1r3eYUQgxm@daneel>
<3654a418-67a4-4189-afea-1c9145439824@intevation.de>
Message-ID: <2741850.lGaqSPkdTl@daneel>
On Mittwoch, 4. Juni 2025 18:05:03 Mitteleurop?ische Sommerzeit Paul
Schwabauer wrote:
> I tried fixing this issue, but I get the following error on
> 2711b5e7a918fbca650acac7570581d83b32a5a8:
>
> ERROR: files left after uninstall:
> ./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/E
> GG-INFO/native_libs.txt
> ./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/
> EGG-INFO/PKG-INFO
[...]
> ./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/
> gpg/callbacks.py make[1]: *** [Makefile:783: distuninstallcheck] Error 1
> make[1]: Leaving directory
> '/home/***/gpgmepy/build/gpgmepy-2.0.0-beta19/_build/sub'
> make: *** [Makefile:729: distcheck] Error 1
For me, `make distcheck` succeeds with your changes.
I noticed that your logs use the version number gpgmepy-2.0.0-beta19. The
correct version number should be gpgmepy-2.0.0-beta21. Try running
`./autogen.sh --force`.
If that doesn't help then provide the full logs of `make distcheck`, e.g. via
https://dev.gnupg.org/paste/.
Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL:
From wk at gnupg.org Fri Jun 6 14:09:55 2025
From: wk at gnupg.org (Werner Koch)
Date: Fri, 06 Jun 2025 14:09:55 +0200
Subject: [PATCH ntbtls] Add support for IBM z/OS
In-Reply-To:
(Sachin T.'s message of "Wed, 28 May 2025 09:22:17 +0000")
References:
<87bjrddtt8.fsf@jacob.g10code.de>
Message-ID: <877c1p8418.fsf@jacob.g10code.de>
Hi!
> I wanted to ask about the preferred way to submit patches to GnuPG. I
> noticed that both the mailing list and the GnuPG development site
The mailing list is preferred because there is a large audience which
might spot problems. And for us maintainers it is easier to apply from
mail.
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: 247 bytes
Desc: not available
URL:
From pschwabauer at intevation.de Fri Jun 6 21:27:33 2025
From: pschwabauer at intevation.de (Paul Schwabauer)
Date: Fri, 6 Jun 2025 21:27:33 +0200
Subject: make distcheck
In-Reply-To: <2741850.lGaqSPkdTl@daneel>
References:
<26916990.1r3eYUQgxm@daneel>
<3654a418-67a4-4189-afea-1c9145439824@intevation.de>
<2741850.lGaqSPkdTl@daneel>
Message-ID: <5cd496ca-4bbb-4442-8ab1-f19b23190b96@intevation.de>
I've resolved the issues; it now works on Arch Linux and Ubuntu. I will
push the new version to PyPI testing upon release.
On 6/6/25 09:47, kloecker at kde.org (Ingo Kl?cker) wrote:
> On Mittwoch, 4. Juni 2025 18:05:03 Mitteleurop?ische Sommerzeit Paul
> Schwabauer wrote:
>> I tried fixing this issue, but I get the following error on
>> 2711b5e7a918fbca650acac7570581d83b32a5a8:
>>
>> ERROR: files left after uninstall:
>> ./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/E
>> GG-INFO/native_libs.txt
>> ./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/
>> EGG-INFO/PKG-INFO
> [...]
>> ./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/
>> gpg/callbacks.py make[1]: *** [Makefile:783: distuninstallcheck] Error 1
>> make[1]: Leaving directory
>> '/home/***/gpgmepy/build/gpgmepy-2.0.0-beta19/_build/sub'
>> make: *** [Makefile:729: distcheck] Error 1
> For me, `make distcheck` succeeds with your changes.
>
> I noticed that your logs use the version number gpgmepy-2.0.0-beta19. The
> correct version number should be gpgmepy-2.0.0-beta21. Try running
> `./autogen.sh --force`.
>
> If that doesn't help then provide the full logs of `make distcheck`,
> e.g. via
> https://dev.gnupg.org/paste/.
>
> Regards,
> Ingo
From collin.funk1 at gmail.com Sat Jun 7 23:30:15 2025
From: collin.funk1 at gmail.com (Collin Funk)
Date: Sat, 7 Jun 2025 14:30:15 -0700
Subject: [PATCH Libgpg-error] argparse: Remove a duplicated condition.
Message-ID: <4588d6e0cc5b193c3f135b7d787038aa258f583e.1749331811.git.collin.funk1@gmail.com>
* src/argparse.c (emulated_registry_lookup): Remove duplicated
condition.
--
Signed-off-by: Collin Funk
---
src/argparse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/argparse.c b/src/argparse.c
index bb33370..5fb03b3 100644
--- a/src/argparse.c
+++ b/src/argparse.c
@@ -1263,7 +1263,7 @@ emulated_registry_lookup (gpgrt_argparse_t *arg, const char *name, int *r_err)
estream_t fp;
char *p;
- if (!arg->internal->confname || !arg->internal->confname)
+ if (!arg->internal->confname)
return NULL; /* No system conf file known. */
fname = xtrymalloc (strlen (arg->internal->confname) + 8 + 2 );
--
2.49.0
From jcb62281 at gmail.com Sun Jun 8 04:24:19 2025
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Sat, 7 Jun 2025 21:24:19 -0500
Subject: [PATCH Libgpg-error] argparse: Remove a duplicated condition.
In-Reply-To: <4588d6e0cc5b193c3f135b7d787038aa258f583e.1749331811.git.collin.funk1@gmail.com>
References: <4588d6e0cc5b193c3f135b7d787038aa258f583e.1749331811.git.collin.funk1@gmail.com>
Message-ID: <56eb5a7c-06b1-43ce-adef-3702eef6c0a5@gmail.com>
On 6/7/25 16:30, Collin Funk via Gnupg-devel wrote:
> * src/argparse.c (emulated_registry_lookup): Remove duplicated
> condition.
>
> [...]
>
> - if (!arg->internal->confname || !arg->internal->confname)
> + if (!arg->internal->confname)
> return NULL; /* No system conf file known. */
Is there any possibility of arg->internal being NULL?
Would "(!arg->internal || !arg->internal->confname)" be a better
replacement?
-- Jacob
From collin.funk1 at gmail.com Sun Jun 8 04:53:57 2025
From: collin.funk1 at gmail.com (Collin Funk)
Date: Sat, 07 Jun 2025 19:53:57 -0700
Subject: [PATCH Libgpg-error] argparse: Remove a duplicated condition.
In-Reply-To: <56eb5a7c-06b1-43ce-adef-3702eef6c0a5@gmail.com>
References: <4588d6e0cc5b193c3f135b7d787038aa258f583e.1749331811.git.collin.funk1@gmail.com>
<56eb5a7c-06b1-43ce-adef-3702eef6c0a5@gmail.com>
Message-ID: <874iwrhrju.fsf@gmail.com>
Jacob Bachmeyer writes:
> On 6/7/25 16:30, Collin Funk via Gnupg-devel wrote:
>> * src/argparse.c (emulated_registry_lookup): Remove duplicated
>> condition.
>>
>> [...]
>>
>> - if (!arg->internal->confname || !arg->internal->confname)
>> + if (!arg->internal->confname)
>> return NULL; /* No system conf file known. */
>
> Is there any possibility of arg->internal being NULL?
>
> Would "(!arg->internal || !arg->internal->confname)" be a better
> replacement?
Good questions. I did not consider that maybe that was the original
intention when writing this...
However, upon checking, this section of code is inside:
if (!arg->internal->registry)
{
/* My changes are here. */
[...]
}
So, if it were NULL we would already have problems. :)
Thanks,
Collin
From pschwabauer at intevation.de Mon Jun 9 17:55:39 2025
From: pschwabauer at intevation.de (Paul Schwabauer)
Date: Mon, 9 Jun 2025 17:55:39 +0200
Subject: Request: Add gpgmepy mirror to Github
Message-ID: <56985CEC-07F6-4BBF-B15F-525F4A678A85@intevation.de>
Since the migration of the gpgmepy bindings into a separate repository, it is no longer available on Github. Other repositories like gpgme are currently mirrored to Github. A Github mirror would make it easier to keep an eye on the status of the project.
From wk at gnupg.org Tue Jun 10 10:23:03 2025
From: wk at gnupg.org (Werner Koch)
Date: Tue, 10 Jun 2025 10:23:03 +0200
Subject: [PATCH Libgpg-error] argparse: Remove a duplicated condition.
In-Reply-To: <874iwrhrju.fsf@gmail.com> (Collin Funk via Gnupg-devel's message
of "Sat, 07 Jun 2025 19:53:57 -0700")
References: <4588d6e0cc5b193c3f135b7d787038aa258f583e.1749331811.git.collin.funk1@gmail.com>
<56eb5a7c-06b1-43ce-adef-3702eef6c0a5@gmail.com>
<874iwrhrju.fsf@gmail.com>
Message-ID: <87cybc6m54.fsf@jacob.g10code.de>
On Sat, 7 Jun 2025 19:53, Collin Funk said:
>> Would "(!arg->internal || !arg->internal->confname)" be a better
>> replacement?
>
> Good questions. I did not consider that maybe that was the original
> intention when writing this...
I can't remember but I guess the idea was more my usual pattern of
if (!arg->internal->confname || !*arg->internal->confname)
return NULL; /* No system conf file known. */
and the code havin a typo. However, at other places the code does also
not check for an empy (zero length) file name. Thus your original patch
is okay.
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: 247 bytes
Desc: not available
URL:
From bernhard at intevation.de Tue Jun 10 12:48:06 2025
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 10 Jun 2025 12:48:06 +0200
Subject: Port to z/OS licenses (was: Request to Create account for
contribution)
In-Reply-To:
References:
<87zffn1oga.fsf@jacob.g10code.de>
Message-ID: <202506101248.12332.bernhard@intevation.de>
Werner wrote:
> The patches seem to be under a BSD license.
Had brief look and it seems the licenses have been updated
to GPL-3.0-or-later
* GnuPG: https://github.com/zopencommunity/gpgport/tree/main/patches
* Libgcrypt: https://github.com/zopencommunity/libgcryptport/tree/main/patches
* Libassuan: https://github.com/zopencommunity/libassuanport/tree/main/patches
* Libksba: https://github.com/zopencommunity/libksbaport/tree/main/patches
* Libgpgerror: https://github.com/zopencommunity/libgpgerrorport/tree/main/patches
Some of those should match the license of the original component.
Libgrypt is under LGPL-2.1-or-later and some parts under GPL-2.0-or-later.
https://gnupg.org/software/libgcrypt/index.html
Best is to check for each componentn.
still BSD something:
* NPTH: https://github.com/zopencommunity/npthport/tree/main/patches
* Ntbls: https://github.com/zopencommunity/ntbtlsport/tree/main/patches
* Pinentry: https://github.com/zopencommunity/pinentryport/tree/main/patches
> We can't accept this. ?The
> whole thing seems to be under Apache 2.0 License - this is incompatible
> to the GPL
While it is clear that one step is to get the licenses to be upwards compatible,
just clarify further:
In general:
Many BSD style licenses are compatible to GPL-2.0-or-later
and Apache-2.0 is compatible with GPL-3.0-or-later which GnuPG itself
is licensed under.
But https://github.com/zopencommunity/gpgport
displayes the Apache-2.0 license and reads
"A free software implementation of the GNU Privacy Guard"
this is a bit missleading.
I suggest to add some text to clarify which files are subject to the Apache-2.0
which are under different licenses. The binary build for instance will most likely
be subject to GPL-3.0-or-later as a complete piece of works (if it contains GnuPG). :)
https://github.com/zopencommunity/gpgport/releases/tag/STABLE_gpgport_3214
Regards,
Bernhard
--
https://intevation.de/~bernhard ? +49 541 33 508 3-3
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL:
From sachin.t at ibm.com Tue Jun 10 17:15:15 2025
From: sachin.t at ibm.com (Sachin T)
Date: Tue, 10 Jun 2025 15:15:15 +0000
Subject: [PATCH libgpg-error] Add support for IBM z/OS
Message-ID:
Hi,
Please review patch required for IBM z/OS platform.
1. mkheader target depends on ?zoslib?(specific to z/OS platform) which is passed via LIBS
2. Uses AF_UNIX instead of AF_LOCAL in socketpair().
3. On z/OS, environ is defined as a macro in , so it is temporarily redefined around the header inclusion to avoid conflicts.
Regards
Sachin
---
>From cbea5636c31668ae238d899dfa6d1f4682704f83 Mon Sep 17 00:00:00 2001
From: Sachin T sachin.t at ibm.com
Date: Tue, 10 Jun 2025 20:14:04 +0530
Subject: [PATCH] Add patches for IBM z/OS
Signed-off-by: Sachin T sachin.t at ibm.com
---
src/Makefile.am | 2 +-
src/spawn-posix.c | 13 +++++++++++++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index e56bb23..7e874cf 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -275,7 +275,7 @@ errnos-sym.h: Makefile mkstrtable.awk errnos.in
mkheader$(EXEEXT_FOR_BUILD): mkheader.c Makefile
$(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) \
- $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c
+ $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c $(LIBS)
parts_of_gpg_error_h = \
gpg-error.h.in \
diff --git a/src/spawn-posix.c b/src/spawn-posix.c
index ac19761..2666862 100644
--- a/src/spawn-posix.c
+++ b/src/spawn-posix.c
@@ -27,8 +27,17 @@
#error This code is only used on POSIX
#endif
+#if defined(__MVS__)
+#define environ environ_replace
+#endif
+
#include
#include
+
+#if defined(__MVS__)
+#undef environ
+#endif
+
#include
#include
#include
@@ -330,7 +339,11 @@ do_create_socketpair (int filedes[2])
gpg_error_t err = 0;
_gpgrt_pre_syscall ();
+#if defined(__MVS__)
+ if (socketpair (AF_UNIX, SOCK_STREAM, 0, filedes) == -1)
+#else
if (socketpair (AF_LOCAL, SOCK_STREAM, 0, filedes) == -1)
+#endif
{
err = _gpg_err_code_from_syserror ();
filedes[0] = filedes[1] = -1;
--
2.39.5 (Apple Git-154)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From tmz at pobox.com Tue Jun 10 18:43:06 2025
From: tmz at pobox.com (Todd Zullinger)
Date: Tue, 10 Jun 2025 12:43:06 -0400
Subject: [PATCH libgpg-error] Add support for IBM z/OS
In-Reply-To:
References:
Message-ID:
Sachin T via Gnupg-devel wrote:
> Please review patch required for IBM z/OS platform.
I'm grossly unqualified to review the main goal of the
patch, but there are a few things which jumped out about the
formatting.
[...]
>>From cbea5636c31668ae238d899dfa6d1f4682704f83 Mon Sep 17 00:00:00 2001
> From: Sachin T sachin.t at ibm.com
> Date: Tue, 10 Jun 2025 20:14:04 +0530
> Subject: [PATCH] Add patches for IBM z/OS
>
> Signed-off-by: Sachin T sachin.t at ibm.com
This seems to have been copy/pasted and the mailer and/or
other app(s) handling the patch files have added an unwanted
mailto: link.
> ---
> src/Makefile.am | 2 +-
> src/spawn-posix.c | 13 +++++++++++++
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/src/Makefile.am b/src/Makefile.am
> index e56bb23..7e874cf 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -275,7 +275,7 @@ errnos-sym.h: Makefile mkstrtable.awk errnos.in
>
> mkheader$(EXEEXT_FOR_BUILD): mkheader.c Makefile
> $(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) \
> - $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c
> + $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c $(LIBS)
This hunk appears to be whitespace damaged. The pre and
post lines should both use tab rather than spaces for
indenting (the different amount of spacing was the first
sign of trouble).
--
Todd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
From jcb62281 at gmail.com Wed Jun 11 04:43:28 2025
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Tue, 10 Jun 2025 21:43:28 -0500
Subject: [PATCH libgpg-error] Add support for IBM z/OS
In-Reply-To:
References:
Message-ID:
On 6/10/25 10:15, Sachin T via Gnupg-devel wrote:
>
> [...]
>
> 3. On z/OS, environ is defined as a macro in , so it is
> temporarily redefined around the header inclusion to avoid conflicts.
>
> [...]
>
> diff --git a/src/spawn-posix.c b/src/spawn-posix.c
> index ac19761..2666862 100644
> --- a/src/spawn-posix.c
> +++ b/src/spawn-posix.c
> @@ -27,8 +27,17 @@
>
> #error This code is only used on POSIX
> #endif
>
> +#if defined(__MVS__)
> +#define environ environ_replace
> +#endif
> +
> #include
> #include
> +
> +#if defined(__MVS__)
> +#undef environ
> +#endif
> +
> #include
> #include
> #include
>
What exactly is this dance supposed to do?? The C preprocessor has no
equivalent to M4's pushdef()/popdef().
If environ is supposed to be a symbol, then there is no reason to define
it before including stdlib.h and undefining it to get rid of the macro.?
If the file does not use environ, then why care? If environ's macro
definition is actually important on z/OS, then this dance likely causes
breakage.
What is this trying to accomplish?
-- Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From wk at gnupg.org Wed Jun 11 09:47:53 2025
From: wk at gnupg.org (Werner Koch)
Date: Wed, 11 Jun 2025 09:47:53 +0200
Subject: [PATCH libgpg-error] Add support for IBM z/OS
In-Reply-To:
(Sachin T. via Gnupg-devel's message of "Tue, 10 Jun 2025 15:15:15
+0000")
References:
Message-ID: <87zfee67o6.fsf@jacob.g10code.de>
Hi!
On Tue, 10 Jun 2025 15:15, Sachin T said:
> +#if defined(__MVS__)
> + if (socketpair (AF_UNIX, SOCK_STREAM, 0, filedes) == -1)
> +#else
> if (socketpair (AF_LOCAL, SOCK_STREAM, 0, filedes) == -1)
> +#endif
AF_UNIX is the legacy name for AF_LOCAL and thus should share the same
value. The configure script should thus detect a missing AF_LOCAL and
redefine it to AF_UNIX. This way you don't need to clobber the code
with cpp conditionals. This is the autoconf way of doing things.
However, sometimes it is useful to diretcly test for teh syste, In
particialr for Windows we need special code at some palces and for that
we use W32_SYSTEM. I would also suggest to define MVS_SYSTEM so that we
don't need to directly use __MVS__.
Please see also Jacob's comments.
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: 247 bytes
Desc: not available
URL:
From sachin.t at ibm.com Thu Jun 12 16:22:21 2025
From: sachin.t at ibm.com (Sachin T)
Date: Thu, 12 Jun 2025 14:22:21 +0000
Subject: [PATCH libgpg-error] Add support for IBM z/OS
In-Reply-To:
References:
Message-ID:
Hi Jacob,
Thanks for the feedback. I?d like to clarify the change.
On z/OS, environ is defined as a macro in :
#define environ (*(__EnvnA()))
This causes any use of environ in user code ? even inside structs or function parameters to be macro-expanded in invalid ways. For example, the following line in spawn-posix.c:
char **environ gets rewritten by the preprocessor as: char **(*(__EnvnA()));
act->environ gets rewritten by the preprocessor as: act->(*(__EnvnA()));
leading to compile errors like:
spawn-posix.c:66:10: error: field '__EnvnA' declared as a function
66 | char **environ;
| ^
/c390/archive/zosv2r4/S2441/util/usr/include/stdlib.h:885:29: note: expanded from macro 'environ'
885 | #define environ (*(__EnvnA()))
| ^
spawn-posix.c:421:12: error: expected identifier
421 | if (act->environ)
| ^
/c390/archive/zosv2r4/S2441/util/usr/include/stdlib.h:885:26: note: expanded from macro 'environ'
885 | #define environ (*(__EnvnA()))
| ^
spawn-posix.c:422:48: error: expected identifier
422 | execve (pgmname, (char *const *)argv, act->environ);
| ^
/c390/archive/zosv2r4/S2441/util/usr/include/stdlib.h:885:26: note: expanded from macro 'environ'
885 | #define environ (*(__EnvnA()))
| ^
spawn-posix.c:523:8: error: expected identifier
523 | act->environ = environ_for_child;
| ^
/c390/archive/zosv2r4/S2441/util/usr/include/stdlib.h:885:26: note: expanded from macro 'environ'
885 | #define environ (*(__EnvnA()))
| ^
4 errors generated.
To resolve this, we temporarily redefine environ around the inclusion of the header files that use it. This allows the code to compile without macro expansion issues.
Let me know if you'd prefer an alternative approach.
Regards
Sachin
From: Jacob Bachmeyer
Date: Wednesday, 11 June 2025 at 8:13?AM
To: Sachin T , gnupg-devel at gnupg.org
Subject: [EXTERNAL] Re: [PATCH libgpg-error] Add support for IBM z/OS
On 6/10/25 10:?15, Sachin T via Gnupg-devel wrote: [.?.?.?] 3. On z/OS, environ is defined as a macro in , so it is temporarily redefined around the header inclusion to avoid conflicts. [.?.?.?] diff --git a/src/spawn-posix.?c b/src/spawn-posix.?c
On 6/10/25 10:15, Sachin T via Gnupg-devel wrote:
[...]
3. On z/OS, environ is defined as a macro in , so it is temporarily redefined around the header inclusion to avoid conflicts.
[...]
diff --git a/src/spawn-posix.c b/src/spawn-posix.c
index ac19761..2666862 100644
--- a/src/spawn-posix.c
+++ b/src/spawn-posix.c
@@ -27,8 +27,17 @@
#error This code is only used on POSIX
#endif
+#if defined(__MVS__)
+#define environ environ_replace
+#endif
+
#include
#include
+
+#if defined(__MVS__)
+#undef environ
+#endif
+
#include
#include
#include
What exactly is this dance supposed to do? The C preprocessor has no equivalent to M4's pushdef()/popdef().
If environ is supposed to be a symbol, then there is no reason to define it before including stdlib.h and undefining it to get rid of the macro. If the file does not use environ, then why care? If environ's macro definition is actually important on z/OS, then this dance likely causes breakage.
What is this trying to accomplish?
-- Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sachin.t at ibm.com Thu Jun 12 16:26:51 2025
From: sachin.t at ibm.com (Sachin T)
Date: Thu, 12 Jun 2025 14:26:51 +0000
Subject: [PATCH libgpg-error] Add support for IBM z/OS
In-Reply-To: <87zfee67o6.fsf@jacob.g10code.de>
References:
<87zfee67o6.fsf@jacob.g10code.de>
Message-ID:
Hi Werner,
Thanks for the feedback.
Yes, this patch is not required as AF_UNIX and AF_LOCAL are indeed same value. I would also define MVS_SYSTEM for z/os platform.
Will share the updated patch with these changes.
I have also addressed Jacob?s comments in a separate thread.
Regards
Sachin
On 11/06/25, 1:15?PM, "Werner Koch" wrote:
Hi!
On Tue, 10 Jun 2025 15:15, Sachin T said:
> +#if defined(__MVS__)
> + if (socketpair (AF_UNIX, SOCK_STREAM, 0, filedes) == -1)
> +#else
> if (socketpair (AF_LOCAL, SOCK_STREAM, 0, filedes) == -1)
> +#endif
AF_UNIX is the legacy name for AF_LOCAL and thus should share the same
value. The configure script should thus detect a missing AF_LOCAL and
redefine it to AF_UNIX. This way you don't need to clobber the code
with cpp conditionals. This is the autoconf way of doing things.
However, sometimes it is useful to diretcly test for teh syste, In
particialr for Windows we need special code at some palces and for that
we use W32_SYSTEM. I would also suggest to define MVS_SYSTEM so that we
don't need to directly use __MVS__.
Please see also Jacob's comments.
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:
From sachin.t at ibm.com Thu Jun 12 16:41:06 2025
From: sachin.t at ibm.com (Sachin T)
Date: Thu, 12 Jun 2025 14:41:06 +0000
Subject: [PATCH libgpg-error] Add support for IBM z/OS
Message-ID:
HI Todd,
Thanks for pointing that out, understood.
I wasn?t able to use git send-email due to SMTP restrictions in my environment, so I sent the patch manually via Outlook. Unfortunately, that included some extra metadata.
I?ll make sure to strip that out and ensure plain text formatting next time.
I'll also ensure the white space issues are addressed in the next patch submission.
Best regards,
Sachin
On 10/06/25, 10:13?PM, "Todd Zullinger" wrote:
Sachin T via Gnupg-devel wrote:
> Please review patch required for IBM z/OS platform.
I'm grossly unqualified to review the main goal of the
patch, but there are a few things which jumped out about the
formatting.
[...]
>>From cbea5636c31668ae238d899dfa6d1f4682704f83 Mon Sep 17 00:00:00 2001
> From: Sachin T sachin.t at ibm.com>
> Date: Tue, 10 Jun 2025 20:14:04 +0530
> Subject: [PATCH] Add patches for IBM z/OS
>
> Signed-off-by: Sachin T sachin.t at ibm.com>
This seems to have been copy/pasted and the mailer and/or
other app(s) handling the patch files have added an unwanted
mailto: link.
> ---
> src/Makefile.am | 2 +-
> src/spawn-posix.c | 13 +++++++++++++
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/src/Makefile.am b/src/Makefile.am
> index e56bb23..7e874cf 100644
> --- a/src/Makefile.am
> +++ b/src/Makefile.am
> @@ -275,7 +275,7 @@ errnos-sym.h: Makefile mkstrtable.awk errnos.in
>
> mkheader$(EXEEXT_FOR_BUILD): mkheader.c Makefile
> $(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) \
> - $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c
> + $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c $(LIBS)
This hunk appears to be whitespace damaged. The pre and
post lines should both use tab rather than spaces for
indenting (the different amount of spacing was the first
sign of trouble).
--
Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jcb62281 at gmail.com Fri Jun 13 05:46:30 2025
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Thu, 12 Jun 2025 22:46:30 -0500
Subject: [PATCH libgpg-error] Add support for IBM z/OS
In-Reply-To:
References:
Message-ID: <8767122b-afbb-42da-987c-3dd983ab9f71@gmail.com>
On 6/12/25 09:22, Sachin T wrote:
>
> Hi Jacob,
>
> Thanks for the feedback. I?d like to clarify? the change.
>
> On z/OS, environ is defined as a macro in :
>
> #define environ (*(__EnvnA()))
>
> This causes any use of environ in user code ? even inside structs or
> function parameters ?to be macro-expanded in invalid ways. For
> example, the following line in spawn-posix.c:
>
> char **environ gets rewritten by the preprocessor as: char
> **(*(__EnvnA()));
>
> act->environ gets rewritten by the preprocessor as: act->(*(__EnvnA()));
>
> [...]
>
> To resolve this, we temporarily redefine environ around the inclusion
> of the header files that use it. This allows the code to compile
> without macro expansion issues.
>
That does not work like that in C.? The preprocessor does not process
macro expansions prior to evaluating a #define.
The only part from that part of your patch that actually has effect is:
#if defined(__MVS__)
#undef environ
#endif
If macro-expanding environ causes problems elsewhere in the code, I see
two options:
(1) Avoid using the token 'environ' except as the process global
environment pointer.? (Perhaps we could rename the 'environ' field in
whatever structure 'act' refers to to 'env'?)
(2) Add:
#ifdef environ
#undef environ
#endif
after including .? This would also handle other systems that
define 'environ' as a macro, provided that no access to the process
global environment is actually needed, since it would make environ
inaccessible if a macro expansion is required.
-- Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From pschwabauer at intevation.de Fri Jun 13 19:16:33 2025
From: pschwabauer at intevation.de (Paul Schwabauer)
Date: Fri, 13 Jun 2025 19:16:33 +0200
Subject: Release 2.0.0
In-Reply-To: <5cd496ca-4bbb-4442-8ab1-f19b23190b96@intevation.de>
References:
<26916990.1r3eYUQgxm@daneel>
<3654a418-67a4-4189-afea-1c9145439824@intevation.de>
<2741850.lGaqSPkdTl@daneel>
<5cd496ca-4bbb-4442-8ab1-f19b23190b96@intevation.de>
Message-ID: <8aae540e-fefc-4b6b-91cd-5845a43d4369@intevation.de>
Are there any other issues that need to be solved? I also fixed the
|make sdist| build. I would prefer if other deprecation warnings are
resolved in another release.
Am 06.06.25 um 21:27 schrieb Paul Schwabauer:
> I've resolved the issues; it now works on Arch Linux and Ubuntu. I
> will push the new version to PyPI testing upon release.
>
> On 6/6/25 09:47, kloecker at kde.org (Ingo Kl?cker) wrote:
>> On Mittwoch, 4. Juni 2025 18:05:03 Mitteleurop?ische Sommerzeit Paul
>> Schwabauer wrote:
>>> I tried fixing this issue, but I get the following error on
>>> 2711b5e7a918fbca650acac7570581d83b32a5a8:
>>>
>>> ERROR: files left after uninstall:
>>> ./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/E
>>>
>>> GG-INFO/native_libs.txt
>>> ./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/
>>>
>>> EGG-INFO/PKG-INFO
>> [...]
>>> ./local/lib/python3.12/dist-packages/gpg-2.0.0b19-py3.12-linux-aarch64.egg/
>>>
>>> gpg/callbacks.py make[1]: *** [Makefile:783: distuninstallcheck]
>>> Error 1
>>> make[1]: Leaving directory
>>> '/home/***/gpgmepy/build/gpgmepy-2.0.0-beta19/_build/sub'
>>> make: *** [Makefile:729: distcheck] Error 1
>> For me, `make distcheck` succeeds with your changes.
>>
>> I noticed that your logs use the version number gpgmepy-2.0.0-beta19.
>> The
>> correct version number should be gpgmepy-2.0.0-beta21. Try running
>> `./autogen.sh --force`.
>>
>> If that doesn't help then provide the full logs of `make distcheck`,
>> e.g. via
>> https://dev.gnupg.org/paste/.
>>
>> Regards,
>> Ingo
From vaibhavks1234 at gmail.com Sun Jun 15 19:44:18 2025
From: vaibhavks1234 at gmail.com (VAIBHAV SHARMA)
Date: Sun, 15 Jun 2025 23:14:18 +0530
Subject: Subject: [PATCH] g10 : passphrase.c : read_passphrase_from_fd : Strip
trailing carriage return from passphrase read from file generated on
windows
Message-ID:
Hello,
On Windows, passphrase files may have CRLF (\r\n) line endings.
This patch removes the trailing '\r' if present, avoiding potential
passphrase mismatches during decryption or signing operations.
I have requested this patch after personally facing the issue with a
passphrase file generated on windows as it was silently including \r in the
password and the decryption attempt was failing.
Please find the below attached patch details.
Thanks,
Vaibhav Sharma
---
>From e0e6acca96405c2a291a11074f510e66774925d6 Mon Sep 17 00:00:00 2001
From: VAIBHAV SHARMA <85764094+VAIBHAV675 at users.noreply.github.com>
Date: Sun, 15 Jun 2025 17:29:29 +0000
Subject: [PATCH] g10: Handle CRLF endings in passphrase file input *
g10/passphrase.c (read_passphrase_from_fd): Trim trailing \r character in
passphrase input to correctly handle CRLF endings.
Signed-off-by: VAIBHAV SHARMA <85764094+VAIBHAV675 at users.noreply.github.com>
---
g10/passphrase.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/g10/passphrase.c b/g10/passphrase.c
index c5ec8eae4..32bbc74f6 100644
--- a/g10/passphrase.c
+++ b/g10/passphrase.c
@@ -150,6 +150,12 @@ read_passphrase_from_fd( int fd )
break;
}
pw[i] = 0;
+
+ /* Fix for Windows CRLF line endings for passphrase file generated on
windows:
+ If the passphrase ends with a carriage return character ('\r') due to
CRLF line endings, strip it. */
+ if (i > 0 && pw[i-1] == '\r')
+ pw[i-1] = 0;
+
if (!opt.batch && opt.pinentry_mode != PINENTRY_MODE_LOOPBACK)
tty_printf("\b\b\b \n" );
--
2.49.0
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From wk at gnupg.org Mon Jun 16 09:08:48 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 16 Jun 2025 09:08:48 +0200
Subject: Subject: [PATCH] g10 : passphrase.c : read_passphrase_from_fd :
Strip trailing carriage return from passphrase read from file generated on
windows
In-Reply-To:
(VAIBHAV SHARMA via Gnupg-devel's message of "Sun, 15 Jun 2025
23:14:18 +0530")
References:
Message-ID: <87ecvk40zj.fsf@jacob.g10code.de>
On Sun, 15 Jun 2025 23:14, VAIBHAV SHARMA said:
> I have requested this patch after personally facing the issue with a
> passphrase file generated on windows as it was silently including \r in the
Please fix this outside of GnuPG. We won't change things in GnuPG
because it was never specified what the character set is and whether the
linen ending is CR, or CR+LF. Some software used fopen("foo","r") and
other software uses fopen("foo", "rb") or "w" and "wb" at the other
site. Your change fixes this for you but introduces a regression for
others.
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: 247 bytes
Desc: not available
URL:
From sachin.t at ibm.com Mon Jun 16 10:21:14 2025
From: sachin.t at ibm.com (Sachin T)
Date: Mon, 16 Jun 2025 08:21:14 +0000
Subject: [PATCH libgpg-error] Add support for IBM z/OS
In-Reply-To:
References:
Message-ID:
Hi,
Please review the updated patch with comments from Werner, Jacob and Todd fixed.
*Renamed environ variable to avoid conflict with environ defined in z/os stdlib header
Regards
Sachin
---
Signed-off-by: Sachin T sachin.t at ibm.com
---
src/Makefile.am | 2 +-
src/spawn-posix.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index e56bb23..7e874cf 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -275,7 +275,7 @@ errnos-sym.h: Makefile mkstrtable.awk errnos.in
mkheader$(EXEEXT_FOR_BUILD): mkheader.c Makefile
$(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) \
- $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c
+ $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c $(LIBS)
parts_of_gpg_error_h = \
gpg-error.h.in \
diff --git a/src/spawn-posix.c b/src/spawn-posix.c
index ac19761..0ffc71e 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 **environ_p;
const char *const *envchange;
void (*atfork) (void *);
void *atfork_arg;
@@ -414,8 +414,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->environ_p)
+ execve (pgmname, (char *const *)argv, act->environ_p);
else
execv (pgmname, (char *const *)argv);
@@ -516,7 +516,7 @@ void
_gpgrt_spawn_actions_set_environ (gpgrt_spawn_actions_t act,
char **environ_for_child)
{
- act->environ = environ_for_child;
+ act->environ_p = environ_for_child;
}
void
--
2.39.5 (Apple Git-154)
From: Sachin T
Date: Tuesday, 10 June 2025 at 8:45?PM
To: gnupg-devel at gnupg.org
Cc: Sachin T
Subject: [PATCH libgpg-error] Add support for IBM z/OS
Hi,
Please review patch required for IBM z/OS platform.
1. mkheader target depends on ?zoslib?(specific to z/OS platform) which is passed via LIBS
2. Uses AF_UNIX instead of AF_LOCAL in socketpair().
3. On z/OS, environ is defined as a macro in , so it is temporarily redefined around the header inclusion to avoid conflicts.
Regards
Sachin
---
From cbea5636c31668ae238d899dfa6d1f4682704f83 Mon Sep 17 00:00:00 2001
From: Sachin T sachin.t at ibm.com
Date: Tue, 10 Jun 2025 20:14:04 +0530
Subject: [PATCH] Add patches for IBM z/OS
Signed-off-by: Sachin T sachin.t at ibm.com
---
src/Makefile.am | 2 +-
src/spawn-posix.c | 13 +++++++++++++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index e56bb23..7e874cf 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -275,7 +275,7 @@ errnos-sym.h: Makefile mkstrtable.awk errnos.in
mkheader$(EXEEXT_FOR_BUILD): mkheader.c Makefile
$(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) \
- $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c
+ $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c $(LIBS)
parts_of_gpg_error_h = \
gpg-error.h.in \
diff --git a/src/spawn-posix.c b/src/spawn-posix.c
index ac19761..2666862 100644
--- a/src/spawn-posix.c
+++ b/src/spawn-posix.c
@@ -27,8 +27,17 @@
#error This code is only used on POSIX
#endif
+#if defined(__MVS__)
+#define environ environ_replace
+#endif
+
#include
#include
+
+#if defined(__MVS__)
+#undef environ
+#endif
+
#include
#include
#include
@@ -330,7 +339,11 @@ do_create_socketpair (int filedes[2])
gpg_error_t err = 0;
_gpgrt_pre_syscall ();
+#if defined(__MVS__)
+ if (socketpair (AF_UNIX, SOCK_STREAM, 0, filedes) == -1)
+#else
if (socketpair (AF_LOCAL, SOCK_STREAM, 0, filedes) == -1)
+#endif
{
err = _gpg_err_code_from_syserror ();
filedes[0] = filedes[1] = -1;
--
2.39.5 (Apple Git-154)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jcb62281 at gmail.com Tue Jun 17 04:03:39 2025
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Mon, 16 Jun 2025 21:03:39 -0500
Subject: [PATCH libgpg-error] Add support for IBM z/OS
In-Reply-To:
References:
Message-ID: <4fe89aec-0710-443a-9029-cbc416e123b9@gmail.com>
On 6/16/25 03:21, Sachin T via Gnupg-devel wrote:
>
> Hi,
>
> Please review the updated patch with comments from Werner, Jacob and
> Todd fixed.
>
> *Renamed environ variable to avoid conflict with environ defined in
> z/os stdlib header
>
First, a nit:? the renamed environ is a structure field, not a
variable.? (I would have used "env" instead of "environ_p" but that is
just bikeshedding.)
Second, you are still adding $(LIBS) to the build rule for mkheader and
you should mention that as you previously did.
Lastly, I am probably more impressed than I should be that this is all
you actually need for a z/OS port.? (The other system that I know of
where "environ" is a macro is not a POSIX system.)
> Regards
>
> Sachin
>
> ---
>
> Signed-off-by: Sachin T sachin.t at ibm.com
>
> ---
>
> src/Makefile.am | 2 +-
>
> src/spawn-posix.c | 8 ++++----
>
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/src/Makefile.am b/src/Makefile.am
>
> index e56bb23..7e874cf 100644
>
> --- a/src/Makefile.am
>
> +++ b/src/Makefile.am
>
> @@ -275,7 +275,7 @@ errnos-sym.h: Makefile mkstrtable.awk errnos.in
>
> mkheader$(EXEEXT_FOR_BUILD): mkheader.c Makefile
>
> $(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) \
>
> - $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c
>
> + $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c
> $(LIBS)
>
> parts_of_gpg_error_h = ????????????? ??????????????? \
>
> gpg-error.h.in? \
>
> diff --git a/src/spawn-posix.c b/src/spawn-posix.c
>
> index ac19761..0ffc71e 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 **environ_p;
>
> const char *const *envchange;
>
> void (*atfork) (void *);
>
> void *atfork_arg;
>
> @@ -414,8 +414,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->environ_p)
>
> + execve (pgmname, (char *const *)argv, act->environ_p);
>
> else
>
> execv (pgmname, (char *const *)argv);
>
> @@ -516,7 +516,7 @@ void
>
> _gpgrt_spawn_actions_set_environ (gpgrt_spawn_actions_t act,
>
> char **environ_for_child)
>
> {
>
> - act->environ = environ_for_child;
>
> + act->environ_p = environ_for_child;
>
> }
>
> void
>
> --
>
> 2.39.5 (Apple Git-154)
>
-- Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sachin.t at ibm.com Tue Jun 17 17:41:58 2025
From: sachin.t at ibm.com (Sachin T)
Date: Tue, 17 Jun 2025 15:41:58 +0000
Subject: [PATCH libgpg-error] Add support for IBM z/OS
In-Reply-To: <4fe89aec-0710-443a-9029-cbc416e123b9@gmail.com>
References:
<4fe89aec-0710-443a-9029-cbc416e123b9@gmail.com>
Message-ID:
Thanks. I?ll update the patch description to mention the $(LIBS) change as well. I?ll also rename the struct field to env for clarity.
And yes, z/OS is POSIX-compliant in general, but sometimes we run into small quirks like this environ macro.
Regards
Sachin
From: Jacob Bachmeyer
Date: Tuesday, 17 June 2025 at 7:33?AM
To: Sachin T , gnupg-devel at gnupg.org
Subject: [EXTERNAL] Re: [PATCH libgpg-error] Add support for IBM z/OS
On 6/16/25 03:?21, Sachin T via Gnupg-devel wrote: Hi, Please review the updated patch with comments from Werner, Jacob and Todd fixed. *Renamed environ variable to avoid conflict with environ defined in z/os stdlib header First, a nit:?
On 6/16/25 03:21, Sachin T via Gnupg-devel wrote:
Hi,
Please review the updated patch with comments from Werner, Jacob and Todd fixed.
*Renamed environ variable to avoid conflict with environ defined in z/os stdlib header
First, a nit: the renamed environ is a structure field, not a variable. (I would have used "env" instead of "environ_p" but that is just bikeshedding.)
Second, you are still adding $(LIBS) to the build rule for mkheader and you should mention that as you previously did.
Lastly, I am probably more impressed than I should be that this is all you actually need for a z/OS port. (The other system that I know of where "environ" is a macro is not a POSIX system.)
Regards
Sachin
---
Signed-off-by: Sachin T sachin.t at ibm.com
---
src/Makefile.am | 2 +-
src/spawn-posix.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index e56bb23..7e874cf 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -275,7 +275,7 @@ errnos-sym.h: Makefile mkstrtable.awk errnos.in
mkheader$(EXEEXT_FOR_BUILD): mkheader.c Makefile
$(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) \
- $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c
+ $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c $(LIBS)
parts_of_gpg_error_h = \
gpg-error.h.in \
diff --git a/src/spawn-posix.c b/src/spawn-posix.c
index ac19761..0ffc71e 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 **environ_p;
const char *const *envchange;
void (*atfork) (void *);
void *atfork_arg;
@@ -414,8 +414,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->environ_p)
+ execve (pgmname, (char *const *)argv, act->environ_p);
else
execv (pgmname, (char *const *)argv);
@@ -516,7 +516,7 @@ void
_gpgrt_spawn_actions_set_environ (gpgrt_spawn_actions_t act,
char **environ_for_child)
{
- act->environ = environ_for_child;
+ act->environ_p = environ_for_child;
}
void
--
2.39.5 (Apple Git-154)
-- Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sachin.t at ibm.com Tue Jun 17 18:34:15 2025
From: sachin.t at ibm.com (Sachin T)
Date: Tue, 17 Jun 2025 16:34:15 +0000
Subject: [PATCH libgpg-error] Add patch to support IBM z/OS
Message-ID:
Hi Gpg team,
Please review patch required for libgpg-error on IBM z/OS platform.
Patch details
1. mkheader target depends on ?zoslib?(specific to z/OS platform) which is passed via LIBS
2. Renamed structure field ?environ? to avoid conflict with environ defined in z/OS stdlib header.
Regards
Sachin
---
Signed-off-by: Sachin T sachin.t at ibm.com
---
src/Makefile.am | 2 +-
src/spawn-posix.c | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/Makefile.am b/src/Makefile.am
index e56bb23..7e874cf 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -275,7 +275,7 @@ errnos-sym.h: Makefile mkstrtable.awk errnos.in
mkheader$(EXEEXT_FOR_BUILD): mkheader.c Makefile
$(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) \
- $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c
+ $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c $(LIBS)
parts_of_gpg_error_h = \
gpg-error.h.in \
diff --git a/src/spawn-posix.c b/src/spawn-posix.c
index ac19761..fce0cf5 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;
@@ -414,8 +414,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);
@@ -516,7 +516,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.39.5 (Apple Git-154)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ametzler at bebt.de Wed Jun 18 07:05:41 2025
From: ametzler at bebt.de (Andreas Metzler)
Date: Wed, 18 Jun 2025 07:05:41 +0200
Subject: Release 2.0.0
In-Reply-To: <8aae540e-fefc-4b6b-91cd-5845a43d4369@intevation.de>
References:
<26916990.1r3eYUQgxm@daneel>
<3654a418-67a4-4189-afea-1c9145439824@intevation.de>
<2741850.lGaqSPkdTl@daneel>
<5cd496ca-4bbb-4442-8ab1-f19b23190b96@intevation.de>
<8aae540e-fefc-4b6b-91cd-5845a43d4369@intevation.de>
Message-ID:
On 2025-06-13 Paul Schwabauer via Gnupg-devel wrote:
> Are there any other issues that need to be solved? I also fixed the |make
> sdist| build. I would prefer if other deprecation warnings are resolved in
> another release.
[...]
Good morning Paul,
I see the release happened, could you please also tag it in git?
TIA, cu Andreas
From wk at gnupg.org Wed Jun 18 10:44:12 2025
From: wk at gnupg.org (Werner Koch)
Date: Wed, 18 Jun 2025 10:44:12 +0200
Subject: [PATCH libgpg-error] Add patch to support IBM z/OS
In-Reply-To:
(Sachin T. via Gnupg-devel's message of "Tue, 17 Jun 2025 16:34:15
+0000")
References:
Message-ID: <87bjql30df.fsf@jacob.g10code.de>
On Tue, 17 Jun 2025 16:34, Sachin T said:
> Hi Gpg team,
>
> Please review patch required for libgpg-error on IBM z/OS platform.
Pretty small now. Cool. I have an improvement:
--8<---------------cut here---------------start------------->8---
Set build specific variable for zOS
* configure.ac (EXTRA_LIBS_FOR_BUILD): New ac_subst.
* src/Makefile.am (mkheader): Append that var to the rule.
Modified configure.ac
diff --git a/configure.ac b/configure.ac
index 78d8356..30a241f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -142,6 +142,17 @@ case "${host}" in
;;
esac
+# Set some variables for building build platform helpers.
+case "$build_os" in
+ *zOS*)
+ EXTRA_LIBS_FOR_BUILD=zoslib
+ ;;
+ *)
+ EXTRA_LIBS_FOR_BUILD=
+ ;;
+esac
+AC_SUBST(EXTRA_LIBS_FOR_BUILD)
+
if test "$have_w32_system" != yes; then
gl_THREADLIB_EARLY
Modified src/Makefile.am
diff --git a/src/Makefile.am b/src/Makefile.am
index e56bb23..feae327 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -275,7 +275,8 @@ errnos-sym.h: Makefile mkstrtable.awk errnos.in
mkheader$(EXEEXT_FOR_BUILD): mkheader.c Makefile
$(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) \
- $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c
+ $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) \
+ -o $@ $(srcdir)/mkheader.c $(EXTRA_LIBS_FOR_BUILD)
parts_of_gpg_error_h = \
gpg-error.h.in \
--8<---------------cut here---------------end--------------->8---
I don't know the cpu-vendor-os triplet for zOS - please fix run
config.guess. But using the above approach we should even be abale to
cross-build and LIBS is saved for host things and can be used as you
like. If you need to run configure (do you run it?) you may also want
to add zOS specific stuff into the 'case "${host}" in' part of
configure.
--
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: 247 bytes
Desc: not available
URL:
From sachin.t at ibm.com Fri Jun 20 12:44:44 2025
From: sachin.t at ibm.com (Sachin T)
Date: Fri, 20 Jun 2025 10:44:44 +0000
Subject: [PATCH libgpg-error] Add patch to support IBM z/OS
In-Reply-To: <87bjql30df.fsf@jacob.g10code.de>
References:
<87bjql30df.fsf@jacob.g10code.de>
Message-ID:
Hi,
Thanks regarding the EXTRA_LIBS_FOR_BUILD suggestion, I had a follow-up question.
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.
To work around this, we usually pass all three -lzoslib, lzoslib-supp, and celquopt.s.o? separately to the linker.
Would it be acceptable to pass these externally via the configure invocation like this?
./configure EXTRA_LIBS_FOR_BUILD="-lzoslib -lzoslib-supp /celquopt.s.o "
Or would you prefer this logic be handled entirely within configure.ac?
Regards,
Sachin
On 18/06/25, 2:13?PM, "Werner Koch" wrote:
On Tue, 17 Jun 2025 16:34, Sachin T said:
> Hi Gpg team,
>
> Please review patch required for libgpg-error on IBM z/OS platform.
Pretty small now. Cool. I have an improvement:
--8<---------------cut here---------------start------------->8---
Set build specific variable for zOS
* configure.ac (EXTRA_LIBS_FOR_BUILD): New ac_subst.
* src/Makefile.am (mkheader): Append that var to the rule.
Modified configure.ac
diff --git a/configure.ac b/configure.ac
index 78d8356..30a241f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -142,6 +142,17 @@ case "${host}" in
;;
esac
+# Set some variables for building build platform helpers.
+case "$build_os" in
+ *zOS*)
+ EXTRA_LIBS_FOR_BUILD=zoslib
+ ;;
+ *)
+ EXTRA_LIBS_FOR_BUILD=
+ ;;
+esac
+AC_SUBST(EXTRA_LIBS_FOR_BUILD)
+
if test "$have_w32_system" != yes; then
gl_THREADLIB_EARLY
Modified src/Makefile.am
diff --git a/src/Makefile.am b/src/Makefile.am
index e56bb23..feae327 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -275,7 +275,8 @@ errnos-sym.h: Makefile mkstrtable.awk errnos.in
mkheader$(EXEEXT_FOR_BUILD): mkheader.c Makefile
$(CC_FOR_BUILD) $(CFLAGS_FOR_BUILD) $(LDFLAGS_FOR_BUILD) \
- $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) -o $@ $(srcdir)/mkheader.c
+ $(CPPFLAGS_FOR_BUILD) -g -I. -I$(srcdir) \
+ -o $@ $(srcdir)/mkheader.c $(EXTRA_LIBS_FOR_BUILD)
parts_of_gpg_error_h = \
gpg-error.h.in \
--8<---------------cut here---------------end--------------->8---
I don't know the cpu-vendor-os triplet for zOS - please fix run
config.guess. But using the above approach we should even be abale to
cross-build and LIBS is saved for host things and can be used as you
like. If you need to run configure (do you run it?) you may also want
to add zOS specific stuff into the 'case "${host}" in' part of
configure.
--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From wk at gnupg.org Fri Jun 20 17:47:13 2025
From: wk at gnupg.org (Werner Koch)
Date: Fri, 20 Jun 2025 17:47:13 +0200
Subject: [Announce] GnuPG 2.5.8 released
Message-ID: <87ikkq1kla.fsf@jacob.g10code.de>
Hello!
We are pleased to announce the availability of a new GnuPG release:
version 2.5.8. This release is another one in a series of public
testing releases eventually leading to a new stable version 2.6.
The main features in the 2.6 series are improvements for 64 bit Windows
and the introduction of Kyber (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.8 (2025-06-20)
================================================
[compared to version 2.5.7]
* gpg: Show revocation reason with a standard -k listing. [T7083]
* gpg: Emit a revocation reason as comment in a "pub" record.
[T7083]
* agent: Fix regression in 2.5.7 decrypting with a card based
cv25519 key. [T7676]
* scd:openpgp: Fix a regression in exporting card based ed25519 ssh
keys. [T7589]
* dirmngr: Do not require a keyserver for "gpg --fetch-key".
[T7693]
Release-info: https://dev.gnupg.org/T7672
Getting the Software
====================
Please follow the instructions found at 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
. 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.8.tar.bz2 (8012k)
https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.8.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.8_20250620.exe (5521k)
https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.8_20250620.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.8_20250620.tar.xz (15M)
https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.8_20250620.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.
Windows Installer
=================
A new *Beta* version of Gpg4win, our full featured Windows installer
including this version of GnuPG as well as the Kleopatra GUI and a PDF
will be released in a few days.
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.8.tar.bz2 you would use this command:
gpg --verify gnupg-2.5.8.tar.bz2.sig gnupg-2.5.8.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.8.tar.bz2, you run the command like this:
sha1sum gnupg-2.5.8.tar.bz2
and check that the output matches the next line:
2767432e0c2a1b95e37ad4117f6cca4c49d459a7 gnupg-2.5.8.tar.bz2
3c15efec53247dd21655a9c155ca15b8a507cb9c gnupg-w32-2.5.8_20250620.tar.xz
ff90e52c7707b1d3da3dbb8be48efbdbfe6abc10 gnupg-w32-2.5.8_20250620.exe
Internationalization
====================
This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), Czech, 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/T7672 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 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.
--
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: 247 bytes
Desc: not available
URL:
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce
From wk at gnupg.org Fri Jun 20 18:02:18 2025
From: wk at gnupg.org (Werner Koch)
Date: Fri, 20 Jun 2025 18:02:18 +0200
Subject: [PATCH libgpg-error] Add patch to support IBM z/OS
In-Reply-To:
(Sachin T. via Gnupg-devel's message of "Fri, 20 Jun 2025 10:44:44
+0000")
References:
<87bjql30df.fsf@jacob.g10code.de>
Message-ID: <87cyay1jw5.fsf@jacob.g10code.de>
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 /celquopt.s.o
+ ;;
Is there any standard 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 --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL:
From ametzler at bebt.de Sat Jun 21 07:10:46 2025
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 21 Jun 2025 07:10:46 +0200
Subject: gpgmepy 2.0.0 signed by unknown key
Message-ID:
Good morning,
The gpgmepy 2.0.0 release tarball is signed by
3556C3224D616EAB1221C2B2DF4475BB0CEDF389 but the key is not part of
https://gnupg.org/signature_key.asc (and I could not find it anywhere
else either).
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
From ametzler at bebt.de Sat Jun 21 08:56:15 2025
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 21 Jun 2025 08:56:15 +0200
Subject: gpgmepy 2.0.0 signed by unknown key
In-Reply-To:
References:
Message-ID:
On 2025-06-21 Andreas Metzler wrote:
> The gpgmepy 2.0.0 release tarball is signed by
> 3556C3224D616EAB1221C2B2DF4475BB0CEDF389 but the key is not part of
> https://gnupg.org/signature_key.asc (and I could not find it anywhere
> else either).
Hello,
it is pschwabauer(a)intevation.de's key which can be pulled with WKD.
Still shouldn't be it somewhere on ttps://gnupg.org/?
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
From wk at gnupg.org Sun Jun 22 15:12:02 2025
From: wk at gnupg.org (Werner Koch)
Date: Sun, 22 Jun 2025 15:12:02 +0200
Subject: gpgmepy 2.0.0 signed by unknown key
In-Reply-To: (Andreas Metzler's message of
"Sat, 21 Jun 2025 07:10:46 +0200")
References:
Message-ID: <87zfdzzzrx.fsf@jacob.g10code.de>
Hi!
On Sat, 21 Jun 2025 07:10, Andreas Metzler said:
> 3556C3224D616EAB1221C2B2DF4475BB0CEDF389 but the key is not part of
> https://gnupg.org/signature_key.asc (and I could not find it anywhere
That is right We don't maintain gpgmepy and thus we can't sign it. You
need to use Paul's key for verification. Sorry for the inconvenience
but that is a side-effect of the maintainer change. We have no direct
releationship to Paul except that he is working for a company I know
quite well for >20 years. If you need a a key signature form me on
Paul's key, I can arrange for that
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: 247 bytes
Desc: not available
URL:
From ametzler at bebt.de Mon Jun 23 09:01:28 2025
From: ametzler at bebt.de (Andreas Metzler)
Date: Mon, 23 Jun 2025 09:01:28 +0200
Subject: gpgmepy 2.0.0 signed by unknown key
In-Reply-To: <87zfdzzzrx.fsf@jacob.g10code.de>
References:
<87zfdzzzrx.fsf@jacob.g10code.de>
Message-ID:
On 2025-06-22 Werner Koch wrote:
> On Sat, 21 Jun 2025 07:10, Andreas Metzler said:
>> 3556C3224D616EAB1221C2B2DF4475BB0CEDF389 but the key is not part of
>> https://gnupg.org/signature_key.asc (and I could not find it anywhere
> That is right We don't maintain gpgmepy and thus we can't sign it. You
> need to use Paul's key for verification. Sorry for the inconvenience
> but that is a side-effect of the maintainer change. We have no direct
> releationship to Paul except that he is working for a company I know
> quite well for >20 years. If you need a a key signature form me on
> Paul's key, I can arrange for that
Hello Werner,
OK I see, I wrongly assumed gpgmepy was still a gnupg project.
The cross-signature would be nice to have but does not make a big
difference.
thanks, cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
From wk at gnupg.org Mon Jun 23 16:18:35 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 23 Jun 2025 16:18:35 +0200
Subject: gpgmepy 2.0.0 signed by unknown key
In-Reply-To: (Andreas Metzler's message of
"Mon, 23 Jun 2025 09:01:28 +0200")
References:
<87zfdzzzrx.fsf@jacob.g10code.de>
Message-ID: <87zfdyy210.fsf@jacob.g10code.de>
On Mon, 23 Jun 2025 09:01, Andreas Metzler said:
> The cross-signature would be nice to have but does not make a big
> difference.
Time for me to visit Osnabr?ck again ;-)
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: 247 bytes
Desc: not available
URL: