STOP
On February 6, 2026 12:27:20 PM MST, [email protected] wrote:
>Send Gnupg-users mailing list submissions to
> [email protected]
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnupg.org/mailman/listinfo/gnupg-users
>or, via email, send a message with subject or body 'help' to
> [email protected]
>
>You can reach the person managing the list at
> [email protected]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Gnupg-users digest..."
>
>
>Today's Topics:
>
> 1. Re: Bad signatures issued on macOS (John Soo)
> 2. Re: Bad signatures issued on macOS (Werner Koch)
> 3. [Announce] Libgcrypt 1.12.0 released (Werner Koch)
> 4. Extra socket forwarding - SUCKS (John Runyon)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 28 Jan 2026 10:38:37 -0700
>From: John Soo <[email protected]>
>To: John Soo via Gnupg-users <[email protected]>, John Soo
> <[email protected]>
>Subject: Re: Bad signatures issued on macOS
>Message-ID:
> <cajyryrrozae2zysmo6r-fmyw2kahurtwaw+f+vghktmku5i...@mail.gmail.com>
>Content-Type: text/plain; charset="UTF-8"
>
>Thanks Werner!
>
>I tried with -v --debug hashing and the content for hashing was not
>printed, is there another flag I need to use?
>
>For reference, this was a good sig:
>
>gpg: reading options from '[cmdline]'
>gpg: reading options from '/Users/<redacted>/.gnupg/common.conf'
>gpg: enabled debug flags: hashing
>gpg: enabled compatibility flags:
>gpg: using subkey B67EB1E57374A315 instead of primary key 6E628CC4145FD2ED
>gpg: writing to 'data.txt.asc'
>gpg: RSA/SHA256 signature from: "B67EB1E57374A315 <redacted>"
>gpg: secmem usage: 1344/32768 bytes in 2 blocks
>
>signature was
>-----BEGIN PGP SIGNATURE-----
>
>iQEzBAABCAAdFiEEG34w4o9D0vlGnPYqtn6x5XN0oxUFAml6SJwACgkQtn6x5XN0
>oxXMrgf9HQbhUZZUp+pPHSpT5Rw3GvnJLH5Sq5KUtmEYs0PArjwNN86OeHN+EENd
>f5F2PXHCTtNgY4OKibm5iJWO1qsCVKJeg/nhdqdx6xLuskAzBi5ogKJOfORSYKpY
>vLvRWbK55ag4iZqxeLJHrt6Chu9qsdlPyWMptzSQGlX2+9fVybmghdthFiUUOoBk
>FZDXuH1s30pUha7h4mNAn52A3P8pIpqX4f46vRTCYqjTtRuc1bXotQFvcmv8WmP+
>URcluMyQc4G5eSBGAeTODtgOBTLntvWMbFxLopO9o7HSIiKUNqgJxl6ZtUzbUxQu
>hziwl6C2gT+1/OUn16hz1m8cIEkAJA==
>=m0Gd
>-----END PGP SIGNATURE-----
>
>verification was
>gpg: reading options from '[cmdline]'
>gpg: reading options from '/Users/<redacted>/.gnupg/common.conf'
>gpg: enabled debug flags: hashing
>gpg: enabled compatibility flags:
>gpg: Signature made Wed Jan 28 11:34:20 2026 CST
>gpg: using RSA key 1B7E30E28F43D2F9469CF62AB67EB1E57374A315
>gpg: using subkey B67EB1E57374A315 instead of primary key 6E628CC4145FD2ED
>gpg: using pgp trust model
>gpg: Good signature from "<redacted>" [unknown]
>gpg: WARNING: This key is not certified with a trusted signature!
>gpg: There is no indication that the signature belongs to the owner.
>Primary key fingerprint: 1510 C864 04E2 F6EC A028 71DB 6E62 8CC4 145F D2ED
> Subkey fingerprint: 1B7E 30E2 8F43 D2F9 469C F62A B67E B1E5 7374 A315
>gpg: binary signature, digest algorithm SHA256, key algorithm rsa2048
>gpg: secmem usage: 0/32768 bytes in 0 blocks
>result: succeeded
>
>
>--- John
>
>On Wed, Jan 28, 2026 at 7:19?AM Werner Koch <[email protected]> wrote:
>>
>> Hi!
>>
>> On Tue, 27 Jan 2026 15:33, John Soo said:
>>
>> > Running the following script will often issue a bad signature after
>> > only a few rounds:
>>
>> You may run into problems when mixing stdout and stderr (&>FILE). Also
>> please do not use --debug-level guto or any other of those debug
>> levels; they are too noisy or don't print what you want.
>>
>> Always use -v or --verbose and then selected debug flags. In your case
>> I would suggest
>>
>> --debug hashing
>>
>> which writes files with what was actually hashed for signature creation
>> and verification. Compare them.
>>
>>
>>
>> Shalom-Salam,
>>
>> Werner
>>
>>
>> --
>> The pioneers of a warless world are the youth that
>> refuse military service. - A. Einstein
>
>
>
>------------------------------
>
>Message: 2
>Date: Thu, 29 Jan 2026 10:53:23 +0100
>From: Werner Koch <[email protected]>
>To: John Soo via Gnupg-users <[email protected]>
>Cc: John Soo <[email protected]>
>Subject: Re: Bad signatures issued on macOS
>Message-ID: <[email protected]>
>Content-Type: text/plain; charset="us-ascii"
>
>On Wed, 28 Jan 2026 10:38, John Soo said:
>> Thanks Werner!
>>
>> I tried with -v --debug hashing and the content for hashing was not
>> printed, is there another flag I need to use?
>
>Let's see using some arbitrary signature
>
> $ gpg --verify --debug hashing swdb.lst.sig swdb.lst
>
> gpg: reading options from '/home/wk/.gnupg/gpg.conf'
> gpg: reading options from '[cmdline]'
> gpg: reading options from '/home/wk/.gnupg/common.conf'
> gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
> gpg: It is only intended for test purposes and should NOT be
> gpg: used in a production environment or with production keys!
> gpg: enabled debug flags: hashing
> gpg: enabled compatibility flags:
> gpg: Signature made Fri 23 Feb 2024 02:34:37 PM CET
> gpg: using EDDSA key 6DAA6E64A76D2840571B4902528897B826403ADA
> gpg: using pgp trust model
> gpg: please do a --check-trustdb
> gpg: Good signature from "Werner Koch (dist signing 2020)" [ultimate]
> gpg: binary signature, digest algorithm SHA256, key algorithm ed25519
> gpg: secmem usage: 0/32768 bytes in 0 blocks
>
> $ ls -lt | head -3
> total 29839972
> -rw-r--r-- 1 wk wk 4725 Jan 29 10:44 dbgmd-00001.verify
> -rw-r--r-- 1 wk wk 41 Jan 29 10:44 dbgmd-00002.unknown
>
>dbgmd-00001.verify is the same as swdb.lst
>dbgmd-00002.unknown is the trailer hashed after swdb.lst.
>
>When creating the signature you should have seen
>dbgmd-00001.sign with the to be signed data
>dbgmd-00001.unknown with the trailer.
>
>dbgmd-00001.unknown gets overwritten so you need to store it away for
>later comparing.
>
>
>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-users/attachments/20260129/37cb8e79/attachment-0001.sig>
>
>------------------------------
>
>Message: 3
>Date: Thu, 29 Jan 2026 14:09:43 +0100
>From: Werner Koch <[email protected]>
>To: [email protected]
>Cc: [email protected]
>Subject: [Announce] Libgcrypt 1.12.0 released
>Message-ID: <[email protected]>
>Content-Type: text/plain; charset="utf-8"
>
>Hello!
>
>We are pleased to announce the availability of Libgcrypt version 1.12.0.
>
>This release starts a new stable branch of Libgcrypt with full API and
>ABI compatibility to the 1.11 series. Since the last major release
>Jussi Kivilinna put again a lot of work into speeding up the algorithms
>for modern CPUs. Niibe-san implemented new APIs and algorithms and
>adjusted the interface for new FIPS requirements. See below for a list
>of improvements and new features in 1.12.
>
>Libgcrypt is a general purpose library of cryptographic building blocks.
>It does not provide implementations of protocols like *PGP. Thorough
>understanding of applied cryptography is required for safe use of
>Libgcrypt.
>
>
>Noteworthy changes in version 1.12.0 (2026-01-29)
>-------------------------------------------------
>
> * New and extended interfaces:
>
> - Allow access to the FIPS service indicator via the new
> GCRYCTL_FIPS_SERVICE_INDICATOR control code.
> [T7338,rCd0db6a5abf,rCf51f4e9893]
>
> - Add GCRYCTL_FIPS_REJECT_NON_FIPS control code. [T7338,rCe52adf0948]
>
> - Add GCRY_FIPS_FLAG_REJECT_PK_FLAGS constant. [T7338,rC0414e126b9]
>
> - Make SHA-1 non-FIPS internally for the 1.12 API. This introduces
> the GCRY_FIPS_FLAG_REJECT_MD_SHA1 constant. [rC4ee91a94bc]
>
> - Add GCRY_FIPS_FLAG_REJECT_PK_FLAGS. [rC0414e126b9]
>
> - Provide macros for each KEM enum constant. [rCe9b1c3ec91]
>
> - Add Dilithium (ML-DSA) support. [T7640]
>
> - Support optional random-override and support byte string data.
> [rCcbefff5fca,rC3bb4a54f43]
>
> * Performance:
>
> - Add VAES/AVX512 accelerated implementation for AES which boosts
> OCB performance by about 2 times on AMD Zen5. [rC9e3af928ee]
>
> - Avoid AVX512/AVX2/SSSE3 for single block processing with Zen5 for
> ChaCha20. [rCc1d9fff3b2]
>
> - Avoid AVX/AVX2/AVX512 when CPU has high vector inst latency like
> Zen5 for Blake2. [rCe5bc3b2826]
>
> - Various optimizations for Camellia.
> [rCf5848080d4,rCb9bafd6c6c,rC8b538a8c76]
>
> - Add POLYVAL acceleration for RISC-V and GCM-SIV. [rC00815c4207]
>
> - Add RISC-V Zbb+Zbc implementation of CRC. [rCab4fa2a19c]
>
> - Add RISC-V vector cryptography implementation of GHASH.
> [rCcc2a4b6388]
>
> - Add RISC-V vector cryptography implementation of AES.
> [rCb000ab6025]
>
> - Add RISC-V vector cryptography implementations of SHA256 and
> SHA512. [rCcc1d5b0b5e]
>
> - Add AVX2 and AVX512 code paths to improve CRC. [rCc30788969d]
>
> * Bug fixes:
>
> - Use secure MPI in _gcry_mpi_assign_limb_space. [rC6e77b09cff]
>
> - Use CSIDL_COMMON_APPDATA instead of /etc on Windows. [rCd5e3cbfd88]
>
> - Apply a Kyber patch from upstream. [rCbdc3724d72]
>
> - Fix an edge case in Jent initialization. [rC0ceca9993f]
>
> - mceliece6688128f: Fix stack overflow crash on win64/wine
> [rC5bd9320171]
>
> * Other:
>
> - Add support for IBM z/OS, fixing -lpthread check with glibc.
> [rC5af59d8454]
>
> - Introduce mpi_tfr and use it for point_tfr to decrease EM signal
> and increase EM noise. [rC4e65996bb8]
>
> - Handle HAVE_BROKEN_MLOCK for the case of building with ASAN.
> [T7889]
>
> - Harden mask generation against branch optimization for several
> algorithms. [e.g. rC4012e9a037,rCbf7546c502,rC052b03fb0c]
>
> - Improve constant-time operation for ECDSA. [T7519,rC0bd4c77be6]
>
>
> Changes also found in 1.11.2:
>
> * Bug fixes:
>
> - Fix link errors in regression test t-thread-local on some
> platforms (e.g. NetBSD). [T7634]
>
> - Add missing file to allow building for RISC-V. [T7647]
>
> - Support secp256k1 by KEM API. GnuPG has recently switched to use
> the KEM interface and a few folks are using this curve. [T7698]
>
> - Fix a missing initialization in RSA's generate_fips.
> [rG292cb75a72]
>
> * Other:
>
> - Silence GCC 15 warnings [rCd5fb7cd9b3,T7617]
>
> - Provide a prototype for __udiv_qrnnd for PowerPC and Alpha which
> is required due to GCC-15 changes. [T7721]
>
> - Add missing abi versions and machine tags for PowerPC assembly
> with GCC-15. [T7721]
>
> - Use '.rodata' section for read-only data of poly1305-p10le.
> [T7721]
>
>
> Changes also found in 1.11.1:
>
> * Bug fixes:
>
> - Fix build regression on 32 bit Windows using Clang. [T7175]
>
> - Fix build regression on macOS due to symbol naming. [T7170]
>
> - Fix Kyber secret-dependent branch introduced by recent versions
> of Clang. [rCf765778e82]
>
> - Fix build regression due to the use of AVX512 in Blake. [T7184]
>
> - Do not build i386 asm on amd64 and vice versa. [T7220]
>
> - Fix build regression on armhf with gcc-14. [T7226]
>
> - Return the proper error code on malloc failure in hex2buffer.
> [rCc51151f5b0]
>
> - Fix long standing bug for PRIME % 2 == 0. [rC639b0fca15]
>
> * Performance:
>
> - Add AES Vector Permute intrinsics implementation for AArch64.
> [rC94a63aedbb]
>
> - Add GHASH AArch64/SIMD intrinsics implementation. [rCfec871fd18]
>
> - Add RISC-V vector permute AES. [rCb24ebd6163]
>
> - Add GHASH RISC-V Zbb+Zbc implementation. [rC0f1fec12b0]
>
> - Add ChaCha20 RISC-V vector intrinsics implementation.
> [rC8dbee93ac2]
>
> - Add SHA3 acceleration for RISC-V Zbb extension. [rC1a660068ba]
>
> * Other:
>
> - Add CET support for i386 and amd64 assembly. [T7220]
>
> - Add PAC/BTI support for AArch64 asm. [T7220]
>
> - Apply changes to Kyber from upstream for final FIPS 203.
> [rCcc95c36e7f]
>
> - Introduce an internal API for a revampled FIPS service indicator.
> [T7340]
>
> - Several improvements for constant time operation by the
> introduction of Least Leak Intended (LLI) variants of internal
> functions. [T7519,T7490]
>
> - Remove WindowsCE support. [T7486]
>
>
> * Interface changes relative to the 1.11.0 release:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> GCRY_KEM_RAW_P256R1 NEW enum and const.
> GCRYCTL_FIPS_SERVICE_INDICATOR NEW enum.
> GCRYCTL_FIPS_REJECT_NON_FIPS NEW enum.
> GCRY_FIPS_FLAG_REJECT_PK_FLAGS NEW const.
> GCRY_FIPS_FLAG_REJECT_MD_SHA1 NEW const.
>
>
> For a list of links to commits and bug numbers see the release info at
> https://dev.gnupg.org/T7643
>
>
>
>Download
>========
>
>Source code is hosted at the GnuPG FTP server and its mirrors as listed
>at https://gnupg.org/download/mirrors.html. On the primary server
>the source tarball and its digital signature are:
>
> https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.bz2
> https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.bz2.sig
>
>or gzip compressed:
>
> https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.gz
> https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.12.0.tar.gz.sig
>
>In order to check that the version of Libgcrypt you downloaded is an
>original and unmodified file please follow the instructions found at
>https://gnupg.org/download/integrity_check.html. In short, you may
>use one of the following methods:
>
> - Check the supplied OpenPGP signature. For example to check the
> signature of the file libgcrypt-1.12.0.tar.bz2 you would use this
> command:
>
> gpg --verify libgcrypt-1.12.0.tar.bz2.sig libgcrypt-1.12.0.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 libgcrypt-1.12.0.tar.bz2, you run the command like this:
>
> sha1sum libgcrypt-1.12.0.tar.bz2
>
> and check that the output matches the first line from the
> this list:
>
>02f80e9bc9967609b7041ef874eae4e542f240a5 libgcrypt-1.12.0.tar.bz2
>1327dd6ca3ec2309ac750ef1c01cbd96432f11a8 libgcrypt-1.12.0.tar.gz
>
> You should also verify that the checksums above are authentic by
> matching them with copies of this announcement. Those copies can be
> found at other mailing lists, web sites, and search engines.
>
>
>Copying
>=======
>
>Libgcrypt is distributed under the terms of the GNU Lesser General
>Public License (LGPLv2.1+). The helper programs as well as the
>documentation are distributed under the terms of the GNU General Public
>License (GPLv2+). The file LICENSES has notices about contributions
>that require that these additional notices are distributed.
>
>
>Support
>=======
>
>For help on developing with Libgcrypt you should read the included
>manual and if needed ask on the gcrypt-devel mailing list.
>
>In case of problems specific to this release please first check
>https://dev.gnupg.org/T7643 for updated information.
>
>Please also consult the archive of the gcrypt-devel 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 .
>
>Please see https://gnupg.org/documentation/security.html for information
>on how to report security issues and for our threat model.
>
>If you are a developer and you need a certain feature for your project,
>please do not hesitate to bring it to the gcrypt-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. Several full-time employed
>developers and contractors are working exclusively on GnuPG and closely
>related software like Libgcrypt, GPGME, Kleopatra and Gpg4win.
>
>Fortunately, and this is still not common with free software, we have
>now 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 helping with donations.
>
>*Thank you all*
>
> Your Libgcrypt hackers
>
>
>
>p.s.
>This is an announcement only mailing list. Please send replies only to
>the gcrypt-devel'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 <[email protected]>
>
> See the package website (https://repos.gnupg.org/deb/gnupg) for a list
> of supported distributions and a download link for the key.
>
>--
>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-users/attachments/20260129/cb1db4ee/attachment-0001.sig>
>-------------- next part --------------
>_______________________________________________
>Gnupg-announce mailing list
>[email protected]
>http://lists.gnupg.org/mailman/listinfo/gnupg-announce
>
>------------------------------
>
>Message: 4
>Date: Fri, 6 Feb 2026 11:17:52 -0700
>From: John Runyon <[email protected]>
>To: [email protected]
>Subject: Extra socket forwarding - SUCKS
>Message-ID:
> <CAN4EqKX-MNLW=zhJpyVU=0h6cwkpjgvebbjdxpuutcd4q9r...@mail.gmail.com>
>Content-Type: text/plain; charset="utf-8"
>
>Ok, can we talk about how much of a pain it is to forward the extra socket
>as a result of putting it in /run?
>
>Like... "Note: On Systems where systemd controls the directories under
>/var/run/user/<uid> it may be that the socket forwarding fails because
>/var/run/user/<uid>/gnupg is deleted on logout. To workaround this you can
>put gpgconf --create-socketdir in the startup script of your shell e.g.
>~/.bashrc or ~/.zshrc." (https://wiki.gnupg.org/AgentForwarding)
>Ok, this is just plain WRONG:
>- Nothing relevant to systemd here. Nor is /var/ relevant. I don't even use
>systemd. But, /run is *meant* to be cleared of files regularly, systemd or
>not. (In fact, mine is a tmpfs.)
>- The shell startup files are not run until AFTER the forwarding is
>attempted (and FAILS). So you have to connect twice for this to actually
>work.
>
>As far as I can tell, an actual solution is creating
>user-tmpfiles.d/gnupg.conf with:
>d /run/user/%U 0700
>d /run/user/%U/gnupg 0700
>
>Along with a separate script:
>su -c 'systemd-tmpfiles --user --create --remove' $PAM_USER
>
>AND a PAM config to run that script (early enough that it happens before
>SSH tries to create the socket):
>-session optional pam_exec.so quiet_log
>/usr/local/sbin/run-systemd-tmpfiles
>
>(Of course, this still has the problem that it's reliant on a UID that
>often changes between systems rather than a username which is, for most
>people, identical across systems, but oh well)
>
>Great fun! Good luck!
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
><https://lists.gnupg.org/pipermail/gnupg-users/attachments/20260206/1d033d9f/attachment.html>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>Gnupg-users mailing list
>[email protected]
>https://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
>------------------------------
>
>End of Gnupg-users Digest, Vol 269, Issue 1
>*******************************************
--
"I'm old but I'm not obsolete,"
Arnold Schwarzenegger
Terminator Genisys
_______________________________________________
Gnupg-users mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-users
