From gniibe at fsij.org Thu Nov 1 01:17:22 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 01 Nov 2012 09:17:22 +0900 Subject: [PATCH] fix agent/findkey.c In-Reply-To: <87fw4u7pcs.fsf@vigenere.g10code.de> References: <1351667346.19651.1.camel@cfw2.gniibe.org> <87fw4u7pcs.fsf@vigenere.g10code.de> Message-ID: <1351729042.2659.2.camel@cfw2.gniibe.org> On 2012-10-31 at 14:17 +0100, Werner Koch wrote: > On Wed, 31 Oct 2012 08:09, gniibe at fsij.org said: > > - args[argidx++] = (void *)uri_length; > > - args[argidx++] = (void *)uri; > > + args[argidx++] = (void *)&uri_length; > > + args[argidx++] = (void *)&uri; > > I would say, this is the correct fix: > > + args[argidx++] = (void *)((int)uri_length); > + args[argidx++] = (void *)uri; > > The format string ("%b") expect an /int/ and an /const char */: > > else if (*p == 'b') > { > /* Insert a memory buffer. */ > const char *astr; > int alen; > > ARG_NEXT (alen, int); > ARG_NEXT (astr, const char *); Please note that the call in this case is gcry_sexp_build_array, with void **arg_list. In libgcrypt/src/sexp.c, ARG_NEXT is implemented as: 1009 /* Depending on whether ARG_LIST is non-zero or not, this macro gives 1010 us the next argument, either from the variable argument list as 1011 specified by ARG_PTR or from the argument array ARG_LIST. */ 1012 #define ARG_NEXT(storage, type) \ 1013 do \ 1014 { \ 1015 if (!arg_list) \ 1016 storage = va_arg (arg_ptr, type); \ 1017 else \ 1018 storage = *((type *) (arg_list[arg_counter++])); \ 1019 } \ 1020 while (0) Here (line 1018), it expects a _pointer_ to the type and it is _dereferenced_. -- From wk at gnupg.org Fri Nov 2 15:31:05 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Nov 2012 15:31:05 +0100 Subject: [PATCH] fix agent/findkey.c In-Reply-To: <1351729042.2659.2.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Thu, 01 Nov 2012 09:17:22 +0900") References: <1351667346.19651.1.camel@cfw2.gniibe.org> <87fw4u7pcs.fsf@vigenere.g10code.de> <1351729042.2659.2.camel@cfw2.gniibe.org> Message-ID: <874nl83wly.fsf@vigenere.g10code.de> On Thu, 1 Nov 2012 01:17, gniibe at fsij.org said: > 1018 storage = *((type *) (arg_list[arg_counter++])); \ > 1019 } \ > 1020 while (0) > > Here (line 1018), it expects a _pointer_ to the type and it is Argh. You are of course right. I overlooked the the semantics of ARG_NEXT. Moritz implemented gcry_sexp_build_array back in 2003 when I was busy renewing our house. I recall that I had no real desk around that time and was quite distracted from GnuPG stuff. Thus I obviously missed to comment on his new function. Anyway, it is clearly my fault. This function should have non-surprising semantics. It is too late now, we can only document it and put a big warning into it. I'll commit your fixes. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From klaus at flittner.org Sun Nov 4 22:46:32 2012 From: klaus at flittner.org (Klaus Flittner) Date: Sun, 4 Nov 2012 22:46:32 +0100 Subject: Openpgp card handling depending on manufacturer? Message-ID: <20121104224632.5e9bc559@earth> Hi, since i read that gpg2 now officially supports 4096 bit keys with the openpgp cards i tested it with a different implementation of the card and noticed something really strange. If i set the manufacturer field of the card to 5 (Zeitcontrol) generating of a 4096 bit key using gpg2 --card-edit works as expected. If i change only the manufacturer field to 1 or 2 (others i did not test) generating stops after approximately 10 seconds with an timeout in libusb_block_transfer (but only for 4096 bit keys, 3072 and lower works as expected). Is there some code in gnupg that depends on the manufacturer of the card? Kind regards, Klaus Flittner From tk at giga.or.at Mon Nov 5 00:28:17 2012 From: tk at giga.or.at (Thomas Klausner) Date: Mon, 5 Nov 2012 00:28:17 +0100 Subject: gnupg-1.4.12 patches from pkgsrc In-Reply-To: <1351360571-28331-1-git-send-email-tk@giga.or.at> References: <1351360571-28331-1-git-send-email-tk@giga.or.at> Message-ID: <20121104232816.GA7119@danbala.tuwien.ac.at> No comments? Thomas On Sat, Oct 27, 2012 at 07:56:06PM +0200, Thomas Klausner wrote: > This patchset contains all patches currently in pkgsrc for gnupg-1.4.12, > applied to the git version of yesterday. > Please add them to the git repository. > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From gniibe at fsij.org Mon Nov 5 03:17:48 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 05 Nov 2012 11:17:48 +0900 Subject: Openpgp card handling depending on manufacturer? In-Reply-To: <20121104224632.5e9bc559@earth> References: <20121104224632.5e9bc559@earth> Message-ID: <1352081868.2731.3.camel@cfw2.gniibe.org> On 2012-11-04 at 22:46 +0100, Klaus Flittner wrote: > Is there some code in gnupg that depends on the manufacturer of the card? All that I can find is the following. Start from line 3809 of gnupg/scd/app-openpgp.c: --------- /* Some of the first cards accidently don't set the CHANGE_FORCE_CHV bit but allow it anyway. */ if (app->card_version <= 0x0100 && manufacturer == 1) app->app_local->extcap.change_force_chv = 1; --------- It would be good to your check smartcard reader and ATR string of the card. Even when key generation at the card takes more time, there is a protocol which extends timeout by the smartcard reader (the time extension request). GnuPG USB communication doesn't timeout when the smartcard reader uses this protocol. If it means the whole process, 10 seconds timeout for key generation operation of RSA 4096-bit key sounds short for me. It is no surprise for me that it takes, say, 30 seconds. -- From wk at gnupg.org Mon Nov 5 08:17:19 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Nov 2012 08:17:19 +0100 Subject: gnupg-1.4.12 patches from pkgsrc In-Reply-To: <20121104232816.GA7119@danbala.tuwien.ac.at> (Thomas Klausner's message of "Mon, 5 Nov 2012 00:28:17 +0100") References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <20121104232816.GA7119@danbala.tuwien.ac.at> Message-ID: <871ug834e8.fsf@vigenere.g10code.de> On Mon, 5 Nov 2012 00:28, tk at giga.or.at said: > No comments? I would have some comments but you may not like them. But first of all, I won't be able to apply your changes without a copyright assignment to the FSF. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 5 08:22:57 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Nov 2012 08:22:57 +0100 Subject: [PATCH 1/5] Only call dlerror() when dlsym() fails. In-Reply-To: <1351360571-28331-2-git-send-email-tk@giga.or.at> (Thomas Klausner's message of "Sat, 27 Oct 2012 19:56:07 +0200") References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-2-git-send-email-tk@giga.or.at> Message-ID: <87wqy01pke.fsf@vigenere.g10code.de> On Sat, 27 Oct 2012 19:56, tk at giga.or.at said: > State of dlerror() is undefined otherwise, at least on NetBSD. I would preser a configure test along with an AC_REPLACE_FUNCS. This should be a common problem on NetBSD. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From klaus at flittner.org Mon Nov 5 08:34:14 2012 From: klaus at flittner.org (Klaus Flittner) Date: Mon, 5 Nov 2012 08:34:14 +0100 Subject: Openpgp card handling depending on manufacturer? In-Reply-To: <1352081868.2731.3.camel@cfw2.gniibe.org> References: <20121104224632.5e9bc559@earth> <1352081868.2731.3.camel@cfw2.gniibe.org> Message-ID: <20121105083414.7d3cf0f9@jupiter> NIIBE Yutaka wrote: > All that I can find is the following. > > Start from line 3809 of gnupg/scd/app-openpgp.c: > --------- > /* Some of the first cards accidently don't set the > CHANGE_FORCE_CHV bit but allow it anyway. */ > if (app->card_version <= 0x0100 && manufacturer == 1) > app->app_local->extcap.change_force_chv = 1; > --------- This was also the only part i found. But it only applies to version 1 of the card and manufacturer value of 1. > It would be good to your check smartcard reader and ATR string of the > card. I will try to get a different smartcard reader and see if it is somehow related to the reader. > Even when key generation at the card takes more time, there is a > protocol which extends timeout by the smartcard reader (the time > extension request). GnuPG USB communication doesn't timeout when the > smartcard reader uses this protocol. > > If it means the whole process, 10 seconds timeout for key generation > operation of RSA 4096-bit key sounds short for me. It is no surprise > for me that it takes, say, 30 seconds. The generation of these keys takes considerably longer than 10 seconds. The longest i've seen till now was 500 seconds. The card sends an time extension request and it is (at least sometimes) used to extend the timeout, as the same card with the same firmware and just a changed manufacturer value generates the keys without an timeout occuring. The only difference between the working and non-working case is the manufacturer value. And as far is i understand the only software in the chain (reader firmware, libccid, pcsc, gpg) that uses this value or even now about it is gpg. Regards, Klaus Flittner From wk at gnupg.org Mon Nov 5 08:30:18 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Nov 2012 08:30:18 +0100 Subject: [PATCH 4/5] Deal with c99 inline semantics. In-Reply-To: <1351360571-28331-5-git-send-email-tk@giga.or.at> (Thomas Klausner's message of "Sat, 27 Oct 2012 19:56:10 +0200") References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-5-git-send-email-tk@giga.or.at> Message-ID: <87sj8o1p85.fsf@vigenere.g10code.de> On Sat, 27 Oct 2012 19:56, tk at giga.or.at said: > Needed for compilation with recent LLVM/Clang. That might be anotherr clang bug; see http://rem.eifzilla.de/archives/2012/08/10/identify-theft-by-clang (IPv6 only) for more comments. If that is not the case, please explain why code working for more than a decade on dozens of OSes and compilers stops working with clang. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Mon Nov 5 09:46:31 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 05 Nov 2012 17:46:31 +0900 Subject: Openpgp card handling depending on manufacturer? In-Reply-To: <20121105083414.7d3cf0f9@jupiter> References: <20121104224632.5e9bc559@earth> <1352081868.2731.3.camel@cfw2.gniibe.org> <20121105083414.7d3cf0f9@jupiter> Message-ID: <1352105191.16311.0.camel@cfw2.gniibe.org> On 2012-11-05 at 08:34 +0100, Klaus Flittner wrote: > The only difference between the working and non-working case is the > manufacturer value. And as far is i understand the only software in the > chain (reader firmware, libccid, pcsc, gpg) that uses this value or > even now about it is gpg. I'd understand your theory. Note that it is also possible the bug were not related to your change of manufacturer value. Are you sure that the error is by timeout? Did you see libusb_block_transfer really returns ETIMEOUT? If your smartcard reader is supported by GnuPG's in-stock CCID driver, it is also worth a try with no pcsc and libccid. * * * Let me explain one example around CCID library and GnuPG. I was in chase of a bug. I changed some code in GnuPG and watched a change of behavior, I assumed that I enbugged in GnuPG... but the bug was in libusb, actually. That was with Debian, with ccid 1.4.2 and libusb 2:1.0.8-2. The library ccid has a buffer (64KiB) and sends four URBs, and there was a race condition between sending another URB and receiving a reply packet. I found the fix in libusb 1.0.9, which handles EROMOTEIO correctly. -- From tk at giga.or.at Mon Nov 5 17:26:39 2012 From: tk at giga.or.at (Thomas Klausner) Date: Mon, 5 Nov 2012 17:26:39 +0100 Subject: [PATCH 1/5] Only call dlerror() when dlsym() fails. In-Reply-To: <87wqy01pke.fsf@vigenere.g10code.de> References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-2-git-send-email-tk@giga.or.at> <87wqy01pke.fsf@vigenere.g10code.de> Message-ID: <20121105162638.GF11062@danbala.tuwien.ac.at> On Mon, Nov 05, 2012 at 08:22:57AM +0100, Werner Koch wrote: > On Sat, 27 Oct 2012 19:56, tk at giga.or.at said: > > > State of dlerror() is undefined otherwise, at least on NetBSD. > > I would preser a configure test along with an AC_REPLACE_FUNCS. This > should be a common problem on NetBSD. I'm not sure you understood the patch. Or I didn't understand your comment. What should the configure test check? The dlerror() function exists, just its return value is undefined in case there was no error with dlsym(). Thomas From tk at giga.or.at Mon Nov 5 17:27:14 2012 From: tk at giga.or.at (Thomas Klausner) Date: Mon, 5 Nov 2012 17:27:14 +0100 Subject: gnupg-1.4.12 patches from pkgsrc In-Reply-To: <871ug834e8.fsf@vigenere.g10code.de> References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <20121104232816.GA7119@danbala.tuwien.ac.at> <871ug834e8.fsf@vigenere.g10code.de> Message-ID: <20121105162714.GG11062@danbala.tuwien.ac.at> On Mon, Nov 05, 2012 at 08:17:19AM +0100, Werner Koch wrote: > On Mon, 5 Nov 2012 00:28, tk at giga.or.at said: > > No comments? > > I would have some comments but you may not like them. I prefer comments I don't like to no comments :) > But first of all, > I won't be able to apply your changes without a copyright assignment to > the FSF. Please let me know how to proceed on that, then. Thanks, Thomas From tk at giga.or.at Mon Nov 5 17:29:11 2012 From: tk at giga.or.at (Thomas Klausner) Date: Mon, 5 Nov 2012 17:29:11 +0100 Subject: [PATCH 4/5] Deal with c99 inline semantics. In-Reply-To: <87sj8o1p85.fsf@vigenere.g10code.de> References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-5-git-send-email-tk@giga.or.at> <87sj8o1p85.fsf@vigenere.g10code.de> Message-ID: <20121105162911.GH11062@danbala.tuwien.ac.at> On Mon, Nov 05, 2012 at 08:30:18AM +0100, Werner Koch wrote: > On Sat, 27 Oct 2012 19:56, tk at giga.or.at said: > > > Needed for compilation with recent LLVM/Clang. > > That might be anotherr clang bug; see > http://rem.eifzilla.de/archives/2012/08/10/identify-theft-by-clang (IPv6 > only) for more comments. If that is not the case, please explain why > code working for more than a decade on dozens of OSes and compilers > stops working with clang. The difference between gcc and clang here is that clang by default defines -std=gnu99. You probably will see the same problem when compiling the code with GCC and that setting (see also __GNUC_STDC_INLINE__). Thomas From klaus at flittner.org Mon Nov 5 19:54:54 2012 From: klaus at flittner.org (Klaus Flittner) Date: Mon, 5 Nov 2012 19:54:54 +0100 Subject: Openpgp card handling depending on manufacturer? In-Reply-To: <1352105191.16311.0.camel@cfw2.gniibe.org> References: <20121104224632.5e9bc559@earth> <1352081868.2731.3.camel@cfw2.gniibe.org> <20121105083414.7d3cf0f9@jupiter> <1352105191.16311.0.camel@cfw2.gniibe.org> Message-ID: <20121105195454.251d84eb@earth> NIIBE Yutaka schrieb: > On 2012-11-05 at 08:34 +0100, Klaus Flittner wrote: > > The only difference between the working and non-working case is the > > manufacturer value. And as far is i understand the only software in the > > chain (reader firmware, libccid, pcsc, gpg) that uses this value or > > even now about it is gpg. > > I'd understand your theory. Note that it is also possible the bug were > not related to your change of manufacturer value. > > Are you sure that the error is by timeout? Did you see > libusb_block_transfer really returns ETIMEOUT? Yes. libusb_block_transfer really returns LIBUSB_ERROR_TIMEOUT. The logfiles contain the following if the error occurs: The value -7 in the first line corresponds to LIBUSB_ERROR_TIMEOUT. ----- pcscd: ccid_usb.c:699:ReadUSB() read failed (7/2): -7 Success pcscd: ifdwrapper.c:527:IFDTransmit() Card not transacted: 612 pcscd: winscard.c:1532:SCardTransmit() Card not transacted: 0x80100016 ----- What is really strange is the fact that the generation of a 3072-bit key on the same card also takes longer than 10 seconds (approximately 30-40 seconds), but in that case no timeout occurs even on the card with the manufacturer value of 1 or 2. Therefore it seems also correlated to the key lengths being 4096 bit in addition to the manufacturer value. > If your smartcard reader is supported by GnuPG's in-stock CCID driver, > it is also worth a try with no pcsc and libccid. I will try this if i figure out how to use the internal driver. Deinstalling pcscd is not enough and in the man page there is only an option to disable the internal ccid driver, not to enable it... Regards, Klaus Flittner From gniibe at fsij.org Tue Nov 6 02:51:22 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 06 Nov 2012 10:51:22 +0900 Subject: Openpgp card handling depending on manufacturer? In-Reply-To: <20121105195454.251d84eb@earth> References: <20121104224632.5e9bc559@earth> <1352081868.2731.3.camel@cfw2.gniibe.org> <20121105083414.7d3cf0f9@jupiter> <1352105191.16311.0.camel@cfw2.gniibe.org> <20121105195454.251d84eb@earth> Message-ID: <1352166682.2842.2.camel@cfw2.gniibe.org> On 2012-11-05 at 19:54 +0100, Klaus Flittner wrote: > Yes. libusb_block_transfer really returns LIBUSB_ERROR_TIMEOUT. The > logfiles contain the following if the error occurs: The value -7 in the > first line corresponds to LIBUSB_ERROR_TIMEOUT. > ----- > pcscd: ccid_usb.c:699:ReadUSB() read failed (7/2): -7 Success > pcscd: ifdwrapper.c:527:IFDTransmit() Card not transacted: 612 > pcscd: winscard.c:1532:SCardTransmit() Card not transacted: 0x80100016 > ----- Thank you for the information. If I were you, I'd check: * ATR string of the card That's because it has information for Block Waiting Time (BWT) * The value of ccid_descriptor -> readTimeout in libccid Namely, the argument of libusb_bulk_transfer * Interaction of libccid and smartcard reader by setting ifdLogLevel = 0x0007 in Info.plist (so that we can see if time extension occurs or not) -- From wk at gnupg.org Tue Nov 6 08:30:16 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Nov 2012 08:30:16 +0100 Subject: Openpgp card handling depending on manufacturer? In-Reply-To: <20121105195454.251d84eb@earth> (Klaus Flittner's message of "Mon, 5 Nov 2012 19:54:54 +0100") References: <20121104224632.5e9bc559@earth> <1352081868.2731.3.camel@cfw2.gniibe.org> <20121105083414.7d3cf0f9@jupiter> <1352105191.16311.0.camel@cfw2.gniibe.org> <20121105195454.251d84eb@earth> Message-ID: <874nl3194n.fsf@vigenere.g10code.de> On Mon, 5 Nov 2012 19:54, klaus at flittner.org said: > I will try this if i figure out how to use the internal driver. > Deinstalling pcscd is not enough and in the man page there is only an You need to have write access to the usb device. Use debug-ccid-driver debug-ccid-driver in scdaemon.conf to see what is going on. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Nov 6 08:31:29 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Nov 2012 08:31:29 +0100 Subject: [PATCH 1/5] Only call dlerror() when dlsym() fails. In-Reply-To: <20121105162638.GF11062@danbala.tuwien.ac.at> (Thomas Klausner's message of "Mon, 5 Nov 2012 17:26:39 +0100") References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-2-git-send-email-tk@giga.or.at> <87wqy01pke.fsf@vigenere.g10code.de> <20121105162638.GF11062@danbala.tuwien.ac.at> Message-ID: <87zk2vyypa.fsf@vigenere.g10code.de> On Mon, 5 Nov 2012 17:26, tk at giga.or.at said: > What should the configure test check? The dlerror() function exists, > just its return value is undefined in case there was no error with > dlsym(). Provide a working dlerror function. That may require to alos wrap dlsym. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Nov 6 08:37:46 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Nov 2012 08:37:46 +0100 Subject: [PATCH 4/5] Deal with c99 inline semantics. In-Reply-To: <20121105162911.GH11062@danbala.tuwien.ac.at> (Thomas Klausner's message of "Mon, 5 Nov 2012 17:29:11 +0100") References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-5-git-send-email-tk@giga.or.at> <87sj8o1p85.fsf@vigenere.g10code.de> <20121105162911.GH11062@danbala.tuwien.ac.at> Message-ID: <87vcdjyyet.fsf@vigenere.g10code.de> On Mon, 5 Nov 2012 17:29, tk at giga.or.at said: > The difference between gcc and clang here is that clang by default > defines -std=gnu99. You probably will see the same problem when > compiling the code with GCC and that setting (see also But it seems not to behave exactly as defined for gnu99. If you can show that there is a problem when using gcc -std=gnu99 I will look at it again. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tk at giga.or.at Tue Nov 6 08:52:04 2012 From: tk at giga.or.at (Thomas Klausner) Date: Tue, 6 Nov 2012 08:52:04 +0100 Subject: [PATCH 4/5] Deal with c99 inline semantics. In-Reply-To: <87vcdjyyet.fsf@vigenere.g10code.de> References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-5-git-send-email-tk@giga.or.at> <87sj8o1p85.fsf@vigenere.g10code.de> <20121105162911.GH11062@danbala.tuwien.ac.at> <87vcdjyyet.fsf@vigenere.g10code.de> Message-ID: <20121106075204.GT11062@danbala.tuwien.ac.at> On Tue, Nov 06, 2012 at 08:37:46AM +0100, Werner Koch wrote: > On Mon, 5 Nov 2012 17:29, tk at giga.or.at said: > > > The difference between gcc and clang here is that clang by default > > defines -std=gnu99. You probably will see the same problem when > > compiling the code with GCC and that setting (see also > > But it seems not to behave exactly as defined for gnu99. If you can > show that there is a problem when using gcc -std=gnu99 I will look at it > again. That's easy, here goes: # gcc --version gcc (NetBSD nb1 20120916) 4.5.4 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # cd /tmp # tar xzf /distfiles/gnupg-1.4.12.tar.bz2 # cd gnupg-1.4.12 # ./configure CPPFLAGS=-std=gnu99 ... # gmake CPPFLAGS=-std=gnu99 ... gcc -g -O2 -Wall -Wno-pointer-sign -o mpicalc mpicalc.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a ../intl/libintl.a ../mpi/libmpi.a(mpi-bit.o): In function `mpihelp_add_1': /tmp/gnupg-1.4.12/mpi/mpi-inline.h:41: multiple definition of `mpihelp_add_1' ../mpi/libmpi.a(mpi-add.o):/tmp/gnupg-1.4.12/mpi/mpi-inline.h:41: first defined here ../mpi/libmpi.a(mpi-bit.o): In function `mpihelp_add': /tmp/gnupg-1.4.12/mpi/mpi-inline.h:68: multiple definition of `mpihelp_add' ../mpi/libmpi.a(mpi-add.o):/tmp/gnupg-1.4.12/mpi/mpi-inline.h:68: first defined here ../mpi/libmpi.a(mpi-bit.o): In function `mpihelp_sub_1': /tmp/gnupg-1.4.12/mpi/mpi-inline.h:87: multiple definition of `mpihelp_sub_1' ../mpi/libmpi.a(mpi-add.o):/tmp/gnupg-1.4.12/mpi/mpi-inline.h:87: first defined here ../mpi/libmpi.a(mpi-bit.o): In function `mpihelp_sub': /tmp/gnupg-1.4.12/mpi/mpi-inline.h:114: multiple definition of `mpihelp_sub' ../mpi/libmpi.a(mpi-add.o):/tmp/gnupg-1.4.12/mpi/mpi-inline.h:114: first defined here ../mpi/libmpi.a(mpi-div.o): In function `mpihelp_add_1': /tmp/gnupg-1.4.12/mpi/mpi-inline.h:41: multiple definition of `mpihelp_add_1' ../mpi/libmpi.a(mpi-add.o):/tmp/gnupg-1.4.12/mpi/mpi-inline.h:41: first defined here ../mpi/libmpi.a(mpi-div.o): In function `mpihelp_add': /tmp/gnupg-1.4.12/mpi/mpi-inline.h:68: multiple definition of `mpihelp_add' ../mpi/libmpi.a(mpi-add.o):/tmp/gnupg-1.4.12/mpi/mpi-inline.h:68: first defined here ../mpi/libmpi.a(mpi-div.o): In function `mpihelp_sub_1': /tmp/gnupg-1.4.12/mpi/mpi-inline.h:87: multiple definition of `mpihelp_sub_1' ../mpi/libmpi.a(mpi-add.o):/tmp/gnupg-1.4.12/mpi/mpi-inline.h:87: first defined here ../mpi/libmpi.a(mpi-div.o): In function `mpihelp_sub': /tmp/gnupg-1.4.12/mpi/mpi-inline.h:114: multiple definition of `mpihelp_sub' ../mpi/libmpi.a(mpi-add.o):/tmp/gnupg-1.4.12/mpi/mpi-inline.h:114: first defined here ../mpi/libmpi.a(mpi-gcd.o): In function `mpihelp_add_1': (and lots more of the same) Thomas From wk at gnupg.org Tue Nov 6 17:19:12 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Nov 2012 17:19:12 +0100 Subject: [PATCH 4/5] Deal with c99 inline semantics. In-Reply-To: <20121106075204.GT11062@danbala.tuwien.ac.at> (Thomas Klausner's message of "Tue, 6 Nov 2012 08:52:04 +0100") References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-5-git-send-email-tk@giga.or.at> <87sj8o1p85.fsf@vigenere.g10code.de> <20121105162911.GH11062@danbala.tuwien.ac.at> <87vcdjyyet.fsf@vigenere.g10code.de> <20121106075204.GT11062@danbala.tuwien.ac.at> Message-ID: <87a9uuya9r.fsf@vigenere.g10code.de> On Tue, 6 Nov 2012 08:52, tk at giga.or.at said: >> But it seems not to behave exactly as defined for gnu99. If you can >> show that there is a problem when using gcc -std=gnu99 I will look at it >> again. > > That's easy, here goes: You are right. I just pushed this: >From 5093bed27580e608de073bcc5953bd76b6b8b2de Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Tue, 6 Nov 2012 17:14:04 +0100 Subject: [PATCH] Fix extern inline use for gcc > 4.3 in c99 mode * mpi/mpi-inline.h [!G10_MPI_INLINE_DECL]: Take care of changed extern inline semantics in gcc. -- I am not use how this will work out with non-gcc. However, we had no problems in the past and thus this change is the least invasive for non-gcc compilers. --- mpi/mpi-inline.h | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/mpi/mpi-inline.h b/mpi/mpi-inline.h index c32adae..6e44518 100644 --- a/mpi/mpi-inline.h +++ b/mpi/mpi-inline.h @@ -28,8 +28,15 @@ #ifndef G10_MPI_INLINE_H #define G10_MPI_INLINE_H +/* Starting with gcc 4.3 "extern inline" conforms in c99 mode to the + c99 semantics. To keep the useful old semantics we use an + attribute. */ #ifndef G10_MPI_INLINE_DECL -#define G10_MPI_INLINE_DECL extern __inline__ +# ifdef __GNUC_STDC_INLINE__ +# define G10_MPI_INLINE_DECL extern inline __attribute__ ((__gnu_inline__)) +# else +# define G10_MPI_INLINE_DECL extern __inline__ +# endif #endif G10_MPI_INLINE_DECL mpi_limb_t -- 1.7.7.1 Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Nov 6 17:29:41 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Nov 2012 17:29:41 +0100 Subject: [PATCH 2/5] Support NetBSD/m68k. In-Reply-To: <1351360571-28331-3-git-send-email-tk@giga.or.at> (Thomas Klausner's message of "Sat, 27 Oct 2012 19:56:08 +0200") References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-3-git-send-email-tk@giga.or.at> Message-ID: <87625iy9sa.fsf@vigenere.g10code.de> On Sat, 27 Oct 2012 19:56, tk at giga.or.at said: > + m68k*-*-netbsdelf) > + echo '#define ELF_SYNTAX' >>./mpi/asm-syntax.h > + cat $srcdir/mpi/m68k/syntax.h >>./mpi/asm-syntax.h > + path="m68k" > + if ! test x$M68060 = xYES; then > + path="m68k/mc68020 m68k" Can you please give a brief description for the M68060 variable? Is that always defined in the env for such a machine? I believe the correct fix is to update config.sub and have an extra rule for M68060. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Nov 6 18:26:16 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Nov 2012 18:26:16 +0100 Subject: [PATCH 5/5] Handle systems which have uint64_t but not the UINT64_C macro. In-Reply-To: <1351360571-28331-6-git-send-email-tk@giga.or.at> (Thomas Klausner's message of "Sat, 27 Oct 2012 19:56:11 +0200") References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-6-git-send-email-tk@giga.or.at> Message-ID: <871ug6y75z.fsf@vigenere.g10code.de> Applied. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From klaus at flittner.org Tue Nov 6 22:10:46 2012 From: klaus at flittner.org (Klaus Flittner) Date: Tue, 6 Nov 2012 22:10:46 +0100 Subject: Openpgp card handling depending on manufacturer? In-Reply-To: <1352166682.2842.2.camel@cfw2.gniibe.org> References: <20121104224632.5e9bc559@earth> <1352081868.2731.3.camel@cfw2.gniibe.org> <20121105083414.7d3cf0f9@jupiter> <1352105191.16311.0.camel@cfw2.gniibe.org> <20121105195454.251d84eb@earth> <1352166682.2842.2.camel@cfw2.gniibe.org> Message-ID: <20121106221046.23281b1f@earth> NIIBE Yutaka wrote: > On 2012-11-05 at 19:54 +0100, Klaus Flittner wrote: > > Yes. libusb_block_transfer really returns LIBUSB_ERROR_TIMEOUT. The > > logfiles contain the following if the error occurs: The value -7 in the > > first line corresponds to LIBUSB_ERROR_TIMEOUT. > > ----- > > pcscd: ccid_usb.c:699:ReadUSB() read failed (7/2): -7 Success > > pcscd: ifdwrapper.c:527:IFDTransmit() Card not transacted: 612 > > pcscd: winscard.c:1532:SCardTransmit() Card not transacted: 0x80100016 > > ----- > > Thank you for the information. > > If I were you, I'd check: > > * ATR string of the card > That's because it has information for Block Waiting Time (BWT) ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 80 00 90 00 CC That should correspond to a BWT of 9.5 seconds (if i got the math right) > * The value of ccid_descriptor -> readTimeout in libccid > Namely, the argument of libusb_bulk_transfer > > * Interaction of libccid and smartcard reader by > setting ifdLogLevel = 0x0007 in Info.plist > (so that we can see if time extension occurs or not) ---------- 20:08:22 pcscd: winscard.c:1507:SCardTransmit() Send Protocol: T=1 20:08:22 pcscd: ifdhandler.c:1257:IFDHTransmitToICC() usb:0d46/3002:libudev:0:/dev/bus/usb/007/002 (lun: 0) 20:08:22 pcscd: commands.c:1487:CmdXfrBlockAPDU_extended() T=0 (extended): 8 bytes 20:08:22 pcscd: -> 000000 6F 08 00 00 00 00 3B 00 00 00 00 47 80 00 02 B6 00 00 20:08:22 pcscd: <- 000000 80 00 00 00 00 00 3B 80 64 00 20:08:22 pcscd: commands.c:1422:CCID_Receive() Time extension requested: 0x64 20:08:22 pcscd: <- 000000 80 00 00 00 00 00 3B 80 64 00 20:08:22 pcscd: commands.c:1422:CCID_Receive() Time extension requested: 0x64 20:08:32 pcscd: ccid_usb.c:699:ReadUSB() read failed (7/2): -7 Success 20:08:32 pcscd: ifdwrapper.c:527:IFDTransmit() Card not transacted: 612 20:08:32 pcscd: winscard.c:1532:SCardTransmit() Card not transacted: 0x80100016 20:08:32 pcscd: winscard_svc.c:604:ContextThread() TRANSMIT rv=0x80100016 for client 5 ---------- The timing fits quite well to the BWT. But with the time extension requested it should allow the operation to need a time of up to 100 times the BWT. As of today key generation no longer works with the cards regardless of manufacturer value. Nothing really changed since the tests yesterday. Even smaller keys are not possible anymore. Everything which takes longer as the BWT times out. Which part of the stack is responsible to handle the time extension request? Is it handled inside the firmware of the reader, or is the driver (ccid) responsible. Regards, Klaus Flittner From gniibe at fsij.org Wed Nov 7 02:12:57 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 07 Nov 2012 10:12:57 +0900 Subject: Openpgp card handling depending on manufacturer? In-Reply-To: <20121106221046.23281b1f@earth> References: <20121104224632.5e9bc559@earth> <1352081868.2731.3.camel@cfw2.gniibe.org> <20121105083414.7d3cf0f9@jupiter> <1352105191.16311.0.camel@cfw2.gniibe.org> <20121105195454.251d84eb@earth> <1352166682.2842.2.camel@cfw2.gniibe.org> <20121106221046.23281b1f@earth> Message-ID: <1352250777.2667.1.camel@cfw2.gniibe.org> Thank you for the log. On 2012-11-06 at 22:10 +0100, Klaus Flittner wrote: > 20:08:22 pcscd: commands.c:1487:CmdXfrBlockAPDU_extended() T=0 (extended): 8 bytes > 20:08:22 pcscd: -> 000000 6F 08 00 00 00 00 3B 00 00 00 00 47 80 00 02 B6 00 00 Soon after the host PC sent a block, ... > 20:08:22 pcscd: <- 000000 80 00 00 00 00 00 3B 80 64 00 > 20:08:22 pcscd: commands.c:1422:CCID_Receive() Time extension requested: 0x64 The smartcard reader responded time extension, once. > 20:08:22 pcscd: <- 000000 80 00 00 00 00 00 3B 80 64 00 > 20:08:22 pcscd: commands.c:1422:CCID_Receive() Time extension requested: 0x64 ... and twice. Here, bStatus is 0x80 (bmCommandStatus=2, bmICCStatus=0), and bError is 0x64 (= 100). The specification (USB CCID 1.1) says: When the bmCommandStatus field is 2, indicating a Time extension is requested, then the slots error register contains the multiplier value of BWT when the protocol is T=1 or the multiplier value of WWT when the protocol is T=0. Thus, host PC should wait 100 x BWT. However, unfortunately, I think that current implementation of libccid doesn't care about the field bError, and just wait again for another BWT. I'm reading the source code of ccid 1.4.7. > 20:08:32 pcscd: ccid_usb.c:699:ReadUSB() read failed (7/2): -7 Success Here, we see timeout of the host PC side after BWT, not 100 x BWT. > Which part of the stack is responsible to handle the time extension > request? Is it handled inside the firmware of the reader, or is the > driver (ccid) responsible. I think that both should be responsible. Conservative implementation of smartcard reader could send back the time extension to the host PC, periodically (say, on each timeout of BWT (or something)) when it is waiting the response from the card (for 100xBWT). Same thing can be applied to the card. Conservative implementation of smartcard could send back time extension request (by S block) to the terminal (multiplier = 1), periodically, when the computation is still ongoing. -- From tk at giga.or.at Wed Nov 7 13:23:48 2012 From: tk at giga.or.at (Thomas Klausner) Date: Wed, 7 Nov 2012 13:23:48 +0100 Subject: [PATCH 4/5] Deal with c99 inline semantics. In-Reply-To: <87a9uuya9r.fsf@vigenere.g10code.de> References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-5-git-send-email-tk@giga.or.at> <87sj8o1p85.fsf@vigenere.g10code.de> <20121105162911.GH11062@danbala.tuwien.ac.at> <87vcdjyyet.fsf@vigenere.g10code.de> <20121106075204.GT11062@danbala.tuwien.ac.at> <87a9uuya9r.fsf@vigenere.g10code.de> Message-ID: <20121107122348.GE11062@danbala.tuwien.ac.at> On Tue, Nov 06, 2012 at 05:19:12PM +0100, Werner Koch wrote: > You are right. I just pushed this: > > >From 5093bed27580e608de073bcc5953bd76b6b8b2de Mon Sep 17 00:00:00 2001 > From: Werner Koch > Date: Tue, 6 Nov 2012 17:14:04 +0100 > Subject: [PATCH] Fix extern inline use for gcc > 4.3 in c99 mode > > * mpi/mpi-inline.h [!G10_MPI_INLINE_DECL]: Take care of changed extern > inline semantics in gcc. That works as well, thanks. I've switched pkgsrc to use this. Thomas From tk at giga.or.at Wed Nov 7 13:30:28 2012 From: tk at giga.or.at (Thomas Klausner) Date: Wed, 7 Nov 2012 13:30:28 +0100 Subject: [PATCH 2/5] Support NetBSD/m68k. In-Reply-To: <87625iy9sa.fsf@vigenere.g10code.de> References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-3-git-send-email-tk@giga.or.at> <87625iy9sa.fsf@vigenere.g10code.de> Message-ID: <20121107123028.GF11062@danbala.tuwien.ac.at> On Tue, Nov 06, 2012 at 05:29:41PM +0100, Werner Koch wrote: > On Sat, 27 Oct 2012 19:56, tk at giga.or.at said: > > > + m68k*-*-netbsdelf) > > + echo '#define ELF_SYNTAX' >>./mpi/asm-syntax.h > > + cat $srcdir/mpi/m68k/syntax.h >>./mpi/asm-syntax.h > > + path="m68k" > > + if ! test x$M68060 = xYES; then > > + path="m68k/mc68020 m68k" > > Can you please give a brief description for the M68060 variable? Is > that always defined in the env for such a machine? I believe the > correct fix is to update config.sub and have an extra rule for M68060. I overlooked this, sorry. There's related code in the package infrastructure that does the following: # be more efficient on M68060 machines CONFIGURE_ENV+= M68060=${M68060:Q} CFLAGS+= -m68060 ...IF the user sets a variable manually -- I don't know if these machines can be automatically recognized. There was a bug report about this: http://gnats.netbsd.org/24579 I'll cc the submitter, spz; perhaps she can shed more light on how to keep these kinds of machines apart, if she's still running one. Thomas From tk at giga.or.at Wed Nov 7 13:34:32 2012 From: tk at giga.or.at (Thomas Klausner) Date: Wed, 7 Nov 2012 13:34:32 +0100 Subject: [PATCH 1/5] Only call dlerror() when dlsym() fails. In-Reply-To: <87zk2vyypa.fsf@vigenere.g10code.de> References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-2-git-send-email-tk@giga.or.at> <87wqy01pke.fsf@vigenere.g10code.de> <20121105162638.GF11062@danbala.tuwien.ac.at> <87zk2vyypa.fsf@vigenere.g10code.de> Message-ID: <20121107123432.GG11062@danbala.tuwien.ac.at> On Tue, Nov 06, 2012 at 08:31:29AM +0100, Werner Koch wrote: > On Mon, 5 Nov 2012 17:26, tk at giga.or.at said: > > > What should the configure test check? The dlerror() function exists, > > just its return value is undefined in case there was no error with > > dlsym(). > > Provide a working dlerror function. That may require to alos wrap > dlsym. I've read http://pubs.opengroup.org/onlinepubs/009695399/functions/dlerror.html a few times, and I don't see it defining what dlerror() returns if it was never called before and no error by dynamic linking occurred yet. (NULL as return value is only specified if there was a previous dlerror() call.) So since POSIX doesn't specify that dlerror() on NetBSD is behaving incorrectly and the patch is trivial, I ask you to use the patch instead of adding quite a bit of overhead in configury. Thanks, Thomas From wk at gnupg.org Wed Nov 7 15:55:30 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Nov 2012 15:55:30 +0100 Subject: [PATCH 1/5] Only call dlerror() when dlsym() fails. In-Reply-To: <20121107123432.GG11062@danbala.tuwien.ac.at> (Thomas Klausner's message of "Wed, 7 Nov 2012 13:34:32 +0100") References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-2-git-send-email-tk@giga.or.at> <87wqy01pke.fsf@vigenere.g10code.de> <20121105162638.GF11062@danbala.tuwien.ac.at> <87zk2vyypa.fsf@vigenere.g10code.de> <20121107123432.GG11062@danbala.tuwien.ac.at> Message-ID: <87txt1v4wt.fsf@vigenere.g10code.de> On Wed, 7 Nov 2012 13:34, tk at giga.or.at said: > a few times, and I don't see it defining what dlerror() returns if it > was never called before and no error by dynamic linking occurred yet. Right, the proper way to use it would be call dlerror() before calling dlsym. This makes sure that we see the right error. However, this won't help with NetBSD's wrong implementation. > So since POSIX doesn't specify that dlerror() on NetBSD is behaving > incorrectly and the patch is trivial, I ask you to use the patch Recall that we also use dlopen et al. as interface to the respective Windows functions. Thus this change is not trivial. > instead of adding quite a bit of overhead in configury. Agreed. However, a better way to fix this is to get rid of dlopen. There is no more need for idea-stub.c and we may add include IDEA support directly. (That algorithm will probably never die - like Arcfour) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tk at giga.or.at Wed Nov 7 16:08:18 2012 From: tk at giga.or.at (Thomas Klausner) Date: Wed, 7 Nov 2012 16:08:18 +0100 Subject: [PATCH 1/5] Only call dlerror() when dlsym() fails. In-Reply-To: <87txt1v4wt.fsf@vigenere.g10code.de> References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-2-git-send-email-tk@giga.or.at> <87wqy01pke.fsf@vigenere.g10code.de> <20121105162638.GF11062@danbala.tuwien.ac.at> <87zk2vyypa.fsf@vigenere.g10code.de> <20121107123432.GG11062@danbala.tuwien.ac.at> <87txt1v4wt.fsf@vigenere.g10code.de> Message-ID: <20121107150817.GK11062@danbala.tuwien.ac.at> On Wed, Nov 07, 2012 at 03:55:30PM +0100, Werner Koch wrote: > On Wed, 7 Nov 2012 13:34, tk at giga.or.at said: > > > a few times, and I don't see it defining what dlerror() returns if it > > was never called before and no error by dynamic linking occurred yet. > > Right, the proper way to use it would be call dlerror() before calling > dlsym. This makes sure that we see the right error. However, this > won't help with NetBSD's wrong implementation. I think I don't understand what you see as the problem in the NetBSD implementation. According to its man page, it should behave the same as specified above. What behaves differently? > > So since POSIX doesn't specify that dlerror() on NetBSD is behaving > > incorrectly and the patch is trivial, I ask you to use the patch > > Recall that we also use dlopen et al. as interface to the respective > Windows functions. Thus this change is not trivial. I'll take your word on that. > > instead of adding quite a bit of overhead in configury. > > Agreed. > > However, a better way to fix this is to get rid of dlopen. There is no > more need for idea-stub.c and we may add include IDEA support directly. > (That algorithm will probably never die - like Arcfour) That solution is fine with me, of course. Thanks, Thomas From wk at gnupg.org Wed Nov 7 18:32:01 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Nov 2012 18:32:01 +0100 Subject: [PATCH 1/5] Only call dlerror() when dlsym() fails. In-Reply-To: <20121107150817.GK11062@danbala.tuwien.ac.at> (Thomas Klausner's message of "Wed, 7 Nov 2012 16:08:18 +0100") References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-2-git-send-email-tk@giga.or.at> <87wqy01pke.fsf@vigenere.g10code.de> <20121105162638.GF11062@danbala.tuwien.ac.at> <87zk2vyypa.fsf@vigenere.g10code.de> <20121107123432.GG11062@danbala.tuwien.ac.at> <87txt1v4wt.fsf@vigenere.g10code.de> <20121107150817.GK11062@danbala.tuwien.ac.at> Message-ID: <87k3txuxny.fsf@vigenere.g10code.de> On Wed, 7 Nov 2012 16:08, tk at giga.or.at said: > I think I don't understand what you see as the problem in the NetBSD > implementation. According to its man page, it should behave the same > as specified above. What behaves differently? Well, you said you need to fix the usage of dlerror. So, if the dlopen on NetBSD is okay, we would only need to put a call to dlerror() before the first dlsym(). >> more need for idea-stub.c and we may add include IDEA support directly. >> (That algorithm will probably never die - like Arcfour) > > That solution is fine with me, of course. I have put it on my list. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From tk at giga.or.at Wed Nov 7 18:46:11 2012 From: tk at giga.or.at (Thomas Klausner) Date: Wed, 7 Nov 2012 18:46:11 +0100 Subject: [PATCH 1/5] Only call dlerror() when dlsym() fails. In-Reply-To: <87k3txuxny.fsf@vigenere.g10code.de> References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-2-git-send-email-tk@giga.or.at> <87wqy01pke.fsf@vigenere.g10code.de> <20121105162638.GF11062@danbala.tuwien.ac.at> <87zk2vyypa.fsf@vigenere.g10code.de> <20121107123432.GG11062@danbala.tuwien.ac.at> <87txt1v4wt.fsf@vigenere.g10code.de> <20121107150817.GK11062@danbala.tuwien.ac.at> <87k3txuxny.fsf@vigenere.g10code.de> Message-ID: <20121107174611.GN11062@danbala.tuwien.ac.at> On Wed, Nov 07, 2012 at 06:32:01PM +0100, Werner Koch wrote: > Well, you said you need to fix the usage of dlerror. So, if the dlopen > on NetBSD is okay, we would only need to put a call to dlerror() before > the first dlsym(). I think that should be fine. Do you want a patch or is it less effort if you write it yourself and we don't have to go through FSF? :) > >> more need for idea-stub.c and we may add include IDEA support directly. > >> (That algorithm will probably never die - like Arcfour) > > > > That solution is fine with me, of course. > > I have put it on my list. Thanks! Thomas From wk at gnupg.org Wed Nov 7 21:34:57 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 Nov 2012 21:34:57 +0100 Subject: [PATCH 1/5] Only call dlerror() when dlsym() fails. In-Reply-To: <20121107174611.GN11062@danbala.tuwien.ac.at> (Thomas Klausner's message of "Wed, 7 Nov 2012 18:46:11 +0100") References: <1351360571-28331-1-git-send-email-tk@giga.or.at> <1351360571-28331-2-git-send-email-tk@giga.or.at> <87wqy01pke.fsf@vigenere.g10code.de> <20121105162638.GF11062@danbala.tuwien.ac.at> <87zk2vyypa.fsf@vigenere.g10code.de> <20121107123432.GG11062@danbala.tuwien.ac.at> <87txt1v4wt.fsf@vigenere.g10code.de> <20121107150817.GK11062@danbala.tuwien.ac.at> <87k3txuxny.fsf@vigenere.g10code.de> <20121107174611.GN11062@danbala.tuwien.ac.at> Message-ID: <87fw4lup72.fsf@vigenere.g10code.de> On Wed, 7 Nov 2012 18:46, tk at giga.or.at said: > I think that should be fine. Do you want a patch or is it less effort I'll put it in for the time until have backported the idea stuff. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Fri Nov 9 18:08:40 2012 From: hans at guardianproject.info (Hans of Guardian) Date: Fri, 9 Nov 2012 12:08:40 -0500 Subject: remaining gnupg changes for Android support Message-ID: Hey Werner, The attached patch is the last outstanding set of changes needed to get all of the GnuPG suite building for Android. While Android uses libiconv internally, it does not expose the system's libiconv for apps to use. That stuff is only accessible via the Java API. Therefore, I'm hoping to avoid using libiconv with gnupg on Android. I see that Windows support works without libiconv so the patch just uses that code for Android also. The one part that I didn't have a good grasp of what the Windows replacement functions, so I hacked in some placeholders for Android. I'm happy to revisit that code with your advice or just trust whatever you choose for the solution there. -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-android-fixes.patch Type: application/octet-stream Size: 3245 bytes Desc: not available URL: -------------- next part -------------- .hc From wk at gnupg.org Fri Nov 9 19:02:07 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 09 Nov 2012 19:02:07 +0100 Subject: remaining gnupg changes for Android support In-Reply-To: (Hans of Guardian's message of "Fri, 9 Nov 2012 12:08:40 -0500") References: Message-ID: <87mwyqac4g.fsf@gnupg.org> On Fri, 9 Nov 2012 18:08, hans at guardianproject.info said: > The one part that I didn't have a good grasp of what the Windows replacement functions, so I hacked in some placeholders for Android. I'm happy to revisit that code with your advice or just trust whatever you choose for the solution there. I'll be at fscons from tomorrow to Monday, thus I won't have network access all the time. But I should have time to review and apply your patch. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From casey.marshall at gmail.com Fri Nov 9 21:33:04 2012 From: casey.marshall at gmail.com (Casey Marshall) Date: Fri, 9 Nov 2012 14:33:04 -0600 Subject: Cross-VM Side Channels and Their Use to Extract Private Keys Message-ID: Today I found this paper, "Cross-VM Side Channels and Their Use to Extract Private Keys", available at http://blogs.rsa.com/juels/stealing-your-neighbors-keys-with-a-drinking-glass/. Are there any plans to harden GnuPG and libgcrypt against side-channel attacks? I understand GnuPG is not recommended for local multi-user deployments, but for better or worse, an increasing number of applications are being hosted in virtualized environments. Thanks, Casey From abel at guardianproject.info Sun Nov 11 21:15:12 2012 From: abel at guardianproject.info (Abel Luck) Date: Sun, 11 Nov 2012 20:15:12 +0000 Subject: pinentry for Android questions In-Reply-To: <87lifya4r4.fsf@vigenere.g10code.de> References: <9333EDAB-36A0-4061-8430-E27EC6C9D566@guardianproject.info> <4F5A26D8.9000309@ruhr-uni-bochum.de> <1E4A9464-47B4-4D8C-BDC4-62A210F83F95@guardianproject.info> <4F5A4812.3090603@ruhr-uni-bochum.de> <4F5ACBFB.1010102@guardianproject.info> <4F5B5DA7.8060608@ruhr-uni-bochum.de> <50592CA2.3090501@guardianproject.info> <87pq5bbtuw.fsf@vigenere.g10code.de> <5060D204.30400@guardianproject.info> <87lifya4r4.fsf@vigenere.g10code.de> Message-ID: <50A00750.1030301@guardianproject.info> Werner Koch: > On Mon, 24 Sep 2012 23:35, hans at guardianproject.info said: > >> then waits for the new process to contact 'system_server' via IPC, then >> requests the right Activity from the process. We can send the Intent, >> but we can't control the starting of the process. > > Okay, so a simple two way communication is not possible. > >> are proposing. I just think that the ideal solution would be having >> gpg-agent launch the GUI Activity using "am start", then that GUI >> Activity could talk directly to the gpg-agent UNIX socket, and that > > We use a simple stdin/stdout server for the pinentry because it reduces > the complexity in gpg-agent. The pinentry can't use the > ~/.gnupg/S.gpg-agent socket because that one is for the client's (gpg) > communication with the agent. If we would use that socket also for > pinentry communication, we would need to synchronize the actions of two > clients (the regular client and the pinentry). That defeats the idea of > having a simple and easy to audit communication with gpg-agent. > > Using an extra socket for pinentry would be possible but this also adds > more complexity. Thus I am very in favor of having a wrapper pinentry > to mediate between gpg-agent and an Android based pinentry. I hope > there is no limit on the number of processes on Android like we have on > WindowsCE. > > Adding such a daemonized version to the pinentry package and thus > re-using some of the pinentry logic is no problem. We don't require any > legal BS for pinentry. > > > Salam-Shalom, > > Werner > Hi Werner, Abel from Guardian Project here. I'm taking the lead on this task (pinentry on Android) for now, and I've a few questions I hope you can help me with. A quick recap: 1. Android has no X server 2. It is *impossible* to launch a GUI app from the CLI and communicate synchronously 3. It is *possible* to launch a GUI app in a non-blocking fashion from the CLI 4. We can communicate w/ the gui through a unix domain socket The goal then is to create a pinentry that launches a non-blocking gui (simple CLI command), then communicates over a unix domain socket with the Android app that interacts with the user. So, with that in mind I've been investigating the pinentry related gpg-agent options, and I have a few questions. How relevant are the following options to the above plan? --keep-tty --no-grab --allow-loopback-pinentry Could you elaborate more on the loopback mode, I don't quite understand its function from the documents. It seems this would be more feasible to implement as a modifier version of pinentry/pinentry[-curses].[c,h] Does that sound reasonable, or do you suggest a different codebase to use as a starting point? Thanks, Abel From wk at gnupg.org Mon Nov 12 12:58:00 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Nov 2012 12:58:00 +0100 Subject: pinentry for Android questions In-Reply-To: <50A00750.1030301@guardianproject.info> (Abel Luck's message of "Sun, 11 Nov 2012 20:15:12 +0000") References: <9333EDAB-36A0-4061-8430-E27EC6C9D566@guardianproject.info> <4F5A26D8.9000309@ruhr-uni-bochum.de> <1E4A9464-47B4-4D8C-BDC4-62A210F83F95@guardianproject.info> <4F5A4812.3090603@ruhr-uni-bochum.de> <4F5ACBFB.1010102@guardianproject.info> <4F5B5DA7.8060608@ruhr-uni-bochum.de> <50592CA2.3090501@guardianproject.info> <87pq5bbtuw.fsf@vigenere.g10code.de> <5060D204.30400@guardianproject.info> <87lifya4r4.fsf@vigenere.g10code.de> <50A00750.1030301@guardianproject.info> Message-ID: <878va78247.fsf@gnupg.org> Hi! On Sun, 11 Nov 2012 21:15, abel at guardianproject.info said: > The goal then is to create a pinentry that launches a non-blocking gui > (simple CLI command), then communicates over a unix domain socket with > the Android app that interacts with the user. very good. I believe that is the best option for now. If we later notice that we need to change something to save on certain resources, we can re-consider this. It is an internal API and thus easy to replace. > How relevant are the following options to the above plan? > --keep-tty That is X server specific. You can ignore it. > --no-grab Does not make sense. It mostly a debugging option for X. The grab keyboard and mouse thing should be replaced by Android's way of protecting PIN/passphrase widgets. > --allow-loopback-pinentry This is quite new and designed to be used by server applications. In fact. gpg2.1 has no support for it now. The idea is that an application using gpg-agent for passphrase entry, private key, or card operations can avoid the use of a pinentry and instead directly send the passphrase (via a callback mechanism). For example a web mail server could use this feature instead of resorting to the pinentry-wrapper hack. > It seems this would be more feasible to implement as a modifier version > of pinentry/pinentry[-curses].[c,h] Does that sound reasonable, or do > you suggest a different codebase to use as a starting point? Please use that code base and create a branch during the development phase. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 12 13:03:04 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Nov 2012 13:03:04 +0100 Subject: Cross-VM Side Channels and Their Use to Extract Private Keys In-Reply-To: (Casey Marshall's message of "Fri, 9 Nov 2012 14:33:04 -0600") References: Message-ID: <871ufz81vr.fsf@gnupg.org> On Fri, 9 Nov 2012 21:33, casey.marshall at gmail.com said: > I understand GnuPG is not recommended for local multi-user > deployments, but for better or worse, an increasing number of > applications are being hosted in virtualized environments. Here is a reply to a similar question: > My understanding is you should do your encryption in your own computer, > not in a virtual machine on someone else's computer. If so, maybe > what we need to do is explain this to the public more. That is also my opinion. If an attacker has access to your account or the hardware in any way (even only through virtualization), we have a "game over" condition. Sure it would be possible to work around some problems. Actually we use RSA blinding to mitigate threats which are based on a remote attacker (on the same LAN). In that case a workaround makes sense. The described attack is IMHO not a real world attack - if they are able to force actions on another virtual machine (running gpg in a loop for signing or encryption), they would have easier means to get at the private key. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 12 15:27:23 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Nov 2012 15:27:23 +0100 Subject: remaining gnupg changes for Android support In-Reply-To: (Hans of Guardian's message of "Fri, 9 Nov 2012 12:08:40 -0500") References: Message-ID: <87ip9a7v78.fsf@gnupg.org> On Fri, 9 Nov 2012 18:08, hans at guardianproject.info said: > to use. That stuff is only accessible via the Java API. Therefore, > I'm hoping to avoid using libiconv with gnupg on Android. I see that IIRC, it used to work this way on WindowsCE. Thus your patch is mostly fine. I can't remember why I used the stub functions on WindowsCE, probably to avoid to many ifdefs. Thus doing the same for Android is fine. Note however, that under plain Windows we dlopen libiconv to make it not a hard dependency. I have changed your patch a bit, though. Please try the attached version before I commit it to master. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Nov 12 15:38:51 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Nov 2012 15:38:51 +0100 Subject: remaining gnupg changes for Android support In-Reply-To: <87ip9a7v78.fsf@gnupg.org> (Werner Koch's message of "Mon, 12 Nov 2012 15:27:23 +0100") References: <87ip9a7v78.fsf@gnupg.org> Message-ID: <87ehjy7uo4.fsf@gnupg.org> Here we go: >From a1fa77e34574b309b20fa2b1ef8be5d56e59c66f Mon Sep 17 00:00:00 2001 From: Werner Koch Date: Mon, 12 Nov 2012 15:18:49 +0100 Subject: [PATCH] utf8conv.c: Add hacks for Android. * common/utf8conv.c [HAVE_ANDROID_SYSTEM]: Do not include iconv.h. (iconv_open, iconv_close, load_libiconv) [HAVE_ANDROID_SYSTEM]: New dummy functions. (set_native_charset) [HAVE_ANDROID_SYSTEM]: Force use of "utf-8". (jnlib_iconv_open) [HAVE_ANDROID_SYSTEM]: Act the same as under W32. (jnlib_iconv) [HAVE_ANDROID_SYSTEM]: Ditto. (jnlib_iconv_close) [HAVE_ANDROID_SYSTEM]: Ditto. -- Co-authored-by: Hans of Guardian --- common/utf8conv.c | 69 ++++++++++++++++++++++++++++++++++++++++++---------- 1 files changed, 55 insertions(+), 14 deletions(-) diff --git a/common/utf8conv.c b/common/utf8conv.c index 1d64933..a45bb63 100644 --- a/common/utf8conv.c +++ b/common/utf8conv.c @@ -38,7 +38,7 @@ #include #endif #include -#ifndef HAVE_W32_SYSTEM +#if !defined HAVE_W32_SYSTEM && !defined HAVE_ANDROID_SYSTEM # include #endif @@ -56,9 +56,48 @@ static int no_translation; /* Set to true if we let simply pass through. */ static int use_iconv; /* iconv comversion fucntions required. */ +#ifdef HAVE_ANDROID_SYSTEM +/* Fake stuff to get things building. */ +typedef void *iconv_t; +#define ICONV_CONST + +static iconv_t +iconv_open (const char *tocode, const char *fromcode) +{ + (void)tocode; + (void)fromcode; + return (iconv_t)(-1); +} + +static size_t +iconv (iconv_t cd, char **inbuf, size_t *inbytesleft, + char **outbuf, size_t *outbytesleft) +{ + (void)cd; + (void)inbuf; + (void)inbytesleft; + (void)outbuf; + (void)outbytesleft; + return (size_t)(0); +} + +static int +iconv_close (iconv_t cd) +{ + (void)cd; + return 0; +} + + +static int +load_libiconv (void) +{ + return -1; +} + +#elif defined HAVE_W32_SYSTEM /* Under W32 we dlopen the iconv dll and don't require any iconv related headers at all. However we need to define some stuff. */ -#ifdef HAVE_W32_SYSTEM typedef void *iconv_t; #ifndef ICONV_CONST #define ICONV_CONST @@ -170,7 +209,9 @@ set_native_charset (const char *newset) if (!newset) { -#ifdef HAVE_W32_SYSTEM +#ifdef HAVE_ANDROID_SYSTEM + newset = "utf-8"; +#elif defined HAVE_W32_SYSTEM static char codepage[30]; unsigned int cpno; const char *aliases; @@ -218,7 +259,7 @@ set_native_charset (const char *newset) } } -#else /*!HAVE_W32_SYSTEM*/ +#else /*!HAVE_W32_SYSTEM && !HAVE_ANDROID_SYSTEM*/ #ifdef HAVE_LANGINFO_CODESET newset = nl_langinfo (CODESET); @@ -252,7 +293,7 @@ set_native_charset (const char *newset) } newset = codepage; #endif /*!HAVE_LANGINFO_CODESET*/ -#endif /*!HAVE_W32_SYSTEM*/ +#endif /*!HAVE_W32_SYSTEM && !HAVE_ANDROID_SYSTEM*/ } full_newset = newset; @@ -291,10 +332,10 @@ set_native_charset (const char *newset) { iconv_t cd; -#ifdef HAVE_W32_SYSTEM +#if defined HAVE_W32_SYSTEM || defined HAVE_ANDROID_SYSTEM if (load_libiconv ()) return -1; -#endif /*HAVE_W32_SYSTEM*/ +#endif /*HAVE_W32_SYSTEM || HAVE_ANDROID_SYSTEM*/ cd = iconv_open (full_newset, "utf-8"); if (cd == (iconv_t)-1) @@ -717,10 +758,10 @@ utf8_to_native (const char *string, size_t length, int delim) jnlib_iconv_t jnlib_iconv_open (const char *tocode, const char *fromcode) { -#ifdef HAVE_W32_SYSTEM +#if defined HAVE_W32_SYSTEM || defined HAVE_ANDROID_SYSTEM if (load_libiconv ()) return (jnlib_iconv_t)(-1); -#endif /*HAVE_W32_SYSTEM*/ +#endif /*HAVE_W32_SYSTEM || HAVE_ANDROID_SYSTEM*/ return (jnlib_iconv_t)iconv_open (tocode, fromcode); } @@ -734,10 +775,10 @@ jnlib_iconv (jnlib_iconv_t cd, char **outbuf, size_t *outbytesleft) { -#ifdef HAVE_W32_SYSTEM +#if defined HAVE_W32_SYSTEM || defined HAVE_ANDROID_SYSTEM if (load_libiconv ()) return 0; -#endif /*HAVE_W32_SYSTEM*/ +#endif /*HAVE_W32_SYSTEM || HAVE_ANDROID_SYSTEM*/ return iconv ((iconv_t)cd, (char**)inbuf, inbytesleft, outbuf, outbytesleft); } @@ -747,10 +788,10 @@ jnlib_iconv (jnlib_iconv_t cd, int jnlib_iconv_close (jnlib_iconv_t cd) { -#ifdef HAVE_W32_SYSTEM +#if defined HAVE_W32_SYSTEM || defined HAVE_ANDROID_SYSTEM if (load_libiconv ()) return 0; -#endif /*HAVE_W32_SYSTEM*/ +#endif /*HAVE_W32_SYSTEM || HAVE_ANDROID_SYSTEM*/ return iconv_close ((iconv_t)cd); } @@ -826,4 +867,4 @@ utf8_to_wchar (const char *string) } return result; } -#endif /*HAVE_W32_SYSTEM*/ +#endif /*HAVE_W32_SYSTEM || HAVE_ANDROID_SYSTEM*/ -- 1.7.4.1 -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ueno at unixuser.org Wed Nov 14 08:43:22 2012 From: ueno at unixuser.org (Daiki Ueno) Date: Wed, 14 Nov 2012 16:43:22 +0900 Subject: using main key ID as cache key? Message-ID: Hi, We've recently had a little discussion about the cache behavior of gpg-agent: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12696#29 Currently, gpg-agent PKSIGN / PKDECRYPT commands maintain passphrases per subkey, while other gpg commands (gpg --gen-key and gpg --edit-key) assume the same passphrase be shared among subkeys. Doesn't it make sense that those gpg-agent commands use the main key ID as cache key? I'm attaching an experimental patch (to the git master). -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-agent-Use-main-keygrip-as-cache-key-for-passphrase-c.patch Type: text/x-patch Size: 11192 bytes Desc: not available URL: -------------- next part -------------- Regards, -- Daiki Ueno From wk at gnupg.org Wed Nov 14 14:21:17 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Nov 2012 14:21:17 +0100 Subject: using main key ID as cache key? In-Reply-To: (Daiki Ueno's message of "Wed, 14 Nov 2012 16:43:22 +0900") References: Message-ID: <87ip98jp6a.fsf@vigenere.g10code.de> On Wed, 14 Nov 2012 08:43, ueno at unixuser.org said: > Currently, gpg-agent PKSIGN / PKDECRYPT commands maintain passphrases > per subkey, while other gpg commands (gpg --gen-key and gpg --edit-key) > assume the same passphrase be shared among subkeys. That is not correct. The GPG key generation creates the 3 standard keys with the same passphrase. All other commands should work correctly if the primary and the subkeys have different passphrases. > Doesn't it make sense that those gpg-agent commands use the main key ID > as cache key? I'm attaching an experimental patch (to the git master). (It depends on your threat model) For ssh keys it has been suggested to try unprotecting all ssh keys at once if one has been unprotected. A rationale for this is that often different ssh keys have the same passphrase. Now if malware already knows one passphrase, it doesn't matter if the other keys are also unprotected (or alias a cache entry). The same is true for the gpg primary and subkeys. A simple implementation would just try to decrypt all keys if a valid passphrase is given for one key. With many keys, that won't fly because the decryption is designed to take some time. For ssh keys, the sshcontrol file could be used to limit the keys. For gpg, we would need a way to link certain keys together. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wavexx at users.sourceforge.net Wed Nov 14 15:27:47 2012 From: wavexx at users.sourceforge.net (Yuri D'Elia) Date: Wed, 14 Nov 2012 15:27:47 +0100 Subject: ESC accelerator support in pinentry-gtk-2 Message-ID: Hi everyone. I was having a look at this Debian bug entry: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516489 ie: ESC does not trigger cancel (which is kind of expected in all dialogs). I checked out the sources from git and prepared the attached patch. It seems like that pinentry-gtk had already this behavior, but got lost in gtk-2. Bests. -------------- next part -------------- A non-text attachment was scrubbed... Name: pinentry-gtk2.patch Type: text/x-patch Size: 1810 bytes Desc: not available URL: From ueno at unixuser.org Thu Nov 15 10:16:26 2012 From: ueno at unixuser.org (Daiki Ueno) Date: Thu, 15 Nov 2012 18:16:26 +0900 Subject: using main key ID as cache key? In-Reply-To: <87ip98jp6a.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 14 Nov 2012 14:21:17 +0100") References: <87ip98jp6a.fsf@vigenere.g10code.de> Message-ID: Werner Koch writes: > That is not correct. The GPG key generation creates the 3 standard > keys with the same passphrase. All other commands should work > correctly if the primary and the subkeys have different passphrases. Is there a way to set different passphrases to the primary and subkeys? > For ssh keys it has been suggested to try unprotecting all ssh keys at > once if one has been unprotected. A rationale for this is that often > different ssh keys have the same passphrase. Now if malware already > knows one passphrase, it doesn't matter if the other keys are also > unprotected (or alias a cache entry). The same is true for the gpg > primary and subkeys. I see. > A simple implementation would just try to decrypt all keys if a valid > passphrase is given for one key. With many keys, that won't fly > because the decryption is designed to take some time. For ssh keys, > the sshcontrol file could be used to limit the keys. Perhaps I don't understand the idea fully, but in the above you mean the information that indicates which secret subkeys share the same passphrase shouldn't be public, right? If so, > For gpg, we would need a way to link certain keys together. The "links" also should be hidden? An idea might be to embed some hints (like, a list of other subkeys in the same group) in each unprotected key data. Regards, -- Daiki Ueno From xi.wang at gmail.com Thu Nov 15 09:27:23 2012 From: xi.wang at gmail.com (Xi Wang) Date: Thu, 15 Nov 2012 03:27:23 -0500 Subject: [PATCH gpgme] Fix error handling in _gpgme_parse_status(). Message-ID: <1352968043-19063-1-git-send-email-xi.wang@gmail.com> The following error handling is broken. gpgme_status_code_t r = _gpgme_parse_status(...); if (r >= 0) { ... } Even though _gpgme_parse_status() returns -1 on error, the return type gpgme_status_code_t is unsigned, and thus (r >= 0) is always true. This patch changes the return type to int. --- Another way to fix this problem is to add -1 to enum gpgme_status_code_t. Then the compiler should consider the enum type as signed. --- src/engine-gpg.c | 2 +- src/status-table.c | 2 +- src/util.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/engine-gpg.c b/src/engine-gpg.c index 4c7a8b2..5635e91 100644 --- a/src/engine-gpg.c +++ b/src/engine-gpg.c @@ -1022,7 +1022,7 @@ read_status (engine_gpg_t gpg) && buffer[9] >= 'A' && buffer[9] <= 'Z') { char *rest; - gpgme_status_code_t r; + int r; rest = strchr (buffer + 9, ' '); if (!rest) diff --git a/src/status-table.c b/src/status-table.c index 8060bdb..3434951 100644 --- a/src/status-table.c +++ b/src/status-table.c @@ -146,7 +146,7 @@ _gpgme_status_init (void) } -gpgme_status_code_t +int _gpgme_parse_status (const char *name) { struct status_table_s t, *r; diff --git a/src/util.h b/src/util.h index cf18099..5c2b34f 100644 --- a/src/util.h +++ b/src/util.h @@ -140,7 +140,7 @@ gpgme_error_t _gpgme_getenv (const char *name, char **value); /*-- status-table.c --*/ /* Convert a status string to a status code. */ void _gpgme_status_init (void); -gpgme_status_code_t _gpgme_parse_status (const char *name); +int _gpgme_parse_status (const char *name); #ifdef HAVE_W32_SYSTEM -- 1.7.10.4 From xi.wang at gmail.com Thu Nov 15 09:27:48 2012 From: xi.wang at gmail.com (Xi Wang) Date: Thu, 15 Nov 2012 03:27:48 -0500 Subject: [PATCH gpgme] Remove suspicious semicolon in _gpgme_encode_percent_string(). Message-ID: <1352968068-20511-1-git-send-email-xi.wang@gmail.com> --- Looks like existing clients call this function with len==0, so this issue is never triggered. --- src/conversion.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conversion.c b/src/conversion.c index 356200c..b47d6de 100644 --- a/src/conversion.c +++ b/src/conversion.c @@ -282,7 +282,7 @@ _gpgme_encode_percent_string (const char *src, char **destp, size_t len) /* Set up the destination buffer. */ if (len) { - if (len < destlen); + if (len < destlen) return gpg_error (GPG_ERR_INTERNAL); dest = *destp; -- 1.7.10.4 From xi.wang at gmail.com Thu Nov 15 09:29:06 2012 From: xi.wang at gmail.com (Xi Wang) Date: Thu, 15 Nov 2012 03:29:06 -0500 Subject: [PATCH libassuan] Fix NULL pointer dereference in _assuan_error(). Message-ID: <1352968146-22465-1-git-send-email-xi.wang@gmail.com> Multiple functions invoke _assuan_error() with a NULL ctx. if (!ctx) return _assuan_error (ctx, GPG_ERR_ASS_INV_VALUE); Since _assuan_error() dereferences ctx, this patch adds a NULL check. --- JOOC, did they ever triggered NULL pointer dereferences? Some functions seem to explicitly allow NULL ctx, such as assuan_sendfd(): /* It is explicitly allowed to use (NULL, -1) as a runtime test to check whether descriptor passing is available. */ If a caller follows this comment, it's likely to trigger a bug. --- src/assuan-defs.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/assuan-defs.h b/src/assuan-defs.h index f6cb9b4..161a28f 100644 --- a/src/assuan-defs.h +++ b/src/assuan-defs.h @@ -55,7 +55,8 @@ #define LINELENGTH ASSUAN_LINELENGTH /* Generate an error code specific to a context. */ -#define _assuan_error(ctx, errcode) gpg_err_make ((ctx)->err_source, errcode) +#define _assuan_error(ctx, errcode) \ + gpg_err_make ((ctx) ? (ctx)->err_source : GPG_ERR_SOURCE_DEFAULT, errcode) struct cmdtbl_s -- 1.7.10.4 From mailinglisten at hauke-laging.de Thu Nov 15 10:29:19 2012 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 15 Nov 2012 10:29:19 +0100 Subject: using main key ID as cache key? In-Reply-To: References: <87ip98jp6a.fsf@vigenere.g10code.de> Message-ID: <3299213.yqREafbYBh@inno> Am Do 15.11.2012, 18:16:26 schrieb Daiki Ueno: > Is there a way to set different passphrases to the primary and subkeys? Yes but it's not the pleasant one... http://atom.smasher.org/gpg/gpg-passwords.txt Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 572 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Thu Nov 15 11:09:04 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Nov 2012 11:09:04 +0100 Subject: [PATCH gpgme] Fix error handling in _gpgme_parse_status(). In-Reply-To: <1352968043-19063-1-git-send-email-xi.wang@gmail.com> (Xi Wang's message of "Thu, 15 Nov 2012 03:27:23 -0500") References: <1352968043-19063-1-git-send-email-xi.wang@gmail.com> Message-ID: <87pq3fch4v.fsf@vigenere.g10code.de> On Thu, 15 Nov 2012 09:27, xi.wang at gmail.com said: > Even though _gpgme_parse_status() returns -1 on error, the return type > gpgme_status_code_t is unsigned, and thus (r >= 0) is always true. How do you come to the impression that gpgme_status_code_t is an unsigned integer? It is an enumeration and those are compatible with a (signed) integer. Although some systems use different sizes for the enumeration integer type, I have never seen a claim that it is unsigned. What is the problem you want solve? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Nov 15 11:28:29 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Nov 2012 11:28:29 +0100 Subject: [PATCH libassuan] Fix NULL pointer dereference in _assuan_error(). In-Reply-To: <1352968146-22465-1-git-send-email-xi.wang@gmail.com> (Xi Wang's message of "Thu, 15 Nov 2012 03:29:06 -0500") References: <1352968146-22465-1-git-send-email-xi.wang@gmail.com> Message-ID: <87haorcg8i.fsf@vigenere.g10code.de> On Thu, 15 Nov 2012 09:29, xi.wang at gmail.com said: > JOOC, did they ever triggered NULL pointer dereferences? Some functions > seem to explicitly allow NULL ctx, such as assuan_sendfd(): I can't remember and would need to search for it. > /* Generate an error code specific to a context. */ > -#define _assuan_error(ctx, errcode) gpg_err_make ((ctx)->err_source, errcode) > +#define _assuan_error(ctx, errcode) \ > + gpg_err_make ((ctx) ? (ctx)->err_source : GPG_ERR_SOURCE_DEFAULT, errcode) We don't have a default source id for libassuan. I may take this as an opportunity to add one for Libassuan. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From abel at guardianproject.info Thu Nov 15 14:21:18 2012 From: abel at guardianproject.info (Abel Luck) Date: Thu, 15 Nov 2012 13:21:18 +0000 Subject: Properly detecting git revision Message-ID: <50A4EC4E.6060604@guardianproject.info> Hi, In many of gnupg's libraries you detect the git revision number in configure.ac using the command: git branch -v 2>/dev/null | awk '/^\* / {printf "%s",$3}' This works well enough when you are in a normal state, but when the repo is a submodule the state of the repo is not in a branch, example: (libgpg-error as submodule) $ git batch -v * (no branch) a7eb1be Remove non-source file from the repo. master 09544df Add the mailing list to AUTHORS. This results in awk detecting the revision number as "branch)", which of course isn't good, moreover, when doing Android builds m4 chokes on the output aborting the build. The proper way, imho, of detecting the revision number is: git rev-parse --short HEAD 2> /dev/null | tr -d '\n' The result is exactly the same, but relies on less sketchy parsing of git output. Shall I submit patches for all the affected repos? ~abel From abel at guardianproject.info Thu Nov 15 16:00:58 2012 From: abel at guardianproject.info (Abel Luck) Date: Thu, 15 Nov 2012 15:00:58 +0000 Subject: ttyname in gpgme when running Android In-Reply-To: <87d307dhvi.fsf@vigenere.g10code.de> References: <5087260B.9050302@guardianproject.info> <508739BA.6040306@guardianproject.info> <87pq48c7xh.fsf@vigenere.g10code.de> <5087F060.70600@guardianproject.info> <87d307dhvi.fsf@vigenere.g10code.de> Message-ID: <50A503AA.8060402@guardianproject.info> Werner Koch: > On Wed, 24 Oct 2012 15:42, hans at guardianproject.info said: > >> Sure, that should work fine for the autoconf stuff, but in ttyname.c, it'll >> need to either have that __ANDROID__ macro, or a macro like FAKE_TTYNAME which >> is defined for both Win32 and Android. > > Pull master. I basically used HAVE_ANDROID_SYSTEM instead of > __ANDROID__. This is to make it similar to Windows where we also don't > use the __WIN32__ macro. > > > Shalom-Salam, > > Werner > So this worked well for gpgme, but gnupg still thinks it has a working ttyname(). gnupg/configure.ac is doing a naive function check for ttyname, which succeeds, but of course on Android ttyname is a stub. I suspect we need the same REPLACE_TTYNAME magic in gnupg that we used in gpgme. My m4 foo is decidedly lacking. Is there any chance you could produce a fix for this? ~abel From wk at gnupg.org Thu Nov 15 19:09:52 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Nov 2012 19:09:52 +0100 Subject: Properly detecting git revision In-Reply-To: <50A4EC4E.6060604@guardianproject.info> (Abel Luck's message of "Thu, 15 Nov 2012 13:21:18 +0000") References: <50A4EC4E.6060604@guardianproject.info> Message-ID: <87fw4abuvj.fsf@vigenere.g10code.de> On Thu, 15 Nov 2012 14:21, abel at guardianproject.info said: > The proper way, imho, of detecting the revision number is: > > git rev-parse --short HEAD 2> /dev/null | tr -d '\n' Probably. > Shall I submit patches for all the affected repos? Let me do it. It is easier than to check that the patches are okay. And well, any non-working stuff will be my fault ;-). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From xi.wang at gmail.com Thu Nov 15 19:20:35 2012 From: xi.wang at gmail.com (Xi Wang) Date: Thu, 15 Nov 2012 13:20:35 -0500 Subject: [PATCH gpgme] Fix error handling in _gpgme_parse_status(). In-Reply-To: <87pq3fch4v.fsf@vigenere.g10code.de> References: <1352968043-19063-1-git-send-email-xi.wang@gmail.com> <87pq3fch4v.fsf@vigenere.g10code.de> Message-ID: <50A53273.7000704@gmail.com> On 11/15/12 5:09 AM, Werner Koch wrote: > On Thu, 15 Nov 2012 09:27, xi.wang at gmail.com said: > >> Even though _gpgme_parse_status() returns -1 on error, the return type >> gpgme_status_code_t is unsigned, and thus (r >= 0) is always true. > > How do you come to the impression that gpgme_status_code_t is an > unsigned integer? It is an enumeration and those are compatible with a > (signed) integer. Although some systems use different sizes for the > enumeration integer type, I have never seen a claim that it is unsigned. The storage of an enum is compatible with int, but the signedness is very tricky. Most compilers seem to decide the signedness of an enum type based on its value range: if all the enum values are non-negative (such as GPGME_STATUS_*), then the enum type is _unsigned_. Check out the assembly of the code below, using gcc/clang/icc on x86. typedef enum { GPGME_STATUS_EOF = 0, GPGME_STATUS_ENTER = 1, GPGME_STATUS_DECRYPTION_INFO = 85 } gpgme_status_code_t; int foo(gpgme_status_code_t code) { return code >= 0; } The resulting assembly is: movl $1, %eax ret It means gpgme_status_code_t is treated as unsigned. We could add -1 to the enum value set; in that case compilers considers the enum type as signed. > What is the problem you want solve? The function _gpgme_parse_status() returns a gpgme_status_code_t, and it also returns -1 on error. Some client code treats the return type as signed for error handling (see readstatus() at src/engine-gpg.c:1034), which doesn't work. It's better to fix this by changing the return type to signed int, or adding -1 to the enum value set. - xi From wk at gnupg.org Thu Nov 15 19:17:28 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Nov 2012 19:17:28 +0100 Subject: ttyname in gpgme when running Android In-Reply-To: <50A503AA.8060402@guardianproject.info> (Abel Luck's message of "Thu, 15 Nov 2012 15:00:58 +0000") References: <5087260B.9050302@guardianproject.info> <508739BA.6040306@guardianproject.info> <87pq48c7xh.fsf@vigenere.g10code.de> <5087F060.70600@guardianproject.info> <87d307dhvi.fsf@vigenere.g10code.de> <50A503AA.8060402@guardianproject.info> Message-ID: <87boeybuiv.fsf@vigenere.g10code.de> On Thu, 15 Nov 2012 16:00, abel at guardianproject.info said: > My m4 foo is decidedly lacking. Is there any chance you could produce a > fix for this? Will do. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From xi.wang at gmail.com Thu Nov 15 19:25:52 2012 From: xi.wang at gmail.com (Xi Wang) Date: Thu, 15 Nov 2012 13:25:52 -0500 Subject: [PATCH libassuan] Fix NULL pointer dereference in _assuan_error(). In-Reply-To: <87haorcg8i.fsf@vigenere.g10code.de> References: <1352968146-22465-1-git-send-email-xi.wang@gmail.com> <87haorcg8i.fsf@vigenere.g10code.de> Message-ID: <50A533B0.9040105@gmail.com> On 11/15/12 5:28 AM, Werner Koch wrote: >> /* Generate an error code specific to a context. */ >> -#define _assuan_error(ctx, errcode) gpg_err_make ((ctx)->err_source, errcode) >> +#define _assuan_error(ctx, errcode) \ >> + gpg_err_make ((ctx) ? (ctx)->err_source : GPG_ERR_SOURCE_DEFAULT, errcode) > > We don't have a default source id for libassuan. I may take this as an > opportunity to add one for Libassuan. Sounds great. :) Do you want me to send a v2? - xi From wk at gnupg.org Thu Nov 15 21:52:44 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Nov 2012 21:52:44 +0100 Subject: [PATCH gpgme] Fix error handling in _gpgme_parse_status(). In-Reply-To: <50A53273.7000704@gmail.com> (Xi Wang's message of "Thu, 15 Nov 2012 13:20:35 -0500") References: <1352968043-19063-1-git-send-email-xi.wang@gmail.com> <87pq3fch4v.fsf@vigenere.g10code.de> <50A53273.7000704@gmail.com> Message-ID: <87wqxma8rn.fsf@vigenere.g10code.de> On Thu, 15 Nov 2012 19:20, xi.wang at gmail.com said: > The storage of an enum is compatible with int, but the signedness is > very tricky. Now I see what you are meaning. The test is optimized out. I am used to see something like warning: comparison of unsigned expression >= 0 is always true in such cases but that does not happen with GPGME. The reason is that, for unknown reasons, GPGME does not test for gcc flags in configure and uses way too less warning switches. This definitely needs to be fixed. > It's better to fix this by changing the return type to signed int, or Right that is how I would have solved this too. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Nov 15 21:53:25 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Nov 2012 21:53:25 +0100 Subject: [PATCH libassuan] Fix NULL pointer dereference in _assuan_error(). In-Reply-To: <50A533B0.9040105@gmail.com> (Xi Wang's message of "Thu, 15 Nov 2012 13:25:52 -0500") References: <1352968146-22465-1-git-send-email-xi.wang@gmail.com> <87haorcg8i.fsf@vigenere.g10code.de> <50A533B0.9040105@gmail.com> Message-ID: <87sj8aa8qi.fsf@vigenere.g10code.de> On Thu, 15 Nov 2012 19:25, xi.wang at gmail.com said: > Sounds great. :) Do you want me to send a v2? No thanks, I take care of it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ueno at unixuser.org Fri Nov 16 10:01:35 2012 From: ueno at unixuser.org (Daiki Ueno) Date: Fri, 16 Nov 2012 18:01:35 +0900 Subject: using main key ID as cache key? In-Reply-To: <3299213.yqREafbYBh@inno> (Hauke Laging's message of "Thu, 15 Nov 2012 10:29:19 +0100") References: <87ip98jp6a.fsf@vigenere.g10code.de> <3299213.yqREafbYBh@inno> Message-ID: Hauke Laging writes: >> Is there a way to set different passphrases to the primary and subkeys? > > Yes but it's not the pleasant one... > > http://atom.smasher.org/gpg/gpg-passwords.txt Thanks, but it is indeed complicated... Isn't it easier to modify the GnuPG source code? Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-users-to-specify-different-passphrases-for-sub.patch Type: text/x-patch Size: 2070 bytes Desc: not available URL: From kf at sumptuouscapital.com Sun Nov 18 19:08:32 2012 From: kf at sumptuouscapital.com (Kristian Fiskerstrand) Date: Sun, 18 Nov 2012 19:08:32 +0100 Subject: [PATCH libgcrypt] * gcrypt.h.in: Set appropriate algo id for ECDSA and ECDH Message-ID: <20121118180832.GA24953@sumptuouscapital.com> * gcrypt.h.in: Set appropriate algo id for ECDSA and ECDH -- Currently a request for e.g. gcry_pk_algo_name with argument 18 or 19 will return "?" rather than the appropriate name for the algorithm. Setting the correct IDs fixes this behavior. Signed-off-by: Kristian Fiskerstrand --- src/gcrypt.h.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gcrypt.h.in b/src/gcrypt.h.in index 1e9d11d..a7956b2 100644 --- a/src/gcrypt.h.in +++ b/src/gcrypt.h.in @@ -838,8 +838,8 @@ enum gcry_pk_algos GCRY_PK_ELG_E = 16, GCRY_PK_DSA = 17, GCRY_PK_ELG = 20, - GCRY_PK_ECDSA = 301, - GCRY_PK_ECDH = 302 + GCRY_PK_ECDSA = 19, + GCRY_PK_ECDH = 18 }; /* Flags describing usage capabilities of a PK algorithm. */ -- 1.7.9.5 From wk at gnupg.org Mon Nov 19 08:35:58 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Nov 2012 08:35:58 +0100 Subject: [PATCH libgcrypt] * gcrypt.h.in: Set appropriate algo id for ECDSA and ECDH In-Reply-To: <20121118180832.GA24953@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Sun, 18 Nov 2012 19:08:32 +0100") References: <20121118180832.GA24953@sumptuouscapital.com> Message-ID: <87pq3a6o4h.fsf@vigenere.g10code.de> On Sun, 18 Nov 2012 19:08, kf at sumptuouscapital.com said: > Currently a request for e.g. gcry_pk_algo_name with argument > 18 or 19 will return "?" rather than the appropriate name for the 18 and 19 are not assigned. Thus a question mark is returned. > - GCRY_PK_ECDSA = 301, > - GCRY_PK_ECDH = 302 > + GCRY_PK_ECDSA = 19, > + GCRY_PK_ECDH = 18 You are going to change the ABI for no good reason! Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Mon Nov 19 09:40:39 2012 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 19 Nov 2012 09:40:39 +0100 Subject: [PATCH libgcrypt] * gcrypt.h.in: Set appropriate algo id for ECDSA and ECDH In-Reply-To: <87pq3a6o4h.fsf@vigenere.g10code.de> References: <20121118180832.GA24953@sumptuouscapital.com> <87pq3a6o4h.fsf@vigenere.g10code.de> Message-ID: <50A9F087.1070700@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/19/2012 08:35 AM, Werner Koch wrote: > On Sun, 18 Nov 2012 19:08, kf at sumptuouscapital.com said: > >> Currently a request for e.g. gcry_pk_algo_name with argument 18 >> or 19 will return "?" rather than the appropriate name for the > > 18 and 19 are not assigned. Thus a question mark is returned. > Thanks for the clarification. I was under the impression that this happened with RFC6637, but I reckon that this has not been formally accepted yet and still remain in a proposed status. FWIW, the "?" is then passed along to GnuPG and is used for e.g gpg2 --search kf at sumptuouscapital.com (key 0x542CA00B) , when querying subset.pool.sks-keyservers.net (which require keyservers to be upgraded to SKS 1.1.4 or higher, that has the draft version of RFC6637 implemented). I just noticed this while playing around with adding SSL/TLS to the dirmngr for hkps support. - -- - ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk - ---------------------------- "I never worry about action, but only inaction." (Winston Churchill) - ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ - ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.0-beta95 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJQqfCDAAoJEAt/i2Dj7frjoEAP/jx9IT+2ZrwX+zXRt9OUu/O2 IFEtcnxq5y+2cqnQZecz/iUx5NXp9M9pbU+GrYFCjeWKux8bj3OAQ6g7lIINX5yC yFLwNyG3L/JG7Bh48jLkOWg/SWKIxaeN8Zi2iwY8FM6EkRXUGX921+LeWZg/D5/S u/i1QK89IwLOrNBbliJ/dPZoIqELvN89CpyjbDOYJmFoA0qWgT6/0p1DazByiTsw A7U2yGnx0/o+EFRA5toV9KKmaozj9wj7AGLSIrBlWdE3DVRiIdAU00QyAm8MyBX3 4SCdlCEgfDuASGmE7q7YyBt+btCX8hOn01a31PuTzLTSSpSxCt2shZe+BbxGbhbg pk+5b/aXjjWbn76L7Vsdy5LdcDKmrnqBQA771CdvF9sb870XV9sjiKm47Te1x5KG O5wbAH2UmtOBKworrf0jKd7wBvWuRzX5iGdsAImgVHWlmoGVyq+yHmx2DfiVcUiV WwEbCm1XZmWBsgV5cTLHVoNdBGIisOozXNjLPVyDqOZX2MWi0IAStgTaZWMBvx+9 o7yRdXd+yzf/sGgnVTRhTScPajIFjYkqsx0sGiEN6vjzPXe+SB72p4g3uyPwWmyv 8ehM7BTu+eJoiT3eRb726QeijfnSE+fcKWYWibts9+7FK5KDBC6wg/GrpkXr/rJs /Mot4l9hnVOIB8cwHmLS =7L7G -----END PGP SIGNATURE----- From wk at gnupg.org Mon Nov 19 19:06:43 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Nov 2012 19:06:43 +0100 Subject: [PATCH libgcrypt] * gcrypt.h.in: Set appropriate algo id for ECDSA and ECDH In-Reply-To: <50A9F087.1070700@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Mon, 19 Nov 2012 09:40:39 +0100") References: <20121118180832.GA24953@sumptuouscapital.com> <87pq3a6o4h.fsf@vigenere.g10code.de> <50A9F087.1070700@sumptuouscapital.com> Message-ID: <87vcd1jwlo.fsf@vigenere.g10code.de> On Mon, 19 Nov 2012 09:40, kristian.fiskerstrand at sumptuouscapital.com said: > Thanks for the clarification. I was under the impression that this > happened with RFC6637, but I reckon that this has not been formally You patch was against Libgcrypt and not against GnuPG. Libgcrypt does not know about OpenPGP or any other protocol. It is historical coincidence that some algorithm numbers in Libgcrypt match the OpenPGP specs. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Mon Nov 19 19:26:45 2012 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Mon, 19 Nov 2012 19:26:45 +0100 Subject: [PATCH libgcrypt] * gcrypt.h.in: Set appropriate algo id for ECDSA and ECDH In-Reply-To: <87vcd1jwlo.fsf@vigenere.g10code.de> References: <20121118180832.GA24953@sumptuouscapital.com> <87pq3a6o4h.fsf@vigenere.g10code.de> <50A9F087.1070700@sumptuouscapital.com> <87vcd1jwlo.fsf@vigenere.g10code.de> Message-ID: <50AA79E5.7090207@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/19/2012 07:06 PM, Werner Koch wrote: > On Mon, 19 Nov 2012 09:40, > kristian.fiskerstrand at sumptuouscapital.com said: > >> Thanks for the clarification. I was under the impression that >> this happened with RFC6637, but I reckon that this has not been >> formally > > You patch was against Libgcrypt and not against GnuPG. Libgcrypt > does not know about OpenPGP or any other protocol. It is > historical coincidence that some algorithm numbers in Libgcrypt > match the OpenPGP specs. Fair enough, but GnuPG is getting this from libgcrypt in keyserver.c on line 509 which use const char *str = gcry_pk_algo_name (keyrec->type); Currently it return "?" for ECDSA keys for a --search request as shown in #Snippet 1# below. The patch solved this for me as shown in #Snippet 2#, but feel free to direct me to a more appropriate solution. ## Snippet 1 ## (1) Kristian Fiskerstrand Kristian Fiskerstrand 521 bit ? key 542CA00B, created: 2012-10-07 ## Snippet 2 ## (1) Kristian Fiskerstrand Kristian Fiskerstrand 521 bit ECDSA key 542CA00B, created: 2012-10-07 - -- - ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Divide et impera Divide and govern - ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ - ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.0-beta95 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCAAGBQJQqnngAAoJEAt/i2Dj7frj/ZYP/3nlCTG/wkpjh7+HkTnnM0K6 3ATXifopQ39NV1D+mGSNzUPUvPw1D0PR9YwKO2JjBOO9FFm0Zo6LenS390e0RtGs 31jKADNmBGXldDqvQBVRMmESQ8o8grsnuIo2vEkpli+07y4d6tzV2wgjm5XC4a+E 7a1sggb+Cc/qbrj2Hbapt4Cm80sckjDrjLyM/O3bCVUxAikBf7YwRo3BvWYt1dSs drRbrWqnM/IZnfZdikYgh924m8dLylSvOnt4SEhdRKKJs/QWO/W6iGNwJfo5VAm5 E1yfH1f55TdC7qNfShvf4340DMgDFkWQxNG4mvcbZm/FU6TUPID50ImITC+CpAYe VIm9B1h8ChN2LXklTnPF5Qo9yZJBMf9NHOSsYMbdeLPTeqNd5JFn8qNwYjdzR7Dm h6wuKloZXnW1JMEI9lMpSZVObMag7pk4wfFW36LdUvji3yN3uPPvQ+ej9TwSnMDN X7hNS+byroX1bP9hTV4zhSiqJm2deNlAI2aAz+nYWKu1sY8mqUF8e2itIIpM2WKX a6iz1wS3Mg2b1s8HXxy1FsRBJi5oHDvfizGso8gthjB39Ydar3tMKsEnHN6JU238 pwDYGVgfd6LnvTnWmsAd1+SQ8GOa2aNM3TGqJDhDHNu6B9FqRSVRahLzMZJGtOdD 1NmpK9mPZadUW/1HQMGR =7Dlx -----END PGP SIGNATURE----- From abel at guardianproject.info Mon Nov 19 22:03:04 2012 From: abel at guardianproject.info (Abel Luck) Date: Mon, 19 Nov 2012 21:03:04 +0000 Subject: ttyname in gpgme when running Android In-Reply-To: <87boeybuiv.fsf@vigenere.g10code.de> References: <5087260B.9050302@guardianproject.info> <508739BA.6040306@guardianproject.info> <87pq48c7xh.fsf@vigenere.g10code.de> <5087F060.70600@guardianproject.info> <87d307dhvi.fsf@vigenere.g10code.de> <50A503AA.8060402@guardianproject.info> <87boeybuiv.fsf@vigenere.g10code.de> Message-ID: <50AA9E88.8020305@guardianproject.info> Werner Koch: > On Thu, 15 Nov 2012 16:00, abel at guardianproject.info said: > >> My m4 foo is decidedly lacking. Is there any chance you could produce a >> fix for this? > > Will do. > Awesome, thanks for carrying that torch! I'll pull gnupg master every now and then to see when it's been added. Cheers, Abel From wk at gnupg.org Tue Nov 20 15:48:07 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Nov 2012 15:48:07 +0100 Subject: ttyname in gpgme when running Android In-Reply-To: <50AA9E88.8020305@guardianproject.info> (Abel Luck's message of "Mon, 19 Nov 2012 21:03:04 +0000") References: <5087260B.9050302@guardianproject.info> <508739BA.6040306@guardianproject.info> <87pq48c7xh.fsf@vigenere.g10code.de> <5087F060.70600@guardianproject.info> <87d307dhvi.fsf@vigenere.g10code.de> <50A503AA.8060402@guardianproject.info> <87boeybuiv.fsf@vigenere.g10code.de> <50AA9E88.8020305@guardianproject.info> Message-ID: <876250jpp4.fsf@vigenere.g10code.de> On Mon, 19 Nov 2012 22:03, abel at guardianproject.info said: > I'll pull gnupg master every now and then to see when it's been added. Sorry, I have not yet come around to fix that. I let you know. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Nov 20 19:10:13 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Nov 2012 19:10:13 +0100 Subject: ttyname in gpgme when running Android In-Reply-To: <50A503AA.8060402@guardianproject.info> (Abel Luck's message of "Thu, 15 Nov 2012 15:00:58 +0000") References: <5087260B.9050302@guardianproject.info> <508739BA.6040306@guardianproject.info> <87pq48c7xh.fsf@vigenere.g10code.de> <5087F060.70600@guardianproject.info> <87d307dhvi.fsf@vigenere.g10code.de> <50A503AA.8060402@guardianproject.info> Message-ID: <87zk2ci1ru.fsf@vigenere.g10code.de> On Thu, 15 Nov 2012 16:00, abel at guardianproject.info said: > gnupg/configure.ac is doing a naive function check for ttyname, which > succeeds, but of course on Android ttyname is a stub. I suspect we need > the same REPLACE_TTYNAME magic in gnupg that we used in gpgme. I defined a HAVE_BROKEN_TTYNAME for Android and switched to use a gnupg_ttyname macro. Please pull and try. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Wed Nov 21 02:37:29 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 21 Nov 2012 10:37:29 +0900 Subject: Let scdaemon exit when no reader is available Message-ID: <1353461849.2749.5.camel@cfw2.gniibe.org> Hello, In June, I talked about how scdaemon should handle card insertion/removal and card reader insertion/removal. Let me talk it again. Currently, a card is detected by scdaemon when user tries to use it at first. Next, when the card is removed, it is detected by scdaemon. Then, scdameon keeps polling, and the insertion will be detected. In my opinion, it is no problem for scdaemon not to poll to detect card insertion or card reader insertion after removal. I mean, it is OK for user that scdaemon detects it when he tries to use the card again. It's just like the first use of a card. The reason why I propose the change of scdaemon's behavior is that some people (including me) don't expect its polling for insertion, but expect its finish of execution. Here is a patch which let scdaemon exit when it detects removal of a card reader. It is to discuss the issue of scdaemon keeps polling (for insertion) after removal of a card reader. It is not yet to handle card removal. Note that this patch is not enough to fix the bug reported in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687250 The patch only works when scdaemon uses internal ccid driver and there is no PC/SC service. This patch is a bit stronger proposal than the one in June. The version in June was just to stop opening card reader by scd_update_reader_status_file and it doesn't let scdaemon finish its execution. I think that this one is better not to waste computer resource. diff --git a/scd/command.c b/scd/command.c index 17da5b7..64b1d5f 100644 --- a/scd/command.c +++ b/scd/command.c @@ -2430,4 +2430,6 @@ scd_update_reader_status_file (void) if (err) log_error ("failed to release status_file_update lock: %s\n", strerror (err)); + if (reader_disabled) + scd_exit (1); } From gniibe at fsij.org Wed Nov 21 06:46:38 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 21 Nov 2012 14:46:38 +0900 Subject: Issue 1290 Message-ID: <1353476798.2749.9.camel@cfw2.gniibe.org> Hello, The issue 1290 in the BTS should be closed. https://bugs.g10code.com/gnupg/issue1290 The bug was fixed by the change: 2010-11-11 Werner Koch * agent.h (opt): Add field SIGUSR2_ENABLED. * gpg-agent.c (handle_connections): Set that flag. * call-scd.c (start_scd): Enable events depending on this flag. Same thing was reported and fixed: http://lists.gnupg.org/pipermail/gnupg-devel/2010-November/025815.html -- From wk at gnupg.org Wed Nov 21 10:12:06 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Nov 2012 10:12:06 +0100 Subject: Let scdaemon exit when no reader is available In-Reply-To: <1353461849.2749.5.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Wed, 21 Nov 2012 10:37:29 +0900") References: <1353461849.2749.5.camel@cfw2.gniibe.org> Message-ID: <87haojial5.fsf@vigenere.g10code.de> On Wed, 21 Nov 2012 02:37, gniibe at fsij.org said: > Here is a patch which let scdaemon exit when it detects removal of a > card reader. It is to discuss the issue of scdaemon keeps polling > (for insertion) after removal of a card reader. It is not yet to > handle card removal. Thus your patch is a hack which works because gpg-agent will start scdaemon anyway if it requires it. We can give it a try for 2.1. Can you please add a comment in the code, explaining why it is useful to exit. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Thu Nov 22 03:08:47 2012 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 22 Nov 2012 11:08:47 +0900 Subject: Let scdaemon exit when no reader is available In-Reply-To: <87haojial5.fsf@vigenere.g10code.de> References: <1353461849.2749.5.camel@cfw2.gniibe.org> <87haojial5.fsf@vigenere.g10code.de> Message-ID: <1353550127.2908.2.camel@cfw2.gniibe.org> Thank you for your reply. Let me iterate the problem again. After removal of a card reader, scdaemon keeps opening card reader (again and again) which may cause many error logs. On 2012-11-21 at 10:12 +0100, Werner Koch wrote: > On Wed, 21 Nov 2012 02:37, gniibe at fsij.org said: > Thus your patch is a hack which works because gpg-agent will start > scdaemon anyway if it requires it. Well, it would be a hack or a dirty patch from the viewpoint of "smartcard daemon". Generally speaking, daemon should be independent and responsible for all cases, and should never exit. It is also true that the patch works well because gpg-agent watches scdaemon's death by the function agent_scd_check_aliveness, and handles it gracefully. However, please note that after a card reader removal (reader_disabled == 1), scdaemon will exit at the end of next session of gpg-agent, in the function scd_command_handler, anyway. From this viewpoint, the patch could be considered a fix for consistent handling of reader_disabled state. > We can give it a try for 2.1. Can you please add a comment in the code, > explaining why it is useful to exit. Umm... Adding another "exit" to a daemon sounds guilty... OK, I'll try another approach: (1) (As original proposal) Fix the function update_reader_status_file not to call get_current_reader. This fix has a impact that the insertion of a card reader will be detected only when user tries to access his card. (2) Fix not to give up in the case of reader_disabled == 1 in the function scd_command_handler. (In the first place.) (3) (Optionally, or in future) Fix the main routine of scdaemon to enable the timer only when there is a card reader available. With this approach, scdaemon will be more robust and it will have same good result as "adding exit to scdaemon" patch (mostly). -- From wk at gnupg.org Tue Nov 27 17:39:26 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Nov 2012 17:39:26 +0100 Subject: [PATCH libgcrypt] * gcrypt.h.in: Set appropriate algo id for ECDSA and ECDH In-Reply-To: <50AA79E5.7090207@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Mon, 19 Nov 2012 19:26:45 +0100") References: <20121118180832.GA24953@sumptuouscapital.com> <87pq3a6o4h.fsf@vigenere.g10code.de> <50A9F087.1070700@sumptuouscapital.com> <87vcd1jwlo.fsf@vigenere.g10code.de> <50AA79E5.7090207@sumptuouscapital.com> Message-ID: <87mwy39f0h.fsf@vigenere.g10code.de> On Mon, 19 Nov 2012 19:26, kristian.fiskerstrand at sumptuouscapital.com said: > Fair enough, but GnuPG is getting this from libgcrypt in keyserver.c > on line 509 which use > > const char *str = gcry_pk_algo_name (keyrec->type); Alright, this needs to be mapped from openpgp ids to gcrypt ids. I just pushed two fixes for 2.0 and master. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Tue Nov 27 18:07:46 2012 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 27 Nov 2012 18:07:46 +0100 Subject: [PATCH libgcrypt] * gcrypt.h.in: Set appropriate algo id for ECDSA and ECDH In-Reply-To: <87mwy39f0h.fsf@vigenere.g10code.de> References: <20121118180832.GA24953@sumptuouscapital.com> <87pq3a6o4h.fsf@vigenere.g10code.de> <50A9F087.1070700@sumptuouscapital.com> <87vcd1jwlo.fsf@vigenere.g10code.de> <50AA79E5.7090207@sumptuouscapital.com> <87mwy39f0h.fsf@vigenere.g10code.de> Message-ID: <50B4F362.1080700@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/27/2012 05:39 PM, Werner Koch wrote: > On Mon, 19 Nov 2012 19:26, > kristian.fiskerstrand at sumptuouscapital.com said: >> Fair enough, but GnuPG is getting this from libgcrypt in >> keyserver.c on line 509 which use >> >> const char *str = gcry_pk_algo_name (keyrec->type); > > Alright, this needs to be mapped from openpgp ids to gcrypt ids. I > just pushed two fixes for 2.0 and master. > Just tried the patch and this works for me, thanks! On another note, the dirmngr seems to be doing a reverse lookup (PTR) on the records and use this for connecting rather than the provided server name. This cause issues with keyservers on e.g. virtual host settings that are expecting the specific name or the pool names to be used (the pool crawler checks for an appropriate response using a Host: header belonging to the pool before including a server) , and result in NO DATA responses. In addition it cause problems with SNI for TLS connections. Beware that similar symptoms will also be the case when using the keys.gnupg.net CNAME as not all servers are configured to respond to this Host:. - -- - ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Primum ego, tum ego, deinde ego First I, then I, thereafter I. - ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ - ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.0-beta100 (GNU/Linux) iQIcBAEBCAAGBQJQtPNdAAoJEAt/i2Dj7frjrqkP/Rm51ZAev+LhZCcyABAPVeBB YLRII95jcQku7gztH4Ec+LVcHwYH6NW5+uI9jzeNGAQS+2E5td70HoilW+XWJJ1c nAcKxLqJFTwg1s/3lgcyHpjd9thX63T5O8EdB7GS3xhNB6KpULPIM3J5AObqEUcg ewVesxROSl6HC7MTQl/PtYs89UNDX8orq6Ucd7OPzkdpukd/BQrnURyvF9wRQHUg vQUl4pLTs4/ijJfIh7a1KdHBLRxYxuUrbLEw6s6O91jVR7mAsMawje1DwirLgV5H 778H6SQIZoRZ8XnLOiDNCOC3QWEXaFHgNm8XHji6n0IenkvoZdwuBUqdt/klMgQH 2ZLBGZzCIxgoD13k616BX/EgG4mBSOLrePxMynUFz9a9K7jM5gkLTe+u3J3rW30h WVdyCg66oSqcLvZwdT3Ak1f4gpAlLnWkpNKoB+ghBz75+6xCu1CUd8ETcnPGbnWQ VoxKrP613upUP1T15qVjs6E3rAvUtN2WjWZ7FTZHlJ1GiPemc2tbZJHKitblMiM1 N0OckJWz5IAxUMqG/P4+f4DZb8sBAvBpprhPnubXaKPe0wtSENjK5OE27c8egpaF YfTjcv7xiLG8bXFQhinMuNZ9ntE82H1C76hRIDp5dsrxZrWG0cwbY2uwVcevCHxL D1zwxAS3Ke5Z8Jgaw4qe =SeI9 -----END PGP SIGNATURE----- From wk at gnupg.org Tue Nov 27 20:21:14 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Nov 2012 20:21:14 +0100 Subject: [PATCH libgcrypt] * gcrypt.h.in: Set appropriate algo id for ECDSA and ECDH In-Reply-To: <50B4F362.1080700@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Tue, 27 Nov 2012 18:07:46 +0100") References: <20121118180832.GA24953@sumptuouscapital.com> <87pq3a6o4h.fsf@vigenere.g10code.de> <50A9F087.1070700@sumptuouscapital.com> <87vcd1jwlo.fsf@vigenere.g10code.de> <50AA79E5.7090207@sumptuouscapital.com> <87mwy39f0h.fsf@vigenere.g10code.de> <50B4F362.1080700@sumptuouscapital.com> Message-ID: <87haoaam39.fsf@vigenere.g10code.de> On Tue, 27 Nov 2012 18:07, kristian.fiskerstrand at sumptuouscapital.com said: > Just tried the patch and this works for me, thanks! That was actually pretty easy. > On another note, the dirmngr seems to be doing a reverse lookup (PTR) > on the records and use this for connecting rather than the provided Actually this is all work in progress. I know that there are quite some things left to be fixed. > server name. This cause issues with keyservers on e.g. virtual host > settings that are expecting the specific name or the pool names to be A virtual HTTP host for a keyserver? I doubt that this is a good idea. Thanks for this heads up. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Tue Nov 27 20:46:51 2012 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 27 Nov 2012 20:46:51 +0100 Subject: [PATCH libgcrypt] * gcrypt.h.in: Set appropriate algo id for ECDSA and ECDH In-Reply-To: <87haoaam39.fsf@vigenere.g10code.de> References: <20121118180832.GA24953@sumptuouscapital.com> <87pq3a6o4h.fsf@vigenere.g10code.de> <50A9F087.1070700@sumptuouscapital.com> <87vcd1jwlo.fsf@vigenere.g10code.de> <50AA79E5.7090207@sumptuouscapital.com> <87mwy39f0h.fsf@vigenere.g10code.de> <50B4F362.1080700@sumptuouscapital.com> <87haoaam39.fsf@vigenere.g10code.de> Message-ID: <50B518AB.4080607@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/27/2012 08:21 PM, Werner Koch wrote: > On Tue, 27 Nov 2012 18:07, > kristian.fiskerstrand at sumptuouscapital.com said: > ... > >> server name. This cause issues with keyservers on e.g. virtual >> host settings that are expecting the specific name or the pool >> names to be > > A virtual HTTP host for a keyserver? I doubt that this is a good > idea. Thanks for this heads up. This is typically related to putting SKS behind a reverse proxy due to [0] or to enable HKPS[1] since it defaults to 443 (hence also the SNI requirement). Personally I'd prefer a non-standard port for this (as we have for HKP), but too late for that, so have to rely on SRV records as an alternative, although that is made more difficult due to issue1446 [2] [0] http://lists.gnu.org/archive/html/sks-devel/2012-03/msg00006.html [1] http://lists.gnu.org/archive/html/sks-devel/2012-10/msg00000.html [2] https://bugs.g10code.com/gnupg/issue1446 - -- - ---------------------------- Kristian Fiskerstrand http://www.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Quidquid latine dictum sit, altum videtur. Anything said in Latin sounds profound - ---------------------------- This email was digitally signed using the OpenPGP standard. If you want to read more about this The book: Sending Emails - The Safe Way: An introduction to OpenPGP security is available in both Amazon Kindle and Paperback format at http://www.amazon.com/dp/B006RSG1S4/ - ---------------------------- Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.0-beta100 (GNU/Linux) iQIcBAEBCAAGBQJQtRiqAAoJEAt/i2Dj7frjprsQAJVRtOJMcF6uVq+/70MVTs9Y owzzAXnyBZjWn6mh28MMLK4Vl99kLawJif1jpmAZIKepCjBTs/spuK7z+kzJHLLn J2mfF57ZI0ck8c65w56vbtDx6i0l3/ubMSooi8K5IRzfbqAFVQtFSn/jDgES/d7J OZnSti8madykwSqpOTfOVVMQiWbG5mBQtrG7IzE66M2FbsJFSxXQMz7v5sgp1q3X MMArRlPh6DhY/3KBF+g8KbDmOAj3AJ1m5Ht+gkFsPF4lwDVOnRHCAhHizi/Q7oUd sTqOPD4SecOcJJkkkqbPy08Atc0nuctP8Y15BRbpC3zDoc3uypD4CAnvCRHNsupu ABkTpLvaaXDI1OLxy2LIf97te5v6nI6IOL7Sql4qxyN/+qpcRQZeHVDlZNP2m3d0 +35XfbBJ+ZeKPdPejuBJHbb3AEMNeGCE/POLC4/HJ2WebO3qMabXq3TcsUMDF3Na orFjHjK5hgUZwAkZGw+pp0M9YMPDzfUqYAnEx+D2XeW9F1ymQGmriVP5duXtcJUf iFmR3OcqhSjdEVxjotdIzk+ApYqMmTSZ2iJeEHddPA6oJiAjCBg2n2QGjAbM4pMQ y4zYyr4DAjyl7ZVWLgGAFxUKZ96wFjhX65+ZC6q5DTEgdDIt7Vj3HXzHBv9AZLbl nIgYqJIjcJdeyODhWsjG =tfcB -----END PGP SIGNATURE-----