From gniibe at fsij.org Fri Feb 1 00:57:20 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 01 Feb 2013 08:57:20 +0900 Subject: Supporting fixed length keypad input In-Reply-To: <1358217413.2667.6.camel@cfw2.gniibe.org> References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> <87wqvm4smu.fsf@vigenere.g10code.de> <1357779807.2924.1.camel@cfw2.gniibe.org> <50EE75B5.3090009@pietig.com> <1358217413.2667.6.camel@cfw2.gniibe.org> Message-ID: <1359676640.2670.2.camel@cfw2.gniibe.org> On 2013-01-15 at 11:36 +0900, NIIBE Yutaka wrote: > To summarize discussion, I'd like to propose the following for pinpad > input. > > * Default is variable length pinpad input when reader supports the > feature. > > * Use pinentry by keyboard on host PC, when reader doesn't supports > the feature (including reader supports pinpad input but requires > fixed length input). > > * Only when a user wants to do special thing, he needs to specify > this. Special cases are: > > (1) Use pinentry by keyboard even with pinpad reader. > (for cases when PIN has characters other than digits.) > > (2) Use fixed length input. Now, in scd-work branch, it is implemented in this way. I'd like to merge scd-work branch to master. It will be backported to 2.0 branch, too. After that, I will do function name changes for keypad -> pinpad. -- From lrn1986 at gmail.com Fri Feb 1 04:11:54 2013 From: lrn1986 at gmail.com (LRN) Date: Fri, 01 Feb 2013 07:11:54 +0400 Subject: W32 build fixes for gnupg-2.0.19 In-Reply-To: <878v7florn.fsf@vigenere.g10code.de> References: <510351C6.7050608@gmail.com> <878v7florn.fsf@vigenere.g10code.de> Message-ID: <510B327A.8010005@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26.01.2013 23:37, Werner Koch wrote: > On Sat, 26 Jan 2013 04:47, lrn1986 at gmail.com said: >> Subj is attached. > > Please explain the problems you are trying to fix. The single problem is GnuPG not building with MinGW/MSys. The separate issues that affect the building process were described briefly in my previous message (for each separate patch). > Note that we still need copyright assignments for GnuPG I have copyright assignment for GnuTLS. Would that suffice? If not, then that still isn't a problem - i need a copyright assignment for binutils anyway, so i'm going to get a generic GNU one in foreseeable future (depends mostly on how fast the postal service works). Also, 1-2-line patches (2/3 of the files i've sent) do not merit a copyright. > and that building requires a full fledged POSIX host; i.e. building > on a Windows host does not work. Let's see. 0001-fix-regex-test-on.mingw32.all.patch: Adds one #include to a configure test. I doubt that including gcc's own stddef.h will break anything. 0002-fix-stringhelp-on.mingw32.patch: First half fixes an obvious bug in the code. The original function looked like this: const char * gethome (void) { if (!home_buffer) { char *home = getenv("HOME"); #if defined(HAVE_GETPWUID) && defined(HAVE_PWD_H) if(home) home_buffer = xstrdup (home); else { struct passwd *pwd; pwd = getpwuid (getuid()); if (pwd) home_buffer = xstrdup (pwd->pw_dir); } #endif } return home_buffer; } Which begs the question: why getenv("HOME"), if you don't HAVE_GETPWUID or don't HAVE_PWD_H? And then another question: if home envvar is defined (is not NULL), then why not xstrdup it to use as gethome() result? It has no relation to getpwuid or pwd.h. This part fixes gethome() to actually work on W32 (when HOME is defined). The second part of that patch is W32-only (see the #ifdefs), and thus does not affect other platforms. It tries to use USERPROFILE envvar as a substitute for HOME, if HOME is not defined. If you don't like the second part (for whatever reason), omit it, it's optional anyway. 0003-fix-tmpfile-on.mingw32.patch: This is probably what you meant when asked for copyright assignment and for cross-compilation testing. First, it's W32-only (see the #ifdefs), so it will not affect other platforms. Second, because it loads functions at runtime, it will cross-_compile_ successfully. Running successfully is another matter. It did run on my NT 6.1.7601 though. Also see below for how this patch can be improved if you bump the minimal W32 version to 0x501. > If you need that I suggest to run a decent Debian version in a VM. I have a Debian laptop, and also have Debian on my server. I'm totally willing to test these under Debian, if you point me to some cross-compilation-of-GnuPG-from-Debian-to-W32 docs. > >> minimal target W32 platform is W2000 (0x500), which means that > > I can't guarantee that GnuPG-2 will run on W2000. I have no test > system anymore and in any case W2000 reached EOL a long time ago. My assumption about minimal target is based upon this code: #ifdef HAVE_W32_SYSTEM # define WINVER 0x0500 /* Required for AllowSetForegroundWindow. */ # include #endif in sysutils.c I do not know who added it there, and when, but it means that GnuPG (compiled as-is, if you manage to do that) will not run on anything older than W2000 (W32 runtime linker will abort, claiming that it can't find AllowSetForegroundWindow in User32.dll). If you are willing to bump the minimal version to XP (0x501) at least, that will GREATLY simplify the last patch, as it will not need to load functions at runtime - it will just use CryptoAPI directly. By the way, all that is explained in the comments in the patch itself. But you probably don't have enough free time to read comments. Anyway, give the minimal version bump a thought. Please. > >> check' passes all tests successfully (i did test all 3 versions >> of the random generator). > > Those tests don't test the quality of the RNG! To make sure that > it works as expected you need to do quite some research. This random number generator is used ONLY to generate names for temporary files (mktemp()). The original code in gnupg_mktemp did not use RNG at all, it used a combination of process ID and system CPU time (tick count), and did some obscure magic with these numbers. And with it sysutils tests failed for me. With my patches they don't fail, they pass. Which was my goal. By the way, i have two more patches (or, more likely, pointers; they are not fit for merging as-is) for you. Do you even want them? P.S. Just realized that my original reply was not sent to the ML. Here's the same message again. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRCzJ3AAoJEOs4Jb6SI2Cwu4cH/ijxVZlXqz2+MJDAr7z6YX5F RWJjVOv9QxZyahBB2av4SLenVpvwWhIIVUBNGd0AlFbJ95YzI9RPHQFUDLZqt4wf 7E89AGZQV4HcDHxBMCbSKWmqmExBy5S1mg/5G2T57hi6D4SVTT98eb/Pw/LbwN1u eHQ9mrFsuRqut5wy2ssBaPkLZB0MB4r3JLr4WaOTXPIzipFBRxTfiJJzIjHLhx6T BQNETwKwgfZ2XQQD0hUlbgkvcjb4DMi96VkcUgfvJPXdtaqEPLUpv7qiEAxDjycX flDZMmAf8KKN9B2t9cs2yZhqGTZKQ6JSL6CNe8XIBQgTc8F9JGr9G46Umj47vP4= =fDJd -----END PGP SIGNATURE----- From gniibe at fsij.org Fri Feb 1 11:16:28 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 01 Feb 2013 19:16:28 +0900 Subject: W32 build fixes for gnupg-2.0.19 In-Reply-To: <510B327A.8010005@gmail.com> References: <510351C6.7050608@gmail.com> <878v7florn.fsf@vigenere.g10code.de> <510B327A.8010005@gmail.com> Message-ID: <1359713788.1952.0.camel@latx1.gniibe.org> Hello, Thanks for your effort and explanation. On 2013-02-01 at 07:11 +0400, LRN wrote: > On 26.01.2013 23:37, Werner Koch wrote: > > On Sat, 26 Jan 2013 04:47, lrn1986 at gmail.com said: > >> Subj is attached. > > > > Please explain the problems you are trying to fix. > The single problem is GnuPG not building with MinGW/MSys. Well, then, my question is: Why on earth do you need to build GnuPG with MinGW/Msys, given we have another recommended way to build GnuPG for Windows? Even if there were some valid reasons, I still have concern here. I'm afraid that it would result another incompatible GnuPG. My major concern is using smartcard/token and/or gpg-agent. The GnuPG built with MinGW wouldn't work well wrt PC/SC service and emulation of Unix domain socket. -- From lrn1986 at gmail.com Fri Feb 1 13:11:04 2013 From: lrn1986 at gmail.com (LRN) Date: Fri, 01 Feb 2013 16:11:04 +0400 Subject: W32 build fixes for gnupg-2.0.19 In-Reply-To: <1359713788.1952.0.camel@latx1.gniibe.org> References: <510351C6.7050608@gmail.com> <878v7florn.fsf@vigenere.g10code.de> <510B327A.8010005@gmail.com> <1359713788.1952.0.camel@latx1.gniibe.org> Message-ID: <510BB0D8.5090403@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01.02.2013 14:16, NIIBE Yutaka wrote: > Hello, > > Thanks for your effort and explanation. > > On 2013-02-01 at 07:11 +0400, LRN wrote: >> On 26.01.2013 23:37, Werner Koch wrote: >>> On Sat, 26 Jan 2013 04:47, lrn1986 at gmail.com said: >>>> Subj is attached. >>> >>> Please explain the problems you are trying to fix. >> The single problem is GnuPG not building with MinGW/MSys. > > Well, then, my question is: > > Why on earth do you need to build GnuPG with MinGW/Msys Because i build everything with MinGW/MSys. I can build gcc, binutils, pthreads, and over 100 other packages. GnuPG can not be (should not be) special in this regard. > , given we have another recommended way to build GnuPG for > Windows? What is that way? GnuPG4Win? Or do you use *gasp* MSVC? > > I'm afraid that it would result another incompatible GnuPG. That will not be a problem. Or, rather, it will not be a problem for _you_. > My major concern is using smartcard/token and/or gpg-agent. The > GnuPG built with MinGW wouldn't work well wrt PC/SC service and > emulation of Unix domain socket. Why? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRC7DXAAoJEOs4Jb6SI2CwYB8IAMkhKNyzbsUkZqaxunBxI2EA DGHHZo7Lg2QhK9CMjkdFnnoOvLURl350Etotkotu2ukv1hPmqKke2FhY8cd8Kw+V JF/q0WCseoRvqV6wYyiHUqedr6YYZhEPswt5XrWptgkg+aNfUHmEMdp/CZZx9AoC hg/HZrH+XbEHg/DoSYvq9v8C3hbi/ZhO+Gbh02QEfmpvyJi523VO8a0398qz+Dyk +qVbgRhEzqXBdgpx3zAbFqW1+ZnqVmxxI0JPX0ZqCLUXABTKrbi/UZOJpRoyrlep MqbP6MbwuSWhxDwQH6W2+JFUp7B6QbRBObJVJQAom399SiWrS3WbHgNWmPRnRE8= =4E9u -----END PGP SIGNATURE----- From John at enigmail.net Fri Feb 1 14:32:44 2013 From: John at enigmail.net (John Clizbe) Date: Fri, 01 Feb 2013 07:32:44 -0600 Subject: 1.4.12 beta installer for Windows In-Reply-To: References: <87y5syd8ah.fsf@vigenere.g10code.de> Message-ID: <510BC3FC.70701@enigmail.net> Veet Vivarto wrote: > Hello Werner, > > My friend and I, are working on a easy to use front-end for GPG for Windows > and Mac. > On Windows we are using the 1.4.11 because it only requires two files (.exe, .dll) Just curious, which DLL? I just did a test with the 1.4.13 installer and didn't see any DLLs installed. > I have not been able to find a small Mac command line program that would > correspond to GnuPG 1.4. > I only found the huge package called GPGTools. > Thank you in advance for your help.1111 Looking in the usual places for ports to Mac OS X... Macports [https://www.macports.org/ ]: basket:~ jpclizbe$ port info gnupg gnupg @1.4.13 (mail, security) Variants: universal Description: GnuPG is a complete and free replacement for PGP. Because it does not use the patented IDEA algorithm, it can be used without any restrictions. GnuPG is a RFC2440 (OpenPGP) compliant application. Homepage: http://www.gnupg.org Library Dependencies: libiconv, gettext, readline, zlib, bzip2, libusb-compat, openldap Platforms: darwin, freebsd, sunos License: GPL-3+ Maintainers: nomaintainer at macports.org Fink [http://www.finkproject.org/ ]: basket:~ jpclizbe$ fink info gnupg Information about 11677 packages read in 5 seconds. gnupg-1.4.13-1: Gnu privacy guard - A Free PGP replacement GnuPG is GNU's tool for secure communication and data storage. It can be used to encrypt data and to create digital signatures. It includes an advanced key management facility and is compliant with the proposed OpenPGP Internet standard as described in RFC2440. GnuPG does not use use any patented algorithms so it cannot be compatible with PGP2 because it uses IDEA (which is patented worldwide) and RSA. RSA's patent expired on the 20th September 2000, and it is now included in GnuPG. . For IDEA support, see the "gnupg-idea" package. . Usage Notes: To create an initial key pair run 'gpg --gen-key' Consult the manual for a good intro: /sw/share/doc/gnupg/documentation/handbook/ . Web site: http://www.gnupg.org . Maintainer: Benjamin Reed basket:~ jpclizbe$ -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 863 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Feb 1 15:54:30 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 01 Feb 2013 15:54:30 +0100 Subject: W32 build fixes for gnupg-2.0.19 In-Reply-To: <510BB0D8.5090403@gmail.com> (LRN's message of "Fri, 01 Feb 2013 16:11:04 +0400") References: <510351C6.7050608@gmail.com> <878v7florn.fsf@vigenere.g10code.de> <510B327A.8010005@gmail.com> <1359713788.1952.0.camel@latx1.gniibe.org> <510BB0D8.5090403@gmail.com> Message-ID: <87vcacaxuh.fsf@vigenere.g10code.de> On Fri, 1 Feb 2013 13:11, lrn1986 at gmail.com said: > What is that way? GnuPG4Win? Or do you use *gasp* MSVC? For a dozen years or so this is: ./autogen.sh --build-w32 Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lrn1986 at gmail.com Fri Feb 1 17:35:06 2013 From: lrn1986 at gmail.com (LRN) Date: Fri, 01 Feb 2013 20:35:06 +0400 Subject: W32 build fixes for gnupg-2.0.19 In-Reply-To: <87vcacaxuh.fsf@vigenere.g10code.de> References: <510351C6.7050608@gmail.com> <878v7florn.fsf@vigenere.g10code.de> <510B327A.8010005@gmail.com> <1359713788.1952.0.camel@latx1.gniibe.org> <510BB0D8.5090403@gmail.com> <87vcacaxuh.fsf@vigenere.g10code.de> Message-ID: <510BEEBA.4070509@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01.02.2013 18:54, Werner Koch wrote: > On Fri, 1 Feb 2013 13:11, lrn1986 at gmail.com said: > >> What is that way? GnuPG4Win? Or do you use *gasp* MSVC? > > For a dozen years or so this is: > > ./autogen.sh --build-w32 > OK. That is cross-compiling from a POSIX system. Using mingw cross-compiler. > The GnuPG built with MinGW wouldn't work well wrt PC/SC service and > emulation of Unix domain socket. Clarify this for me, please. How could GnuPG compiled with mingw cross-compiler work fine (since that is the recommended way of building it), and GnuPG compiled with mingw native compiler not work fine? Both build methods are identical, the only difference is in host/build values, maybe compiler flags, and the fact that you do not run tests when cross-compiling. Are you, by chance, confusing mingw-gcc (which produces native W32 binaries) with msys-gcc (which produces binaries linked to msys POSIX compatibility library)? Because i'm using the former (msys here is only used to run shell scripts - configure and such), not the latter. No UNIX domain socket emulation is in play here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRC+66AAoJEOs4Jb6SI2CwRTEH/3UvloCBrm+y2eydHwU9RUzY NcY6GIeGZh977DI8Cr75BeD1K3yPnT4ysrK6xLfGTeciejwOmaXf5lDzpGEAXSyr 832GQGI6cYWPhzTCctDI0iFzAkBScitc/dIxf+0kTp1NDGT6RryelaJJ/B/CU3kV PSUhevCbrVMNrOq1/SQtP9csijnY3E55+1b3T+AzWt9v5W5UZtFrRrn3o9qIc3R1 KuZgZDvy8nCQ1IHgGO6StjvniVHxnQ4amMAXndagx9eFB5tyVqYHMVnif/C4Jx66 USF2eDfao13oqXPhnsHMc4eKTEe1I+BH3OTYHYjfzaDzx6JLNkX014u6fiwQIhI= =b7zk -----END PGP SIGNATURE----- From gniibe at fsij.org Mon Feb 4 01:16:49 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 04 Feb 2013 09:16:49 +0900 Subject: Popup_message_stop In-Reply-To: <1359619074.22168.1.camel@cfw2.gniibe.org> References: <1358219182.2667.8.camel@cfw2.gniibe.org> <1359001349.5224.4.camel@cfw2.gniibe.org> <1359619074.22168.1.camel@cfw2.gniibe.org> Message-ID: <1359937009.2696.3.camel@cfw2.gniibe.org> I committed and pushed the fix of pinentry signal mask and signal handler to 2.0 branch. For master branch, I believe it is cleaner to add a code to nPth. On 2013-01-31 at 16:57 +0900, NIIBE Yutaka wrote: > For 2.0 branch, it is signal mask and signal handler setting. > > Here is a patch to fix the original issue in 2.0. Built and tested > (with VASCO reader). > > diff --git a/agent/call-pinentry.c b/agent/call-pinentry.c > index 2483019..c945c13 100644 > --- a/agent/call-pinentry.c > +++ b/agent/call-pinentry.c > @@ -170,6 +170,16 @@ static void > atfork_cb (void *opaque, int where) > { > ctrl_t ctrl = opaque; > +#ifndef HAVE_W32_SYSTEM > + struct sigaction sa; > + > + /* Pop up message should be able to be killed by SIGINT. */ > + sigemptyset (&sa.sa_mask); > + sa.sa_handler = SIG_DFL; > + sa.sa_flags = 0; > + sigaction (SIGINT, &sa, NULL); > + sigprocmask (SIG_SETMASK, &sa.sa_mask, NULL); /* Unblock all signals. */ > +#endif > > if (!where) > { > @@ -1159,8 +1169,7 @@ agent_popup_message_stop (ctrl_t ctrl) > assuan_set_flag (entry_ctx, ASSUAN_NO_WAITPID, 1); > } > else if (pid > 0) > - kill (pid, SIGKILL); /* Need to use SIGKILL due to bad > - interaction of SIGINT with Pth. */ > + kill (pid, SIGINT); > #endif > > /* Now wait for the thread to terminate. */ -- From gniibe at fsij.org Mon Feb 4 01:34:23 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 04 Feb 2013 09:34:23 +0900 Subject: agent: adding KEYTOCARD command (master branch) Message-ID: <1359938063.2696.5.camel@cfw2.gniibe.org> In master branch, "keytocard" command for --edit-key is not supported yet (the function g10/card_store_subkey). I'd like to fix this. I think that the reason why it is not yet supported is because of the shift of secret key handling to gpg-agent. Well, it is possible to implement this functionality again with current gpg-agent's command set ("EXPORT_KEY" and "SCD"), but this is not that good if we want to push secret key handling to gpg-agent. Instead, I'd like to propose adding "KEYTOCARD" command to gpg-agent, which directly implements the functionality of g10/card_store_subkey. The command format would be like: KEYTOCARD [--force] -- From gniibe at fsij.org Mon Feb 4 02:23:56 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 04 Feb 2013 10:23:56 +0900 Subject: Pinpad input problem for GemPC Pinpad reader In-Reply-To: <1357872188.2659.6.camel@cfw2.gniibe.org> References: <1357805722.2924.6.camel@cfw2.gniibe.org> <1357872188.2659.6.camel@cfw2.gniibe.org> Message-ID: <1359941036.2696.7.camel@cfw2.gniibe.org> I applied and pushed this change to STABLE-BRANCH-2-0. On 2013-01-11 at 11:43 +0900, NIIBE Yutaka wrote: > On 2013-01-10 at 17:15 +0900, NIIBE Yutaka wrote: > > It seems that GemPC Pinpad reader is single threaded. > > > > I need to configure SCDaemon with debug-disable-ticker option to > > use the reader reliably (or I need to input quickly). > > > > Here is a log when I don't configure debug-disable-ticker option. > > > > When we were in use of pinpad, apdu_get_status got timeout (after 5 > > seconds, the timeout value of bulk_out). See usb_bulk_write > > failed: -110. > > This is due to a bug which doesn't hold lock for _keypad functions. > > Here is a patch to fix this (against master). Same should be applied > to 2.0. > > OK to commit? > > diff --git a/scd/apdu.c b/scd/apdu.c > index 68d4e99..278e08a 100644 > --- a/scd/apdu.c > +++ b/scd/apdu.c > @@ -3429,9 +3429,18 @@ apdu_check_keypad (int slot, int command, int pin_mode, > return SW_HOST_NO_DRIVER; > > if (reader_table[slot].check_keypad) > - return reader_table[slot].check_keypad (slot, command, > + { > + int sw; > + > + if ((sw = lock_slot (slot))) > + return sw; > + > + sw = reader_table[slot].check_keypad (slot, command, > pin_mode, pinlen_min, pinlen_max, > pin_padlen); > + unlock_slot (slot); > + return sw; > + } > else > return SW_HOST_NOT_SUPPORTED; > } > @@ -3452,8 +3461,17 @@ apdu_keypad_verify (int slot, int class, int ins, int p0, int p1, int pin_mode, > return SW_HOST_NO_DRIVER; > > if (reader_table[slot].keypad_verify) > - return reader_table[slot].keypad_verify (slot, class, ins, p0, p1, > + { > + int sw; > + > + if ((sw = lock_slot (slot))) > + return sw; > + > + sw = reader_table[slot].keypad_verify (slot, class, ins, p0, p1, > &pininfo); > + unlock_slot (slot); > + return sw; > + } > else > return SW_HOST_NOT_SUPPORTED; > } > @@ -3474,8 +3492,17 @@ apdu_keypad_modify (int slot, int class, int ins, int p0, int p1, int pin_mode, > return SW_HOST_NO_DRIVER; > > if (reader_table[slot].keypad_modify) > - return reader_table[slot].keypad_modify (slot, class, ins, p0, p1, > + { > + int sw; > + > + if ((sw = lock_slot (slot))) > + return sw; > + > + sw = reader_table[slot].keypad_modify (slot, class, ins, p0, p1, > &pininfo); > + unlock_slot (slot); > + return sw; > + } > else > return SW_HOST_NOT_SUPPORTED; > } -- From wk at gnupg.org Mon Feb 4 14:40:01 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Feb 2013 14:40:01 +0100 Subject: agent: adding KEYTOCARD command (master branch) In-Reply-To: <1359938063.2696.5.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Mon, 04 Feb 2013 09:34:23 +0900") References: <1359938063.2696.5.camel@cfw2.gniibe.org> Message-ID: <87sj5c9ozy.fsf@vigenere.g10code.de> On Mon, 4 Feb 2013 01:34, gniibe at fsij.org said: > I think that the reason why it is not yet supported is because of the > shift of secret key handling to gpg-agent. Right, after that change some card specific commands are not yet working. > Instead, I'd like to propose adding "KEYTOCARD" command to gpg-agent, > which directly implements the functionality of g10/card_store_subkey. That would indeed be helpful and it looks like the right solution. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Feb 4 14:44:10 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Feb 2013 14:44:10 +0100 Subject: [Feature request] send an user agent in hkp request In-Reply-To: <20130130225643.96594dc5.jeanjacquesbrucker@gmail.com> (jbar's message of "Wed, 30 Jan 2013 22:56:43 +0100") References: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> <87ehh3ghwt.fsf@vigenere.g10code.de> <87d2wmfyic.fsf@vigenere.g10code.de> <20130130225643.96594dc5.jeanjacquesbrucker@gmail.com> Message-ID: <87obg09ot1.fsf@vigenere.g10code.de> On Wed, 30 Jan 2013 22:56, jeanjacquesbrucker at gmail.com said: > the logs to detect eventual unexpected behaviours, empty HTTP user > agent are always suspicious, and I prefer personnaly false, liar, or > little wordy user-agents, than empty ones. I don't understand what benefits you gain from that. The log should show which service is accessed and thus you can expect that the client knows about keyserver protocol. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Feb 4 15:04:06 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Feb 2013 15:04:06 +0100 Subject: Are we ready for 1.4.14? In-Reply-To: (David Shaw's message of "Fri, 11 Jan 2013 16:51:57 -0500") References: <87k3rjvf5n.fsf@vigenere.g10code.de> Message-ID: <87mwvk89bd.fsf@vigenere.g10code.de> On Fri, 11 Jan 2013 22:51, dshaw at jabberwocky.com said: > Has anyone tried the fixed SRV + https + SNI code? It worked for me, but it would be better to have more than one person test it out. I have seen no replies; shall we assume this works? David, any other patches in the queue? The only open question from my part is whether to trim the version info in the armor header. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From John at enigmail.net Mon Feb 4 17:22:00 2013 From: John at enigmail.net (John Clizbe) Date: Mon, 04 Feb 2013 10:22:00 -0600 Subject: [Feature request] send an user agent in hkp request In-Reply-To: <87obg09ot1.fsf@vigenere.g10code.de> References: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> <87ehh3ghwt.fsf@vigenere.g10code.de> <87d2wmfyic.fsf@vigenere.g10code.de> <20130130225643.96594dc5.jeanjacquesbrucker@gmail.com> <87obg09ot1.fsf@vigenere.g10code.de> Message-ID: <510FE028.6080708@enigmail.net> Werner Koch wrote: > On Wed, 30 Jan 2013 22:56, jeanjacquesbrucker at gmail.com said: > >> the logs to detect eventual unexpected behaviours, empty HTTP user >> agent are always suspicious, and I prefer personally false, liar, or >> little wordy user-agents, than empty ones. > > I don't understand what benefits you gain from that. The log should > show which service is accessed and thus you can expect that the client > knows about keyserver protocol. Nor do I. I can't say I recall seeing requests for such coming from the SKS keyserver community either. I think most of us seem to prefer to log less information about requests than more. That we've lived so long without any sort of user-agent header tells me a lot about it's necessity. -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 863 bytes Desc: OpenPGP digital signature URL: From John at enigmail.net Mon Feb 4 17:33:15 2013 From: John at enigmail.net (John Clizbe) Date: Mon, 04 Feb 2013 10:33:15 -0600 Subject: [Feature request] send an user agent in hkp request In-Reply-To: <20130130122937.2eec10a9@fabiankeil.de> References: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> <20130130122937.2eec10a9@fabiankeil.de> Message-ID: <510FE2CB.5000407@enigmail.net> Fabian Keil wrote: > David Shaw wrote: >> On Jan 27, 2013, at 5:33 AM, jbar wrote: >>> It should not be a big job, but is could be great to send an HTTP user-agent within hkp request (to search, receive and send keys from/to a key keyserver). >> >> Not passing a user-agent is actually intentional behavior. Unlike some sites which may want to behave differently for different user-agents, you get the same key blob no matter who (or what) is making the request. Given this, there is no real reason beyond tracking and statistics gathering to send a user-agent string, so we don't, as it is really nobody's business what client you are using. > > An advantage of sending a User-Agent is that it allows the proxy > to easily differentiate gpg from other clients to route the > requests differently. Since all HKP requests are under /pks, I really don't see how an User-Agent string would help differentiate them. Also the default port for HKP traffic is 11371, that alone should be enough for a proxy at the client end. > For example I do not want my gpg requests to share a Tor circuit > with my feed reader or web browser and a "User-Agent: GnuPG" > header would make this easier, IMHO without disclosing too much > information. Easier than port 11371? There's only an issue if you're sending HKP traffic on port 80. > "Detecting" gpg by looking for requests without a User-Agent header > only works as long as no other client sends no User-Agent header > either. Keyserver requests from gpg are handled no differently than requests from PGP or any other client. They are easily identified by being on port 11371 and/or being under /pks. -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 863 bytes Desc: OpenPGP digital signature URL: From freebsd-listen at fabiankeil.de Mon Feb 4 19:00:28 2013 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Mon, 4 Feb 2013 19:00:28 +0100 Subject: [Feature request] send an user agent in hkp request In-Reply-To: <510FE2CB.5000407@enigmail.net> References: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> <20130130122937.2eec10a9@fabiankeil.de> <510FE2CB.5000407@enigmail.net> Message-ID: <20130204190028.19558886@fabiankeil.de> John Clizbe wrote: > Fabian Keil wrote: > > David Shaw wrote: > >> On Jan 27, 2013, at 5:33 AM, jbar wrote: > >>> It should not be a big job, but is could be great to send an HTTP > user-agent within hkp request (to search, receive and send keys from/to a key > keyserver). > >> > >> Not passing a user-agent is actually intentional behavior. Unlike some > sites which may want to behave differently for different user-agents, you get > the same key blob no matter who (or what) is making the request. Given this, > there is no real reason beyond tracking and statistics gathering to send a > user-agent string, so we don't, as it is really nobody's business what client > you are using. > > > > An advantage of sending a User-Agent is that it allows the proxy > > to easily differentiate gpg from other clients to route the > > requests differently. > > Since all HKP requests are under /pks, I really don't see how an User-Agent > string would help differentiate them. Also the default port for HKP traffic is > 11371, that alone should be enough for a proxy at the client end. > > > For example I do not want my gpg requests to share a Tor circuit > > with my feed reader or web browser and a "User-Agent: GnuPG" > > header would make this easier, IMHO without disclosing too much > > information. > > Easier than port 11371? There's only an issue if you're sending HKP traffic on > port 80. I also access key servers with my browser and the URLs contain ":11371/pks/" as well. Additionally speculating based on the URL would be less reliable and I'd prefer using the same detection method for all clients. > > "Detecting" gpg by looking for requests without a User-Agent header > > only works as long as no other client sends no User-Agent header > > either. > > Keyserver requests from gpg are handled no differently than requests from PGP > or any other client. They are easily identified by being on port 11371 and/or > being under /pks. I was referring to the gpg detection on the proxy. I don't use PGP, but if I was, I'd probably prefer to let the proxy handle its requests differently than gpg's. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From dshaw at jabberwocky.com Mon Feb 4 19:50:16 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 4 Feb 2013 13:50:16 -0500 Subject: Are we ready for 1.4.14? In-Reply-To: <87mwvk89bd.fsf@vigenere.g10code.de> References: <87k3rjvf5n.fsf@vigenere.g10code.de> <87mwvk89bd.fsf@vigenere.g10code.de> Message-ID: <912686F1-5BD2-4DF5-B9D9-61C26397CA8D@jabberwocky.com> On Feb 4, 2013, at 9:04 AM, Werner Koch wrote: > On Fri, 11 Jan 2013 22:51, dshaw at jabberwocky.com said: > >> Has anyone tried the fixed SRV + https + SNI code? It worked for me, but it would be better to have more than one person test it out. > > I have seen no replies; shall we assume this works? > > David, any other patches in the queue? > > The only open question from my part is whether to trim the version info > in the armor header. I have a patch (written, but not committed) to not provide armor Version and Comments when sending a key via --send-key. I haven't committed it yet since there was the more general open question about Version in armor headers. David From dshaw at jabberwocky.com Mon Feb 4 19:55:16 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 4 Feb 2013 13:55:16 -0500 Subject: [Feature request] send an user agent in hkp request In-Reply-To: <20130130225643.96594dc5.jeanjacquesbrucker@gmail.com> References: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> <87ehh3ghwt.fsf@vigenere.g10code.de> <87d2wmfyic.fsf@vigenere.g10code.de> <20130130225643.96594dc5.jeanjacquesbrucker@gmail.com> Message-ID: On Jan 30, 2013, at 4:56 PM, jbar wrote: > On Wed, 30 Jan 2013 17:04:27 +0100 > Werner Koch wrote: > >> >> And before someone asks, we could of course add a --emit-full-version ;-) > > I don't consider softwares and versions as "private", but I agree with not sending such information, at least not needed, by default. And yes that could be great to have such option to enable such information in Armored data AND in the HTTP user agent. (i.e. with --armor AND with --recv-keys and --send-keys). > > Note: I don't want absolutely to have the GnuPG versions in HTTP user agent, I could also being satistfied to have only the default libcurl user-agent. Note there is no default libcurl user-agent. Or rather, the default libcurl user-agent is the empty string. The curl command line tool has one, but programs that use the library are required to explicitly set one if they want it. > The matter is that when you are a web admin, who checks the logs to detect eventual unexpected behaviours, empty HTTP user agent are always suspicious, and I prefer personnaly false, liar, or little wordy user-agents, than empty ones. We've never had a user-agent for the HKP code in GnuPG. If it was a problem, wouldn't it have come up before now? David From dshaw at jabberwocky.com Mon Feb 4 19:57:15 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 4 Feb 2013 13:57:15 -0500 Subject: [Feature request] send an user agent in hkp request In-Reply-To: <87d2wmfyic.fsf@vigenere.g10code.de> References: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> <87ehh3ghwt.fsf@vigenere.g10code.de> <87d2wmfyic.fsf@vigenere.g10code.de> Message-ID: <1BF736ED-CBC4-4A87-8264-71389A3BCC0E@jabberwocky.com> On Jan 30, 2013, at 11:04 AM, Werner Koch wrote: > On Wed, 30 Jan 2013 16:10, dshaw at jabberwocky.com said: > >> Hmm. Are you suggesting removing the Version header completely, or would simply changing the default to --no-emit-version handle this? > > I fear that there are applications which expect the Version header or at > least a header and thus I suggest to change it from > > Version: GnuPG v1.4.13 (GNU/Linux) > to > Version: GnuPG > > (maybe to "GnuPG v1" and "GnuPG v2" to see how often both branches are > used). > > And before someone asks, we could of course add a --emit-full-version ;-) Perhaps: --emit-version=full --emit-version=short --emit-version=none (or --no-emit-version) Then just default to "short". David From gnupg-devel at spodhuis.org Mon Feb 4 20:00:01 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Mon, 4 Feb 2013 14:00:01 -0500 Subject: [Feature request] send an user agent in hkp request In-Reply-To: <20130204190028.19558886@fabiankeil.de> References: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> <20130130122937.2eec10a9@fabiankeil.de> <510FE2CB.5000407@enigmail.net> <20130204190028.19558886@fabiankeil.de> Message-ID: <20130204190001.GA79944@redoubt.spodhuis.org> On 2013-02-04 at 19:00 +0100, Fabian Keil wrote: > Additionally speculating based on the URL would be less reliable > and I'd prefer using the same detection method for all clients. What's unreliable about dispatching functionality based on the URL and the path components? That's how almost all web-servers work and is fundamental to the model of URLs. If the path starts /pks/ then it goes to the keyserver; it's something speaking the Horowitz Keyserver Protocol, and if it isn't then tough, because it has asked for that, as even on ports other than 11371 the protocol, since the original thesis paper, has used URLs in that namespace. Specifically, `/pks/lookup` and `/pks/add`. You get to use the hostname and the path. That's sufficient for everyone else, and dispatching functionality based on User-Agent has always been far less reliable and advocated against, as it leads to new User-Agents having to pretend to be old ones, to get past dated checks. You _decide_ based on the URL; you might sometimes _speculate_ based on the User-Agent and choose to override the URL for stuff like bug-workarounds, setting additional HTTP headers in a response, for instance. The closest there is to a formal specification for HKP is http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00 and you might want to read it. From lists-gnupgdev at lina.inka.de Mon Feb 4 20:56:56 2013 From: lists-gnupgdev at lina.inka.de (Bernd Eckenfels) Date: Mon, 04 Feb 2013 20:56:56 +0100 Subject: [Feature request] send an user agent in hkp request In-Reply-To: <20130204190001.GA79944@redoubt.spodhuis.org> References: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> <20130130122937.2eec10a9@fabiankeil.de> <510FE2CB.5000407@enigmail.net> <20130204190028.19558886@fabiankeil.de> <20130204190001.GA79944@redoubt.spodhuis.org> Message-ID: Am 04.02.2013, 20:00 Uhr, schrieb Phil Pennock : > You get to use the hostname and the path. That's sufficient for > everyone else, and dispatching functionality based on User-Agent has > always been far less reliable and advocated against, as it leads to new > User-Agents having to pretend to be old ones, to get past dated checks. Besides that, Content-Negotiation (Accept header) would be more aproperiate if you want to do some flexible response. However I fully agree that the URL (behind a configurable base) is a far more robust/simple way. Gruss Bernd -- http://bernd.eckenfels.net From gniibe at fsij.org Tue Feb 5 05:48:23 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 05 Feb 2013 13:48:23 +0900 Subject: Supporting fixed length keypad input In-Reply-To: <1359676640.2670.2.camel@cfw2.gniibe.org> References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> <87wqvm4smu.fsf@vigenere.g10code.de> <1357779807.2924.1.camel@cfw2.gniibe.org> <50EE75B5.3090009@pietig.com> <1358217413.2667.6.camel@cfw2.gniibe.org> <1359676640.2670.2.camel@cfw2.gniibe.org> Message-ID: <1360039703.14506.1.camel@cfw2.gniibe.org> On 2013-02-01 at 08:57 +0900, NIIBE Yutaka wrote: > I'd like to merge scd-work branch to master. It will be backported > to 2.0 branch, too. I applied changes in scd-work branch to master and pushed it the repository. -- From gniibe at fsij.org Tue Feb 5 05:55:33 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 05 Feb 2013 13:55:33 +0900 Subject: agent: adding KEYTOCARD command (master branch) In-Reply-To: <87sj5c9ozy.fsf@vigenere.g10code.de> References: <1359938063.2696.5.camel@cfw2.gniibe.org> <87sj5c9ozy.fsf@vigenere.g10code.de> Message-ID: <1360040133.14506.2.camel@cfw2.gniibe.org> On 2013-02-04 at 14:40 +0100, Werner Koch wrote: > On Mon, 4 Feb 2013 01:34, gniibe at fsij.org said: > > > I think that the reason why it is not yet supported is because of the > > shift of secret key handling to gpg-agent. > > Right, after that change some card specific commands are not yet > working. Here's the patch. It works for me, but the behavior of gpg command has been changed. In 2.0, we invoke --edit-key to invoke keytocard subcommand. After we store private keys to card, it goes like this: gpg> quit Save changes? (y/N) n Quit without saving? (y/N) y $ But, master branch don't ask "Save changes?", and it has been changed already in gpg-agent's storage. gpg: Implement card_store_subkey again. * g10/call-agent.h (agent_keytocard): New. * g10/call-agent.c (agent_keytocard): New. * g10/card-util.c (replace_existing_key_p): Returns 1 when replace. (card_generate_subkey): Check return value of replace_existing_key_p. (card_store_subkey): Implement again using agent_keytocard. agent: Add KEYTOCARD command. * agent/agent.h (divert_writekey, agent_card_writekey): New. * agent/call-scd.c (inq_writekey_parms, agent_card_writekey): New. * agent/command.c (cmd_keytocard, hlp_keytocard): New. (register_commands): Add cmd_keytocard. * agent/divert-scd.c (divert_writekey): New. diff --git a/agent/agent.h b/agent/agent.h index 45bc507..8457e34 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -421,6 +421,8 @@ int divert_pkdecrypt (ctrl_t ctrl, char **r_buf, size_t *r_len); int divert_generic_cmd (ctrl_t ctrl, const char *cmdline, void *assuan_context); +int divert_writekey (ctrl_t ctrl, int force, const char *serialno, + const char *id, const char *keydata, size_t keydatalen); /*-- call-scd.c --*/ @@ -454,6 +456,11 @@ int agent_card_pkdecrypt (ctrl_t ctrl, int agent_card_readcert (ctrl_t ctrl, const char *id, char **r_buf, size_t *r_buflen); int agent_card_readkey (ctrl_t ctrl, const char *id, unsigned char **r_buf); +int agent_card_writekey (ctrl_t ctrl, int force, const char *serialno, + const char *id, const char *keydata, + size_t keydatalen, + int (*getpin_cb)(void *, const char *, char*, size_t), + void *getpin_cb_arg); gpg_error_t agent_card_getattr (ctrl_t ctrl, const char *name, char **result); int agent_card_scd (ctrl_t ctrl, const char *cmdline, int (*getpin_cb)(void *, const char *, char*, size_t), diff --git a/agent/call-scd.c b/agent/call-scd.c index 2bda377..ed80be2 100644 --- a/agent/call-scd.c +++ b/agent/call-scd.c @@ -1050,6 +1050,64 @@ agent_card_readkey (ctrl_t ctrl, const char *id, unsigned char **r_buf) } +struct writekey_parm_s +{ + assuan_context_t ctx; + int (*getpin_cb)(void *, const char *, char*, size_t); + void *getpin_cb_arg; + assuan_context_t passthru; + int any_inq_seen; + /**/ + const unsigned char *keydata; + size_t keydatalen; +}; + +/* Handle a KEYDATA inquiry. Note, we only send the data, + assuan_transact takes care of flushing and writing the end */ +static gpg_error_t +inq_writekey_parms (void *opaque, const char *line) +{ + struct writekey_parm_s *parm = opaque; + + if (!strncmp (line, "KEYDATA", 7) && (line[7]==' '||!line[7])) + return assuan_send_data (parm->ctx, parm->keydata, parm->keydatalen); + else + return inq_needpin (opaque, line); +} + + +int +agent_card_writekey (ctrl_t ctrl, int force, const char *serialno, + const char *id, const char *keydata, size_t keydatalen, + int (*getpin_cb)(void *, const char *, char*, size_t), + void *getpin_cb_arg) +{ + int rc; + char line[ASSUAN_LINELENGTH]; + struct writekey_parm_s parms; + + (void)serialno; + rc = start_scd (ctrl); + if (rc) + return rc; + + snprintf (line, DIM(line)-1, "WRITEKEY %s%s", force ? "--force " : "", id); + line[DIM(line)-1] = 0; + parms.ctx = ctrl->scd_local->ctx; + parms.getpin_cb = getpin_cb; + parms.getpin_cb_arg = getpin_cb_arg; + parms.passthru = 0; + parms.any_inq_seen = 0; + parms.keydata = keydata; + parms.keydatalen = keydatalen; + + rc = assuan_transact (ctrl->scd_local->ctx, line, NULL, NULL, + inq_writekey_parms, &parms, NULL, NULL); + if (parms.any_inq_seen && (gpg_err_code(rc) == GPG_ERR_CANCELED || + gpg_err_code(rc) == GPG_ERR_ASS_CANCELED)) + rc = cancel_inquire (ctrl, rc); + return unlock_scd (ctrl, rc); +} /* Type used with the card_getattr_cb. */ struct card_getattr_parm_s { diff --git a/agent/command.c b/agent/command.c index 3ba921b..17d266b 100644 --- a/agent/command.c +++ b/agent/command.c @@ -2119,9 +2119,123 @@ cmd_export_key (assuan_context_t ctx, char *line) return leave_cmd (ctx, err); } + +static const char hlp_keytocard[] = + "KEYTOCARD [--force] \n" + "\n"; +static gpg_error_t +cmd_keytocard (assuan_context_t ctx, char *line) +{ + ctrl_t ctrl = assuan_get_pointer (ctx); + int force; + gpg_error_t err = 0; + unsigned char grip[20]; + gcry_sexp_t s_skey = NULL; + gcry_sexp_t s_pkey = NULL; + char keydata[2048]; + size_t keydatalen, timestamplen; + const char *serialno, *timestamp_str, *id; + unsigned char *shadow_info; + unsigned char *shdkey; + time_t timestamp; + + force = has_option (line, "--force"); + line = skip_options (line); + err = parse_keygrip (ctx, line, grip); + if (err) + return err; + if (agent_key_available (grip)) + return gpg_error (GPG_ERR_NO_SECKEY); + line += 40; + while (*line && (*line == ' ' || *line == '\t')) + line++; + serialno = line; + while (*line && (*line != ' ' && *line != '\t')) + line++; + if (!*line) + return gpg_error (GPG_ERR_MISSING_VALUE); + *line = '\0'; + line++; + while (*line && (*line == ' ' || *line == '\t')) + line++; + id = line; + while (*line && (*line != ' ' && *line != '\t')) + line++; + if (!*line) + return gpg_error (GPG_ERR_MISSING_VALUE); + *line = '\0'; + line++; + while (*line && (*line == ' ' || *line == '\t')) + line++; + timestamp_str = line; + while (*line && (*line != ' ' && *line != '\t')) + line++; + if (*line) + *line = '\0'; + timestamplen = line - timestamp_str; + if (timestamplen != 15) + return gpg_error (GPG_ERR_INV_VALUE); + + err = agent_key_from_file (ctrl, NULL, ctrl->server_local->keydesc, grip, + NULL, CACHE_MODE_IGNORE, NULL, &s_skey, NULL); + if (err) + return err; + if (!s_skey) + /* Key is on a smartcard already. */ + return gpg_error (GPG_ERR_UNUSABLE_SECKEY); + + keydatalen = gcry_sexp_sprint (s_skey, GCRYSEXP_FMT_CANON, keydata, + sizeof (keydata)); + /* Add timestamp "created-at" in the private key */ + timestamp = isotime2epoch (timestamp_str); + snprintf (keydata+keydatalen-1, sizeof (keydata) - keydatalen -1, + "(10:created-at10:%010lu))", timestamp); + keydatalen += 10 + 19 - 1; + err = divert_writekey (ctrl, force, serialno, id, keydata, keydatalen); + if (err) + { + gcry_sexp_release (s_skey); + goto leave; + } + + err = agent_public_key_from_file (ctrl, grip, &s_pkey); + if (err) + { + gcry_sexp_release (s_skey); + goto leave; + } + + shadow_info = make_shadow_info (serialno, id); + if (!shadow_info) + { + err = gpg_error (GPG_ERR_ENOMEM); + gcry_sexp_release (s_pkey); + gcry_sexp_release (s_skey); + goto leave; + } + keydatalen = gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, keydata, + sizeof (keydata)); + err = agent_shadow_key (keydata, shadow_info, &shdkey); + xfree (shadow_info); + if (err) + { + log_error ("shadowing the key failed: %s\n", gpg_strerror (err)); + gcry_sexp_release (s_pkey); + gcry_sexp_release (s_skey); + goto leave; + } + keydatalen = gcry_sexp_canon_len (shdkey, 0, NULL, NULL); + err = agent_write_private_key (grip, shdkey, keydatalen, 1); + xfree (shdkey); + gcry_sexp_release (s_pkey); + gcry_sexp_release (s_skey); + + leave: + return leave_cmd (ctx, err); +} static const char hlp_getval[] = "GETVAL \n" @@ -2682,6 +2796,7 @@ register_commands (assuan_context_t ctx) { "KILLAGENT", cmd_killagent, hlp_killagent }, { "RELOADAGENT", cmd_reloadagent,hlp_reloadagent }, { "GETINFO", cmd_getinfo, hlp_getinfo }, + { "KEYTOCARD", cmd_keytocard, hlp_keytocard }, { NULL } }; int i, rc; diff --git a/agent/divert-scd.c b/agent/divert-scd.c index 656d5cd..65784a8 100644 --- a/agent/divert-scd.c +++ b/agent/divert-scd.c @@ -442,6 +442,13 @@ divert_pkdecrypt (ctrl_t ctrl, return rc; } +int +divert_writekey (ctrl_t ctrl, int force, const char *serialno, + const char *id, const char *keydata, size_t keydatalen) +{ + return agent_card_writekey (ctrl, force, serialno, id, keydata, keydatalen, + getpin_cb, ctrl); +} int divert_generic_cmd (ctrl_t ctrl, const char *cmdline, void *assuan_context) diff --git a/g10/call-agent.c b/g10/call-agent.c index a4d1dbb..2f7f21a 100644 --- a/g10/call-agent.c +++ b/g10/call-agent.c @@ -545,6 +545,30 @@ agent_learn (struct agent_card_info_s *info) return rc; } + +int +agent_keytocard (const char *hexgrip, int keyno, int force, + const char *serialno, const char *timestamp) +{ + int rc; + char line[ASSUAN_LINELENGTH]; + + snprintf (line, DIM(line)-1, "KEYTOCARD %s%s %s OPENPGP.%d %s", + force?"--force ": "", hexgrip, serialno, keyno, timestamp); + line[DIM(line)-1] = 0; + + rc = start_agent (NULL, 1); + if (rc) + return rc; + + rc = assuan_transact (agent_ctx, line, NULL, NULL, default_inq_cb, + NULL, NULL, NULL); + if (rc) + return rc; + + return rc; +} + /* Call the agent to retrieve a data object. This function returns the data in the same structure as used by the learn command. It is allowed to update such a structure using this commmand. */ diff --git a/g10/call-agent.h b/g10/call-agent.h index 43de14f..7ae5e80 100644 --- a/g10/call-agent.h +++ b/g10/call-agent.h @@ -81,6 +81,10 @@ int agent_learn (struct agent_card_info_s *info); /* Update INFO with the attribute NAME. */ int agent_scd_getattr (const char *name, struct agent_card_info_s *info); +/* Send the KEYTOCARD command. */ +int agent_keytocard (const char *hexgrip, int keyno, int force, + const char *serialno, const char *timestamp); + /* Send a SETATTR command to the SCdaemon. */ int agent_scd_setattr (const char *name, const unsigned char *value, size_t valuelen, diff --git a/g10/card-util.c b/g10/card-util.c index 8358685..75208cc 100644 --- a/g10/card-util.c +++ b/g10/card-util.c @@ -1264,6 +1264,7 @@ replace_existing_key_p (struct agent_card_info_s *info, int keyno) if ( !cpr_get_answer_is_yes( "cardedit.genkeys.replace_key", _("Replace existing key? (y/N) "))) return -1; + return 1; } return 0; } @@ -1484,7 +1485,7 @@ card_generate_subkey (KBNODE pub_keyblock) tty_printf(_("Invalid selection.\n")); } - if (replace_existing_key_p (&info, keyno)) + if (replace_existing_key_p (&info, keyno) < 0) { err = gpg_error (GPG_ERR_CANCELED); goto leave; @@ -1531,152 +1532,99 @@ card_generate_subkey (KBNODE pub_keyblock) int card_store_subkey (KBNODE node, int use) { - log_info ("FIXME: card_store_subkey has not yet been implemented\n"); -/* struct agent_card_info_s info; */ -/* int okay = 0; */ -/* int rc; */ -/* int keyno, i; */ -/* PKT_secret_key *copied_sk = NULL; */ -/* PKT_secret_key *sk; */ -/* size_t n; */ -/* const char *s; */ -/* int allow_keyno[3]; */ -/* unsigned int nbits; */ - - -/* assert (node->pkt->pkttype == PKT_SECRET_KEY */ -/* || node->pkt->pkttype == PKT_SECRET_SUBKEY); */ -/* sk = node->pkt->pkt.secret_key; */ - -/* if (get_info_for_key_operation (&info)) */ -/* return 0; */ - -/* if (!info.extcap.ki) */ -/* { */ -/* tty_printf ("The card does not support the import of keys\n"); */ -/* tty_printf ("\n"); */ -/* goto leave; */ -/* } */ - -/* show_card_key_info (&info); */ - -/* nbits = nbits_from_sk (sk); */ - -/* if (!is_RSA (sk->pubkey_algo) || (!info.is_v2 && nbits != 1024) ) */ -/* { */ -/* tty_printf ("You may only store a 1024 bit RSA key on the card\n"); */ -/* tty_printf ("\n"); */ -/* goto leave; */ -/* } */ - -/* allow_keyno[0] = (!use || (use & (PUBKEY_USAGE_SIG))); */ -/* allow_keyno[1] = (!use || (use & (PUBKEY_USAGE_ENC))); */ -/* allow_keyno[2] = (!use || (use & (PUBKEY_USAGE_SIG|PUBKEY_USAGE_AUTH))); */ - -/* tty_printf (_("Please select where to store the key:\n")); */ - -/* if (allow_keyno[0]) */ -/* tty_printf (_(" (1) Signature key\n")); */ -/* if (allow_keyno[1]) */ -/* tty_printf (_(" (2) Encryption key\n")); */ -/* if (allow_keyno[2]) */ -/* tty_printf (_(" (3) Authentication key\n")); */ - -/* for (;;) */ -/* { */ -/* char *answer = cpr_get ("cardedit.genkeys.storekeytype", */ -/* _("Your selection? ")); */ -/* cpr_kill_prompt(); */ -/* if (*answer == CONTROL_D || !*answer) */ -/* { */ -/* xfree (answer); */ -/* goto leave; */ -/* } */ -/* keyno = *answer? atoi(answer): 0; */ -/* xfree(answer); */ -/* if (keyno >= 1 && keyno <= 3 && allow_keyno[keyno-1]) */ -/* { */ -/* if (info.is_v2 && !info.extcap.aac */ -/* && info.key_attr[keyno-1].nbits != nbits) */ -/* { */ -/* tty_printf ("Key does not match the card's capability.\n"); */ -/* } */ -/* else */ -/* break; /\* Okay. *\/ */ -/* } */ -/* else */ -/* tty_printf(_("Invalid selection.\n")); */ -/* } */ - -/* if (replace_existing_key_p (&info, keyno)) */ -/* goto leave; */ - -/* /\* Unprotect key. *\/ */ -/* switch (is_secret_key_protected (sk) ) */ -/* { */ -/* case 0: /\* Not protected. *\/ */ -/* break; */ -/* case -1: */ -/* log_error (_("unknown key protection algorithm\n")); */ -/* goto leave; */ -/* default: */ -/* if (sk->protect.s2k.mode == 1001) */ -/* { */ -/* log_error (_("secret parts of key are not available\n")); */ -/* goto leave; */ -/* } */ -/* if (sk->protect.s2k.mode == 1002) */ -/* { */ -/* log_error (_("secret key already stored on a card\n")); */ -/* goto leave; */ -/* } */ -/* /\* We better copy the key before we unprotect it. *\/ */ -/* copied_sk = sk = copy_secret_key (NULL, sk); */ -/* rc = 0/\*check_secret_key (sk, 0)*\/; */ -/* if (rc) */ -/* goto leave; */ -/* } */ - -/* #warning code save_unprotected_key_to_card */ -/* /\* rc = save_unprotected_key_to_card (sk, keyno); *\/ */ -/* /\* if (rc) *\/ */ -/* /\* { *\/ */ -/* /\* log_error (_("error writing key to card: %s\n"), gpg_strerror (rc)); *\/ */ -/* /\* goto leave; *\/ */ -/* /\* } *\/ */ - -/* /\* Get back to the maybe protected original secret key. *\/ */ -/* if (copied_sk) */ -/* { */ -/* free_secret_key (copied_sk); */ -/* copied_sk = NULL; */ -/* } */ -/* sk = node->pkt->pkt.secret_key; */ - -/* /\* Get rid of the secret key parameters and store the serial numer. *\/ */ -/* n = pubkey_get_nskey (sk->pubkey_algo); */ -/* for (i=pubkey_get_npkey (sk->pubkey_algo); i < n; i++) */ -/* { */ -/* gcry_mpi_release (sk->skey[i]); */ -/* sk->skey[i] = NULL; */ -/* } */ -/* i = pubkey_get_npkey (sk->pubkey_algo); */ -/* sk->skey[i] = gcry_mpi_set_opaque (NULL, xstrdup ("dummydata"), 10*8); */ -/* sk->is_protected = 1; */ -/* sk->protect.s2k.mode = 1002; */ -/* s = info.serialno; */ -/* for (sk->protect.ivlen=0; sk->protect.ivlen < 16 && *s && s[1]; */ -/* sk->protect.ivlen++, s += 2) */ -/* sk->protect.iv[sk->protect.ivlen] = xtoi_2 (s); */ - -/* okay = 1; */ - -/* leave: */ -/* if (copied_sk) */ -/* free_secret_key (copied_sk); */ -/* agent_release_card_info (&info); */ -/* return okay; */ - return -1; + struct agent_card_info_s info; + int okay = 0; + unsigned int nbits; + int allow_keyno[3]; + int keyno; + PKT_public_key *pk; + gpg_error_t err; + char *hexgrip; + int rc; + gnupg_isotime_t timebuf; + + assert (node->pkt->pkttype == PKT_PUBLIC_KEY + || node->pkt->pkttype == PKT_PUBLIC_SUBKEY); + + pk = node->pkt->pkt.public_key; + + if (get_info_for_key_operation (&info)) + return 0; + + if (!info.extcap.ki) + { + tty_printf ("The card does not support the import of keys\n"); + tty_printf ("\n"); + goto leave; + } + + nbits = nbits_from_pk (pk); + + if (!is_RSA (pk->pubkey_algo) || (!info.is_v2 && nbits != 1024) ) + { + tty_printf ("You may only store a 1024 bit RSA key on the card\n"); + tty_printf ("\n"); + goto leave; + } + + allow_keyno[0] = (!use || (use & (PUBKEY_USAGE_SIG))); + allow_keyno[1] = (!use || (use & (PUBKEY_USAGE_ENC))); + allow_keyno[2] = (!use || (use & (PUBKEY_USAGE_SIG|PUBKEY_USAGE_AUTH))); + + tty_printf (_("Please select where to store the key:\n")); + + if (allow_keyno[0]) + tty_printf (_(" (1) Signature key\n")); + if (allow_keyno[1]) + tty_printf (_(" (2) Encryption key\n")); + if (allow_keyno[2]) + tty_printf (_(" (3) Authentication key\n")); + + for (;;) + { + char *answer = cpr_get ("cardedit.genkeys.storekeytype", + _("Your selection? ")); + cpr_kill_prompt(); + if (*answer == CONTROL_D || !*answer) + { + xfree (answer); + goto leave; + } + keyno = *answer? atoi(answer): 0; + xfree(answer); + if (keyno >= 1 && keyno <= 3 && allow_keyno[keyno-1]) + { + if (info.is_v2 && !info.extcap.aac + && info.key_attr[keyno-1].nbits != nbits) + { + tty_printf ("Key does not match the card's capability.\n"); + } + else + break; /* Okay. */ + } + else + tty_printf(_("Invalid selection.\n")); + } + + if ((rc = replace_existing_key_p (&info, keyno)) < 0) + goto leave; + + err = hexkeygrip_from_pk (pk, &hexgrip); + if (err) + goto leave; + + epoch2isotime (timebuf, (time_t)pk->timestamp); + agent_keytocard (hexgrip, keyno, rc, info.serialno, timebuf); + + if (rc) + log_error (_("KEYTOCARD failed: %s\n"), gpg_strerror (rc)); + else + okay = 1; + xfree (hexgrip); + + leave: + agent_release_card_info (&info); + return okay; } -- From freebsd-listen at fabiankeil.de Tue Feb 5 11:43:37 2013 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Tue, 5 Feb 2013 11:43:37 +0100 Subject: [Feature request] send an user agent in hkp request In-Reply-To: <20130204190001.GA79944@redoubt.spodhuis.org> References: <20130127113340.d1de6902.jeanjacquesbrucker@gmail.com> <20130130122937.2eec10a9@fabiankeil.de> <510FE2CB.5000407@enigmail.net> <20130204190028.19558886@fabiankeil.de> <20130204190001.GA79944@redoubt.spodhuis.org> Message-ID: <20130205114337.34ea89eb@fabiankeil.de> Phil Pennock wrote: > On 2013-02-04 at 19:00 +0100, Fabian Keil wrote: > > Additionally speculating based on the URL would be less reliable > > and I'd prefer using the same detection method for all clients. > > What's unreliable about dispatching functionality based on the URL and > the path components? That's how almost all web-servers work and is > fundamental to the model of URLs. The context you didn't bother to preserve was Tor circuit separation for gpg requests. "Detecting" gpg based on the URL would allow Tor exit relays and untrustworthy websites to get the browser to use the same circuits as gpg which is undesirable. > If the path starts /pks/ then it goes to the keyserver; it's something > speaking the Horowitz Keyserver Protocol, and if it isn't then tough, > because it has asked for that, as even on ports other than 11371 the > protocol, since the original thesis paper, has used URLs in that > namespace. Specifically, `/pks/lookup` and `/pks/add`. The "requirement" isn't to differentiate keyserver URLs from other URLs, but to reliably differentiate requests from gpg from requests coming from different clients without allowing remote third-parties to sabotage the detection. > You get to use the hostname and the path. That's sufficient for > everyone else, and dispatching functionality based on User-Agent has > always been far less reliable and advocated against, as it leads to new > User-Agents having to pretend to be old ones, to get past dated checks. Tor circuit separation for gpg has been discussed on or-talk@ several times in the past so clearly using hostname and path is not "sufficient for everyone else". > You _decide_ based on the URL; you might sometimes _speculate_ based on > the User-Agent and choose to override the URL for stuff like > bug-workarounds, setting additional HTTP headers in a response, for > instance. > > The closest there is to a formal specification for HKP is > http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00 > and you might want to read it. Given that it's based on HTTP the "formal specification" already allows setting the User-Agent. In fact, browsers already set the User-Agent when using keyservers. As far as I can tell the keyservers just ignore the header and thus this doesn't affect the reliability in any way. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From gniibe at fsij.org Wed Feb 6 09:19:30 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 06 Feb 2013 17:19:30 +0900 Subject: Supporting fixed length keypad input In-Reply-To: <1360039703.14506.1.camel@cfw2.gniibe.org> References: <1357633878.10080.3.camel@cfw2.gniibe.org> <87obgz6853.fsf@vigenere.g10code.de> <1357698164.2912.1.camel@cfw2.gniibe.org> <87wqvm4smu.fsf@vigenere.g10code.de> <1357779807.2924.1.camel@cfw2.gniibe.org> <50EE75B5.3090009@pietig.com> <1358217413.2667.6.camel@cfw2.gniibe.org> <1359676640.2670.2.camel@cfw2.gniibe.org> <1360039703.14506.1.camel@cfw2.gniibe.org> Message-ID: <1360138770.3564.6.camel@cfw2.gniibe.org> On 2013-02-05 at 13:48 +0900, NIIBE Yutaka wrote: > On 2013-02-01 at 08:57 +0900, NIIBE Yutaka wrote: > > I'd like to merge scd-work branch to master. It will be backported > > to 2.0 branch, too. > > I applied changes in scd-work branch to master and pushed it the > repository. Backported to 2.0 and pushed it to 2.0 branch. -- From gniibe at fsij.org Thu Feb 7 02:24:36 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 07 Feb 2013 10:24:36 +0900 Subject: [PATCH] Rename keypad to pinpad Message-ID: <1360200276.2675.7.camel@cfw2.gniibe.org> This is the change to rename "keypad" to "pinpad". It's not only implementation (functions and constants), but also commands in agent<-> scdaemon protocol and options. I'll apply this to both of master and 2.0. * agent/divert-scd.c (getpin_cb): Change message. * agent/call-scd.c (inq_needpin): Change the protocol to POPUPPINPADPROMPT and DISMISSPINPADPROMPT. * scd/command.c (pin_cb): Likewise. * scd/apdu.c (struct reader_table_s): Rename member functions. (check_pcsc_pinpad, pcsc_pinpad_verify, pcsc_pinpad_modify, check_ccid_pinpad, ccid_pinpad_operation, apdu_check_pinpad apdu_pinpad_verify, apdu_pinpad_modify): Rename. * scd/apdu.h (SW_HOST_NO_PINPAD, apdu_check_pinpad) (apdu_pinpad_verify, apdu_pinpad_modify): Rename. * scd/iso7816.h (iso7816_check_pinpad): Rename. * scd/iso7816.c (map_sw): Use SW_HOST_NO_PINPAD. (iso7816_check_pinpad): Rename. (iso7816_verify_kp, iso7816_change_reference_data_kp): Follow the change. * scd/ccid-driver.h (CCID_DRIVER_ERR_NO_PINPAD): Rename. * scd/ccid-driver.c (ccid_transceive_secure): Use it. * scd/app-dinsig.c (verify_pin): Follow the change. * scd/app-nks.c (verify_pin): Follow the change. * scd/app-openpgp.c (check_pinpad_request): Rename. (parse_login_data, verify_a_chv, verify_chv3, do_change_pin): Follow the change. * scd/scdaemon.c (oDisablePinpad, oEnablePinpadVarlen): Rename. * scd/scdaemon.h (opt): Rename to disable_pinpad, enable_pinpad_varlen. * tools/gpgconf-comp.c (gc_options_scdaemon): Rename to disable-pinpad. diff --git a/agent/call-scd.c b/agent/call-scd.c index 2bda377..00b34ed 100644 --- a/agent/call-scd.c +++ b/agent/call-scd.c @@ -722,7 +722,7 @@ inq_needpin (void *opaque, const char *line) rc = assuan_send_data (parm->ctx, pin, pinlen); xfree (pin); } - else if (!strncmp (line, "POPUPKEYPADPROMPT", 17) + else if (!strncmp (line, "POPUPPINPADPROMPT", 17) && (line[17] == ' ' || !line[17])) { line += 17; @@ -731,7 +731,7 @@ inq_needpin (void *opaque, const char *line) rc = parm->getpin_cb (parm->getpin_cb_arg, line, NULL, 1); } - else if (!strncmp (line, "DISMISSKEYPADPROMPT", 19) + else if (!strncmp (line, "DISMISSPINPADPROMPT", 19) && (line[19] == ' ' || !line[19])) { rc = parm->getpin_cb (parm->getpin_cb_arg, "", NULL, 0); diff --git a/agent/divert-scd.c b/agent/divert-scd.c index 656d5cd..5d53891 100644 --- a/agent/divert-scd.c +++ b/agent/divert-scd.c @@ -223,7 +223,7 @@ getpin_cb (void *opaque, const char *info, char *buf, size_t maxbuf) else if (info && *info == '|') log_debug ("pin_cb called without proper PIN info hack\n"); - /* If BUF has been passed as NULL, we are in keypad mode: The + /* If BUF has been passed as NULL, we are in pinpad mode: The callback opens the popup and immediatley returns. */ if (!buf) { @@ -239,7 +239,7 @@ getpin_cb (void *opaque, const char *info, char *buf, size_t maxbuf) char *desc; if ( asprintf (&desc, - _("%s%%0A%%0AUse the reader's keypad for input."), + _("%s%%0A%%0AUse the reader's pinpad for input."), info) < 0 ) rc = gpg_error_from_syserror (); else diff --git a/doc/scdaemon.texi b/doc/scdaemon.texi index 200fed8..ed2cc51 100644 --- a/doc/scdaemon.texi +++ b/doc/scdaemon.texi @@ -287,10 +287,18 @@ Note that with the current version of Scdaemon the card is powered down immediately at the next timer tick for any value of @var{n} other than 0. - - at item --disable-keypad - at opindex disable-keypad -Even if a card reader features a keypad, do not try to use it. + at item --enable-pinpad-varlen + at opindex enable-pinpad-varlen +Please specify this option when the card reader supports variable +length input for pinpad (default is no). For known readers listed in +ccid-driver, this option is not needed. Note that if your card reader +doesn't supports variable length input but you want to use it, you +need to specify your pinpad request on your card. + + + at item --disable-pinpad + at opindex disable-pinpad +Even if a card reader features a pinpad, do not try to use it. @item --deny-admin diff --git a/scd/apdu.c b/scd/apdu.c index ef7c54f..6824ded 100644 --- a/scd/apdu.c +++ b/scd/apdu.c @@ -97,11 +97,11 @@ struct reader_table_s { int (*get_status_reader)(int, unsigned int *); int (*send_apdu_reader)(int,unsigned char *,size_t, unsigned char *, size_t *, pininfo_t *); - int (*check_keypad)(int, int, pininfo_t *); + int (*check_pinpad)(int, int, pininfo_t *); void (*dump_status_reader)(int); int (*set_progress_cb)(int, gcry_handler_progress_t, void*); - int (*keypad_verify)(int, int, int, int, int, pininfo_t *); - int (*keypad_modify)(int, int, int, int, int, pininfo_t *); + int (*pinpad_verify)(int, int, int, int, int, pininfo_t *); + int (*pinpad_modify)(int, int, int, int, int, pininfo_t *); struct { ccid_driver_t handle; @@ -319,10 +319,10 @@ static int reset_pcsc_reader (int slot); static int apdu_get_status_internal (int slot, int hang, int no_atr_reset, unsigned int *status, unsigned int *changed); -static int check_pcsc_keypad (int slot, int command, pininfo_t *pininfo); -static int pcsc_keypad_verify (int slot, int class, int ins, int p0, int p1, +static int check_pcsc_pinpad (int slot, int command, pininfo_t *pininfo); +static int pcsc_pinpad_verify (int slot, int class, int ins, int p0, int p1, pininfo_t *pininfo); -static int pcsc_keypad_modify (int slot, int class, int ins, int p0, int p1, +static int pcsc_pinpad_modify (int slot, int class, int ins, int p0, int p1, pininfo_t *pininfo); @@ -369,11 +369,11 @@ new_reader_slot (void) reader_table[reader].reset_reader = NULL; reader_table[reader].get_status_reader = NULL; reader_table[reader].send_apdu_reader = NULL; - reader_table[reader].check_keypad = check_pcsc_keypad; + reader_table[reader].check_pinpad = check_pcsc_pinpad; reader_table[reader].dump_status_reader = NULL; reader_table[reader].set_progress_cb = NULL; - reader_table[reader].keypad_verify = pcsc_keypad_verify; - reader_table[reader].keypad_modify = pcsc_keypad_modify; + reader_table[reader].pinpad_verify = pcsc_pinpad_verify; + reader_table[reader].pinpad_modify = pcsc_pinpad_modify; reader_table[reader].used = 1; reader_table[reader].any_status = 0; @@ -428,7 +428,7 @@ host_sw_string (long err) case SW_HOST_GENERAL_ERROR: return "general error"; case SW_HOST_NO_READER: return "no reader"; case SW_HOST_ABORTED: return "aborted"; - case SW_HOST_NO_KEYPAD: return "no keypad"; + case SW_HOST_NO_PINPAD: return "no pinpad"; case SW_HOST_ALREADY_CONNECTED: return "already connected"; default: return "unknown host status error"; } @@ -661,10 +661,10 @@ open_ct_reader (int port) reader_table[reader].reset_reader = reset_ct_reader; reader_table[reader].get_status_reader = ct_get_status; reader_table[reader].send_apdu_reader = ct_send_apdu; - reader_table[reader].check_keypad = NULL; + reader_table[reader].check_pinpad = NULL; reader_table[reader].dump_status_reader = ct_dump_reader_status; - reader_table[reader].keypad_verify = NULL; - reader_table[reader].keypad_modify = NULL; + reader_table[reader].pinpad_verify = NULL; + reader_table[reader].pinpad_modify = NULL; dump_reader_status (reader); return reader; @@ -1978,9 +1978,9 @@ open_pcsc_reader (const char *portstr) /* Check whether the reader supports the ISO command code COMMAND - on the keypad. Return 0 on success. */ + on the pinpad. Return 0 on success. */ static int -check_pcsc_keypad (int slot, int command, pininfo_t *pininfo) +check_pcsc_pinpad (int slot, int command, pininfo_t *pininfo) { unsigned char buf[256]; size_t len = 256; @@ -2037,7 +2037,7 @@ check_pcsc_keypad (int slot, int command, pininfo_t *pininfo) #define PIN_VERIFY_STRUCTURE_SIZE 24 static int -pcsc_keypad_verify (int slot, int class, int ins, int p0, int p1, +pcsc_pinpad_verify (int slot, int class, int ins, int p0, int p1, pininfo_t *pininfo) { int sw; @@ -2120,7 +2120,7 @@ pcsc_keypad_verify (int slot, int class, int ins, int p0, int p1, #define PIN_MODIFY_STRUCTURE_SIZE 29 static int -pcsc_keypad_modify (int slot, int class, int ins, int p0, int p1, +pcsc_pinpad_modify (int slot, int class, int ins, int p0, int p1, pininfo_t *pininfo) { int sw; @@ -2325,10 +2325,10 @@ send_apdu_ccid (int slot, unsigned char *apdu, size_t apdulen, /* Check whether the CCID reader supports the ISO command code COMMAND - on the keypad. Return 0 on success. For a description of the pin + on the pinpad. Return 0 on success. For a description of the pin parameters, see ccid-driver.c */ static int -check_ccid_keypad (int slot, int command, pininfo_t *pininfo) +check_ccid_pinpad (int slot, int command, pininfo_t *pininfo) { unsigned char apdu[] = { 0, 0, 0, 0x81 }; @@ -2339,7 +2339,7 @@ check_ccid_keypad (int slot, int command, pininfo_t *pininfo) static int -ccid_keypad_operation (int slot, int class, int ins, int p0, int p1, +ccid_pinpad_operation (int slot, int class, int ins, int p0, int p1, pininfo_t *pininfo) { unsigned char apdu[4]; @@ -2406,11 +2406,11 @@ open_ccid_reader (const char *portstr) reader_table[slot].reset_reader = reset_ccid_reader; reader_table[slot].get_status_reader = get_status_ccid; reader_table[slot].send_apdu_reader = send_apdu_ccid; - reader_table[slot].check_keypad = check_ccid_keypad; + reader_table[slot].check_pinpad = check_ccid_pinpad; reader_table[slot].dump_status_reader = dump_ccid_reader_status; reader_table[slot].set_progress_cb = set_progress_cb_ccid_reader; - reader_table[slot].keypad_verify = ccid_keypad_operation; - reader_table[slot].keypad_modify = ccid_keypad_operation; + reader_table[slot].pinpad_verify = ccid_pinpad_operation; + reader_table[slot].pinpad_modify = ccid_pinpad_operation; /* Our CCID reader code does not support T=0 at all, thus reset the flag. */ reader_table[slot].is_t0 = 0; @@ -2701,10 +2701,10 @@ open_rapdu_reader (int portno, reader_table[slot].reset_reader = reset_rapdu_reader; reader_table[slot].get_status_reader = my_rapdu_get_status; reader_table[slot].send_apdu_reader = my_rapdu_send_apdu; - reader_table[slot].check_keypad = NULL; + reader_table[slot].check_pinpad = NULL; reader_table[slot].dump_status_reader = NULL; - reader_table[slot].keypad_verify = NULL; - reader_table[slot].keypad_modify = NULL; + reader_table[slot].pinpad_verify = NULL; + reader_table[slot].pinpad_modify = NULL; dump_reader_status (slot); rapdu_msg_release (msg); @@ -3392,25 +3392,25 @@ apdu_get_status (int slot, int hang, /* Check whether the reader supports the ISO command code COMMAND on - the keypad. Return 0 on success. For a description of the pin + the pinpad. Return 0 on success. For a description of the pin parameters, see ccid-driver.c */ int -apdu_check_keypad (int slot, int command, pininfo_t *pininfo) +apdu_check_pinpad (int slot, int command, pininfo_t *pininfo) { if (slot < 0 || slot >= MAX_READER || !reader_table[slot].used ) return SW_HOST_NO_DRIVER; - if (opt.enable_keypad_varlen) + if (opt.enable_pinpad_varlen) pininfo->fixedlen = 0; - if (reader_table[slot].check_keypad) + if (reader_table[slot].check_pinpad) { int sw; if ((sw = lock_slot (slot))) return sw; - sw = reader_table[slot].check_keypad (slot, command, pininfo); + sw = reader_table[slot].check_pinpad (slot, command, pininfo); unlock_slot (slot); return sw; } @@ -3420,20 +3420,20 @@ apdu_check_keypad (int slot, int command, pininfo_t *pininfo) int -apdu_keypad_verify (int slot, int class, int ins, int p0, int p1, +apdu_pinpad_verify (int slot, int class, int ins, int p0, int p1, pininfo_t *pininfo) { if (slot < 0 || slot >= MAX_READER || !reader_table[slot].used ) return SW_HOST_NO_DRIVER; - if (reader_table[slot].keypad_verify) + if (reader_table[slot].pinpad_verify) { int sw; if ((sw = lock_slot (slot))) return sw; - sw = reader_table[slot].keypad_verify (slot, class, ins, p0, p1, + sw = reader_table[slot].pinpad_verify (slot, class, ins, p0, p1, pininfo); unlock_slot (slot); return sw; @@ -3444,20 +3444,20 @@ apdu_keypad_verify (int slot, int class, int ins, int p0, int p1, int -apdu_keypad_modify (int slot, int class, int ins, int p0, int p1, +apdu_pinpad_modify (int slot, int class, int ins, int p0, int p1, pininfo_t *pininfo) { if (slot < 0 || slot >= MAX_READER || !reader_table[slot].used ) return SW_HOST_NO_DRIVER; - if (reader_table[slot].keypad_modify) + if (reader_table[slot].pinpad_modify) { int sw; if ((sw = lock_slot (slot))) return sw; - sw = reader_table[slot].keypad_modify (slot, class, ins, p0, p1, + sw = reader_table[slot].pinpad_modify (slot, class, ins, p0, p1, pininfo); unlock_slot (slot); return sw; @@ -3487,7 +3487,7 @@ send_apdu (int slot, unsigned char *apdu, size_t apdulen, /* Core APDU tranceiver function. Parameters are described at - apdu_send_le with the exception of PININFO which indicates keypad + apdu_send_le with the exception of PININFO which indicates pinpad related operations if not NULL. If EXTENDED_MODE is not 0 command chaining or extended length will be used according to these values: diff --git a/scd/apdu.h b/scd/apdu.h index c69fe36..37f9f43 100644 --- a/scd/apdu.h +++ b/scd/apdu.h @@ -69,7 +69,7 @@ enum { SW_HOST_GENERAL_ERROR = 0x1000b, SW_HOST_NO_READER = 0x1000c, SW_HOST_ABORTED = 0x1000d, - SW_HOST_NO_KEYPAD = 0x1000e, + SW_HOST_NO_PINPAD = 0x1000e, SW_HOST_ALREADY_CONNECTED = 0x1000f }; @@ -114,10 +114,10 @@ int apdu_set_progress_cb (int slot, gcry_handler_progress_t cb, void *cb_arg); int apdu_reset (int slot); int apdu_get_status (int slot, int hang, unsigned int *status, unsigned int *changed); -int apdu_check_keypad (int slot, int command, pininfo_t *pininfo); -int apdu_keypad_verify (int slot, int class, int ins, int p0, int p1, +int apdu_check_pinpad (int slot, int command, pininfo_t *pininfo); +int apdu_pinpad_verify (int slot, int class, int ins, int p0, int p1, pininfo_t *pininfo); -int apdu_keypad_modify (int slot, int class, int ins, int p0, int p1, +int apdu_pinpad_modify (int slot, int class, int ins, int p0, int p1, pininfo_t *pininfo); int apdu_send_simple (int slot, int extended_mode, int class, int ins, int p0, int p1, diff --git a/scd/app-dinsig.c b/scd/app-dinsig.c index 9d4ebe2..7dad6b1 100644 --- a/scd/app-dinsig.c +++ b/scd/app-dinsig.c @@ -292,11 +292,11 @@ verify_pin (app_t app, pininfo.minlen = 6; pininfo.maxlen = 8; - if (!opt.disable_keypad - && !iso7816_check_keypad (app->slot, ISO7816_VERIFY, &pininfo) ) + if (!opt.disable_pinpad + && !iso7816_check_pinpad (app->slot, ISO7816_VERIFY, &pininfo) ) { rc = pincb (pincb_arg, - _("||Please enter your PIN at the reader's keypad"), + _("||Please enter your PIN at the reader's pinpad"), NULL); if (rc) { @@ -308,7 +308,7 @@ verify_pin (app_t app, /* Dismiss the prompt. */ pincb (pincb_arg, NULL, NULL); } - else /* No Keypad. */ + else /* No Pinpad. */ { char *pinvalue; diff --git a/scd/app-nks.c b/scd/app-nks.c index 8a48871..72e726d 100644 --- a/scd/app-nks.c +++ b/scd/app-nks.c @@ -792,8 +792,8 @@ verify_pin (app_t app, int pwid, const char *desc, pininfo.minlen = 6; pininfo.maxlen = 16; - if (!opt.disable_keypad - && !iso7816_check_keypad (app->slot, ISO7816_VERIFY, &pininfo) ) + if (!opt.disable_pinpad + && !iso7816_check_pinpad (app->slot, ISO7816_VERIFY, &pininfo) ) { rc = pincb (pincb_arg, desc, NULL); if (rc) diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 3693833..23b28c3 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -191,13 +191,13 @@ struct app_local_s { unsigned int def_chv2:1; /* Use 123456 for CHV2. */ } flags; - /* Keypad request specified on card. */ + /* Pinpad request specified on card. */ struct { unsigned int specified:1; int fixedlen_user; int fixedlen_admin; - } keypad; + } pinpad; struct { @@ -600,11 +600,11 @@ count_bits (const unsigned char *a, size_t len) Bit 1 = CHV2 has been been set to the default PIN of "123456" (this implies that bit 0 is also set). - P= + P= - Where KEYPAD_REQUEST is in the format of: or ,. + Where PINPAD_REQUEST is in the format of: or ,. N for user PIN, M for admin PIN. If M is missing it means M=N. - 0 means to force not to use keypad. + 0 means to force not to use pinpad. */ static void @@ -617,9 +617,9 @@ parse_login_data (app_t app) /* Set defaults. */ app->app_local->flags.no_sync = 0; app->app_local->flags.def_chv2 = 0; - app->app_local->keypad.specified = 0; - app->app_local->keypad.fixedlen_user = -1; - app->app_local->keypad.fixedlen_admin = -1; + app->app_local->pinpad.specified = 0; + app->app_local->pinpad.fixedlen_user = -1; + app->app_local->pinpad.fixedlen_admin = -1; /* Read the DO. */ relptr = get_one_do (app, 0x005E, &buffer, &buflen, NULL); @@ -654,7 +654,7 @@ parse_login_data (app_t app) } else if (buflen > 1 && *buffer == 'P' && buffer[1] == '=') { - /* Keypad request control sequence found. */ + /* Pinpad request control sequence found. */ buffer += 2; buflen -= 2; @@ -687,9 +687,9 @@ parse_login_data (app_t app) if (buflen && !(*buffer == '\n' || *buffer == '\x18')) goto next; - app->app_local->keypad.specified = 1; - app->app_local->keypad.fixedlen_user = n; - app->app_local->keypad.fixedlen_admin = m; + app->app_local->pinpad.specified = 1; + app->app_local->pinpad.fixedlen_user = n; + app->app_local->pinpad.fixedlen_admin = m; } } } @@ -1530,14 +1530,14 @@ do_readcert (app_t app, const char *certid, } -/* Decide if we use the keypad of the reader for PIN input according +/* Decide if we use the pinpad of the reader for PIN input according to the user preference on the card, and the capability of the - reader. This routine is only called when the reader has keypad. - Returns 0 if we use keypad, 1 otherwise. */ + reader. This routine is only called when the reader has pinpad. + Returns 0 if we use pinpad, 1 otherwise. */ static int -check_keypad_request (app_t app, pininfo_t *pininfo, int admin_pin) +check_pinpad_request (app_t app, pininfo_t *pininfo, int admin_pin) { - if (app->app_local->keypad.specified == 0) /* No preference on card. */ + if (app->app_local->pinpad.specified == 0) /* No preference on card. */ { if (pininfo->fixedlen == 0) /* Reader has varlen capability. */ return 0; /* Then, use pinpad. */ @@ -1550,9 +1550,9 @@ check_keypad_request (app_t app, pininfo_t *pininfo, int admin_pin) } if (admin_pin) - pininfo->fixedlen = app->app_local->keypad.fixedlen_admin; + pininfo->fixedlen = app->app_local->pinpad.fixedlen_admin; else - pininfo->fixedlen = app->app_local->keypad.fixedlen_user; + pininfo->fixedlen = app->app_local->pinpad.fixedlen_user; if (pininfo->fixedlen == 0 /* User requests disable pinpad. */ || pininfo->fixedlen < pininfo->minlen @@ -1566,14 +1566,14 @@ check_keypad_request (app_t app, pininfo_t *pininfo, int admin_pin) /* Verify a CHV either using using the pinentry or if possibile by - using a keypad. PINCB and PINCB_ARG describe the usual callback + using a pinpad. PINCB and PINCB_ARG describe the usual callback for the pinentry. CHVNO must be either 1 or 2. SIGCOUNT is only used with CHV1. PINVALUE is the address of a pointer which will receive a newly allocated block with the actual PIN (this is useful in case that PIN shall be used for another verify operation). The caller needs to free this value. If the function returns with success and NULL is stored at PINVALUE, the caller should take this - as an indication that the keypad has been used. + as an indication that the pinpad has been used. */ static gpg_error_t verify_a_chv (app_t app, @@ -1631,13 +1631,13 @@ verify_a_chv (app_t app, prompt = _("||Please enter the PIN"); - if (!opt.disable_keypad - && !iso7816_check_keypad (app->slot, ISO7816_VERIFY, &pininfo) - && !check_keypad_request (app, &pininfo, 0)) + if (!opt.disable_pinpad + && !iso7816_check_pinpad (app->slot, ISO7816_VERIFY, &pininfo) + && !check_pinpad_request (app, &pininfo, 0)) { - /* The reader supports the verify command through the keypad. + /* The reader supports the verify command through the pinpad. Note that the pincb appends a text to the prompt telling the - user to use the keypad. */ + user to use the pinpad. */ rc = pincb (pincb_arg, prompt, NULL); prompt = NULL; xfree (prompt_buffer); @@ -1656,7 +1656,7 @@ verify_a_chv (app_t app, } else { - /* The reader has no keypad or we don't want to use it. */ + /* The reader has no pinpad or we don't want to use it. */ rc = pincb (pincb_arg, prompt, pinvalue); prompt = NULL; xfree (prompt_buffer); @@ -1716,7 +1716,7 @@ verify_chv2 (app_t app, /* For convenience we verify CHV1 here too. We do this only if the card is not configured to require a verification before each CHV1 controlled operation (force_chv1) and if we are not - using the keypad (PINVALUE == NULL). */ + using the pinpad (PINVALUE == NULL). */ rc = iso7816_verify (app->slot, 0x81, pinvalue, strlen (pinvalue)); if (gpg_err_code (rc) == GPG_ERR_BAD_PIN) rc = gpg_error (GPG_ERR_PIN_NOT_SYNCED); @@ -1815,11 +1815,11 @@ verify_chv3 (app_t app, if (rc) return rc; - if (!opt.disable_keypad - && !iso7816_check_keypad (app->slot, ISO7816_VERIFY, &pininfo) - && !check_keypad_request (app, &pininfo, 1)) + if (!opt.disable_pinpad + && !iso7816_check_pinpad (app->slot, ISO7816_VERIFY, &pininfo) + && !check_pinpad_request (app, &pininfo, 1)) { - /* The reader supports the verify command through the keypad. */ + /* The reader supports the verify command through the pinpad. */ rc = pincb (pincb_arg, prompt, NULL); xfree (prompt); prompt = NULL; @@ -2015,7 +2015,7 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr, int reset_mode = !!(flags & APP_CHANGE_FLAG_RESET); int set_resetcode = 0; pininfo_t pininfo; - int use_keypad = 0; + int use_pinpad = 0; int minlen = 6; (void)ctrl; @@ -2065,16 +2065,16 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr, { /* Version 2 cards. */ - if (!opt.disable_keypad - && !iso7816_check_keypad (app->slot, + if (!opt.disable_pinpad + && !iso7816_check_pinpad (app->slot, ISO7816_CHANGE_REFERENCE_DATA, &pininfo) - && !check_keypad_request (app, &pininfo, chvno == 3)) - use_keypad = 1; + && !check_pinpad_request (app, &pininfo, chvno == 3)) + use_pinpad = 1; if (reset_mode) { /* To reset a PIN the Admin PIN is required. */ - use_keypad = 0; + use_pinpad = 0; app->did_chv3 = 0; rc = verify_chv3 (app, pincb, pincb_arg); if (rc) @@ -2085,7 +2085,7 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr, } else if (chvno == 1 || chvno == 3) { - if (!use_keypad) + if (!use_pinpad) { char *promptbuf = NULL; const char *prompt; @@ -2128,7 +2128,7 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr, size_t valuelen; int remaining; - use_keypad = 0; + use_pinpad = 0; minlen = 8; relptr = get_one_do (app, 0x00C4, &value, &valuelen, NULL); if (!relptr || valuelen < 7) @@ -2176,7 +2176,7 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr, else app->did_chv1 = app->did_chv2 = 0; - if (!use_keypad) + if (!use_pinpad) { /* TRANSLATORS: Do not translate the "|*|" prefixes but keep it at the start of the string. We need this elsewhere @@ -2249,7 +2249,7 @@ do_change_pin (app_t app, ctrl_t ctrl, const char *chvnostr, /* Version 2 cards. */ assert (chvno == 1 || chvno == 3); - if (use_keypad) + if (use_pinpad) { rc = pincb (pincb_arg, chvno == 3 ? @@ -3324,7 +3324,7 @@ do_sign (app_t app, const char *keyidstr, int hashalgo, sync, thus we verify CHV2 here using the given PIN. Cards with version2 to not have the need for a separate CHV2 and internally use just one. Obviously we can't do that if the - keypad has been used. */ + pinpad has been used. */ if (!app->did_chv2 && pinvalue && !app->app_local->extcap.is_v2) { rc = iso7816_verify (app->slot, 0x82, pinvalue, strlen (pinvalue)); diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index 6d6c3db..2d1ef8d 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -3352,7 +3352,7 @@ ccid_transceive_secure (ccid_driver_t handle, else if (apdu_buflen >= 4 && apdu_buf[1] == 0x24 && (handle->has_pinpad & 2)) ; else - return CCID_DRIVER_ERR_NO_KEYPAD; + return CCID_DRIVER_ERR_NO_PINPAD; if (!pininfo->minlen) pininfo->minlen = 1; diff --git a/scd/ccid-driver.h b/scd/ccid-driver.h index 217bb72..1fd7ffa 100644 --- a/scd/ccid-driver.h +++ b/scd/ccid-driver.h @@ -72,7 +72,7 @@ #define CCID_DRIVER_ERR_GENERAL_ERROR 0x1000b #define CCID_DRIVER_ERR_NO_READER 0x1000c #define CCID_DRIVER_ERR_ABORTED 0x1000d -#define CCID_DRIVER_ERR_NO_KEYPAD 0x1000e +#define CCID_DRIVER_ERR_NO_PINPAD 0x1000e struct ccid_driver_s; typedef struct ccid_driver_s *ccid_driver_t; diff --git a/scd/command.c b/scd/command.c index 343830a..6267bb0 100644 --- a/scd/command.c +++ b/scd/command.c @@ -909,13 +909,13 @@ pin_cb (void *opaque, const char *info, char **retstr) if (!retstr) { - /* We prompt for keypad entry. To make sure that the popup has + /* We prompt for pinpad entry. To make sure that the popup has been show we use an inquire and not just a status message. We ignore any value returned. */ if (info) { - log_debug ("prompting for keypad entry '%s'\n", info); - rc = estream_asprintf (&command, "POPUPKEYPADPROMPT %s", info); + log_debug ("prompting for pinpad entry '%s'\n", info); + rc = estream_asprintf (&command, "POPUPPINPADPROMPT %s", info); if (rc < 0) return gpg_error (gpg_err_code_from_errno (errno)); rc = assuan_inquire (ctx, command, &value, &valuelen, MAXLEN_PIN); @@ -923,8 +923,8 @@ pin_cb (void *opaque, const char *info, char **retstr) } else { - log_debug ("dismiss keypad entry prompt\n"); - rc = assuan_inquire (ctx, "DISMISSKEYPADPROMPT", + log_debug ("dismiss pinpad entry prompt\n"); + rc = assuan_inquire (ctx, "DISMISSPINPADPROMPT", &value, &valuelen, MAXLEN_PIN); } if (!rc) diff --git a/scd/iso7816.c b/scd/iso7816.c index b2324b4..f1dbcff 100644 --- a/scd/iso7816.c +++ b/scd/iso7816.c @@ -94,7 +94,7 @@ map_sw (int sw) case SW_HOST_GENERAL_ERROR: ec = GPG_ERR_GENERAL; break; case SW_HOST_NO_READER: ec = GPG_ERR_ENODEV; break; case SW_HOST_ABORTED: ec = GPG_ERR_CANCELED; break; - case SW_HOST_NO_KEYPAD: ec = GPG_ERR_NOT_SUPPORTED; break; + case SW_HOST_NO_PINPAD: ec = GPG_ERR_NOT_SUPPORTED; break; default: if ((sw & 0x010000)) @@ -267,26 +267,26 @@ iso7816_apdu_direct (int slot, const void *apdudata, size_t apdudatalen, /* Check whether the reader supports the ISO command code COMMAND on - the keypad. Returns 0 on success. */ + the pinpad. Returns 0 on success. */ gpg_error_t -iso7816_check_keypad (int slot, int command, pininfo_t *pininfo) +iso7816_check_pinpad (int slot, int command, pininfo_t *pininfo) { int sw; - sw = apdu_check_keypad (slot, command, pininfo); + sw = apdu_check_pinpad (slot, command, pininfo); return iso7816_map_sw (sw); } /* Perform a VERIFY command on SLOT using the card holder verification - vector CHVNO. With PININFO non-NULL the keypad of the reader will + vector CHVNO. With PININFO non-NULL the pinpad of the reader will be used. Returns 0 on success. */ gpg_error_t iso7816_verify_kp (int slot, int chvno, pininfo_t *pininfo) { int sw; - sw = apdu_keypad_verify (slot, 0x00, CMD_VERIFY, 0, chvno, pininfo); + sw = apdu_pinpad_verify (slot, 0x00, CMD_VERIFY, 0, chvno, pininfo); return map_sw (sw); } @@ -302,7 +302,7 @@ iso7816_verify (int slot, int chvno, const char *chv, size_t chvlen) } /* Perform a CHANGE_REFERENCE_DATA command on SLOT for the card holder - verification vector CHVNO. With PININFO non-NULL the keypad of the + verification vector CHVNO. With PININFO non-NULL the pinpad of the reader will be used. If IS_EXCHANGE is 0, a "change reference data" is done, otherwise an "exchange reference data". */ gpg_error_t @@ -311,7 +311,7 @@ iso7816_change_reference_data_kp (int slot, int chvno, int is_exchange, { int sw; - sw = apdu_keypad_modify (slot, 0x00, CMD_CHANGE_REFERENCE_DATA, + sw = apdu_pinpad_modify (slot, 0x00, CMD_CHANGE_REFERENCE_DATA, is_exchange ? 1 : 0, chvno, pininfo); return map_sw (sw); } diff --git a/scd/iso7816.h b/scd/iso7816.h index bf195ea..6dd1052 100644 --- a/scd/iso7816.h +++ b/scd/iso7816.h @@ -24,13 +24,13 @@ #include "cardglue.h" #endif -/* Command codes used by iso7816_check_keypad. */ +/* Command codes used by iso7816_check_pinpad. */ #define ISO7816_VERIFY 0x20 #define ISO7816_CHANGE_REFERENCE_DATA 0x24 #define ISO7816_RESET_RETRY_COUNTER 0x2C -/* Information to be passed to keypad equipped readers. See +/* Information to be passed to pinpad equipped readers. See ccid-driver.c for details. */ struct pininfo_s { @@ -62,7 +62,7 @@ gpg_error_t iso7816_apdu_direct (int slot, const void *apdudata, size_t apdudatalen, int handle_more, unsigned char **result, size_t *resultlen); -gpg_error_t iso7816_check_keypad (int slot, int command, +gpg_error_t iso7816_check_pinpad (int slot, int command, pininfo_t *pininfo); gpg_error_t iso7816_verify (int slot, int chvno, const char *chv, size_t chvlen); diff --git a/scd/scdaemon.c b/scd/scdaemon.c index f8a86c8..4f9b369 100644 --- a/scd/scdaemon.c +++ b/scd/scdaemon.c @@ -92,11 +92,11 @@ enum cmd_and_opt_values opcscDriver, oDisableCCID, oDisableOpenSC, - oDisableKeypad, + oDisablePinpad, oAllowAdmin, oDenyAdmin, oDisableApplication, - oEnableKeypadVarlen, + oEnablePinpadVarlen, oDebugDisableTicker }; @@ -144,14 +144,14 @@ static ARGPARSE_OPTS opts[] = { /* end --disable-ccid */), ARGPARSE_s_u (oCardTimeout, "card-timeout", N_("|N|disconnect the card after N seconds of inactivity")), - ARGPARSE_s_n (oDisableKeypad, "disable-keypad", - N_("do not use a reader's keypad")), + ARGPARSE_s_n (oDisablePinpad, "disable-pinpad", + N_("do not use a reader's pinpad")), ARGPARSE_s_n (oAllowAdmin, "allow-admin", "@"), ARGPARSE_s_n (oDenyAdmin, "deny-admin", N_("deny the use of admin card commands")), ARGPARSE_s_s (oDisableApplication, "disable-application", "@"), - ARGPARSE_s_n (oEnableKeypadVarlen, "enable-keypad-varlen", - N_("use variable length input for keypad")), + ARGPARSE_s_n (oEnablePinpadVarlen, "enable-pinpad-varlen", + N_("use variable length input for pinpad")), ARGPARSE_end () }; @@ -579,7 +579,7 @@ main (int argc, char **argv ) case oDisableCCID: opt.disable_ccid = 1; break; case oDisableOpenSC: break; - case oDisableKeypad: opt.disable_keypad = 1; break; + case oDisablePinpad: opt.disable_pinpad = 1; break; case oAllowAdmin: /* Dummy because allow is now the default. */ break; @@ -591,7 +591,7 @@ main (int argc, char **argv ) add_to_strlist (&opt.disabled_applications, pargs.r.ret_str); break; - case oEnableKeypadVarlen: opt.enable_keypad_varlen = 1; break; + case oEnablePinpadVarlen: opt.enable_pinpad_varlen = 1; break; default: pargs.err = configfp? ARGPARSE_PRINT_WARNING:ARGPARSE_PRINT_ERROR; @@ -681,8 +681,9 @@ main (int argc, char **argv ) es_printf ("disable-ccid:%lu:\n", GC_OPT_FLAG_NONE ); #endif es_printf ("deny-admin:%lu:\n", GC_OPT_FLAG_NONE ); - es_printf ("disable-keypad:%lu:\n", GC_OPT_FLAG_NONE ); + es_printf ("disable-pinpad:%lu:\n", GC_OPT_FLAG_NONE ); es_printf ("card-timeout:%lu:%d:\n", GC_OPT_FLAG_DEFAULT, 0); + es_printf ("enable-pinpad-varlen:%lu:\n", GC_OPT_FLAG_NONE ); scd_exit (0); } diff --git a/scd/scdaemon.h b/scd/scdaemon.h index 8f048d5..ab63425 100644 --- a/scd/scdaemon.h +++ b/scd/scdaemon.h @@ -56,8 +56,8 @@ struct const char *pcsc_driver; /* Library to access the PC/SC system. */ const char *reader_port; /* NULL or reder port to use. */ int disable_ccid; /* Disable the use of the internal CCID driver. */ - int disable_keypad; /* Do not use a keypad. */ - int enable_keypad_varlen; /* Use variable length input for keypad. */ + int disable_pinpad; /* Do not use a pinpad. */ + int enable_pinpad_varlen; /* Use variable length input for pinpad. */ int allow_admin; /* Allow the use of admin commands for certain cards. */ strlist_t disabled_applications; /* Card applications we do not diff --git a/tools/gpgconf-comp.c b/tools/gpgconf-comp.c index d07ab59..9dbddee 100644 --- a/tools/gpgconf-comp.c +++ b/tools/gpgconf-comp.c @@ -617,8 +617,8 @@ static gc_option_t gc_options_scdaemon[] = { "disable-ccid", GC_OPT_FLAG_NONE|GC_OPT_FLAG_RUNTIME, GC_LEVEL_EXPERT, "gnupg", "do not use the internal CCID driver", GC_ARG_TYPE_NONE, GC_BACKEND_SCDAEMON }, - { "disable-keypad", GC_OPT_FLAG_NONE|GC_OPT_FLAG_RUNTIME, GC_LEVEL_BASIC, - "gnupg", "do not use a reader's keypad", + { "disable-pinpad", GC_OPT_FLAG_NONE|GC_OPT_FLAG_RUNTIME, GC_LEVEL_BASIC, + "gnupg", "do not use a reader's pinpad", GC_ARG_TYPE_NONE, GC_BACKEND_SCDAEMON }, { "card-timeout", GC_OPT_FLAG_NONE|GC_OPT_FLAG_RUNTIME, GC_LEVEL_BASIC, "gnupg", "|N|disconnect the card after N seconds of inactivity", -- From wk at gnupg.org Thu Feb 7 21:14:16 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Feb 2013 21:14:16 +0100 Subject: Pinentry-mode Message-ID: <8738x73mqv.fsf@vigenere.g10code.de> Hi, I just commited some changes to GnuPG and GPGME to support using GPG without a Pinentry: This new features allows to use gpg without a Pinentry. As a prerequisite the agent must be configured to allow the loopback pinentry mode (option --allow-loopback-pinentry). For example gpg2 --pinentry-mode=loopback FILE.gpg may be used to decrypt FILE.gpg while entering the passphrase on the tty. If batch is used, --passphrase et al. may be used, if --command-fd is used, the passphrase may be provided by another process. Note that there are no try-again prompts in case of a bad passphrase. GPGME now sports the function gpgme_set_pinentry_mode. See gpgme/src/gpgme-tool.c on how to use it. I hope that this feature will make it easier to use GnuPG 2.1 on non-desktop machines. I have only tested decryption and signing and thus other parts may not yet work. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri Feb 8 02:07:47 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 08 Feb 2013 10:07:47 +0900 Subject: [PATCH] Rename keypad to pinpad In-Reply-To: <1360200276.2675.7.camel@cfw2.gniibe.org> References: <1360200276.2675.7.camel@cfw2.gniibe.org> Message-ID: <1360285667.2840.1.camel@cfw2.gniibe.org> On 2013-02-07 at 10:24 +0900, NIIBE Yutaka wrote: > This is the change to rename "keypad" to "pinpad". It's not only > implementation (functions and constants), but also commands in > agent<-> scdaemon protocol and options. > > I'll apply this to both of master and 2.0. For both branches, I applied this patch and updated NEWS entries. I realized that this patch introduces changes of PO files, since the patch touches messages to user. I'm talking about 2.0 branch. I don't know the development/communication process for translations, how should I notify translators? Well, I will update po/ja.po later. -- From abel at guardianproject.info Fri Feb 8 11:06:46 2013 From: abel at guardianproject.info (Abel Luck) Date: Fri, 08 Feb 2013 10:06:46 +0000 Subject: Pinentry-mode In-Reply-To: <8738x73mqv.fsf@vigenere.g10code.de> References: <8738x73mqv.fsf@vigenere.g10code.de> Message-ID: <5114CE36.5010906@guardianproject.info> Werner Koch: > Hi, > > I just commited some changes to GnuPG and GPGME to support using GPG > without a Pinentry: > > This new features allows to use gpg without a Pinentry. As a > prerequisite the agent must be configured to allow the loopback > pinentry mode (option --allow-loopback-pinentry). For example > > gpg2 --pinentry-mode=loopback FILE.gpg > > may be used to decrypt FILE.gpg while entering the passphrase on the > tty. If batch is used, --passphrase et al. may be used, if > --command-fd is used, the passphrase may be provided by another > process. Note that there are no try-again prompts in case of a bad > passphrase. > > GPGME now sports the function gpgme_set_pinentry_mode. See > gpgme/src/gpgme-tool.c on how to use it. > > I hope that this feature will make it easier to use GnuPG 2.1 on > non-desktop machines. I have only tested decryption and signing and > thus other parts may not yet work. > > > Salam-Shalom, > > Werner > Hi Werner, This looks like great stuff :) I don't suppose you have some example/tests demonstrating the command-[fd,file] functionality? If not, then am I right to conclude that all the possible messages a client program would receive from gpg2 would be those in doc/DETAILS in the "Remote control" section? ~abel From abel at guardianproject.info Fri Feb 8 14:22:54 2013 From: abel at guardianproject.info (Abel Luck) Date: Fri, 08 Feb 2013 13:22:54 +0000 Subject: gpg: error getting the KEK: Unsupported certificate Message-ID: <5114FC2E.7050105@guardianproject.info> I'm getting this error on gpg2 master whenever I try to import a secret key exported from 1.4.13 $ gpg-agent -v --daemon gpg-agent[12554]: listening on socket '/home/user/.gnupg/S.gpg-agent' GPG_AGENT_INFO=/home/user/.gnupg/S.gpg-agent:12555:1; export GPG_AGENT_INFO; gpg-agent[12555]: gpg-agent (GnuPG) 2.1.0-beta108 started $ gpg2 --import secret-keys.gpg gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: key 51EF9A28: "Test Key (pin: 1234)" not changed gpg: error getting the KEK: Unsupported certificate gpg: Total number processed: 1 gpg: unchanged: 1 gpg: secret keys read: 1 I've tried going back to 36ba7845995dd3caf8faeec3e09b3ffb879fc29b but I'm getting the same results. I figure if I go back any farther I'll start running into compatibility issues with the other gnupg repos (e.g., libgpg-error) I encountered this while playing with the new pinentry modes for the Android port. ~abel From gniibe at fsij.org Fri Feb 8 16:33:52 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 09 Feb 2013 00:33:52 +0900 Subject: gpg: error getting the KEK: Unsupported certificate In-Reply-To: <5114FC2E.7050105@guardianproject.info> References: <5114FC2E.7050105@guardianproject.info> Message-ID: <1360337632.2782.0.camel@latx1.gniibe.org> On 2013-02-08 at 13:22 +0000, Abel Luck wrote: > $ gpg2 --import secret-keys.gpg [...] > gpg: error getting the KEK: Unsupported certificate Could you please check your environment variable GPG_AGENT_INFO for gpg2? Does the process number of GPG_AGENT_INFO correspond to gnome-keyring? Are you running gnome-keyring with gpg-agent feature enabled? "Unsupported certificate" is common error behavior when you are using gnome-keyring as gpg-agent. It replies "103 unknow command", which causes "Unsupported certificate" error of GnuPG. See the line 156 of gnome-keyring source code: http://git.gnome.org/browse/gnome-keyring/tree/daemon/gpg-agent/gkd-gpg-agent.c Or does it work? $ unset GPG_AGENT_INFO $ eval `gpg-agent -v --daemon` $ gpg2 --import secret-keys.gpg -- From folkert at vanheusden.com Fri Feb 8 23:28:39 2013 From: folkert at vanheusden.com (folkert) Date: Fri, 8 Feb 2013 23:28:39 +0100 Subject: What is wrong with 0xC4739D2D? Message-ID: <20130208222839.GA8791@belle.intranet.vanheusden.com> Hi, There's this key, 0xC4739D2D, and it is not usable for encryption: $ gpg --encrypt -r C4739D2D foobar.txt gpg: c4739d2d: skipped: unusable public key gpg: foobar.txt encryption failed: unusable public key It can be used for signing I found. Folkert van Heusden -- www.TrustedTimestamping.com is a service that enables you to show that at a certain point in time, you had access to a hash-value reflecting the contents of a file (this file can be a word document, a jpeg image, everything). ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From dkg at fifthhorseman.net Fri Feb 8 23:35:06 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 08 Feb 2013 17:35:06 -0500 Subject: What is wrong with 0xC4739D2D? In-Reply-To: <20130208222839.GA8791@belle.intranet.vanheusden.com> References: <20130208222839.GA8791@belle.intranet.vanheusden.com> Message-ID: <51157D9A.3020609@fifthhorseman.net> On 02/08/2013 05:28 PM, folkert wrote: > There's this key, 0xC4739D2D, and it is not usable for encryption: > $ gpg --encrypt -r C4739D2D foobar.txt > gpg: c4739d2d: skipped: unusable public key > gpg: foobar.txt encryption failed: unusable public key > > It can be used for signing I found. There is nothing wrong with this key. It is a single primary key with no subkeys attached. the primary key is marked with usage flags to indicate that it should be used for data signing and identity certification. There are no encryption capabilities, presumably because the keyholder wants to indicate that no one should encrypt anything to it. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From folkert at vanheusden.com Sat Feb 9 01:48:58 2013 From: folkert at vanheusden.com (folkert) Date: Sat, 9 Feb 2013 01:48:58 +0100 Subject: What is wrong with 0xC4739D2D? In-Reply-To: <51157D9A.3020609@fifthhorseman.net> References: <20130208222839.GA8791@belle.intranet.vanheusden.com> <51157D9A.3020609@fifthhorseman.net> Message-ID: <20130209004856.GB8791@belle.intranet.vanheusden.com> > > There's this key, 0xC4739D2D, and it is not usable for encryption: > > $ gpg --encrypt -r C4739D2D foobar.txt > > gpg: c4739d2d: skipped: unusable public key > > gpg: foobar.txt encryption failed: unusable public key > > > > It can be used for signing I found. > > There is nothing wrong with this key. It is a single primary key with > no subkeys attached. the primary key is marked with usage flags to > indicate that it should be used for data signing and identity certification. > There are no encryption capabilities, presumably because the keyholder > wants to indicate that no one should encrypt anything to it. So the holder should add a sub-key? Or can the holder change the usage flags? Folkert van Heusden -- MultiTail ?r ett flexibel redskap f?r att f?lja en eller flera logfiler, utf?ra kommandon, filtrera, f?rgl?gga, sammanfoga, o.s.v... ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From mailinglisten at hauke-laging.de Sat Feb 9 01:57:46 2013 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sat, 09 Feb 2013 01:57:46 +0100 Subject: What is wrong with 0xC4739D2D? In-Reply-To: <20130209004856.GB8791@belle.intranet.vanheusden.com> References: <20130208222839.GA8791@belle.intranet.vanheusden.com> <51157D9A.3020609@fifthhorseman.net> <20130209004856.GB8791@belle.intranet.vanheusden.com> Message-ID: <3133953.tiDWbXkYvg@inno> Am Sa 09.02.2013, 01:48:58 schrieb folkert: > So the holder should add a sub-key? Yes. > Or can the holder change the usage flags? As far as I know that is not possible with the official GnuPG. Hauke -- ? PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) http://www.openpgp-schulungen.de/ -------------- 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 Sat Feb 9 12:57:57 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 09 Feb 2013 12:57:57 +0100 Subject: Pinentry-mode In-Reply-To: <5114CE36.5010906@guardianproject.info> (Abel Luck's message of "Fri, 08 Feb 2013 10:06:46 +0000") References: <8738x73mqv.fsf@vigenere.g10code.de> <5114CE36.5010906@guardianproject.info> Message-ID: <87y5exzol6.fsf@vigenere.g10code.de> On Fri, 8 Feb 2013 11:06, abel at guardianproject.info said: > I don't suppose you have some example/tests demonstrating the > command-[fd,file] functionality? --command-fd, there is --no command-file. A simple test run looks like this (gpg-agent has already been started): $ g10/gpg2 --pinentry-mode loopback --verbose --status-fd 2 \ --command-fd 0 g10/x.asc gpg: WARNING: unsafe permissions on homedir '[...]' gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: armor header: Version: GnuPG v2.1.0-beta129 (GNU/Linux) gpg: public key is AD7AB69C [GNUPG:] ENC_TO B705A348AD7AB69C 18 0 gpg: using subkey AD7AB69C instead of primary key EE5CA433 [GNUPG:] USERID_HINT B705A348AD7AB69C Egon Charlie Crypto (ECC Test Key) [GNUPG:] NEED_PASSPHRASE B705A348AD7AB69C 9B57DB04EE5CA433 18 0 [GNUPG:] GET_HIDDEN passphrase.enter abc ; I entered the above line at the tty. [GNUPG:] GOT_IT gpg: using subkey AD7AB69C instead of primary key EE5CA433 gpg: encrypted with 256-bit ECDH key, ID AD7AB69C, created 2011-07-01 "Egon Charlie Crypto (ECC Test Key)" [GNUPG:] BEGIN_DECRYPTION gpg: AES128 encrypted data [GNUPG:] DECRYPTION_INFO 2 7 gpg: original file name='' [GNUPG:] PLAINTEXT 62 1360140890 [GNUPG:] PLAINTEXT_LENGTH 47 File 'g10/x' exists. [GNUPG:] GET_BOOL openfile.overwrite.okay y ; I entered the above line at the tty. [GNUPG:] GOT_IT [GNUPG:] DECRYPTION_OKAY [GNUPG:] GOODMDC [GNUPG:] END_DECRYPTION Or if you want to use gpgme-tool: $ (printf "pinentry_mode loopback\nINPUT FILE=g10/x.asc\n\ OUTPUT FILE=g10/x.txt\ndecrypt\n" && cat -) | \ GPGME_DEBUG=9:out ~/b/gpgme/src/gpgme-tool --gpg-binary ~/b/gnupg/g10/gpg2 OK GPGME-Tool 1.3.3-gitcd6de92 ready OK OK OK S PROGRESS -&14 0x3f 0 0 S USERID_HINT B705A348AD7AB69C Egon Charlie Crypto (ECC Test Key) S NEED_PASSPHRASE B705A348AD7AB69C 9B57DB04EE5CA433 18 0 INQUIRE PASSPHRASE D abc ; I entered the above line at the tty. ; The correct thing would be "D abc%0A" but the gpgme code takes care to ; append a missing LF. END S PROGRESS -&14 0x3f 404 0 OK bye ; I entered the above line at the tty. OK closing connection Using --edit-key with --command-fd is more complex. GPA uses a FSM to handle this (gpa/src/gpgmeedit.c). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Feb 9 13:06:50 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 09 Feb 2013 13:06:50 +0100 Subject: gpg: error getting the KEK: Unsupported certificate In-Reply-To: <1360337632.2782.0.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Sat, 09 Feb 2013 00:33:52 +0900") References: <5114FC2E.7050105@guardianproject.info> <1360337632.2782.0.camel@latx1.gniibe.org> Message-ID: <87txplzo6d.fsf@vigenere.g10code.de> On Fri, 8 Feb 2013 16:33, gniibe at fsij.org said: > "Unsupported certificate" is common error behavior when you are > using gnome-keyring as gpg-agent. It replies "103 unknow command", FWIW, I had a meeting with Stef Walter at FOSDEM and we agreed on a plan how to solve the gnome-keyring problem. > $ unset GPG_AGENT_INFO > $ eval `gpg-agent -v --daemon` > $ gpg2 --import secret-keys.gpg IMHO the best way to test gpg is this $ GNUPGHOME=/foo/testdir gpg-agent --verbose --daemon bash Now within this new shell (bash or whatever you used) you can run your tests nicely without wondering about GPG_AGENT_INFO etc. If you want to terminate the test just enter exit and wait a few seconds until gpg-agent has terminated itself. Running watchgnupg in another xterm is also useful to see what is going on. If you want to test smartcards you should have put "disable-scdaemon" into ~/.gnupg/gpg-agent.conf so that the production gpg-agent does not block the use of the reader device. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Feb 9 13:14:36 2013 From: wk at gnupg.org (Werner Koch) Date: Sat, 09 Feb 2013 13:14:36 +0100 Subject: [PATCH] Rename keypad to pinpad In-Reply-To: <1360285667.2840.1.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Fri, 08 Feb 2013 10:07:47 +0900") References: <1360200276.2675.7.camel@cfw2.gniibe.org> <1360285667.2840.1.camel@cfw2.gniibe.org> Message-ID: <87obftzntf.fsf@vigenere.g10code.de> On Fri, 8 Feb 2013 02:07, gniibe at fsij.org said: > On 2013-02-07 at 10:24 +0900, NIIBE Yutaka wrote: >> This is the change to rename "keypad" to "pinpad". It's not only >> implementation (functions and constants), but also commands in >> agent<-> scdaemon protocol and options. Is that only agent<->scdaemon comminucation? That would be okay. For 2.0 any change to commands of gpg-agent (as used by gpg, gpgsm, gpa and kleopatra), need a backward compatibility option: An alias for commands and some way to handle Status and Inquiry lines. The PO file chnage are not that important. If the chnage is only in the English version, we should be able to fix it ourself. IIRC, there is a tool for that in po4a. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From abel at guardianproject.info Sun Feb 10 18:53:56 2013 From: abel at guardianproject.info (Abel Luck) Date: Sun, 10 Feb 2013 17:53:56 +0000 Subject: Properly detecting git revision In-Reply-To: <87fw4abuvj.fsf@vigenere.g10code.de> References: <50A4EC4E.6060604@guardianproject.info> <87fw4abuvj.fsf@vigenere.g10code.de> Message-ID: <5117DEB4.9050207@guardianproject.info> Werner Koch: > 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 ;-). > Looks like this one still needs to be applied to the pinentry repo. Thanks for doing the others :) ~abel From g.esp at free.fr Mon Feb 11 22:43:45 2013 From: g.esp at free.fr (g.esp at free.fr) Date: Mon, 11 Feb 2013 22:43:45 +0100 (CET) Subject: Minor mailing-lists.en.html page updates In-Reply-To: <511448767.302559471.1360618592686.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <1315682627.302574064.1360619025681.JavaMail.root@zimbra33-e6.priv.proxad.net> In http://www.gnupg.org/documentation/mailing-lists.en.html, change the old URL http://marc.theaimsgroup.com/ by http://marc.info/ Or maybe remove the entire sentence as the archives are available from http://lists.gnupg.org/pipermail/ Gilles From gniibe at fsij.org Tue Feb 12 02:31:04 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 12 Feb 2013 10:31:04 +0900 Subject: [PATCH] Rename keypad to pinpad In-Reply-To: <87obftzntf.fsf@vigenere.g10code.de> References: <1360200276.2675.7.camel@cfw2.gniibe.org> <1360285667.2840.1.camel@cfw2.gniibe.org> <87obftzntf.fsf@vigenere.g10code.de> Message-ID: <1360632664.7158.2.camel@cfw2.gniibe.org> On 2013-02-09 at 13:14 +0100, Werner Koch wrote: > Is that only agent<->scdaemon comminucation? That would be okay. It's only agent<->scdaemon comminucation, and only for pinpad input. Specifically, POPUPPINPADPROMPT and DISMISSPINPADPROMPT. I don't think that it's worth for newer gpg-agent to have backward compatibility, that is, having support of POPUPKEYPADPROMPT and DISMISSKEYPADPROMPT. > For 2.0 any change to commands of gpg-agent (as used by gpg, gpgsm, gpa > and kleopatra), need a backward compatibility option: An alias for > commands and some way to handle Status and Inquiry lines. I see. > The PO file chnage are not that important. If the chnage is only in the > English version, we should be able to fix it ourself. IIRC, there is a > tool for that in po4a. It seems that "keypad" was translated in some languages. -- From gniibe at fsij.org Tue Feb 12 06:29:07 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 12 Feb 2013 14:29:07 +0900 Subject: agent: adding KEYTOCARD command (master branch) In-Reply-To: <1360040133.14506.2.camel@cfw2.gniibe.org> References: <1359938063.2696.5.camel@cfw2.gniibe.org> <87sj5c9ozy.fsf@vigenere.g10code.de> <1360040133.14506.2.camel@cfw2.gniibe.org> Message-ID: <1360646947.7158.3.camel@cfw2.gniibe.org> I updated the changes of gpg-agent so that it uses secure memory for private key, and applied and pushed to master branch. This change is 2.1 only (not for 2.0). On 2013-02-05 at 13:55 +0900, NIIBE Yutaka wrote: > On 2013-02-04 at 14:40 +0100, Werner Koch wrote: > > On Mon, 4 Feb 2013 01:34, gniibe at fsij.org said: > > > > > I think that the reason why it is not yet supported is because of the > > > shift of secret key handling to gpg-agent. > > > > Right, after that change some card specific commands are not yet > > working. > > Here's the patch. > > It works for me, but the behavior of gpg command has been changed. In > 2.0, we invoke --edit-key to invoke keytocard subcommand. After we > store private keys to card, it goes like this: > > gpg> quit > Save changes? (y/N) n > Quit without saving? (y/N) y > $ > > But, master branch don't ask "Save changes?", and it has been changed > already in gpg-agent's storage. > > > gpg: Implement card_store_subkey again. > > * g10/call-agent.h (agent_keytocard): New. > * g10/call-agent.c (agent_keytocard): New. > * g10/card-util.c (replace_existing_key_p): Returns 1 when replace. > (card_generate_subkey): Check return value of replace_existing_key_p. > (card_store_subkey): Implement again using agent_keytocard. > > agent: Add KEYTOCARD command. > > * agent/agent.h (divert_writekey, agent_card_writekey): New. > * agent/call-scd.c (inq_writekey_parms, agent_card_writekey): New. > * agent/command.c (cmd_keytocard, hlp_keytocard): New. > (register_commands): Add cmd_keytocard. > * agent/divert-scd.c (divert_writekey): New. -- From gniibe at fsij.org Tue Feb 12 06:37:48 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 12 Feb 2013 14:37:48 +0900 Subject: Popup_message_stop In-Reply-To: <1359001349.5224.4.camel@cfw2.gniibe.org> References: <1358219182.2667.8.camel@cfw2.gniibe.org> <1359001349.5224.4.camel@cfw2.gniibe.org> Message-ID: <1360647468.7158.5.camel@cfw2.gniibe.org> Werner, how do you think about the change of nPth for signal mask? On 2013-01-24 at 13:22 +0900, NIIBE Yutaka wrote: > On 2013-01-15 at 12:06 +0900, NIIBE Yutaka wrote: > > I am bitten by my own change of: > > > > commit f6251c0d0af92331388f5e9bcd1750cbadcaca8f > > Author: NIIBE Yutaka > > Date: Fri Dec 16 09:07:56 2011 +0900 > > > > Don't kill pinentry by SIGKILL but let it quit by SIGINT. > > > > * agent/call-pinentry.c (agent_popup_message_stop): To pinentry, send > > SIGINT (was: SIGKILL). > > > > The window of pinentry doesn't pop down, now. > > > > This change was done because of pinentry-curses. With > > pinentry-curses, when it is killed by SIGINT, terminal gets confused. s/SIGINT/SIGKILL/ I mean, pinentry-curses shoule be killed by SIGINT so that terminal setting will be reset. When it is killed by SIGKILL, terminal gets confused. > > I figured out that the problem here is signal mask. To handle > > signals, GPG-Agent has signal mask for SIGHUP, SIGUSR1, SIGUSR2, > > SIGINT and SIGTERM. Then, pinentry will be fork/exec-ed with this > > signal mask, and SIGINT will not be delivered because of this mask. > > > > We need to call pthread_atfork to unmask signals for child processes > > of GPG-Agent. > > > > I'm not sure where to implement unmasking signals. > > > > It should be GnuPG which calls pthread_atfork for 2.0 branch. But > > it's common things among applications, it would be npth_sigev_fini > > which calls pthread_atfork for master branch. > > Something like this. It works for me. > > diff --git a/src/npth-sigev.c b/src/npth-sigev.c > index f1271d1..aab977e 100644 > --- a/src/npth-sigev.c > +++ b/src/npth-sigev.c > @@ -126,6 +126,13 @@ npth_sigev_add (int signum) > } > > > +static void > +restore_sigmask_for_child_process (void) > +{ > + pthread_sigmask (SIG_SETMASK, &sigev_unblock, NULL); > +} > + > + > /* Finish the list of watched signals. This starts to block them, > too. */ > void > @@ -133,6 +140,7 @@ npth_sigev_fini (void) > { > /* Block the interesting signals. */ > pthread_sigmask (SIG_SETMASK, &sigev_block, NULL); > + pthread_atfork (NULL, NULL, restore_sigmask_for_child_process); > } > -- From wk at gnupg.org Tue Feb 12 15:59:47 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Feb 2013 15:59:47 +0100 Subject: PyGPGME support for GPGME 1.4 Message-ID: <8738x1y3vg.fsf@vigenere.g10code.de> Hi James, The next version of gpgme will have support for the new pinentry-mode feature. I hacked some support for pygpgme to support this. I don't know the details of the Python C module build system so what I did is to provide the API always but to throw a runtime error if pygpgme has been build with a GPGME version < 1.4.0. Will you be so kind to consider the attached patches? I have no clue about bzr so I used a little script by Bart Trojanowski to create the patches [1]. Shalom-Salam, Werner [1] http://www.jukie.net/~bart/scripts/bzr-export-patch/bzr-export-patch -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 00091-Add-support-for-the-pinentry-mode-which-is-available-since-gpgme-1-3-3--.patch Type: text/x-diff Size: 3703 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 00092-Allow-building-with-gpgme-versions---1-4--.patch Type: text/x-diff Size: 2131 bytes Desc: not available URL: From wk at gnupg.org Tue Feb 12 20:49:23 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Feb 2013 20:49:23 +0100 Subject: [PATCH] Rename keypad to pinpad In-Reply-To: <1360632664.7158.2.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Tue, 12 Feb 2013 10:31:04 +0900") References: <1360200276.2675.7.camel@cfw2.gniibe.org> <1360285667.2840.1.camel@cfw2.gniibe.org> <87obftzntf.fsf@vigenere.g10code.de> <1360632664.7158.2.camel@cfw2.gniibe.org> Message-ID: <87r4kluxbw.fsf@vigenere.g10code.de> On Tue, 12 Feb 2013 02:31, gniibe at fsij.org said: > It's only agent<->scdaemon comminucation, and only for pinpad input. Good. > I don't think that it's worth for newer gpg-agent to have backward > compatibility, that is, having support of POPUPKEYPADPROMPT and > DISMISSKEYPADPROMPT. I agree. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kylebutt at gmail.com Wed Feb 13 01:34:17 2013 From: kylebutt at gmail.com (Kyle Butt) Date: Tue, 12 Feb 2013 16:34:17 -0800 Subject: Work remaining for a 2.1 release? Message-ID: Given that the last beta was over a year ago, what work remains on the 2.1 release, and how can I help? I'm a SWE with some background in security and crypto. Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Feb 13 18:31:53 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Feb 2013 18:31:53 +0100 Subject: Work remaining for a 2.1 release? In-Reply-To: (Kyle Butt's message of "Tue, 12 Feb 2013 16:34:17 -0800") References: Message-ID: <87fw10t912.fsf@vigenere.g10code.de> On Wed, 13 Feb 2013 01:34, kylebutt at gmail.com said: > Given that the last beta was over a year ago, what work remains on the 2.1 > release, and how can I help? Don't expect too much from a beta tag, there is no definite list of features to be included in 2.1 but this development cycle needs to come to an end soon. I am currently working on improving the key storage and on features to help using GnuPG-2 on unattended boxes. What we definitely need is a way to make the migration from secring.gpg to the gpg-agend based private key storage easier. There are two options I can see: - A Pinentry based message to tell the user how to migrate - A fully automated way to migrate the keys. The latter is more complicated due to the fact that the user needs to enter the passphrase for each private key. It also needs to take care of the not so common cases of offline stored keys etc. In theory this should all work, but it needs to see more tests. The keys are too precious to risk any loss. Another construction area is the smartcard stuff. gniibe is currently working on it so I assume we are on track there. Help would of course be welcome. However, any code contribution also means initially a bit more work for me. Given that I can only barely finance my living I unfortunately need to limit the time I can hack on GnuPG. And I also need to sort out the issues with the requirement for copyright assignments. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kylebutt at gmail.com Thu Feb 14 02:48:01 2013 From: kylebutt at gmail.com (Kyle Butt) Date: Wed, 13 Feb 2013 17:48:01 -0800 Subject: Work remaining for a 2.1 release? In-Reply-To: <87fw10t912.fsf@vigenere.g10code.de> References: <87fw10t912.fsf@vigenere.g10code.de> Message-ID: On Wed, Feb 13, 2013 at 9:31 AM, Werner Koch wrote: > On Wed, 13 Feb 2013 01:34, kylebutt at gmail.com said: >> Given that the last beta was over a year ago, what work remains on the 2.1 >> release, and how can I help? > > Don't expect too much from a beta tag, there is no definite list of > features to be included in 2.1 but this development cycle needs to come > to an end soon. > > I am currently working on improving the key storage and on features to > help using GnuPG-2 on unattended boxes. What we definitely need is a > way to make the migration from secring.gpg to the gpg-agend based > private key storage easier. There are two options I can see: > > - A Pinentry based message to tell the user how to migrate > - A fully automated way to migrate the keys. > > The latter is more complicated due to the fact that the user needs to > enter the passphrase for each private key. It also needs to take care > of the not so common cases of offline stored keys etc. In theory this > should all work, but it needs to see more tests. The keys are too > precious to risk any loss. > Can you give me a brief explanation of why the passphrase is needed for import? > Another construction area is the smartcard stuff. gniibe is currently > working on it so I assume we are on track there. > > Help would of course be welcome. However, any code contribution also > means initially a bit more work for me. Given that I can only barely > finance my living I unfortunately need to limit the time I can hack on > GnuPG. And I also need to sort out the issues with the requirement for > copyright assignments. > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Feb 14 05:20:49 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 14 Feb 2013 13:20:49 +0900 Subject: Work remaining for a 2.1 release? In-Reply-To: References: <87fw10t912.fsf@vigenere.g10code.de> Message-ID: <1360815649.2681.0.camel@cfw2.gniibe.org> On 2013-02-13 at 17:48 -0800, Kyle Butt wrote: > Can you give me a brief explanation of why the passphrase is needed > for import? I think that it's because of the difference between the encryption mode of secring.gpg and the one under private-keys-v1.d/. (I don't know the technical reason why it's different.) According to RFC4880, secret-key packet is encrypted by CFB mode. According to gnupg/agent/keyformat.txt, the latter only supports the protection mode of openpgp-s2k3-sha1-aes-cbc. If the protection mode of secret-key packet were supported by new secret key storage, it would be possible to move such secret keys as opaque data from secring.gpg to private-keys-v1.d/. Currently, we need to decrypt the secret-key packet and to encrypt again into the file under private-keys-v1.d/. To decrypt/encrypt, we use passphrase. -- From kylebutt at gmail.com Thu Feb 14 06:52:37 2013 From: kylebutt at gmail.com (Kyle Butt) Date: Wed, 13 Feb 2013 21:52:37 -0800 Subject: Work remaining for a 2.1 release? In-Reply-To: <1360815649.2681.0.camel@cfw2.gniibe.org> References: <87fw10t912.fsf@vigenere.g10code.de> <1360815649.2681.0.camel@cfw2.gniibe.org> Message-ID: On Wed, Feb 13, 2013 at 8:20 PM, NIIBE Yutaka wrote: > On 2013-02-13 at 17:48 -0800, Kyle Butt wrote: >> Can you give me a brief explanation of why the passphrase is needed >> for import? > > I think that it's because of the difference between the encryption > mode of secring.gpg and the one under private-keys-v1.d/. > > (I don't know the technical reason why it's different.) > > According to RFC4880, secret-key packet is encrypted by CFB mode. > > According to gnupg/agent/keyformat.txt, the latter only supports > the protection mode of openpgp-s2k3-sha1-aes-cbc. > > If the protection mode of secret-key packet were supported by new > secret key storage, it would be possible to move such secret keys as > opaque data from secring.gpg to private-keys-v1.d/. > Is there an objection to porting the common algorithms for the agent's storage? > Currently, we need to decrypt the secret-key packet and to encrypt > again into the file under private-keys-v1.d/. To decrypt/encrypt, > we use passphrase. > -- > > From wk at gnupg.org Thu Feb 14 09:34:19 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Feb 2013 09:34:19 +0100 Subject: Work remaining for a 2.1 release? In-Reply-To: (Kyle Butt's message of "Wed, 13 Feb 2013 21:52:37 -0800") References: <87fw10t912.fsf@vigenere.g10code.de> <1360815649.2681.0.camel@cfw2.gniibe.org> Message-ID: <87wqubs390.fsf@vigenere.g10code.de> On Thu, 14 Feb 2013 06:52, kylebutt at gmail.com said: > Is there an objection to porting the common algorithms for the agent's storage? Yes. The protection of private keys in OpenPGP is pretty complex, carries a lot of historic baggage, and uses too much bit-fiddling. Further, gpg-agent is designed to be protocol neutral thus does not need to know about OpenPGP details. Just for the sake of a one-time requirement for the passphrase it does not make sense to make the current gpg-agent private key protection more complex. I also bet that more than 99% of all users have only one key and thus one passphrase (they should know very well). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From cloos at jhcloos.com Thu Feb 14 16:40:18 2013 From: cloos at jhcloos.com (James Cloos) Date: Thu, 14 Feb 2013 10:40:18 -0500 Subject: Work remaining for a 2.1 release? In-Reply-To: <87wqubs390.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 14 Feb 2013 09:34:19 +0100") References: <87fw10t912.fsf@vigenere.g10code.de> <1360815649.2681.0.camel@cfw2.gniibe.org> <87wqubs390.fsf@vigenere.g10code.de> Message-ID: >>>>> "WK" == Werner Koch writes: WK> I also bet that more than 99% of all users have only one key WK> and thus one passphrase (they should know very well). On that front, please do be sure that when iterating through the keys in secring a secret key with a forgotten passphrase does not DoS the con- version for subsequent keys. Ie, there must be an option to skip a key until later. Also, an easy way to backup such a keypair -- both the encrypted secret key and the matching public key -- would help avoid repeated skip-this-for-now dances. Some keys may have been generated for short-term use. Some may have one of those damned 'clever' passphrases which turn out the be as memorable as what one had for dinner on the nth of last month. ;( But still, eventually, insiration might surprise one with the missing phrase. And for convenience, it could try recently entered phrases before prompting, much like (openssh's) ssh-agent(1) does when adding a collection of keys. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From stlman at poczta.fm Thu Feb 14 20:06:39 2013 From: stlman at poczta.fm (=?utf-8?Q?=C5=81ukasz?= Stelmach) Date: Thu, 14 Feb 2013 20:06:39 +0100 Subject: listing unusable keys Message-ID: <87mwv6hg00.fsf%stlman@poczta.fm> Greetings All. I've got a question about --list-keys action. When it is given execution comes via list_one, get_pubkey_bynames, key_byname. The last gets 1 as include_unusable parameter. This makes gpg show keys with revoked uids matching the one given as an argument to --list-keys, however, the matching uid isn't displayed unless show-unusable-uids option is set. This brings a question to my mind: is this behavior correct? It works a bit better with --with-colons where show-unusable-uids does not affect output and all uids are displayed with revoked ones marked appropriately. Nevertheless it is inconvenient from time to time (emacs+epg+gnus) if gpg is expected to return list of keys (e.g.) usable for encryption to a particular uid. Is there a reason to pass 1 to key_byname in get_pubkey_bynames rather then the value of show-unusable-uids? -- Kind regards, ?ukasz Stelmach -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 619 bytes Desc: not available URL: From wk at gnupg.org Thu Feb 14 20:52:25 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Feb 2013 20:52:25 +0100 Subject: Work remaining for a 2.1 release? In-Reply-To: (James Cloos's message of "Thu, 14 Feb 2013 10:40:18 -0500") References: <87fw10t912.fsf@vigenere.g10code.de> <1360815649.2681.0.camel@cfw2.gniibe.org> <87wqubs390.fsf@vigenere.g10code.de> Message-ID: <87pq02r7uu.fsf@vigenere.g10code.de> On Thu, 14 Feb 2013 16:40, cloos at jhcloos.com said: > On that front, please do be sure that when iterating through the keys in > secring a secret key with a forgotten passphrase does not DoS the con- > version for subsequent keys. Ie, there must be an option to skip a key > until later. Also, an easy way to backup such a keypair -- both the Yes, these are the little things which make a software usable. It should all be there but the user interface needs is just for hackers ;-). > encrypted secret key and the matching public key -- would help avoid > repeated skip-this-for-now dances. Well, a backup option. That makes really sense. It could be as simple as listing the files which need a backup. > And for convenience, it could try recently entered phrases before > prompting, much like (openssh's) ssh-agent(1) does when adding a > collection of keys. IIRC, we already talked about this. It makes a lot of sense. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri Feb 15 08:03:45 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 15 Feb 2013 16:03:45 +0900 Subject: ECC and smartcards In-Reply-To: <1326243062.2015.1.camel@latx1.gniibe.org> References: <1326243062.2015.1.camel@latx1.gniibe.org> Message-ID: <1360911825.12360.1.camel@cfw2.gniibe.org> It was more than a year ago, there is a thread on ECC support of OpenPGP card... On 2012-01-11 at 09:51 +0900, NIIBE Yutaka wrote: > On 2012-01-03 at 11:28 +0000, Benjamin Donnachie wrote: > > Are there any plans to include ECC support within the OpenPGP > > Smartcard specification? > > > > > > If not, would a proposal be welcome? > > I'd like to see your proposal. If it will include specification for > NIST Curve P256, it will be soon implemented in Gnuk, as it has a > branch which has ECDSA/ECDH computation for the curve. I think that it's good if GnuPG 2.1 comes with the ECDSA/ECDH support for smartcard. Besides, I'm considering adding ECC feature to development branch of Gnuk, too. (I only have NIST curve P-256 computation routines, now.) ECDSA is mostly ready. For ECDH, I'll need to implement AESwrap routine. Starting from easy part for the specification, I think that adding a spec for "Algorithm Attributes" is not that difficult. It would be: For ECDSA: ECDSA ID (one byte) OID of curve (variable length) For ECDH: ECDH ID (one byte) Hash ID (one byte) Encryption ID (one byte) OID of curve (variable length) I'm not sure about user interface, though. That is, how we should show this attribute for output of --card-status of GnuPG. Currently for RSA, it's like: Key attributes ...: 2048R 2048R 2048R It will be something like: Key attributes ...: 256E 256e 256E -- From wk at gnupg.org Fri Feb 15 13:53:58 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 Feb 2013 13:53:58 +0100 Subject: ECC and smartcards In-Reply-To: <1360911825.12360.1.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Fri, 15 Feb 2013 16:03:45 +0900") References: <1326243062.2015.1.camel@latx1.gniibe.org> <1360911825.12360.1.camel@cfw2.gniibe.org> Message-ID: <87ehghpwk9.fsf@vigenere.g10code.de> On Fri, 15 Feb 2013 08:03, gniibe at fsij.org said: > I think that it's good if GnuPG 2.1 comes with the ECDSA/ECDH support > for smartcard. Right, Achim asked me a few years ago, what we need in the specs to support ECC. > Besides, I'm considering adding ECC feature to development branch of > Gnuk, too. (I only have NIST curve P-256 computation routines, now.) > ECDSA is mostly ready. For ECDH, I'll need to implement AESwrap That is perfectly okay. However ECDH is more complicated because it is quite OpenPGP specific and most is done in gpg and not in gpg-agent. Thus I am not sure whether it is a good idea to implement the OpenPGP ECDH stuff in the card. It might be better to implement the raw operations on the card and keep the rest in gpg. How is ECDH implemented by other smartcard specs? What I mean is that, despite it is called OpenPGP card, it is a pretty generic card spec with only two data objects for OpenPGP meta data (fingerprint and creation date). > I'm not sure about user interface, though. That is, how we should > show this attribute for output of --card-status of GnuPG. > > Currently for RSA, it's like: > > Key attributes ...: 2048R 2048R 2048R > > It will be something like: > > Key attributes ...: 256E 256e 256E That is okay, we don't show the RSA key parameters either. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri Feb 15 15:18:21 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 15 Feb 2013 23:18:21 +0900 Subject: ECC and smartcards In-Reply-To: <87ehghpwk9.fsf@vigenere.g10code.de> References: <1326243062.2015.1.camel@latx1.gniibe.org> <1360911825.12360.1.camel@cfw2.gniibe.org> <87ehghpwk9.fsf@vigenere.g10code.de> Message-ID: <1360937901.1886.2.camel@latx1.gniibe.org> On 2013-02-15 at 13:53 +0100, Werner Koch wrote: > How is ECDH implemented by other smartcard specs? I don't have some spec of ECC smartcard at hand. However, I could guess. Since such devices are highly recommended to follow standards and validation programs, I'm sure that implementations have the interface of ECC CDH (which is standard). If it's better for OpenPGP card specification not to specific to OpenPGP, how about One-Pass Diffie-Hellman method C(1, 1, ECC CDH) only? What PSO:DECRYPT command does is getting KEK, and it's gpg-agent to use KEK to get SESSION-KEY. This means that I don't need to implement AESwrap (unwrap, in fact) for Gnuk. Then, it's mostly ready. -- From wk at gnupg.org Fri Feb 15 16:43:35 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 15 Feb 2013 16:43:35 +0100 Subject: ECC and smartcards In-Reply-To: <1360937901.1886.2.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Fri, 15 Feb 2013 23:18:21 +0900") References: <1326243062.2015.1.camel@latx1.gniibe.org> <1360911825.12360.1.camel@cfw2.gniibe.org> <87ehghpwk9.fsf@vigenere.g10code.de> <1360937901.1886.2.camel@latx1.gniibe.org> Message-ID: <87y5epoa54.fsf@vigenere.g10code.de> On Fri, 15 Feb 2013 15:18, gniibe at fsij.org said: > I don't have some spec of ECC smartcard at hand. However, I could > guess. I just talked to Achim and we will check the latest ISO drafts to see what is actually in there. > Since such devices are highly recommended to follow standards and > validation programs, I'm sure that implementations have the interface > of ECC CDH (which is standard). We will check. > This means that I don't need to implement AESwrap (unwrap, in fact) > for Gnuk. Then, it's mostly ready. Okay. Salam-Shalom, Werner #include -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From martin at martinpaljak.net Fri Feb 15 19:28:23 2013 From: martin at martinpaljak.net (Martin Paljak) Date: Fri, 15 Feb 2013 20:28:23 +0200 Subject: ECC and smartcards In-Reply-To: <87y5epoa54.fsf@vigenere.g10code.de> References: <1326243062.2015.1.camel@latx1.gniibe.org> <1360911825.12360.1.camel@cfw2.gniibe.org> <87ehghpwk9.fsf@vigenere.g10code.de> <1360937901.1886.2.camel@latx1.gniibe.org> <87y5epoa54.fsf@vigenere.g10code.de> Message-ID: Hello, On Fri, Feb 15, 2013 at 5:43 PM, Werner Koch wrote: > On Fri, 15 Feb 2013 15:18, gniibe at fsij.org said: > >> I don't have some spec of ECC smartcard at hand. However, I could >> guess. > > I just talked to Achim and we will check the latest ISO drafts to see > what is actually in there. I have a bunch of different smart cards with varying EC support. If somebody would be interested in cooperation on extending the jopenpgpcard applet with ECC support, that might be a viable test-bed. Martin From lailavrazda1979 at gmail.com Sun Feb 17 02:29:13 2013 From: lailavrazda1979 at gmail.com (Laila Vrazda) Date: Sat, 16 Feb 2013 19:29:13 -0600 Subject: Several problems with building GnuPG 2 for Windows Message-ID: w32pth's location is nowhere to be found on the web site. All I could find on the internet were outdated svn URLs, so it was very hard to find. Also, --with-libgpg-error prefix doesn't work for libassuan or libksba, a workaround is to ignore what --help says and use --with-gpg-error-prefix. With libassuan, HAVE_DOSISH_SYSTEM needs to be set for x86_64-w64-mingw32. A workaround is to do CFLAGS+=-DHAVE_DOSISH_SYSTEM ./configure ... As for w32pth, is there any release of this, or does everyone have to pull it from the repo? The build is confusing, after running autogen.sh, it tells you to run it again. Shouldn't it run the configure script? Speaking of the configure script, it doesn't even run; it dies with a syntax error. It uses /w32root as the install directory; what ever happened to --prefix? Finally, it only supports MinGW, which is dead and buried. Why is there no support for MinGW-w64? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Sun Feb 17 17:10:15 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 17 Feb 2013 17:10:15 +0100 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: (Laila Vrazda's message of "Sat, 16 Feb 2013 19:29:13 -0600") References: Message-ID: <87txpancpk.fsf@vigenere.g10code.de> On Sun, 17 Feb 2013 02:29, lailavrazda1979 at gmail.com said: > w32pth's location is nowhere to be found on the web site. All I could find > on the internet were outdated svn URLs, so it was very hard to find. Also, I don't think that it is hard to fine: # # Pth emulation # server ftp://ftp.g10code.com/g10code/w32pth # checked: 2012-03-28 wk - still sufficient file w32pth-2.0.2.tar.bz2 chk 9f43acb64867fb54b456f8a1187307ceb7bdf183 That is from packages/packages.current. You use gpg4win? No, then better start using this. Everything you need to know is there: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=tree > of the configure script, it doesn't even run; it dies with a syntax error. > It uses /w32root as the install directory; what ever doc/README.W32 tells you how to change the defauld build tree. > happened to --prefix? Finally, it only supports MinGW, which is dead and Nope. Actually the last release was done with the 32 bit toolchain from mingw64. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lailavrazda1979 at gmail.com Sun Feb 17 19:56:57 2013 From: lailavrazda1979 at gmail.com (Laila Vrazda) Date: Sun, 17 Feb 2013 12:56:57 -0600 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: <87txpancpk.fsf@vigenere.g10code.de> References: <87txpancpk.fsf@vigenere.g10code.de> Message-ID: Thanks for the link to the release of w32pth, its configure script works, and it does support x86_64-w64-mingw32. It seems my complaints about w32pth only applied to the git copy I found. However, you didn't address the issues I pointed out with libassuan or libksba. Additionally, the build of w32pth dies with "unknown type name sigset_t". On Sun, Feb 17, 2013 at 10:10 AM, Werner Koch wrote: > On Sun, 17 Feb 2013 02:29, lailavrazda1979 at gmail.com said: > > w32pth's location is nowhere to be found on the web site. All I could > find > > on the internet were outdated svn URLs, so it was very hard to find. > Also, > > I don't think that it is hard to fine: > > # > # Pth emulation > # > > server ftp://ftp.g10code.com/g10code/w32pth > > # checked: 2012-03-28 wk - still sufficient > file w32pth-2.0.2.tar.bz2 > chk 9f43acb64867fb54b456f8a1187307ceb7bdf183 > > That is from packages/packages.current. You use gpg4win? No, then > better start using this. Everything you need to know is there: > > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=tree > > > of the configure script, it doesn't even run; it dies with a syntax > error. > > It uses /w32root as the install directory; what ever > > doc/README.W32 tells you how to change the defauld build tree. > > > happened to --prefix? Finally, it only supports MinGW, which is dead and > > Nope. Actually the last release was done with the 32 bit toolchain from > mingw64. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Mon Feb 18 05:16:43 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 18 Feb 2013 13:16:43 +0900 Subject: NeuG 0.05 and Gnuk 1.0.2 Message-ID: <1361161003.3183.4.camel@cfw2.gniibe.org> NeuG 0.05 was released with just a bit of speed improvement. NeuG is an implementation of True Random Number Generator based on quantization error of ADC of STM32F103. Also, Gnuk 1.0.2 was released. Gnuk is an implementation of Cryptographic Token for GnuPG, and it runs on STM32F103. Highlights are: * Product string is now "Gnuk Token" (was: "FSIJ USB Token") Since the USB ID Repository suggests not including vendor name in product string, we changed the product string. * New tool (experimental): test/upgrade_by_passwd.py This is the tool to install new firmware to Gnuk Token, provided that it's just shipped from factory (and nothing changed). It authenticate as admin by factory setting, register a public key for firmware upgrade, and then, does firmware upgrade. * tool/gnuk_upgrade.py supports '-k' option It now supports RSA key on the host PC (not the one on the Token). * New tool: tool/get_raw_public_key.py This is a script to dump raw data of RSA public key, which is useful to register to Gnuk Token as a firmware upgrade key. * New tool: tool/gnuk_remove_keys_libusb.py This tool is libusb version of gnuk_remove_keys.py. Besides, a bug in gnuk_remove_keys.py was fixed. * CCID protocol fix When time extension is requested by Gnuk Token to host PC, argument field was 0, which was wrong (but it works for most PC/SC implementations and GnuPG internal driver). Now it's 1, which means 1*BWT. * OpenPGP card protocol enhancement Now, VERIFY command accepts empty data and returns remaining trial counts, or 0x9000 (OK) when it's already authenticated. This is useful for application to synchronize card's authentication status. After this release, I branched off STABLE-BRANCH-1-0, and resumed further development of Gnuk in master branch. Here are some links for Gnuk and FST-01 (the hardware). Gnuk Repository: http://gitorious.org/gnuk Gnuk News: http://www.fsij.org/gnuk/ FST-01 introduction: http://www.seeedstudio.com/wiki/index.php?title=FST-01 FST-01 Q&A site: http://no-passwd.net/askbot/questions/ Japanese Documentation for FST-01 and Gnuk Token: http://no-passwd.net/fst-01-gnuk-handbook/index.html Enjoy, -- From gniibe at fsij.org Mon Feb 18 06:01:08 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 18 Feb 2013 14:01:08 +0900 Subject: ECC and smartcards In-Reply-To: <87y5epoa54.fsf@vigenere.g10code.de> References: <1326243062.2015.1.camel@latx1.gniibe.org> <1360911825.12360.1.camel@cfw2.gniibe.org> <87ehghpwk9.fsf@vigenere.g10code.de> <1360937901.1886.2.camel@latx1.gniibe.org> <87y5epoa54.fsf@vigenere.g10code.de> Message-ID: <1361163668.3183.9.camel@cfw2.gniibe.org> On 2013-02-15 at 16:43 +0100, Werner Koch wrote: > I just talked to Achim and we will check the latest ISO drafts to see > what is actually in there. Thank you. In Japan, ECDH means C(2, 0, ECC CDH) by CRYPTREC. http://www.cryptrec.go.jp/english/method.html Update of this specification is scheduled this year. -- From wk at gnupg.org Mon Feb 18 10:03:38 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Feb 2013 10:03:38 +0100 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: (Laila Vrazda's message of "Sun, 17 Feb 2013 12:56:57 -0600") References: <87txpancpk.fsf@vigenere.g10code.de> Message-ID: <87d2vym1sl.fsf@vigenere.g10code.de> On Sun, 17 Feb 2013 19:56, lailavrazda1979 at gmail.com said: > and it does support x86_64-w64-mingw32. It seems my complaints about w32pth > only applied to the git copy I found. However, you didn't address the The git stuff works as well. > issues I pointed out with libassuan or libksba. Additionally, the build of > w32pth dies with "unknown type name sigset_t". Did you actually tried to build it using the rules from Gpg4win? And even if a unreleased version does currently not build, the released versions all support building using "./autogen.sh --build-w32". Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lailavrazda1979 at gmail.com Mon Feb 18 11:15:16 2013 From: lailavrazda1979 at gmail.com (Laila Vrazda) Date: Mon, 18 Feb 2013 04:15:16 -0600 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: <87d2vym1sl.fsf@vigenere.g10code.de> References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> Message-ID: I don't want to build the installer, I want to cross-compile the GnuPG 2 binaries using autotools like you can for other targets. Why can't I do that, when it only requires a few simple fixes to work? Also, you STILL haven't addressed the issues I mentioned with libassuan or libksba, one of which applies to EVERY target. On Mon, Feb 18, 2013 at 3:03 AM, Werner Koch wrote: > On Sun, 17 Feb 2013 19:56, lailavrazda1979 at gmail.com said: > > > and it does support x86_64-w64-mingw32. It seems my complaints about > w32pth > > only applied to the git copy I found. However, you didn't address the > > The git stuff works as well. > > > issues I pointed out with libassuan or libksba. Additionally, the build > of > > w32pth dies with "unknown type name sigset_t". > > Did you actually tried to build it using the rules from Gpg4win? And > even if a unreleased version does currently not build, the released > versions all support building using "./autogen.sh --build-w32". > > > Shalom-Salam, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Feb 18 14:50:29 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 18 Feb 2013 14:50:29 +0100 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: (Laila Vrazda's message of "Mon, 18 Feb 2013 04:15:16 -0600") References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> Message-ID: <87621pn32y.fsf@vigenere.g10code.de> On Mon, 18 Feb 2013 11:15, lailavrazda1979 at gmail.com said: > that, when it only requires a few simple fixes to work? Also, you STILL > haven't addressed the issues I mentioned with libassuan or libksba, one of > which applies to EVERY target. Please re-read my answers. In general if you want us to help you, you have a better chance for an answer if you do this: * Avoid top posting. * Provide a more detailed problem report * Provide answer to our questions * Keep in mind that we are volunteers; if you need commercial support, check out http://gnupg.org/service.html . Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lailavrazda1979 at gmail.com Mon Feb 18 19:12:58 2013 From: lailavrazda1979 at gmail.com (Laila Vrazda) Date: Mon, 18 Feb 2013 12:12:58 -0600 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: <87621pn32y.fsf@vigenere.g10code.de> References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> Message-ID: Okay. I'll start from the beginning. First, I don't want to build the installer. I want to build the GnuPG 2 binaries for x86_64-w64-mingw32 using the autotools. I ran into the following issues: * Both libassuan and libksba mention a switch in their configure script that doesn't work (--with-libgpg-error-prefix). What does work is --with-gpg-error-prefix. The help should be changed to remove --with-libgpg-error-prefix and add --with-gpg-error-prefix, or the configure script should actually support --with-libgpg-error-prefix. Either one works. * The build for libassuan will die for x86_64-w64-mingw32 unless HAVE_DOSISH_SYSTEM is defined. This is not defined by the configure script for x86_64-w64-mingw32. * The autogen.sh script for w32pth in the git repository does not generate a working configure script. Additionally, its build process is strange; the autogen.sh script should generate a configure script, and I should be able to use that configure script with --prefix, --build, and --host. This does not apply to the release at the link you gave me, because the configure script in there works. If I use './autogen.sh --build-w32' it dies complaining that I don't have the MinGW tools installed, and besides, I want to use the configure script anyway. * The release of w32pth has a compile time issue. When compiling for x86_64-w64-mingw32, it dies complaining about an unknown type name 'sigset_t'. I believe this is simply an int, and can be fixed with a typedef in a header file. Whether it belongs in MinGW-w64 or GnuPG 2, I do not know. Again, I'd like to say that I want to use the autotools ( ./configure && make && make install ) to build GnuPG 2 for Windows x64 like I would for any other target. I don't understand why I should have to use Gpg4win to do this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian at quelltextlich.at Mon Feb 18 19:57:52 2013 From: christian at quelltextlich.at (Christian Aistleitner) Date: Mon, 18 Feb 2013 19:57:52 +0100 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> Message-ID: <20130218185752.GA14238@quelltextlich.at> Hi Laila, On Mon, Feb 18, 2013 at 12:12:58PM -0600, Laila Vrazda wrote: > [ --with-{lib,}gpg-error-prefix ] a fix for this problem is available at http://lists.gnupg.org/pipermail/gnupg-devel/2012-October/026972.html Best regards, Christian -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From wk at gnupg.org Tue Feb 19 10:11:48 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Feb 2013 10:11:48 +0100 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: (Laila Vrazda's message of "Mon, 18 Feb 2013 12:12:58 -0600") References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> Message-ID: <87ppzwk6qz.fsf@vigenere.g10code.de> On Mon, 18 Feb 2013 19:12, lailavrazda1979 at gmail.com said: > Again, I'd like to say that I want to use the autotools ( ./configure && > make && make install ) to build GnuPG 2 for Windows x64 like I would for Sorry, 64 bit Windows is not supported. There are two major problems: A new entropy gatherer modules in Libgcrypt needs to be written and due to sizeof(HANDLE) != sizeof(int) the entire HANDLE, socket, fd, sysfd, FILE use needs to be reworked. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Feb 19 10:25:02 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Feb 2013 10:25:02 +0100 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: (Laila Vrazda's message of "Mon, 18 Feb 2013 12:12:58 -0600") References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> Message-ID: <87liakk64x.fsf@vigenere.g10code.de> On Mon, 18 Feb 2013 19:12, lailavrazda1979 at gmail.com said: > * Both libassuan and libksba mention a switch in their configure script > that doesn't work (--with-libgpg-error-prefix). What does work is > --with-gpg-error-prefix. The help should be changed to remove I wonder which version you are using. This has been fixed in master more than a year ago. Both options are accepted but we only document --with-libgpg-error-prefix. > * The autogen.sh script for w32pth in the git repository does not generate > a working configure script. Additionally, its build process is strange; the It actually works for me and has evver worked. However, note that we don't develop w32pth anymore - it has been superseded by npth. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lailavrazda1979 at gmail.com Tue Feb 19 16:46:59 2013 From: lailavrazda1979 at gmail.com (Laila Vrazda) Date: Tue, 19 Feb 2013 09:46:59 -0600 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: <87liakk64x.fsf@vigenere.g10code.de> References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> <87liakk64x.fsf@vigenere.g10code.de> Message-ID: On Tue, Feb 19, 2013 at 3:25 AM, Werner Koch wrote: > On Mon, 18 Feb 2013 19:12, lailavrazda1979 at gmail.com said: > > > * Both libassuan and libksba mention a switch in their configure script > > that doesn't work (--with-libgpg-error-prefix). What does work is > > --with-gpg-error-prefix. The help should be changed to remove > > I wonder which version you are using. This has been fixed in master > more than a year ago. Both options are accepted but we only document > --with-libgpg-error-prefix. > > > * The autogen.sh script for w32pth in the git repository does not > generate > > a working configure script. Additionally, its build process is strange; > the > > It actually works for me and has evver worked. However, note that we > don't develop w32pth anymore - it has been superseded by npth. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > As far as I know, I am using the latest versions of everything. * libgpg-error 1.10 * libassuan 2.0.3 * libksba 1.3.0 * libgcrypt 1.5.0 * gnupg 2.0.19 * w32pth 2.0.4 Also, if w32pth has been superseded, why is there nothing about this on the website? It has almost no information about building for Windows. Since w32pth is obsolete, I won't worry about my problems with it, I'll just try npth. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lailavrazda1979 at gmail.com Tue Feb 19 17:11:34 2013 From: lailavrazda1979 at gmail.com (Laila Vrazda) Date: Tue, 19 Feb 2013 10:11:34 -0600 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> <87liakk64x.fsf@vigenere.g10code.de> Message-ID: The build of npth dies with the following: libtool: compile: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT npth.lo -MD -MP -MF .deps/npth.Tpo -c npth.c -o npth.o In file included from npth.c:39:0: npth.h:50:8: error: redefinition of 'struct timespec' struct timespec { ^ In file included from npth.h:33:0, from npth.c:39: /home/kineta/win64-build/cross/x86_64-w64-mingw32/include/sys/types.h:89:8: note: originally defined here struct timespec { ^ A workaround is to comment out lines 50-53 in the file w32/npth.h. After that, one of the tests fails to compile: make[2]: Entering directory `/home/kineta/gpg2-build/npth-0.91/tests' x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I.. -I../w32 -g -O2 -MT t-mutex.o -MD -MP -MF .deps/t-mutex.Tpo -c -o t-mutex.o t-mutex.c mv -f .deps/t-mutex.Tpo .deps/t-mutex.Po /bin/sh ../libtool --tag=CC --mode=link x86_64-w64-mingw32-gcc -g -O2 -o t-mutex.exe t-mutex.o ../w32/libnpth.la libtool: link: x86_64-w64-mingw32-gcc -g -O2 -o t-mutex.exe t-mutex.o ../w32/.libs/libnpth.a ../w32/.libs/libnpth.a(npth.o): In function `npth_connect': /home/kineta/gpg2-build/npth-0.91/w32/npth.c:1676: undefined reference to `__imp_connect' ../w32/.libs/libnpth.a(npth.o): In function `npth_accept': /home/kineta/gpg2-build/npth-0.91/w32/npth.c:1688: undefined reference to `__imp_accept' ... /home/kineta/gpg2-build/npth-0.91/w32/npth.c:1978: undefined reference to `__WSAFDIsSet' /home/kineta/gpg2-build/npth-0.91/w32/npth.c:1979: undefined reference to `__WSAFDIsSet' /home/kineta/gpg2-build/npth-0.91/w32/npth.c:1984: undefined reference to `__imp_WSACloseEvent' collect2: error: ld returned 1 exit status make[2]: *** [t-mutex.exe] Error 1 I think it just needs to link with ws2_32. Unfortunately, I know next to nothing about autotools internals, so I can't fix it for now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lailavrazda1979 at gmail.com Tue Feb 19 20:02:27 2013 From: lailavrazda1979 at gmail.com (Laila Vrazda) Date: Tue, 19 Feb 2013 13:02:27 -0600 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> <87liakk64x.fsf@vigenere.g10code.de> Message-ID: I tried it manually and confirmed that t-mutex.o and t-thread.o just need to be linked with ws2_32 to work. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Feb 19 21:44:00 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Feb 2013 21:44:00 +0100 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: (Laila Vrazda's message of "Tue, 19 Feb 2013 09:46:59 -0600") References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> <87liakk64x.fsf@vigenere.g10code.de> Message-ID: <87fw0shw4v.fsf@vigenere.g10code.de> On Tue, 19 Feb 2013 16:46, lailavrazda1979 at gmail.com said: > Also, if w32pth has been superseded, why is there nothing about this on the > website? It has almost no information about building for Windows. Since doc/README.W32 has al required information. nPth is only used by the current development version. Please re-read my previous post: Building GnuPG as 64 bit programs is not supported. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From lailavrazda1979 at gmail.com Tue Feb 19 22:07:41 2013 From: lailavrazda1979 at gmail.com (Laila Vrazda) Date: Tue, 19 Feb 2013 15:07:41 -0600 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: <87fw0shw4v.fsf@vigenere.g10code.de> References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> <87liakk64x.fsf@vigenere.g10code.de> <87fw0shw4v.fsf@vigenere.g10code.de> Message-ID: I found no doc/README.W32 in the GnuPG 2 tarball. Additionally, the build failures I pointed out have nothing to do with building as 64 bit. Speaking of which, out of curiosity, why is it not supported? -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian at quelltextlich.at Wed Feb 20 00:16:08 2013 From: christian at quelltextlich.at (Christian Aistleitner) Date: Wed, 20 Feb 2013 00:16:08 +0100 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: <87liakk64x.fsf@vigenere.g10code.de> References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> <87liakk64x.fsf@vigenere.g10code.de> Message-ID: <20130219231607.GA9297@quelltextlich.at> Hi Werner, On Tue, Feb 19, 2013 at 10:25:02AM +0100, Werner Koch wrote: > On Mon, 18 Feb 2013 19:12, lailavrazda1979 at gmail.com said: > > > * Both libassuan and libksba mention a switch in their configure script > > that doesn't work (--with-libgpg-error-prefix). What does work is > > --with-gpg-error-prefix. The help should be changed to remove > > I wonder which version you are using. This has been fixed in master > more than a year ago. Are you sure? The last change of libassuan's m4/gpg-error.m4 I get from git://git.gnupg.org/libassuan.git is 2e037baefdc40da6961721ad56fc7c38d4e492a8 from 2011-11-28. This commit introduced --with-libgpg-error-prefix --- However, this never worked. If --with-libgpg-error-prefix (without "lib") is omitted, m4/gpg-error.m4 resets gpg_error_config_prefix, thereby throwing away any setting made by --with-libgpg-error-prefix. The m4/gpg-error.m4 fix from the October 2012 has never been applied. Same holds true for other projects relying on gpg-error. Best regards, Christian -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From kylebutt at gmail.com Wed Feb 20 04:30:56 2013 From: kylebutt at gmail.com (Kyle Butt) Date: Tue, 19 Feb 2013 19:30:56 -0800 Subject: Patch add support for different algorithms in the agent private key storage Message-ID: There's probably more to done for this to be complete, but I'd like to get thoughts before I go too much further. I've tested with a new key and it works. Info about writing an automated test would be useful. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-different-protect-ciphers.patch Type: application/octet-stream Size: 12796 bytes Desc: not available URL: From wk at gnupg.org Wed Feb 20 10:15:26 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Feb 2013 10:15:26 +0100 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: <20130219231607.GA9297@quelltextlich.at> (Christian Aistleitner's message of "Wed, 20 Feb 2013 00:16:08 +0100") References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> <87liakk64x.fsf@vigenere.g10code.de> <20130219231607.GA9297@quelltextlich.at> Message-ID: <878v6jibwx.fsf@vigenere.g10code.de> On Wed, 20 Feb 2013 00:16, christian at quelltextlich.at said: > is 2e037baefdc40da6961721ad56fc7c38d4e492a8 from 2011-11-28. This > commit introduced --with-libgpg-error-prefix --- However, this never > worked. Frankly, I never tested Jim's patch. It worked for him and I had no problems, either. > The m4/gpg-error.m4 fix from the October 2012 has never been applied. Care to post it again? > Same holds true for other projects relying on gpg-error. Sure the M4 files are source copied. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Feb 20 10:22:33 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Feb 2013 10:22:33 +0100 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: (Laila Vrazda's message of "Tue, 19 Feb 2013 15:07:41 -0600") References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> <87liakk64x.fsf@vigenere.g10code.de> <87fw0shw4v.fsf@vigenere.g10code.de> Message-ID: <87y5ejgx0m.fsf@vigenere.g10code.de> On Tue, 19 Feb 2013 22:07, lailavrazda1979 at gmail.com said: > I found no doc/README.W32 in the GnuPG 2 tarball. Additionally, the build > failures I pointed out have nothing to do with building as 64 bit. Speaking Maybe the compiler differs from my version. Mingw had a tendency to introduce a lot of regression, I hope that this does not start again. FWIW, I am working on current Wheezy. > of which, out of curiosity, why is it not supported? See my message <87ppzwk6qz.fsf at vigenere.g10code.de> Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Feb 20 15:46:36 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Feb 2013 15:46:36 +0100 Subject: Patch add support for different algorithms in the agent private key storage In-Reply-To: (Kyle Butt's message of "Tue, 19 Feb 2013 19:30:56 -0800") References: Message-ID: <87ip5ngi0j.fsf@vigenere.g10code.de> On Wed, 20 Feb 2013 04:30, kylebutt at gmail.com said: > There's probably more to done for this to be complete, but I'd like to > get thoughts before I go too much further. I've tested with a new key > and it works. Info about writing an automated test would be useful. I am not keen to add the complexity by adding new vanity ciphers. If we would start with this we would rightfully receive requests to add yet another cipher for use in country X. There is a reason why gpg-agent only uses one cipher. Right, it could be argued that AES-256 is a stronger variant of AES but AES 128 is still sufficient for our purposes. There are many possible attacks on the passphrase and AES-128 is for sure not the weakest point. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kylebutt at gmail.com Wed Feb 20 18:20:39 2013 From: kylebutt at gmail.com (Kyle Butt) Date: Wed, 20 Feb 2013 09:20:39 -0800 Subject: Patch add support for different algorithms in the agent private key storage In-Reply-To: <87ip5ngi0j.fsf@vigenere.g10code.de> References: <87ip5ngi0j.fsf@vigenere.g10code.de> Message-ID: On Wed, Feb 20, 2013 at 6:46 AM, Werner Koch wrote: > On Wed, 20 Feb 2013 04:30, kylebutt at gmail.com said: >> There's probably more to done for this to be complete, but I'd like to >> get thoughts before I go too much further. I've tested with a new key >> and it works. Info about writing an automated test would be useful. > > I am not keen to add the complexity by adding new vanity ciphers. If we > would start with this we would rightfully receive requests to add yet > another cipher for use in country X. There is a reason why gpg-agent > only uses one cipher. Right, it could be argued that AES-256 is a > stronger variant of AES but AES 128 is still sufficient for our > purposes. There are many possible attacks on the passphrase and AES-128 > is for sure not the weakest point. > In general, yes. but not always. There are people with passphrases that long. I have a passphrase that long, and had changed my previous gpg settings to use AES-256. It's a minor regression to not be able to use a 256 bit cipher to protect keys. I think these 2 and no more is an acceptable position. I wrote the patch with the idea of making it general. If gpg will only ever support AES and AES256, there are some simplifications I can make (like removing smatchesprefix and putting the openpgp-sha1-s2k3- in the cipher name, assuming everything is CBC, etc). From wk at gnupg.org Wed Feb 20 20:21:37 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Feb 2013 20:21:37 +0100 Subject: Patch add support for different algorithms in the agent private key storage In-Reply-To: (Kyle Butt's message of "Wed, 20 Feb 2013 09:20:39 -0800") References: <87ip5ngi0j.fsf@vigenere.g10code.de> Message-ID: <87vc9mg5a6.fsf@vigenere.g10code.de> On Wed, 20 Feb 2013 18:20, kylebutt at gmail.com said: > In general, yes. but not always. There are people with passphrases that long. > I have a passphrase that long, and had changed my previous gpg settings to > use AES-256. It's a minor regression to not be able to use a 256 bit cipher to Why do you think the key length of the cipher has anything to do with the length of the passphrase? What is your threat model? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kylebutt at gmail.com Wed Feb 20 20:35:58 2013 From: kylebutt at gmail.com (Kyle Butt) Date: Wed, 20 Feb 2013 11:35:58 -0800 Subject: Patch add support for different algorithms in the agent private key storage In-Reply-To: <87vc9mg5a6.fsf@vigenere.g10code.de> References: <87ip5ngi0j.fsf@vigenere.g10code.de> <87vc9mg5a6.fsf@vigenere.g10code.de> Message-ID: On Wed, Feb 20, 2013 at 11:21 AM, Werner Koch wrote: > On Wed, 20 Feb 2013 18:20, kylebutt at gmail.com said: > >> In general, yes. but not always. There are people with passphrases that long. >> I have a passphrase that long, and had changed my previous gpg settings to >> use AES-256. It's a minor regression to not be able to use a 256 bit cipher to > > Why do you think the key length of the cipher has anything to do with > the length of the passphrase? What is your threat model? > My passphrase has 256 bits of entropy, so this does relate to key size. Most passphrases don't contain that much entropy, agreed. > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > From lailavrazda1979 at gmail.com Wed Feb 20 22:22:18 2013 From: lailavrazda1979 at gmail.com (Laila Vrazda) Date: Wed, 20 Feb 2013 15:22:18 -0600 Subject: Patch add support for different algorithms in the agent private key storage In-Reply-To: <87vc9mg5a6.fsf@vigenere.g10code.de> References: <87ip5ngi0j.fsf@vigenere.g10code.de> <87vc9mg5a6.fsf@vigenere.g10code.de> Message-ID: Just an FYI, AES-256 is less secure than AES-192. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kylebutt at gmail.com Wed Feb 20 22:31:51 2013 From: kylebutt at gmail.com (Kyle Butt) Date: Wed, 20 Feb 2013 13:31:51 -0800 Subject: Patch add support for different algorithms in the agent private key storage In-Reply-To: References: <87ip5ngi0j.fsf@vigenere.g10code.de> <87vc9mg5a6.fsf@vigenere.g10code.de> Message-ID: I'm aware of the related key attacks on AES-256, and also aware that they don't apply in this situation. On Wed, Feb 20, 2013 at 1:22 PM, Laila Vrazda wrote: > Just an FYI, AES-256 is less secure than AES-192. From rjh at sixdemonbag.org Wed Feb 20 23:03:41 2013 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 20 Feb 2013 17:03:41 -0500 Subject: Patch add support for different algorithms in the agent private key storage In-Reply-To: References: <87ip5ngi0j.fsf@vigenere.g10code.de> <87vc9mg5a6.fsf@vigenere.g10code.de> Message-ID: <5125483D.8080500@sixdemonbag.org> On 02/20/2013 04:22 PM, Laila Vrazda wrote: > Just an FYI, AES-256 is less secure than AES-192. That sentence has no meaning absent a context. "Less secure" against what, precisely? There are a couple of theorized instances in which AES-256 provides less resistance to certain kinds of attacks than AES-192 and/or AES-128, but it's a huge and unwarranted leap to go from purely theoretical cryptanalysis to a blanket, "AES-256 is less secure than AES-192." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From kylebutt at gmail.com Thu Feb 21 08:55:56 2013 From: kylebutt at gmail.com (Kyle Butt) Date: Wed, 20 Feb 2013 23:55:56 -0800 Subject: Private key storage hashed vs mac Message-ID: I'm curious about the private key storage. Currently the integrity of the key is protected by a sha1 of the plaintext. Were there discussions around using encrypt then authenticate with a mac? From wk at gnupg.org Thu Feb 21 11:15:36 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Feb 2013 11:15:36 +0100 Subject: Private key storage hashed vs mac In-Reply-To: (Kyle Butt's message of "Wed, 20 Feb 2013 23:55:56 -0800") References: Message-ID: <87hal6ezw7.fsf@vigenere.g10code.de> On Thu, 21 Feb 2013 08:55, kylebutt at gmail.com said: > I'm curious about the private key storage. Currently the integrity of > the key is protected by a sha1 of the plaintext. Were there > discussions around using encrypt then authenticate with a mac? The reason this scheme is used is because it is identical to the modern OpenPGP way protecting keys. We had this discussion a decade ago and it pops up on cryptography@ from time to time. However, if you want to evaluate this, please also consider that a (protected) private key is not intended to be send over any public channel [1] but merely acts as a fail stop mitigation in case an attacker got physical access to the machine. If it is possible for attacker to gain access to the protected key he should also be able to install malware to retrieve an unprotected copy of the key. Salam-Shalom, Werner [1] Modulo Robert's offer to run an NYT ad with his private key. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kylebutt at gmail.com Thu Feb 21 17:22:21 2013 From: kylebutt at gmail.com (Kyle Butt) Date: Thu, 21 Feb 2013 08:22:21 -0800 Subject: Private key storage hashed vs mac In-Reply-To: <87hal6ezw7.fsf@vigenere.g10code.de> References: <87hal6ezw7.fsf@vigenere.g10code.de> Message-ID: On Feb 21, 2013 2:22 AM, "Werner Koch" wrote: > > On Thu, 21 Feb 2013 08:55, kylebutt at gmail.com said: > > I'm curious about the private key storage. Currently the integrity of > > the key is protected by a sha1 of the plaintext. Were there > > discussions around using encrypt then authenticate with a mac? > > The reason this scheme is used is because it is identical to the modern > OpenPGP way protecting keys. > Can you point me at the reference for this? > We had this discussion a decade ago and it pops up on cryptography@ from Can you point me at the archives for that discussion? > time to time. However, if you want to evaluate this, please also > consider that a (protected) private key is not intended to be send over > any public channel [1] but merely acts as a fail stop mitigation in case > an attacker got physical access to the machine. If it is possible for > attacker to gain access to the protected key he should also be able to > install malware to retrieve an unprotected copy of the key. > There are scenarios where an attacker can read or modify your keys without being able to put malware on a machine. I wanted to find the discussion, but nothing turned up on Google. Thanks, Kyle. > > Salam-Shalom, > > Werner > > > [1] Modulo Robert's offer to run an NYT ad with his private key. > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Feb 21 18:33:20 2013 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Feb 2013 18:33:20 +0100 Subject: Private key storage hashed vs mac In-Reply-To: (Kyle Butt's message of "Thu, 21 Feb 2013 08:22:21 -0800") References: <87hal6ezw7.fsf@vigenere.g10code.de> Message-ID: <87wqu1efmn.fsf@vigenere.g10code.de> On Thu, 21 Feb 2013 17:22, kylebutt at gmail.com said: > Can you point me at the reference for this? RFC-4880 >> We had this discussion a decade ago and it pops up on cryptography@ from > > Can you point me at the archives for that discussion? I don't know whether there are archives - maybe at metzdown.com or randombit.net. Note that the name of that ML used to be coderpunks - I can't remeber the time it changed. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri Feb 22 03:27:08 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 22 Feb 2013 11:27:08 +0900 Subject: [PATCH] Bug fix of keytocard and support ECC key attributes Message-ID: <87r4k9hymb.fsf@cfw2.gniibe.org> Now, I am testing ECDSA authentication with Gnuk. It is highly experimental, but current development version of Gnuk (in the repository) works for me, with OpenSSH by ECDSA authentication. We need to change GnuPG for supporting ECC card/token. I'd like to apply patches incrementally, from easy parts to difficult parts. I won't apply changes where we haven't got answers yet, such as the things related to modifications of OpenPGPcard specification. This patch is for "gpg --card-status" to show ECDSA/ECDH key attributes and "keytocard" bug fix. Other changes needed are agent/ and scd/app-openpgp.c. I think that we have consensus about showing ECDSA/ECDH key attributes. I'll apply and push this changes to master. diff --git a/g10/call-agent.c b/g10/call-agent.c index 85a3f28..e3250fe 100644 --- a/g10/call-agent.c +++ b/g10/call-agent.c @@ -606,6 +606,10 @@ agent_keytocard (const char *hexgrip, int keyno, int force, { int rc; char line[ASSUAN_LINELENGTH]; + struct default_inq_parm_s parm; + + memset (&parm, 0, sizeof parm); + parm.ctx = agent_ctx; snprintf (line, DIM(line)-1, "KEYTOCARD %s%s %s OPENPGP.%d %s", force?"--force ": "", hexgrip, serialno, keyno, timestamp); @@ -615,8 +619,8 @@ agent_keytocard (const char *hexgrip, int keyno, int force, if (rc) return rc; - rc = assuan_transact (agent_ctx, line, NULL, NULL, default_inq_cb, - NULL, NULL, NULL); + rc = assuan_transact (agent_ctx, line, NULL, NULL, default_inq_cb, &parm, + NULL, NULL); if (rc) return rc; diff --git a/g10/card-util.c b/g10/card-util.c index 75208cc..add8eed 100644 --- a/g10/card-util.c +++ b/g10/card-util.c @@ -550,7 +550,9 @@ card_status (estream_t fp, char *serialno, size_t serialnobuflen) tty_fprintf (fp, " %u%c", info.key_attr[i].nbits, info.key_attr[i].algo == 1? 'R': - info.key_attr[i].algo == 17? 'D': '?'); + info.key_attr[i].algo == 17? 'D': + info.key_attr[i].algo == 18? 'e': + info.key_attr[i].algo == 19? 'E': '?'); tty_fprintf (fp, "\n"); } tty_fprintf (fp, "Max. PIN lengths .: %d %d %d\n", @@ -1560,7 +1562,7 @@ card_store_subkey (KBNODE node, int use) nbits = nbits_from_pk (pk); - if (!is_RSA (pk->pubkey_algo) || (!info.is_v2 && nbits != 1024) ) + if (!info.is_v2 && nbits != 1024) { tty_printf ("You may only store a 1024 bit RSA key on the card\n"); tty_printf ("\n"); -- From gniibe at fsij.org Fri Feb 22 05:03:10 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 22 Feb 2013 13:03:10 +0900 Subject: [PATCH] agent: fix two bugs Message-ID: <87obfdhu69.fsf@cfw2.gniibe.org> This is a fix which I found during ECC card/token support. (1) The length of keydata should not include trailing '\0'. (2) Since ECDSA and ECDH has six elements, we need to allocate 7 (+1 for trailing '\0'). I'll apply and push these changes to master. diff --git a/agent/command.c b/agent/command.c index 2844398..823b233 100644 --- a/agent/command.c +++ b/agent/command.c @@ -2197,6 +2197,7 @@ cmd_keytocard (assuan_context_t ctx, char *line) gcry_sexp_sprint (s_skey, GCRYSEXP_FMT_CANON, keydata, keydatalen); gcry_sexp_release (s_skey); + keydatalen--; /* Decrement for last '\0'. */ /* Add timestamp "created-at" in the private key */ timestamp = isotime2epoch (timestamp_str); snprintf (keydata+keydatalen-1, 30, "(10:created-at10:%010lu))", timestamp); diff --git a/agent/findkey.c b/agent/findkey.c index b17870e..ebdcc03 100644 --- a/agent/findkey.c +++ b/agent/findkey.c @@ -828,7 +828,7 @@ agent_public_key_from_file (ctrl_t ctrl, int i, idx; gcry_sexp_t s_skey; char algoname[6]; - char elems[6]; + char elems[7]; gcry_sexp_t uri_sexp, comment_sexp; const char *uri, *comment; size_t uri_length, comment_length; -- From wk at gnupg.org Fri Feb 22 20:20:53 2013 From: wk at gnupg.org (Werner Koch) Date: Fri, 22 Feb 2013 20:20:53 +0100 Subject: [Announce] Libassuan 2.1.0 released Message-ID: <87y5egb1ey.fsf@vigenere.g10code.de> Hello! I am pleased to announce version 2.1.0 of Libassuan. Libassuan is the IPC library used by GnuPG 2, GPGME, and a few other packages. This release adds support for the nPth thread library as used by the current development version of GnuPG. It also fixes some minor bugs and enables features on *BSD platforms. You may download the library and its OpenPGP signature from: ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.1.0.tar.bz2 (525k) ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.1.0.tar.bz2.sig As an alternative you may use a patch file to upgrade the previous version of the library: ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.0.3-2.1.0.diff.bz2 (62k) SHA-1 checksums are: af114073610ce0b30961986c2741d5e7230c9880 libassuan-2.1.0.tar.bz2 627e8b7560f0137d4e3ed2c409b6d9cc3ceb5150 libassuan-2.0.3-2.1.0.diff.bz2 Noteworthy changes in version 2.1.0 (2013-02-22) ------------------------------------------------ * Support for the nPth library. * Add assuan_check_version and two version macros. * Interface changes relative to the 2.0.3 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ASSUAN_SYSTEM_NPTH_IMPL NEW macro. ASSUAN_SYSTEM_NPTH NEW macro. __assuan_read NEW (private). __assuan_write NEW (private). __assuan_recvmsg NEW (private). __assuan_sendmsg NEW (private). __assuan_waitpid NEW (private). ASSUAN_VERSION NEW macro. ASSUAN_VERSION_NUMBER NEW macro. assuan_check_version NEW. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks to Ben Kibbey, W. Trevor King, and Marcus Brinkmann for their contributions. A listing with commercial support offers for GnuPG and related software is available at: http://www.gnupg.org/service.html The driving force behind the development of the GnuPG system is my company g10 Code. Maintenance and improvement of GnuPG and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Happy hacking, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Sun Feb 24 16:22:51 2013 From: wk at gnupg.org (Werner Koch) Date: Sun, 24 Feb 2013 16:22:51 +0100 Subject: Termination of GnuPG assignment Message-ID: <878v6dbut0.fsf@vigenere.g10code.de> Hello! Herewith I terminate my copyright assignment to the FSF for the program GnuPG, signed on 1998-02-23 and known in your records as GNUPG Werner Koch Germany 1961 1998-02-23 Assigns GNU Privacy Guard and future changes. wk at gnupg.org to the effect that all changes and/or enhancements to the code, documentation, and supporting files done by me from 2013-03-29 on will not anymore be covered by this assignment. Requirements for reporting and help for enforcement shall also be deemed as terminated. I also ask you to grant me back non-exclusive rights to use GNUPG as I see fit, as stated in the second paragraph of the assignment contract. Please confirm the receipt of this mail. Shalom-Salam, Werner Koch p.s. As already discussed with John at FOSDEM, I consider the use copyright assignments an inappropriate restriction of the freedom we want to give to users of software. However, the waiving of my copyright assignment does not mean that I would like to retract GnuPG from the GNU project. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: From gniibe at fsij.org Mon Feb 25 01:47:31 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 25 Feb 2013 09:47:31 +0900 Subject: [PATCH] agent: pksign result conversion to sexp to upper layer Message-ID: <1361753251.2945.4.camel@cfw2.gniibe.org> Here is anoter patch in the smartcard ECDSA support series. I think that some discussion would be needed for this implementation. The call sequence in question is like this: agent/pksign.c:agent_pksign_do -> agent/divert-scd.c:divert_pksign -> agent/call-scd.c:agent_card_pksign This patch moves the conversion/building of SEXP structure from agent_card_pksign to agent_pksign_do. That's because lower layer of gpg-agent doesn't have the detail of the information, such that what kind of key type, etc. In this patch, we get the key type by agent_public_key_from_file and build SEXP structure in agent_pksign_do. Perhaps, the approach of completely opposite would be preferable. That is, to let scdaemon build the SEXP structure, since scdaemon has all relevant information. In any cases, the changes will be similar for gpg-agent. So, please have a look. diff --git a/agent/agent.h b/agent/agent.h index 030b295..2fd0b8b 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -405,7 +405,8 @@ void agent_reload_trustlist (void); /*-- divert-scd.c --*/ int divert_pksign (ctrl_t ctrl, const unsigned char *digest, size_t digestlen, int algo, - const unsigned char *shadow_info, unsigned char **r_sig); + const unsigned char *shadow_info, unsigned char **r_sig, + size_t *r_siglen); int divert_pkdecrypt (ctrl_t ctrl, const unsigned char *cipher, const unsigned char *shadow_info, diff --git a/agent/call-scd.c b/agent/call-scd.c index f4ea20b..a334b15 100644 --- a/agent/call-scd.c +++ b/agent/call-scd.c @@ -825,10 +825,6 @@ agent_card_pksign (ctrl_t ctrl, char *p, line[ASSUAN_LINELENGTH]; membuf_t data; struct inq_needpin_s inqparm; - size_t len; - unsigned char *sigbuf; - size_t sigbuflen; - int prepend_nul; *r_buf = NULL; rc = start_scd (ctrl); @@ -868,32 +864,13 @@ agent_card_pksign (ctrl_t ctrl, if (rc) { + size_t len; + xfree (get_membuf (&data, &len)); return unlock_scd (ctrl, rc); } - sigbuf = get_membuf (&data, &sigbuflen); - - /* Create an S-expression from it which is formatted like this: - "(7:sig-val(3:rsa(1:sSIGBUFLEN:SIGBUF)))". We better make sure - that this won't be interpreted as a negative number. */ - prepend_nul = (sigbuflen && (*sigbuf & 0x80)); - - *r_buflen = 21 + 11 + prepend_nul + sigbuflen + 4; - p = xtrymalloc (*r_buflen); - *r_buf = (unsigned char*)p; - if (!p) - return unlock_scd (ctrl, out_of_core ()); - p = stpcpy (p, "(7:sig-val(3:rsa(1:s" ); - sprintf (p, "%u:", (unsigned int)sigbuflen + prepend_nul); - p += strlen (p); - if (prepend_nul) - *p++ = 0; - memcpy (p, sigbuf, sigbuflen); - p += sigbuflen; - strcpy (p, ")))"); - xfree (sigbuf); - - assert (gcry_sexp_canon_len (*r_buf, *r_buflen, NULL, NULL)); + + *r_buf = get_membuf (&data, r_buflen); return unlock_scd (ctrl, 0); } diff --git a/agent/divert-scd.c b/agent/divert-scd.c index 5fb037e..f0d8473 100644 --- a/agent/divert-scd.c +++ b/agent/divert-scd.c @@ -335,7 +335,8 @@ getpin_cb (void *opaque, const char *info, char *buf, size_t maxbuf) int divert_pksign (ctrl_t ctrl, const unsigned char *digest, size_t digestlen, int algo, - const unsigned char *shadow_info, unsigned char **r_sig) + const unsigned char *shadow_info, unsigned char **r_sig, + size_t *r_siglen) { int rc; char *kid; @@ -369,7 +370,10 @@ divert_pksign (ctrl_t ctrl, } if (!rc) - *r_sig = sigval; + { + *r_sig = sigval; + *r_siglen = siglen; + } xfree (kid); diff --git a/agent/pksign.c b/agent/pksign.c index dc44b88..1c56920 100644 --- a/agent/pksign.c +++ b/agent/pksign.c @@ -278,24 +278,105 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, if (!s_skey) { /* Divert operation to the smartcard */ - + gcry_sexp_t s_pkey, l; + const char *name; + size_t len; unsigned char *buf = NULL; - size_t len = 0; + int is_RSA = 0, is_ECDSA = 0; + + /* Check keytype by public key */ + rc = agent_public_key_from_file (ctrl, ctrl->keygrip, &s_pkey); + if (rc) + { + log_error ("failed to read the public key\n"); + goto leave; + } + l = gcry_sexp_cadr (s_pkey); + name = gcry_sexp_nth_data (l, 0, &len); + if (len == 3 && !memcmp (name, "rsa", 3)) + is_RSA = 1; + else if (len == 5 && !memcmp (name, "ecdsa", 5)) + is_ECDSA = 1; + gcry_sexp_release (l); + gcry_sexp_release (s_pkey); rc = divert_pksign (ctrl, ctrl->digest.value, ctrl->digest.valuelen, ctrl->digest.algo, - shadow_info, &buf); + shadow_info, &buf, &len); if (rc) { log_error ("smartcard signing failed: %s\n", gpg_strerror (rc)); goto leave; } - len = gcry_sexp_canon_len (buf, 0, NULL, NULL); - assert (len); - rc = gcry_sexp_sscan (&s_sig, NULL, (char*)buf, len); + if (is_RSA) + { + if (*buf & 0x80) + { + len++; + buf = xtryrealloc (buf, len); + if (!buf) + goto leave; + + memmove (buf + 1, buf, len - 1); + *buf = 0; + } + + rc = gcry_sexp_build (&s_sig, NULL, "(sig-val(rsa(s%b)))", len, buf); + } + else if (is_ECDSA) + { + unsigned char *r_buf, *s_buf; + int r_buflen, s_buflen; + + r_buflen = s_buflen = len/2; + + if (*buf & 0x80) + { + r_buflen++; + r_buf = xtrymalloc (r_buflen); + if (!r_buf) + goto leave; + + memcpy (r_buf + 1, buf, len/2); + *r_buf = 0; + } + else + r_buf = buf; + + if (*(buf + len/2) & 0x80) + { + s_buflen++; + s_buf = xtrymalloc (s_buflen); + if (!s_buf) + { + if (r_buflen > len/2) + xfree (r_buf); + + goto leave; + } + + memcpy (s_buf + 1, buf + len/2, len/2); + *s_buf = 0; + } + else + s_buf = buf + len/2; + + rc = gcry_sexp_build (&s_sig, NULL, "(sig-val(ecdsa(r%b)(s%b)))", + r_buflen, r_buf, + s_buflen, s_buf); + + if (r_buflen > len/2) + xfree (r_buf); + + if (s_buflen > len/2) + xfree (s_buf); + } + else + rc = gpg_error (GPG_ERR_NOT_IMPLEMENTED); + xfree (buf); if (rc) { -- From wk at gnupg.org Mon Feb 25 13:32:24 2013 From: wk at gnupg.org (Werner Koch) Date: Mon, 25 Feb 2013 13:32:24 +0100 Subject: [Announce] Libgpg-error 1.11 released Message-ID: <87obf8a813.fsf@vigenere.g10code.de> Hi! I am pleased to announce version 1.11 of libgpg-error, a library for common error values and messages in GnuPG components. If you want to use this library for you own project, please chime in and gnupg-devel so that we can discuss whether it makes sense to add a new source identifier. This is a shared library so it can be updated independently of each individual component, while still allowing the use of new error values in inter-process communication. It may be found in the files ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.11.tar.bz2 (478k) ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.11.tar.bz2.sig or gzip compressed ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.11.tar.gz (624k) ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.11.tar.gz.sig or as a patch to upgrade from 1.10: ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.10-1.11.diff.bz2 (200k) It should soon appear on the mirrors listed at: http://www.gnupg.org/mirrors.html Bug reports and requests for assistance should best be sent to: gnupg-devel at gnupg.org The sha1sum checksums for this distibution are be209b013652add5c7e2c473ea114f58203cc6cd libgpg-error-1.11.tar.bz2 db05ac4a29d3f92ae736da44f359b92b6af9f7ee libgpg-error-1.11.tar.gz 93b0cc74c21e6aa23863322ad7f32f1f4ae04e43 libgpg-error-1.10-1.11.diff.bz2 Noteworthy changes in version 1.11 (2013-02-25) ----------------------------------------------- * New error source GPG_ERR_SOURCE_ASSUAN for Libassuan related errors. * New macros GPG_ERROR_VERSION and GPG_ERROR_VERSION_NUMBER. New function gpg_error_check_version. * Interface changes relative to the 1.10 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GPG_ERR_NO_KEYSERVER NEW. GPG_ERR_INV_CURVE NEW. GPG_ERR_UNKNOWN_CURVE NEW. GPG_ERR_DUP_KEY NEW. GPG_ERR_AMBIGUOUS NEW. GPG_ERR_SOURCE_ASSUAN NEW. gpg_error_check_version NEW. GPG_ERROR_VERSION NEW. GPG_ERROR_VERSION_NUMBER NEW. Thanks to all translators; this time in particular to Yuri Chornoivan and Felipe Castro for adding Ukranian and Esperanto translations. A listing with commercial support offers for GnuPG and related software is available at: http://www.gnupg.org/service.html The driving force behind the development of the GnuPG system is my company g10 Code. Maintenance and improvement of GnuPG and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Happy hacking, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From branko at majic.rs Mon Feb 25 21:42:03 2013 From: branko at majic.rs (Branko Majic) Date: Mon, 25 Feb 2013 21:42:03 +0100 Subject: Termination of GnuPG assignment In-Reply-To: <878v6dbut0.fsf@vigenere.g10code.de> References: <878v6dbut0.fsf@vigenere.g10code.de> Message-ID: <20130225214203.341094c7@zetkin.primekey.se> On Sun, 24 Feb 2013 16:22:51 +0100 Werner Koch wrote: > Hello! > > Herewith I terminate my copyright assignment to the FSF for the > program GnuPG, signed on 1998-02-23 and known in your records as > > GNUPG Werner Koch Germany 1961 1998-02-23 > Assigns GNU Privacy Guard and future changes. > wk at gnupg.org > > to the effect that all changes and/or enhancements to the code, > documentation, and supporting files done by me from 2013-03-29 on will > not anymore be covered by this assignment. Requirements for reporting > and help for enforcement shall also be deemed as terminated. > > I also ask you to grant me back non-exclusive rights to use GNUPG as I > see fit, as stated in the second paragraph of the assignment contract. > Hello Werner, Could you tell us (I don't think I'm the only person interested) what would this mean in terms of development of GnuPG (when it comes down to your involvement in the project)? I apologise if my question is inappropriate. I'd also like to emphasize that it's not my intention to start any kind of heated debate regarding this topic. Best regards -- Branko Majic Jabber: branko at majic.rs Please use only Free formats when sending attachments to me. ?????? ????? ?????: branko at majic.rs ????? ??? ?? ??????? ?????? ????????? ? ????????? ?????????. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From kylebutt at gmail.com Tue Feb 26 06:36:56 2013 From: kylebutt at gmail.com (Kyle Butt) Date: Mon, 25 Feb 2013 21:36:56 -0800 Subject: [PATCH] add support for AES256 in the private key storage. Message-ID: Some simplification based on the assumption that key storage shouldn't be highly configurable. No longer touches common/sexp-parse.h I'm sending this patch under CC-0 creative commons license. If I need to sign something and scan it, I can do that too. From christian at quelltextlich.at Tue Feb 26 08:50:14 2013 From: christian at quelltextlich.at (Christian Aistleitner) Date: Tue, 26 Feb 2013 08:50:14 +0100 Subject: Termination of GnuPG assignment In-Reply-To: <878v6dbut0.fsf@vigenere.g10code.de> References: <878v6dbut0.fsf@vigenere.g10code.de> Message-ID: <20130226075014.GA30950@quelltextlich.at> Hello Werner, On Sun, Feb 24, 2013 at 04:22:51PM +0100, Werner Koch wrote: > Herewith I terminate my copyright assignment to the FSF for the program > GnuPG, signed on 1998-02-23 and known in your records as > [...] \o/ Yippie! What a generous move to strengthen dev's rights. Thanks a lot Werner. Kudos! That's a huge leap forward for GnuPG and freedom of free software. +1 to opening up GnuPG to contributors who choose to not surrender their rights! Best regards, Christian -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From wk at gnupg.org Tue Feb 26 10:10:20 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Feb 2013 10:10:20 +0100 Subject: [PATCH] add support for AES256 in the private key storage. In-Reply-To: (Kyle Butt's message of "Mon, 25 Feb 2013 21:36:56 -0800") References: Message-ID: <87obf78mpv.fsf@vigenere.g10code.de> On Tue, 26 Feb 2013 06:36, kylebutt at gmail.com said: > I'm sending this patch under CC-0 creative commons license. If I need > to sign something and scan it, I can do that too. You might have seen that I CCed the termination of my copyright assignment to this list. There is a 30 days period I have to wait and after then I will not anymore demand copyright assignments from any contributor. Thus please wait until then. However, this does not mean, that it will be easier to get patches in ;-) To keep code in a well being state, a maintainer has the unfriendly job of having to say "no" quite often. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Feb 26 10:17:32 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Feb 2013 10:17:32 +0100 Subject: Termination of GnuPG assignment In-Reply-To: <20130225214203.341094c7@zetkin.primekey.se> (Branko Majic's message of "Mon, 25 Feb 2013 21:42:03 +0100") References: <878v6dbut0.fsf@vigenere.g10code.de> <20130225214203.341094c7@zetkin.primekey.se> Message-ID: <87k3pv8mdv.fsf@vigenere.g10code.de> On Mon, 25 Feb 2013 21:42, branko at majic.rs said: > Could you tell us (I don't think I'm the only person interested) what > would this mean in terms of development of GnuPG (when it comes down to > your involvement in the project)? I have not planned for any change. I still like to work on GnuPG and would even like to spend more time on it. My financial situation however might demand that I better take a reasonable paid job somewhere else. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From christian at quelltextlich.at Tue Feb 26 12:00:59 2013 From: christian at quelltextlich.at (Christian Aistleitner) Date: Tue, 26 Feb 2013 12:00:59 +0100 Subject: [PATCH] Fix --with-{lib,}gpg-error-prefix. Message-ID: <20130226110058.GA23617@quelltextlich.at> * m4/gpg-error.m4: Update from current libgpg-error git. --- m4/gpg-error.m4 | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/m4/gpg-error.m4 b/m4/gpg-error.m4 index 35cbc78..feb963c 100644 --- a/m4/gpg-error.m4 +++ b/m4/gpg-error.m4 @@ -15,19 +15,20 @@ dnl Test for libgpg-error and define GPG_ERROR_CFLAGS and GPG_ERROR_LIBS dnl AC_DEFUN([AM_PATH_GPG_ERROR], [ AC_REQUIRE([AC_CANONICAL_HOST]) + gpg_error_config_prefix="" dnl --with-libgpg-error-prefix=PFX is the preferred name for this option, dnl since that is consistent with how our three siblings use the directory/ dnl package name in --with-$dir_name-prefix=PFX. AC_ARG_WITH(libgpg-error-prefix, - AC_HELP_STRING([--with-libgpg-error-prefix=PFX], - [prefix where GPG Error is installed (optional)]), - gpg_error_config_prefix="$withval", gpg_error_config_prefix="") + AC_HELP_STRING([--with-libgpg-error-prefix=PFX], + [prefix where GPG Error is installed (optional)]), + [gpg_error_config_prefix="$withval"]) dnl Accept --with-gpg-error-prefix and make it work the same as dnl --with-libgpg-error-prefix above, for backwards compatibility, dnl but do not document this old, inconsistently-named option. AC_ARG_WITH(gpg-error-prefix,, - gpg_error_config_prefix="$withval", gpg_error_config_prefix="") + [gpg_error_config_prefix="$withval"]) if test x$gpg_error_config_prefix != x ; then if test x${GPG_ERROR_CONFIG+set} != xset ; then @@ -39,7 +40,8 @@ AC_DEFUN([AM_PATH_GPG_ERROR], min_gpg_error_version=ifelse([$1], ,0.0,$1) AC_MSG_CHECKING(for GPG Error - version >= $min_gpg_error_version) ok=no - if test "$GPG_ERROR_CONFIG" != "no" ; then + if test "$GPG_ERROR_CONFIG" != "no" \ + && test -f "$GPG_ERROR_CONFIG" ; then req_major=`echo $min_gpg_error_version | \ sed 's/\([[0-9]]*\)\.\([[0-9]]*\)/\1/'` req_minor=`echo $min_gpg_error_version | \ -- 1.8.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From christian at quelltextlich.at Tue Feb 26 12:39:32 2013 From: christian at quelltextlich.at (Christian Aistleitner) Date: Tue, 26 Feb 2013 12:39:32 +0100 Subject: --with-{lib,}gpg-error-prefix fixes [was: Re: Several problems with building GnuPG 2 for Windows] In-Reply-To: <878v6jibwx.fsf@vigenere.g10code.de> References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> <87liakk64x.fsf@vigenere.g10code.de> <20130219231607.GA9297@quelltextlich.at> <878v6jibwx.fsf@vigenere.g10code.de> Message-ID: <20130226113931.GA19198@quelltextlich.at> Hello, On Wed, Feb 20, 2013 at 10:15:26AM +0100, Werner Koch wrote: > On Wed, 20 Feb 2013 00:16, christian at quelltextlich.at said: > > The m4/gpg-error.m4 fix from the October 2012 has never been applied. > > Care to post it again? just to have this in the archives as well: Werner meanwhile pushed a fix to both libgpg-error, and libassuan. Patches to fix this issue in gnupg and libgcrypt have been sent to the relevant lists. Best regards, Christian -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From wk at gnupg.org Tue Feb 26 13:22:15 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Feb 2013 13:22:15 +0100 Subject: [PATCH] Fix --with-{lib,}gpg-error-prefix. In-Reply-To: <20130226110058.GA23617@quelltextlich.at> (Christian Aistleitner's message of "Tue, 26 Feb 2013 12:00:59 +0100") References: <20130226110058.GA23617@quelltextlich.at> Message-ID: <8738wj8du0.fsf@vigenere.g10code.de> Hi! FWIW: If you send a patch, please note somewhere for what project this is. m4/gpg-error.m4 is used by several projects and looking up the commit id is cumbersome. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From christian at quelltextlich.at Tue Feb 26 14:29:10 2013 From: christian at quelltextlich.at (Christian Aistleitner) Date: Tue, 26 Feb 2013 14:29:10 +0100 Subject: Naming projects in patch subject lines [was: Re: [PATCH] Fix --with-{lib,}gpg-error-prefix.] In-Reply-To: <8738wj8du0.fsf@vigenere.g10code.de> References: <20130226110058.GA23617@quelltextlich.at> <8738wj8du0.fsf@vigenere.g10code.de> Message-ID: <20130226132910.GA23275@quelltextlich.at> Hi Werner, On Tue, Feb 26, 2013 at 01:22:15PM +0100, Werner Koch wrote: > FWIW: If you send a patch, please note somewhere for what project this > is. As none of this month's messages on this list follow this convention, it looks like a new convention to me :-) What's wrong with the current/old convention of just giving the project name when it's not gnupg? Best regards, Christian -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian at quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ --------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From wk at gnupg.org Tue Feb 26 18:58:04 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Feb 2013 18:58:04 +0100 Subject: [Announce] GPGME 1.4.0 released Message-ID: <874ngz6jpv.fsf@vigenere.g10code.de> Hello! I am pleased to announce version 1.4.0 of GPGME. GnuPG Made Easy (GPGME) is a C language library that allows to add support for cryptography to a program. It is designed to make access to public key crypto engines as included in GnuPG easier for applications. GPGME provides a high-level crypto API for encryption, decryption, signing, signature verification and key management. Noteworthy changes in version 1.4.0 are: * New function gpgme_set_global_flag to help debugging on Android. * New function gpgme_io_writen as a convenience wrapper around gpgme_io_write. * New functions to support the pinentry mode feature of GnuPG 2.1. * New macro GPGME_VERSION_NUMBER to allow supporting different API versions without the need for a configure test. * Several improvements for gpgme-tool. * Better logging of the common "invalid engine" error code. * Support for FD passing is now enabled by default. The configure option --disable-fd-passing may be used to disable this. * Interface changes relative to the 1.3.1 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GPGME_VERSION_NUMBER NEW. gpgme_io_writen NEW. gpgme_set_global_flag NEW. gpgme_set_pinentry_mode NEW. gpgme_get_pinentry_mode NEW. gpgme_pinentry_mode_t NEW. GPGME_PINENTRY_MODE_DEFAULT NEW. GPGME_PINENTRY_MODE_ASK NEW. GPGME_PINENTRY_MODE_CANCEL NEW. GPGME_PINENTRY_MODE_ERROR NEW. GPGME_PINENTRY_MODE_LOOPBACK NEW. You may download this library and its OpenPGP signature from: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.0.tar.bz2 (935k) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.0.tar.bz2.sig GZIP compressed tarballs are also available: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.0.tar.gz (1183k) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.0.tar.gz.sig As an alternative you may use a patch file to upgrade the previous version of the library: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.3.2-1.4.0.diff.bz2 (255k) SHA-1 checksums are: 897e36c1d3f6595d69fb37c820aaa162daa0e369 gpgme-1.4.0.tar.bz2 d91fde8377cc7da7e8897fd1a2ed767bba6bf71d gpgme-1.4.0.tar.gz 215961b0780916612a9c08ef88f92e113a3e0b51 gpgme-1.3.2-1.4.0.diff.bz2 Thanks to W. Trevor King for his contributions to gpgme-tool and to all others who reported and fixed bugs and portability issues. A big THANK YOU goes to my former colleague Marcus Brinkmann: He maintained GPGME for more than a decade and helped to turn it into the standard API for GnuPG. Please send questions regarding the use of GPGME to the gnupg-devel mailing list: http://lists.gnupg.org/mailman/listinfo/gnupg-devel If you need commercial support, you may want to consult this listing: http://www.gnupg.org/service.html The driving force behind the development of the GnuPG system is my company g10 Code. Maintenance and improvement of GnuPG and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Happy hacking, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 204 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Tue Feb 26 19:06:27 2013 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Feb 2013 19:06:27 +0100 Subject: Naming projects in patch subject lines In-Reply-To: <20130226132910.GA23275@quelltextlich.at> (Christian Aistleitner's message of "Tue, 26 Feb 2013 14:29:10 +0100") References: <20130226110058.GA23617@quelltextlich.at> <8738wj8du0.fsf@vigenere.g10code.de> <20130226132910.GA23275@quelltextlich.at> Message-ID: <87vc9f54rg.fsf@vigenere.g10code.de> On Tue, 26 Feb 2013 14:29, christian at quelltextlich.at said: > What's wrong with the current/old convention of just giving the > project name when it's not gnupg? I was not aware of the current convention. I usually tell hackers to ask on gnupg-devel for all GnuPG related software with the exception of libgcrypt. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Feb 27 09:48:48 2013 From: wk at gnupg.org (Werner Koch) Date: Wed, 27 Feb 2013 09:48:48 +0100 Subject: [PATCH] agent: pksign result conversion to sexp to upper layer In-Reply-To: <1361753251.2945.4.camel@cfw2.gniibe.org> (NIIBE Yutaka's message of "Mon, 25 Feb 2013 09:47:31 +0900") References: <1361753251.2945.4.camel@cfw2.gniibe.org> Message-ID: <87a9qq5ehb.fsf@vigenere.g10code.de> On Mon, 25 Feb 2013 01:47, gniibe at fsij.org said: > This patch moves the conversion/building of SEXP structure from > agent_card_pksign to agent_pksign_do. I see no problem with this change. > - size_t len = 0; > + int is_RSA = 0, is_ECDSA = 0; Please change to int is_RSA = 0; int is_ECDSA = 0; as per GNU coding standards. > + if (r_buflen > len/2) > + xfree (r_buf); > + > + if (s_buflen > len/2) > + xfree (s_buf); These conditions are not easy to understand. What about using an explicit flag telling whether they have been allocated or to use an alias variable initialized to NULL which may then always be freed? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Wed Feb 27 13:05:17 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 27 Feb 2013 21:05:17 +0900 Subject: [PATCH] agent: pksign result conversion to sexp to upper layer In-Reply-To: <87a9qq5ehb.fsf@vigenere.g10code.de> References: <1361753251.2945.4.camel@cfw2.gniibe.org> <87a9qq5ehb.fsf@vigenere.g10code.de> Message-ID: <1361966717.2672.1.camel@cfw2.gniibe.org> Thank you for reviewing the patch. On 2013-02-27 at 09:48 +0100, Werner Koch wrote: > On Mon, 25 Feb 2013 01:47, gniibe at fsij.org said: > > > This patch moves the conversion/building of SEXP structure from > > agent_card_pksign to agent_pksign_do. > > I see no problem with this change. OK. If it will be needed to move this to scdaemon, we will be able to do that later. As move to scdaemon will introduce a protocol change, I think that it's good to defer decision. > Please change to > > int is_RSA = 0; > int is_ECDSA = 0; > > as per GNU coding standards. > > > + if (r_buflen > len/2) > > + xfree (r_buf); > > + > > + if (s_buflen > len/2) > > + xfree (s_buf); > > These conditions are not easy to understand. What about using an > explicit flag telling whether they have been allocated or to use an > alias variable initialized to NULL which may then always be freed? Done. Now it's like this: + else if (is_ECDSA) + { + unsigned char *r_buf_allocated = NULL; + unsigned char *s_buf_allocated = NULL; + unsigned char *r_buf, *s_buf; + int r_buflen, s_buflen; + + r_buflen = s_buflen = len/2; + + if (*buf & 0x80) + { + r_buflen++; + r_buf_allocated = xtrymalloc (r_buflen); + if (!r_buf_allocated) + goto leave; + + r_buf = r_buf_allocated; + memcpy (r_buf + 1, buf, len/2); + *r_buf = 0; + } + else + r_buf = buf; + + if (*(buf + len/2) & 0x80) + { + s_buflen++; + s_buf_allocated = xtrymalloc (s_buflen); + if (!s_buf_allocated) + { + xfree (r_buf_allocated); + goto leave; + } + + s_buf = s_buf_allocated; + memcpy (s_buf + 1, buf + len/2, len/2); + *s_buf = 0; + } + else + s_buf = buf + len/2; + + rc = gcry_sexp_build (&s_sig, NULL, "(sig-val(ecdsa(r%b)(s%b)))", + r_buflen, r_buf, + s_buflen, s_buf); + xfree (r_buf_allocated); + xfree (s_buf_allocated); + } I'll commit this tomorrow after testing. I'm out of town today. -- From lailavrazda1979 at gmail.com Wed Feb 27 20:19:21 2013 From: lailavrazda1979 at gmail.com (Laila Vrazda) Date: Wed, 27 Feb 2013 13:19:21 -0600 Subject: Several problems with building GnuPG 2 for Windows In-Reply-To: <87y5ejgx0m.fsf@vigenere.g10code.de> References: <87txpancpk.fsf@vigenere.g10code.de> <87d2vym1sl.fsf@vigenere.g10code.de> <87621pn32y.fsf@vigenere.g10code.de> <87liakk64x.fsf@vigenere.g10code.de> <87fw0shw4v.fsf@vigenere.g10code.de> <87y5ejgx0m.fsf@vigenere.g10code.de> Message-ID: With the latest version of libassuan, HAVE_DOSISH_SYSTEM is still not defined for target x86_64-w64-mingw32. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg-devel at spodhuis.org Thu Feb 28 01:38:42 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Wed, 27 Feb 2013 19:38:42 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop Message-ID: <20130228003842.GA16965@redoubt.spodhuis.org> I've filed an issue to ensure this can be tracked, with a hope of getting it resolved before the next release of GnuPG. https://bugs.g10code.com/gnupg/issue1479 TCP half-close is, to me, sane and rational, but it is a grey area in HTTP and the nginx developers are probably not alone in treating it as "probably a connection abort, stop the proxying". Getting curl-shim to behave more like cURL itself, which does not use TCP half-closes, will lead to the most interoperable outcome. Beware that getting these requests to fail can be highly latency sensitive. Kristian's server aborts the connections fairly reliably; when I shoved my system load to 5x the number of CPUs, I could *sometimes* see it fail (I guess 5% from VM on laptop in Eastern USA to colo machine in NL) whereas Kristian (in Scandinavia) could see it fail much more reliably, 50% to 90% of the time. -Phil From dshaw at jabberwocky.com Thu Feb 28 04:06:08 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 27 Feb 2013 22:06:08 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: <20130228003842.GA16965@redoubt.spodhuis.org> References: <20130228003842.GA16965@redoubt.spodhuis.org> Message-ID: <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> On Feb 27, 2013, at 7:38 PM, Phil Pennock wrote: > I've filed an issue to ensure this can be tracked, with a hope of > getting it resolved before the next release of GnuPG. > > https://bugs.g10code.com/gnupg/issue1479 > > TCP half-close is, to me, sane and rational, but it is a grey area in > HTTP and the nginx developers are probably not alone in treating it as > "probably a connection abort, stop the proxying". Getting curl-shim to > behave more like cURL itself, which does not use TCP half-closes, will > lead to the most interoperable outcome. Interesting. This sounded so familiar, I did some digging and sure enough - it's bug 739: https://bugs.g10code.com/gnupg/issue739 Looks like that bug was fixed on 1.4 and for some reason it didn't make it into 2.0. David From gniibe at fsij.org Thu Feb 28 05:38:04 2013 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 28 Feb 2013 13:38:04 +0900 Subject: [PATCH] scd: support ECDSA public key Message-ID: <1362026284.3220.2.camel@cfw2.gniibe.org> Here is another patch for GnuPG in the smartcard ECDSA support series. (There will be two more: support ECDSA signing and support writekey for ECDSA.) This is to add ECDSA public key handling in OpenPGP card support. It includes things for ECDH too, but it is not yet fully implemented. Currently, the implementation assumes RSA. We extend it to support Elliptic Curve Cryptography (ECDH and ECDSA), too. For OpenPGP card specification. The implementation (6) and (8) below relates modify something to the specification. (6) for public key representation, and (8) for algorithm attributes. I think that we won't use compressed format for EC point for obvious reason, so we could get consensus on (6). For (8), it requires only OID, which defines all EC parameters. This is different which is mentioned in the specification currently. Summary: (1) We add key_type_t to support different key types. (2) We define curves by enumeration. This time only for NIST curves. (3) We extend keyattr: add key_type and union for RSA, ECDH, and ECDSA. (4) Extend SCDaemon to GPG protocol for key attributes. Which is implemented send_key_attr using new function get_ecc_key_parameters. Currently, it is like following for RSA: ... but only first two data are examined and used. In this patch, we re-define it as (in compatible way): [algorithm specific part...] and extend to ECDH and ECDSA. For ECDSA: and for ECDH (5) New function get_curve_name for name of Elliptic Curve in public key SEXP. (6) We extend get_public_key to support ECDSA. ECDH is not yet supported. It assumes OpenPGP card returns MPI of an EC point representing a public key for CMD_GENERATE_KEYPAIR. That is, in the format of uncompressed point format: 04 || x || y (7) New function parse_ecc_curve to parse OID and determice the curve. It's not fully parse the OID now. (8) We extend parse_algorithm_attribute to support ECDH and ECDSA. (9) Other changes following the change of keyattr. diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 23b28c3..f7f0f63 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -116,6 +116,16 @@ static struct { }; +/* Type of keys. */ +typedef enum + { + KEY_TYPE_ECDH, + KEY_TYPE_ECDSA, + KEY_TYPE_RSA, + } +key_type_t; + + /* The format of RSA private keys. */ typedef enum { @@ -128,6 +138,15 @@ typedef enum rsa_key_format_t; +/* Elliptic Curves. */ +enum + { + CURVE_NIST_P256, + CURVE_NIST_P384, + CURVE_NIST_P521 + }; + + /* One cache item for DOs. */ struct cache_s { struct cache_s *next; @@ -199,15 +218,27 @@ struct app_local_s { int fixedlen_admin; } pinpad; - struct - { - unsigned int n_bits; /* Size of the modulus in bits. The rest - of this strucuire is only valid if - this is not 0. */ - unsigned int e_bits; /* Size of the public exponent in bits. */ - rsa_key_format_t format; - } keyattr[3]; - + struct + { + key_type_t key_type; + union { + struct { + unsigned int n_bits; /* Size of the modulus in bits. The rest + of this strucuire is only valid if + this is not 0. */ + unsigned int e_bits; /* Size of the public exponent in bits. */ + rsa_key_format_t format; + } rsa; + struct { + int curve; + } ecdsa; + struct { + int curve; + int hashalgo; + int cipheralgo; + } ecdh; + }; + } keyattr[3]; }; @@ -845,18 +876,59 @@ send_key_data (ctrl_t ctrl, const char *name, static void +get_ecc_key_parameters (int curve, int *r_n_bits, const char **r_curve_oid) +{ + if (curve == CURVE_NIST_P256) + { + *r_n_bits = 256; + *r_curve_oid = "1.2.840.10045.3.1.7"; + } + else if (curve == CURVE_NIST_P384) + { + *r_n_bits = 384; + *r_curve_oid = "1.3.132.0.34"; + } + else + { + *r_n_bits = 521; + *r_curve_oid = "1.3.132.0.35"; + } +} + +static void send_key_attr (ctrl_t ctrl, app_t app, const char *keyword, int number) { char buffer[200]; + int n_bits; + const char *curve_oid; assert (number >=0 && number < DIM(app->app_local->keyattr)); - /* We only support RSA thus the algo identifier is fixed to 1. */ - snprintf (buffer, sizeof buffer, "%d 1 %u %u %d", - number+1, - app->app_local->keyattr[number].n_bits, - app->app_local->keyattr[number].e_bits, - app->app_local->keyattr[number].format); + if (app->app_local->keyattr[number].key_type == KEY_TYPE_RSA) + snprintf (buffer, sizeof buffer, "%d 1 %u %u %d", + number+1, + app->app_local->keyattr[number].rsa.n_bits, + app->app_local->keyattr[number].rsa.e_bits, + app->app_local->keyattr[number].rsa.format); + else if (app->app_local->keyattr[number].key_type == KEY_TYPE_ECDSA) + { + get_ecc_key_parameters (app->app_local->keyattr[number].ecdsa.curve, + &n_bits, &curve_oid); + snprintf (buffer, sizeof buffer, "%d 19 %u %s", + number+1, n_bits, curve_oid); + } + else if (app->app_local->keyattr[number].key_type == KEY_TYPE_ECDH) + { + get_ecc_key_parameters (app->app_local->keyattr[number].ecdh.curve, + &n_bits, &curve_oid); + snprintf (buffer, sizeof buffer, "%d 18 %u %s %d %d", + number+1, n_bits, curve_oid, + app->app_local->keyattr[number].ecdh.hashalgo, + app->app_local->keyattr[number].ecdh.cipheralgo); + } + else + snprintf (buffer, sizeof buffer, "0 0 UNKNOWN"); + send_status_direct (ctrl, keyword, buffer); } @@ -1154,6 +1226,18 @@ retrieve_key_material (FILE *fp, const char *hexkeyid, #endif /*GNUPG_MAJOR_VERSION > 1*/ +static const char * +get_curve_name (int curve) +{ + if (curve == CURVE_NIST_P256) + return "NIST P-256"; + else if (curve == CURVE_NIST_P384) + return "NIST P-384"; + else + return "NIST P-521"; +} + + /* Get the public key for KEYNO and store it as an S-expresion with the APP handle. On error that field gets cleared. If we already know about the public key we will just return. Note that this does @@ -1171,11 +1255,14 @@ get_public_key (app_t app, int keyno) gpg_error_t err = 0; unsigned char *buffer; const unsigned char *keydata, *m, *e; - size_t buflen, keydatalen, mlen, elen; + size_t buflen, keydatalen; + size_t mlen = 0; + size_t elen = 0; unsigned char *mbuf = NULL; unsigned char *ebuf = NULL; char *keybuf = NULL; - char *keybuf_p; + gcry_sexp_t s_pkey; + size_t len; if (keyno < 1 || keyno > 3) return gpg_error (GPG_ERR_INV_ID); @@ -1235,43 +1322,16 @@ get_public_key (app_t app, int keyno) goto leave; } - - e = find_tlv (keydata, keydatalen, 0x0082, &elen); - if (!e) - { - err = gpg_error (GPG_ERR_CARD); - log_error (_("response does not contain the RSA public exponent\n")); - goto leave; - } - - /* Prepend numbers with a 0 if needed. */ - if (mlen && (*m & 0x80)) + if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_RSA) { - mbuf = xtrymalloc ( mlen + 1); - if (!mbuf) + e = find_tlv (keydata, keydatalen, 0x0082, &elen); + if (!e) { - err = gpg_error_from_syserror (); + err = gpg_error (GPG_ERR_CARD); + log_error (_("response does not contain the RSA public exponent\n")); goto leave; } - *mbuf = 0; - memcpy (mbuf+1, m, mlen); - mlen++; - m = mbuf; } - if (elen && (*e & 0x80)) - { - ebuf = xtrymalloc ( elen + 1); - if (!ebuf) - { - err = gpg_error_from_syserror (); - goto leave; - } - *ebuf = 0; - memcpy (ebuf+1, e, elen); - elen++; - e = ebuf; - } - } else { @@ -1328,29 +1388,88 @@ get_public_key (app_t app, int keyno) } } - /* Allocate a buffer to construct the S-expression. */ - /* FIXME: We should provide a generalized S-expression creation - mechanism. */ - keybuf = xtrymalloc (50 + 2*35 + mlen + elen + 1); - if (!keybuf) + + mbuf = xtrymalloc ( mlen + 1); + if (!mbuf) + { + err = gpg_error_from_syserror (); + goto leave; + } + /* Prepend numbers with a 0 if needed. */ + if (mlen && (*m & 0x80)) + { + *mbuf = 0; + memcpy (mbuf+1, m, mlen); + mlen++; + } + else + memcpy (mbuf, m, mlen); + + ebuf = xtrymalloc ( elen + 1); + if (!ebuf) { err = gpg_error_from_syserror (); goto leave; } + /* Prepend numbers with a 0 if needed. */ + if (elen && (*e & 0x80)) + { + *ebuf = 0; + memcpy (ebuf+1, e, elen); + elen++; + } + else + memcpy (ebuf, e, elen); + + if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_RSA) + { + err = gcry_sexp_build (&s_pkey, NULL, "(public-key(rsa(n%b)(e%b)))", + mlen, mbuf, elen, ebuf); + if (err) + goto leave; + + len = gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, NULL, 0); + keybuf = xtrymalloc (len); + if (!keybuf) + { + gcry_sexp_release (s_pkey); + err = gpg_error_from_syserror (); + goto leave; + } + gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, keybuf, len); + gcry_sexp_release (s_pkey); + } + else if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_ECDSA) + { + const char *curve_name + = get_curve_name (app->app_local->keyattr[keyno].ecdsa.curve); + + err = gcry_sexp_build (&s_pkey, NULL, + "(public-key(ecdsa(curve%s)(q%b)))", + curve_name, mlen, mbuf); + if (err) + goto leave; + + len = gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, NULL, 0); - sprintf (keybuf, "(10:public-key(3:rsa(1:n%u:", (unsigned int) mlen); - keybuf_p = keybuf + strlen (keybuf); - memcpy (keybuf_p, m, mlen); - keybuf_p += mlen; - sprintf (keybuf_p, ")(1:e%u:", (unsigned int)elen); - keybuf_p += strlen (keybuf_p); - memcpy (keybuf_p, e, elen); - keybuf_p += elen; - strcpy (keybuf_p, ")))"); - keybuf_p += strlen (keybuf_p); + keybuf = xtrymalloc (len); + if (!keybuf) + { + gcry_sexp_release (s_pkey); + err = gpg_error_from_syserror (); + goto leave; + } + gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, keybuf, len); + gcry_sexp_release (s_pkey); + } + else + { + err = gpg_error (GPG_ERR_NOT_IMPLEMENTED); + goto leave; + } app->app_local->pk[keyno].key = (unsigned char*)keybuf; - app->app_local->pk[keyno].keylen = (keybuf_p - keybuf); + app->app_local->pk[keyno].keylen = len - 1; /* Decrement for trailing '\0' */ leave: /* Set a flag to indicate that we tried to read the key. */ @@ -2395,7 +2514,7 @@ build_privkey_template (app_t app, int keyno, *result = NULL; *resultlen = 0; - switch (app->app_local->keyattr[keyno].format) + switch (app->app_local->keyattr[keyno].rsa.format) { case RSA_STD: case RSA_STD_N: @@ -2409,7 +2528,7 @@ build_privkey_template (app_t app, int keyno, } /* Get the required length for E. */ - rsa_e_reqlen = app->app_local->keyattr[keyno].e_bits/8; + rsa_e_reqlen = app->app_local->keyattr[keyno].rsa.e_bits/8; assert (rsa_e_len <= rsa_e_reqlen); /* Build the 7f48 cardholder private key template. */ @@ -2425,8 +2544,8 @@ build_privkey_template (app_t app, int keyno, tp += add_tlv (tp, 0x93, rsa_q_len); datalen += rsa_q_len; - if (app->app_local->keyattr[keyno].format == RSA_STD_N - || app->app_local->keyattr[keyno].format == RSA_CRT_N) + if (app->app_local->keyattr[keyno].rsa.format == RSA_STD_N + || app->app_local->keyattr[keyno].rsa.format == RSA_CRT_N) { tp += add_tlv (tp, 0x97, rsa_n_len); datalen += rsa_n_len; @@ -2478,8 +2597,8 @@ build_privkey_template (app_t app, int keyno, memcpy (tp, rsa_q, rsa_q_len); tp += rsa_q_len; - if (app->app_local->keyattr[keyno].format == RSA_STD_N - || app->app_local->keyattr[keyno].format == RSA_CRT_N) + if (app->app_local->keyattr[keyno].rsa.format == RSA_STD_N + || app->app_local->keyattr[keyno].rsa.format == RSA_CRT_N) { memcpy (tp, rsa_n, rsa_n_len); tp += rsa_n_len; @@ -2764,7 +2883,7 @@ do_writekey (app_t app, ctrl_t ctrl, goto leave; } - maxbits = app->app_local->keyattr[keyno].n_bits; + maxbits = app->app_local->keyattr[keyno].rsa.n_bits; nbits = rsa_n? count_bits (rsa_n, rsa_n_len) : 0; if (opt.verbose) log_info ("RSA modulus size is %u bits (%u bytes)\n", @@ -2775,7 +2894,7 @@ do_writekey (app_t app, ctrl_t ctrl, /* Try to switch the key to a new length. */ err = change_keyattr (app, keyno, nbits, pincb, pincb_arg); if (!err) - maxbits = app->app_local->keyattr[keyno].n_bits; + maxbits = app->app_local->keyattr[keyno].rsa.n_bits; } if (nbits != maxbits) { @@ -2785,7 +2904,7 @@ do_writekey (app_t app, ctrl_t ctrl, goto leave; } - maxbits = app->app_local->keyattr[keyno].e_bits; + maxbits = app->app_local->keyattr[keyno].rsa.e_bits; if (maxbits > 32 && !app->app_local->extcap.is_v2) maxbits = 32; /* Our code for v1 does only support 32 bits. */ nbits = rsa_e? count_bits (rsa_e, rsa_e_len) : 0; @@ -2797,7 +2916,7 @@ do_writekey (app_t app, ctrl_t ctrl, goto leave; } - maxbits = app->app_local->keyattr[keyno].n_bits/2; + maxbits = app->app_local->keyattr[keyno].rsa.n_bits/2; nbits = rsa_p? count_bits (rsa_p, rsa_p_len) : 0; if (nbits != maxbits) { @@ -2966,7 +3085,7 @@ do_genkey (app_t app, ctrl_t ctrl, const char *keynostr, unsigned int flags, to put a limit on the max. allowed keysize. 2048 bit will already lead to a 527 byte long status line and thus a 4096 bit key would exceed the Assuan line length limit. */ - keybits = app->app_local->keyattr[keyno].n_bits; + keybits = app->app_local->keyattr[keyno].rsa.n_bits; if (keybits > 4096) return gpg_error (GPG_ERR_TOO_LARGE); @@ -3753,6 +3872,22 @@ parse_historical (struct app_local_s *apploc, } +static int +parse_ecc_curve (const unsigned char *buffer, size_t buflen) +{ + int curve; + + if (buflen == 6 && buffer[5] == 0x22) + curve = CURVE_NIST_P384; + else if (buflen == 6 && buffer[5] == 0x23) + curve = CURVE_NIST_P521; + else + curve = CURVE_NIST_P256; + + return curve; +} + + /* Parse and optionally show the algorithm attributes for KEYNO. KEYNO must be in the range 0..2. */ static void @@ -3765,7 +3900,8 @@ parse_algorithm_attribute (app_t app, int keyno) assert (keyno >=0 && keyno <= 2); - app->app_local->keyattr[keyno].n_bits = 0; + app->app_local->keyattr[keyno].key_type = KEY_TYPE_RSA; + app->app_local->keyattr[keyno].rsa.n_bits = 0; relptr = get_one_do (app, 0xC1+keyno, &buffer, &buflen, NULL); if (!relptr) @@ -3784,27 +3920,41 @@ parse_algorithm_attribute (app_t app, int keyno) log_info ("Key-Attr-%s ..: ", desc[keyno]); if (*buffer == 1 && (buflen == 5 || buflen == 6)) { - app->app_local->keyattr[keyno].n_bits = (buffer[1]<<8 | buffer[2]); - app->app_local->keyattr[keyno].e_bits = (buffer[3]<<8 | buffer[4]); - app->app_local->keyattr[keyno].format = 0; + app->app_local->keyattr[keyno].rsa.n_bits = (buffer[1]<<8 | buffer[2]); + app->app_local->keyattr[keyno].rsa.e_bits = (buffer[3]<<8 | buffer[4]); + app->app_local->keyattr[keyno].rsa.format = 0; if (buflen < 6) - app->app_local->keyattr[keyno].format = RSA_STD; + app->app_local->keyattr[keyno].rsa.format = RSA_STD; else - app->app_local->keyattr[keyno].format = (buffer[5] == 0? RSA_STD : - buffer[5] == 1? RSA_STD_N : - buffer[5] == 2? RSA_CRT : - buffer[5] == 3? RSA_CRT_N : - RSA_UNKNOWN_FMT); + app->app_local->keyattr[keyno].rsa.format = (buffer[5] == 0? RSA_STD : + buffer[5] == 1? RSA_STD_N : + buffer[5] == 2? RSA_CRT : + buffer[5] == 3? RSA_CRT_N : + RSA_UNKNOWN_FMT); if (opt.verbose) log_printf ("RSA, n=%u, e=%u, fmt=%s\n", - app->app_local->keyattr[keyno].n_bits, - app->app_local->keyattr[keyno].e_bits, - app->app_local->keyattr[keyno].format == RSA_STD? "std" : - app->app_local->keyattr[keyno].format == RSA_STD_N?"std+n": - app->app_local->keyattr[keyno].format == RSA_CRT? "crt" : - app->app_local->keyattr[keyno].format == RSA_CRT_N?"crt+n":"?"); + app->app_local->keyattr[keyno].rsa.n_bits, + app->app_local->keyattr[keyno].rsa.e_bits, + app->app_local->keyattr[keyno].rsa.format == RSA_STD? "std" : + app->app_local->keyattr[keyno].rsa.format == RSA_STD_N?"std+n": + app->app_local->keyattr[keyno].rsa.format == RSA_CRT? "crt" : + app->app_local->keyattr[keyno].rsa.format == RSA_CRT_N?"crt+n":"?"); + } + else if (*buffer == 19) /* ECDSA */ + { + app->app_local->keyattr[keyno].key_type = KEY_TYPE_ECDSA; + app->app_local->keyattr[keyno].ecdsa.curve + = parse_ecc_curve (buffer + 1, buflen - 1); + } + else if (*buffer == 18 && buflen == 11) /* ECDH */ + { + app->app_local->keyattr[keyno].key_type = KEY_TYPE_ECDH; + app->app_local->keyattr[keyno].ecdh.curve + = parse_ecc_curve (buffer + 1, buflen - 1); + app->app_local->keyattr[keyno].ecdh.hashalgo = buffer[1]; + app->app_local->keyattr[keyno].ecdh.cipheralgo = buffer[2]; } else if (opt.verbose) log_printhex ("", buffer, buflen); -- From gnupg-devel at spodhuis.org Thu Feb 28 09:13:04 2013 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Thu, 28 Feb 2013 03:13:04 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> Message-ID: <20130228081304.GA23444@redoubt.spodhuis.org> On 2013-02-27 at 22:06 -0500, David Shaw wrote: > Interesting. This sounded so familiar, I did some digging and sure enough - it's bug 739: > > https://bugs.g10code.com/gnupg/issue739 > > Looks like that bug was fixed on 1.4 and for some reason it didn't make it into 2.0. Okay, I guess that means that getting it fixed on 2.0 is an easy case to argue. :) Thanks, -Phil From dshaw at jabberwocky.com Thu Feb 28 20:09:18 2013 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 28 Feb 2013 14:09:18 -0500 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: <20130228081304.GA23444@redoubt.spodhuis.org> References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> <20130228081304.GA23444@redoubt.spodhuis.org> Message-ID: On Feb 28, 2013, at 3:13 AM, Phil Pennock wrote: > On 2013-02-27 at 22:06 -0500, David Shaw wrote: >> Interesting. This sounded so familiar, I did some digging and sure enough - it's bug 739: >> >> https://bugs.g10code.com/gnupg/issue739 >> >> Looks like that bug was fixed on 1.4 and for some reason it didn't make it into 2.0. > > Okay, I guess that means that getting it fixed on 2.0 is an easy case to > argue. :) Pretty easy case. All set. This isn't an issue on master, by the way. The logic is reversed on that branch so there is only a shutdown when specifically requested - and it isn't requested. David From calestyo at scientia.net Thu Feb 28 19:43:01 2013 From: calestyo at scientia.net (Christoph Anton Mitterer) Date: Thu, 28 Feb 2013 19:43:01 +0100 Subject: Bug 1479: GnuPG curl-shim TCP half-close harms HTTP interop In-Reply-To: <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> References: <20130228003842.GA16965@redoubt.spodhuis.org> <074C92CD-12DB-4818-A0AA-8DB3DB2DA0CE@jabberwocky.com> Message-ID: <1362076981.20807.1.camel@fermat.scientia.net> On Wed, 2013-02-27 at 22:06 -0500, David Shaw wrote: > Looks like that bug was fixed on 1.4 and for some reason it didn't > make it into 2.0. I wonder how many important stuff makes it in only one of the two branches... Don't think it's a good idea to maintain both. Cheers, Chris.