From benjamin at py-soft.co.uk Tue Jan 3 12:28:45 2012 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Tue, 3 Jan 2012 11:28:45 +0000 Subject: ECC and smartcards Message-ID: Are there any plans to include ECC support within the OpenPGP Smartcard specification? If not, would a proposal be welcome? Take care, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Jan 3 15:29:55 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Jan 2012 15:29:55 +0100 Subject: ECC and smartcards In-Reply-To: (Benjamin Donnachie's message of "Tue, 3 Jan 2012 11:28:45 +0000") References: Message-ID: <87ipkskgf0.fsf@vigenere.g10code.de> On Tue, 3 Jan 2012 12:28, benjamin at py-soft.co.uk said: > Are there any plans to include ECC support within the OpenPGP Smartcard > specification? Achim planned to do so. However, we have not yet found the time to work it out. A main goal would be to make is easy to implement in GnuPG 2.1. > If not, would a proposal be welcome? Achim? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From benjamin at py-soft.co.uk Wed Jan 4 15:59:41 2012 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Wed, 4 Jan 2012 14:59:41 +0000 Subject: GnuPG 2.1 beta 3 released In-Reply-To: <87fwgf1a5y.fsf@vigenere.g10code.de> References: <87fwgf1a5y.fsf@vigenere.g10code.de> Message-ID: On 20 December 2011 16:26, Werner Koch wrote: > It is marked as a beta versions and the plan is to release a couple more > betas in the next months before we can declare 2.1.0 stable enough for > general use. Do you have a specific time frame in mind for the stable release? Take care, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Jan 4 16:33:17 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 04 Jan 2012 16:33:17 +0100 Subject: GnuPG 2.1 beta 3 released In-Reply-To: (Benjamin Donnachie's message of "Wed, 4 Jan 2012 14:59:41 +0000") References: <87fwgf1a5y.fsf@vigenere.g10code.de> Message-ID: <8739bvfpoi.fsf@vigenere.g10code.de> On Wed, 4 Jan 2012 15:59, benjamin at py-soft.co.uk said: > Do you have a specific time frame in mind for the stable release? No. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From alphazo at gmail.com Wed Jan 4 16:55:13 2012 From: alphazo at gmail.com (Alphazo) Date: Wed, 4 Jan 2012 16:55:13 +0100 Subject: Unable to compile GnuPG 2.1 beta 3 In-Reply-To: References: <8762haz0nk.fsf@vigenere.g10code.de> <87vcp9x0nq.fsf@vigenere.g10code.de> Message-ID: Was my backtrace of any help regarding the seg. fault I'm experiencing? On Wed, Dec 21, 2011 at 9:36 PM, Alphazo wrote: > here is the backtrace: > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff732e700 in ?? () from /lib/libgcrypt.so.11 > (gdb) bt full > > #0 ?0x00007ffff732e700 in ?? () from /lib/libgcrypt.so.11 > No symbol table info available. > #1 ?0x00007ffff72e6726 in ?? () from /lib/libgcrypt.so.11 > No symbol table info available. > #2 ?0x00007ffff72e7bfa in ?? () from /lib/libgcrypt.so.11 > No symbol table info available. > #3 ?0x00007ffff72e1ef2 in gcry_sexp_build () from /lib/libgcrypt.so.11 > No symbol table info available. > #4 ?0x0000000000425f7a in ?? () > No symbol table info available. > #5 ?0x000000000043703f in ?? () > No symbol table info available. > #6 ?0x000000000043833d in ?? () > No symbol table info available. > #7 ?0x0000000000438867 in ?? () > No symbol table info available. > #8 ?0x000000000040b19d in ?? () > No symbol table info available. > #9 ?0x00007ffff6b6114d in __libc_start_main () from /lib/libc.so.6 > No symbol table info available. > #10 0x000000000040c5ed in ?? () > No symbol table info available. > #11 0x00007fffffffe0b8 in ?? () > No symbol table info available. > #12 0x00000000ffffffff in ?? () > No symbol table info available. > #13 0x0000000000000003 in ?? () > No symbol table info available. > #14 0x00007fffffffe40f in ?? () > No symbol table info available. > #15 0x00007fffffffe41d in ?? () > No symbol table info available. > #16 0x00007fffffffe420 in ?? () > No symbol table info available. > #17 0x0000000000000000 in ?? () > No symbol table info available. > > > On Wed, Dec 21, 2011 at 7:03 PM, Werner Koch wrote: >> On Wed, 21 Dec 2011 15:19, alphazo at gmail.com said: >> >>> However I also received a seg. fault at the end: >>> >>> gpg: signal Segmentation fault caught ... exiting >>> [1] ? ?10610 segmentation fault ?gpg2 -v --list-keys >>> >>> Is this normal? >> >> Definitely no. ?Segfaults are bugs. ?Can you run it unter gdb and send a >> backtrace? >> >> ?gdb gpg2 >> ?gdb> run ?-v --list-keys >> ?gdb> # after it stops at the segv >> ?gdb> bt full >> >> >> Shalom-Salam, >> >> ? Werner >> >> -- >> Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. >> From gniibe at fsij.org Thu Jan 5 02:37:20 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 05 Jan 2012 10:37:20 +0900 Subject: pinpad entry support in Git repository In-Reply-To: <1324267157.1983.1.camel@latx1.gniibe.org> References: <1322802559.2589.9.camel@latx1.gniibe.org> <1324267157.1983.1.camel@latx1.gniibe.org> Message-ID: <1325727440.2060.1.camel@latx1.gniibe.org> Happy New Year, everyone! On 2011-12-19 at 12:59 +0900, NIIBE Yutaka wrote: > Thus, I wrote a python script. Attached is a program which tests PIN > entry using pinpad of card reader. It requires "Pyscard", smartcard > library for python. See http://pyscard.sourceforge.net/ for Pyscard. > > This test program assumes that OpenPGP card v2 is inserted to it. I updated the test program for pinpad entry. It is also renamed (with no hyphen in the filename). Attached is the newest version, which is also available at: http://www.gniibe.org/gitweb?p=gnuk.git;a=blob;f=tool/pinpadtest.py It is extensively tested with Vasco DIGIPASS 920. Note that the reader has firewall feature which doesn't allow VERIFY or CHANGE REFERENCE DATA command with data from host, but only allows pinpad entry by the reader. With no pinpad entry support, this reader were useless at all. It works well except --unblock --admin. I also tested with Gemalto's GemPC PinPad Smart Card Reader (08e6:3478) which has the firmware "GemTwRC2-V2.10-GL04". Unfortunately, it seems that this reader doesn't support variable length PIN. Please test your readers, it they come with pinpad. And let me know the result. Thanks again, in advance. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: pinpadtest.py Type: text/x-python Size: 14815 bytes Desc: not available URL: From gniibe at fsij.org Thu Jan 5 05:08:03 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 05 Jan 2012 13:08:03 +0900 Subject: Options for pinpad entry Message-ID: <1325736483.2060.3.camel@latx1.gniibe.org> While adding lower level support for pinpad entry, I am considering that it is better to have some user options for the feature. That's because: (1) Characters supported by pinpad is limited (usually it's only decimal digits). When your pass phrase include non-digit character, you can't verify with pinpad. (2) There are card readers which don't support variable length pass phrase. For those readers, the length of pass phrase should be known to host in advance. Currently, scdaemon has an option: --disable-keypad Even if a card reader features a keypad, do not try to use it. But this is not a command line option of GnuPG. For (1), --enable-keypad (or something) as a command line option would be good (and --disable-keypad for scdaemon will be not needed). For (2), --fixed-length-pin (or something) as a command line option would be good. And it assumes 6 characters for user's pass phrase and 8 characters for admin's pass phrase and reset code. Your comments are appreciated. -- From wk at gnupg.org Thu Jan 5 10:12:21 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 05 Jan 2012 10:12:21 +0100 Subject: Options for pinpad entry In-Reply-To: <1325736483.2060.3.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Thu, 05 Jan 2012 13:08:03 +0900") References: <1325736483.2060.3.camel@latx1.gniibe.org> Message-ID: <87k456ecne.fsf@vigenere.g10code.de> On Thu, 5 Jan 2012 05:08, gniibe at fsij.org said: > (1) Characters supported by pinpad is limited (usually it's only > decimal digits). When your pass phrase include non-digit > character, you can't verify with pinpad. I think we should have a check for a new PIN to make sure that it only has digits. agent/call-pinentry.c has even this code: if (!errtext && pininfo->min_digits) { /* do some basic checks on the entered PIN. */ if (!all_digitsp (pininfo->pin)) errtext = _("Invalid characters in PIN"); else if (pininfo->max_digits && strlen (pininfo->pin) > pininfo->max_digits) errtext = _("PIN too long"); else if (strlen (pininfo->pin) < pininfo->min_digits) errtext = _("PIN too short"); } Nowever I can't find a place were min_digits is set. This - now unused - check is there since 2002. > For (2), --fixed-length-pin (or something) as a command line option > would be good. And it assumes 6 characters for user's pass phrase > and 8 characters for admin's pass phrase and reset code. This should depend on the current application. The above values are good for OpenPGP cards but other cards may have different defaults. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jan 5 13:01:12 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 05 Jan 2012 13:01:12 +0100 Subject: Unable to compile GnuPG 2.1 beta 3 In-Reply-To: (alphazo@gmail.com's message of "Wed, 4 Jan 2012 16:55:13 +0100") References: <8762haz0nk.fsf@vigenere.g10code.de> <87vcp9x0nq.fsf@vigenere.g10code.de> Message-ID: <87mxa2cq9j.fsf@vigenere.g10code.de> On Wed, 4 Jan 2012 16:55, alphazo at gmail.com said: > Was my backtrace of any help regarding the seg. fault I'm experiencing? Well, not really. You probably stripped all debug infos when you installed GnuPG. The standard install procedure does not do this. You may want to try building GnuPG again and give the -g flag: make CFLAGS="-g" Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From alphazo at gmail.com Thu Jan 5 14:43:56 2012 From: alphazo at gmail.com (Alphazo) Date: Thu, 5 Jan 2012 14:43:56 +0100 Subject: Unable to compile GnuPG 2.1 beta 3 In-Reply-To: <87mxa2cq9j.fsf@vigenere.g10code.de> References: <8762haz0nk.fsf@vigenere.g10code.de> <87vcp9x0nq.fsf@vigenere.g10code.de> <87mxa2cq9j.fsf@vigenere.g10code.de> Message-ID: I recompiled gnupg2 with the mentioned CFLAGS="'g" option but didn't get much in the backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff732d700 in ?? () from /lib/libgcrypt.so.11 (gdb) bt full #0 0x00007ffff732d700 in ?? () from /lib/libgcrypt.so.11 No symbol table info available. #1 0x00007ffff72e5726 in ?? () from /lib/libgcrypt.so.11 No symbol table info available. #2 0x00007ffff72e6bfa in ?? () from /lib/libgcrypt.so.11 No symbol table info available. #3 0x00007ffff72e0ef2 in gcry_sexp_build () from /lib/libgcrypt.so.11 No symbol table info available. #4 0x000000000042abd1 in ?? () No symbol table info available. #5 0x000000000042f59f in ?? () No symbol table info available. #6 0x000000000043e283 in ?? () No symbol table info available. #7 0x0000000000440733 in ?? () No symbol table info available. #8 0x000000000043d3d7 in ?? () No symbol table info available. #9 0x000000000043c5f9 in ?? () No symbol table info available. #10 0x000000000040ca75 in ?? () No symbol table info available. #11 0x00007ffff6b4438d in __libc_start_main () from /lib/libc.so.6 No symbol table info available. #12 0x00000000004062f9 in ?? () No symbol table info available. #13 0x00007fffffffe0b8 in ?? () No symbol table info available. #14 0x00000000ffffffff in ?? () No symbol table info available. #15 0x0000000000000003 in ?? () No symbol table info available. #16 0x00007fffffffe40f in ?? () No symbol table info available. #17 0x00007fffffffe41d in ?? () No symbol table info available. #18 0x00007fffffffe420 in ?? () No symbol table info available. #19 0x0000000000000000 in ?? () No symbol table info available. alphazo On Thu, Jan 5, 2012 at 1:01 PM, Werner Koch wrote: > On Wed, ?4 Jan 2012 16:55, alphazo at gmail.com said: >> Was my backtrace of any help regarding the seg. fault I'm experiencing? > > Well, not really. ?You probably stripped all debug infos when you > installed GnuPG. ?The standard install procedure does not do this. ?You > may want to try building GnuPG again and give the -g flag: > > ?make CFLAGS="-g" > > > > Shalom-Salam, > > ? Werner > > -- > Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. > From alphazo at gmail.com Thu Jan 5 14:53:51 2012 From: alphazo at gmail.com (Alphazo) Date: Thu, 5 Jan 2012 14:53:51 +0100 Subject: Unable to compile GnuPG 2.1 beta 3 In-Reply-To: References: <8762haz0nk.fsf@vigenere.g10code.de> <87vcp9x0nq.fsf@vigenere.g10code.de> <87mxa2cq9j.fsf@vigenere.g10code.de> Message-ID: I meant witt the CFLAGS="-g". BTW, I tried to recompile libgcrypt with the same switch but it didn't help in providing more detailed messages. On Thu, Jan 5, 2012 at 2:43 PM, Alphazo wrote: > I recompiled gnupg2 with the mentioned CFLAGS="'g" option but didn't > get much in the backtrace: > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff732d700 in ?? () from /lib/libgcrypt.so.11 > (gdb) bt full > #0 ?0x00007ffff732d700 in ?? () from /lib/libgcrypt.so.11 > No symbol table info available. > #1 ?0x00007ffff72e5726 in ?? () from /lib/libgcrypt.so.11 > No symbol table info available. > #2 ?0x00007ffff72e6bfa in ?? () from /lib/libgcrypt.so.11 > No symbol table info available. > #3 ?0x00007ffff72e0ef2 in gcry_sexp_build () from /lib/libgcrypt.so.11 > No symbol table info available. > #4 ?0x000000000042abd1 in ?? () > No symbol table info available. > #5 ?0x000000000042f59f in ?? () > No symbol table info available. > #6 ?0x000000000043e283 in ?? () > No symbol table info available. > #7 ?0x0000000000440733 in ?? () > No symbol table info available. > #8 ?0x000000000043d3d7 in ?? () > No symbol table info available. > #9 ?0x000000000043c5f9 in ?? () > No symbol table info available. > #10 0x000000000040ca75 in ?? () > No symbol table info available. > #11 0x00007ffff6b4438d in __libc_start_main () from /lib/libc.so.6 > No symbol table info available. > #12 0x00000000004062f9 in ?? () > No symbol table info available. > #13 0x00007fffffffe0b8 in ?? () > No symbol table info available. > #14 0x00000000ffffffff in ?? () > No symbol table info available. > #15 0x0000000000000003 in ?? () > No symbol table info available. > #16 0x00007fffffffe40f in ?? () > No symbol table info available. > #17 0x00007fffffffe41d in ?? () > No symbol table info available. > #18 0x00007fffffffe420 in ?? () > No symbol table info available. > #19 0x0000000000000000 in ?? () > No symbol table info available. > > alphazo > > On Thu, Jan 5, 2012 at 1:01 PM, Werner Koch wrote: >> On Wed, ?4 Jan 2012 16:55, alphazo at gmail.com said: >>> Was my backtrace of any help regarding the seg. fault I'm experiencing? >> >> Well, not really. ?You probably stripped all debug infos when you >> installed GnuPG. ?The standard install procedure does not do this. ?You >> may want to try building GnuPG again and give the -g flag: >> >> ?make CFLAGS="-g" >> >> >> >> Shalom-Salam, >> >> ? Werner >> >> -- >> Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. >> From siva.ityouth at gmail.com Thu Jan 5 16:34:20 2012 From: siva.ityouth at gmail.com (siva reddy) Date: Thu, 5 Jan 2012 21:04:20 +0530 Subject: GNUPG Vs MacAfee 7.1 E business server : Bad signature, doesn't match file contents! Message-ID: Hi Team, Issue: I imported both encryption key and signing key from MacFee 7.1 e-business server into GNUPG 1.4. I encryt and signing with the new key which I imported. The problem Is: When decrypt message in MacAFee 7.1 it showing warning message as Bad Signature does not match file contents. Please see the output when I decrypt in Macfee 7.1 McAfee E-Business Server v7.1.1 - Full License (c) 1991-2002 Network Associates, Inc. All Rights Reserved. Warning: Using insecure memory! Opening keyring files: /entsys/.pgp/pubring.pkr /entsys/.pgp/secring.skr Decoding data.... event 1: initial event 13: BeginLex event 8: Analyze File is encrypted. event 9: Recipients Secret key is required to read it. Key for user ID "Entsys " event 6: Passphrase event 23: Decryption symmetric cipher used: CAST5 event 11: Output options typecode: 0062 suggested name: test.dat tempfile: created 'pgptemp.$0000' event 12: Signature WARNING: Bad signature, doesn't match file contents! Bad signature from user "Entsys ". event 14: EndLex event 2: final Done. Output file 'test' already exists. Overwrite (y/N)? y savetemp: renaming 'pgptemp.$0000' to 'test' exitcode = 0 Could you please help me why it is giving bad signature message? Any Help Greatly appreciated!!!! From wk at gnupg.org Fri Jan 6 14:22:51 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 06 Jan 2012 14:22:51 +0100 Subject: Shall we do a 1.4.12 ? Message-ID: <87ehvd7yok.fsf@vigenere.g10code.de> Hi, the last 1.4 release is more than a year old (2010-10-08). The repo has collected a few minor bug fixes and small enhancements. Shall I do a new release next week? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From alphazo at gmail.com Fri Jan 6 14:29:41 2012 From: alphazo at gmail.com (Alphazo) Date: Fri, 6 Jan 2012 14:29:41 +0100 Subject: Shall we do a 1.4.12 ? In-Reply-To: <87ehvd7yok.fsf@vigenere.g10code.de> References: <87ehvd7yok.fsf@vigenere.g10code.de> Message-ID: I vote yes for a 1.4.2 release if you include ECC support in it ;) On Fri, Jan 6, 2012 at 2:22 PM, Werner Koch wrote: > Hi, > > the last 1.4 release is more than a year old (2010-10-08). ?The repo has > collected a few minor bug fixes and small enhancements. ?Shall I do a > new release next week? > > > Shalom-Salam, > > ? 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 dkg at fifthhorseman.net Fri Jan 6 15:33:38 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 06 Jan 2012 09:33:38 -0500 Subject: Shall we do a 1.4.12 ? In-Reply-To: <87ehvd7yok.fsf@vigenere.g10code.de> References: <87ehvd7yok.fsf@vigenere.g10code.de> Message-ID: <4F070642.4010801@fifthhorseman.net> On 01/06/2012 08:22 AM, Werner Koch wrote: > the last 1.4 release is more than a year old (2010-10-08). The repo has > collected a few minor bug fixes and small enhancements. Shall I do a > new release next week? Yes, please! That would be much appreciated. Thanks for all your work on GnuPG, Werner. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Fri Jan 6 16:50:09 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 6 Jan 2012 10:50:09 -0500 Subject: Shall we do a 1.4.12 ? In-Reply-To: <87ehvd7yok.fsf@vigenere.g10code.de> References: <87ehvd7yok.fsf@vigenere.g10code.de> Message-ID: <87DD740E-BB6B-4EDA-A789-752269298D50@jabberwocky.com> On Jan 6, 2012, at 8:22 AM, Werner Koch wrote: > Hi, > > the last 1.4 release is more than a year old (2010-10-08). The repo has > collected a few minor bug fixes and small enhancements. Shall I do a > new release next week? I'm very much in favor of doing a new 1.4.x. One thought - perhaps to wait a day or two until the question about allowing spaces in fingerprints (for -r and the like) is resolved. It would be nice if 1.4.x and 2.x could both accept fingerprints in the same way so that advice and howtos given for one version are applicable to both. David From sms at antinode.info Fri Jan 6 15:14:35 2012 From: sms at antinode.info (Steven M. Schweda) Date: Fri, 6 Jan 2012 08:14:35 -0600 (CST) Subject: Shall we do a 1.4.12 ? Message-ID: <12010608143529_20207B56@antinode.info> From: Werner Koch > the last 1.4 release is more than a year old (2010-10-08). The repo has > collected a few minor bug fixes and small enhancements. Shall I do a > new release next week? Ok with me. Below are the VMS-related changes to the main code since 1.4.11. I think that most of them are old (type casts to avoid %CC-I-QUESTCOMPARE1 complaints), but the changes to g10/gpg.c and util/ttyio.c may be new. The idea in g10/gpg.c is to default to --batch when running in a VMS batch job. The changes to util/ttyio.c are intended to defeat an infinite loop in a VMS batch job, which I believe was reported here before. (One of the victims reported this problem. Amazingly enough, there seem to be some actual, real-world users of this stuff on VMS. Setting --batch automatically helps, but doesn't cover every case.) --- g10/encr-data.c_orig 2008-12-11 10:40:05 -0600 +++ g10/encr-data.c 2010-10-18 12:01:56 -0500 @@ -298,7 +298,7 @@ if( control == IOBUFCTRL_UNDERFLOW ) { assert(a); n = iobuf_read( a, buf, size ); - if( n == -1 ) n = 0; + if( n == (size_t)-1 ) n = 0; if( n ) { if (fc->cipher_hd) cipher_decrypt( fc->cipher_hd, buf, buf, n); --- g10/gpg.c_orig 2010-07-05 04:17:37 -0500 +++ g10/gpg.c 2011-09-08 13:37:06 -0500 @@ -40,6 +40,10 @@ #include #endif +#ifdef __VMS +# include "vms.h" +#endif + #define INCLUDED_BY_MAIN_MODULE 1 #include "packet.h" #include "iobuf.h" @@ -1872,6 +1876,14 @@ opt.lock_once = 1; #endif /* __riscos__ */ +#ifdef __VMS + /* On VMS, set the default value of the "--[no-]batch" flag + * according to the actual process mode. The user can override this + * with an explicit command-line "--[no-]batch" option. + */ + opt.batch = batch_mode_vms(); +#endif + reopen_std(); trap_unaligned(); secmem_set_flags( secmem_get_flags() | 2 ); /* suspend warnings */ --- g10/trustdb.c_orig 2009-12-21 08:34:19 -0600 +++ g10/trustdb.c 2010-10-18 12:05:13 -0500 @@ -2343,7 +2343,7 @@ { k->ownertrust = ask_ownertrust (k->kid,min); - if (k->ownertrust == -1) + if (k->ownertrust == (unsigned int)-1) { quit=1; goto leave; --- util/ttyio.c_orig 2010-09-28 04:39:05 -0500 +++ util/ttyio.c 2012-01-06 08:03:12 -0600 @@ -185,7 +185,9 @@ #else ttyfp = batchmode? stderr : fopen( tty_get_ttyname (), "r+"); if( !ttyfp ) { - log_error("cannot open `%s': %s\n", + ttyfp = stderr; /* Fall-back for failing fopen(). */ + initialized = 1; /* Don't come back again, ever. */ + log_error("cannot open tty, `%s': %s\n", tty_get_ttyname (), strerror(errno) ); exit(2); } Thanks again for including the VMS-related changes in the main code stream. Wake me if you have any questions or complaints. ------------------------------------------------------------------------ Steven M. Schweda sms at antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 From rose-indorf at gmx.de Fri Jan 6 23:42:45 2012 From: rose-indorf at gmx.de (Sebastian Rose-Indorf) Date: Fri, 6 Jan 2012 23:42:45 +0100 Subject: AW: Shall we do a 1.4.12 ? In-Reply-To: <87ehvd7yok.fsf@vigenere.g10code.de> References: <87ehvd7yok.fsf@vigenere.g10code.de> Message-ID: <002401ccccc4$82b79f30$8826dd90$@de> Hello, > a new release next week? Best of course with ECC ;-) - but with or without: This would be very good! Sebastian From wk at gnupg.org Sat Jan 7 18:45:03 2012 From: wk at gnupg.org (Werner Koch) Date: Sat, 07 Jan 2012 18:45:03 +0100 Subject: Shall we do a 1.4.12 ? In-Reply-To: <87DD740E-BB6B-4EDA-A789-752269298D50@jabberwocky.com> (David Shaw's message of "Fri, 6 Jan 2012 10:50:09 -0500") References: <87ehvd7yok.fsf@vigenere.g10code.de> <87DD740E-BB6B-4EDA-A789-752269298D50@jabberwocky.com> Message-ID: <87mx9z76g0.fsf@vigenere.g10code.de> On Fri, 6 Jan 2012 16:50, dshaw at jabberwocky.com said: > I'm very much in favor of doing a new 1.4.x. One thought - perhaps to > wait a day or two until the question about allowing spaces in > fingerprints (for -r and the like) is resolved. It would be nice if I hoped that we can avoid it. But well okay. I'll backport it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From thijs at debian.org Sat Jan 7 18:20:47 2012 From: thijs at debian.org (Thijs Kinkhorst) Date: Sat, 7 Jan 2012 18:20:47 +0100 Subject: Shall we do a 1.4.12 ? In-Reply-To: <87ehvd7yok.fsf@vigenere.g10code.de> References: <87ehvd7yok.fsf@vigenere.g10code.de> Message-ID: <5ddf708aa381589c663d50f8ce7f3024.squirrel@wm.kinkhorst.nl> On Fri, January 6, 2012 14:22, Werner Koch wrote: > the last 1.4 release is more than a year old (2010-10-08). The repo has > collected a few minor bug fixes and small enhancements. Shall I do a > new release next week? >From a Debian standpoint this would be much appreciated. We're in the middle of a release cycle now, so now is an excellent moment to be uploading a new release. It would be good to bring the bug fixes and enhancements to the users, even if not critical. thanks, Thijs From g.esp at free.fr Sat Jan 7 22:59:19 2012 From: g.esp at free.fr (Gilles Espinasse) Date: Sat, 7 Jan 2012 22:59:19 +0100 Subject: [PATCH] Fix desktop-devel-list archive link Message-ID: <1325973559-1773-1-git-send-email-g.esp@free.fr> Add the missing dot Signed-off-by: Gilles Espinasse --- scripts/autogen.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/scripts/autogen.sh b/scripts/autogen.sh index c58afbf..408f760 100755 --- a/scripts/autogen.sh +++ b/scripts/autogen.sh @@ -268,7 +268,7 @@ if [ -d .git ]; then cat <&2 *** Activating trailing whitespace git pre-commit hook. *** For more information see this thread: - http://mail.gnome.org/archives/desktop-devel-list/2009-May/msg00084html + http://mail.gnome.org/archives/desktop-devel-list/2009-May/msg00084.html To deactivate this pre-commit hook again move .git/hooks/pre-commit and .git/hooks/pre-commit.sample out of the way. EOF -- 1.5.6.5 From g.esp at free.fr Sun Jan 8 23:36:40 2012 From: g.esp at free.fr (Gilles Espinasse) Date: Sun, 8 Jan 2012 23:36:40 +0100 Subject: Shall we do a 1.4.12 ? References: <87ehvd7yok.fsf@vigenere.g10code.de> Message-ID: <1b7f01ccce55$fe7a6d40$f9b5a8c0@pii350> ----- Original Message ----- From: "Werner Koch" To: Sent: Friday, January 06, 2012 2:22 PM Subject: Shall we do a 1.4.12 ? > Hi, > > the last 1.4 release is more than a year old (2010-10-08). The repo has > collected a few minor bug fixes and small enhancements. Shall I do a > new release next week? > > > Shalom-Salam, > > Werner > Tested using git tree with ./configure --prefix=/usr --build=i486-linux-gnu --disable-nls --enable-mini mal -enable-noexecstack --enable-maintainer-mode this compile and produce =================== All 27 tests passed =================== I spotted a few gliches Like with 1.4.11, without setting in the environment LDFLAGS += -pie it fail to compile using hardened compiler with this error gcc -Os -march=i486 -mtune=pentium -pipe -fomit-frame-pointer -Wall -Wcast- align -Wshadow -Wstrict-prototypes -Wformat-nonliteral -Wno-pointer-sign -W l,--hash-style=gnu -o mpicalc mpicalc.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. The compiler I use is gcc-4.4.5 modified with hardening by default, reason why you don't see -fPIE. I could live setting LDFLAGS Compilation produce those new warnings, not seen in 1.4.11 miscutil.c:238: warning: format not a string literal, format string not checked estream-printf.c:1056: warning: format not a string literal, argument types not checked estream-printf.c:1059: warning: format not a string literal, argument types not checked so something is wrong, not yet understood what Looking at miscutil.c, I checked the define in config.h and found #define HAVE_STRFTIME 1 #define HAVE_NL_LANGINFO 1 LANG is not set inside the chroot Same warnings happen if not using --disable-nls The last thing I find is that clock_gettime syscall is not found in gnupg and libgcrypt despite it is found by a small majority of other packages (glibc-2.11.3 is in chroot). Looking at the compilation log : grep -r clock_gettime log_i486 | grep yes log_i486/02_base/gzip-1.4:checking for clock_gettime... yes log_i486/02_base/diffutils-3.2:checking for clock_gettime... yes log_i486/02_base/tar-1.26:checking for clock_gettime... yes log_i486/02_base/coreutils-8.14:checking for clock_gettime... yes log_i486/02_base/findutils-4.4.2:checking for clock_gettime... yes log_i486/03_ipcop/cairo-1.10.2:checking for clock_gettime... yes log_i486/03_ipcop/glib-2.26.1:checking for clock_gettime in -lrt... yes log_i486/03_ipcop/libusb-1.0.8:checking for clock_gettime in -lrt... yes log_i486/03_ipcop/ntp-4.2.6p5:checking for clock_gettime... yes log_i486/03_ipcop/cpio-2.11:checking for clock_gettime... yes log_i486/03_ipcop/wget-1.13.4:checking for clock_gettime... yes log_i486/03_ipcop/wget-1.13.4:checking for clock_gettime... (cached) yes grep -r clock_gettime log_i486 | grep no log_i486/02_base/rsyslog-5.8.6:checking for clock_gettime... no log_i486/02_base/gmp-5.0.2:checking for clock_gettime... no log_i486/03_ipcop/db-4.8.30:checking for clock_gettime... no log_i486/03_ipcop/db-4.8.30:checking for clock_gettime monotonic clock... no log_i486/03_ipcop/libgcrypt-1.4.6:checking for clock_gettime... no log_i486/03_ipcop/glib-2.26.1:checking for clock_gettime... no log_i486/03_ipcop/lzo-2.04:checking for clock_gettime... no Using AC_CHECK_FUNCS for clock_gettime is not enought as a test should be made with -lrt Gilles From achim at pietig.com Mon Jan 9 09:42:16 2012 From: achim at pietig.com (Achim Pietig) Date: Mon, 09 Jan 2012 09:42:16 +0100 Subject: ECC and smartcards In-Reply-To: <87ipkskgf0.fsf@vigenere.g10code.de> References: <87ipkskgf0.fsf@vigenere.g10code.de> Message-ID: <4F0AA868.4020905@pietig.com> Hi, I was on vacation, sorry for my late answer... Yes, ECC is planned for the next OpenPGP smart card specification. I had several discussions on this topic with Werner, but we found no time to finalise it. Main problem at the moment is that the OpenPGP white paper for ECC is basing on NIST curves. All available cards in Europe (my test samples etc.) support Brainpool only, because Brainpool is the comming standard in most smart card standards like ISO and CEN. Regards, Achim Am 03.01.2012 15:29, schrieb Werner Koch: > On Tue, 3 Jan 2012 12:28, benjamin at py-soft.co.uk said: >> Are there any plans to include ECC support within the OpenPGP Smartcard >> specification? > > Achim planned to do so. However, we have not yet found the time to work > it out. A main goal would be to make is easy to implement in GnuPG 2.1. > >> If not, would a proposal be welcome? > > Achim? > > > Salam-Shalom, > > Werner > From wk at gnupg.org Mon Jan 9 09:50:34 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Jan 2012 09:50:34 +0100 Subject: ECC and smartcards In-Reply-To: <4F0AA868.4020905@pietig.com> (Achim Pietig's message of "Mon, 09 Jan 2012 09:42:16 +0100") References: <87ipkskgf0.fsf@vigenere.g10code.de> <4F0AA868.4020905@pietig.com> Message-ID: <874nw55kf9.fsf@vigenere.g10code.de> On Mon, 9 Jan 2012 09:42, achim at pietig.com said: > Main problem at the moment is that the OpenPGP white paper for ECC is basing on NIST curves. > All available cards in Europe (my test samples etc.) support Brainpool only, because Brainpool Actually this is not a problem. ECC for OpenPGP allows the use of arbitrary curves. Libgcrypt support the relevant Brainpool curves. It is just a matter of UI design in GPG to select a curve. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ott at mirix.org Mon Jan 9 10:33:19 2012 From: ott at mirix.org (Matthias-Christian Ott) Date: Mon, 9 Jan 2012 10:33:19 +0100 Subject: ECC and smartcards In-Reply-To: <4F0AA868.4020905@pietig.com> References: <87ipkskgf0.fsf@vigenere.g10code.de> <4F0AA868.4020905@pietig.com> Message-ID: <20120109093319.GA2267@qp> On Mon, Jan 09, 2012 at 09:42:16AM +0100, Achim Pietig wrote: > Main problem at the moment is that the OpenPGP white paper for ECC is basing on NIST curves. > All available cards in Europe (my test samples etc.) support Brainpool only, because Brainpool > is the comming standard in most smart card standards like ISO and CEN. Java Card 2.2.2 should be able to do both ECDSA and ECDH. The NXP J2A040 and J2A080 support up to 320 bit curves (not yet tested) and are available in Europe. Regards, Matthias-Christian From ott at mirix.org Mon Jan 9 15:11:01 2012 From: ott at mirix.org (Matthias-Christian Ott) Date: Mon, 9 Jan 2012 15:11:01 +0100 Subject: ECC and smartcards In-Reply-To: <874nw55kf9.fsf@vigenere.g10code.de> References: <87ipkskgf0.fsf@vigenere.g10code.de> <4F0AA868.4020905@pietig.com> <874nw55kf9.fsf@vigenere.g10code.de> Message-ID: <20120109141100.GC2542@qp> On Mon, Jan 09, 2012 at 09:50:34AM +0100, Werner Koch wrote: > On Mon, 9 Jan 2012 09:42, achim at pietig.com said: > > > Main problem at the moment is that the OpenPGP white paper for ECC is basing on NIST curves. > > All available cards in Europe (my test samples etc.) support Brainpool only, because Brainpool > > Actually this is not a problem. ECC for OpenPGP allows the use of > arbitrary curves. Libgcrypt support the relevant Brainpool curves. It > is just a matter of UI design in GPG to select a curve. The current RFC draft (you are probably aware of it) only specifies OIDs for NIST curves and mandates support for NIST P-256 [1]. Though it might be possible to support other curves, it seems likely that (at least) P-256 will be the best choice for interoperability. Regards, Matthias-Christian [1] https://tools.ietf.org/html/draft-jivsov-openpgp-ecc-08 From wk at gnupg.org Mon Jan 9 16:42:05 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Jan 2012 16:42:05 +0100 Subject: ECC and smartcards In-Reply-To: <20120109141100.GC2542@qp> (Matthias-Christian Ott's message of "Mon, 9 Jan 2012 15:11:01 +0100") References: <87ipkskgf0.fsf@vigenere.g10code.de> <4F0AA868.4020905@pietig.com> <874nw55kf9.fsf@vigenere.g10code.de> <20120109141100.GC2542@qp> Message-ID: <8739bo51de.fsf@vigenere.g10code.de> On Mon, 9 Jan 2012 15:11, ott at mirix.org said: > The current RFC draft (you are probably aware of it) only specifies > OIDs for NIST curves and mandates support for NIST P-256 [1]. Though There is no need to specify an OID. You may simply use a different curved than those which will be in the RFC. The problem is that the IETF is very US centric and thus they want US stuff. However no curve is excluded (MUST NOT) and thus we will simply set a de-facto standard by using a subset of the Brainpool OIDs. That is much easier than endless discussions on the benefits of certain algorithms. We have the very same issue with the supported algorithm sizes. OpenPGP does not specify that either. > it might be possible to support other curves, it seems likely that > (at least) P-256 will be the best choice for interoperability. This is purely a political thing; let them do what they want. I am pretty sure that we have good control over what will be used in the end ;-). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ott at mirix.org Mon Jan 9 18:57:22 2012 From: ott at mirix.org (Matthias-Christian Ott) Date: Mon, 9 Jan 2012 18:57:22 +0100 Subject: ECC and smartcards In-Reply-To: <8739bo51de.fsf@vigenere.g10code.de> References: <87ipkskgf0.fsf@vigenere.g10code.de> <4F0AA868.4020905@pietig.com> <874nw55kf9.fsf@vigenere.g10code.de> <20120109141100.GC2542@qp> <8739bo51de.fsf@vigenere.g10code.de> Message-ID: <20120109175213.GA2422@qp> On Mon, Jan 09, 2012 at 04:42:05PM +0100, Werner Koch wrote: > On Mon, 9 Jan 2012 15:11, ott at mirix.org said: > > > The current RFC draft (you are probably aware of it) only specifies > > OIDs for NIST curves and mandates support for NIST P-256 [1]. Though > > There is no need to specify an OID. You may simply use a different > curved than those which will be in the RFC. The problem is that the > IETF is very US centric and thus they want US stuff. However no curve > is excluded (MUST NOT) and thus we will simply set a de-facto standard > by using a subset of the Brainpool OIDs. That is much easier than > endless discussions on the benefits of certain algorithms. We have the > very same issue with the supported algorithm sizes. OpenPGP does not > specify that either. I'm not against that. Maybe the thing we can take out of this discussion is that, the specification should allow multiple curves and curve formats to be supported (similar to the RSA key sizes in current specification) and perhaps there could be an option ?user defined? or something similar which allows you to set the parameters yourself. > > it might be possible to support other curves, it seems likely that > > (at least) P-256 will be the best choice for interoperability. > > This is purely a political thing; let them do what they want. I am > pretty sure that we have good control over what will be used in the end > ;-). Well, we'll talk about this in ten years ;). But considering the current state of X.509 it maybe commercially worthwhile to support the standard and the specified profiles required for certain contracts in the future. Regards, Matthias-Christian From wk at gnupg.org Mon Jan 9 19:20:46 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 09 Jan 2012 19:20:46 +0100 Subject: ECC and smartcards In-Reply-To: <20120109175213.GA2422@qp> (Matthias-Christian Ott's message of "Mon, 9 Jan 2012 18:57:22 +0100") References: <87ipkskgf0.fsf@vigenere.g10code.de> <4F0AA868.4020905@pietig.com> <874nw55kf9.fsf@vigenere.g10code.de> <20120109141100.GC2542@qp> <8739bo51de.fsf@vigenere.g10code.de> <20120109175213.GA2422@qp> Message-ID: <87obuc3fgh.fsf@vigenere.g10code.de> On Mon, 9 Jan 2012 18:57, ott at mirix.org said: > I'm not against that. Maybe the thing we can take out of this > discussion is that, the specification should allow multiple curves > and curve formats to be supported (similar to the RSA key sizes in I does. > current specification) and perhaps there could be an option ?user > defined? or something similar which allows you to set the parameters I has one. You only have to map it to an OID. > state of X.509 it maybe commercially worthwhile to support the standard > and the specified profiles required for certain contracts in the future. For Symantec it makes a lot of sense to support SuiteB. For GnuPG we don't need to care. Well, unless someone pays for it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Tue Jan 10 01:30:28 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 10 Jan 2012 00:30:28 +0000 Subject: gpg refusing to sign bug? Message-ID: Dear List, I *think* this is a bug, but it might be expected behaviour. Steps to reproduce: Using gpg 2.0.18 Sign a UID of a key with a local signature. Revoke the signature Sign the UID of the key again - GPG complains that the key is already signed and refuses to issue a new signature. I would have expected that since there is no currently valid signature, gpg would have been prepared to issue a new signature. Am I correct that this is a bug? Nicholas From wk at gnupg.org Tue Jan 10 10:17:31 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Jan 2012 10:17:31 +0100 Subject: Shall we do a 1.4.12 ? In-Reply-To: <12010608143529_20207B56@antinode.info> (Steven M. Schweda's message of "Fri, 6 Jan 2012 08:14:35 -0600 (CST)") References: <12010608143529_20207B56@antinode.info> Message-ID: <87vcoj29xw.fsf@vigenere.g10code.de> On Fri, 6 Jan 2012 15:14, sms at antinode.info said: > Ok with me. Below are the VMS-related changes to the main code since > 1.4.11. I think that most of them are old (type casts to avoid I just checked: The are all in the GIT repository. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jan 10 10:19:02 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Jan 2012 10:19:02 +0100 Subject: Shall we do a 1.4.12 ? In-Reply-To: <5ddf708aa381589c663d50f8ce7f3024.squirrel@wm.kinkhorst.nl> (Thijs Kinkhorst's message of "Sat, 7 Jan 2012 18:20:47 +0100") References: <87ehvd7yok.fsf@vigenere.g10code.de> <5ddf708aa381589c663d50f8ce7f3024.squirrel@wm.kinkhorst.nl> Message-ID: <87r4z729vd.fsf@vigenere.g10code.de> On Sat, 7 Jan 2012 18:20, thijs at debian.org said: >>From a Debian standpoint this would be much appreciated. We're in the > middle of a release cycle now, so now is an excellent moment to be > uploading a new release. It would be good to bring the bug fixes and Actually, I would love to see gpg being replaced by gpg2 (maybe except for udeb). I guess we have to wait for 2.1, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From branko at majic.rs Tue Jan 10 09:45:07 2012 From: branko at majic.rs (=?UTF-8?Q?=D0=91=D1=80=D0=B0=D0=BD=D0=BA=D0=BE_=D0=9C=D0=B0=D1=98?= =?UTF-8?Q?=D0=B8=D1=9B?=) Date: Tue, 10 Jan 2012 09:45:07 +0100 Subject: FOSDEM 2012, Hardware Security and Cryptography, Call for Papers Message-ID: <0a22daf3ae4c2dada3a90690acd1737f@majic.rs> AKA "Protect your privates!" FOSDEM 2012 will [1] take place in Brussels, the heart of EU. In 2012, as almost all EU countries have either ongoing rollouts of national eID cards or are planning it, many people will find yet another smartcard in their wallet. Cards that don't contain virtual credit but private keys and certificates that can be used for many purposes in the online world. FOSS has an important role in the overall eID infrastructure, either on the server side inside Apache's mod_ssl, on the client computer inside Firefox as OpenSC PKCS#11 module or hidden in the infrastructure, issuing the certificates from an EJBCA server, which is administered over SSH. Security in the online world matters and one the most common tools for it is cryptography and PKI. The chain is as strong as its weakest link and for PKI, the security of private keys matters. The integrated and widespread nature of PKI implementation makes it difficult to get it perfect, but one must not stop trying. Do you develop software that can do HTTPS queries? Can it use keys and certificates on a smart card? Does your service use RSA keys for signing? Can it work with hardware keys? Are you interested in protecting your private keys like Three Letter Organizations or do you want to roll your own proper PKI with a smaller than five or six digit budget? How can we make cryptographic hardware Just Work with any application that uses crypto? The devroom is the place to share experiences and learn. This is a call for talks and presentations that will take place in the Security devroom at FOSDEM 2012. Security / hardware crytpo devroom will take place on Saturday, 04.02.2012. The exact room still hasn't been specified by the organisers. The workshop should take place on Sunday, 05.02.2012, and should include demonstration and hacking sessions. The expected audience will range from crypto library developers to desktop GUI creators, from hardware driver makers to business software providers. Two main themes are cross-application (hardware) interoperability and user awareness/education, but if you have anything interesting to share that deals with security or cryptography, don't be bounded by the main topic. Don't be limited with a traditional "presentation and questions" format, hands-on workshop format is also welcome. HOWTO: 1. Subscribe to security-devroom at lists.fosdem.org [2] 2. Send a short talk description, its duration, your bio/affiliation and contact information to the list and/or add it directly to the OpenSC wiki [3]. a) There are 5 up to 1 hour slots (with 10 minutes for Q&A and 5 minutes for organizational time included, so 45 minutes max for a talk) b) You don't have to fill the entire slot, 30 minute slots with ~20+5+5 minutes format are also OK c) FOSDEM is for FOSS developers, keep this in mind when planning your talk. 3. The deadline for submissions is 20.01.2012 23:00 UTC 4. The final schedule for the day will be fixed no later than 25.01.2012 5. If there will be more submissions than there are time slots, then: a) you may be asked to jam your presentation into a shorter (20 minutes) format b) the final list will be fixed by subscribers of security-devroom at lists.fosdem.org list Please forward this announcement to any relevant FOSS project mailing lists you're subscribed to. [1] https://fosdem.org/2012/ [2] https://lists.fosdem.org/mailman/listinfo/security-devroom [3] https://www.opensc-project.org/opensc/wiki/FOSDEM2012 -- Branko Majic Jabber: branko at majic.rs Please use only Free formats when sending attachments to me. ?????? ????? ?????: branko at majic.rs ????? ??? ?? ??????? ?????? ????????? ? ????????? ?????????. From wk at gnupg.org Tue Jan 10 11:36:03 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 10 Jan 2012 11:36:03 +0100 Subject: Shall we do a 1.4.12 ? In-Reply-To: <1b7f01ccce55$fe7a6d40$f9b5a8c0@pii350> (Gilles Espinasse's message of "Sun, 8 Jan 2012 23:36:40 +0100") References: <87ehvd7yok.fsf@vigenere.g10code.de> <1b7f01ccce55$fe7a6d40$f9b5a8c0@pii350> Message-ID: <87mx9v26b0.fsf@vigenere.g10code.de> On Sun, 8 Jan 2012 23:36, g.esp at free.fr said: > /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. > > The compiler I use is gcc-4.4.5 modified with hardening by default, reason If you want to get rid of this warning, please help to track it down. > Compilation produce those new warnings, not seen in 1.4.11 > miscutil.c:238: warning: format not a string literal, format string not > checked > estream-printf.c:1056: warning: format not a string literal, argument types > not checked > estream-printf.c:1059: warning: format not a string literal, argument types > not checked > so something is wrong, not yet understood what Well, we request a warning when using a non-literal in a format. However at that places we retrieve or create our format string and thus we will be warned. For gcc 4.6 I added a pragma to suppress thes warnings. > Using AC_CHECK_FUNCS for clock_gettime is not enought as a test should be > made with -lrt I am now looking at this. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Tue Jan 10 17:05:37 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 10 Jan 2012 16:05:37 +0000 Subject: Unable to compile GnuPG 2.1 beta 3 In-Reply-To: References: <8762haz0nk.fsf@vigenere.g10code.de> <87vcp9x0nq.fsf@vigenere.g10code.de> <87mxa2cq9j.fsf@vigenere.g10code.de> Message-ID: I'm running into a different error compiling (also on OS X): [snipped earlier errors] Making all in agent gcc -DHAVE_CONFIG_H -I. -I.. -I../gl -I../common -I../intl -DLOCALEDIR=\"/opt/gnupg2.1beta3/share/locale\" -DGNUPG_BINDIR="\"/opt/gnupg2.1beta3/bin\"" -DGNUPG_LIBEXECDIR="\"/opt/gnupg2.1beta3/libexec\"" -DGNUPG_LIBDIR="\"/opt/gnupg2.1beta3/lib/gnupg\"" -DGNUPG_DATADIR="\"/opt/gnupg2.1beta3/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/opt/gnupg2.1beta3/etc/gnupg\"" -DGNUPG_LOCALSTATEDIR="\"/opt/gnupg2.1beta3/var\"" -I/sw/include -I/sw/include -I/usr/local/include -I/sw/include -I/sw/include -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -MT gpg_agent-command.o -MD -MP -MF .deps/gpg_agent-command.Tpo -c -o gpg_agent-command.o `test -f 'command.c' || echo './'`command.c In file included from agent.h:32, from command.c:37: /sw/include/gcrypt.h:1336: warning: ?gcry_ac_io_mode_t? is deprecated /sw/include/gcrypt.h:1337: warning: ?gcry_ac_io_type_t? is deprecated /sw/include/gcrypt.h:1344: warning: ?gcry_ac_data_read_cb_t? is deprecated /sw/include/gcrypt.h:1358: warning: ?gcry_ac_data_write_cb_t? is deprecated /sw/include/gcrypt.h:1393: warning: ?gcry_md_algo_t? is deprecated /sw/include/gcrypt.h:1401: warning: ?gcry_md_algo_t? is deprecated /sw/include/gcrypt.h:1407: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1411: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1415: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1416: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1421: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1425: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1433: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1440: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1448: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1456: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1463: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1470: warning: ?gcry_ac_io_t? is deprecated /sw/include/gcrypt.h:1470: warning: ?gcry_ac_io_mode_t? is deprecated /sw/include/gcrypt.h:1471: warning: ?gcry_ac_io_type_t? is deprecated /sw/include/gcrypt.h:1477: warning: ?gcry_ac_io_t? is deprecated /sw/include/gcrypt.h:1477: warning: ?gcry_ac_io_mode_t? is deprecated /sw/include/gcrypt.h:1478: warning: ?gcry_ac_io_type_t? is deprecated /sw/include/gcrypt.h:1482: warning: ?gcry_ac_handle_t? is deprecated /sw/include/gcrypt.h:1483: warning: ?gcry_ac_id_t? is deprecated /sw/include/gcrypt.h:1487: warning: ?gcry_ac_handle_t? is deprecated /sw/include/gcrypt.h:1491: warning: ?gcry_ac_key_t? is deprecated /sw/include/gcrypt.h:1491: warning: ?gcry_ac_handle_t? is deprecated /sw/include/gcrypt.h:1492: warning: ?gcry_ac_key_type_t? is deprecated /sw/include/gcrypt.h:1492: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1500: warning: ?gcry_ac_handle_t? is deprecated /sw/include/gcrypt.h:1502: warning: ?gcry_ac_key_pair_t? is deprecated /sw/include/gcrypt.h:1507: warning: ?gcry_ac_key_pair_t? is deprecated /sw/include/gcrypt.h:1508: warning: ?gcry_ac_key_type_t? is deprecated /sw/include/gcrypt.h:1512: warning: ?gcry_ac_key_t? is deprecated /sw/include/gcrypt.h:1516: warning: ?gcry_ac_handle_t? is deprecated /sw/include/gcrypt.h:1516: warning: ?gcry_ac_key_t? is deprecated /sw/include/gcrypt.h:1520: warning: ?gcry_ac_handle_t? is deprecated /sw/include/gcrypt.h:1521: warning: ?gcry_ac_key_t? is deprecated /sw/include/gcrypt.h:1526: warning: ?gcry_ac_handle_t? is deprecated /sw/include/gcrypt.h:1526: warning: ?gcry_ac_key_t? is deprecated /sw/include/gcrypt.h:1531: warning: ?gcry_ac_key_t? is deprecated /sw/include/gcrypt.h:1535: warning: ?gcry_ac_key_pair_t? is deprecated /sw/include/gcrypt.h:1541: warning: ?gcry_ac_em_t? is deprecated /sw/include/gcrypt.h:1543: warning: ?gcry_ac_io_t? is deprecated /sw/include/gcrypt.h:1544: warning: ?gcry_ac_io_t? is deprecated /sw/include/gcrypt.h:1550: warning: ?gcry_ac_em_t? is deprecated /sw/include/gcrypt.h:1552: warning: ?gcry_ac_io_t? is deprecated /sw/include/gcrypt.h:1553: warning: ?gcry_ac_io_t? is deprecated /sw/include/gcrypt.h:1559: warning: ?gcry_ac_handle_t? is deprecated /sw/include/gcrypt.h:1561: warning: ?gcry_ac_key_t? is deprecated /sw/include/gcrypt.h:1563: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1569: warning: ?gcry_ac_handle_t? is deprecated /sw/include/gcrypt.h:1571: warning: ?gcry_ac_key_t? is deprecated /sw/include/gcrypt.h:1573: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1578: warning: ?gcry_ac_handle_t? is deprecated /sw/include/gcrypt.h:1579: warning: ?gcry_ac_key_t? is deprecated /sw/include/gcrypt.h:1581: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1587: warning: ?gcry_ac_handle_t? is deprecated /sw/include/gcrypt.h:1588: warning: ?gcry_ac_key_t? is deprecated /sw/include/gcrypt.h:1590: warning: ?gcry_ac_data_t? is deprecated /sw/include/gcrypt.h:1598: warning: ?gcry_ac_handle_t? is deprecated /sw/include/gcrypt.h:1599: warning: ?gcry_ac_scheme_t? is deprecated /sw/include/gcrypt.h:1601: warning: ?gcry_ac_key_t? is deprecated /sw/include/gcrypt.h:1602: warning: ?gcry_ac_io_t? is deprecated /sw/include/gcrypt.h:1603: warning: ?gcry_ac_io_t? is deprecated /sw/include/gcrypt.h:1611: warning: ?gcry_ac_handle_t? is deprecated /sw/include/gcrypt.h:1612: warning: ?gcry_ac_scheme_t? is deprecated /sw/include/gcrypt.h:1614: warning: ?gcry_ac_key_t? is deprecated /sw/include/gcrypt.h:1615: warning: ?gcry_ac_io_t? is deprecated /sw/include/gcrypt.h:1616: warning: ?gcry_ac_io_t? is deprecated /sw/include/gcrypt.h:1624: warning: ?gcry_ac_handle_t? is deprecated /sw/include/gcrypt.h:1625: warning: ?gcry_ac_scheme_t? is deprecated /sw/include/gcrypt.h:1627: warning: ?gcry_ac_key_t? is deprecated /sw/include/gcrypt.h:1628: warning: ?gcry_ac_io_t? is deprecated /sw/include/gcrypt.h:1629: warning: ?gcry_ac_io_t? is deprecated /sw/include/gcrypt.h:1638: warning: ?gcry_ac_handle_t? is deprecated /sw/include/gcrypt.h:1639: warning: ?gcry_ac_scheme_t? is deprecated /sw/include/gcrypt.h:1641: warning: ?gcry_ac_key_t? is deprecated /sw/include/gcrypt.h:1642: warning: ?gcry_ac_io_t? is deprecated /sw/include/gcrypt.h:1643: warning: ?gcry_ac_io_t? is deprecated /sw/include/gcrypt.h:1649: warning: ?gcry_ac_id_t? is deprecated /sw/include/gcrypt.h:1656: warning: ?gcry_ac_id_t? is deprecated command.c: In function ?cmd_killagent?: command.c:2313: error: ?ASSUAN_FORCE_CLOSE? undeclared (first use in this function) command.c:2313: error: (Each undeclared identifier is reported only once command.c:2313: error: for each function it appears in.) make[2]: *** [gpg_agent-command.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 From gniibe at fsij.org Wed Jan 11 01:51:02 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 11 Jan 2012 09:51:02 +0900 Subject: ECC and smartcards In-Reply-To: References: Message-ID: <1326243062.2015.1.camel@latx1.gniibe.org> On 2012-01-03 at 11:28 +0000, Benjamin Donnachie wrote: > Are there any plans to include ECC support within the OpenPGP > Smartcard specification? > > > If not, would a proposal be welcome? I'd like to see your proposal. If it will include specification for NIST Curve P256, it will be soon implemented in Gnuk, as it has a branch which has ECDSA/ECDH computation for the curve. -- From bjk at luxsci.net Wed Jan 11 04:19:11 2012 From: bjk at luxsci.net (Ben Kibbey) Date: Tue, 10 Jan 2012 22:19:11 -0500 Subject: [PATCH] Added user defined pinentry prompts for SCD. Message-ID: <201201110320.q0B3K2WM019378@rs136.luxsci.com> This adds scdaemon "OPTION pin-prompt" and "OPTION pin-admin-prompt" along with special escapes to replace in the prompt string to inform the user of a signature count and admin PIN attempts remaining. It also adds another "standard" pinentry escape "|I|" to ignore the default pinentry prompt from gpg-agent and use the supplied 'info' parameter unmodified (cannot be used with other pinentry flags). --- agent/divert-scd.c | 12 +++++- scd/app-common.h | 9 ++++ scd/app-openpgp.c | 108 ++++++++++++++++++++++++++++++++++++++++++++++------ scd/app.c | 92 ++++++++++++++++++++++++++++++++++++++++++++ scd/command.c | 68 ++++++++++++++++++++++++++++++++- 5 files changed, 274 insertions(+), 15 deletions(-) diff --git a/agent/divert-scd.c b/agent/divert-scd.c index f176a6b..a2de217 100644 --- a/agent/divert-scd.c +++ b/agent/divert-scd.c @@ -166,6 +166,8 @@ encode_md_for_card (const unsigned char *digest, size_t digestlen, int algo, 'A' = The PIN is an Admin PIN, SO-PIN or alike. 'P' = The PIN is a PUK (Personal Unblocking Key). 'R' = The PIN is a Reset Code. + 'I' = Ignore using the default prompt and use 'info' as the entire + prompt. Cannot be used with other flags. Example: @@ -185,6 +187,7 @@ getpin_cb (void *opaque, const char *info, char *buf, size_t maxbuf) int newpin = 0; int resetcode = 0; int is_puk = 0; + int ignore = 0; const char *again_text = NULL; const char *prompt = "PIN"; @@ -212,6 +215,8 @@ getpin_cb (void *opaque, const char *info, char *buf, size_t maxbuf) prompt = _("Reset Code"); resetcode = 1; } + else if (*s == 'I') + ignore = 1; } info = ends+1; any_flags = 1; @@ -219,6 +224,9 @@ getpin_cb (void *opaque, const char *info, char *buf, size_t maxbuf) else if (info && *info == '|') log_debug ("pin_cb called without proper PIN info hack\n"); + if (ignore) + any_flags = 0; + /* If BUF has been passed as NULL, we are in keypad mode: The callback opens the popup and immediatley returns. */ if (!buf) @@ -305,8 +313,8 @@ getpin_cb (void *opaque, const char *info, char *buf, size_t maxbuf) } else { - char *desc; - if ( asprintf (&desc, + char *desc = NULL; + if (!ignore && asprintf (&desc, _("Please enter the PIN%s%s%s to unlock the card"), info? " (`":"", info? info:"", diff --git a/scd/app-common.h b/scd/app-common.h index e3d23c2..d89c5dc 100644 --- a/scd/app-common.h +++ b/scd/app-common.h @@ -34,6 +34,11 @@ #define APP_CHANGE_FLAG_RESET 1 #define APP_CHANGE_FLAG_NULLPIN 2 +/* For user defined pinentry prompts. */ +enum { + PIN_PROMPT, + PIN_ADMIN_PROMPT, +}; struct app_local_s; /* Defined by all app-*.c. */ @@ -119,6 +124,7 @@ struct app_ctx_s { gpg_error_t (*check_pin) (app_t app, const char *keyidstr, gpg_error_t (*pincb)(void*, const char *, char **), void *pincb_arg); + gpg_error_t (*set_pin_prompt)(app_t app, int which, const char *prompt); } fnc; }; @@ -192,6 +198,7 @@ gpg_error_t app_genkey (app_t app, ctrl_t ctrl, time_t createtime, gpg_error_t (*pincb)(void*, const char *, char **), void *pincb_arg); +gpg_error_t app_set_pin_prompt (app_t app, int which, const char *prompt); gpg_error_t app_get_challenge (app_t app, size_t nbytes, unsigned char *buffer); gpg_error_t app_change_pin (app_t app, ctrl_t ctrl, @@ -201,6 +208,8 @@ gpg_error_t app_change_pin (app_t app, ctrl_t ctrl, gpg_error_t app_check_pin (app_t app, const char *keyidstr, gpg_error_t (*pincb)(void*, const char *, char **), void *pincb_arg); +char *expand_pin_prompt(const char *prompt, const char *prepend, int which, + ...); /*-- app-openpgp.c --*/ diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index e3a4484..a840c98 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -198,6 +198,8 @@ struct app_local_s { rsa_key_format_t format; } keyattr[3]; + char *pin_prompt; /* As set with set_pin_prompt() or a default. */ + char *pin_admin_prompt; }; @@ -242,6 +244,8 @@ do_deinit (app_t app) xfree (app->app_local->pk[i].key); app->app_local->pk[i].read_done = 0; } + xfree(app->app_local->pin_prompt); + xfree(app->app_local->pin_admin_prompt); xfree (app->app_local); app->app_local = NULL; } @@ -1520,19 +1524,41 @@ verify_a_chv (app_t app, if (chvno == 1) { + if (app->app_local->pin_prompt) + { + prompt_buffer = expand_pin_prompt(app->app_local->pin_prompt, "|I|", + PIN_PROMPT, sigcount); + if (!prompt_buffer) + return gpg_error_from_syserror(); + } + else + { #define PROMPTSTRING _("||Please enter the PIN%%0A[sigs done: %lu]") - size_t promptsize = strlen (PROMPTSTRING) + 50; + size_t promptsize; - prompt_buffer = xtrymalloc (promptsize); - if (!prompt_buffer) - return gpg_error_from_syserror (); - snprintf (prompt_buffer, promptsize-1, PROMPTSTRING, sigcount); - prompt = prompt_buffer; + promptsize = strlen (PROMPTSTRING) + 50; + prompt_buffer = xtrymalloc (promptsize); + if (!prompt_buffer) + return gpg_error_from_syserror (); + snprintf (prompt_buffer, promptsize-1, PROMPTSTRING, sigcount); #undef PROMPTSTRING + } + + prompt = prompt_buffer; } else - prompt = _("||Please enter the PIN"); - + { + if (app->app_local->pin_prompt) + { + prompt_buffer = expand_pin_prompt(app->app_local->pin_prompt, "|I|", + -1, NULL); + if (!prompt_buffer) + return gpg_error_from_syserror(); + prompt = prompt_buffer; + } + else + prompt = _("||Please enter the PIN"); + } if (!opt.disable_keypad && !iso7816_check_keypad (app->slot, ISO7816_VERIFY, &pininfo) ) @@ -1673,11 +1699,21 @@ build_enter_admin_pin_prompt (app_t app, char **r_prompt) { /* TRANSLATORS: Do not translate the "|A|" prefix but keep it at the start of the string. Use %%0A to force a linefeed. */ - prompt = xtryasprintf (_("|A|Please enter the Admin PIN%%0A" - "[remaining attempts: %d]"), remaining); + if (app->app_local->pin_admin_prompt) + prompt = expand_pin_prompt(app->app_local->pin_admin_prompt, "|I|", + PIN_ADMIN_PROMPT, remaining); + else + prompt = xtryasprintf (_("|A|Please enter the Admin PIN%%0A" + "[remaining attempts: %d]"), remaining); } else - prompt = xtrystrdup (_("|A|Please enter the Admin PIN")); + { + if (app->app_local->pin_admin_prompt) + prompt = expand_pin_prompt(app->app_local->pin_admin_prompt, "|I|", + -1, NULL); + else + prompt = xtrystrdup (_("|A|Please enter the Admin PIN")); + } if (!prompt) return gpg_error_from_syserror (); @@ -1999,7 +2035,21 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr, prompt = promptbuf; } else - prompt = _("||Please enter the PIN"); + { + if (app->app_local->pin_prompt) + { + promptbuf = expand_pin_prompt(app->app_local->pin_prompt, + "|I|", -1, NULL); + if (!promptbuf) + { + rc = gpg_error_from_syserror(); + goto leave; + } + prompt = promptbuf; + } + else + prompt = _("||Please enter the PIN"); + } rc = pincb (pincb_arg, prompt, &oldpinvalue); xfree (promptbuf); promptbuf = NULL; @@ -3707,6 +3757,39 @@ parse_algorithm_attribute (app_t app, int keyno) xfree (relptr); } +gpg_error_t do_set_pin_prompt(app_t app, int which, const char *prompt) +{ + gpg_error_t rc = 0; + char **p = NULL; + + switch (which) + { + case PIN_PROMPT: + p = &app->app_local->pin_prompt; + break; + case PIN_ADMIN_PROMPT: + p = &app->app_local->pin_admin_prompt; + break; + default: + break; + } + + if (p) + { + xfree(*p); + *p = NULL; + + if (prompt && *prompt != '-' && *(prompt+1) != 0) + { + *p = xtrystrdup(prompt); + if (!*p) + rc = gpg_error_from_syserror(); + } + } + + return rc; +} + /* Select the OpenPGP application on the card in SLOT. This function must be used before any other OpenPGP application functions. */ gpg_error_t @@ -3850,6 +3933,7 @@ app_select_openpgp (app_t app) app->fnc.decipher = do_decipher; app->fnc.change_pin = do_change_pin; app->fnc.check_pin = do_check_pin; + app->fnc.set_pin_prompt = do_set_pin_prompt; } leave: diff --git a/scd/app.c b/scd/app.c index 76dc8b4..0e722c6 100644 --- a/scd/app.c +++ b/scd/app.c @@ -923,6 +923,98 @@ app_genkey (app_t app, ctrl_t ctrl, const char *keynostr, unsigned int flags, } +/* Replaces special escapes in a user defined pinentry prompt with the + * argument value where 'which' is one of: + * + * PIN_PROMPT: |S| - signature count (unsigned long) + * PIN_ADMIN_PROMPT: |A| - remaining attempts (int) + * + * The escapes in the prompt are replaced with the values. A prompt is set + * with the OPTION command and reset to the default when it's value is -. + */ +char *expand_pin_prompt(const char *prompt, const char *prepend, + int which, ...) +{ + va_list ap; + size_t len, n; + char *buf; + unsigned long luval; + int intval; + char valuebuf[50] = {0}; + char *p, *token = NULL, *tokenp; + + if (!prompt) + return NULL; + + len = strlen(prompt); + len += prepend ? strlen(prepend) : 0; + va_start(ap, which); + + switch (which) + { + /* Signature count. */ + case PIN_PROMPT: + luval = va_arg(ap, unsigned long); + snprintf(valuebuf, sizeof(valuebuf), "%lu", luval); + token = "|S|"; + break; + /* Pin tries remaining. */ + case PIN_ADMIN_PROMPT: + intval = va_arg(ap, int); + snprintf(valuebuf, sizeof(valuebuf), "%i", intval); + token = "|A|"; + break; + } + + va_end(ap); + + if (!token) + return xtrystrdup(prompt); + + len += strlen(valuebuf)+1; + buf = xtrymalloc(len); + if (!buf) + return NULL; + + buf[0] = 0; + if (prepend) + strcpy(buf, prepend); + + strcat(buf, prompt); + + if (prepend) + p = buf+strlen(prepend); + else + p = buf; + + tokenp = strstr(p, token); + if (!tokenp) + return buf; + + p = tokenp+strlen(token); + len -= strlen(token)+1; + memmove(&buf[len-strlen(p)], p, strlen(p)); + + for (n = 0; valuebuf[n]; n++) + *tokenp++ = valuebuf[n]; + + buf[len] = 0; + return buf; +} + +/* Set the prompt shown in the pinentry dialog. If not set then a default will + * be used. */ +gpg_error_t app_set_pin_prompt(app_t app, int which, const char *prompt) +{ + if (!app) + return gpg_error (GPG_ERR_INV_VALUE); + + if (!app->fnc.set_pin_prompt) + return gpg_error (GPG_ERR_UNSUPPORTED_OPERATION); + + return app->fnc.set_pin_prompt(app, which, prompt); +} + /* Perform a GET CHALLENGE operation. This fucntion is special as it directly accesses the card without any application specific wrapper. */ diff --git a/scd/command.c b/scd/command.c index 88f8ec2..6e6d89b 100644 --- a/scd/command.c +++ b/scd/command.c @@ -139,6 +139,13 @@ struct server_local_s this session. */ int stopme; + /* User-defined pinentry prompt strings. Needed both here and in the app + * since they may be defined before an app is selected with + * select_application(). They are copied to the app when + * select_application() succeeds and further modifications done in the app. + * */ + char *pin_prompt; + char *pin_admin_prompt; }; @@ -387,6 +394,39 @@ reset_notify (assuan_context_t ctx, char *line) return 0; } +static gpg_error_t set_pinentry_prompt(struct server_local_s *srv, int which, + const char *prompt) +{ + gpg_error_t rc = 0; + char **p = NULL; + + switch (which) + { + case PIN_PROMPT: + p = &srv->pin_prompt; + break; + case PIN_ADMIN_PROMPT: + p = &srv->pin_admin_prompt; + break; + default: + break; + } + + if (p) + { + xfree(*p); + *p = NULL; + + if (prompt && *prompt != '-' && *(prompt+1) != 0) + { + *p = xtrystrdup(prompt); + if (!*p) + rc = gpg_error_from_syserror(); + } + } + + return rc; +} static gpg_error_t option_handler (assuan_context_t ctx, const char *key, const char *value) @@ -407,6 +447,20 @@ option_handler (assuan_context_t ctx, const char *key, const char *value) ctrl->server_local->event_signal = i; #endif } + else if (!strcmp (key, "pin-prompt")) + { + if (ctrl->app_ctx) + return app_set_pin_prompt(ctrl->app_ctx, PIN_PROMPT, value); + else + return set_pinentry_prompt(ctrl->server_local, PIN_PROMPT, value); + } + else if (!strcmp (key, "pin-admin-prompt")) + { + if (ctrl->app_ctx) + return app_set_pin_prompt(ctrl->app_ctx, PIN_ADMIN_PROMPT, value); + else + return set_pinentry_prompt(ctrl->server_local, PIN_ADMIN_PROMPT, value); + } return 0; } @@ -523,7 +577,17 @@ open_card (ctrl_t ctrl, const char *apptype) err = gpg_error (GPG_ERR_CARD); } else - err = select_application (ctrl, slot, apptype, &ctrl->app_ctx); + { + err = select_application (ctrl, slot, apptype, &ctrl->app_ctx); + if (!err) + { + err = app_set_pin_prompt(ctrl->app_ctx, PIN_PROMPT, + ctrl->server_local->pin_prompt); + if (!err) + err = app_set_pin_prompt(ctrl->app_ctx, PIN_ADMIN_PROMPT, + ctrl->server_local->pin_admin_prompt); + } + } } TEST_CARD_REMOVAL (ctrl, err); @@ -2097,6 +2161,8 @@ scd_command_handler (ctrl_t ctrl, int fd) sl->next_session = ctrl->server_local->next_session; } stopme = ctrl->server_local->stopme || reader_disabled; + xfree(ctrl->server_local->pin_prompt); + xfree(ctrl->server_local->pin_admin_prompt); xfree (ctrl->server_local); ctrl->server_local = NULL; -- 1.7.7.3 From wk at gnupg.org Wed Jan 11 09:34:11 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Jan 2012 09:34:11 +0100 Subject: Unable to compile GnuPG 2.1 beta 3 In-Reply-To: (Nicholas Cole's message of "Tue, 10 Jan 2012 16:05:37 +0000") References: <8762haz0nk.fsf@vigenere.g10code.de> <87vcp9x0nq.fsf@vigenere.g10code.de> <87mxa2cq9j.fsf@vigenere.g10code.de> Message-ID: <87mx9uzlh8.fsf@vigenere.g10code.de> On Tue, 10 Jan 2012 17:05, nicholas.cole at gmail.com said: > command.c:2313: error: ?ASSUAN_FORCE_CLOSE? undeclared (first use in > this function) configure checks for libassuan 2.0.3 which has this constant. You may have not correctly installed libassuan 2.0.3. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From martin at martinpaljak.net Wed Jan 11 10:01:03 2012 From: martin at martinpaljak.net (Martin Paljak) Date: Wed, 11 Jan 2012 11:01:03 +0200 Subject: pinpad entry support in Git repository In-Reply-To: <1325727440.2060.1.camel@latx1.gniibe.org> References: <1322802559.2589.9.camel@latx1.gniibe.org> <1324267157.1983.1.camel@latx1.gniibe.org> <1325727440.2060.1.camel@latx1.gniibe.org> Message-ID: Hello, On Thu, Jan 5, 2012 at 03:37, NIIBE Yutaka wrote: > Happy New Year, everyone! > > On 2011-12-19 at 12:59 +0900, NIIBE Yutaka wrote: >> Thus, I wrote a python script. ?Attached is a program which tests PIN >> entry using pinpad of card reader. ?It requires "Pyscard", smartcard >> library for python. ?See http://pyscard.sourceforge.net/ for Pyscard. >> >> This test program assumes that OpenPGP card v2 is inserted to it. > > I updated the test program for pinpad entry. ?It is also renamed (with > no hyphen in the filename). ?Attached is the newest version, which is > also available at: > > ? http://www.gniibe.org/gitweb?p=gnuk.git;a=blob;f=tool/pinpadtest.py > > It is extensively tested with Vasco DIGIPASS 920. ?Note that the > reader has firewall feature which doesn't allow VERIFY or CHANGE > REFERENCE DATA command with data from host, but only allows pinpad > entry by the reader. ?With no pinpad entry support, this reader were > useless at all. ?It works well except --unblock --admin. > > I also tested with Gemalto's GemPC PinPad Smart Card Reader > (08e6:3478) which has the firmware "GemTwRC2-V2.10-GL04". > Unfortunately, it seems that this reader doesn't support variable > length PIN. > > Please test your readers, it they come with pinpad. ?And let me know > the result. ?Thanks again, in advance. Did some testing with three readers that were not mentioned, which I had available. Attached a small "report". Reader 1: ACS non-CCID reader ACR83, with the vnedor-provided modified CCID driver. Did not work at all. Reader 2: Gemalto Ezio Shield (variant): PIN commands worked as expected (with pinmax up to 32, I did not type 32 digits though), plaintext PIN commands were disallowed with 6d00 Reader 3: Omnikey 3821: worked as expected with pinpad. Also a small patch against pinpadtest.py as I have several readers I can't disconnect. It might make sense to make a "probing script" that would discover deficiencies in reader firmwares (like require certain message bits (some of them are fixed in the CCID driver) or require fixed PIN lengths etc) Hope this helps, Martin -------------- next part -------------- Bus 002 Device 052: ID 072f:90d2 Advanced Card Systems, Ltd some ACS reader with their modified CCID driver. Does not work, do not fiddle with properties. $ ./pinpadtest.py Reader/Token: ACS ACR83U 01 00 ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C Please input User's PIN Traceback (most recent call last): File "./pinpadtest.py", line 340, in main(who, method, add_a_byte, pinmin, pinmax, change_by_two_steps) File "./pinpadtest.py", line 209, in main card.cmd_verify_pinpad(who) File "./pinpadtest.py", line 123, in cmd_verify_pinpad raise ValueError, ("cmd_verify_pinpad %02x %02x" % (sw1, sw2)) ValueError: cmd_verify_pinpad 6b 80 Bus 002 Device 054: ID 08e6:34c2 Gemplus Gemplus Ezio Shield (might be a development snapshot) pinpad works as expected, 6d00 means "firewalled" ./pinpadtest.py --unblock2 Reader/Token: Gemalto Ezio Shield PinPad 01 00 ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C Please input reset code from keyboard: Please input New User's PIN from keyboard: Traceback (most recent call last): File "./pinpadtest.py", line 340, in main(who, method, add_a_byte, pinmin, pinmax, change_by_two_steps) File "./pinpadtest.py", line 236, in main card.cmd_reset_retry_counter(who,resetcode+newpin) File "./pinpadtest.py", line 164, in cmd_reset_retry_counter raise ValueError, ("cmd_reset_retry_counter %02x %02x" % (sw1, sw2)) ValueError: cmd_reset_retry_counter 6d 00 Bus 002 Device 055: ID 076b:3821 OmniKey AG CardMan 3821 Works as expected: $ ./pinpadtest.py --change --pinmax 31 --pinmin 1 Reader/Token: OmniKey CardMan 3821 01 00 ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C Please input User's PIN and New User's PIN twice OK. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-pinpadtest-allow-working-with-more-than-a-single-con.patch Type: text/x-patch Size: 1097 bytes Desc: not available URL: From wk at gnupg.org Wed Jan 11 12:37:22 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Jan 2012 12:37:22 +0100 Subject: pinpad entry support in Git repository In-Reply-To: (Martin Paljak's message of "Wed, 11 Jan 2012 11:01:03 +0200") References: <1322802559.2589.9.camel@latx1.gniibe.org> <1324267157.1983.1.camel@latx1.gniibe.org> <1325727440.2060.1.camel@latx1.gniibe.org> Message-ID: <87ty42xyfh.fsf@vigenere.g10code.de> On Wed, 11 Jan 2012 10:01, martin at martinpaljak.net said: > Reader 3: Omnikey 3821: worked as expected with pinpad. Are you sure about this? Do they now support extended length APDUs via CCID or still only with their Windows driver? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jan 11 13:07:29 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Jan 2012 13:07:29 +0100 Subject: [PATCH] Added user defined pinentry prompts for SCD. In-Reply-To: <201201110320.q0B3K2WM019378@rs136.luxsci.com> (Ben Kibbey's message of "Tue, 10 Jan 2012 22:19:11 -0500") References: <201201110320.q0B3K2WM019378@rs136.luxsci.com> Message-ID: <87lipexx1a.fsf@vigenere.g10code.de> On Wed, 11 Jan 2012 04:19, bjk at luxsci.net said: > This adds scdaemon "OPTION pin-prompt" and "OPTION pin-admin-prompt" > along with special escapes to replace in the prompt string to inform the > user of a signature count and admin PIN attempts remaining. Would you mind to describe a use case for this feature? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From martin at martinpaljak.net Wed Jan 11 13:27:40 2012 From: martin at martinpaljak.net (Martin Paljak) Date: Wed, 11 Jan 2012 14:27:40 +0200 Subject: pinpad entry support in Git repository In-Reply-To: <87ty42xyfh.fsf@vigenere.g10code.de> References: <1322802559.2589.9.camel@latx1.gniibe.org> <1324267157.1983.1.camel@latx1.gniibe.org> <1325727440.2060.1.camel@latx1.gniibe.org> <87ty42xyfh.fsf@vigenere.g10code.de> Message-ID: On Wed, Jan 11, 2012 at 13:37, Werner Koch wrote: > On Wed, 11 Jan 2012 10:01, martin at martinpaljak.net said: > >> Reader 3: Omnikey 3821: worked as expected with pinpad. > > Are you sure about this? ?Do they now support extended length APDUs via > CCID or still only with their Windows driver? I don't believe that PIN commands require extended APDU-s for normal people. Lack of extended APDU-s for this reader is also written to the CCID driver matrix limitations: http://pcsclite.alioth.debian.org/ccid/limitations.html#180 Martin From wk at gnupg.org Wed Jan 11 14:13:54 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Jan 2012 14:13:54 +0100 Subject: pinpad entry support in Git repository In-Reply-To: (Martin Paljak's message of "Wed, 11 Jan 2012 14:27:40 +0200") References: <1322802559.2589.9.camel@latx1.gniibe.org> <1324267157.1983.1.camel@latx1.gniibe.org> <1325727440.2060.1.camel@latx1.gniibe.org> <87ty42xyfh.fsf@vigenere.g10code.de> Message-ID: <87vcoiwfe5.fsf@vigenere.g10code.de> On Wed, 11 Jan 2012 13:27, martin at martinpaljak.net said: > I don't believe that PIN commands require extended APDU-s for normal people. It is more about the usability of the reader. For modern cards it thus unusable with free software. We won't add any specific support for it. If they would open the specs and describe how to exactly use the escape sequences which allow sending of extendend length APDUs, we can reconsider that. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jan 11 20:20:36 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 11 Jan 2012 20:20:36 +0100 Subject: [solved] Re: Unable to compile GnuPG 2.1 beta 3 In-Reply-To: (alphazo@gmail.com's message of "Thu, 5 Jan 2012 14:53:51 +0100") References: <8762haz0nk.fsf@vigenere.g10code.de> <87vcp9x0nq.fsf@vigenere.g10code.de> <87mxa2cq9j.fsf@vigenere.g10code.de> Message-ID: <877h0yujuj.fsf_-_@vigenere.g10code.de> Hi, after some private mails, we finally found the bug: commit 30ec869b8c63f1edcc58110ed20b83b0e77248f8 gpg: Fix segv with RSA_S keys. * g10/misc.c (pubkey_get_npkey, pubkey_get_nskey) (pubkey_get_nsig, pubkey_get_nenc): Map all RSA algo ids to GCRY_PK_RSA. -- The problem is that Libgcrypt has no more support for the alternate RSA ids and thus if asking for the number of parameters, they will return zero. Now, this leads to packing the key parameters into an opaque MPI but because the algorithm id is actually known to GPG, it assumes valid RSA parameters. An example key with RSA_S is 0x5434509D. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From alphazo at gmail.com Wed Jan 11 22:48:55 2012 From: alphazo at gmail.com (Alphazo) Date: Wed, 11 Jan 2012 22:48:55 +0100 Subject: [solved] Re: Unable to compile GnuPG 2.1 beta 3 In-Reply-To: <877h0yujuj.fsf_-_@vigenere.g10code.de> References: <8762haz0nk.fsf@vigenere.g10code.de> <87vcp9x0nq.fsf@vigenere.g10code.de> <87mxa2cq9j.fsf@vigenere.g10code.de> <877h0yujuj.fsf_-_@vigenere.g10code.de> Message-ID: Proposed patch fixes the problem. Thanks. As a side note, thread is marked as solved but I still have to compile gnupg2 with "--disable-dirmngr" ;) I don't use X.509 certificates (yet) under GnuPG so I guess I can leave without it. Alphazo On Wed, Jan 11, 2012 at 8:20 PM, Werner Koch wrote: > Hi, > > after some private mails, we finally found the bug: > > commit 30ec869b8c63f1edcc58110ed20b83b0e77248f8 > > ? ?gpg: Fix segv with RSA_S keys. > > ? ?* g10/misc.c (pubkey_get_npkey, pubkey_get_nskey) > ? ?(pubkey_get_nsig, pubkey_get_nenc): Map all RSA algo ids to > ? ?GCRY_PK_RSA. > ? ?-- > > ? ?The problem is that Libgcrypt has no more support for the alternate > ? ?RSA ids and thus if asking for the number of parameters, they will > ? ?return zero. ?Now, this leads to packing the key parameters into an > ? ?opaque MPI but because the algorithm id is actually known to GPG, it > ? ?assumes valid RSA parameters. > > ? ?An example key with RSA_S is 0x5434509D. > > > Salam-Shalom, > > ? Werner > > -- > Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. > From alphazo at gmail.com Wed Jan 11 23:14:00 2012 From: alphazo at gmail.com (Alphazo) Date: Wed, 11 Jan 2012 23:14:00 +0100 Subject: Migrating from OpenPGP card + gnupg 1.4 to 2.1 In-Reply-To: References: <87r4zxx0f5.fsf@vigenere.g10code.de> Message-ID: Now that the seg. fault is fixed. I tried again to migrate my hybrid private key to the new gnupg2 key storage but I don't get On Wed, Dec 21, 2011 at 10:38 PM, Alphazo wrote: > You were right on the subkey. In the meantime I realized that the > import function was also trying to import old revoked keys as well. > That's why I got the password prompt for an old non OpenGPG card based > key. > > Now for testing purposes I cleaned up my secring.gpg by removing all > secret keys but one which is the one I described in my previous post. > > I started the import and didn't get any password prompt but > unfortunately also no PIN prompt for my OpenPGP card (?). > alpha at fatfly ~/.gnupg % gpg2 --import ~/.gnupg/secring.gpg > gpg: key F89A6E41: "Test Key " not changed > gpg: key F89A6E41: secret key imported > gpg: Total number processed: 4 > gpg: ? ? ? ? ? ? ?unchanged: 1 > gpg: ? ? ? secret keys read: 4 > > Then I looked at my gnugp2 keystore but it remains empty. > > alpha at fatfly ~/.gnupg % ls private-keys-v1.d > alpha at fatfly ~/.gnupg % > > Is my OpenPGP card stub being checked correctly? > Is gpg-agent supposed to work out of the box with OpenPGP card? > > I then did another test by using a regular key (no OpenPGP card) and > got a strange 'can't handle public key algorithm 3" error then a seg. > fault when doing a --list-secret-keys. However --edit-key did work > fine. > > (gdb) run -v --list-secret-keys > Starting program: /usr/bin/gpg2 -v --list-secret-keys > gpg: using PGP trust model > gpg: can't handle public key algorithm 3 > gpg: subpacket of type 20 has critical bit set > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff732e700 in ?? () from /lib/libgcrypt.so.11 > > > #0 ?0x00007ffff732e700 in ?? () from /lib/libgcrypt.so.11 > No symbol table info available. > #1 ?0x00007ffff72e6726 in ?? () from /lib/libgcrypt.so.11 > No symbol table info available. > #2 ?0x00007ffff72e7bfa in ?? () from /lib/libgcrypt.so.11 > No symbol table info available. > #3 ?0x00007ffff72e1ef2 in gcry_sexp_build () from /lib/libgcrypt.so.11 > No symbol table info available. > #4 ?0x000000000042a05b in ?? () > No symbol table info available. > #5 ?0x0000000000471e63 in ?? () > No symbol table info available. > #6 ?0x00000000004383fc in ?? () > No symbol table info available. > #7 ?0x000000000040c120 in ?? () > No symbol table info available. > #8 ?0x00007ffff6b6114d in __libc_start_main () from /lib/libc.so.6 > No symbol table info available. > #9 ?0x000000000040c5ed in ?? () > No symbol table info available. > #10 0x00007fffffffe0b8 in ?? () > ---Type to continue, or q to quit--- > No symbol table info available. > #11 0x00000000ffffffff in ?? () > No symbol table info available. > #12 0x0000000000000003 in ?? () > No symbol table info available. > #13 0x00007fffffffe408 in ?? () > No symbol table info available. > #14 0x00007fffffffe416 in ?? () > No symbol table info available. > #15 0x00007fffffffe419 in ?? () > No symbol table info available. > #16 0x0000000000000000 in ?? () > No symbol table info available. > > > gpg2 -v --edit-key alphazo at gmail.com > Secret key is available. > > gpg: using PGP trust model > pub ?1024D/242D4DFB ?created: 2009-08-20 ?expires: never ? ? ? usage: SC > ? ? ? ? ? ? ? ? ? ? trust: ultimate ? ? ?validity: ultimate > sub ?2048g/CBF93DD2 ?created: 2009-08-20 ?expires: never ? ? ? usage: E > [ultimate] (1). Alphazo > > Alphazo > > On Wed, Dec 21, 2011 at 7:08 PM, Werner Koch wrote: >> On Wed, 21 Dec 2011 15:35, alphazo at gmail.com said: >> >>> When importing this key I got the pinentry-gtk popup asking for the >>> passphrase for this key but this won't be of any help considering that >>> no private key material is there. >> >> Are you sure that it ask for the passphrase of the primary key? ?It >> should ask for the one of the subkey. ?In any case, please enter the >> passphrase of the subkey (which is usually the same as of the primary >> key). ?Note, that I have a very similar setup and it worked without >> problems. ?It is however possible that we have a regression here. >> >>> I could probably setup a temporary machine to use the full keychain >>> with passphrase then migrate to 2.1 and finally remove the private key >>> material of the primary key (is that possible with 2.1?). >> >> Yes, very easy: >> >> ?gpg2 --with-keygrip -K >> >> shows you the keygrip of the keys. ?Now, simply remove the file >> ~/.gnupg/private-keys-v1.d/KEYGRIP.key >> >> >> Salam-Shalom, >> >> ? Werner >> >> -- >> Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. >> From alphazo at gmail.com Wed Jan 11 23:25:24 2012 From: alphazo at gmail.com (Alphazo) Date: Wed, 11 Jan 2012 23:25:24 +0100 Subject: Migrating from OpenPGP card + gnupg 1.4 to 2.1 In-Reply-To: References: <87r4zxx0f5.fsf@vigenere.g10code.de> Message-ID: Now that the seg. fault is fixed. I tried again to migrate my hybrid private key to the new gnupg2 key storage. I do get password prompt for older keys (and I clicked on cancel for each) but I don't get password or PIN prompt for my current hybrid key. However gnupg2 says that it has imported my secret key but the private-keys-v1.d directory stays empty.... Where has my private key been imported to? As a side not I also get some errors with some old keys. # gpg2 --import ~/.gnupg/secring.gpg .... gpg: key 12345678 : "Test Key1 " not changed gpg: key 12345678/3344556677: error sending to agent: Operation cancelled gpg: key 0022446688: no valid user IDs gpg: this may be caused by a missing self-signature gpg: key 0022446688/AABBCCDDEE: error sending to agent: Operation cancelled ... gpg: key 7A7B7D7E: "Hybrid Key " not changed gpg: key 7A7B7D7E: secret key imported ... gpg: Total number processed: 24 gpg: w/o user IDs: 1 gpg: unchanged: 9 gpg: secret keys read: 24 On Wed, Jan 11, 2012 at 11:14 PM, Alphazo wrote: > Now that the seg. fault is fixed. I tried again to migrate my hybrid > private key to the new gnupg2 key storage but I don't get > > On Wed, Dec 21, 2011 at 10:38 PM, Alphazo wrote: >> You were right on the subkey. In the meantime I realized that the >> import function was also trying to import old revoked keys as well. >> That's why I got the password prompt for an old non OpenGPG card based >> key. >> >> Now for testing purposes I cleaned up my secring.gpg by removing all >> secret keys but one which is the one I described in my previous post. >> >> I started the import and didn't get any password prompt but >> unfortunately also no PIN prompt for my OpenPGP card (?). >> alpha at fatfly ~/.gnupg % gpg2 --import ~/.gnupg/secring.gpg >> gpg: key F89A6E41: "Test Key " not changed >> gpg: key F89A6E41: secret key imported >> gpg: Total number processed: 4 >> gpg: ? ? ? ? ? ? ?unchanged: 1 >> gpg: ? ? ? secret keys read: 4 >> >> Then I looked at my gnugp2 keystore but it remains empty. >> >> alpha at fatfly ~/.gnupg % ls private-keys-v1.d >> alpha at fatfly ~/.gnupg % >> >> Is my OpenPGP card stub being checked correctly? >> Is gpg-agent supposed to work out of the box with OpenPGP card? >> >> I then did another test by using a regular key (no OpenPGP card) and >> got a strange 'can't handle public key algorithm 3" error then a seg. >> fault when doing a --list-secret-keys. However --edit-key did work >> fine. >> >> (gdb) run -v --list-secret-keys >> Starting program: /usr/bin/gpg2 -v --list-secret-keys >> gpg: using PGP trust model >> gpg: can't handle public key algorithm 3 >> gpg: subpacket of type 20 has critical bit set >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x00007ffff732e700 in ?? () from /lib/libgcrypt.so.11 >> >> >> #0 ?0x00007ffff732e700 in ?? () from /lib/libgcrypt.so.11 >> No symbol table info available. >> #1 ?0x00007ffff72e6726 in ?? () from /lib/libgcrypt.so.11 >> No symbol table info available. >> #2 ?0x00007ffff72e7bfa in ?? () from /lib/libgcrypt.so.11 >> No symbol table info available. >> #3 ?0x00007ffff72e1ef2 in gcry_sexp_build () from /lib/libgcrypt.so.11 >> No symbol table info available. >> #4 ?0x000000000042a05b in ?? () >> No symbol table info available. >> #5 ?0x0000000000471e63 in ?? () >> No symbol table info available. >> #6 ?0x00000000004383fc in ?? () >> No symbol table info available. >> #7 ?0x000000000040c120 in ?? () >> No symbol table info available. >> #8 ?0x00007ffff6b6114d in __libc_start_main () from /lib/libc.so.6 >> No symbol table info available. >> #9 ?0x000000000040c5ed in ?? () >> No symbol table info available. >> #10 0x00007fffffffe0b8 in ?? () >> ---Type to continue, or q to quit--- >> No symbol table info available. >> #11 0x00000000ffffffff in ?? () >> No symbol table info available. >> #12 0x0000000000000003 in ?? () >> No symbol table info available. >> #13 0x00007fffffffe408 in ?? () >> No symbol table info available. >> #14 0x00007fffffffe416 in ?? () >> No symbol table info available. >> #15 0x00007fffffffe419 in ?? () >> No symbol table info available. >> #16 0x0000000000000000 in ?? () >> No symbol table info available. >> >> >> gpg2 -v --edit-key alphazo at gmail.com >> Secret key is available. >> >> gpg: using PGP trust model >> pub ?1024D/242D4DFB ?created: 2009-08-20 ?expires: never ? ? ? usage: SC >> ? ? ? ? ? ? ? ? ? ? trust: ultimate ? ? ?validity: ultimate >> sub ?2048g/CBF93DD2 ?created: 2009-08-20 ?expires: never ? ? ? usage: E >> [ultimate] (1). Alphazo >> >> Alphazo >> >> On Wed, Dec 21, 2011 at 7:08 PM, Werner Koch wrote: >>> On Wed, 21 Dec 2011 15:35, alphazo at gmail.com said: >>> >>>> When importing this key I got the pinentry-gtk popup asking for the >>>> passphrase for this key but this won't be of any help considering that >>>> no private key material is there. >>> >>> Are you sure that it ask for the passphrase of the primary key? ?It >>> should ask for the one of the subkey. ?In any case, please enter the >>> passphrase of the subkey (which is usually the same as of the primary >>> key). ?Note, that I have a very similar setup and it worked without >>> problems. ?It is however possible that we have a regression here. >>> >>>> I could probably setup a temporary machine to use the full keychain >>>> with passphrase then migrate to 2.1 and finally remove the private key >>>> material of the primary key (is that possible with 2.1?). >>> >>> Yes, very easy: >>> >>> ?gpg2 --with-keygrip -K >>> >>> shows you the keygrip of the keys. ?Now, simply remove the file >>> ~/.gnupg/private-keys-v1.d/KEYGRIP.key >>> >>> >>> Salam-Shalom, >>> >>> ? Werner >>> >>> -- >>> Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. >>> From bjk at luxsci.net Thu Jan 12 00:25:31 2012 From: bjk at luxsci.net (Ben Kibbey) Date: Wed, 11 Jan 2012 18:25:31 -0500 Subject: [PATCH] Added user defined pinentry prompts for SCD. In-Reply-To: <87lipexx1a.fsf@vigenere.g10code.de> References: <201201110320.q0B3K2WM019378@rs136.luxsci.com> <87lipexx1a.fsf@vigenere.g10code.de> Message-ID: <201201112327.q0BNR25I018237@rs136.luxsci.com> On Wed, Jan 11, 2012 at 01:07:29PM +0100, Werner Koch wrote: > On Wed, 11 Jan 2012 04:19, bjk at luxsci.net said: > > This adds scdaemon "OPTION pin-prompt" and "OPTION pin-admin-prompt" > > along with special escapes to replace in the prompt string to inform the > > user of a signature count and admin PIN attempts remaining. > > Would you mind to describe a use case for this feature? To inform the user where the pinentry came from or what the pinentry is for. For example, my server program has clients the connect to it and these clients can set a client name that the server can use to keep track of in log files. Using this new option, the server program can set the pinentry prompt to inform the user of what client needs the pinentry rather than only prompting for a PIN. I noticed a discussion in the ML of setting the pinentry title but this patch modifies the pinentry description strings. A title patch would be good to have, too. I posted the patch here so folks can review it and maybe suggest a better way of going about it. It does need other application support (only app-openpgp has been modified to make use of it). Maybe it would be better to make a pin-prompt branch? Have a good one, -- Ben Kibbey [XMPP: bjk AT jabber DOT org] - [IRC: (bjk) FreeNode/OFTC] From gniibe at fsij.org Thu Jan 12 02:12:02 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 12 Jan 2012 10:12:02 +0900 Subject: pinpad entry support in Git repository In-Reply-To: References: <1322802559.2589.9.camel@latx1.gniibe.org> <1324267157.1983.1.camel@latx1.gniibe.org> <1325727440.2060.1.camel@latx1.gniibe.org> Message-ID: <1326330722.1970.0.camel@latx1.gniibe.org> On 2012-01-11 at 11:01 +0200, Martin Paljak wrote: > Did some testing with three readers that were not mentioned, which I > had available. Attached a small "report". Thanks a lot. > Reader 1: ACS non-CCID reader ACR83, with the vnedor-provided modified > CCID driver. Did not work at all. > Reader 2: Gemalto Ezio Shield (variant): PIN commands worked as > expected (with pinmax up to 32, I did not type 32 digits though), > plaintext PIN commands were disallowed with 6d00 > Reader 3: Omnikey 3821: worked as expected with pinpad. > > Also a small patch against pinpadtest.py as I have several readers I > can't disconnect. I added your patch to the script. > It might make sense to make a "probing script" that would discover > deficiencies in reader firmwares (like require certain message bits > (some of them are fixed in the CCID driver) or require fixed PIN > lengths etc) Pinpad entry for vaiable length PIN is a corner area. If there is a way to identify card readers with PC/SC API, we could have white list or black list, but I don't know portable way to distinguish readers. It would be good if we can do probing the feature with no user intervention, but I don't have idea for that. -- From wk at gnupg.org Thu Jan 12 10:23:49 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Jan 2012 10:23:49 +0100 Subject: [PATCH] Added user defined pinentry prompts for SCD. In-Reply-To: <201201112327.q0BNR25I018237@rs136.luxsci.com> (Ben Kibbey's message of "Wed, 11 Jan 2012 18:25:31 -0500") References: <201201110320.q0B3K2WM019378@rs136.luxsci.com> <87lipexx1a.fsf@vigenere.g10code.de> <201201112327.q0BNR25I018237@rs136.luxsci.com> Message-ID: <87ehv5tgt6.fsf@vigenere.g10code.de> On Thu, 12 Jan 2012 00:25, bjk at luxsci.net said: > I posted the patch here so folks can review it and maybe suggest a > better way of going about it. It does need other application support I am fine with the patch after some indentaion changes. > (only app-openpgp has been modified to make use of it). Maybe it would > be better to make a pin-prompt branch? Yes, please do that. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jan 12 10:21:02 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 12 Jan 2012 10:21:02 +0100 Subject: [solved] Re: Unable to compile GnuPG 2.1 beta 3 In-Reply-To: (alphazo@gmail.com's message of "Wed, 11 Jan 2012 22:48:55 +0100") References: <8762haz0nk.fsf@vigenere.g10code.de> <87vcp9x0nq.fsf@vigenere.g10code.de> <87mxa2cq9j.fsf@vigenere.g10code.de> <877h0yujuj.fsf_-_@vigenere.g10code.de> Message-ID: <87ipkhtgxt.fsf@vigenere.g10code.de> On Wed, 11 Jan 2012 22:48, alphazo at gmail.com said: > As a side note, thread is marked as solved but I still have to compile > gnupg2 with "--disable-dirmngr" ;) I know. > I don't use X.509 certificates (yet) under GnuPG so I guess I can > leave without it. The dirmngr is also used to access keyservers in 2.1. Thus I am bretty sure you want it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From g.esp at free.fr Fri Jan 13 09:04:45 2012 From: g.esp at free.fr (Gilles Espinasse) Date: Fri, 13 Jan 2012 09:04:45 +0100 Subject: Shall we do a 1.4.12 ? References: <87ehvd7yok.fsf@vigenere.g10code.de><1b7f01ccce55$fe7a6d40$f9b5a8c0@pii350> <87mx9v26b0.fsf@vigenere.g10code.de> Message-ID: <22fc01ccd1ca$0454ff60$f9b5a8c0@pii350> ----- Original Message ----- From: "Werner Koch" To: "Gilles Espinasse" Cc: Sent: Tuesday, January 10, 2012 11:36 AM Subject: Re: Shall we do a 1.4.12 ? > On Sun, 8 Jan 2012 23:36, g.esp at free.fr said: > > > /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. > > > > The compiler I use is gcc-4.4.5 modified with hardening by default, reason > > If you want to get rid of this warning, please help to track it down. > I try to see what happen using CC='gcc -v' and adding '-no-fatal-warnings' to LDFLAGS That way, I see all DT_TEXTREL issues without stoping at the first and find three. gcc -v -Os -march=i486 -mtune=pentium -pipe -fomit-frame-pointer -Wall -Wno -pointer-sign -Wl,--hash-style=gnu -no-fatal-warnings -o mpicalc mpicalc.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a Using built-in specs. Target: i486-linux-gnu Configured with: ../gcc-4.4.5/configure --prefix=/usr --libexecdir=/usr/lib --disable-nls --e nable-checking=release --enable-shared --enable-threads=posix --enable-__cxa _atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-libmudflap - -disable-libgomp --build=i486-linux-gnu --host=i486-linux-gnu --target=i486- linux-gnu --with-arch=i486 --with-tune=pentium --disable-bootstrap Thread model: posix gcc version 4.4.5 (GCC) COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.5/:/usr/lib/gcc/i486-linux-gnu /4.4.5/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.5/:/usr /lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.5/:/usr/lib/gcc/i48 6-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.5/:/usr/lib/gcc/i486-linux-gnu/ 4.4.5/:/usr/lib/gcc/i486-linux-gnu/4.4.5/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-Os' '-march=i486' '-mtune=pentium' '-pipe' '-fomit-frame-pointer' '-Wall' '-Wno-pointer-sign' '-no-fatal-warnings' '-o' 'mpicalc' /usr/lib/gcc/i486-linux-gnu/4.4.5/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie --warn-shared-textrel -z relro -z combreloc -z now -o mpicalc /usr/lib/gcc/i486-linux-gnu/4.4.5/../../../Scrt1.o /usr/lib/gcc/i486-linux-gnu/4.4.5/../../../crti.o /usr/lib/gcc/i486-linux-gnu/4.4.5/crtbeginS.o -L/usr/lib/gcc/i486-linux-gnu/ 4.4.5 -L/usr/lib/gcc/i486-linux-gnu/4.4.5 -L/usr/lib/gcc/i486-linux-gnu/4.4. 5/../../.. --hash-style=gnu mpicalc.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-ne eded -lgcc_s --no-as-needed /usr/lib/gcc/i486-linux-gnu/4.4.5/crtendS.o /usr/lib/gcc/i486-linux-gnu/4.4.5/../../../crtn.o /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. gcc -v -Os -march=i486 -mtune=pentium -pipe -fomit-frame-pointer -Wall -Wno -pointer-sign -Wl,--hash-style=gnu -no-fatal-warnings -o gpg gpg.o build-packet.o compress.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-packet.o status.o plaintext.o sig-check.o keylist.o signal.o pkclist.o skclist.o pubkey-enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdbio.o delkey.o keygen.o pipemode.o helptext.o keyserver.o photoid.o exec.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -lz -lreadline Using built-in specs. Target: i486-linux-gnu Configured with: ../gcc-4.4.5/configure --prefix=/usr --libexecdir=/usr/lib --disable-nls --e nable-checking=release --enable-shared --enable-threads=posix --enable-__cxa _atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-libmudflap - -disable-libgomp --build=i486-linux-gnu --host=i486-linux-gnu --target=i486- linux-gnu --with-arch=i486 --with-tune=pentium --disable-bootstrap Thread model: posix gcc version 4.4.5 (GCC) COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.5/:/usr/lib/gcc/i486-linux-gnu /4.4.5/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.5/:/usr /lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.5/:/usr/lib/gcc/i48 6-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.5/:/usr/lib/gcc/i486-linux-gnu/ 4.4.5/:/usr/lib/gcc/i486-linux-gnu/4.4.5/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-Os' '-march=i486' '-mtune=pentium' '-pipe' '-fomit-frame-pointer' '-Wall' '-Wno-pointer-sign' '-no-fatal-warnings' '-o' 'gpg' /usr/lib/gcc/i486-linux-gnu/4.4.5/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie --warn-shared-textrel -z relro -z combreloc -z now -o gpg /usr/lib/gcc/i486-linux-gnu/4.4.5/../../../Scrt1.o /usr/lib/gcc/i486-linux-gnu/4.4.5/../../../crti.o /usr/lib/gcc/i486-linux-gnu/4.4.5/crtbeginS.o -L/usr/lib/gcc/i486-linux-gnu/ 4.4.5 -L/usr/lib/gcc/i486-linux-gnu/4.4.5 -L/usr/lib/gcc/i486-linux-gnu/4.4. 5/../../.. --hash-style=gnu gpg.o build-packet.o compress.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-packet.o status.o plaintext.o sig-check.o keylist.o signal.o pkclist.o skclist.o pubkey-enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdbio.o delkey.o keygen.o pipemode.o helptext.o keyserver.o photoid.o exec.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -lz -lreadline -lgcc --as-needed -lgcc_s --no-as-needed -l c -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i486-linux-gnu/4.4.5/crtendS.o /usr/lib/gcc/i486-linux-gnu/4.4.5/../../../crtn.o /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. gcc -v -Os -march=i486 -mtune=pentium -pipe -fomit-frame-pointer -Wall -Wno -pointer-sign -Wl,--hash-style=gnu -no-fatal-warnings -o gpgv gpgv.o build-packet.o compress.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-packet.o status.o plaintext.o sig-check.o keylist.o signal.o verify.o ../cipher/libcipher.a ../mpi/libmpi.a til/libutil.a -lz -lreadline Using built-in specs. Target: i486-linux-gnu Configured with: ../gcc-4.4.5/configure --prefix=/usr --libexecdir=/usr/lib --disable-nls --e nable-checking=release --enable-shared --enable-threads=posix --enable-__cxa _atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-libmudflap - -disable-libgomp --build=i486-linux-gnu --host=i486-linux-gnu --target=i486- linux-gnu --with-arch=i486 --with-tune=pentium --disable-bootstrap Thread model: posix gcc version 4.4.5 (GCC) COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.5/:/usr/lib/gcc/i486-linux-gnu /4.4.5/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.5/:/usr /lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.5/:/usr/lib/gcc/i48 6-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.5/:/usr/lib/gcc/i486-linux-gnu/ 4.4.5/:/usr/lib/gcc/i486-linux-gnu/4.4.5/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-Os' '-march=i486' '-mtune=pentium' '-pipe' '-fomit-frame-pointer' '-Wall' '-Wno-pointer-sign' '-no-fatal-warnings' '-o' 'gpgv' /usr/lib/gcc/i486-linux-gnu/4.4.5/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie --warn-shared-textrel -z relro -z combreloc -z now -o gpgv /usr/lib/gcc/i486-linux-gnu/4.4.5/../../../Scrt1.o /usr/lib/gcc/i486-linux-gnu/4.4.5/../../../crti.o /usr/lib/gcc/i486-linux-gnu/4.4.5/crtbeginS.o -L/usr/lib/gcc/i486-linux-gnu/ 4.4.5 -L/usr/lib/gcc/i486-linux-gnu/4.4.5 -L/usr/lib/gcc/i486-linux-gnu/4.4. 5/../../.. --hash-style=gnu gpgv.o build-packet.o compress.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-packet.o status.o plaintext.o sig-check.o keylist.o signal.o verify.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -lz -lreadline -lgcc --as-needed -lgcc_s --no-as-needed -l c -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i486-linux-gnu/4.4.5/crtendS.o /usr/lib/gcc/i486-linux-gnu/4.4.5/../../../crtn.o /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. Using scanelf as documented in gentoo hardened http://www.gentoo.org/proj/en/hardened/pic-fix-guide.xml#doc_chap2 scanelf -qT g10/gpg g10/gpgv tools/mpicalc gpg: (memory/data?) [0x66EBE] in (optimized out: previous mpihelp_add_n) [0x66E90] gpg: (memory/data?) [0x66F4E] in (optimized out: previous mpihelp_sub_n) [0x66F20] g10/gpg gpgv: (memory/data?) [0x312BE] in (optimized out: previous mpihelp_add_n) [0x31290] gpgv: (memory/data?) [0x3134E] in (optimized out: previous mpihelp_sub_n) [0x31320] g10/gpgv mpicalc: (memory/data?) [0x6A1E] in (optimized out: previous mpihelp_add_n) [0x69F0] mpicalc: (memory/data?) [0x6AAE] in (optimized out: previous mpihelp_sub_n) [0x6A80] tools/mpicalc I see that the issue should be in the same part of code. But I don't understand what need to be fixed and why adding -pie like I do fix that issue (mostly following what Fedora do with LDFLAGS). I should say I don't know if my gcc modified spec is wrong or right. It look -pie is added at the right place but something is missing for mpihelp_* right behavior. > > Compilation produce those new warnings, not seen in 1.4.11 > > miscutil.c:238: warning: format not a string literal, format string not > > checked > > estream-printf.c:1056: warning: format not a string literal, argument types > > not checked > > estream-printf.c:1059: warning: format not a string literal, argument types > > not checked > > so something is wrong, not yet understood what > > Well, we request a warning when using a non-literal in a format. > However at that places we retrieve or create our format string and thus > we will be warned. For gcc 4.6 I added a pragma to suppress thes > warnings. > I understand -Wformat-nonliteral was added after 1.4.11. That's not a big issue seeing a new warning if you know why (gcc doesn't support well strftime string format) > > Using AC_CHECK_FUNCS for clock_gettime is not enought as a test should be > > made with -lrt > > I am now looking at this. > > Maybe adding m4/clock_time.m4 from coreutils is enought (need still to plug that to the makefile) Gilles From jim at meyering.net Sat Jan 14 22:22:01 2012 From: jim at meyering.net (Jim Meyering) Date: Sat, 14 Jan 2012 22:22:01 +0100 Subject: [PATCH] gpg-agent: fix lc-messages handling not to change Xauthority setting Message-ID: <87y5tam13a.fsf@rho.meyering.net> Hi Werner, Coverity spotted the missing break. This one is clearly legitimate: >From d270326fb3f7ad86470e85b2aaa3b06cdf2aaddf Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 14 Jan 2012 22:20:39 +0100 Subject: [PATCH] gpg-agent: fix lc-messages handling not to change Xauthority setting * agent/gpg-agent.c (main): Supply omitted "break" statement for lc-messages option. Otherwise, control would fall through to the following oXauthority case and use the same value there. --- agent/gpg-agent.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index 63f4ba2..c264ba3 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -817,6 +817,7 @@ main (int argc, char **argv ) case oTTYtype: default_ttytype = xstrdup (pargs.r.ret_str); break; case oLCctype: default_lc_ctype = xstrdup (pargs.r.ret_str); break; case oLCmessages: default_lc_messages = xstrdup (pargs.r.ret_str); + break; case oXauthority: default_xauthority = xstrdup (pargs.r.ret_str); break; -- 1.7.9.rc1.2.gccfe4 From jim at meyering.net Sat Jan 14 22:36:08 2012 From: jim at meyering.net (Jim Meyering) Date: Sat, 14 Jan 2012 22:36:08 +0100 Subject: [PATCH] yat2m: don't dereference pointer to freed memory Message-ID: <87pqemm0fr.fsf@rho.meyering.net> Here's an untested patch. Coverity spotted the use-after-free. >From b99a8f0d77509d9f77aa5e42890e927abbbafae0 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Sat, 14 Jan 2012 22:34:58 +0100 Subject: [PATCH] yat2m: don't dereference pointer to freed memory * doc/yat2m.c (top_parse_file): Correct macrolist-freeing loop. --- doc/yat2m.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/yat2m.c b/doc/yat2m.c index aaa7ea6..a22176c 100644 --- a/doc/yat2m.c +++ b/doc/yat2m.c @@ -1203,10 +1203,10 @@ top_parse_file (const char *fname, FILE *fp) if not in a section. */ while (macrolist) { - macro_t m = macrolist->next; - free (m->value); - free (m); - macrolist = m; + macro_t next = macrolist->next; + free (macrolist->value); + free (macrolist); + macrolist = next; } parse_file (fname, fp, §ion_name, 0); -- 1.7.9.rc1.2.gccfe4 From wk at gnupg.org Mon Jan 16 11:53:09 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Jan 2012 11:53:09 +0100 Subject: [PATCH] yat2m: don't dereference pointer to freed memory In-Reply-To: <87pqemm0fr.fsf@rho.meyering.net> (Jim Meyering's message of "Sat, 14 Jan 2012 22:36:08 +0100") References: <87pqemm0fr.fsf@rho.meyering.net> Message-ID: <87wr8rrka2.fsf@vigenere.g10code.de> On Sat, 14 Jan 2012 22:36, jim at meyering.net said: > { > - macro_t m = macrolist->next; > - free (m->value); > - free (m); > - macrolist = m; Oops. Such a common pattern I still got it wrong. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jan 16 11:53:56 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 16 Jan 2012 11:53:56 +0100 Subject: [PATCH] gpg-agent: fix lc-messages handling not to change Xauthority setting In-Reply-To: <87y5tam13a.fsf@rho.meyering.net> (Jim Meyering's message of "Sat, 14 Jan 2012 22:22:01 +0100") References: <87y5tam13a.fsf@rho.meyering.net> Message-ID: <87pqejrk8r.fsf@vigenere.g10code.de> On Sat, 14 Jan 2012 22:22, jim at meyering.net said: > Coverity spotted the missing break. > This one is clearly legitimate: Sure. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jan 17 11:39:03 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Jan 2012 11:39:03 +0100 Subject: GnuPG 1.4 for Windows Message-ID: <87obu2pq9k.fsf@vigenere.g10code.de> Hi, over the last days I did some work on the GnuPG 1.4 port for Windows. The major change is that I now use the mingw64 toolchain (the 32 bit version). This required a few fixes. Before I do the 1.4.12 release, I would like to have some more tests with that builds. Shall I make a Beta installer available? Partly due to the donations we received for GnuPG over the last months, I revamped the installer build procedure. It is now possible to build the installer directly from a release ready tarball and an optional patch file. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jan 17 11:50:10 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Jan 2012 11:50:10 +0100 Subject: Smartcards and 1.4 Message-ID: <87k44qppr1.fsf@vigenere.g10code.de> Hi, GnuPG 1.4 uses the smartcard code from 2.0. This is made possible by using some glue code and copies of the required source files. The problem with this approach is that testing the smartcard functions is very time consuming. Thus I consider a change for post 1.4.12: Either: 1. Drop the smartcard stuff completely. 2. Feature freeze, keep the code as it is and don't update it from 2.0. (I will do this for 1.4.12) 3. Keep the functionality but require the use of the gpg-agent. (As of now gpg uses the gpg-agent if available but falls back to an included copy of scdaemon code other wise). Comments? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From simon at josefsson.org Tue Jan 17 14:35:48 2012 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 17 Jan 2012 14:35:48 +0100 Subject: Smartcards and 1.4 In-Reply-To: <87k44qppr1.fsf@vigenere.g10code.de> (Werner Koch's message of "Tue, 17 Jan 2012 11:50:10 +0100") References: <87k44qppr1.fsf@vigenere.g10code.de> Message-ID: <87fwfepi2z.fsf@latte.josefsson.org> Werner Koch writes: > Hi, > > GnuPG 1.4 uses the smartcard code from 2.0. This is made possible by > using some glue code and copies of the required source files. The > problem with this approach is that testing the smartcard functions is > very time consuming. Thus I consider a change for post 1.4.12: > > Either: > > 1. Drop the smartcard stuff completely. > > 2. Feature freeze, keep the code as it is and don't update it from 2.0. > (I will do this for 1.4.12) > > 3. Keep the functionality but require the use of the gpg-agent. > (As of now gpg uses the gpg-agent if available but falls back to an > included copy of scdaemon code other wise). > > Comments? How about: 4. Drop the included copies of 2.0 code for smartcard use, and require the use of gpg-agent if someone wants to use smart cards with v1. Is this what you meant by 1? It wasn't clear to me if 1 also meant removing the gpg-agent code or not. Or was this meant by 3? It wasn't clear to me if 3 implied removing any code or not. Perhaps it is coffee time here. :-) /Simon From wk at gnupg.org Tue Jan 17 18:24:28 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 17 Jan 2012 18:24:28 +0100 Subject: Smartcards and 1.4 In-Reply-To: <87fwfepi2z.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 17 Jan 2012 14:35:48 +0100") References: <87k44qppr1.fsf@vigenere.g10code.de> <87fwfepi2z.fsf@latte.josefsson.org> Message-ID: <877h0qp7hv.fsf@vigenere.g10code.de> On Tue, 17 Jan 2012 14:35, simon at josefsson.org said: > 4. Drop the included copies of 2.0 code for smartcard use, and require > the use of gpg-agent if someone wants to use smart cards with v1. That is what I meant with 3. We would keep the smart card menu code from 2.0, because that needs to be in gpg, proper. > Is this what you meant by 1? It wasn't clear to me if 1 also meant No, 1 was about removing *all* smart card code. I guess this is not acceptable. > removing the gpg-agent code or not. Or was this meant by 3? It wasn't > clear to me if 3 implied removing any code or not. Perhaps it is coffee Right. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jeanjacquesbrucker at gmail.com Tue Jan 17 20:50:21 2012 From: jeanjacquesbrucker at gmail.com (Jbar) Date: Tue, 17 Jan 2012 20:50:21 +0100 Subject: get the trust level of an external key Message-ID: <201201172050.37736.jeanjacquesbrucker@gmail.com> Hi, To save space in a keyring, I would like to store only full trusted key in it. Is there a way to check the trust level of an external certificate before to import it ? or are we forced to import it, check its trust and then remove it (or not) ? (that question is for some non-interactive scripts) Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Tue Jan 17 22:13:52 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 17 Jan 2012 16:13:52 -0500 Subject: get the trust level of an external key In-Reply-To: <201201172050.37736.jeanjacquesbrucker@gmail.com> References: <201201172050.37736.jeanjacquesbrucker@gmail.com> Message-ID: <4F15E490.5000904@fifthhorseman.net> On 01/17/2012 02:50 PM, Jbar wrote: > To save space in a keyring, I would like to store only full trusted key in it. > > Is there a way to check the trust level of an external certificate before to import it ? or are we forced to import it, check its > trust and then remove it (or not) ? if you're talking about actual trust (meaning keys to which you have assigned, say, marginal or full or ultimate ownertrust) then you can just check the fingerprint against the info from: gpg --export-ownertrust If instead, you're talking about the validity of User IDs, you should be aware that this is not the same thing as trust (and that it can change over time, e.g. as certifications expire, keys are revoked, etc). For example, you might know for certain (via a fully-valid User ID) that key X belongs to "Evil Bad Guy " -- but you might not want to consider that a trusted key. In either case, though, it's probably simplest to import the key to get gpg to do any sort of sophisticated operations on it. if you want to avoid contaminating one particular keyring, you could set up multiple GNUPGHOME directories -- one for triage, and once a key has passed triage, it could be exported into the "cleaner" keyring. Whether this is a useful arrangement probably depends on the needs and implementation of the rest of your system, though. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From hans at at.or.at Tue Jan 17 23:44:26 2012 From: hans at at.or.at (Hans-Christoph Steiner) Date: Tue, 17 Jan 2012 17:44:26 -0500 Subject: porting gnupg to Android, is pth required? In-Reply-To: <1326505894.10230.140661023201905@webmail.messagingengine.com> References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> Message-ID: <1326840266.20291.17.camel@palatschinken.at.or.at> On Fri, 2012-01-13 at 20:51 -0500, Hans-Christoph Steiner wrote: > > On Fri, Jan 13, 2012, at 16:09, Hans-Christoph Steiner wrote: > > > > I'm in the process of porting gnupg to Android, and I've gotten > > libgpg-error, libgcrypt, libassuan, and libksba all building for > > Android. The big stickler right now is GNU Pth, it looks like it could > > be a lot of work to get running on Android. gnupg's ./configure seems > > to say that Pth is now required. Is it possible to build gnupg without > > Pth? If not in a current version, in a previous version? > > > > .hc > > > Well, I've gotten pth built for Android and am now stuck on OpenLDAP. > Is that absolutely required? ;-) > > .hc > Progress and a git repo! But no gnupg build yet. https://github.com/guardianproject/gnupg-for-android Ah... openldap is built and gnupg's ./configure is happy with it, but now I'm getting this very odd error triggered from gl/allocsa.c with both 2.1.0beta3 and the head of master: /usr/local/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc --sysroot=/usr/local/android-ndk/platforms/android-9/arch-arm -DHAVE_CONFIG_H -I. -I.. -DANDROID -I/media/share/code/guardianproject/gnupg-for-android/external/include -O3 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith -MT allocsa.o -MD -MP -MF .deps/allocsa.Tpo -c -o allocsa.o allocsa.c In file included from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/sys/time.h:33, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:32, from ./stdint.h:88, from /usr/local/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/sys/types.h:43, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/strings.h:42, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/stdlib.h:42, from allocsa.h:23, from allocsa.c:21: /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/linux/time.h:20: error: expected specifier-qualifier-list before 'time_t' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/linux/time.h:26: error: expected specifier-qualifier-list before 'time_t' In file included from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/asm/siginfo.h:15, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:35, from ./stdint.h:88, from /usr/local/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/sys/types.h:43, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/strings.h:42, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/stdlib.h:42, from allocsa.h:23, from allocsa.c:21: /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/asm-generic/siginfo.h:51: error: expected specifier-qualifier-list before 'pid_t' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/asm-generic/siginfo.h:56: error: expected specifier-qualifier-list before 'timer_t' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/asm-generic/siginfo.h:64: error: expected specifier-qualifier-list before 'pid_t' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/asm-generic/siginfo.h:70: error: expected specifier-qualifier-list before 'pid_t' In file included from ./stdint.h:88, from /usr/local/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/sys/types.h:43, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/strings.h:42, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/stdlib.h:42, from allocsa.h:23, from allocsa.c:21: /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:40: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'time' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:70: error: expected ')' before '__time1' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:71: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'mktime' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:73: error: expected ';', ',' or ')' before '*' token /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:74: error: expected ';', ',' or ')' before '*' token /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:76: error: expected ';', ',' or ')' before '*' token /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:77: error: expected ';', ',' or ')' before '*' token /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:82: error: expected ';', ',' or ')' before '*' token /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:83: error: expected ';', ',' or ')' before '*' token /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:94: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'clock' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:107: error: expected declaration specifiers or '...' before 'timer_t' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:109: error: expected ')' before 'timerid' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:110: error: expected ')' before 'timerid' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:111: error: expected ')' before 'timerid' allocsa.c: In function 'mallocsa': allocsa.c:82: warning: cast increases required alignment of target type allocsa.c:86: warning: cast increases required alignment of target type allocsa.c: In function 'freesa': allocsa.c:126: warning: cast increases required alignment of target type allocsa.c:130: warning: cast increases required alignment of target type make[4]: *** [allocsa.o] Error 1 make[4]: Leaving directory `/media/share/code/guardianproject/gnupg-for-android/external/gnupg/gl' make[3]: *** [all] Error 2 make[3]: Leaving directory `/media/share/code/guardianproject/gnupg-for-android/external/gnupg/gl' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/media/share/code/guardianproject/gnupg-for-android/external/gnupg' make[1]: *** [all] Error 2 make[1]: Leaving directory `/media/share/code/guardianproject/gnupg-for-android/external/gnupg' make: *** [gnupg-build-stamp] Error 2 From leftfoot at siu.edu Tue Jan 17 23:38:15 2012 From: leftfoot at siu.edu (S.U.) Date: Tue, 17 Jan 2012 16:38:15 -0600 Subject: PHP5+PECL-gnupg-1.3 fails in CLI mode ("Result too large", "could not init keylist") Message-ID: <4F15F857.4010609@siu.edu> Attempting a simple PHP (pecl) gnupg key lookup fails with a "could not init keylist" error in a Solaris environment, using PHP CLI mode. Note that using the same basic code under Apache2+PHP5 works just fine (under Solaris). Under FreeBSD-7/8, the PHP5 CLI mode + PECL GnuPG works just fine (as does Apache+PHP5 mode). Sample Code ======================================= keyinfo(""); echo $gpg->geterror() . "\n"; echo "res:\n";print_r($res);echo"\n"; exit; ?> ======================================== Enabling GPGME_DEBUG=9 environment variable includes the following message: GPGME 2012-01-06 11:59:56 <0x0638> gpgme_op_keylist_start: error: Result too large Environments ===================================================== a) Solaris 10 u10 x86-64 b) Solaris 10 u9 x86-64 c) Solaris 10 u10 sparc (64-bit) d) Solaris 10 u10 x86-64 (64-bit OS, 32-bit boot before compiles) e) Solaris 10 u8 x86 (32-bit) gpgme-1.3.1.tar.bz2 libassuan-2.0.3.tar.bz2 libgpg-error-1.10.tar.bz2 pecl gnupg 1.3.2 php-5.3.5.tar.bz2 or php-5.3.8.tar.bz2 gnupg-1.4.11.tar.bz2 gnupg-2.0.18.tar.bz2 (not installed in all cases) ===================================================== Added parameters for compilation of PECL-GNUPG required because of GPGME LFS ===================================================== setenv CFLAGS '-D_FILE_OFFSET_BITS=64' ===================================================== Full GPGME+gpg2 debug output: ======================================================== GPGME 2012-01-06 12:13:28 <0x064d> gpgme_debug: level=9 GPGME 2012-01-06 12:13:28 <0x064d> gpgme_check_version: call: 0=0, req_version=(null), VERSION=1.3.1 GPGME 2012-01-06 12:13:28 <0x064d> gpgme_check_version_internal: call: 0=0, req_version=(null), offset_sig_validity=32 GPGME 2012-01-06 12:13:28 <0x064d> gpgme_new: enter: r_ctx=804643c GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_pipe: enter: filedes=8046268, inherit_idx=1 (GPGME uses it for reading) GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_pipe: leave: read=0x4, write=0x5 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: enter: path=fdef4e47, path=/usr/local/bin/gpg GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef4e47, argv[ 0] = /usr/local/bin/gpg GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef4e47, argv[ 1] = --version GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef4e47, fd[0] = 0x5 -> 0x1 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef4e47, waiting for child process pid=1614 GPGME 2012-01-06 12:13:28 <0x064f> gpgme:max_fds: call: 0=0, max fds=65536 (RLIMIT_NOFILE) GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: enter: fd=5 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: enter: fd=4, buffer=80462a0, count=79 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 6770672028476e75 50472920312e342e gpg (GnuPG) 1.4. GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 31310a436f707972 6967687420284329 11.Copyright (C) GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 2032303130204672 656520536f667477 2010 Free Softw GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 61726520466f756e 646174696f6e2c20 are Foundation, GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 496e632e0a4c6963 656e7365204750 Inc..License GP GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: leave: result=79 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: enter: fd=4 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_pipe: enter: filedes=8046268, inherit_idx=1 (GPGME uses it for reading) GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_pipe: leave: read=0x4, write=0x5 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: enter: path=fdef526b, path=/usr/local/bin/gpgsm GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef526b, argv[ 0] = /usr/local/bin/gpgsm GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef526b, argv[ 1] = --version GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef526b, fd[0] = 0x5 -> 0x1 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef526b, waiting for child process pid=1616 GPGME 2012-01-06 12:13:28 <0x0651> gpgme:max_fds: call: 0=0, max fds=65536 (RLIMIT_NOFILE) GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: enter: fd=5 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: enter: fd=4, buffer=80462a0, count=79 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 677067736d202847 6e7550472920322e gpgsm (GnuPG) 2. GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 302e31380a6c6962 6763727970742031 0.18.libgcrypt 1 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 2e352e300a6c6962 6b73626120312e32 .5.0.libksba 1.2 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 2e300a436f707972 6967687420284329 .0.Copyright (C) GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 2032303131204672 656520536f6674 2011 Free Soft GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: leave: result=79 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: enter: fd=4 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_pipe: enter: filedes=8046268, inherit_idx=1 (GPGME uses it for reading) GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_pipe: leave: read=0x4, write=0x5 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: enter: path=fdef49cd, path=/usr/local/bin/gpgconf GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef49cd, argv[ 0] = /usr/local/bin/gpgconf GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef49cd, argv[ 1] = --version GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef49cd, fd[0] = 0x5 -> 0x1 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef49cd, waiting for child process pid=1618 GPGME 2012-01-06 12:13:28GPGME <0x0653> gpgme:max_fds: call: 0=0, max fds=65536 (RLIMIT_NOFILE) 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: enter: fd=5 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: enter: fd=4, buffer=80462a0, count=79 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 677067636f6e6620 28476e7550472920 gpgconf (GnuPG) GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 322e302e31380a43 6f70797269676874 2.0.18.Copyright GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 2028432920323031 3120467265652053 (C) 2011 Free S GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 6f66747761726520 466f756e64617469 oftware Foundati GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 6f6e2c20496e632e 0a4c6963656e73 on, Inc..Licens GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: leave: result=79 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: enter: fd=4 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_pipe: enter: filedes=8045ee8, inherit_idx=1 (GPGME uses it for reading) GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_pipe: leave: read=0x4, write=0x5 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: enter: path=fdef49cd, path=/usr/local/bin/gpgconf GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef49cd, argv[ 0] = /usr/local/bin/gpgconf GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef49cd, argv[ 1] = --list-dirs GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef49cd, fd[0] = 0x5 -> 0x1 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: check: path=fdef49cd, waiting for child process pid=1620 GPGME GPGME 2012-01-06 12:13:28 <0x0655> gpgme:max_fds: call: 0=0, max fds=65536 (RLIMIT_NOFILE) 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: enter: fd=5 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_spawn: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: enter: fd=4, buffer=8045f20, count=1023 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 737973636f6e6664 69723a2f7573722f sysconfdir:/usr/ GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 6c6f63616c2f6574 632f676e7570670a local/etc/gnupg. GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 62696e6469723a2f 7573722f6c6f6361 bindir:/usr/loca GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 6c2f62696e0a6c69 6265786563646972 l/bin.libexecdir GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 3a2f7573722f6c6f 63616c2f6c696265 :/usr/local/libe GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 7865630a6c696264 69723a2f7573722f xec.libdir:/usr/ GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 6c6f63616c2f6c69 622f676e7570670a local/lib/gnupg. GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 646174616469723a 2f7573722f6c6f63 datadir:/usr/loc GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 616c2f7368617265 2f676e7570670a6c al/share/gnupg.l GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 6f63616c65646972 3a2f7573722f6c6f ocaledir:/usr/lo GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 63616c2f73686172 652f6c6f63616c65 cal/share/locale GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 0a6469726d6e6772 2d736f636b65743a .dirmngr-socket: GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 2f7661722f72756e 2f6469726d6e6772 /var/run/dirmngr GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 2f736f636b65740a 6167656e742d736f /socket.agent-so GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx cket:xxxxxxxxxxx GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx xxxxxx/.gnupg/S. GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: 6770672d6167656e 740a686f6d656469 gpg-agent.homedi GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: check: xxxxxxxxxxxxxxxx xxxxxx xxx/.gnupg. GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: leave: result=299 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: enter: fd=4, buffer=8045f20, count=1023 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_read: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: enter: fd=4 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> gpgme_new: leave: ctx=89f9b38 GPGME 2012-01-06 12:13:28 <0x064d> gpgme_set_armor: call: ctx=89f9b38, use_armor=1 (yes) GPGME 2012-01-06 12:13:28 <0x064d> gpgme_op_keylist_start: enter: ctx=89f9b38, pattern=Jones, secret_only=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_pipe: enter: filedes=89f9c54, inherit_idx=1 (GPGME uses it for reading) GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_pipe: leave: read=0x4, write=0x5 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_set_close_notify: enter: fd=4, close_handler=fdee6078/89f9c40 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_set_close_notify: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_set_close_notify: enter: fd=5, close_handler=fdee6078/89f9c40 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_set_close_notify: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: enter: fd=4 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: check: fd=4, invoking close handler fdee6078/89f9c40 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: enter: fd=5 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: check: fd=5, invoking close handler fdee6078/89f9c40 GPGME 2012-01-06 12:13:28 <0x064d> _gpgme_io_close: leave: result=0 GPGME 2012-01-06 12:13:28 <0x064d> gpgme_op_keylist_start: error: Result too large could not init keylist res: GPGME 2012-01-06 12:13:28 <0x064d> gpgme_signers_clear: call: ctx=89f9b38 GPGME 2012-01-06 12:13:28 <0x064d> gpgme_release: call: ctx=89f9b38 ======================================================== Full GPGME-gpg2 debug output: ========================================================= GPGME 2012-01-06 12:12:39 <0x03c2> gpgme_debug: level=9 GPGME 2012-01-06 12:12:39 <0x03c2> gpgme_check_version: call: 0=0, req_version=(null), VERSION=1.3.1 GPGME 2012-01-06 12:12:39 <0x03c2> gpgme_check_version_internal: call: 0=0, req_version=(null), offset_sig_validity=32 GPGME 2012-01-06 12:12:39 <0x03c2> gpgme_new: enter: r_ctx=80466fc GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_pipe: enter: filedes=8046528, inherit_idx=1 (GPGME uses it for reading) GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_pipe: leave: read=0x4, write=0x5 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_spawn: enter: path=feac0772, path=/usr/local/bin//gpg GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_spawn: check: path=feac0772, argv[ 0] = /usr/local/bin//gpg GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_spawn: check: path=feac0772, argv[ 1] = --version GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_spawn: check: path=feac0772, fd[0] = 0x5 -> 0x1 GPGME 2012-01-06 12:12:39 <0x03c4> gpgme:max_fds: call: 0=0, max fds=65536 (RLIMIT_NOFILE) GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_spawn: check: path=feac0772, waiting for child process pid=963 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_close: enter: fd=5 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_close: leave: result=0 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_spawn: leave: result=0 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_read: enter: fd=4, buffer=8046560, count=79 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_read: check: 6770672028476e75 50472920312e342e gpg (GnuPG) 1.4. GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_read: check: 31310a436f707972 6967687420284329 11.Copyright (C) GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_read: check: 2032303130204672 656520536f667477 2010 Free Softw GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_read: check: 61726520466f756e 646174696f6e2c20 are Foundation, GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_read: check: 496e632e0a4c6963 656e7365204750 Inc..License GP GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_read: leave: result=79 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_close: enter: fd=4 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_close: leave: result=0 GPGME 2012-01-06 12:12:39 <0x03c2> gpgme_new: leave: ctx=894f8d8 GPGME 2012-01-06 12:12:39 <0x03c2> gpgme_set_armor: call: ctx=894f8d8, use_armor=1 (yes) GPGME 2012-01-06 12:12:39 <0x03c2> gpgme_op_keylist_start: enter: ctx=894f8d8, pattern=Jones, secret_only=0 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_pipe: enter: filedes=895016c, inherit_idx=1 (GPGME uses it for reading) GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_pipe: leave: read=0x4, write=0x5 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_set_close_notify: enter: fd=4, close_handler=feab5db4/8950158 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_set_close_notify: leave: result=0 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_set_close_notify: enter: fd=5, close_handler=feab5db4/8950158 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_set_close_notify: leave: result=0 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_close: enter: fd=4 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_close: check: fd=4, invoking close handler feab5db4/8950158 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_close: leave: result=0 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_close: enter: fd=5 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_close: check: fd=5, invoking close handler feab5db4/8950158 GPGME 2012-01-06 12:12:39 <0x03c2> _gpgme_io_close: leave: result=0 GPGME 2012-01-06 12:12:39 <0x03c2> gpgme_op_keylist_start: error: Result too large could not init keylist res: GPGME 2012-01-06 12:12:39 <0x03c2> gpgme_signers_clear: call: ctx=894f8d8 GPGME 2012-01-06 12:12:39 <0x03c2> gpgme_release: call: ctx=894f8d8 ========================================================= From jeanjacquesbrucker at gmail.com Wed Jan 18 07:08:46 2012 From: jeanjacquesbrucker at gmail.com (Jbar) Date: Wed, 18 Jan 2012 07:08:46 +0100 Subject: get the trust level of an external key In-Reply-To: <4F15E490.5000904@fifthhorseman.net> References: <201201172050.37736.jeanjacquesbrucker@gmail.com> <4F15E490.5000904@fifthhorseman.net> Message-ID: <201201180708.51444.jeanjacquesbrucker@gmail.com> Le mardi 17 janvier 2012 22:13:52, Daniel Kahn Gillmor a ?crit : > On 01/17/2012 02:50 PM, Jbar wrote: > > > > Is there a way to check the trust level of an external certificate before > > to import it ? or are we forced to import it, check its trust and then > > remove it (or not) ? > > If instead, you're talking about the validity of User IDs, you should be > aware that this is not the same thing as trust (and that it can change > over time, e.g. as certifications expire, keys are revoked, etc). Yes, I am talking about validity, I was saying "trust" because it is written as so in some old GnuPG manuals. Better choice is to designate this both concepts with the words "validity" and "ownertrust", indeed. (Instead of words "trust" and "ownertrust"). > > In either case, though, it's probably simplest to import the key to get > gpg to do any sort of sophisticated operations on it. > > if you want to avoid contaminating one particular keyring, you could set > up multiple GNUPGHOME directories -- one for triage, and once a key has > passed triage, it could be exported into the "cleaner" keyring. Whether > this is a useful arrangement probably depends on the needs and > implementation of the rest of your system, though. > > hth, > > --dkg I won't like to import the key as in fact I already manage several keyrings. My use is close to something needed relative to the RFC 6091 http://tools.ietf.org/html/rfc6091 which you did write with Nikolas Mavrogiannopoulos * : I have agents (also called bots) which send their OpenPGP certificate (with sigs), to others. Each agent maintain the same keyring, the smallest possible (only minimized valid certificates, and with ownertrust=4:marginal) (and which contain only individual/human certificates). I then want to check the validity of the agent/bot certificate (according to the individual/human keyring).** I have check what GnuTLS does about that : http://www.gnu.org/software/gnutls/manual/html_node/OpenPGP- API.html#gnutls_005fopenpgp_005fcrt_005fverify_005fring ; and that is not sufficient to detect validity of the certificate, which should so be done manually :-(. I don't know if GnuTLS use libgpgme, but to test with gpg the validity of an external key may be a great feature, for GnuTLS, Monkeysphere, and OpenUDC (our project). What do you think ? (Is there someone to code the patch, please ?) *: _Note 1:_ I don't use RFC6091 or GnuTLS today, because I don't care/need about encryption and don't code in C but with bash to develop and test the required software architectures and features faster **: _Note 2:_ about our indivudual/human and agent/bot certificates, we wrote draft : https://github.com/jbar/open- udc/blob/master/docs/Authentication_Mechanisms.draft.txt (not completely up to date, comments welcomes). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: From simon at josefsson.org Wed Jan 18 10:51:43 2012 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 18 Jan 2012 10:51:43 +0100 Subject: Smartcards and 1.4 In-Reply-To: <877h0qp7hv.fsf@vigenere.g10code.de> (Werner Koch's message of "Tue, 17 Jan 2012 18:24:28 +0100") References: <87k44qppr1.fsf@vigenere.g10code.de> <87fwfepi2z.fsf@latte.josefsson.org> <877h0qp7hv.fsf@vigenere.g10code.de> Message-ID: <87pqeh8hjk.fsf@latte.josefsson.org> Werner Koch writes: > On Tue, 17 Jan 2012 14:35, simon at josefsson.org said: > >> 4. Drop the included copies of 2.0 code for smartcard use, and require >> the use of gpg-agent if someone wants to use smart cards with v1. > > That is what I meant with 3. We would keep the smart card menu code > from 2.0, because that needs to be in gpg, proper. Then I support that option. As a user, I find having to debug and analyze two different implementations to get proper smart card functionality is more complicated than debugging one implementation and to live with the extra step to install gpg-agent for gpg 1.x. /Simon From wk at gnupg.org Wed Jan 18 11:28:45 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Jan 2012 11:28:45 +0100 Subject: porting gnupg to Android, is pth required? In-Reply-To: <1326840266.20291.17.camel@palatschinken.at.or.at> (Hans-Christoph Steiner's message of "Tue, 17 Jan 2012 17:44:26 -0500") References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> Message-ID: <8739bdnw2q.fsf@vigenere.g10code.de> Hi, I have not seen your previous two mails (HTML parts?), but let me give you a short comment anyway: >> On Fri, Jan 13, 2012, at 16:09, Hans-Christoph Steiner wrote: >> > be a lot of work to get running on Android. gnupg's ./configure seems >> > to say that Pth is now required. Is it possible to build gnupg without Pth is for a looong time a requirement for GnuPG-2. However, there are only a few users of Pth left and thus we plan to drop Pth support. Instead, we will use a new library (nPth) which has a very similar interface but internally uses the systems's standard trhead implementaions. That is pthreads on most Unix systems and WindowsThreads on Windows. This change will help us to solve conflicts with other libraries used by GnuPG and Pth. There is a npth branch for GnupG which will soon be merged into master. >> Well, I've gotten pth built for Android and am now stuck on OpenLDAP. >> Is that absolutely required? ;-) No, OpenLDAP is only required for the dirmngr. However with 2.1 Dirmngr is resonsible for all network access (keyservers etc.), thus eventually you need to support it. ./configure --disable-dirmngr allows to build without dirmngr. > Ah... openldap is built and gnupg's ./configure is happy with it, but > now I'm getting this very odd error triggered from gl/allocsa.c with > both 2.1.0beta3 and the head of master: I don't know. You may want to check whether gnulib has updates for this code. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jan 18 14:30:45 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Jan 2012 14:30:45 +0100 Subject: PHP5+PECL-gnupg-1.3 fails in CLI mode ("Result too large", "could not init keylist") In-Reply-To: <4F15F857.4010609@siu.edu> (S. U.'s message of "Tue, 17 Jan 2012 16:38:15 -0600") References: <4F15F857.4010609@siu.edu> Message-ID: <87lip5m92y.fsf@vigenere.g10code.de> On Tue, 17 Jan 2012 23:38, leftfoot at siu.edu said: > Attempting a simple PHP (pecl) gnupg key lookup fails with a "could not init > keylist" error in a Solaris environment, using PHP CLI mode. Note that using > Enabling GPGME_DEBUG=9 environment variable includes the following message: > > GPGME 2012-01-06 11:59:56 <0x0638> gpgme_op_keylist_start: error: Result too > large "Result too large" is not an error code printed by GPGME or GnuPG. The debug output might be mixed up with other output to stdout. To check this, please use: GPGME_DEBUG=9:/foo/bar/gpgme.log so that gpgme will only write to the given file. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at at.or.at Wed Jan 18 16:05:29 2012 From: hans at at.or.at (Hans-Christoph Steiner) Date: Wed, 18 Jan 2012 10:05:29 -0500 Subject: porting gnupg to Android, is pth required? In-Reply-To: <8739bdnw2q.fsf@vigenere.g10code.de> References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> Message-ID: <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> On Jan 18, 2012, at 5:28 AM, Werner Koch wrote: > Hi, > > I have not seen your previous two mails (HTML parts?), but let me give > you a short comment anyway: Thanks for your reply. >>> On Fri, Jan 13, 2012, at 16:09, Hans-Christoph Steiner wrote: > >>>> be a lot of work to get running on Android. gnupg's ./configure seems >>>> to say that Pth is now required. Is it possible to build gnupg without > > Pth is for a looong time a requirement for GnuPG-2. However, there are > only a few users of Pth left and thus we plan to drop Pth support. > Instead, we will use a new library (nPth) which has a very similar > interface but internally uses the systems's standard trhead > implementaions. That is pthreads on most Unix systems and > WindowsThreads on Windows. This change will help us to solve conflicts > with other libraries used by GnuPG and Pth. > > There is a npth branch for GnupG which will soon be merged into master. Well, I got pth built so I think it'll work. For now I'll keep it, unless you think the Android port would be better without it. >>> Well, I've gotten pth built for Android and am now stuck on OpenLDAP. >>> Is that absolutely required? ;-) > > No, OpenLDAP is only required for the dirmngr. However with 2.1 Dirmngr > is resonsible for all network access (keyservers etc.), thus eventually > you need to support it. ./configure --disable-dirmngr allows to build > without dirmngr. Ah, ok, --disable-ldap wasn't working for me. I suppose I needed also --disable-dirmngr. We want keyserver support for sure, and openldap is built for Android now. Does gnupg need any of the openldap client or server programs? I only installed the libraries. >> Ah... openldap is built and gnupg's ./configure is happy with it, but >> now I'm getting this very odd error triggered from gl/allocsa.c with >> both 2.1.0beta3 and the head of master: > > I don't know. You may want to check whether gnulib has updates for this > code. Ah, ok so 'gl' stands for gnulib. I've done quite a bit of porting, but haven't used gnulib before. I've never seen a project that makes its own versions of system headers like alloca.h, is this behavior inherited from gnulib? .hc ---------------------------------------------------------------------------- "[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore From alphazo at gmail.com Wed Jan 18 16:10:09 2012 From: alphazo at gmail.com (Alphazo) Date: Wed, 18 Jan 2012 16:10:09 +0100 Subject: porting gnupg to Android, is pth required? In-Reply-To: <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> Message-ID: How does this project compare to APG for Android? http://www.thialfihar.org/projects/apg/ https://market.android.com/details?id=org.thialfihar.android.apg&hl=en Thanks Alphazo On Wed, Jan 18, 2012 at 4:05 PM, Hans-Christoph Steiner wrote: > > On Jan 18, 2012, at 5:28 AM, Werner Koch wrote: > >> Hi, >> >> I have not seen your previous two mails (HTML parts?), but let me give >> you a short comment anyway: > > Thanks for your reply. > >>>> On Fri, Jan 13, 2012, at 16:09, Hans-Christoph Steiner wrote: >> >>>>> be a lot of work to get running on Android. ?gnupg's ./configure seems >>>>> to say that Pth is now required. ?Is it possible to build gnupg without >> >> Pth is for a looong time a requirement for GnuPG-2. ?However, there are >> only a few users of Pth left and thus we plan to drop Pth support. >> Instead, we will use a new library (nPth) which has a very similar >> interface but internally uses the systems's standard trhead >> implementaions. ?That is pthreads on most Unix systems and >> WindowsThreads on Windows. ?This change will help us to solve conflicts >> with other libraries used by GnuPG and Pth. >> >> There is a npth branch for GnupG which will soon be merged into master. > > Well, I got pth built so I think it'll work. ?For now I'll keep it, unless you think the Android port would be better without it. > > >>>> Well, I've gotten pth built for Android and am now stuck on OpenLDAP. >>>> Is that absolutely required? ?;-) >> >> No, OpenLDAP is only required for the dirmngr. ?However with 2.1 Dirmngr >> is resonsible for all network access (keyservers etc.), thus eventually >> you need to support it. ?./configure --disable-dirmngr allows to build >> without dirmngr. > > Ah, ok, --disable-ldap wasn't working for me. ?I suppose I needed also --disable-dirmngr. ?We want keyserver support for sure, and openldap is built for Android now. ?Does gnupg need any of the openldap client or server programs? ?I only installed the libraries. > > >>> Ah... openldap is built and gnupg's ./configure is happy with it, but >>> now I'm getting this very odd error triggered from gl/allocsa.c with >>> both 2.1.0beta3 and the head of master: >> >> I don't know. ?You may want to check whether gnulib has updates for this >> code. > > Ah, ok so 'gl' stands for gnulib. ?I've done quite a bit of porting, but haven't used gnulib before. ?I've never seen a project that makes its own versions of system headers like alloca.h, is this behavior inherited from gnulib? > > > .hc > > > ---------------------------------------------------------------------------- > > "[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." ? ? ? ?-John Gilmore > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From wk at gnupg.org Wed Jan 18 16:56:04 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Jan 2012 16:56:04 +0100 Subject: porting gnupg to Android, is pth required? In-Reply-To: <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> (Hans-Christoph Steiner's message of "Wed, 18 Jan 2012 10:05:29 -0500") References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> Message-ID: <87pqehknsb.fsf@vigenere.g10code.de> On Wed, 18 Jan 2012 16:05, hans at at.or.at said: > Well, I got pth built so I think it'll work. For now I'll keep it, unless you think the Android port would be better without it. We will switch with the next beta. Anyway using the new lib should be easier than Pth. Keep it for now. > --disable-dirmngr. We want keyserver support for sure, and openldap > is built for Android now. Does gnupg need any of the openldap client > or server programs? I only installed the libraries. No, we only need the library. --disable-ldap should also work. It is a still a development version and thus I don't care too much about these little bugs. > Ah, ok so 'gl' stands for gnulib. I've done quite a bit of porting, > but haven't used gnulib before. I've never seen a project that makes > its own versions of system headers like alloca.h, is this behavior > inherited from gnulib? Yes, I think so. gnulib is GNU's portability layer. It is the successor of the old libiberty. See http://gnu.org/software/gnulib (you need to wait until tomorrow due to the SOPA blackout, though). It is much newer than GnuPG and thus we don't make full use of it and possible have modified some files. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Wed Jan 18 16:33:30 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 18 Jan 2012 10:33:30 -0500 Subject: porting gnupg to Android, is pth required? In-Reply-To: References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> Message-ID: <4F16E64A.9040209@guardianproject.info> On 1/18/12 10:10 AM, Alphazo wrote: > On Wed, Jan 18, 2012 at 4:05 PM, Hans-Christoph Steiner wrote: >> On Jan 18, 2012, at 5:28 AM, Werner Koch wrote: >> >>> Hi, >>> >>> I have not seen your previous two mails (HTML parts?), but let me give >>> you a short comment anyway: >> Thanks for your reply. >> >>>>> On Fri, Jan 13, 2012, at 16:09, Hans-Christoph Steiner wrote: >>>>>> be a lot of work to get running on Android. gnupg's ./configure seems >>>>>> to say that Pth is now required. Is it possible to build gnupg without >>> Pth is for a looong time a requirement for GnuPG-2. However, there are >>> only a few users of Pth left and thus we plan to drop Pth support. >>> Instead, we will use a new library (nPth) which has a very similar >>> interface but internally uses the systems's standard trhead >>> implementaions. That is pthreads on most Unix systems and >>> WindowsThreads on Windows. This change will help us to solve conflicts >>> with other libraries used by GnuPG and Pth. >>> >>> There is a npth branch for GnupG which will soon be merged into master. >> Well, I got pth built so I think it'll work. For now I'll keep it, unless you think the Android port would be better without it. >> >> >>>>> Well, I've gotten pth built for Android and am now stuck on OpenLDAP. >>>>> Is that absolutely required? ;-) >>> No, OpenLDAP is only required for the dirmngr. However with 2.1 Dirmngr >>> is resonsible for all network access (keyservers etc.), thus eventually >>> you need to support it. ./configure --disable-dirmngr allows to build >>> without dirmngr. >> Ah, ok, --disable-ldap wasn't working for me. I suppose I needed also --disable-dirmngr. We want keyserver support for sure, and openldap is built for Android now. Does gnupg need any of the openldap client or server programs? I only installed the libraries. >> >> >>>> Ah... openldap is built and gnupg's ./configure is happy with it, but >>>> now I'm getting this very odd error triggered from gl/allocsa.c with >>>> both 2.1.0beta3 and the head of master: >>> I don't know. You may want to check whether gnulib has updates for this >>> code. >> Ah, ok so 'gl' stands for gnulib. I've done quite a bit of porting, but haven't used gnulib before. I've never seen a project that makes its own versions of system headers like alloca.h, is this behavior inherited from gnulib? >> >> >> .hc > How does this project compare to APG for Android? > > http://www.thialfihar.org/projects/apg/ > https://market.android.com/details?id=org.thialfihar.android.apg&hl=en > > Thanks > Alphazo APG is great, but it still needs much work. While we'd like to see a complete OpenPGP implementation in Java, our skills lie more in porting and user-facing development, so we're porting gnupg and wrapping it. Here are some key limitations of APG as it stands now: - no method for uploading personal public key - no method for signing other people's keys - no method to view signatures on a key You can follow our progress on our wiki, this is part of the PSST project: https://guardianproject.info/wiki/GnuPG_for_Android If you are interested in contributing, we are always looking for help. :-) .hc From hans at guardianproject.info Wed Jan 18 18:03:41 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 18 Jan 2012 12:03:41 -0500 Subject: porting gnupg to Android, is pth required? In-Reply-To: <87pqehknsb.fsf@vigenere.g10code.de> References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <87pqehknsb.fsf@vigenere.g10code.de> Message-ID: <4F16FB6D.2090208@guardianproject.info> On 01/18/2012 10:56 AM, Werner Koch wrote: > On Wed, 18 Jan 2012 16:05, hans at at.or.at said: > >> Well, I got pth built so I think it'll work. For now I'll keep it, unless you think the Android port would be better without it. > > We will switch with the next beta. Anyway using the new lib should be > easier than Pth. Keep it for now. > >> --disable-dirmngr. We want keyserver support for sure, and openldap >> is built for Android now. Does gnupg need any of the openldap client >> or server programs? I only installed the libraries. > > No, we only need the library. --disable-ldap should also work. It is a > still a development version and thus I don't care too much about these > little bugs. If you care, both --disable-ldap and "--disable-ldap --without-ldap" did not work for me on 2.1.0beta3 and head of master. I can file a bug report, if you are interested. >> Ah, ok so 'gl' stands for gnulib. I've done quite a bit of porting, >> but haven't used gnulib before. I've never seen a project that makes >> its own versions of system headers like alloca.h, is this behavior >> inherited from gnulib? > > Yes, I think so. gnulib is GNU's portability layer. It is the successor > of the old libiberty. See http://gnu.org/software/gnulib (you need to > wait until tomorrow due to the SOPA blackout, though). It is much newer > than GnuPG and thus we don't make full use of it and possible have > modified some files. Ok, I'll dive into gnulib today and report back with my progress. .hc From wk at gnupg.org Wed Jan 18 18:29:21 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 18 Jan 2012 18:29:21 +0100 Subject: porting gnupg to Android, is pth required? In-Reply-To: <4F16FB6D.2090208@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 18 Jan 2012 12:03:41 -0500") References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <87pqehknsb.fsf@vigenere.g10code.de> <4F16FB6D.2090208@guardianproject.info> Message-ID: <87wr8okjgu.fsf@vigenere.g10code.de> On Wed, 18 Jan 2012 18:03, hans at guardianproject.info said: > If you care, both --disable-ldap and "--disable-ldap --without-ldap" did > not work for me on 2.1.0beta3 and head of master. I can file a bug > report, if you are interested. Please don't. It is WiP and thus such bugs are expected and it does not make sense to solve them now. In fact the LDAP detection is worse than that of 1.4 - needs to be updated. > Ok, I'll dive into gnulib today and report back with my progress. git://git.savannah.gnu.org/gnulib.git which has not been blacked out. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Wed Jan 18 23:52:06 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 18 Jan 2012 17:52:06 -0500 Subject: porting gnupg to Android, is pth required? In-Reply-To: <87pqehknsb.fsf@vigenere.g10code.de> References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <87pqehknsb.fsf@vigenere.g10code.de> Message-ID: <4F174D16.8050100@guardianproject.info> On 01/18/2012 10:56 AM, Werner Koch wrote: > On Wed, 18 Jan 2012 16:05, hans at at.or.at said: > >> Well, I got pth built so I think it'll work. For now I'll keep it, unless you think the Android port would be better without it. > > We will switch with the next beta. Anyway using the new lib should be > easier than Pth. Keep it for now. > >> --disable-dirmngr. We want keyserver support for sure, and openldap >> is built for Android now. Does gnupg need any of the openldap client >> or server programs? I only installed the libraries. > > No, we only need the library. --disable-ldap should also work. It is a > still a development version and thus I don't care too much about these > little bugs. > >> Ah, ok so 'gl' stands for gnulib. I've done quite a bit of porting, >> but haven't used gnulib before. I've never seen a project that makes >> its own versions of system headers like alloca.h, is this behavior >> inherited from gnulib? > > Yes, I think so. gnulib is GNU's portability layer. It is the successor > of the old libiberty. See http://gnu.org/software/gnulib (you need to > wait until tomorrow due to the SOPA blackout, though). It is much newer > than GnuPG and thus we don't make full use of it and possible have > modified some files. Updating using the latest gnulib unfortunately just makes for new strange errors. Also the 'allocsa' module seem to have become the 'malloca' module, so that's what I used. Any idea how much work it is to remove gnulib? Here's the build log part with the errors: make[4]: Entering directory `/media/share/code/guardianproject/gnupg-for-android/external/gnupg/gl' /usr/local/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc --sysroot=/usr/local/android-ndk/platforms/android-9/arch-arm -DHAVE_CONFIG_H -I. -I.. -DANDROID -I/media/share/code/guardianproject/gnupg-for-android/external/include -O3 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith -MT malloca.o -MD -MP -MF .deps/malloca.Tpo -c -o malloca.o malloca.c In file included from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/sys/time.h:33, from ./sys/time.h:39, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:32, from ./time.h:40, from ./stdint.h:527, from /usr/local/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/sys/types.h:43, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/strings.h:42, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/stdlib.h:42, from ./stdlib.h:35, from malloca.h:24, from malloca.c:23: /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/linux/time.h:20: error: expected specifier-qualifier-list before 'time_t' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/linux/time.h:26: error: expected specifier-qualifier-list before 'time_t' In file included from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/asm/siginfo.h:15, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:35, from ./time.h:40, from ./stdint.h:527, from /usr/local/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/sys/types.h:43, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/strings.h:42, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/stdlib.h:42, from ./stdlib.h:35, from malloca.h:24, from malloca.c:23: /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/asm-generic/siginfo.h:51: error: expected specifier-qualifier-list before 'pid_t' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/asm-generic/siginfo.h:56: error: expected specifier-qualifier-list before 'timer_t' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/asm-generic/siginfo.h:64: error: expected specifier-qualifier-list before 'pid_t' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/asm-generic/siginfo.h:70: error: expected specifier-qualifier-list before 'pid_t' In file included from ./time.h:40, from ./stdint.h:527, from /usr/local/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/sys/types.h:43, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/strings.h:42, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/stdlib.h:42, from ./stdlib.h:35, from malloca.h:24, from malloca.c:23: /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:40: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'time' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:70: error: expected ')' before '__time1' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:71: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'mktime' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:73: error: expected ';', ',' or ')' before '*' token /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:74: error: expected ';', ',' or ')' before '*' token /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:76: error: expected ';', ',' or ')' before '*' token /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:77: error: expected ';', ',' or ')' before '*' token /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:82: error: expected ';', ',' or ')' before '*' token /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:83: error: expected ';', ',' or ')' before '*' token /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:94: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'clock' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:107: error: expected declaration specifiers or '...' before 'timer_t' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:109: error: expected ')' before 'timerid' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:110: error: expected ')' before 'timerid' /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/time.h:111: error: expected ')' before 'timerid' In file included from ./stdint.h:527, from /usr/local/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/include-fixed/sys/types.h:43, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/strings.h:42, from /usr/local/android-ndk/platforms/android-9/arch-arm/usr/include/stdlib.h:42, from ./stdlib.h:35, from malloca.h:24, from malloca.c:23: ./time.h:409: error: 'time_t' undeclared here (not in a function) ./time.h:409: error: bit-field '__floating_time_t_unsupported' width not an integer constant ./time.h:409: error: expected ',', ';' or '}' before numeric constant malloca.c: In function 'mmalloca': malloca.c:85: warning: cast increases required alignment of target type malloca.c:89: warning: cast increases required alignment of target type malloca.c: In function 'freea': malloca.c:129: warning: cast increases required alignment of target type malloca.c:133: warning: cast increases required alignment of target type make[4]: *** [malloca.o] Error 1 make[4]: Leaving directory `/media/share/code/guardianproject/gnupg-for-android/external/gnupg/gl' make[3]: *** [all-recursive] Error 1 From gniibe at fsij.org Thu Jan 19 06:59:49 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 19 Jan 2012 14:59:49 +0900 Subject: Smartcards and 1.4 In-Reply-To: <87k44qppr1.fsf@vigenere.g10code.de> References: <87k44qppr1.fsf@vigenere.g10code.de> Message-ID: <1326952789.1940.5.camel@latx1.gniibe.org> On 2012-01-17 at 11:50 +0100, Werner Koch wrote: > 1. Drop the smartcard stuff completely. > > 2. Feature freeze, keep the code as it is and don't update it from 2.0. > (I will do this for 1.4.12) > > 3. Keep the functionality but require the use of the gpg-agent. > (As of now gpg uses the gpg-agent if available but falls back to an > included copy of scdaemon code other wise). I think that option 2 is preferable, since it will cause less surprise. >From smart card users' point of view, there will be options: A. Switch to 2.0, entirely. B. Use new one of 1.4 series with gpg-agent of 2.0 C. Keep using old 1.4. Option 1 or 3 sounds like it encourages smartcard users to switch 2.0 series (fully or partially), but users have option C. Just an opinion, -- From wk at gnupg.org Thu Jan 19 11:33:19 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Jan 2012 11:33:19 +0100 Subject: QR code (was: porting gnupg to Android, is pth required?) In-Reply-To: <4F16E64A.9040209@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 18 Jan 2012 10:33:30 -0500") References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <4F16E64A.9040209@guardianproject.info> Message-ID: <87k44oj828.fsf_-_@vigenere.g10code.de> On Wed, 18 Jan 2012 16:33, hans at guardianproject.info said: > You can follow our progress on our wiki, this is part of the PSST project: > https://guardianproject.info/wiki/GnuPG_for_Android Interesting. I would appreciate if you use this list to discuss: - QR code display/scanning for keysigning exchanges - display randomart image of fingerprint for keysigning exchanges In particular a QR format is something we will use for STEED also. BTW, what about changing the goals a bit a aim for STEED. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jan 19 11:38:08 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Jan 2012 11:38:08 +0100 Subject: porting gnupg to Android, is pth required? In-Reply-To: <4F174D16.8050100@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 18 Jan 2012 17:52:06 -0500") References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <87pqehknsb.fsf@vigenere.g10code.de> <4F174D16.8050100@guardianproject.info> Message-ID: <87fwfcj7u7.fsf@vigenere.g10code.de> On Wed, 18 Jan 2012 23:52, hans at guardianproject.info said: > strange errors. Also the 'allocsa' module seem to have become the > 'malloca' module, so that's what I used. Any idea how much work it is > to remove gnulib? Gnulib is only used on non gnu platforms to support some important features not, or not well, defined by Posix. You problem here is about the libc, used by Android. I am pretty sure the gnulib folks are interested in helping out. Simon, do you think the problem is due to GnuPG's old style use of gnulib? Or is Android not yet supported? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jan 19 14:38:25 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Jan 2012 14:38:25 +0100 Subject: Smartcards and 1.4 In-Reply-To: <1326952789.1940.5.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Thu, 19 Jan 2012 14:59:49 +0900") References: <87k44qppr1.fsf@vigenere.g10code.de> <1326952789.1940.5.camel@latx1.gniibe.org> Message-ID: <87ipk7izhq.fsf@vigenere.g10code.de> On Thu, 19 Jan 2012 06:59, gniibe at fsij.org said: >> 2. Feature freeze, keep the code as it is and don't update it from 2.0. >> (I will do this for 1.4.12) > I think that option 2 is preferable, since it will cause less surprise. Meanwhile I also tend to this option. In addition we could print a note at the start of the card menu, that the use of 1.4 for smartcards is deprecated. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From simon at josefsson.org Thu Jan 19 15:41:01 2012 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 19 Jan 2012 15:41:01 +0100 Subject: porting gnupg to Android, is pth required? In-Reply-To: <87fwfcj7u7.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 19 Jan 2012 11:38:08 +0100") References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <87pqehknsb.fsf@vigenere.g10code.de> <4F174D16.8050100@guardianproject.info> <87fwfcj7u7.fsf@vigenere.g10code.de> Message-ID: <87y5t34uwy.fsf@latte.josefsson.org> Werner Koch writes: > On Wed, 18 Jan 2012 23:52, hans at guardianproject.info said: > >> strange errors. Also the 'allocsa' module seem to have become the >> 'malloca' module, so that's what I used. Any idea how much work it is >> to remove gnulib? > > Gnulib is only used on non gnu platforms to support some important > features not, or not well, defined by Posix. You problem here is about > the libc, used by Android. I am pretty sure the gnulib folks are > interested in helping out. > > Simon, do you think the problem is due to GnuPG's old style use of > gnulib? Or is Android not yet supported? The error messages suggests it is the former, you need to integrate gnulib in the documented way otherwise there will be many strange compiler errors. I don't recall any significant discussions involving Android as a porting target, but I think that is mostly because of lack of testers not that it is intentionally not supported. I could help with the gnulib infrastructure in GnuPG if you want, I think there is good opportunitity to reduce code duplication. The first thing to do for Android would be to build a gnulib mega tarball for the environment -- that way we'll identify any gnulib bugs immediately. Running the extensive set of self checks will also be quite interesting, implementing a POSIX system is not easy. Doing this would be quite interesting. Where do I find a android cross-compiler? /Simon From hans at guardianproject.info Thu Jan 19 16:14:33 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 19 Jan 2012 10:14:33 -0500 Subject: porting gnupg to Android, is pth required? In-Reply-To: <87y5t34uwy.fsf@latte.josefsson.org> References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <87pqehknsb.fsf@vigenere.g10code.de> <4F174D16.8050100@guardianproject.info> <87fwfcj7u7.fsf@vigenere.g10code.de> <87y5t34uwy.fsf@latte.josefsson.org> Message-ID: <14D62F52-5D16-40C0-8FA8-8C0AA65CA893@guardianproject.info> On Jan 19, 2012, at 9:41 AM, Simon Josefsson wrote: > Werner Koch writes: > >> On Wed, 18 Jan 2012 23:52, hans at guardianproject.info said: >> >>> strange errors. Also the 'allocsa' module seem to have become the >>> 'malloca' module, so that's what I used. Any idea how much work it is >>> to remove gnulib? >> >> Gnulib is only used on non gnu platforms to support some important >> features not, or not well, defined by Posix. You problem here is about >> the libc, used by Android. I am pretty sure the gnulib folks are >> interested in helping out. >> >> Simon, do you think the problem is due to GnuPG's old style use of >> gnulib? Or is Android not yet supported? > > The error messages suggests it is the former, you need to integrate > gnulib in the documented way otherwise there will be many strange > compiler errors. I don't recall any significant discussions involving > Android as a porting target, but I think that is mostly because of lack > of testers not that it is intentionally not supported. > > I could help with the gnulib infrastructure in GnuPG if you want, I > think there is good opportunitity to reduce code duplication. > > The first thing to do for Android would be to build a gnulib mega > tarball for the environment -- that way we'll identify any gnulib bugs > immediately. Running the extensive set of self checks will also be > quite interesting, implementing a POSIX system is not easy. Doing this > would be quite interesting. Where do I find a android cross-compiler? Excellent, thanks for stepping up on this! Here's the Android cross-compiler, its a big tarball of a custom gcc build, some libs, and some utilities: http://developer.android.com/sdk/ndk/index.html I work on Debian, Ubuntu, and Mac OS X. I have taken to untarring the above in /usr/local, then making a /usr/local/android-ndk symlink to the versioned directory. I also attached my bash settings to set the path and some env vars for the Makefiles. I don't think you'll need to download the Android SDK stuff at all. -------------- next part -------------- A non-text attachment was scrubbed... Name: bashrc Type: application/octet-stream Size: 409 bytes Desc: not available URL: -------------- next part -------------- ---------------------------------------------------------------------------- Access to computers should be unlimited and total. - the hacker ethic From simon at josefsson.org Thu Jan 19 16:20:21 2012 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 19 Jan 2012 16:20:21 +0100 Subject: porting gnupg to Android, is pth required? In-Reply-To: <14D62F52-5D16-40C0-8FA8-8C0AA65CA893@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 19 Jan 2012 10:14:33 -0500") References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <87pqehknsb.fsf@vigenere.g10code.de> <4F174D16.8050100@guardianproject.info> <87fwfcj7u7.fsf@vigenere.g10code.de> <87y5t34uwy.fsf@latte.josefsson.org> <14D62F52-5D16-40C0-8FA8-8C0AA65CA893@guardianproject.info> Message-ID: <87hazr4t3e.fsf@latte.josefsson.org> Hans-Christoph Steiner writes: > Excellent, thanks for stepping up on this! Here's the Android > cross-compiler, its a big tarball of a custom gcc build, some libs, > and some utilities: > > http://developer.android.com/sdk/ndk/index.html > > I work on Debian, Ubuntu, and Mac OS X. I have taken to untarring the > above in /usr/local, then making a /usr/local/android-ndk symlink to > the versioned directory. I also attached my bash settings to set the > path and some env vars for the Makefiles. I don't think you'll need > to download the Android SDK stuff at all. Thank you for pointers! I'll start by trying to make gnulib buildable in this environment... (although not until tomorrow) /Simon From hans at guardianproject.info Thu Jan 19 18:35:08 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 19 Jan 2012 12:35:08 -0500 Subject: porting gnupg to Android, is pth required? In-Reply-To: <87hazr4t3e.fsf@latte.josefsson.org> References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <87pqehknsb.fsf@vigenere.g10code.de> <4F174D16.8050100@guardianproject.info> <87fwfcj7u7.fsf@vigenere.g10code.de> <87y5t34uwy.fsf@latte.josefsson.org> <14D62F52-5D16-40C0-8FA8-8C0AA65CA893@guardianproject.info> <87hazr4t3e.fsf@latte.josefsson.org> Message-ID: On Jan 19, 2012, at 10:20 AM, Simon Josefsson wrote: > Hans-Christoph Steiner writes: > >> Excellent, thanks for stepping up on this! Here's the Android >> cross-compiler, its a big tarball of a custom gcc build, some libs, >> and some utilities: >> >> http://developer.android.com/sdk/ndk/index.html >> >> I work on Debian, Ubuntu, and Mac OS X. I have taken to untarring the >> above in /usr/local, then making a /usr/local/android-ndk symlink to >> the versioned directory. I also attached my bash settings to set the >> path and some env vars for the Makefiles. I don't think you'll need >> to download the Android SDK stuff at all. > > Thank you for pointers! I'll start by trying to make gnulib buildable > in this environment... (although not until tomorrow) > > /Simon Excellent! This is a high priority for us, so please don't hesitate to contact me with Android porting questions. It can be via this list, direct email, or IRC. I'm _hc on freenode and oftc.net. I'm generally in #guardianproject on freenode or #debian-nyc on oftc. .hc ---------------------------------------------------------------------------- ?El pueblo unido jam?s ser? vencido! From wk at gnupg.org Thu Jan 19 19:02:05 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 19 Jan 2012 19:02:05 +0100 Subject: porting gnupg to Android, is pth required? In-Reply-To: <87y5t34uwy.fsf@latte.josefsson.org> (Simon Josefsson's message of "Thu, 19 Jan 2012 15:41:01 +0100") References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <87pqehknsb.fsf@vigenere.g10code.de> <4F174D16.8050100@guardianproject.info> <87fwfcj7u7.fsf@vigenere.g10code.de> <87y5t34uwy.fsf@latte.josefsson.org> Message-ID: <87aa5jinaa.fsf@vigenere.g10code.de> On Thu, 19 Jan 2012 15:41, simon at josefsson.org said: > The error messages suggests it is the former, you need to integrate > gnulib in the documented way otherwise there will be many strange > compiler errors. I don't recall any significant discussions involving Well, the included gnulib stuff is pretty old and has been modified. For example to support Windows CE. The only really requirement we had was support for setenv. That pulled in a lot of other stuff. The problem with gnulib is, it defines a complete new build environment which often does not work well with existing code. GnuPG has its own OS abstraction layer and thus the use of gnulib is not easy. gnulib is designed as an extension to Posix to lift it up to a glibc feature level. GnuPG is not designed to build against glibc but towards Posix 2001 and W32. Other related applications (e.g. GPA) build against glib - which is again a different environment. My conclusion is that we can't switch to gnulib nor to glib without breaking a lot of code. Fixing the few problems with the Android libc should be easy compared to the changes required to support W32CE or VMS. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Thu Jan 19 19:25:40 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 19 Jan 2012 13:25:40 -0500 Subject: QR code (was: porting gnupg to Android, is pth required?) In-Reply-To: <87k44oj828.fsf_-_@vigenere.g10code.de> References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <4F16E64A.9040209@guardianproject.info> <87k44oj828.fsf_-_@vigenere.g10code.de> Message-ID: On Jan 19, 2012, at 5:33 AM, Werner Koch wrote: > On Wed, 18 Jan 2012 16:33, hans at guardianproject.info said: > >> You can follow our progress on our wiki, this is part of the PSST project: >> https://guardianproject.info/wiki/GnuPG_for_Android > > Interesting. I would appreciate if you use this list to discuss: > > - QR code display/scanning for keysigning exchanges > - display randomart image of fingerprint for keysigning exchanges > > In particular a QR format is something we will use for STEED also. BTW, > what about changing the goals a bit a aim for STEED. I'm just catching up on the STEED project, I have only skimmed your info so far, but I'll read the paper on the train home today. The goals sound great. We (the Guardian Project) are also working on projects focused on making encryption usable, mostly on mobile platforms, and really mostly on Android since it is far and away the quickest and easiest platform for us to develop on. About QR code display and scanning, that is deployed in our Gibberbot Instant Messaging app with OTR support. It is used to validate the fingerprints of the OTR private keys. The best way to try it is either install it on an Android device, or if you don't have access to one, install the Android SDK and run it on the emulator. About randomart display of fingerprints, we really like the idea as it is implemented in OpenSSH. Most people will find it much easier to compare little pictures rather than hex strings. Indeed many people will be quite intimidated by the site of a long hex string in their app. So the idea is to incorporate the randomart image into the fingerprint validation process. We are currently planning on implementing this in our Android app based on the ongoing port of gnupg to Android. .hc ---------------------------------------------------------------------------- kill your television From dkg at fifthhorseman.net Thu Jan 19 19:44:06 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 19 Jan 2012 13:44:06 -0500 Subject: randomart is troubling [was: Re: QR code] In-Reply-To: References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <4F16E64A.9040209@guardianproject.info> <87k44oj828.fsf_-_@vigenere.g10code.de> Message-ID: <4F186476.6000507@fifthhorseman.net> On 01/19/2012 01:25 PM, Hans-Christoph Steiner wrote: > About randomart display of fingerprints, we really like the idea as it is implemented in OpenSSH. > Most people will find it much easier to compare little pictures rather than hex strings. > Indeed many people will be quite intimidated by the site of a long hex string in their app. > So the idea is to incorporate the randomart image into the fingerprint validation process. I'm unconvinced by these arguments. people might feel more comfortable "comparing pictures" than "comparing hex strings", but that doesn't say anything about the actual collision-resistance of the pictures (especially in the context of the heuristic- and idiosyncrasy-ridden human visual apparatus). Most people would also feel more comfortable comparing shorter strings that were pronouncable (e.g. it says "cat dog zebra" -- does yours say "cat dog zebra"?); but we don't do that because those shorter strings don't have enough entropy to be collision-resistant in the way that we need fingerprints to be. Can you point me to studies that show actual resistance to malicious attack against "randomart" approaches? Mingerprints themselves are subject to attacks against common human mental idiosyncrasies: http://www.thc.org/papers/ffp.html my instincts suggest that visual image comparison is at least as "fuzzy" (probably moreso) than string comparison, even if people find it more comfortable. We don't do anyone a good service by introducing insecure steps in a critical stage of the verification process. It would be better to just get the human out of the loop entirely if the opaque data is beyond human capacity to deal with (which is the idea behind the QR code stuff, aiui. Are there good arguments for randomart? I'd like to hear them if there are. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From hans at guardianproject.info Thu Jan 19 20:23:43 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 19 Jan 2012 14:23:43 -0500 Subject: randomart is troubling [was: Re: QR code] In-Reply-To: <4F186476.6000507@fifthhorseman.net> References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <4F16E64A.9040209@guardianproject.info> <87k44oj828.fsf_-_@vigenere.g10code.de> <4F186476.6000507@fifthhorseman.net> Message-ID: <55DE6AD7-76E7-4883-9B20-A56747A8BE60@guardianproject.info> On Jan 19, 2012, at 1:44 PM, Daniel Kahn Gillmor wrote: > On 01/19/2012 01:25 PM, Hans-Christoph Steiner wrote: >> About randomart display of fingerprints, we really like the idea as it is implemented in OpenSSH. >> Most people will find it much easier to compare little pictures rather > than hex strings. >> Indeed many people will be quite intimidated by the site of a long hex > string in their app. >> So the idea is to incorporate the randomart image into the fingerprint > validation process. > > I'm unconvinced by these arguments. people might feel more comfortable > "comparing pictures" than "comparing hex strings", but that doesn't say > anything about the actual collision-resistance of the pictures > (especially in the context of the heuristic- and idiosyncrasy-ridden > human visual apparatus). > > Most people would also feel more comfortable comparing shorter strings > that were pronouncable (e.g. it says "cat dog zebra" -- does yours say > "cat dog zebra"?); but we don't do that because those shorter strings > don't have enough entropy to be collision-resistant in the way that we > need fingerprints to be. > > Can you point me to studies that show actual resistance to malicious > attack against "randomart" approaches? Mingerprints themselves are > subject to attacks against common human mental idiosyncrasies: > > http://www.thc.org/papers/ffp.html > > my instincts suggest that visual image comparison is at least as "fuzzy" > (probably moreso) than string comparison, even if people find it more > comfortable. > > We don't do anyone a good service by introducing insecure steps in a > critical stage of the verification process. > > It would be better to just get the human out of the loop entirely if the > opaque data is beyond human capacity to deal with (which is the idea > behind the QR code stuff, aiui. > > Are there good arguments for randomart? I'd like to hear them if there are. I think you are misunderstanding two key points: - we are not claiming randomart is tried and true - we are not replacing standard manual fingerprint verification The key idea here is that we are adding another view on the same data. The standard manual fingerprint verification procedure is easy to mess up. If a fingerprint is off by one digit, how many users to do you think will catch that error? How about off by a few? Do you have data that more people will feel comfortable comparing a string of random words rather than any other technique? How about error rates of experts doing standard manual fingerprint verification, or anyone using any other technique? The point here is that I do not think there is much of this data anywhere, so we are all left to intuition and educated guesses. If you do have this data, please share :) Getting these techniques into easily useable forms will lead to this data being generated. Our current idea is something like this: - the software is geared towards smartphones with cameras - the fingerprint verification screen shows the standard hex fingerprint, the QR Code version, and the randomart image - users scan each other's QR code to get the fingerprint - they will then validate each others' fingerprints by looking at the QR code, the hex string and the randomart image We could also throw in the random words technique you mentioned above, can you recommend a library? .hc ---------------------------------------------------------------------------- "[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr. From hans at guardianproject.info Thu Jan 19 20:24:14 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 19 Jan 2012 14:24:14 -0500 Subject: QR code (was: porting gnupg to Android, is pth required?) In-Reply-To: <87fwfbo6x1.fsf@servo.finestructure.net> References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <4F16E64A.9040209@guardianproject.info> <87k44oj828.fsf_-_@vigenere.g10code.de> <87fwfbo6x1.fsf@servo.finestructure.net> Message-ID: <9A0C2088-1A92-4100-B095-0E939A22AEA8@guardianproject.info> On Jan 19, 2012, at 1:59 PM, Jameson Graef Rollins wrote: > On Thu, 19 Jan 2012 11:33:19 +0100, Werner Koch wrote: >> - display randomart image of fingerprint for keysigning exchanges > > Introducing raondomart fingerprint images was one of the worst mistakes > OpenSSH ever made. Care to back up that statement? .hc ---------------------------------------------------------------------------- As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin From jrollins at finestructure.net Thu Jan 19 19:59:06 2012 From: jrollins at finestructure.net (Jameson Graef Rollins) Date: Thu, 19 Jan 2012 10:59:06 -0800 Subject: QR code (was: porting gnupg to Android, is pth required?) In-Reply-To: <87k44oj828.fsf_-_@vigenere.g10code.de> References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <4F16E64A.9040209@guardianproject.info> <87k44oj828.fsf_-_@vigenere.g10code.de> Message-ID: <87fwfbo6x1.fsf@servo.finestructure.net> On Thu, 19 Jan 2012 11:33:19 +0100, Werner Koch wrote: > - display randomart image of fingerprint for keysigning exchanges Introducing raondomart fingerprint images was one of the worst mistakes OpenSSH ever made. jamie. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Jan 19 21:56:47 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 19 Jan 2012 15:56:47 -0500 Subject: randomart is troubling [was: Re: QR code] In-Reply-To: <55DE6AD7-76E7-4883-9B20-A56747A8BE60@guardianproject.info> References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <4F16E64A.9040209@guardianproject.info> <87k44oj828.fsf_-_@vigenere.g10code.de> <4F186476.6000507@fifthhorseman.net> <55DE6AD7-76E7-4883-9B20-A56747A8BE60@guardianproject.info> Message-ID: <4F18838F.9060607@fifthhorseman.net> On 01/19/2012 02:23 PM, Hans-Christoph Steiner wrote: > - we are not claiming randomart is tried and true > - we are not replacing standard manual fingerprint verification thanks, i'm glad to hear this. > The standard manual fingerprint verification procedure is easy to mess up. If a fingerprint is off by one digit, how many users to do you think will catch that error? How about off by a few? Sure, agreed! See the link i posted about fuzzy fingerprint attacks. humans suck at this kind of thing in general, which is why wordfinds and "find the difference" puzzles are considered challenging. > Our current idea is something like this: > > - the software is geared towards smartphones with cameras > - the fingerprint verification screen shows the standard hex fingerprint, the QR Code version, and the randomart image > - users scan each other's QR code to get the fingerprint > - they will then validate each others' fingerprints by looking at the QR code, the hex string and the randomart image if your goal is just experimentation, this seems like a fine approach. in practice, though, i suspect regular humans will either be so overwhelmed by the range of choices that they'll just click "OK", or they'll decide to focus specifically on the one that seems simplest/easiest for them. I wouldn't be surprised if that turned out to also be the one that offers the least collision resistance, unfortunately. If we want something to be secure for regular users, it should offer them one simple and secure method, preferably not involving anything like a "find the difference" puzzle (and yes, i'm including hex-string matching in that set). That's the advantage of the QR approach -- direct machine-to-machine comparison with any (sighted) human being able to tell if there's an MITM going on. > We could also throw in the random words technique you mentioned above, can you recommend a library? you might have noticed that i *wasn't* recommending short strings of random words. if you're interested in longer strings, there are several existing implementations of that idea, including: http://search.cpan.org/dist/Digest-BubbleBabble/ http://world.std.com/~reinhold/diceware.html i don't think either of these supports a C shared library, though. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Thu Jan 19 22:08:10 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 19 Jan 2012 16:08:10 -0500 Subject: randomart is troubling [was: Re: QR code] In-Reply-To: <4F18838F.9060607@fifthhorseman.net> References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <4F16E64A.9040209@guardianproject.info> <87k44oj828.fsf_-_@vigenere.g10code.de> <4F186476.6000507@fifthhorseman.net> <55DE6AD7-76E7-4883-9B20-A56747A8BE60@guardianproject.info> <4F18838F.9060607@fifthhorseman.net> Message-ID: <4F18863A.4050304@sixdemonbag.org> On 1/19/12 3:56 PM, Daniel Kahn Gillmor wrote: > you might have noticed that i *wasn't* recommending short strings of > random words. if you're interested in longer strings, there are > several existing implementations of that idea, including: There are an unpleasant lot of edge cases with this, starting with homonyms: if the word is "lead", how should it be pronounced? Ditto with synonyms: if "great" and "grate" are both in your dictionary, you have problems. PGP Corporation tried to solve this by hiring a linguist to compile a list of 512 short phonologically-distinct words. For each byte of the SHA-1 fingerprint it chose one of 256 words, representing each distinct value. Further, there were two sets to choose from: even-numbered bytes took their word from one set, odd-numbered bytes took their word from the other. It was an interesting experiment, but as far as I know only PGP has ever implemented it. It never gained traction in the larger PGP community. From dshaw at jabberwocky.com Fri Jan 20 00:42:32 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 19 Jan 2012 18:42:32 -0500 Subject: Smartcards and 1.4 In-Reply-To: <87k44qppr1.fsf@vigenere.g10code.de> References: <87k44qppr1.fsf@vigenere.g10code.de> Message-ID: <40133D2B-2957-402D-BC37-ECF3D63F521A@jabberwocky.com> On Jan 17, 2012, at 5:50 AM, Werner Koch wrote: > Hi, > > GnuPG 1.4 uses the smartcard code from 2.0. This is made possible by > using some glue code and copies of the required source files. The > problem with this approach is that testing the smartcard functions is > very time consuming. Thus I consider a change for post 1.4.12: > > Either: > > 1. Drop the smartcard stuff completely. > > 2. Feature freeze, keep the code as it is and don't update it from 2.0. > (I will do this for 1.4.12) > > 3. Keep the functionality but require the use of the gpg-agent. > (As of now gpg uses the gpg-agent if available but falls back to an > included copy of scdaemon code other wise). > > Comments? I still use 1.4.x heavily (baked into various things), and smartcard support is important to me, so I'm obviously against #1. As I see it, #2 and #3 both still allow using smartcards with 1.4.x. #2 will keep working for a while, but eventually the built-in code will be old enough to cause a problem, after which the agent will be the only way to do it? Do I understand you correctly? David From John at enigmail.net Fri Jan 20 01:54:37 2012 From: John at enigmail.net (John Clizbe) Date: Thu, 19 Jan 2012 18:54:37 -0600 Subject: Smartcards and 1.4 In-Reply-To: <40133D2B-2957-402D-BC37-ECF3D63F521A@jabberwocky.com> References: <87k44qppr1.fsf@vigenere.g10code.de> <40133D2B-2957-402D-BC37-ECF3D63F521A@jabberwocky.com> Message-ID: <4F18BB4D.3090807@enigmail.net> David Shaw wrote: > On Jan 17, 2012, at 5:50 AM, Werner Koch wrote: > >> Hi, >> >> GnuPG 1.4 uses the smartcard code from 2.0. This is made possible by >> using some glue code and copies of the required source files. The >> problem with this approach is that testing the smartcard functions is >> very time consuming. Thus I consider a change for post 1.4.12: >> >> Either: >> >> 1. Drop the smartcard stuff completely. >> >> 2. Feature freeze, keep the code as it is and don't update it from 2.0. >> (I will do this for 1.4.12) >> >> 3. Keep the functionality but require the use of the gpg-agent. >> (As of now gpg uses the gpg-agent if available but falls back to an >> included copy of scdaemon code other wise). >> >> Comments? > > I still use 1.4.x heavily (baked into various things), and smartcard support is important to me, so I'm obviously against #1. > > As I see it, #2 and #3 both still allow using smartcards with 1.4.x. #2 will keep working for a while, but eventually the built-in code will be old enough to cause a problem, after which the agent will be the only way to do it? Do I understand you correctly? > > David Like David, I have 1.4 wired into a fair amount of scripts and they often need to access a smart card. One additional question, would the addition of gpg-agent support into the Windows 1.4.x allow the simultaneous use of more than one reader? Currently in 1.4.11, --card-status will see both readers, but only return resilts for Reader #0. It's not a show stopper for me, but it would be nice to know. -John -- John P. Clizbe Inet: John ( a ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" From simon at josefsson.org Fri Jan 20 10:16:41 2012 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 20 Jan 2012 10:16:41 +0100 Subject: porting gnupg to Android, is pth required? In-Reply-To: (Hans-Christoph Steiner's message of "Thu, 19 Jan 2012 12:35:08 -0500") References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <87pqehknsb.fsf@vigenere.g10code.de> <4F174D16.8050100@guardianproject.info> <87fwfcj7u7.fsf@vigenere.g10code.de> <87y5t34uwy.fsf@latte.josefsson.org> <14D62F52-5D16-40C0-8FA8-8C0AA65CA893@guardianproject.info> <87hazr4t3e.fsf@latte.josefsson.org> Message-ID: <87vco63f9i.fsf@latte.josefsson.org> Hans-Christoph Steiner writes: > On Jan 19, 2012, at 10:20 AM, Simon Josefsson wrote: > >> Hans-Christoph Steiner writes: >> >>> Excellent, thanks for stepping up on this! Here's the Android >>> cross-compiler, its a big tarball of a custom gcc build, some libs, >>> and some utilities: >>> >>> http://developer.android.com/sdk/ndk/index.html >>> >>> I work on Debian, Ubuntu, and Mac OS X. I have taken to untarring the >>> above in /usr/local, then making a /usr/local/android-ndk symlink to >>> the versioned directory. I also attached my bash settings to set the >>> path and some env vars for the Makefiles. I don't think you'll need >>> to download the Android SDK stuff at all. >> >> Thank you for pointers! I'll start by trying to make gnulib buildable >> in this environment... (although not until tomorrow) >> >> /Simon > > Excellent! This is a high priority for us, so please don't hesitate > to contact me with Android porting questions. It can be via this > list, direct email, or IRC. I'm _hc on freenode and oftc.net. I'm > generally in #guardianproject on freenode or #debian-nyc on oftc. I'm now up and running with the NDK, and actually got the same error as you did when I tried to build a small gnulib based dummy project. So it is certainly an incompatibility between Android and gnulib somewhere. Now, let's see if I can fix it... I'll probably continue this thread on bug-gnulib at gnu.org instead since it is not (yet) to do anything with GnuPG, just gnulib. /Simon From martin at martinpaljak.net Fri Jan 20 11:21:06 2012 From: martin at martinpaljak.net (Martin Paljak) Date: Fri, 20 Jan 2012 12:21:06 +0200 Subject: Smartcards and 1.4 In-Reply-To: <4F18BB4D.3090807@enigmail.net> References: <87k44qppr1.fsf@vigenere.g10code.de> <40133D2B-2957-402D-BC37-ECF3D63F521A@jabberwocky.com> <4F18BB4D.3090807@enigmail.net> Message-ID: On Fri, Jan 20, 2012 at 02:54, John Clizbe wrote: > Currently in 1.4.11, --card-status will see both readers, but only return > resilts for Reader #0. Doesn't --reader-port fix this? I also use 1.4 for smart cards, as 2.0.X does not seem to work for decryption. Martin From wk at gnupg.org Fri Jan 20 12:03:47 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Jan 2012 12:03:47 +0100 Subject: Smartcards and 1.4 In-Reply-To: <40133D2B-2957-402D-BC37-ECF3D63F521A@jabberwocky.com> (David Shaw's message of "Thu, 19 Jan 2012 18:42:32 -0500") References: <87k44qppr1.fsf@vigenere.g10code.de> <40133D2B-2957-402D-BC37-ECF3D63F521A@jabberwocky.com> Message-ID: <87wr8mfxf0.fsf@vigenere.g10code.de> On Fri, 20 Jan 2012 00:42, dshaw at jabberwocky.com said: > As I see it, #2 and #3 both still allow using smartcards with 1.4.x. > #2 will keep working for a while, but eventually the built-in code > will be old enough to cause a problem, after which the agent will be > the only way to do it? Do I understand you correctly? Yes. The problem is that writing the code in 2.x in a way that it can also be used in 1.4 will get more and more troublesome. One drawback with the agent is that it is currently not possible to pass the PIN on the command line as it can be done with 1.4. However, in 2.1 we have code the loopback pinentry feature which would then allow that. That will also make gpg-agent mostly invisible. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jan 20 12:26:00 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Jan 2012 12:26:00 +0100 Subject: Smartcards and 1.4 In-Reply-To: <4F18BB4D.3090807@enigmail.net> (John Clizbe's message of "Thu, 19 Jan 2012 18:54:37 -0600") References: <87k44qppr1.fsf@vigenere.g10code.de> <40133D2B-2957-402D-BC37-ECF3D63F521A@jabberwocky.com> <4F18BB4D.3090807@enigmail.net> Message-ID: <87fwfafwdz.fsf@vigenere.g10code.de> On Fri, 20 Jan 2012 01:54, John at enigmail.net said: > One additional question, would the addition of gpg-agent support into the > Windows 1.4.x allow the simultaneous use of more than one reader? Definitely not. Smartcards almost always require user interaction and thus I wonder why you use 1.4 on Windows. For a long time it has now been replaced by 2.0. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jan 20 12:28:21 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Jan 2012 12:28:21 +0100 Subject: Smartcards and 1.4 In-Reply-To: (Martin Paljak's message of "Fri, 20 Jan 2012 12:21:06 +0200") References: <87k44qppr1.fsf@vigenere.g10code.de> <40133D2B-2957-402D-BC37-ECF3D63F521A@jabberwocky.com> <4F18BB4D.3090807@enigmail.net> Message-ID: <87bopyfwa2.fsf@vigenere.g10code.de> On Fri, 20 Jan 2012 11:21, martin at martinpaljak.net said: > Doesn't --reader-port fix this? Yes. Either use reader-port in scdaemon.conf or in gpg - depends on which backend is used. > I also use 1.4 for smart cards, as 2.0.X does not seem to work for decryption. Huh? Can you please explain the problem? I used 2.0 exclusivly for many years (now at 2.1 of course). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jan 20 12:34:58 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Jan 2012 12:34:58 +0100 Subject: randomart is troubling In-Reply-To: <4F18863A.4050304@sixdemonbag.org> (Robert J. Hansen's message of "Thu, 19 Jan 2012 16:08:10 -0500") References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <4F16E64A.9040209@guardianproject.info> <87k44oj828.fsf_-_@vigenere.g10code.de> <4F186476.6000507@fifthhorseman.net> <55DE6AD7-76E7-4883-9B20-A56747A8BE60@guardianproject.info> <4F18838F.9060607@fifthhorseman.net> <4F18863A.4050304@sixdemonbag.org> Message-ID: <877h0mfvz1.fsf@vigenere.g10code.de> On Thu, 19 Jan 2012 22:08, rjh at sixdemonbag.org said: > It was an interesting experiment, but as far as I know only PGP has ever > implemented it. It never gained traction in the larger PGP community. One important reason is, it does not work across different language and cultures. Even somewhat related languages like German and English would need different dictionaries to make it really usable. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From martin at martinpaljak.net Fri Jan 20 13:29:40 2012 From: martin at martinpaljak.net (Martin Paljak) Date: Fri, 20 Jan 2012 14:29:40 +0200 Subject: Smartcards and 1.4 In-Reply-To: <87bopyfwa2.fsf@vigenere.g10code.de> References: <87k44qppr1.fsf@vigenere.g10code.de> <40133D2B-2957-402D-BC37-ECF3D63F521A@jabberwocky.com> <4F18BB4D.3090807@enigmail.net> <87bopyfwa2.fsf@vigenere.g10code.de> Message-ID: On Fri, Jan 20, 2012 at 13:28, Werner Koch wrote: > On Fri, 20 Jan 2012 11:21, martin at martinpaljak.net said: > >> I also use 1.4 for smart cards, as 2.0.X does not seem to work for decryption. > > Huh? Can you please explain the problem? ?I used 2.0 exclusivly for many > years (now at 2.1 of course). Decryption with 4K keys works with 1.4 but not with 2.X (last time I checked) Martin From hans at guardianproject.info Fri Jan 20 15:25:31 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 20 Jan 2012 09:25:31 -0500 Subject: porting gnupg to Android, is pth required? In-Reply-To: <87vco63f9i.fsf@latte.josefsson.org> References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <87pqehknsb.fsf@vigenere.g10code.de> <4F174D16.8050100@guardianproject.info> <87fwfcj7u7.fsf@vigenere.g10code.de> <87y5t34uwy.fsf@latte.josefsson.org> <14D62F52-5D16-40C0-8FA8-8C0AA65CA893@guardianproject.info> <87hazr4t3e.fsf@latte.josefsson.org> <87vco63f9i.fsf@latte.josefsson.org> Message-ID: <942FDD59-54B8-4B99-9116-583E29A70987@guardianproject.info> On Jan 20, 2012, at 4:16 AM, Simon Josefsson wrote: > Hans-Christoph Steiner writes: > >> On Jan 19, 2012, at 10:20 AM, Simon Josefsson wrote: >> >>> Hans-Christoph Steiner writes: >>> >>>> Excellent, thanks for stepping up on this! Here's the Android >>>> cross-compiler, its a big tarball of a custom gcc build, some libs, >>>> and some utilities: >>>> >>>> http://developer.android.com/sdk/ndk/index.html >>>> >>>> I work on Debian, Ubuntu, and Mac OS X. I have taken to untarring the >>>> above in /usr/local, then making a /usr/local/android-ndk symlink to >>>> the versioned directory. I also attached my bash settings to set the >>>> path and some env vars for the Makefiles. I don't think you'll need >>>> to download the Android SDK stuff at all. >>> >>> Thank you for pointers! I'll start by trying to make gnulib buildable >>> in this environment... (although not until tomorrow) >>> >>> /Simon >> >> Excellent! This is a high priority for us, so please don't hesitate >> to contact me with Android porting questions. It can be via this >> list, direct email, or IRC. I'm _hc on freenode and oftc.net. I'm >> generally in #guardianproject on freenode or #debian-nyc on oftc. > > I'm now up and running with the NDK, and actually got the same error as > you did when I tried to build a small gnulib based dummy project. So it > is certainly an incompatibility between Android and gnulib somewhere. > Now, let's see if I can fix it... I'll probably continue this thread on > bug-gnulib at gnu.org instead since it is not (yet) to do anything with > GnuPG, just gnulib. > > /Simon Excellent, thanks. Feel free to CC me on threads there if you want my input. I've done a fair amount of Android porting at this point. .hc ---------------------------------------------------------------------------- News is what people want to keep hidden and everything else is publicity. - Bill Moyers From simon at josefsson.org Fri Jan 20 15:54:26 2012 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 20 Jan 2012 15:54:26 +0100 Subject: porting gnupg to Android, is pth required? In-Reply-To: <942FDD59-54B8-4B99-9116-583E29A70987@guardianproject.info> (Hans-Christoph Steiner's message of "Fri, 20 Jan 2012 09:25:31 -0500") References: <1326488985.12276.140661023134225@webmail.messagingengine.com> <1326505894.10230.140661023201905@webmail.messagingengine.com> <1326840266.20291.17.camel@palatschinken.at.or.at> <8739bdnw2q.fsf@vigenere.g10code.de> <1BC209C8-B370-4754-A6B2-DBDACE473465@at.or.at> <87pqehknsb.fsf@vigenere.g10code.de> <4F174D16.8050100@guardianproject.info> <87fwfcj7u7.fsf@vigenere.g10code.de> <87y5t34uwy.fsf@latte.josefsson.org> <14D62F52-5D16-40C0-8FA8-8C0AA65CA893@guardianproject.info> <87hazr4t3e.fsf@latte.josefsson.org> <87vco63f9i.fsf@latte.josefsson.org> <942FDD59-54B8-4B99-9116-583E29A70987@guardianproject.info> Message-ID: <877h0mzaot.fsf@latte.josefsson.org> Hans-Christoph Steiner writes: > Excellent, thanks. Feel free to CC me on threads there if you want my > input. I've done a fair amount of Android porting at this point. I've posted my first analysis: https://lists.gnu.org/archive/html/bug-gnulib/2012-01/msg00277.html The problem seems to be an incompatibility between Android system headers and some replacement headers from gnulib. It would be easy to work around this by editing the system header file, but that is probably not possible. If you have any thoughts on solution, please chime in on that thread. /Simon From wk at gnupg.org Fri Jan 20 18:23:51 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 20 Jan 2012 18:23:51 +0100 Subject: Smartcards and 1.4 In-Reply-To: (Martin Paljak's message of "Fri, 20 Jan 2012 14:29:40 +0200") References: <87k44qppr1.fsf@vigenere.g10code.de> <40133D2B-2957-402D-BC37-ECF3D63F521A@jabberwocky.com> <4F18BB4D.3090807@enigmail.net> <87bopyfwa2.fsf@vigenere.g10code.de> Message-ID: <87r4yue194.fsf@vigenere.g10code.de> On Fri, 20 Jan 2012 13:29, martin at martinpaljak.net said: > Decryption with 4K keys works with 1.4 but not with 2.X (last time I checked) That works only if you use the internal gpg 1.4 code, but it is a side effect of not using our IPC mechanism. 4k keys work in 2.0.18 - despite that the back matter of card tells you it supports only 3k ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From g.esp at free.fr Sat Jan 21 23:41:51 2012 From: g.esp at free.fr (Gilles Espinasse) Date: Sat, 21 Jan 2012 23:41:51 +0100 Subject: [PATCH] Fix clock_gettime detection Message-ID: <1327185711-14947-1-git-send-email-g.esp@free.fr> AC_CHECK_FUNCS is not enought as AC_SEARCH_LIBS has to be used before Tested to work with ac_cv_func_gettimeofday= ./configure using --enable-minimal or no other option than --enable-maintainer-mode Signed-off-by: Gilles Espinasse --- configure.ac | 23 +++++++++++++++++++++-- g10/Makefile.am | 2 +- tools/Makefile.am | 2 +- 3 files changed, 23 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index 181c07b..54d0dd0 100644 --- a/configure.ac +++ b/configure.ac @@ -1023,7 +1023,7 @@ AC_FUNC_VPRINTF AC_FUNC_FORK AC_CHECK_FUNCS(strerror stpcpy strlwr tcgetattr strtoul mmap sysconf) AC_CHECK_FUNCS(strcasecmp strncasecmp ctermid times unsetenv getpwnam getpwuid) -AC_CHECK_FUNCS(memmove gettimeofday getrusage setrlimit clock_gettime) +AC_CHECK_FUNCS(memmove gettimeofday getrusage setrlimit) AC_CHECK_FUNCS(atexit raise getpagesize strftime nl_langinfo setlocale) AC_CHECK_FUNCS(waitpid wait4 sigaction sigprocmask rand pipe stat getaddrinfo) AC_CHECK_FUNCS(fcntl ftruncate) @@ -1037,7 +1037,26 @@ AC_CHECK_TYPES([struct sigaction, sigset_t],,,[#include ]) AC_CHECK_FUNC(getopt,,AC_CHECK_LIB(iberty,getopt,AC_SUBST(GETOPT,"-liberty"))) -# +dnl Check for clock_gettime, in libc for FreeBSD, in rt for linux, +dnl in rt for Solaris 7, in posix4 for Solaris 2.5.1 +LIB_CLOCK_GETTIME= +clk_saved_libs=$LIBS +AC_SEARCH_LIBS([clock_gettime], [rt posix4], + [test "$ac_cv_search_clock_gettime" = "none required" || + LIB_CLOCK_GETTIME=$ac_cv_search_clock_gettime]) +AC_SUBST([LIB_CLOCK_GETTIME]) + +AC_MSG_CHECKING([for working clock_gettime]) +AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]], + [[clock_gettime(CLOCK_REALTIME, 0);]])], [gnupg_cv_clock_gettime=yes], [gnupg_cv_clock_gettime=no]) +AC_MSG_RESULT($gnupg_cv_clock_gettime) + +if test x"$gnupg_cv_clock_gettime" = xyes; then + AC_DEFINE([HAVE_CLOCK_GETTIME], 1, + [Define to 1 if you have the `clock_gettime' function.]) +fi +LIBS=$clk_saved_libs + # check for gethrtime and run a testprogram to see whether # it is broken. It has been reported that some Solaris and HP UX systems # raise an SIGILL diff --git a/g10/Makefile.am b/g10/Makefile.am index 60e7e11..ebceb2e 100644 --- a/g10/Makefile.am +++ b/g10/Makefile.am @@ -127,7 +127,7 @@ gpgv_SOURCES = gpgv.c \ verify.c LDADD = $(needed_libs) $(other_libs) @ZLIBS@ @W32LIBS@ -gpg_LDADD = $(LDADD) @LIBREADLINE@ @DLLIBS@ @NETLIBS@ @LIBUSB@ +gpg_LDADD = $(LDADD) @LIBREADLINE@ @DLLIBS@ @NETLIBS@ @LIBUSB@ @LIB_CLOCK_GETTIME@ $(PROGRAMS): $(needed_libs) diff --git a/tools/Makefile.am b/tools/Makefile.am index 0c6e691..604354a 100644 --- a/tools/Makefile.am +++ b/tools/Makefile.am @@ -41,7 +41,7 @@ endif gpgsplit_LDADD = $(needed_libs) $(other_libs) @ZLIBS@ mpicalc_LDADD = $(needed_libs) $(other_libs) @W32LIBS@ -bftest_LDADD = $(needed_libs) $(other_libs) @W32LIBS@ @DLLIBS@ @NETLIBS@ @LIBREADLINE@ +bftest_LDADD = $(needed_libs) $(other_libs) @W32LIBS@ @DLLIBS@ @NETLIBS@ @LIBREADLINE@ @LIB_CLOCK_GETTIME@ shmtest_LDADD = $(needed_libs) $(other_libs) @LIBREADLINE@ gpgsplit mpicalc bftest shmtest: $(needed_libs) -- 1.5.6.5 From g.esp at free.fr Sun Jan 22 07:01:45 2012 From: g.esp at free.fr (Gilles Espinasse) Date: Sun, 22 Jan 2012 07:01:45 +0100 Subject: [PATCH] Fix clock_gettime detection References: <1327185711-14947-1-git-send-email-g.esp@free.fr> Message-ID: <314c01ccd8cb$532e5d90$f9b5a8c0@pii350> forgot to say it is for 1.4. This is probably not the right way as gpg would link to librt and libpthread every time clock_gettime is found when in fact, code only use clock_gettime when !defined (HAVE_GETTIMEOFDAY) && !defined(HAVE_GETHRTIME) && defined(HAVE_BROKEN_GETHRTIME) I will do it again. ----- Original Message ----- From: "Gilles Espinasse" To: Cc: "Gilles Espinasse" Sent: Saturday, January 21, 2012 11:41 PM Subject: [PATCH] Fix clock_gettime detection > AC_CHECK_FUNCS is not enought as AC_SEARCH_LIBS has to be used before > > Tested to work with > ac_cv_func_gettimeofday= ./configure using --enable-minimal or no other option than --enable-maintainer-mode > > Signed-off-by: Gilles Espinasse > --- > configure.ac | 23 +++++++++++++++++++++-- > g10/Makefile.am | 2 +- > tools/Makefile.am | 2 +- > 3 files changed, 23 insertions(+), 4 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 181c07b..54d0dd0 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1023,7 +1023,7 @@ AC_FUNC_VPRINTF > AC_FUNC_FORK > AC_CHECK_FUNCS(strerror stpcpy strlwr tcgetattr strtoul mmap sysconf) > AC_CHECK_FUNCS(strcasecmp strncasecmp ctermid times unsetenv getpwnam getpwuid) > -AC_CHECK_FUNCS(memmove gettimeofday getrusage setrlimit clock_gettime) > +AC_CHECK_FUNCS(memmove gettimeofday getrusage setrlimit) > AC_CHECK_FUNCS(atexit raise getpagesize strftime nl_langinfo setlocale) > AC_CHECK_FUNCS(waitpid wait4 sigaction sigprocmask rand pipe stat getaddrinfo) > AC_CHECK_FUNCS(fcntl ftruncate) > @@ -1037,7 +1037,26 @@ AC_CHECK_TYPES([struct sigaction, sigset_t],,,[#include ]) > > AC_CHECK_FUNC(getopt,,AC_CHECK_LIB(iberty,getopt,AC_SUBST(GETOPT,"-liberty") )) > > -# > +dnl Check for clock_gettime, in libc for FreeBSD, in rt for linux, > +dnl in rt for Solaris 7, in posix4 for Solaris 2.5.1 > +LIB_CLOCK_GETTIME= > +clk_saved_libs=$LIBS > +AC_SEARCH_LIBS([clock_gettime], [rt posix4], > + [test "$ac_cv_search_clock_gettime" = "none required" || > + LIB_CLOCK_GETTIME=$ac_cv_search_clock_gettime]) > +AC_SUBST([LIB_CLOCK_GETTIME]) > + > +AC_MSG_CHECKING([for working clock_gettime]) > +AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]], > + [[clock_gettime(CLOCK_REALTIME, 0);]])], [gnupg_cv_clock_gettime=yes], [gnupg_cv_clock_gettime=no]) > +AC_MSG_RESULT($gnupg_cv_clock_gettime) > + > +if test x"$gnupg_cv_clock_gettime" = xyes; then > + AC_DEFINE([HAVE_CLOCK_GETTIME], 1, > + [Define to 1 if you have the `clock_gettime' function.]) > +fi > +LIBS=$clk_saved_libs > + > # check for gethrtime and run a testprogram to see whether > # it is broken. It has been reported that some Solaris and HP UX systems > # raise an SIGILL > diff --git a/g10/Makefile.am b/g10/Makefile.am > index 60e7e11..ebceb2e 100644 > --- a/g10/Makefile.am > +++ b/g10/Makefile.am > @@ -127,7 +127,7 @@ gpgv_SOURCES = gpgv.c \ > verify.c > > LDADD = $(needed_libs) $(other_libs) @ZLIBS@ @W32LIBS@ > -gpg_LDADD = $(LDADD) @LIBREADLINE@ @DLLIBS@ @NETLIBS@ @LIBUSB@ > +gpg_LDADD = $(LDADD) @LIBREADLINE@ @DLLIBS@ @NETLIBS@ @LIBUSB@ @LIB_CLOCK_GETTIME@ > > $(PROGRAMS): $(needed_libs) > > diff --git a/tools/Makefile.am b/tools/Makefile.am > index 0c6e691..604354a 100644 > --- a/tools/Makefile.am > +++ b/tools/Makefile.am > @@ -41,7 +41,7 @@ endif > > gpgsplit_LDADD = $(needed_libs) $(other_libs) @ZLIBS@ > mpicalc_LDADD = $(needed_libs) $(other_libs) @W32LIBS@ > -bftest_LDADD = $(needed_libs) $(other_libs) @W32LIBS@ @DLLIBS@ @NETLIBS@ @LIBREADLINE@ > +bftest_LDADD = $(needed_libs) $(other_libs) @W32LIBS@ @DLLIBS@ @NETLIBS@ @LIBREADLINE@ @LIB_CLOCK_GETTIME@ > shmtest_LDADD = $(needed_libs) $(other_libs) @LIBREADLINE@ > > gpgsplit mpicalc bftest shmtest: $(needed_libs) > -- > 1.5.6.5 > From g.esp at free.fr Sun Jan 22 08:21:41 2012 From: g.esp at free.fr (Gilles Espinasse) Date: Sun, 22 Jan 2012 08:21:41 +0100 Subject: [PATCH] 1.4 Fix clock_gettime configure detection Message-ID: <1327216901-18187-1-git-send-email-g.esp@free.fr> AC_CHECK_FUNCS is not enought for clock_gettime as AC_SEARCH_LIBS has to be used Changed configure clock_gettime test to only run in the case when cipher/random.c code will use that. This avoid linking to librt/libpthread when no required. Tested with a combination of ac_cv_func_gettimeofday=no gnupg_cv_func_gethrtime=no gnupg_cv_func_broken_gethrtime=yes ./configure --enable-minimal --enable-minimal is a test case as librt/libpthread already link with libusb Signed-off-by: Gilles Espinasse --- configure.ac | 26 ++++++++++++++++++++++++-- g10/Makefile.am | 2 +- tools/Makefile.am | 2 +- 3 files changed, 26 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index 181c07b..0cc2b46 100644 --- a/configure.ac +++ b/configure.ac @@ -1023,7 +1023,7 @@ AC_FUNC_VPRINTF AC_FUNC_FORK AC_CHECK_FUNCS(strerror stpcpy strlwr tcgetattr strtoul mmap sysconf) AC_CHECK_FUNCS(strcasecmp strncasecmp ctermid times unsetenv getpwnam getpwuid) -AC_CHECK_FUNCS(memmove gettimeofday getrusage setrlimit clock_gettime) +AC_CHECK_FUNCS(memmove gettimeofday getrusage setrlimit) AC_CHECK_FUNCS(atexit raise getpagesize strftime nl_langinfo setlocale) AC_CHECK_FUNCS(waitpid wait4 sigaction sigprocmask rand pipe stat getaddrinfo) AC_CHECK_FUNCS(fcntl ftruncate) @@ -1037,7 +1037,6 @@ AC_CHECK_TYPES([struct sigaction, sigset_t],,,[#include ]) AC_CHECK_FUNC(getopt,,AC_CHECK_LIB(iberty,getopt,AC_SUBST(GETOPT,"-liberty"))) -# # check for gethrtime and run a testprogram to see whether # it is broken. It has been reported that some Solaris and HP UX systems # raise an SIGILL @@ -1073,6 +1072,29 @@ if test $gnupg_cv_func_gethrtime = yes; then fi fi +dnl clock_gettime is only used when gethrtime and gettimeofday are not available +dnl so avoid linking to external lib when not needed +if test x"$ac_cv_func_gettimeofday" != xyes && test x"$gnupg_cv_func_gethrtime" != xyes && test x"$gnupg_cv_func_broken_gethrtime" != xno; then + dnl Check for clock_gettime, in libc for FreeBSD, in rt for linux, + dnl in rt for Solaris 7, in posix4 for Solaris 2.5.1 + LIB_CLOCK_GETTIME= + clk_saved_libs=$LIBS + AC_SEARCH_LIBS([clock_gettime], [rt posix4], + [test "$ac_cv_search_clock_gettime" = "none required" || + LIB_CLOCK_GETTIME=$ac_cv_search_clock_gettime]) + AC_SUBST([LIB_CLOCK_GETTIME]) + + AC_MSG_CHECKING([for working clock_gettime]) + AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include ]], + [[clock_gettime(CLOCK_REALTIME, 0);]])], [gnupg_cv_clock_gettime=yes], [gnupg_cv_clock_gettime=no]) + AC_MSG_RESULT($gnupg_cv_clock_gettime) + + if test x"$gnupg_cv_clock_gettime" = xyes; then + AC_DEFINE([HAVE_CLOCK_GETTIME], 1, + [Define to 1 if you have the `clock_gettime' function.]) + fi + LIBS=$clk_saved_libs +fi GNUPG_CHECK_MLOCK GNUPG_FUNC_MKDIR_TAKES_ONE_ARG diff --git a/g10/Makefile.am b/g10/Makefile.am index 60e7e11..ebceb2e 100644 --- a/g10/Makefile.am +++ b/g10/Makefile.am @@ -127,7 +127,7 @@ gpgv_SOURCES = gpgv.c \ verify.c LDADD = $(needed_libs) $(other_libs) @ZLIBS@ @W32LIBS@ -gpg_LDADD = $(LDADD) @LIBREADLINE@ @DLLIBS@ @NETLIBS@ @LIBUSB@ +gpg_LDADD = $(LDADD) @LIBREADLINE@ @DLLIBS@ @NETLIBS@ @LIBUSB@ @LIB_CLOCK_GETTIME@ $(PROGRAMS): $(needed_libs) diff --git a/tools/Makefile.am b/tools/Makefile.am index 0c6e691..604354a 100644 --- a/tools/Makefile.am +++ b/tools/Makefile.am @@ -41,7 +41,7 @@ endif gpgsplit_LDADD = $(needed_libs) $(other_libs) @ZLIBS@ mpicalc_LDADD = $(needed_libs) $(other_libs) @W32LIBS@ -bftest_LDADD = $(needed_libs) $(other_libs) @W32LIBS@ @DLLIBS@ @NETLIBS@ @LIBREADLINE@ +bftest_LDADD = $(needed_libs) $(other_libs) @W32LIBS@ @DLLIBS@ @NETLIBS@ @LIBREADLINE@ @LIB_CLOCK_GETTIME@ shmtest_LDADD = $(needed_libs) $(other_libs) @LIBREADLINE@ gpgsplit mpicalc bftest shmtest: $(needed_libs) -- 1.5.6.5 From g.esp at free.fr Sun Jan 22 08:47:36 2012 From: g.esp at free.fr (Gilles Espinasse) Date: Sun, 22 Jan 2012 08:47:36 +0100 Subject: [PATCH] Fix minor typo in comments Message-ID: <1327218456-18259-1-git-send-email-g.esp@free.fr> or missing words, replace scare with scarce Signed-off-by: Gilles Espinasse --- cipher/random.c | 4 ++-- cipher/rndw32.c | 2 +- doc/HACKING | 5 ++--- 3 files changed, 5 insertions(+), 6 deletions(-) diff --git a/cipher/random.c b/cipher/random.c index f7ffb22..460c2af 100644 --- a/cipher/random.c +++ b/cipher/random.c @@ -514,8 +514,8 @@ read_seed_file(void) /* And read a few bytes from our entropy source. By using * a level of 0 this will not block and might not return anything * with some entropy drivers, however the rndlinux driver will use - * /dev/urandom and return some stuff - Do not read to much as we - * want to be friendly to the scare system entropy resource. */ + * /dev/urandom and return some stuff - Do not read too much as we + * want to be friendly to the scarce system entropy resource. */ read_random_source( 0, 16, 0 ); allow_seed_file_update = 1; diff --git a/cipher/rndw32.c b/cipher/rndw32.c index 2d107e0..aec5fbb 100644 --- a/cipher/rndw32.c +++ b/cipher/rndw32.c @@ -534,7 +534,7 @@ rndw32_gather_random (void (*add)(const void*, size_t, int), int requester, if( !level ) return 0; /* We don't differentiate between level 1 and 2 here because - * there is no nternal entropy pool as a scary resource. It may + * there is no internal entropy pool as a scarce resource. It may * all work slower, but because our entropy source will never * block but deliver some not easy to measure entropy, we assume level 2 */ diff --git a/doc/HACKING b/doc/HACKING index 37ebdc9..27ebe64 100644 --- a/doc/HACKING +++ b/doc/HACKING @@ -47,9 +47,8 @@ by sending a mail with subject "subscribe" to You must run scripts/autogen.sh before doing the ./configure, -as this creates some needed while which are not in the repository. -autogen.sh should check that you have all required tools -installed. +as this creates some needed files not include in the repository. +autogen.sh should check that you have all required tools installed. RSYNC access -- 1.5.6.5 From wk at gnupg.org Mon Jan 23 11:26:14 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 23 Jan 2012 11:26:14 +0100 Subject: 1.4.12 beta installer for Windows Message-ID: <87y5syd8ah.fsf@vigenere.g10code.de> Hi, I created a pre-release of an GnuPG 1.4.12 installer for Windows: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-w32cli-1.4.12-git51c1e84.exe ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-w32cli-1.4.12-git51c1e84.exe.sig Sources are in the same directory. This version is built using a newer toolchain and thus you might run into problems. If so, please report them to this list. Note: The use of the 1.4 version under Windows is not generally suggested. In almost all cases you are better off with the GnuPG-2 installer provided at gpg4win.org. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jan 25 17:04:48 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 25 Jan 2012 17:04:48 +0100 Subject: GnuPG master migrated to nPth Message-ID: <8739b37opr.fsf@vigenere.g10code.de> Hi, I merged the npth branch of GnuPG into master. Thus there is no more need for GNU Pth. The drawback is that you need to build and install the replacement library nPth. There are no tarballs yet, thus you need to get that library from its GIT repo: git clone git://git.gnupg.org/npth.git you will also need the latest version of libassuan: git clone git://git.gnupg.org/libassuan.git Q: What is nPth? A: nPth - The New GNU Portable Threads Library This is a library to provide the GNU Pth API and thus a non-preemptive threads implementation. In contrast to GNU Pth is is based on the system's standard threads implementation. This allows the use of libraries which are not compatible to GNU Pth. Experience with a Windows Pth emulation showed that this is a solid way to provide a co-routine based framework. Q: For what system is nPth available? A: As of now nPth provides support for pthread based systems and Windows. Support for other threading implementations is not planned, but can be done. The only tested platforms are GNU/Linux systems; it has not yet been tested on *BSD systems. The support for Windows is implemented but not well tested. nPth is a small library and easy to port to other systems. Q: Why did you drop GNU Pth? A: Almost all systems these days have reliable native thread support thus we should make use of it. We did it for Windows anyway (via our w32pth). The use of GNU Pth is troublesome if you need to link to libraries which require pthread. There are also some problems with GNU Pth on certain systems (iirc, HP/UX). Further, GNU Pth is not anymore used by many projects. Debian Sid lists only zhcon (Fast console CJK system using FrameBuffer) as another user of it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jan 26 17:39:52 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Jan 2012 17:39:52 +0100 Subject: GnuPG master migrated to nPth In-Reply-To: <8739b37opr.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 25 Jan 2012 17:04:48 +0100") References: <8739b37opr.fsf@vigenere.g10code.de> Message-ID: <8762fy5sfb.fsf@vigenere.g10code.de> Hi, just a quick update: npth now builds also on kfreebsd and GnuPG basically runs on that platform. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Thu Jan 26 17:46:35 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 26 Jan 2012 11:46:35 -0500 Subject: GnuPG master migrated to nPth In-Reply-To: <8762fy5sfb.fsf@vigenere.g10code.de> References: <8739b37opr.fsf@vigenere.g10code.de> <8762fy5sfb.fsf@vigenere.g10code.de> Message-ID: <131D4253-7659-4451-A77C-638828D16562@guardianproject.info> Any ideas bout npth on Android? Is npth required to run gnupg? .hc On Jan 26, 2012, at 11:39 AM, Werner Koch wrote: > Hi, > > just a quick update: npth now builds also on kfreebsd and GnuPG > basically runs on that platform. > > > 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 ---------------------------------------------------------------------------- ?El pueblo unido jam?s ser? vencido! From wk at gnupg.org Thu Jan 26 18:00:46 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 26 Jan 2012 18:00:46 +0100 Subject: GnuPG master migrated to nPth In-Reply-To: <131D4253-7659-4451-A77C-638828D16562@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 26 Jan 2012 11:46:35 -0500") References: <8739b37opr.fsf@vigenere.g10code.de> <8762fy5sfb.fsf@vigenere.g10code.de> <131D4253-7659-4451-A77C-638828D16562@guardianproject.info> Message-ID: <87zkda4cw1.fsf@vigenere.g10code.de> On Thu, 26 Jan 2012 17:46, hans at guardianproject.info said: > Any ideas bout npth on Android? Is npth required to run gnupg? Would you mind try building it? It should not be too hard to adjust it for Android. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Thu Jan 26 20:50:28 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 26 Jan 2012 14:50:28 -0500 Subject: GnuPG master migrated to nPth In-Reply-To: <87zkda4cw1.fsf@vigenere.g10code.de> References: <8739b37opr.fsf@vigenere.g10code.de> <8762fy5sfb.fsf@vigenere.g10code.de> <131D4253-7659-4451-A77C-638828D16562@guardianproject.info> <87zkda4cw1.fsf@vigenere.g10code.de> Message-ID: <4F21AE84.1060006@guardianproject.info> On 01/26/2012 12:00 PM, Werner Koch wrote: > On Thu, 26 Jan 2012 17:46, hans at guardianproject.info said: >> Any ideas bout npth on Android? Is npth required to run gnupg? > > Would you mind try building it? It should not be too hard to adjust it > for Android. First thing, config.sub and config.guess are too old, they don't support the host 'arm-linux-androideabi'. I think this applies to all of the libs hosted at gnupg.org that I've tried (gpg-error, assuan, gcrypt, gnupg, npth). Those files need to be upgraded in order for things to build. I've been manually replacing them in my builds. Next, npth's ./configure complains it can't find pthread, I'm looking into this now. pthread is included in Android's bionic libc, but someone simplified. It does not have pthread_cancel(), for example: http://groups.google.com/group/android-platform/browse_thread/thread/0aad393da2da65b1 .hc From hans at guardianproject.info Thu Jan 26 21:00:59 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 26 Jan 2012 15:00:59 -0500 Subject: GnuPG master migrated to nPth In-Reply-To: <4F21AE84.1060006@guardianproject.info> References: <8739b37opr.fsf@vigenere.g10code.de> <8762fy5sfb.fsf@vigenere.g10code.de> <131D4253-7659-4451-A77C-638828D16562@guardianproject.info> <87zkda4cw1.fsf@vigenere.g10code.de> <4F21AE84.1060006@guardianproject.info> Message-ID: <4F21B0FB.6010902@guardianproject.info> On 01/26/2012 02:50 PM, Hans-Christoph Steiner wrote: > > On 01/26/2012 12:00 PM, Werner Koch wrote: >> On Thu, 26 Jan 2012 17:46, hans at guardianproject.info said: >>> Any ideas bout npth on Android? Is npth required to run gnupg? >> >> Would you mind try building it? It should not be too hard to adjust it >> for Android. > > First thing, config.sub and config.guess are too old, they don't support > the host 'arm-linux-androideabi'. I think this applies to all of the > libs hosted at gnupg.org that I've tried (gpg-error, assuan, gcrypt, > gnupg, npth). Those files need to be upgraded in order for things to > build. I've been manually replacing them in my builds. > > Next, npth's ./configure complains it can't find pthread, I'm looking > into this now. pthread is included in Android's bionic libc, but > someone simplified. It does not have pthread_cancel(), for example: > http://groups.google.com/group/android-platform/browse_thread/thread/0aad393da2da65b1 As for pthread, in Android its in libc, so this fails: AC_CHECK_LIB(pthread, pthread_create) But this succeeds: AC_CHECK_LIB(c, pthread_create) Bionic libc does not seem to have these though: pthread_tryjoin_np pthread_getname_np but does seem to have pthread_setname_np. So at this point pth is ported and seems a better option for Android than npth. .hc From hans at guardianproject.info Thu Jan 26 21:35:15 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 26 Jan 2012 15:35:15 -0500 Subject: porting gnupg to Android, is pth required? Message-ID: <4F21B903.5060000@guardianproject.info> Werner Koch writes: > On Thu, 19 Jan 2012 15:41, simon at josefsson.org said: > >> The error messages suggests it is the former, you need to integrate >> gnulib in the documented way otherwise there will be many strange >> compiler errors. I don't recall any significant discussions involving > > Well, the included gnulib stuff is pretty old and has been modified. > For example to support Windows CE. The only really requirement we had > was support for setenv. That pulled in a lot of other stuff. > > The problem with gnulib is, it defines a complete new build environment > which often does not work well with existing code. GnuPG has its own OS > abstraction layer and thus the use of gnulib is not easy. gnulib is > designed as an extension to Posix to lift it up to a glibc feature > level. GnuPG is not designed to build against glibc but towards Posix > 2001 and W32. Other related applications (e.g. GPA) build against glib > - which is again a different environment. > > My conclusion is that we can't switch to gnulib nor to glib without > breaking a lot of code. Fixing the few problems with the Android libc > should be easy compared to the changes required to support W32CE or VMS. So unfortunately, the Android gnulib porting effort didn't go very far. And it still doesn't build. It seems like this is currently a deal breaker for gnupg on Android since there doesn't seem to be interest in the gnulib maintainers in fixing it for Android, and gnupg's include gnulib is a custom version, so the upstream fixes might not even apply to gnupg. What is the next step? .hc From hans at guardianproject.info Thu Jan 26 23:51:20 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 26 Jan 2012 17:51:20 -0500 Subject: porting gnupg to Android, is pth required? In-Reply-To: <4F21B903.5060000@guardianproject.info> References: <4F21B903.5060000@guardianproject.info> Message-ID: <4F21D8E8.1060704@guardianproject.info> On 01/26/2012 03:35 PM, Hans-Christoph Steiner wrote: > Werner Koch writes: >> On Thu, 19 Jan 2012 15:41, simon at josefsson.org said: >> >>> The error messages suggests it is the former, you need to integrate >>> gnulib in the documented way otherwise there will be many strange >>> compiler errors. I don't recall any significant discussions involving >> >> Well, the included gnulib stuff is pretty old and has been modified. >> For example to support Windows CE. The only really requirement we had >> was support for setenv. That pulled in a lot of other stuff. >> >> The problem with gnulib is, it defines a complete new build environment >> which often does not work well with existing code. GnuPG has its own OS >> abstraction layer and thus the use of gnulib is not easy. gnulib is >> designed as an extension to Posix to lift it up to a glibc feature >> level. GnuPG is not designed to build against glibc but towards Posix >> 2001 and W32. Other related applications (e.g. GPA) build against glib >> - which is again a different environment. >> >> My conclusion is that we can't switch to gnulib nor to glib without >> breaking a lot of code. Fixing the few problems with the Android libc >> should be easy compared to the changes required to support W32CE or VMS. > > So unfortunately, the Android gnulib porting effort didn't go very far. > And it still doesn't build. It seems like this is currently a deal > breaker for gnupg on Android since there doesn't seem to be interest in > the gnulib maintainers in fixing it for Android, and gnupg's include > gnulib is a custom version, so the upstream fixes might not even apply > to gnupg. > > What is the next step? Sorry for all the doom and gloom, I actually just got past the original gnupg gnulib hurdle by installing gnulib from the head of its master. Let's see what I can nail down, then I'll report back once I have something working. .hc From g.esp at free.fr Fri Jan 27 08:49:47 2012 From: g.esp at free.fr (Gilles Espinasse) Date: Fri, 27 Jan 2012 08:49:47 +0100 Subject: GnuPG master migrated to nPth References: <8739b37opr.fsf@vigenere.g10code.de><8762fy5sfb.fsf@vigenere.g10code.de><131D4253-7659-4451-A77C-638828D16562@guardianproject.info><87zkda4cw1.fsf@vigenere.g10code.de><4F21AE84.1060006@guardianproject.info> <4F21B0FB.6010902@guardianproject.info> Message-ID: <006a01ccdcc8$3f12d330$f9b5a8c0@pii350> ----- Original Message ----- From: "Hans-Christoph Steiner" To: Sent: Thursday, January 26, 2012 9:00 PM Subject: Re: GnuPG master migrated to nPth > > On 01/26/2012 02:50 PM, Hans-Christoph Steiner wrote: > > > > On 01/26/2012 12:00 PM, Werner Koch wrote: > >> On Thu, 26 Jan 2012 17:46, hans at guardianproject.info said: > >>> Any ideas bout npth on Android? Is npth required to run gnupg? > >> > >> Would you mind try building it? It should not be too hard to adjust it > >> for Android. > > > > First thing, config.sub and config.guess are too old, they don't support > > the host 'arm-linux-androideabi'. I think this applies to all of the > > libs hosted at gnupg.org that I've tried (gpg-error, assuan, gcrypt, > > gnupg, npth). Those files need to be upgraded in order for things to > > build. I've been manually replacing them in my builds. > > > > Next, npth's ./configure complains it can't find pthread, I'm looking > > into this now. pthread is included in Android's bionic libc, but > > someone simplified. It does not have pthread_cancel(), for example: > > http://groups.google.com/group/android-platform/browse_thread/thread/0aad393da2da65b1 > > As for pthread, in Android its in libc, so this fails: > > AC_CHECK_LIB(pthread, pthread_create) > Something like this should work as libc c is the first lib the system call is searched if you look at code generated in configure AC_SEARCH_LIBS([pthread_create], [pthread], [test "$ac_cv_search_pthread_create" = "none required" || LIB_PTHREAD_CREATE=$ac_cv_search_pthread_create]) AC_SUBST([LIB_PTHREAD_CREATE]) Gilles From wk at gnupg.org Fri Jan 27 11:02:39 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Jan 2012 11:02:39 +0100 Subject: GnuPG master migrated to nPth In-Reply-To: <4F21AE84.1060006@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 26 Jan 2012 14:50:28 -0500") References: <8739b37opr.fsf@vigenere.g10code.de> <8762fy5sfb.fsf@vigenere.g10code.de> <131D4253-7659-4451-A77C-638828D16562@guardianproject.info> <87zkda4cw1.fsf@vigenere.g10code.de> <4F21AE84.1060006@guardianproject.info> Message-ID: <87ehulcvk0.fsf@vigenere.g10code.de> On Thu, 26 Jan 2012 20:50, hans at guardianproject.info said: > First thing, config.sub and config.guess are too old, they don't support > the host 'arm-linux-androideabi'. I think this applies to all of the > libs hosted at gnupg.org that I've tried (gpg-error, assuan, gcrypt, I update them only when doing a release (see README.maint): * Decide whether you want to update the automake standard files (Mainly config.guess and config.sub). I can do it for npth today Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jan 27 11:06:51 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Jan 2012 11:06:51 +0100 Subject: porting gnupg to Android, is pth required? In-Reply-To: <4F21B903.5060000@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 26 Jan 2012 15:35:15 -0500") References: <4F21B903.5060000@guardianproject.info> Message-ID: <8762fxcvd0.fsf@vigenere.g10code.de> On Thu, 26 Jan 2012 21:35, hans at guardianproject.info said: > breaker for gnupg on Android since there doesn't seem to be interest in > the gnulib maintainers in fixing it for Android, and gnupg's include I have seen that they are working on it. > gnulib is a custom version, so the upstream fixes might not even apply > to gnupg. If there is a working fix, I'll port it to gnupg. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jan 27 11:05:13 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Jan 2012 11:05:13 +0100 Subject: GnuPG master migrated to nPth In-Reply-To: <4F21B0FB.6010902@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 26 Jan 2012 15:00:59 -0500") References: <8739b37opr.fsf@vigenere.g10code.de> <8762fy5sfb.fsf@vigenere.g10code.de> <131D4253-7659-4451-A77C-638828D16562@guardianproject.info> <87zkda4cw1.fsf@vigenere.g10code.de> <4F21AE84.1060006@guardianproject.info> <4F21B0FB.6010902@guardianproject.info> Message-ID: <87aa59cvfq.fsf@vigenere.g10code.de> On Thu, 26 Jan 2012 21:00, hans at guardianproject.info said: > As for pthread, in Android its in libc, so this fails: > > AC_CHECK_LIB(pthread, pthread_create) Well that is okay, but the follwoing test is not. I'll do something about it later. > Bionic libc does not seem to have these though: pthread_tryjoin_np > pthread_getname_np but does seem to have pthread_setname_np. So at this > point pth is ported and seems a better option for Android than npth. Already fixed yesterday while porting it to kfreebsd. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Fri Jan 27 14:55:31 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 27 Jan 2012 08:55:31 -0500 Subject: porting gnupg to Android, is pth required? In-Reply-To: <8762fxcvd0.fsf@vigenere.g10code.de> References: <4F21B903.5060000@guardianproject.info> <8762fxcvd0.fsf@vigenere.g10code.de> Message-ID: On Jan 27, 2012, at 5:06 AM, Werner Koch wrote: > On Thu, 26 Jan 2012 21:35, hans at guardianproject.info said: > >> breaker for gnupg on Android since there doesn't seem to be interest in >> the gnulib maintainers in fixing it for Android, and gnupg's include > > I have seen that they are working on it. > >> gnulib is a custom version, so the upstream fixes might not even apply >> to gnupg. > > If there is a working fix, I'll port it to gnupg. I got past the stdint.h problem, but am now onto the pthread. I guess we'll know whether the new gnulib works once we have a full build. For the record, this is how I got past the stdint.h issue: rm -rf gnupg/gl gnulib-tool --import \ --dir=gnupg/ --lib=libgnu --source-base=gl --m4-base=gl/m4 --doc-base=doc \ --tests-base=tests --aux-dir=scripts --no-conditional-dependencies \ --no-libtool --macro-prefix=gl alloca-opt malloca mkdtemp setenv strpbrk \ xsize .hc ---------------------------------------------------------------------------- I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler From hans at at.or.at Fri Jan 27 14:57:27 2012 From: hans at at.or.at (Hans-Christoph Steiner) Date: Fri, 27 Jan 2012 08:57:27 -0500 Subject: porting gnupg to Android, is pth required? In-Reply-To: References: <4F21B903.5060000@guardianproject.info> <8762fxcvd0.fsf@vigenere.g10code.de> Message-ID: <3EC7B948-29DC-4F07-8F95-80DAC0C4A613@at.or.at> On Jan 27, 2012, at 8:55 AM, Hans-Christoph Steiner wrote: > > On Jan 27, 2012, at 5:06 AM, Werner Koch wrote: > >> On Thu, 26 Jan 2012 21:35, hans at guardianproject.info said: >> >>> breaker for gnupg on Android since there doesn't seem to be interest in >>> the gnulib maintainers in fixing it for Android, and gnupg's include >> >> I have seen that they are working on it. >> >>> gnulib is a custom version, so the upstream fixes might not even apply >>> to gnupg. >> >> If there is a working fix, I'll port it to gnupg. > > I got past the stdint.h problem, but am now onto the pthread. I guess we'll know whether the new gnulib works once we have a full build. For the record, this is how I got past the stdint.h issue: > > rm -rf gnupg/gl > gnulib-tool --import \ > --dir=gnupg/ --lib=libgnu --source-base=gl --m4-base=gl/m4 --doc-base=doc \ > --tests-base=tests --aux-dir=scripts --no-conditional-dependencies \ > --no-libtool --macro-prefix=gl alloca-opt malloca mkdtemp setenv strpbrk \ > xsize Oops, I forgot to say, it was close to the HEAD of master of gnulib git, it was at this commit: 8661b04d4c3c3cdded4cdb00c5a4ced165612c1d .hc ---------------------------------------------------------------------------- If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson From wk at gnupg.org Fri Jan 27 15:42:28 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Jan 2012 15:42:28 +0100 Subject: porting gnupg to Android, is pth required? In-Reply-To: (Hans-Christoph Steiner's message of "Fri, 27 Jan 2012 08:55:31 -0500") References: <4F21B903.5060000@guardianproject.info> <8762fxcvd0.fsf@vigenere.g10code.de> Message-ID: <87ty3hb417.fsf@vigenere.g10code.de> On Fri, 27 Jan 2012 14:55, hans at guardianproject.info said: > I got past the stdint.h problem, but am now onto the pthread. I guess Please try the latest npth - I changed quite some things in the configuration. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jan 27 17:52:57 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 27 Jan 2012 17:52:57 +0100 Subject: porting gnupg to Android, is pth required? In-Reply-To: (Hans-Christoph Steiner's message of "Fri, 27 Jan 2012 08:55:31 -0500") References: <4F21B903.5060000@guardianproject.info> <8762fxcvd0.fsf@vigenere.g10code.de> Message-ID: <87ehulaxzq.fsf@vigenere.g10code.de> Hi, please try this patch to solve the build problems on gnupg. It is basically the same as used in gnulib. I have not tested it, though. Eventuelly I need to install the Android toolchain. >From bdde44ae8d4709e33c09781c3d37a5da2c7a5e0d Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Fri, 27 Jan 2012 17:29:57 +0100 Subject: [PATCH] gl: Add support for Android to stdint.h replacement. * gl/stdint_.h: When included from Bionic , just include the system's . --- gl/stdint_.h | 368 ++++++++++++++++++++++++++++++---------------------------- 1 files changed, 189 insertions(+), 179 deletions(-) diff --git a/gl/stdint_.h b/gl/stdint_.h index bc27595..19577e7 100644 --- a/gl/stdint_.h +++ b/gl/stdint_.h @@ -23,6 +23,16 @@ * */ +/* On Android (Bionic libc), includes this file before + having defined 'time_t'. Therefore in this case avoid including + other system header files; just include the system's . + Ideally we should test __BIONIC__ here, but it is only defined after + has been included; hence test __ANDROID__ instead. */ +#if defined __ANDROID__ \ + && defined _SYS_TYPES_H_ && !defined _SSIZE_T_DEFINED_ +# include_next +#else + /* Get those types that are already defined in other system include files, so that we can "#define int8_t signed char" below without worrying about a later system include file containing a "typedef @@ -243,38 +253,38 @@ /* Here we assume a standard architecture where the hardware integer types have 8, 16, 32, optionally 64 bits. */ -#undef INT8_MIN -#undef INT8_MAX -#undef UINT8_MAX -#define INT8_MIN (~ INT8_MAX) -#define INT8_MAX 127 -#define UINT8_MAX 255 - -#undef INT16_MIN -#undef INT16_MAX -#undef UINT16_MAX -#define INT16_MIN (~ INT16_MAX) -#define INT16_MAX 32767 -#define UINT16_MAX 65535 - -#undef INT32_MIN -#undef INT32_MAX -#undef UINT32_MAX -#define INT32_MIN (~ INT32_MAX) -#define INT32_MAX 2147483647 -#define UINT32_MAX 4294967295U - -#undef INT64_MIN -#undef INT64_MAX -#ifdef int64_t -# define INT64_MIN (~ INT64_MAX) -# define INT64_MAX INTMAX_C (9223372036854775807) -#endif +# undef INT8_MIN +# undef INT8_MAX +# undef UINT8_MAX +# define INT8_MIN (~ INT8_MAX) +# define INT8_MAX 127 +# define UINT8_MAX 255 + +# undef INT16_MIN +# undef INT16_MAX +# undef UINT16_MAX +# define INT16_MIN (~ INT16_MAX) +# define INT16_MAX 32767 +# define UINT16_MAX 65535 + +# undef INT32_MIN +# undef INT32_MAX +# undef UINT32_MAX +# define INT32_MIN (~ INT32_MAX) +# define INT32_MAX 2147483647 +# define UINT32_MAX 4294967295U + +# undef INT64_MIN +# undef INT64_MAX +# ifdef int64_t +# define INT64_MIN (~ INT64_MAX) +# define INT64_MAX INTMAX_C (9223372036854775807) +# endif -#undef UINT64_MAX -#ifdef uint64_t -# define UINT64_MAX UINTMAX_C (18446744073709551615) -#endif +# undef UINT64_MAX +# ifdef uint64_t +# define UINT64_MAX UINTMAX_C (18446744073709551615) +# endif /* 7.18.2.2. Limits of minimum-width integer types */ @@ -282,38 +292,38 @@ types have 8, 16, 32, optionally 64 bits. Therefore the leastN_t types are the same as the corresponding N_t types. */ -#undef INT_LEAST8_MIN -#undef INT_LEAST8_MAX -#undef UINT_LEAST8_MAX -#define INT_LEAST8_MIN INT8_MIN -#define INT_LEAST8_MAX INT8_MAX -#define UINT_LEAST8_MAX UINT8_MAX - -#undef INT_LEAST16_MIN -#undef INT_LEAST16_MAX -#undef UINT_LEAST16_MAX -#define INT_LEAST16_MIN INT16_MIN -#define INT_LEAST16_MAX INT16_MAX -#define UINT_LEAST16_MAX UINT16_MAX - -#undef INT_LEAST32_MIN -#undef INT_LEAST32_MAX -#undef UINT_LEAST32_MAX -#define INT_LEAST32_MIN INT32_MIN -#define INT_LEAST32_MAX INT32_MAX -#define UINT_LEAST32_MAX UINT32_MAX - -#undef INT_LEAST64_MIN -#undef INT_LEAST64_MAX -#ifdef int64_t -# define INT_LEAST64_MIN INT64_MIN -# define INT_LEAST64_MAX INT64_MAX -#endif +# undef INT_LEAST8_MIN +# undef INT_LEAST8_MAX +# undef UINT_LEAST8_MAX +# define INT_LEAST8_MIN INT8_MIN +# define INT_LEAST8_MAX INT8_MAX +# define UINT_LEAST8_MAX UINT8_MAX + +# undef INT_LEAST16_MIN +# undef INT_LEAST16_MAX +# undef UINT_LEAST16_MAX +# define INT_LEAST16_MIN INT16_MIN +# define INT_LEAST16_MAX INT16_MAX +# define UINT_LEAST16_MAX UINT16_MAX + +# undef INT_LEAST32_MIN +# undef INT_LEAST32_MAX +# undef UINT_LEAST32_MAX +# define INT_LEAST32_MIN INT32_MIN +# define INT_LEAST32_MAX INT32_MAX +# define UINT_LEAST32_MAX UINT32_MAX + +# undef INT_LEAST64_MIN +# undef INT_LEAST64_MAX +# ifdef int64_t +# define INT_LEAST64_MIN INT64_MIN +# define INT_LEAST64_MAX INT64_MAX +# endif -#undef UINT_LEAST64_MAX -#ifdef uint64_t -# define UINT_LEAST64_MAX UINT64_MAX -#endif +# undef UINT_LEAST64_MAX +# ifdef uint64_t +# define UINT_LEAST64_MAX UINT64_MAX +# endif /* 7.18.2.3. Limits of fastest minimum-width integer types */ @@ -321,105 +331,105 @@ types have 8, 16, 32, optionally 64 bits. Therefore the fastN_t types are taken from the same list of types. */ -#undef INT_FAST8_MIN -#undef INT_FAST8_MAX -#undef UINT_FAST8_MAX -#define INT_FAST8_MIN LONG_MIN -#define INT_FAST8_MAX LONG_MAX -#define UINT_FAST8_MAX ULONG_MAX - -#undef INT_FAST16_MIN -#undef INT_FAST16_MAX -#undef UINT_FAST16_MAX -#define INT_FAST16_MIN LONG_MIN -#define INT_FAST16_MAX LONG_MAX -#define UINT_FAST16_MAX ULONG_MAX - -#undef INT_FAST32_MIN -#undef INT_FAST32_MAX -#undef UINT_FAST32_MAX -#define INT_FAST32_MIN LONG_MIN -#define INT_FAST32_MAX LONG_MAX -#define UINT_FAST32_MAX ULONG_MAX - -#undef INT_FAST64_MIN -#undef INT_FAST64_MAX -#ifdef int64_t -# define INT_FAST64_MIN INT64_MIN -# define INT_FAST64_MAX INT64_MAX -#endif +# undef INT_FAST8_MIN +# undef INT_FAST8_MAX +# undef UINT_FAST8_MAX +# define INT_FAST8_MIN LONG_MIN +# define INT_FAST8_MAX LONG_MAX +# define UINT_FAST8_MAX ULONG_MAX + +# undef INT_FAST16_MIN +# undef INT_FAST16_MAX +# undef UINT_FAST16_MAX +# define INT_FAST16_MIN LONG_MIN +# define INT_FAST16_MAX LONG_MAX +# define UINT_FAST16_MAX ULONG_MAX + +# undef INT_FAST32_MIN +# undef INT_FAST32_MAX +# undef UINT_FAST32_MAX +# define INT_FAST32_MIN LONG_MIN +# define INT_FAST32_MAX LONG_MAX +# define UINT_FAST32_MAX ULONG_MAX + +# undef INT_FAST64_MIN +# undef INT_FAST64_MAX +# ifdef int64_t +# define INT_FAST64_MIN INT64_MIN +# define INT_FAST64_MAX INT64_MAX +# endif -#undef UINT_FAST64_MAX -#ifdef uint64_t -# define UINT_FAST64_MAX UINT64_MAX -#endif +# undef UINT_FAST64_MAX +# ifdef uint64_t +# define UINT_FAST64_MAX UINT64_MAX +# endif /* 7.18.2.4. Limits of integer types capable of holding object pointers */ -#undef INTPTR_MIN -#undef INTPTR_MAX -#undef UINTPTR_MAX -#define INTPTR_MIN LONG_MIN -#define INTPTR_MAX LONG_MAX -#define UINTPTR_MAX ULONG_MAX +# undef INTPTR_MIN +# undef INTPTR_MAX +# undef UINTPTR_MAX +# define INTPTR_MIN LONG_MIN +# define INTPTR_MAX LONG_MAX +# define UINTPTR_MAX ULONG_MAX /* 7.18.2.5. Limits of greatest-width integer types */ -#undef INTMAX_MIN -#undef INTMAX_MAX -#define INTMAX_MIN (~ INTMAX_MAX) -#ifdef INT64_MAX -# define INTMAX_MAX INT64_MAX -#else -# define INTMAX_MAX INT32_MAX -#endif +# undef INTMAX_MIN +# undef INTMAX_MAX +# define INTMAX_MIN (~ INTMAX_MAX) +# ifdef INT64_MAX +# define INTMAX_MAX INT64_MAX +# else +# define INTMAX_MAX INT32_MAX +# endif -#undef UINTMAX_MAX -#ifdef UINT64_MAX -# define UINTMAX_MAX UINT64_MAX -#else -# define UINTMAX_MAX UINT32_MAX -#endif +# undef UINTMAX_MAX +# ifdef UINT64_MAX +# define UINTMAX_MAX UINT64_MAX +# else +# define UINTMAX_MAX UINT32_MAX +# endif /* 7.18.3. Limits of other integer types */ /* ptrdiff_t limits */ -#undef PTRDIFF_MIN -#undef PTRDIFF_MAX -#define PTRDIFF_MIN \ +# undef PTRDIFF_MIN +# undef PTRDIFF_MAX +# define PTRDIFF_MIN \ _STDINT_MIN (1, @BITSIZEOF_PTRDIFF_T@, 0 at PTRDIFF_T_SUFFIX@) -#define PTRDIFF_MAX \ +# define PTRDIFF_MAX \ _STDINT_MAX (1, @BITSIZEOF_PTRDIFF_T@, 0 at PTRDIFF_T_SUFFIX@) /* sig_atomic_t limits */ -#undef SIG_ATOMIC_MIN -#undef SIG_ATOMIC_MAX -#define SIG_ATOMIC_MIN \ +# undef SIG_ATOMIC_MIN +# undef SIG_ATOMIC_MAX +# define SIG_ATOMIC_MIN \ _STDINT_MIN (@HAVE_SIGNED_SIG_ATOMIC_T@, @BITSIZEOF_SIG_ATOMIC_T@, \ 0 at SIG_ATOMIC_T_SUFFIX@) -#define SIG_ATOMIC_MAX \ +# define SIG_ATOMIC_MAX \ _STDINT_MAX (@HAVE_SIGNED_SIG_ATOMIC_T@, @BITSIZEOF_SIG_ATOMIC_T@, \ 0 at SIG_ATOMIC_T_SUFFIX@) /* size_t limit */ -#undef SIZE_MAX -#define SIZE_MAX _STDINT_MAX (0, @BITSIZEOF_SIZE_T@, 0 at SIZE_T_SUFFIX@) +# undef SIZE_MAX +# define SIZE_MAX _STDINT_MAX (0, @BITSIZEOF_SIZE_T@, 0 at SIZE_T_SUFFIX@) /* wchar_t limits */ -#undef WCHAR_MIN -#undef WCHAR_MAX -#define WCHAR_MIN \ +# undef WCHAR_MIN +# undef WCHAR_MAX +# define WCHAR_MIN \ _STDINT_MIN (@HAVE_SIGNED_WCHAR_T@, @BITSIZEOF_WCHAR_T@, 0 at WCHAR_T_SUFFIX@) -#define WCHAR_MAX \ +# define WCHAR_MAX \ _STDINT_MAX (@HAVE_SIGNED_WCHAR_T@, @BITSIZEOF_WCHAR_T@, 0 at WCHAR_T_SUFFIX@) /* wint_t limits */ -#undef WINT_MIN -#undef WINT_MAX -#define WINT_MIN \ +# undef WINT_MIN +# undef WINT_MAX +# define WINT_MIN \ _STDINT_MIN (@HAVE_SIGNED_WINT_T@, @BITSIZEOF_WINT_T@, 0 at WINT_T_SUFFIX@) -#define WINT_MAX \ +# define WINT_MAX \ _STDINT_MAX (@HAVE_SIGNED_WINT_T@, @BITSIZEOF_WINT_T@, 0 at WINT_T_SUFFIX@) #endif /* !defined __cplusplus || defined __STDC_LIMIT_MACROS */ @@ -434,58 +444,58 @@ /* Here we assume a standard architecture where the hardware integer types have 8, 16, 32, optionally 64 bits, and int is 32 bits. */ -#undef INT8_C -#undef UINT8_C -#define INT8_C(x) x -#define UINT8_C(x) x - -#undef INT16_C -#undef UINT16_C -#define INT16_C(x) x -#define UINT16_C(x) x - -#undef INT32_C -#undef UINT32_C -#define INT32_C(x) x -#define UINT32_C(x) x ## U - -#undef INT64_C -#undef UINT64_C -#if LONG_MAX >> 31 >> 31 == 1 -# define INT64_C(x) x##L -#elif defined _MSC_VER -# define INT64_C(x) x##i64 -#elif @HAVE_LONG_LONG_INT@ -# define INT64_C(x) x##LL -#endif -#if ULONG_MAX >> 31 >> 31 >> 1 == 1 -# define UINT64_C(x) x##UL -#elif defined _MSC_VER -# define UINT64_C(x) x##ui64 -#elif @HAVE_UNSIGNED_LONG_LONG_INT@ -# define UINT64_C(x) x##ULL -#endif +# undef INT8_C +# undef UINT8_C +# define INT8_C(x) x +# define UINT8_C(x) x + +# undef INT16_C +# undef UINT16_C +# define INT16_C(x) x +# define UINT16_C(x) x + +# undef INT32_C +# undef UINT32_C +# define INT32_C(x) x +# define UINT32_C(x) x ## U + +# undef INT64_C +# undef UINT64_C +# if LONG_MAX >> 31 >> 31 == 1 +# define INT64_C(x) x##L +# elif defined _MSC_VER +# define INT64_C(x) x##i64 +# elif @HAVE_LONG_LONG_INT@ +# define INT64_C(x) x##LL +# endif +# if ULONG_MAX >> 31 >> 31 >> 1 == 1 +# define UINT64_C(x) x##UL +# elif defined _MSC_VER +# define UINT64_C(x) x##ui64 +# elif @HAVE_UNSIGNED_LONG_LONG_INT@ +# define UINT64_C(x) x##ULL +# endif /* 7.18.4.2. Macros for greatest-width integer constants */ -#undef INTMAX_C -#if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1 -# define INTMAX_C(x) x##LL -#elif defined int64_t -# define INTMAX_C(x) INT64_C(x) -#else -# define INTMAX_C(x) x##L -#endif +# undef INTMAX_C +# if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1 +# define INTMAX_C(x) x##LL +# elif defined int64_t +# define INTMAX_C(x) INT64_C(x) +# else +# define INTMAX_C(x) x##L +# endif -#undef UINTMAX_C -#if @HAVE_UNSIGNED_LONG_LONG_INT@ && ULONG_MAX >> 31 == 1 -# define UINTMAX_C(x) x##ULL -#elif defined uint64_t -# define UINTMAX_C(x) UINT64_C(x) -#else -# define UINTMAX_C(x) x##UL -#endif +# undef UINTMAX_C +# if @HAVE_UNSIGNED_LONG_LONG_INT@ && ULONG_MAX >> 31 == 1 +# define UINTMAX_C(x) x##ULL +# elif defined uint64_t +# define UINTMAX_C(x) UINT64_C(x) +# else +# define UINTMAX_C(x) x##UL +# endif +#endif /* !(defined __ANDROID__ && ...) */ #endif /* !defined __cplusplus || defined __STDC_CONSTANT_MACROS */ - #endif /* _GL_STDINT_H */ -- 1.7.7.1 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Fri Jan 27 18:22:29 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 27 Jan 2012 12:22:29 -0500 Subject: porting gnupg to Android, is pth required? In-Reply-To: <87ehulaxzq.fsf@vigenere.g10code.de> References: <4F21B903.5060000@guardianproject.info> <8762fxcvd0.fsf@vigenere.g10code.de> <87ehulaxzq.fsf@vigenere.g10code.de> Message-ID: <4F22DD55.6090607@guardianproject.info> Ok, that worked for me, at least as much as the gnulib update did. I'm now at iconv, so time for another build, and I'll report back. .hc On 01/27/2012 11:52 AM, Werner Koch wrote: > Hi, > > please try this patch to solve the build problems on gnupg. It is > basically the same as used in gnulib. I have not tested it, though. > Eventuelly I need to install the Android toolchain. > > > From bdde44ae8d4709e33c09781c3d37a5da2c7a5e0d Mon Sep 17 00:00:00 2001 > From: Werner Koch > Date: Fri, 27 Jan 2012 17:29:57 +0100 > Subject: [PATCH] gl: Add support for Android to stdint.h replacement. > > * gl/stdint_.h: When included from Bionic , just include > the system's . > --- > gl/stdint_.h | 368 ++++++++++++++++++++++++++++++---------------------------- > 1 files changed, 189 insertions(+), 179 deletions(-) > > diff --git a/gl/stdint_.h b/gl/stdint_.h > index bc27595..19577e7 100644 > --- a/gl/stdint_.h > +++ b/gl/stdint_.h > @@ -23,6 +23,16 @@ > * > */ > > +/* On Android (Bionic libc), includes this file before > + having defined 'time_t'. Therefore in this case avoid including > + other system header files; just include the system's . > + Ideally we should test __BIONIC__ here, but it is only defined after > + has been included; hence test __ANDROID__ instead. */ > +#if defined __ANDROID__ \ > + && defined _SYS_TYPES_H_ && !defined _SSIZE_T_DEFINED_ > +# include_next > +#else > + > /* Get those types that are already defined in other system include > files, so that we can "#define int8_t signed char" below without > worrying about a later system include file containing a "typedef > @@ -243,38 +253,38 @@ > /* Here we assume a standard architecture where the hardware integer > types have 8, 16, 32, optionally 64 bits. */ > > -#undef INT8_MIN > -#undef INT8_MAX > -#undef UINT8_MAX > -#define INT8_MIN (~ INT8_MAX) > -#define INT8_MAX 127 > -#define UINT8_MAX 255 > - > -#undef INT16_MIN > -#undef INT16_MAX > -#undef UINT16_MAX > -#define INT16_MIN (~ INT16_MAX) > -#define INT16_MAX 32767 > -#define UINT16_MAX 65535 > - > -#undef INT32_MIN > -#undef INT32_MAX > -#undef UINT32_MAX > -#define INT32_MIN (~ INT32_MAX) > -#define INT32_MAX 2147483647 > -#define UINT32_MAX 4294967295U > - > -#undef INT64_MIN > -#undef INT64_MAX > -#ifdef int64_t > -# define INT64_MIN (~ INT64_MAX) > -# define INT64_MAX INTMAX_C (9223372036854775807) > -#endif > +# undef INT8_MIN > +# undef INT8_MAX > +# undef UINT8_MAX > +# define INT8_MIN (~ INT8_MAX) > +# define INT8_MAX 127 > +# define UINT8_MAX 255 > + > +# undef INT16_MIN > +# undef INT16_MAX > +# undef UINT16_MAX > +# define INT16_MIN (~ INT16_MAX) > +# define INT16_MAX 32767 > +# define UINT16_MAX 65535 > + > +# undef INT32_MIN > +# undef INT32_MAX > +# undef UINT32_MAX > +# define INT32_MIN (~ INT32_MAX) > +# define INT32_MAX 2147483647 > +# define UINT32_MAX 4294967295U > + > +# undef INT64_MIN > +# undef INT64_MAX > +# ifdef int64_t > +# define INT64_MIN (~ INT64_MAX) > +# define INT64_MAX INTMAX_C (9223372036854775807) > +# endif > > -#undef UINT64_MAX > -#ifdef uint64_t > -# define UINT64_MAX UINTMAX_C (18446744073709551615) > -#endif > +# undef UINT64_MAX > +# ifdef uint64_t > +# define UINT64_MAX UINTMAX_C (18446744073709551615) > +# endif > > /* 7.18.2.2. Limits of minimum-width integer types */ > > @@ -282,38 +292,38 @@ > types have 8, 16, 32, optionally 64 bits. Therefore the leastN_t types > are the same as the corresponding N_t types. */ > > -#undef INT_LEAST8_MIN > -#undef INT_LEAST8_MAX > -#undef UINT_LEAST8_MAX > -#define INT_LEAST8_MIN INT8_MIN > -#define INT_LEAST8_MAX INT8_MAX > -#define UINT_LEAST8_MAX UINT8_MAX > - > -#undef INT_LEAST16_MIN > -#undef INT_LEAST16_MAX > -#undef UINT_LEAST16_MAX > -#define INT_LEAST16_MIN INT16_MIN > -#define INT_LEAST16_MAX INT16_MAX > -#define UINT_LEAST16_MAX UINT16_MAX > - > -#undef INT_LEAST32_MIN > -#undef INT_LEAST32_MAX > -#undef UINT_LEAST32_MAX > -#define INT_LEAST32_MIN INT32_MIN > -#define INT_LEAST32_MAX INT32_MAX > -#define UINT_LEAST32_MAX UINT32_MAX > - > -#undef INT_LEAST64_MIN > -#undef INT_LEAST64_MAX > -#ifdef int64_t > -# define INT_LEAST64_MIN INT64_MIN > -# define INT_LEAST64_MAX INT64_MAX > -#endif > +# undef INT_LEAST8_MIN > +# undef INT_LEAST8_MAX > +# undef UINT_LEAST8_MAX > +# define INT_LEAST8_MIN INT8_MIN > +# define INT_LEAST8_MAX INT8_MAX > +# define UINT_LEAST8_MAX UINT8_MAX > + > +# undef INT_LEAST16_MIN > +# undef INT_LEAST16_MAX > +# undef UINT_LEAST16_MAX > +# define INT_LEAST16_MIN INT16_MIN > +# define INT_LEAST16_MAX INT16_MAX > +# define UINT_LEAST16_MAX UINT16_MAX > + > +# undef INT_LEAST32_MIN > +# undef INT_LEAST32_MAX > +# undef UINT_LEAST32_MAX > +# define INT_LEAST32_MIN INT32_MIN > +# define INT_LEAST32_MAX INT32_MAX > +# define UINT_LEAST32_MAX UINT32_MAX > + > +# undef INT_LEAST64_MIN > +# undef INT_LEAST64_MAX > +# ifdef int64_t > +# define INT_LEAST64_MIN INT64_MIN > +# define INT_LEAST64_MAX INT64_MAX > +# endif > > -#undef UINT_LEAST64_MAX > -#ifdef uint64_t > -# define UINT_LEAST64_MAX UINT64_MAX > -#endif > +# undef UINT_LEAST64_MAX > +# ifdef uint64_t > +# define UINT_LEAST64_MAX UINT64_MAX > +# endif > > /* 7.18.2.3. Limits of fastest minimum-width integer types */ > > @@ -321,105 +331,105 @@ > types have 8, 16, 32, optionally 64 bits. Therefore the fastN_t types > are taken from the same list of types. */ > > -#undef INT_FAST8_MIN > -#undef INT_FAST8_MAX > -#undef UINT_FAST8_MAX > -#define INT_FAST8_MIN LONG_MIN > -#define INT_FAST8_MAX LONG_MAX > -#define UINT_FAST8_MAX ULONG_MAX > - > -#undef INT_FAST16_MIN > -#undef INT_FAST16_MAX > -#undef UINT_FAST16_MAX > -#define INT_FAST16_MIN LONG_MIN > -#define INT_FAST16_MAX LONG_MAX > -#define UINT_FAST16_MAX ULONG_MAX > - > -#undef INT_FAST32_MIN > -#undef INT_FAST32_MAX > -#undef UINT_FAST32_MAX > -#define INT_FAST32_MIN LONG_MIN > -#define INT_FAST32_MAX LONG_MAX > -#define UINT_FAST32_MAX ULONG_MAX > - > -#undef INT_FAST64_MIN > -#undef INT_FAST64_MAX > -#ifdef int64_t > -# define INT_FAST64_MIN INT64_MIN > -# define INT_FAST64_MAX INT64_MAX > -#endif > +# undef INT_FAST8_MIN > +# undef INT_FAST8_MAX > +# undef UINT_FAST8_MAX > +# define INT_FAST8_MIN LONG_MIN > +# define INT_FAST8_MAX LONG_MAX > +# define UINT_FAST8_MAX ULONG_MAX > + > +# undef INT_FAST16_MIN > +# undef INT_FAST16_MAX > +# undef UINT_FAST16_MAX > +# define INT_FAST16_MIN LONG_MIN > +# define INT_FAST16_MAX LONG_MAX > +# define UINT_FAST16_MAX ULONG_MAX > + > +# undef INT_FAST32_MIN > +# undef INT_FAST32_MAX > +# undef UINT_FAST32_MAX > +# define INT_FAST32_MIN LONG_MIN > +# define INT_FAST32_MAX LONG_MAX > +# define UINT_FAST32_MAX ULONG_MAX > + > +# undef INT_FAST64_MIN > +# undef INT_FAST64_MAX > +# ifdef int64_t > +# define INT_FAST64_MIN INT64_MIN > +# define INT_FAST64_MAX INT64_MAX > +# endif > > -#undef UINT_FAST64_MAX > -#ifdef uint64_t > -# define UINT_FAST64_MAX UINT64_MAX > -#endif > +# undef UINT_FAST64_MAX > +# ifdef uint64_t > +# define UINT_FAST64_MAX UINT64_MAX > +# endif > > /* 7.18.2.4. Limits of integer types capable of holding object pointers */ > > -#undef INTPTR_MIN > -#undef INTPTR_MAX > -#undef UINTPTR_MAX > -#define INTPTR_MIN LONG_MIN > -#define INTPTR_MAX LONG_MAX > -#define UINTPTR_MAX ULONG_MAX > +# undef INTPTR_MIN > +# undef INTPTR_MAX > +# undef UINTPTR_MAX > +# define INTPTR_MIN LONG_MIN > +# define INTPTR_MAX LONG_MAX > +# define UINTPTR_MAX ULONG_MAX > > /* 7.18.2.5. Limits of greatest-width integer types */ > > -#undef INTMAX_MIN > -#undef INTMAX_MAX > -#define INTMAX_MIN (~ INTMAX_MAX) > -#ifdef INT64_MAX > -# define INTMAX_MAX INT64_MAX > -#else > -# define INTMAX_MAX INT32_MAX > -#endif > +# undef INTMAX_MIN > +# undef INTMAX_MAX > +# define INTMAX_MIN (~ INTMAX_MAX) > +# ifdef INT64_MAX > +# define INTMAX_MAX INT64_MAX > +# else > +# define INTMAX_MAX INT32_MAX > +# endif > > -#undef UINTMAX_MAX > -#ifdef UINT64_MAX > -# define UINTMAX_MAX UINT64_MAX > -#else > -# define UINTMAX_MAX UINT32_MAX > -#endif > +# undef UINTMAX_MAX > +# ifdef UINT64_MAX > +# define UINTMAX_MAX UINT64_MAX > +# else > +# define UINTMAX_MAX UINT32_MAX > +# endif > > /* 7.18.3. Limits of other integer types */ > > /* ptrdiff_t limits */ > -#undef PTRDIFF_MIN > -#undef PTRDIFF_MAX > -#define PTRDIFF_MIN \ > +# undef PTRDIFF_MIN > +# undef PTRDIFF_MAX > +# define PTRDIFF_MIN \ > _STDINT_MIN (1, @BITSIZEOF_PTRDIFF_T@, 0 at PTRDIFF_T_SUFFIX@) > -#define PTRDIFF_MAX \ > +# define PTRDIFF_MAX \ > _STDINT_MAX (1, @BITSIZEOF_PTRDIFF_T@, 0 at PTRDIFF_T_SUFFIX@) > > /* sig_atomic_t limits */ > -#undef SIG_ATOMIC_MIN > -#undef SIG_ATOMIC_MAX > -#define SIG_ATOMIC_MIN \ > +# undef SIG_ATOMIC_MIN > +# undef SIG_ATOMIC_MAX > +# define SIG_ATOMIC_MIN \ > _STDINT_MIN (@HAVE_SIGNED_SIG_ATOMIC_T@, @BITSIZEOF_SIG_ATOMIC_T@, \ > 0 at SIG_ATOMIC_T_SUFFIX@) > -#define SIG_ATOMIC_MAX \ > +# define SIG_ATOMIC_MAX \ > _STDINT_MAX (@HAVE_SIGNED_SIG_ATOMIC_T@, @BITSIZEOF_SIG_ATOMIC_T@, \ > 0 at SIG_ATOMIC_T_SUFFIX@) > > > /* size_t limit */ > -#undef SIZE_MAX > -#define SIZE_MAX _STDINT_MAX (0, @BITSIZEOF_SIZE_T@, 0 at SIZE_T_SUFFIX@) > +# undef SIZE_MAX > +# define SIZE_MAX _STDINT_MAX (0, @BITSIZEOF_SIZE_T@, 0 at SIZE_T_SUFFIX@) > > /* wchar_t limits */ > -#undef WCHAR_MIN > -#undef WCHAR_MAX > -#define WCHAR_MIN \ > +# undef WCHAR_MIN > +# undef WCHAR_MAX > +# define WCHAR_MIN \ > _STDINT_MIN (@HAVE_SIGNED_WCHAR_T@, @BITSIZEOF_WCHAR_T@, 0 at WCHAR_T_SUFFIX@) > -#define WCHAR_MAX \ > +# define WCHAR_MAX \ > _STDINT_MAX (@HAVE_SIGNED_WCHAR_T@, @BITSIZEOF_WCHAR_T@, 0 at WCHAR_T_SUFFIX@) > > /* wint_t limits */ > -#undef WINT_MIN > -#undef WINT_MAX > -#define WINT_MIN \ > +# undef WINT_MIN > +# undef WINT_MAX > +# define WINT_MIN \ > _STDINT_MIN (@HAVE_SIGNED_WINT_T@, @BITSIZEOF_WINT_T@, 0 at WINT_T_SUFFIX@) > -#define WINT_MAX \ > +# define WINT_MAX \ > _STDINT_MAX (@HAVE_SIGNED_WINT_T@, @BITSIZEOF_WINT_T@, 0 at WINT_T_SUFFIX@) > > #endif /* !defined __cplusplus || defined __STDC_LIMIT_MACROS */ > @@ -434,58 +444,58 @@ > /* Here we assume a standard architecture where the hardware integer > types have 8, 16, 32, optionally 64 bits, and int is 32 bits. */ > > -#undef INT8_C > -#undef UINT8_C > -#define INT8_C(x) x > -#define UINT8_C(x) x > - > -#undef INT16_C > -#undef UINT16_C > -#define INT16_C(x) x > -#define UINT16_C(x) x > - > -#undef INT32_C > -#undef UINT32_C > -#define INT32_C(x) x > -#define UINT32_C(x) x ## U > - > -#undef INT64_C > -#undef UINT64_C > -#if LONG_MAX >> 31 >> 31 == 1 > -# define INT64_C(x) x##L > -#elif defined _MSC_VER > -# define INT64_C(x) x##i64 > -#elif @HAVE_LONG_LONG_INT@ > -# define INT64_C(x) x##LL > -#endif > -#if ULONG_MAX >> 31 >> 31 >> 1 == 1 > -# define UINT64_C(x) x##UL > -#elif defined _MSC_VER > -# define UINT64_C(x) x##ui64 > -#elif @HAVE_UNSIGNED_LONG_LONG_INT@ > -# define UINT64_C(x) x##ULL > -#endif > +# undef INT8_C > +# undef UINT8_C > +# define INT8_C(x) x > +# define UINT8_C(x) x > + > +# undef INT16_C > +# undef UINT16_C > +# define INT16_C(x) x > +# define UINT16_C(x) x > + > +# undef INT32_C > +# undef UINT32_C > +# define INT32_C(x) x > +# define UINT32_C(x) x ## U > + > +# undef INT64_C > +# undef UINT64_C > +# if LONG_MAX >> 31 >> 31 == 1 > +# define INT64_C(x) x##L > +# elif defined _MSC_VER > +# define INT64_C(x) x##i64 > +# elif @HAVE_LONG_LONG_INT@ > +# define INT64_C(x) x##LL > +# endif > +# if ULONG_MAX >> 31 >> 31 >> 1 == 1 > +# define UINT64_C(x) x##UL > +# elif defined _MSC_VER > +# define UINT64_C(x) x##ui64 > +# elif @HAVE_UNSIGNED_LONG_LONG_INT@ > +# define UINT64_C(x) x##ULL > +# endif > > /* 7.18.4.2. Macros for greatest-width integer constants */ > > -#undef INTMAX_C > -#if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1 > -# define INTMAX_C(x) x##LL > -#elif defined int64_t > -# define INTMAX_C(x) INT64_C(x) > -#else > -# define INTMAX_C(x) x##L > -#endif > +# undef INTMAX_C > +# if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1 > +# define INTMAX_C(x) x##LL > +# elif defined int64_t > +# define INTMAX_C(x) INT64_C(x) > +# else > +# define INTMAX_C(x) x##L > +# endif > > -#undef UINTMAX_C > -#if @HAVE_UNSIGNED_LONG_LONG_INT@ && ULONG_MAX >> 31 == 1 > -# define UINTMAX_C(x) x##ULL > -#elif defined uint64_t > -# define UINTMAX_C(x) UINT64_C(x) > -#else > -# define UINTMAX_C(x) x##UL > -#endif > +# undef UINTMAX_C > +# if @HAVE_UNSIGNED_LONG_LONG_INT@ && ULONG_MAX >> 31 == 1 > +# define UINTMAX_C(x) x##ULL > +# elif defined uint64_t > +# define UINTMAX_C(x) UINT64_C(x) > +# else > +# define UINTMAX_C(x) x##UL > +# endif > > +#endif /* !(defined __ANDROID__ && ...) */ > #endif /* !defined __cplusplus || defined __STDC_CONSTANT_MACROS */ > - > #endif /* _GL_STDINT_H */ From hans at guardianproject.info Fri Jan 27 18:26:59 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 27 Jan 2012 12:26:59 -0500 Subject: porting gnupg to Android, is pth required? In-Reply-To: <87ty3hb417.fsf@vigenere.g10code.de> References: <4F21B903.5060000@guardianproject.info> <8762fxcvd0.fsf@vigenere.g10code.de> <87ty3hb417.fsf@vigenere.g10code.de> Message-ID: <4F22DE63.4040301@guardianproject.info> On 01/27/2012 09:42 AM, Werner Koch wrote: > On Fri, 27 Jan 2012 14:55, hans at guardianproject.info said: > >> I got past the stdint.h problem, but am now onto the pthread. I guess > > Please try the latest npth - I changed quite some things in the > configuration. Just tried the latest in master, and there is a new problem. I'm working on this all day today, ping me on jabber or irc://irc.freenode.net/guardianproject (_hc) if you would to work on this or help setting up the Android NDK cross-building environment. Its really straightforward to setup on Debian, Ubuntu, and Mac OS X, especially compared to other cross-compilers I've worked with. Here's the build error: /bin/sh ../libtool --tag=CC --mode=compile /usr/local/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc --sysroot=/usr/local/android-ndk/platforms/android-9/arch-arm -DHAVE_CONFIG_H -I. -I.. -DANDROID -I/media/share/code/guardianproject/gnupg-for-android/external/include -MT npth.lo -MD -MP -MF .deps/npth.Tpo -c -o npth.lo npth.c libtool: compile: /usr/local/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc --sysroot=/usr/local/android-ndk/platforms/android-9/arch-arm -DHAVE_CONFIG_H -I. -I.. -DANDROID -I/media/share/code/guardianproject/gnupg-for-android/external/include -MT npth.lo -MD -MP -MF .deps/npth.Tpo -c npth.c -fPIC -DPIC -o .libs/npth.o In file included from npth.c:40: npth.h:300: error: expected declaration specifiers or '...' before 'fd_set' npth.h:300: error: expected declaration specifiers or '...' before 'fd_set' npth.h:300: error: expected declaration specifiers or '...' before 'fd_set' npth.h:302: error: expected declaration specifiers or '...' before 'fd_set' npth.h:302: error: expected declaration specifiers or '...' before 'fd_set' npth.h:302: error: expected declaration specifiers or '...' before 'fd_set' npth.c:433: error: expected declaration specifiers or '...' before 'fd_set' npth.c:433: error: expected declaration specifiers or '...' before 'fd_set' npth.c:433: error: expected declaration specifiers or '...' before 'fd_set' npth.c: In function 'npth_select': npth.c:439: error: 'rfds' undeclared (first use in this function) npth.c:439: error: (Each undeclared identifier is reported only once npth.c:439: error: for each function it appears in.) npth.c:439: error: 'wfds' undeclared (first use in this function) npth.c:439: error: 'efds' undeclared (first use in this function) npth.c: At top level: npth.c:446: error: expected declaration specifiers or '...' before 'fd_set' npth.c:446: error: expected declaration specifiers or '...' before 'fd_set' npth.c:446: error: expected declaration specifiers or '...' before 'fd_set' npth.c: In function 'npth_pselect': npth.c:452: error: 'rfds' undeclared (first use in this function) npth.c:452: error: 'wfds' undeclared (first use in this function) npth.c:452: error: 'efds' undeclared (first use in this function) make[3]: *** [npth.lo] Error 1 From marcus.brinkmann at ruhr-uni-bochum.de Fri Jan 27 18:51:40 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 27 Jan 2012 18:51:40 +0100 Subject: GnuPG master migrated to nPth In-Reply-To: <4F21AE84.1060006@guardianproject.info> References: <8739b37opr.fsf@vigenere.g10code.de> <8762fy5sfb.fsf@vigenere.g10code.de> <131D4253-7659-4451-A77C-638828D16562@guardianproject.info> <87zkda4cw1.fsf@vigenere.g10code.de> <4F21AE84.1060006@guardianproject.info> Message-ID: <4F22E42C.90501@ruhr-uni-bochum.de> On 01/26/2012 08:50 PM, Hans-Christoph Steiner wrote: > Next, npth's ./configure complains it can't find pthread, I'm looking > into this now. pthread is included in Android's bionic libc, but > someone simplified. It does not have pthread_cancel(), for example: > http://groups.google.com/group/android-platform/browse_thread/thread/0aad393da2da65b1 That's ok. npth only uses and provides a subset, too. In particular, pthread_cancel is not used. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Fri Jan 27 18:59:05 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 27 Jan 2012 18:59:05 +0100 Subject: GnuPG master migrated to nPth In-Reply-To: <4F21B0FB.6010902@guardianproject.info> References: <8739b37opr.fsf@vigenere.g10code.de> <8762fy5sfb.fsf@vigenere.g10code.de> <131D4253-7659-4451-A77C-638828D16562@guardianproject.info> <87zkda4cw1.fsf@vigenere.g10code.de> <4F21AE84.1060006@guardianproject.info> <4F21B0FB.6010902@guardianproject.info> Message-ID: <4F22E5E9.8010208@ruhr-uni-bochum.de> On 01/26/2012 09:00 PM, Hans-Christoph Steiner wrote: > Bionic libc does not seem to have these though: pthread_tryjoin_np > pthread_getname_np but does seem to have pthread_setname_np. So at this > point pth is ported and seems a better option for Android than npth. pth_tryjoin_np is not used by gnupg, only in the npth implementation as a shortcut in case the thread is joinable immediately. This is only an optimization and can be skipped without violating any invariants. getname and setname are only used for debugging and can be stubbed out without any problems. Thanks, Marcus From hans at guardianproject.info Fri Jan 27 23:22:12 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 27 Jan 2012 17:22:12 -0500 Subject: gnupg vs libiconv on Android Message-ID: <4F232394.3000008@guardianproject.info> In the continuing saga of the Android port, I'm now running into libiconv. First I tried without libiconv using --disable-nls, and it still died with iconv errors in common/utf8conv.c. Now I have libiconv-1.14 built and installed for Android, and now it dies looking for ICONV_CONST, which I couldn't find defined anywhere: /usr/local/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc --sysroot=/usr/local/android-ndk/platforms/android-9/arch-arm -DHAVE_CONFIG_H -I. -I.. -I../gl -I../intl -DLOCALEDIR=\"/data/local/share/locale\" -DGNUPG_BINDIR="\"/data/local/bin\"" -DGNUPG_LIBEXECDIR="\"/data/local/libexec\"" -DGNUPG_LIBDIR="\"/data/local/lib/gnupg\"" -DGNUPG_DATADIR="\"/data/local/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/data/local/etc/gnupg\"" -DGNUPG_LOCALSTATEDIR="\"/data/local/var\"" -I/media/share/code/guardianproject/gnupg-for-android/external/data/local/include -I/data/local/include -I/usr/local/include -I/data/local/include -I/usr/local/include -I/media/share/code/guardianproject/gnupg-for-android/external/data/local/include -I/usr/local/include -I/data/local/include -I/usr/local/include -DWITHOUT_GNU_PTH=1 -DANDROID -I/media/share/code/guardianproject/gnupg-for-android/external/data/local/include -O3 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith -MT libcommon_a-utf8conv.o -MD -MP -MF .deps/libcommon_a-utf8conv.Tpo -c -o libcommon_a-utf8conv.o `test -f 'utf8conv.c' || echo './'`utf8conv.c utf8conv.c: In function 'native_to_utf8': utf8conv.c:400: error: 'ICONV_CONST' undeclared (first use in this function) utf8conv.c:400: error: (Each undeclared identifier is reported only once utf8conv.c:400: error: for each function it appears in.) utf8conv.c:400: error: expected ')' before 'char' utf8conv.c: In function 'do_utf8_to_native': utf8conv.c:666: error: 'ICONV_CONST' undeclared (first use in this function) utf8conv.c:666: error: expected ')' before 'char' make[4]: *** [libcommon_a-utf8conv.o] Error 1 make[4]: Leaving directory `/media/share/code/guardianproject/gnupg-for-android/external/gnupg/common' From wk at gnupg.org Sat Jan 28 12:26:21 2012 From: wk at gnupg.org (Werner Koch) Date: Sat, 28 Jan 2012 12:26:21 +0100 Subject: gnupg vs libiconv on Android In-Reply-To: <4F232394.3000008@guardianproject.info> (Hans-Christoph Steiner's message of "Fri, 27 Jan 2012 17:22:12 -0500") References: <4F232394.3000008@guardianproject.info> Message-ID: <87r4yk9ig2.fsf@vigenere.g10code.de> On Fri, 27 Jan 2012 23:22, hans at guardianproject.info said: > libiconv-1.14 built and installed for Android, and now it dies looking > for ICONV_CONST, which I couldn't find defined anywhere: Define it to an empty string like utf8conv.c does for Windows. In fact you can disable the iconv stuff as we do for WindowsCE.. Latin-1 and utf-8 will still work. I guess Android uses utf-8 anyway. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Sat Jan 28 20:11:56 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Sat, 28 Jan 2012 14:11:56 -0500 Subject: gnupg vs libiconv on Android In-Reply-To: <87r4yk9ig2.fsf@vigenere.g10code.de> References: <4F232394.3000008@guardianproject.info> <87r4yk9ig2.fsf@vigenere.g10code.de> Message-ID: <22DB77CD-9C6F-4732-B419-DB4D6165081E@guardianproject.info> On Jan 28, 2012, at 6:26 AM, Werner Koch wrote: > On Fri, 27 Jan 2012 23:22, hans at guardianproject.info said: > >> libiconv-1.14 built and installed for Android, and now it dies looking >> for ICONV_CONST, which I couldn't find defined anywhere: > > Define it to an empty string like utf8conv.c does for Windows. In fact > you can disable the iconv stuff as we do for WindowsCE.. Latin-1 and > utf-8 will still work. I guess Android uses utf-8 anyway. How do I disable iconv? I tried combinations ./configure --disable-nls --without-iconv-prefix and nothing seem to have any effect. .hc ---------------------------------------------------------------------------- Mistrust authority - promote decentralization. - the hacker ethic From christian at quelltextlich.at Sat Jan 28 22:46:47 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Sat, 28 Jan 2012 22:46:47 +0100 Subject: [PATCH] Use preferred hashing algorithm when updating signature packets Message-ID: <20120128214647.GA20683@quelltextlich.at> Hello, when updating a signature packet, GnuPG reuses the hashing algorithm of the original signature packet. Hence, if the preferred hashing algorithm changed since the first signature, the updated signature does not use the currently preferred hashing algorithm. Kind regards, Christian --- g10/sign.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/g10/sign.c b/g10/sign.c index 4cc813c..b7b4c49 100644 --- a/g10/sign.c +++ b/g10/sign.c @@ -1584,7 +1584,7 @@ update_keysig_packet( PKT_signature **ret_sig, || (orig_sig->sig_class == 0x18 && !subpk)) return G10ERR_GENERAL; - if ( gcry_md_open (&md, orig_sig->digest_algo, 0 ) ) + if ( gcry_md_open (&md, hash_for( pksk ), 0 ) ) BUG (); /* Hash the public key certificate and the user id. */ -- 1.7.8.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From dshaw at jabberwocky.com Sun Jan 29 05:43:19 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 28 Jan 2012 23:43:19 -0500 Subject: [PATCH] Use preferred hashing algorithm when updating signature packets In-Reply-To: <20120128214647.GA20683@quelltextlich.at> References: <20120128214647.GA20683@quelltextlich.at> Message-ID: <53CCF2A9-0818-4C07-988C-584E52258713@jabberwocky.com> On Jan 28, 2012, at 4:46 PM, Christian Aistleitner wrote: > Hello, > > when updating a signature packet, GnuPG reuses the hashing algorithm of the > original signature packet. > Hence, if the preferred hashing algorithm changed since the first > signature, the updated signature does not use the currently preferred > hashing algorithm. > > Kind regards, > Christian > > --- > g10/sign.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/g10/sign.c b/g10/sign.c > index 4cc813c..b7b4c49 100644 > --- a/g10/sign.c > +++ b/g10/sign.c > @@ -1584,7 +1584,7 @@ update_keysig_packet( PKT_signature **ret_sig, > || (orig_sig->sig_class == 0x18 && !subpk)) > return G10ERR_GENERAL; > > - if ( gcry_md_open (&md, orig_sig->digest_algo, 0 ) ) > + if ( gcry_md_open (&md, hash_for( pksk ), 0 ) ) This is not quite correct. hash_for() returns the appropriate digest for data, not for certification. If the intent is to have update_keysig_packet() use --cert-digest-algo rather than basing the signature on the existing digest, you want something like this: if ( opt.cert_digest_algo ) digest_algo = opt.cert_digest_algo; else digest_algo = orig_sig->digest_algo; David From dshaw at jabberwocky.com Sun Jan 29 05:57:45 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 28 Jan 2012 23:57:45 -0500 Subject: [PATCH] Use preferred hashing algorithm when updating signature packets In-Reply-To: <53CCF2A9-0818-4C07-988C-584E52258713@jabberwocky.com> References: <20120128214647.GA20683@quelltextlich.at> <53CCF2A9-0818-4C07-988C-584E52258713@jabberwocky.com> Message-ID: <1AB5C858-3FC7-4E27-99A3-43BF37C8706B@jabberwocky.com> On Jan 28, 2012, at 11:43 PM, David Shaw wrote: > On Jan 28, 2012, at 4:46 PM, Christian Aistleitner wrote: > >> Hello, >> >> when updating a signature packet, GnuPG reuses the hashing algorithm of the >> original signature packet. >> Hence, if the preferred hashing algorithm changed since the first >> signature, the updated signature does not use the currently preferred >> hashing algorithm. >> >> Kind regards, >> Christian >> >> --- >> g10/sign.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/g10/sign.c b/g10/sign.c >> index 4cc813c..b7b4c49 100644 >> --- a/g10/sign.c >> +++ b/g10/sign.c >> @@ -1584,7 +1584,7 @@ update_keysig_packet( PKT_signature **ret_sig, >> || (orig_sig->sig_class == 0x18 && !subpk)) >> return G10ERR_GENERAL; >> >> - if ( gcry_md_open (&md, orig_sig->digest_algo, 0 ) ) >> + if ( gcry_md_open (&md, hash_for( pksk ), 0 ) ) > > This is not quite correct. hash_for() returns the appropriate digest for data, not for certification. If the intent is to have update_keysig_packet() use --cert-digest-algo rather than basing the signature on the existing digest, you want something like this: > > if ( opt.cert_digest_algo ) > digest_algo = opt.cert_digest_algo; > else > digest_algo = orig_sig->digest_algo; Although, let me add - I think you're right. The updated certification should use an updated digest, if the user has selected one. It just needs to be the cert-digest-algo, rather than the digest-algo. David From christian at quelltextlich.at Sun Jan 29 11:27:29 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Sun, 29 Jan 2012 11:27:29 +0100 Subject: [PATCH] Use preferred hashing algorithm when updating signature packets In-Reply-To: <53CCF2A9-0818-4C07-988C-584E52258713@jabberwocky.com> References: <20120128214647.GA20683@quelltextlich.at> <53CCF2A9-0818-4C07-988C-584E52258713@jabberwocky.com> Message-ID: <20120129102729.GA6530@quelltextlich.at> Hi David, on Sat, Jan 28, 2012 at 11:43:19PM -0500, David Shaw wrote: > [ hash_for() -> opt.cert_digest_algo ] Of course, you're right. Find the updated patch below. Kind regards, Christian --- g10/sign.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/g10/sign.c b/g10/sign.c index 4cc813c..2728fda 100644 --- a/g10/sign.c +++ b/g10/sign.c @@ -1578,13 +1578,19 @@ update_keysig_packet( PKT_signature **ret_sig, PKT_signature *sig; int rc=0; gcry_md_hd_t md; + int digest_algo; if ((!orig_sig || !pk || !pksk) || (orig_sig->sig_class >= 0x10 && orig_sig->sig_class <= 0x13 && !uid) || (orig_sig->sig_class == 0x18 && !subpk)) return G10ERR_GENERAL; - if ( gcry_md_open (&md, orig_sig->digest_algo, 0 ) ) + if ( opt.cert_digest_algo ) + digest_algo = opt.cert_digest_algo; + else + digest_algo = orig_sig->digest_algo; + + if ( gcry_md_open (&md, digest_algo, 0 ) ) BUG (); /* Hash the public key certificate and the user id. */ -- 1.7.8.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From christian at quelltextlich.at Sun Jan 29 14:53:24 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Sun, 29 Jan 2012 14:53:24 +0100 Subject: [PATCH] Updating gitignore Message-ID: <20120129135324.GA25191@quelltextlich.at> Hello, common/t-dns-cert, and common/t-openpgp-oid are generated by make, but not listed in .gitignore. The below patch adds them. Kind regards, Christian --- .gitignore | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index d5ccfa0..1b5e2ce 100644 --- a/.gitignore +++ b/.gitignore @@ -37,9 +37,11 @@ common/libgpgrl.a common/libsimple-pwquery.a common/t-b64 common/t-convert +common/t-dns-cert common/t-exechelp common/t-gettime common/t-helpfile +common/t-openpgp-oid common/t-percent common/t-session-env common/t-sexputil -- 1.7.8.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From christian at quelltextlich.at Sun Jan 29 16:23:11 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Sun, 29 Jan 2012 16:23:11 +0100 Subject: [PATCH] Allow printing key digests in key edit Message-ID: <20120129152311.GA28756@quelltextlich.at> Hello, Although SHA1 is considered to be broken by some, key-signing parties typically still rely on asserting validity of keys by comparing their fingerprints. The main obstacle being that programs as GnuPG do not provide an easy access to a more secure digest of a key. The patch added below, adds a "digest" command in the --edit-keys menu, that allows to compute further digests of keys. By getting easy access to SHA2 digests of their keys, participants of key-signing parties can assert validity of keys by comparing SHA2 digests, and can finally (manually) check whether a key obtained from a keyserver matches the SHA2 digests compared at the party. Kind regards, Christian P.S.: Of course, this does not address the problems arising from the use of SHA1 in OpenPGP, or from (key) signatures made with SHA1. This patch just gives more options to the GnuPG user. --- g10/keyedit.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 70 insertions(+), 1 deletions(-) diff --git a/g10/keyedit.c b/g10/keyedit.c index 26e05a0..d78c761 100644 --- a/g10/keyedit.c +++ b/g10/keyedit.c @@ -56,6 +56,8 @@ static void show_key_with_all_names (KBNODE keyblock, int only_marked, int with_revoker, int with_fpr, int with_subkeys, int with_prefs); static void show_key_and_fingerprint (KBNODE keyblock); +static void show_digest (KBNODE keyblock, int digest_algo); +static int menu_digest (void); static int menu_adduid (KBNODE keyblock, int photo, const char *photo_name); static void menu_deluid (KBNODE pub_keyblock); static int menu_delsig (KBNODE pub_keyblock); @@ -1308,7 +1310,7 @@ enum cmdids cmdEXPIRE, cmdBACKSIGN, cmdENABLEKEY, cmdDISABLEKEY, cmdSHOWPREF, cmdSETPREF, cmdPREFKS, cmdNOTATION, cmdINVCMD, cmdSHOWPHOTO, cmdUPDTRUST, cmdCHKTRUST, cmdADDCARDKEY, cmdKEYTOCARD, cmdBKUPTOCARD, cmdCHECKBKUPKEY, - cmdCLEAN, cmdMINIMIZE, cmdNOP + cmdCLEAN, cmdMINIMIZE, cmdDIGEST, cmdNOP }; static struct @@ -1399,6 +1401,7 @@ static struct N_("compact unusable user IDs and remove unusable signatures from key")}, { "minimize", cmdMINIMIZE, KEYEDIT_NOT_SK, N_("compact unusable user IDs and remove all signatures from key")}, + { "digest", cmdDIGEST, 0, N_("compute a digest for the key")}, { NULL, cmdNONE, 0, NULL} }; @@ -1649,6 +1652,10 @@ keyedit_menu (ctrl_t ctrl, const char *username, strlist_t locusr, show_key_and_fingerprint (keyblock); break; + case cmdDIGEST: + show_digest( keyblock, menu_digest() ); + break; + case cmdSELUID: if (strlen (arg_string) == NAMEHASH_LEN * 2) redisplay = menu_select_uid_namehash (keyblock, arg_string); @@ -2938,6 +2945,68 @@ show_key_and_fingerprint (KBNODE keyblock) print_fingerprint (pk, 2); } +// Prints a digest of the public key in keyblock +// using the digest_algo digest algorithm +static void +show_digest (KBNODE keyblock, int digest_algo) +{ + PKT_public_key *pk = NULL; + gcry_md_hd_t md; + const byte *dp; + int len; + int i; + + assert (keyblock->pkt->pkttype == PKT_PUBLIC_KEY); + pk = keyblock->pkt->pkt.public_key; + + tty_printf ("\n"); + + if (gcry_md_open (&md, digest_algo, 0)) + BUG (); + hash_public_key(md,pk); + gcry_md_final( md ); + + dp = gcry_md_read( md, 0 ); + len = gcry_md_get_algo_dlen (gcry_md_get_algo (md)); + assert( len >=0 ); + tty_printf(" %s digest of key = ", gcry_md_algo_name( digest_algo ) ); + for ( i=0; i < len ; i++ ) + tty_printf("%s%s%s%02X", + (i&15)?"":"\n ", + (i&7)?"":" ", + (i&1)?"":" ", + dp[i] ); + gcry_md_close( md ); + + tty_printf ("\n"); +} + +static int +menu_digest ( void ) +{ + int i; + char *answer; + int digest_algo = 0; + + // Showing the possible digests + tty_printf (_("Please select what kind of digest you want:\n")); + for(i=0; i <= 110; i++ ) + if( !openpgp_md_test_algo(i) ) + { + tty_printf( " (%d) %s\n", i, gcry_md_algo_name(i)); + } + + // User selects digest + while ( openpgp_md_test_algo( digest_algo ) ) + { + answer = cpr_get( "keyedit.print_digest", _("Your selection? ") ); + cpr_kill_prompt (); + digest_algo = *answer? atoi (answer) : DIGEST_ALGO_SHA512; + } + + return digest_algo; +} + /* Show a warning if no uids on the key have the primary uid flag set. */ -- 1.7.8.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From wk at gnupg.org Mon Jan 30 09:25:48 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 30 Jan 2012 09:25:48 +0100 Subject: gnupg vs libiconv on Android In-Reply-To: <22DB77CD-9C6F-4732-B419-DB4D6165081E@guardianproject.info> (Hans-Christoph Steiner's message of "Sat, 28 Jan 2012 14:11:56 -0500") References: <4F232394.3000008@guardianproject.info> <87r4yk9ig2.fsf@vigenere.g10code.de> <22DB77CD-9C6F-4732-B419-DB4D6165081E@guardianproject.info> Message-ID: <87ipjta96b.fsf@vigenere.g10code.de> On Sat, 28 Jan 2012 20:11, hans at guardianproject.info said: > How do I disable iconv? I tried combinations ./configure --disable-nls --without-iconv-prefix and nothing seem to have any effect. You need to do it in the source gnupg/common/utf8conv.c - checkout how it has been downe for W32CE. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jan 30 09:32:58 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 30 Jan 2012 09:32:58 +0100 Subject: [PATCH] Allow printing key digests in key edit In-Reply-To: <20120129152311.GA28756@quelltextlich.at> (Christian Aistleitner's message of "Sun, 29 Jan 2012 16:23:11 +0100") References: <20120129152311.GA28756@quelltextlich.at> Message-ID: <87ehuha8ud.fsf@vigenere.g10code.de> On Sun, 29 Jan 2012 16:23, christian at quelltextlich.at said: > Although SHA1 is considered to be broken by some, key-signing parties That is plain nonsense. It is not yet possible to compute collisions, let a anone a second preimage. > The patch added below, adds a "digest" command in the --edit-keys menu, that allows to compute further digests of keys. These are not defined by OpenPGP and thus I strongly advise against its use. SHA-1 is an integral part of OpenPGP; it doesn't help if you come up with a different way of computing a fingerprint. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From christian at quelltextlich.at Mon Jan 30 14:36:20 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Mon, 30 Jan 2012 14:36:20 +0100 Subject: [PATCH] Allow printing key digests in key edit In-Reply-To: <87ehuha8ud.fsf@vigenere.g10code.de> References: <20120129152311.GA28756@quelltextlich.at> <87ehuha8ud.fsf@vigenere.g10code.de> Message-ID: <20120130133620.GA5541@quelltextlich.at> Hello Werner, on Mon, Jan 30, 2012 at 09:32:58AM +0100, Werner Koch wrote: > On Sun, 29 Jan 2012 16:23, christian at quelltextlich.at said: > > > Although SHA1 is considered to be broken by some, [...] > > That is plain nonsense. I suppose we all agree that among those who claim such "nonsense" are for example renowned cryptographer Bruce Schneier [1]. For whatever reason places like Apache.org also follow this nonsense [2]. Be things as they may, I haven't seen SHA-1 collisions growing on trees since 2005 either :) > > The patch added below, adds a "digest" command in the --edit-keys > > menu, that allows to compute further digests of keys. > > These are not defined by OpenPGP and thus I strongly advise against its > use. SHA-1 is an integral part of OpenPGP; it doesn't help if you come > up with a different way of computing a fingerprint. As written in the PS of my previous post [3], this patch is not to mangle with OpenPGP business. It is not an attempt to replace the OpenPGP fingerprint. It does not even touch any OpenPGP stuff within GnuPG. It's solely about letting GnuPG (not general OpenPGP) users experiment. Let the GnuPG users see, what the SHA2 digests look like. Let them see how it feels to be "identified" by more bits. This might help finding answers to questions like: - Is it feasable to ask people to check printouts of SHA2 digests before coming to key-signing parties? - Is it feasable to hold key-signing parties where SHA2 digests are compared live? - Do people revolt against manually checking longer digests? It is not about mangling with OpenPGP. OpenPGP and the patch do not interfere. It is about freedom; giving people access to further digests. Letting people experiment. Kind regards, Christian [1] http://www.schneier.com/blog/archives/2005/02/sha1_broken.html [2] http://www.apache.org/dev/openpgp.html#sha1 [3] Which you edited away for whatever reason. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From wk at gnupg.org Mon Jan 30 15:44:08 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 30 Jan 2012 15:44:08 +0100 Subject: [PATCH] Allow printing key digests in key edit In-Reply-To: <20120130133620.GA5541@quelltextlich.at> (Christian Aistleitner's message of "Mon, 30 Jan 2012 14:36:20 +0100") References: <20120129152311.GA28756@quelltextlich.at> <87ehuha8ud.fsf@vigenere.g10code.de> <20120130133620.GA5541@quelltextlich.at> Message-ID: <87vcnt8d3b.fsf@vigenere.g10code.de> On Mon, 30 Jan 2012 14:36, christian at quelltextlich.at said: > I suppose we all agree that among those who claim such "nonsense" are > for example renowned cryptographer Bruce Schneier [1]. For whatever You need to understand what crypto analysts understand under "broken": It does not match the original design goals anymore. However, all algorithms have a high security margin which allows them to be used after that break. Even the for many common usages actually broken MD5, still holds strong when used as the digest in a HMAC. For SHA-1 we even don't known how to compute a collision. > Be things as they may, I haven't seen SHA-1 collisions growing on > trees since 2005 either :) In the case of a fingerprint we don't care too much about collision resistance but about preimage attacks. Consider if someone is able to create two keys with the same fingerprint. You don't need to care because you sign his key+user_id. The fingerprint doesn't matter anymore after you signed it. Only with a preimage attack a third person would be able to create a key to impersonate the first one. In any case the crypto community is well aware that algorithms wear out that we need to prepare the migration to newer algorithms. This is the hard job of protocol designing and product deployment. > with OpenPGP business. It is not an attempt to replace the OpenPGP > fingerprint. It does not even touch any OpenPGP stuff within GnuPG. > It's solely about letting GnuPG (not general OpenPGP) users experiment. New features will be used and may later force the protocol designers to take a path they would haven't used if not many users had set a de-facto standard. Fortunately the OpenPGP fingerprint is well defined and we want to keep it this way and don't fall back to a de-facto method on how to compute a fingerprint on an X.509 certificate. > - Is it feasable to ask people to check printouts of SHA2 digests before > coming to key-signing parties? No. [ And you should not use the key checking method you have in mind. Exchanging paper slips is the only solid way to run a key signing party. I am really sorry, that we came up with that crypto-cool key signing scheme back at the Utrecht keyserver admins back in 2000. It does not work in practice. ] > - Is it feasable to hold key-signing parties where SHA2 digests are > compared live? No. > - Do people revolt against manually checking longer digests? No. Because may of them check only the begin and end of the fingerprint - if at all. > It is about freedom; giving people access to further digests. > Letting people experiment. You are about to weaken a good protocol to drive it into the X.509 mess. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rjh at sixdemonbag.org Mon Jan 30 15:52:31 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 30 Jan 2012 09:52:31 -0500 Subject: [PATCH] Allow printing key digests in key edit In-Reply-To: <20120130133620.GA5541@quelltextlich.at> References: <20120129152311.GA28756@quelltextlich.at> <87ehuha8ud.fsf@vigenere.g10code.de> <20120130133620.GA5541@quelltextlich.at> Message-ID: <4F26AEAF.2070707@sixdemonbag.org> On 1/30/12 8:36 AM, Christian Aistleitner wrote: > I suppose we all agree that among those who claim such "nonsense" > are for example renowned cryptographer Bruce Schneier [1]. For > whatever reason places like Apache.org also follow this nonsense > [2]. A guy I know is fond of saying that God may know absolute truth, but for us mortals every truth has a context. Schneier is a cryptographer. When he says something is broken, he means in a cryptographer's sense: that it substantially fails to meet its original design criteria. But to say that SHA-1 is "broken," full stop, presents its brokenness as an absolute fact, when the truth is it just ain't. I know a ton of people who are still using MD5 as a collision-resistant hash. This gives some people the heebie-jeebies, but the people who are doing this include some of the smartest people I've ever known, and they have good reasons for doing it. > It's solely about letting GnuPG (not general OpenPGP) users > experiment. Then post your code as a diff against a 2.0.x tree and let interested users apply the patch themselves. Why should an experimental, let's-play-around feature be introduced into the trunk of GnuPG and have *all* of GnuPG's users be exposed to it? > This might help finding answers to questions like: It might. It's a good idea. It's just not (IMO) a good idea to include it in GnuPG-trunk. From dshaw at jabberwocky.com Mon Jan 30 16:10:14 2012 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 30 Jan 2012 10:10:14 -0500 Subject: [PATCH] Allow printing key digests in key edit In-Reply-To: <20120130133620.GA5541@quelltextlich.at> References: <20120129152311.GA28756@quelltextlich.at> <87ehuha8ud.fsf@vigenere.g10code.de> <20120130133620.GA5541@quelltextlich.at> Message-ID: <6333162A-A988-4422-BF5F-55959589894E@jabberwocky.com> On Jan 30, 2012, at 8:36 AM, Christian Aistleitner wrote: >> These are not defined by OpenPGP and thus I strongly advise against its >> use. SHA-1 is an integral part of OpenPGP; it doesn't help if you come >> up with a different way of computing a fingerprint. > > As written in the PS of my previous post [3], this patch is not to mangle > with OpenPGP business. It is not an attempt to replace the OpenPGP > fingerprint. It does not even touch any OpenPGP stuff within GnuPG. > It's solely about letting GnuPG (not general OpenPGP) users experiment. Experimentation is fine, but it is inappropriate to experiment in ways that affect core pieces of interoperability. This would make GnuPG users essentially have two types of fingerprint - the standard OpenPGP one, and the new GnuPG-specific longer hash one. When signing keys with people using other implementations (PGP being the big one here), we don't need the confusion of multiple strings to compare, only some of which are useful for a given implementation. There will, no doubt, be a new fingerprint standard arriving someday. It probably won't be soon, but when it does, it will be something decided on by the OpenPGP WG after discussion and input. It's been discussed there before, and it's not a trivial task. I don't mean that nobody should experiment, of course, but I do think that including such an experiment as a standard feature in GnuPG pushes it away from a mere experiment. David From wk at gnupg.org Mon Jan 30 17:36:52 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 30 Jan 2012 17:36:52 +0100 Subject: [Announce] GnuPG 1.4.12 released Message-ID: <87mx9587vf.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-1 release: Version 1.4.12. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility, smartcard support and is compliant with the OpenPGP Internet standard as described by RFC-4880. Note that this version is from the GnuPG-1 series and thus smaller than those from the GnuPG-2 series, easier to build and also better portable to ancient platforms. In contrast to GnuPG-2 (e.g version 2.0.18) it comes with no support for S/MIME, Secure Shell, or other tools useful for desktop environments. Fortunately you may install both versions alongside on the same system without any conflict. What's New =========== * GPG now accepts a space separated fingerprint as a user ID. This allows to copy and paste the fingerprint from the key listing. * Removed support for the original HKP keyserver which is not anymore used by any site. * Rebuild the trustdb after changing the option --min-cert-level. * Improved JPEG detection. * Included more VMS patches * Made it easier to create an installer for Windows. * Supports the 32 bit variant of the mingw-w64 toolchain. * Made file locking more portable. * Minor bug fixes. * Ukrainian translation. Getting the Software ==================== First of all, decide whether you really need GnuPG version 1.4.x - most users are better off with the modern GnuPG 2.0.x version. Thene follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 1.4.12 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the following files in the *gnupg* directory: gnupg-1.4.12.tar.bz2 (3500k) gnupg-1.4.12.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.4.12.tar.gz (4823k) gnupg-1.4.12.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.4.11-1.4.12.diff.bz2 (574k) A patch file to upgrade a 1.4.11 GnuPG source tree. This patch does not include updates of the language files. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. In the *binary* directory, you should find these files: gnupg-w32cli-1.4.12.exe (1557k) gnupg-w32cli-1.4.12.exe.sig GnuPG compiled for Microsoft Windows and OpenPGP signature. This is a command line only version; the source files are the same as given above. Note, that this is a minimal installer and unless you are just in need for the gpg binary, you are better off using the full featured installer at http://www.gpg4win.org . Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.4.12.tar.bz2 you would use this command: gpg --verify gnupg-1.4.12.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com | gpg --import or using a keyserver like gpg --recv-key 4F25E3B6 The distribution key 1CE0C630 is signed by the well known keys 1E42B367. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-1.4.12.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-1.4.12.tar.bz2 and check that the output matches the first line from the following list: 9b78e20328d35525af7b8a9c1cf081396910e937 gnupg-1.4.12.tar.bz2 790587e440ec7d429b120db7a96a237badc638fd gnupg-1.4.12.tar.gz 5ce9105ce6b6c9c38638eead87658f4b735a4a68 gnupg-1.4.11-1.4.12.diff.bz2 e7d8e48900d35fe407a8d8308b3a02b8de46b2f2 gnupg-w32cli-1.4.12.exe Internationalization ==================== GnuPG comes with support for 29 languages. Due to a lot of new and changed strings some translations are not entirely complete. The Chinese (Simple and Traditional), Czech, Dutch, French, German, Norwegian, Polish, Romanian, Russian, Spanish, Swedish, Ukrainian and Turkish translations are close to be complete. Support ======= A listing with commercial support offers for GnuPG is available at: http://www.gnupg.org/service.html Improving and maintaining GnuPG is costly, but you can help! g10 Code GmbH (http://g10code.com), a Duesseldorf based company owned and headed by GnuPG's principal author, has been funding GnuPG development for more than 10 years now. They are looking for organizations that find GnuPG useful and wish to contribute back by ordering extensions, sign into a support contract, or employ them for other development projects. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, donating money, spreading the word, or answering questions on the mailing lists. Happy Hacking, The GnuPG Team (David, Werner and the other contributors) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 207 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 rjh at sixdemonbag.org Mon Jan 30 18:33:08 2012 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 30 Jan 2012 12:33:08 -0500 Subject: [PATCH] Allow printing key digests in key edit In-Reply-To: <87vcnt8d3b.fsf@vigenere.g10code.de> References: <20120129152311.GA28756@quelltextlich.at> <87ehuha8ud.fsf@vigenere.g10code.de> <20120130133620.GA5541@quelltextlich.at> <87vcnt8d3b.fsf@vigenere.g10code.de> Message-ID: <4F26D454.1050401@sixdemonbag.org> On 1/30/12 9:44 AM, Werner Koch wrote: > Even the for many common usages actually broken MD5, still holds strong > when used as the digest in a HMAC. For SHA-1 we even don't known how to > compute a collision. It's also worth noting that "actually broken" might not mean broken at all. In the United States, MD5 has been used in literally thousands of court cases. Programs like md5sum and m5deep have been examined by state and federal courts time and again, and have been judged to meet the courts' standards for the admission of scientific evidence. Nowadays if you want to introduce an MD5 checksum of a file as proof that the file hasn't changed, the courts will accept that. SHA-1 has less support from the courts. You probably won't get your evidence thrown out for lack of proper process, but why take the risk when MD5 can be used instead? The SHA-2 family are almost unknown in the courts. If you're the first person presenting a SHA512 or a WHIRLPOOL hash in a courtroom, suddenly you're going to have a rough time of things as you repeat all the challenges that MD5 went through when it first came out. I know a few forensic investigators who use both SHA256 and MD5 in their professional work. When they inventory a file system they compute and store both sets of hashes. They might use SHA256 themselves, but when it comes time to testify in court they present the MD5s. If and when courts decide MD5 no longer is credible they'll have SHA256es to fall back upon, but for now they play the game according to the rules the courts have set up: and according to them, MD5 hasn't been broken. From hans at guardianproject.info Tue Jan 31 04:47:21 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 30 Jan 2012 22:47:21 -0500 Subject: gnupg vs libiconv on Android In-Reply-To: <87ipjta96b.fsf@vigenere.g10code.de> References: <4F232394.3000008@guardianproject.info> <87r4yk9ig2.fsf@vigenere.g10code.de> <22DB77CD-9C6F-4732-B419-DB4D6165081E@guardianproject.info> <87ipjta96b.fsf@vigenere.g10code.de> Message-ID: <4F276449.3030004@guardianproject.info> On 01/30/2012 03:25 AM, Werner Koch wrote: > On Sat, 28 Jan 2012 20:11, hans at guardianproject.info said: > >> How do I disable iconv? I tried combinations ./configure --disable-nls --without-iconv-prefix and nothing seem to have any effect. > > You need to do it in the source gnupg/common/utf8conv.c - checkout how > it has been downe for W32CE. Ok, we have a build, I'm in the process of testing it now. I attached my rough patch that got it building, in case you want to know what needs changing. Not too much, basically I had to add stuff in configure.ac and Makefile.am so the tests are not run on either Win32 or Android (it builds for arm..., so can't run it on most build machines). Then I had to do something similar to W32CE in common/utf8conv.c. I got the adns lib built for Android, but gnupg does not build when I enable adns. Is adns useful? .hc -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-android-fixes.patch Type: text/x-patch Size: 4989 bytes Desc: not available URL: From hans at guardianproject.info Tue Jan 31 15:24:50 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 31 Jan 2012 09:24:50 -0500 Subject: --recv-keys without dirmngr? Message-ID: <4F27F9B2.6040103@guardianproject.info> Is it possible to have a working --recv-keys without using dirmngr? I ask because I got gpg2, dirmngr, and dirmngr-client built and executing on Android. But it seems that gpg2+dirmngr need things like a socket in /var/run, etc. which could be tricky to manage in Android apps. .hc From wk at gnupg.org Tue Jan 31 16:05:07 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 31 Jan 2012 16:05:07 +0100 Subject: gnupg vs libiconv on Android In-Reply-To: <4F276449.3030004@guardianproject.info> (Hans-Christoph Steiner's message of "Mon, 30 Jan 2012 22:47:21 -0500") References: <4F232394.3000008@guardianproject.info> <87r4yk9ig2.fsf@vigenere.g10code.de> <22DB77CD-9C6F-4732-B419-DB4D6165081E@guardianproject.info> <87ipjta96b.fsf@vigenere.g10code.de> <4F276449.3030004@guardianproject.info> Message-ID: <878vkn52vw.fsf@vigenere.g10code.de> On Tue, 31 Jan 2012 04:47, hans at guardianproject.info said: > builds for arm..., so can't run it on most build machines). Then I had > to do something similar to W32CE in common/utf8conv.c. We need a better solution than this. But for now it should be okay. > I got the adns lib built for Android, but gnupg does not build when I > enable adns. Is adns useful? ADNS is fast and flexible. It used for two reasons: On Windows it is easier to use ADNS than the native Windows Resolver API. For the KDNS keyserver helper we need a way to specify a namesever; the ADNS API allows this. GnuPG on Unix works without. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Jan 31 16:07:25 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 31 Jan 2012 16:07:25 +0100 Subject: --recv-keys without dirmngr? In-Reply-To: <4F27F9B2.6040103@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 31 Jan 2012 09:24:50 -0500") References: <4F27F9B2.6040103@guardianproject.info> Message-ID: <874nvb52s2.fsf@vigenere.g10code.de> On Tue, 31 Jan 2012 15:24, hans at guardianproject.info said: > Is it possible to have a working --recv-keys without using dirmngr? I No. > ask because I got gpg2, dirmngr, and dirmngr-client built and executing > on Android. But it seems that gpg2+dirmngr need things like a socket in > /var/run, etc. which could be tricky to manage in Android apps. We have been able to port it to WindowsCE thus we can also port it to crippled Posix systems. IIRC, the problem with dirmngr is an LDAP configure problem. I have the same on kfreebsd - thus it should not take to long to fix it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Tue Jan 31 17:41:50 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 31 Jan 2012 11:41:50 -0500 Subject: gnupg vs libiconv on Android In-Reply-To: <878vkn52vw.fsf@vigenere.g10code.de> References: <4F232394.3000008@guardianproject.info> <87r4yk9ig2.fsf@vigenere.g10code.de> <22DB77CD-9C6F-4732-B419-DB4D6165081E@guardianproject.info> <87ipjta96b.fsf@vigenere.g10code.de> <4F276449.3030004@guardianproject.info> <878vkn52vw.fsf@vigenere.g10code.de> Message-ID: <4F2819CE.5090707@guardianproject.info> On 01/31/2012 10:05 AM, Werner Koch wrote: > On Tue, 31 Jan 2012 04:47, hans at guardianproject.info said: > >> builds for arm..., so can't run it on most build machines). Then I had >> to do something similar to W32CE in common/utf8conv.c. > > We need a better solution than this. But for now it should be okay. >> I got the adns lib built for Android, but gnupg does not build when I >> enable adns. Is adns useful? > > ADNS is fast and flexible. It used for two reasons: On Windows it is > easier to use ADNS than the native Windows Resolver API. For the KDNS > keyserver helper we need a way to specify a namesever; the ADNS API > allows this. > > GnuPG on Unix works without. I don't think we'll need iconv on Android, and we want to keep things as small as possible, so stripping out non-essential libraries is a good way to do that. So I think we'll do without adns for now too. About a better solution for utf8conv.c, can you expand on that? Do you just mean a cleaned up version of that technique, which is the same as the W32CE, or another technique? .hc From wk at gnupg.org Tue Jan 31 17:57:06 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 31 Jan 2012 17:57:06 +0100 Subject: gnupg vs libiconv on Android In-Reply-To: <4F2819CE.5090707@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 31 Jan 2012 11:41:50 -0500") References: <4F232394.3000008@guardianproject.info> <87r4yk9ig2.fsf@vigenere.g10code.de> <22DB77CD-9C6F-4732-B419-DB4D6165081E@guardianproject.info> <87ipjta96b.fsf@vigenere.g10code.de> <4F276449.3030004@guardianproject.info> <878vkn52vw.fsf@vigenere.g10code.de> <4F2819CE.5090707@guardianproject.info> Message-ID: <87lion3j4t.fsf@vigenere.g10code.de> On Tue, 31 Jan 2012 17:41, hans at guardianproject.info said: > About a better solution for utf8conv.c, can you expand on that? Do you > just mean a cleaned up version of that technique, which is the same as > the W32CE, or another technique? What is the standard charset on Android devices? If it is utf-8 it will be easy. We would either introduce a test for iconv or provide a configure options to disable its use. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Tue Jan 31 18:07:27 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 31 Jan 2012 12:07:27 -0500 Subject: gnupg vs libiconv on Android In-Reply-To: <87lion3j4t.fsf@vigenere.g10code.de> References: <4F232394.3000008@guardianproject.info> <87r4yk9ig2.fsf@vigenere.g10code.de> <22DB77CD-9C6F-4732-B419-DB4D6165081E@guardianproject.info> <87ipjta96b.fsf@vigenere.g10code.de> <4F276449.3030004@guardianproject.info> <878vkn52vw.fsf@vigenere.g10code.de> <4F2819CE.5090707@guardianproject.info> <87lion3j4t.fsf@vigenere.g10code.de> Message-ID: <4F281FCF.6090501@guardianproject.info> On 01/31/2012 11:57 AM, Werner Koch wrote: > On Tue, 31 Jan 2012 17:41, hans at guardianproject.info said: > >> About a better solution for utf8conv.c, can you expand on that? Do you >> just mean a cleaned up version of that technique, which is the same as >> the W32CE, or another technique? > > What is the standard charset on Android devices? > > If it is utf-8 it will be easy. We would either introduce a test for > iconv or provide a configure options to disable its use. At least in Java, "The platform's default charset is UTF-8" http://developer.android.com/reference/java/nio/charset/Charset.html If we need character conversion, we can do it in Java, since there is full charset handling in Java on Android. .hc From hans at guardianproject.info Tue Jan 31 18:14:44 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 31 Jan 2012 12:14:44 -0500 Subject: gnupg vs libiconv on Android In-Reply-To: <4F281FCF.6090501@guardianproject.info> References: <4F232394.3000008@guardianproject.info> <87r4yk9ig2.fsf@vigenere.g10code.de> <22DB77CD-9C6F-4732-B419-DB4D6165081E@guardianproject.info> <87ipjta96b.fsf@vigenere.g10code.de> <4F276449.3030004@guardianproject.info> <878vkn52vw.fsf@vigenere.g10code.de> <4F2819CE.5090707@guardianproject.info> <87lion3j4t.fsf@vigenere.g10code.de> <4F281FCF.6090501@guardianproject.info> Message-ID: <4F282184.8090903@guardianproject.info> On 01/31/2012 12:07 PM, Hans-Christoph Steiner wrote: > On 01/31/2012 11:57 AM, Werner Koch wrote: >> On Tue, 31 Jan 2012 17:41, hans at guardianproject.info said: >> >>> About a better solution for utf8conv.c, can you expand on that? Do you >>> just mean a cleaned up version of that technique, which is the same as >>> the W32CE, or another technique? >> >> What is the standard charset on Android devices? >> >> If it is utf-8 it will be easy. We would either introduce a test for >> iconv or provide a configure options to disable its use. > > At least in Java, "The platform's default charset is UTF-8" > http://developer.android.com/reference/java/nio/charset/Charset.html > > If we need character conversion, we can do it in Java, since there is > full charset handling in Java on Android. Oops, I forgot to add, I think that a test for iconv will work well if its done via the compiler. Currently the Android build sets gcc's --sysroot, and that then includes the Android cross-compiler's usr/include, which has no iconv. Or is there an easy way to set sysroot for ./configure? ./configure --disable-iconv is easy enough to use as well. .hc From christian at quelltextlich.at Tue Jan 31 21:02:11 2012 From: christian at quelltextlich.at (Christian Aistleitner) Date: Tue, 31 Jan 2012 21:02:11 +0100 Subject: [PATCH] Allow printing key digests in key edit In-Reply-To: <4F26AEAF.2070707@sixdemonbag.org> References: <20120129152311.GA28756@quelltextlich.at> <87ehuha8ud.fsf@vigenere.g10code.de> <20120130133620.GA5541@quelltextlich.at> <4F26AEAF.2070707@sixdemonbag.org> Message-ID: <20120131200211.GA668@quelltextlich.at> Hello, on Mon, Jan 30, 2012 at 09:52:31AM -0500, Robert J. Hansen wrote: > Then post your code as a diff against a 2.0.x tree and let interested > users apply the patch themselves. So be it :) Those interested in trying out / toying around with digests in the 2.0 series find a patch against the current STABLE-BRANCH-2-0 attached below. Kind regards, Christian --- g10/keyedit.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 70 insertions(+), 1 deletions(-) diff --git a/g10/keyedit.c b/g10/keyedit.c index 76830f0..a9c358e 100644 --- a/g10/keyedit.c +++ b/g10/keyedit.c @@ -52,6 +52,8 @@ static void show_names(KBNODE keyblock,PKT_public_key *pk, static void show_key_with_all_names( KBNODE keyblock, int only_marked, int with_revoker, int with_fpr, int with_subkeys, int with_prefs ); static void show_key_and_fingerprint( KBNODE keyblock ); +static void show_digest (KBNODE keyblock, int digest_algo); +static int menu_digest (void); static int menu_adduid( KBNODE keyblock, KBNODE sec_keyblock, int photo, const char *photo_name ); static void menu_deluid( KBNODE pub_keyblock, KBNODE sec_keyblock ); @@ -1368,7 +1370,7 @@ enum cmdids cmdEXPIRE, cmdBACKSIGN, cmdENABLEKEY, cmdDISABLEKEY, cmdSHOWPREF, cmdSETPREF, cmdPREFKS, cmdNOTATION, cmdINVCMD, cmdSHOWPHOTO, cmdUPDTRUST, cmdCHKTRUST, cmdADDCARDKEY, cmdKEYTOCARD, cmdBKUPTOCARD, cmdCLEAN, - cmdMINIMIZE, cmdNOP + cmdMINIMIZE, cmdDIGEST, cmdNOP }; static struct @@ -1475,6 +1477,7 @@ static struct N_("compact unusable user IDs and remove unusable signatures from key")}, { "minimize", cmdMINIMIZE , KEYEDIT_NOT_SK, N_("compact unusable user IDs and remove all signatures from key") }, + { "digest", cmdDIGEST, 0, N_("compute a digest for the key")}, { NULL, cmdNONE, 0, NULL } }; @@ -1741,6 +1744,10 @@ keyedit_menu( const char *username, strlist_t locusr, show_key_and_fingerprint( keyblock ); break; + case cmdDIGEST: + show_digest( keyblock, menu_digest() ); + break; + case cmdSELUID: if(strlen(arg_string)==NAMEHASH_LEN*2) redisplay=menu_select_uid_namehash(cur_keyblock,arg_string); @@ -3040,6 +3047,68 @@ show_key_and_fingerprint( KBNODE keyblock ) print_fingerprint( pk, NULL, 2 ); } +// Prints a digest of the public key in keyblock +// using the digest_algo digest algorithm +static void +show_digest (KBNODE keyblock, int digest_algo) +{ + PKT_public_key *pk = NULL; + gcry_md_hd_t md; + const byte *dp; + int len; + int i; + + assert (keyblock->pkt->pkttype == PKT_PUBLIC_KEY); + pk = keyblock->pkt->pkt.public_key; + + tty_printf ("\n"); + + if (gcry_md_open (&md, digest_algo, 0)) + BUG (); + hash_public_key(md,pk); + gcry_md_final( md ); + + dp = gcry_md_read( md, 0 ); + len = gcry_md_get_algo_dlen (gcry_md_get_algo (md)); + assert( len >=0 ); + tty_printf(" %s digest of key = ", gcry_md_algo_name( digest_algo ) ); + for ( i=0; i < len ; i++ ) + tty_printf("%s%s%s%02X", + (i&15)?"":"\n ", + (i&7)?"":" ", + (i&1)?"":" ", + dp[i] ); + gcry_md_close( md ); + + tty_printf ("\n"); +} + +static int +menu_digest ( void ) +{ + int i; + char *answer; + int digest_algo = 0; + + // Showing the possible digests + tty_printf (_("Please select what kind of digest you want:\n")); + for(i=0; i <= 110; i++ ) + if( !openpgp_md_test_algo(i) ) + { + tty_printf( " (%d) %s\n", i, gcry_md_algo_name(i)); + } + + // User selects digest + while ( openpgp_md_test_algo( digest_algo ) ) + { + answer = cpr_get( "keyedit.print_digest", _("Your selection? ") ); + cpr_kill_prompt (); + digest_algo = *answer? atoi (answer) : DIGEST_ALGO_SHA512; + } + + return digest_algo; +} + /* Show a warning if no uids on the key have the primary uid flag set. */ -- 1.7.8.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From beebe at math.utah.edu Tue Jan 31 20:00:09 2012 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 31 Jan 2012 12:00:09 -0700 (MST) Subject: [gnupg-devel] gnupg-1.4.12 build issue Message-ID: I now have gnupg-1.4.12 successfully built, validated, and installed on all of our more than 20 flavors of Unix in our test lab, EXCEPT for one: GNU/Linux Gentoo 2.0.3 on 32-bit SPARC. Before an upgrade from an earlier Gentoo release, gnupg-1.4.10 had been successfully installed, but as too often happens with Linux releases, dropped shared libraries result in installed executables no longer running. After several attempts today, I tracked down the problem: ../mpi/libmpi.a(mpih-div.o):mpih-div.c:(.text+0xe40): more undefined references to `__udiv_qrnnd' follow I have saved output of nm for /usr/lib/libc.a from an earlier Gentoo release, and -lc then had a definition of that symbol. On the current Gentoo release, that symbol has disappeared: % nm /usr/lib/libc.a | grep -A10 udiv_qrnnd ... udiv_qrnnd.o: nm: udiv_qrnnd.o: no symbols ... Gentoo supplies /usr/bin/gpg built from gnupg-2.0.17, so I do have a workaround. However, it appears that the mpi tree is incorrectly making an assumption that udiv_qrnnd is universally available. Curiously, the udiv_qrnnd symbol IS present in -lc on Gentoo 2.0.3 for Alpha. It is missing in Gentoo 2.0.3 for PowerPC-32 and PowerPC-64. The build of gnupg-1.4.12 nevertheless succeeds on those three architectures. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From robbat2 at gentoo.org Tue Jan 31 22:38:26 2012 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Tue, 31 Jan 2012 21:38:26 +0000 Subject: [gnupg-devel] gnupg-1.4.12 build issue In-Reply-To: References: Message-ID: On Tue, Jan 31, 2012 at 12:00:09PM -0700, Nelson H. F. Beebe wrote: > After several attempts today, I tracked down the problem: > > ../mpi/libmpi.a(mpih-div.o):mpih-div.c:(.text+0xe40): > more undefined references to `__udiv_qrnnd' follow ... > Gentoo supplies /usr/bin/gpg built from gnupg-2.0.17, so I do have a > workaround. > > However, it appears that the mpi tree is incorrectly making an > assumption that udiv_qrnnd is universally available. > > Curiously, the udiv_qrnnd symbol IS present in -lc on Gentoo 2.0.3 for > Alpha. It is missing in Gentoo 2.0.3 for PowerPC-32 and PowerPC-64. > The build of gnupg-1.4.12 nevertheless succeeds on those three > architectures. Could you file that in the Gentoo bugzilla for our toolchain team please? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2 at gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85