From buanzo at buanzo.com.ar Thu Aug 1 18:41:39 2013 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Thu, 1 Aug 2013 16:41:39 +0000 (UTC) Subject: Invitation to connect on LinkedIn Message-ID: <1725899606.59092715.1375375299533.JavaMail.app@ela4-app0131.prod> LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Arturo 'Buanzo' Arturo 'Buanzo' Busleiman Developer at OWASP Argentina Confirm that you know Arturo 'Buanzo' Busleiman: https://www.linkedin.com/e/gubhr-hju6xx29-2g/isd/15458425062/_PX-2F3w/?hs=false&tok=3xChs7j_aFNBQ1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/gubhr-hju6xx29-2g/unf1-ezSvsJoK9EMApgCVEzSvsJo5nDk1O/goo/gnupg-devel%40gnupg%2Eorg/20061/I5146257092_1/?hs=false&tok=2TCLzHbHqFNBQ1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From timprepscius at gmail.com Thu Aug 1 23:14:34 2013 From: timprepscius at gmail.com (Tim Prepscius) Date: Thu, 1 Aug 2013 17:14:34 -0400 Subject: sending in band public key Message-ID: > Sending the public key is not common with OpenPGP - You send it out of > band. Only S/MIME resorts to this kludged due to the non-standardized > way of looking up keys (Oh well, unless you use the global X.500 > directory ;-) If I were to send a public key in-band. Is the security concern that the mail could be intercepted in route and the key be replaced by a different key? MITM. Or are there other security concerns as well? -tim From hagman33 at icloud.com Fri Aug 2 03:00:27 2013 From: hagman33 at icloud.com (Aaron) Date: Thu, 01 Aug 2013 19:00:27 -0600 Subject: Ready Message-ID: Ready Hagman From daniel.leidert.spam at gmx.net Sat Aug 3 14:02:56 2013 From: daniel.leidert.spam at gmx.net (Daniel Leidert) Date: Sat, 03 Aug 2013 14:02:56 +0200 Subject: gpg 1.4.x and 2.0.x differ in output with --with-colons --check-sigs In-Reply-To: <87fvv27m2w.fsf@vigenere.g10code.de> References: <87bo67dbir.fsf@alice.fifthhorseman.net> <1374400742.4984.3.camel@haktar.debian.wgdd.de> <87fvv27m2w.fsf@vigenere.g10code.de> Message-ID: <1375531376.492.1.camel@haktar.debian.wgdd.de> Am Donnerstag, den 25.07.2013, 16:25 +0200 schrieb Werner Koch: > On Sun, 21 Jul 2013 11:59, daniel.leidert.spam at gmx.net said: > > > apply it to Debian. I decided to do not for Wheezy. Would be nice, if > > this patch would make it officially into the 1.4 series. > > Sorry, too late for 1.4.14. Maybe in 1.4.15? If you don't plan to add this patch to the 1.4 series I'm hesitating to apply it to the Debian package. Regards, Daniel From troy.clevenger at gmail.com Sat Aug 10 20:33:03 2013 From: troy.clevenger at gmail.com (Troy Clevenger) Date: Sat, 10 Aug 2013 14:33:03 -0400 Subject: Unable to compile latest npth library for Windows. Message-ID: Hello, After some trial and error I was able to get GnuPG-2.1.0beta3 compiled and running on Windows using the latest Debian distro and mingw. This is 100+ commits behind the latest on master, so I pulled down the latest from the git repositories and tried to build that. Nothing since the switch to using the npth library will compile for me though, because it want's a newer version of the npth library. So I must not be compiling it properly. The latest npth code in git throws this error when I try to build it. root at debian:~/npth# make make all-recursive make[1]: Entering directory `/root/npth' Making all in w32 make[2]: Entering directory `/root/npth/w32' /bin/bash ../libtool --tag=CC --mode=link i586-mingw32msvc-gcc -g -O2 -no-undefined -export-symbols ./npth.def -version-info 0:2:0 -o libnpth.la -rpath /root/w32root/lib npth.lo @NETLIBS@ libtool: link: /usr/bin/i586-mingw32msvc-nm -B .libs/npth.o | sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*_\([_A-Za-z][_A-Za-z0-9]*\)$/\1 _\2 \2/p' | sed '/ __gnu_lto/d' | /bin/sed -e '/^[BCDGRS][ ]/s/.*[ ]\([^ ]*\)/\1 DATA/;s/^.*[ ]__nm__\([^ ]*\)[ ][^ ]*/\1 DATA/;/^I[ ]/d;/^[AITW][ ]/s/.* //' | sort | uniq > .libs/libnpth.exp /usr/bin/i586-mingw32msvc-nm: '.libs/npth.o': No such file libtool: link: if test "x`/bin/sed 1q .libs/libnpth.def`" = xEXPORTS; then cp .libs/libnpth.def .libs/libnpth-0.dll.def; else echo EXPORTS > .libs/libnpth-0.dll.def; cat .libs/libnpth.def >> .libs/libnpth-0.dll.def; fi libtool: link: i586-mingw32msvc-gcc -shared .libs/libnpth-0.dll.def .libs/npth.o -O2 @NETLIBS@ -o .libs/libnpth-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libnpth.dll.a i586-mingw32msvc-gcc: .libs/npth.o: No such file or directory i586-mingw32msvc-gcc: @NETLIBS@: No such file or directory make[2]: *** [libnpth.la] Error 1 make[2]: Leaving directory `/root/npth/w32' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/npth' make: *** [all] Error 2 I think I've initialized everything correctly using ./autogen.sh and ./autogen.sh --build-w32 before running make. I used narrowed it down to commit 96964e02 where the NETLIBS block was removed from configure.ac. If I restore that, it then compiles, but GnuPG build still fails with npth library problems. So my guess is that I'm not doing something right building npth. If anyone can help, I'd be very grateful. Troy From wk at gnupg.org Sun Aug 11 14:48:04 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 11 Aug 2013 14:48:04 +0200 Subject: Unable to compile latest npth library for Windows. In-Reply-To: (Troy Clevenger's message of "Sat, 10 Aug 2013 14:33:03 -0400") References: Message-ID: <87zjsoe6m3.fsf@vigenere.g10code.de> On Sat, 10 Aug 2013 20:33, troy.clevenger at gmail.com said: > libtool: link: /usr/bin/i586-mingw32msvc-nm -B .libs/npth.o | sed Meanwhile I switched to i686-w64-mingw32 (Debian gcc-mingw-w64-i686) and thus it is quite possible that the old mingw32 does not anymore work. The problem is that both projects add their own extensions/fixes/whatever to the header files. It try not to break old code but testing that all is to expensive. I suggest that you switch to that toolchain; it is in Wheezy. > configure.ac. If I restore that, it then compiles, but GnuPG build > still fails with npth library problems. So my guess is that I'm not Anyway, master does not yet build for Windows. Would be easy to fix, but right now Windows for 2.1 has low priority. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From alphazo at gmail.com Mon Aug 12 13:47:53 2013 From: alphazo at gmail.com (Alphazo) Date: Mon, 12 Aug 2013 13:47:53 +0200 Subject: smartcard stub not imported when migrating to gnupg 2.1 In-Reply-To: <87fvvmv8kj.fsf@vigenere.g10code.de> References: <87zjtuve2m.fsf@vigenere.g10code.de> <87fvvmv8kj.fsf@vigenere.g10code.de> Message-ID: Hi Werner, Have you had a chance to look at my key import issue ? Thanks Alphazo On Wed, Jul 10, 2013 at 3:38 PM, Werner Koch wrote: > On Wed, 10 Jul 2013 15:07, alphazo at gmail.com said: > > > gpg: encrypted with 3072-bit RSA key, ID A45B67C8, created 2010-11-07 > > "Test Key" " > > gpg: public key decryption failed: Wrong secret key used > > gpg: decryption failed: No secret key > > I need to look closer at it. Please give me a few days. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Aug 12 15:09:22 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Aug 2013 15:09:22 +0200 Subject: [Announce] GPGME 1.4.3 released Message-ID: <87siyfdpj1.fsf@vigenere.g10code.de> Hello! I am pleased to announce version 1.4.3 of GPGME. GnuPG Made Easy (GPGME) is a C language library that allows to add support for cryptography to a program. It is designed to make access to public key crypto engines as included in GnuPG easier for applications. GPGME provides a high-level crypto API for encryption, decryption, signing, signature verification, and key management. * Noteworthy changes in version 1.4.3 (2013-08-12) - The default engine names are now taken from the output of gpgconf. If gpgconf is not found the use of gpg 1 is assumed. - Under Windows the default engines names are first searched in the installation directory of the gpgme DLL. - New function gpgme_data_identify to detect the type of a message. - Interface changes relative to the 1.4.2 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gpgme_signers_count NEW. gpgme_data_type_t NEW. gpgme_data_identify NEW. * Download You may download this library and its OpenPGP signature from: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.3.tar.bz2 (950k) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.3.tar.bz2.sig GZIP compressed tarballs are also available: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.3.tar.gz (1202k) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.3.tar.gz.sig As an alternative you may use a patch file to upgrade the previous version of the library: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.2-1.4.3.diff.bz2 (27k) SHA-1 checksums are: ffdb5e4ce85220501515af8ead86fd499525ef9a gpgme-1.4.3.tar.bz2 65c7f78593065946a7480c3389b4b1f19326a59d gpgme-1.4.3.tar.gz dc9f68f8d2fa1208f736035fc6c5693ae4bac0f7 gpgme-1.4.2-1.4.3.diff.bz2 * Support Please send questions regarding the use of GPGME to the gnupg-devel mailing list: http://lists.gnupg.org/mailman/listinfo/gnupg-devel/ If you need commercial support, you may want to consult this listing: http://www.gnupg.org/service.html The driving force behind the development of the GnuPG system is my company g10 Code. Maintenance and improvement of GnuPG 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 Happy hacking, Werner -- 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 Mon Aug 12 19:07:50 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Aug 2013 19:07:50 +0200 Subject: smartcard stub not imported when migrating to gnupg 2.1 In-Reply-To: (alphazo@gmail.com's message of "Mon, 12 Aug 2013 13:47:53 +0200") References: <87zjtuve2m.fsf@vigenere.g10code.de> <87fvvmv8kj.fsf@vigenere.g10code.de> Message-ID: <8738qeet21.fsf@vigenere.g10code.de> On Mon, 12 Aug 2013 13:47, alphazo at gmail.com said: > Have you had a chance to look at my key import issue ? Not yet. Sorry. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Mon Aug 12 21:26:36 2013 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 12 Aug 2013 15:26:36 -0400 Subject: [Announce] GPGME 1.4.3 released In-Reply-To: <87siyfdpj1.fsf@vigenere.g10code.de> References: <87siyfdpj1.fsf@vigenere.g10code.de> Message-ID: <520936EC.70209@guardianproject.info> Congrats on the release! The data_identify stuff sounds quite useful, thanks for that! I see that it can tell signed and encrypted. Can it also identify a .gpg file that contains keys? Like what would this report if I ran it on pubring.gpg, secring.gpg, or trustdb.gpg? From your other email, these are the supported types it identifies: case GPGME_DATA_TYPE_CMS_SIGNED: case GPGME_DATA_TYPE_CMS_ENCRYPTED: case GPGME_DATA_TYPE_CMS_OTHER: case GPGME_DATA_TYPE_X509_CERT: case GPGME_DATA_TYPE_PKCS12: Will it identify a file with symmetrically encrypted data in it? .hc On 08/12/2013 09:09 AM, Werner Koch wrote: > Hello! > > I am pleased to announce version 1.4.3 of GPGME. > > GnuPG Made Easy (GPGME) is a C language library that allows to add > support for cryptography to a program. It is designed to make access > to public key crypto engines as included in GnuPG easier for > applications. GPGME provides a high-level crypto API for encryption, > decryption, signing, signature verification, and key management. > > > * Noteworthy changes in version 1.4.3 (2013-08-12) > > - The default engine names are now taken from the output of gpgconf. > If gpgconf is not found the use of gpg 1 is assumed. > > - Under Windows the default engines names are first searched in the > installation directory of the gpgme DLL. > > - New function gpgme_data_identify to detect the type of a message. > > - Interface changes relative to the 1.4.2 release: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > gpgme_signers_count NEW. > gpgme_data_type_t NEW. > gpgme_data_identify NEW. > > > * Download > > You may download this library and its OpenPGP signature from: > > ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.3.tar.bz2 (950k) > ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.3.tar.bz2.sig > > GZIP compressed tarballs are also available: > > ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.3.tar.gz (1202k) > ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.3.tar.gz.sig > > As an alternative you may use a patch file to upgrade the previous > version of the library: > > ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.2-1.4.3.diff.bz2 (27k) > > SHA-1 checksums are: > > ffdb5e4ce85220501515af8ead86fd499525ef9a gpgme-1.4.3.tar.bz2 > 65c7f78593065946a7480c3389b4b1f19326a59d gpgme-1.4.3.tar.gz > dc9f68f8d2fa1208f736035fc6c5693ae4bac0f7 gpgme-1.4.2-1.4.3.diff.bz2 > > > * Support > > Please send questions regarding the use of GPGME to the gnupg-devel > mailing list: > > http://lists.gnupg.org/mailman/listinfo/gnupg-devel/ > > If you need commercial support, you may want to consult this listing: > > http://www.gnupg.org/service.html > > The driving force behind the development of the GnuPG system is my > company g10 Code. Maintenance and improvement of GnuPG 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 > > > > Happy hacking, > > Werner > > > > > _______________________________________________ > Gnupg-announce mailing list > Gnupg-announce at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-announce > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -- 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: 939 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Aug 12 23:27:49 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Aug 2013 23:27:49 +0200 Subject: [Announce] GPGME 1.4.3 released In-Reply-To: <520936EC.70209@guardianproject.info> (Hans-Christoph Steiner's message of "Mon, 12 Aug 2013 15:26:36 -0400") References: <87siyfdpj1.fsf@vigenere.g10code.de> <520936EC.70209@guardianproject.info> Message-ID: <87y586d2ga.fsf@vigenere.g10code.de> On Mon, 12 Aug 2013 21:26, hans at guardianproject.info said: > Congrats on the release! The data_identify stuff sounds quite useful, thanks > for that! I see that it can tell signed and encrypted. Can it also identify > a .gpg file that contains keys? Like what would this report if I ran it on Until now it is quite limited. For OpenPGP the code is currently only able to detect the type of armored files. For CMS a real binary parser is included (very basic but sufficient). > pubring.gpg, secring.gpg, or trustdb.gpg? Not yet, not yet, unknown. trustdb is internal to gpg and thus the format is not of any interest to other software. I consider it more important to have an interface which can be used now. Adding an OpenPGP parser can be done for the next release. I have some code for this somewhere but it needs to be mangled for the new purpose. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From troy.clevenger at gmail.com Tue Aug 13 04:23:40 2013 From: troy.clevenger at gmail.com (Troy Clevenger) Date: Mon, 12 Aug 2013 22:23:40 -0400 Subject: Unable to compile latest npth library for Windows. In-Reply-To: <87zjsoe6m3.fsf@vigenere.g10code.de> References: <87zjsoe6m3.fsf@vigenere.g10code.de> Message-ID: Thank you for your reply, I'll switch over to using the i686-w64 toolchain and let you know how it goes. But it sounds like if I want to try out the features in 2.1 I'll need to stick with using it in linux. Troy On Sun, Aug 11, 2013 at 8:48 AM, Werner Koch wrote: > On Sat, 10 Aug 2013 20:33, troy.clevenger at gmail.com said: > >> libtool: link: /usr/bin/i586-mingw32msvc-nm -B .libs/npth.o | sed > > Meanwhile I switched to i686-w64-mingw32 (Debian gcc-mingw-w64-i686) and > thus it is quite possible that the old mingw32 does not anymore work. > The problem is that both projects add their own > extensions/fixes/whatever to the header files. It try not to break old > code but testing that all is to expensive. I suggest that you switch to > that toolchain; it is in Wheezy. > >> configure.ac. If I restore that, it then compiles, but GnuPG build >> still fails with npth library problems. So my guess is that I'm not > > Anyway, master does not yet build for Windows. Would be easy to fix, > but right now Windows for 2.1 has low priority. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > From wk at gnupg.org Tue Aug 13 18:03:44 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 Aug 2013 18:03:44 +0200 Subject: PUBKEY_USAGE_AUTH In-Reply-To: <1372817431.3324.4.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Wed, 03 Jul 2013 11:10:31 +0900") References: <1372817431.3324.4.camel@cfw2.gniibe.org> Message-ID: <87vc39bmsf.fsf@vigenere.g10code.de> On Wed, 3 Jul 2013 04:10, gniibe at fsij.org said: > With Gnuk Token, I have been using a subkey for authentication, that > is, a subkey with PUBKEY_USAGE_AUTH flag. But I only use it through > gpg-agent for SSH-agent service and Scute for X.509 client certificate Yes that was the idea. > Does it make sense to add an option like --auth to enable using > authkey for --sign or --clearsign? Or some flag to enable > gpgme_op_sign using authkey? OpenPGP only says 0x20 - This key may be used for authentication. Thus, if an OpenPGP signature is part of an authentication system, it makes sense to allow the use of such a key. Anyone with ideas for the best way to tell gpg about this. Shall gpg only select authkeys then? In terms of GPGME integration an option to switch to (or allow the use of) authkeys would be the easiest way. > I know that we can use gpg-connect-agent and PKSIGN. I want somewhat > public API for authentication subkey. You can also use GPGME for this: /* Send the Assuan COMMAND and return results via the callbacks. Asynchronous variant. */ gpgme_error_t gpgme_op_assuan_transact_ext (gpgme_ctx_t ctx, ..... This is for example used by GPA's smartcard interface. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Aug 13 18:17:45 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 Aug 2013 18:17:45 +0200 Subject: agent: fix for UPDATESTARTUPTTY In-Reply-To: <1372909313.3163.4.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Thu, 04 Jul 2013 12:41:53 +0900") References: <1372909313.3163.4.camel@cfw2.gniibe.org> Message-ID: <87r4dxbm52.fsf@vigenere.g10code.de> On Thu, 4 Jul 2013 05:41, gniibe at fsij.org said: > (1) When I want to use pinentry for nterminal, there is no way, > if I already have gpg-agent with DISPLAY. Right, whether an X or an ncurses pinentry is used depends solely on DISPLAY. As far as I can see, there is no way to unset DISPLAY for pinentry. Thus we either need to add a new IGNORE_DISPLAY feature or use DISPLAY with a special value (DISPLAY=none) and detect that right before calling pinentry. > (2) UPDATESTARTUPTTY doesn't work to switch TTY for pinentry for SSH. > Latter is simply a bug. Right. Would you mind to prepare and push a patch? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bruce.dubbs at gmail.com Tue Aug 13 17:48:38 2013 From: bruce.dubbs at gmail.com (Bruce Dubbs) Date: Tue, 13 Aug 2013 10:48:38 -0500 Subject: GPGME 1.4.3 make check failure Message-ID: <520A5556.3090408@gmail.com> Building with a simple: ./configure --prefix=/usr && make && make check hangs for me at tests/gpgsm/t-verify. Running t-verify directly gives a segmentation fault: /tmp/gpgme/gpgme-1.4.3/tests/gpgsm $ ./t-verify t-verify.c:71: Unexpected signature summary: want=0x3 have=0x80 Segmentation fault Changing check_result to return immediately after detecting an error leads to a hang at the first 'show_auditlog (ctx);' -- Bruce Dubbs linuxfromscratch.org From wk at gnupg.org Tue Aug 13 19:16:01 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 13 Aug 2013 19:16:01 +0200 Subject: GPGME 1.4.3 make check failure In-Reply-To: <520A5556.3090408@gmail.com> (Bruce Dubbs's message of "Tue, 13 Aug 2013 10:48:38 -0500") References: <520A5556.3090408@gmail.com> Message-ID: <87mwolbjfy.fsf@vigenere.g10code.de> On Tue, 13 Aug 2013 17:48, bruce.dubbs at gmail.com said: > hangs for me at tests/gpgsm/t-verify. Running t-verify directly gives > a segmentation fault: Can you please send me by PM the config.log? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Aug 19 14:38:16 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Aug 2013 14:38:16 +0200 Subject: [Announce] GnuPG 2.0.21 released Message-ID: <87mwod5007.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.21. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data, create digital signatures, help authenticating using Secure Shell and to provide a framework for public key cryptography. It includes an advanced key management facility and is compliant with the OpenPGP and S/MIME standards. GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.14) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. GnuPG is distributed under the terms of the GNU General Public License (GPLv3+). GnuPG-2 works best on GNU/Linux and *BSD systems but is also available for other Unices, Microsoft Windows and Mac OS X. What's New in 2.0.21 ==================== * gpg-agent: By default the users are now asked via the Pinentry whether they trust an X.509 root key. To prohibit interactive marking of such keys, the new option --no-allow-mark-trusted may be used. * gpg-agent: The command KEYINFO has options to add info from sshcontrol. * The included ssh agent does now support ECDSA keys. * The new option --enable-putty-support allows gpg-agent to act on Windows as a Pageant replacement with full smartcard support. * Support installation as portable application under Windows. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.21 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . 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 FTP server and its mirrors you should find the following files in the gnupg/ directory: gnupg-2.0.21.tar.bz2 (4200k) gnupg-2.0.21.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.20-2.0.21.diff.bz2 (39k) A patch file to upgrade a 2.0.20 GnuPG source tree. This patch does not include updates of the language files. Note, that we don't distribute gzip compressed tarballs for GnuPG-2. 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-2.0.21.tar.bz2 you would use this command: gpg --verify gnupg-2.0.21.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 or using a keyserver like gpg --keyserver keys.gnupg.net --recv-key 4F25E3B6 The distribution key 4F25E3B6 is signed by the well known key 1E42B367. 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-2.0.21.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.21.tar.bz2 and check that the output matches the first line from the following list: 5ba8cce72eb4fd1a3ac1a282d25d7c7b90d3bf26 gnupg-2.0.21.tar.bz2 cd94a6267088eeff4735641b1fc832a1e6770ba3 gnupg-2.0.20-2.0.21.diff.bz2 Documentation ============= The file gnupg.info has the complete user manual of the system. Separate man pages are included as well; however they have not all the details available in the manual. It is also possible to read the complete manual online in HTML format at http://www.gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at http://www.gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Almost all mail clients support GnuPG-2. Mutt users may want to use the configure option "--enable-gpgme" during build time and put a "set use_crypt_gpgme" in ~/.muttrc to enable S/MIME support along with the reworked OpenPGP support. Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . We also have a dedicated service directory 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 takes up most of their resources. To allow him to continue this work he kindly asks to either purchase a support contract, engage g10 Code 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, administering the servers, spreading the word, or answering questions on the mailing lists. 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 dkg at fifthhorseman.net Tue Aug 20 20:37:29 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 20 Aug 2013 14:37:29 -0400 Subject: PUBKEY_USAGE_AUTH In-Reply-To: <87vc39bmsf.fsf@vigenere.g10code.de> References: <1372817431.3324.4.camel@cfw2.gniibe.org> <87vc39bmsf.fsf@vigenere.g10code.de> Message-ID: <5213B769.5000305@fifthhorseman.net> On 08/13/2013 12:03 PM, Werner Koch wrote: > On Wed, 3 Jul 2013 04:10, gniibe at fsij.org said: >> Does it make sense to add an option like --auth to enable using >> authkey for --sign or --clearsign? Or some flag to enable >> gpgme_op_sign using authkey? > > OpenPGP only says > > 0x20 - This key may be used for authentication. > > Thus, if an OpenPGP signature is part of an authentication system, it > makes sense to allow the use of such a key. > > Anyone with ideas for the best way to tell gpg about this. Shall gpg > only select authkeys then? In terms of GPGME integration an option to > switch to (or allow the use of) authkeys would be the easiest way. Note that some authentication schemes may require decryption instead of signing by the keyholder. So whatever feature is added to gpg to support auth-capable subkeys should probably apply symmetrically to both signing and decryption. as for how to indicate to gpg that the given action is taking place as part of an authentication exchange, i'd be fine with a new --authentication option (and --no-authentication, which would be the default). Do you see any problems with that approach? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Thu Aug 22 09:44:04 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 22 Aug 2013 16:44:04 +0900 Subject: NeuG 0.11 Message-ID: <1377157444.3419.8.camel@cfw2.gniibe.org> NeuG 0.11 was released. NeuG is an implementation of True Random Number Generator based on quantization error of ADC of STM32F103. It is basically intended to be used as a part of Gnuk, but we also have standalone USB CDC-ACM version (you can get random stream from /dev/ttyACM0). Standalone version is useful to feed entropy to /dev/random on GNU/Linux. Its generation speed is >= 50kB/sec, and it's more when connected to USB 2.0 Hub. The output is tested NIST STS 2.1.1 and Dieharder 3.31.1. Highlights are: * Replacement of kernel (thread library) Instead of ChibiOS/RT, we now use Chopstx. * Improved performance The output of random numbers got faster than the previous implementation by 30% or so. * Unsupported targets CQ_STARM, STBEE, STBEE Mini, and STM32_PRIMER2 are not supported in this release, but porting should be easy. Here are some links for NeuG, Gnuk and FST-01 (the hardware). NeuG (under Gnuk Repository): http://gitorious.org/gnuk/neug Gnuk News: http://www.fsij.org/gnuk/ FST-01 introduction: http://www.seeedstudio.com/wiki/index.php?title=FST-01 FST-01 Q&A site: http://no-passwd.net/askbot/questions/ Japanese Documentation for FST-01 and Gnuk Token: http://no-passwd.net/fst-01-gnuk-handbook/index.html Enjoy, -- From christian at quelltextlich.at Thu Aug 22 09:53:17 2013 From: christian at quelltextlich.at (Christian Aistleitner) Date: Thu, 22 Aug 2013 09:53:17 +0200 Subject: [PATCHES] Enable building using GNU Automake 1.13, 1.14 Message-ID: <20130822075317.GA1543@quelltextlich.at> Hi, the attached patches [1] enable building GnuPG and its dependencies using GNU automake 1.13, and 1.14. The attachments are named like PROJECT_BRANCH_PATCH and are essentially three patches: * 0001-Switch-to-non-deprecated-form-of-GNU-Automake-initia.patch Some projects still used a deprecated variant of AM_INIT_AUTOMAKE, which makes updating to GNU automake 1.13+ cumbersome. In order to not mangle different things into a single patch, I put the switch to a not deprecated form of AM_INIT_AUTOMAKE into separate patches. * 0002-Fix-building-with-GNU-Automake-1.13.patch GNU automake 1.13+ defaults to parallel_tests, which fails for our tests. So we force ?serial_tests? for new enough GNU automakes. * 0003-Fix-building-with-GNU-Automake-1.14.patch GNU automake 1.14 made the compile script mandatory for packages compiling C code. So we add the compile script where necessary. Have fun, Christian P.S.: The patches have been tested against: * automake (GNU automake) 1.11.6 * automake (GNU automake) 1.12.2 * automake (GNU automake) 1.13.4 * automake (GNU automake) 1.14 [1] Yes, sending more than one patch per email is not too nice, but they are essentially the same three patches against different projects/branches. Hence, comments to some patch would likely also apply to the other formulations of the patch as well. And splitting the patches into ten separate emails would rather complicate commenting on the patches :-/ If you nevertheless prefer to receive the patches as separate emails, please let me know. -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- From c83f37c0b24671b3afd558f37b0da3b22e35ceef Mon Sep 17 00:00:00 2001 From: Christian Aistleitner Date: Sun, 14 Jul 2013 13:00:19 +0200 Subject: [PATCH] Fix building with GNU Automake 1.13+ * configure.ac: Force serial tests for GNU Automake 1.13+. (serial_tests): New. -- GNU Automake switched the default test harness to parallel beginning with GNU Automake 1.13. Until we upgrade our tests, we force serial-tests beginning with GNU Automake 1.13. This commit is a minor adaption of libguestfs's (GPLv2+) commit a1c89bf03dd432f0e4c8c26fe01fd9b2a50df97e by Richard W.M. Jones. Signed-off-by: Christian Aistleitner --- configure.ac | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 01530e0..88cb4d8 100644 --- a/configure.ac +++ b/configure.ac @@ -66,9 +66,27 @@ VERSION=$PACKAGE_VERSION AC_CONFIG_AUX_DIR([scripts]) AC_CONFIG_SRCDIR([sm/gpgsm.c]) AC_CONFIG_HEADER([config.h]) -# Note: For automake 1.13 add the option -# serial-tests -AM_INIT_AUTOMAKE([dist-bzip2 no-dist-gzip]) + +dnl Initialize automake. automake < 1.12 didn't have serial-tests and +dnl gives an error if it sees this, but for automake >= 1.13 +dnl serial-tests is required so we have to include it. Solution is to +dnl test for the version of automake (by running an external command) +dnl and provide it if necessary. Note we have to do this entirely using +dnl m4 macros since automake queries this macro by running +dnl 'autoconf --trace'. +m4_define([serial_tests], [ + m4_esyscmd([automake --version | awk 'NR==1 { + split ($NF, V_ARR, "."); + V_INT=1000000*V_ARR[1]+1000*V_ARR[2]+V_ARR[3] + if (V_INT >= 1013000) + # GNU Automake is version 1.13 or newer + print "serial-tests"; + }' + ]) +]) + +dnl As we need expansion of the serial_tests macro, do not [quote] it. +AM_INIT_AUTOMAKE([dist-bzip2 no-dist-gzip] serial_tests) AC_CANONICAL_HOST AB_INIT -- 1.8.1.5 -------------- next part -------------- From 1af21fbe6956a6c05a384f5e8a01976e5d2e47e0 Mon Sep 17 00:00:00 2001 From: Christian Aistleitner Date: Sun, 14 Jul 2013 21:51:23 +0200 Subject: [PATCH 1/2] Switch to non-deprecated form of GNU Automake initialization Signed-off-by: Christian Aistleitner --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 702b8d3..f5748a9 100644 --- a/configure.ac +++ b/configure.ac @@ -63,7 +63,7 @@ VERSION=$PACKAGE_VERSION AC_CONFIG_AUX_DIR(scripts) AC_CONFIG_SRCDIR(sm/gpgsm.c) AM_CONFIG_HEADER(config.h) -AM_INIT_AUTOMAKE($PACKAGE, $VERSION) +AM_INIT_AUTOMAKE AC_CANONICAL_HOST AB_INIT -- 1.8.1.5 -------------- next part -------------- From 57c304a4531b08986e508bc632380869788318bb Mon Sep 17 00:00:00 2001 From: Christian Aistleitner Date: Sun, 14 Jul 2013 21:53:27 +0200 Subject: [PATCH 2/2] Fix building with GNU Automake 1.13+ * configure.ac: Force serial tests for GNU Automake 1.13+. (serial_tests): New. -- GNU Automake switched the default test harness to parallel beginning with GNU Automake 1.13. Until we upgrade our tests, we force serial-tests beginning with GNU Automake 1.13. This commit is a minor adaption of libguestfs's (GPLv2+) commit a1c89bf03dd432f0e4c8c26fe01fd9b2a50df97e by Richard W.M. Jones. Signed-off-by: Christian Aistleitner --- configure.ac | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index f5748a9..2ac92ab 100644 --- a/configure.ac +++ b/configure.ac @@ -63,7 +63,27 @@ VERSION=$PACKAGE_VERSION AC_CONFIG_AUX_DIR(scripts) AC_CONFIG_SRCDIR(sm/gpgsm.c) AM_CONFIG_HEADER(config.h) -AM_INIT_AUTOMAKE + +dnl Initialize automake. automake < 1.12 didn't have serial-tests and +dnl gives an error if it sees this, but for automake >= 1.13 +dnl serial-tests is required so we have to include it. Solution is to +dnl test for the version of automake (by running an external command) +dnl and provide it if necessary. Note we have to do this entirely using +dnl m4 macros since automake queries this macro by running +dnl 'autoconf --trace'. +m4_define([serial_tests], [ + m4_esyscmd([automake --version | awk 'NR==1 { + split ($NF, V_ARR, "."); + V_INT=1000000*V_ARR[1]+1000*V_ARR[2]+V_ARR[3] + if (V_INT >= 1013000) + # GNU Automake is version 1.13 or newer + print "serial-tests"; + }' + ]) +]) + +dnl As we need expansion of the serial_tests macro, do not [quote] it. +AM_INIT_AUTOMAKE(serial_tests) AC_CANONICAL_HOST AB_INIT -- 1.8.1.5 -------------- next part -------------- From 6008bd6661379722fa021ff0ec70dc74d45ebd4e Mon Sep 17 00:00:00 2001 From: Christian Aistleitner Date: Sun, 14 Jul 2013 12:36:00 +0200 Subject: [PATCH] Fix building with GNU Automake 1.13+ * configure.ac: Force serial tests for GNU Automake 1.13+. (serial_tests): New. -- GNU Automake switched the default test harness to parallel beginning with GNU Automake 1.13. Until we upgrade our tests, we force serial-tests beginning with GNU Automake 1.13. This commit is a minor adaption of libguestfs's (GPLv2+) commit a1c89bf03dd432f0e4c8c26fe01fd9b2a50df97e by Richard W.M. Jones. Signed-off-by: Christian Aistleitner --- configure.ac | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index de2347f..381fd67 100644 --- a/configure.ac +++ b/configure.ac @@ -70,7 +70,26 @@ AC_SUBST(LIBASSUAN_LT_REVISION) PACKAGE=$PACKAGE_NAME VERSION=$PACKAGE_VERSION -AM_INIT_AUTOMAKE +dnl Initialize automake. automake < 1.12 didn't have serial-tests and +dnl gives an error if it sees this, but for automake >= 1.13 +dnl serial-tests is required so we have to include it. Solution is to +dnl test for the version of automake (by running an external command) +dnl and provide it if necessary. Note we have to do this entirely using +dnl m4 macros since automake queries this macro by running +dnl 'autoconf --trace'. +m4_define([serial_tests], [ + m4_esyscmd([automake --version | awk 'NR==1 { + split ($NF, V_ARR, "."); + V_INT=1000000*V_ARR[1]+1000*V_ARR[2]+V_ARR[3] + if (V_INT >= 1013000) + # GNU Automake is version 1.13 or newer + print "serial-tests"; + }' + ]) +]) + +dnl As we need expansion of the serial_tests macro, do not [quote] it. +AM_INIT_AUTOMAKE(serial_tests) AM_MAINTAINER_MODE AC_CONFIG_SRCDIR(src/assuan.h.in) AC_CONFIG_MACRO_DIR(m4) -- 1.8.1.5 -------------- next part -------------- From e8e37f6be871d84069658d0c48979d7a12395171 Mon Sep 17 00:00:00 2001 From: Christian Aistleitner Date: Sun, 14 Jul 2013 12:50:07 +0200 Subject: [PATCH] Fix building with GNU Automake 1.13+ * configure.ac: Force serial tests for GNU Automake 1.13+. (serial_tests): New. -- GNU Automake switched the default test harness to parallel beginning with GNU Automake 1.13. Until we upgrade our tests, we force serial-tests beginning with GNU Automake 1.13. This commit is a minor adaption of libguestfs's (GPLv2+) commit a1c89bf03dd432f0e4c8c26fe01fd9b2a50df97e by Richard W.M. Jones. Signed-off-by: Christian Aistleitner --- configure.ac | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 13541bb..59f8281 100644 --- a/configure.ac +++ b/configure.ac @@ -73,7 +73,27 @@ PACKAGE=$PACKAGE_NAME VERSION=$PACKAGE_VERSION AC_CONFIG_SRCDIR([src/libgcrypt.vers]) -AM_INIT_AUTOMAKE + +dnl Initialize automake. automake < 1.12 didn't have serial-tests and +dnl gives an error if it sees this, but for automake >= 1.13 +dnl serial-tests is required so we have to include it. Solution is to +dnl test for the version of automake (by running an external command) +dnl and provide it if necessary. Note we have to do this entirely using +dnl m4 macros since automake queries this macro by running +dnl 'autoconf --trace'. +m4_define([serial_tests], [ + m4_esyscmd([automake --version | awk 'NR==1 { + split ($NF, V_ARR, "."); + V_INT=1000000*V_ARR[1]+1000*V_ARR[2]+V_ARR[3] + if (V_INT >= 1013000) + # GNU Automake is version 1.13 or newer + print "serial-tests"; + }' + ]) +]) + +dnl As we need expansion of the serial_tests macro, do not [quote] it. +AM_INIT_AUTOMAKE(serial_tests) AC_CONFIG_HEADER(config.h) AC_CONFIG_MACRO_DIR([m4]) AC_CONFIG_LIBOBJ_DIR([compat]) -- 1.8.1.5 -------------- next part -------------- From cf3a3a6e255aee259e5a4a36efad071994460fa3 Mon Sep 17 00:00:00 2001 From: Christian Aistleitner Date: Sat, 13 Jul 2013 11:49:43 +0200 Subject: [PATCH] Fix building with GNU Automake 1.13+ * configure.ac: Force serial tests for GNU Automake 1.13+. (serial_tests): New. -- GNU Automake switched the default test harness to parallel beginning with GNU Automake 1.13. Until we upgrade our tests, we force serial-tests beginning with GNU Automake 1.13. This commit is a minor adaption of libguestfs's (GPLv2+) commit a1c89bf03dd432f0e4c8c26fe01fd9b2a50df97e by Richard W.M. Jones. Signed-off-by: Christian Aistleitner --- configure.ac | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 04e259b..01e7635 100644 --- a/configure.ac +++ b/configure.ac @@ -64,7 +64,26 @@ VERSION_NUMBER=m4_esyscmd(printf "0x%02x%02x00" mym4_version_major \ mym4_version_minor) AC_SUBST(VERSION_NUMBER) -AM_INIT_AUTOMAKE +dnl Initialize automake. automake < 1.12 didn't have serial-tests and +dnl gives an error if it sees this, but for automake >= 1.13 +dnl serial-tests is required so we have to include it. Solution is to +dnl test for the version of automake (by running an external command) +dnl and provide it if necessary. Note we have to do this entirely using +dnl m4 macros since automake queries this macro by running +dnl 'autoconf --trace'. +m4_define([serial_tests], [ + m4_esyscmd([automake --version | awk 'NR==1 { + split ($NF, V_ARR, "."); + V_INT=1000000*V_ARR[1]+1000*V_ARR[2]+V_ARR[3] + if (V_INT >= 1013000) + # GNU Automake is version 1.13 or newer + print "serial-tests"; + }' + ]) +]) + +dnl As we need expansion of the serial_tests macro, do not [quote] it. +AM_INIT_AUTOMAKE(serial_tests) AM_MAINTAINER_MODE AC_CONFIG_SRCDIR([src/err-sources.h.in]) AC_CONFIG_HEADER([config.h]) -- 1.8.1.5 -------------- next part -------------- From bfb43b855fa2023a24a3b045c613274eef6bfd9d Mon Sep 17 00:00:00 2001 From: Christian Aistleitner Date: Sun, 14 Jul 2013 12:26:36 +0200 Subject: [PATCH 1/2] Switch to non-deprecated form of GNU Automake initialization -- Signed-off-by: Christian Aistleitner --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index bd650c7..cbb63f4 100644 --- a/configure.ac +++ b/configure.ac @@ -73,7 +73,7 @@ VERSION=$PACKAGE_VERSION AC_CONFIG_SRCDIR([src/npth.c]) AC_CONFIG_HEADERS([config.h]) AC_CONFIG_MACRO_DIR([m4]) -AM_INIT_AUTOMAKE($PACKAGE, $VERSION) +AM_INIT_AUTOMAKE AM_MAINTAINER_MODE AC_CANONICAL_HOST -- 1.8.1.5 -------------- next part -------------- From 13f3b8ec618d027b83b99bc1678394f26e32bac0 Mon Sep 17 00:00:00 2001 From: Christian Aistleitner Date: Sun, 14 Jul 2013 12:31:03 +0200 Subject: [PATCH 2/2] Fix building with GNU Automake 1.13+ * configure.ac: Force serial tests for GNU Automake 1.13+. (serial_tests): New. -- GNU Automake switched the default test harness to parallel beginning with GNU Automake 1.13. Until we upgrade our tests, we force serial-tests beginning with GNU Automake 1.13. This commit is a minor adaption of libguestfs's (GPLv2+) commit a1c89bf03dd432f0e4c8c26fe01fd9b2a50df97e by Richard W.M. Jones. Signed-off-by: Christian Aistleitner --- configure.ac | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index cbb63f4..9cf8f59 100644 --- a/configure.ac +++ b/configure.ac @@ -73,7 +73,27 @@ VERSION=$PACKAGE_VERSION AC_CONFIG_SRCDIR([src/npth.c]) AC_CONFIG_HEADERS([config.h]) AC_CONFIG_MACRO_DIR([m4]) -AM_INIT_AUTOMAKE + +dnl Initialize automake. automake < 1.12 didn't have serial-tests and +dnl gives an error if it sees this, but for automake >= 1.13 +dnl serial-tests is required so we have to include it. Solution is to +dnl test for the version of automake (by running an external command) +dnl and provide it if necessary. Note we have to do this entirely using +dnl m4 macros since automake queries this macro by running +dnl 'autoconf --trace'. +m4_define([serial_tests], [ + m4_esyscmd([automake --version | awk 'NR==1 { + split ($NF, V_ARR, "."); + V_INT=1000000*V_ARR[1]+1000*V_ARR[2]+V_ARR[3] + if (V_INT >= 1013000) + # GNU Automake is version 1.13 or newer + print "serial-tests"; + }' + ]) +]) + +dnl As we need expansion of the serial_tests macro, do not [quote] it. +AM_INIT_AUTOMAKE(serial_tests) AM_MAINTAINER_MODE AC_CANONICAL_HOST -- 1.8.1.5 -------------- next part -------------- From 290c6c8e956aa948276f6257964b575518fa4a9b Mon Sep 17 00:00:00 2001 From: Christian Aistleitner Date: Wed, 21 Aug 2013 14:56:25 +0200 Subject: [PATCH] Fix building with GNU Automake 1.14 * compile: New. Taken from GNU Automake 1.14. -- Signed-off-by: Christian Aistleitner --- compile | 347 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 347 insertions(+) create mode 100755 compile diff --git a/compile b/compile new file mode 100755 index 0000000..531136b --- /dev/null +++ b/compile @@ -0,0 +1,347 @@ +#! /bin/sh +# Wrapper for compilers which do not understand '-c -o'. + +scriptversion=2012-10-14.11; # UTC + +# Copyright (C) 1999-2013 Free Software Foundation, Inc. +# Written by Tom Tromey . +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2, or (at your option) +# any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +# As a special exception to the GNU General Public License, if you +# distribute this file as part of a program that contains a +# configuration script generated by Autoconf, you may include it under +# the same distribution terms that you use for the rest of that program. + +# This file is maintained in Automake, please report +# bugs to or send patches to +# . + +nl=' +' + +# We need space, tab and new line, in precisely that order. Quoting is +# there to prevent tools from complaining about whitespace usage. +IFS=" "" $nl" + +file_conv= + +# func_file_conv build_file lazy +# Convert a $build file to $host form and store it in $file +# Currently only supports Windows hosts. If the determined conversion +# type is listed in (the comma separated) LAZY, no conversion will +# take place. +func_file_conv () +{ + file=$1 + case $file in + / | /[!/]*) # absolute file, and not a UNC file + if test -z "$file_conv"; then + # lazily determine how to convert abs files + case `uname -s` in + MINGW*) + file_conv=mingw + ;; + CYGWIN*) + file_conv=cygwin + ;; + *) + file_conv=wine + ;; + esac + fi + case $file_conv/,$2, in + *,$file_conv,*) + ;; + mingw/*) + file=`cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'` + ;; + cygwin/*) + file=`cygpath -m "$file" || echo "$file"` + ;; + wine/*) + file=`winepath -w "$file" || echo "$file"` + ;; + esac + ;; + esac +} + +# func_cl_dashL linkdir +# Make cl look for libraries in LINKDIR +func_cl_dashL () +{ + func_file_conv "$1" + if test -z "$lib_path"; then + lib_path=$file + else + lib_path="$lib_path;$file" + fi + linker_opts="$linker_opts -LIBPATH:$file" +} + +# func_cl_dashl library +# Do a library search-path lookup for cl +func_cl_dashl () +{ + lib=$1 + found=no + save_IFS=$IFS + IFS=';' + for dir in $lib_path $LIB + do + IFS=$save_IFS + if $shared && test -f "$dir/$lib.dll.lib"; then + found=yes + lib=$dir/$lib.dll.lib + break + fi + if test -f "$dir/$lib.lib"; then + found=yes + lib=$dir/$lib.lib + break + fi + if test -f "$dir/lib$lib.a"; then + found=yes + lib=$dir/lib$lib.a + break + fi + done + IFS=$save_IFS + + if test "$found" != yes; then + lib=$lib.lib + fi +} + +# func_cl_wrapper cl arg... +# Adjust compile command to suit cl +func_cl_wrapper () +{ + # Assume a capable shell + lib_path= + shared=: + linker_opts= + for arg + do + if test -n "$eat"; then + eat= + else + case $1 in + -o) + # configure might choose to run compile as 'compile cc -o foo foo.c'. + eat=1 + case $2 in + *.o | *.[oO][bB][jJ]) + func_file_conv "$2" + set x "$@" -Fo"$file" + shift + ;; + *) + func_file_conv "$2" + set x "$@" -Fe"$file" + shift + ;; + esac + ;; + -I) + eat=1 + func_file_conv "$2" mingw + set x "$@" -I"$file" + shift + ;; + -I*) + func_file_conv "${1#-I}" mingw + set x "$@" -I"$file" + shift + ;; + -l) + eat=1 + func_cl_dashl "$2" + set x "$@" "$lib" + shift + ;; + -l*) + func_cl_dashl "${1#-l}" + set x "$@" "$lib" + shift + ;; + -L) + eat=1 + func_cl_dashL "$2" + ;; + -L*) + func_cl_dashL "${1#-L}" + ;; + -static) + shared=false + ;; + -Wl,*) + arg=${1#-Wl,} + save_ifs="$IFS"; IFS=',' + for flag in $arg; do + IFS="$save_ifs" + linker_opts="$linker_opts $flag" + done + IFS="$save_ifs" + ;; + -Xlinker) + eat=1 + linker_opts="$linker_opts $2" + ;; + -*) + set x "$@" "$1" + shift + ;; + *.cc | *.CC | *.cxx | *.CXX | *.[cC]++) + func_file_conv "$1" + set x "$@" -Tp"$file" + shift + ;; + *.c | *.cpp | *.CPP | *.lib | *.LIB | *.Lib | *.OBJ | *.obj | *.[oO]) + func_file_conv "$1" mingw + set x "$@" "$file" + shift + ;; + *) + set x "$@" "$1" + shift + ;; + esac + fi + shift + done + if test -n "$linker_opts"; then + linker_opts="-link$linker_opts" + fi + exec "$@" $linker_opts + exit 1 +} + +eat= + +case $1 in + '') + echo "$0: No command. Try '$0 --help' for more information." 1>&2 + exit 1; + ;; + -h | --h*) + cat <<\EOF +Usage: compile [--help] [--version] PROGRAM [ARGS] + +Wrapper for compilers which do not understand '-c -o'. +Remove '-o dest.o' from ARGS, run PROGRAM with the remaining +arguments, and rename the output as expected. + +If you are trying to build a whole package this is not the +right script to run: please start by reading the file 'INSTALL'. + +Report bugs to . +EOF + exit $? + ;; + -v | --v*) + echo "compile $scriptversion" + exit $? + ;; + cl | *[/\\]cl | cl.exe | *[/\\]cl.exe ) + func_cl_wrapper "$@" # Doesn't return... + ;; +esac + +ofile= +cfile= + +for arg +do + if test -n "$eat"; then + eat= + else + case $1 in + -o) + # configure might choose to run compile as 'compile cc -o foo foo.c'. + # So we strip '-o arg' only if arg is an object. + eat=1 + case $2 in + *.o | *.obj) + ofile=$2 + ;; + *) + set x "$@" -o "$2" + shift + ;; + esac + ;; + *.c) + cfile=$1 + set x "$@" "$1" + shift + ;; + *) + set x "$@" "$1" + shift + ;; + esac + fi + shift +done + +if test -z "$ofile" || test -z "$cfile"; then + # If no '-o' option was seen then we might have been invoked from a + # pattern rule where we don't need one. That is ok -- this is a + # normal compilation that the losing compiler can handle. If no + # '.c' file was seen then we are probably linking. That is also + # ok. + exec "$@" +fi + +# Name of file we expect compiler to create. +cofile=`echo "$cfile" | sed 's|^.*[\\/]||; s|^[a-zA-Z]:||; s/\.c$/.o/'` + +# Create the lock directory. +# Note: use '[/\\:.-]' here to ensure that we don't use the same name +# that we are using for the .o file. Also, base the name on the expected +# object file name, since that is what matters with a parallel build. +lockdir=`echo "$cofile" | sed -e 's|[/\\:.-]|_|g'`.d +while true; do + if mkdir "$lockdir" >/dev/null 2>&1; then + break + fi + sleep 1 +done +# FIXME: race condition here if user kills between mkdir and trap. +trap "rmdir '$lockdir'; exit 1" 1 2 15 + +# Run the compile. +"$@" +ret=$? + +if test -f "$cofile"; then + test "$cofile" = "$ofile" || mv "$cofile" "$ofile" +elif test -f "${cofile}bj"; then + test "${cofile}bj" = "$ofile" || mv "${cofile}bj" "$ofile" +fi + +rmdir "$lockdir" +exit $ret + +# Local Variables: +# mode: shell-script +# sh-indentation: 2 +# eval: (add-hook 'write-file-hooks 'time-stamp) +# time-stamp-start: "scriptversion=" +# time-stamp-format: "%:y-%02m-%02d.%02H" +# time-stamp-time-zone: "UTC" +# time-stamp-end: "; # UTC" +# End: -- 1.8.1.5 -------------- next part -------------- From 290c6c8e956aa948276f6257964b575518fa4a9b Mon Sep 17 00:00:00 2001 From: Christian Aistleitner Date: Wed, 21 Aug 2013 14:56:25 +0200 Subject: [PATCH] Fix building with GNU Automake 1.14 * compile: New. Taken from GNU Automake 1.14. -- Signed-off-by: Christian Aistleitner --- compile | 347 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 347 insertions(+) create mode 100755 compile diff --git a/compile b/compile new file mode 100755 index 0000000..531136b --- /dev/null +++ b/compile @@ -0,0 +1,347 @@ +#! /bin/sh +# Wrapper for compilers which do not understand '-c -o'. + +scriptversion=2012-10-14.11; # UTC + +# Copyright (C) 1999-2013 Free Software Foundation, Inc. +# Written by Tom Tromey . +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2, or (at your option) +# any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +# As a special exception to the GNU General Public License, if you +# distribute this file as part of a program that contains a +# configuration script generated by Autoconf, you may include it under +# the same distribution terms that you use for the rest of that program. + +# This file is maintained in Automake, please report +# bugs to or send patches to +# . + +nl=' +' + +# We need space, tab and new line, in precisely that order. Quoting is +# there to prevent tools from complaining about whitespace usage. +IFS=" "" $nl" + +file_conv= + +# func_file_conv build_file lazy +# Convert a $build file to $host form and store it in $file +# Currently only supports Windows hosts. If the determined conversion +# type is listed in (the comma separated) LAZY, no conversion will +# take place. +func_file_conv () +{ + file=$1 + case $file in + / | /[!/]*) # absolute file, and not a UNC file + if test -z "$file_conv"; then + # lazily determine how to convert abs files + case `uname -s` in + MINGW*) + file_conv=mingw + ;; + CYGWIN*) + file_conv=cygwin + ;; + *) + file_conv=wine + ;; + esac + fi + case $file_conv/,$2, in + *,$file_conv,*) + ;; + mingw/*) + file=`cmd //C echo "$file " | sed -e 's/"\(.*\) " *$/\1/'` + ;; + cygwin/*) + file=`cygpath -m "$file" || echo "$file"` + ;; + wine/*) + file=`winepath -w "$file" || echo "$file"` + ;; + esac + ;; + esac +} + +# func_cl_dashL linkdir +# Make cl look for libraries in LINKDIR +func_cl_dashL () +{ + func_file_conv "$1" + if test -z "$lib_path"; then + lib_path=$file + else + lib_path="$lib_path;$file" + fi + linker_opts="$linker_opts -LIBPATH:$file" +} + +# func_cl_dashl library +# Do a library search-path lookup for cl +func_cl_dashl () +{ + lib=$1 + found=no + save_IFS=$IFS + IFS=';' + for dir in $lib_path $LIB + do + IFS=$save_IFS + if $shared && test -f "$dir/$lib.dll.lib"; then + found=yes + lib=$dir/$lib.dll.lib + break + fi + if test -f "$dir/$lib.lib"; then + found=yes + lib=$dir/$lib.lib + break + fi + if test -f "$dir/lib$lib.a"; then + found=yes + lib=$dir/lib$lib.a + break + fi + done + IFS=$save_IFS + + if test "$found" != yes; then + lib=$lib.lib + fi +} + +# func_cl_wrapper cl arg... +# Adjust compile command to suit cl +func_cl_wrapper () +{ + # Assume a capable shell + lib_path= + shared=: + linker_opts= + for arg + do + if test -n "$eat"; then + eat= + else + case $1 in + -o) + # configure might choose to run compile as 'compile cc -o foo foo.c'. + eat=1 + case $2 in + *.o | *.[oO][bB][jJ]) + func_file_conv "$2" + set x "$@" -Fo"$file" + shift + ;; + *) + func_file_conv "$2" + set x "$@" -Fe"$file" + shift + ;; + esac + ;; + -I) + eat=1 + func_file_conv "$2" mingw + set x "$@" -I"$file" + shift + ;; + -I*) + func_file_conv "${1#-I}" mingw + set x "$@" -I"$file" + shift + ;; + -l) + eat=1 + func_cl_dashl "$2" + set x "$@" "$lib" + shift + ;; + -l*) + func_cl_dashl "${1#-l}" + set x "$@" "$lib" + shift + ;; + -L) + eat=1 + func_cl_dashL "$2" + ;; + -L*) + func_cl_dashL "${1#-L}" + ;; + -static) + shared=false + ;; + -Wl,*) + arg=${1#-Wl,} + save_ifs="$IFS"; IFS=',' + for flag in $arg; do + IFS="$save_ifs" + linker_opts="$linker_opts $flag" + done + IFS="$save_ifs" + ;; + -Xlinker) + eat=1 + linker_opts="$linker_opts $2" + ;; + -*) + set x "$@" "$1" + shift + ;; + *.cc | *.CC | *.cxx | *.CXX | *.[cC]++) + func_file_conv "$1" + set x "$@" -Tp"$file" + shift + ;; + *.c | *.cpp | *.CPP | *.lib | *.LIB | *.Lib | *.OBJ | *.obj | *.[oO]) + func_file_conv "$1" mingw + set x "$@" "$file" + shift + ;; + *) + set x "$@" "$1" + shift + ;; + esac + fi + shift + done + if test -n "$linker_opts"; then + linker_opts="-link$linker_opts" + fi + exec "$@" $linker_opts + exit 1 +} + +eat= + +case $1 in + '') + echo "$0: No command. Try '$0 --help' for more information." 1>&2 + exit 1; + ;; + -h | --h*) + cat <<\EOF +Usage: compile [--help] [--version] PROGRAM [ARGS] + +Wrapper for compilers which do not understand '-c -o'. +Remove '-o dest.o' from ARGS, run PROGRAM with the remaining +arguments, and rename the output as expected. + +If you are trying to build a whole package this is not the +right script to run: please start by reading the file 'INSTALL'. + +Report bugs to . +EOF + exit $? + ;; + -v | --v*) + echo "compile $scriptversion" + exit $? + ;; + cl | *[/\\]cl | cl.exe | *[/\\]cl.exe ) + func_cl_wrapper "$@" # Doesn't return... + ;; +esac + +ofile= +cfile= + +for arg +do + if test -n "$eat"; then + eat= + else + case $1 in + -o) + # configure might choose to run compile as 'compile cc -o foo foo.c'. + # So we strip '-o arg' only if arg is an object. + eat=1 + case $2 in + *.o | *.obj) + ofile=$2 + ;; + *) + set x "$@" -o "$2" + shift + ;; + esac + ;; + *.c) + cfile=$1 + set x "$@" "$1" + shift + ;; + *) + set x "$@" "$1" + shift + ;; + esac + fi + shift +done + +if test -z "$ofile" || test -z "$cfile"; then + # If no '-o' option was seen then we might have been invoked from a + # pattern rule where we don't need one. That is ok -- this is a + # normal compilation that the losing compiler can handle. If no + # '.c' file was seen then we are probably linking. That is also + # ok. + exec "$@" +fi + +# Name of file we expect compiler to create. +cofile=`echo "$cfile" | sed 's|^.*[\\/]||; s|^[a-zA-Z]:||; s/\.c$/.o/'` + +# Create the lock directory. +# Note: use '[/\\:.-]' here to ensure that we don't use the same name +# that we are using for the .o file. Also, base the name on the expected +# object file name, since that is what matters with a parallel build. +lockdir=`echo "$cofile" | sed -e 's|[/\\:.-]|_|g'`.d +while true; do + if mkdir "$lockdir" >/dev/null 2>&1; then + break + fi + sleep 1 +done +# FIXME: race condition here if user kills between mkdir and trap. +trap "rmdir '$lockdir'; exit 1" 1 2 15 + +# Run the compile. +"$@" +ret=$? + +if test -f "$cofile"; then + test "$cofile" = "$ofile" || mv "$cofile" "$ofile" +elif test -f "${cofile}bj"; then + test "${cofile}bj" = "$ofile" || mv "${cofile}bj" "$ofile" +fi + +rmdir "$lockdir" +exit $ret + +# Local Variables: +# mode: shell-script +# sh-indentation: 2 +# eval: (add-hook 'write-file-hooks 'time-stamp) +# time-stamp-start: "scriptversion=" +# time-stamp-format: "%:y-%02m-%02d.%02H" +# time-stamp-time-zone: "UTC" +# time-stamp-end: "; # UTC" +# End: -- 1.8.1.5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From wk at gnupg.org Fri Aug 23 14:21:37 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 23 Aug 2013 14:21:37 +0200 Subject: [PATCHES] Enable building using GNU Automake 1.13, 1.14 In-Reply-To: <20130822075317.GA1543@quelltextlich.at> (Christian Aistleitner's message of "Thu, 22 Aug 2013 09:53:17 +0200") References: <20130822075317.GA1543@quelltextlich.at> Message-ID: <87vc2wzjfy.fsf@vigenere.g10code.de> On Thu, 22 Aug 2013 09:53, christian at quelltextlich.at said: > the attached patches [1] enable building GnuPG and its dependencies > using GNU automake 1.13, and 1.14. We need to stick to 1.11 for some more time. One of the reasons is: # Note: For automake 1.13 add the option # serial-tests AM_INIT_AUTOMAKE([dist-bzip2 no-dist-gzip]) The current automake does not support this option and for unknown reasons the default changed in newer automakes. I see that you hacked around that problem. However, requiring hacks to support newer automake versions is clearly an automake problem which they should solbe and not hundreds of other projects. After all automake is there to make maintainig software easier and not harder. Also, experience of the last ~15 years has shown that major changes in autotools introduced lots of problems for non-mainstream platforms or non-default system configurations. Thus I believe it is better to delay a migration to newer versions. I almost always follow deprecated warnings of autotools before doing a release - the serial tests regression prohibited it this time. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From christian at quelltextlich.at Sun Aug 25 14:57:08 2013 From: christian at quelltextlich.at (Christian Aistleitner) Date: Sun, 25 Aug 2013 14:57:08 +0200 Subject: [PATCHES] Enable building using GNU Automake 1.13, 1.14 In-Reply-To: <87vc2wzjfy.fsf@vigenere.g10code.de> References: <20130822075317.GA1543@quelltextlich.at> <87vc2wzjfy.fsf@vigenere.g10code.de> Message-ID: <20130825125708.GA4406@quelltextlich.at> Hi, On Fri, Aug 23, 2013 at 02:21:37PM +0200, Werner Koch wrote: > [ GNU automake's upstream approach to serial-tests is not nice ] > However, requiring hacks to support newer automake > versions is clearly an automake problem which they should solbe [...] Yes. Full ACK. The newer automake releases are indeed irritating at best. And yes, automake upstream should fix the issue. However, we cannot hide from the fact that newer automakes are out in the wild and get used just now. To list only a few distributions: * Arch Linux is on 1.14. * Linux From Scratch is on 1.13.1. * Fedora Core 19 is on 1.13.2. But actually, the motivation for the patches stems from Debian Jessie / Sid users that were asking me about why the GnuPG ecosystem does not compile for them. Building GnuPG and its relevant dependencies by hand is already hard. And I fully understand that this hurdle cannot be torn down at once for free. However, I see little use in trying to keep those hurdles up just to allow to build up pressure against automake. That said, I am of course fine with you deciding GnuPG will stay automake <=1.12 only. Have fun, Christian P.S.: I assume that other, similar patches (e.g.: Fixing compilation for Texinfo >=5) will go down the same road, which I am totally fine with. But ... is it nevertheless ok to post such patches to this list, so people can at least find patches to help them build GnuPG and related packages with up-to-date build systems? -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From abel at guardianproject.info Mon Aug 26 13:15:47 2013 From: abel at guardianproject.info (Abel Luck) Date: Mon, 26 Aug 2013 11:15:47 +0000 Subject: how to debug --gen-key on Android In-Reply-To: <877gj7l5i0.fsf@vigenere.g10code.de> References: <5182CDD3.2010308@guardianproject.info> <87mwsdot2c.fsf@vigenere.g10code.de> <518BF4D6.4000501@guardianproject.info> <877gj7l5i0.fsf@vigenere.g10code.de> Message-ID: <521B38E3.1050206@guardianproject.info> Werner Koch: > On Thu, 9 May 2013 21:11, abel at guardianproject.info said: >> I can't seem to get log_[info,error] output from libgrcrypt when >> debugging the genkey code in agent. >> >> Is there a way to make gpg-agent setup libgcrypt to use the same >> --log-file as itself? > > It does by calling setup_libgcrypt_logging quite early. If you are > looking for progress output, it is indeed not enabled. gpg has > provisions to handle PROGRESS status messages, but none are coming for > libgcrypt. Thus we need to call gcry_set_progress_handler also in > gpg-agent with a handler to emit PROGRESS status lines. > Any update on this? Getting progress feedback via gpgme when doing crypto operations (specifically keygen, signing, and encryption) would be super useful. ~abel From abel at guardianproject.info Mon Aug 26 13:22:28 2013 From: abel at guardianproject.info (Abel Luck) Date: Mon, 26 Aug 2013 11:22:28 +0000 Subject: pinentry for android patches Message-ID: <521B3A74.2000805@guardianproject.info> Hi, As part of the GnuPG to Android port, we've written an android specific pinentry. [0] This pinentry is actually not usable standalone. That is, the code in the android/ dir is not sufficient for pinentry to work on Android. It requires a java helper running in an Android app to handle the GUI operations. This is currently implemented in our Gnupg for Android application [1]. Due to the structure of Android apps and the security model, this java portion of pinentry must reside within an Android app and cannot be included in the pinentry repo itself. We would like to contribute the pinentry to the project however, as it is a valuable piece of work (well, we spent a long time on it). i. Would you accept this new pinentry into the main repo? ii. Would you like to preserve the commit history as it exists, or shall we create one big patch? Cheers! ~abel [0]: https://github.com/guardianproject/pinentry [1]: https://github.com/guardianproject/gnupg-for-android -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Aug 26 15:21:43 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Aug 2013 15:21:43 +0200 Subject: [PATCHES] Enable building using GNU Automake 1.13, 1.14 In-Reply-To: <20130825125708.GA4406@quelltextlich.at> (Christian Aistleitner's message of "Sun, 25 Aug 2013 14:57:08 +0200") References: <20130822075317.GA1543@quelltextlich.at> <87vc2wzjfy.fsf@vigenere.g10code.de> <20130825125708.GA4406@quelltextlich.at> Message-ID: <87ob8kwpso.fsf@vigenere.g10code.de> On Sun, 25 Aug 2013 14:57, christian at quelltextlich.at said: > But actually, the motivation for the patches stems from Debian > Jessie / Sid users that were asking me about why the GnuPG ecosystem > does not compile for them. AFAICS, Sid's latest Automake version is 1.11. In any case README.GIT describes how to use an older autotools version. For example: AUTOMAKE_SUFFIX=1.11 ./autogen.sh > Building GnuPG and its relevant dependencies by hand is already > hard. And I fully understand that this hurdle cannot be torn down at > once for free. Well, time to update the scripts/gpg-w32-dev/ speeo scripts to git and tell people that they are also useful for Unix. > P.S.: I assume that other, similar patches (e.g.: Fixing compilation > for Texinfo >=5) will go down the same road, which I am totally fine I fear that the changes to texinfo which - to what I know - made it again real slow are enough of a reason to stay with the old texinfo for now. Eventually we need to add index creating and function name templates to org-mode and switch the docs over to org-mode. > with. But ... is it nevertheless ok to post such patches to this list, > so people can at least find patches to help them build GnuPG and Sure. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Aug 26 17:53:05 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Aug 2013 17:53:05 +0200 Subject: how to debug --gen-key on Android In-Reply-To: <521B38E3.1050206@guardianproject.info> (Abel Luck's message of "Mon, 26 Aug 2013 11:15:47 +0000") References: <5182CDD3.2010308@guardianproject.info> <87mwsdot2c.fsf@vigenere.g10code.de> <518BF4D6.4000501@guardianproject.info> <877gj7l5i0.fsf@vigenere.g10code.de> <521B38E3.1050206@guardianproject.info> Message-ID: <8738pwwise.fsf@vigenere.g10code.de> On Mon, 26 Aug 2013 13:15, abel at guardianproject.info said: >> libgcrypt. Thus we need to call gcry_set_progress_handler also in >> gpg-agent with a handler to emit PROGRESS status lines. >> > > Any update on this? No, I forgot about this. Do we have a bug tracker item? > Getting progress feedback via gpgme when doing crypto operations > (specifically keygen, signing, and encryption) would be super useful. Yeah. I recently realized that GPA has a progress bar but it is does not move either. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Aug 26 17:55:43 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Aug 2013 17:55:43 +0200 Subject: pinentry for android patches In-Reply-To: <521B3A74.2000805@guardianproject.info> (Abel Luck's message of "Mon, 26 Aug 2013 11:22:28 +0000") References: <521B3A74.2000805@guardianproject.info> Message-ID: <87y57ov43k.fsf@vigenere.g10code.de> On Mon, 26 Aug 2013 13:22, abel at guardianproject.info said: > i. Would you accept this new pinentry into the main repo? Sure. > ii. Would you like to preserve the commit history as it exists, or shall > we create one big patch? Given that is is probably not yet in wide use the commit history does not make much sense. If there are any interesting remarks, you may want to put them in the final commit. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue Aug 27 03:14:09 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 27 Aug 2013 10:14:09 +0900 Subject: scd: fix for Vega Alpha reader Message-ID: <1377566049.3851.2.camel@cfw2.gniibe.org> This is a fix for Vega Alpha reader. The length of command was wrong. The card may be inactive or there may be no card yet, and we need to handle those cases. This is an obvious fix. I will commit this change to both of master and STABLE-BRANCH-2-0. diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index 8c91767..3376be0 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -1534,6 +1534,7 @@ ccid_vendor_specific_init (ccid_driver_t handle) { if (handle->id_vendor == VENDOR_VEGA && handle->id_product == VEGA_ALPHA) { + int r; /* * Vega alpha has a feature to show retry counter on the pinpad * display. But it assumes that the card returns the value of @@ -1542,9 +1543,12 @@ ccid_vendor_specific_init (ccid_driver_t handle) * VERIFY command with empty data. This vendor specific command * sequence is to disable the feature. */ - const unsigned char cmd[] = "\xb5\x01\x00\x03\x00"; + const unsigned char cmd[] = { '\xb5', '\x01', '\x00', '\x03', '\x00' }; - return send_escape_cmd (handle, cmd, sizeof (cmd), NULL, 0, NULL); + r = send_escape_cmd (handle, cmd, sizeof (cmd), NULL, 0, NULL); + if (r != 0 && r != CCID_DRIVER_ERR_CARD_INACTIVE + && r != CCID_DRIVER_ERR_NO_CARD) + return r; } return 0; -- From gniibe at fsij.org Tue Aug 27 03:28:22 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 27 Aug 2013 10:28:22 +0900 Subject: scd: fix parsing login-data DO Message-ID: <1377566902.3851.4.camel@cfw2.gniibe.org> Reviewing my change again, I fixed coding mistake. The code was wrong, although it worked somehow. I'm going to commit this fix to both of master and STABLE-BRANCH-2-0. * scd/app-openpgp.c (parse_login_data): Release RELPTR. Fix parsing. diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 673570d..011c248 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -660,7 +660,11 @@ parse_login_data (app_t app) if (*buffer == '\n') break; if (buflen < 2 || buffer[1] != '\x14') - return; /* No control sequences. */ + { + xfree (relptr); + return; /* No control sequences. */ + } + buflen--; buffer++; do @@ -707,14 +711,11 @@ parse_login_data (app_t app) m = strtol (q, &q, 10); } - buffer = q; if (buflen < ((unsigned char *)q - buffer)) - { - buflen = 0; - break; - } - else - buflen -= ((unsigned char *)q - buffer); + break; + + buflen -= ((unsigned char *)q - buffer); + buffer = q; if (buflen && !(*buffer == '\n' || *buffer == '\x18')) goto next; @@ -725,11 +726,11 @@ parse_login_data (app_t app) } } next: - for (; buflen && *buffer != '\x18'; buflen--, buffer++) - if (*buffer == '\n') - buflen = 1; + /* Skip to FS (0x18) or LF (\n). */ + for (; buflen && *buffer != '\x18' && *buffer != '\n'; buflen--) + buffer++; } - while (buflen); + while (buflen && *buffer != '\n'); xfree (relptr); } -- From gniibe at fsij.org Tue Aug 27 03:40:03 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 27 Aug 2013 10:40:03 +0900 Subject: scd: PC/SC pinpad input improvement Message-ID: <1377567603.3851.6.camel@cfw2.gniibe.org> This is the change to support pinpad input by PC/SC better. In this patch, we now have the function pcsc_vendor_specific_init, which examines feature and PCSCv2_PART10_PROPERTY. There, we can do special thing like for the one of Vega Alpha. Besides, I found that bNumberMessage=0xff (default) doesn't work well for some readers. So, I think that it is good to have specific number. This is tested for my readers (master and STABLE-BRANCH-2-0), but more tests are needed. diff --git a/scd/apdu.c b/scd/apdu.c index e05869f..203fb62 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -118,6 +118,8 @@ struct reader_table_s { pcsc_dword_t protocol; pcsc_dword_t verify_ioctl; pcsc_dword_t modify_ioctl; + int pinmin; + int pinmax; #ifdef NEED_PCSC_WRAPPER int req_fd; int rsp_fd; @@ -135,6 +137,9 @@ struct reader_table_s { int status; int is_t0; /* True if we know that we are running T=0. */ int is_spr532; /* True if we know that the reader is a SPR532. */ + int pinpad_varlen_supported; /* True if we know that the reader + supports variable length pinpad + input. */ unsigned char atr[33]; size_t atrlen; /* A zero length indicates that the ATR has not yet been read; i.e. the card is not @@ -244,8 +249,17 @@ static char (* DLSTDCALL CT_close) (unsigned short ctn); #endif #define CM_IOCTL_GET_FEATURE_REQUEST SCARD_CTL_CODE(3400) +#define CM_IOCTL_VENDOR_IFD_EXCHANGE SCARD_CTL_CODE(1) #define FEATURE_VERIFY_PIN_DIRECT 0x06 #define FEATURE_MODIFY_PIN_DIRECT 0x07 +#define FEATURE_GET_TLV_PROPERTIES 0x12 + +#define PCSCv2_PART10_PROPERTY_bEntryValidationCondition 2 +#define PCSCv2_PART10_PROPERTY_bTimeOut2 3 +#define PCSCv2_PART10_PROPERTY_bMinPINSize 6 +#define PCSCv2_PART10_PROPERTY_bMaxPINSize 7 +#define PCSCv2_PART10_PROPERTY_wIdVendor 11 +#define PCSCv2_PART10_PROPERTY_wIdProduct 12 /* The PC/SC error is defined as a long as per specs. Due to left @@ -400,6 +414,7 @@ new_reader_slot (void) reader_table[reader].last_status = 0; reader_table[reader].is_t0 = 1; reader_table[reader].is_spr532 = 0; + reader_table[reader].pinpad_varlen_supported = 0; #ifdef NEED_PCSC_WRAPPER reader_table[reader].pcsc.req_fd = -1; reader_table[reader].pcsc.rsp_fd = -1; @@ -407,6 +422,8 @@ new_reader_slot (void) #endif reader_table[reader].pcsc.verify_ioctl = 0; reader_table[reader].pcsc.modify_ioctl = 0; + reader_table[reader].pcsc.pinmin = -1; + reader_table[reader].pcsc.pinmax = -1; return reader; } @@ -1676,6 +1693,120 @@ reset_pcsc_reader (int slot) } +/* Examine reader specific parameters and initialize. This is mostly + for pinpad input. Called at opening the connection to the reader. */ +static int +pcsc_vendor_specific_init (int slot) +{ + unsigned char buf[256]; + pcsc_dword_t len; + int sw; + int vendor = 0; + int product = 0; + pcsc_dword_t get_tlv_ioctl = (pcsc_dword_t)-1; + unsigned char *p; + + len = sizeof (buf); + sw = control_pcsc (slot, CM_IOCTL_GET_FEATURE_REQUEST, NULL, 0, buf, &len); + if (sw) + { + log_error ("pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: %d\n", + sw); + return SW_NOT_SUPPORTED; + } + else + { + p = buf; + while (p < buf + len) + { + unsigned char code = *p++; + int l = *p++; + unsigned int v = 0; + + if (l == 1) + v = p[0]; + else if (l == 2) + v = ((p[0] << 8) | p[1]); + else if (l == 4) + v = ((p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3]); + + if (code == FEATURE_VERIFY_PIN_DIRECT) + reader_table[slot].pcsc.verify_ioctl = v; + else if (code == FEATURE_MODIFY_PIN_DIRECT) + reader_table[slot].pcsc.modify_ioctl = v; + else if (code == FEATURE_GET_TLV_PROPERTIES) + get_tlv_ioctl = v; + + if (DBG_CARD_IO) + log_debug ("feature: code=%02X, len=%d, v=%02X\n", code, l, v); + + p += l; + } + } + + if (get_tlv_ioctl == (pcsc_dword_t)-1) + return 0; + + len = sizeof (buf); + sw = control_pcsc (slot, get_tlv_ioctl, NULL, 0, buf, &len); + if (sw) + { + log_error ("pcsc_vendor_specific_init: GET_TLV_IOCTL failed: %d\n", sw); + return SW_NOT_SUPPORTED; + } + + p = buf; + while (p < buf + len) + { + unsigned char tag = *p++; + int l = *p++; + unsigned int v = 0; + + /* Umm... here is little endian, while the encoding above is big. */ + if (l == 1) + v = p[0]; + else if (l == 2) + v = ((p[1] << 8) | p[0]); + else if (l == 4) + v = ((p[3] << 24) | (p[2] << 16) | (p[1] << 8) | p[0]); + + if (tag == PCSCv2_PART10_PROPERTY_bMinPINSize) + reader_table[slot].pcsc.pinmin = v; + else if (tag == PCSCv2_PART10_PROPERTY_bMaxPINSize) + reader_table[slot].pcsc.pinmax = v; + else if (tag == PCSCv2_PART10_PROPERTY_wIdVendor) + vendor = v; + else if (tag == PCSCv2_PART10_PROPERTY_wIdProduct) + product = v; + + if (DBG_CARD_IO) + log_debug ("TLV properties: tag=%02X, len=%d, v=%08X\n", tag, l, v); + + p += l; + } + + if (vendor == 0x0982 && product == 0x0008) /* Vega Alpha */ + { + /* + * Please read the comment of ccid_vendor_specific_init in + * ccid-driver.c. + */ + const unsigned char cmd[] = { '\xb5', '\x01', '\x00', '\x03', '\x00' }; + sw = control_pcsc (slot, CM_IOCTL_VENDOR_IFD_EXCHANGE, + cmd, sizeof (cmd), NULL, 0); + if (sw) + return SW_NOT_SUPPORTED; + } + else if (vendor == 0x04e6 && product == 0xe003) /* SCM SPR532 */ + { + reader_table[slot].is_spr532 = 1; + reader_table[slot].pinpad_varlen_supported = 1; + } + + return 0; +} + + /* Open the PC/SC reader without using the wrapper. Returns -1 on error or a slot number for the reader. */ #ifndef NEED_PCSC_WRAPPER @@ -1770,6 +1901,7 @@ open_pcsc_reader_direct (const char *portstr) reader_table[slot].send_apdu_reader = pcsc_send_apdu; reader_table[slot].dump_status_reader = dump_pcsc_reader_status; + pcsc_vendor_specific_init (slot); dump_reader_status (slot); return slot; } @@ -1967,6 +2099,8 @@ open_pcsc_reader_wrapped (const char *portstr) reader_table[slot].send_apdu_reader = pcsc_send_apdu; reader_table[slot].dump_status_reader = dump_pcsc_reader_status; + pcsc_vendor_specific_init (slot); + /* Read the status so that IS_T0 will be set. */ pcsc_get_status (slot, &dummy_status); @@ -2005,68 +2139,28 @@ open_pcsc_reader (const char *portstr) static int check_pcsc_pinpad (int slot, int command, pininfo_t *pininfo) { - unsigned char buf[256]; - pcsc_dword_t len = 256; - int sw; - - /* Hack to identify the SCM SPR532 and SPR332 readers which support - variable length PIN input. - FIXME: Figure out whether there is a feature attribute for this. - Alternatively use the USB ids to detect known readers. */ - if (reader_table[slot].rdrname - && strstr (reader_table[slot].rdrname, "SPRx32")) - { - reader_table[slot].is_spr532 = 1; - pininfo->fixedlen = 0; - } - - check_again: - if (command == ISO7816_VERIFY) - { - if (reader_table[slot].pcsc.verify_ioctl == (pcsc_dword_t)-1) - return SW_NOT_SUPPORTED; - else if (reader_table[slot].pcsc.verify_ioctl != 0) - return 0; /* Success */ - } - else if (command == ISO7816_CHANGE_REFERENCE_DATA) - { - if (reader_table[slot].pcsc.modify_ioctl == (pcsc_dword_t)-1) - return SW_NOT_SUPPORTED; - else if (reader_table[slot].pcsc.modify_ioctl != 0) - return 0; /* Success */ - } - else - return SW_NOT_SUPPORTED; + int r; - reader_table[slot].pcsc.verify_ioctl = (pcsc_dword_t)-1; - reader_table[slot].pcsc.modify_ioctl = (pcsc_dword_t)-1; + pininfo->minlen = reader_table[slot].pcsc.pinmin; + pininfo->maxlen = reader_table[slot].pcsc.pinmax; - sw = control_pcsc (slot, CM_IOCTL_GET_FEATURE_REQUEST, NULL, 0, buf, &len); - if (sw) - return SW_NOT_SUPPORTED; + if ((command == ISO7816_VERIFY && reader_table[slot].pcsc.verify_ioctl != 0) + || (command == ISO7816_CHANGE_REFERENCE_DATA + && reader_table[slot].pcsc.modify_ioctl != 0)) + r = 0; /* Success */ else - { - unsigned char *p = buf; - - while (p < buf + len) - { - unsigned char code = *p++; + r = SW_NOT_SUPPORTED; + + if (DBG_CARD_IO) + log_debug ("check_pcsc_pinpad: command=%02X, r=%d\n", + (unsigned int)command, r); - p++; /* Skip length */ - if (code == FEATURE_VERIFY_PIN_DIRECT) - reader_table[slot].pcsc.verify_ioctl - = (p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3]; - else if (code == FEATURE_MODIFY_PIN_DIRECT) - reader_table[slot].pcsc.modify_ioctl - = (p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3]; - p += 4; - } - } + if (reader_table[slot].pinpad_varlen_supported) + pininfo->fixedlen = 0; - goto check_again; + return r; } - #define PIN_VERIFY_STRUCTURE_SIZE 24 static int pcsc_pinpad_verify (int slot, int class, int ins, int p0, int p1, @@ -2113,7 +2207,7 @@ pcsc_pinpad_verify (int slot, int class, int ins, int p0, int p1, pin_verify[7] = 0x02; /* bEntryValidationCondition: Validation key pressed */ if (pininfo->minlen && pininfo->maxlen && pininfo->minlen == pininfo->maxlen) pin_verify[7] |= 0x01; /* Max size reached. */ - pin_verify[8] = 0xff; /* bNumberMessage: Default */ + pin_verify[8] = 0x01; /* bNumberMessage: One message */ pin_verify[9] = 0x09; /* wLangId: 0x0409: US English */ pin_verify[10] = 0x04; /* wLangId: 0x0409: US English */ pin_verify[11] = 0x00; /* bMsgIndex */ @@ -2210,12 +2304,12 @@ pcsc_pinpad_modify (int slot, int class, int ins, int p0, int p1, pin_modify[10] = 0x02; /* bEntryValidationCondition: Validation key pressed */ if (pininfo->minlen && pininfo->maxlen && pininfo->minlen == pininfo->maxlen) pin_modify[10] |= 0x01; /* Max size reached. */ - pin_modify[11] = 0xff; /* bNumberMessage: Default */ + pin_modify[11] = 0x03; /* bNumberMessage: Three messages */ pin_modify[12] = 0x09; /* wLangId: 0x0409: US English */ pin_modify[13] = 0x04; /* wLangId: 0x0409: US English */ pin_modify[14] = 0x00; /* bMsgIndex1 */ - pin_modify[15] = 0x00; /* bMsgIndex2 */ - pin_modify[16] = 0x00; /* bMsgIndex3 */ + pin_modify[15] = 0x01; /* bMsgIndex2 */ + pin_modify[16] = 0x02; /* bMsgIndex3 */ pin_modify[17] = 0x00; /* bTeoPrologue[0] */ pin_modify[18] = 0x00; /* bTeoPrologue[1] */ pin_modify[19] = 2 * pininfo->fixedlen + 0x05 - no_lc; /* bTeoPrologue[2] */ -- From gniibe at fsij.org Tue Aug 27 03:51:13 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 27 Aug 2013 10:51:13 +0900 Subject: scd: PC/SC pinpad input improvement In-Reply-To: <1377567603.3851.6.camel@cfw2.gniibe.org> References: <1377567603.3851.6.camel@cfw2.gniibe.org> Message-ID: <1377568273.3851.8.camel@cfw2.gniibe.org> Sorry, I realized that following part won't work on Windows, because of PCSC v2 PART10. On 2013-08-27 at 10:40 +0900, NIIBE Yutaka wrote: > This is the change to support pinpad input by PC/SC better. > +/* Examine reader specific parameters and initialize. This is mostly > + for pinpad input. Called at opening the connection to the reader. */ > +static int > +pcsc_vendor_specific_init (int slot) > +{ > + sw = control_pcsc (slot, get_tlv_ioctl, NULL, 0, buf, &len); [...] > + if (tag == PCSCv2_PART10_PROPERTY_bMinPINSize) > + reader_table[slot].pcsc.pinmin = v; > + else if (tag == PCSCv2_PART10_PROPERTY_bMaxPINSize) > + reader_table[slot].pcsc.pinmax = v; > + else if (tag == PCSCv2_PART10_PROPERTY_wIdVendor) > + vendor = v; > + else if (tag == PCSCv2_PART10_PROPERTY_wIdProduct) > + product = v; [...] > + else if (vendor == 0x04e6 && product == 0xe003) /* SCM SPR532 */ > + { > + reader_table[slot].is_spr532 = 1; > + reader_table[slot].pinpad_varlen_supported = 1; > + } I think that we'd better to use reader_table[slot].rdrname. -- From wk at gnupg.org Tue Aug 27 09:18:24 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Aug 2013 09:18:24 +0200 Subject: scd: fix for Vega Alpha reader In-Reply-To: <1377566049.3851.2.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Tue, 27 Aug 2013 10:14:09 +0900") References: <1377566049.3851.2.camel@cfw2.gniibe.org> Message-ID: <87eh9fvby7.fsf@vigenere.g10code.de> On Tue, 27 Aug 2013 03:14, gniibe at fsij.org said: > - const unsigned char cmd[] = "\xb5\x01\x00\x03\x00"; > + const unsigned char cmd[] = { '\xb5', '\x01', '\x00', '\x03', '\x00' }; > > - return send_escape_cmd (handle, cmd, sizeof (cmd), NULL, 0, NULL); An easier fix would have been to change just the first line to const unsigned char cmd[] = "\xb5\x01\x00\x03"; But you more explict code is probably easier to read for must people. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Aug 27 09:29:41 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Aug 2013 09:29:41 +0200 Subject: scd: PC/SC pinpad input improvement In-Reply-To: <1377567603.3851.6.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Tue, 27 Aug 2013 10:40:03 +0900") References: <1377567603.3851.6.camel@cfw2.gniibe.org> Message-ID: <87a9k3vbfe.fsf@vigenere.g10code.de> On Tue, 27 Aug 2013 03:40, gniibe at fsij.org said: > In this patch, we now have the function pcsc_vendor_specific_init, > which examines feature and PCSCv2_PART10_PROPERTY. There, we can > do special thing like for the one of Vega Alpha. Very good. > Besides, I found that bNumberMessage=0xff (default) doesn't work well > for some readers. So, I think that it is good to have specific I have no reader with a display, thus I can't say anything about it. > + else if (tag == PCSCv2_PART10_PROPERTY_wIdVendor) > + vendor = v; > + else if (tag == PCSCv2_PART10_PROPERTY_wIdProduct) > + product = v; I expected that something like this is available but did not had the time to check. However, as you also mention in your other mail, this may not work on Windows. I can check later the day whether it works with the SPR532 and if that is the case we could keep it. Something different: During a presentation I did last week, I realized that the default timeout of the SPR532 is a bit short. As of now the pop up window has a pretty short message but we may change this and the user will need more time to read that message - by then she may have already run into a timeout. Shall we add a configuration option to change the timeout? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue Aug 27 10:35:43 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 27 Aug 2013 17:35:43 +0900 Subject: scd: PC/SC pinpad input improvement In-Reply-To: <87a9k3vbfe.fsf@vigenere.g10code.de> References: <1377567603.3851.6.camel@cfw2.gniibe.org> <87a9k3vbfe.fsf@vigenere.g10code.de> Message-ID: <1377592543.3851.14.camel@cfw2.gniibe.org> On 2013-08-27 at 09:29 +0200, Werner Koch wrote: > Something different: During a presentation I did last week, I realized > that the default timeout of the SPR532 is a bit short. As of now the > pop up window has a pretty short message but we may change this and the > user will need more time to read that message - by then she may have > already run into a timeout. Shall we add a configuration option to > change the timeout? Please let me know the situation, how timeout occurs. There are two places for timeout of pinpad input. (1) Reader's timeout for execution of PC_to_RDR_Secure message. Host specifies this timeout. Currently, we don't use this feature. The reader waits validation key (Enter) pressed (with no timeout). (2) Host PC's timeout for waiting reply of RDR_to_PC_DataBlock. This is low-level thing. In GnuPG's ccid-driver, it's 30 secs. I think that the reader usually sends back "timer extension" to host PC to ask waiting again (before the expiration). I will check for PC/SC. -- From christian at quelltextlich.at Tue Aug 27 13:31:40 2013 From: christian at quelltextlich.at (Christian Aistleitner) Date: Tue, 27 Aug 2013 13:31:40 +0200 Subject: [PATCHES] Enable building using GNU Automake 1.13, 1.14 In-Reply-To: <87ob8kwpso.fsf@vigenere.g10code.de> References: <20130822075317.GA1543@quelltextlich.at> <87vc2wzjfy.fsf@vigenere.g10code.de> <20130825125708.GA4406@quelltextlich.at> <87ob8kwpso.fsf@vigenere.g10code.de> Message-ID: <20130827113140.GA15494@quelltextlich.at> Hi, On Mon, Aug 26, 2013 at 03:21:43PM +0200, Werner Koch wrote: > On Sun, 25 Aug 2013 14:57, christian at quelltextlich.at said: > > > But actually, the motivation for the patches stems from Debian > > Jessie / Sid users that were asking me about why the GnuPG ecosystem > > does not compile for them. > > AFAICS, Sid's latest Automake version is 1.11. Debian people tell me ?Sid? is not ?Jessie / Sid?. But maybe they are wrong. I do not know Debian's naming conventions well enough. Either way: http://packages.debian.org/search?suite=sid&keywords=automake shows 1.13.3 as default automake even for Sid. > In any case README.GIT > describes how to use an older autotools version. Sure :-) And once people realize that they are using a too new automake, then README.GIT shows them how to use an older automake. But how could people know that they are using a too new automake? README.GIT does not mention which automake versions are expected to work, and which are not :-/ And the error messages they get from autogen.sh / configure [1] do not allow them straight away to detect that they are using an unsupported automake version. But meh. Patches to build GnuPG & Co. using up-to-date automake are at least in the public now. :-) > > with. But ... is it nevertheless ok to post such patches to this list, > > so people can at least find patches to help them build GnuPG and > > Sure. Cool. Thanks. Best regards, Christian [1] configure complains that config.status: error: cannot find input file: `tests/Makefile.in' . The scrollback has some log lines parallel-tests: error: required file './test-driver' not found parallel-tests: 'automake --add-missing' can install 'test-driver' for running autogen.sh. But those lines also do not hint at automake being too new. Especially since autogen.sh does not abort after this error, but goes on with Running autoconf ... You may now run ./configure --enable-maintainer-mode && make -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From wk at gnupg.org Tue Aug 27 22:28:11 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Aug 2013 22:28:11 +0200 Subject: [PATCHES] Enable building using GNU Automake 1.13, 1.14 In-Reply-To: <20130827113140.GA15494@quelltextlich.at> (Christian Aistleitner's message of "Tue, 27 Aug 2013 13:31:40 +0200") References: <20130822075317.GA1543@quelltextlich.at> <87vc2wzjfy.fsf@vigenere.g10code.de> <20130825125708.GA4406@quelltextlich.at> <87ob8kwpso.fsf@vigenere.g10code.de> <20130827113140.GA15494@quelltextlich.at> Message-ID: <87fvtuswtg.fsf@vigenere.g10code.de> On Tue, 27 Aug 2013 13:31, christian at quelltextlich.at said: > http://packages.debian.org/search?suite=sid&keywords=automake > shows 1.13.3 as default automake even for Sid. Sorry, my fault. I only looked at it using apt-cache show and that scrollend away the new version and thus I only noticed the 1.11. > And once people realize that they are using a too new automake, then > README.GIT shows them how to use an older automake. I expect that people building from git are well aware of automake and problems using a a non-released version. > README.GIT does not mention which automake versions are expected to > work, and which are not :-/ It can't. It is the usual problem of future incompatibilities. This can't be handled by plain version number checks. If the automake author would add an extra API version number which is bumped after backward incompatible changes, we could check for it. But without such a thing it is hard to get things right. Consider next month they decide to revert the incompatible changes. Shall we then backout the change - in hundreds of packages or keep on carrying loads of less needed code? It has always been hard to defend autotools against people not willing to read the manuals and switching to cmake (shudder). With such an incompatible change as recently introduced, I feel slapped into the face. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jonas at borgstrom.se Wed Aug 28 12:28:51 2013 From: jonas at borgstrom.se (=?ISO-8859-1?Q?Jonas_Borgstr=F6m?=) Date: Wed, 28 Aug 2013 12:28:51 +0200 Subject: [PATCH] scd: RSA_CRT and RSA_CRT_N support Message-ID: <521DD0E3.50805@borgstrom.se> Hi, the attached patches for master and STABLE-BRANCH-2-0 adds support for the RSA_CRT and RSA_CRT_N key format as per the openpgp-card-2.0 specification. The patch has been used to successfully import keys to a yubikey neo[1] card running the ykneo-openpgp[2] applet. The latest firmware is needed for key import. [1]: http://www.yubico.com/yubikey-neo [2]: https://github.com/jborg/ykneo-openpgp Cheers, Jonas -------------- next part -------------- >From 9bb45e86f0d2951356a35a254bdcfcd712c481b9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Borgstr=C3=B6m?= Date: Wed, 28 Aug 2013 11:21:10 +0200 Subject: [PATCH] scd: add support for RSA_CRT and RSA_CRT_N key import. * scd/app-openpgp.c (do_writekey): Added RSA_CRT and RSA_CRT_N support. --- scd/app-openpgp.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 68 insertions(+), 7 deletions(-) diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 011c248..75a5787 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -2508,10 +2508,13 @@ build_privkey_template (app_t app, int keyno, const unsigned char *rsa_e, size_t rsa_e_len, const unsigned char *rsa_p, size_t rsa_p_len, const unsigned char *rsa_q, size_t rsa_q_len, + const unsigned char *rsa_u, size_t rsa_u_len, + const unsigned char *rsa_dp, size_t rsa_dp_len, + const unsigned char *rsa_dq, size_t rsa_dq_len, unsigned char **result, size_t *resultlen) { size_t rsa_e_reqlen; - unsigned char privkey[7*(1+3)]; + unsigned char privkey[7*(1+3+3)]; size_t privkey_len; unsigned char exthdr[2+2+3]; size_t exthdr_len; @@ -2529,17 +2532,16 @@ build_privkey_template (app_t app, int keyno, { case RSA_STD: case RSA_STD_N: - break; case RSA_CRT: case RSA_CRT_N: - return gpg_error (GPG_ERR_NOT_SUPPORTED); + break; default: return gpg_error (GPG_ERR_INV_VALUE); } - /* Get the required length for E. */ - rsa_e_reqlen = app->app_local->keyattr[keyno].rsa.e_bits/8; + /* Get the required length for E. Rounded up to the nearest byte */ + rsa_e_reqlen = (app->app_local->keyattr[keyno].rsa.e_bits + 7) / 8; assert (rsa_e_len <= rsa_e_reqlen); /* Build the 7f48 cardholder private key template. */ @@ -2555,6 +2557,17 @@ build_privkey_template (app_t app, int keyno, tp += add_tlv (tp, 0x93, rsa_q_len); datalen += rsa_q_len; + if (app->app_local->keyattr[keyno].rsa.format == RSA_CRT + || app->app_local->keyattr[keyno].rsa.format == RSA_CRT_N) + { + tp += add_tlv (tp, 0x94, rsa_u_len); + datalen += rsa_u_len; + tp += add_tlv (tp, 0x95, rsa_dp_len); + datalen += rsa_dp_len; + tp += add_tlv (tp, 0x96, rsa_dq_len); + datalen += rsa_dq_len; + } + if (app->app_local->keyattr[keyno].rsa.format == RSA_STD_N || app->app_local->keyattr[keyno].rsa.format == RSA_CRT_N) { @@ -2608,6 +2621,17 @@ build_privkey_template (app_t app, int keyno, memcpy (tp, rsa_q, rsa_q_len); tp += rsa_q_len; + if (app->app_local->keyattr[keyno].rsa.format == RSA_CRT + || app->app_local->keyattr[keyno].rsa.format == RSA_CRT_N) + { + memcpy (tp, rsa_u, rsa_u_len); + tp += rsa_u_len; + memcpy (tp, rsa_dp, rsa_dp_len); + tp += rsa_dp_len; + memcpy (tp, rsa_dq, rsa_dq_len); + tp += rsa_dq_len; + } + if (app->app_local->keyattr[keyno].rsa.format == RSA_STD_N || app->app_local->keyattr[keyno].rsa.format == RSA_CRT_N) { @@ -2954,16 +2978,53 @@ do_writekey (app_t app, ctrl_t ctrl, if (app->app_local->extcap.is_v2) { - /* Build the private key template as described in section 4.3.3.7 of - the OpenPGP card specs version 2.0. */ + unsigned char *rsa_u, *rsa_dp, rsa_dq; + size_t rsa_u_len, rsa_dp_len, rsa_dq_len; + gcry_mpi_t mpi_e, mpi_p, mpi_q; + gcry_mpi_t mpi_u = gcry_mpi_snew (0); + gcry_mpi_t mpi_dp = gcry_mpi_snew (0); + gcry_mpi_t mpi_dq = gcry_mpi_snew (0); + gcry_mpi_t mpi_tmp = gcry_mpi_snew (0); int exmode; + /* Calculate the u, dp and dq components needed by RSA_CRT cards */ + gcry_mpi_scan (&mpi_e, GCRYMPI_FMT_USG, rsa_e, rsa_e_len, NULL); + gcry_mpi_scan (&mpi_p, GCRYMPI_FMT_USG, rsa_p, rsa_p_len, NULL); + gcry_mpi_scan (&mpi_q, GCRYMPI_FMT_USG, rsa_q, rsa_q_len, NULL); + + gcry_mpi_invm (mpi_u, mpi_q, mpi_p); + gcry_mpi_sub_ui (mpi_tmp, mpi_p, 1); + gcry_mpi_invm (mpi_dp, mpi_e, mpi_tmp); + gcry_mpi_sub_ui (mpi_tmp, mpi_q, 1); + gcry_mpi_invm (mpi_dq, mpi_e, mpi_tmp); + + gcry_mpi_aprint (GCRYMPI_FMT_USG, &rsa_u, &rsa_u_len, mpi_u); + gcry_mpi_aprint (GCRYMPI_FMT_USG, &rsa_dp, &rsa_dp_len, mpi_dp); + gcry_mpi_aprint (GCRYMPI_FMT_USG, &rsa_dq, &rsa_dq_len, mpi_dq); + + gcry_mpi_release (mpi_e); + gcry_mpi_release (mpi_p); + gcry_mpi_release (mpi_q); + gcry_mpi_release (mpi_u); + gcry_mpi_release (mpi_dp); + gcry_mpi_release (mpi_dq); + gcry_mpi_release (mpi_tmp); + + /* Build the private key template as described in section 4.3.3.7 of + the OpenPGP card specs version 2.0. */ err = build_privkey_template (app, keyno, rsa_n, rsa_n_len, rsa_e, rsa_e_len, rsa_p, rsa_p_len, rsa_q, rsa_q_len, + rsa_u, rsa_u_len, + rsa_dp, rsa_dp_len, + rsa_dq, rsa_dq_len, &template, &template_len); + xfree(rsa_u); + xfree(rsa_dp); + xfree(rsa_dq); + if (err) goto leave; -- 1.7.9.6 (Apple Git-31.1) -------------- next part -------------- >From 24cb29c308261a9b060bcc62ac325f184f237a80 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Borgstr=C3=B6m?= Date: Wed, 28 Aug 2013 11:21:10 +0200 Subject: [PATCH] scd: add support for RSA_CRT and RSA_CRT_N key import. * scd/app-openpgp.c (do_writekey): Added RSA_CRT and RSA_CRT_N support. --- scd/app-openpgp.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 68 insertions(+), 7 deletions(-) diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 9186e18..20fd2de 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -2380,10 +2380,13 @@ build_privkey_template (app_t app, int keyno, const unsigned char *rsa_e, size_t rsa_e_len, const unsigned char *rsa_p, size_t rsa_p_len, const unsigned char *rsa_q, size_t rsa_q_len, + const unsigned char *rsa_u, size_t rsa_u_len, + const unsigned char *rsa_dp, size_t rsa_dp_len, + const unsigned char *rsa_dq, size_t rsa_dq_len, unsigned char **result, size_t *resultlen) { size_t rsa_e_reqlen; - unsigned char privkey[7*(1+3)]; + unsigned char privkey[7*(1+3+3)]; size_t privkey_len; unsigned char exthdr[2+2+3]; size_t exthdr_len; @@ -2401,17 +2404,16 @@ build_privkey_template (app_t app, int keyno, { case RSA_STD: case RSA_STD_N: - break; case RSA_CRT: case RSA_CRT_N: - return gpg_error (GPG_ERR_NOT_SUPPORTED); + break; default: return gpg_error (GPG_ERR_INV_VALUE); } - /* Get the required length for E. */ - rsa_e_reqlen = app->app_local->keyattr[keyno].e_bits/8; + /* Get the required length for E. Rounded up to the nearest byte */ + rsa_e_reqlen = (app->app_local->keyattr[keyno].e_bits + 7) / 8; assert (rsa_e_len <= rsa_e_reqlen); /* Build the 7f48 cardholder private key template. */ @@ -2427,6 +2429,17 @@ build_privkey_template (app_t app, int keyno, tp += add_tlv (tp, 0x93, rsa_q_len); datalen += rsa_q_len; + if (app->app_local->keyattr[keyno].format == RSA_CRT + || app->app_local->keyattr[keyno].format == RSA_CRT_N) + { + tp += add_tlv (tp, 0x94, rsa_u_len); + datalen += rsa_u_len; + tp += add_tlv (tp, 0x95, rsa_dp_len); + datalen += rsa_dp_len; + tp += add_tlv (tp, 0x96, rsa_dq_len); + datalen += rsa_dq_len; + } + if (app->app_local->keyattr[keyno].format == RSA_STD_N || app->app_local->keyattr[keyno].format == RSA_CRT_N) { @@ -2480,6 +2493,17 @@ build_privkey_template (app_t app, int keyno, memcpy (tp, rsa_q, rsa_q_len); tp += rsa_q_len; + if (app->app_local->keyattr[keyno].format == RSA_CRT + || app->app_local->keyattr[keyno].format == RSA_CRT_N) + { + memcpy (tp, rsa_u, rsa_u_len); + tp += rsa_u_len; + memcpy (tp, rsa_dp, rsa_dp_len); + tp += rsa_dp_len; + memcpy (tp, rsa_dq, rsa_dq_len); + tp += rsa_dq_len; + } + if (app->app_local->keyattr[keyno].format == RSA_STD_N || app->app_local->keyattr[keyno].format == RSA_CRT_N) { @@ -2826,16 +2850,53 @@ do_writekey (app_t app, ctrl_t ctrl, if (app->app_local->extcap.is_v2) { - /* Build the private key template as described in section 4.3.3.7 of - the OpenPGP card specs version 2.0. */ + unsigned char *rsa_u, *rsa_dp, rsa_dq; + size_t rsa_u_len, rsa_dp_len, rsa_dq_len; + gcry_mpi_t mpi_e, mpi_p, mpi_q; + gcry_mpi_t mpi_u = gcry_mpi_snew (0); + gcry_mpi_t mpi_dp = gcry_mpi_snew (0); + gcry_mpi_t mpi_dq = gcry_mpi_snew (0); + gcry_mpi_t mpi_tmp = gcry_mpi_snew (0); int exmode; + /* Calculate the u, dp and dq components needed by RSA_CRT cards */ + gcry_mpi_scan (&mpi_e, GCRYMPI_FMT_USG, rsa_e, rsa_e_len, NULL); + gcry_mpi_scan (&mpi_p, GCRYMPI_FMT_USG, rsa_p, rsa_p_len, NULL); + gcry_mpi_scan (&mpi_q, GCRYMPI_FMT_USG, rsa_q, rsa_q_len, NULL); + + gcry_mpi_invm (mpi_u, mpi_q, mpi_p); + gcry_mpi_sub_ui (mpi_tmp, mpi_p, 1); + gcry_mpi_invm (mpi_dp, mpi_e, mpi_tmp); + gcry_mpi_sub_ui (mpi_tmp, mpi_q, 1); + gcry_mpi_invm (mpi_dq, mpi_e, mpi_tmp); + + gcry_mpi_aprint (GCRYMPI_FMT_USG, &rsa_u, &rsa_u_len, mpi_u); + gcry_mpi_aprint (GCRYMPI_FMT_USG, &rsa_dp, &rsa_dp_len, mpi_dp); + gcry_mpi_aprint (GCRYMPI_FMT_USG, &rsa_dq, &rsa_dq_len, mpi_dq); + + gcry_mpi_release (mpi_e); + gcry_mpi_release (mpi_p); + gcry_mpi_release (mpi_q); + gcry_mpi_release (mpi_u); + gcry_mpi_release (mpi_dp); + gcry_mpi_release (mpi_dq); + gcry_mpi_release (mpi_tmp); + + /* Build the private key template as described in section 4.3.3.7 of + the OpenPGP card specs version 2.0. */ err = build_privkey_template (app, keyno, rsa_n, rsa_n_len, rsa_e, rsa_e_len, rsa_p, rsa_p_len, rsa_q, rsa_q_len, + rsa_u, rsa_u_len, + rsa_dp, rsa_dp_len, + rsa_dq, rsa_dq_len, &template, &template_len); + xfree(rsa_u); + xfree(rsa_dp); + xfree(rsa_dq); + if (err) goto leave; -- 1.7.9.6 (Apple Git-31.1) From niklas.schnelle at gmail.com Wed Aug 28 17:39:56 2013 From: niklas.schnelle at gmail.com (Niklas Schnelle) Date: Wed, 28 Aug 2013 17:39:56 +0200 Subject: Pinentry makes it awfully easy to snoop all passwords entered by the user Message-ID: Dear GnuPG Devs, first I do understand this is not really a security vulnerability as it is rooted in the very design of pinentry still it looks like a major problem to me. So as I understand it pinentry is used to request a password from the user and it then sends that password to the requesting process via a pipe. The problem here is that this makes it a lot easier to snoop passwords than if gnupg read them in a more direct way. To demonstrate this I've created a script [1] that waits for a pinentry process to start and than uses strace to get a trace of the syscall used to write the password to the pipe. This makes snooping on users gpg passwords extremely easy. One simply runs the script and it outputs the clear text passwords of all pinentry based password entries plus some strace output I was too lazy to remove. Of course an attacker needs access to the users account or root access but in many settings this is quite easy to achieve (e.g. a trojan or an admin snooping on it's users). Now if gnupg read the password itself it would at least be harder to grep for it in it's trace and it might get even harder with more secure input like what Wayland wants to provide in the future.. What do you girls/guys think? Greetings Niklas Schnelle [1] http://pastebin.com/79t1ATzx -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Aug 28 20:12:37 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Aug 2013 14:12:37 -0400 Subject: Pinentry makes it awfully easy to snoop all passwords entered by the user In-Reply-To: References: Message-ID: <521E3D95.80802@fifthhorseman.net> On 08/28/2013 11:39 AM, Niklas Schnelle wrote: > So as I understand it pinentry is used to request a password from the user > and it then sends that password to the requesting process via a pipe. The > problem here is that this > makes it a lot easier to snoop passwords than if gnupg read them in a more > direct way. Surely the same systemcall tracing approach could be tuned to scrape the passphrases from direct tty input as well? If i understand it correctly, in newer versions of gpg (2.1, not yet released afaik), the agent is designed to not transmit passwords to gpg itself at all; instead, the agent hangs on to the keys and only asymmetric crypto challenges and responses are communicated between the agent and the gpg process. So if you're really only concerned about what's passing across the pipes then you probably want to move to the newer version of gpg and test that out. but basically: if your adversary has root on your machine or has full control over your local account even, there isn't a way to use gpg (or any software) safely. This is unfortunate, but it seems to be the way things work. :( Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From niklas.schnelle at gmail.com Wed Aug 28 20:45:15 2013 From: niklas.schnelle at gmail.com (Niklas Schnelle) Date: Wed, 28 Aug 2013 20:45:15 +0200 Subject: Fwd: Pinentry makes it awfully easy to snoop all passwords entered by the user In-Reply-To: References: <521E3D95.80802@fifthhorseman.net> Message-ID: Just found this discussion about the same problem in ssh [1]. I do realize that the root user accessing this info is not really a problem it's trusted anyway and can do much worse including just reading your process memory. However it would be nice to have a way to disable tracing for normal users, I mean there isn't really any reason another process should be able to watch your processes system calls just like there are facilities to keep the kernel from swapping certain RAM areas. Maybe we should bring this up in the kernel community things like AppAmor and SELinux already reduce what processes can do, somehow I feel like this should be a special capability. This is actually quite a good reason for why Android in general has a better security model for today's day and age than normal desktop Linux, there every process runs as a different user. I think the kernel folks even limited access to some /proc files for exactly the same reason. [1] https://plus.google.com/107770072576338242009/posts/ETqpKHLUEKr -------------- next part -------------- An HTML attachment was scrubbed... URL: From abel at guardianproject.info Wed Aug 28 20:44:45 2013 From: abel at guardianproject.info (Abel Luck) Date: Wed, 28 Aug 2013 18:44:45 +0000 Subject: Pinentry makes it awfully easy to snoop all passwords entered by the user In-Reply-To: <521E3D95.80802@fifthhorseman.net> References: <521E3D95.80802@fifthhorseman.net> Message-ID: <521E451D.3030504@guardianproject.info> Daniel Kahn Gillmor: > but basically: if your adversary has root on your machine or has full > control over your local account even, there isn't a way to use gpg (or > any software) safely. This is unfortunate, but it seems to be the way > things work. :( This is the important point here imho! ~abel From niklas.schnelle at gmail.com Wed Aug 28 20:46:34 2013 From: niklas.schnelle at gmail.com (Niklas Schnelle) Date: Wed, 28 Aug 2013 20:46:34 +0200 Subject: Pinentry makes it awfully easy to snoop all passwords entered by the user In-Reply-To: References: <521E3D95.80802@fifthhorseman.net> Message-ID: Just found this discussion about the same problem in ssh [1]. I do realize that the root user accessing this info is not really a problem it's trusted anyway and can do much worse including just reading your process memory. However it would be nice to have a way to disable tracing for normal users, I mean there isn't really any reason another process should be able to watch your processes system calls just like there are facilities to keep the kernel from swapping certain RAM areas. Maybe we should bring this up in the kernel community things like AppAmor and SELinux already reduce what processes can do, somehow I feel like this should be a special capability. This is actually quite a good reason for why Android in general has a better security model for today's day and age than normal desktop Linux, there every process runs as a different user. I think the kernel folks even limited access to some /proc files for exactly the same reason. [1] https://plus.google.com/107770072576338242009/posts/ETqpKHLUEKr On Wed, Aug 28, 2013 at 8:40 PM, Niklas Schnelle wrote: > Just found this discussion about the same problem in ssh [1]. I do realize > that the root user accessing > this info is not really a problem it's trusted anyway and can do much > worse including just reading your process memory. > However it would be nice to have a way to disable tracing for normal > users, I mean there isn't really any reason another process should be able > to watch your processes system calls just like there are facilities to keep > the kernel from swapping certain RAM areas. Maybe we should bring this up > in the kernel community things like AppAmor and SELinux already reduce what > processes can do, somehow I feel like this should be a special capability. > This is actually quite a good reason for why Android in general has a > better security model for today's day and age than normal desktop Linux, > there every process runs as a different user. I think the kernel folks even > limited access to some /proc files for exactly the same reason. > > [1] https://plus.google.com/107770072576338242009/posts/ETqpKHLUEKr > > > On Wed, Aug 28, 2013 at 8:12 PM, Daniel Kahn Gillmor < > dkg at fifthhorseman.net> wrote: > >> On 08/28/2013 11:39 AM, Niklas Schnelle wrote: >> >> > So as I understand it pinentry is used to request a password from the >> user >> > and it then sends that password to the requesting process via a pipe. >> The >> > problem here is that this >> > makes it a lot easier to snoop passwords than if gnupg read them in a >> more >> > direct way. >> >> Surely the same systemcall tracing approach could be tuned to scrape the >> passphrases from direct tty input as well? >> >> If i understand it correctly, in newer versions of gpg (2.1, not yet >> released afaik), the agent is designed to not transmit passwords to gpg >> itself at all; instead, the agent hangs on to the keys and only >> asymmetric crypto challenges and responses are communicated between the >> agent and the gpg process. So if you're really only concerned about >> what's passing across the pipes then you probably want to move to the >> newer version of gpg and test that out. >> >> but basically: if your adversary has root on your machine or has full >> control over your local account even, there isn't a way to use gpg (or >> any software) safely. This is unfortunate, but it seems to be the way >> things work. :( >> >> Regards, >> >> --dkg >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Aug 28 21:00:09 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Aug 2013 15:00:09 -0400 Subject: Pinentry makes it awfully easy to snoop all passwords entered by the user In-Reply-To: References: <521E3D95.80802@fifthhorseman.net> Message-ID: <521E48B9.3090805@fifthhorseman.net> On 08/28/2013 02:46 PM, Niklas Schnelle wrote: > However it would be nice to have a way to disable tracing for normal users, If you use the linux kernel, take a look at the grsecurity patchset. I believe this is one of its features. https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Ptrace_logging --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From branko at majic.rs Wed Aug 28 20:03:58 2013 From: branko at majic.rs (Branko Majic) Date: Wed, 28 Aug 2013 20:03:58 +0200 Subject: Pinentry makes it awfully easy to snoop all passwords entered by the user In-Reply-To: References: Message-ID: <20130828200358.69bbe9ad@zetkin.primekey.se> On Wed, 28 Aug 2013 17:39:56 +0200 Niklas Schnelle wrote: > Dear GnuPG Devs, > > first I do understand this is not really a security vulnerability as it is > rooted in the very design of pinentry still it looks like a major problem > to me. > > So as I understand it pinentry is used to request a password from the user > and it then sends that password to the requesting process via a pipe. The > problem here is that this > makes it a lot easier to snoop passwords than if gnupg read them in a more > direct way. To demonstrate this I've created a script [1] that waits for a > pinentry process to start and than uses strace to get a trace of the > syscall used to write the password to the pipe. This makes snooping on > users gpg passwords extremely easy. One simply runs the script and it > outputs the clear text passwords of all pinentry based password entries > plus some strace output I was too lazy to remove. Of course an attacker > needs access to the users account or root access but in many settings this > is quite easy to achieve (e.g. a trojan or an admin snooping on it's users). > Now if gnupg read the password itself it would at least be harder to grep > for it in it's trace and it might get even harder with more secure input > like what Wayland wants to provide in the future.. > What do you girls/guys think? > > Greetings Niklas Schnelle > > [1] http://pastebin.com/79t1ATzx I'm not a developer, but, to be honest, if you get user or root access to a machine, your account (or whole machine in case of root) is completely compromised anyway, so you can obtain the PIN code in a multitude of ways - replacing gpg binary with a custom one, for example. The only real defense against this is to use (proper) smart-card reader with built-in PIN pad. When I say "proper", I mean the one where the PIN code won't leave the reader at all (there's been cases of PIN pads where the PIN still goes happily to the computer, but they masked it via driver). Now, the main question is - does using piping make it in any way possible for another, non-root, user to obtain the PIN code? If not, piping is still probably good enough. Best regards -- Branko Majic Jabber: branko at majic.rs Please use only Free formats when sending attachments to me. ?????? ????? ?????: branko at majic.rs ????? ??? ?? ??????? ?????? ????????? ? ????????? ?????????. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From jake at spaz.org Thu Aug 29 02:29:44 2013 From: jake at spaz.org (Jake) Date: Wed, 28 Aug 2013 17:29:44 -0700 (PDT) Subject: git repository questions Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everybody, I'm new to the list, because I want to contribute improvements to the excellent and important tool that is gnupg. I am new to a lot of the tools and practices involved in this kind of project, so please forgive me for the mistakes I have and will make and the dumb questions that will result. For example, I can tell you i spent several long sessions trying to figure out why gnupg would insist that I needed libgpg-error version 1.11 or newer, even though I had version 1.9 (which I thought was clearly newer than 1.11). Now I know better. But I am finally able to compile gnupg from the latest git pull, albeit without gpgtar, nls, and doc (i will explain why if asked) So now I would like to make improvements, and submit them for review by the maintainers in the most convenient (for the maintainers) way possible. Should I create a repository on github, and post my commits there, or should I ask for a respoitory on git.gnupg.org ?? I really don't know what is correct in this situation. Please feel free to educate me about anything you think I have missed, on or off list is fine. I look forward to contributing in a helpful way. thanks - -jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSHpX4AAoJEN7XJKHgSSB1agEP/2B9/3+59DVKlN7i+3xbwD7J fSJUO2aCIo1A58XKxISWQsvb4wQF0TeqHsBcl9syeNbR9a2eqqpx97sHcdZ5K6Qj j6kGxRAgZcuuk7ajYb7EPKoVpV2c9RAGUlX7/yduvhcy4LisZHOVAGdkZTu/uJW4 5S0pHsdUAfrBk5q3qLr/9b/dOANWAXReBZiw903pJtr4OQM0n//oMi+/arrTKUO3 ByyJ+4nzUdYUasQDhlbPCB4H3TJur7ngWNPKf402OfrTkDzYiLLIvbdWEyuStUB0 6jzIPXU99YlIhRainKXE8wgFECZoSTuJu0ay+gL3h8ZhH7RDmip7BL8ba3toQPV/ XZrlk+wGuRu31tZYYOKy0zMLjeSbfwJ+gHtO4xT99HbskgfkUFF+2okc+X3E7UAn t9vdclAPCX3sojQoPZwdzORJm+bRi00Zqj1yxCf/3Vga1Yqh8mIeibDLydt2bo11 NyCjOTJWACDdCsQjuA6YLQHP94rG1IPLH/baiP6pHmeRPvNjyR1+Zy/1JEYBF+5M 3XaeBCQ39s4C47vwW7snWE1+cr5w2mcBM5Ajuz3vFNna6GM3lCCHIaveHtWbrGwr SyHngjRrGSwtkoFKcLLvSnHwEW29hunJ6pMMzv0VPRoAipx4EBLlcb8ca1U3LKs6 ZQMPZpFqgYnMz+tYpBBR =uVeC -----END PGP SIGNATURE----- From gniibe at fsij.org Thu Aug 29 04:17:37 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 29 Aug 2013 11:17:37 +0900 Subject: Pinentry makes it awfully easy to snoop all passwords entered by the user In-Reply-To: References: <521E3D95.80802@fifthhorseman.net> Message-ID: <1377742657.3712.0.camel@cfw2.gniibe.org> On 2013-08-28 at 20:46 +0200, Niklas Schnelle wrote: > However it would be nice to have a way to disable tracing for normal > users, I mean there isn't really any reason another process should be > able to watch your processes system calls just like there are > facilities to keep the kernel from swapping certain RAM areas. FYI, we have an ticket at BTS: https://bugs.g10code.com/gnupg/issue1509 This is not about passphrase but private keys, but discuss same thing. I'm not sure what kind of threat you imagine. My solution against the scenario (you suggested) would be just not to install strace or gdb. Or, my easier and precise attack would be replacing pinentry to log sessions to save passphrase(s). -- From wk at gnupg.org Thu Aug 29 09:46:46 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 29 Aug 2013 09:46:46 +0200 Subject: Pinentry makes it awfully easy to snoop all passwords entered by the user In-Reply-To: <521E3D95.80802@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 28 Aug 2013 14:12:37 -0400") References: <521E3D95.80802@fifthhorseman.net> Message-ID: <87y57lq6qh.fsf@vigenere.g10code.de> On Wed, 28 Aug 2013 20:12, dkg at fifthhorseman.net said: > released afaik), the agent is designed to not transmit passwords to gpg > itself at all; instead, the agent hangs on to the keys and only > asymmetric crypto challenges and responses are communicated between the > agent and the gpg process. So if you're really only concerned about Right. However, the pinentry is still used to ask for the passphrase or PIN. As a separate process it also communicates via pipes. > but basically: if your adversary has root on your machine or has full > control over your local account even, there isn't a way to use gpg (or Right. As soon as you can ptrace a process it is really easy to figure out anything. An adversary might also use gdb to grab interesting things. I do that all the time during debugging. Protecting one from herself is not possible. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Aug 29 10:19:31 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 29 Aug 2013 10:19:31 +0200 Subject: git repository questions In-Reply-To: (jake@spaz.org's message of "Wed, 28 Aug 2013 17:29:44 -0700 (PDT)") References: Message-ID: <87txi8rjsc.fsf@vigenere.g10code.de> On Thu, 29 Aug 2013 02:29, jake at spaz.org said: > newer, even though I had version 1.9 (which I thought was clearly newer > than 1.11). Now I know better. Yep, we are using integers and not real numbers. The dot is used to separate the parts of the version number and is not the fraction point. For gpg-error we use a simple MAJOR.MINOR Scheme whereas for other projects aversion numbering scheme of MAJOR.MINOR.MICRO is used. > But I am finally able to compile gnupg from the latest git pull, albeit > without gpgtar, nls, and doc (i will explain why if asked) Do you mean gpgtar does not build ? That is a pretty standard Unix program and I have never heard of any problems. If you have problems wityh NLS, there are probably other problems. BTW: Make sure to use automake 1.11. > Should I create a repository on github, and post my commits there, or > should I ask for a respoitory on git.gnupg.org ?? I really don't know Neither. The cool thing with a DVCS is that you can have your own copy of the entire repository. If you want me to integrate your patches, you should send the patches (git format-patch) to this mailing list and I may apply them to the default repo. Before you put too much work into writing a patch, you may want to describe the problem and discuss it with us. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jonas at borgstrom.se Thu Aug 29 12:12:10 2013 From: jonas at borgstrom.se (=?ISO-8859-1?Q?Jonas_Borgstr=F6m?=) Date: Thu, 29 Aug 2013 12:12:10 +0200 Subject: DCO for Jonas =?ISO-8859-1?Q?Borgstr=F6m?= Message-ID: <521F1E7A.5080602@borgstrom.se> GnuPG Developer's Certificate of Origin. Version 1.0 ===================================================== By making a contribution to the GnuPG project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the free software license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same free software license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the free software license(s) involved. Signed-off-by: Jonas Borgstr?m -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: OpenPGP digital signature URL: From jake at spaz.org Fri Aug 30 01:33:44 2013 From: jake at spaz.org (Jake) Date: Thu, 29 Aug 2013 16:33:44 -0700 (PDT) Subject: gpgtar not building on limited macos environment In-Reply-To: <87txi8rjsc.fsf@vigenere.g10code.de> References: <87txi8rjsc.fsf@vigenere.g10code.de> Message-ID: I couldn't build gpgtar because of the error pasted here: http://pastebin.com/ti4x1jL1 I was told by others that libintl is required, and does not exist for my environment (32-bit intel MacOS 10.6.8) and I could not find a path forward, so I built without gpgtar for now. I understand that compiling things in macOS requires a complete install of 500 GB of developer tools, and since I didn't have enough space I have been getting by with homebrew (the package manager not the beverage) except for things like this. I can also tell you that I could not build nls because of this: http://pastebin.com/tJ1DS1dQ and because i couldn't install xfig (and fig2dev) i had to disable-doc I cannot claim to have a "complete" build environment, so I am not going to suggest there is a deficiency anywhere but on my computer and in my brain. Thank you, -jake On Thu, 29 Aug 2013, Werner Koch wrote: > On Thu, 29 Aug 2013 02:29, jake at spaz.org said: >> But I am finally able to compile gnupg from the latest git pull, albeit >> without gpgtar, nls, and doc (i will explain why if asked) > > Do you mean gpgtar does not build ? That is a pretty standard Unix > program and I have never heard of any problems. If you have problems > wityh NLS, there are probably other problems. BTW: Make sure to use > automake 1.11. From gniibe at fsij.org Fri Aug 30 02:47:05 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 30 Aug 2013 09:47:05 +0900 Subject: scd: PC/SC pinpad input improvement In-Reply-To: <1377592543.3851.14.camel@cfw2.gniibe.org> References: <1377567603.3851.6.camel@cfw2.gniibe.org> <87a9k3vbfe.fsf@vigenere.g10code.de> <1377592543.3851.14.camel@cfw2.gniibe.org> Message-ID: <1377823625.3190.12.camel@cfw2.gniibe.org> I'm going to commit following change to SCD. I updated pcsc_vendor_specific_init, so that it can detect SPR532 on Windows. ================================================ diff --git a/scd/apdu.c b/scd/apdu.c index e05869f..a863a16 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -118,6 +118,8 @@ struct reader_table_s { pcsc_dword_t protocol; pcsc_dword_t verify_ioctl; pcsc_dword_t modify_ioctl; + int pinmin; + int pinmax; #ifdef NEED_PCSC_WRAPPER int req_fd; int rsp_fd; @@ -135,6 +137,9 @@ struct reader_table_s { int status; int is_t0; /* True if we know that we are running T=0. */ int is_spr532; /* True if we know that the reader is a SPR532. */ + int pinpad_varlen_supported; /* True if we know that the reader + supports variable length pinpad + input. */ unsigned char atr[33]; size_t atrlen; /* A zero length indicates that the ATR has not yet been read; i.e. the card is not @@ -244,8 +249,17 @@ static char (* DLSTDCALL CT_close) (unsigned short ctn); #endif #define CM_IOCTL_GET_FEATURE_REQUEST SCARD_CTL_CODE(3400) +#define CM_IOCTL_VENDOR_IFD_EXCHANGE SCARD_CTL_CODE(1) #define FEATURE_VERIFY_PIN_DIRECT 0x06 #define FEATURE_MODIFY_PIN_DIRECT 0x07 +#define FEATURE_GET_TLV_PROPERTIES 0x12 + +#define PCSCv2_PART10_PROPERTY_bEntryValidationCondition 2 +#define PCSCv2_PART10_PROPERTY_bTimeOut2 3 +#define PCSCv2_PART10_PROPERTY_bMinPINSize 6 +#define PCSCv2_PART10_PROPERTY_bMaxPINSize 7 +#define PCSCv2_PART10_PROPERTY_wIdVendor 11 +#define PCSCv2_PART10_PROPERTY_wIdProduct 12 /* The PC/SC error is defined as a long as per specs. Due to left @@ -400,6 +414,7 @@ new_reader_slot (void) reader_table[reader].last_status = 0; reader_table[reader].is_t0 = 1; reader_table[reader].is_spr532 = 0; + reader_table[reader].pinpad_varlen_supported = 0; #ifdef NEED_PCSC_WRAPPER reader_table[reader].pcsc.req_fd = -1; reader_table[reader].pcsc.rsp_fd = -1; @@ -407,6 +422,8 @@ new_reader_slot (void) #endif reader_table[reader].pcsc.verify_ioctl = 0; reader_table[reader].pcsc.modify_ioctl = 0; + reader_table[reader].pcsc.pinmin = -1; + reader_table[reader].pcsc.pinmax = -1; return reader; } @@ -1676,6 +1693,132 @@ reset_pcsc_reader (int slot) } +/* Examine reader specific parameters and initialize. This is mostly + for pinpad input. Called at opening the connection to the reader. */ +static int +pcsc_vendor_specific_init (int slot) +{ + unsigned char buf[256]; + pcsc_dword_t len; + int sw; + int vendor = 0; + int product = 0; + pcsc_dword_t get_tlv_ioctl = (pcsc_dword_t)-1; + unsigned char *p; + + len = sizeof (buf); + sw = control_pcsc (slot, CM_IOCTL_GET_FEATURE_REQUEST, NULL, 0, buf, &len); + if (sw) + { + log_error ("pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: %d\n", + sw); + return SW_NOT_SUPPORTED; + } + else + { + p = buf; + while (p < buf + len) + { + unsigned char code = *p++; + int l = *p++; + unsigned int v = 0; + + if (l == 1) + v = p[0]; + else if (l == 2) + v = ((p[0] << 8) | p[1]); + else if (l == 4) + v = ((p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3]); + + if (code == FEATURE_VERIFY_PIN_DIRECT) + reader_table[slot].pcsc.verify_ioctl = v; + else if (code == FEATURE_MODIFY_PIN_DIRECT) + reader_table[slot].pcsc.modify_ioctl = v; + else if (code == FEATURE_GET_TLV_PROPERTIES) + get_tlv_ioctl = v; + + if (DBG_CARD_IO) + log_debug ("feature: code=%02X, len=%d, v=%02X\n", code, l, v); + + p += l; + } + } + + /* + * For system which doesn't support GET_TLV_PROPERTIES, + * we put some heuristics here. + */ + if (reader_table[slot].rdrname + && strstr (reader_table[slot].rdrname, "SPRx32")) + { + reader_table[slot].is_spr532 = 1; + reader_table[slot].pinpad_varlen_supported = 1; + return 0; + } + + if (get_tlv_ioctl == (pcsc_dword_t)-1) + return 0; + + len = sizeof (buf); + sw = control_pcsc (slot, get_tlv_ioctl, NULL, 0, buf, &len); + if (sw) + { + log_error ("pcsc_vendor_specific_init: GET_TLV_IOCTL failed: %d\n", sw); + return SW_NOT_SUPPORTED; + } + + p = buf; + while (p < buf + len) + { + unsigned char tag = *p++; + int l = *p++; + unsigned int v = 0; + + /* Umm... here is little endian, while the encoding above is big. */ + if (l == 1) + v = p[0]; + else if (l == 2) + v = ((p[1] << 8) | p[0]); + else if (l == 4) + v = ((p[3] << 24) | (p[2] << 16) | (p[1] << 8) | p[0]); + + if (tag == PCSCv2_PART10_PROPERTY_bMinPINSize) + reader_table[slot].pcsc.pinmin = v; + else if (tag == PCSCv2_PART10_PROPERTY_bMaxPINSize) + reader_table[slot].pcsc.pinmax = v; + else if (tag == PCSCv2_PART10_PROPERTY_wIdVendor) + vendor = v; + else if (tag == PCSCv2_PART10_PROPERTY_wIdProduct) + product = v; + + if (DBG_CARD_IO) + log_debug ("TLV properties: tag=%02X, len=%d, v=%08X\n", tag, l, v); + + p += l; + } + + if (vendor == 0x0982 && product == 0x0008) /* Vega Alpha */ + { + /* + * Please read the comment of ccid_vendor_specific_init in + * ccid-driver.c. + */ + const unsigned char cmd[] = { '\xb5', '\x01', '\x00', '\x03', '\x00' }; + sw = control_pcsc (slot, CM_IOCTL_VENDOR_IFD_EXCHANGE, + cmd, sizeof (cmd), NULL, 0); + if (sw) + return SW_NOT_SUPPORTED; + } + else if (vendor == 0x04e6 && product == 0xe003) /* SCM SPR532 */ + { + reader_table[slot].is_spr532 = 1; + reader_table[slot].pinpad_varlen_supported = 1; + } + + return 0; +} + + /* Open the PC/SC reader without using the wrapper. Returns -1 on error or a slot number for the reader. */ #ifndef NEED_PCSC_WRAPPER @@ -1770,6 +1913,7 @@ open_pcsc_reader_direct (const char *portstr) reader_table[slot].send_apdu_reader = pcsc_send_apdu; reader_table[slot].dump_status_reader = dump_pcsc_reader_status; + pcsc_vendor_specific_init (slot); dump_reader_status (slot); return slot; } @@ -1967,6 +2111,8 @@ open_pcsc_reader_wrapped (const char *portstr) reader_table[slot].send_apdu_reader = pcsc_send_apdu; reader_table[slot].dump_status_reader = dump_pcsc_reader_status; + pcsc_vendor_specific_init (slot); + /* Read the status so that IS_T0 will be set. */ pcsc_get_status (slot, &dummy_status); @@ -2005,68 +2151,28 @@ open_pcsc_reader (const char *portstr) static int check_pcsc_pinpad (int slot, int command, pininfo_t *pininfo) { - unsigned char buf[256]; - pcsc_dword_t len = 256; - int sw; - - /* Hack to identify the SCM SPR532 and SPR332 readers which support - variable length PIN input. - FIXME: Figure out whether there is a feature attribute for this. - Alternatively use the USB ids to detect known readers. */ - if (reader_table[slot].rdrname - && strstr (reader_table[slot].rdrname, "SPRx32")) - { - reader_table[slot].is_spr532 = 1; - pininfo->fixedlen = 0; - } - - check_again: - if (command == ISO7816_VERIFY) - { - if (reader_table[slot].pcsc.verify_ioctl == (pcsc_dword_t)-1) - return SW_NOT_SUPPORTED; - else if (reader_table[slot].pcsc.verify_ioctl != 0) - return 0; /* Success */ - } - else if (command == ISO7816_CHANGE_REFERENCE_DATA) - { - if (reader_table[slot].pcsc.modify_ioctl == (pcsc_dword_t)-1) - return SW_NOT_SUPPORTED; - else if (reader_table[slot].pcsc.modify_ioctl != 0) - return 0; /* Success */ - } - else - return SW_NOT_SUPPORTED; + int r; - reader_table[slot].pcsc.verify_ioctl = (pcsc_dword_t)-1; - reader_table[slot].pcsc.modify_ioctl = (pcsc_dword_t)-1; + pininfo->minlen = reader_table[slot].pcsc.pinmin; + pininfo->maxlen = reader_table[slot].pcsc.pinmax; - sw = control_pcsc (slot, CM_IOCTL_GET_FEATURE_REQUEST, NULL, 0, buf, &len); - if (sw) - return SW_NOT_SUPPORTED; + if ((command == ISO7816_VERIFY && reader_table[slot].pcsc.verify_ioctl != 0) + || (command == ISO7816_CHANGE_REFERENCE_DATA + && reader_table[slot].pcsc.modify_ioctl != 0)) + r = 0; /* Success */ else - { - unsigned char *p = buf; - - while (p < buf + len) - { - unsigned char code = *p++; + r = SW_NOT_SUPPORTED; + + if (DBG_CARD_IO) + log_debug ("check_pcsc_pinpad: command=%02X, r=%d\n", + (unsigned int)command, r); - p++; /* Skip length */ - if (code == FEATURE_VERIFY_PIN_DIRECT) - reader_table[slot].pcsc.verify_ioctl - = (p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3]; - else if (code == FEATURE_MODIFY_PIN_DIRECT) - reader_table[slot].pcsc.modify_ioctl - = (p[0] << 24) | (p[1] << 16) | (p[2] << 8) | p[3]; - p += 4; - } - } + if (reader_table[slot].pinpad_varlen_supported) + pininfo->fixedlen = 0; - goto check_again; + return r; } - #define PIN_VERIFY_STRUCTURE_SIZE 24 static int pcsc_pinpad_verify (int slot, int class, int ins, int p0, int p1, @@ -2113,7 +2219,7 @@ pcsc_pinpad_verify (int slot, int class, int ins, int p0, int p1, pin_verify[7] = 0x02; /* bEntryValidationCondition: Validation key pressed */ if (pininfo->minlen && pininfo->maxlen && pininfo->minlen == pininfo->maxlen) pin_verify[7] |= 0x01; /* Max size reached. */ - pin_verify[8] = 0xff; /* bNumberMessage: Default */ + pin_verify[8] = 0x01; /* bNumberMessage: One message */ pin_verify[9] = 0x09; /* wLangId: 0x0409: US English */ pin_verify[10] = 0x04; /* wLangId: 0x0409: US English */ pin_verify[11] = 0x00; /* bMsgIndex */ @@ -2210,12 +2316,12 @@ pcsc_pinpad_modify (int slot, int class, int ins, int p0, int p1, pin_modify[10] = 0x02; /* bEntryValidationCondition: Validation key pressed */ if (pininfo->minlen && pininfo->maxlen && pininfo->minlen == pininfo->maxlen) pin_modify[10] |= 0x01; /* Max size reached. */ - pin_modify[11] = 0xff; /* bNumberMessage: Default */ + pin_modify[11] = 0x03; /* bNumberMessage: Three messages */ pin_modify[12] = 0x09; /* wLangId: 0x0409: US English */ pin_modify[13] = 0x04; /* wLangId: 0x0409: US English */ pin_modify[14] = 0x00; /* bMsgIndex1 */ - pin_modify[15] = 0x00; /* bMsgIndex2 */ - pin_modify[16] = 0x00; /* bMsgIndex3 */ + pin_modify[15] = 0x01; /* bMsgIndex2 */ + pin_modify[16] = 0x02; /* bMsgIndex3 */ pin_modify[17] = 0x00; /* bTeoPrologue[0] */ pin_modify[18] = 0x00; /* bTeoPrologue[1] */ pin_modify[19] = 2 * pininfo->fixedlen + 0x05 - no_lc; /* bTeoPrologue[2] */ -- From gniibe at fsij.org Fri Aug 30 03:24:59 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 30 Aug 2013 10:24:59 +0900 Subject: scd: PC/SC pinpad input improvement In-Reply-To: <1377592543.3851.14.camel@cfw2.gniibe.org> References: <1377567603.3851.6.camel@cfw2.gniibe.org> <87a9k3vbfe.fsf@vigenere.g10code.de> <1377592543.3851.14.camel@cfw2.gniibe.org> Message-ID: <1377825899.3190.13.camel@cfw2.gniibe.org> On 2013-08-27 at 17:35 +0900, NIIBE Yutaka wrote: > On 2013-08-27 at 09:29 +0200, Werner Koch wrote: > > Something different: During a presentation I did last week, I realized > > that the default timeout of the SPR532 is a bit short. As of now the > > pop up window has a pretty short message but we may change this and the > > user will need more time to read that message - by then she may have > > already run into a timeout. Shall we add a configuration option to > > change the timeout? > [...] > I will check for PC/SC. In GNU/Linux, the lower level timeout is usually dynamically adusted in libccid by IFDHSetProtocolParameters. It uses different timeout for SecurePINVerify and SecurePINModify. That's because it is up to user how many seconds are required to the command request from host. BWT (Block Waiting Time) doesn't matter for pinpad input. It was 30 seconds in older implementations, and it's now 90 seconds. It would be better to specify bigger bTimeOut of pin_verify[0] or pin_modify[0]. Current implementation specifies 0, it means, the default value, it's up to PC/SC. -- From dkg at fifthhorseman.net Fri Aug 30 05:22:56 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 29 Aug 2013 23:22:56 -0400 Subject: gpg --gen-key --batch RSA keys default to 1024 bits Message-ID: <52201010.3000807@fifthhorseman.net> gpg --gen-key currently defaults interactively to creating 2048-bit RSA keys. But using gpg --gen-key --batch with Key-Type: RSA defaults to 1024 bits: > > 0 dkg at alice:/tmp/cdtemp.MTYWwo$ printf "Key-Type: RSA\nName-Real: foobar\n" | gpg --batch --gen-key --yes > gpg: keyring `/tmp/cdtemp.MTYWwo/secring.gpg' created > gpg: keyring `/tmp/cdtemp.MTYWwo/pubring.gpg' created > gpg: keysize invalid; using 1024 bits > > Not enough random bytes available. Please do some other work to give > the OS a chance to collect more entropy! (Need 257 more bytes) > +++++ > +++++ > gpg: /tmp/cdtemp.MTYWwo/trustdb.gpg: trustdb created > gpg: key 2576700C marked as ultimately trusted > 0 dkg at alice:/tmp/cdtemp.MTYWwo$ It seems like these defaults should be aligned with each other. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From christoph_murauer at yahoo.de Fri Aug 30 08:37:11 2013 From: christoph_murauer at yahoo.de (Christoph Roland Murauer) Date: Fri, 30 Aug 2013 08:37:11 +0200 Subject: gpgtar not building on limited macos environment In-Reply-To: References: <87txi8rjsc.fsf@vigenere.g10code.de> Message-ID: Hello Jake ! Yes, Apple has killer applications in size but for Xcode and the required things (CLI tools) you need only round 5 GB not 500. I am sure you know how to build things on Snow Leopard but could you describe what you have done (installed software, build options and so on ... ) - that makes it more easy to find a solution (if there is one). MacPorts and Homebrew are very tricky ... in what they do and in killing your file and folder permissions. And I (maybe for others it works fine) would not mix things like brew and self compiled software. C. M. Am 30.08.2013 um 01:33 schrieb Jake : > I couldn't build gpgtar because of the error pasted here: > http://pastebin.com/ti4x1jL1 > > I was told by others that libintl is required, and does not exist for my environment (32-bit intel MacOS 10.6.8) and I could not find a path forward, so I built without gpgtar for now. > > I understand that compiling things in macOS requires a complete install of 500 GB of developer tools, and since I didn't have enough space I have been getting by with homebrew (the package manager not the beverage) except for things like this. > > I can also tell you that I could not build nls because of this: http://pastebin.com/tJ1DS1dQ > > and because i couldn't install xfig (and fig2dev) i had to disable-doc > > I cannot claim to have a "complete" build environment, so I am not going to suggest there is a deficiency anywhere but on my computer and in my brain. > > Thank you, > -jake > > On Thu, 29 Aug 2013, Werner Koch wrote: > >> On Thu, 29 Aug 2013 02:29, jake at spaz.org said: >>> But I am finally able to compile gnupg from the latest git pull, albeit >>> without gpgtar, nls, and doc (i will explain why if asked) >> >> Do you mean gpgtar does not build ? That is a pretty standard Unix >> program and I have never heard of any problems. If you have problems >> wityh NLS, there are probably other problems. BTW: Make sure to use >> automake 1.11. > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From wk at gnupg.org Fri Aug 30 09:40:40 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 30 Aug 2013 09:40:40 +0200 Subject: scd: PC/SC pinpad input improvement In-Reply-To: <1377825899.3190.13.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Fri, 30 Aug 2013 10:24:59 +0900") References: <1377567603.3851.6.camel@cfw2.gniibe.org> <87a9k3vbfe.fsf@vigenere.g10code.de> <1377592543.3851.14.camel@cfw2.gniibe.org> <1377825899.3190.13.camel@cfw2.gniibe.org> Message-ID: <87ppsvpqx3.fsf@vigenere.g10code.de> On Fri, 30 Aug 2013 03:24, gniibe at fsij.org said: > It would be better to specify bigger bTimeOut of pin_verify[0] or > pin_modify[0]. Current implementation specifies 0, it means, the > default value, it's up to PC/SC. Thus for Windows it is up to the Windows driver for the reader (which seems to be either the generic CCID driver or a customized SCM version). If that is only a problem on Windows we may treat this as a problem of the Windows driver (maybe there is even a Registry entry tochange that). OTOH, it shouldn't harm if we add a configuration option to allow the user to change it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Aug 30 09:58:51 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 30 Aug 2013 09:58:51 +0200 Subject: gpgtar not building on limited macos environment In-Reply-To: (jake@spaz.org's message of "Thu, 29 Aug 2013 16:33:44 -0700 (PDT)") References: <87txi8rjsc.fsf@vigenere.g10code.de> Message-ID: <87hae7pq2s.fsf@vigenere.g10code.de> On Fri, 30 Aug 2013 01:33, jake at spaz.org said: > I couldn't build gpgtar because of the error pasted here: > http://pastebin.com/ti4x1jL1 That's easy. Sone linker options are missing. I am currently fixinf this for master and will then do it for 2.0. Thanks for reporting. > I can also tell you that I could not build nls because of this: > http://pastebin.com/tJ1DS1dQ Other are more expereinced with OS X; the problem should be common because GnuPG uses the same gettext as all other software. > and because i couldn't install xfig (and fig2dev) i had to disable-doc A common complaint. Eventually I need to do something about it. I only wonder why a small and useful tool like xfig is not installed by default. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Aug 30 10:25:42 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 30 Aug 2013 10:25:42 +0200 Subject: gpg --gen-key --batch RSA keys default to 1024 bits In-Reply-To: <52201010.3000807@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 29 Aug 2013 23:22:56 -0400") References: <52201010.3000807@fifthhorseman.net> Message-ID: <87d2ovpou1.fsf@vigenere.g10code.de> On Fri, 30 Aug 2013 05:22, dkg at fifthhorseman.net said: >> gpg: keysize invalid; using 1024 bits Okay. Changed to 2048 for rsa, elg and dsa in all thre branches. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri Aug 30 10:50:01 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 30 Aug 2013 17:50:01 +0900 Subject: scd: PC/SC pinpad input improvement In-Reply-To: <87ppsvpqx3.fsf@vigenere.g10code.de> References: <1377567603.3851.6.camel@cfw2.gniibe.org> <87a9k3vbfe.fsf@vigenere.g10code.de> <1377592543.3851.14.camel@cfw2.gniibe.org> <1377825899.3190.13.camel@cfw2.gniibe.org> <87ppsvpqx3.fsf@vigenere.g10code.de> Message-ID: <1377852601.3190.25.camel@cfw2.gniibe.org> On 2013-08-30 at 09:40 +0200, Werner Koch wrote: > Thus for Windows it is up to the Windows driver for the reader (which > seems to be either the generic CCID driver or a customized SCM > version). If that is only a problem on Windows we may treat this as a > problem of the Windows driver (maybe there is even a Registry entry > tochange that). OTOH, it shouldn't harm if we add a configuration > option to allow the user to change it. I think that this is a kind of corner case. Card reader should just work with no configuration. When it properly emits time extension reply message, there is no need to specify such a low-level timeout, in the first place. When we need to specify, I think that it would be easier for a user to use system wide setting to specify pinpad timeout (if available). That's because I don't think it is application specific. It would be card reader specific. The method of input PIN would be different. Suppose that there is another application than GnuPG, which uses the card reader (well, it would use different kinds of cards). In this case, a user naturally wants to specify pinpad timeout, system widely. If we will find there's no way to change the default pinpad timeout, then, we need to support the way to specify it by the application. When an application needs timeout to cancel authentication, it is different story. In this case, it is an application which specifies timeout. It is only application which knows this kind of context. -- From christoph_murauer at yahoo.de Sat Aug 31 09:59:53 2013 From: christoph_murauer at yahoo.de (Christoph Roland Murauer) Date: Sat, 31 Aug 2013 09:59:53 +0200 Subject: gpgtar not building on limited macos environment In-Reply-To: References: <87txi8rjsc.fsf@vigenere.g10code.de> <87hae7pq2s.fsf@vigenere.g10code.de> Message-ID: <069E77A8-2C39-460B-B26E-7AB5705FAC9D@yahoo.de> Update : Before I meaned ./configure --sysconfdir=/etc --enable-maintainer-mode --enable-symcryptrun --enable-mailto --enable-gpgtar --enable-nls --enable-doc && make && sude make install My fault - sorry. C. M. Am 31.08.2013 um 09:35 schrieb Christoph Roland Murauer : > Hy Jake ! > > Thanks for your detailed informations. > > I used a older Mac (Black MacBook) with a Intel Core 2 Due, a clean install of Snow Leopard 10.6.8 on it, Xcode 3.2 from the DVD (it is not really important, because I never launched it) including gcc version 4.2.1. You wrote 32 bit intel with Mac OS X 10.6.8 and thats the reason why I asked for details. In the machine I tried is a 64 bit CPU but Snow Leopard uses by default a 32 bit kernel and 32 bit extension BUT the unfair thing is, that gcc builds by default 64 bit software on this machine. If you also had a machine like this then the following should work - if you have a real 32 bit machine (look in the system profiler) then I have to play around with the compiler options and / or older versions of the libraries / the software. > > I downloaded the file gnupg-2.0.21.tar.bz2 (only to be sure that we talk about the same thing - isn?t meaned bad, maybe I talk about something different here), checked the integrity, extract it and run (I don?t use the autogen.sh script !) > > ./configure --sysconfdir=/etc --enable-maintainer-mode --enable-symcryptrun --enable-mailto > > as you wrote before. Configure told me the missing libraries (thanks to Werner to show also the path to the missing libraries and an explanation text about it !). I downloaded pth-2.0.7.tar.gz, libksba-1.3.0.tar.bz2, libassuan-2.1.1.tar.bz2, libgcrypt-1.5.3.tar.gz and libgpg-error-1.12.tar.gz (not in that order), extract it and installed (for every library the same commands) it using > > ./configure && make && sudo make install > > The libgpg-error-1.12.tar.gz should be the first to install because of some dependancies. After that I runned configure with your given options again and it builds fine. > > C. M. > > > Am 30.08.2013 um 09:58 schrieb Werner Koch : > >> On Fri, 30 Aug 2013 01:33, jake at spaz.org said: >>> I couldn't build gpgtar because of the error pasted here: >>> http://pastebin.com/ti4x1jL1 >> >> That's easy. Sone linker options are missing. I am currently fixinf >> this for master and will then do it for 2.0. Thanks for reporting. >> >>> I can also tell you that I could not build nls because of this: >>> http://pastebin.com/tJ1DS1dQ >> >> Other are more expereinced with OS X; the problem should be common >> because GnuPG uses the same gettext as all other software. >> >>> and because i couldn't install xfig (and fig2dev) i had to disable-doc >> >> A common complaint. Eventually I need to do something about it. I only >> wonder why a small and useful tool like xfig is not installed by >> default. >> >> >> Salam-Shalom, >> >> Werner >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> >> >> _______________________________________________ >> Gnupg-devel mailing list >> Gnupg-devel at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-devel From christoph_murauer at yahoo.de Sat Aug 31 09:35:54 2013 From: christoph_murauer at yahoo.de (Christoph Roland Murauer) Date: Sat, 31 Aug 2013 09:35:54 +0200 Subject: gpgtar not building on limited macos environment In-Reply-To: <87hae7pq2s.fsf@vigenere.g10code.de> References: <87txi8rjsc.fsf@vigenere.g10code.de> <87hae7pq2s.fsf@vigenere.g10code.de> Message-ID: Hy Jake ! Thanks for your detailed informations. I used a older Mac (Black MacBook) with a Intel Core 2 Due, a clean install of Snow Leopard 10.6.8 on it, Xcode 3.2 from the DVD (it is not really important, because I never launched it) including gcc version 4.2.1. You wrote 32 bit intel with Mac OS X 10.6.8 and thats the reason why I asked for details. In the machine I tried is a 64 bit CPU but Snow Leopard uses by default a 32 bit kernel and 32 bit extension BUT the unfair thing is, that gcc builds by default 64 bit software on this machine. If you also had a machine like this then the following should work - if you have a real 32 bit machine (look in the system profiler) then I have to play around with the compiler options and / or older versions of the libraries / the software. I downloaded the file gnupg-2.0.21.tar.bz2 (only to be sure that we talk about the same thing - isn?t meaned bad, maybe I talk about something different here), checked the integrity, extract it and run (I don?t use the autogen.sh script !) ./configure --sysconfdir=/etc --enable-maintainer-mode --enable-symcryptrun --enable-mailto as you wrote before. Configure told me the missing libraries (thanks to Werner to show also the path to the missing libraries and an explanation text about it !). I downloaded pth-2.0.7.tar.gz, libksba-1.3.0.tar.bz2, libassuan-2.1.1.tar.bz2, libgcrypt-1.5.3.tar.gz and libgpg-error-1.12.tar.gz (not in that order), extract it and installed (for every library the same commands) it using ./configure && make && sudo make install The libgpg-error-1.12.tar.gz should be the first to install because of some dependancies. After that I runned configure with your given options again and it builds fine. C. M. Am 30.08.2013 um 09:58 schrieb Werner Koch : > On Fri, 30 Aug 2013 01:33, jake at spaz.org said: >> I couldn't build gpgtar because of the error pasted here: >> http://pastebin.com/ti4x1jL1 > > That's easy. Sone linker options are missing. I am currently fixinf > this for master and will then do it for 2.0. Thanks for reporting. > >> I can also tell you that I could not build nls because of this: >> http://pastebin.com/tJ1DS1dQ > > Other are more expereinced with OS X; the problem should be common > because GnuPG uses the same gettext as all other software. > >> and because i couldn't install xfig (and fig2dev) i had to disable-doc > > A common complaint. Eventually I need to do something about it. I only > wonder why a small and useful tool like xfig is not installed by > default. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From jake at spaz.org Sat Aug 31 10:44:38 2013 From: jake at spaz.org (Jake) Date: Sat, 31 Aug 2013 01:44:38 -0700 (PDT) Subject: --pinentry-mode causes curses Message-ID: I am using alpine for a mail reader, and i recently integrated GPG support so I can read and send encrypted mail. I am using gpg (GnuPG) 2.0.21 I am also running screen, and alpine is running in one of the windows of screen. I believe it is a known issue that pinentry doesn't work with screen. Perhaps there is a way to fix that but I have been cacheing with gpg-preset-passphrase and that has been working. However, when the cache timeout happens, if I try to send an email gpg2 gets called and wants my passphrase. It calls pinentry. That creates problems for me. So I tried to use the parameter --pinentry-mode=cancel which would hopefully cause gpg2 to simply fail if my passphrase isn't cached, allowing me to gpg-preset-passphrase in another window and try again. However, it doesn't seem to be a recognized option at all. Note this is not the gnupg i compiled on my laptop, this is regular admin-installed gpg on a freeBSD system. I apologize if this is a RTFM type problem, or a known issue that simply is not a priority at this time. I just did a grep for pinentry-mode in the source code and found it only in the documentation. My best guess is that pinentry-mode is for unreleased version 2.1 and I should focus on other solutions to my unique problem. thank you, -jake [jake at pe2950 ~/bin]$ gpg --pinentry mode cancel gpg: Invalid option "--pinentry" [jake at pe2950 ~/bin]$ gpg2 --pinentry-mode=cancel gpg: invalid option "--pinentry-mode=cancel" [jake at pe2950 ~/bin]$ gpg2 --pinentry-mode=loopback FILE.gpg gpg: invalid option "--pinentry-mode=loopback" [jake at pe2950 ~/bin]$ gpg2 --version gpg (GnuPG) 2.0.21 libgcrypt 1.5.2 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 From jake at spaz.org Sat Aug 31 13:45:12 2013 From: jake at spaz.org (Jake) Date: Sat, 31 Aug 2013 04:45:12 -0700 (PDT) Subject: adding blind-signing to GnuPG Message-ID: I am working on a certified polling system, where a Central Registrar enables participation in the polling by signing the keys of eligible persons who have shown their credentials (such as a Photo ID) Because this system is for expression of political opinions in the context of Democracy, participants need to be guaranteed anonymity. They will generate a key-pair with a fake name, exclusively for use in this system. However, to guarantee anonymity even from the Central Registrar, it is necessary to use rsa blinding to obscure users' keys from the registrar during signing. Fortunately the cryptography to do this is already established, and is already in libgcrypt as rsa_blind() and rsa_unblind(), but those functions are not available to a regular user of gnupg. I want to add two functions to gnupg; blind and unblind. blind will take data, supplied by the user, and pass it to rsa_blind() along with a random number, and the public key of the target of the blind signing. the output of this operation will be a blinded version of the data, and a seperate file containing the modular multiplicative inverse of the random number used for the blinding. That seperate file will be automatically named according to the current date and time, and the filename of the unblinded data. after having the blinded data signed by the target (whose job is to sign indecipherable blobs of data, and whose key is used only for that), the user feeds that signed blinded data into unblind, along with the public key of the target and the file containing the modular multiplicative inverse... and the result is the signed data that the user wants. I would like to add these operations to gpg2 as --blind and --unblind, and to submit the implementation I create for review by the maintainers of gnupg. That approval (if i can earn it) will be very valuable to give legitimacy to the system I am creating, since GnuPG has a great reputation and great auditing. Please let me know what you think of this idea, and any advice you have for me about it. I know that there is a lot of work to do on GnuPG right now and that this is somewhat of a tangent from the common use of gpg, but I feel that it is very important and i'm prepared to do whatever work is necessary to make it happen. Thank you all for your time, -jake On Thu, 29 Aug 2013, Werner Koch wrote: > (...) > Before you put too much work into writing a patch, you may want to > describe the problem and discuss it with us. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >