From wk at gnupg.org Tue Dec 3 14:37:03 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Dec 2013 14:37:03 +0100 Subject: pinentry: How to get key id? In-Reply-To: (Lukas Haase's message of "Fri, 29 Nov 2013 21:18:57 -0800") References: Message-ID: <87k3fm839c.fsf@vigenere.g10code.de> On Sat, 30 Nov 2013 06:18, lukashaase at gmx.at said: > Is there a way to find the key id for which the password is queried, > e.g. within the pinentry_loop2 or better, the w32_cmd_handler function? No. The keyid is an OpenPGP specific datum and useless with other protocols. gpg-agent does not know about OpenPGP but only about the keys. Therefore it uses a protocol-neutral identification string for keys, dubbed ?keygrip?. The pinentry is for humans and humans are really good in pattern matching ;-). If you need to automate pinentry, you should first ask yourself, why you need to supply a passphrase. Most likely this is an unattended system and then a passphrase to protect the key does not make anything more secure - the passphrase is stored somewhere in the clear anyway. In case this is a server application you may use a loopback pinentry to present the user a custom web form instead of the pinentry. If that all does not help, you need to wait for GnuPG 2.1 which may work without a pinentry by providing an internal loopback and thus the gpgme passphrase callback can be used again. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lukashaase at gmx.at Wed Dec 4 06:45:09 2013 From: lukashaase at gmx.at (Lukas Haase) Date: Tue, 03 Dec 2013 21:45:09 -0800 Subject: pinentry: How to get key id? In-Reply-To: <87k3fm839c.fsf@vigenere.g10code.de> References: <87k3fm839c.fsf@vigenere.g10code.de> Message-ID: On 2013-12-03 5:37, Werner Koch wrote: > On Sat, 30 Nov 2013 06:18, lukashaase at gmx.at said: > >> Is there a way to find the key id for which the password is queried, >> e.g. within the pinentry_loop2 or better, the w32_cmd_handler function? > > No. The keyid is an OpenPGP specific datum and useless with other > protocols. gpg-agent does not know about OpenPGP but only about the > keys. Therefore it uses a protocol-neutral identification string for > keys, dubbed ?keygrip?. That's sad. Then I indeed need to do pattern matching :( The string that's displayed, is it directly an output from gpg executeable? > [...] > If you need to automate pinentry, you should first ask yourself, why you > need to supply a passphrase. Most likely this is an unattended system > and then a passphrase to protect the key does not make anything more > secure - the passphrase is stored somewhere in the clear anyway. I kindly ask to not start pro/contra discussions regarding that. Still, as an explanation: It's not an unattended system. I may want to store the keys password-encrypted but still decide for myself where the passphrase comes from. For example, I may have a central, trusted password database with many passwords securely stored and only "unlocked" when needed, on request. They could be supplied in a more convenient way than, e.g., typing them off or copying through the clipboard. > [...] > If that all does not help, you need to wait for GnuPG 2.1 which may work > without a pinentry by providing an internal loopback and thus the gpgme > passphrase callback can be used again. That sounds exactly what I am looking for, still, pattern matching seems to be the one way currently. Luke From lists-gnupgdev at lina.inka.de Thu Dec 5 00:43:24 2013 From: lists-gnupgdev at lina.inka.de (Bernd Eckenfels) Date: Thu, 05 Dec 2013 00:43:24 +0100 Subject: generating RSA key sizes > 4096 Message-ID: Hello, From Robert (rjh): > Further, there has been no clear message from the cryptographic > community that such a large key is in any way useful. NIST believes a > 2048-bit key will be secure for 30 years; ENISA recommends a 3072-bit > key. Allowing a 4096-bit key allows people to go far beyond all the > current recommendations; why should it go further? Actually that is not correct. The just recently released key params report* of ENISA proposes a protection equivalent of 256bit-symmetric-block ciphers for recommended future proof protections and they state that the RSA-equivalent of various sources (NIST**, IETF, ECTYPT2,...) is between 15360 and 46752 bit in this case. And this is explicitely for single use keys (and strong deprecation of PKCS#1 v1.5). The "legacy minumum" is 1024, the future system minimum is 3072 and for long term they recommend 15360 bits. (or ECDLP 512bit). Greetings Bernd * http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report ** http://www.keylength.com/en/4/ From mailinglisten at hauke-laging.de Thu Dec 5 02:29:30 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 05 Dec 2013 02:29:30 +0100 Subject: generating RSA key sizes > 4096 In-Reply-To: References: Message-ID: <1986915.GefAastaRT@inno.berlin.laging.de> Am Do 05.12.2013, 00:43:24 schrieb Bernd Eckenfels: > The "legacy minumum" is 1024, the future system minimum is 3072 and for > long term they recommend 15360 bits. (or ECDLP 512bit). This document is quite strange as it is inconsistent (from text to table). They say that it was a matter of taste whether to recommend 2048 or 3072 as a minimum. They do not say 2048 was too short. Hauke -- Crypto f?r alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From ido at kernel.org Thu Dec 5 04:59:53 2013 From: ido at kernel.org (Ido Rosen) Date: Wed, 4 Dec 2013 22:59:53 -0500 Subject: generating RSA key sizes > 4096 In-Reply-To: <1986915.GefAastaRT@inno.berlin.laging.de> References: <1986915.GefAastaRT@inno.berlin.laging.de> Message-ID: There is another compelling reason to add the larger key sizes as a compile-time option: The purpose of this patch is not to change the default maximum for everyone, but to remove the incentive for a large subset of GnuPG users to use third-party, untrusted patches/code to get a feature that is supposed to enhance security for their use case. The patch in bug #1573 provides a compile-time option to allow users to set the maximum key size supported to greater than the default maximum if they want to. This is about more than key sizes: If downstream users of GnuPG are regularly and routinely patching the GnuPG code with external, untrusted code to add a feature that is beneficial to a large subset of GnuPG users (since the majority of GnuPG users are probably not on mobile phones or 10+ year old computers), then for the purpose of preventing GnuPG users from having to monkeypatch their GnuPG with patches the implications of which they may not fully understand themselves, we should make that it a compile-time option. I don't even mind if you modify the patch to make it a *hidden* compile-time option. My only desire in submitting the patch is to return control of the actual GnuPG code that is running in the wild to the core GnuPG developers rather than untrusted third parties, by removing the need for a patch to obtain this feature. Cheers, Ido From wk at gnupg.org Thu Dec 5 08:26:35 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 05 Dec 2013 08:26:35 +0100 Subject: pinentry: How to get key id? In-Reply-To: (Lukas Haase's message of "Tue, 03 Dec 2013 21:45:09 -0800") References: <87k3fm839c.fsf@vigenere.g10code.de> Message-ID: <87zjof69n8.fsf@vigenere.g10code.de> On Wed, 4 Dec 2013 06:45, lukashaase at gmx.at said: > The string that's displayed, is it directly an output from gpg executeable? Yes. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Dec 5 08:39:47 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 05 Dec 2013 08:39:47 +0100 Subject: generating RSA key sizes > 4096 In-Reply-To: (Ido Rosen's message of "Wed, 4 Dec 2013 22:59:53 -0500") References: <1986915.GefAastaRT@inno.berlin.laging.de> Message-ID: <87vbz36918.fsf@vigenere.g10code.de> On Thu, 5 Dec 2013 04:59, ido at kernel.org said: > regularly and routinely patching the GnuPG code with external, > untrusted code to add a feature that is beneficial to a large subset > of GnuPG users (since the majority of GnuPG users are probably not on Please define beneficial. I can't see what you mean by that: It has been reported that Mac users do that because GPGtools has lifted the limit. Now, what kind of extra security do they get by using a ridiculous long key on an operating system which is not under their full control and which has a higher likeliness to be backdoored by the vendor than the chance to break even arbitrary 1024 bit RSA keys? If you want higher security than default you need to turn a lot of knobs: Audit all software and hardware, never connect the box to the Net, use a shielded room, install a good entropy source, and educate all users with access to the confidential information to employ proper OPSEC. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lists-gnupgdev at lina.inka.de Thu Dec 5 18:11:20 2013 From: lists-gnupgdev at lina.inka.de (Bernd Eckenfels) Date: Thu, 05 Dec 2013 18:11:20 +0100 Subject: generating RSA key sizes > 4096 In-Reply-To: <1986915.GefAastaRT@inno.berlin.laging.de> References: <1986915.GefAastaRT@inno.berlin.laging.de> Message-ID: Am 05.12.2013, 02:29 Uhr, schrieb Hauke Laging : > This document is quite strange Yes it is also not really defined what "long term" means. For example transactional data which contains a PII, does it need "long term" de-cryption protection. And it fails to differentiate between confidentiality and authentisity. But still the document and the recommendation is out there in the wild (my take away from it is however that they declare RSA dead end in favor of ECC, and I am not sure if that is a valid thing to do right now). Nevertheless, it is a contra argument to the discussion here claiming there is no recommendation in that direction. After all it is also based on NIST projections. Bernd -- http://bernd.eckenfels.net From hans at guardianproject.info Thu Dec 5 23:34:08 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 05 Dec 2013 17:34:08 -0500 Subject: changing SONAME for libs on Android In-Reply-To: <52A0E576.3000107@guardianproject.info> References: <87bo6uod0r.fsf@vigenere.g10code.de> <52A0E576.3000107@guardianproject.info> Message-ID: <52A0FF60.9020709@guardianproject.info> On 12/05/2013 03:43 PM, Hans-Christoph Steiner wrote: > > > On 06/26/2013 11:15 AM, Hans of Guardian wrote: >> >> On Jun 25, 2013, at 3:39 AM, Werner Koch wrote: >> >>> On Tue, 25 Jun 2013 01:04, hans at guardianproject.info said: >>> >>>> Right now, when building the GnuPG suite for Android, it creates >>>> shared library files that are named in the normal GNU/Linux style, >>>> i.e. libfoo.so.1.0.3, including the ABI version after .so. When >>>> building for Android, it currently inherits this behavior, perhaps >>>> because they share the Linux kernel. But unfortunately, this is not >>> >>> The reason is that libtool selects this versioning scheme. It is based >>> on the several factors but mainly on the cpu-vendor-os triplet. >>> >>>> So I'm curious whether this would take a lot of work to do, and what >>>> other repercussions such a change would have. As far as just changing >>> >>> Because we are using libtool, this may only be fixed in libtool. A >>> quick check of the current libtool (2.4.2) does not reveal any strings >>> "android" or "bionic" thus I assume there is no special code for android >>> there. Autoconf however knows about Android (see config.sub). >>> >>>> the SONAME in the build process, that should be pretty >>>> straightforward. >>> >>> I don't exactly understand the problem. Is it merely that ld.so does >>> not follow symlinks or is ld.so very different from the glibc ld.so ? >>> >>> For the former it should be easy to change the name after installation. >>> For the latter we also need to change libtool because it takes care of >>> installing the libraries. >> >> The linker in Android is very different, its very stripped down and basic. It only looks in LD_LIBRARY_PATH for paths, it has no hard-coded default lib path and it entirely ignores rpath in a binary. My guess is that it does follow symlinks. >> >> The Android APK installer handles installing the .so files, and they are installed in a way that only root has access to that folder. That means even the app itself cannot modify them or add symlinks. We have worked around this by entirely managing the installation of the .so files in the app, then setting LD_LIBRARY_PATH. But this is a approach that is fraught with difficulties and complexity. >> >>> A quick search found these notes on a gstreamer presentation slide: >>> >>> - android's dynamic linker has a hard-coded limit on the number of .so >>> files (shared libraries and/or plugins) you can load in a single >>> process. >>> >>> - Android's linker is limited to 64, 96 and 128 shared libraries >>> Including all plugins we have 262 shared libraries >> >> Currently, we are only using about 10 .so files for the app. I guess I'm not aware of all the plugins for GnuPG. >> >> >>> May be it it worth to look closer at this. I consider it important to >>> know the exact reason why there are problems with the SO files before we >>> start hacking on libtool. >>> >>> The next version of libtool has major changes and is not anymore a >>> complex shell script. I assume it will take more than a year before a >>> new libtool version is released. For that reason, small changes to the >>> included 2.42 version of libtool are justified (in fact I recently did >>> this for W64 and def file parsing). >> >> Sounds like modifying libtool is the way to do it, and also working to get this stuff incorporated upstream. >> >> .hc > > Luckily someone from Google already beat me to it, so his commit just needs to > be included: > > http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=8eeeb00daef8c4f720c9b79a0cdb89225d9909b6 > > This only changes m4/libtool.m4, which is currently included in this projects: > > gpgme/m4/libtool.m4 > libassuan/m4/libtool.m4 > libgcrypt/m4/libtool.m4 > libgpg-error/m4/libtool.m4 > libksba/m4/libtool.m4 > npth/m4/libtool.m4 > > It seems to me that gnupg will also need this patch, I'm not sure how that > works, since there is no gnupg/m4/libtool.m4 to patch. > > .hc Applying that commit as a patch worked for me on these projects: * gpgme * libgcrypt * libkbsa It did not work for this project: * libgpg-error It did not apply for these: * libassuan * npth Copying the patched m4/libtool.m4 from libgcrypt into the non-working projects didn't seem to fix any of them, so I guess the libtool stuff there needs a bigger update. It broke the build for libassuan, libgpg-error, and npth. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From hans at guardianproject.info Thu Dec 5 21:43:34 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 05 Dec 2013 15:43:34 -0500 Subject: changing SONAME for libs on Android In-Reply-To: References: <87bo6uod0r.fsf@vigenere.g10code.de> Message-ID: <52A0E576.3000107@guardianproject.info> On 06/26/2013 11:15 AM, Hans of Guardian wrote: > > On Jun 25, 2013, at 3:39 AM, Werner Koch wrote: > >> On Tue, 25 Jun 2013 01:04, hans at guardianproject.info said: >> >>> Right now, when building the GnuPG suite for Android, it creates >>> shared library files that are named in the normal GNU/Linux style, >>> i.e. libfoo.so.1.0.3, including the ABI version after .so. When >>> building for Android, it currently inherits this behavior, perhaps >>> because they share the Linux kernel. But unfortunately, this is not >> >> The reason is that libtool selects this versioning scheme. It is based >> on the several factors but mainly on the cpu-vendor-os triplet. >> >>> So I'm curious whether this would take a lot of work to do, and what >>> other repercussions such a change would have. As far as just changing >> >> Because we are using libtool, this may only be fixed in libtool. A >> quick check of the current libtool (2.4.2) does not reveal any strings >> "android" or "bionic" thus I assume there is no special code for android >> there. Autoconf however knows about Android (see config.sub). >> >>> the SONAME in the build process, that should be pretty >>> straightforward. >> >> I don't exactly understand the problem. Is it merely that ld.so does >> not follow symlinks or is ld.so very different from the glibc ld.so ? >> >> For the former it should be easy to change the name after installation. >> For the latter we also need to change libtool because it takes care of >> installing the libraries. > > The linker in Android is very different, its very stripped down and basic. It only looks in LD_LIBRARY_PATH for paths, it has no hard-coded default lib path and it entirely ignores rpath in a binary. My guess is that it does follow symlinks. > > The Android APK installer handles installing the .so files, and they are installed in a way that only root has access to that folder. That means even the app itself cannot modify them or add symlinks. We have worked around this by entirely managing the installation of the .so files in the app, then setting LD_LIBRARY_PATH. But this is a approach that is fraught with difficulties and complexity. > >> A quick search found these notes on a gstreamer presentation slide: >> >> - android's dynamic linker has a hard-coded limit on the number of .so >> files (shared libraries and/or plugins) you can load in a single >> process. >> >> - Android's linker is limited to 64, 96 and 128 shared libraries >> Including all plugins we have 262 shared libraries > > Currently, we are only using about 10 .so files for the app. I guess I'm not aware of all the plugins for GnuPG. > > >> May be it it worth to look closer at this. I consider it important to >> know the exact reason why there are problems with the SO files before we >> start hacking on libtool. >> >> The next version of libtool has major changes and is not anymore a >> complex shell script. I assume it will take more than a year before a >> new libtool version is released. For that reason, small changes to the >> included 2.42 version of libtool are justified (in fact I recently did >> this for W64 and def file parsing). > > Sounds like modifying libtool is the way to do it, and also working to get this stuff incorporated upstream. > > .hc Luckily someone from Google already beat me to it, so his commit just needs to be included: http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=8eeeb00daef8c4f720c9b79a0cdb89225d9909b6 This only changes m4/libtool.m4, which is currently included in this projects: gpgme/m4/libtool.m4 libassuan/m4/libtool.m4 libgcrypt/m4/libtool.m4 libgpg-error/m4/libtool.m4 libksba/m4/libtool.m4 npth/m4/libtool.m4 It seems to me that gnupg will also need this patch, I'm not sure how that works, since there is no gnupg/m4/libtool.m4 to patch. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From gniibe at fsij.org Mon Dec 9 03:47:42 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 09 Dec 2013 11:47:42 +0900 Subject: npth change required for Android Message-ID: <1386557262.3441.2.camel@cfw2.gniibe.org> For the issue 1576 (reported by Hans Christoph Steiner), I write a patch for Npth. OK to commit? [0] https://bugs.g10code.com/gnupg/issue1576 -------------- diff --git a/configure.ac b/configure.ac index bd650c7..2a0216f 100644 --- a/configure.ac +++ b/configure.ac @@ -256,6 +256,7 @@ if test "$have_w32_system" = no; then AC_CHECK_FUNCS([pthread_rwlock_rdlock pthread_rwlock_wrlock]) AC_CHECK_FUNCS([pthread_rwlock_timedrdlock pthread_rwlock_timedwrlock]) AC_CHECK_FUNCS([pthread_rwlock_tryrdlock pthread_rwlock_trywrlock]) + AC_CHECK_FUNCS([pthread_atfork]) fi fi diff --git a/src/npth-sigev.c b/src/npth-sigev.c index aab977e..78e92ff 100644 --- a/src/npth-sigev.c +++ b/src/npth-sigev.c @@ -126,12 +126,16 @@ npth_sigev_add (int signum) } +#ifdef HAVE_PTHREAD_ATFORK +/* There is non-POSIX operating system where fork is not available to + applications. There, we have no pthread_atfork either. In such a + case, we don't call pthread_atfork. */ static void restore_sigmask_for_child_process (void) { pthread_sigmask (SIG_SETMASK, &sigev_unblock, NULL); } - +#endif /* Finish the list of watched signals. This starts to block them, too. */ @@ -140,7 +144,9 @@ npth_sigev_fini (void) { /* Block the interesting signals. */ pthread_sigmask (SIG_SETMASK, &sigev_block, NULL); +#ifdef HAVE_PTHREAD_ATFORK pthread_atfork (NULL, NULL, restore_sigmask_for_child_process); +#endif } -- From hans at guardianproject.info Mon Dec 9 18:49:37 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 09 Dec 2013 12:49:37 -0500 Subject: npth change required for Android In-Reply-To: <1386557262.3441.2.camel@cfw2.gniibe.org> References: <1386557262.3441.2.camel@cfw2.gniibe.org> Message-ID: <52A602B1.9010908@guardianproject.info> Looks good to me. Luckily, Android didn't do the very aggravating fake version of this function that is has for others, so configure doesn't detect anything for pthread_atfork(): checking for pthread_tryjoin_np... no checking for pthread_setname_np... yes checking for pthread_getname_np... no checking for pthread_mutex_timedlock... no checking for pthread_rwlock_rdlock... yes checking for pthread_rwlock_wrlock... yes checking for pthread_rwlock_timedrdlock... yes checking for pthread_rwlock_timedwrlock... yes checking for pthread_rwlock_tryrdlock... yes checking for pthread_rwlock_trywrlock... yes checking for pthread_atfork... no (For other unimplemented libc functions, Android's bionic libc includes a stub function that just printfs a message, so ./configure correctly detects that function's presense, but its a non-functional function). .hc On 12/08/2013 09:47 PM, NIIBE Yutaka wrote: > For the issue 1576 (reported by Hans Christoph Steiner), I write > a patch for Npth. > > OK to commit? > > > [0] https://bugs.g10code.com/gnupg/issue1576 > > -------------- > diff --git a/configure.ac b/configure.ac > index bd650c7..2a0216f 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -256,6 +256,7 @@ if test "$have_w32_system" = no; then > AC_CHECK_FUNCS([pthread_rwlock_rdlock pthread_rwlock_wrlock]) > AC_CHECK_FUNCS([pthread_rwlock_timedrdlock pthread_rwlock_timedwrlock]) > AC_CHECK_FUNCS([pthread_rwlock_tryrdlock pthread_rwlock_trywrlock]) > + AC_CHECK_FUNCS([pthread_atfork]) > fi > fi > > diff --git a/src/npth-sigev.c b/src/npth-sigev.c > index aab977e..78e92ff 100644 > --- a/src/npth-sigev.c > +++ b/src/npth-sigev.c > @@ -126,12 +126,16 @@ npth_sigev_add (int signum) > } > > > +#ifdef HAVE_PTHREAD_ATFORK > +/* There is non-POSIX operating system where fork is not available to > + applications. There, we have no pthread_atfork either. In such a > + case, we don't call pthread_atfork. */ > static void > restore_sigmask_for_child_process (void) > { > pthread_sigmask (SIG_SETMASK, &sigev_unblock, NULL); > } > - > +#endif > > /* Finish the list of watched signals. This starts to block them, > too. */ > @@ -140,7 +144,9 @@ npth_sigev_fini (void) > { > /* Block the interesting signals. */ > pthread_sigmask (SIG_SETMASK, &sigev_block, NULL); > +#ifdef HAVE_PTHREAD_ATFORK > pthread_atfork (NULL, NULL, restore_sigmask_for_child_process); > +#endif > } > > -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Mon Dec 9 19:21:53 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Dec 2013 19:21:53 +0100 Subject: npth change required for Android In-Reply-To: <1386557262.3441.2.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Mon, 09 Dec 2013 11:47:42 +0900") References: <1386557262.3441.2.camel@cfw2.gniibe.org> Message-ID: <87y53tyjem.fsf@vigenere.g10code.de> On Mon, 9 Dec 2013 03:47, gniibe at fsij.org said: > For the issue 1576 (reported by Hans Christoph Steiner), I write > a patch for Npth. > > OK to commit? Sure. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Dec 9 20:07:48 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Dec 2013 20:07:48 +0100 Subject: changing SONAME for libs on Android In-Reply-To: <52A0E576.3000107@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 05 Dec 2013 15:43:34 -0500") References: <87bo6uod0r.fsf@vigenere.g10code.de> <52A0E576.3000107@guardianproject.info> Message-ID: <87txehyha3.fsf@vigenere.g10code.de> On Thu, 5 Dec 2013 21:43, hans at guardianproject.info said: > http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=8eeeb00daef8c4f720c9b79a0cdb89225d9909b6 Applied to libgcrypt and libgpg-error maste. > It seems to me that gnupg will also need this patch, I'm not sure how that GnuPG is not a library and thus does not use libtool. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Mon Dec 9 22:23:32 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 09 Dec 2013 16:23:32 -0500 Subject: changing SONAME for libs on Android In-Reply-To: <87txehyha3.fsf@vigenere.g10code.de> References: <87bo6uod0r.fsf@vigenere.g10code.de> <52A0E576.3000107@guardianproject.info> <87txehyha3.fsf@vigenere.g10code.de> Message-ID: <52A634D4.6050604@guardianproject.info> On 12/09/2013 02:07 PM, Werner Koch wrote: > On Thu, 5 Dec 2013 21:43, hans at guardianproject.info said: > >> http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=8eeeb00daef8c4f720c9b79a0cdb89225d9909b6 > > Applied to libgcrypt and libgpg-error maste. Thanks. Unfortunately, there is more to do here. I have it all working on my machine with the latest in master for gpgme, gnupg, libgpg-error and libgcrypt. * gpgme and libkbsa need this same patch, and then work * libassuan and npth need the patch, but then also need this to work: ./autogen.sh && autoreconf --install --force --verbose * libgpg-error needs the patch, the autoreconf, and then also forcing the change to libgpg-error/libtool via sed: sed 's,^fast_install=.*,fast_install=needless,' sed 's,^version_type=.*,version_type=none,' sed 's,^shlibpath_overrides_runpath=.*,shlibpath_overrides_runpath=yes,' sed 's,^library_names_spec=.*,library_names_spec="\\$$libname\\$$release\\$$shared_ext",' sed 's,^soname_spec=.*,soname_spec="\\$$libname\\$$release\\$$shared_ext",' sed 's,^finish_cmds=.*,finish_cmds="",' sed 's,^sys_lib_dlsearch_path_spec=.*,sys_lib_dlsearch_path_spec="/lib /usr/lib",' I don't know how best to handle those extra situations beyond including the patch, it seems that the autotools in those projects has been customized, so they can't be easily updated with 'autoreconf' Shall I file a bug report? .hc >> It seems to me that gnupg will also need this patch, I'm not sure how that > > GnuPG is not a library and thus does not use libtool. > > > Shalom-Salam, > > Werner > -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From gniibe at fsij.org Tue Dec 10 01:22:44 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 10 Dec 2013 09:22:44 +0900 Subject: npth change required for Android In-Reply-To: <52A602B1.9010908@guardianproject.info> References: <1386557262.3441.2.camel@cfw2.gniibe.org> <52A602B1.9010908@guardianproject.info> Message-ID: <1386634964.3167.2.camel@cfw2.gniibe.org> On 2013-12-09 at 12:49 -0500, Hans-Christoph Steiner wrote: > Looks good to me. Luckily, Android didn't do the very aggravating fake > version of this function that is has for others, so configure doesn't detect > anything for pthread_atfork(): [...] > checking for pthread_atfork... no Thank you for your testing. The patch has been pushed to master branch of Npth. Please note that signal mask reset is required (for POSIX) when pinentry is spawned from gpg-agent (it is libassuan for GnuPG 2.1.x, which does fork/exec). Being killed by signal is needed for pinentry in case of PIN input for smartcard with pinpad card reader. -- From hans at guardianproject.info Tue Dec 10 04:24:56 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 09 Dec 2013 22:24:56 -0500 Subject: npth change required for Android In-Reply-To: <1386634964.3167.2.camel@cfw2.gniibe.org> References: <1386557262.3441.2.camel@cfw2.gniibe.org> <52A602B1.9010908@guardianproject.info> <1386634964.3167.2.camel@cfw2.gniibe.org> Message-ID: <52A68988.3010205@guardianproject.info> On 12/09/2013 07:22 PM, NIIBE Yutaka wrote: > On 2013-12-09 at 12:49 -0500, Hans-Christoph Steiner wrote: >> Looks good to me. Luckily, Android didn't do the very aggravating fake >> version of this function that is has for others, so configure doesn't detect >> anything for pthread_atfork(): > [...] >> checking for pthread_atfork... no > > Thank you for your testing. The patch has been pushed to master > branch of Npth. > > Please note that signal mask reset is required (for POSIX) when > pinentry is spawned from gpg-agent (it is libassuan for GnuPG 2.1.x, > which does fork/exec). Being killed by signal is needed for pinentry > in case of PIN input for smartcard with pinpad card reader. We'd like to support using smart cards with Android, does that mean its not possible currently? .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From gniibe at fsij.org Tue Dec 10 04:53:28 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 10 Dec 2013 12:53:28 +0900 Subject: npth change required for Android In-Reply-To: <52A68988.3010205@guardianproject.info> References: <1386557262.3441.2.camel@cfw2.gniibe.org> <52A602B1.9010908@guardianproject.info> <1386634964.3167.2.camel@cfw2.gniibe.org> <52A68988.3010205@guardianproject.info> Message-ID: <1386647608.3167.8.camel@cfw2.gniibe.org> On 2013-12-09 at 22:24 -0500, Hans-Christoph Steiner wrote: > We'd like to support using smart cards with Android, does that mean its not > possible currently? Well, I explain the particular issue of pinentry. (In general, it's not only pinentry but also any program which will be spawned and receive signal.) When your card reader has pinpad, it won't work, perhaps. Pinentry will be spawned (by gpg-agent through libassuan) to prompt user to input PIN using pinpad. After PIN input with pinpad, pinentry will be killed by signal on POSIX system. It is possible that this part (of receiving signal) won't work on Android. It depends on how libassuan spawns pinentry on Android. If it doesn't inherit signal mask (of parent), it will work. -- From wk at gnupg.org Tue Dec 10 08:37:07 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Dec 2013 08:37:07 +0100 Subject: changing SONAME for libs on Android In-Reply-To: <52A634D4.6050604@guardianproject.info> (Hans-Christoph Steiner's message of "Mon, 09 Dec 2013 16:23:32 -0500") References: <87bo6uod0r.fsf@vigenere.g10code.de> <52A0E576.3000107@guardianproject.info> <87txehyha3.fsf@vigenere.g10code.de> <52A634D4.6050604@guardianproject.info> Message-ID: <87r49lupgc.fsf@vigenere.g10code.de> On Mon, 9 Dec 2013 22:23, hans at guardianproject.info said: > * gpgme and libkbsa need this same patch, and then work Sure. I usually do that right before a release. I can do that earlier if it helps you. > * libassuan and npth need the patch, but then also need this to work: > ./autogen.sh && autoreconf --install --force --verbose No autoreconf please. We use autogen.sh and the tested automake/conf versions. What is the reason that you think you need to do that. > * libgpg-error needs the patch, the autoreconf, and then also forcing > the change to libgpg-error/libtool via sed: > sed 's,^fast_install=.*,fast_install=needless,' > sed 's,^version_type=.*,version_type=none,' Please explain why this is required. libgpg-error is not different than the other tools. > Shall I file a bug report? It is easier for me to discuss this here. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Tue Dec 10 15:44:29 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 10 Dec 2013 09:44:29 -0500 Subject: changing SONAME for libs on Android In-Reply-To: <87r49lupgc.fsf@vigenere.g10code.de> References: <87bo6uod0r.fsf@vigenere.g10code.de> <52A0E576.3000107@guardianproject.info> <87txehyha3.fsf@vigenere.g10code.de> <52A634D4.6050604@guardianproject.info> <87r49lupgc.fsf@vigenere.g10code.de> Message-ID: <52A728CD.7090003@guardianproject.info> On 12/10/2013 02:37 AM, Werner Koch wrote: > On Mon, 9 Dec 2013 22:23, hans at guardianproject.info said: > >> * gpgme and libkbsa need this same patch, and then work > > Sure. I usually do that right before a release. I can do that earlier > if it helps you. No rush, I have it building in the GPGA tree. >> * libassuan and npth need the patch, but then also need this to work: >> ./autogen.sh && autoreconf --install --force --verbose > > No autoreconf please. We use autogen.sh and the tested automake/conf > versions. What is the reason that you think you need to do that. The patch alone didn't work, it was still generating libnpth.so.0.2.0 or whatever the number is. It should be libnpth.so. After running autoreconf, it made libnpth.so and libassuan.so. >> * libgpg-error needs the patch, the autoreconf, and then also forcing >> the change to libgpg-error/libtool via sed: >> sed 's,^fast_install=.*,fast_install=needless,' >> sed 's,^version_type=.*,version_type=none,' > > Please explain why this is required. libgpg-error is not different than > the other tools. Same as above. After running autoreconf and ./configure, it still hadn't updated libgpg-error/libtool. But in this case, forcing it with sed patterns worked where that didn't work with libnpth and libassuan. .hc >> Shall I file a bug report? > > It is easier for me to discuss this here. > > > Shalom-Salam, > > Werner > -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Tue Dec 10 19:14:50 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Dec 2013 19:14:50 +0100 Subject: changing SONAME for libs on Android In-Reply-To: <52A728CD.7090003@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 10 Dec 2013 09:44:29 -0500") References: <87bo6uod0r.fsf@vigenere.g10code.de> <52A0E576.3000107@guardianproject.info> <87txehyha3.fsf@vigenere.g10code.de> <52A634D4.6050604@guardianproject.info> <87r49lupgc.fsf@vigenere.g10code.de> <52A728CD.7090003@guardianproject.info> Message-ID: <87vbywtvxh.fsf@vigenere.g10code.de> On Tue, 10 Dec 2013 15:44, hans at guardianproject.info said: > The patch alone didn't work, it was still generating libnpth.so.0.2.0 or > whatever the number is. It should be libnpth.so. After running autoreconf, > it made libnpth.so and libassuan.so. Did you run "make distclean" and "./autogen.sh --force" after patching? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Tue Dec 10 19:57:45 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 10 Dec 2013 13:57:45 -0500 Subject: changing SONAME for libs on Android In-Reply-To: <87vbywtvxh.fsf@vigenere.g10code.de> References: <87bo6uod0r.fsf@vigenere.g10code.de> <52A0E576.3000107@guardianproject.info> <87txehyha3.fsf@vigenere.g10code.de> <52A634D4.6050604@guardianproject.info> <87r49lupgc.fsf@vigenere.g10code.de> <52A728CD.7090003@guardianproject.info> <87vbywtvxh.fsf@vigenere.g10code.de> Message-ID: <52A76429.6010903@guardianproject.info> On 12/10/2013 01:14 PM, Werner Koch wrote: > On Tue, 10 Dec 2013 15:44, hans at guardianproject.info said: > >> The patch alone didn't work, it was still generating libnpth.so.0.2.0 or >> whatever the number is. It should be libnpth.so. After running autoreconf, >> it made libnpth.so and libassuan.so. > > Did you run "make distclean" and "./autogen.sh --force" after patching? The m4/libtool.m4 is too old for that patch to apply. So running autoreconf puts a newer version in place which can be patched. I've tried with distclean and 'git clean -fdx; git reset --hard'. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Tue Dec 10 21:32:28 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Dec 2013 21:32:28 +0100 Subject: changing SONAME for libs on Android In-Reply-To: <52A76429.6010903@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 10 Dec 2013 13:57:45 -0500") References: <87bo6uod0r.fsf@vigenere.g10code.de> <52A0E576.3000107@guardianproject.info> <87txehyha3.fsf@vigenere.g10code.de> <52A634D4.6050604@guardianproject.info> <87r49lupgc.fsf@vigenere.g10code.de> <52A728CD.7090003@guardianproject.info> <87vbywtvxh.fsf@vigenere.g10code.de> <52A76429.6010903@guardianproject.info> Message-ID: <87d2l4tpk3.fsf@vigenere.g10code.de> On Tue, 10 Dec 2013 19:57, hans at guardianproject.info said: > The m4/libtool.m4 is too old for that patch to apply. So running autoreconf > puts a newer version in place which can be patched. Okay, so just copy a libtool from libgcrypt etc. That is what I will eventually do anyway. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lists at sk2.org Thu Dec 12 23:21:37 2013 From: lists at sk2.org (Stephen Kitt) Date: Thu, 12 Dec 2013 23:21:37 +0100 Subject: Patch to build mipcalc on Windows with MinGW-w64 Message-ID: <20131212232137.1545a85a@heffalump.sk2.org> Hi, All MinGW targets require underscores when linking. This patch fixes acinclude.m4 and the resulting configure so they don't limit the use of underscores to the old mingw32msvc targets; otherwise the build fails if libgomp is available and an attempt is made to build mpicalc.exe. Regards, Stephen Signed-off-by: Stephen Kitt --- a/acinclude.m4 +++ b/acinclude.m4 @@ -692,7 +692,7 @@ AC_DEFUN([GNUPG_SYS_SYMBOL_UNDERSCORE], [tmp_do_check="no" case "${host}" in - *-mingw32msvc*) + *-mingw32*) ac_cv_sys_symbol_underscore=yes ;; i386-emx-os2 | i[3456]86-pc-os2*emx | i386-pc-msdosdjgpp) --- a/configure +++ b/configure @@ -7314,7 +7314,7 @@ tmp_do_check="no" case "${host}" in - *-mingw32msvc*) + *-mingw32*) ac_cv_sys_symbol_underscore=yes ;; i386-emx-os2 | i345686-pc-os2*emx | i386-pc-msdosdjgpp) From wk at gnupg.org Fri Dec 13 10:28:46 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 13 Dec 2013 10:28:46 +0100 Subject: GnuPG 1.4.16 release preparation Message-ID: <87wqj9p0a9.fsf@vigenere.g10code.de> Hi, please do not push any more changes to the 1.4 branch of GnuPG. I am currently preparing 1.4.16 and plan to release it next week. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Fri Dec 13 20:18:53 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 13 Dec 2013 14:18:53 -0500 Subject: automatic builds on jenkins Message-ID: <52AB5D9D.4080500@guardianproject.info> Hey all, We have our own Jenkins build server that we use for all of our projects. That also includes Gnu Privacy Guard for Android. I would be happy to set up a couple GnuPG of jobs that build the entire GnuPG suite from the head of master in git for Debian and Android. It would then email the committers when the build breaks. Its also possible to run test suites and static analysis tools like cppcheck. It will check hourly for new commits, but I'm happy to give remote access to trigger builds and get info about them. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Sun Dec 15 12:52:38 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 15 Dec 2013 12:52:38 +0100 Subject: Patch to build mipcalc on Windows with MinGW-w64 In-Reply-To: <20131212232137.1545a85a@heffalump.sk2.org> (Stephen Kitt's message of "Thu, 12 Dec 2013 23:21:37 +0100") References: <20131212232137.1545a85a@heffalump.sk2.org> Message-ID: <87eh5ejpq1.fsf@vigenere.g10code.de> On Thu, 12 Dec 2013 23:21, lists at sk2.org said: > underscores to the old mingw32msvc targets; otherwise the build fails if > libgomp is available and an attempt is made to build mpicalc.exe. mpicalc is part of libgcrypt. The one included with GnuPG 1.4 is too old and is only intended for debugging. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sun Dec 15 12:56:20 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 15 Dec 2013 12:56:20 +0100 Subject: automatic builds on jenkins In-Reply-To: <52AB5D9D.4080500@guardianproject.info> (Hans-Christoph Steiner's message of "Fri, 13 Dec 2013 14:18:53 -0500") References: <52AB5D9D.4080500@guardianproject.info> Message-ID: <87a9g2jpjv.fsf@vigenere.g10code.de> On Fri, 13 Dec 2013 20:18, hans at guardianproject.info said: > That also includes Gnu Privacy Guard for Android. I would be happy to set up > a couple GnuPG of jobs that build the entire GnuPG suite from the head of > master in git for Debian and Android. It would then email the committers when No need to to that for Debian. I am using Debian myself. ;-) There is also a NixOS build server running. For Android this should be quite useful. > It will check hourly for new commits, but I'm happy to give remote access to > trigger builds and get info about them. Daily or 12 hour intervals should be enough. There is no guarantee that a git commit builds on all platforms everytime. A remote trigger would actually be really nice. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Dec 16 18:49:01 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Dec 2013 18:49:01 +0100 Subject: [Announce] Libgcrypt 1.6.0 released Message-ID: <87haa8fzzm.fsf@vigenere.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.6.0. This is the new stable version of Libgcrypt with the API being mostly compatible to previous versions. Due to the removal of certain long deprecated functions this version introduces an ABI change. 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. The main features of this version are performance improvements [3], better support for elliptic curves, new algorithms and modes, as well as API and internal cleanups. Better performance of public key algorithms, in particular for Curve25519, is planned for forthcoming releases. Note that the 1.5 series will enter end of life state on 2016-12-31. Noteworthy changes between version 1.5.0 and 1.6.0: =================================================== * Removed the long deprecated gcry_ac interface. Thus Libgcrypt is not anymore ABI compatible to previous versions if they used the ac interface. * Removed the module register subsystem. * The deprecated message digest debug macros have been removed. Use gcry_md_debug instead. * Removed deprecated control codes. * Improved performance of most cipher algorithms as well as for the SHA family of hash functions. * Added support for the IDEA cipher algorithm. * Added support for the Salsa20 and reduced Salsa20/12 stream ciphers. * Added limited support for the GOST 28147-89 cipher algorithm. * Added support for the GOST R 34.11-94 and R 34.11-2012 (Stribog) hash algorithms. * Added a random number generator to directly use the system's RNG. Also added an interface to prefer the use of a specified RNG. * Added support for the SCRYPT algorithm. * Mitigated the Yarom/Falkner flush+reload side-channel attack on RSA secret keys. See [CVE-2013-4242]. * Added support for Deterministic DSA as per RFC-6969. * Added support for curve Ed25519. * Added a scatter gather hash convenience function. * Added several MPI amd SEXP helper functions. * Added support for negative numbers to gcry_mpi_print, gcry_mpi_aprint and gcry_mpi_scan. * The algorithm ids GCRY_PK_ECDSA and GCRY_PK_ECDH are now deprecated. Use GCRY_PK_ECC if you need an algorithm id. * Changed gcry_pk_genkey for "ecc" to only include the curve name and not the parameters. The flag "param" may be used to revert this. * Added a feature to globally disable selected hardware features. * Added debug helper functions. For Interface changes relative to the 1.5.0 release see below [4]. Download ======== Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source file and its digital signatures is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.0.tar.bz2 (2441k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.0.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.0.tar.gz (2866k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.0.tar.gz.sig Due to the amount of changes we don't provide a patch file against 1.5.x. The SHA-1 checksums are: 43283c0b41c41e3d3bc13c2d8f937dfe2aaa1a77 libgcrypt-1.6.0.tar.bz2 03551121fe5b706532158667699f63b6e2606755 libgcrypt-1.6.0.tar.gz 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 these additional notices are distributed. Support ======= For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. A listing with commercial support offers for Libgcrypt and related software is available at the GnuPG web site [2]. The driving force behind the development of Libgcrypt is my company g10 Code. Maintenance and improvement of Libgcrypt and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Thanks ====== Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Special thanks to Jussi Kivilinna who did most of the performance improvement work. Happy hacking, Werner [1] http://www.gnupg.org/documentation/mailing-lists.html [2] http://www.gnupg.org/service.html [3] http://blog.gnupg.org/20131215-gcrypt-bench.html [4] Interface changes relative to the 1.5.0 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gcry_ac_* REMOVED. GCRY_AC_* REMOVED. gcry_module_t REMOVED. gcry_cipher_register REMOVED. gcry_cipher_unregister REMOVED. gcry_cipher_list REMOVED. gcry_pk_register REMOVED. gcry_pk_unregister REMOVED. gcry_pk_list REMOVED. gcry_md_register REMOVED. gcry_md_unregister REMOVED. gcry_md_list REMOVED. gcry_md_start_debug REMOVED (macro). gcry_md_stop_debug REMOVED (macro). GCRYCTL_SET_KEY REMOVED. GCRYCTL_SET_IV REMOVED. GCRYCTL_SET_CTR REMOVED. GCRYCTL_DISABLE_ALGO CHANGED: Not anymore thread-safe. gcry_pk_genkey CHANGED: ECC curve params not returned. gcry_md_hash_buffers NEW. gcry_buffer_t NEW. GCRYCTL_SET_ENFORCED_FIPS_FLAG NEW. GCRYCTL_SET_PREFERRED_RNG_TYPE NEW. GCRYCTL_GET_CURRENT_RNG_TYPE NEW. GCRYCTL_CLOSE_RANDOM_DEVICE NEW. GCRY_RNG_TYPE_STANDARD NEW. GCRY_RNG_TYPE_FIPS NEW. GCRY_RNG_TYPE_SYSTEM NEW. gcry_mpi_is_neg NEW. gcry_mpi_neg NEW. gcry_mpi_abs NEW. gcry_mpi_snatch NEW. gcry_mpi_set_opaque_copy NEW. gcry_mpi_point_t NEW. gcry_mpi_point_new NEW. gcry_mpi_point_release NEW. gcry_mpi_point_get NEW. gcry_mpi_point_snatch_get NEW. gcry_mpi_point_set NEW. gcry_mpi_point_snatch_set NEW. gcry_ctx_t NEW. gcry_ctx_release NEW. gcry_mpi_ec_new NEW. gcry_mpi_ec_get_mpi NEW. gcry_mpi_ec_get_point NEW. gcry_mpi_ec_set_mpi NEW. gcry_mpi_ec_set_point NEW. gcry_mpi_ec_get_affine NEW. gcry_mpi_ec_dup NEW. gcry_mpi_ec_add NEW. gcry_mpi_ec_mul NEW. gcry_mpi_ec_curve_point NEW. GCRYMPI_FLAG_IMMUTABLE NEW. GCRYMPI_FLAG_CONST NEW. GCRYMPI_FLAG_USER1 NEW. GCRYMPI_FLAG_USER2 NEW. GCRYMPI_FLAG_USER3 NEW. GCRYMPI_FLAG_USER4 NEW. GCRYMPI_CONST_ONE NEW. GCRYMPI_CONST_TWO NEW. GCRYMPI_CONST_THREE NEW. GCRYMPI_CONST_FOUR NEW. GCRYMPI_CONST_EIGHT NEW. GCRYMPI_FMT_OPAQUE NEW. GCRYPT_VERSION_NUMBER NEW. GCRY_KDF_SCRYPT NEW. gcry_pubkey_get_sexp NEW. GCRYCTL_DISABLE_LOCKED_SECMEM NEW. GCRYCTL_DISABLE_PRIV_DROP NEW. GCRY_CIPHER_SALSA20 NEW. gcry_sexp_nth_buffer NEW. gcry_sexp_extract_param NEW. GCRY_CIPHER_SALSA20R12 NEW. GCRY_CIPHER_GOST28147 NEW. GCRY_MD_GOSTR3411_94 NEW. GCRY_MD_STRIBOG256 NEW. GCRY_MD_STRIBOG512 NEW. GCRY_PK_ECC NEW. gcry_log_debug NEW. gcry_log_debughex NEW. gcry_log_debugmpi NEW. gcry_log_debugpnt NEW. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 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 hans at guardianproject.info Mon Dec 16 21:04:41 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 16 Dec 2013 15:04:41 -0500 Subject: automatic builds on jenkins In-Reply-To: <87a9g2jpjv.fsf@vigenere.g10code.de> References: <52AB5D9D.4080500@guardianproject.info> <87a9g2jpjv.fsf@vigenere.g10code.de> Message-ID: <52AF5CD9.5010503@guardianproject.info> On 12/15/2013 06:56 AM, Werner Koch wrote: > On Fri, 13 Dec 2013 20:18, hans at guardianproject.info said: > >> That also includes Gnu Privacy Guard for Android. I would be happy to set up >> a couple GnuPG of jobs that build the entire GnuPG suite from the head of >> master in git for Debian and Android. It would then email the committers when > > No need to to that for Debian. I am using Debian myself. ;-) There is > also a NixOS build server running. For Android this should be quite > useful. > >> It will check hourly for new commits, but I'm happy to give remote access to >> trigger builds and get info about them. > > Daily or 12 hour intervals should be enough. There is no guarantee > that a git commit builds on all platforms everytime. A remote trigger > would actually be really nice. I've set up the job to check the git repos once a day, and if there are new commits, then build the whole suite for Android. When the build breaks, all of the committers since the last successful build will be emailed with the error. Anyone can ask me directly for instructions on how to manually trigger the builds. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From eternaleye at gmail.com Tue Dec 17 06:46:25 2013 From: eternaleye at gmail.com (Alex Elsayed) Date: Mon, 16 Dec 2013 21:46:25 -0800 Subject: [Announce] Libgcrypt 1.6.0 released References: <87haa8fzzm.fsf__9326.01447352699$1387217416$gmane$org@vigenere.g10code.de> Message-ID: Werner Koch wrote: > Hello! > > Noteworthy changes between version 1.5.0 and 1.6.0: > =================================================== > * Added support for Deterministic DSA as per RFC-6969. A minor correction: RFC-6979 is Deterministic DSA, RFC-6969 is "OSPFv3 Instance ID Registry Update" From hans at guardianproject.info Tue Dec 17 15:52:32 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 17 Dec 2013 09:52:32 -0500 Subject: building gnupg with keyserver support but without ldap Message-ID: <52B06530.8040802@guardianproject.info> Right now, openldap is proving to be a pain to build on Android, and quite large to boot. Is it possible to build gnupg with keyserver support but without openldap? I've been trying with the addition of libcurl, but the build dies saying it requires openldap even though I did ./configure --disable-ldap .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Wed Dec 18 15:05:38 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Dec 2013 15:05:38 +0100 Subject: [Announce] [security fix] GnuPG 1.4.16 released Message-ID: <87wqj26yq5.fsf@vigenere.g10code.de> Hello! Along with the publication of an interesting new side channel attack by Daniel Genkin, Adi Shamir, and Eran Tromer we announce the availability of a new stable GnuPG release to relieve this bug: Version 1.4.16. This is a *security fix* release and all users of GnuPG versions 1.x are advised to updated to this version. GnuPG versions 2.x are not affected. See below for the impact of the problem. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility, smartcard support and is compliant with the OpenPGP Internet standard as described by RFC-4880. Note that this version is from the GnuPG-1 series and thus smaller than those from the GnuPG-2 series, easier to build, and also better portable to ancient platforms. In contrast to GnuPG-2 (e.g version 2.0.22) it comes with no support for S/MIME, Secure Shell, or other tools useful for desktop environments. Fortunately you may install both versions alongside on the same system without any conflict. What's New =========== * Fixed the RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis attack as described by Genkin, Shamir, and Tromer. See . [CVE-2013-4576] * Put only the major version number by default into armored output. * Do not create a trustdb file if --trust-model=always is used. * Print the keyid for key packets with --list-packets. * Changed modular exponentiation algorithm to recover from a small performance loss due to a change in 1.4.14. Impact of the security problem ============================== CVE-2013-4576 has been assigned to this security bug. The paper describes two attacks. The first attack allows to distinguish keys: An attacker is able to notice which key is currently used for decryption. This is in general not a problem but may be used to reveal the information that a message, encrypted to a commonly not used key, has been received by the targeted machine. We do not have a software solution to mitigate this attack. The second attack is more serious. It is an adaptive chosen ciphertext attack to reveal the private key. A possible scenario is that the attacker places a sensor (for example a standard smartphone) in the vicinity of the targeted machine. That machine is assumed to do unattended RSA decryption of received mails, for example by using a mail client which speeds up browsing by opportunistically decrypting mails expected to be read soon. While listening to the acoustic emanations of the targeted machine, the smartphone will send new encrypted messages to that machine and re-construct the private key bit by bit. A 4096 bit RSA key used on a laptop can be revealed within an hour. GnuPG 1.4.16 avoids this attack by employing RSA blinding during decryption. GnuPG 2.x and current Gpg4win versions make use of Libgcrypt which employs RSA blinding anyway and are thus not vulnerable. For the highly interesting research on acoustic cryptanalysis and the details of the attack see http://www.cs.tau.ac.il/~tromer/acoustic/ . Getting the Software ==================== First of all, decide whether you really need GnuPG version 1.4.x - most users are better off with the modern GnuPG 2.0.x version. Then follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 1.4.16 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the following files in the *gnupg* directory: gnupg-1.4.16.tar.bz2 (3571k) gnupg-1.4.16.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.4.16.tar.gz (4955k) gnupg-1.4.16.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.4.15-1.4.15.diff.bz2 (26k) A patch file to upgrade a 1.4.15 GnuPG source tree. This patch does not include updates of the language files. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. In the *binary* directory, you should find these files: gnupg-w32cli-1.4.16.exe (1573k) gnupg-w32cli-1.4.16.exe.sig GnuPG compiled for Microsoft Windows and its OpenPGP signature. This is a command line only version; the source files are the same as given above. Note, that this is a minimal installer and unless you are just in need for the gpg binary, you are better off using the full featured installer at http://www.gpg4win.org . Gpg4win uses GnuPG 2.x and is thus not affected by the security bug. 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 trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.4.16.tar.bz2 you would use this command: gpg --verify gnupg-1.4.16.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com | gpg --import or using a keyserver like gpg --recv-key 4F25E3B6 The distribution key 4F25E3B6 is signed by the well known key 1E42B367. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-1.4.16.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-1.4.16.tar.bz2 and check that the output matches the first line from the following list: 0bf5e475f3eb6f33d5474d017fe5bf66070e43f4 gnupg-1.4.16.tar.bz2 ea40324a5b2e3a16ffb63ea0ccc950a3faf5b11c gnupg-1.4.16.tar.gz ead70b47218ba76da51c16b652bee2a712faf2f6 gnupg-1.4.15-1.4.16.diff.bz2 82079c7c183467b4dd3795ca197983cd2494cec4 gnupg-w32cli-1.4.16.exe Internationalization ==================== GnuPG comes with support for 29 languages. The Chinese (Simple and Traditional), Czech, Danish, Dutch, French, German, Norwegian, Polish, Romanian, Russian, Spanish, Swedish, Ukrainian, and Turkish translations are close to be complete. Support ======= A listing with commercial support offers for GnuPG is available at: http://www.gnupg.org/service.html The driving force behind the development of GnuPG is the company of its principal author, Werner Koch. Maintenance and improvement of GnuPG and related software take up a most of their resources. To allow them continue their work they ask to either purchase a support contract, engage them for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, donating money, spreading the word, or answering questions on the mailing lists. Many thanks to Eran Tromer for providing early drafts of the paper and testing the fixes. Happy Hacking, The GnuPG Team -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 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 Wed Dec 18 21:26:09 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Dec 2013 21:26:09 +0100 Subject: building gnupg with keyserver support but without ldap In-Reply-To: <52B06530.8040802@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 17 Dec 2013 09:52:32 -0500") References: <52B06530.8040802@guardianproject.info> Message-ID: <87ppot52ji.fsf@vigenere.g10code.de> On Tue, 17 Dec 2013 15:52, hans at guardianproject.info said: > Right now, openldap is proving to be a pain to build on Android, and quite > large to boot. Is it possible to build gnupg with keyserver support but > without openldap? I've been trying with the addition of libcurl, but the Should be. However the keyserver stuff is not yet finished. It is one of my top priority tasks to fix that. I am currently using gpg 1 for keyserver access ;-) Thanks for the build server - I will test it later the year or in January. I am overloaded these days. The end of the year requires finishing lots of smaller business tasks and we are strating the funding campaign. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 18 21:27:18 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Dec 2013 21:27:18 +0100 Subject: [Announce] Libgcrypt 1.6.0 released In-Reply-To: (Alex Elsayed's message of "Mon, 16 Dec 2013 21:46:25 -0800") References: <87haa8fzzm.fsf__9326.01447352699$1387217416$gmane$org@vigenere.g10code.de> Message-ID: <87lhzh52hl.fsf@vigenere.g10code.de> On Tue, 17 Dec 2013 06:46, eternaleye at gmail.com said: > A minor correction: RFC-6979 is Deterministic DSA, RFC-6969 is > "OSPFv3 Instance ID Registry Update" Yeah, it is known typo. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Wed Dec 18 22:00:24 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 18 Dec 2013 16:00:24 -0500 Subject: building gnupg with keyserver support but without ldap In-Reply-To: <87ppot52ji.fsf@vigenere.g10code.de> References: <52B06530.8040802@guardianproject.info> <87ppot52ji.fsf@vigenere.g10code.de> Message-ID: <52B20CE8.1060501@guardianproject.info> On 12/18/2013 03:26 PM, Werner Koch wrote: > On Tue, 17 Dec 2013 15:52, hans at guardianproject.info said: >> Right now, openldap is proving to be a pain to build on Android, and quite >> large to boot. Is it possible to build gnupg with keyserver support but >> without openldap? I've been trying with the addition of libcurl, but the > > Should be. However the keyserver stuff is not yet finished. It is one > of my top priority tasks to fix that. I am currently using gpg 1 for > keyserver access ;-) Turns out that libcurl is easy to use on Android, I got that working and included already. Its just openldap that's the big prompt. Any pointers on how to build without ldap? I might be able to do some configure.ac/etc work. > Thanks for the build server - I will test it later the year or in > January. I am overloaded these days. The end of the year requires > finishing lots of smaller business tasks and we are strating the funding > campaign. We saw some signs of that, we'll promote it as well! .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Dec 19 11:08:59 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Dec 2013 11:08:59 +0100 Subject: [Announce] GnuPG launches crowdfunding campaign Message-ID: <87eh592lvo.fsf@vigenere.g10code.de> GnuPG encryption project launches crowdfunding campaign Today GNU Privacy Guard (GnuPG) has launched its first crowdfunding campaign [1] with the aim of building a new website and long term infrastructure. The 24.000 EUR target will fund: - Fresh web interfaces for gnupg.org including mobile - Completion and release of GnuPG 2.1 - Anonymous Tor network access to the website - A new user friendly download page suitable for all devices - A new server for web services - New pages convening external guides, videos, and handbooks - Facilities for processing recurring donations for long term project support Project founder and Lead Developer Werner Koch said ?GnuPG has seen a huge upsurge in popularity following recent state spying revelations. After 16 years of continuous development, we are now asking for community support to capitalise on consumer demand for privacy, and make GnuPG easy to access for mainstream audiences?. GnuPG is one of the few tools remaining above suspicion in the wake of leaked NSA documents. Edward Snowden and his contacts including Bruce Schneier switched to GnuPG when they began handling the secret documents earlier this year [2]. The Wall Street Journal, The Committee to Protect Journalists, and ProPublica [3] have all embraced GnuPG for protection of staff and sources. Phil Zimmermann, original inventor of Pretty Good Privacy (PGP), has also moved to GnuPG in wake of the news. ?GnuPG is a key part of modern privacy infrastructure? said Sam Tuke, Campaign Manager, GnuPG. ?Millions of users rely on GnuPG to work securely on servers, laptops and smartphones, but 2013 donations totaling 3.000 EUR to date have not even covered fixed costs. Supporting new algorithms like elliptical curve and fixing newfound exploits fast takes a lot of work which is done voluntarily. Now is the time for people to contribute to making GnuPG slick and more sustainable in future?. Jacob Appelbaum, Tor Project developer, added ?GnuPG is important - it allows us the assurances we need to do our work. Community funding is a critical part of a confident outlook for GnuPG in future.? For further information, please contact Sam Tuke. Email: samtuke [at] gnupg.org Phone: +49 176 81923811 [1] [2] [3] == About GNU Privacy Guard == GnuPG is a leading cryptography app that protects emails and data from interception. It is developed by a community of Free Software engineers led by Werner Koch. GnuPG is used and recommended by the world?s top security experts, including Bruce Schneier and Phil Zimmermann. It offers best in class privacy free of charge and restriction. Hundreds of companies have integrated GnuPG into their products to perform mission critical security, including Red Hat, Deutsche Bahn, and many others. http://gnupg.org -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Thu Dec 19 11:35:38 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Dec 2013 11:35:38 +0100 Subject: True RNG and GnuPG / libgcrypt In-Reply-To: <20131003115533.GA29459@leortable> (Leo Gaspard's message of "Thu, 3 Oct 2013 13:55:33 +0200") References: <1377157444.3419.8.camel@cfw2.gniibe.org> <1378092424.3168.5.camel@cfw2.gniibe.org> <5230B97E.2080408@mirix.org> <1380163559.3247.5.camel@cfw2.gniibe.org> <524C79E4.9020303@mirix.org> <3DCD67A3-F340-48EB-B2C2-B9025AF7B3AE@mac.com> <20131003115533.GA29459@leortable> Message-ID: <87a9fx2kn9.fsf@vigenere.g10code.de> On Thu, 3 Oct 2013 13:55, ekleog at gmail.com said: > So I believe implementing a fortuna "generator" in GnuPG is not the most urgent > improvement to be made -- though I know nothing of GnuPG's current most-wanted > improvements. GnuPG and Libgcrypt use an RNG architecture described many years ago by Peter Gutmann and also used in his very good Cryptlib. Actually Peter and his co-hackers have been so kind to re-license their code so that we could make use of the Windows and bare Unix entropy gatherers. This random number generator is modelled after the one described in Peter Gutmann's 1998 Usenix Security Symposium paper: "Software Generation of Practically Strong Random Numbers". See also chapter 6 in his book "Cryptographic Security Architecture", New York, 2004, ISBN 0-387-95387-6. Note that the acronym CSPRNG stands for "Continuously Seeded PseudoRandom Number Generator" as used in Peter's implementation of the paper and not only for "Cryptographically Secure PseudoRandom Number Generator". Yarrow and Fortuna are different and simpler designs than this highly conservative CSPRNG. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Dec 20 10:46:22 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Dec 2013 10:46:22 +0100 Subject: [Announce] 0x10 years of protecting privacy Message-ID: <87r497vor5.fsf@vigenere.g10code.de> Hi, me lacking the time to write an update of the 10 Years of GnuPG [2], Sam Tuke was kind enough to draft this: 16 Years of protecting privacy ?????????????????????????????? Today marks 16 years since the first release of GNU Privacy Guard (GnuPG). In that time the project has grown from being a hacker?s hobby into one of the world?s most critical anti-surveillance tools. Today GnuPG stands at the front line of the battle between invasive surveillance and civil liberties. ?Time has proven Free Software [1] to be the most trustworthy defender against companies and governments seeking to undermine citizen privacy? said Werner Koch, GnuPG Founder and Lead Developer. ?Although funding our work has not always been easy, the need for universally accessible privacy tools has never been more apparent?. Some of the world?s top security specialists are now counted among GnuPG users, including Bruce Schneier, Jacob Appelbaum, and Phil Zimmerman, inventor of PGP. This summer the world learned of the extent of Government spying thanks to whistleblowers and journalists communicating using GnuPG encrypted emails. Market leading servers from Red Hat and Debian have built their reputation for security on the foundation of GnuPG-verified software. ?The success of GnuPG?s first crowdfunding campaign, which received 90% of it?s target in 24 hours, shows a fresh willingness among users to support GnuPG in it?s 16th year, and points to new opportunities for the project in future? said Sam Tuke, GnuPG Campaign Manager. ?The release of GnuPG 2.1 and the launch of a newly designed website later this year will bring GnuPG and its clients for Windows, Mac, Gnu/Linux, and Android to new audiences?. Over the years GnuPG has kept up to date with new algorithms, such as Elliptic Curve Cryptography, and reactive to new threats, such as key extraction via acoustic monitoring, which was announced two days ago by researchers as GnuPG updates were released, in coordination with developers. Members remain confident of the future of GnuPG and look forward to facing the privacy threats of tomorrow with community support. [1] http://fsfe.org/freesoftware/basics/4freedoms.en.html [2] http://lists.gnupg.org/pipermail/gnupg-announce/2007q4/000268.html -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 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 hans at guardianproject.info Fri Dec 20 15:44:27 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 20 Dec 2013 09:44:27 -0500 Subject: dynamic CPU detection for libgcrypt assembly code? Message-ID: <52B457CB.9050805@guardianproject.info> Hey, Its great to see all that work being done adding assembly optimizations to libgcrypt, it should make a really big difference on mobile devices. My question is whether there is any kind of dynamic CPU detection that would enable certain modules, like ARM NEON code? We'd like to include the NEON code, but if the same binary won't work on armv7 chips that don't have NEON, then its a showstopper for us. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Fri Dec 20 16:12:37 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Dec 2013 16:12:37 +0100 Subject: libgpg-error : Request to spin up a new version of libgpg-error with ppc64le support. In-Reply-To: <1387534855.15762.12.camel@localhost.localdomain> (Chandan's message of "Fri, 20 Dec 2013 15:50:55 +0530") References: <1387534855.15762.12.camel@localhost.localdomain> Message-ID: <87haa3pndm.fsf@vigenere.g10code.de> On Fri, 20 Dec 2013 11:20, chandand at linux.vnet.ibm.com said: > I was looking at libgpg-error (libgpg-error-1.12) and was failed to > build libgpg-error on ppc64le machine because of outdated libtool. libgpg-error GIT master has already been updated. > Would it be possible for you to spin up a newer version of > "libgpg-error" which would support ppc64le? by using alpha libtool You want a new tarball release? Please wait for about two weeks - we may need to add more error codes anyway. However, if you have a critical dependency on it I can do a release at any time. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Dec 20 16:17:45 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Dec 2013 16:17:45 +0100 Subject: dynamic CPU detection for libgcrypt assembly code? In-Reply-To: <52B457CB.9050805@guardianproject.info> (Hans-Christoph Steiner's message of "Fri, 20 Dec 2013 09:44:27 -0500") References: <52B457CB.9050805@guardianproject.info> Message-ID: <87d2krpn52.fsf@vigenere.g10code.de> On Fri, 20 Dec 2013 15:44, hans at guardianproject.info said: > question is whether there is any kind of dynamic CPU detection that would > enable certain modules, like ARM NEON code? We'd like to include the NEON Libgcrypt uses /proc/self/auxv to detect the presence of NEON. If you run mpicalc --print-config | grep ^hwflist: you get the list of hardware features libgcrypt 1.6 knows about. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jussi.kivilinna at iki.fi Fri Dec 20 16:04:34 2013 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Fri, 20 Dec 2013 17:04:34 +0200 Subject: dynamic CPU detection for libgcrypt assembly code? In-Reply-To: <52B457CB.9050805@guardianproject.info> References: <52B457CB.9050805@guardianproject.info> Message-ID: <52B45C82.1090404@iki.fi> On 20.12.2013 16:44, Hans-Christoph Steiner wrote: > > Hey, > > Its great to see all that work being done adding assembly optimizations to > libgcrypt, it should make a really big difference on mobile devices. My > question is whether there is any kind of dynamic CPU detection that would > enable certain modules, like ARM NEON code? We'd like to include the NEON > code, but if the same binary won't work on armv7 chips that don't have NEON, > then its a showstopper for us. Libgcrypt has HW detection modules for x86 and ARM. On x86, cpuid instruction is used to detect CPU features. On ARM, detection is platform dependent since there is no cpuid instruction; with linux/arm platform NEON detection is done through '/proc/self/auxv':AT_HWCAP. On non-linux/arm platform, NEON implementations can be enabled by compiling binary for ARMv7/NEON (libgcrypt notices that compiler has __ARM_NEON__ macro predefined). -Jussi > > .hc > From hans at guardianproject.info Fri Dec 20 17:09:51 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 20 Dec 2013 11:09:51 -0500 Subject: dynamic CPU detection for libgcrypt assembly code? In-Reply-To: <52B45C82.1090404@iki.fi> References: <52B457CB.9050805@guardianproject.info> <52B45C82.1090404@iki.fi> Message-ID: <52B46BCF.6000709@guardianproject.info> On 12/20/2013 10:04 AM, Jussi Kivilinna wrote: > On 20.12.2013 16:44, Hans-Christoph Steiner wrote: >> >> Hey, >> >> Its great to see all that work being done adding assembly optimizations to >> libgcrypt, it should make a really big difference on mobile devices. My >> question is whether there is any kind of dynamic CPU detection that would >> enable certain modules, like ARM NEON code? We'd like to include the NEON >> code, but if the same binary won't work on armv7 chips that don't have NEON, >> then its a showstopper for us. > > Libgcrypt has HW detection modules for x86 and ARM. On x86, cpuid instruction > is used to detect CPU features. On ARM, detection is platform dependent since > there is no cpuid instruction; with linux/arm platform NEON detection is done through '/proc/self/auxv':AT_HWCAP. On non-linux/arm platform, NEON implementations can be enabled by compiling binary for ARMv7/NEON (libgcrypt notices that compiler has __ARM_NEON__ macro predefined). So Android is Linux but not GNU or UNIX. Sounds like /proc/self/auxv should work for Android then, in my quick survey of one Android device, it does have /proc/self/auxv. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From jussi.kivilinna at iki.fi Fri Dec 20 20:06:28 2013 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Fri, 20 Dec 2013 21:06:28 +0200 Subject: dynamic CPU detection for libgcrypt assembly code? In-Reply-To: <52B46BCF.6000709@guardianproject.info> References: <52B457CB.9050805@guardianproject.info> <52B45C82.1090404@iki.fi> <52B46BCF.6000709@guardianproject.info> Message-ID: <52B49534.9010309@iki.fi> On 20.12.2013 18:09, Hans-Christoph Steiner wrote: > > > On 12/20/2013 10:04 AM, Jussi Kivilinna wrote: >> On 20.12.2013 16:44, Hans-Christoph Steiner wrote: >>> >>> Hey, >>> >>> Its great to see all that work being done adding assembly optimizations to >>> libgcrypt, it should make a really big difference on mobile devices. My >>> question is whether there is any kind of dynamic CPU detection that would >>> enable certain modules, like ARM NEON code? We'd like to include the NEON >>> code, but if the same binary won't work on armv7 chips that don't have NEON, >>> then its a showstopper for us. >> >> Libgcrypt has HW detection modules for x86 and ARM. On x86, cpuid instruction >> is used to detect CPU features. On ARM, detection is platform dependent since >> there is no cpuid instruction; with linux/arm platform NEON detection is done through '/proc/self/auxv':AT_HWCAP. On non-linux/arm platform, NEON implementations can be enabled by compiling binary for ARMv7/NEON (libgcrypt notices that compiler has __ARM_NEON__ macro predefined). > > So Android is Linux but not GNU or UNIX. Sounds like /proc/self/auxv should > work for Android then, in my quick survey of one Android device, it does have > /proc/self/auxv. Well, after little bit of research, I found out that Android blocks read access to /proc/self/auxv. Instead there is another API for cpu features: http://www.kandroid.org/ndk/docs/CPU-ARM-NEON.html For proper NEON support on Android, libgcrypt should use this API for arm hw detection. -Jussi > > .hc > From hans at guardianproject.info Fri Dec 20 20:16:38 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 20 Dec 2013 14:16:38 -0500 Subject: dynamic CPU detection for libgcrypt assembly code? In-Reply-To: <52B49534.9010309@iki.fi> References: <52B457CB.9050805@guardianproject.info> <52B45C82.1090404@iki.fi> <52B46BCF.6000709@guardianproject.info> <52B49534.9010309@iki.fi> Message-ID: <52B49796.4050200@guardianproject.info> On 12/20/2013 02:06 PM, Jussi Kivilinna wrote: > On 20.12.2013 18:09, Hans-Christoph Steiner wrote: >> >> >> On 12/20/2013 10:04 AM, Jussi Kivilinna wrote: >>> On 20.12.2013 16:44, Hans-Christoph Steiner wrote: >>>> >>>> Hey, >>>> >>>> Its great to see all that work being done adding assembly optimizations to >>>> libgcrypt, it should make a really big difference on mobile devices. My >>>> question is whether there is any kind of dynamic CPU detection that would >>>> enable certain modules, like ARM NEON code? We'd like to include the NEON >>>> code, but if the same binary won't work on armv7 chips that don't have NEON, >>>> then its a showstopper for us. >>> >>> Libgcrypt has HW detection modules for x86 and ARM. On x86, cpuid instruction >>> is used to detect CPU features. On ARM, detection is platform dependent since >>> there is no cpuid instruction; with linux/arm platform NEON detection is done through '/proc/self/auxv':AT_HWCAP. On non-linux/arm platform, NEON implementations can be enabled by compiling binary for ARMv7/NEON (libgcrypt notices that compiler has __ARM_NEON__ macro predefined). >> >> So Android is Linux but not GNU or UNIX. Sounds like /proc/self/auxv should >> work for Android then, in my quick survey of one Android device, it does have >> /proc/self/auxv. > > Well, after little bit of research, I found out that Android blocks read access > to /proc/self/auxv. Instead there is another API for cpu features: > http://www.kandroid.org/ndk/docs/CPU-ARM-NEON.html > > For proper NEON support on Android, libgcrypt should use this API for arm hw > detection. > e > -Jussi Ok, sounds not too bad. I won't have time to work on this particular issue in the near future, but I added it to our issue tracker: https://dev.guardianproject.info/issues/2807 If someone implements it, I can test it. Indeed, our new automatic nightly build of GnuPG for Android will run some of the tests on it automatically :). .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From chdiza at gmail.com Sat Dec 21 08:19:25 2013 From: chdiza at gmail.com (Charles Diza) Date: Sat, 21 Dec 2013 02:19:25 -0500 Subject: Fix for bug #1547 from the tracker Message-ID: I believe I've solved bug #1547 from the tracker, which means the workaround in #1541 is obsolete, and finally gnupg2 will build on recent versions of MacOSX again. Like the OP for that bug, I observed that gnupg2.0.22 will build fine on OSX, with XCode5, using the package manager Homebrew. I discovered the reason for this. It's because on XCode5 (which requires OSX 10.8 or greater), the variable $gl_cv_absolute_stdint_h is set by gnupg2's configure script to /Applications/Xcode.app/Contents/Developer/Toolchains/ XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.0/include/stdint.h But that copy of stdint.h is buggy (don't ask me why). Homebrew knew about this a long time ago, and they manually set that variable to just be: /usr/include/stdint.h, which is a non-buggy copy. So I built gnupg 2.0.22 straight up (not in Homebrew) after doing: export gl_cv_absolute_stdint_h=/usr/include/stdint.h before doing ./configure. Then everything built as it normally did before XCode5 came out. Hooray! Also, I tested this method on older versions of OSX: 10.7, 10.5, 10.4, and it builds fine over there. So the fix for XCode5 doesn't break Mac builds that aren't on XCode5. So I think the configure script should be modified so that on the Mac it sets that variable to just be /usr/include/stdint.h. At least on 10.9 and 10.8. -Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Sat Dec 21 11:28:58 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 21 Dec 2013 11:28:58 +0100 Subject: dynamic CPU detection for libgcrypt assembly code? In-Reply-To: <52B49534.9010309@iki.fi> (Jussi Kivilinna's message of "Fri, 20 Dec 2013 21:06:28 +0200") References: <52B457CB.9050805@guardianproject.info> <52B45C82.1090404@iki.fi> <52B46BCF.6000709@guardianproject.info> <52B49534.9010309@iki.fi> Message-ID: <87sitmlcph.fsf@vigenere.g10code.de> On Fri, 20 Dec 2013 20:06, jussi.kivilinna at iki.fi said: > Well, after little bit of research, I found out that Android blocks > read access to /proc/self/auxv. Instead there is another API for cpu I guess it is better not to think of Android as a Linux kernel bases OS. They should have named their kernel googlix Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Mon Dec 23 03:24:16 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Sun, 22 Dec 2013 21:24:16 -0500 Subject: libgcrypt's ./configure should report Android as Android (patch) Message-ID: <52B79ED0.8050301@guardianproject.info> Attached is a simple patch to make libgcrypt's ./configure report Android as Android, and not as GNU/Linux: .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-make-.-configure-report-Android-as-Android-and-not-G.patch Type: text/x-patch Size: 882 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From hans at guardianproject.info Mon Dec 23 03:44:39 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Sun, 22 Dec 2013 21:44:39 -0500 Subject: dynamic CPU detection for libgcrypt assembly code? In-Reply-To: <87sitmlcph.fsf@vigenere.g10code.de> References: <52B457CB.9050805@guardianproject.info> <52B45C82.1090404@iki.fi> <52B46BCF.6000709@guardianproject.info> <52B49534.9010309@iki.fi> <87sitmlcph.fsf@vigenere.g10code.de> Message-ID: <52B7A397.1040806@guardianproject.info> On 12/21/2013 05:28 AM, Werner Koch wrote: > On Fri, 20 Dec 2013 20:06, jussi.kivilinna at iki.fi said: > >> Well, after little bit of research, I found out that Android blocks >> read access to /proc/self/auxv. Instead there is another API for cpu > > I guess it is better not to think of Android as a Linux kernel bases > OS. They should have named their kernel googlix > > > Shalom-Salam, > > Werner Android is definitely Linux, the kernel used in Android is quite close to plain Linux. Android just highlights the GNU project's stance on the name GNU/Linux. Most people confuse Linux with GNU/Linux, and that's where the problems begin. As Android clearly points out, UNIX models are not inherint to OSes built on top of the Linux kernel. While Android is the most popular non-UNIX that uses the Linux kernel, it is certainly not the only one. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From hans at guardianproject.info Mon Dec 23 21:40:19 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 23 Dec 2013 15:40:19 -0500 Subject: dynamic CPU detection for libgcrypt assembly code? In-Reply-To: <52B49534.9010309@iki.fi> References: <52B457CB.9050805@guardianproject.info> <52B45C82.1090404@iki.fi> <52B46BCF.6000709@guardianproject.info> <52B49534.9010309@iki.fi> Message-ID: <52B89FB3.4000200@guardianproject.info> On 12/20/2013 02:06 PM, Jussi Kivilinna wrote: > On 20.12.2013 18:09, Hans-Christoph Steiner wrote: >> >> >> On 12/20/2013 10:04 AM, Jussi Kivilinna wrote: >>> On 20.12.2013 16:44, Hans-Christoph Steiner wrote: >>>> >>>> Hey, >>>> >>>> Its great to see all that work being done adding assembly optimizations to >>>> libgcrypt, it should make a really big difference on mobile devices. My >>>> question is whether there is any kind of dynamic CPU detection that would >>>> enable certain modules, like ARM NEON code? We'd like to include the NEON >>>> code, but if the same binary won't work on armv7 chips that don't have NEON, >>>> then its a showstopper for us. >>> >>> Libgcrypt has HW detection modules for x86 and ARM. On x86, cpuid instruction >>> is used to detect CPU features. On ARM, detection is platform dependent since >>> there is no cpuid instruction; with linux/arm platform NEON detection is done through '/proc/self/auxv':AT_HWCAP. On non-linux/arm platform, NEON implementations can be enabled by compiling binary for ARMv7/NEON (libgcrypt notices that compiler has __ARM_NEON__ macro predefined). >> >> So Android is Linux but not GNU or UNIX. Sounds like /proc/self/auxv should >> work for Android then, in my quick survey of one Android device, it does have >> /proc/self/auxv. > > Well, after little bit of research, I found out that Android blocks read access > to /proc/self/auxv. Instead there is another API for cpu features: > http://www.kandroid.org/ndk/docs/CPU-ARM-NEON.html > > For proper NEON support on Android, libgcrypt should use this API for arm hw > detection. > > -Jussi > >> >> .hc Ok, I tested this latest patch on my unrooted dev tablet, and it detects NEON properly. I think that patch is ready to include. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Thu Dec 26 01:32:42 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 26 Dec 2013 09:32:42 +0900 Subject: Gnuk 1.1.1 Message-ID: <1388017962.3165.2.camel@cfw2.gniibe.org> Hello, Development version of Gnuk 1.1.1 was released. Gnuk is an implementation of Cryptographic Token for GnuPG, and it runs on STM32F103. This is experimental version, with new thread library. While I have been using Gnuk 1.0.1 for about 1.5 year, this version is not used much. It has been only tested with the test suite. Basically, this version is for developers. It is better to stay with stable Gnuk 1.0.x for normal case. But, for Japanese people who like bleeding edge, I'm doing a little campaign of FST-01 wit Gnuk 1.1.1 (only ten or so): http://www.gniibe.org/shop/gnuk_1_1_x-on-fst-01 (in Japanese) RSA computation routine is updated and improved, too. Major change is from upstream PolarSSL 1.2.10 (against timing attack), but we don't use RSA blinding for Gnuk. Instead, I fixed all timing differences of original PolarSSL, carefully and correctly. During this change, memory consumption and speed are improved a bit. Note that the risk by such an attack is not that huge if you follow a general practice of Gnuk Token (inserting the token only when used, and unattended use (for days) couldn't occur), in the first place. Therefore, we don't urge Gnuk 1.0.x users to upgrade 1.1.0 as security upgrade. To handle the risk of unattended use, card insertion/removal simulation feature is added, but this is also experimental, too. This version include the source code of Elliptic Curve Cryptography and the NIST curve P256. It is not enabled, because no one would use it. When enabled, you can use the key of ECC with SSH and development version of GnuPG 2.1.x. I had thought that this were the new feature of 2013, but, well, life is hard. I will implement a different curve next year. Here are the list of changes (in 1.1.0 and 1.1.1). * Overriding key import / generation (Incompatible Change) Gnuk supports overriding key import or key generation even if keys are already installed. Note that it will result password reset of user. * RSA key generation improvement Prime number generation is done by Fouque-Tibouchi method. * Security fix for RSA computation PolarSSL had a vulnerability against timing attack. For detail, please see: http://www.gniibe.org/memo/development/gnuk/polarssl/polarssl-rsa-blinding * Improved RSA routine RSA computation has been improved using MPI square routine. Note that you should not adopt this modification for general purpose computer, as this change is weak against the Yarom/Falkner flush+reload cache side-channel attack. Working memory for RSA computation is taken from stack instead of malloc (mostly). * Upgrade of NeuG The true random number generator was upgraded to the one of NeuG 1.0. * Replacement of kernel (thread library) Instead of ChibiOS/RT, we now use Chopstx. * Removal of obsolete features The feature named pin-dial, which is pin input with hardware enhancement (with rotary encoder) is removed. * Tools and test suite now work with PyUSB 1.0, too. It only worked with PyUSB 0.4.3, but it works with PyUSB 1.0 too. Links: Gnuk Documentation: http://www.fsij.org/doc-gnuk/ Gnuk Repository: http://gitorious.org/gnuk/ FST-01 introduction: http://www.seeedstudio.com/wiki/index.php?title=FST-01 FST-01 Gnuk Handbook (in Japanese); http://no-passwd.net/fst-01-gnuk-handbook/ Happy Hacking and Happy Holidays. Enjoy, --