From wk at gnupg.org Thu Dec 1 11:21:54 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Dec 2011 11:21:54 +0100 Subject: No more ChangeLogs Message-ID: <87y5uw7fst.fsf@vigenere.g10code.de> Hi! About a year ago I migrated all GnuPG related repositories from SVN to GIT. Now is the time to finish this process and get rid of the ChangeLog files. I did this right now with GnuPG master; the other projects will follow soon. Here is the info from doc/HACKING: * No more ChangeLog files Do not modify any of the ChangeLog files in GnuPG. Starting on December 1st, 2011 we put change information only in the GIT commit log, and generate a top-level ChangeLog file from logs at "make dist" time. As such, there are strict requirements on the form of the commit log messages. The old ChangeLog files have all be renamed to ChangeLog-2011 * Commit log requirements Your commit log should always start with a one-line summary, the second line should be blank, and the remaining lines are usually ChangeLog-style entries for all affected files. However, it's fine -- even recommended -- to write a few lines of prose describing the change, when the summary and ChangeLog entries don't give enough of the big picture. Omit the leading TABs that you're used to seeing in a "real" ChangeLog file, but keep the maximum line length at 72 or smaller, so that the generated ChangeLog lines, each with its leading TAB, will not exceed 80 columns. Instead of writing changelog entries along with the code I will now write them right before committing them. MAGIT is a great tool for this: You review your changes and by hitting 'C' in the diff output you will be taken to magit's log edit buffer which has been prepared similar to Emacsens add-change-log-entry-other-window. Another way to prepare the commit message is by using the vc-dwim tool. Thanks to Jim Meyering for the conversion script and his suggestions. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri Dec 2 06:09:19 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 02 Dec 2011 14:09:19 +0900 Subject: pinpad entry support in Git repository Message-ID: <1322802559.2589.9.camel@latx1.gniibe.org> Hi, In the Git repository of GnuPG (of master branch), I added pinpad input support for PC/SC. It is enabled for OpenPGPcard 2.0. Could you please test it out? (1) pinpad input for verify for user (2) pinpad input for verify for admin (3) pinpad input for passphrase modification by user (4) pinpad input for passphrase modification by admin Please let me know your reader and its features (has display or not). If it is stable enough, I would like to apply changes to stable branch. Thanks in advance. -- From n-roeser at gmx.net Fri Dec 2 10:05:30 2011 From: n-roeser at gmx.net (Nico R.) Date: Fri, 02 Dec 2011 10:05:30 +0100 Subject: Strange error message when running pinentry-gtk-2 Message-ID: <4ED894DA.9000208@gmx.net> Hello! on one computer, I?m running a gpg-agent from gnupg-2.0.18 and pinentry-gtk-2 from pinentry-0.8.1 under a Gentoo system. A few minutes ago, I tried to add a new SSH key to gpg-agent?s store using ssh-add. When the gpg-agent dialog opened, I typed a passphrase. Then I was asked to confirm it in the next dialog. This did not work, but I keep getting the following error message: Ung?ltige Zeichen in der PIN! (Versuch -1955310293 von 1) (I am using the de_DE.UTF-8 locale.) This message seems to indicate a bug somewhere. Especially the negative number. The passphrase I used was: 1spontaneous vulcano eruption0 (So this passphrase contains invalid characters?) Due to [0], I can?t try to track it down today, but I may have some more spare time soon. Perhaps someone spots the problem earlier. [0] http://ictf.cs.ucsb.edu/ Happy hacking -- Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From nils.faerber at kernelconcepts.de Fri Dec 2 10:41:10 2011 From: nils.faerber at kernelconcepts.de (Nils Faerber) Date: Fri, 02 Dec 2011 10:41:10 +0100 Subject: pinpad entry support in Git repository In-Reply-To: <1322802559.2589.9.camel@latx1.gniibe.org> References: <1322802559.2589.9.camel@latx1.gniibe.org> Message-ID: <4ED89D36.70701@kernelconcepts.de> Am 02.12.2011 06:09, schrieb NIIBE Yutaka: > Hi, Hi! > In the Git repository of GnuPG (of master branch), I added pinpad > input support for PC/SC. It is enabled for OpenPGPcard 2.0. > > Could you please test it out? > > (1) pinpad input for verify for user > (2) pinpad input for verify for admin > (3) pinpad input for passphrase modification by user > (4) pinpad input for passphrase modification by admin > > Please let me know your reader and its features (has display or not). > > If it is stable enough, I would like to apply changes to stable > branch. This is great news! I have been waiting for this for quite some time - many thanks for your effort! For the moment though I am not able to test it but anyway I wanted to communicate my great appreciation for your work. Thanks again! > Thanks in advance. Cheers nils -- kernel concepts GmbH Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Dec 2 11:45:52 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Dec 2011 11:45:52 +0100 Subject: Strange error message when running pinentry-gtk-2 In-Reply-To: <4ED894DA.9000208@gmx.net> (Nico R.'s message of "Fri, 02 Dec 2011 10:05:30 +0100") References: <4ED894DA.9000208@gmx.net> Message-ID: <87liqv45gf.fsf@vigenere.g10code.de> On Fri, 2 Dec 2011 10:05, n-roeser at gmx.net said: > Ung?ltige Zeichen in der PIN! (Versuch -1955310293 von 1) > > (I am using the de_DE.UTF-8 locale.) There are at least two bugs: a) The negative number and b) that it asks for a PIN; it shouls have asked for a passphrase. After you caught the flag, can you please try this again under the C locale? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bernhard at intevation.de Fri Dec 2 16:33:17 2011 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 2 Dec 2011 16:33:17 +0100 Subject: STEED - Usable end-to-end encryption In-Reply-To: <87ty774hf2.fsf@vigenere.g10code.de> References: <87ty774hf2.fsf@vigenere.g10code.de> Message-ID: <201112021633.25007.bernhard@intevation.de> Am Monday, 17. October 2011 20:11:29 schrieb Werner Koch: > ? http://g10code.com/steed.html I wonder how STEED compares to the approach of http://convergence.io/ which I haven't read fully yet. -- Managing Director + Owner: www.Intevation.net <- A Free Software Company Kolabsys.com: Board Member FSFE.org: Founding GA Member Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Fri Dec 2 16:53:42 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Dec 2011 16:53:42 +0100 Subject: STEED - Usable end-to-end encryption In-Reply-To: <201112021633.25007.bernhard@intevation.de> (Bernhard Reiter's message of "Fri, 2 Dec 2011 16:33:17 +0100") References: <87ty774hf2.fsf@vigenere.g10code.de> <201112021633.25007.bernhard@intevation.de> Message-ID: <87zkfb2cmx.fsf@vigenere.g10code.de> On Fri, 2 Dec 2011 16:33, bernhard at intevation.de said: > Am Monday, 17. October 2011 20:11:29 schrieb Werner Koch: >> ? http://g10code.com/steed.html > > I wonder how STEED compares to the approach of > http://convergence.io/ which I haven't read fully yet. Convergence is pased on Perspective (Wendlandt et al.) and used for Web access. Such a system may be used to extend our system: For example, DNSSEC can provide a strong channel for certificate transfer, and sophisticated monitoring networks can provide a high degree of spatial and temporal persistence, see\cite{Wendlandt:2008} and Sect.~\ref{related}. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Dec 2 18:11:41 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Dec 2011 18:11:41 +0100 Subject: [PATCH] Support Cherry SmartTerminal ST-2000 In-Reply-To: <1318021115-2231-1-git-send-email-ott@mirix.org> (Matthias-Christian Ott's message of "Fri, 7 Oct 2011 22:58:35 +0200") References: <1318021115-2231-1-git-send-email-ott@mirix.org> Message-ID: <87r50m3nle.fsf@vigenere.g10code.de> Hi, it took a while but I finally applied a similar patch (239659d3). Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From bjk at luxsci.net Sat Dec 3 22:07:49 2011 From: bjk at luxsci.net (Ben Kibbey) Date: Sat, 3 Dec 2011 16:07:49 -0500 Subject: pinpad entry support in Git repository In-Reply-To: <1322802559.2589.9.camel@latx1.gniibe.org> References: <1322802559.2589.9.camel@latx1.gniibe.org> Message-ID: <201112032108.pB3L82FW031034@rs136.luxsci.com> On Fri, Dec 02, 2011 at 02:09:19PM +0900, NIIBE Yutaka wrote: > Hi, > > In the Git repository of GnuPG (of master branch), I added pinpad > input support for PC/SC. It is enabled for OpenPGPcard 2.0. > > Could you please test it out? > > (1) pinpad input for verify for user > (2) pinpad input for verify for admin > (3) pinpad input for passphrase modification by user > (4) pinpad input for passphrase modification by admin > > Please let me know your reader and its features (has display or not). > > If it is stable enough, I would like to apply changes to stable > branch. I have a GemPlus USB-SL which does not have a pinpad and am having problems with this patch. I think I have narrowed it down to check_pcsc_keypad() and control_pcsc_wrapped() returning "premature EOF" after sending the CM_IOCTL_GET_FEATURE_REQUEST ioctl (or does that determine if there is pinpad support or not?). scdaemon later fails with "verify CHV2 failed: General error" after pinentry retrieves my PIN. -- Ben Kibbey [XMPP: bjk AT jabber DOT org] - [IRC: (bjk) FreeNode/OFTC] From bjk at luxsci.net Sun Dec 4 17:40:19 2011 From: bjk at luxsci.net (Ben Kibbey) Date: Sun, 4 Dec 2011 11:40:19 -0500 Subject: pinpad entry support in Git repository In-Reply-To: <201112032108.pB3L82FW031034@rs136.luxsci.com> References: <1322802559.2589.9.camel@latx1.gniibe.org> <201112032108.pB3L82FW031034@rs136.luxsci.com> Message-ID: <201112041641.pB4Gf5Ub030378@rs136.luxsci.com> On Sat, Dec 03, 2011 at 04:07:49PM -0500, Ben Kibbey wrote: > On Fri, Dec 02, 2011 at 02:09:19PM +0900, NIIBE Yutaka wrote: > > Hi, > > > > In the Git repository of GnuPG (of master branch), I added pinpad > > input support for PC/SC. It is enabled for OpenPGPcard 2.0. > > > > Could you please test it out? > > > > (1) pinpad input for verify for user > > (2) pinpad input for verify for admin > > (3) pinpad input for passphrase modification by user > > (4) pinpad input for passphrase modification by admin > > > > Please let me know your reader and its features (has display or not). > > > > If it is stable enough, I would like to apply changes to stable > > branch. > > I have a GemPlus USB-SL which does not have a pinpad and am having > problems with this patch. I think I have narrowed it down to > check_pcsc_keypad() and control_pcsc_wrapped() returning "premature EOF" > after sending the CM_IOCTL_GET_FEATURE_REQUEST ioctl (or does that > determine if there is pinpad support or not?). > > scdaemon later fails with "verify CHV2 failed: General error" after > pinentry retrieves my PIN. Nevermind. Working now. Thanks, -- Ben Kibbey [XMPP: bjk AT jabber DOT org] - [IRC: (bjk) FreeNode/OFTC] From gniibe at fsij.org Mon Dec 5 03:01:23 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 05 Dec 2011 11:01:23 +0900 Subject: pinentry-curses and pinpad entry Message-ID: <1323050483.1977.1.camel@latx1.gniibe.org> When using pinpad entry, GnuPG invokes pinentry and then kill it. It's OK killing pinentry program when it's GUI, but when it runs on terminal, the terminal remains cbreak an noecho mode. -- From vivarto at gmail.com Mon Dec 5 22:33:41 2011 From: vivarto at gmail.com (Veet Vivarto) Date: Mon, 5 Dec 2011 22:33:41 +0100 Subject: Strange error message when running pinentry-gtk-2 In-Reply-To: <4ED894DA.9000208@gmx.net> References: <4ED894DA.9000208@gmx.net> Message-ID: is there a way to generate a new key with just one line at the command promt? using the "--gen-key" command starts a long process of promts, questions and answers. Is it possible to bypass all of this by providing the name email and other necessary information all in one line? The same question for changing the pass-phrase. Can this be done without going through a submenu? than you in advance for your help. Vivarto -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Mon Dec 5 22:39:06 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 05 Dec 2011 16:39:06 -0500 Subject: Strange error message when running pinentry-gtk-2 In-Reply-To: References: <4ED894DA.9000208@gmx.net> Message-ID: <4EDD39FA.7070207@fifthhorseman.net> On 12/05/2011 04:33 PM, Veet Vivarto wrote: > the "--gen-key" command starts a long process of promts, questions and > answers. > Is it possible to bypass all of this by providing the name email > and other necessary information all in one line? You're probably looking for the --batch option. You can write your various information into an (ugly) print hack and pipe it into gpg --batch --gen-key if it really must all be a one-liner. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From vivarto at gmail.com Mon Dec 5 22:38:31 2011 From: vivarto at gmail.com (Veet Vivarto) Date: Mon, 5 Dec 2011 22:38:31 +0100 Subject: Is there a way to use just one line with parameters when manipulating key-ring at the at command prompt? Message-ID: Please disregard my previous message. I made a mistake and forgot to change the subject. Here is the question again, this time with the correct subject line. Is there a way to generate a new key with just one line at the command promt? using the "--gen-key" command starts a long process of promts, questions and answers. Is it possible to bypass all of this by providing the name email and other necessary information all in one line? The same question for changing the pass-phrase. Can this be done without going through a submenu? than you in advance for your help. Vivarto From jerome at jeromebaum.com Mon Dec 5 22:44:24 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Mon, 05 Dec 2011 22:44:24 +0100 Subject: Strange error message when running pinentry-gtk-2 In-Reply-To: References: <4ED894DA.9000208@gmx.net> Message-ID: <4EDD3B38.2060108@jeromebaum.com> On 2011-12-05 22:33, Veet Vivarto wrote: > is there a way to generate a new key with just one line at the command > promt? > using > the "--gen-key" command starts a long process of promts, questions and > answers. > Is it possible to bypass all of this by providing the name email > and other necessary information all in one line? You can create a keyspec file and use that. Example command: gpg --gen-key --no-tty --batch -----END----- This is without passphrase, see gnupg docs for more details. > The same question for changing the pass-phrase. Can this be done without > going through a submenu? Take a look at passphrase-fd, not sure if it works for this but worth a try. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- Recht: Internet-freier Raum. -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Dec 6 09:59:50 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 Dec 2011 09:59:50 +0100 Subject: Strange error message when running pinentry-gtk-2 In-Reply-To: (Veet Vivarto's message of "Mon, 5 Dec 2011 22:33:41 +0100") References: <4ED894DA.9000208@gmx.net> Message-ID: <87sjkyf52x.fsf@vigenere.g10code.de> On Mon, 5 Dec 2011 22:33, vivarto at gmail.com said: > The same question for changing the pass-phrase. Can this be done without > going through a submenu? gpg --passwd userid (since version 2.0.15) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From phcoder at gmail.com Tue Dec 13 15:49:07 2011 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Tue, 13 Dec 2011 15:49:07 +0100 Subject: [PATCH] Fix alignment in serpent.c Message-ID: <4EE765E3.405@gmail.com> When compiling with -Wcast-align I've got some warnings in serpent.c upon closer examination it revealed that this is a real problem. Serpent assumes key, input and output to be aligned but even in selftests it's not guaranteed to be. Attached patch fixes the issue without performance impact -- Regards Vladimir '?-coder/phcoder' Serbinenko -------------- next part -------------- A non-text attachment was scrubbed... Name: serpent.diff Type: text/x-diff Size: 5159 bytes Desc: not available URL: From justin at mac.com Tue Dec 13 20:09:12 2011 From: justin at mac.com (Justin C. Walker) Date: Tue, 13 Dec 2011 11:09:12 -0800 Subject: Parallel builds Message-ID: <52BA4C13-50DA-4EC0-8910-08146D62A5D7@mac.com> Hi, I am a Sage developer , and we package and build libgpg_error as part of Sage. We recently discovered a problem with parallel builds on fast systems with a lot of cores (we have seen this on 12- and 8-core systems, both with two threads per core). The problem appears to be in the top-level Makefile of libgpg_error: a number of "mkdir" commands (not embedded in macros, AFAICT) are invoked without a leading "-" to avoid stopping the build if the directory exists. It can happen, if the system is fast enough and enough "make"s are going on simultaneously, that the check in the Makefile will indicate that directory does not exist, in multiple threads, and each of those threads will attempt to make the directory (with only one succeeding). Is this a known problem that's been fixed? We're currently using version 1.6. I'm not signed up for this project, so I don't know the bug-tracking system or how to find out such things. Thanks! Justin -- Justin C. Walker, Curmudgeon at Large Director Institute for the Enhancement of the Director's income ----------- Question 43: What if the hokey pokey really *is* what it?s all about? -- From gniibe at fsij.org Wed Dec 14 08:04:05 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 14 Dec 2011 16:04:05 +0900 Subject: Gnuk version 0.16 Message-ID: <1323846245.1918.7.camel@latx1.gniibe.org> Hi, Gnuk version 0.16 is out. Gnuk is software implementation of a USB token for GNU Privacy Guard. Gnuk supports OpenPGP card protocol version 2, and it runs on STM32F103 processor. In this release, I add "DnDpinentry" feature, which is quite experimental. We can use GUI of a file manager and drag and drop folders for pinentry. You need pinpad support of GnuPG to use this, though (which is currently only available in the master branch of git.gnupg.org). Highlights are (in gnuk-0.16/NEWS): * DnD pinentry support is added and it's default to pinentry support DnD pinentry support doesn't require any hardware extension, but emulates mass storage class device of USB. User inputs pass phrase by "drag and drop"-ing folders using file manager or something. * Bug fix for VERIFY for CHV2 With no keys, VERIFY command for CHV2 used to fail even if pass phrase is correct. It was intentional, because CHV2 verification would be useless with no keys. But there is a corner case for PRIVATE-DOs, which may requires CHV2 verification. Even though Gnuk doesn't support any PRIVATE-DOs, it is good to be fixed. * Changed bcdUSB = 1.1 Gnuk device conforms to USB 2.0 full speed device, but when it was 2.0, some OS informs users, "you can connect the device to 2.0 compliant hub so that it can have better bandwidth", which is not the case for full speed device. -- From phcoder at gmail.com Wed Dec 14 10:02:57 2011 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Wed, 14 Dec 2011 10:02:57 +0100 Subject: Fix few warnings in libgcrypt/cipher In-Reply-To: <4EA460A6.6050309@gmail.com> References: <4EA460A6.6050309@gmail.com> Message-ID: <4EE86641.8050308@gmail.com> Nobody seems to care. Is it a wrong list for libgcrypt patches? If so what would be the right one? -- Regards Vladimir '?-coder/phcoder' Serbinenko From wk at gnupg.org Wed Dec 14 10:43:35 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Dec 2011 10:43:35 +0100 Subject: Card reader fixes Message-ID: <8762hjcwu0.fsf@vigenere.g10code.de> Hi, since a couple of versions Scdaemon did not worked properly with regard to changing cards. I have now fixed a couple of such problems and for me it works again. I have only tested with the internal driver, though. We may want to backport some of these changes to 2.0. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 14 10:46:12 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Dec 2011 10:46:12 +0100 Subject: Parallel builds In-Reply-To: <52BA4C13-50DA-4EC0-8910-08146D62A5D7@mac.com> (Justin C. Walker's message of "Tue, 13 Dec 2011 11:09:12 -0800") References: <52BA4C13-50DA-4EC0-8910-08146D62A5D7@mac.com> Message-ID: <871us7cwpn.fsf@vigenere.g10code.de> On Tue, 13 Dec 2011 20:09, justin at mac.com said: > Is this a known problem that's been fixed? We're currently using > version 1.6. I'm not signed up for this project, so I don't know the The current version is 1.1.0. Please test again with that one. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 14 13:55:22 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Dec 2011 13:55:22 +0100 Subject: Fix few warnings in libgcrypt/cipher In-Reply-To: <4EE86641.8050308@gmail.com> ("Vladimir =?utf-8?Q?'=CF=86-cod?= =?utf-8?Q?er=2Fphcoder'?= Serbinenko"'s message of "Wed, 14 Dec 2011 10:02:57 +0100") References: <4EA460A6.6050309@gmail.com> <4EE86641.8050308@gmail.com> Message-ID: <87wr9zb9dx.fsf@vigenere.g10code.de> On Wed, 14 Dec 2011 10:02, phcoder at gmail.com said: > Nobody seems to care. Is it a wrong list for libgcrypt patches? If so > what would be the right one? gcrypt-devel would be better; but I read both. I briefly looked at your patch but I am not convinced about the change. In particular because you say that it does not impact on performance. On what systems and CPUs did you tested it? To apply a patch to Libgcrypt we need a copyright assignment to the FSF. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From phcoder at gmail.com Wed Dec 14 14:51:46 2011 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Wed, 14 Dec 2011 14:51:46 +0100 Subject: Fix few warnings in libgcrypt/cipher In-Reply-To: <87wr9zb9dx.fsf@vigenere.g10code.de> References: <4EA460A6.6050309@gmail.com> <4EE86641.8050308@gmail.com> <87wr9zb9dx.fsf@vigenere.g10code.de> Message-ID: <4EE8A9F2.8000208@gmail.com> On 14.12.2011 13:55, Werner Koch wrote: > On Wed, 14 Dec 2011 10:02, phcoder at gmail.com said: >> Nobody seems to care. Is it a wrong list for libgcrypt patches? If so >> what would be the right one? > gcrypt-devel would be better; but I read both. Ok, didn't find it at first and archives seems to be inaccessible. Subscribed to it. > I briefly looked at your patch but I am not convinced about the change. > In particular because you say that it does not impact on performance. > On what systems and CPUs did you tested it? > I didn't actually test but I don't do any additional copying that wasn't there. In any case the issues at hand (modifying const * for first patch und misaligned access for the second) can cause a crash or misbehaviour. > To apply a patch to Libgcrypt we need a copyright assignment to the FSF. > I have it for GRUB. But these patches are small. Since I intend to pull the new libgcrypt and put it in GRUB as soon as they are committed I believe my assignment will extend to those too (I don't remember exact wording now). Alternatively I could put it in GRUB first and then there will be no doubt and we avoid administrative hassle. > Salam-Shalom, > > Werner > -- Regards Vladimir '?-coder/phcoder' Serbinenko From hans at at.or.at Thu Dec 15 01:36:26 2011 From: hans at at.or.at (Hans-Christoph Steiner) Date: Wed, 14 Dec 2011 16:36:26 -0800 Subject: Creating a subkey from an existing key In-Reply-To: <4EB7DF82.7050509@fifthhorseman.net> References: <878vnsb9c1.fsf@vigenere.g10code.de> <4EB7DF82.7050509@fifthhorseman.net> Message-ID: <92F4CD37-4800-490E-ABC5-F691E6468527@at.or.at> On Nov 7, 2011, at 5:39 AM, Daniel Kahn Gillmor wrote: > On 11/07/2011 03:55 AM, Werner Koch wrote: >> GPGSM has a way to create a self-signed certificate or a certificate >> signing requests using an existing key. This feature was missing from >> GPG, thus I added it. > > Thank you for this, Werner! This is a great feature to have available. > I hope to test it out soon. I'll add my bit in now that I have a better sense of what I'm doing with gpg. This will definitely be useful in making integrating OTR keys into OpenPGP keys much more flexible. WIthout this, the only option seems to be to generate a DSA subkey in gpg, then export that for use in OTR. If someone has a well established DSA key for OTR that they want to include into their OpenPGP, this should be now possible using this new functionality. Thanks! .hc ---------------------------------------------------------------------------- If you are not part of the solution, you are part of the problem. From wk at gnupg.org Thu Dec 15 15:32:57 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Dec 2011 15:32:57 +0100 Subject: Fix few warnings in libgcrypt/cipher In-Reply-To: <4EE8A9F2.8000208@gmail.com> ("Vladimir =?utf-8?Q?'=CF=86-cod?= =?utf-8?Q?er=2Fphcoder'?= Serbinenko"'s message of "Wed, 14 Dec 2011 14:51:46 +0100") References: <4EA460A6.6050309@gmail.com> <4EE86641.8050308@gmail.com> <87wr9zb9dx.fsf@vigenere.g10code.de> <4EE8A9F2.8000208@gmail.com> Message-ID: <877h1xc3c6.fsf@vigenere.g10code.de> On Wed, 14 Dec 2011 14:51, phcoder at gmail.com said: > wasn't there. In any case the issues at hand (modifying const * for > first patch und misaligned access for the second) can cause a crash or > misbehaviour. Yes sure. There is definitley a need to fix that. It seems that until now everyone used a key right from the start of a properly aligned buffer. > I have it for GRUB. But these patches are small. Since I intend to Copyright does only care about the text and not about the sematics. Thus this patch might be a bit too long. > remember exact wording now). Alternatively I could put it in GRUB > first and then there will be no doubt and we avoid administrative > hassle. That is a better way. I can easily copy it from other GNU projects. Please give me some time; https://bugs.g10code.com/gnupg/issue1384 tracks this. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From alex at gpgtools.org Thu Dec 15 17:46:29 2011 From: alex at gpgtools.org (Alex (via GPGTools)) Date: Thu, 15 Dec 2011 17:46:29 +0100 Subject: 'xyt.jpg' is not a JPEG file Message-ID: <79591E04-24C3-4F26-8E0E-AA76C3CE7D38@gpgtools.org> Dear all, I think one of our users found a bug in GnuPG: Description: 'xyt.jpg' is not a JPEG file Version: 2.0.17 URL: http://support.gpgtools.org/discussions/everything/174 Steps that will reproduce the problem? 1. curl -LOs http://support.gpgtools.org/discussions/everything/174/assets/8ba23b7439a1ddd2b81d87daadf16b8c810dd7f4/essai.jpg 2. gpg2 --edit-key 123456789ABCDEF 3. addphoto essai.jpg What is the expected result? Added photo. What happens instead? Error message "gpg: `essai.jpg' is not a JPEG file" Possible workaround: Convert the file. Any additional information: * Seems to be a valid jpeg file * Here is the output ---------------------------------------------------- $ curl -LOs http://support.gpgtools.org/discussions/everything/174/assets/8ba23b7439a1ddd2b81d87daadf16b8c810dd7f4/essai.jpg $ gpg2 --edit-key 0DB03A7D gpg (GnuPG/MacGPG2) 2.0.17; Copyright (C) 2011 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. pub 2048R/0DB03A7D created: 2011-08-11 expires: never usage: SCEA trust: ultimate validity: ultimate sub 2048R/0AA3DA82 created: 2011-08-11 expires: never usage: SEA [ultimate] (1). GPGTools Test Key (For testing purposes only!) gpg> addphoto Pick an image to use for your photo ID. The image must be a JPEG file. Remember that the image is stored within your public key. If you use a very large picture, your key will become very large as well! Keeping the image close to 240x288 is a good size to use. Enter JPEG filename for photo ID: essai.jpg This JPEG is really large (13750 bytes) ! Are you sure you want to use it? (y/N) y gpg: `essai.jpg' is not a JPEG file Enter JPEG filename for photo ID: ---------------------------------------------------- Best regards, Alex -- http://gpgtools.org http://gpgtools.org/about (Google+, Twitter, RSS) From dshaw at jabberwocky.com Thu Dec 15 18:52:28 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 15 Dec 2011 12:52:28 -0500 Subject: 'xyt.jpg' is not a JPEG file In-Reply-To: <79591E04-24C3-4F26-8E0E-AA76C3CE7D38@gpgtools.org> References: <79591E04-24C3-4F26-8E0E-AA76C3CE7D38@gpgtools.org> Message-ID: <840AB387-AF50-4DE5-A5C4-449B375F83FE@jabberwocky.com> On Dec 15, 2011, at 11:46 AM, Alex (via GPGTools) wrote: > Dear all, > > I think one of our users found a bug in GnuPG: > > Description: 'xyt.jpg' is not a JPEG file > Version: 2.0.17 > URL: http://support.gpgtools.org/discussions/everything/174 > > Steps that will reproduce the problem? > 1. curl -LOs http://support.gpgtools.org/discussions/everything/174/assets/8ba23b7439a1ddd2b81d87daadf16b8c810dd7f4/essai.jpg > 2. gpg2 --edit-key 123456789ABCDEF > 3. addphoto essai.jpg This is issue 1331 on the tracker. I could have sworn I fixed it. Ah, looks like it was fixed on 1.4, but not 2.0. I'm currently setting up a new work box (going to try to use hg-git), and I'll add it to my stuff to do. David From phcoder at gmail.com Thu Dec 15 20:36:53 2011 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Thu, 15 Dec 2011 20:36:53 +0100 Subject: Fix few warnings in libgcrypt/cipher In-Reply-To: <877h1xc3c6.fsf@vigenere.g10code.de> References: <4EA460A6.6050309@gmail.com> <4EE86641.8050308@gmail.com> <87wr9zb9dx.fsf@vigenere.g10code.de> <4EE8A9F2.8000208@gmail.com> <877h1xc3c6.fsf@vigenere.g10code.de> Message-ID: <4EEA4C55.5000903@gmail.com> On 15.12.2011 15:32, Werner Koch wrote: > On Wed, 14 Dec 2011 14:51, phcoder at gmail.com said: > >> wasn't there. In any case the issues at hand (modifying const * for >> first patch und misaligned access for the second) can cause a crash or >> misbehaviour. > Yes sure. There is definitley a need to fix that. It seems that until > now everyone used a key right from the start of a properly aligned > buffer. > Or that most of software is undertested on non-x86 and serpent isn't among the most used ones. >> I have it for GRUB. But these patches are small. Since I intend to > Copyright does only care about the text and not about the sematics. Thus > this patch might be a bit too long. > >> remember exact wording now). Alternatively I could put it in GRUB >> first and then there will be no doubt and we avoid administrative >> hassle. > That is a better way. I can easily copy it from other GNU projects. > Please give me some time; https://bugs.g10code.com/gnupg/issue1384 > tracks this. > http://bzr.savannah.gnu.org/lh/grub/trunk/grub/revision/3685 and http://bzr.savannah.gnu.org/lh/grub/trunk/grub/revision/3686 > Thanks, > > Werner > -- Regards Vladimir '?-coder/phcoder' Serbinenko From dshaw at jabberwocky.com Thu Dec 15 23:23:16 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 15 Dec 2011 17:23:16 -0500 Subject: 'xyt.jpg' is not a JPEG file In-Reply-To: <840AB387-AF50-4DE5-A5C4-449B375F83FE@jabberwocky.com> References: <79591E04-24C3-4F26-8E0E-AA76C3CE7D38@gpgtools.org> <840AB387-AF50-4DE5-A5C4-449B375F83FE@jabberwocky.com> Message-ID: <0F91712E-F412-4D6E-BE82-D1887977406B@jabberwocky.com> On Dec 15, 2011, at 12:52 PM, David Shaw wrote: > On Dec 15, 2011, at 11:46 AM, Alex (via GPGTools) wrote: > >> Dear all, >> >> I think one of our users found a bug in GnuPG: >> >> Description: 'xyt.jpg' is not a JPEG file >> Version: 2.0.17 >> URL: http://support.gpgtools.org/discussions/everything/174 >> >> Steps that will reproduce the problem? >> 1. curl -LOs http://support.gpgtools.org/discussions/everything/174/assets/8ba23b7439a1ddd2b81d87daadf16b8c810dd7f4/essai.jpg >> 2. gpg2 --edit-key 123456789ABCDEF >> 3. addphoto essai.jpg > > This is issue 1331 on the tracker. I could have sworn I fixed it. > > Ah, looks like it was fixed on 1.4, but not 2.0. I'm currently setting up a new work box (going to try to use hg-git), and I'll add it to my stuff to do. This is fixed now. Alas, hg-git didn't really work. David From justin at mac.com Fri Dec 16 02:57:23 2011 From: justin at mac.com (Justin C. Walker) Date: Thu, 15 Dec 2011 17:57:23 -0800 Subject: Parallel builds In-Reply-To: <871us7cwpn.fsf@vigenere.g10code.de> References: <52BA4C13-50DA-4EC0-8910-08146D62A5D7@mac.com> <871us7cwpn.fsf@vigenere.g10code.de> Message-ID: On Dec 14, 2011, at 01:46 , Werner Koch wrote: > On Tue, 13 Dec 2011 20:09, justin at mac.com said: > >> Is this a known problem that's been fixed? We're currently using >> version 1.6. I'm not signed up for this project, so I don't know the > > The current version is 1.1.0. Please test again with that one. You mean "1.10", correct? Thanks. Justin -- Justin C. Walker Curmudgeon at Large Director Institute for the Enhancement of the Director's Income -- Build a man a fire and he'll be warm for a night. Set a man on fire and he'll be warm for the rest of his life. From gniibe at fsij.org Fri Dec 16 05:21:50 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 16 Dec 2011 13:21:50 +0900 Subject: pinentry-curses and pinpad entry In-Reply-To: <1323050483.1977.1.camel@latx1.gniibe.org> References: <1323050483.1977.1.camel@latx1.gniibe.org> Message-ID: <1324009310.1949.6.camel@latx1.gniibe.org> On 2011-12-05 at 11:01 +0900, NIIBE Yutaka wrote: > When using pinpad entry, GnuPG invokes pinentry and then kill it. > > It's OK killing pinentry program when it's GUI, but when it runs > on terminal, the terminal remains cbreak an noecho mode. I committed following fix to master branch. diff --git a/agent/call-pinentry.c b/agent/call-pinentry.c index d0cfd2b..36093bb 100644 --- a/agent/call-pinentry.c +++ b/agent/call-pinentry.c @@ -1273,8 +1273,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. */ I believe that this fix is correct, but I think that it would cause a problem on Windows. Can we let pinentry finish by sending SIGINT on Windows? If not, we need to fix pinentry. Could someone please test pinentry on Windows? -- From wk at gnupg.org Fri Dec 16 10:13:29 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 16 Dec 2011 10:13:29 +0100 Subject: Fix few warnings in libgcrypt/cipher In-Reply-To: <4EEA4C55.5000903@gmail.com> ("Vladimir =?utf-8?Q?'=CF=86-cod?= =?utf-8?Q?er=2Fphcoder'?= Serbinenko"'s message of "Thu, 15 Dec 2011 20:36:53 +0100") References: <4EA460A6.6050309@gmail.com> <4EE86641.8050308@gmail.com> <87wr9zb9dx.fsf@vigenere.g10code.de> <4EE8A9F2.8000208@gmail.com> <877h1xc3c6.fsf@vigenere.g10code.de> <4EEA4C55.5000903@gmail.com> Message-ID: <87liqcangm.fsf@vigenere.g10code.de> On Thu, 15 Dec 2011 20:36, phcoder at gmail.com said: > Or that most of software is undertested on non-x86 and serpent isn't > among the most used ones. That reminds me to add a regression test for unaligned keys etc. Before I do a major release I try to build and check it in non-x86. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Dec 16 10:15:11 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 16 Dec 2011 10:15:11 +0100 Subject: Parallel builds In-Reply-To: (Justin C. Walker's message of "Thu, 15 Dec 2011 17:57:23 -0800") References: <52BA4C13-50DA-4EC0-8910-08146D62A5D7@mac.com> <871us7cwpn.fsf@vigenere.g10code.de> Message-ID: <87hb10ands.fsf@vigenere.g10code.de> On Fri, 16 Dec 2011 02:57, justin at mac.com said: > You mean "1.10", correct? Yeah. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Dec 16 10:16:53 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 16 Dec 2011 10:16:53 +0100 Subject: pinentry-curses and pinpad entry In-Reply-To: <1324009310.1949.6.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Fri, 16 Dec 2011 13:21:50 +0900") References: <1323050483.1977.1.camel@latx1.gniibe.org> <1324009310.1949.6.camel@latx1.gniibe.org> Message-ID: <87d3boanay.fsf@vigenere.g10code.de> On Fri, 16 Dec 2011 05:21, gniibe at fsij.org said: > Can we let pinentry finish by sending SIGINT on Windows? If not, we > need to fix pinentry. Under Windows we use TerminateProcess (process, 1); Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From justin at mac.com Sat Dec 17 03:10:47 2011 From: justin at mac.com (Justin C. Walker) Date: Fri, 16 Dec 2011 18:10:47 -0800 Subject: Parallel builds In-Reply-To: <871us7cwpn.fsf@vigenere.g10code.de> References: <52BA4C13-50DA-4EC0-8910-08146D62A5D7@mac.com> <871us7cwpn.fsf@vigenere.g10code.de> Message-ID: <302812C6-1D21-479B-B251-C288E3968548@mac.com> On Dec 14, 2011, at 01:46 , Werner Koch wrote: > On Tue, 13 Dec 2011 20:09, justin at mac.com said: > >> Is this a known problem that's been fixed? We're currently using >> version 1.6. I'm not signed up for this project, so I don't know the > > The current version is 1.1.0. Please test again with that one. Rather than try to figure out the changes to the library, we just replaced "install-sh" with an updated version, which seemed to make the build system happy. At least until we get faster processors with more threads :-} Thanks! Justin -- Justin C. Walker Director Institute for the Enhancement of the Director's Income -- Fame is fleeting, but obscurity just drags on and on. F&E From alex at gpgtools.org Sat Dec 17 15:43:41 2011 From: alex at gpgtools.org (Alex (via GPGTools)) Date: Sat, 17 Dec 2011 15:43:41 +0100 Subject: 'xyt.jpg' is not a JPEG file In-Reply-To: <0F91712E-F412-4D6E-BE82-D1887977406B@jabberwocky.com> References: <79591E04-24C3-4F26-8E0E-AA76C3CE7D38@gpgtools.org> <840AB387-AF50-4DE5-A5C4-449B375F83FE@jabberwocky.com> <0F91712E-F412-4D6E-BE82-D1887977406B@jabberwocky.com> Message-ID: Thanks! On 15.12.2011, at 23:23, David Shaw wrote: > On Dec 15, 2011, at 12:52 PM, David Shaw wrote: > >> On Dec 15, 2011, at 11:46 AM, Alex (via GPGTools) wrote: >> >>> Dear all, >>> >>> I think one of our users found a bug in GnuPG: >>> >>> Description: 'xyt.jpg' is not a JPEG file >>> Version: 2.0.17 >>> URL: http://support.gpgtools.org/discussions/everything/174 >>> >>> Steps that will reproduce the problem? >>> 1. curl -LOs http://support.gpgtools.org/discussions/everything/174/assets/8ba23b7439a1ddd2b81d87daadf16b8c810dd7f4/essai.jpg >>> 2. gpg2 --edit-key 123456789ABCDEF >>> 3. addphoto essai.jpg >> >> This is issue 1331 on the tracker. I could have sworn I fixed it. >> >> Ah, looks like it was fixed on 1.4, but not 2.0. I'm currently setting up a new work box (going to try to use hg-git), and I'll add it to my stuff to do. > > This is fixed now. Alas, hg-git didn't really work. > > David > -- http://gpgtools.org http://gpgtools.org/about (Google+, Twitter, RSS) From gniibe at fsij.org Mon Dec 19 04:59:17 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 19 Dec 2011 12:59:17 +0900 Subject: pinpad entry support in Git repository In-Reply-To: <1322802559.2589.9.camel@latx1.gniibe.org> References: <1322802559.2589.9.camel@latx1.gniibe.org> Message-ID: <1324267157.1983.1.camel@latx1.gniibe.org> On 2011-12-02 at 14:09 +0900, NIIBE Yutaka wrote: > Could you please test it out? > > (1) pinpad input for verify for user > (2) pinpad input for verify for admin > (3) pinpad input for passphrase modification by user > (4) pinpad input for passphrase modification by admin I think that it's better to have some test program testing the feature of card reader, instead of asking test by GnuPG. Thus, I wrote a python script. Attached is a program which tests PIN entry using pinpad of card reader. It requires "Pyscard", smartcard library for python. See http://pyscard.sourceforge.net/ for Pyscard. This test program assumes that OpenPGP card v2 is inserted to it. There are nine cases (if card reader supports all). $ pinpad-test # verify user's PIN " $ pinpad-test --admin # verify admin's PIN " $ pinpad-test --change # change user's PIN " $ pinpad-test --change --admin # change admin's PIN " $ pinpad-test --change2 # change user's PIN by two steps" $ pinpad-test --change2 --admin # change admin's PIN by two steps" $ pinpad-test --unblock # change user's PIN by reset code" $ pinpad-test --unblock --admin # change user's PIN by admin's PIN" $ pinpad-test --put # setup resetcode " Please test your readers, it they come with pinpad. And let me know the result. Thanks in advance. I maintain this script in the Gnuk repository: http://www.gniibe.org/gitweb?p=gnuk.git;a=blob;f=tool/pinpad-test.py -- -------------- next part -------------- A non-text attachment was scrubbed... Name: pinpad-test.py Type: text/x-python Size: 11090 bytes Desc: not available URL: From gniibe at fsij.org Tue Dec 20 04:51:39 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 20 Dec 2011 12:51:39 +0900 Subject: ccid_driver_improvement Message-ID: <1324353099.1921.8.camel@latx1.gniibe.org> Hi, I created ccid_driver_improvement branch on the repository of git.gnupg.org. It's for master branch now, but I think it can be applied to stable branches too. I committed two changes, and tested with Gnuk. commit fb01522af758be19a16337cd7bf86cef21b7b155 Author: NIIBE Yutaka Date: Mon Dec 5 13:57:42 2011 +0900 Support keypad_modify method by ccid-driver. * apdu.c (ccid_keypad_operation): Rename from ccid_keypad_verify. (open_ccid_reader): Use ccid_keypad_operation for verify and modify. * ccid-driver.c (ccid_transceive_secure): Support CHANGE_REFERENCE_DATA: 0x24. commit 37fadead90e985b544c9f817cf7c7b0ada797d3c Author: NIIBE Yutaka Date: Mon Dec 5 12:00:14 2011 +0900 Support extended APDU exchange level somehow. * ccid-driver.c (ccid_transceive_apdu_level): Permit sending packet where apdulen <= 289. Support receiving packets in a chain. Note that Gnuk uses extended APDU exchange level. With these changes, Gnuk will work with in-stock CCID driver of GnuPG. -- From phcoder at gmail.com Tue Dec 20 15:14:46 2011 From: phcoder at gmail.com (=?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=) Date: Tue, 20 Dec 2011 15:14:46 +0100 Subject: Fix few warnings in libgcrypt/cipher In-Reply-To: <87liqcangm.fsf@vigenere.g10code.de> References: <4EA460A6.6050309@gmail.com> <4EE86641.8050308@gmail.com> <87wr9zb9dx.fsf@vigenere.g10code.de> <4EE8A9F2.8000208@gmail.com> <877h1xc3c6.fsf@vigenere.g10code.de> <4EEA4C55.5000903@gmail.com> <87liqcangm.fsf@vigenere.g10code.de> Message-ID: <4EF09856.7030007@gmail.com> On 16.12.2011 10:13, Werner Koch wrote: > On Thu, 15 Dec 2011 20:36, phcoder at gmail.com said: > >> Or that most of software is undertested on non-x86 and serpent isn't >> among the most used ones. > That reminds me to add a regression test for unaligned keys etc. Before > I do a major release I try to build and check it in non-x86. > You could use http://gcc.gnu.org/wiki/CompileFarm > Salam-Shalom, > > Werner > -- Regards Vladimir '?-coder/phcoder' Serbinenko From wk at gnupg.org Tue Dec 20 17:26:49 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Dec 2011 17:26:49 +0100 Subject: GnuPG 2.1 beta 3 released Message-ID: <87fwgf1a5y.fsf@vigenere.g10code.de> Hello! We just released the third *beta version* of GnuPG 2.1. It has been released to give you the opportunity to check out the new features. It is marked as a beta versions and the plan is to release a couple more betas in the next months before we can declare 2.1.0 stable enough for general use. If you need a stable and fully maintained version of GnuPG, you should in general use 2.0.x or even the old 1.4.x. Noteworthy changes in version 2.1.0beta3 ======================================== * Fixed regression in GPG's secret key export function. * Allow generation of card keys up to 4096 bit. * Support the SSH confirm flag. * The Assuan commands KILLAGENT and KILLSCD are working again. * SCdaemon does not anymore block after changing a card (regression fix). * gpg-connect-agent does now proberly display the help output for "SCD HELP" commands. * Preliminary support for the GPGSM validation model "steed". * Improved certificate creation in GPGSM. * New option for GPG_AGENT to select a passphrase mode. The loopback mode may be used to bypass Pinentry. Noteworthy changes already found in beta2: * ECC support for GPG as described by draft-jivsov-openpgp-ecc-06.txt. * New GPGSM feature to create certificates from a parameter file. Add prompt to the --gen-key UI to create self-signed certificates. * Dirmngr has taken over the function of the keyserver helpers. Thus we now have a specified direct interface to keyservers via Dirmngr. LDAP, DNS and mail backends are not yet implemented. * TMPDIR is now also honored when creating a socket using --no-standard-socket and with symcryptrun's temp files. * Fixed a bug where SCdaemon sends a signal to Gpg-agent running in non-daemon mode. * Print "AES128" instead of "AES". This change introduces a little incompatibility for tools using "gpg --list-config". We hope that these tools are written robust enough to accept this new algorithm name as well. * Fixed CRL loading under W32 (bug#1010). * Fixed TTY management for pinentries and session variable update problem. Noteworthy changes already found in beta1: * GPG does not anymore use secring.gpg but delegates all secret key operations to gpg-agent. The import command moves secret keys to the agent. * The OpenPGP import command is now able to merge secret keys. * The G13 tool for disk encryption key management has been added. * If the agent's --use-standard-socket option is active, all tools try to start and daemonize the agent on the fly. In the past this was only supported on W32; on non-W32 systems the new configure option --disable-standard-socket may now be used to disable this new default. * Dirmngr is now a part of this package. Dirmngr is now also expected to run as a system service and the configuration directories are changed to the GnuPG name space. * Removed GPG options: --export-options: export-secret-subkey-passwd --simple-sk-checksum * New GPG options: --try-secret-key * Support DNS lookups for SRV, PKA and CERT on W32. * The default for --include-cert is now to include all certificates in the chain except for the root certificate. * Numerical values may now be used as an alternative to the debug-level keywords. * New GPGSM option --ignore-cert-extension. * Support for Windows CE. * Given sufficient permissions Dirmngr is started automagically. * Bug fixes. Migration from 1.4 or 2.0 to this version ========================================= The major change in 2.1 is that gpg-agent now takes care of the OpenPGP secret keys (those managed by GPG). The former secring.gpg will not be used anymore. Newly generated keys are generated and stored in the agent's key store (~/.gnupg/private-keys-v1.d/). To migrate your existing keys to the agent you should run this command gpg2 --import ~/.gnupg/secring.gpg The agent will you ask for the passphrase of each key. You may use the Cancel button of the Pinentry to skip importing this key. If you want to stop the import process and you use one of the latest pinentries, you should close the pinentry window instead of hitting the cancel button. Secret keys already imported are skipped by the import command. It is advisable to keep the secring.gpg for use with older versions of GPG. Note that gpg-agent now uses a fixed socket by default. All tools will start the gpg-agent as needed. In general there is no more need to set the GPG_AGENT_INFO environment variable. The SSH_AUTH_SOCK environment variable should be set to a fixed value. GPG's smartcard commands --card-edit and --card-status as well as the card related sub-commands of --edit-key are not yet supported. However, signing and decryption with a smartcard does work. The Dirmngr is now part of GnuPG proper. Thus there is no more need to install the separate dirmngr package. The directroy layout of Dirmngr changed to make use of the GnuPG directories; for example you use /etc/gnupg/trusted-certs and /var/lib/gnupg/extra-certs. Dirmngr needs to be started as a system daemon. Getting the Software ==================== GnuPG 2.1 is available at ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0beta3.tar.bz2 ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0beta3.tar.bz2.sig and soon on all mirrors . Note that libgcrypt >= 1.5 and Libassuan >= 2.0.3 are now required; they are available at ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.bz2.sig ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.0.3.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.0.3.tar.bz2.sig Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * You are expected to have a trusted version of GnuPG installed, thus you may simply check the supplied signature. For example to check the signature of the file gnupg-2.1.0beta3.tar.bz2 you would use this command: gpg --verify gnupg-2.1.0beta3.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a key server like gpg --recv-key 4F25E3B6 The distribution key 4F25E3B6 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! Internationalization ==================== This version comes only with support for English and German. More languages will be added for the real release. Documentation ============= We are currently working on an installation guide to explain in more detail how to configure the new features. As of now the chapters on gpg-agent and gpgsm include brief information on how to set up the whole thing. Please watch the GnuPG website for updates of the documentation. In the meantime you may search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Future Plans ============ Some tasks we would like to do before a 2.1 release: * Replace the pubring.gpg public key store with the keybox format. * Re-enable importing keys to a smartcard * Re-enable LDAP, kDNS and mail keyserver methods * Replace Pth by the nPth (already done and tested for GNU/Linux) Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or by donating money. Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. A service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 201 bytes Desc: not available URL: From wk at gnupg.org Tue Dec 20 17:50:55 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Dec 2011 17:50:55 +0100 Subject: Fix few warnings in libgcrypt/cipher In-Reply-To: <4EF09856.7030007@gmail.com> ("Vladimir =?utf-8?Q?'=CF=86-cod?= =?utf-8?Q?er=2Fphcoder'?= Serbinenko"'s message of "Tue, 20 Dec 2011 15:14:46 +0100") References: <4EA460A6.6050309@gmail.com> <4EE86641.8050308@gmail.com> <87wr9zb9dx.fsf@vigenere.g10code.de> <4EE8A9F2.8000208@gmail.com> <877h1xc3c6.fsf@vigenere.g10code.de> <4EEA4C55.5000903@gmail.com> <87liqcangm.fsf@vigenere.g10code.de> <4EF09856.7030007@gmail.com> Message-ID: <8739cf191s.fsf@vigenere.g10code.de> On Tue, 20 Dec 2011 15:14, phcoder at gmail.com said: > You could use http://gcc.gnu.org/wiki/CompileFarm I know and use it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From alphazo at gmail.com Tue Dec 20 18:23:26 2011 From: alphazo at gmail.com (Alphazo) Date: Tue, 20 Dec 2011 18:23:26 +0100 Subject: Unable to compile GnuPG 2.1 beta 3 Message-ID: I'm trying to compile the newly released GnuPG 2.1 beta 3 but it fails. First I had to update my libassuan to 2.0.3 but now I get this: gcc -DHAVE_CONFIG_H -I. -I.. -I../gl -I../intl -I../common -DLOCALEDIR=\"/usr/share/locale\" -DGNUPG_BINDIR="\"/usr/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/lib/gnupg2\"" -DGNUPG_LIBDIR="\"/usr/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/etc/gnupg\"" -DGNUPG_LOCALSTATEDIR="\"/usr/var\"" -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O3 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith -MT dirmngr_ldap-dirmngr_ldap.o -MD -MP -MF .deps/dirmngr_ldap-dirmngr_ldap.Tpo -c -o dirmngr_ldap-dirmngr_ldap.o `test -f 'dirmngr_ldap.c' || echo './'`dirmngr_ldap.c mv -f .deps/dirmngr_ldap-dirmngr_ldap.Tpo .deps/dirmngr_ldap-dirmngr_ldap.Po gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O3 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -o dirmngr_ldap dirmngr_ldap-dirmngr_ldap.o ../common/libcommon.a no-libgcrypt.o ../gl/libgnu.a -lresolv -lgpg-error -lldap /usr/bin/ld: dirmngr_ldap-dirmngr_ldap.o: undefined reference to symbol 'ber_free' /usr/bin/ld: note: 'ber_free' is defined in DSO /usr/lib/liblber-2.4.so.2 so try adding it to the linker command line /usr/lib/liblber-2.4.so.2: could not read symbols: Invalid operation collect2: ld returned 1 exit status make[3]: *** [dirmngr_ldap] Error 1 In the meantime, here are the package I already have installed on my system: - libldap 2.4.28 - curl 7.23.1 - bzip2 1.0.6 - zlib 1.2.5 - libksba 1.2.0 - libgpg-error 1.10 - libgcrypt 1.5.0 - pth 2.0.7 - libusb-compat 0.1.3 - libassuan 2.0.3 - texinfo 4.13a - readline 6.2.002 - pinentry 0.8.1 Do I have one the dependency not up to date for building this beta3? Thanks alphazo From nicholas.cole at gmail.com Tue Dec 20 19:24:16 2011 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 20 Dec 2011 18:24:16 +0000 Subject: GnuPG 2.1 beta 3 released In-Reply-To: <87fwgf1a5y.fsf@vigenere.g10code.de> References: <87fwgf1a5y.fsf@vigenere.g10code.de> Message-ID: On Tue, Dec 20, 2011 at 4:26 PM, Werner Koch wrote: > ?* GPG does not anymore use secring.gpg but delegates all secret key > ? operations to gpg-agent. ?The import command moves secret keys to > ? the agent. > > ?* The OpenPGP import command is now able to merge secret keys. I see that the man page still refers to the option --secret-keyring. Presumably this option now does nothing? Very exciting to see the new release! N From gniibe at fsij.org Wed Dec 21 03:10:56 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 21 Dec 2011 11:10:56 +0900 Subject: ccid_driver_improvement In-Reply-To: <1324353099.1921.8.camel@latx1.gniibe.org> References: <1324353099.1921.8.camel@latx1.gniibe.org> Message-ID: <1324433456.1922.8.camel@latx1.gniibe.org> On 2011-12-20 at 12:51 +0900, NIIBE Yutaka wrote: > commit 37fadead90e985b544c9f817cf7c7b0ada797d3c Let me explain this commit a bit. Note that this is not the patch to fully support extended APDU exchange level communication, but to support most of cases. I think that full support requires to have 64KiB buffer, but for almost all cases for OpenPGP card interaction (I mean, Gnuk), it doesn't require such a big buffer. The maximum case is for handling of Data Object of 0x7f21 ("CERT-3"), This commit doesn't handle this case. I will write another mail about Data Object of 0x7f21 ("CERT-3"). Next maximum case is to store key from host to card. The magic number 289 comes from for 2048-bit key: 7 (header of CCID message) + 22 (Extended header list, kind of key, private key template, tag) + 4 (E : 00 01 00 01) + 128 (P) + 128 (Q) Besides, the commit supports packets in a chain. With these changes, OpenPGP card v2 with extended APDU exchange level communication (== Gnuk) works well (except DO 0x7f21). I paste output of "git show 37fadead90e985b544c9f817cf7c7b0ada797d3c" to ask your review and comment. commit 37fadead90e985b544c9f817cf7c7b0ada797d3c Author: NIIBE Yutaka Date: Mon Dec 5 12:00:14 2011 +0900 Support extended APDU exchange level somehow. * ccid-driver.c (ccid_transceive_apdu_level): Permit sending packet where apdulen <= 289. Support receiving packets in a chain. diff --git a/scd/ccid-driver.c b/scd/ccid-driver.c index 7338ccc..5755b07 100644 --- a/scd/ccid-driver.c +++ b/scd/ccid-driver.c @@ -2590,8 +2590,8 @@ ccid_transceive_apdu_level (ccid_driver_t handle, /* The maximum length for a short APDU T=1 block is 261. For an extended APDU T=1 block the maximum length 65544; however - extended APDU exchange level is not yet supported. */ - if (apdulen > 261) + extended APDU exchange level is not fully supported yet. */ + if (apdulen > 289) return CCID_DRIVER_ERR_INV_VALUE; /* Invalid length. */ msg[0] = PC_to_RDR_XfrBlock; @@ -2614,8 +2614,51 @@ ccid_transceive_apdu_level (ccid_driver_t handle, if (rc) return rc; - apdu = msg + 10; - apdulen = msglen - 10; + if (msg[9] == 1) + { + size_t total_msglen = msglen; + + while (1) + { + unsigned char status; + + msg = recv_buffer + total_msglen; + + msg[0] = PC_to_RDR_XfrBlock; + msg[5] = 0; /* slot */ + msg[6] = seqno = handle->seqno++; + msg[7] = bwi; /* bBWI */ + msg[8] = 0x10; /* Request next data block */ + msg[9] = 0; + set_msg_len (msg, 0); + msglen = 10; + + rc = bulk_out (handle, msg, msglen, 0); + if (rc) + return rc; + + rc = bulk_in (handle, msg, sizeof recv_buffer - total_msglen, &msglen, + RDR_to_PC_DataBlock, seqno, 5000, 0); + if (rc) + return rc; + status = msg[9]; + memmove (msg, msg+10, msglen - 10); + total_msglen += msglen - 10; + if (total_msglen >= sizeof recv_buffer) + return CCID_DRIVER_ERR_OUT_OF_CORE; + + if (status == 0x02) + break; + } + + apdu = recv_buffer + 10; + apdulen = total_msglen - 10; + } + else + { + apdu = msg + 10; + apdulen = msglen - 10; + } if (resp) { -- From gniibe at fsij.org Wed Dec 21 04:24:14 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 21 Dec 2011 12:24:14 +0900 Subject: OpenPGP card specification: Data Object of 0x7f21 ("CERT-3") Message-ID: <1324437854.1922.10.camel@latx1.gniibe.org> Hi, This is my comment for OpenPGP card specification version 2.0, with regard to Data Object 0x7f21, according to my experience of developing Gnuk. In short, Data Object 0x7f21 ("CERT-3") is difficult to support. If I understand correctly, this data object supposed to have X.509 certificate for authentication key "OPENPGP.3". The size of this data object is big, from the viewpoint of smartcard. When I created my certificate with cacert.org, its length is 1328 byte (for my RSA 2048-bit key for authentication). I think that it can be bigger. While other data objects are small enough (< 256 bytes), this data object is exceptionally big. Current of GnuPG for exended APDU level cannot handle such a big data object. This is true for internal ccid driver as well as for PC/SC backend. For ccid driver, it's ccid-driver.c:ccid_transceive_apdu_level, which has smaller buffer. For PC/SC backend it's pcsc-wrapper.c:handle_transmit which has 1024-byte buffer. I wonder to change ccid-driver.c and pcsc-wrapper.c just for the data object 0x7f21. So, I have investigated if there are some use case for this data object. I had thought that it were used by Scute and Poldi, but I couldn't find any use case in the code. In my opinion, it would be better to define EF (elementary file) instead of DO for large data, so that it can be accessed by READ_BINARY and WRITE_BINARY. -- From wk at gnupg.org Wed Dec 21 11:20:31 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Dec 2011 11:20:31 +0100 Subject: Unable to compile GnuPG 2.1 beta 3 In-Reply-To: (alphazo@gmail.com's message of "Tue, 20 Dec 2011 18:23:26 +0100") References: Message-ID: <8762haz0nk.fsf@vigenere.g10code.de> On Tue, 20 Dec 2011 18:23, alphazo at gmail.com said: > /usr/bin/ld: dirmngr_ldap-dirmngr_ldap.o: undefined reference to > symbol 'ber_free' Oh, it is back. I had this problem for while but not the time to look at it. I used ./configure --disable-dirmngr to work around it. Now when I was ready to look at the problem it vanished. Most likely due to an update of my Debian Sid box. I'll try to replicate the problem on another box. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 21 11:26:17 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Dec 2011 11:26:17 +0100 Subject: GnuPG 2.1 beta 3 released In-Reply-To: (Nicholas Cole's message of "Tue, 20 Dec 2011 18:24:16 +0000") References: <87fwgf1a5y.fsf@vigenere.g10code.de> Message-ID: <871uryz0dy.fsf@vigenere.g10code.de> On Tue, 20 Dec 2011 19:24, nicholas.cole at gmail.com said: > I see that the man page still refers to the option --secret-keyring. > Presumably this option now does nothing? Right, it is a NOP. It is still there so you are able to use the same gpg.conf for all versions of GnuPG. I will fix the documentation. > Very exciting to see the new release! I did it mainly to tell that 2.1 development is still alive and also to remind me about 14 years of GnuPG. More seriously this will be the last beta which uses Pth - we need to switch over to nPth[1]. This new library will need some time to build and work correctly on non-GNU/Linux systems. Salam-Shalom, Werner [1] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=npth.git -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sebastien at lorquet.fr Wed Dec 21 10:32:10 2011 From: sebastien at lorquet.fr (=?utf-8?b?U8OpYmFzdGllbg==?= Lorquet) Date: Wed, 21 Dec 2011 10:32:10 +0100 Subject: OpenPGP card specification: Data Object of 0x7f21 ("CERT-3") In-Reply-To: <1324437854.1922.10.camel@latx1.gniibe.org> References: <1324437854.1922.10.camel@latx1.gniibe.org> Message-ID: <20111221103210.Horde.-f__SnfM5mBO8aea8Uk3K7A@www.unsads.com> Hi, On May 18, 2011, Werner told me that: > There won't be a stupid old file system interface. Will you be luckier than me? Regards Sebastien NIIBE Yutaka a ?crit?: > Hi, > > This is my comment for OpenPGP card specification version 2.0, with > regard to Data Object 0x7f21, according to my experience of developing > Gnuk. > > In short, Data Object 0x7f21 ("CERT-3") is difficult to support. > > If I understand correctly, this data object supposed to have X.509 > certificate for authentication key "OPENPGP.3". > > The size of this data object is big, from the viewpoint of smartcard. > When I created my certificate with cacert.org, its length is 1328 byte > (for my RSA 2048-bit key for authentication). I think that it can be > bigger. > > While other data objects are small enough (< 256 bytes), this data > object is exceptionally big. > > Current of GnuPG for exended APDU level cannot handle such a big data > object. This is true for internal ccid driver as well as for PC/SC > backend. > > For ccid driver, it's ccid-driver.c:ccid_transceive_apdu_level, which > has smaller buffer. For PC/SC backend it's > pcsc-wrapper.c:handle_transmit which has 1024-byte buffer. > > I wonder to change ccid-driver.c and pcsc-wrapper.c just for the data > object 0x7f21. So, I have investigated if there are some use case for > this data object. I had thought that it were used by Scute and Poldi, > but I couldn't find any use case in the code. > > In my opinion, it would be better to define EF (elementary file) > instead of DO for large data, so that it can be accessed by > READ_BINARY and WRITE_BINARY. > -- > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From achim at pietig.com Wed Dec 21 09:46:29 2011 From: achim at pietig.com (Achim Pietig) Date: Wed, 21 Dec 2011 09:46:29 +0100 Subject: OpenPGP card specification: Data Object of 0x7f21 ("CERT-3") In-Reply-To: <1324437854.1922.10.camel@latx1.gniibe.org> References: <1324437854.1922.10.camel@latx1.gniibe.org> Message-ID: <4EF19CE5.80608@pietig.com> Hi, data length of 2048 and more are still common in actual smart cards. E. g. the next german health card (eGK v2) comming in 2012 has a requirement of 2048 bytes for sending and 64K for receiving in a single command. Most actual card readers under PC/SC (e. G. SCR 3310/335) have no problems with these data length. If the ccid-driver and the pcsc-wrapper have still such limitations, there is a need to extend them soon! The next version of the OpenPGP card will support even more certificates with these length. I have several requests for even bigger storage, if the I/O buffer of the card hardware is not able to support it, command chaining can be used, maybe I will support this in the next version also. The content of a certificate DO is not limited to X.509, it is possible to store CV-certificates and proprietary formats as well, it depends on the application. I will not support transparent EFs, it's a pre-historic technic ;) Next version of ISO 7816-4 has many extensions for working with DOs (including keys and passwords) and I'm working on a card OS without any EFs. Regards, Achim Am 21.12.2011 04:24, schrieb NIIBE Yutaka: > Hi, > > This is my comment for OpenPGP card specification version 2.0, with > regard to Data Object 0x7f21, according to my experience of developing > Gnuk. > > In short, Data Object 0x7f21 ("CERT-3") is difficult to support. > > If I understand correctly, this data object supposed to have X.509 > certificate for authentication key "OPENPGP.3". > > The size of this data object is big, from the viewpoint of smartcard. > When I created my certificate with cacert.org, its length is 1328 byte > (for my RSA 2048-bit key for authentication). I think that it can be > bigger. > > While other data objects are small enough (< 256 bytes), this data > object is exceptionally big. > > Current of GnuPG for exended APDU level cannot handle such a big data > object. This is true for internal ccid driver as well as for PC/SC > backend. > > For ccid driver, it's ccid-driver.c:ccid_transceive_apdu_level, which > has smaller buffer. For PC/SC backend it's > pcsc-wrapper.c:handle_transmit which has 1024-byte buffer. > > I wonder to change ccid-driver.c and pcsc-wrapper.c just for the data > object 0x7f21. So, I have investigated if there are some use case for > this data object. I had thought that it were used by Scute and Poldi, > but I couldn't find any use case in the code. > > In my opinion, it would be better to define EF (elementary file) > instead of DO for large data, so that it can be accessed by > READ_BINARY and WRITE_BINARY. From wk at gnupg.org Wed Dec 21 13:56:02 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Dec 2011 13:56:02 +0100 Subject: OpenPGP card specification: Data Object of 0x7f21 ("CERT-3") In-Reply-To: <1324437854.1922.10.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Wed, 21 Dec 2011 12:24:14 +0900") References: <1324437854.1922.10.camel@latx1.gniibe.org> Message-ID: <87obv2xevx.fsf@vigenere.g10code.de> On Wed, 21 Dec 2011 04:24, gniibe at fsij.org said: > Current of GnuPG for exended APDU level cannot handle such a big data > object. This is true for internal ccid driver as well as for PC/SC > backend. For the internal driver we can switch to malloced buffers. They were simply not needed with short APDUs. We may want to keep them in the ccid_driver_s struct. We could start with a short buffer and increase it to ~64k if we get a respective error back from the card. In general I would like to limit the allocated memory unless more is needed. That driver is quite usable for embedded systems and there RAM is still a scarce resource. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From alphazo at gmail.com Wed Dec 21 15:19:31 2011 From: alphazo at gmail.com (Alphazo) Date: Wed, 21 Dec 2011 15:19:31 +0100 Subject: Unable to compile GnuPG 2.1 beta 3 In-Reply-To: <8762haz0nk.fsf@vigenere.g10code.de> References: <8762haz0nk.fsf@vigenere.g10code.de> Message-ID: Adding "--disable-dirmngr" did the trick. After installing beta 3 I didn't import my old keychain but rather did a "gpg2 -v --list-keys" that listed keys present in my keychain. However I also received a seg. fault at the end: gpg: signal Segmentation fault caught ... exiting [1] 10610 segmentation fault gpg2 -v --list-keys Is this normal? Thanks Alphazo On Wed, Dec 21, 2011 at 11:20 AM, Werner Koch wrote: > On Tue, 20 Dec 2011 18:23, alphazo at gmail.com said: > >> /usr/bin/ld: dirmngr_ldap-dirmngr_ldap.o: undefined reference to >> symbol 'ber_free' > > Oh, it is back. ?I had this problem for while but not the time to look > at it. ?I used ./configure --disable-dirmngr to work around it. ?Now > when I was ready to look at the problem it vanished. ?Most likely due > to an update of my Debian Sid box. > > I'll try to replicate the problem on another box. > > > Shalom-Salam, > > ? Werner > > -- > Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. > From alphazo at gmail.com Wed Dec 21 15:35:38 2011 From: alphazo at gmail.com (Alphazo) Date: Wed, 21 Dec 2011 15:35:38 +0100 Subject: Migrating from OpenPGP card + gnupg 1.4 to 2.1 Message-ID: I'm testing the latest beta 3 and tried the suggested command to my secring.gpg to 2.1 keyring. Before I explain what I get, here is how my key is setup: - Primary key is a RSA4096 one that I only use to sign my own subkeys and other people's key. The private key material of this key has been removed from this specific machine as I only sign keys offline using a full copy of the key that I keep away from computers. - Subkey 1 is for encryption (RSA) using an OpenPGP card (cryptostick) therefore only a stub is present in the keychain and no private key material - Subkey 2 is for signature (RSA) using an OpenPGP card (cryptostick) therefore only a stub is present in the keychain and no private key material When importing this key I got the pinentry-gtk popup asking for the passphrase for this key but this won't be of any help considering that no private key material is there. What do you recommend to migrate this particular key? I could probably setup a temporary machine to use the full keychain with passphrase then migrate to 2.1 and finally remove the private key material of the primary key (is that possible with 2.1?). Thanks Alphazo From wk at gnupg.org Wed Dec 21 19:03:21 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Dec 2011 19:03:21 +0100 Subject: Unable to compile GnuPG 2.1 beta 3 In-Reply-To: (alphazo@gmail.com's message of "Wed, 21 Dec 2011 15:19:31 +0100") References: <8762haz0nk.fsf@vigenere.g10code.de> Message-ID: <87vcp9x0nq.fsf@vigenere.g10code.de> On Wed, 21 Dec 2011 15:19, alphazo at gmail.com said: > However I also received a seg. fault at the end: > > gpg: signal Segmentation fault caught ... exiting > [1] 10610 segmentation fault gpg2 -v --list-keys > > Is this normal? Definitely no. Segfaults are bugs. Can you run it unter gdb and send a backtrace? gdb gpg2 gdb> run -v --list-keys gdb> # after it stops at the segv gdb> bt full Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Dec 21 19:08:30 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Dec 2011 19:08:30 +0100 Subject: Migrating from OpenPGP card + gnupg 1.4 to 2.1 In-Reply-To: (alphazo@gmail.com's message of "Wed, 21 Dec 2011 15:35:38 +0100") References: Message-ID: <87r4zxx0f5.fsf@vigenere.g10code.de> On Wed, 21 Dec 2011 15:35, alphazo at gmail.com said: > When importing this key I got the pinentry-gtk popup asking for the > passphrase for this key but this won't be of any help considering that > no private key material is there. Are you sure that it ask for the passphrase of the primary key? It should ask for the one of the subkey. In any case, please enter the passphrase of the subkey (which is usually the same as of the primary key). Note, that I have a very similar setup and it worked without problems. It is however possible that we have a regression here. > I could probably setup a temporary machine to use the full keychain > with passphrase then migrate to 2.1 and finally remove the private key > material of the primary key (is that possible with 2.1?). Yes, very easy: gpg2 --with-keygrip -K shows you the keygrip of the keys. Now, simply remove the file ~/.gnupg/private-keys-v1.d/KEYGRIP.key Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From alex at gpgtools.org Wed Dec 21 19:12:51 2011 From: alex at gpgtools.org (Alex (via GPGTools)) Date: Wed, 21 Dec 2011 19:12:51 +0100 Subject: Unable to compile GnuPG 2.1 beta 3 In-Reply-To: References: Message-ID: <49294672-EF29-44B4-8052-BE1CDB217A10@gpgtools.org> By the way (and sorry for highjacking your thread, Alphazo): has anyone successfully compiled GnuPG 2.1b3 on OS X? Best regards, Alex On 20.12.2011, at 18:23, Alphazo wrote: > I'm trying to compile the newly released GnuPG 2.1 beta 3 but it > fails. First I had to update my libassuan to 2.0.3 but now I get this: > > gcc -DHAVE_CONFIG_H -I. -I.. -I../gl -I../intl -I../common > -DLOCALEDIR=\"/usr/share/locale\" -DGNUPG_BINDIR="\"/usr/bin\"" > -DGNUPG_LIBEXECDIR="\"/usr/lib/gnupg2\"" > -DGNUPG_LIBDIR="\"/usr/lib/gnupg\"" > -DGNUPG_DATADIR="\"/usr/share/gnupg\"" > -DGNUPG_SYSCONFDIR="\"/usr/etc/gnupg\"" > -DGNUPG_LOCALSTATEDIR="\"/usr/var\"" -march=x86-64 > -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 > -D_FORTIFY_SOURCE=2 -O3 -Wall -Wcast-align -Wshadow > -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -W > -Wno-sign-compare -Wno-missing-field-initializers > -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith -MT > dirmngr_ldap-dirmngr_ldap.o -MD -MP -MF > .deps/dirmngr_ldap-dirmngr_ldap.Tpo -c -o dirmngr_ldap-dirmngr_ldap.o > `test -f 'dirmngr_ldap.c' || echo './'`dirmngr_ldap.c > mv -f .deps/dirmngr_ldap-dirmngr_ldap.Tpo .deps/dirmngr_ldap-dirmngr_ldap.Po > gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector > --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O3 -Wall -Wcast-align > -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k > -Wformat-security -W -Wno-sign-compare -Wno-missing-field-initializers > -Wdeclaration-after-statement -Wno-pointer-sign -Wpointer-arith > -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -o > dirmngr_ldap dirmngr_ldap-dirmngr_ldap.o ../common/libcommon.a > no-libgcrypt.o ../gl/libgnu.a -lresolv -lgpg-error -lldap > /usr/bin/ld: dirmngr_ldap-dirmngr_ldap.o: undefined reference to > symbol 'ber_free' > /usr/bin/ld: note: 'ber_free' is defined in DSO > /usr/lib/liblber-2.4.so.2 so try adding it to the linker command line > /usr/lib/liblber-2.4.so.2: could not read symbols: Invalid operation > collect2: ld returned 1 exit status > make[3]: *** [dirmngr_ldap] Error 1 > > > In the meantime, here are the package I already have installed on my system: > - libldap 2.4.28 > - curl 7.23.1 > - bzip2 1.0.6 > - zlib 1.2.5 > - libksba 1.2.0 > - libgpg-error 1.10 > - libgcrypt 1.5.0 > - pth 2.0.7 > - libusb-compat 0.1.3 > - libassuan 2.0.3 > - texinfo 4.13a > - readline 6.2.002 > - pinentry 0.8.1 > > Do I have one the dependency not up to date for building this beta3? > > Thanks > alphazo > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -- http://gpgtools.org From alphazo at gmail.com Wed Dec 21 21:36:04 2011 From: alphazo at gmail.com (Alphazo) Date: Wed, 21 Dec 2011 21:36:04 +0100 Subject: Unable to compile GnuPG 2.1 beta 3 In-Reply-To: <87vcp9x0nq.fsf@vigenere.g10code.de> References: <8762haz0nk.fsf@vigenere.g10code.de> <87vcp9x0nq.fsf@vigenere.g10code.de> Message-ID: here is the backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff732e700 in ?? () from /lib/libgcrypt.so.11 (gdb) bt full #0 0x00007ffff732e700 in ?? () from /lib/libgcrypt.so.11 No symbol table info available. #1 0x00007ffff72e6726 in ?? () from /lib/libgcrypt.so.11 No symbol table info available. #2 0x00007ffff72e7bfa in ?? () from /lib/libgcrypt.so.11 No symbol table info available. #3 0x00007ffff72e1ef2 in gcry_sexp_build () from /lib/libgcrypt.so.11 No symbol table info available. #4 0x0000000000425f7a in ?? () No symbol table info available. #5 0x000000000043703f in ?? () No symbol table info available. #6 0x000000000043833d in ?? () No symbol table info available. #7 0x0000000000438867 in ?? () No symbol table info available. #8 0x000000000040b19d in ?? () No symbol table info available. #9 0x00007ffff6b6114d in __libc_start_main () from /lib/libc.so.6 No symbol table info available. #10 0x000000000040c5ed in ?? () No symbol table info available. #11 0x00007fffffffe0b8 in ?? () No symbol table info available. #12 0x00000000ffffffff in ?? () No symbol table info available. #13 0x0000000000000003 in ?? () No symbol table info available. #14 0x00007fffffffe40f in ?? () No symbol table info available. #15 0x00007fffffffe41d in ?? () No symbol table info available. #16 0x00007fffffffe420 in ?? () No symbol table info available. #17 0x0000000000000000 in ?? () No symbol table info available. On Wed, Dec 21, 2011 at 7:03 PM, Werner Koch wrote: > On Wed, 21 Dec 2011 15:19, alphazo at gmail.com said: > >> However I also received a seg. fault at the end: >> >> gpg: signal Segmentation fault caught ... exiting >> [1] ? ?10610 segmentation fault ?gpg2 -v --list-keys >> >> Is this normal? > > Definitely no. ?Segfaults are bugs. ?Can you run it unter gdb and send a > backtrace? > > ?gdb gpg2 > ?gdb> run ?-v --list-keys > ?gdb> # after it stops at the segv > ?gdb> bt full > > > Shalom-Salam, > > ? Werner > > -- > Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. > From alphazo at gmail.com Wed Dec 21 22:38:26 2011 From: alphazo at gmail.com (Alphazo) Date: Wed, 21 Dec 2011 22:38:26 +0100 Subject: Migrating from OpenPGP card + gnupg 1.4 to 2.1 In-Reply-To: <87r4zxx0f5.fsf@vigenere.g10code.de> References: <87r4zxx0f5.fsf@vigenere.g10code.de> Message-ID: You were right on the subkey. In the meantime I realized that the import function was also trying to import old revoked keys as well. That's why I got the password prompt for an old non OpenGPG card based key. Now for testing purposes I cleaned up my secring.gpg by removing all secret keys but one which is the one I described in my previous post. I started the import and didn't get any password prompt but unfortunately also no PIN prompt for my OpenPGP card (?). alpha at fatfly ~/.gnupg % gpg2 --import ~/.gnupg/secring.gpg gpg: key F89A6E41: "Test Key " not changed gpg: key F89A6E41: secret key imported gpg: Total number processed: 4 gpg: unchanged: 1 gpg: secret keys read: 4 Then I looked at my gnugp2 keystore but it remains empty. alpha at fatfly ~/.gnupg % ls private-keys-v1.d alpha at fatfly ~/.gnupg % Is my OpenPGP card stub being checked correctly? Is gpg-agent supposed to work out of the box with OpenPGP card? I then did another test by using a regular key (no OpenPGP card) and got a strange 'can't handle public key algorithm 3" error then a seg. fault when doing a --list-secret-keys. However --edit-key did work fine. (gdb) run -v --list-secret-keys Starting program: /usr/bin/gpg2 -v --list-secret-keys gpg: using PGP trust model gpg: can't handle public key algorithm 3 gpg: subpacket of type 20 has critical bit set Program received signal SIGSEGV, Segmentation fault. 0x00007ffff732e700 in ?? () from /lib/libgcrypt.so.11 #0 0x00007ffff732e700 in ?? () from /lib/libgcrypt.so.11 No symbol table info available. #1 0x00007ffff72e6726 in ?? () from /lib/libgcrypt.so.11 No symbol table info available. #2 0x00007ffff72e7bfa in ?? () from /lib/libgcrypt.so.11 No symbol table info available. #3 0x00007ffff72e1ef2 in gcry_sexp_build () from /lib/libgcrypt.so.11 No symbol table info available. #4 0x000000000042a05b in ?? () No symbol table info available. #5 0x0000000000471e63 in ?? () No symbol table info available. #6 0x00000000004383fc in ?? () No symbol table info available. #7 0x000000000040c120 in ?? () No symbol table info available. #8 0x00007ffff6b6114d in __libc_start_main () from /lib/libc.so.6 No symbol table info available. #9 0x000000000040c5ed in ?? () No symbol table info available. #10 0x00007fffffffe0b8 in ?? () ---Type to continue, or q to quit--- No symbol table info available. #11 0x00000000ffffffff in ?? () No symbol table info available. #12 0x0000000000000003 in ?? () No symbol table info available. #13 0x00007fffffffe408 in ?? () No symbol table info available. #14 0x00007fffffffe416 in ?? () No symbol table info available. #15 0x00007fffffffe419 in ?? () No symbol table info available. #16 0x0000000000000000 in ?? () No symbol table info available. gpg2 -v --edit-key alphazo at gmail.com Secret key is available. gpg: using PGP trust model pub 1024D/242D4DFB created: 2009-08-20 expires: never usage: SC trust: ultimate validity: ultimate sub 2048g/CBF93DD2 created: 2009-08-20 expires: never usage: E [ultimate] (1). Alphazo Alphazo On Wed, Dec 21, 2011 at 7:08 PM, Werner Koch wrote: > On Wed, 21 Dec 2011 15:35, alphazo at gmail.com said: > >> When importing this key I got the pinentry-gtk popup asking for the >> passphrase for this key but this won't be of any help considering that >> no private key material is there. > > Are you sure that it ask for the passphrase of the primary key? ?It > should ask for the one of the subkey. ?In any case, please enter the > passphrase of the subkey (which is usually the same as of the primary > key). ?Note, that I have a very similar setup and it worked without > problems. ?It is however possible that we have a regression here. > >> I could probably setup a temporary machine to use the full keychain >> with passphrase then migrate to 2.1 and finally remove the private key >> material of the primary key (is that possible with 2.1?). > > Yes, very easy: > > ?gpg2 --with-keygrip -K > > shows you the keygrip of the keys. ?Now, simply remove the file > ~/.gnupg/private-keys-v1.d/KEYGRIP.key > > > Salam-Shalom, > > ? Werner > > -- > Die Gedanken sind frei. ?Ausnahmen regelt ein Bundesgesetz. > From gniibe at fsij.org Thu Dec 22 03:03:52 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 22 Dec 2011 11:03:52 +0900 Subject: OpenPGP card specification: Data Object of 0x7f21 ("CERT-3") In-Reply-To: <87obv2xevx.fsf@vigenere.g10code.de> References: <1324437854.1922.10.camel@latx1.gniibe.org> <87obv2xevx.fsf@vigenere.g10code.de> Message-ID: <1324519431.2667.4.camel@latx1.gniibe.org> On 2011-12-21 at 13:56 +0100, Werner Koch wrote: > For the internal driver we can switch to malloced buffers. They were > simply not needed with short APDUs. We may want to keep them in the > ccid_driver_s struct. We could start with a short buffer and increase > it to ~64k if we get a respective error back from the card. I see. For OpenPGP card, we could use the value in the extended capabilities for max length of response data (I don't see any general scheme for allocation of buffer). My question is: Is it worth to do such a change just only for 7f21? I assume that there is no real use of 7f21. -- From nicholas.cole at gmail.com Fri Dec 23 19:29:09 2011 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 23 Dec 2011 18:29:09 +0000 Subject: GnuPG 2.1 beta 3 released In-Reply-To: <87fwgf1a5y.fsf@vigenere.g10code.de> References: <87fwgf1a5y.fsf@vigenere.g10code.de> Message-ID: > ?* GPG does not anymore use secring.gpg but delegates all secret key > ? operations to gpg-agent. ?The import command moves secret keys to > ? the agent. How will this interact with the --homedir option? Will --homedir be passed to gpg-agent or are the two entirely separate? I ask because at the moment it is possible to keep separate keyrings in different home directories, which might be useful to (for example) keep the large debian keyrings separate from personal keys, or to keep a set of keys for testing purposes separate from production keys. Best wishes, Nicholas From wk at gnupg.org Fri Dec 23 20:59:14 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 23 Dec 2011 20:59:14 +0100 Subject: GnuPG 2.1 beta 3 released In-Reply-To: (Nicholas Cole's message of "Fri, 23 Dec 2011 18:29:09 +0000") References: <87fwgf1a5y.fsf@vigenere.g10code.de> Message-ID: <87k45nrre5.fsf@vigenere.g10code.de> On Fri, 23 Dec 2011 19:29, nicholas.cole at gmail.com said: > How will this interact with the --homedir option? Will --homedir be > passed to gpg-agent or are the two entirely separate? No it won't. The gpg-agent has its own --homedir option which allows to have a flexible configuration. By design the gpg-agent may even running on a different box. However that is currently not supported. > I ask because at the moment it is possible to keep separate keyrings > in different home directories, which might be useful to (for example) > keep the large debian keyrings separate from personal keys, or to keep > a set of keys for testing purposes separate from production keys. gpg --homedir is still used of the public keyrings. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From greve at fsfeurope.org Fri Dec 23 23:10:07 2011 From: greve at fsfeurope.org (Georg C. F. Greve) Date: Fri, 23 Dec 2011 23:10:07 +0100 Subject: Issues with smart card since update to FC16 Message-ID: <1404432.czf0Cb0YsG@katana.lair> Hi all, I've been using the Fellowship smart card for years under Debian and Fedora, up until updating to Fedora 16. Ever since I keep having issues that are, well, odd. Take the following instructions of pinentry-qt4 upon trying to decrypt an email in Kontact (screenshot attached). This is the gpg --card-status output for the very same card: Application ID ...: D2760001240101010001000003500000 Version ..........: 1.1 Manufacturer .....: PPC Card Systems Serial number ....: 00000350 Name of cardholder: Georg C.F. Greve Language prefs ...: ende Sex ..............: male URL of public key : http://gnuhh.org/greve-public.asc Login data .......: greve Private DO 1 .....: [not set] Private DO 2 .....: [7] Georg C. F. Greve CA fingerprint 1 .: C485 A6CD 7EC6 6E9E EC33 65F2 70F2 75E4 C32F 6CA5 Signature PIN ....: not forced Key attributes ...: 1024R 1024R 1024R Max. PIN lengths .: 254 254 254 PIN retry counter : 3 0 3 Signature counter : 48318 Signature key ....: E2E7 DABF 1B6D 948E A55E 07B4 293D B14C B7DB 041C created ....: 2005-05-02 11:35:48 Encryption key....: ECDA 0869 1DCE 2C60 C265 281D F953 D01F 7DF1 6B24 created ....: 2005-05-02 11:36:44 Authentication key: DF41 4ED5 A2C5 42D7 BF92 67D1 4742 F5AD 5378 AB47 created ....: 2005-05-02 11:37:16 General key info..: pub 1024R/B7DB041C 2005-05-02 Georg C. F. Greve (Kolab Systems AG, CEO) sec# 1024D/86574ACA created: 1999-02-20 expires: never ssb> 1024R/B7DB041C created: 2005-05-02 expires: never card-no: 0001 00000350 ssb> 1024R/7DF16B24 created: 2005-05-02 expires: never card-no: 0001 00000350 ssb> 1024R/5378AB47 created: 2005-05-02 expires: never card-no: 0001 00000350 When trying to decrypt a file on the command line, I get: gpg: anonymous recipient; trying secret key C3C6A26D ... gpg: protection algorithm 1 (IDEA) is not supported gpg: the IDEA cipher plugin is not present gpg: please see http://www.gnupg.org/faq/why-not-idea.html for more information gpg: anonymous recipient; trying secret key 7487FC5D ... gpg: anonymous recipient; trying secret key A1783953 ... gpg: anonymous recipient; trying secret key B7DB041C ... gpg: fingerprint on card does not match requested one gpg: anonymous recipient; trying secret key 7DF16B24 ... Please enter the PIN gpg: verify CHV2 failed: invalid passphrase gpg: anonymous recipient; trying secret key 5378AB47 ... gpg: fingerprint on card does not match requested one gpg: encrypted with RSA key, ID 00000000 gpg: encrypted with ELG-E key, ID 00000000 gpg: decryption failed: secret key not available when entering the correct PIN. Trying to ssh into another machine does not even attempt smart card authentication, which I guess may have to do with my running the agent without scdaemon support, via: --disable-scdaemon --pinentry-program /usr/bin/pinentry-qt4 --enable-ssh- support --daemon --sh --write-env-file=/home/greve/.gpg-agent-info So I guess the key should be listed in .gnupg/sshcontrol, which it is not. But then, ssh-add -l, which I guess should add it, tells me: The agent has no identities. The environment variables in the session look okay, I guess: declare -x GPG_AGENT_INFO="/home/greve/.gnupg/S.gpg-agent:1750:1" declare -x SSH_AGENT_PID="1750" declare -x SSH_ASKPASS="/usr/libexec/openssh/gnome-ssh-askpass" declare -x SSH_AUTH_SOCK="/home/greve/.gnupg/S.gpg-agent.ssh" and the pinentry dialogue pops up as expected. So what's going on? Did something change to which I should have adapted my setup when upgrading to FC 16? Or is this an issue with the new kernel series? Or something else? Pointers appreciated. Best regards, Georg -- Georg C. F. Greve Member of the General Assembly http://fsfe.org/about/greve/ http://blogs.fsfe.org/greve/ http://identi.ca/greve -------------- next part -------------- A non-text attachment was scrubbed... Name: agent.png Type: image/png Size: 15901 bytes Desc: not available URL: From gniibe at fsij.org Sat Dec 24 01:41:04 2011 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 24 Dec 2011 09:41:04 +0900 Subject: OpenPGP card specification: Data Object of 0x7f21 ("CERT-3") In-Reply-To: <4EF19CE5.80608@pietig.com> References: <1324437854.1922.10.camel@latx1.gniibe.org> <4EF19CE5.80608@pietig.com> Message-ID: <1324687264.1992.3.camel@latx1.gniibe.org> On 2011-12-21 at 09:46 +0100, Achim Pietig wrote: > data length of 2048 and more are still common in actual smart cards. > E. g. the next german health card (eGK v2) comming in 2012 has a > requirement of 2048 bytes for sending and 64K for receiving in a > single command. Most actual card readers under PC/SC (e. G. SCR > 3310/335) have no problems with these data length. Thanks for your comment. Your comment gives me an opportunity to think about communication between host PC, card reader, and card. For implementation of Token, I thought that it would be good to support extended APDU level exchange (only), from the view point of for host PC software. But I think that it might not be better way, because the world is not only for Token, but card reader + card is common. For me, command chaining and/or GET RESPONSE looked quite awkward way of communication at application level. I thought that it's much simpler using lower level way to handle merging packets by extended APDU level exchange. If there were only tokens in the world (I mean, no card reader + card combination), it would be. However, considering card reader + card combination, it is not the "application level" sometimes, but communication between card reader and card. > If the ccid-driver and the pcsc-wrapper have still such limitations, > there is a need to extend them soon! The limitations are only valid for extended APDU level exchange. > The next version of the OpenPGP card will support even more > certificates with these length. [...] > I will not support transparent EFs, it's a pre-historic technic ;) In the current standard of ISO 7816, DO handling just supports data as a whole. While it might be questionable using EF, READ BINARY or WRITE BINARY supports partial data access on the card using offset. That's the reason, I said using EF might be better for big data. But, it's not that such big in fact, 8KiB at maximum. So, I wonder if I will support some big data (such as trust db and public keyring) on Token in the way of ISO 7816, or another way. For token implementation, it is possible, say, to support USB Mass Storage Class, which might be better for big data. Thanks again for your valuable input. -- From nicholas.cole at gmail.com Sun Dec 25 19:00:58 2011 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sun, 25 Dec 2011 18:00:58 +0000 Subject: GnuPG 2.1 beta 3 released In-Reply-To: <87k45nrre5.fsf@vigenere.g10code.de> References: <87fwgf1a5y.fsf@vigenere.g10code.de> <87k45nrre5.fsf@vigenere.g10code.de> Message-ID: On Friday, December 23, 2011, Werner Koch wrote: > On Fri, 23 Dec 2011 19:29, nicholas.cole at gmail.com said: > >> How will this interact with the --homedir option? Will --homedir be >> passed to gpg-agent or are the two entirely separate? > > No it won't. The gpg-agent has its own --homedir option which allows to > have a flexible configuration. By design the gpg-agent may even running > on a different box. However that is currently not supported. > >> I ask because at the moment it is possible to keep separate keyrings >> in different home directories, which might be useful to (for example) >> keep the large debian keyrings separate from personal keys, or to keep >> a set of keys for testing purposes separate from production keys. > > gpg --homedir is still used of the public keyrings. Dear Werner, It would be very good if there were still a way to completely 'sandox' (for want of a better term) an instance of gpg, so that it uses its own key rings and trust databases. I certainly find that for testing purposes it is very useful indeed. On previous versions --homedir does this nicely. I presume the new way will be to make sure that a separate copy of gpg-agent is running and to pass in GPG_AGENT_INFO as an environment variable, as well as specifying a --homedir. Or will there be a better way? Best wishes, Nicholas -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Dec 26 14:42:26 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Dec 2011 14:42:26 +0100 Subject: GnuPG 2.1 beta 3 released In-Reply-To: (Nicholas Cole's message of "Sun, 25 Dec 2011 18:00:58 +0000") References: <87fwgf1a5y.fsf@vigenere.g10code.de> <87k45nrre5.fsf@vigenere.g10code.de> Message-ID: <87sjk7qwjh.fsf@vigenere.g10code.de> On Sun, 25 Dec 2011 19:00, nicholas.cole at gmail.com said: > It would be very good if there were still a way to completely 'sandox' (for > want of a better term) an instance of gpg, so that it uses its own key > rings and trust databases. I certainly find that for testing purposes it > is very useful indeed. On previous versions --homedir does this nicely. A easy way to do this is: GNUPGHOME=/foo/bar gpg-agent --daemon sh and then do whatever you want in this shell. If you are done run give an exit and with a few seconds that gpg-agent will be terminated. That is how I do almost all tests. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From vivarto at gmail.com Mon Dec 26 21:42:25 2011 From: vivarto at gmail.com (Veet Vivarto) Date: Tue, 27 Dec 2011 04:42:25 +0800 Subject: GnuPG 2.1 beta 3 released In-Reply-To: <87sjk7qwjh.fsf@vigenere.g10code.de> References: <87fwgf1a5y.fsf@vigenere.g10code.de> <87k45nrre5.fsf@vigenere.g10code.de> <87sjk7qwjh.fsf@vigenere.g10code.de> Message-ID: Perhaps you find this relevant. I don't even begin to see why you are interested in this. But who knows. On Mon, Dec 26, 2011 at 9:42 PM, Werner Koch wrote: > On Sun, 25 Dec 2011 19:00, nicholas.cole at gmail.com said: > > > It would be very good if there were still a way to completely 'sandox' > (for > > want of a better term) an instance of gpg, so that it uses its own key > > rings and trust databases. I certainly find that for testing purposes it > > is very useful indeed. On previous versions --homedir does this nicely. > > A easy way to do this is: > > GNUPGHOME=/foo/bar gpg-agent --daemon sh > > and then do whatever you want in this shell. If you are done run give > an exit and with a few seconds that gpg-agent will be terminated. That > is how I do almost all tests. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivarto at gmail.com Mon Dec 26 22:02:20 2011 From: vivarto at gmail.com (Veet Vivarto) Date: Tue, 27 Dec 2011 05:02:20 +0800 Subject: GnuPG 2.1 beta 3 released In-Reply-To: References: <87fwgf1a5y.fsf@vigenere.g10code.de> <87k45nrre5.fsf@vigenere.g10code.de> <87sjk7qwjh.fsf@vigenere.g10code.de> Message-ID: sorry my previous message was sent in error. Please disregard. Thank you. On Tue, Dec 27, 2011 at 4:42 AM, Veet Vivarto wrote: > Perhaps you find this relevant. I don't even begin to see why you are > interested in this. But who knows. > > On Mon, Dec 26, 2011 at 9:42 PM, Werner Koch wrote: > >> On Sun, 25 Dec 2011 19:00, nicholas.cole at gmail.com said: >> >> > It would be very good if there were still a way to completely 'sandox' >> (for >> > want of a better term) an instance of gpg, so that it uses its own key >> > rings and trust databases. I certainly find that for testing purposes >> it >> > is very useful indeed. On previous versions --homedir does this nicely. >> >> A easy way to do this is: >> >> GNUPGHOME=/foo/bar gpg-agent --daemon sh >> >> and then do whatever you want in this shell. If you are done run give >> an exit and with a few seconds that gpg-agent will be terminated. That >> is how I do almost all tests. >> >> >> Salam-Shalom, >> >> Werner >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> >> >> _______________________________________________ >> Gnupg-devel mailing list >> Gnupg-devel at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-devel >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at gpgtools.org Mon Dec 26 23:02:30 2011 From: alex at gpgtools.org (Alex (via GPGTools)) Date: Mon, 26 Dec 2011 23:02:30 +0100 Subject: "key not found on keyserver" error message to stdout Message-ID: <27013B18-7928-4C26-ABE0-42A37EA90742@gpgtools.org> Dear all, just another small bug report: Description: "key not found on keyserver" error message to stdout Version: 2.0.17 Steps that will reproduce the problem? 1. enable "auto-key-retrieve" 2. disable your internet connection 3. let gpg download the pubkey What is the expected result? "gpgkeys: key XXX not found on keyserver" to stderr What happens instead? "gpgkeys: key XXX not found on keyserver" to stdout Possible workaround: - Any additional information: http://gpgtools.lighthouseapp.com/projects/73378/tickets/15 Best regards, Alex -- http://gpgtools.org http://gpgtools.org/about (Google+, Twitter, RSS) From wk at gnupg.org Tue Dec 27 16:07:29 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Dec 2011 16:07:29 +0100 Subject: "key not found on keyserver" error message to stdout In-Reply-To: <27013B18-7928-4C26-ABE0-42A37EA90742@gpgtools.org> (alex@gpgtools.org's message of "Mon, 26 Dec 2011 23:02:30 +0100") References: <27013B18-7928-4C26-ABE0-42A37EA90742@gpgtools.org> Message-ID: <8739c6qci6.fsf@vigenere.g10code.de> On Mon, 26 Dec 2011 23:02, alex at gpgtools.org said: > Description: "key not found on keyserver" error message to stdout > Version: 2.0.17 2.0.17 is not the current version. Anyway, that code did not change for years. > What is the expected result? > "gpgkeys: key XXX not found on keyserver" to stderr > > What happens instead? > "gpgkeys: key XXX not found on keyserver" to stdout Please show exactly how you tested that. What OS etc. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.