From nicholas.cole at gmail.com Mon Jun 1 16:02:54 2009 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Mon, 1 Jun 2009 15:02:54 +0100 Subject: RSA+RSA is now the default In-Reply-To: <87ab51y5ed.fsf@wheatstone.g10code.de> References: <87zldcszvb.fsf@wheatstone.g10code.de> <87ab51y5ed.fsf@wheatstone.g10code.de> Message-ID: On Mon, May 25, 2009 at 9:04 AM, Werner Koch wrote: > On Sat, 23 May 2009 21:51, nicholas.cole at gmail.com said: > >> Will the order of the add sub key menu of algorithms also change? > > Yes, I changed them so that they are imho grouped in a more logically > way. Is there any way that the list of algorithms could be available in the --status-fd output (ie. for when --no-tty has to be used or no terminal is present?) Best wishes, Nicholas From dshaw at jabberwocky.com Thu Jun 4 14:52:06 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 4 Jun 2009 08:52:06 -0400 Subject: Camellia for OpenPGP RFC published Message-ID: A new Request for Comments is now available in online RFC libraries. RFC 5581 Title: The Camellia Cipher in OpenPGP Author: D. Shaw Status: Informational Date: June 2009 Mailbox: dshaw at jabberwocky.com Pages: 3 Characters: 5129 Updates: RFC4880 I-D Tag: draft-ietf-openpgp-camellia-04.txt URL: http://www.rfc-editor.org/rfc/rfc5581.txt This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. From wk at gnupg.org Thu Jun 4 15:20:29 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 04 Jun 2009 15:20:29 +0200 Subject: Camellia for OpenPGP RFC published In-Reply-To: (David Shaw's message of "Thu, 4 Jun 2009 08:52:06 -0400") References: Message-ID: <87eiu0dtk2.fsf@wheatstone.g10code.de> On Thu, 4 Jun 2009 14:52, dshaw at jabberwocky.com said: > RFC 5581 > > Title: The Camellia Cipher in OpenPGP It seems we can now remove camellia out of the experimental-do-no-use state. Our Japanese friends will be glad to hear that. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Thu Jun 4 16:06:08 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 4 Jun 2009 10:06:08 -0400 Subject: Camellia for OpenPGP RFC published In-Reply-To: <87eiu0dtk2.fsf@wheatstone.g10code.de> References: <87eiu0dtk2.fsf@wheatstone.g10code.de> Message-ID: <3D6619CB-E6A8-4866-8550-9F30BB11E531@jabberwocky.com> On Jun 4, 2009, at 9:20 AM, Werner Koch wrote: > On Thu, 4 Jun 2009 14:52, dshaw at jabberwocky.com said: > >> RFC 5581 >> >> Title: The Camellia Cipher in OpenPGP > > It seems we can now remove camellia out of the experimental-do-no-use > state. Our Japanese friends will be glad to hear that. I'd feel much better if there was more than one implementation done for Camellia, just to prove there isn't some error somewhere. The PGP folks mentioned they would likely support Camellia eventually, but it's not there to test with yet. Maybe I'll quickly put some Camellia support into openpgpsdk just to prove interoperability. David From wk at gnupg.org Thu Jun 4 17:29:33 2009 From: wk at gnupg.org (Werner Koch) Date: Thu, 04 Jun 2009 17:29:33 +0200 Subject: Camellia for OpenPGP RFC published In-Reply-To: <3D6619CB-E6A8-4866-8550-9F30BB11E531@jabberwocky.com> (David Shaw's message of "Thu, 4 Jun 2009 10:06:08 -0400") References: <87eiu0dtk2.fsf@wheatstone.g10code.de> <3D6619CB-E6A8-4866-8550-9F30BB11E531@jabberwocky.com> Message-ID: <877hzsdnky.fsf@wheatstone.g10code.de> On Thu, 4 Jun 2009 16:06, dshaw at jabberwocky.com said: > it's not there to test with yet. Maybe I'll quickly put some Camellia > support into openpgpsdk just to prove interoperability. It would be better if someone else could do that to avoid the same coding behavior. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Thu Jun 4 20:39:13 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 4 Jun 2009 14:39:13 -0400 Subject: Camellia for OpenPGP RFC published In-Reply-To: <877hzsdnky.fsf@wheatstone.g10code.de> References: <87eiu0dtk2.fsf@wheatstone.g10code.de> <3D6619CB-E6A8-4866-8550-9F30BB11E531@jabberwocky.com> <877hzsdnky.fsf@wheatstone.g10code.de> Message-ID: <967638D4-6195-4853-89BC-011DC0AC577E@jabberwocky.com> On Jun 4, 2009, at 11:29 AM, Werner Koch wrote: > On Thu, 4 Jun 2009 16:06, dshaw at jabberwocky.com said: > >> it's not there to test with yet. Maybe I'll quickly put some >> Camellia >> support into openpgpsdk just to prove interoperability. > > It would be better if someone else could do that to avoid the same > coding behavior. Adding an algorithm to openpgpsdk doesn't actually involve coding all that much. It uses OpenSSL for its crypto, so adding Camellia basically involves passing a pointer to the Camellia_set_key(), Camellia_encrypt(), etc, functions within OpenSSL. Even so, anyone want to give it a whirl? It should take you less than 30 minutes (I've done it already - it's trivial, and not much more than copying the AES section and doing a search and replace to swap "AES" for "Camellia"). The only real gotcha is that openpgpsdk doesn't support Elgamal, so you'll need to make an RSA key to test with. David From dshaw at jabberwocky.com Fri Jun 5 05:03:30 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 4 Jun 2009 23:03:30 -0400 Subject: Camellia for OpenPGP RFC published In-Reply-To: <87eiu0dtk2.fsf@wheatstone.g10code.de> References: <87eiu0dtk2.fsf@wheatstone.g10code.de> Message-ID: <33269F33-9265-473A-A508-4C5ED27B925F@jabberwocky.com> On Jun 4, 2009, at 9:20 AM, Werner Koch wrote: > On Thu, 4 Jun 2009 14:52, dshaw at jabberwocky.com said: > >> RFC 5581 >> >> Title: The Camellia Cipher in OpenPGP > > It seems we can now remove camellia out of the experimental-do-no-use > state. Our Japanese friends will be glad to hear that. I did this for gpg1, and started on this for gpg2, but there is a bit of a headache hiding there: libgcrypt uses 310-312 for the Camellia algorithm numbers and OpenPGP uses 11-13, so every call to gcry_cipher_* needs to call map_cipher_openpgp_to_gcry to sanitize the algorithm numbers before passing them to libgcrypt. At the moment, almost none of them do, so any use of Camellia causes libgcrypt to abort with "Ohhhh jeeee: cipher 11 not found". I'm thinking of making a macro to simplify this. There are a good number of places it happens. David From jmoore3rd at bellsouth.net Fri Jun 5 05:48:36 2009 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Thu, 04 Jun 2009 23:48:36 -0400 Subject: Camellia for OpenPGP RFC published In-Reply-To: <33269F33-9265-473A-A508-4C5ED27B925F@jabberwocky.com> References: <87eiu0dtk2.fsf@wheatstone.g10code.de> <33269F33-9265-473A-A508-4C5ED27B925F@jabberwocky.com> Message-ID: <4A289594.70207@bellsouth.net> David Shaw wrote: > On Jun 4, 2009, at 9:20 AM, Werner Koch wrote: > >> On Thu, 4 Jun 2009 14:52, dshaw at jabberwocky.com said: >> >>> RFC 5581 >>> >>> Title: The Camellia Cipher in OpenPGP >> >> It seems we can now remove camellia out of the experimental-do-no-use >> state. Our Japanese friends will be glad to hear that. > > I did this for gpg1 Does this mean that --enable-Camellia will be included by default and no longer necessary to include during Build? JOHN ;) Timestamp: Thursday 04 Jun 2009, 23:48 --400 (Eastern Daylight Time) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 654 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Fri Jun 5 06:56:38 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 5 Jun 2009 00:56:38 -0400 Subject: Camellia for OpenPGP RFC published In-Reply-To: <4A289594.70207@bellsouth.net> References: <87eiu0dtk2.fsf@wheatstone.g10code.de> <33269F33-9265-473A-A508-4C5ED27B925F@jabberwocky.com> <4A289594.70207@bellsouth.net> Message-ID: On Jun 4, 2009, at 11:48 PM, John W. Moore III wrote: > David Shaw wrote: >> On Jun 4, 2009, at 9:20 AM, Werner Koch wrote: >> >>> On Thu, 4 Jun 2009 14:52, dshaw at jabberwocky.com said: >>> >>>> RFC 5581 >>>> >>>> Title: The Camellia Cipher in OpenPGP >>> >>> It seems we can now remove camellia out of the experimental-do-no- >>> use >>> state. Our Japanese friends will be glad to hear that. >> >> I did this for gpg1 > > Does this mean that --enable-Camellia will be included by default > and no > longer necessary to include during Build? It will mean that fairly soon, yes. David From John at Mozilla-Enigmail.org Fri Jun 5 07:20:21 2009 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Fri, 05 Jun 2009 00:20:21 -0500 Subject: Camellia for OpenPGP RFC published In-Reply-To: References: <87eiu0dtk2.fsf@wheatstone.g10code.de> <33269F33-9265-473A-A508-4C5ED27B925F@jabberwocky.com> <4A289594.70207@bellsouth.net> Message-ID: <4A28AB15.4080805@Mozilla-Enigmail.org> David Shaw wrote: > On Jun 4, 2009, at 11:48 PM, John W. Moore III wrote: >> David Shaw wrote: >>> I did this for gpg1 >> >> Does this mean that --enable-Camellia will be included by default >> and no longer necessary to include during Build? > > It will mean that fairly soon, yes. Cool. I can disable my patch that disables the warning. :-} -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 678 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Fri Jun 5 08:39:24 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Jun 2009 08:39:24 +0200 Subject: Camellia for OpenPGP RFC published In-Reply-To: <33269F33-9265-473A-A508-4C5ED27B925F@jabberwocky.com> (David Shaw's message of "Thu, 4 Jun 2009 23:03:30 -0400") References: <87eiu0dtk2.fsf@wheatstone.g10code.de> <33269F33-9265-473A-A508-4C5ED27B925F@jabberwocky.com> Message-ID: <871vpzdw0z.fsf@wheatstone.g10code.de> On Fri, 5 Jun 2009 05:03, dshaw at jabberwocky.com said: > of a headache hiding there: libgcrypt uses 310-312 for the Camellia > algorithm numbers and OpenPGP uses 11-13, so every call to That is becuase Libgcrypt offically supports Camellia longer than OpenPGP and to not mess up things Libgcrypt uses algorithm numbers > 255 if they don't map directly to the nu7mbers used by OpenPGP. > gcry_cipher_* needs to call map_cipher_openpgp_to_gcry to sanitize the > algorithm numbers before passing them to libgcrypt. At the moment, Yeah, I implemented that a year ago with the idea to do the mapping while parsing and building OpenPGP messages. As you noticed, it is not complete yet. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Fri Jun 5 10:43:19 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 05 Jun 2009 10:43:19 +0200 Subject: Camellia for OpenPGP RFC published In-Reply-To: <871vpzdw0z.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri, 05 Jun 2009 08:39:24 +0200") References: <87eiu0dtk2.fsf@wheatstone.g10code.de> <33269F33-9265-473A-A508-4C5ED27B925F@jabberwocky.com> <871vpzdw0z.fsf@wheatstone.g10code.de> Message-ID: <87ws7rqdeg.fsf@mocca.josefsson.org> Werner Koch writes: > On Fri, 5 Jun 2009 05:03, dshaw at jabberwocky.com said: > >> of a headache hiding there: libgcrypt uses 310-312 for the Camellia >> algorithm numbers and OpenPGP uses 11-13, so every call to > > That is becuase Libgcrypt offically supports Camellia longer than > OpenPGP and to not mess up things Libgcrypt uses algorithm numbers > 255 > if they don't map directly to the nu7mbers used by OpenPGP. Couldn't libgcrypt just map 11-13 to 310-312 internally now that the RFC is published? Sounds simpler than adding a mapping macro. /Simon From wk at gnupg.org Fri Jun 5 11:50:41 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Jun 2009 11:50:41 +0200 Subject: Camellia for OpenPGP RFC published In-Reply-To: <87ws7rqdeg.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 05 Jun 2009 10:43:19 +0200") References: <87eiu0dtk2.fsf@wheatstone.g10code.de> <33269F33-9265-473A-A508-4C5ED27B925F@jabberwocky.com> <871vpzdw0z.fsf@wheatstone.g10code.de> <87ws7rqdeg.fsf@mocca.josefsson.org> Message-ID: <87prdjau1a.fsf@wheatstone.g10code.de> On Fri, 5 Jun 2009 10:43, simon at josefsson.org said: > Couldn't libgcrypt just map 11-13 to 310-312 internally now that the RFC > is published? Sounds simpler than adding a mapping macro. Libgcrypt and GnuPG are independent; it is purely coincidence that some algorithm IDs match the OpenPGP specs ;-). Adding an alias would lead to surprises like in: id2name(name2id(id2name(N))) != N Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Fri Jun 5 17:07:47 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 5 Jun 2009 11:07:47 -0400 Subject: Camellia for OpenPGP RFC published In-Reply-To: <4A28AB15.4080805@Mozilla-Enigmail.org> References: <87eiu0dtk2.fsf@wheatstone.g10code.de> <33269F33-9265-473A-A508-4C5ED27B925F@jabberwocky.com> <4A289594.70207@bellsouth.net> <4A28AB15.4080805@Mozilla-Enigmail.org> Message-ID: <66B00649-F42C-4A5B-9947-7007B55238F5@jabberwocky.com> On Jun 5, 2009, at 1:20 AM, John Clizbe wrote: > David Shaw wrote: >> On Jun 4, 2009, at 11:48 PM, John W. Moore III wrote: >>> David Shaw wrote: >>>> I did this for gpg1 >>> >>> Does this mean that --enable-Camellia will be included by default >>> and no longer necessary to include during Build? >> >> It will mean that fairly soon, yes. > > Cool. I can disable my patch that disables the warning. :-} Yes. You aimed the gun at your foot, pulled the trigger... and found out it wasn't loaded. ;) David From dshaw at jabberwocky.com Fri Jun 5 17:09:23 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 5 Jun 2009 11:09:23 -0400 Subject: Camellia for OpenPGP RFC published In-Reply-To: <871vpzdw0z.fsf@wheatstone.g10code.de> References: <87eiu0dtk2.fsf@wheatstone.g10code.de> <33269F33-9265-473A-A508-4C5ED27B925F@jabberwocky.com> <871vpzdw0z.fsf@wheatstone.g10code.de> Message-ID: On Jun 5, 2009, at 2:39 AM, Werner Koch wrote: >> gcry_cipher_* needs to call map_cipher_openpgp_to_gcry to sanitize >> the >> algorithm numbers before passing them to libgcrypt. At the moment, > > Yeah, I implemented that a year ago with the idea to do the mapping > while parsing and building OpenPGP messages. As you noticed, it is > not > complete yet. I did this as a few macros to wrap around the gcry functions (gcry_cipher_open -> openpgp_cipher_open, etc). David From wk at gnupg.org Fri Jun 5 18:55:46 2009 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Jun 2009 18:55:46 +0200 Subject: RSA+RSA is now the default In-Reply-To: (Nicholas Cole's message of "Mon, 1 Jun 2009 15:02:54 +0100") References: <87zldcszvb.fsf@wheatstone.g10code.de> <87ab51y5ed.fsf@wheatstone.g10code.de> Message-ID: <87r5xyaact.fsf@wheatstone.g10code.de> On Mon, 1 Jun 2009 16:02, nicholas.cole at gmail.com said: > Is there any way that the list of algorithms could be available in the > --status-fd output (ie. for when --no-tty has to be used or no > terminal is present?) The key generation dialog has been written for a human user and all scripts should use the batch mode. What I plan is to have a new interface which lists the default algorithms and related information. This allows frontends to use the batch mode key generation while taking the actual algorithms from GnuPG. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From nicholas.cole at gmail.com Sat Jun 6 00:02:01 2009 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 5 Jun 2009 23:02:01 +0100 Subject: RSA+RSA is now the default In-Reply-To: <87r5xyaact.fsf@wheatstone.g10code.de> References: <87zldcszvb.fsf@wheatstone.g10code.de> <87ab51y5ed.fsf@wheatstone.g10code.de> <87r5xyaact.fsf@wheatstone.g10code.de> Message-ID: On Fri, Jun 5, 2009 at 5:55 PM, Werner Koch wrote: > On Mon, ?1 Jun 2009 16:02, nicholas.cole at gmail.com said: > >> Is there any way that the list of algorithms could be available in the >> --status-fd output (ie. for when --no-tty has to be used or no >> terminal is present?) > > The key generation dialog has been written for a human user and all > scripts should use the batch mode. > > What I plan is to have a new interface which lists the default > algorithms and related information. ?This allows frontends to use the > batch mode key generation while taking the actual algorithms from GnuPG. Fantastic! Though I was actually talking about the addsubkey menu, not the create key menu. I don't quite understand why that menu has to be sent to the terminal only (rather than stdout) - since it would be easy to parse. N From kevhilton at gmail.com Tue Jun 9 22:07:53 2009 From: kevhilton at gmail.com (Kevin Hilton) Date: Tue, 9 Jun 2009 15:07:53 -0500 Subject: Errors compiling 1.4 Branch on Cygwin In-Reply-To: <96c450350906082315p7015f3b3o821c7c5d607e9fcd@mail.gmail.com> References: <96c450350906082315p7015f3b3o821c7c5d607e9fcd@mail.gmail.com> Message-ID: <96c450350906091307q2e1c3c6bu673203b1f8ba85c7@mail.gmail.com> With the latest 1.4 branch revision 5039 and 5040 I can't seem to compile the source on cygwin. ?I haven't tried with earlier revisions except that I can tell you I have revision 4907 successfully compiled. Here are the errors I am getting: This should work unless it involves constant data structures referencing symbols ?from auto-imported DLLs.../util/libcompat.a(srv.o): In function `getsrv': /home/admin/src/gpg/util/srv.c:64: undefined reference to `___res_query' /home/admin/src/gpg/util/srv.c:78: undefined reference to `___dn_skipname' /home/admin/src/gpg/util/srv.c:98: undefined reference to `___dn_skipname' /home/admin/src/gpg/util/srv.c:132: undefined reference to `___dn_expand' Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) collect2: ld returned 1 exit status make[2]: *** [gpgkeys_hkp.exe] Error 1 make[2]: Leaving directory `/home/admin/src/gpg/keyserver' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/admin/src/gpg' make: *** [all] Error 2 Do I have an old unresolved dependency? -- Kevin Hilton From jmoore3rd at bellsouth.net Tue Jun 9 22:56:25 2009 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Tue, 09 Jun 2009 16:56:25 -0400 Subject: Errors compiling 1.4 Branch on Cygwin In-Reply-To: <96c450350906091307q2e1c3c6bu673203b1f8ba85c7@mail.gmail.com> References: <96c450350906082315p7015f3b3o821c7c5d607e9fcd@mail.gmail.com> <96c450350906091307q2e1c3c6bu673203b1f8ba85c7@mail.gmail.com> Message-ID: <4A2ECC79.8060208@bellsouth.net> Kevin Hilton wrote: > With the latest 1.4 branch revision 5039 and 5040 I can't seem to > compile the source on cygwin. I haven't tried with earlier revisions > except that I can tell you I have revision 4907 successfully compiled. Unless I'm sadly mistaken, those svn version numbers are not 1.4.x Branch, but rather 2.x Trunk versions. IIRC the last svn Branch release was 5037. JOHN ;) Timestamp: Tuesday 09 Jun 2009, 16:55 --400 (Eastern Daylight Time) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 654 bytes Desc: OpenPGP digital signature URL: From robbat2 at gentoo.org Tue Jun 9 21:59:35 2009 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Tue, 9 Jun 2009 12:59:35 -0700 Subject: Security Concern - Open Source Binaries In-Reply-To: <4A2EB6BE.1000409@fifthhorseman.net> References: <23916072.post@talk.nabble.com> <4A2EB6BE.1000409@fifthhorseman.net> Message-ID: On Tue, Jun 09, 2009 at 03:23:42PM -0400, Daniel Kahn Gillmor wrote: > however, most gnu/linux distributions do. If you want a centralized > software aggregator who cryptographically signs off on packages at their > own distribution step, you should install debian or ubuntu (i know they > do this, through secure apt) or fedora or gentoo (i'm pretty sure they > do). I can't speak for other distros. For Gentoo, if you use the official rsync mirrors (rsync.gentoo.org) instead of the community mirrors (rsync$N.$CC.gentoo.org), you get one additional layer of protection, but I'd say that our overall signing rate isn't as high as I'd like it to be. It varies between 40-80% of packages as changes are made over time. > The usual caveats apply, of course: trusting the distro is often the > same as trusting the weakest link in the chain -- the most sloppy > developer with commit privileges to the distro, or the most sloppy > upstream developer, or the least-secured machinery in the chain between > you and the original developer who wrote the code. For many distributions, the mirrors are a severe weak point at them moment: http://www.cs.arizona.edu/people/justin/packagemanagersecurity/ The replay is of note, because it does not require defeating a signature, but only sending old data to prospective attack targets instead of the latest version. The CCS2008 and ;login: February 2009 reports are the best ones to read. The status of Gentoo signing plans are linked from there (disclaimer: I'm the driving force behind them). -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : robbat2 at gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 330 bytes Desc: not available URL: From dshaw at jabberwocky.com Tue Jun 9 23:16:01 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 9 Jun 2009 17:16:01 -0400 Subject: Errors compiling 1.4 Branch on Cygwin In-Reply-To: <96c450350906091307q2e1c3c6bu673203b1f8ba85c7@mail.gmail.com> References: <96c450350906082315p7015f3b3o821c7c5d607e9fcd@mail.gmail.com> <96c450350906091307q2e1c3c6bu673203b1f8ba85c7@mail.gmail.com> Message-ID: <662AD17A-A2EB-4EB7-B1BB-81372CFE8B66@jabberwocky.com> On Jun 9, 2009, at 4:07 PM, Kevin Hilton wrote: > With the latest 1.4 branch revision 5039 and 5040 I can't seem to > compile the source on cygwin. I haven't tried with earlier revisions > except that I can tell you I have revision 4907 successfully compiled. > > Here are the errors I am getting: > > This should work unless it involves constant data structures > referencing symbols > from auto-imported DLLs.../util/libcompat.a(srv.o): In function > `getsrv': > /home/admin/src/gpg/util/srv.c:64: undefined reference to > `___res_query' > /home/admin/src/gpg/util/srv.c:78: undefined reference to > `___dn_skipname' > /home/admin/src/gpg/util/srv.c:98: undefined reference to > `___dn_skipname' > /home/admin/src/gpg/util/srv.c:132: undefined reference to > `___dn_expand' > Info: resolving _optarg by linking to __imp__optarg (auto-import) > Info: resolving _optind by linking to __imp__optind (auto-import) > collect2: ld returned 1 exit status > make[2]: *** [gpgkeys_hkp.exe] Error 1 > make[2]: Leaving directory `/home/admin/src/gpg/keyserver' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/admin/src/gpg' > make: *** [all] Error 2 > > Do I have an old unresolved dependency? In your main build directory, tell me the output of these commands: grep DNSLIBS config.status grep LIBCURL config.status grep USE_DNS config.h grep BIND config.h David From John at Mozilla-Enigmail.org Tue Jun 9 23:23:46 2009 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Tue, 09 Jun 2009 16:23:46 -0500 Subject: Errors compiling 1.4 Branch on Cygwin In-Reply-To: <662AD17A-A2EB-4EB7-B1BB-81372CFE8B66@jabberwocky.com> References: <96c450350906082315p7015f3b3o821c7c5d607e9fcd@mail.gmail.com> <96c450350906091307q2e1c3c6bu673203b1f8ba85c7@mail.gmail.com> <662AD17A-A2EB-4EB7-B1BB-81372CFE8B66@jabberwocky.com> Message-ID: <4A2ED2E2.6000708@Mozilla-Enigmail.org> David Shaw wrote: > > In your main build directory, tell me the output of these commands: > > grep DNSLIBS config.status > grep LIBCURL config.status > grep USE_DNS config.h > grep BIND config.h David, I got the same error on 5031, but I don't use Cygwin enough to worry about it too much. jpclizbe at booboo ~/gnupg-svn/gnupg14r5031 $ grep DNSLIBS config.status S["DNSLIBS"]="-lresolv " jpclizbe at booboo ~/gnupg-svn/gnupg14r5031 $ grep LIBCURL config.status S["LIBCURL"]="-lcurl -L/usr/lib -lssh2 -lssl -lcrypto -lz" S["LIBCURL_CPPFLAGS"]="" D["HAVE_LIBCURL"]=" 1" D["LIBCURL_FEATURE_SSL"]=" 1" D["LIBCURL_FEATURE_LIBZ"]=" 1" D["LIBCURL_FEATURE_NTLM"]=" 1" D["LIBCURL_PROTOCOL_HTTP"]=" 1" D["LIBCURL_PROTOCOL_HTTPS"]=" 1" D["LIBCURL_PROTOCOL_FTP"]=" 1" D["LIBCURL_PROTOCOL_FTPS"]=" 1" D["LIBCURL_PROTOCOL_FILE"]=" 1" D["LIBCURL_PROTOCOL_TELNET"]=" 1" D["LIBCURL_PROTOCOL_LDAP"]=" 1" D["LIBCURL_PROTOCOL_DICT"]=" 1" D["LIBCURL_PROTOCOL_TFTP"]=" 1" jpclizbe at booboo ~/gnupg-svn/gnupg14r5031 $ grep USE_DNS config.h #define USE_DNS_CERT 1 #define USE_DNS_PKA 1 #define USE_DNS_SRV 1 jpclizbe at booboo ~/gnupg-svn/gnupg14r5031 $ grep BIND config.h /* #undef BIND_8_COMPAT */ -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 678 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Tue Jun 9 23:29:37 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 9 Jun 2009 17:29:37 -0400 Subject: Errors compiling 1.4 Branch on Cygwin In-Reply-To: <4A2ED2E2.6000708@Mozilla-Enigmail.org> References: <96c450350906082315p7015f3b3o821c7c5d607e9fcd@mail.gmail.com> <96c450350906091307q2e1c3c6bu673203b1f8ba85c7@mail.gmail.com> <662AD17A-A2EB-4EB7-B1BB-81372CFE8B66@jabberwocky.com> <4A2ED2E2.6000708@Mozilla-Enigmail.org> Message-ID: <741E7723-BEFC-4709-AA85-9AF3F9CDA49B@jabberwocky.com> On Jun 9, 2009, at 5:23 PM, John Clizbe wrote: > David Shaw wrote: >> >> In your main build directory, tell me the output of these commands: >> >> grep DNSLIBS config.status >> grep LIBCURL config.status >> grep USE_DNS config.h >> grep BIND config.h > > David, > > I got the same error on 5031, but I don't use Cygwin enough to worry > about it too much. > > jpclizbe at booboo ~/gnupg-svn/gnupg14r5031 > $ grep DNSLIBS config.status > S["DNSLIBS"]="-lresolv " Try this patch: Index: keyserver/Makefile.am =================================================================== --- keyserver/Makefile.am (revision 5041) +++ keyserver/Makefile.am (working copy) @@ -1,5 +1,5 @@ # Copyright (C) 2001, 2002, 2004, 2005, 2006, -# 2007 Free Software Foundation, Inc. +# 2007, 2009 Free Software Foundation, Inc. # # This file is part of GnuPG. # @@ -48,7 +48,7 @@ gpgkeys_curl_CPPFLAGS = @LIBCURL_CPPFLAGS@ gpgkeys_curl_LDADD = ../util/libcompat.a @LIBCURL@ @GETOPT@ gpgkeys_hkp_CPPFLAGS = @LIBCURL_CPPFLAGS@ -gpgkeys_hkp_LDADD = ../util/libcompat.a @LIBCURL@ @GETOPT@ +gpgkeys_hkp_LDADD = ../util/libcompat.a @DNSLIBS@ @LIBCURL@ @GETOPT@ gpgkeys_finger_CPPFLAGS = @LIBCURL_CPPFLAGS@ gpgkeys_ldap_CPPFLAGS += @LIBCURL_CPPFLAGS@ endif David From John at Mozilla-Enigmail.org Tue Jun 9 23:57:34 2009 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Tue, 09 Jun 2009 16:57:34 -0500 Subject: Errors compiling 1.4 Branch on Cygwin In-Reply-To: <741E7723-BEFC-4709-AA85-9AF3F9CDA49B@jabberwocky.com> References: <96c450350906082315p7015f3b3o821c7c5d607e9fcd@mail.gmail.com> <96c450350906091307q2e1c3c6bu673203b1f8ba85c7@mail.gmail.com> <662AD17A-A2EB-4EB7-B1BB-81372CFE8B66@jabberwocky.com> <4A2ED2E2.6000708@Mozilla-Enigmail.org> <741E7723-BEFC-4709-AA85-9AF3F9CDA49B@jabberwocky.com> Message-ID: <4A2EDACE.1030702@Mozilla-Enigmail.org> David Shaw wrote: > Try this patch: > > Index: keyserver/Makefile.am > =================================================================== > --- keyserver/Makefile.am (revision 5041) > +++ keyserver/Makefile.am (working copy) > @@ -1,5 +1,5 @@ > # Copyright (C) 2001, 2002, 2004, 2005, 2006, > -# 2007 Free Software Foundation, Inc. > +# 2007, 2009 Free Software Foundation, Inc. > # > # This file is part of GnuPG. > # > @@ -48,7 +48,7 @@ > gpgkeys_curl_CPPFLAGS = @LIBCURL_CPPFLAGS@ > gpgkeys_curl_LDADD = ../util/libcompat.a @LIBCURL@ @GETOPT@ > gpgkeys_hkp_CPPFLAGS = @LIBCURL_CPPFLAGS@ > -gpgkeys_hkp_LDADD = ../util/libcompat.a @LIBCURL@ @GETOPT@ > +gpgkeys_hkp_LDADD = ../util/libcompat.a @DNSLIBS@ @LIBCURL@ @GETOPT@ > gpgkeys_finger_CPPFLAGS = @LIBCURL_CPPFLAGS@ > gpgkeys_ldap_CPPFLAGS += @LIBCURL_CPPFLAGS@ > endif Looks like a winner jpclizbe at booboo ~/gnupg-svn/gnupg14r5031/keyserver $ ./gpgkeys_hkp --version gpgkeys_hkp (GnuPG) 1.4.10-svn5031 Uses: libcurl/7.16.3 OpenSSL/0.9.8k zlib/1.2.3 libssh2/0.15-CVS -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 678 bytes Desc: OpenPGP digital signature URL: From JPClizbe at tx.rr.com Wed Jun 10 00:30:45 2009 From: JPClizbe at tx.rr.com (John Clizbe) Date: Tue, 09 Jun 2009 17:30:45 -0500 Subject: Errors compiling 1.4 Branch on Cygwin In-Reply-To: <4A2ECC79.8060208@bellsouth.net> References: <96c450350906082315p7015f3b3o821c7c5d607e9fcd@mail.gmail.com> <96c450350906091307q2e1c3c6bu673203b1f8ba85c7@mail.gmail.com> <4A2ECC79.8060208@bellsouth.net> Message-ID: <4A2EE295.90801@tx.rr.com> John W. Moore III wrote: > Kevin Hilton wrote: >> With the latest 1.4 branch revision 5039 and 5040 I can't seem to >> compile the source on cygwin. I haven't tried with earlier revisions >> except that I can tell you I have revision 4907 successfully compiled. > > Unless I'm sadly mistaken, those svn version numbers are not 1.4.x > Branch, but rather 2.x Trunk versions. IIRC the last svn Branch release > was 5037. You are not mistaken, John. Cancel the porcine ballroom dancing lessons before you get too muddy. ( http://lists.gnupg.org/pipermail/gnupg-users/2008-March/032837.html ) -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 693 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 678 bytes Desc: OpenPGP digital signature URL: From kevhilton at gmail.com Wed Jun 10 08:00:45 2009 From: kevhilton at gmail.com (Kevin Hilton) Date: Wed, 10 Jun 2009 01:00:45 -0500 Subject: Errors compiling 1.4 Branch on Cygwin In-Reply-To: <4A2EDACE.1030702@Mozilla-Enigmail.org> References: <96c450350906082315p7015f3b3o821c7c5d607e9fcd@mail.gmail.com> <96c450350906091307q2e1c3c6bu673203b1f8ba85c7@mail.gmail.com> <662AD17A-A2EB-4EB7-B1BB-81372CFE8B66@jabberwocky.com> <4A2ED2E2.6000708@Mozilla-Enigmail.org> <741E7723-BEFC-4709-AA85-9AF3F9CDA49B@jabberwocky.com> <4A2EDACE.1030702@Mozilla-Enigmail.org> Message-ID: <96c450350906092300m6ecae29cif4dd2da43b587a66@mail.gmail.com> Thanks for integration of the patch file to the svn version. Everything looks good for now! From wk at gnupg.org Wed Jun 10 11:18:13 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Jun 2009 11:18:13 +0200 Subject: Errors compiling 1.4 Branch on Cygwin In-Reply-To: <4A2ECC79.8060208@bellsouth.net> (John W. Moore, III's message of "Tue, 09 Jun 2009 16:56:25 -0400") References: <96c450350906082315p7015f3b3o821c7c5d607e9fcd@mail.gmail.com> <96c450350906091307q2e1c3c6bu673203b1f8ba85c7@mail.gmail.com> <4A2ECC79.8060208@bellsouth.net> Message-ID: <87r5xsxx9m.fsf@wheatstone.g10code.de> On Tue, 9 Jun 2009 22:56, jmoore3rd at bellsouth.net said: > Unless I'm sadly mistaken, those svn version numbers are not 1.4.x > Branch, but rather 2.x Trunk versions. IIRC the last svn Branch release > was 5037. That doesn't matter. The revision number is global for the entire repository. You need to specify the branch (URL) of what you want to extract. In fact SVN has no real branches but is a filesystem; branches are just a convention. For example you could do a "svn co svn://cvs.gnupg.org/gnupg" and it will checkout the entire repository with all branches. You can see this with the ls command: $ svn ls svn://cvs.gnupg.org/gnupg/ 2.0-mo-scd/ branches/ tags/ trunk/ With option -R it would show you all files like ls(1) does. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Wed Jun 17 13:18:30 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Jun 2009 13:18:30 +0200 Subject: [Announce] GnuPG 2.0.12 released Message-ID: <87d493w1kp.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.12. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data, create digital signatures, help authenticating using Secure Shell and to provide a framework for public key cryptography. It includes an advanced key management facility and is compliant with the OpenPGP and S/MIME standards. GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.9) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. GnuPG is distributed under the terms of the GNU General Public License (GPL version 3). GnuPG-2 works best on GNU/Linux or *BSD systems. What's New =========== * GPGSM now always lists ephemeral certificates if specified by fingerprint or keygrip. * New command "KEYINFO" for GPG_AGENT. GPGSM now also returns information about smartcards. * Made sure not to leak file descriptors if running gpg-agent with a command. Restore the signal mask to solve a problem in Mono. * Changed order of the confirmation questions for root certificates and store negative answers in trustlist.txt. * Better synchronization of concurrent smartcard sessions. * Support 2048 bit OpenPGP cards. * Support Telesec Netkey 3 cards. * The gpg-protect-tool now uses gpg-agent via libassuan. Under Windows the Pinentry will now be put into the foreground. * Changed code to avoid a possible Mac OS X system freeze. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.12 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the FTP server and its mirrors you should find the following files in the gnupg/ directory: gnupg-2.0.12.tar.bz2 (3832k) gnupg-2.0.12.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.11-2.0.12.diff.bz2 (113k) A patch file to upgrade a 2.0.11 GnuPG source tree. This patch does not include updates of the language files. Note, that we don't distribute gzip compressed tarballs for GnuPG-2. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-2.0.12.tar.bz2 you would use this command: gpg --verify gnupg-2.0.12.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a keyserver like gpg --recv-key 1CE0C630 The distribution key 1CE0C630 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! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-2.0.12.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.12.tar.bz2 and check that the output matches the first line from the following list: 91856f917c13a1a12622ef39995eaf59c46f7502 gnupg-2.0.12.tar.bz2 0d4a3828d437d88353da36aa8f74ba92f6eca0e7 gnupg-2.0.11-2.0.12.diff.bz2 Internationalization ==================== GnuPG comes with support for 27 languages. Due to a lot of new and changed strings many translations are not entirely complete. Jedi, Maxim Britov, Jaime Su?rez and Nilg?n Belma Bug?ner have been kind enough to go over their translations and thus the Chinese, German, Russian, Spanish, and Turkish translations are pretty much complete. 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. KDE's KMail is the most prominent user of GnuPG-2. In fact it has been developed along with the KMail folks. Mutt users might want to use the configure option "--enable-gpgme" and "set use_crypt_gpgme" in ~/.muttrc to make use of GnuPG-2 to enable S/MIME in addition to a reworked OpenPGP support. The manual is also available online in HTML format at http://www.gnupg.org/documentation/manuals/gnupg/ and in Portable Document Format at http://www.gnupg.org/documentation/manuals/gnupg.pdf . 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, order extensions or support or more general by donating money to the Free Software movement (e.g. http://www.fsfeurope.org/help/donate.en.html). 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. The GnuPG 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. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Wed Jun 17 15:49:43 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Jun 2009 15:49:43 +0200 Subject: [Announce] Dirmngr 1.0.3 released Message-ID: <87ljnrug08.fsf@wheatstone.g10code.de> Hi! We are pleased to announce the availability of Dirmngr version 1.0.3. Dirmngr is a server for managing and downloading certificate revocation lists (CRLs) for X.509 certificates and for downloading the certificates themselves. Dirmngr also handles OCSP requests as an alternative to CRLs. Although Dirmngr can be invoked on demand, it should in general be installed as a system daemon. Get it from: ftp://ftp.gnupg.org/gcrypt/dirmngr/dirmngr-1.0.3.tar.bz2 (542k) ftp://ftp.gnupg.org/gcrypt/dirmngr/dirmngr-1.0.3.tar.bz2.sig or as a patch against the last version: ftp://ftp.gnupg.org/gcrypt/dirmngr/dirmngr-1.0.2-1.0.3.diff.bz2 (25k) SHA-1 checksums are: 437d381c937b1f1d0699d1ed37cf50f14bfbcd32 dirmngr-1.0.3.tar.bz2 e139db6205145066b6bb13686121d07f241bacb4 dirmngr-1.0.2-1.0.3.diff.bz2 Whats new in this release ========================= * Client based trust anchors are now supported. * Configured certificates with the suffix ".der" are now also used. * Libgcrypt 1.4 is now required. Documentation ============= Dirmngr comes with man pages and as well as with a texinfo based manual. Run "info dirmngr" to read the manual or run make -C doc dirmngr.pdf to build a printable version. If you have questions on the use of Dirmngr, feel free to ask at gnupg-users at gnupg.org. Support ======= Improving Dirmngr is costly, but you can help! We are looking for organizations that find Dirmngr useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or by donating money. Commercial support contracts for Dirmngr 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 Dirmngr 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. The folks at Intevation helped a lot to track down bugs and to define new features. Marcus Brinkmann is mainly responsible for completing the Windows port. Happy Hacking, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From stefan.lorenz at stud.uni-saarland.de Wed Jun 17 14:54:04 2009 From: stefan.lorenz at stud.uni-saarland.de (Stefan Lorenz) Date: Wed, 17 Jun 2009 14:54:04 +0200 Subject: DSA Implementation in GnuPG Message-ID: <4A38E76C.7030006@stud.uni-saarland.de> Hi there, we are interested in the actual implementation of DSA in GnuPG, in particular we would like to know whether the primes p, q and the generator g are or can somehow be fixed during the key generation. Additionally we would like to know how the size of q is determined. Best, Stefan From wk at gnupg.org Wed Jun 17 20:42:45 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Jun 2009 20:42:45 +0200 Subject: DSA Implementation in GnuPG In-Reply-To: <4A38E76C.7030006@stud.uni-saarland.de> (Stefan Lorenz's message of "Wed, 17 Jun 2009 14:54:04 +0200") References: <4A38E76C.7030006@stud.uni-saarland.de> Message-ID: <87k53a3dne.fsf@wheatstone.g10code.de> On Wed, 17 Jun 2009 14:54, stefan.lorenz at stud.uni-saarland.de said: > we are interested in the actual implementation of DSA in GnuPG, in You should look at Libgcrypt which is used by GnuPG-2. > particular we would like to know whether the primes p, q and the > generator g are or can somehow be fixed during the key That is possible; use the domain parameter. Checkout the test programs in libgcrypt/tests. The libgcrypt manual describes several parameter: Look for gcry_pk_genkey. > generation. Additionally we would like to know how the size of q is > determined. In non-FIPS mode we use the values take from the standard (libgcrypt/cipher/dsa.c:generate): if (qbits) ; /* Caller supplied qbits. Use this value. */ else if ( nbits >= 512 && nbits <= 1024 ) qbits = 160; else if ( nbits == 2048 ) qbits = 224; else if ( nbits == 3072 ) qbits = 256; else if ( nbits == 7680 ) qbits = 384; else if ( nbits == 15360 ) qbits = 512; else return GPG_ERR_INV_VALUE; Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Wed Jun 17 21:28:09 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 17 Jun 2009 15:28:09 -0400 Subject: DSA Implementation in GnuPG In-Reply-To: <4A38E76C.7030006@stud.uni-saarland.de> References: <4A38E76C.7030006@stud.uni-saarland.de> Message-ID: On Jun 17, 2009, at 8:54 AM, Stefan Lorenz wrote: > Hi there, > > we are interested in the actual implementation of DSA in GnuPG, in > particular we would like to know whether the primes p, q and the > generator g are or can somehow be fixed during the key generation. > Additionally we would like to know how the size of q is determined. Not in GnuPG directly, but I believe you can access this via gcrypt, which is what GnuPG uses for its crypto. In GnuPG, 'q' is chosen based on the size of the key: if the key is over 2048 bits long, q is 256 bits. If the key is over 1024 bits long, q is 224 bits. If the key is 1024 bits or less, then q is 160 bits. David From rdieter at math.unl.edu Thu Jun 18 15:06:30 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 18 Jun 2009 08:06:30 -0500 Subject: new pinentry release with qt4 support? Message-ID: Any news/plans on a new pinentry release that includes the new/shiny qt4 support? -- Rex From marcus.brinkmann at ruhr-uni-bochum.de Thu Jun 18 21:54:01 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 18 Jun 2009 21:54:01 +0200 Subject: new pinentry release with qt4 support? In-Reply-To: References: Message-ID: <4A3A9B59.9090702@ruhr-uni-bochum.de> Rex Dieter wrote: > Any news/plans on a new pinentry release that includes the new/shiny qt4 > support? Stay tuned, it's upcoming (tonight). Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Fri Jun 19 02:51:20 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 19 Jun 2009 02:51:20 +0200 Subject: scim and pinentry-gtk2 In-Reply-To: <87myo45rkb.fsf@wheatstone.g10code.de> References: <47BDF11A.8010500@rlworkman.net> <87hcfvg8wu.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47E09E50.8040106@rlworkman.net> <87myo5wkg3.wl%marcus.brinkmann@ruhr-uni-bochum.de> <87myo45rkb.fsf@wheatstone.g10code.de> Message-ID: <4A3AE108.8010905@ruhr-uni-bochum.de> Werner Koch wrote: > On Mon, 7 Apr 2008 21:09, marcus.brinkmann at ruhr-uni-bochum.de said: > >> If it can be implemented without linking to any more libraries, I >> would suggest a command line option to enable external input methods. > > Command line options are cumbersome because we would need to implement > them in gpg-agent and and gpgconf too. > >> towards more GNOME/Gtk compliance, it might make sense to provide two >> separate versions of pinentry: A hardened version based on the current > > That's also my suggestion. Our framework makes it pretty easy to add new > pinentries Unfortunately, a binary won't cut it. This is because the input module is not selected by the X server or the gtk configuration, but by the client, through standardized environment variables. The X server supports many input methods, even in parallel, and clients can open sessions to one or more of them according to their own preferences. This is by design of the X protocol. The effect is that the input method is selected by the client, not by pinentry itself, and needs to be passed through gpg-agent in the same manner as the DISPLAY and locale setting. In particular, the following environment variables are responsible: GTK_IM_MODULE used by gtk to select gtk input modules (eg "scim-bridge") XMODIFIERS used by Xlib to select X input modules (eg "@im=SCIM") QT_IM_MODUL used by Qt to select qt input modules (eg "xim") The fun is that we need to pass through all three variables, because we don't know which backend the pinentry actually uses. This is a bigger change that needs to be coordinated across several packages (gpgme, gnupg, pinentry at least). Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Fri Jun 19 02:24:49 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 19 Jun 2009 02:24:49 +0200 Subject: Fix pinentry.tex lc-type command line option type In-Reply-To: <200901291003.33423.bernhard@intevation.de> References: <200901291003.33423.bernhard@intevation.de> Message-ID: <4A3ADAD1.7020506@ruhr-uni-bochum.de> Put it in, thanks (rev 207). Marcus From us3r07 at web.de Fri Jun 19 19:08:11 2009 From: us3r07 at web.de (Michael Hansen) Date: Fri, 19 Jun 2009 19:08:11 +0200 Subject: GnuPG 2.0 for Win + Feature requests Message-ID: <1250706896@web.de> Hello there! Firstly: I am wondering, that there is still no compiled version (of the 2.0 series) for Windows. What's the reason? Then I have also two feature requests: 1. Support for secure wiping files 2. A Steganography feature I know, that GnuPG is mainly for encryption, but I think to add those kind of features would make sense. Regards. Michael ___________________________________________________________________ WEB.DE FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss f?r 17,95 Euro/mtl.! http://produkte.web.de/go/02/ From rjh at sixdemonbag.org Fri Jun 19 19:21:47 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 19 Jun 2009 13:21:47 -0400 Subject: GnuPG 2.0 for Win + Feature requests In-Reply-To: <1250706896@web.de> References: <1250706896@web.de> Message-ID: <4A3BC92B.6090900@sixdemonbag.org> Michael Hansen wrote: > Firstly: I am wondering, that there is still no compiled version (of > the 2.0 series) for Windows. What's the reason? There's no standalone installer, but GPG 2 is available as part of gpg4win (http://www.gpg4win.org). > 1. Support for secure wiping files Not happening. Look in the archives of this list for details. > 2. A Steganography feature (Probably) not happening. Steganography is grossly overhyped as a technology. Moulin and O'Sullivan's _An Information-Theoretic Analysis of Data Hiding_ (1999) was an attempt to put steganography on firm mathematical foundations to make it a peer of cryptography; in the course of this, they proved the Emperor had no clothes. ObNote: I am not a GnuPG developer. My 'not happening' is born of prior remarks by the core developers, but I am neither speaking for the developers nor claiming they can't change their minds. :) From jmoore3rd at bellsouth.net Fri Jun 19 19:39:46 2009 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Fri, 19 Jun 2009 13:39:46 -0400 Subject: GnuPG 2.0 for Win + Feature requests In-Reply-To: <1250706896@web.de> References: <1250706896@web.de> Message-ID: <4A3BCD62.7050005@bellsouth.net> Michael Hansen wrote: > Firstly: I am wondering, that there is still no compiled version (of the 2.0 series) for Windows. What's the reason? Are You not familiar with gpg4win? JOHN ;) Timestamp: Friday 19 Jun 2009, 13:39 --400 (Eastern Daylight Time) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 653 bytes Desc: OpenPGP digital signature URL: From us3r07 at web.de Fri Jun 19 19:52:15 2009 From: us3r07 at web.de (Michael Hansen) Date: Fri, 19 Jun 2009 19:52:15 +0200 Subject: GnuPG 2.0 for Win + Feature requests Message-ID: <1250754782@web.de> >> Firstly: I am wondering, that there is still no compiled version (of >> the 2.0 series) for Windows. What's the reason? > There's no standalone installer, but GPG 2 is available as part of > gpg4win (http://www.gpg4win.org). Thx! But I hope, that a stand-alone version will follow. >> 1. Support for secure wiping files > Not happening. Look in the archives of this list for details. Well, maybe it is also useless, if you simply encrypt your sensible files. >> 2. A Steganography feature > (Probably) not happening. Steganography is grossly overhyped as a > technology. Moulin and O'Sullivan's _An Information-Theoretic Analysis > of Data Hiding_ (1999) was an attempt to put steganography on firm > mathematical foundations to make it a peer of cryptography; in the > course of this, they proved the Emperor had no clothes. So, it's useless!? >> Firstly: I am wondering, that there is still no compiled version (of the 2.0 series) for Windows. What's the reason? > Are You not familiar with gpg4win? How, if I never used it before? I also only need the plain command-line tools, nothing more. ^^ Btw: Thanks for your replies! ___________________________________________________________________ WEB.DE FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss f?r 17,95 Euro/mtl.! http://produkte.web.de/go/02/ From mo at g10code.com Fri Jun 19 19:44:52 2009 From: mo at g10code.com (Moritz Schulte) Date: 19 Jun 2009 19:44:52 +0200 Subject: GnuPG 2.0 for Win + Feature requests In-Reply-To: <1250706896@web.de> References: <1250706896@web.de> Message-ID: <4A3BCE94.9000201@g10code.com> > Firstly: I am wondering, that there is still no compiled version (of the 2.0 series) for Windows. What's the reason? Huh? The Gpg4Win project (http://www.gpg4win.org/) exists for a rather long time already and includes GnuPG 2. mo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 269 bytes Desc: OpenPGP digital signature URL: From John at Mozilla-Enigmail.org Fri Jun 19 21:09:00 2009 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Fri, 19 Jun 2009 14:09:00 -0500 Subject: GnuPG 2.0 for Win + Feature requests In-Reply-To: <1250706896@web.de> References: <1250706896@web.de> Message-ID: <4A3BE24C.1000401@Mozilla-Enigmail.org> Michael Hansen wrote: > Firstly: I am wondering, that there is still no compiled version (of > the 2.0 series) for Windows. What's the reason? Maybe you didn't look very hard? Googling "gnupg+for+windows" http://www.google.com/search?q=gnupg%2Bfor%2Bwindows www.gpg4win is the first hit > Then I have also two feature requests: > > 1. Support for secure wiping files > 2. A Steganography feature > > I know, that GnuPG is mainly for encryption, but I think to add those > kind of features would make sense. Stego has been discussed and is not very likely from the developers opinions. Secure file wiping has been discussed to death, and is also unlikely. Details are in this list's archive as well as GnuPG-Users' archive, both available at www.gnupg.org. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 679 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri Jun 19 22:45:33 2009 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 19 Jun 2009 16:45:33 -0400 Subject: GnuPG 2.0 for Win + Feature requests In-Reply-To: <1250754782@web.de> References: <1250754782@web.de> Message-ID: <4A3BF8ED.7060105@sixdemonbag.org> Michael Hansen wrote: > Well, maybe it is also useless, if you simply encrypt your sensible files. There's an old adage: use the right tool for the job. If you're worried about someone doing serious forensic recovery of your hard drive, then invest in full-volume encryption. TrueCrypt and PGPDisk are two popular and well-reputed options: the former is open-source software, while the latter has source available. Disk shredders do not work -- more to the point, they _cannot_ work. From dshaw at jabberwocky.com Sat Jun 20 00:19:35 2009 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 19 Jun 2009 18:19:35 -0400 Subject: GnuPG 2.0 for Win + Feature requests In-Reply-To: <4A3BF8ED.7060105@sixdemonbag.org> References: <1250754782@web.de> <4A3BF8ED.7060105@sixdemonbag.org> Message-ID: On Jun 19, 2009, at 4:45 PM, Robert J. Hansen wrote: > Michael Hansen wrote: >> Well, maybe it is also useless, if you simply encrypt your sensible >> files. > > There's an old adage: use the right tool for the job. If you're > worried > about someone doing serious forensic recovery of your hard drive, then > invest in full-volume encryption. TrueCrypt and PGPDisk are two > popular > and well-reputed options: the former is open-source software, while > the > latter has source available. > > Disk shredders do not work -- more to the point, they _cannot_ work. Depends on the shredder ;) http://www.youtube.com/watch?v=sQYPCPB1g3o (Yes, I know you were talking about software shredders. When software can't help you, there are a number of companies who are happy to sell you a hardware or service solution.) David From pgut001 at cs.auckland.ac.nz Sat Jun 20 05:43:35 2009 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Sat, 20 Jun 2009 15:43:35 +1200 Subject: GnuPG 2.0 for Win + Feature requests In-Reply-To: <4A3BC92B.6090900@sixdemonbag.org> Message-ID: Michael Hansen writes: >Steganography is grossly overhyped as a technology. Moulin and O'Sullivan's >_An Information-Theoretic Analysis of Data Hiding_ (1999) was an attempt to >put steganography on firm mathematical foundations to make it a peer of >cryptography; in the course of this, they proved the Emperor had no clothes. Minor nit, it was Information Hiding and not Data Hiding (makes it easier to find via Google). The ref via Citeseer is http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.2370. I've run into a similar issue with threshold schemes, in collaboration with someone else we sat down to think about a standardised data format and (eventually) API and (even more eventually) UI for managing this, and found that just trying to frame the problem ended up creating a pretty good argument for why it wasn't practically solveable. Peter. From wk at gnupg.org Sat Jun 20 10:57:57 2009 From: wk at gnupg.org (Werner Koch) Date: Sat, 20 Jun 2009 10:57:57 +0200 Subject: scim and pinentry-gtk2 In-Reply-To: <4A3AE108.8010905@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "19 Jun 2009 02:51:20 +0200") References: <47BDF11A.8010500@rlworkman.net> <87hcfvg8wu.wl%marcus.brinkmann@ruhr-uni-bochum.de> <47E09E50.8040106@rlworkman.net> <87myo5wkg3.wl%marcus.brinkmann@ruhr-uni-bochum.de> <87myo45rkb.fsf@wheatstone.g10code.de> <4A3AE108.8010905@ruhr-uni-bochum.de> Message-ID: <87r5xfz3hm.fsf@wheatstone.g10code.de> On Fri, 19 Jun 2009 02:51, marcus.brinkmann at ruhr-uni-bochum.de said: > GTK_IM_MODULE used by gtk to select gtk input modules (eg "scim-bridge") > XMODIFIERS used by Xlib to select X input modules (eg "@im=SCIM") > QT_IM_MODUL used by Qt to select qt input modules (eg "xim") I see. What we should do is to define a global configuration option to list those envirnoment variables to pass along. Something like /etc/gnupg/environment Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From rdieter at math.unl.edu Sun Jun 21 02:31:13 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 20 Jun 2009 19:31:13 -0500 Subject: new pinentry release with qt4 support? References: <4A3A9B59.9090702@ruhr-uni-bochum.de> Message-ID: Marcus Brinkmann wrote: > Rex Dieter wrote: >> Any news/plans on a new pinentry release that includes the new/shiny qt4 >> support? > > Stay tuned, it's upcoming (tonight). Tried it out, didn't get very far trying to build against (the latest) qt-4.5.1: In file included from pinentrydialog.cpp:246: pinentrydialog.moc:14:2: error: #error "This file was generated using the moc from 4.4.1. It" pinentrydialog.moc:15:2: error: #error "cannot be used with the include files from this version of Qt." pinentrydialog.moc:16:2: error: #error "(The moc has changed too much.)" secstring.cpp: In function 'secstring toUtf8(const secqstring&)': In file included from qsecurelineedit.cpp:3589: qsecurelineedit.moc:14:2: error: #error "This file was generated using the moc from 4.4.1. It" qsecurelineedit.moc:15:2: error: #error "cannot be used with the include files from this version of Qt." qsecurelineedit.moc:16:2: error: #error "(The moc has changed too much.)" From arfrever.fta at gmail.com Sun Jun 21 04:44:26 2009 From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 21 Jun 2009 04:44:26 +0200 Subject: [PATCH] Support --without-adns option Message-ID: <200906210444.31617.Arfrever.FTA@gmail.com> Currently GnuPG tries to build support for ADNS even when the --without-adns option has been passed to `configure`. I'm attaching the patch which fixes this problem. -- Arfrever Frehtes Taifersar Arahesis -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-2.0.12-adns.patch Type: text/x-patch Size: 818 bytes Desc: not available URL: -------------- 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 arfrever.fta at gmail.com Mon Jun 22 03:56:40 2009 From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 22 Jun 2009 03:56:40 +0200 Subject: [GPGME] [PATCH] Fix implicit declaration Message-ID: <200906220358.03694.Arfrever.FTA@gmail.com> I'm attaching the patch which fixes the following compiler warning: assuan-socket.c: In function '_gpgme__assuan_sock_connect': assuan-socket.c:261: warning: implicit declaration of function '_gpgme_io_connect' -- Arfrever Frehtes Taifersar Arahesis -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme-1.2.0-fix_implicit_declaration.patch Type: text/x-patch Size: 818 bytes Desc: not available URL: -------------- 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 marcus.brinkmann at ruhr-uni-bochum.de Mon Jun 22 15:47:52 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 22 Jun 2009 15:47:52 +0200 Subject: [GPGME] [PATCH] Fix implicit declaration In-Reply-To: <200906220358.03694.Arfrever.FTA@gmail.com> References: <200906220358.03694.Arfrever.FTA@gmail.com> Message-ID: <4A3F8B88.4020205@ruhr-uni-bochum.de> Arfrever Frehtes Taifersar Arahesis wrote: > I'm attaching the patch which fixes the following compiler warning: > > assuan-socket.c: In function '_gpgme__assuan_sock_connect': > assuan-socket.c:261: warning: implicit declaration of function '_gpgme_io_connect' Thanks, I fixed this a bit differently: The change in src/ was ok, but we don't want to include GPGME header files in libassuan, so I copied the _gpgme_io_connect prototype manually. I also fixed all other warnings (there are some new ones in latest glibc), so we are warning clean again. The fixes are in revision 1388. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Mon Jun 22 15:50:26 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 22 Jun 2009 15:50:26 +0200 Subject: new pinentry release with qt4 support? In-Reply-To: References: <4A3A9B59.9090702@ruhr-uni-bochum.de> Message-ID: <4A3F8C22.4070203@ruhr-uni-bochum.de> Rex Dieter wrote: > Marcus Brinkmann wrote: > >> Rex Dieter wrote: >>> Any news/plans on a new pinentry release that includes the new/shiny qt4 >>> support? >> Stay tuned, it's upcoming (tonight). > > Tried it out, didn't get very far trying to build against (the latest) > qt-4.5.1: > > In file included from pinentrydialog.cpp:246: > pinentrydialog.moc:14:2: error: #error "This file was generated using the > moc from 4.4.1. It" > pinentrydialog.moc:15:2: error: #error "cannot be used with the include > files from this version of Qt." > pinentrydialog.moc:16:2: error: #error "(The moc has changed too much.)" > secstring.cpp: In function 'secstring toUtf8(const secqstring&)': > > In file included from qsecurelineedit.cpp:3589: > qsecurelineedit.moc:14:2: error: #error "This file was generated using the > moc from 4.4.1. It" > qsecurelineedit.moc:15:2: error: #error "cannot be used with the include > files from this version of Qt." > qsecurelineedit.moc:16:2: error: #error "(The moc has changed too much.)" Yes. Because there is support for qt3 and qt4, and qt doesn't integrate well with autoconf, and we must simplfiy cross compilation to Windows platforms, we ship with a default set of moc files that are not usable by everyone. Simply go to the qt4 directory and execute moc manually: moc pinentrydialog.h > pinentrydialog.moc moc qsecurelineedit.h > qsecurelineedit.moc Thanks, Marcus From rdieter at math.unl.edu Mon Jun 22 17:50:45 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 22 Jun 2009 10:50:45 -0500 Subject: new pinentry release with qt4 support? References: <4A3A9B59.9090702@ruhr-uni-bochum.de> <4A3F8C22.4070203@ruhr-uni-bochum.de> Message-ID: Marcus Brinkmann wrote: > Rex Dieter wrote: >> Marcus Brinkmann wrote: >> >>> Rex Dieter wrote: >>>> Any news/plans on a new pinentry release that includes the new/shiny >>>> qt4 support? >>> Stay tuned, it's upcoming (tonight). >> >> Tried it out, didn't get very far trying to build against (the latest) >> qt-4.5.1: >> >> In file included from pinentrydialog.cpp:246: >> pinentrydialog.moc:14:2: error: #error "This file was generated using the >> moc from 4.4.1. It" >> pinentrydialog.moc:15:2: error: #error "cannot be used with the include >> files from this version of Qt." >> pinentrydialog.moc:16:2: error: #error "(The moc has changed too much.)" >> secstring.cpp: In function 'secstring toUtf8(const secqstring&)': >> >> In file included from qsecurelineedit.cpp:3589: >> qsecurelineedit.moc:14:2: error: #error "This file was generated using >> the moc from 4.4.1. It" >> qsecurelineedit.moc:15:2: error: #error "cannot be used with the include >> files from this version of Qt." >> qsecurelineedit.moc:16:2: error: #error "(The moc has changed too much.)" > > Yes. Because there is support for qt3 and qt4, and qt doesn't integrate > well with autoconf, and we must simplfiy cross compilation to Windows > platforms, we ship with a default set of moc files that are not usable by > everyone. > > Simply go to the qt4 directory and execute moc manually: > > moc pinentrydialog.h > pinentrydialog.moc > moc qsecurelineedit.h > qsecurelineedit.moc Eww... that's far from ideal. This will likely trip up most folks building the qt4 frontend, hopefully a better solution will come along soon. *cough* cmake? *cough* :) -- Rex From wk at gnupg.org Tue Jun 23 18:26:40 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 23 Jun 2009 18:26:40 +0200 Subject: Required patches for the OpenPG card v2.0 Message-ID: <87hby6vrun.fsf@wheatstone.g10code.de> Hi! Unfortunately I realized too late that 2.0.12 still had bugs with the new OpenPGP card[1]. Without actual hardware testing stuff is a bit hard; I had 2 engineering samples during development and we swapped card back and forth to squash the bugs in the card's firmware while also hacking gnupg. Thus some things got not tested for 2.0.12. Find attached 2 patches against GnuPG 2.0.12 to fix the card problem as well as an unlrealted Windows-only problem. These patches are already in the Gpg4win 2.0.0rc1 installer currently being copied to the servers. GnuPG 1.4 does not yet support the v2 cards. I plan to backport the code from 2.0 in the next week and then it should not take too long to get 1.4.10 out. If you don't want to wait: gpg2 is the perfect version for the desktop or laptop ;-) A cautionary note: If you plan to buy a smartcard reader, please abstain From Omnikey based readers (Cardman and some others). They do not work with 2048 bit smartcards. They work on Windows, but not on a free OSes. We need to do some protocol analysis to see how the Windows driver achieves to send so-called extended lengths APDUs. The vendors are not very helpful in this regard, thus I can only suggest to resort to SCM based readers. Salam-Shalom, Werner [1] Meanwhile we received the first batch of cards; they will be sold at the LinuxTag and if cards are left over by next week through the well known distributor. -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 01-scd-pw2.patch Type: text/x-patch Size: 3502 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 02-pth-estream.patch Type: text/x-patch Size: 1759 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available URL: From cononet at gmail.com Wed Jun 24 13:57:53 2009 From: cononet at gmail.com (John D) Date: Wed, 24 Jun 2009 14:57:53 +0300 Subject: GCRY_THREAD_OPTION_PTHREAD_IMPL Message-ID: <419cd9410906240457k2c937174s8a5c8df4fc67832c@mail.gmail.com> Hello This: #include #include #include #include GCRY_THREAD_OPTION_PTHREAD_IMPL; int main() { /* The order matters. */ gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); gnutls_global_init(); } Compiles flawlessly on debian 5 64bit.. However, on Cent OS 5 64 bit.. With an identical setup and gcc produces: [root at localhost code]# gcc -lpthread test.cpp -O -lgnutls -lssl -lcurl -pthread test.cpp: In function int gcry_pthread_mutex_init(void**): test.cpp:5: error: malloc was not declared in this scope test.cpp:5: error: free was not declared in this scope test.cpp: In function int gcry_pthread_mutex_destroy(void**): test.cpp:5: error: invalid conversion from void* to pthread_mutex_t* test.cpp:5: error: initializing argument 1 of int pthread_mutex_destroy(pthread_mutex_t*) test.cpp:5: error: free was not declared in this scope test.cpp: In function int gcry_pthread_mutex_lock(void**): test.cpp:5: error: invalid conversion from void* to pthread_mutex_t* test.cpp:5: error: initializing argument 1 of int pthread_mutex_lock(pthread_mutex_t*) test.cpp: In function int gcry_pthread_mutex_unlock(void**): test.cpp:5: error: invalid conversion from void* to pthread_mutex_t* test.cpp:5: error: initializing argument 1 of int pthread_mutex_unlock(pthread_mutex_t*) [root at localhost code]# Might anyone be able to shed any light on what and why, I need to get this rectified. Thanks a million, John -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.uzel at suse.cz Wed Jun 24 18:26:10 2009 From: petr.uzel at suse.cz (Petr Uzel) Date: Wed, 24 Jun 2009 18:26:10 +0200 Subject: [libksba] asn1-func.c: array index out of range Message-ID: <20090624162610.GA11876@localhost> Hi, as David Binderman (CC:) pointed out in [1], there's a 'array index out of range' bug in current libksba. Patch follows ;) [1] https://bugzilla.novell.com/show_bug.cgi?id=515038 Index: src/asn1-func.c =================================================================== --- src/asn1-func.c (revision 306) +++ src/asn1-func.c (working copy) @@ -171,7 +171,7 @@ break; case VALTYPE_BOOL: len = 1; - helpbuf[1] = s->value.v_bool; + helpbuf[0] = s->value.v_bool; buf = helpbuf; break; case VALTYPE_CSTR: -- Best regards / s pozdravem Petr Uzel, Packages maintainer --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: puzel at suse.cz Lihovarsk? 1060/12 http://www.suse.cz 190 00 Prague 9 Czech Republic From marcus.brinkmann at ruhr-uni-bochum.de Sat Jun 27 11:18:38 2009 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 27 Jun 2009 11:18:38 +0200 Subject: new pinentry release with qt4 support? In-Reply-To: References: <4A3A9B59.9090702@ruhr-uni-bochum.de> <4A3F8C22.4070203@ruhr-uni-bochum.de> Message-ID: <4A45E3EE.3090501@ruhr-uni-bochum.de> Rex Dieter wrote: >> Simply go to the qt4 directory and execute moc manually: >> >> moc pinentrydialog.h > pinentrydialog.moc >> moc qsecurelineedit.h > qsecurelineedit.moc > > Eww... that's far from ideal. This will likely trip up most folks building > the qt4 frontend, hopefully a better solution will come along soon. > *cough* cmake? *cough* :) If you can't say it without coughing, it ain't gonna happen :) If you know how to improve the configure checks, you know where to send patches. Heck, if it's possible to run cmake from configure that could even be an option, too. But the i586-mingw32msvc cross-compilation case needs to work (that is _our_ requirement). Apart from that, my only idea is to remove pinentry-qt(3), which could make writing configure checks easier. It's true that we spoiled the most simple case, but we just don't have the resources to cover all the cases, and the help from people who know what the qt folks are up to is required here (but they are not interested in autoconf :-/). Thanks, Marcus From wk at gnupg.org Sun Jun 28 13:06:06 2009 From: wk at gnupg.org (Werner Koch) Date: Sun, 28 Jun 2009 13:06:06 +0200 Subject: RSA+RSA is now the default In-Reply-To: (Nicholas Cole's message of "Fri, 5 Jun 2009 23:02:01 +0100") References: <87zldcszvb.fsf@wheatstone.g10code.de> <87ab51y5ed.fsf@wheatstone.g10code.de> <87r5xyaact.fsf@wheatstone.g10code.de> Message-ID: <87fxdkvcrl.fsf@wheatstone.g10code.de> On Sat, 6 Jun 2009 00:02, nicholas.cole at gmail.com said: > Fantastic! Though I was actually talking about the addsubkey menu, > not the create key menu. I don't quite understand why that menu has > to be sent to the terminal only (rather than stdout) - since it would That is because it uses the same code as --gen-key. I plan to add subkey maintenance to GPA and the course of doing that I probably will run into the same problems you get. Needs to be fixed then. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From kevhilton at gmail.com Mon Jun 29 07:53:18 2009 From: kevhilton at gmail.com (Kevin Hilton) Date: Mon, 29 Jun 2009 00:53:18 -0500 Subject: SVN 5052 GPG2 Make Errors - Cygwin Message-ID: <96c450350906282253v1a50366fieff07d521499a109@mail.gmail.com> Sorry to keep reporting problems, but thought I would let the developers know the gpg2 make errors with cygwin with the latest svn 5052 release: In file included from ../common/util.h:34, from estream.c:59: ../common/../jnlib/stringhelp.h:98:1: warning: "stricmp" redefined In file included from estream.c:37: /usr/include/string.h:88:1: warning: this is the location of the previous defini tion estream.c:466:2: warning: #warning READ the code and see how it should work estream.c: In function `es_write_sanitized_utf8_buffer': estream.c:3208: error: `rc' undeclared (first use in this function) estream.c:3208: error: (Each undeclared identifier is reported only once estream.c:3208: error: for each function it appears in.) make[3]: *** [libcommon_a-estream.o] Error 1 make[3]: Leaving directory `/home/admin/src/gpg2/common' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/admin/src/gpg2/common' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/admin/src/gpg2' make: *** [all] Error 2 -- Kevin Hilton From wk at gnupg.org Mon Jun 29 08:32:32 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Jun 2009 08:32:32 +0200 Subject: [libksba] asn1-func.c: array index out of range In-Reply-To: <20090624162610.GA11876@localhost> (Petr Uzel's message of "Wed, 24 Jun 2009 18:26:10 +0200") References: <20090624162610.GA11876@localhost> Message-ID: <8763efh7nj.fsf@wheatstone.g10code.de> On Wed, 24 Jun 2009 18:26, petr.uzel at suse.cz said: > as David Binderman (CC:) pointed out in [1], there's a 'array index > out of range' bug in current libksba. Patch follows ;) Thanks for reporting. This is a really old code part: * asn1-func.c (copy_value): Fix out-of-bounds assignment of a boolean to HELPBUF. Due to alignment rules this was not exploitable and we did not even used this code path. Reported by David Binderman. Fixed in SVN r306. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon Jun 29 08:41:35 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Jun 2009 08:41:35 +0200 Subject: [PATCH] Support --without-adns option In-Reply-To: <200906210444.31617.Arfrever.FTA@gmail.com> (Arfrever Frehtes Taifersar Arahesis's message of "Sun, 21 Jun 2009 04:44:26 +0200") References: <200906210444.31617.Arfrever.FTA@gmail.com> Message-ID: <87ws6vfso0.fsf@wheatstone.g10code.de> On Sun, 21 Jun 2009 04:44, arfrever.fta at gmail.com said: > Currently GnuPG tries to build support for ADNS even when the --without-adns > option has been passed to `configure`. I'm attaching the patch which fixes Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon Jun 29 09:03:37 2009 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Jun 2009 09:03:37 +0200 Subject: Strange Key ID problem. : subkey id is reported where primary key id should be reported as missing? In-Reply-To: <4A485795.3030701@ubin.jp> (chiaki.ishikawa@ubin.jp's message of "Mon, 29 Jun 2009 14:56:37 +0900") References: <4A485795.3030701@ubin.jp> Message-ID: <87ocs7frna.fsf@wheatstone.g10code.de> On Mon, 29 Jun 2009 07:56, chiaki.ishikawa at ubin.jp said: > (After writing this summary, I now think it is a bug, but am not sure Yes it is a bug. But not in GnupG but in tghe keyserver software. > So I tried to obtain the key using gpg with arguments such as > --keyserver pgp.mit.edu -recv-keys 17785FE8 > --keyserver pgp.nic.ad.jp -recv-keys 17785FE8 > to no avail. Both keyservers run old and non-OpenPGP compatible software - Do not use them. I tried this too (using gpg2 but that doesn't matter) $ gpg2 --recv-key 17785FE8 gpg: requesting key 17785FE8 from hkp server keys.gnupg.net gpg: key 812347DD: public key "Mozilla Software [...] gpg: Total number processed: 1 gpg: imported: 1 So everything is fine. The key was taken from one of the SKS keyservers to which keys.gnupg.net resolve. If you now look at the key: $ gpg2 --list-key 17785FE8 pub 1024D/812347DD 2007-07-17 [expires: 2009-07-16] uid Mozilla Software Releases sub 1024D/17785FE8 2007-07-17 [expires: 2009-07-16] sub 2048g/1B0EC2E7 2007-07-17 [expires: 2009-07-16] You will notice that 17785FE8 is a signing subkey. The old pks software can't handle this and breaks the key. We do have this problem for years now and at least the admins of pgp.mit.edu don't care about it and keep on running this broken software. I am now considering whether we should detect Server: pks_www/0.9.6 and reject this one as entirely broken. Maybe just a warning if --expert is used. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From JPClizbe at tx.rr.com Mon Jun 29 09:59:30 2009 From: JPClizbe at tx.rr.com (John Clizbe) Date: Mon, 29 Jun 2009 02:59:30 -0500 Subject: Strange Key ID problem. : subkey id is reported where primary key id should be reported as missing? In-Reply-To: <87ocs7frna.fsf@wheatstone.g10code.de> References: <4A485795.3030701@ubin.jp> <87ocs7frna.fsf@wheatstone.g10code.de> Message-ID: <4A487462.9050305@tx.rr.com> Werner Koch wrote: > On Mon, 29 Jun 2009 07:56, chiaki.ishikawa at ubin.jp said: >> (After writing this summary, I now think it is a bug, but am not sure > Yes it is a bug. But not in GnupG but in the keyserver software. > >> So I tried to obtain the key using gpg with arguments such as >> --keyserver pgp.mit.edu -recv-keys 17785FE8 >> --keyserver pgp.nic.ad.jp -recv-keys 17785FE8 >> to no avail. > > Both keyservers run old and non-OpenPGP compatible software - Do not use > them. > > I tried this too (using gpg2 but that doesn't matter) > > So everything is fine. The key was taken from one of the SKS keyservers > to which keys.gnupg.net resolve. If you now look at the key: > The key shows correctly on the SKS servers: http://keyserver.gingerbear.net/pks/lookup?search=0x17785FE8&fingerprint=on&op=vindex > We do have this problem for years now and at least the admins of > pgp.mit.edu don't care about it and keep on running this broken > software. And we keep on giving the same advice over and over not to use this and other broken PKS servers. > I am now considering whether we should detect > Server: pks_www/0.9.6 > and reject this one as entirely broken. Maybe just a warning if > --expert is used. No complaints here. Maybe it would push the PKS admins to upgrade. I doubt anyone is interested in making the PKS code RFC compliant. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 679 bytes Desc: OpenPGP digital signature URL: From kevhilton at gmail.com Mon Jun 29 14:53:51 2009 From: kevhilton at gmail.com (Kevin Hilton) Date: Mon, 29 Jun 2009 07:53:51 -0500 Subject: SVN 5052 GPG2 Make Errors - Cygwin In-Reply-To: <96c450350906282253v1a50366fieff07d521499a109@mail.gmail.com> References: <96c450350906282253v1a50366fieff07d521499a109@mail.gmail.com> Message-ID: <96c450350906290553t27874c1fg52f80cf98e26b42@mail.gmail.com> Thanks for prompt response Revision 5054 fixes the problem :) From wk at gnupg.org Tue Jun 30 09:33:23 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 30 Jun 2009 09:33:23 +0200 Subject: Extended length APDU solved for Cardman Message-ID: <87r5x2dvlo.fsf@wheatstone.g10code.de> Hi Ludovic, After spending too much time trying to trace the USB commands of the Cardman readers using Windows under KVM I switched back to the old sniffusb tool on native Windows. I figured out how to send extended APDUs and it works now with GnuPG's internal driver and the new OpenPGP card. I have not yet tested other cards. Tested with a CM6121 and the CM4040 PCCARD reader. I still need to check wether the Cherry keyboard works the same way and maybe even try the KAAN reader. You need to switch to TPDU mode for extended length APDUs. They are send using the CCID Escape sequence 00 00 00 1A followed by the TPDU. The response is a 1A followed by the TPDU. The only problem is that you need to resync the T=1 sequence counter if the reader returns an error (which is likely). Make sure to use a NAD of 0x00. If you want to trace stuff yourself http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/tools/ccidmon.c?root=GnuPG might be useful. Should build as a standalone program; usage is ccidmod --sniffusb (Ludovic Rousseau's message of "Tue, 30 Jun 2009 11:22:32 +0200 (CEST)") References: <1149720252.1734121246353752909.JavaMail.root@spooler10-g27.priv.proxad.net> Message-ID: <87my7qc7og.fsf@wheatstone.g10code.de> On Tue, 30 Jun 2009 11:22, ludovic.rousseau at free.fr said: > You are using a proprietary command to switch the reader in TPDU mode. Is it documented somewhere by Omnikey? As usual with Omnikey stuff: Docs are hard to get and they are not eager to help developers to get their hadware working. > You should not have to play this game with the Kobil KAAN readers. They are declared as "Short and Extended APDU level exchange". I had severe problems with mine; according to people working with the Windows driver it is known that these readers have problems with extended length APDUs. I have not used mine for weeks; I'll try it later. > I am surprised you invested so much energy in supporting (limited) readers instead of using existing TPDU or extended APDU readers. The driving force is that we have the new OpenPGP cards and can't use them with laptops. The CM4040 pccard reader is widely used and I suggested it in the past to many folks; they are now using it on a daily base (including me). > You can also see the page [1] to know the readers you should recommand for use with the OpenPGP card. I know ;-) Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From kevhilton at gmail.com Tue Jun 9 09:18:43 2009 From: kevhilton at gmail.com (Kevin Hilton) Date: Tue, 09 Jun 2009 07:18:43 -0000 Subject: Errors compiling 1.4 Branch on Cygwin Message-ID: <96c450350906082315p7015f3b3o821c7c5d607e9fcd@mail.gmail.com> With the latest 1.4 branch revision 5039 and 5040 I can't seem to compile the source on cygwin. I haven't tried with earlier revisions except that I can tell you I have revision 4907 successfully compiled. Here are the errors I am getting: This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.../util/libcompat.a(srv.o): In function `getsrv': /home/admin/src/gpg/util/srv.c:64: undefined reference to `___res_query' /home/admin/src/gpg/util/srv.c:78: undefined reference to `___dn_skipname' /home/admin/src/gpg/util/srv.c:98: undefined reference to `___dn_skipname' /home/admin/src/gpg/util/srv.c:132: undefined reference to `___dn_expand' Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) collect2: ld returned 1 exit status make[2]: *** [gpgkeys_hkp.exe] Error 1 make[2]: Leaving directory `/home/admin/src/gpg/keyserver' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/admin/src/gpg' make: *** [all] Error 2 Do I have an old unresolved dependency? -- Kevin Hilton From chiaki.ishikawa at ubin.jp Mon Jun 29 07:56:37 2009 From: chiaki.ishikawa at ubin.jp (ishikawa) Date: Mon, 29 Jun 2009 14:56:37 +0900 Subject: Strange Key ID problem. : subkey id is reported where primary key id should be reported as missing? Message-ID: <4A485795.3030701@ubin.jp> (I sent this to gnupg-bugs at gnu.org a week ago, but nothing seems to happen, and so am sending this out again after a slight modification, and this time to gnupg-devel at gnupg.org. If you have seen this twice, apologies.) --- Strange key ID problems. Hi, thank you for sharing this great tool with programming community and beyond. Recently, I encountered this strange problem and I wonder if this is caused by incompatibilities or bugs in GNUPG. (After writing this summary, I now think it is a bug, but am not sure why this was not reported elsewhere. Yes, I tried searching in aim group but could not find a similar report easily. [not that I am familiar with aim group mail archive search feature, so I may have missed it.]) I encountered similar problems with this particular key in the last few days under linux and windows vist (cygwin), and so the problem is not limited to a particular platform, it seems. Background: I obtained a signed tar ball of mozilla thunderbird mailer source. http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/3.0b2/source/ In the above URL, you can find a bzipped tar ball and a signature (.asc). It is signed by a PGP (or GPG) key. It seems that it was signed by GnuPG v1.4.1 thunderbird-3.0b2-source.tar.bz2.asc The contents is shown below. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin) iD8DBQBJpQExtXtUhBd4X+gRAn+GAJ9IDT++Y+Js54fyiSqxDZg3YtoMdQCeOvDh kTD2CVzG2VKHJKSbv9qUgN4= =2pFg -----END PGP SIGNATURE----- Initially, when I tried to verify the signature, I didn't have the signature key and GPG (my version under linux is 1.4.9) complained that the key is not found. $ gpg --version gpg (GnuPG) 1.4.9 The problem: When GPG mentioned that it could not find the key, it printed the missing signature key ID as 17785FE8 So I tried to obtain the key using gpg with arguments such as --keyserver pgp.mit.edu -recv-keys 17785FE8 --keyserver pgp.nic.ad.jp -recv-keys 17785FE8 to no avail. The key could not be found there. Hmm, a problem, I thought. After browsing web pages, I noticed that the signature key has an e-mail address of the form "some-string-for -release-ID at mozilla.org". When I search the key using this string (--search-keys @mozilla.org), GPG found several hits, and I chose the most recent key with so called "release at mozilla.org" BUT WITH A DIFFERENT KEY ID (?), thinking it would not hurt to have a new such key anyway for later use. (Below I edited the messages slightly to remove Japanese characters. I use Japanese locale.) gpg --keyserver pgp.nic.ad.jp --search-keys @mozilla.org .... (1) Alexandro Colorado (Gmail) Alexandro Colorado (Mozilla Mexico) Alexandro Colorado (Grupo de usuarios Linux Tabasco) Alexandro Colorado (1 year OOoES individual signature) L. David Baron L. David Baron L. David Baron L. David Baron L. David Baron 1024 bit DSA key 2380E70A, created: 2007-12-25 (3) Mozilla Software Releases <=== 1024 bit DSA key 812347DD, created: 2007-07-17 (4) Mozilla Software Releases 1024 bit DSA key 0E3606D9, created: 2005-09-29 ... I chose (3) above. But note its key (ID?) is 812347DD. Then, TO MY SURPRISE, when I ran gpg --verify again with this key with a seemingly different ID, the verification succeeded! To wit: $ env LC_ALL=C LANG=C gpg --verify *.asc gpg: Signature made Wed Feb 25 17:28:33 2009 JST using DSA key ID 17785FE8 gpg: Good signature from "Mozilla Software Releases " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 8D6F 1BA4 A340 4DDB 3F2F D080 7447 4499 8123 47DD Subkey fingerprint: 3338 E6BA FF10 3B3D A6A9 E424 B57B 5484 1778 5FE8 ishikawa at ubi7f-w3:/extra/ishikawa/download/TB-3$ Note that thye key ID of the signature (printed on the first line) is 17785FE8 as in the original state, but now the signature succeeded. But then I am very confused. This key id was searched and could not be found in the server. The server responded with a set of keys when I searched for "@mozilla.org", and when I chose a key from the found keys, it seemed to have a different key "812347DD". What is going on here? Is there an incompatibility between 1.4.1 and 1.4.9 regarding the representation of key ID? Or are keys 17785FE8 and 812347DD actually the same key with a disguise? I am perplexed here. After writing all this, I realized the following. But I am not sure if this is intended or not. I think it is a bug somewhere. When gpg (1.4.9) printed out 812347DD in the list of found keys in response to my search request, it is not the key id, but it seems to be the last hexadecimal digits of "PRIMARY key finger print". Oh wait, the 17785FE8 printed as the missing key ID is the last digits of "SUBKEY fingerprint" !? If the key ID printed as missing is the SUBKEY fingerprint, and the --recev-key and friends expect "PRIMARY key fingerprint", then I don't think the search will ever succeed. Or will it? (I just checked to see if --recv-keys 812347DD will succeed. It did! It found the intended "release at mozilla.org" key and since the key has not changed, nothing was done.) I think we have a very serious usability problem here. I don't know if this is the problem of 1.4.9 or the signature and key created by 1.4.1 for this particular key. TIA PS: Previously, when I tried to verify signatures of various open source archives and the signature keys were missing, the IDs printed could be used to fetch the keys from PGP keyservers. This is the first time the printed key ID could not be fetched, and after the above steps, the validation could be done, but quite in an unexpected manner. From chiaki.ishikawa at ubin.jp Mon Jun 29 13:08:57 2009 From: chiaki.ishikawa at ubin.jp (ishikawa) Date: Mon, 29 Jun 2009 20:08:57 +0900 Subject: Strange Key ID problem. : subkey id is reported where primary key id should be reported as missing? In-Reply-To: <87ocs7frna.fsf@wheatstone.g10code.de> References: <4A485795.3030701@ubin.jp> <87ocs7frna.fsf@wheatstone.g10code.de> Message-ID: <4A48A0C9.2000603@ubin.jp> Dear Werner Koch, Thank you for your prompt feedback. On (06/29/2009 04:03 PM), Werner Koch wrote: > On Mon, 29 Jun 2009 07:56, chiaki.ishikawa at ubin.jp said: > >> (After writing this summary, I now think it is a bug, but am not sure > > Yes it is a bug. But not in GnupG but in tghe keyserver software. > Oh, I didn't realize this. It is very difficult to figure this out as this stands. >> So I tried to obtain the key using gpg with arguments such as >> --keyserver pgp.mit.edu -recv-keys 17785FE8 >> --keyserver pgp.nic.ad.jp -recv-keys 17785FE8 >> to no avail. > > Both keyservers run old and non-OpenPGP compatible software - Do not use > them. > > I tried this too (using gpg2 but that doesn't matter) > > $ gpg2 --recv-key 17785FE8 > gpg: requesting key 17785FE8 from hkp server keys.gnupg.net > gpg: key 812347DD: public key "Mozilla Software [...] > gpg: Total number processed: 1 > gpg: imported: 1 > > So everything is fine. The key was taken from one of the SKS keyservers > to which keys.gnupg.net resolve. If you now look at the key: > > $ gpg2 --list-key 17785FE8 > pub 1024D/812347DD 2007-07-17 [expires: 2009-07-16] > uid Mozilla Software Releases > sub 1024D/17785FE8 2007-07-17 [expires: 2009-07-16] > sub 2048g/1B0EC2E7 2007-07-17 [expires: 2009-07-16] > > You will notice that 17785FE8 is a signing subkey. The old pks software > can't handle this and breaks the key. > > We do have this problem for years now and at least the admins of > pgp.mit.edu don't care about it and keep on running this broken > software. > > I am now considering whether we should detect > Server: pks_www/0.9.6 > and reject this one as entirely broken. Maybe just a warning if > --expert is used. I think that maybe it is a good idea to have this rejection. Then at least, the user of gpg will try to move to the sites that run newer software. (I wonder though why my setup didn't access keys.gnupg.net automatically. Maybe the other PCs on which gpg worked to fetch such keys were configured properly to access newer sites whereas the said PCs in my post were configured lately with gpg and so I had to type in keyserver names manually (I didn't have the time to edit the configuration file. I just tried to verify the archives on the fly.) Also, such messages *may* encourage the admins of sites that run old software to move on to the newer software when a system upgrade is attempted. Just a chance. So I am for such a change. Thank you again for your explanation. Sincerely, Chiaki Ishikawa > Shalom-Salam, > > Werner > From ludovic.rousseau at free.fr Tue Jun 30 11:22:32 2009 From: ludovic.rousseau at free.fr (Ludovic Rousseau) Date: Tue, 30 Jun 2009 11:22:32 +0200 (CEST) Subject: Extended length APDU solved for Cardman In-Reply-To: <1707815355.1718821246349562052.JavaMail.root@spooler10-g27.priv.proxad.net> Message-ID: <1149720252.1734121246353752909.JavaMail.root@spooler10-g27.priv.proxad.net> ----- "Werner Koch" a ?crit : > Hi Ludovic, Hello Werner, > After spending too much time trying to trace the USB commands of the > Cardman readers using Windows under KVM I switched back to the old > sniffusb tool on native Windows. > > I figured out how to send extended APDUs and it works now with > GnuPG's > internal driver and the new OpenPGP card. I have not yet tested > other > cards. Tested with a CM6121 and the CM4040 PCCARD reader. I still > need > to check wether the Cherry keyboard works the same way and maybe even > try the KAAN reader. > > You need to switch to TPDU mode for extended length APDUs. They are > send using the CCID Escape sequence 00 00 00 1A followed by the TPDU. > The response is a 1A followed by the TPDU. The only problem is that > you > need to resync the T=1 sequence counter if the reader returns an > error > (which is likely). Make sure to use a NAD of 0x00. You are using a proprietary command to switch the reader in TPDU mode. Is it documented somewhere by Omnikey? You should not have to play this game with the Kobil KAAN readers. They are declared as "Short and Extended APDU level exchange". I am surprised you invested so much energy in supporting (limited) readers instead of using existing TPDU or extended APDU readers. You can also see the page [1] to know the readers you should recommand for use with the OpenPGP card. > If you want to trace stuff yourself > http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/tools/ccidmon.c?root=GnuPG > might be useful. Should build as a standalone program; usage is > > ccidmod --sniffusb