From kloecker at kde.org Mon Jan 4 16:37:14 2021
From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=)
Date: Mon, 04 Jan 2021 16:37:14 +0100
Subject: Missing const in Signature::operator<
In-Reply-To: <5677373.lOV4Wx5bFT@collossus.localdomain>
References: <2843969.slGk94SIus@beastie.bionicmutton.org>
<5677373.lOV4Wx5bFT@collossus.localdomain>
Message-ID: <1725374.8MKJivv2P8@breq>
On Mittwoch, 30. Dezember 2020 19:50:15 CET Ingo Kl?cker wrote:
> On Mittwoch, 30. Dezember 2020 14:56:45 CET Adriaan de Groot wrote:
> > In 6a6d2a27648, Signature got an operator<, so that Signatures can be
> > sorted. This is used in libkleo, for instance, to sort the signatures for
> > display.
> >
> > + bool operator<(const Signature &other);
> >
> > That should be const, though?
>
> Yeah, should've been const.
>
> > I have bunged in a const in the obvious spot, a patch is at https://
> > invent.kde.org/-/snippets/1437 . I have test-built libkleo against a
> > gpgmepp patched this way on FreeBSD, and this compile failure is then
> > repaired.
>
> Unfortunately, making a member function const is not BC. I'll add a const
> overload instead.
Done in master (a6220adf3081c9c848f6d0a6fc3774cb168ccf9c).
Regards,
Ingo
From wk at gnupg.org Mon Jan 11 20:44:57 2021
From: wk at gnupg.org (Werner Koch)
Date: Mon, 11 Jan 2021 20:44:57 +0100
Subject: [Announce] GnuPG 2.2.27 released
Message-ID: <874kjnjm12.fsf@wheatstone.g10code.de>
Hello!
We are pleased to announce the availability of a new GnuPG release:
version 2.2.27. This is a maintenance release fixing two recently
introduced bugs.
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.2.27 (2021-01-11)
-------------------------------------------------
* gpg: Fix regression in 2.2.24 for gnupg_remove function under
Windows. [#5230]
* gpgconf: Fix case with neither local nor global gpg.conf. [9f37d3e6f3]
* gpgconf: Fix description of two new options. [#5221]
* Build Windows installer without timestamps. Note that the
Authenticode signatures still carry a timestamp.
Release-info: https://dev.gnupg.org/T5234
Getting the Software
====================
Please follow the instructions found at or
read on:
GnuPG 2.2.27 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP 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.2.27.tar.bz2 (7023k)
https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.27.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.2.27_20210111.exe (4252k)
https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.27_20210111.exe.sig
The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.
New versions of the GnuPG VS-Desktop(tm) and Gpg4win featuring this
version of GnuPG will be released shortly.
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.2.27.tar.bz2 you would use this command:
gpg --verify gnupg-2.2.27.tar.bz2.sig gnupg-2.2.27.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.2.27.tar.bz2, you run the command like this:
sha1sum gnupg-2.2.27.tar.bz2
and check that the output matches the next line:
d928d4bd0808ffb8fe20d1161501401d5d389458 gnupg-2.2.27.tar.bz2
53aaa951be77b9f59fe0981291962be3e5a21314 gnupg-w32-2.2.27_20210111.tar.xz
9f2ff2ce36b6537f895ab3306527f105ff95df8d gnupg-w32-2.2.27_20210111.exe
Internationalization
====================
This version of GnuPG has support for 26 languages with Chinese
(traditional and simplified), Czech, French, German, Italian,
Japanese, Norwegian, Polish, Russian, and Ukrainian being almost
completely translated.
Documentation and Support
=========================
If you used GnuPG in the past you should read the description of
changes and new features at doc/whats-new-in-2.1.txt or online at
https://gnupg.org/faq/whats-new-in-2.1.html
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 thee 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/T5234 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 still mostly financed by donations. Three full-time employed
developers as well as two contractors exclusively work on GnuPG and
closely related software like Libgcrypt, GPGME and Gpg4win.
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, or answering questions on the mailing
lists.
Many thanks to our numerous financial supporters, both corporate and
individuals. Without you it would not be possible to keep GnuPG in a
good and secure shape and to address all the small and larger requests
made by our users. Thanks.
Happy hacking in 2021,
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.
p.p.s
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 [expires: 2030-06-30]
Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA
Werner Koch (dist signing 2020)
rsa2048 2014-10-29 [expires: 2020-10-30]
Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06
NIIBE Yutaka (GnuPG Release Key)
rsa3072 2017-03-17 [expires: 2027-03-15]
Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28
Andre Heinecke (Release Signing Key)
rsa2048 2011-01-12 [expires: 2021-12-31]
Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6
Werner Koch (dist sig)
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.
--
"If privacy is outlawed, only outlaws will have privacy."
- PRZ 1991
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 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 Tue Jan 19 17:13:18 2021
From: wk at gnupg.org (Werner Koch)
Date: Tue, 19 Jan 2021 17:13:18 +0100
Subject: [Announce] Libgcrypt 1.9.0 relased
Message-ID: <87k0s8dhwh.fsf@wheatstone.g10code.de>
Hello!
We are pleased to announce the availability of Libgcrypt version 1.9.0.
This release starts a new stable branch of Libgcrypt with full API and
ABI compatibility to the 1.8 series. Over the last 3 or 4 years Jussi
Kivilinna put a lot of work into speeding up the algorithms for the most
commonly used CPUs. See below for a list of improvements and new
features in 1.9.
Libgcrypt is a general purpose library of cryptographic building blocks.
It is originally based on code used by GnuPG. It does not provide any
implementation of OpenPGP or other protocols. Thorough understanding of
applied cryptography is required to use Libgcrypt.
Noteworthy changes in Libgcrypt 1.9.0
-------------------------------------
* New and extended interfaces:
- New curves Ed448, X448, and SM2.
- New cipher mode EAX.
- New cipher algo SM4.
- New hash algo SM3.
- New hash algo variants SHA512/224 and SHA512/256.
- New MAC algos for Blake-2 algorithms, the new SHA512 variants,
SM3, SM4 and for a GOST variant.
- New convenience function gcry_mpi_get_ui.
- gcry_sexp_extract_param understands new format specifiers to
directly store to integers and strings.
- New function gcry_ecc_mul_point and curve constants for Curve448
and Curve25519. [#4293]
- New function gcry_ecc_get_algo_keylen.
- New control code GCRYCTL_AUTO_EXPAND_SECMEM to allow growing the
secure memory area. Also in 1.8.2 as an undocumented feature.
* Performance:
- Optimized implementations for Aarch64.
- Faster implementations for Poly1305 and ChaCha. Also for
PowerPC. [b9a471ccf5,172ad09cbe,#4460]
- Optimized implementations of AES and SHA-256 on PowerPC.
[#4529,#4530]
- Improved use of AES-NI to speed up AES-XTS (6 times faster).
[a00c5b2988]
- Improved use of AES-NI for OCB. [eacbd59b13,e924ce456d]
- Speedup AES-XTS on ARMv8/CE (2.5 times faster). [93503c127a]
- New AVX and AVX2 implementations for Blake-2 (1.3/1.4 times
faster). [af7fc732f9, da58a62ac1]
- Use Intel SHA extension for SHA-1 and SHA-256 (4.0/3.7 times
faster). [d02958bd30, 0b3ec359e2]
- Use ARMv7/NEON accelerated GCM implementation (3 times faster).
[2445cf7431]
- Use of i386/SSSE3 for SHA-512 (4.5 times faster on Ryzen 7).
[b52dde8609]
- Use 64 bit ARMv8/CE PMULL for CRC (7 times faster). [14c8a593ed]
- Improve CAST5 (40% to 70% faster). [4ec566b368]
- Improve Blowfish (60% to 80% faster). [ced7508c85]
* Bug fixes:
- Fix infinite loop due to applications using fork the wrong
way. [#3491][also in 1.8.4]
- Fix possible leak of a few bits of secret primes to pageable
memory. [#3848][also in 1.8.4]
- Fix possible hang in the RNG (1.8.3 only). [#4034][also in 1.8.4]
- Several minor fixes. [#4102,#4208,#4209,#4210,#4211,#4212]
[also in 1.8.4]
- On Linux always make use of getrandom if possible and then use
its /dev/urandom behaviour. [#3894][also in 1.8.4]
- Use blinding for ECDSA signing to mitigate a novel side-channel
attack. [#4011,CVE-2018-0495] [also in 1.8.3, 1.7.10]
- Fix incorrect counter overflow handling for GCM when using an IV
size other than 96 bit. [#3764] [also in 1.8.3, 1.7.10]
- Fix incorrect output of AES-keywrap mode for in-place encryption
on some platforms. [also in 1.8.3, 1.7.10]
- Fix the gcry_mpi_ec_curve_point point validation function.
[also in 1.8.3, 1.7.10]
- Fix rare assertion failure in gcry_prime_check. [also in 1.8.3]
- Do not use /dev/srandom on OpenBSD. [also in 1.8.2]
- Fix test suite failure on systems with large pages. [#3351]
[also in 1.8.2]
- Fix test suite to not use mmap on Windows. [also in 1.8.2]
- Fix fatal out of secure memory status in the s-expression parser
on heavy loaded systems. [also in 1.8.2]
- Fix build problems on OpenIndiana et al. [#4818, also in 1.8.6]
- Fix GCM bug on arm64 which troubles for example OMEMO. [#4986,
also in 1.8.6]
- Detect a div-by-zero in a debug helper tool. [#4868, also in 1.8.6]
- Use a constant time mpi_inv and related changes. [#4869, partly
also in 1.8.6]
- Fix mpi_copy to correctly handle flags of opaque MPIs.
[also in 1.8.6]
- Fix mpi_cmp to consider +0 and -0 the same. [also in 1.8.6]
- Fix extra entropy collection via clock_gettime. Note that this
fallback code path is not used on any decent hardware. [#4966,
also in 1.8.7]
- Support opaque MPI with gcry_mpi_print. [#4872, also in 1.8.7]
- Allow for a Unicode random seed file on Windows. [#5098, also in
1.8.7]
* Other features:
- Add OIDs from RFC-8410 as aliases for Ed25519 and Curve25519.
[also in 1.8.6]
- Add mitigation against ECC timing attack CVE-2019-13626. [#4626]
- Internal cleanup of the ECC implementation.
- Support reading EC point in compressed format for some curves.
[#4951]
For a list of interface changes and links to commits and bug numbers
see the release info at https://dev.gnupg.org/T4294
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.9.0.tar.bz2
https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.0.tar.bz2.sig
or gzip compressed:
https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.0.tar.gz
https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.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.9.0.tar.bz2 you would use this
command:
gpg --verify libgcrypt-1.9.0.tar.bz2.sig libgcrypt-1.9.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.9.0.tar.bz2, you run the command like this:
sha1sum libgcrypt-1.9.0.tar.bz2
and check that the output matches the first line from the
this list:
459383a8b6200673cfc31f7b265c4961c0850031 libgcrypt-1.9.0.tar.bz2
25b36d1e3c32ef76be5098da721dd68933798a3d libgcrypt-1.9.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/T4294 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 .
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 still mostly financed by donations. Three full-time employed
developers as well as two contractors exclusively work on GnuPG and
closely related software like Libgcrypt, GPGME, and Gpg4win.
We like to thank all the nice people who are helping Libgcrypt, be it
testing, coding, suggesting, auditing, administering the servers,
spreading the word, or answering questions on the mailing lists.
Many thanks to our numerous financial supporters, both corporate and
individuals. Without you it would not be possible to keep GnuPG and
Libgcrypt in a good and secure shape and to address all the small and
larger requests made by our users. Thanks.
Happy hacking,
Your Libgcrypt hackers
p.s.
This is an announcement only mailing list. Please send replies only to
the gnupg-devel'at'gnupg.org mailing list.
p.p.s
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 [expires: 2030-06-30]
Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA
Werner Koch (dist signing 2020)
rsa2048 2014-10-29 [expires: 2020-10-30]
Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06
NIIBE Yutaka (GnuPG Release Key)
rsa3072 2017-03-17 [expires: 2027-03-15]
Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28
Andre Heinecke (Release Signing Key)
rsa2048 2011-01-12 [expires: 2021-12-31]
Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6
Werner Koch (dist sig)
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.
--
"If privacy is outlawed, only outlaws will have privacy."
- PRZ 1991
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 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 dgouttegattat at incenp.org Tue Jan 19 20:32:52 2021
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Tue, 19 Jan 2021 19:32:52 +0000
Subject: Last call for patches for pinentry-1.1.1
Message-ID: <20210119193252.snkqnmiq7u5xlkjo@dynein.local.incenp.org>
Hi GnuPG contributors,
A new release of pinentry (pinentry-1.1.1) is coming soon. If anyone has
a patch in waiting that they believe should be part of that release,
please raise your voice, either on that list or on dev.gnupg.org [1].
Barring any last-minute issues, the release should happen before the end
of this week.
Regards,
- Damien
[1] https://dev.gnupg.org/T4659
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
From fedora.dm0 at gmail.com Thu Jan 21 20:58:18 2021
From: fedora.dm0 at gmail.com (David Michael)
Date: Thu, 21 Jan 2021 14:58:18 -0500
Subject: [PATCH libgcrypt 1/2] cipher/sha512: Fix non-NEON ARM assembly
implementation
Message-ID: <87h7nagizp.fsf@gmail.com>
* cipher/sha512.c (do_transform_generic)
[USE_ARM_ASM]: Switch to the non-NEON assembly implementation.
--
When building for ARM CPUs that don't support NEON, linking fails
with an "undefined reference to _gcry_sha512_transform_armv7_neon"
error. Switching to the non-NEON assembly function corrects this.
---
(Resending this in case it wasn't delivered due to not being subscribed.)
cipher/sha512.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cipher/sha512.c b/cipher/sha512.c
index f70cdf42..0f4c304f 100644
--- a/cipher/sha512.c
+++ b/cipher/sha512.c
@@ -291,7 +291,7 @@ static unsigned int
do_transform_generic (void *context, const unsigned char *data, size_t nblks)
{
SHA512_CONTEXT *hd = context;
- return _gcry_sha512_transform_armv7_neon (&hd->state, data, k, nblks);
+ return _gcry_sha512_transform_arm (&hd->state, data, k, nblks);
}
#else
static unsigned int
--
2.26.2
From fedora.dm0 at gmail.com Thu Jan 21 20:58:26 2021
From: fedora.dm0 at gmail.com (David Michael)
Date: Thu, 21 Jan 2021 14:58:26 -0500
Subject: [PATCH libgcypt 2/2] cipher/poly1305: Fix 32-bit x86 compilation
Message-ID: <87ft2ugizh.fsf@gmail.com>
* cipher/poly1305.c [HAVE_COMPATIBLE_GCC_ARM_PLATFORM_AS]: Also
conditionalize on whether __arm__ is defined.
--
When building for i686, configure detects that the assembler can
use the different architectures, so it defined everything under the
HAVE_COMPATIBLE_GCC_ARM_PLATFORM_AS conditional block. Since that
block is first and the following x86 block only defines UMUL_ADD_32
if it's not already defined, the lto-wrapper failed during linking
with a pile of "no such instruction: umlal ..." errors. Gating on
__arm__ prevents that initial defintion and fixes the errors.
---
cipher/poly1305.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cipher/poly1305.c b/cipher/poly1305.c
index 6cb4d2b7..d9706ced 100644
--- a/cipher/poly1305.c
+++ b/cipher/poly1305.c
@@ -289,7 +289,7 @@ static unsigned int poly1305_final (poly1305_context_t *ctx,
#ifdef USE_MPI_32BIT
-#ifdef HAVE_COMPATIBLE_GCC_ARM_PLATFORM_AS
+#if defined (__arm__) && defined (HAVE_COMPATIBLE_GCC_ARM_PLATFORM_AS)
/* HI:LO += A * B (arm) */
#define UMUL_ADD_32(HI, LO, A, B) \
@@ -308,7 +308,7 @@ static unsigned int poly1305_final (poly1305_context_t *ctx,
: "r" (B0), "r" (B1), "r" (B2), "r" (B3), "r" (B4) \
: "cc" )
-#endif /* HAVE_COMPATIBLE_GCC_ARM_PLATFORM_AS */
+#endif /* __arm__ */
#if defined (__i386__) && __GNUC__ >= 4
--
2.26.2
From fedora.dm0 at gmail.com Thu Jan 21 20:05:54 2021
From: fedora.dm0 at gmail.com (David Michael)
Date: Thu, 21 Jan 2021 14:05:54 -0500
Subject: [PATCH] cipher/sha512: Fix non-NEON ARM assembly implementation
Message-ID: <87o8hidsa5.fsf@gmail.com>
* cipher/sha512.c (do_transform_generic)
[USE_ARM_ASM]: Switch to the non-NEON assembly implementation.
--
When building for ARM CPUs that don't support NEON, linking fails
with an "undefined reference to _gcry_sha512_transform_armv7_neon"
error. Switching to the non-NEON assembly function corrects this.
---
cipher/sha512.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cipher/sha512.c b/cipher/sha512.c
index f70cdf42..0f4c304f 100644
--- a/cipher/sha512.c
+++ b/cipher/sha512.c
@@ -291,7 +291,7 @@ static unsigned int
do_transform_generic (void *context, const unsigned char *data, size_t nblks)
{
SHA512_CONTEXT *hd = context;
- return _gcry_sha512_transform_armv7_neon (&hd->state, data, k, nblks);
+ return _gcry_sha512_transform_arm (&hd->state, data, k, nblks);
}
#else
static unsigned int
--
2.26.2
From wk at gnupg.org Fri Jan 22 12:18:32 2021
From: wk at gnupg.org (Werner Koch)
Date: Fri, 22 Jan 2021 12:18:32 +0100
Subject: [PATCH] cipher/sha512: Fix non-NEON ARM assembly implementation
In-Reply-To: <87o8hidsa5.fsf@gmail.com> (David Michael via Gnupg-devel's
message of "Thu, 21 Jan 2021 14:05:54 -0500")
References: <87o8hidsa5.fsf@gmail.com>
Message-ID: <87o8hh5iev.fsf@wheatstone.g10code.de>
Hi!
Thanks David for the reports. I accidentally mentioned this mailing
list in the annoucnement, but it really this should go to gcrypt-devel.
Libgcrypt hackers are not necessary reading this list.
I'll repost your mails to gcrypt-devel.
We have a couple of fixes already in the repo, see also
https://dev/gnupg.org/T5251 for the NEON thing. I am not sure whether
the Poly1305 bug has already been reported.
Shalom-Salam,
Werner
--
* Free Assange and protect free journalism!
* Germany: Sign the Treaty on the Prohibition of Nuclear Weapons!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL:
From taviso at gmail.com Wed Jan 27 06:05:15 2021
From: taviso at gmail.com (Tavis Ormandy)
Date: Wed, 27 Jan 2021 05:05:15 -0000 (UTC)
Subject: BUG() in symmetric decryption mode
Message-ID:
Hello, I happened to notice this hit's a BUG() in 2.2.27, it's no big
deal just a bad algorithm not handled gracefully:
$ printf "\x8c\x49\x05\x0e\x0a\x03\x01" | gpg --decrypt --pinentry-mode loopback --passphrase secret
gpg: encrypted with unknown algorithm 14
gpg: Ohhhh jeeee: ... this is a bug (passphrase.c:433:passphrase_to_dek)
Aborted
(It works.. uh, fails gracefully, in 2.2.19)
Thanks, Tavis.
--
_o) $ lynx lock.cmpxchg8b.com
/\\ _o) _o) $ finger taviso at sdf.org
_\_V _( ) _( ) @taviso
From dgouttegattat at incenp.org Wed Jan 27 12:22:23 2021
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Wed, 27 Jan 2021 11:22:23 +0000
Subject: [Announce] Pinentry 1.1.1 released
Message-ID: <20210127112223.sc2hba2xjnznwc5w@dynein.local.incenp.org>
Hi,
The GnuPG project is pleased to announce the availability of the latest
release of the collection of PIN or passphrase entry dialogs for GnuPG,
Pinentry 1.1.1.
Noteworthy changes in version 1.1.1 (2021-01-21)
===================================
* A Pinentry for the Enlightenment environment is available.
* In the GTK, QT, TQt, and curses pinentries, echoing can be disabled by
pressing the backspace key prior to any other input.
* The TTY pinentry now supports line editing.
* The GTK pinentry now requires GTK+ 2.12.0 or a later version.
Download
========
Source code is hosted at the GnuPG FTP server and its mirrors as listed
on . On the primary server the
source tarball and its signature are:
ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-1.1.1.tar.bz2
ftp://ftp.gnupg.org/gcrypt/pinentry/pinentry-1.1.1.tar.bz2.sig
The same files are also available via HTTP:
https://gnupg.org/ftp/gcrypt/pinentry/pinentry-1.1.1.tar.bz2
https://gnupg.org/ftp/gcrypt/pinentry/pinentry-1.1.1.tar.bz2.sig
Signing keys
============
The tarball is signed by the following keys:
pub rsa4096 2014-03-14 [SC]
Key fingerprint = 4FA2 0823 62FE 73AD 03B8 8830 A8DC 7067 E25F BABB
uid Damien Goutte-Gattat
pub ed25519 3030-08-24 [SC] [expires: 2030-06-30]
Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA
uid Werner Koch (dist signing key 2020)
The first of those keys is available via a WKD lookup:
$ gpg --locate-key dgouttegattat at incenp.org
The second is available in https://gnupg.org/signature_key.html and in
any recently released GnuPG tarball in the file g10/distsigkey.gpg.
Copying
=======
Pinentry is copyright by g10 Code GmbH and licensed under the GNU
General Public License version 2 or later (GPL-2.0+). The full text of
the license is included in the COPYING file of the source distribution.
Support
=======
The Pinentry manual is included in the source distribution in TeXinfo
format. For community support, you may ask on the gnupg-users mailing
list .
If you need commercial support, check out
.
Maintenance and development of Pinentry and of GnuPG as a whole is
mostly financed by donations. Please consider donating via
.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 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 Thu Jan 28 09:24:01 2021
From: wk at gnupg.org (Werner Koch)
Date: Thu, 28 Jan 2021 09:24:01 +0100
Subject: Sending envvars via ssh agent protocol
Message-ID: <87lfcdxye6.fsf@wheatstone.g10code.de>
Hi!
[ I sent this mail to the OpenSSH list openssh-unix-dev at mindrot.org
but given that this is GnuPG related it should go here as well. ]
There are quite some folks out there who use GnuPG's implementation of
the ssh-agent which we implemented about 15 years ago. It nicely fits
into the OpenPGP framework and we even have support for several
smartcards and tokens. In fact the standard OpenPGP card is be default
created with an authentication key to be used with ssh.
So far, so good. There is one annoying thing which we can only properly
solve by adding code to ssh. The problem is that if you switch between
different X-servers or ttys, gpg-agent does not know where to popup the
passphrase or PIN entry dialog. For example I am either working on
laptop directly or using an X server to work on that laptop. So when
switching between these devices I am meanwhile very accustomed to run
the command "gpg-connect-agent updatestartuptty /bye" to tell gpg-agent
the default tty or display it shall use by default. With gpg etc the
default is not used because gpg tells gpg-agent via its own IPC a number
of envvar values.
It would be very cool to get rid of this and so I hacked gpg-agent and
openssh to convet the required envvars via the ssh agent protocols
(according to draft-miller-ssh-agent-04 which is expired, but who
cares).
The new extension mechanism from this protocol is used; the details
should be easyl available from the attached patch. However, I can
describe them in another post.
The visisble change in ssh is a new option:
AgentEnv
Specifies what variables from the local environ(7) should be sent to
a running ssh-agent(1). The agent may use these environment
variables at its own discretion. Note that patterns for the
variable names are not supported. To empty the list of previously
set AgentEnv variable names the special name "-" may be used. To
ignore all further set names use the special name "#". To ask the
agent for a list of names to send use "auto" as the first and only
item.
The default is not to send any environment variables to the agent.
The rationale for the "-" thingy is to allow a config file to override
what for example the command line has already set. The "#" can be used
to disable a globally set option from the commandline or ~/.ssh/config.
On a GnuPG system you would usually have
AgentEnv auto
in ssh_config. "auto" reads the envvars known by GnuPG and sends their
values back. This is easier than to list them as arguments to AgentEnv.
GnuPG from Git is required but if things go smoothly we may even
backport this to the stable GnuPG 2.2 version.
I have not implemented that feature yet for ssh-add and ssh-keygen
because both don't parse ssh_config and thus this needs more thinking.
Anyway for everydays use it is enough to have this in ssh.
Please let me know whether this patch (against yesterday's Git) might be
acceptable to be included into the portable or upstream OpenSSH version.
Comments on the code are also appreciated. I merely followed the
existing style. I noticed that there are some ways to improve it but
that might me more intrusive as this change.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-sending-envrionment-variables-to-the-agent.patch
Type: text/x-diff
Size: 14532 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL:
From angel at pgp.16bits.net Fri Jan 29 00:06:47 2021
From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=)
Date: Fri, 29 Jan 2021 00:06:47 +0100
Subject: Sending envvars via ssh agent protocol
In-Reply-To: <87lfcdxye6.fsf@wheatstone.g10code.de>
References: <87lfcdxye6.fsf@wheatstone.g10code.de>
Message-ID: <6000d1719ce693e515ef13a31dbee7532e8a357e.camel@16bits.net>
On 2021-01-28 at 09:24 +0100, Werner Koch via Gnupg-devel wrote:
> The rationale for the "-" thingy is to allow a config file to
> override what for example the command line has already set. The "#"
> can be used to disable a globally set option from the commandline or
> ~/.ssh/config.
This seems backwards. I would expect command line to have hidher
priority than ssh_config, not ~/.ssh/config to be able to disable an
explicit command line option.
However, this may be useful for ~/.ssh/configto override
/etc/ssh/ssh_config (or as a command line parameter -oAcceptEnv=-)
Also, I would suggest using none instead of -, as that's what other ssh
options use. (This might cause issues if you wanted to pass an
environment variable named "none", but the same problem already exists
for "auto")
On a quick review of the patch:
> @@ -313,11 +313,22 @@ static struct {
> { "proxyjump", oProxyJump },
> { "securitykeyprovider", oSecurityKeyProvider },
> { "knownhostscommand", oKnownHostsCommand },
> + { "agentenv", oAgentEnv },
There is an extra space identation here.
> + error("%s line %d: Invalid environment name.",
Maybe nitpicking, but on this error (appears twice) I would say
"Invalid name of environment variable". The environment would be the
whole block of variables and values, not just one variable.
> if (*arg == '-') {
> if (*arg == '#') {
You are comparing against the first character of the argument.
Per your description I would expect that you compared that the whole
was that, not just that it began with # or -
And particularly, I can easily see how one might want to prefix an
environment variable with a minus to *substract* it from the set of
accepted vars.
+ if (options->num_agent_env >= INT_MAX) {
It is a bit strange to compare >= INT_MAX, since num_agent_env is an
int, but after reviewing, you only need the == comparison, so probably
ok.
There are more indentation sheningans around this block.
> +++ b/readconf.h
> @@ -126,6 +126,10 @@ typedef struct {
> char **send_env;
> int num_setenv;
> char **setenv;
> + int no_more_agent_env;
> + int num_agent_env;
> + char **agent_env;
> +
Bad indentation. send_env, num_setenv and setenv are indented with a
tab, no_more_agent_env with 8 spaces, num_agent_env with 3 spaces and
agent_env with a tab.
The fixme comments of ssh-add.c and ssh-keygen.c also use 8 spaces
instead of a tab (but these should probably end up implemented).
> +++ b/sshconnect.c
> @@ -1718,6 +1718,12 @@ maybe_add_key_to_agent(const char *authfile,
> struct sshkey *private,
> }
> if (sshkey_is_sk(private))
> skprovider = options.sk_provider;
> + if ((r = ssh_send_agent_env (auth_sock, options.agent_env,
> + options.num_agent_env)) != 0) {
> + debug("agent does not support AgentEnv: (%d)", r);
> + close(auth_sock);
> + return;
> + }
Indentation with 8 spaces, not with tabs
> +++ b/sshconnect2.c
>
> +/* Helper for pubkey_prepare. */
> +static int
> +authentication_socket(int *fdp)
More indentation errors (there is a mixture in the function itself)
Best regards
From angel at pgp.16bits.net Fri Jan 29 00:23:39 2021
From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=)
Date: Fri, 29 Jan 2021 00:23:39 +0100
Subject: Sending envvars via ssh agent protocol
In-Reply-To: <6000d1719ce693e515ef13a31dbee7532e8a357e.camel@16bits.net>
References: <87lfcdxye6.fsf@wheatstone.g10code.de>
<6000d1719ce693e515ef13a31dbee7532e8a357e.camel@16bits.net>
Message-ID:
On 2021-01-29 at 00:06 +0100, ?ngel wrote:
> (lots of notes about indentation on previos patch)
>
I attach a revised version of the patch addressing the indentation
issues. It has only spacing changes from Werner's original patch.
Best regards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-sending-envrionment-variables-to-the-agent+spacing.patch
Type: text/x-patch
Size: 12950 bytes
Desc: not available
URL:
From wk at gnupg.org Fri Jan 29 09:01:44 2021
From: wk at gnupg.org (Werner Koch)
Date: Fri, 29 Jan 2021 09:01:44 +0100
Subject: [Announce] [urgent] Stop using Libgcrypt 1.9.0 !
Message-ID: <87v9bgw4rb.fsf@wheatstone.g10code.de>
Hi!
A severe bug was reported yesterday evening against Libgcrypt 1.9.0
which we released last week. A new version to fix this as weel as a
couple of build problems will be released today.
In the meantime please stop using 1.9.0.
It seems that Fedora 34 and Gentoo are already using 1.9.0 .
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 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 Jan 29 12:20:18 2021
From: wk at gnupg.org (Werner Koch)
Date: Fri, 29 Jan 2021 12:20:18 +0100
Subject: [Announce] [Security fix] Libgcrypt 1.9.1 relased
Message-ID: <87h7n0vvkd.fsf@wheatstone.g10code.de>
Hello!
We have to announce the availability of Libgcrypt version 1.9.1.
This version fixes a *critical security bug* in the recently released
version 1.9.0. If you are already using 1.9.0 please update immediately
to 1.9.1.
Libgcrypt is a general purpose library of cryptographic building blocks.
It is originally based on code used by GnuPG. It does not provide any
implementation of OpenPGP or other protocols. Thorough understanding of
applied cryptography is required to use Libgcrypt.
Impact and timeline
===================
Only one released version is affected:
- Libgcrypt 1.9.0 (released 2021-01-19)
All other versions are not affected.
On 2021-01-28 Tavis Ormandy contacted us to report a severe bug in 1.9.0
which he found while testing GnuPG:
There is a heap buffer overflow in libgcrypt due to an incorrect
assumption in the block buffer management code. Just decrypting some
data can overflow a heap buffer with attacker controlled data, no
verification or signature is validated before the vulnerability
occurs.
The bug was introduced during the the 1.9 development phase about two
years ago with commit e76617cbab018dd8f41fd6b4ec6740b5303f7e13 (Reduce
overhead on generic hash write function).
Exploiting this bug is simple and thus immediate action for 1.9.0 users
is required. A CVE-id has not yet been assigned. We track this bug at
https://dev.gnupg.org/T5275. The 1.9.0 tarballs on our FTP server have
been renamed so that scripts won't be able to get this version anymore.
Solution
========
If Libgcrypt versions 1.9.0 is in use please update immediately to
version 1.9.1.
If you are using the 1.8 LTS branch you are not affected. While you are
checking anyway please make sure that you have at least 1.8.5.
If you are using a development version build taken from our Git
repository you need to update as well. NB: The use of non-released
versions in a production environment is strongly discouraged.
There is yet no released GnuPG version hich requires Libgcrypt 1.9
Noteworthy changes in Libgcrypt 1.9.1
=====================================
* Bug fixes:
- *Fix exploitable bug* in hash functions introduced with 1.9.0.
[#5275]
- Return an error if a negative MPI is used with sexp scan
functions. [#4964]
- Check for operational FIPS in the random and KDF functions.
[#5243]
- Fix compile error on ARMv7 with NEON disabled. [#5251]
- Fix self-test in KDF module. [#5254]
- Improve assembler checks for better LTO support. [#5255]
- Fix assember problem on macOS running on M1. [#5157]
- Support older macOS without posix_spawn. [#5159]
- Fix 32-bit cross build on x86. [#5257]
- Fix non-NEON ARM assembly implementation for SHA512. [#5263]
- Fix build problems with the cipher_bulk_ops_t typedef. [#5264]
- Fix Ed25519 private key handling for preceding ZEROs. [#5267]
- Fix overflow in modular inverse implementation. [#5269]
- Fix register access for AVX/AVX2 implementations of Blake2.
[#5271].
* Performance:
- Add optimized cipher and hash functions for s390x/zSeries.
- Use hardware bit counting functionx when available.
* Internal changes:
- The macOS getentropy syscall is used when available. [#5268]
- Update DSA functions to match FIPS 186-3. [30ed9593f6]
- New self-tests for CMACs and KDFs. [385a89e35b,7a0da24925]
- Add bulk cipher functions for OFB and GCM modes.
[f12b6788f2,f4e63e92dc]
For a list of links to commits and bug numbers
see the release info at https://dev.gnupg.org/T5259
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.9.1.tar.bz2
https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.1.tar.bz2.sig
or gzip compressed:
https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.1.tar.gz
https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.9.1.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.9.1.tar.bz2 you would use this
command:
gpg --verify libgcrypt-1.9.1.tar.bz2.sig libgcrypt-1.9.1.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.9.1.tar.bz2, you run the command like this:
sha1sum libgcrypt-1.9.1.tar.bz2
and check that the output matches the first line from the
this list:
a15ce7355b028f28a33428eaa0147154861b29d4 libgcrypt-1.9.1.tar.bz2
f4440ce7893c3cf12f633ad4d3f91c77110a3a40 libgcrypt-1.9.1.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/T5259 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 .
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 still mostly financed by donations. Three full-time employed
developers as well as two contractors exclusively work on GnuPG and
closely related software like Libgcrypt, GPGME, and Gpg4win.
We like to thank all the nice people who are helping Libgcrypt, be it
testing, coding, suggesting, auditing, administering the servers,
spreading the word, or answering questions on the mailing lists.
Many thanks to our numerous financial supporters, both corporate and
individuals. Without you it would not be possible to keep GnuPG and
Libgcrypt in a good and secure shape and to address all the small and
larger requests made by our users. Thanks.
Thanks to Tavis Ormandy for finding an reporting the bug.
We are sorry for the trouble,
Your Libgcrypt hackers
p.s.
This is an announcement only mailing list. Please send replies only to
the gnupg-devel'at'gnupg.org mailing list.
p.p.s
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 [expires: 2030-06-30]
Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA
Werner Koch (dist signing 2020)
rsa2048 2014-10-29 [expires: 2020-10-30]
Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06
NIIBE Yutaka (GnuPG Release Key)
rsa3072 2017-03-17 [expires: 2027-03-15]
Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28
Andre Heinecke (Release Signing Key)
rsa2048 2011-01-12 [expires: 2021-12-31]
Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6
Werner Koch (dist sig)
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.
--
"If privacy is outlawed, only outlaws will have privacy."
- PRZ 1991
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL:
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce