From Henry.Story at Sun.COM Tue Apr 1 09:50:39 2008 From: Henry.Story at Sun.COM (Henry Story) Date: Tue, 01 Apr 2008 09:50:39 +0200 Subject: RDFAuth: a sketch of a simple authentication protol Message-ID: Dear GNU-PG users and experts, I recently posted a proposal for a very simple HTTP based protocol to build on GPG web of trust concepts by combining these with the linked data network [1] effect of the semantic web, and simple REST architecture concepts. Here is the introduction [[ Here is a proposal for an authentication scheme that is even simpler than OpenId, more secure, more RESTful, with fewer points of failure and fewer points of control, that is needed in order to make Open Distributed Social Networks with privacy controls possible. ]] http://blogs.sun.com/bblfish/entry/rdfauth_sketch_of_a_buzzword I am not a cryptography expert, but I make essential use of PGP in this sketch, so I was looking for feedback from this community, as well as REST and HTTP experts. I know there is something really powerful lying here to be discovered. Please give us feedback and ideas for improvements. Or just let us know that we are wrong. Any feedback is welcome :-) Henry [1] http://en.wikipedia.org/wiki/Linked_Data Home page: http://bblfish.net/ From Axel.Thimm at ATrpms.net Tue Apr 1 13:23:50 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 1 Apr 2008 14:23:50 +0300 Subject: gpg-agent/ssh-add asking for passphrase at first usage In-Reply-To: <20080331041759.GG18510@inocybe.teonanacatl.org> References: <20080331004621.GB7497@puariko.nirvana> <20080331041759.GG18510@inocybe.teonanacatl.org> Message-ID: <20080401112350.GB13632@puariko.nirvana> On Mon, Mar 31, 2008 at 12:17:59AM -0400, Todd Zullinger wrote: > Axel Thimm wrote: > > some years ago I did create a nice "gpg-agent --enable-ssh-support" > > setup that would register ssh keys with the agent, but the agent > > would only ask for the passphrase when ssh would try a connection. > > > > Now I upgraded my system and this doesn't work anymore. > > What exactly doesn't work? You don't get any password prompt for > either your ssh nor gpg keys? Or you get the prompt for both now > instead of having your ssh key automatically added? Or something else > entirely? I tried to explain, but maybe the mail was too long: Previously, right after logging in I would see the keys with ssh-add -l, but I would only be asked for the passphrase on their first usage. Now they are not listed and if I try to add them I'm asked for the pssphrase immediately. > > Now my questions are: > [...] > > - *why* did it break with the update? The old system has gnupg 2.0.8 > > and the new one 2.0.9. But the Changelog doesn't indicate anything > > that would make these two behave differently. > > Is the new system running another agent, like the seahorse agent? I > think that might be on by default now, and it provides similar > functionlity to gpg-agent and ssh-agent. Maybe it's causing problems? I'm invoking gpg-agent directly in the ssh-agent replacment scrip (see my OP). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevhilton at gmail.com Tue Apr 1 16:47:58 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Tue, 1 Apr 2008 09:47:58 -0500 Subject: Whirlpool Hash Message-ID: <96c450350804010747q21de35fbpbdf17a78d99d743d@mail.gmail.com> Has anyone written a patch that would allow whirlpool as an available hash algorithm for use with gnupg? -- Kevin Hilton From jmoore3rd at bellsouth.net Tue Apr 1 18:12:55 2008 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Tue, 01 Apr 2008 12:12:55 -0400 Subject: Whirlpool Hash In-Reply-To: <96c450350804010747q21de35fbpbdf17a78d99d743d@mail.gmail.com> References: <96c450350804010747q21de35fbpbdf17a78d99d743d@mail.gmail.com> Message-ID: <47F25F07.6070501@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Kevin Hilton wrote: > Has anyone written a patch that would allow whirlpool as an available > hash algorithm for use with gnupg? The addition of Whirlpool would require the effective 'patching' of 11 Files. I am fooling with it in My spare time but haven't completed it as yet. I haven't devoted much time to this as there would be very few instances where it would be practical to implement. What would be accomplished by using a Hash that would prevent anyone from verifying My Sig? JOHN ;) Timestamp: Tuesday 01 Apr 2008, 12:11 --400 (Eastern Daylight Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.5.0-svn4732: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: https://www.gswot.org Comment: Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJH8l8GAAoJEBCGy9eAtCsP6fgIAIVgRvdeMXSty+3/EFcMQBhs 2I3u3eVCeEeX4gxP+LZO6zJ+fiCOgRYJ3/Fq6bJ6HhUFQjTC3hBeTamdPbjlzQHC xkvb90VBllqfP7cMN5kYJYZBEChfbsjn9IyZ+97+gyhlBpKMXVroRvykz9iSNRPe OUYeFkcVIk9V3YilGoVGlWE9kjunQ8TZFmHGaK75ntpZAIkOdm2vgW+fE1xIYacu 3SYuxBS3VidcTvAOVtVILsmKnwr95+9aCOP8ymum7ZUa2CdDUgPVp0wgUeZDBQla tCJPB9SkIesF0AwvdGVrBnuZWzbFa1ewOZON1r6eQtagdX2RiC9vPPLO0tXJcuI= =qGpS -----END PGP SIGNATURE----- From kevhilton at gmail.com Tue Apr 1 18:39:15 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Tue, 1 Apr 2008 11:39:15 -0500 Subject: Whirlpool Hash In-Reply-To: <96c450350804010747q21de35fbpbdf17a78d99d743d@mail.gmail.com> References: <96c450350804010747q21de35fbpbdf17a78d99d743d@mail.gmail.com> Message-ID: <96c450350804010939r62cd58d6gc6015e36a9b22539@mail.gmail.com> Let us know when you are done with the patch. I'd be interested in trying it out -- that would make one person who could verify your signature! From wk at gnupg.org Tue Apr 1 18:47:21 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 01 Apr 2008 18:47:21 +0200 Subject: Whirlpool Hash In-Reply-To: <96c450350804010747q21de35fbpbdf17a78d99d743d@mail.gmail.com> (Kevin Hilton's message of "Tue, 1 Apr 2008 09:47:58 -0500") References: <96c450350804010747q21de35fbpbdf17a78d99d743d@mail.gmail.com> Message-ID: <87ve31wmhy.fsf@wheatstone.g10code.de> On Tue, 1 Apr 2008 16:47, kevhilton at gmail.com said: > Has anyone written a patch that would allow whirlpool as an available > hash algorithm for use with gnupg? Whirlpool is not specified by OpenPGP and thus not supported by gpg. FWIW, Libgcrypt has support for Whirlpool and thus can be used by other applications (e.g. S/MIME as supported by gpgsm) Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Tue Apr 1 19:12:23 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 1 Apr 2008 13:12:23 -0400 Subject: Whirlpool Hash In-Reply-To: <96c450350804010747q21de35fbpbdf17a78d99d743d@mail.gmail.com> References: <96c450350804010747q21de35fbpbdf17a78d99d743d@mail.gmail.com> Message-ID: <20080401171222.GA6478@jabberwocky.com> On Tue, Apr 01, 2008 at 09:47:58AM -0500, Kevin Hilton wrote: > Has anyone written a patch that would allow whirlpool as an available > hash algorithm for use with gnupg? Not that I know of. Note that Whirlpool is not specified for OpenPGP, so that is a major barrier. There is a project to add Whirlpool to OpenPGP going on at the moment (also the Camellia cipher, by the way). When that happens, Whirlpool makes more sense than it does now. David From noc at phibee.net Tue Apr 1 20:50:34 2008 From: noc at phibee.net (Phibee Network Operation Center) Date: Tue, 01 Apr 2008 20:50:34 +0200 Subject: sign a public key ? Message-ID: <47F283FA.1030003@phibee.net> Hi i use this for crypt a tar archives: /usr/bin/gpg --recipient Stefan --encrypt /tmp/backup.tgz i use the public key of stefan for crypt, but when i start he request all time a "o" (Yes) and say me (sorry in french) : =================================================== [root at gw tmp]# /usr/bin/gpg --recipient Stefan --encrypt /tmp/backup.tgz gpg: DCC8B9Z4: Rien ne dit que la cl? appartient vraiment ? l'utilisateur nomm?. pub 2048g/DCC8B9Z4 2008-03-25 Stefan Empreinte de la cl? principale: XX Empreinte de la sous-cl?: XX Il n'est PAS certain que la cl? appartient ? la personne nom?e dans le nom d'utilisateur. Si vous savez *vraiment* ce que vous faites, vous pouvez r?pondre oui ? la prochaine question. Utiliser cette cl? quand m?me ? (o/N) ======================================================== He said that it's not sure that th key are the key of Stefan ..... can i write for all time a "Y" or what is the exact process ? thanks for your help From allen.schultz at gmail.com Wed Apr 2 01:29:36 2008 From: allen.schultz at gmail.com (Allen Schultz) Date: Tue, 1 Apr 2008 17:29:36 -0600 Subject: Office Outlook 2003 and GnuPG Message-ID: <3f34f8420804011629o28a6e7e6q606129489185c2f7@mail.gmail.com> What is the recommended frontend/plugin to Office Outlook 2003 for GnuPG that will allow the user (my friend in this case) to manually select Encrypt/Sign rather than have it automatically do that on all his messages. He wants that choice. I found one with it hiding in the Tools menu, but he wants it visible while writing/typing the message. Allen From JPClizbe at tx.rr.com Wed Apr 2 03:43:53 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Tue, 01 Apr 2008 20:43:53 -0500 Subject: sign a public key ? In-Reply-To: <47F283FA.1030003@phibee.net> References: <47F283FA.1030003@phibee.net> Message-ID: <47F2E4D9.5010104@tx.rr.com> Phibee Network Operation Center wrote: > Hi > > i use this for crypt a tar archives: > > /usr/bin/gpg --recipient Stefan --encrypt /tmp/backup.tgz > can i write for all time a "Y" or what is the exact process ? /usr/bin/gpg --batch --yes --recipient Stefan --encrypt /tmp/backup.tgz From the man page: --batch --no-batch Use batch mode. Never ask, do not allow interactive com- mands. --no-batch disables this option. --yes Assume "yes" on most questions. --no Assume "no" on most questions. -- John P. Clizbe Inet: JPClizbe (a) tx DAWT rr DAHT con Ginger Bear Networks hkp://keyserver.gingerbear.net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 657 bytes Desc: OpenPGP digital signature URL: From jmoore3rd at bellsouth.net Wed Apr 2 04:08:06 2008 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Tue, 01 Apr 2008 22:08:06 -0400 Subject: Office Outlook 2003 and GnuPG In-Reply-To: <3f34f8420804011629o28a6e7e6q606129489185c2f7@mail.gmail.com> References: <3f34f8420804011629o28a6e7e6q606129489185c2f7@mail.gmail.com> Message-ID: <47F2EA86.5090401@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Allen Schultz wrote: > What is the recommended frontend/plugin to Office Outlook 2003 for > GnuPG that will allow the user (my friend in this case) to manually > select Encrypt/Sign rather than have it automatically do that on all > his messages. He wants that choice. I found one with it hiding in the > Tools menu, but he wants it visible while writing/typing the message. Why not try GPGshell: http://www.jumaros.de/rsoft/index.html This will provide both a Tray Tool, Key Management & the ability to Encrypt/Decrypt Files. JOHN ;) Timestamp: Tuesday 01 Apr 2008, 22:07 --400 (Eastern Daylight Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.5.0-svn4732: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: https://www.gswot.org Comment: Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJH8uqFAAoJEBCGy9eAtCsPXIkH/35ewbdZCfKIH5aBGOMp1yOV +2SlKh0y3zPwjXwt4OtM8LFETMkHUsXbKlh9V18/cbaJmiPIJAjk33tW1jqJmmTi Lhu8V9EbXjCBazMe0R36VBrEckLjfDRDLPEqUt0kTmSo42eniAa9jnMTAvcRjHZd WeB1Z0hvoMv3VQzgOJ7cq/Aw48di94kjyNvPtsTco7625h9QdPkxWWbIVQ9ffJtu WPyU/ig1NoYAah1GIiLkgSDEPkV39fWs5b0zvcYOFxZyUwkJBI/3r0tPOfzgR3JK d29aI71DfPNsGEVgvuJhUwr5FwwZeZMznMf8UX/qyT5SvHJhANq4DcDXNUuA1BM= =e3ly -----END PGP SIGNATURE----- From noc at phibee.net Wed Apr 2 06:30:43 2008 From: noc at phibee.net (Phibee Network Operation Center) Date: Wed, 02 Apr 2008 06:30:43 +0200 Subject: sign a public key ? In-Reply-To: <47F2E4D9.5010104@tx.rr.com> References: <47F283FA.1030003@phibee.net> <47F2E4D9.5010104@tx.rr.com> Message-ID: <47F30BF3.4090104@phibee.net> John Clizbe a ?crit : > Phibee Network Operation Center wrote: > >> Hi >> >> i use this for crypt a tar archives: >> >> /usr/bin/gpg --recipient Stefan --encrypt /tmp/backup.tgz >> > > > >> can i write for all time a "Y" or what is the exact process ? >> > > /usr/bin/gpg --batch --yes --recipient Stefan --encrypt /tmp/backup.tgz > > > > From the man page: > > --batch > > --no-batch > Use batch mode. Never ask, do not allow interactive com- > mands. --no-batch disables this option. > > --yes Assume "yes" on most questions. > > --no Assume "no" on most questions. > > > > Thanks for your answer, but i have read the man and tested this solution ... i have a : [root at gw tmp]# /usr/bin/gpg --batch --yes --recipient Stefan --encrypt /tmp/backup.tgz gpg: DCC8B9Z4: Rien ne dit que la cl? appartient vraiment ? l'utilisateur nomm?. gpg: /tmp/backup.tgz: encryption failed: cl? publique inutilisable Failed :=< From JPClizbe at tx.rr.com Wed Apr 2 06:43:09 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Tue, 01 Apr 2008 23:43:09 -0500 Subject: sign a public key ? In-Reply-To: <47F30BF3.4090104@phibee.net> References: <47F283FA.1030003@phibee.net> <47F2E4D9.5010104@tx.rr.com> <47F30BF3.4090104@phibee.net> Message-ID: <47F30EDD.90809@tx.rr.com> Phibee Network Operation Center wrote: > John Clizbe a ?crit : >> Phibee Network Operation Center wrote: >>> Hi >>> >>> i use this for crypt a tar archives: >>> >>> /usr/bin/gpg --recipient Stefan --encrypt /tmp/backup.tgz >>> can i write for all time a "Y" or what is the exact process ? >>> >> /usr/bin/gpg --batch --yes --recipient Stefan --encrypt /tmp/backup.tgz >> > Thanks for your answer, but i have read the man and tested this solution ... > > i have a : > > [root at gw tmp]# /usr/bin/gpg --batch --yes --recipient Stefan --encrypt > /tmp/backup.tgz > gpg: DCC8B9Z4: Rien ne dit que la cl? appartient vraiment ? l'utilisateur > nomm?. > gpg: /tmp/backup.tgz: encryption failed: cl? publique inutilisable Try signing his key with a local signature: gpg --edit-key Stefan lsign or adding the --always-trust option to the command-line /usr/bin/gpg --batch --yes --always-trust --recipient Stefan \ --encrypt /tmp/backup.tgz I think a local sig is the better option. -- John P. Clizbe Inet: JPClizbe (a) tx DAWT rr DAHT con Ginger Bear Networks hkp://keyserver.gingerbear.net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 657 bytes Desc: OpenPGP digital signature URL: From email at sven-radde.de Wed Apr 2 07:40:56 2008 From: email at sven-radde.de (Sven Radde) Date: Wed, 02 Apr 2008 07:40:56 +0200 Subject: Office Outlook 2003 and GnuPG In-Reply-To: <3f34f8420804011629o28a6e7e6q606129489185c2f7@mail.gmail.com> References: <3f34f8420804011629o28a6e7e6q606129489185c2f7@mail.gmail.com> Message-ID: <1207114856.6313.5.camel@carbon> Hi! Am Dienstag, den 01.04.2008, 17:29 -0600 schrieb Allen Schultz: > What is the recommended frontend/plugin to Office Outlook 2003 I think the one coming with gpg4win is fine? I am running Office 2007 at work in the meantime but AFAIR I used it when we still had 2003. And I definitely did never have a "full auto" mode enabled. cu, Sven From john.fitzpatrick at centralbank.ie Wed Apr 2 15:34:38 2008 From: john.fitzpatrick at centralbank.ie (JohnnyF1) Date: Wed, 2 Apr 2008 06:34:38 -0700 (PDT) Subject: 1.4.7 <-> 1.4.8 compatibility Message-ID: <16418735.post@talk.nabble.com> Hi, could anyone tell me if there are many problems with encrypting using 1.4.7 and decrypting in 1.4.8 and vice versa? I am aware of this one in relation to signing: http://www.nabble.com/SHA-224-problem-to14038812.html#a14040484 on the SHA-224 problem. Thank you in Advance John -- View this message in context: http://www.nabble.com/1.4.7-%3C-%3E-1.4.8-compatibility-tp16418735p16418735.html Sent from the GnuPG - User mailing list archive at Nabble.com. From rjh at sixdemonbag.org Wed Apr 2 15:52:35 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 02 Apr 2008 08:52:35 -0500 Subject: 1.4.7 <-> 1.4.8 compatibility In-Reply-To: <16418735.post@talk.nabble.com> References: <16418735.post@talk.nabble.com> Message-ID: <47F38FA3.6070708@sixdemonbag.org> JohnnyF1 wrote: > could anyone tell me if there are many problems with encrypting using 1.4.7 > and decrypting in 1.4.8 and vice versa? With the exception of RSA+SHA224 signatures, I know of none. From dshaw at jabberwocky.com Wed Apr 2 16:24:43 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 2 Apr 2008 10:24:43 -0400 Subject: 1.4.7 <-> 1.4.8 compatibility In-Reply-To: <16418735.post@talk.nabble.com> References: <16418735.post@talk.nabble.com> Message-ID: <4283CE7D-8403-43A5-83CF-B1B804ABEE3D@jabberwocky.com> On Apr 2, 2008, at 9:34 AM, JohnnyF1 wrote: > > Hi, > > could anyone tell me if there are many problems with encrypting > using 1.4.7 > and decrypting in 1.4.8 and vice versa? > I am aware of this one in relation to signing: > http://www.nabble.com/SHA-224-problem-to14038812.html#a14040484 > on the SHA-224 problem. No problems that have been reported. Note that we're up to version 1.4.9 now though. David From vedaal at hush.com Wed Apr 2 17:52:54 2008 From: vedaal at hush.com (vedaal at hush.com) Date: Wed, 02 Apr 2008 11:52:54 -0400 Subject: 1.4.7 <-> 1.4.8 compatibility Message-ID: <20080402155254.F3E3311803C@mailserver5.hushmail.com> David Shaw dshaw at jabberwocky.com wrote on Wed Apr 2 16:24:43 CEST 2008 : > Note that we're up to version 1.4.9 now though. the gnupg website http://www.gnupg.org/ and all the download links http://www.gnupg.org/download/index.en.html still lists 1.4.8 and doesn't mention 1.4.9 vedaal any ads or links below this message are added by hushmail without my endorsement or awareness of the nature of the link -- Click here for fast, reliable, quality printing services! http://tagline.hushmail.com/fc/REAK6ZBP0G5EMbd348ni2qiW5XUNwVgUEz4Hw0OwovmtVqPvrv94PF/ From neal.dudley at utoledo.edu Wed Apr 2 18:07:55 2008 From: neal.dudley at utoledo.edu (Neal Dudley) Date: Wed, 02 Apr 2008 11:07:55 -0500 Subject: Keysigning request Message-ID: Is there anyone in the Chicago area who would be willing and able to meet me to sign my GPG key? Yes, I have looked on Biglumber and contacted several people from there. Yes, I have searched for WoT groups in the area. If you, or someone you know, is in the Chicago area and would be able to meet with me to id me and sign my key, I would very much appreciate it. Thank you for your time. From shavital at mac.com Wed Apr 2 18:12:21 2008 From: shavital at mac.com (Charly Avital) Date: Wed, 02 Apr 2008 12:12:21 -0400 Subject: 1.4.7 <-> 1.4.8 compatibility In-Reply-To: <20080402155254.F3E3311803C@mailserver5.hushmail.com> References: <20080402155254.F3E3311803C@mailserver5.hushmail.com> Message-ID: <47F3B065.1000502@mac.com> vedaal at hush.com wrote the following on 4/2/08 11:52 AM: [...] > the gnupg website > http://www.gnupg.org/ > and all the download links > http://www.gnupg.org/download/index.en.html > still lists 1.4.8 > and doesn't mention 1.4.9 > > > vedaal Concur. It seems that the web site has not been updated with the announcement of the availability of 1.4.9, that was posted to the list. Charly From wk at gnupg.org Wed Apr 2 19:45:00 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Apr 2008 19:45:00 +0200 Subject: 1.4.7 <-> 1.4.8 compatibility In-Reply-To: <20080402155254.F3E3311803C@mailserver5.hushmail.com> (vedaal@hush.com's message of "Wed, 02 Apr 2008 11:52:54 -0400") References: <20080402155254.F3E3311803C@mailserver5.hushmail.com> Message-ID: <87wsngqhgj.fsf@wheatstone.g10code.de> On Wed, 2 Apr 2008 17:52, vedaal at hush.com said: > still lists 1.4.8 > and doesn't mention 1.4.9 Sorry, the website is pretty outdated. This is due to the WML stuff which requires a chroot environment which more or less got lost during the hardware change. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Wed Apr 2 19:53:16 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Apr 2008 19:53:16 +0200 Subject: Siemens card reader In-Reply-To: <1206885127.5177.5.camel@dublin.local> ("Reinhard =?utf-8?Q?M?= =?utf-8?Q?=C3=BCller=22's?= message of "Sun, 30 Mar 2008 15:52:07 +0200") References: <1206885127.5177.5.camel@dublin.local> Message-ID: <87sky4qh2r.fsf@wheatstone.g10code.de> On Sun, 30 Mar 2008 15:52, reinhard.mueller at bytewise.at said: > Any hint? Please add thse options --debug-ccid-driver --debug-ccid-driver so get more output (yes, give it twice). Use a test card, so that your PIN is not visible in the output. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From jmoore3rd at bellsouth.net Wed Apr 2 21:16:39 2008 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Wed, 02 Apr 2008 15:16:39 -0400 Subject: 1.4.7 <-> 1.4.8 compatibility In-Reply-To: <47F3B065.1000502@mac.com> References: <20080402155254.F3E3311803C@mailserver5.hushmail.com> <47F3B065.1000502@mac.com> Message-ID: <47F3DB97.8000507@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Charly Avital wrote: > vedaal at hush.com wrote the following on 4/2/08 11:52 AM: > [...] > >> the gnupg website >> http://www.gnupg.org/ >> and all the download links >> http://www.gnupg.org/download/index.en.html >> still lists 1.4.8 >> and doesn't mention 1.4.9 > Concur. It seems that the web site has not been updated with the > announcement of the availability of 1.4.9, that was posted to the list. Last I checked the Download Manager also shows that 1.4.8 is being Downloaded. :-\ JOHN ;) Timestamp: Wednesday 02 Apr 2008, 15:16 --400 (Eastern Daylight Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.5.0-svn4735: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: https://www.gswot.org Comment: Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJH89uWAAoJEBCGy9eAtCsPpicH/A7JbBe/c9ZoGW59B8w3n6TA +/P/mHAy9hWSLfxY5wjXimJwl2NmT2Ui9wrpUVHhMFkSP8w/qY4Ju4KMwUII/TDM KX5sFfWfel5vTXqSQRZ1R3F4lJVrVx3Fno/xCyBar/yUkCF8DBskRRRj+RX7aoq4 h4g5P6EDT57H/vpUZ+i+mN4JWQO7uJuOa0SQzCHVrEz9T4V/QGcjbKfB0F2ZP2h9 D1MaanmWFSer6Cte3dtLbz+qtVFz0z9jko27rRkz1It+SC9bxunxS5o3SQjzLbb4 I+i8JyYOo0+L0AI7gytIaXGiLmGDxj5hJr8W6Tq3OHa6BXY0V2KmGdeOtEgqR/w= =0NkJ -----END PGP SIGNATURE----- From Vern.Bradner at cit.com Wed Apr 2 20:47:28 2008 From: Vern.Bradner at cit.com (Vern.Bradner at cit.com) Date: Wed, 2 Apr 2008 14:47:28 -0400 Subject: 1.4.9 availability Message-ID: <58542869CBA00141AB7E2F357F0F3FA303F39C08@crplivexc54.citnet.cit.com> Hi, I can see that 1.4.9 binaries are available at ftp://ftp.gnupg.org/gcrypt/binary/ But it looks like 1.4.8 is at http://www.gnupg.org/download/ I have tended to use http://www.gnupg.org/download/ as my official location for binaries in the past. Should I not? Thanks, Vern Vern Bradner Vern.Bradner at cit.com Voice: 973-535-3562 Cellular: 732-236-5537 From vedaal at hush.com Wed Apr 2 22:10:08 2008 From: vedaal at hush.com (vedaal at hush.com) Date: Wed, 02 Apr 2008 16:10:08 -0400 Subject: 1.4.9 (IDEA not working?) Message-ID: <20080402201009.2BD2511803C@mailserver5.hushmail.com> have installed gnupg 1.4.9 using the windows binary, and IDEA no longer loads have tried this again on a usb drive, replacing all the gnupg 1.4.8 files with 1.4.9 files, but leaving the idea.dll, gpg.conf, keyrings and trust db the same as they were for 1.4.8 and even tested it before the replacement 1.4.8 loads IDEA 1.4.9 does not here is my gpg.conf in case i overlooked anything ##gpg2go drive comment "Acts of Kindness better the World, and protect the Soul" keyring v:\gnupg\pubring.gpg secret-keyring v:\gnupg\secring.gpg no-default-keyring trustdb-name v:\gnupg\trustdb.gpg cipher-algo TWOFISH digest-algo SHA256 #digest-algo SHA1 compress-algo ZIP homedir v:\gnupg load-extension v:\gnupg\idea.dll #local-user 0x5AA20C866A589A97! #hidden-encrypt-to 0x5AA20C866A589A97 s2k-cipher-algo twofish s2k-digest-algo SHA256 cert-digest-algo SHA256 #digest-algo sha1 #digest-algo ripemd160 verbose verbose ignore-crc-error ignore-mdc-error show-session-key expert #throw-keyids #try-all-secrets #default-key 6A589A97! default-key D35FB186 (v:\ is the truecrypt drive letter i use for volume that has gnupg and the keyrings) can anyone else confirm this, or did i make a mistake somnehwere (other than still using a v3 key and idea ;-)) ) TIA, vedaal any ads or links below this message are added by hushmail without -- Click here to choose from a huge selection of shipping supplies! http://tagline.hushmail.com/fc/REAK6ZBPnMblQux3ayDSua5qXy6KnlPR1TiJywFAh70Sdppg1Q6tLB/ my endorsement or awareness of the nature of the link From vedaal at hush.com Wed Apr 2 22:13:19 2008 From: vedaal at hush.com (vedaal at hush.com) Date: Wed, 02 Apr 2008 16:13:19 -0400 Subject: 1.4.9 IDEA still works,// sorry, my mistake Message-ID: <20080402201319.5D59911803C@mailserver5.hushmail.com> sorry, a silly oversight on my part, ;-(( IDEA loads fine on 1.4.9 vedaal any ads or links below this message are added by hushmail without -- Click to recieve credit card help and get out of debt fast. http://tagline.hushmail.com/fc/REAK6ZBOk4NIwhYiT5hHUXjgn2GYzFMx1ahERXmgLhbVQ6NHRxQfyn/ my endorsement or awareness of the nature of the link From lists at michel-messerschmidt.de Wed Apr 2 23:58:06 2008 From: lists at michel-messerschmidt.de (Michel Messerschmidt) Date: Wed, 2 Apr 2008 23:58:06 +0200 Subject: Using CCID and PCSC Message-ID: <20080402215806.GA1013@ryu.matrix> Hello, is there a possibility to force gnupg 2 to use the internal CCID smartcard driver even if pcscd is running (something like the --disable-ccid option but for pcsc) ? I have a SCM SPR532 reader and like to use the pinpad. But it's deactivated if pcscd is running. Thanks, Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: Digital signature URL: From mlisten at hammernoch.net Thu Apr 3 07:30:32 2008 From: mlisten at hammernoch.net (=?ISO-8859-1?Q?Ludwig_H=FCgelsch=E4fer?=) Date: Thu, 03 Apr 2008 07:30:32 +0200 Subject: 1.4.9 availability In-Reply-To: <58542869CBA00141AB7E2F357F0F3FA303F39C08@crplivexc54.citnet.cit.com> References: <58542869CBA00141AB7E2F357F0F3FA303F39C08@crplivexc54.citnet.cit.com> Message-ID: <47F46B78.70501@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Vern.Bradner at cit.com wrote on 02.04.2008 20:47 Uhr: > Hi, > > I can see that 1.4.9 binaries are available at > ftp://ftp.gnupg.org/gcrypt/binary/ > > But it looks like 1.4.8 is at http://www.gnupg.org/download/ > > I have tended to use http://www.gnupg.org/download/ as my official > location for binaries in the past. Should I not? Well, I tried to point you to the archives, but http://lists.gnupg.org/pipermail/ gives a 403 So nothing else leaves than to cite Werner Koch from yesterday: > Sorry, the website is pretty outdated. This is due to the WML stuff > which requires a chroot environment which more or less got lost during > the hardware change. Seems the permissions on the archives also got lost. HTH Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBR/Rrd1YnpxVXVowdAQrqyQgApVmTIhowgGZwqhhUrpK2iZLcQg1+D7jb UpoEVkNi0uX3TDRqwI6OziVRCSn+EDVuZ+b6ajz59FFLZm7l2Bi1/CWEakhgCiwa XquokSmu1zWN1eFdGbGWiJdlOGxtgKjW4f9cbsJIy1tCIGJxVABo+XZc/vEvvI/2 kZxvU3lDbw9zfqdlTMFXTK1LHv/odZEsFy7bgLzNvnRb+fRWU2VOSuU8cjDoLvOK bHXSzkT8F1/ypmeCxpfo5Fu/maVAMLt90n0j214claNzJ2GLGYU42hqqn2r4Iwov HWM2h6FPP10KhDzTmu9ifJkLAEDEAPB3a/diWjBijUEtaJB467Unag== =rQlP -----END PGP SIGNATURE----- From wk at gnupg.org Thu Apr 3 09:18:25 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Apr 2008 09:18:25 +0200 Subject: Using CCID and PCSC In-Reply-To: <20080402215806.GA1013@ryu.matrix> (Michel Messerschmidt's message of "Wed, 2 Apr 2008 23:58:06 +0200") References: <20080402215806.GA1013@ryu.matrix> Message-ID: <87abkbquda.fsf@wheatstone.g10code.de> On Wed, 2 Apr 2008 23:58, lists at michel-messerschmidt.de said: > is there a possibility to force gnupg 2 to use the internal CCID > smartcard driver even if pcscd is running (something like the > --disable-ccid option but for pcsc) ? No. This can't work becuase pcscd has already claimed the interface. If you use --disable-ccid with pcscd GnuPG should have no problem using its inetrnal driver. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Apr 3 09:20:21 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Apr 2008 09:20:21 +0200 Subject: 1.4.9 availability In-Reply-To: <47F46B78.70501@hammernoch.net> ("Ludwig =?utf-8?Q?H=C3=BCgel?= =?utf-8?Q?sch=C3=A4fer=22's?= message of "Thu, 03 Apr 2008 07:30:32 +0200") References: <58542869CBA00141AB7E2F357F0F3FA303F39C08@crplivexc54.citnet.cit.com> <47F46B78.70501@hammernoch.net> Message-ID: <8763uzqua2.fsf@wheatstone.g10code.de> On Thu, 3 Apr 2008 07:30, mlisten at hammernoch.net said: > http://lists.gnupg.org/pipermail/ gives a 403 Use http://lists.gnupg.org/pipermail/gnupg-announce/ Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From gukgukcommunity at yahoo.com Thu Apr 3 10:31:05 2008 From: gukgukcommunity at yahoo.com (guk guk) Date: Thu, 3 Apr 2008 18:31:05 +1000 (EST) Subject: Decrypt file from PGP Desktop Professional Message-ID: <992532.51724.qm@web46013.mail.sp1.yahoo.com> Hi ! I'm a newbie in gnupg. If a file is encrypted using PGP Desktop Professional, is it possible for me to decrypt that file using gnupg ? If it's possible , how to do that ? Thanks ____________________________________________________________________________________ You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Apr 3 11:38:27 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Apr 2008 11:38:27 +0200 Subject: FYI: Website updated Message-ID: <8763uzp9bg.fsf@wheatstone.g10code.de> Hi, www.gnupg.org is now up to date and lists the current versions of the gnupg et al. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Apr 3 12:04:45 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Apr 2008 12:04:45 +0200 Subject: Siemens card reader In-Reply-To: <1207210634.13949.8.camel@dublin.local> ("Reinhard =?utf-8?Q?M=C3=BCller=22's?= message of "Thu, 03 Apr 2008 10:17:14 +0200") References: <1206885127.5177.5.camel@dublin.local> <87sky4qh2r.fsf@wheatstone.g10code.de> <1207210634.13949.8.camel@dublin.local> Message-ID: <871w5np83m.fsf@wheatstone.g10code.de> On Thu, 3 Apr 2008 10:17, reinhard.mueller at bytewise.at said: > gpg: DBG: ccid-driver: bMaxCCIDBusySlots 1 > gpg: DBG: ccid-driver: usb_bulk_read error: Resource temporarily That seems to be a problem with the reader's USB stack. I have seen similar things with other old readers. You might want to ask for a firmware update. The reader is also not listed at http://pcsclite.alioth.debian.org/ccid.html Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From shavital at mac.com Thu Apr 3 13:39:51 2008 From: shavital at mac.com (Charly Avital) Date: Thu, 03 Apr 2008 07:39:51 -0400 Subject: Decrypt file from PGP Desktop Professional In-Reply-To: <992532.51724.qm@web46013.mail.sp1.yahoo.com> References: <992532.51724.qm@web46013.mail.sp1.yahoo.com> Message-ID: <47F4C207.2010208@mac.com> guk guk wrote the following on 4/3/08 4:31 AM: > Hi ! > > I'm a newbie in gnupg. > If a file is encrypted using PGP Desktop Professional, is it possible for me to decrypt that file using gnupg ? > If it's possible , how to do that ? > Thanks > I also use PGP Desktop 9.8.1 (Build 2.5.3), Macintosh. I correspond with some one who also uses the same application, and decrypt his messages with gpg and/or gpg2. To use gpg to decrypt such messages, it all depends on what MUA and operating system you are using. The message you posted to the list was composed in X-Mailer: YahooMailRC/902.40 YahooMailWebService/0.7.185 I am not familiar with that mailer. Does it have a plug-in that enables it to communicate with GnuPG? If you are running some flavor of Windows, I believe there is something called PGP Tray (or similar) that night enable you to process messages with GnuPG in your mailer's message window. A Google search with Yahoomail Web GnuPG brought up a number of links that you can check at: Check according to your operating system. I use, here, Thunderbird+Enigmail. Enigmail enables Thunderbird to interact with GnuPG. When I receive a message from the person who uses PGP 9.8.1, Thunderbird+Enigmail processes it as any other encrypted, signed, or signed and encrypted message; I use either icons in the tool bar, or commands from the Menu. Regards, Charly MacOS 10.5.2 - MacBook Intel C2Duo - GnuPG 1.4.9 - GPG2 2.0.9 - Thunderbird 2.0.0.12- Enigmail 0.95.6 From ladislav.hagara at unob.cz Thu Apr 3 13:47:24 2008 From: ladislav.hagara at unob.cz (Ladislav Hagara) Date: Thu, 03 Apr 2008 13:47:24 +0200 Subject: FYI: Website updated In-Reply-To: <8763uzp9bg.fsf@wheatstone.g10code.de> References: <8763uzp9bg.fsf@wheatstone.g10code.de> Message-ID: <47F4C3CC.2000409@unob.cz> > www.gnupg.org is now up to date and lists the current versions of the > gnupg et al. And what about favicon.ico, still old logo? -- Ladislav Hagara From stephen.fromm at gmail.com Thu Apr 3 13:28:50 2008 From: stephen.fromm at gmail.com (Stephen Fromm) Date: Thu, 3 Apr 2008 07:28:50 -0400 Subject: gpg for symmetric key encryption: cipher mode of operation? Message-ID: <000f01c8957d$e6ba0360$6401a8c0@apollosjf> I'd like to use gpg for symmetric key encryption, but I cannot find anything that tells me the mode of operation (cbc, ecb, etc), either in the usage (e.g., the cipher choices themselves don't have e.g. "-cbc") or in the documentation. TIA, S From email at sven-radde.de Thu Apr 3 14:43:47 2008 From: email at sven-radde.de (Sven Radde) Date: Thu, 03 Apr 2008 14:43:47 +0200 Subject: gpg for symmetric key encryption: cipher mode of operation? In-Reply-To: <000f01c8957d$e6ba0360$6401a8c0@apollosjf> References: <000f01c8957d$e6ba0360$6401a8c0@apollosjf> Message-ID: <47F4D103.7060408@sven-radde.de> Hi! Stephen Fromm schrieb: > I'd like to use gpg for symmetric key encryption, but I cannot find > anything that tells me the mode of operation GnuPG does "a variant of CFB mode". The exact details are specified in the OpenPGP standard: HTH, Sven From dshaw at jabberwocky.com Thu Apr 3 14:52:09 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 3 Apr 2008 08:52:09 -0400 Subject: gpg for symmetric key encryption: cipher mode of operation? In-Reply-To: <000f01c8957d$e6ba0360$6401a8c0@apollosjf> References: <000f01c8957d$e6ba0360$6401a8c0@apollosjf> Message-ID: On Apr 3, 2008, at 7:28 AM, Stephen Fromm wrote: > I'd like to use gpg for symmetric key encryption, but I cannot find > anything that tells me the mode of operation (cbc, ecb, etc), either > in the usage (e.g., the cipher choices themselves don't have e.g. "- > cbc") or in the documentation. It's "sort of" CFB. See http://tools.ietf.org/html/rfc4880#section-13.9 David From wk at gnupg.org Thu Apr 3 16:10:17 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Apr 2008 16:10:17 +0200 Subject: Siemens card reader In-Reply-To: <1207220879.13949.32.camel@dublin.local> ("Reinhard =?utf-8?Q?M=C3=BCller=22's?= message of "Thu, 03 Apr 2008 13:07:59 +0200") References: <1206885127.5177.5.camel@dublin.local> <87sky4qh2r.fsf@wheatstone.g10code.de> <1207210634.13949.8.camel@dublin.local> <871w5np83m.fsf@wheatstone.g10code.de> <1207220879.13949.32.camel@dublin.local> Message-ID: <877iffm3li.fsf@wheatstone.g10code.de> On Thu, 3 Apr 2008 13:07, reinhard.mueller at bytewise.at said: > Can I assume that all of the listed readers work with GnuPG? I'm > specifically looking for an internal reader, like the SCM-SCR333. They should at least work when using the PC/CS interface. Usually they should all work and some will even work better whne using gpg's driver (keypad support woraround for SCR-335). I am pretty sure that the SCR-333 will work. I once talked with an SCM engineer about that device and he confirmed that it uses the same chip as all other modern SCM readers. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Apr 3 16:28:31 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Apr 2008 16:28:31 +0200 Subject: FYI: Website updated In-Reply-To: <47F4C3CC.2000409@unob.cz> (Ladislav Hagara's message of "Thu, 03 Apr 2008 13:47:24 +0200") References: <8763uzp9bg.fsf@wheatstone.g10code.de> <47F4C3CC.2000409@unob.cz> Message-ID: <87zlsbko6o.fsf@wheatstone.g10code.de> On Thu, 3 Apr 2008 13:47, ladislav.hagara at unob.cz said: > And what about favicon.ico, still old logo? Updated. (Galeon does not show the icon, so I didn't noticed) Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From ravi2082 at gmail.com Thu Apr 3 15:53:18 2008 From: ravi2082 at gmail.com (ravi shankar) Date: Thu, 3 Apr 2008 19:23:18 +0530 Subject: Decrypting 2 files which were merged into 1 Message-ID: <402f074b0804030653x2643866cved1341c4749da493@mail.gmail.com> Hi All, We have been using gnupg to decrypt files pulled from a customer FTP server. On the customer side, the software used is some financial gateway software which sets flags for each of the files. Based on those flags we are given permission to pull those and decrypt. Sometimes there are 2 encrypted files placed on the customer side with the same name, not sure how thats possible on that financial gateway.So we have 2 encrypted files at their end with same name, say suppose one of 2 MB and the other 3 MB, when we fetch those at one go using FTP we are getting a combined encrypted file of 5 MB. This 5 MB file is then decrypted using our gnupg key to get the data out of it. Now when we decrypt, we are only seeing one set of data and other 3 MB data of the second file is lost. We are using the following command to decrypt echo "password" | gpg --verbose --no-tty --no-secmem-warning --passphrase-fd 0 "$fpgp" And we get the following trace > gpg: armor header: Version: GnuPG v1.2.1 (AIX) stderr > gpg: Signature made Wed Apr 2 16:32:08 2008 EDT using DSA key ID F83564E3 stderr > gpg: Can't check signature: public key not found stderr > gpg: onepass_sig with unknown version 73 stderr > gpg: WARNING: encrypted message has been manipulated! stderr> gpg: [don't know]: invalid packet (ctb=42) Though we get data of 1 file out of it correctly. Is there a way to decrypt the merged file correctly and extract entire data of both encrypted files within it correctly using gnupg? Thanks, Ravi From email at sven-radde.de Thu Apr 3 17:04:06 2008 From: email at sven-radde.de (Sven Radde) Date: Thu, 03 Apr 2008 17:04:06 +0200 Subject: Decrypting 2 files which were merged into 1 In-Reply-To: <402f074b0804030653x2643866cved1341c4749da493@mail.gmail.com> References: <402f074b0804030653x2643866cved1341c4749da493@mail.gmail.com> Message-ID: <47F4F1E6.5030205@sven-radde.de> Hi! Well apart from the fact that this whole thing sounds rather strange, I would assume that you should include a step to separate those two files again before decrypting both separately (and saving to two different names ;-). The message from GnuPG suggests to me that the files are ASCII armored so that should be rather simple to accomplish. HTH, Sven From ravi2082 at gmail.com Thu Apr 3 18:36:17 2008 From: ravi2082 at gmail.com (ravi shankar) Date: Thu, 3 Apr 2008 22:06:17 +0530 Subject: Decrypting 2 files which were merged into 1 In-Reply-To: <47F4F1E6.5030205@sven-radde.de> References: <402f074b0804030653x2643866cved1341c4749da493@mail.gmail.com> <47F4F1E6.5030205@sven-radde.de> Message-ID: <402f074b0804030936v751c5e1bl469187b7e001317d@mail.gmail.com> Hi Sorry for asking this again. We have an automated job which pulls the file from the client machine. Once the file has been fetched, we get the merged file(if there are 2 files present with same name on the client machine) directly. How can we separate the 2 encrypted files from the merged file? Is there a way to specifically extract 1 encrypted file out of that merged file and the other separately again? I mean some params,commands etc? Thanks in advance Ravi On Thu, Apr 3, 2008 at 8:34 PM, Sven Radde wrote: > Hi! > > Well apart from the fact that this whole thing sounds rather strange, I > would assume that you should include a step to separate those two files > again before decrypting both separately (and saving to two different names > ;-). > The message from GnuPG suggests to me that the files are ASCII armored so > that should be rather simple to accomplish. > > HTH, Sven > From wk at gnupg.org Thu Apr 3 18:41:24 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 03 Apr 2008 18:41:24 +0200 Subject: GnuPG v2.x? In-Reply-To: <47ED0FD6.4010807@sixdemonbag.org> (Robert J. Hansen's message of "Fri, 28 Mar 2008 10:33:42 -0500") References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <47ED0FD6.4010807@sixdemonbag.org> Message-ID: <8763uylwln.fsf@wheatstone.g10code.de> On Fri, 28 Mar 2008 16:33, rjh at sixdemonbag.org said: > to your question, and one I suspect they will emphatically disagree > with. :) Let's see ... > exist mostly as rules of thumb and handed-down wisdom. I use 1.4.x only > because of the latter kind of reasons: particularly, the Small Tools > Principle and the Second System Effect. That is why we promised to keep 1.4 alive. > of the Small Tools Principle. When I build my own 1.4.x GnuPG, I > typically turn off all the options I don't need. The smaller my trusted > codebase, the more reliable the final product will be. Right. However there are so many features in gpg that I have doubts that it is really a small tool. The major problem is that gpg tries to implement the entire OpenPGP standard and quite some extra features. > doesn't sit well with me. I don't need the new capabilities of 2.x; > why, then, should I migrate to it? For my part, the convenience of the gpg-agent. > understand the architecture and design of the system. As GnuPG 1.0 > turned into 1.2 and 1.4, I kept track of the changes. I've not yet had > the time to study GnuPG 2.x. I don't know the architecture and design. The OpenPGP code (gpg2) is identical to the one from GnuPG 1.4. There are some exceptions: All low level crypto code has been moved out to Libgcrypt which in turn was created from the GnuPG 1.x code base. passphrase.c has been modified to use the standard code to access the gpg-agent (gpg1 uses some simplied code). In general we try to keep the code as similar as possible between gpg1 and gpg2 - this make maintenacne much easier. Of course there are plans to better integrate gpg2 into the entire GnuPG-2 framework. For example all secret key processing will eventually be moved to gpg-agent. This is to follow the crypto pronciple of putting all your keys into one basket and watch that basket very carefully. The real reason for GnuPG-2 is the support for S/MIME. This is all plain new code and you can't consider this the second system effect. S/MIME is an orthogonal addition to GnuPG. The code is definitely not as matured as the one for gpg 1.4 but it works reasonable well. I hope that I will eventually find the time to get trapped by the Second System Effect ;-). Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From email at sven-radde.de Thu Apr 3 19:13:48 2008 From: email at sven-radde.de (Sven Radde) Date: Thu, 03 Apr 2008 19:13:48 +0200 Subject: Decrypting 2 files which were merged into 1 In-Reply-To: <402f074b0804030936v751c5e1bl469187b7e001317d@mail.gmail.com> References: <402f074b0804030653x2643866cved1341c4749da493@mail.gmail.com> <47F4F1E6.5030205@sven-radde.de> <402f074b0804030936v751c5e1bl469187b7e001317d@mail.gmail.com> Message-ID: <1207242828.6353.11.camel@carbon> Hi! Am Donnerstag, den 03.04.2008, 22:06 +0530 schrieb ravi shankar: > Once the file has been fetched, we get the merged file(if there are 2 > files present with same name on the client machine) directly. How can > we separate the 2 encrypted files from the merged file? Is there a way > to specifically extract 1 encrypted file out of that merged file and > the other separately again? I mean some params,commands etc? Maybe I didn't make it clear that I think that it is not GnuPG's task to do the separation for you. Before even invoking GnuPG in your batch job, you should invoke a program to separate the two files. You will have to do some programming/scripting work of your own here, depending of how exactly those two files are merged into the one you're receiving. If they are simply concatenated ASCII-armored files that ought to be rather simple by parsing for the "END PGP MESSAGE" line in the middle of the file. HTH, Sven From mjkortve at optusnet.com.au Thu Apr 3 19:40:47 2008 From: mjkortve at optusnet.com.au (Michael) Date: Fri, 04 Apr 2008 03:40:47 +1000 Subject: re GPG 2.0 Message-ID: <47F5169F.8050905@optusnet.com.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ~ Hi everyone. I know this is probably a bit late, since I generally get the digest, and also only log on infrequently, but felt I might for the sake of anyone interested mention that I'm still using gpg 1.4.8 with Enigmail and thunderbird 2.0.0.12, and I think it pretty much works. ~ I also use to use GPGshell occasionally, just for a nice clear interface. ~ My question is should I upgrade to 1.4.9 for any particular reason? My understanding was that .8 is still more or less "current". Is .9 a security upgrade? ~ As an aside, I have an older version 1.4.1 I think on an older machine that runs an old linux system (Red Hat 9 to be specific) and I think keys created on that machine are compatible with 1.4.9, however on an even older system (Red Hat 7) I recall building a version of gpg 1.2.3 with the help of rpm. Would keys created with that version be usable or are they incompatible? ~ Michael. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFH9RacVlIM867aTsoRAuDNAJ45Jl/eGIXjLYNapPBFTifyjdvdvACgwgmJ ZPQyNH3MNsna27vLHPHmP24= =A4m3 -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Fri Apr 4 15:03:16 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 4 Apr 2008 09:03:16 -0400 Subject: re GPG 2.0 In-Reply-To: <47F5169F.8050905@optusnet.com.au> References: <47F5169F.8050905@optusnet.com.au> Message-ID: <903DEECF-FBFE-4809-B7E0-C641C59B5C10@jabberwocky.com> On Apr 3, 2008, at 1:40 PM, Michael wrote: > ~ My question is should I upgrade to 1.4.9 for any particular > reason? My > understanding was that .8 is still more or less "current". Is .9 a > security upgrade? Yes. The flaw is not trivially exploitable, but there is always a chance. > ~ As an aside, I have an older version 1.4.1 I think on an older > machine > that runs an old linux system (Red Hat 9 to be specific) and I think > keys created on that machine are compatible with 1.4.9, however on an > even older system (Red Hat 7) I recall building a version of gpg 1.2.3 > with the help of rpm. Would keys created with that version be usable > or > are they incompatible? Very usable. GPG follows the OpenPGP standard, so any version of GPG should be able to handle any OpenPGP key. David From dshaw at jabberwocky.com Fri Apr 4 17:45:03 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 4 Apr 2008 11:45:03 -0400 Subject: sign a public key ? In-Reply-To: <47F283FA.1030003@phibee.net> References: <47F283FA.1030003@phibee.net> Message-ID: <20080404154503.GA3715@jabberwocky.com> On Tue, Apr 01, 2008 at 08:50:34PM +0200, Phibee Network Operation Center wrote: > Hi > > i use this for crypt a tar archives: > > /usr/bin/gpg --recipient Stefan --encrypt /tmp/backup.tgz > > i use the public key of stefan for crypt, but when i start > he request all time a "o" (Yes) and say me (sorry in french) : You have several options here. If you know that the key is valid (say, if you met Stefan), then you can sign the key which tells the system that you know it is the right key. This will prevent GPG from asking you about it. gpg --sign-key Stefan (sign publically - signature can be exported for others to use) or gpg --lsign-key Stefan (sign locally - signature is local to you) Alternately, you can tell GPG to not ask the question at all. This is less good, but is still appropriate for certain uses where you know the key is the right one. gpg --trust-model always David From wk at gnupg.org Fri Apr 4 22:45:52 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Apr 2008 22:45:52 +0200 Subject: GnuPG v2.x? In-Reply-To: <1207243216.6353.18.camel@carbon> (Sven Radde's message of "Thu, 03 Apr 2008 19:20:16 +0200") References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <47ED0FD6.4010807@sixdemonbag.org> <8763uylwln.fsf@wheatstone.g10code.de> <1207243216.6353.18.camel@carbon> Message-ID: <874pahfiwv.fsf@wheatstone.g10code.de> On Thu, 3 Apr 2008 19:20, sven at radde.name said: > I'm just curious and do not mean to be offensive or to belittle the > effort to implement S/MIME, but is GnuPG's S/MIME implementation > actually used somewhere? Well, KDE uses it. It is further the only Unix S/MIME application (with KMail) which passed the compatibility checks done by the BSI [1]. Mozilla has been tested too but woth some problems. In fact the Mozilla Foundation rejected our offer to implement a couple of useful and necessary enhancements to their S/MIME implementation. The way Mozilla works is basically: Show a positive result but don't annoy the user if the signature is suspicious. The fact that Mozilla may fall back to 40 bit RC4 encryption may indicate that the developers do not consider privacy a major goal. > aware of (like being able to re-use OpenPGP key material 'transparently' > in an S/MIME certificate)? You can't do that for technical reasons. An X.509 certificate based on the key material from an OpenPGP key has just the key material in common but nothing else. This would only make sense if you store your private key on a smartcard. GnuPG supports creation of certificates (to be exact, certificate signing requests) using existing key material. Salam-Shalom, Werner [1] e.g. http://www.bsi.de/fachthem/verwpki/dokumente/1_2005.pdf (German) -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From allen.schultz at gmail.com Sat Apr 5 04:21:51 2008 From: allen.schultz at gmail.com (Allen Schultz) Date: Fri, 4 Apr 2008 20:21:51 -0600 Subject: GnuPG v2.x? In-Reply-To: <874pahfiwv.fsf@wheatstone.g10code.de> References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <47ED0FD6.4010807@sixdemonbag.org> <8763uylwln.fsf@wheatstone.g10code.de> <1207243216.6353.18.camel@carbon> <874pahfiwv.fsf@wheatstone.g10code.de> Message-ID: <3f34f8420804041921v16d40716t868f7c2839b5bb24@mail.gmail.com> Does 2.x work in Vista? From wk at gnupg.org Sat Apr 5 11:23:10 2008 From: wk at gnupg.org (Werner Koch) Date: Sat, 05 Apr 2008 11:23:10 +0200 Subject: GnuPG v2.x? In-Reply-To: <3f34f8420804041921v16d40716t868f7c2839b5bb24@mail.gmail.com> (Allen Schultz's message of "Fri, 4 Apr 2008 20:21:51 -0600") References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <47ED0FD6.4010807@sixdemonbag.org> <8763uylwln.fsf@wheatstone.g10code.de> <1207243216.6353.18.camel@carbon> <874pahfiwv.fsf@wheatstone.g10code.de> <3f34f8420804041921v16d40716t868f7c2839b5bb24@mail.gmail.com> Message-ID: <87ve2wejup.fsf@wheatstone.g10code.de> On Sat, 5 Apr 2008 04:21, allen.schultz at gmail.com said: > Does 2.x work in Vista? Yes. GnuPG-2 under Windows is pretty new so you might encounter some problems. A binary distribution is not yet available. The best way to build is to use the SVN trunk of gpg4win.org. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From kevhilton at gmail.com Sat Apr 5 15:26:57 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Sat, 5 Apr 2008 08:26:57 -0500 Subject: GnuPG v2.x? Message-ID: <96c450350804050626u61877e7dg755503d0edf34889@mail.gmail.com> But will it compile using in Vista using cygwin? -- Kevin Hilton From kevhilton at gmail.com Sat Apr 5 15:54:04 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Sat, 5 Apr 2008 08:54:04 -0500 Subject: GnuPG v2.x? Message-ID: <96c450350804050654i1b902cfal34f0fa7c193e0c01@mail.gmail.com> I think I can answer my own question --- No! I obtained svn sources, but during the make process, it failed with the following: gcc -I/usr/local/include -I/usr/local/include -I/usr/local/include -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-secu rity -Wpointer-arith -o gpg2.exe gpg.o server.o build-packet.o compress.o comp ress-bz2.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-pack et.o cpr.o plaintext.o sig-check.o keylist.o pkglue.o pkclist.o skclist.o pubkey -enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdb io.o delkey.o keygen.o helptext.o keyserver.o photoid.o call-agent.o card-util.o exec.o ../common/libcommon.a ../jnlib/libjnlib.a ../gl/libgnu.a ../common/libg pgrl.a -lz -lbz2 -lresolv -lreadline /usr/local/lib/libintl.dll.a -liconv -L/us r/local/lib -L/usr/local/lib -lgcrypt -lgpg-error -L/usr/local/lib -lassuan -L /usr/local/lib -lgpg-error -liconv /usr/local/lib/libgpg-error.a(libgpg_error_la-strerror.o): In function `gpg_stre rror': /home/klal/libgpg-error-1.6/src/strerror.c:50: undefined reference to `_libintl_ dgettext' /usr/local/lib/libgpg-error.a(libgpg_error_la-strerror.o): In function `gpg_stre rror_r': /home/klal/libgpg-error-1.6/src/strerror.c:161: undefined reference to `_libintl _dgettext' /usr/local/lib/libgpg-error.a(libgpg_error_la-strsource.o): In function `gpg_str source': /home/klal/libgpg-error-1.6/src/strsource.c:36: undefined reference to `_libintl _dgettext' /home/klal/libgpg-error-1.6/src/strsource.c:36: undefined reference to `_libintl _dgettext' Info: resolving _rl_attempted_completion_over by linking to __imp__rl_attempted_ completion_over (auto-import) Info: resolving _rl_attempted_completion_function by linking to __imp__rl_attemp ted_completion_function (auto-import) Info: resolving _rl_inhibit_completion by linking to __imp__rl_inhibit_completio n (auto-import) Info: resolving _rl_catch_signals by linking to __imp__rl_catch_signals (auto-im port) Info: resolving _rl_outstream by linking to __imp__rl_outstream (auto-import) Info: resolving _rl_instream by linking to __imp__rl_instream (auto-import) Info: resolving _rl_readline_name by linking to __imp__rl_readline_name (auto-im port) -- Kevin Hilton From JPClizbe at tx.rr.com Sat Apr 5 22:37:03 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Sat, 05 Apr 2008 15:37:03 -0500 Subject: GnuPG v2.x? In-Reply-To: <96c450350804050654i1b902cfal34f0fa7c193e0c01@mail.gmail.com> References: <96c450350804050654i1b902cfal34f0fa7c193e0c01@mail.gmail.com> Message-ID: <47F7E2EF.3040407@tx.rr.com> Kevin Hilton wrote: > I think I can answer my own question --- No! If you've gotten that far; ie, all other dependencies built, it's more like --- Maybe! > I obtained svn sources, but during the make process, it failed with > the following: > > gcc -I/usr/local/include -I/usr/local/include -I/usr/local/include -g -O2 -Wall > -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-secu > rity -Wpointer-arith -o gpg2.exe gpg.o server.o build-packet.o compress.o comp > ress-bz2.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o > armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-pack > et.o cpr.o plaintext.o sig-check.o keylist.o pkglue.o pkclist.o skclist.o pubkey > -enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o > revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdb > io.o delkey.o keygen.o helptext.o keyserver.o photoid.o call-agent.o card-util.o > exec.o ../common/libcommon.a ../jnlib/libjnlib.a ../gl/libgnu.a ../common/libg > pgrl.a -lz -lbz2 -lresolv -lreadline /usr/local/lib/libintl.dll.a -liconv -L/us > r/local/lib -L/usr/local/lib -lgcrypt -lgpg-error -L/usr/local/lib -lassuan -L > /usr/local/lib -lgpg-error -liconv > /usr/local/lib/libgpg-error.a(libgpg_error_la-strerror.o): In function `gpg_stre > rror': > /home/klal/libgpg-error-1.6/src/strerror.c:50: undefined reference to `_libintl_ > dgettext' > /usr/local/lib/libgpg-error.a(libgpg_error_la-strerror.o): In function `gpg_stre > rror_r': looks like it can't find one of its dependencies. Rerun Cygwin's setup and make sure you've installed all of them, including any associated devel package. If you have, then you have a problem with your gettext/intl install. -- John P. Clizbe Inet: JPClizbe (a) tx DAWT rr DAHT con Ginger Bear Networks hkp://keyserver.gingerber,net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 657 bytes Desc: OpenPGP digital signature URL: From kevhilton at gmail.com Sun Apr 6 00:42:34 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Sat, 5 Apr 2008 17:42:34 -0500 Subject: GnuPG v2.x? In-Reply-To: <96c450350804050654i1b902cfal34f0fa7c193e0c01@mail.gmail.com> References: <96c450350804050654i1b902cfal34f0fa7c193e0c01@mail.gmail.com> Message-ID: <96c450350804051542i644bccb5h7f3620bdafe626cd@mail.gmail.com> Hmm, thanks for the suggestion. I believe gnupg2 requires gettext 0.17 or greater -- cygwin ships with 0.16, with no higher version available in its mirrors. I downloaded the 0.17 sources from here: ftp://mirrors.kernel.org/gnu/gettext/, compiled and installed. I'm kind of stuck at this point. The intl package is contained within the gettext package correct? For some reason the cvs sources of gettext will not compile. I'm stuck in dependency hell! I'm finding not much luck with the cygwin mailing list either! From kevhilton at gmail.com Sun Apr 6 02:15:55 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Sat, 5 Apr 2008 19:15:55 -0500 Subject: GnuPG v2.x? In-Reply-To: <96c450350804051542i644bccb5h7f3620bdafe626cd@mail.gmail.com> References: <96c450350804050654i1b902cfal34f0fa7c193e0c01@mail.gmail.com> <96c450350804051542i644bccb5h7f3620bdafe626cd@mail.gmail.com> Message-ID: <96c450350804051715q48c16bc8r67343ca8f7904c0b@mail.gmail.com> Maybe this isnt for me. I did manage to get gettext compiled from cvs. Its now 0.18-pre1. However I think Im getting stuck at the same point: gcc -I/usr/local/include -I/usr/local/include -I/usr/local/include -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-secu rity -Wpointer-arith -o gpg2.exe gpg.o server.o build-packet.o compress.o comp ress-bz2.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-pack et.o cpr.o plaintext.o sig-check.o keylist.o pkglue.o pkclist.o skclist.o pubkey -enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdb io.o delkey.o keygen.o helptext.o keyserver.o photoid.o call-agent.o card-util.o exec.o ../common/libcommon.a ../jnlib/libjnlib.a ../gl/libgnu.a ../common/libg pgrl.a -lz -lbz2 -lresolv -lreadline /usr/local/lib/libintl.dll.a -liconv -L/us r/local/lib -L/usr/local/lib -lgcrypt -lgpg-error -L/usr/local/lib -lassuan -L /usr/local/lib -lgpg-error -liconv /usr/local/lib/libgpg-error.a(libgpg_error_la-strerror.o): In function `gpg_stre rror': /home/klal/libgpg-error-1.6/src/strerror.c:50: undefined reference to `_libintl_ dgettext' /usr/local/lib/libgpg-error.a(libgpg_error_la-strerror.o): In function `gpg_stre rror_r': /home/klal/libgpg-error-1.6/src/strerror.c:161: undefined reference to `_libintl _dgettext' /usr/local/lib/libgpg-error.a(libgpg_error_la-strsource.o): In function `gpg_str source': /home/klal/libgpg-error-1.6/src/strsource.c:36: undefined reference to `_libintl _dgettext' /home/klal/libgpg-error-1.6/src/strsource.c:36: undefined reference to `_libintl _dgettext' Info: resolving _rl_attempted_completion_over by linking to __imp__rl_attempted_ completion_over (auto-import) Info: resolving _rl_attempted_completion_function by linking to __imp__rl_attemp ted_completion_function (auto-import) Info: resolving _rl_inhibit_completion by linking to __imp__rl_inhibit_completio n (auto-import) Info: resolving _rl_catch_signals by linking to __imp__rl_catch_signals (auto-im port) Info: resolving _rl_outstream by linking to __imp__rl_outstream (auto-import) Info: resolving _rl_instream by linking to __imp__rl_instream (auto-import) Info: resolving _rl_readline_name by linking to __imp__rl_readline_name (auto-im port) collect2: ld returned 1 exit status make[2]: *** [gpg2.exe] Error 1 make[2]: Leaving directory `/home/klal/temp/gnupg/gnupg2/gnupg/g10' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/klal/temp/gnupg/gnupg2/gnupg' make: *** [all] Error 2 Still seems like a gettext error. All libs are in /usr/local/libs Thanks for any suggestions or sympathies. From kevhilton at gmail.com Sun Apr 6 02:38:30 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Sat, 5 Apr 2008 19:38:30 -0500 Subject: GnuPG v2.x? In-Reply-To: <96c450350804051715q48c16bc8r67343ca8f7904c0b@mail.gmail.com> References: <96c450350804050654i1b902cfal34f0fa7c193e0c01@mail.gmail.com> <96c450350804051542i644bccb5h7f3620bdafe626cd@mail.gmail.com> <96c450350804051715q48c16bc8r67343ca8f7904c0b@mail.gmail.com> Message-ID: <96c450350804051738h3deb21feg46ef2d59152b2512@mail.gmail.com> Clarification, my libraries are in /usr/local/lib Also this link statement seems strange to me. Possibly this is correct?: -lreadline /usr/local/lib/libintl.dll.a From claws at thewildbeast.co.uk Sun Apr 6 08:48:03 2008 From: claws at thewildbeast.co.uk (Paul) Date: Sun, 6 Apr 2008 07:48:03 +0100 Subject: GnuPG v2.x? In-Reply-To: <874pahfiwv.fsf@wheatstone.g10code.de> References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <47ED0FD6.4010807@sixdemonbag.org> <8763uylwln.fsf@wheatstone.g10code.de> <1207243216.6353.18.camel@carbon> <874pahfiwv.fsf@wheatstone.g10code.de> Message-ID: <20080406074803.242e1a48@thewildbeast> On Fri, 04 Apr 2008 22:45:52 +0200 Werner Koch wrote: > Well, KDE uses it. It is also used by Claws Mail for its S/MIME plugin. best regards Paul -- It isn't worth a nickle to two guys like you or me, but to a collector it is worth a fortune From hudson at osresearch.net Sun Apr 6 22:59:56 2008 From: hudson at osresearch.net (Trammell Hudson) Date: Sun, 6 Apr 2008 16:59:56 -0400 Subject: Re-attaching a signature Message-ID: <20080406205956.GX21197@osresearch.net> Is there a way to detach a signature from a message after it has already been signed and then to-reattach it? As an example, let's say that I've received a signed message encrypted to me and I want to be able to decrypt it, verify the signature and then re-encrypt it to resend it to someone else, but with the original signature rather than mine. I've been able to use gpgsplit to generate the separate packets from the outer-most encrypted message (the encryption key and the encrypted data packet), but do not know how to get the data packets from the message once it has been decrypted. Looking at the output from --list-packets, I'm interested in the 'onepass_sig', 'literal data' and 'signature' packets that are nested in the 'encrypted data' packet: :pubkey enc packet: version 3, algo 16, keyid 366DE80896CDC35C data: [2048 bits] data: [2048 bits] :encrypted data packet: length: 205 mdc_method: 2 gpg: encrypted with 2048-bit ELG-E key, ID 96CDC35C, created 2008-04-06 "Test Key " :compressed packet: algo=2 :onepass_sig packet: keyid 317BCDBAC7BE611A version 3, sigclass 00, digest 2, pubkey 17, last=1 :literal data packet: mode b (62), created 1207514699, name="clear.txt", raw data: 128 bytes :signature packet: algo 17, keyid 317BCDBAC7BE611A version 3, created 1207514699, md5len 5, sigclass 00 digest algo 2, begin of digest 8e 1e data: [158 bits] data: [158 bits] If I use --status-fd, there are lots of data reported, but I do not know if any of it can be used to generate the signature. The SIG_ID reported is 27 bytes long in radix-64, which would result in the 158 bit signature + 4 bit CRC, but I'd rather find an easier way! [GNUPG:] ENC_TO 366DE80896CDC35C 16 0 [GNUPG:] GOOD_PASSPHRASE [GNUPG:] BEGIN_DECRYPTION [GNUPG:] PLAINTEXT 62 1207514699 clear.txt [GNUPG:] PLAINTEXT_LENGTH 128 [GNUPG:] SIG_ID ziWhsXtNDWk/TEDZiE+nEZB0x/w 2008-04-06 1207514699 [GNUPG:] GOODSIG 317BCDBAC7BE611A Trammell Hudson [GNUPG:] VALIDSIG 2CAAF424FC407D1904A56AD8317BCDBAC7BE611A 2008-04-06 1207514699 0 3 0 17 2 00 2CAAF424FC407D1904A56AD8317BCDBAC7BE611A [GNUPG:] TRUST_UNDEFINED [GNUPG:] DECRYPTION_OKAY [GNUPG:] GOODMDC [GNUPG:] END_DECRYPTION Thanks! -- Trammell -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 155 bytes Desc: not available URL: From s_protsman at yahoo.com Mon Apr 7 06:07:56 2008 From: s_protsman at yahoo.com (Shawn Protsman) Date: Sun, 6 Apr 2008 21:07:56 -0700 (PDT) Subject: Decrypt file from PGP Desktop Professional Message-ID: <127028.20087.qm@web30805.mail.mud.yahoo.com> This is not a problem. I use both, PGP Desktop, gnupg and PGP Command Line interchangeably all the time. You would decrypt the file the same way you would any other file. Encrypted file with pgp: $ pgp -e appts.txt -r jd at foo.com appts.txt:encrypt (0:output file appts.txt.pgp) Decrypt the file with gpg: $ gpg -o appts.tmp.txt -d appts.txt.pgp You need a passphrase to unlock the secret key for user: "John Doe " 2048-bit ELG-E key, ID 6AD4EB61, created 2007-02-12 (main key ID BB93ECF1) gpg: encrypted with 2048-bit ELG-E key, ID 6AD4EB61, created 2007-02-12 "John Doe " ----- Original Message ---- From: guk guk To: gnupg-users at gnupg.org Sent: Thursday, April 3, 2008 1:31:05 AM Subject: Decrypt file from PGP Desktop Professional Hi ! I'm a newbie in gnupg. If a file is encrypted using PGP Desktop Professional, is it possible for me to decrypt that file using gnupg ? If it's possible , how to do that ? Thanks ____________________________________________________________________________________ You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From paulo.s.rod at bol.com.br Mon Apr 7 14:57:22 2008 From: paulo.s.rod at bol.com.br (paulo.s.rod) Date: Mon, 7 Apr 2008 10:57:22 -0200 Subject: Encrypt files using my secret key Message-ID: Guys, Please, is that possible to encrypt files with gnupg using my secret key ? Then other people could decrypt it using my public key, in order to have authenticity, that is, it came from me ? Thanks and regards, Paulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshaw at jabberwocky.com Mon Apr 7 15:28:30 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 7 Apr 2008 09:28:30 -0400 Subject: Encrypt files using my secret key In-Reply-To: References: Message-ID: On Apr 7, 2008, at 8:57 AM, paulo.s.rod wrote: > Guys, > > Please, is that possible to encrypt files with gnupg using my secret > key ? Then other people could decrypt it using my public key, in > order to have authenticity, that is, it came from me ? Not exactly. What you are looking for is a "signature". Signatures are made using your secret key, and can be verified by your public key, and it does show that it came from you (or at least, that it came from your key). However, signatures do not encrypt the data, so you get authenticity, but not confidentiality. If you want to encrypt also, you must encrypt on top of the signature. GPG can do this with "--sign -- encrypt". David From patrick at mozilla-enigmail.org Mon Apr 7 16:26:49 2008 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Mon, 07 Apr 2008 16:26:49 +0200 Subject: GnuPG v2.x? In-Reply-To: <874pahfiwv.fsf__20991.1794089296$1207342473$gmane$org@wheatstone.g10code.de> References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <47ED0FD6.4010807@sixdemonbag.org> <8763uylwln.fsf@wheatstone.g10code.de> <1207243216.6353.18.camel@carbon> <874pahfiwv.fsf__20991.1794089296$1207342473$gmane$org@wheatstone.g10code.de> Message-ID: Werner Koch wrote: [...] > necessary enhancements to their S/MIME implementation. The way Mozilla > works is basically: Show a positive result but don't annoy the user if > the signature is suspicious. The fact that Mozilla may fall back to 40 > bit RC4 encryption may indicate that the developers do not consider > privacy a major goal. I think that last statement is no longer true. As of Thunderbird 2.0, SeaMonkey 1.1 and Firefox 2.0 all 40 bit algorithms are disabled by default (but the user may still enable them if he knows how to change hidden prefs). -Patrick From hlmuller at yahoo.com Mon Apr 7 16:27:13 2008 From: hlmuller at yahoo.com (Harvey Muller) Date: Mon, 7 Apr 2008 07:27:13 -0700 (PDT) Subject: Encrypt files using my secret key Message-ID: <374495.33748.qm@web53609.mail.re2.yahoo.com> Paulo, I apologize in advance for the rtfm response, but you probably want to investigate the --sign and --clearsign options in the gpg manpage. If you are only looking for authenticity, and not secrecy, then encryption is probably not necessary. Best regards, Harvey ----- Original Message ---- From: paulo.s.rod To: gnupg-users Sent: Monday, April 7, 2008 8:57:22 AM Subject: Encrypt files using my secret key Guys, Please, is that possible to encrypt files with gnupg using my secret key ? Then other people could decrypt it using my public key, in order to have authenticity, that is, it came from me ? Thanks and regards, Paulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From shavital at mac.com Mon Apr 7 17:30:40 2008 From: shavital at mac.com (Charly Avital) Date: Mon, 07 Apr 2008 11:30:40 -0400 Subject: gpg 2.0.9 - compiling problem In-Reply-To: <200411171111.04077.linux@codehelp.co.uk> References: <20041117095555.23839.qmail@web52102.mail.yahoo.com> <200411171111.04077.linux@codehelp.co.uk> Message-ID: <47FA3E20.2060101@mac.com> Hi, When trying to compile 2.0.9 on a PPC, I get the following: 1. End of ./configure: ------- GnuPG v2.0.9 has been configured as follows: Platform: Darwin (powerpc-apple-darwin9.2.2) OpenPGP: yes S/MIME: yes Agent: yes Smartcard: yes Protect tool: (default) Default agent: (default) Default pinentry: (default) Default scdaemon: (default) Default dirmngr: (default) ------- 2. But end of Make: -------- gcc -DHAVE_CONFIG_H -I. -I.. -I../gl -I../intl -DLOCALEDIR=\"/usr/local/share/locale\" -DGNUPG_BINDIR="\"/usr/local/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/local/libexec\"" -DGNUPG_LIBDIR="\"/usr/local/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/local/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/local/etc/gnupg\"" -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -MT t-convert.o -MD -MP -MF .deps/t-convert.Tpo -c -o t-convert.o t-convert.c mv -f .deps/t-convert.Tpo .deps/t-convert.Po gcc -I/usr/local/include -I/usr/local/include -I/usr/local/include -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -o t-convert t-convert.o libcommon.a ../jnlib/libjnlib.a ../gl/libgnu.a -L/usr/local/lib -lgcrypt -L/usr/local/lib -lgpg-error -L/usr/local/lib -lgpg-error -L/usr/local/lib -liconv ld: file not found: /usr/local/lib/libintl.8.dylib collect2: ld returned 1 exit status make[3]: *** [t-convert] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ------- 3. I got a lot of hits when Googling for 'ld: file not found: /usr/local/lib/libintl.8.dylib, that seems to be a part (?) of gettest. I tried to compile gettest 0.17, but 'make' failed. I had no problem compiling 2.0.9 on an Intel Mac. 4. What am I missing here? Thanks in advance, Charly From shavital at mac.com Mon Apr 7 20:13:51 2008 From: shavital at mac.com (Charly Avital) Date: Mon, 07 Apr 2008 14:13:51 -0400 Subject: Solved_ gpg 2.0.9 - compiling problem In-Reply-To: <200411171111.04077.linux@codehelp.co.uk> References: <20041117095555.23839.qmail@web52102.mail.yahoo.com> <200411171111.04077.linux@codehelp.co.uk> Message-ID: <47FA645F.1050805@mac.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Please disregard my previous question. Could compile successfully gpg 2.0.9, with gpg-agent running, on a PPC. I found out why gettext's compiling failed, and fixed it. Updated libksba to 1.0.3 Updated libgcrypt to 1.4.0 GnuPG v2.0.9 has been configured as follows: Platform: Darwin (powerpc-apple-darwin9.2.2) OpenPGP: yes S/MIME: yes Agent: yes Smartcard: yes Protect tool: (default) Default agent: (default) Default pinentry: (default) Default scdaemon: (default) Default dirmngr: (default) $ gpg2 --version gpg (GnuPG) 2.0.9 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ELG Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Used libraries: gcrypt(1.4.0) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: GnuPG for Privacy Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBCAAGBQJH+mRZAAoJEM3GMi2FW4Pvsw0H/AqVpwsrHlqrEuaFpglw3Wr2 IASKeOCpH7BVha1Bn9m8B/TZ0XI3Tfi/dwLpZXZBNmzG3LXk7c6giK51QkTqpA+q sqtP/1P8YYTz7Hz2JfskDIKzSi5PfVZqx13D9wIg/duLF28/T8EHMAL+JTLb1/4k /BzKwvUZD4170yRhFSVbbwv3mOFmg/MM+f7mnuPWLxiMQCncd2hU/nQP399LDwp1 hD9sB2OxCsIzScXrcTY9cqLN3/TD9iiZ+Um8UwvFYu8s6TjuL+QYfxOysXpbrFD1 VOGqFpP0WxP0G2q4cO4eb+EJqMZVRCdCl+NrIYOlDYCMJjs1SgKDsi+HS9ByEQk= =g6fu -----END PGP SIGNATURE----- From kevhilton at gmail.com Tue Apr 8 05:12:47 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Mon, 7 Apr 2008 22:12:47 -0500 Subject: GnuPG v2.x? In-Reply-To: <96c450350804051738h3deb21feg46ef2d59152b2512@mail.gmail.com> References: <96c450350804050654i1b902cfal34f0fa7c193e0c01@mail.gmail.com> <96c450350804051542i644bccb5h7f3620bdafe626cd@mail.gmail.com> <96c450350804051715q48c16bc8r67343ca8f7904c0b@mail.gmail.com> <96c450350804051738h3deb21feg46ef2d59152b2512@mail.gmail.com> Message-ID: <96c450350804072012h78081398n5863abcbf5792742@mail.gmail.com> Just updated to svn version gpg2 4739 Still have same problems trying to compile gpg2 under cygwin with the gettext error: gcc -I/usr/local/include -I/usr/local/include -g -O2 -Wall -Wcast-align -Wshado w -Wstrict-prototypes -Wformat -Wno-format-y2k -Wformat-security -Wpointer-arith -o gpg2.exe gpg.o server.o build-packet.o compress.o compress-bz2.o free-pack et.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-packet.o cpr.o plaintext .o sig-check.o keylist.o pkglue.o pkclist.o skclist.o pubkey-enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o k eyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdbio.o delkey.o keygen .o helptext.o keyserver.o photoid.o call-agent.o card-util.o exec.o ../common/li bcommon.a ../jnlib/libjnlib.a ../gl/libgnu.a ../common/libgpgrl.a -lz -lbz2 -lr esolv -lreadline /usr/local/lib/libintl.dll.a -liconv -L/usr/local/lib -lgcry pt -lgpg-error -L/usr/local/lib -lassuan -L/usr/local/lib -lgpg-error -liconv /usr/local/lib/libgpg-error.a(libgpg_error_la-strerror.o): In function `gpg_stre rror': /home/klal/temp/gnupg/libgpg-error-1.6/src/strerror.c:50: undefined reference to `_libintl_dgettext' /usr/local/lib/libgpg-error.a(libgpg_error_la-strerror.o): In function `gpg_stre rror_r': /home/klal/temp/gnupg/libgpg-error-1.6/src/strerror.c:161: undefined reference t o `_libintl_dgettext' Info: resolving _rl_attempted_completion_over by linking to __imp__rl_attempted_ completion_over (auto-import) Info: resolving _rl_attempted_completion_function by linking to __imp__rl_attemp ted_completion_function (auto-import) Info: resolving _rl_inhibit_completion by linking to __imp__rl_inhibit_completio n (auto-import) Info: resolving _rl_catch_signals by linking to __imp__rl_catch_signals (auto-im port) Info: resolving _rl_outstream by linking to __imp__rl_outstream (auto-import) Info: resolving _rl_instream by linking to __imp__rl_instream (auto-import) Info: resolving _rl_readline_name by linking to __imp__rl_readline_name (auto-im port) collect2: ld returned 1 exit status make[2]: *** [gpg2.exe] Error 1 make[2]: Leaving directory `/home/klal/temp/gnupg/gpg2/g10' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/klal/temp/gnupg/gpg2' make: *** [all] Error 2 I've seen other people complain of a similar error trying to compile other programs, but never found a posted solution. I don't know a lot about playing with the link flags. Are there any suggestions I could try? From john.fitzpatrick at centralbank.ie Tue Apr 1 19:06:23 2008 From: john.fitzpatrick at centralbank.ie (JohnnyF1) Date: Tue, 1 Apr 2008 10:06:23 -0700 (PDT) Subject: 1.4.7 <-> 1.4.8 compatibility Message-ID: <16418735.post@talk.nabble.com> Hi, could anyone tell me if there are many problems with encrypting using 1.4.7 and decrypting in 1.4.8 and vice versa? I am aware of this one in relation to signing: http://www.nabble.com/SHA-224-problem-to14038812.html#a14040484 on the SHA-224 problem. Thank you in Advance John -- View this message in context: http://www.nabble.com/1.4.7-%3C-%3E-1.4.8-compatibility-tp16418735p16418735.html Sent from the GnuPG - User mailing list archive at Nabble.com. From bluewire at imapmail.org Wed Apr 2 17:24:30 2008 From: bluewire at imapmail.org (Neal Dudley) Date: Wed, 02 Apr 2008 10:24:30 -0500 Subject: Keysigning request Message-ID: <47F3A52E.40709@imapmail.org> Is there anyone in the Chicago area who would be willing and able to meet me to sign my GPG key? Yes, I have looked on Biglumber and contacted several people from there. Yes, I have searched for WoT groups in the area. No, not one person has met with me yet. I will only be in Chicago for the next few days. If you, or someone you know, is in the Chicago area and would be able to meet with me to id me and sign my key, I would very much appreciate it. Thank you for your time. From reinhard.mueller at bytewise.at Thu Apr 3 10:17:14 2008 From: reinhard.mueller at bytewise.at (Reinhard =?ISO-8859-1?Q?M=FCller?=) Date: Thu, 03 Apr 2008 10:17:14 +0200 Subject: Siemens card reader In-Reply-To: <87sky4qh2r.fsf@wheatstone.g10code.de> References: <1206885127.5177.5.camel@dublin.local> <87sky4qh2r.fsf@wheatstone.g10code.de> Message-ID: <1207210634.13949.8.camel@dublin.local> Am Mittwoch, den 02.04.2008, 19:53 +0200 schrieb Werner Koch: > Please add thse options > > --debug-ccid-driver --debug-ccid-driver > > so get more output (yes, give it twice). Use a test card, so that your > PIN is not visible in the output. Using these options with a card with PIN 123456 gives me: ---8<--- $ gpg --debug-ccid --debug-ccid --clearsign foo gpg: DBG: ccid-driver: using CCID reader 0 (ID=0BF8:1006:X:0) gpg: DBG: ccid-driver: idVendor: 0BF8 idProduct: 1006 bcdDevice: 0203 gpg: DBG: ccid-driver: ChipCard Interface Descriptor: gpg: DBG: ccid-driver: bLength 54 gpg: DBG: ccid-driver: bDescriptorType 33 gpg: DBG: ccid-driver: bcdCCID 1.00 gpg: DBG: ccid-driver: nMaxSlotIndex 0 gpg: DBG: ccid-driver: bVoltageSupport 7 ? gpg: DBG: ccid-driver: dwProtocols 3 T=0 T=1 gpg: DBG: ccid-driver: dwDefaultClock 4800 gpg: DBG: ccid-driver: dwMaxiumumClock 8000 gpg: DBG: ccid-driver: bNumClockSupported 4 gpg: DBG: ccid-driver: dwDataRate 10752 bps gpg: DBG: ccid-driver: dwMaxDataRate 412903 bps gpg: DBG: ccid-driver: bNumDataRatesSupp. 106 gpg: DBG: ccid-driver: dwMaxIFSD 254 gpg: DBG: ccid-driver: dwSyncProtocols 00000007 2-wire 3-wire I2C gpg: DBG: ccid-driver: dwMechanical 00000000 gpg: DBG: ccid-driver: dwFeatures 000207B2 gpg: DBG: ccid-driver: Auto configuration based on ATR gpg: DBG: ccid-driver: Auto clock change gpg: DBG: ccid-driver: Auto baud rate change gpg: DBG: ccid-driver: Auto PPS made by CCID gpg: DBG: ccid-driver: CCID can set ICC in clock stop mode gpg: DBG: ccid-driver: NAD value other than 0x00 accepted gpg: DBG: ccid-driver: Auto IFSD exchange gpg: DBG: ccid-driver: Short APDU level exchange gpg: DBG: ccid-driver: dwMaxCCIDMsgLen 271 gpg: DBG: ccid-driver: bClassGetResponse echo gpg: DBG: ccid-driver: bClassEnvelope echo gpg: DBG: ccid-driver: wlcdLayout none gpg: DBG: ccid-driver: bPINSupport 0 gpg: DBG: ccid-driver: bMaxCCIDBusySlots 1 gpg: DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable gpg: DBG: ccid-driver: USB: CALLING USB_CLEAR_HALT gpg: DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable gpg: DBG: ccid-driver: USB: RETRYING bulk_in AGAIN gpg: DBG: ccid-driver: usb_bulk_read error: Resource temporarily unavailable gpg: DBG: ccid-driver: USB: RETRYING bulk_in AGAIN gpg: DBG: ccid-driver: status: 00 error: 00 octet[9]: 00 data: 3B FA 13 00 FF 81 31 80 45 00 31 C1 73 C0 01 00 00 90 00 B1 gpg: DBG: ccid-driver: status: 00 error: 00 octet[9]: 01 data: 11 10 FF 45 00 80 00 gpg: DBG: ccid-driver: GetParametes returned 82 07 00 00 00 00 05 00 00 01 11 10 FF 45 00 80 00 gpg: DBG: ccid-driver: protocol ..........: T=1 gpg: DBG: ccid-driver: bmFindexDindex ....: 11 gpg: DBG: ccid-driver: bmTCCKST1 .........: 10 gpg: DBG: ccid-driver: bGuardTimeT1 ......: FF gpg: DBG: ccid-driver: bmWaitingIntegersT1: 45 gpg: DBG: ccid-driver: bClockStop ........: 00 gpg: DBG: ccid-driver: bIFSC .............: 128 gpg: DBG: ccid-driver: bNadValue .........: 0 gpg: DBG: ccid-driver: sending 61 07 00 00 00 00 06 01 00 00 11 10 FF 45 00 80 00 gpg: DBG: ccid-driver: status: 00 error: 00 octet[9]: 01 data: 13 10 FF 45 00 80 00 gpg: DBG: ccid-driver: sending 6F 0B 00 00 00 00 07 04 00 00 00 A4 04 00 06 D2 76 00 01 24 01 gpg: DBG: ccid-driver: status: 00 error: 00 octet[9]: 00 data: 6F 12 84 10 D2 76 00 01 24 01 01 01 00 01 00 00 07 AC 00 00 90 00 gpg: DBG: ccid-driver: sending 6F 05 00 00 00 00 08 04 00 00 00 CA 00 4F 00 gpg: DBG: ccid-driver: status: 00 error: 00 octet[9]: 00 data: D2 76 00 01 24 01 01 01 00 01 00 00 07 AC 00 00 90 00 gpg: DBG: ccid-driver: sending 6F 05 00 00 00 00 09 04 00 00 00 CA 00 C4 00 gpg: DBG: ccid-driver: status: 00 error: 00 octet[9]: 00 data: 00 FE FE FE 03 03 03 90 00 gpg: DBG: ccid-driver: sending 6F 05 00 00 00 00 0A 04 00 00 00 CA 00 6E 00 gpg: DBG: ccid-driver: status: 00 error: 00 octet[9]: 00 data: 4F 10 D2 76 00 01 24 01 01 01 00 01 00 00 07 AC 00 00 73 81 9D C0 01 78 C1 05 01 04 00 00 20 C2 05 01 04 00 00 20 C3 05 01 04 00 00 20 C4 07 00 FE FE FE 03 03 03 C5 3C 4A D9 E9 39 32 E4 58 75 0A F5 80 98 2A 6F D3 72 87 7C A6 E3 1E 9A 5B 89 0C BA F5 36 7E 2E 09 93 74 5F EC 25 AD 08 A0 AE C6 F9 89 47 13 3A EC DA 62 61 0D E7 8A ED 10 D3 D0 C4 48 5B C6 3C C4 85 A6 CD 7E C6 6E 9E EC 33 65 F2 70 F2 75 E4 C3 2F 6C A5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 44 D5 EB 94 44 D5 EB C2 44 D5 EB 3D 5E 08 72 65 69 6E 68 61 72 64 90 00 gpg: DBG: ccid-driver: sending 6F 05 00 00 00 00 0B 04 00 00 00 CA 00 5E 00 gpg: DBG: ccid-driver: status: 00 error: 00 octet[9]: 00 data: 72 65 69 6E 68 61 72 64 90 00 gpg: DBG: ccid-driver: sending 6F 05 00 00 00 00 0C 04 00 00 00 CA 00 6E 00 gpg: DBG: ccid-driver: status: 00 error: 00 octet[9]: 00 data: 4F 10 D2 76 00 01 24 01 01 01 00 01 00 00 07 AC 00 00 73 81 9D C0 01 78 C1 05 01 04 00 00 20 C2 05 01 04 00 00 20 C3 05 01 04 00 00 20 C4 07 00 FE FE FE 03 03 03 C5 3C 4A D9 E9 39 32 E4 58 75 0A F5 80 98 2A 6F D3 72 87 7C A6 E3 1E 9A 5B 89 0C BA F5 36 7E 2E 09 93 74 5F EC 25 AD 08 A0 AE C6 F9 89 47 13 3A EC DA 62 61 0D E7 8A ED 10 D3 D0 C4 48 5B C6 3C C4 85 A6 CD 7E C6 6E 9E EC 33 65 F2 70 F2 75 E4 C3 2F 6C A5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 44 D5 EB 94 44 D5 EB C2 44 D5 EB 3D 5E 08 72 65 69 6E 68 61 72 64 90 00 gpg: DBG: ccid-driver: sending 6F 05 00 00 00 00 0D 04 00 00 00 CA 00 7A 00 gpg: DBG: ccid-driver: status: 00 error: 00 octet[9]: 00 data: 93 03 00 20 B5 90 00 gpg: Bisher erstellte Signaturen: 8373 Bitte geben Sie die PIN ein [Verarbeitete Signaturen: 8373] gpg: DBG: ccid-driver: sending 6F 0B 00 00 00 00 0E 04 00 00 00 20 00 81 06 31 32 33 34 35 36 gpg: DBG: ccid-driver: status: 00 error: 00 octet[9]: 00 data: 90 00 gpg: DBG: ccid-driver: sending 6F 0B 00 00 00 00 0F 04 00 00 00 20 00 82 06 31 32 33 34 35 36 gpg: DBG: ccid-driver: status: 00 error: 00 octet[9]: 00 data: 90 00 gpg: DBG: ccid-driver: sending 6F 28 00 00 00 00 10 04 00 00 00 2A 9E 9A 23 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 4E 64 F2 0F 81 0E 0E 5B A6 1A 4F A6 DE AB 51 67 A5 AB A0 31 gpg: DBG: ccid-driver: status: 41 error: F4 octet[9]: 00 data: gpg: DBG: ccid-driver: CCID command failed: Procedure byte conflict gpg: ccid_transceive failed: (0x10009) gpg: apdu_send_simple(0) failed: card inactive gpg: Beglaubigung fehlgeschlagen: Allgemeiner Fehler gpg: foo: clearsign failed: Allgemeiner Fehler gpg: DBG: ccid-driver: status: 01 error: 00 octet[9]: 01 data: ---8<--- Thanks, Reinhard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From reinhard.mueller at bytewise.at Thu Apr 3 13:07:59 2008 From: reinhard.mueller at bytewise.at (Reinhard =?ISO-8859-1?Q?M=FCller?=) Date: Thu, 03 Apr 2008 13:07:59 +0200 Subject: Siemens card reader In-Reply-To: <871w5np83m.fsf@wheatstone.g10code.de> References: <1206885127.5177.5.camel@dublin.local> <87sky4qh2r.fsf@wheatstone.g10code.de> <1207210634.13949.8.camel@dublin.local> <871w5np83m.fsf@wheatstone.g10code.de> Message-ID: <1207220879.13949.32.camel@dublin.local> Werner, thanks for investigating. Am Donnerstag, den 03.04.2008, 12:04 +0200 schrieb Werner Koch: > The reader is also not listed at > http://pcsclite.alioth.debian.org/ccid.html Hm, this seems to be a useful page :-) Can I assume that all of the listed readers work with GnuPG? I'm specifically looking for an internal reader, like the SCM-SCR333. Thanks, Reinhard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From sven at radde.name Thu Apr 3 19:20:16 2008 From: sven at radde.name (Sven Radde) Date: Thu, 03 Apr 2008 19:20:16 +0200 Subject: GnuPG v2.x? In-Reply-To: <8763uylwln.fsf@wheatstone.g10code.de> References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <47ED0FD6.4010807@sixdemonbag.org> <8763uylwln.fsf@wheatstone.g10code.de> Message-ID: <1207243216.6353.18.camel@carbon> Hi! Am Donnerstag, den 03.04.2008, 18:41 +0200 schrieb Werner Koch: > The real reason for GnuPG-2 is the support for S/MIME. I'm just curious and do not mean to be offensive or to belittle the effort to implement S/MIME, but is GnuPG's S/MIME implementation actually used somewhere? As far as I see it, the mail clients that offer S/MIME do so far longer than GnuPG2 exists and therefore have their own implementations (or use other libs). Is there any benefit for GnuPG's S/MIME implementation that I am not aware of (like being able to re-use OpenPGP key material 'transparently' in an S/MIME certificate)? cu, Sven From shavital at netvision.net.il Mon Apr 7 20:12:48 2008 From: shavital at netvision.net.il (Charly Avital) Date: Mon, 07 Apr 2008 14:12:48 -0400 Subject: Solved_ gpg 2.0.9 - compiling problem In-Reply-To: <200411171111.04077.linux@codehelp.co.uk> References: <20041117095555.23839.qmail@web52102.mail.yahoo.com> <200411171111.04077.linux@codehelp.co.uk> Message-ID: <47FA6420.1070802@netvision.net.il> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Please disregard my previous question. Could compile successfully gpg 2.0.9, with gpg-agent running, on a PPC. I found out why gettext's compiling failed, and fixed it. Updated libksba to 1.0.3 Updated libgcrypt to 1.4.0 GnuPG v2.0.9 has been configured as follows: Platform: Darwin (powerpc-apple-darwin9.2.2) OpenPGP: yes S/MIME: yes Agent: yes Smartcard: yes Protect tool: (default) Default agent: (default) Default pinentry: (default) Default scdaemon: (default) Default dirmngr: (default) $ gpg2 --version gpg (GnuPG) 2.0.9 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ELG Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Used libraries: gcrypt(1.4.0) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: GnuPG for Privacy Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBCAAGBQJH+mQcAAoJEM3GMi2FW4PvBnYIAJHP5R+SloOJlaYlNfSnjuYj amv5qI+/bY1SCwiUlTNnEe5lE//9WEP5M2ei0bmqCbsYwGhjGic0Fp2kFmcFyHlq u39mX9jeaD/xeB79VsLg6nstiH37ULqeLhW2gkojRBh5UNnvS1NQhyo3kDVJwQ4g ascW/Ms5xDFvvijeDtY6WE/gxVTifddExW/X1Mx0Cgz6tNsHMhPqQ3rWhOPfN/w4 g0OKc93jeYJHOA3LHrRCzhYmQtCNpNkARNpD1DzqXln9JlTQGmNdqUI3CVTIvl7Z 3+AD4M9+DfHYbg22KRZ63nWeP1GGi+ShO0VEJdPWQ42FpaNXKoEmrsSLrd0/9U8= =E0ki -----END PGP SIGNATURE----- From shavital at mac.com Tue Apr 8 16:28:02 2008 From: shavital at mac.com (Charly Avital) Date: Tue, 08 Apr 2008 10:28:02 -0400 Subject: gettext version 0.17 Message-ID: <47FB80F2.3080605@mac.com> Hi, [MacOS 10.5.2 - MacBook Intel C2Duo - GnuPG 1.4.9 - GPG2 2.0.9] I am running gpg 2.0.9, that I have compiled on March 26, 2008, using an existing gettext (GNU gettext-runtime) 0.14.5. Is there any advantage that I compile and install gettext (GNU gettext-runtime) 0.17 and then compile 2.0.9 again? TIA Charly From wk at gnupg.org Tue Apr 8 16:46:52 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Apr 2008 16:46:52 +0200 Subject: GnuPG v2.x? In-Reply-To: (Patrick Brunschwig's message of "Mon, 07 Apr 2008 16:26:49 +0200") References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <47ED0FD6.4010807@sixdemonbag.org> <8763uylwln.fsf@wheatstone.g10code.de> <1207243216.6353.18.camel@carbon> <874pahfiwv.fsf__20991.1794089296$1207342473$gmane$org@wheatstone.g10code.de> Message-ID: <87ve2s5rqb.fsf@wheatstone.g10code.de> On Mon, 7 Apr 2008 16:26, patrick at mozilla-enigmail.org said: > I think that last statement is no longer true. As of Thunderbird 2.0, > SeaMonkey 1.1 and Firefox 2.0 all 40 bit algorithms are disabled by > default (but the user may still enable them if he knows how to change > hidden prefs). We had this problem recently; not longer than half a year ago. I don't know what the current version of thunderbird was at that time. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From rjh at sixdemonbag.org Tue Apr 8 17:00:34 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 08 Apr 2008 10:00:34 -0500 Subject: gettext version 0.17 In-Reply-To: <47FB80F2.3080605@mac.com> References: <47FB80F2.3080605@mac.com> Message-ID: <47FB8892.8040009@sixdemonbag.org> Charly Avital wrote: > Is there any advantage that I compile and install gettext (GNU > gettext-runtime) 0.17 and then compile 2.0.9 again? Not especially. If you really want to know the nitty-gritty details about the differences between versions, I'd suggest asking on the gettext mailing list. If you want to proceed with this, I'd recommend using Fink to install GnuPG2 and gettext. Fink is a much more convenient way to build packages from source. From rjh at sixdemonbag.org Tue Apr 8 17:35:31 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 08 Apr 2008 10:35:31 -0500 Subject: Invalid cross certification? Message-ID: <47FB90C3.5060806@sixdemonbag.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm beginning to do my own testing of GnuPG 2.0.9, and I'm seeing something a bit odd. I have a message encrypted and signed to myself which GnuPG 1.4.9 decrypts and verifies correctly. GnuPG 2.0.9 gives a warning about there being an invalid cross-certification. Googling was not especially helpful. Checking the source code, sig-check.c turned out to have the most useful bit of information: /* Check the backsig. This is a 0x19 signature from the ~ subkey on the primary key. The idea here is that it should ~ not be possible for someone to "steal" subkeys and claim ~ them as their own. The attacker couldn't actually use the ~ subkey, but they could try and claim ownership of any ~ signaures issued by it. */ So the obvious questions: 1. If 1.4.9 and 2.0.9 use the same crypto code for OpenPGP, why is there this difference in functionality? 2. How is it possible to put an 0x19 signature on the primary key from the subkey, in order to get rid of this error message? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iFYEAREIAAYFAkf7kMMACgkQf2XByo0Cu7PJRADfVUbPPX0AaqMmQTvS8vKLSU4L G9b2D6QqQS9H/gDfUDOtXYOBQbeVn+hJp6te7IlClAQ75wFHdPQuTYkBHAQBAQgA BgUCR/uQwwAKCRC3APSC/q+BCV7DB/9MUUKtRF3AR7QJY/HyhIoCY97jQOrmQhL0 +gao8vq/DPUj+1WcfbR4hG4eGbs3Xj20b7HTmj3X8Jjx/jiXWP82qbk7npwAmtyz 2KtHiEUz7iC/Glv2Tlgz0tPCGIVIpq5wOzZHm38mgge/S4WgRpC+Y7QOG3X/m7TZ Agy3jUKkiHd4fiAHxHQxIQj07M+L9AbHVawGr3ptmjSXJRp5enCBHyOHo7ex++fH IKD/whulUPQG09K7VnzDYqgT+VsPSpJ4yTjWGktTNJwdcg1WbuXxzrFyYrty6xot S1X7llqKy+glW97XFytMBl3AUSYjPcPk7lxQ7UB7vF1jft26jwtJ =rmQg -----END PGP SIGNATURE----- From wk at gnupg.org Tue Apr 8 18:44:06 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Apr 2008 18:44:06 +0200 Subject: Invalid cross certification? In-Reply-To: <47FB90C3.5060806@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 08 Apr 2008 10:35:31 -0500") References: <47FB90C3.5060806@sixdemonbag.org> Message-ID: <87y77o2t61.fsf@wheatstone.g10code.de> On Tue, 8 Apr 2008 17:35, rjh at sixdemonbag.org said: > 1. If 1.4.9 and 2.0.9 use the same crypto code for OpenPGP, why is > there this difference in functionality? I did a quick check and I can't find a difference in the code. Do youuse the same config file? Note that gpg tries to read a gpg.conf-2 file first. If David has no other idea, I'd ask you to send me that test signature. > 2. How is it possible to put an 0x19 signature on the primary key from > the subkey, in order to get rid of this error message? I am not sure whether this works. We probably never tested the case to rectify an invalid cross-signature: http://www.gnupg.org/faq/subkey-cross-certify.html (en)If you have been pointed to this page by someone who received a warning when verifying one of your signatures, your key does not contain a subkey cross-certification. You can easily add this cross-certification using GnuPG 1.4.3 or later. To do this, simply run "gpg --edit-key (yourkey)" and then enter "cross-certify". You'll need to type your passphrase, and GnuPG will add the necessary cross-certification. Once this is done, you should distribute your key however you like (send it to a keyserver, post on a web page, etc). If you have already done this and people are still receiving the warning, make sure they have updated their copy of your key from the keyserver or web page. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Tue Apr 8 19:22:12 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 8 Apr 2008 13:22:12 -0400 Subject: Invalid cross certification? In-Reply-To: <47FB90C3.5060806@sixdemonbag.org> References: <47FB90C3.5060806@sixdemonbag.org> Message-ID: <20080408172212.GA14881@jabberwocky.com> On Tue, Apr 08, 2008 at 10:35:31AM -0500, Robert J. Hansen wrote: > I'm beginning to do my own testing of GnuPG 2.0.9, and I'm seeing > something a bit odd. I have a message encrypted and signed to myself > which GnuPG 1.4.9 decrypts and verifies correctly. GnuPG 2.0.9 gives a > warning about there being an invalid cross-certification. > > Googling was not especially helpful. Checking the source code, > sig-check.c turned out to have the most useful bit of information: > > /* Check the backsig. This is a 0x19 signature from the > ~ subkey on the primary key. The idea here is that it should > ~ not be possible for someone to "steal" subkeys and claim > ~ them as their own. The attacker couldn't actually use the > ~ subkey, but they could try and claim ownership of any > ~ signaures issued by it. */ > > So the obvious questions: > > 1. If 1.4.9 and 2.0.9 use the same crypto code for OpenPGP, why is > there this difference in functionality? This should work. I believe the code is identical around backsigs. > 2. How is it possible to put an 0x19 signature on the primary key from > the subkey, in order to get rid of this error message? It seems that there is a valid 0x19 signature already, as 1.4.9 does not give you a warning. Still, if you do --edit-key and then "cross-certify", you can add a backsig to any key you like. Looking at your signing subkey 8D02BBB3, I do see a valid backsig on it. Ah, I suspect this is the reason: subpkt 32 len 86 (signature: v4, class 0x19, algo 17, digest algo 11) Digest algo 11 is SHA-224, which is fairly recent. I believe it was added to libgcrypt somewhere in the 1.3.x development. Does your libgcrypt have it? David From ladislav.hagara at unob.cz Tue Apr 8 22:10:37 2008 From: ladislav.hagara at unob.cz (Ladislav Hagara) Date: Tue, 08 Apr 2008 22:10:37 +0200 Subject: gettext version 0.17 In-Reply-To: <47FB8892.8040009@sixdemonbag.org> References: <47FB80F2.3080605@mac.com> <47FB8892.8040009@sixdemonbag.org> Message-ID: <47FBD13D.1070000@unob.cz> >> Is there any advantage that I compile and install gettext (GNU >> gettext-runtime) 0.17 and then compile 2.0.9 again? >> > > Not especially. If you really want to know the nitty-gritty details > about the differences between versions, I'd suggest asking on the > gettext mailing list. http://cvs.savannah.gnu.org/viewvc/gettext/NEWS?revision=1.134&root=gettext&view=markup -- Ladislav Hagara From kloecker at kde.org Tue Apr 8 22:17:03 2008 From: kloecker at kde.org (Ingo =?iso-8859-1?q?Kl=F6cker?=) Date: Tue, 08 Apr 2008 22:17:03 +0200 Subject: GnuPG v2.x? In-Reply-To: <1207243216.6353.18.camel@carbon> References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <8763uylwln.fsf@wheatstone.g10code.de> <1207243216.6353.18.camel@carbon> Message-ID: <200804082217.04263@erwin.ingo-kloecker.de> On Thursday 03 April 2008, Sven Radde wrote: > Hi! > > Am Donnerstag, den 03.04.2008, 18:41 +0200 schrieb Werner Koch: > > The real reason for GnuPG-2 is the support for S/MIME. > > I'm just curious and do not mean to be offensive or to belittle the > effort to implement S/MIME, but is GnuPG's S/MIME implementation > actually used somewhere? Yes. > As far as I see it, the mail clients that offer S/MIME do so far > longer than GnuPG2 exists and therefore have their own > implementations (or use other libs). GnuPG's S/MIME implementation was developed as part of the Aegypten project [1]. It is used in KMail and probably also in Mutt (but I'm not sure about the latter). The S/MIME implementation in KMail (via gpgme/gpgsm) is the only Free Software implementation of S/MIME that has passed the Sphinx interoperability tests of the Federal Office for Information Security (BSI) [2]. Regards, Ingo [1] http://www.gnupg.de/aegypten/ [2] http://www.bsi.bund.de/fachthem/verwpki/interoptests/testberichte.htm (German) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part. URL: From shavital at mac.com Tue Apr 8 22:35:28 2008 From: shavital at mac.com (Charly Avital) Date: Tue, 08 Apr 2008 16:35:28 -0400 Subject: gettext version 0.17 In-Reply-To: <47FBD13D.1070000@unob.cz> References: <47FB80F2.3080605@mac.com> <47FB8892.8040009@sixdemonbag.org> <47FBD13D.1070000@unob.cz> Message-ID: <47FBD710.40909@mac.com> Ladislav Hagara wrote the following on 4/8/08 4:10 PM: [...] > Ladislav, thank you for the pointer. When I was trying to compile gpg 2.0.9, I kept getting an error warning about 'libintl.8.dylib', until I compiled and installed gettext 0.17. Charly From claws at thewildbeast.co.uk Wed Apr 9 08:15:15 2008 From: claws at thewildbeast.co.uk (Paul) Date: Wed, 9 Apr 2008 07:15:15 +0100 Subject: GnuPG v2.x? In-Reply-To: <200804082217.04263@erwin.ingo-kloecker.de> References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <8763uylwln.fsf@wheatstone.g10code.de> <1207243216.6353.18.camel@carbon> <200804082217.04263@erwin.ingo-kloecker.de> Message-ID: <20080409071515.25eb08e2@thewildbeast> On Tue, 08 Apr 2008 22:17:03 +0200 Ingo Kl?cker wrote: > The S/MIME implementation in KMail (via > gpgme/gpgsm) is the only Free Software implementation of S/MIME that > has passed the Sphinx interoperability tests of the Federal Office for > Information Security (BSI) And what else did they test besides Kmail? best regards Paul -- It isn't worth a nickle to two guys like you or me, but to a collector it is worth a fortune From rjh at sixdemonbag.org Wed Apr 9 09:42:08 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 09 Apr 2008 02:42:08 -0500 Subject: GnuPG v2.x? In-Reply-To: <20080409071515.25eb08e2@thewildbeast> References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <8763uylwln.fsf@wheatstone.g10code.de> <1207243216.6353.18.camel@carbon> <200804082217.04263@erwin.ingo-kloecker.de> <20080409071515.25eb08e2@thewildbeast> Message-ID: <47FC7350.1060709@sixdemonbag.org> Paul wrote: > And what else did they test besides Kmail? It doesn't really matter if there were a hundred other S/MIME implementations tested by Sphinx, or if GnuPG's S/MIME implementation was the only one. The Sphinx evaluation criteria are what matters--not the competition. If the evaluation criteria are rigorous and demanding, then being the only one to pass is a major accomplishment even if no one else submitted. If the evaluation criteria are easy, then being the best of hundreds to pass the examination really doesn't amount to much at all. From wk at gnupg.org Wed Apr 9 10:14:21 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Apr 2008 10:14:21 +0200 Subject: GnuPG v2.x? In-Reply-To: <200804082217.04263@erwin.ingo-kloecker.de> ("Ingo =?utf-8?Q?Kl=C3=B6cker=22's?= message of "Tue, 08 Apr 2008 22:17:03 +0200") References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <8763uylwln.fsf@wheatstone.g10code.de> <1207243216.6353.18.camel@carbon> <200804082217.04263@erwin.ingo-kloecker.de> Message-ID: <878wzn30o2.fsf@wheatstone.g10code.de> On Tue, 8 Apr 2008 22:17, kloecker at kde.org said: > project [1]. It is used in KMail and probably also in Mutt (but I'm not > sure about the latter). The S/MIME implementation in KMail (via If Mutt has been compiled with the gpgme development package installed, it will have support. It is then just a matter of set crypt_use_gpgme in your .muttrc to switch from the OpenSSL based implementaion to the better integrated gpgme one. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Wed Apr 9 10:25:06 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Apr 2008 10:25:06 +0200 Subject: Invalid cross certification? In-Reply-To: <20080408172212.GA14881@jabberwocky.com> (David Shaw's message of "Tue, 8 Apr 2008 13:22:12 -0400") References: <47FB90C3.5060806@sixdemonbag.org> <20080408172212.GA14881@jabberwocky.com> Message-ID: <874pab3065.fsf@wheatstone.g10code.de> On Tue, 8 Apr 2008 19:22, dshaw at jabberwocky.com said: > Digest algo 11 is SHA-224, which is fairly recent. I believe it was > added to libgcrypt somewhere in the 1.3.x development. Does your Right, since 1.3.0 (May 2007) but we neded to fixed the ASN OID in 1.3.2 (Dec 2007) to to an error in the OpenPGP RFC. Given that Libgcrypt was marked as development and gpg2 was not in wide use we did not put this workaround for the changed OID into GnuPG-2: /* This code is to work around a SHA-224 problem. RFC-4880 and the drafts leading up to it were published with the wrong DER prefix for SHA-224. Unfortunately, GPG pre-1.4.8 used this wrong prefix. What this code does is take all bad RSA signatures that use SHA-224, and re-checks them using the old, incorrect, DER prefix. Someday we should remove this code, and when we do remove it, pkcs1_encode_md can be made into a static function again. Note that GPG2 does not have this issue as it uses libgcrypt, which is being fixed while it is still a development version. */ However if you know verify a signature created with a faulty SHA-224 signature, gpg2 will flag it as bad. I hesitate to put the workaround into gpg2 unless more people complain about this problem. It would be better to fix the back signature. What about having gpg print a notice pointing to an online FAQ entry? Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From email at sven-radde.de Wed Apr 9 12:46:17 2008 From: email at sven-radde.de (Sven Radde) Date: Wed, 09 Apr 2008 12:46:17 +0200 Subject: Accessing the private DOs of the smartcard Message-ID: <47FC9E79.5060502@sven-radde.de> Hello GnuPG users, Is there a convenient way to access the data objects of the OpenPGP smartcard? The best thing I know is to use "gpg --card-edit" to get at the PIN-protected DOs, which is cumbersome and does not give a very machine-friendly output... What I am thinking of is the following: The card with its PIN counters represents a protection against brute force attempts, that is not available to other software-only crypto applications like EncFS, Truecrypt etc. Consequently, the card PIN can be shorter than the overlong passphrases needed to secure those applications. Now, it would be really nice to store a long passphrase into one of the PIN-protected data objects and have the possibility to pipe that to one of those applications. This way, e.g., a Truecrypt volume would be protected by a very long passphrase, while the owner has the convenience of "unlocking" that passphrase using his/her shorter smartcard PIN. Can this be accomplished using some scripting? Or may I suggest to add "--card-do1" through "--card-do4" as new commands to GnuPG which would print the respective string to standard output after asking for the PIN when applicable? Thanks for listening :-) Sven From dshaw at jabberwocky.com Wed Apr 9 14:53:43 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 9 Apr 2008 08:53:43 -0400 Subject: Invalid cross certification? In-Reply-To: <874pab3065.fsf@wheatstone.g10code.de> References: <47FB90C3.5060806@sixdemonbag.org> <20080408172212.GA14881@jabberwocky.com> <874pab3065.fsf@wheatstone.g10code.de> Message-ID: <5F0784E4-3649-4EBF-8665-686C97C0278C@jabberwocky.com> On Apr 9, 2008, at 4:25 AM, Werner Koch wrote: > On Tue, 8 Apr 2008 19:22, dshaw at jabberwocky.com said: > >> Digest algo 11 is SHA-224, which is fairly recent. I believe it was >> added to libgcrypt somewhere in the 1.3.x development. Does your > > Right, since 1.3.0 (May 2007) but we neded to fixed the ASN OID in > 1.3.2 > (Dec 2007) to to an error in the OpenPGP RFC. Given that Libgcrypt > was > marked as development and gpg2 was not in wide use we did not put this > workaround for the changed OID into GnuPG-2: > > /* This code is to work around a SHA-224 problem. RFC-4880 > and the drafts leading up to it were published with the > wrong DER prefix for SHA-224. Unfortunately, GPG pre-1.4.8 > used this wrong prefix. What this code does is take all > bad RSA signatures that use SHA-224, and re-checks them > using the old, incorrect, DER prefix. Someday we should > remove this code, and when we do remove it, pkcs1_encode_md > can be made into a static function again. Note that GPG2 > does not have this issue as it uses libgcrypt, which is > being fixed while it is still a development version. */ > > However if you know verify a signature created with a faulty SHA-224 > signature, gpg2 will flag it as bad. > > I hesitate to put the workaround into gpg2 unless more people complain > about this problem. It would be better to fix the back signature. > What > about having gpg print a notice pointing to an online FAQ entry? I'm trying to persuade myself that doing nothing is the right answer :) I rather like the FAQ idea, so we could print the notice on any failed SHA-224 verification? We might want to do that in 1.4.x as well, actually (with a reminder that we won't be fixing the signatures in the background forever). That way we could encourage people to fix the signatures as soon as possible. I need to check the backsig issuing code in keyedit.c to see how users can reissue backsigs. It shouldn't be too bad: backsigs live on the unhashed part of the signature. Maybe --expert could allow the backsig to be reissued. David From wk at gnupg.org Wed Apr 9 17:00:11 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Apr 2008 17:00:11 +0200 Subject: Accessing the private DOs of the smartcard In-Reply-To: <47FC9E79.5060502@sven-radde.de> (Sven Radde's message of "Wed, 09 Apr 2008 12:46:17 +0200") References: <47FC9E79.5060502@sven-radde.de> Message-ID: <87lk3nxedg.fsf@wheatstone.g10code.de> On Wed, 9 Apr 2008 12:46, email at sven-radde.de said: > smartcard? The best thing I know is to use "gpg --card-edit" to get at > the PIN-protected DOs, which is cumbersome and does not give a very > machine-friendly output... You can script that (use --with-colons, --status-fd and command-fd). There is even a gpgme interface to it. It is also possible to read the content from a file in the --card-edit menu: privatedo 4 < FILE Another way to sscript this is by using gpg-agent and gpg-connect-agent. Have a look at the gpg/gpg-agent/scdaemon communication by enabling a log file for scdaemon and using "debug 1024". Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From claws at thewildbeast.co.uk Wed Apr 9 20:01:00 2008 From: claws at thewildbeast.co.uk (Paul) Date: Wed, 9 Apr 2008 19:01:00 +0100 Subject: GnuPG v2.x? In-Reply-To: <47FC7350.1060709@sixdemonbag.org> References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <8763uylwln.fsf@wheatstone.g10code.de> <1207243216.6353.18.camel@carbon> <200804082217.04263@erwin.ingo-kloecker.de> <20080409071515.25eb08e2@thewildbeast> <47FC7350.1060709@sixdemonbag.org> Message-ID: <20080409190100.431f9008@thewildbeast> On Wed, 09 Apr 2008 02:42:08 -0500 "Robert J. Hansen" wrote: > It doesn't really matter if there were a hundred other S/MIME > implementations tested by Sphinx, or if GnuPG's S/MIME implementation > was the only one. The Sphinx evaluation criteria are what matters--not > the competition. That maybe true, but that is not what the OP said exactly. He didn't say GnuPG's S/MIME implementation passed, he said 'The S/MIME implementation in KMail'. So, I asked what other MUAs were tested. KMail is not the only MUA using GnuPG's S/MIME, Claws Mail does too. It's news to me if Claws Mail was tested - as a member of the dev team I would have expected to hear about it. So, I wondered, if KMail was the only MUA tested, then saying it is the only one that passed seems like a bit of semantic trickery, inferring, as it does, that others failed. best regards Paul -- It isn't worth a nickle to two guys like you or me, but to a collector it is worth a fortune From kloecker at kde.org Wed Apr 9 21:37:12 2008 From: kloecker at kde.org (Ingo =?iso-8859-1?q?Kl=F6cker?=) Date: Wed, 09 Apr 2008 21:37:12 +0200 Subject: GnuPG v2.x? In-Reply-To: <20080409190100.431f9008@thewildbeast> References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <47FC7350.1060709@sixdemonbag.org> <20080409190100.431f9008@thewildbeast> Message-ID: <200804092137.13188@erwin.ingo-kloecker.de> On Wednesday 09 April 2008, Paul wrote: > On Wed, 09 Apr 2008 02:42:08 -0500 > > "Robert J. Hansen" wrote: > > It doesn't really matter if there were a hundred other S/MIME > > implementations tested by Sphinx, or if GnuPG's S/MIME > > implementation was the only one. The Sphinx evaluation criteria > > are what matters--not the competition. > > That maybe true, but that is not what the OP said exactly. He didn't > say GnuPG's S/MIME implementation passed, he said 'The S/MIME > implementation in KMail'. So, I asked what other MUAs were tested. Did you follow the link I provided? The PDFs available on this page contain the test reports. They are in German but it shouldn't be a problem to understand which solutions were tested. Anyway, KMail was the only Free Software MUA that was tested because testing costs a lot of money. The other tested solutions were proprietary plugins for Groupwise, Lotus Notes and MS Outlook, and a mail gateway running on Linux. Note that the BSI wasn't interested in testing all available MUAs. They only wanted to make sure that the MUA they have chosen for usage on Linux was interoperable with the other solutions used by them. Obviously, this statement is somewhat simplified (and might even be incorrect). Even though I'm the former maintainer of KMail I was only very marginally involved in the ?gypten project. > KMail is not the only MUA using GnuPG's S/MIME, Claws Mail does too. > It's news to me if Claws Mail was tested - as a member of the dev > team I would have expected to hear about it. So, I wondered, if KMail > was the only MUA tested, then saying it is the only one that passed > seems like a bit of semantic trickery, inferring, as it does, that > others failed. Shoot me for using semantic trickery. :-) I only answered Sven's provocative (as I understood it) question whether GnuPG's S/MIME implementation is actually used somewhere and what its benefits are. I didn't want to belittle other MUAs using GnuPG's S/MIME. Au contraire. IMO all Free Software MUAs should use GnuPG's S/MIME instead of rolling their own S/MIME implementation. I'm pretty sure passing the Sphinx-interoperability test wouldn't be much of a problem for any MUA doing so. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Wed Apr 9 21:44:22 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 09 Apr 2008 14:44:22 -0500 Subject: GnuPG v2.x? In-Reply-To: <20080409190100.431f9008@thewildbeast> References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <8763uylwln.fsf@wheatstone.g10code.de> <1207243216.6353.18.camel@carbon> <200804082217.04263@erwin.ingo-kloecker.de> <20080409071515.25eb08e2@thewildbeast> <47FC7350.1060709@sixdemonbag.org> <20080409190100.431f9008@thewildbeast> Message-ID: <47FD1C96.9080000@sixdemonbag.org> Paul wrote: > So, I wondered, if KMail was the only MUA tested, then saying it is > the only one that passed seems like a bit of semantic trickery, > inferring, as it does, that others failed. [sigh] If you're going to misquote someone, at least do it accurately. The original poster's exact words were "is the only Free Software implementation of S/MIME that has passed the Sphinx interoperability tests." The parse is ambiguous. You can read it as meaning "only one Free Software implementation was submitted to Sphinx, and it passed". You can read it as "other Free Software implementations were submitted to Sphinx, and only KMail passed". Or you can do what I do, which is recognize that it's an ambiguous parse, and assume that the person speaking is a reasonable human being who is probably not engaging in semantic trickery. Accusing people of malfeasance when there is no clear evidence any occurred is a McCarthyism into which I do not wish to fall. Ingo is a reasonable human being. From claws at thewildbeast.co.uk Wed Apr 9 22:46:02 2008 From: claws at thewildbeast.co.uk (Paul) Date: Wed, 9 Apr 2008 21:46:02 +0100 Subject: GnuPG v2.x? In-Reply-To: <47FD1C96.9080000@sixdemonbag.org> References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <8763uylwln.fsf@wheatstone.g10code.de> <1207243216.6353.18.camel@carbon> <200804082217.04263@erwin.ingo-kloecker.de> <20080409071515.25eb08e2@thewildbeast> <47FC7350.1060709@sixdemonbag.org> <20080409190100.431f9008@thewildbeast> <47FD1C96.9080000@sixdemonbag.org> Message-ID: <20080409214602.4fa0af8b@thewildbeast> On Wed, 09 Apr 2008 14:44:22 -0500 "Robert J. Hansen" wrote: > [sigh] [bigger sigh] > If you're going to misquote someone, at least do it accurately. The > original poster's exact words were "is the only Free Software > implementation of S/MIME that has passed the Sphinx interoperability tests." Yes, exactly. That's why I asked what else was tested. I don't see any misquoting. As you say... > The parse is ambiguous. > You can read it as meaning "only one Free > Software implementation was submitted to Sphinx, and it passed". You > can read it as "other Free Software implementations were submitted to > Sphinx, and only KMail passed". Yes, exactly. That's why I asked what else was tested. > Or you can do what I do, which is recognize that it's an ambiguous > parse, and assume that the person speaking is a reasonable human being > who is probably not engaging in semantic trickery. Accusing people of > malfeasance when there is no clear evidence any occurred is a > McCarthyism into which I do not wish to fall. 'malfeasance' is a strong word. Alas, it seems that you might be slipping already! :) > Ingo is a reasonable human being. I didn't say otherwise. have a banana Paul -- Note to self: do as Robert does. From allen.schultz at gmail.com Wed Apr 9 23:50:05 2008 From: allen.schultz at gmail.com (Allen Schultz) Date: Wed, 9 Apr 2008 15:50:05 -0600 Subject: Accessing the private DOs of the smartcard In-Reply-To: <87lk3nxedg.fsf@wheatstone.g10code.de> References: <47FC9E79.5060502@sven-radde.de> <87lk3nxedg.fsf@wheatstone.g10code.de> Message-ID: <3f34f8420804091450p52e60c70ue582a12b1f6d1246@mail.gmail.com> Is there a FAQ for this question? I have either a 256 or a 512 MB USB Flash drive that I am not using. Is there anyway I can turn that into a smartcard for GNUPG and other security stuff? If so, is there a tutorial/walkthrough to setting that up? From reynt0 at cs.albany.edu Thu Apr 10 01:38:00 2008 From: reynt0 at cs.albany.edu (reynt0) Date: Wed, 9 Apr 2008 19:38:00 -0400 (EDT) Subject: GnuPG v2.x? In-Reply-To: <20080409071515.25eb08e2@thewildbeast> References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <8763uylwln.fsf@wheatstone.g10code.de> <1207243216.6353.18.camel@carbon> <200804082217.04263@erwin.ingo-kloecker.de> <20080409071515.25eb08e2@thewildbeast> Message-ID: On Wed, 9 Apr 2008, Paul wrote: [back to the original, so quotation accuracy is not the issue] > On Tue, 08 Apr 2008 22:17:03 +0200 > Ingo Kl?cker wrote: > >> The S/MIME implementation in KMail (via >> gpgme/gpgsm) is the only Free Software implementation of S/MIME that >> has passed the Sphinx interoperability tests of the Federal Office for >> Information Security (BSI) > > And what else did they test besides Kmail? . . . Hmmmm.... The simple logic of that is like questions I often have, including when the topic is new to me or is about some "official" agency giving attention to someone or thing: him/her: "A did B to C." me: "Oh, did A do B to anyone/thing else?" It's a neutral way to learn more about not just B, but also about A and about C, plus about any D, E, ... which might be mentioned in the answer to my question. From email at sven-radde.de Thu Apr 10 07:51:47 2008 From: email at sven-radde.de (Sven Radde) Date: Thu, 10 Apr 2008 07:51:47 +0200 Subject: Accessing the private DOs of the smartcard In-Reply-To: <3f34f8420804091450p52e60c70ue582a12b1f6d1246@mail.gmail.com> References: <47FC9E79.5060502@sven-radde.de> <87lk3nxedg.fsf@wheatstone.g10code.de> <3f34f8420804091450p52e60c70ue582a12b1f6d1246@mail.gmail.com> Message-ID: <1207806708.6353.8.camel@carbon> Hi! Am Mittwoch, den 09.04.2008, 15:50 -0600 schrieb Allen Schultz: > I have either a 256 or a 512 MB USB Flash drive that I am not using. > Is there anyway I can turn that into a smartcard for GNUPG and other > security stuff? I was talking about the chip card, as seen here: http://www.g10code.de/p-card.html You cannot replicate its functionality with USB flash drives. If you think about "just" storing your GnuPG keys on a removable medium, that's relatively easy to do. Copy your GnuPG home directory to the stick and configure GnuPG to use that instead of the default directory, e.g. by giving "--homedir /path/to/usb/...". See also: Where the issue was discussed recently. HTH, Sven From claws at thewildbeast.co.uk Thu Apr 10 09:27:39 2008 From: claws at thewildbeast.co.uk (Paul) Date: Thu, 10 Apr 2008 08:27:39 +0100 Subject: GnuPG v2.x? In-Reply-To: <200804092137.13188@erwin.ingo-kloecker.de> References: <259C5607-6DAB-47E3-BE3F-1D468CFB92D5@fastmail.net> <47FC7350.1060709@sixdemonbag.org> <20080409190100.431f9008@thewildbeast> <200804092137.13188@erwin.ingo-kloecker.de> Message-ID: <20080410082739.381b3650@thewildbeast> On Wed, 09 Apr 2008 21:37:12 +0200 Ingo Kl?cker wrote: > IMO all Free Software MUAs should use GnuPG's S/MIME instead of rolling > their own S/MIME implementation. I couldn't agree more. Anyway, thanks for clearing that up! best regards Paul -- It isn't worth a nickle to two guys like you or me, but to a collector it is worth a fortune From dshaw at jabberwocky.com Fri Apr 11 22:17:27 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 11 Apr 2008 16:17:27 -0400 Subject: Need Help In-Reply-To: <304216.41718.qm@web94109.mail.in2.yahoo.com> References: <304216.41718.qm@web94109.mail.in2.yahoo.com> Message-ID: <20080411201727.GA1546@jabberwocky.com> On Tue, Apr 08, 2008 at 02:47:40PM +0100, Debabrata Das wrote: > Hi All, > > Currently we are using GnuPG 1.4.7 which is under GPL V2 on HP-UX ,but we came to know that there is a security vulnerability on GnuPG 1.4.8 & earlier version.Since Gnupg 1.4.9 is under GPL V3 & we don't want to move to product under GPL v3.Can you please tell us if it is permissible to back port all the changes made to GnuPg 1.4.9 on to Gnupg 1.4.7. The recent bug only applies to 1.4.8 and 2.0.8. It does not apply to 1.4.7 or any earlier version. There is no need to backport any patches. David From dshaw at jabberwocky.com Fri Apr 11 22:32:50 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 11 Apr 2008 16:32:50 -0400 Subject: Re-attaching a signature In-Reply-To: <20080406205956.GX21197@osresearch.net> References: <20080406205956.GX21197@osresearch.net> Message-ID: <20080411203250.GC1546@jabberwocky.com> On Sun, Apr 06, 2008 at 04:59:56PM -0400, Trammell Hudson wrote: > Is there a way to detach a signature from a message after it has > already been signed and then to-reattach it? As an example, let's > say that I've received a signed message encrypted to me and I want > to be able to decrypt it, verify the signature and then re-encrypt > it to resend it to someone else, but with the original signature > rather than mine. The OpenPGP protocol allows for this, but there are no tools that can currently do it. What you need is a change in GPG to unwrap only one layer of a layered object. Signed and encrypted data is layered with the data on the inside, then the signature around that, then the encryption around that. It's actually on my list of interesting things to do someday, but doesn't exist today. David From mca_debu at yahoo.co.in Tue Apr 8 15:47:40 2008 From: mca_debu at yahoo.co.in (Debabrata Das) Date: Tue, 8 Apr 2008 14:47:40 +0100 (BST) Subject: Need Help Message-ID: <304216.41718.qm@web94109.mail.in2.yahoo.com> Hi All, Currently we are using GnuPG 1.4.7 which is under GPL V2 on HP-UX ,but we came to know that there is a security vulnerability on GnuPG 1.4.8 & earlier version.Since Gnupg 1.4.9 is under GPL V3 & we don't want to move to product under GPL v3.Can you please tell us if it is permissible to back port all the changes made to GnuPg 1.4.9 on to Gnupg 1.4.7. We are interested to use whatever the changes made to bug-fix release Gnupg 1.4.9 on to Gnupg 1.4.7 which is under GPL V2 and use it. Looking forward for your response. Regards Debabrata India --------------------------------- Bring your gang together. Do your thing. Find your favourite Yahoo! Group. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail2lokesh at gmail.com Thu Apr 10 00:20:07 2008 From: mail2lokesh at gmail.com (Lokesh Madan) Date: Wed, 9 Apr 2008 15:20:07 -0700 Subject: problem in using windows Message-ID: <770bb3fe0804091520u1192b2d7m85a07afc7db33015@mail.gmail.com> Hi, I am not the group member of this list, but i have one serious problem. In one of my application i want to use the libcrypt-1.4.0 version, but my application is in windows and i am using visual c++ compiler. can anyone please help me in generating the .dll and .lib files from the package (libcrypt-1.4.0) so that i can directly call them. I am not in the mailing list please CC me your answers. Thanks in advance -- Regards, Lokesh Madan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sun Apr 13 03:03:02 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 12 Apr 2008 20:03:02 -0500 Subject: problem in using windows In-Reply-To: <770bb3fe0804091520u1192b2d7m85a07afc7db33015@mail.gmail.com> References: <770bb3fe0804091520u1192b2d7m85a07afc7db33015@mail.gmail.com> Message-ID: <48015BC6.8030306@sixdemonbag.org> Lokesh Madan wrote: > I am not the group member of this list, but i have one serious > problem. In one of my application i want to use the libcrypt-1.4.0 > version, but my application is in windows and i am using visual c++ > compiler. can anyone please help me in generating the .dll and .lib > files from the package I would suggest looking in GPG4WIN to see if the necessary files are already there. The GNU C compiler is ABI-compatible with Microsoft's C compiler; it's only in C++ that the ABIs change. Otherwise, I'd suggest asking on the MinGW list about using Microsoft's cl command-line compiler with Autotools. Finally, Microsoft's C++ compiler is, by default, not a C++ compiler at all. If you're working with C++ I would strongly suggest using Intel's C++ compiler, the GNU C++ compiler, or Sun's C++ compiler, all of which are available at very low cost to students. > I am not in the mailing list please CC me your answers. Thanks in > advance This is rude. If you're going to come on a mailing list asking for help, you should read the mailing list in order to see your replies. From JPClizbe at tx.rr.com Sun Apr 13 03:59:45 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Sat, 12 Apr 2008 20:59:45 -0500 Subject: problem in using windows In-Reply-To: <770bb3fe0804091520u1192b2d7m85a07afc7db33015@mail.gmail.com> References: <770bb3fe0804091520u1192b2d7m85a07afc7db33015@mail.gmail.com> Message-ID: <48016911.5030105@tx.rr.com> Lokesh Madan wrote: > Hi, > > I am not the group member of this list, but i have one serious problem. In > one of my application i want to use the libcrypt-1.4.0 version, but my > application is in windows and i am using visual c++ compiler. can anyone > please help me in generating the .dll and .lib files from the package > (libcrypt-1.4.0) so that i can directly call them. You may wish to look at Cygwin. You will also need libgpg-error, libintl, libiconv. You can probably use Cygwin's source modifications along with -mno-cygwin to generate the DLLs along with import and static libs. Whether you use Cygwin's or MinGW's GCC, you'll also need w32api and mingw-runtime in order to interface with the Microsoft runtime and DLLs. Details for doing this are readily available via the handy use of Google, "Google *IS* Your Friend?." > I am not in the mailing list please CC me your answers. Thanks in advance Ask here. Get your answer here. If you wish a private answer, I'll be happy to forward you my consulting rates and will gladly help you once I've received the minimum billing in advance. Otherwise, please visit http://lists.gnupg.org/mailman/listinfo/gnupg-users and subscribe. -- John P. Clizbe Inet: JPClizbe (a) tx DAWT rr DAHT con Ginger Bear Networks hkp://keyserver.gingerbear.net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 654 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Sun Apr 13 17:48:27 2008 From: wk at gnupg.org (Werner Koch) Date: Sun, 13 Apr 2008 17:48:27 +0200 Subject: problem in using windows In-Reply-To: <48015BC6.8030306@sixdemonbag.org> (Robert J. Hansen's message of "Sat, 12 Apr 2008 20:03:02 -0500") References: <770bb3fe0804091520u1192b2d7m85a07afc7db33015@mail.gmail.com> <48015BC6.8030306@sixdemonbag.org> Message-ID: <87y77hpxh0.fsf@wheatstone.g10code.de> On Sun, 13 Apr 2008 03:03, rjh at sixdemonbag.org said: > already there. The GNU C compiler is ABI-compatible with Microsoft's C > compiler; it's only in C++ that the ABIs change. To be fully ABI compatible you need to pass -mms-bitfields to gcc. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From cpollock at embarqmail.com Mon Apr 14 02:41:02 2008 From: cpollock at embarqmail.com (Chris) Date: Sun, 13 Apr 2008 19:41:02 -0500 Subject: problem installing gnupg-2.0.9 Message-ID: <200804131941.11001.cpollock@embarqmail.com> I can't seem to get the above installed. I get the below at the end of configure, I've downloaded and attempted to install the below libraries but to no avail it seems. Looking at the file dates in /usr/lib they all seem to be the older version I've installed previously. Below is a link to the config logs for gnupg-2.0.9 and the three libraries. I had no problems installing gpg v1.4.9 except copying the binaries from /usr/local/bin to /usr/bin which for some reason my box likes instead of the default install directory. *** You need libgcrypt to build this program. ** This library is for example available at *** ftp://ftp.gnupg.org/gcrypt/libgcrypt/ *** (at least version 1.2.2 using API 1 is required.) *** configure: *** *** You need libassuan with Pth support to build this program. *** This library is for example available at *** ftp://ftp.gnupg.org/gcrypt/libassuan/ *** (at least version 1.0.4 (API 1) is required). *** configure: *** *** You need libksba to build this program. *** This library is for example available at *** ftp://ftp.gnupg.org/gcrypt/libksba/ *** (at least version 1.0.2 using API 1 is required). http://www.mediamax.com/chris1948/Hosted/gnupg-2.0.9config.log http://www.mediamax.com/chris1948/Hosted/libassuanconfig.log http://www.mediamax.com/chris1948/Hosted/libgcryptconfig.log http://www.mediamax.com/chris1948/Hosted/libksbaconfig.log Any help would be greatly appreciated. Chris -- Chris KeyID 0xE372A7DA98E6705C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rjh at sixdemonbag.org Mon Apr 14 04:09:13 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 13 Apr 2008 21:09:13 -0500 Subject: problem installing gnupg-2.0.9 In-Reply-To: <200804131941.11001.cpollock@embarqmail.com> References: <200804131941.11001.cpollock@embarqmail.com> Message-ID: <4802BCC9.6030309@sixdemonbag.org> Chris wrote: > I can't seem to get the above installed. There are many, many things it could be. To help us narrow it down, try telling us your operating system and version. From 210525p42015 at denstarfarm.us Mon Apr 14 04:13:16 2008 From: 210525p42015 at denstarfarm.us (Robert D.) Date: Sun, 13 Apr 2008 22:13:16 -0400 Subject: problem installing gnupg-2.0.9 In-Reply-To: <200804131941.11001.cpollock@embarqmail.com> References: <200804131941.11001.cpollock@embarqmail.com> Message-ID: <4802BDBC.9070907@denstarfarm.us> Chris said the following: > *** You need libgcrypt to build this program. I had this problem ... and I (re)(re)read the, couch, README part and noticed that I hadn't noticed a certain key line, located in this clip second from the bottom .. the phrase "in the order" I had omitted. honestly, I did. So, since you didn't clarify, you may either pardon my ignorance for reminding you, or try to re-compile as there is a dependency: ---------------------------------------------------------------- GnuPG 2.0 depends on the following packages: libgpg-error (ftp://ftp.gnupg.org/gcrypt/libgpg-error/) libgcrypt (ftp://ftp.gnupg.org/gcrypt/libgcrypt/) libksba (ftp://ftp.gnupg.org/gcrypt/libksba/) libassuan (ftp://ftp.gnupg.org/gcrypt/libassuan/) You also need the Pinentry package for most function of GnuPG; however it is not a build requirement. Pinentry is available at ftp://ftp.gnupg.org/gcrypt/pinentry/ . You should get the latest versions of course, the GnuPG configure script complains if a version is not sufficient. After building and installing the above packages in the order as given above, you may now continue with GnuPG installation (you may also just -------------------------------------------------------------------- From cpollock at embarqmail.com Mon Apr 14 04:30:00 2008 From: cpollock at embarqmail.com (Chris) Date: Sun, 13 Apr 2008 21:30:00 -0500 Subject: problem installing gnupg-2.0.9 In-Reply-To: <200804131941.11001.cpollock@embarqmail.com> References: <200804131941.11001.cpollock@embarqmail.com> Message-ID: <200804132130.00401.cpollock@embarqmail.com> On Sunday 13 April 2008 7:41 pm, Chris wrote: > I can't seem to get the above installed. I get the below at the end of > > *** You need libgcrypt to build this program. > ** This library is for example available at > *** ftp://ftp.gnupg.org/gcrypt/libgcrypt/ > *** (at least version 1.2.2 using API 1 is required.) > *** > configure: > *** > *** You need libassuan with Pth support to build this program. > *** This library is for example available at > *** ftp://ftp.gnupg.org/gcrypt/libassuan/ > *** (at least version 1.0.4 (API 1) is required). > *** > configure: > *** > *** You need libksba to build this program. > *** This library is for example available at > *** ftp://ftp.gnupg.org/gcrypt/libksba/ > *** (at least version 1.0.2 using API 1 is required). > I probably should have shown what I do have installed: [chris at cpollock lib]$ ls -l libgcrypt* -rw-r--r-- 1 root root 466748 Aug 18 2004 libgcrypt.a -rwxr-xr-x 1 root root 833 Aug 18 2004 libgcrypt.la* lrwxrwxrwx 1 root root 19 Dec 25 2004 libgcrypt.so -> libgcrypt.so.11.1.1* lrwxrwxrwx 1 root root 19 Dec 25 2004 libgcrypt.so.11 -> libgcrypt.so.11.1.1* -rwxr-xr-x 1 root root 314280 Aug 18 2004 libgcrypt.so.11.1.1* [chris at cpollock lib]$ ls -l libassuan* -rwxr-xr-x 1 root root 798 Dec 26 2004 libassuan.la* lrwxrwxrwx 1 root root 18 Nov 23 2005 libassuan.so -> libassuan.so.0.0.0* lrwxrwxrwx 1 root root 18 Nov 23 2005 libassuan.so.0 -> libassuan.so.0.0.0* -rwxr-xr-x 1 root root 36772 Dec 26 2004 libassuan.so.0.0.0* The below I think is from a Mandrake rpm, however, I don't understand why the source wouldn't install. [chris at cpollock lib]$ ls -l libksba* lrwxrwxrwx 1 root root 16 Nov 23 2005 libksba.so.8 -> libksba.so.8.5.1* -rwxr-xr-x 1 root root 175864 Aug 18 2004 libksba.so.8.5.1* -- Chris KeyID 0xE372A7DA98E6705C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From cpollock at embarqmail.com Mon Apr 14 04:32:26 2008 From: cpollock at embarqmail.com (Chris) Date: Sun, 13 Apr 2008 21:32:26 -0500 Subject: problem installing gnupg-2.0.9 In-Reply-To: <4802BDBC.9070907@denstarfarm.us> References: <200804131941.11001.cpollock@embarqmail.com> <4802BDBC.9070907@denstarfarm.us> Message-ID: <200804132132.26957.cpollock@embarqmail.com> On Sunday 13 April 2008 9:13 pm, Robert D. wrote: > Chris said the following: > > *** You need libgcrypt to build this program. > > I had this problem ... and I (re)(re)read the, couch, README part and > noticed that I hadn't noticed a certain key line, located in this clip > second from the bottom .. the phrase "in the order" I had omitted. > honestly, I did. So, since you didn't clarify, you may either pardon my > ignorance for reminding you, or try to re-compile as there is a dependency: > > ---------------------------------------------------------------- > > GnuPG 2.0 depends on the following packages: > > libgpg-error (ftp://ftp.gnupg.org/gcrypt/libgpg-error/) > libgcrypt (ftp://ftp.gnupg.org/gcrypt/libgcrypt/) > libksba (ftp://ftp.gnupg.org/gcrypt/libksba/) > libassuan (ftp://ftp.gnupg.org/gcrypt/libassuan/) > > You also need the Pinentry package for most function of GnuPG; however > it is not a build requirement. Pinentry is available at > ftp://ftp.gnupg.org/gcrypt/pinentry/ . > > You should get the latest versions of course, the GnuPG configure > script complains if a version is not sufficient. > > After building and installing the above packages in the order as given > above, you may now continue with GnuPG installation (you may also just > -------------------------------------------------------------------- > Thanks Robert, I didn't notice that, guess I read too fast. I'll give it another go tomorrow night and see what happens. Thanks Chris -- Chris KeyID 0xE372A7DA98E6705C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From cpollock at embarqmail.com Mon Apr 14 04:33:21 2008 From: cpollock at embarqmail.com (Chris) Date: Sun, 13 Apr 2008 21:33:21 -0500 Subject: problem installing gnupg-2.0.9 In-Reply-To: <4802BCC9.6030309@sixdemonbag.org> References: <200804131941.11001.cpollock@embarqmail.com> <4802BCC9.6030309@sixdemonbag.org> Message-ID: <200804132133.22260.cpollock@embarqmail.com> On Sunday 13 April 2008 9:09 pm, Robert J. Hansen wrote: > Chris wrote: > > I can't seem to get the above installed. > > There are many, many things it could be. To help us narrow it down, try > telling us your operating system and version. Guess that would have helped, Linux, Mandrake 10.1 -- Chris KeyID 0xE372A7DA98E6705C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From shavital at mac.com Mon Apr 14 05:56:58 2008 From: shavital at mac.com (Charly Avital) Date: Sun, 13 Apr 2008 23:56:58 -0400 Subject: problem installing gnupg-2.0.9 In-Reply-To: <200804131941.11001.cpollock@embarqmail.com> References: <200804131941.11001.cpollock@embarqmail.com> Message-ID: <4802D60A.4020603@mac.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Chris wrote the following on 4/13/08 8:41 PM: > I can't seem to get the above installed. I get the below at the end of > configure, I've downloaded and attempted to install the below libraries but > to no avail it seems. Looking at the file dates in /usr/lib they all seem to > be the older version I've installed previously. Below is a link to the config > logs for gnupg-2.0.9 and the three libraries. I had no problems installing > gpg v1.4.9 except copying the binaries from /usr/local/bin to /usr/bin which > for some reason my box likes instead of the default install directory. > > *** You need libgcrypt to build this program. > ** This library is for example available at > *** ftp://ftp.gnupg.org/gcrypt/libgcrypt/ > *** (at least version 1.2.2 using API 1 is required.) > *** > configure: > *** > *** You need libassuan with Pth support to build this program. > *** This library is for example available at > *** ftp://ftp.gnupg.org/gcrypt/libassuan/ > *** (at least version 1.0.4 (API 1) is required). > *** > configure: > *** > *** You need libksba to build this program. > *** This library is for example available at > *** ftp://ftp.gnupg.org/gcrypt/libksba/ > *** (at least version 1.0.2 using API 1 is required). > > http://www.mediamax.com/chris1948/Hosted/gnupg-2.0.9config.log > http://www.mediamax.com/chris1948/Hosted/libassuanconfig.log > http://www.mediamax.com/chris1948/Hosted/libgcryptconfig.log > http://www.mediamax.com/chris1948/Hosted/libksbaconfig.log > > Any help would be greatly appreciated. > > Chris > > Hi Chris, The raw source of your e-mail indicates that you are using KMail. If that's correct, I'll guess that you are running Linux. I am a Macintosh user, but run Ubuntu 7.10 under virtual-ware Parallels 3.0. I have compiled 2.0.9 under Ubuntu, upgrading from 2.0.7, and then 2.0.8. GPG2 requires that certain libraries be installed, before gpg2 can actually be compiled and installed. The README file included in the expanded source code of 2.0.9 should indicate exactly which libraries should be compiled and installed, and in what order. In addition to the libraries that you have indicated above, there is also the issue of gettext. I believe that if you have already a gettext version that is above 0.14, you are safe. Type in Terminal gettext --version, and you'll know. All the above is "the fruit" of my empirical knowledge. I have a very basic, limited and unprofessional grasp of all these matters. If you really want to install gpg2 in your Linux environment, just arm yourself with patience, and be ready that in spite of your having compiled and installed everything that is required, you *might* still get some error-warning that you still need some other library, or a more recent version of one of the installed libraries. Charly -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: GnuPG for Privacy Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBCAAGBQJIAtYBAAoJEM3GMi2FW4Pv3cQH/iIJCNbbdUyGGM4ih2REKO7J usclNrwyCc2KLdOmWeioIch/o2Vhi+PbDLLwA2FcnYOUOq85M4sULUNLXWOhmW1u sjc0VIEE4tPX2gU5BVcjWglx5IXj4i5LvoMKPbb3XJfLul9CpmiL443XcFWeDVHU AEnjmul5fxfZbpnRckGL+oJkjDWyBrTDryvBtj+08xkvoaBwUyeU1N/3S+uLsvsH kpIZQltvo8gNT6XK/8Zbg0o4n9szg97Ws6iJDOcsqp58mwC7SeDleB+sPi8bk0QG EYhuibSoCIu/GUY5ChEH8KGUw8aIkgql8nD10rd5RozhoNEIf8UBg791xKBTt0Y= =k6DZ -----END PGP SIGNATURE----- From ladislav.hagara at unob.cz Mon Apr 14 11:33:52 2008 From: ladislav.hagara at unob.cz (Ladislav Hagara) Date: Mon, 14 Apr 2008 11:33:52 +0200 Subject: problem installing gnupg-2.0.9 In-Reply-To: <200804132130.00401.cpollock@embarqmail.com> References: <200804131941.11001.cpollock@embarqmail.com> <200804132130.00401.cpollock@embarqmail.com> Message-ID: <48032500.6030309@unob.cz> >> I can't seem to get the above installed. I get the below at the end of >> >> *** You need libgcrypt to build this program. >> ** This library is for example available at >> *** ftp://ftp.gnupg.org/gcrypt/libgcrypt/ >> *** (at least version 1.2.2 using API 1 is required.) >> *** >> configure: >> *** >> *** You need libassuan with Pth support to build this program. >> *** This library is for example available at >> *** ftp://ftp.gnupg.org/gcrypt/libassuan/ >> *** (at least version 1.0.4 (API 1) is required). >> *** >> configure: >> *** >> *** You need libksba to build this program. >> *** This library is for example available at >> *** ftp://ftp.gnupg.org/gcrypt/libksba/ >> *** (at least version 1.0.2 using API 1 is required). >> >> > > I probably should have shown what I do have installed: > > [chris at cpollock lib]$ ls -l libgcrypt* > -rw-r--r-- 1 root root 466748 Aug 18 2004 libgcrypt.a > -rwxr-xr-x 1 root root 833 Aug 18 2004 libgcrypt.la* > lrwxrwxrwx 1 root root 19 Dec 25 2004 libgcrypt.so -> > libgcrypt.so.11.1.1* > lrwxrwxrwx 1 root root 19 Dec 25 2004 libgcrypt.so.11 -> > libgcrypt.so.11.1.1* > -rwxr-xr-x 1 root root 314280 Aug 18 2004 libgcrypt.so.11.1.1* > > [chris at cpollock lib]$ ls -l libassuan* > -rwxr-xr-x 1 root root 798 Dec 26 2004 libassuan.la* > lrwxrwxrwx 1 root root 18 Nov 23 2005 libassuan.so -> libassuan.so.0.0.0* > lrwxrwxrwx 1 root root 18 Nov 23 2005 libassuan.so.0 -> > libassuan.so.0.0.0* > -rwxr-xr-x 1 root root 36772 Dec 26 2004 libassuan.so.0.0.0* > > The below I think is from a Mandrake rpm, however, I don't understand why the > source wouldn't install. > > [chris at cpollock lib]$ ls -l libksba* > lrwxrwxrwx 1 root root 16 Nov 23 2005 libksba.so.8 -> libksba.so.8.5.1* > -rwxr-xr-x 1 root root 175864 Aug 18 2004 libksba.so.8.5.1* > > What versions of these libs do you have? Older than required. See dates (2004). For example libksba: My libksba 1.0.2. provides libksba.so.8.9.2, your libksba provides libksba.so.8.5.1. Just update your libraries/distro. -- Ladislav Hagara http://www.sourcemage.org/ From wk at gnupg.org Mon Apr 14 13:07:19 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 14 Apr 2008 13:07:19 +0200 Subject: problem installing gnupg-2.0.9 In-Reply-To: <200804131941.11001.cpollock@embarqmail.com> (cpollock@embarqmail.com's message of "Sun, 13 Apr 2008 19:41:02 -0500") References: <200804131941.11001.cpollock@embarqmail.com> Message-ID: <8763ukpue0.fsf@wheatstone.g10code.de> On Mon, 14 Apr 2008 02:41, cpollock at embarqmail.com said: > *** You need libgcrypt to build this program. > ** This library is for example available at > *** ftp://ftp.gnupg.org/gcrypt/libgcrypt/ > *** (at least version 1.2.2 using API 1 is required.) Looking at the config log: configure:6032: checking for libgcrypt-config configure:6050: found /usr/bin/libgcrypt-config configure:6063: result: /usr/bin/libgcrypt-config configure:6080: checking for LIBGCRYPT - version >= 1.2.2 configure:6117: result: no shows that configure picked up the system installed libgcrypt and not the one you build and installed which probably installed as /usr/local/bin/libgcrypt-config. I assume that /usr/local is not in your PATH before /usr/bin and thus you get the wrong one. You need to make sure that the recent libgcrypt-config gets picked up first. You can advise the configure script to do that: $ ./configure --with-libgcrypt-prefix=/usr/local As an alternative you can set the environment variable $ LIBGCRYPT_CONFIG=/usr/local/bin/libgcrypt-config $ export LIBGCRYPT_CONFIG and then run configure. You may also want to test whether this is the correct configure script, like in: $ /usr/local/bin/libgcrypt-config --version 1.4.0 Similar options are available for the other libraries. Thus a $ ./configure --with-ksba-prefix=/usr/local \ --with-libgcrypt-prefix=/usr/local \ --with-libassuan-prefix=/usr/local $ make should get you a bit further. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From lhshas at googlemail.com Mon Apr 14 16:46:33 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Mon, 14 Apr 2008 16:46:33 +0200 Subject: Miscellaneous questions Message-ID: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> Hi list. I've got some questions... 1) When creating a new UID, why does gpg have a minimum size of 5 characters? This is not imposed by RFC4880? Where can I report this bug. 2) I have a key that is already published to keyservers. Unfortunately it uses old SHA1 as hasing algorithm. Now I want to recreate the selfsignature (but using SHA512) and mark the old selfsignature(s) (the 0x13's on my UIDs) that they _can_ not longer be used. Most OpenPGP would simply only use the newer self-sig (according to the creation time) but RFC4880 says that an implementation might use any other means to resolve ambiguites so just having to self-sigs published doesn't go far enought for me. I want the old selfsigs revoked (btw: what would be a good reason for revocation?) and have a new self-sig on the (same) UIDs. Main reason for this is probably to prevent downgrade attacks or similar stuff. While the standard seems to allow this,.. gpg does not (it won't sign a UID when the a self-sig has been revoked before). How can I solve this? 3) On an existing key,.. how can I change the key usage flags with gpg? 4) gpg stores most (all) of the preferences in 0x13 self-sigs. I know that this could make sense for the preferred algorithms and the features but I think that I prefer to have a sort of default preferences in an 0x1F self-sig. e.g. I'd like to set the algorithm preferences globally on a 0x1F and only set it "locally" for one UID if the environment where that UID is used hast different settings. The key usage and key-server-prefs should be always on a 0x1F selfsig and not und 0x13's because these are information about the key itself,... and not a UID,... and they don't have that role-style as with the algorithm-prefs and key features. Yes I know that RFC4880 allows key usage flags and key server prefs on 0x13's,... but I think that's still not the best idea. How can I change this in gpg, that it puts these on 0x1F? 5) Last but not least,... when setting the algorithm preferences gpg always automatically adds 3DES, SHA1 and uncompressed. I now that all of these are must-implement algorithms. But RFC4880 does not say, that the preference subpacktes must include them. It just says it's good behaviour. I think the export mode should allow it to not have them set. My reason therefore is this: An OpenPGP implementation MUST implement these algorithms,... if they are part of the subpackets or not.... so communication will work anyway. But when I despite the good-behaviour stuff remove those algorithms from the preference subpacktes, I make a statement like saying: I don't care what RFC4880 says,.. I consider 3DES as unsafe for my needs and won't accept anything using it... same idea goes with the hashing algorithms. For the compression preference,.... you now that there are attacks that are thwarted by using compression, right? Well removing uncompressed from the list, could say something like: Although I support uncompressed datapackets (of course every implementation does) I don't want,.. that anybody sends me uncompressed data,.. because I fear those attacks. Regards, H.F. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Mon Apr 14 19:19:17 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 Apr 2008 12:19:17 -0500 Subject: Miscellaneous questions In-Reply-To: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> Message-ID: <48039215.6010808@sixdemonbag.org> Herbert Furting wrote: > 1) When creating a new UID, why does gpg have a minimum size of 5 > characters? This is not imposed by RFC4880? Where can I report this bug. It's not a bug. It's a deliberate design decision on the part of the GnuPG authors. > 2) I have a key that is already published to keyservers. Unfortunately > it uses old SHA1 as hasing algorithm. I would not recommend this sort of brain surgery on a key. If you're that concerned about the use of SHA1, I would suggest just generating an entirely new key that is entirely to your specifications. > How can I change this in gpg, that it puts these on 0x1F? Hack the source. > 5) Last but not least,... when setting the algorithm preferences gpg > always automatically adds 3DES, SHA1 and uncompressed. I now that all of > these are must-implement algorithms. But RFC4880 does not say, that the > preference subpacktes must include them. It just says it's good behaviour. > I think the export mode should allow it to not have them set. Why? Your reason doesn't make sense. > the preference subpacktes, I make a statement like saying: I don't care > what RFC4880 says,.. I consider 3DES as unsafe for my needs and won't > accept anything using it... same idea goes with the hashing algorithms. Sorry. This is not a statement about anything other than "I'm not following RFC4880's best practice". If I see that you're omitting 3DES from your preference list, I'm not going to think you're making a statement about 3DES. I'm going to think you're not following RFC4880's best practice. Other people in the world are not telepathic, cannot read your mind, and cannot rationally infer what you want us to infer. I will happily send you 3DES traffic regardless, since it happens to be a high preference of mine and it's automatically going to be on yours. Incidentally, if you can't articulate solid cryptanalytic reasons why 3DES is an unsafe choice for you, you really shouldn't be arguing against 3DES. There's a joke I often tell the undergrad computer security course here--"3DES: turning brilliant young graduate students into burned-out alcoholic wrecks since 1974." 3DES has all the aesthetics of a Soviet worker's housing bloc, and just as much durability. It is quite slow by modern standards, but it is ridiculously overdesigned for its task--_ridiculously_ overdesigned. If there are attacks against 3DES you're worried about, then please share them with the rest of us so we can be better-informed. > implementation does) I don't want,.. that anybody sends me uncompressed > data,.. because I fear those attacks. If you're this concerned about cryptanalytic attacks, I have to ask how many heavily-armed Marines you have guarding your key. You're talking about adding more armor plating to the vault door of your home. An attacker is most likely going to pick up a chainsaw and just cut through the wall. It's what I'd do. Do not fetishize cryptography. It will not save you. It is not magic pixie dust. From dshaw at jabberwocky.com Mon Apr 14 19:41:30 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 14 Apr 2008 13:41:30 -0400 Subject: Miscellaneous questions In-Reply-To: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> Message-ID: <20080414174129.GE54766@jabberwocky.com> On Mon, Apr 14, 2008 at 04:46:33PM +0200, Herbert Furting wrote: > Hi list. > > I've got some questions... > > 1) When creating a new UID, why does gpg have a minimum size of 5 > characters? This is not imposed by RFC4880? Where can I report this bug. Not a bug. It's there to protect people from making poor UIDs. you can turn off the check with --allow-freeform-uid. > 2) I have a key that is already published to keyservers. Unfortunately it > uses old SHA1 as hasing algorithm. > Now I want to recreate the selfsignature (but using SHA512) and mark the old > selfsignature(s) (the 0x13's on my UIDs) that they _can_ not longer be used. > Most OpenPGP would simply only use the newer self-sig (according to the > creation time) but RFC4880 says that an implementation might use any other > means to resolve ambiguites so just having to self-sigs published doesn't go > far enought for me. I want the old selfsigs revoked (btw: what would be a > good reason for revocation?) and have a new self-sig on the (same) UIDs. > Main reason for this is probably to prevent downgrade attacks or similar > stuff. > While the standard seems to allow this,.. gpg does not (it won't sign a UID > when the a self-sig has been revoked before). > How can I solve this? GPG allows this. Add "--expert" to your command line when you want to re-sign the UID, and GPG will allow you to do what you want. Mind you, while GPG can do it, I don't think what you are doing is a good idea: OpenPGP itself uses SHA1 in a number of places. These are not changeable, so even if you purge SHA1 from your key, note that you're still using SHA1. Also, SHA512 is not widely implemented yet. You can very easily render your key not usable by a large percentage of the population if you pick a hash they don't have. > 3) On an existing key,.. how can I change the key usage flags with gpg? Modify the source. > 4) gpg stores most (all) of the preferences in 0x13 self-sigs. I know that > this could make sense for the preferred algorithms and the features but I > think that I prefer to have a sort of default preferences in an 0x1F > self-sig. e.g. I'd like to set the algorithm preferences globally on a 0x1F > and only set it "locally" for one UID if the environment where that UID is > used hast different settings. > > The key usage and key-server-prefs should be always on a 0x1F selfsig and > not und 0x13's because these are information about the key itself,... and > not a UID,... and they don't have that role-style as with the > algorithm-prefs and key features. Yes I know that RFC4880 allows key usage > flags and key server prefs on 0x13's,... but I think that's still not the > best idea. > How can I change this in gpg, that it puts these on 0x1F? Modify the source. > 5) Last but not least,... when setting the algorithm preferences gpg always > automatically adds 3DES, SHA1 and uncompressed. I now that all of these are > must-implement algorithms. But RFC4880 does not say, that the preference > subpacktes must include them. It just says it's good behaviour. > I think the export mode should allow it to not have them set. > My reason therefore is this: > An OpenPGP implementation MUST implement these algorithms,... if they are > part of the subpackets or not.... so communication will work anyway. But > when I despite the good-behaviour stuff remove those algorithms from the > preference subpacktes, I make a statement like saying: I don't care what > RFC4880 says,.. I consider 3DES as unsafe for my needs and won't accept > anything using it... same idea goes with the hashing algorithms. > For the compression preference,.... you now that there are attacks that are > thwarted by using compression, right? > Well removing uncompressed from the list, could say something like: Although > I support uncompressed datapackets (of course every implementation does) I > don't want,.. that anybody sends me uncompressed data,.. because I fear > those attacks. You can do this with "setpref" but there is no point. GPG is just a computer program and doesn't care about making statements. If you take 3DES, SHA1 and Uncompressed out, any program that sees your key will just internally put them back in again as required by 4880. David From prlewis at letterboxes.org Mon Apr 14 23:05:58 2008 From: prlewis at letterboxes.org (Peter Lewis) Date: Mon, 14 Apr 2008 22:05:58 +0100 Subject: How trust works in gpg... Message-ID: <200804142205.59132.prlewis@letterboxes.org> Hi there, Firstly, apolgies if this is a simple query. I didn't get the answer though from reading the manual. My friend and I signed each others' keys last week. However, since then he has added another UID with his work email address to his key. This showed up in my keyring when I sync'ed with the keyserver. This was after I had signed his key. However his new UID is not shown as trusted by me, even though he has signed his new UID with his key, which I have in turn also signed. Is this supposed to happen? Thanks, Pete. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part. URL: From lhshas at googlemail.com Mon Apr 14 23:50:46 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Mon, 14 Apr 2008 23:50:46 +0200 Subject: How trust works in gpg... In-Reply-To: <200804142205.59132.prlewis@letterboxes.org> References: <200804142205.59132.prlewis@letterboxes.org> Message-ID: <1208209846.9323.1.camel@fermat.scientia.net> Hi Peter. Trust and signatures are different things (of course they are connected). You can change the trust on the key with the "trust" command when editing his key. Herbert. From lhshas at googlemail.com Mon Apr 14 23:22:59 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Mon, 14 Apr 2008 23:22:59 +0200 Subject: Miscellaneous questions In-Reply-To: <20080414174129.GE54766@jabberwocky.com> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <20080414174129.GE54766@jabberwocky.com> Message-ID: <1208208179.8757.8.camel@fermat.scientia.net> Hi David. On Mon, 2008-04-14 at 13:41 -0400, David Shaw wrote: > Not a bug. It's there to protect people from making poor UIDs. you > can turn off the check with --allow-freeform-uid. Ah thanks,.. wouldn't it make sense to merge this with the expert flag? > > While the standard seems to allow this,.. gpg does not (it won't sign a UID > > when the a self-sig has been revoked before). > > How can I solve this? > GPG allows this. Add "--expert" to your command line when you want to > re-sign the UID, and GPG will allow you to do what you want. Ah great,... and it will work with gpg,... I mean a layout like, [pubkey packet] [UID packet] [positive user certification 1] [revoc of positive user certification 1] ?[positive user certification 2 (with better algos)] > Mind you, while GPG can do it, I don't think what you are doing is a > good idea: OpenPGP itself uses SHA1 in a number of places. I know,.. but in the signatures,.. only the revocation key subpacket uses it, right? The signatures (even the certification sigs) are made directly on the key (and additional data like the UID), right? So as far as I understand,.. I should actually gain some security, at least from the point that an attacker could no longer concentrate on attacking my SHA1 sigs. If he want's to do a downgrade attack (recreate an new SHA1 selfsig) he would have to attack the signature algorithm itself (e.g. RSA) ... or kick me until I gave him my private key ;) So the only left areas where I should use SHA1 is hmm the MDC and the fingprint right? When I always make signatures (of course with "something better" than SHA1) the SHA1 in the MDC is no problem at all... And for the fingerprint,... in principle,... I could not rely on the fingerprint (when singing other keys) but ask for a copy of the key itself,.. when meeting someone. Does this make sense? > These are > not changeable, so even if you purge SHA1 from your key, note that > you're still using SHA1. btw: When is this going to be changed? i.e. the fingerprint algorithm? > Also, SHA512 is not widely implemented yet. > You can very easily render your key not usable by a large percentage > of the population if you pick a hash they don't have. Yeah,... I know this,... unfortunately (at least from my point of view) gpg and this list, seems to be very conservative it such issues :-/ (don't want to offend you ;) ) > > 3) On an existing key,.. how can I change the key usage flags with gpg? > Modify the source. Ok, if I modify it,.. and create a 0x1F with key usage, key server-prefs, algorithm prefs, and so on... Will gpg understand this? What will happen if I have both, e.g. a hash algo pref subpacket on a 0x1F and a 0x13? Last but not least,.. I've already browsed through the source code... could you please point me at the functions where I can put together the bits for a (signature) packet (the type of the sig, date, hashed subpacktes, and so on),... and the function that creates the actual signature (MPI and so on) on this data and the (in case of an 0x1F) on the key and UID? Ah and,.. same question as to rjh,... (I hope you read my answer to his mail,.. and share me your thoughts on my ideas :) )... why does gpg make no use of them by default? > You can do this with "setpref" but there is no point. GPG is just a > computer program and doesn't care about making statements. If you > take 3DES, SHA1 and Uncompressed out, any program that sees your key > will just internally put them back in again as required by 4880. Yes of course,... but (hopefully) on the end of the _internal_ list. btw: What do you think about my ideas on this issue,.. that I wrote down in the reply to Robert? Regards, Herbert. From dshaw at jabberwocky.com Mon Apr 14 23:55:43 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 14 Apr 2008 17:55:43 -0400 Subject: How trust works in gpg... In-Reply-To: <200804142205.59132.prlewis@letterboxes.org> References: <200804142205.59132.prlewis@letterboxes.org> Message-ID: <20080414215543.GA55036@jabberwocky.com> On Mon, Apr 14, 2008 at 10:05:58PM +0100, Peter Lewis wrote: > Hi there, > > Firstly, apolgies if this is a simple query. I didn't get the answer though > from reading the manual. > > My friend and I signed each others' keys last week. However, since then he has > added another UID with his work email address to his key. This showed up in > my keyring when I sync'ed with the keyserver. This was after I had signed his > key. However his new UID is not shown as trusted by me, even though he has > signed his new UID with his key, which I have in turn also signed. > > Is this supposed to happen? Yes. It's fairly common to say "I signed a key", but in reality, you're signing a UID on a key. Thus, the UID that you signed is marked as valid, but the UID you didn't sign isn't. If you want that UID to be valid as well, you need to sign it too. David From lhshas at googlemail.com Mon Apr 14 23:03:19 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Mon, 14 Apr 2008 23:03:19 +0200 Subject: Miscellaneous questions In-Reply-To: <48039215.6010808@sixdemonbag.org> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> Message-ID: <1208206999.8238.7.camel@fermat.scientia.net> On Mon, 2008-04-14 at 12:19 -0500, Robert J. Hansen wrote: > > 1) When creating a new UID, why does gpg have a minimum size of 5 > > characters? This is not imposed by RFC4880? Where can I report this bug. > It's not a bug. It's a deliberate design decision on the part of the > GnuPG authors. Uhm,.. apart from the answer from David (who told me the correct parameter) I don't think that an implementation should forbid this (making UIDs smaller than 5 characters). OpenPGP is said to be open,... and the specification of the UID packet only says, that the intended uses is a mail name-addr. It doesn't say that it must be one. I'd be happier if it would clearly say, that it's just an ID that identifies the user (as the packet name says) but that most people use a mail name-addr. Imagine a closed software system that uses simply numbers for identifying the participants. When it starts at 1, we have UIDs smaller than 5 characters. > > 2) I have a key that is already published to keyservers. Unfortunately > > it uses old SHA1 as hasing algorithm. > I would not recommend this sort of brain surgery on a key. If you're > that concerned about the use of SHA1, I would suggest just generating an > entirely new key that is entirely to your specifications. Hm why? I'd loose a lot of certifications and I don't see any security problem with my approach (of course, as David said, SHA-1 is still used in some other places). > > How can I change this in gpg, that it puts these on 0x1F? > Hack the source. Uhm,.. is there any reason why gpg doesn't support it? I mean it exists,.. and there are several things (e.g. the examples from my inital post) that would be better of with an 0x1F? > > 5) Last but not least,... when setting the algorithm preferences gpg > > always automatically adds 3DES, SHA1 and uncompressed. I now that all of > > these are must-implement algorithms. But RFC4880 does not say, that the > > preference subpacktes must include them. It just says it's good behaviour. > > I think the export mode should allow it to not have them set. > Why? Your reason doesn't make sense. Why not? The RFC (and even the meaning of the name "preference packet") say, that these subpackets are a way for the user to express his preferences on alorithms. It does not say that they have to include those fall-back-algorithms, it just says they should. So when a user wishes not to include e.g. 3DES it should clearly mean,.. I don't like that algorithm, despite the fact, that his implementation has to support it. What the authors of RFC4880 had probably in mind when saying this is a best practise (at least I think so,.. David?! ;) ) was: As every implementation has to support it,...put it in the list. But this packet is not about specifying what an implementation is able to do, but what the user would like to have. I think they were tempted by the fact, that a preference list that contains the must-have algorithms could be used easier for algorithm-negotiation. > > the preference subpacktes, I make a statement like saying: I don't care > > what RFC4880 says,.. I consider 3DES as unsafe for my needs and won't > > accept anything using it... same idea goes with the hashing algorithms. > Sorry. This is not a statement about anything other than "I'm not > following RFC4880's best practice". Hm yes,.. but in all doing respect,... this practise is probably not the best as it does not tell the users preference but a mix of the users preference and the minimal algorithm subset. But the implementation already knows about that minimal must-have subset (because of the standard). It's not necessary to mix it up with the users preference. > If I see that you're omitting 3DES from your preference list, I'm not > going to think you're making a statement about 3DES. I'm going to think > you're not following RFC4880's best practice. Other people in the world > are not telepathic, cannot read your mind, and cannot rationally infer > what you want us to infer. See above. > I will happily send you 3DES traffic Yes, but that's already the case because each implementation must support 3DES, not because you or me put it in our lists. > regardless, since it happens to be a high preference of mine and it's > automatically going to be on yours. Yes it will work (even if I said,... I don't like 3DES). But an implementation could provide options to warn a user, if he receives such messages. > Incidentally, if you can't articulate solid cryptanalytic reasons why > 3DES is an unsafe choice for you, you really shouldn't be arguing > against 3DES. There's a joke I often tell the undergrad computer > security course here--"3DES: turning brilliant young graduate students > into burned-out alcoholic wrecks since 1974." > > 3DES has all the aesthetics of a Soviet worker's housing bloc, and just > as much durability. It is quite slow by modern standards, but it is > ridiculously overdesigned for its task--_ridiculously_ overdesigned. > > If there are attacks against 3DES you're worried about, then please > share them with the rest of us so we can be better-informed. Well then why does OpenPGP allow us to use newer algos? Why did we change the fingerprint algo to SHA-1? Ok MD5 is much weaker than SHA1 (as 3DES is probably weaker than AES) but for "normal" people it should still be impossible to forge MD5 hashes, and if an intelligence service wants your data,.. they simply kidnap and torture you. To be honest,.. I don't see your arguments above,... apart from the fact, that I didn't asked about the pros and cons of algorithms. Why do we make the whole crypto stuff,... if we stick with old algorithms (probably weaker than newer ones). > > implementation does) I don't want,.. that anybody sends me uncompressed > > data,.. because I fear those attacks. > If you're this concerned about cryptanalytic attacks, I have to ask how > many heavily-armed Marines you have guarding your key. Well,.. I have a fighter australian parrot ;-) ... > You're talking > about adding more armor plating to the vault door of your home. An > attacker is most likely going to pick up a chainsaw and just cut through > the wall. ... again: If so,. why do we make all that effort? We could simply keep using MD5/IDEA because for most cases that would be enough. Regards, Herb. From prlewis at letterboxes.org Tue Apr 15 00:20:29 2008 From: prlewis at letterboxes.org (Peter Lewis) Date: Mon, 14 Apr 2008 23:20:29 +0100 Subject: How trust works in gpg... In-Reply-To: <1208209846.9323.1.camel@fermat.scientia.net> References: <200804142205.59132.prlewis@letterboxes.org> <1208209846.9323.1.camel@fermat.scientia.net> Message-ID: <200804142320.29571.prlewis@letterboxes.org> Thanks Herbert, David, for the quick replies. On Monday 14 April 2008 at 22:50:46 Herbert Furting wrote: > Trust and signatures are different things (of course they are > connected). > > You can change the trust on the key with the "trust" command when > editing his key. Ah yes, thanks. So I have now set the owner-trust for his key to "full", but still it says "unknown" for the other UIDs. So, I should manually set the trust for keys / UIDs that I think I trust based on who has signed them? I was under the impression that the trust would be inferred automatically by gpg, according to the trust rules ("completes-needed", "marginals-needed", "max-cert-depth"). For example, in this case, I have trusted his key fully, and he has signed his UID, which is one complete link (or two from my own key), right? If not, what is the purpose of these parameters? On Monday 14 April 2008 at 22:55:43 David Shaw wrote: > Yes. It's fairly common to say "I signed a key", but in reality, > you're signing a UID on a key. Thus, the UID that you signed is > marked as valid, but the UID you didn't sign isn't. If you want that > UID to be valid as well, you need to sign it too. Is there any reason not to do this? I.e. is it possible for someone else to upload a UID to his key and make it look like he's signed it? Sorry for the newbie questions! Pete. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Tue Apr 15 01:06:49 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 Apr 2008 18:06:49 -0500 Subject: Miscellaneous questions In-Reply-To: <1208206999.8238.7.camel@fermat.scientia.net> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> Message-ID: <4803E389.3090500@sixdemonbag.org> Herbert Furting wrote: >>> 1) When creating a new UID, why does gpg have a minimum size of 5 >>> characters? This is not imposed by RFC4880? Where can I report >>> this bug. >> >> It's not a bug. It's a deliberate design decision on the part of >> the GnuPG authors. > > Uhm,.. apart from the answer from David (who told me the correct > parameter) I don't think that an implementation should forbid this > (making UIDs smaller than 5 characters). There are two responses here: 1. You didn't ask for the option to allow zero-length UIDs. If you'd asked for that option, I would have given it. You asked "why does GnuPG have a minimum size of five characters", "is this imposed by RFC4880", and "where can I report this bug". Your questions were answered. Don't blame me if you asked the wrong questions. 2. The beautiful thing about open standards is that anyone can implement them. The beautiful thing about open source is that anyone can change it. If you really think it's so stupid to forbid short UIDs, then hack the source and submit a patch. It's a trivial change. > OpenPGP is said to be open,... and the specification of the UID > packet only says, that the intended uses is a mail name-addr. It > doesn't say that it must be one. You're misunderstanding the purpose of a specification. A specification does not set a high-water mark for implementations. It sets a low-water mark. Implementations are free to restrict keys in any way they want, so long as the low-water mark is met. If you want to write an RFC2440 implementation that supports only DSA, SHA-1 and 3DES, nobody will stop you. You're meeting the low-water mark. GnuPG would be entirely within rights to require that all UIDs be set to "aaaaaaa". Or to leave them utterly blank. Or to not give users a choice in them at all. As long as GnuPG understands RFC-conformant UIDs and generates RFC-conformant UIDs, that's all it has to do according to the RFC. In reality, GnuPG is guided by concerns beyond just strict RFC conformance: interoperability, ease of use, and others. > Imagine a closed software system that uses simply numbers for > identifying the participants. When it starts at 1, we have UIDs > smaller than 5 characters. Imagine the interoperability problems you will have when your UIDs do not conform to the de-facto standard. If you want to do things that will deliberately mangle your interoperability, go ahead: --allow-freeform-uid will let you do that. GnuPG will, by default, try to keep you very interoperable. That's clearly the Right Thing To Do. > Hm why? I'd loose a lot of certifications and I don't see any > security problem with my approach (of course, as David said, SHA-1 is > still used in some other places). Interoperability. There are a lot of people out there using old, decrepit versions of PGP and GnuPG. Old versions tend not to react very well when people decide to get creative in ways that were not foreseen back when the old versions were written. > Uhm,.. is there any reason why gpg doesn't support it? Yes. Because you haven't written a patch for it. > I mean it exists,.. and there are several things (e.g. the examples > from my inital post) that would be better of with an 0x1F? You're ascribing magical meanings to things. You're not going to be safer under your scheme. It's different--it's not better. I don't know why GnuPG does it this way. I strongly suspect it's for historical reasons and interoperability concerns. > those fall-back-algorithms, it just says they should. So when a user > wishes not to include e.g. 3DES it should clearly mean... And this is the problem: you _are_ including it. The RFC requires them to be present, and if they're not present, requires all implementations to add them. You're not communicating anything other than "I am not paying attention to the best practice outlined in the RFC." Your correspondents are not going to say "oh, you don't like 3DES". They're going to say "oh, you're using a badly-written OpenPGP implementation, here, let me fix that for you." > Hm yes,.. but in all doing respect,... this practise is probably not > the best as it does not tell the users preference but a mix of the > users preference and the minimal algorithm subset. Then join the WG and advocate for this position. It's an open WG. >> I will happily send you 3DES traffic > > Yes, but that's already the case because each implementation must > support 3DES, not because you or me put it in our lists. Speak for yourself. My personal-cipher-preferences has 3DES explicitly listed as my first preference. I see no reason not to use 3DES and I know 3DES will be supported by everyone, so why not use 3DES and avoid the risk of a problem existing? > Yes it will work (even if I said,... I don't like 3DES). But an > implementation could provide options to warn a user, if he receives > such messages. Why? You're assuming 3DES is a weak cipher. It's not. It's really quite grotesquely overdesigned. The best attack against it, _in thirty-four years of intense cryptanalysis_, requires: * 10^9 known plaintexts * 10^34 operations * 10^27 DES decryptions * 10^14 terabytes of memory Assuming a thermodynamically perfect computer running at a nice chilly three point two Kelvins, you're talking about an energy usage that's plenty enough to launch you on a one-way trip out of the Solar System. So please, explain to me: why do you want to be warned when you receive 3DES traffic? > Well then why does OpenPGP allow us to use newer algos? Because OpenPGP has fallen victim to the Second System Effect. Because everyone and their grandmother wants to get their own personal pet algorithm in the mix. Because people who don't know better scream about the injustice of TIGER192 being removed from the mix. Because people who read somewhere on a web forum that SERPENT is better than Rijndael and Rijndael is better than AES insist that GnuPG include Rijndael and SERPENT. Because... ... Rijndael is AES, incidentally. Rijndael was the name it was submitted under to the AES competition. Once it was chosen as the winner, it became AES. And yes, I have seen people passionately advocating for the inclusion of Rijndael in OpenPGP, despite the fact it's already there, just under the name AES. > Why did we change the fingerprint algo to SHA-1? Because Hans Dobbertin kicked MD5 to the curb and went through its pockets looking for interesting bits of number theory. > Ok MD5 is much weaker than SHA1 (as 3DES is probably weaker than AES) 3DES is not weaker than AES. It's different. It's slower. It's less efficient. It's not weaker. Not in any sense that matters, at least. 168 bits of effective 3DES key versus 128 bits of AES key--which wins? Past a certain point additional key length ceases to matter. > fact, that I didn't asked about the pros and cons of algorithms. Why > do we make the whole crypto stuff,... if we stick with old algorithms > (probably weaker than newer ones). Because 3DES is slow, inefficient, and doesn't work well on very small computers. Really. That's the reason. AES is fast, efficient, and works well in a whole lot of different environments. That's why we love AES; it's a great tool across a very broad swath of the problem domain. 3DES is a more limited tool. There are certain parts of the problem set where you just don't want to use it. Email is not one of these certain parts. There is no compelling reason to avoid using 3DES for email, unless you often send very large encrypted files. > ... again: If so,. why do we make all that effort? We could simply > keep using MD5/IDEA because for most cases that would be enough. In fact, a lot of people are still using MD5 and IDEA. The biggest problem facing OpenPGP's adoption is the enormous amount of ClassicPGP installations out there which are not upgrading because they see no need to upgrade. ... Also, to anyone who's thinking "wow, 3DES is really good!" after reading this: yes, yes it is. So is AES. The defaults GnuPG gives you are safe. You don't need to tweak them. From rjh at sixdemonbag.org Tue Apr 15 01:08:05 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 Apr 2008 18:08:05 -0500 Subject: Miscellaneous questions In-Reply-To: <1208208179.8757.8.camel@fermat.scientia.net> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <20080414174129.GE54766@jabberwocky.com> <1208208179.8757.8.camel@fermat.scientia.net> Message-ID: <4803E3D5.8090909@sixdemonbag.org> Herbert Furting wrote: > Ah thanks,.. wouldn't it make sense to merge this with the expert flag? Yes. No. Maybe. HCI (Human-Computer Interaction) is an infamously black art. What one person thinks is the most obvious set of options for them is a Byzantine kludge to another. It might make sense to you. It might not make sense to others. For now, the best that can be done is for the option to exist, for it to be documented, and for it to be easy to control. > So as far as I understand,.. I should actually gain some security, at > least from the point that an attacker could no longer concentrate on > attacking my SHA1 sigs. Vault door, wooden wall, chainsaw. From lhshas at googlemail.com Tue Apr 15 00:42:43 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Tue, 15 Apr 2008 00:42:43 +0200 Subject: How trust works in gpg... In-Reply-To: <200804142320.29571.prlewis@letterboxes.org> References: <200804142205.59132.prlewis@letterboxes.org> <1208209846.9323.1.camel@fermat.scientia.net> <200804142320.29571.prlewis@letterboxes.org> Message-ID: <1208212963.9323.10.camel@fermat.scientia.net> On Mon, 2008-04-14 at 23:20 +0100, Peter Lewis wrote: > Ah yes, thanks. So I have now set the owner-trust for his key to "full", but > still it says "unknown" for the other UIDs. So, I should manually set the > trust for keys / UIDs that I think I trust based on who has signed them? Sorry,.. I haven't read your initial post correctly. As David said in the meantime new UIDs are of course _not_ recognised automatically (a user could simply add a completely wrong name). You have to sign the UID (better said, key+UID). You should only do so, if the name is the same (or if you know that the key holder goes by that name). If the new UID just contains a new email address, you should really check if the keyholder "controlls" that email address. You can do so, by sending him an encrypted challenge. > I was under the impression that the trust would be inferred automatically by > gpg, according to the trust rules > ("completes-needed", "marginals-needed", "max-cert-depth"). > For example, in this case, I have trusted his key fully, and he has signed his > UID, which is one complete link (or two from my own key), right? > If not, what is the purpose of these parameters? First of all,... you don't sign a key,.. you sign the UID for a key. The trust stuff is there to let you recognize other keys as valid,... that your directly signed people signed them self. e.g. If you trust Bill, who signed Joe,.. you might (depending on which trust, and your settings) consider Joe's signatures to,... and even trust him ;) Herbert. From lhshas at googlemail.com Tue Apr 15 02:31:07 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Tue, 15 Apr 2008 02:31:07 +0200 Subject: Miscellaneous questions In-Reply-To: <4803E389.3090500@sixdemonbag.org> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> Message-ID: <1208219467.12772.2.camel@fermat.scientia.net> On Mon, 2008-04-14 at 18:06 -0500, Robert J. Hansen wrote: > 1. You didn't ask for the option to allow zero-length UIDs. If you'd > asked for that option, I would have given it. You asked "why does > GnuPG have a minimum size of five characters", "is this imposed by > RFC4880", and "where can I report this bug". Your questions were > answered. Don't blame me if you asked the wrong questions. Well I don't want to go into such quibbling, but I've seen that gpg complained for UIDs shorter than 5 characters,... I've seen that RFC4880 doesn't require this, and I've asked why. Not more not less. btw: as far as I remember,... zero-length UIDs are allowed by the standard, aren't they? While this doesn't make sense ("nothing" is bound to the key) it wouldn't hurt either. > 2. The beautiful thing about open standards is that anyone can > implement them. The beautiful thing about open source is that > anyone can change it. If you really think it's so stupid to forbid > short UIDs, then hack the source and submit a patch. It's a trivial > change. Of course it is,.. but as I've learned,.. this is not necessary because it already works. And please don't put my words into a light,.. that I tried to say somebody or something might be stupid. I just think, that an implementation should not forbid things, that are allowed by the standard. Of course it makes sense to have things like an expert mode or a beginners mode,.. to prevent people from doing thing that are normally not so useful. > > OpenPGP is said to be open,... and the specification of the UID > > packet only says, that the intended uses is a mail name-addr. It > > doesn't say that it must be one. > You're misunderstanding the purpose of a specification. Did I? So probably I should burn my diploma ;) > A specification does not set a high-water mark for implementations. It > sets a low-water mark. Implementations are free to restrict keys in any > way they want, so long as the low-water mark is met. If you want to > write an RFC2440 implementation that supports only DSA, SHA-1 and 3DES, > nobody will stop you. You're meeting the low-water mark. Of course. But I didn't talk about this at all? Did you read my arguments? I probably didn't explain it correctly (*not a native English speaker*): Preferred * Algorithm => Tells what the user prefers (and not what his implementation support. Neither does it strictly make sense to include these must-have algos in the lists (because it is obvious that a conforming implementation will support them), nor is it (or should it be) the intention of that packet. And that's why I've argued, that one could use it to show up algorithms that - even while supported - are not liked or accepted by a user. If that breaks the best practise idea of the RFC,... it think - in all doing respect - the RFC should be changed in that matter. However... if my previous explanation were clear and you just don't like my ideas, views (for whatever reason) we don't have to discuss it any longer ;) > GnuPG would be entirely within rights to require that all UIDs be set to > "aaaaaaa". > Or to leave them utterly blank. Or to not give users a > choice in them at all. As long as GnuPG understands RFC-conformant > UIDs and generates RFC-conformant UIDs, that's all it has to do > according to the RFC. Of course it would, but why should it do so (apart from the expert/beginners mode idea). gpg is probably THE main implementation of OpenPGP (sorry to the commercial PGP folks ;) ),... as such I think it should support most of the stuff from OpenPGP, or not? How many other major implementations are there? Not too much right? And if none of these use all (or at least most) of the "features",.. why did we included it at all? I don't talk just about the UID size (which is already cleared) but also on stuff like the 0x0F sigs. Is there an implementation the uses third party signatures? Or timestamp sigs? Can I use the critical bit with gpg? etc. etc. Please don't understand me wrong,... I'm _not_ saying "stupid Werner Koch, stupid David Shaw and all the other developers,... go and implement this!" ;-) I know that this is opensource and all have their own lives and business, but I have the felling that the attitude here is,.. most average people don't need it,... it will perhaps break older/other or even historical implementations (which ones ;) ) so don't even talk about it or think about the idea the we could implement it. Got the point? > In reality, GnuPG is guided by concerns beyond just strict RFC > conformance: interoperability, ease of use, and others. Agreed,... well strict conformance should be meet in each case, this (as you've said does however not mean that gpg can not implement just a subset of the standard). Interoperability,.. of course important,... but we should perhaps (at least slowly) move to newer stuff (e.g. the sha512 sigs) or we won't have any advancement at all... Ease of use,.. of course important to,... but that does not mean,.. that one shouldn't be able to use every little bit of the standard (=> expert/beginner modes). > > Imagine a closed software system that uses simply numbers for > > identifying the participants. When it starts at 1, we have UIDs > > smaller than 5 characters. > Imagine the interoperability problems you will have when your UIDs do > not conform to the de-facto standard. If you want to do things that > will deliberately mangle your interoperability, go ahead: You're funny ;) You just said,.. an implementation can do what it want (as long as it's meeting the lower mark) now you said it should not. Of course it would be an interoperability problem,.. but not in a totally closed (in the sense of autonomous) system. ... > --allow-freeform-uid will let you do that. GnuPG will, by default, try > to keep you very interoperable. That's clearly the Right Thing To Do. ... and of course I agree with you,.. that the default (non-expert mode) should at least strongly suggest the user to use name mail-addr UIDs. But it should not completely forbid to make something different. It's GnuPG and not GNOME_PG (sorry folks *g*,... and no I use GNOME and not KDE ^^) > > Hm why? I'd loose a lot of certifications and I don't see any > > security problem with my approach (of course, as David said, SHA-1 is > > still used in some other places). > Interoperability. There are a lot of people out there using old, > decrepit versions of PGP and GnuPG. Old versions tend not to react very > well when people decide to get creative in ways that were not foreseen > back when the old versions were written. Of course,.. that was clear,... but I'm not very happy with such really old stuff. Of course it should receive an specific amount of support and interoperability,... but I think it's more important to move further. And to be honest,... it's not so difficult to update gpg ;) However,.. all of this does not answer my original question,.. whether it works and makes sense (from a security and not interoperability point of view) do revoke the old SHA1 selfsigs and create new (e.g.) SHA512, if it works with _current_ versions of gpg, if it's possible at all, and which revocation reason one should use. > > Uhm,.. is there any reason why gpg doesn't support it? > Yes. Because you haven't written a patch for it. Ah,.. I waited for such a comment... this is the you-dont-develop-so-you-dont-have-any-rights-to-ask-or-discuss answer... So I translate your answer to: "No there is no reason, except that no developer had the time to implement it, yet" btw: are you a gpg developer? > > I mean it exists,.. and there are several things (e.g. the examples > > from my inital post) that would be better of with an 0x1F? > You're ascribing magical meanings to things. You're not going to be > safer under your scheme. It's different--it's not better. Not? When looking at the prefered * algos it definitely makes sense to allow putting them on UIDs, because one might e.g. have different locations (home, work) with different implementations that support different algos. But I think that actually it _is_ better to make a global (key wide) setting first (on a 0x1F) and just modify UIDs that really need other settings. This is common sense in the world of computing, like you have /etc/vim/vimrc with global settings first,.. and only create a ~/.vimrc if you relly need to do so. But for the preferred * algo subpackets I agree that it is not really necessary (although I think it would be cleaner). But I consider other subpackets e.g. key usage to be really key and nod UID related. So why putting them on 0x13 selfsigs if we have the possibility to use the indented signature on key. (Yes I know that the RFC allows it on all self-sigs, but I think that could be improved). > And this is the problem: you _are_ including it. The RFC requires them > to be present, and if they're not present, requires all implementations > to add them. Could you please show me the place where it says, that those algorithm IDs must be part of the prefered algorithm subpacktes? > You're not communicating anything other than "I am not paying attention > to the best practice outlined in the RFC." Your correspondents are not > going to say "oh, you don't like 3DES". But they should... otherwise this it would contradict the idea of the user preferences of algorithms. You understand the difference between what a user prefers and what the implementation has to support? > They're going to say "oh, > you're using a badly-written OpenPGP implementation, here, let me fix > that for you." This is only possible internally at all,.. (except when the preference subpacktes would be in the unhashed subpacket data set). > > Hm yes,.. but in all doing respect,... this practise is probably not > > the best as it does not tell the users preference but a mix of the > > users preference and the minimal algorithm subset. > Then join the WG and advocate for this position. It's an open WG. A friend of mine (Christoph Mitterer) is going to do so these days,... he's currently preparing a deep review and lots of questions to RFC4880,... But in the meantime I fear,.. that he will run against closed doors and highly conservative (not to say narrow-minded) attitudes :-( > Speak for yourself. My personal-cipher-preferences has 3DES explicitly > listed as my first preference. Fine. If mine has listed AES256 (and yours too) first and lacks 3DES gpg should choose AES256,... if yours doesn't list it,.. it should choose 3DES (or of course another working match). But imagine the following: Yours: 3DES, AES256 Mine: AES256, 3DES Which one is chosen now? But when I only include AES256 I can at least somewhat control it. > I see no reason not to use 3DES and I know 3DES will be supported by > everyone, so why not use 3DES and avoid the risk of a problem existing? > > > Yes it will work (even if I said,... I don't like 3DES). But an > > implementation could provide options to warn a user, if he receives > > such messages. > Why? Because A user might think 3DES is unsafe for his needs. > You're assuming 3DES is a weak cipher. It's not. It's really quite > grotesquely overdesigned. The best attack against it, _in thirty-four > years of intense cryptanalysis_, requires: I cannot discuss with you about algorithm details (have only little knowledge about this)... but I know that e.g. NIST decided to replace DES by AES and the only thing I can do is follow such hints,... to decide which algorithm is currently "the best". > Assuming a thermodynamically perfect computer running at a nice chilly > three point two Kelvins, you're talking about an energy usage that's > plenty enough to launch you on a one-way trip out of the Solar System. Hmm I should ask Christoph whether he can put a computer to one of the cryostats at CERN... :P > > Well then why does OpenPGP allow us to use newer algos? > Because OpenPGP has fallen victim to the Second System Effect. Because > everyone and their grandmother wants to get their own personal pet > algorithm in the mix. Because people who don't know better scream about > the injustice of TIGER192 being removed from the mix. Because people > who read somewhere on a web forum that SERPENT is better than Rijndael > and Rijndael is better than AES Rijndael is AES (well not exactly but more or less ;) ) > insist that GnuPG include Rijndael and > SERPENT. Because... afaik,.. serpent was considered to be more secure,... however... deep cryptoanaltics are probably missing. > ... Rijndael is AES, incidentally. Rijndael was the name it was > submitted under to the AES competition. Once it was chosen as the > winner, it became AES. That's not completely true... > And yes, I have seen people passionately > advocating for the inclusion of Rijndael in OpenPGP, despite the fact > it's already there, just under the name AES. http://en.wikipedia.org/wiki/Rijndael#Description_of_the_cipher > 3DES is not weaker than AES. It's different. It's slower. It's less > efficient. > > It's not weaker. Not in any sense that matters, at least. *g* who decides which sense matters? > 168 bits of > effective 3DES key versus 128 bits of AES key--which wins? Past a > certain point additional key length ceases to matter. Of course,.. but the quality of an alogorihtm doesn't depend on its key length (see RSA vs. ECC). > > ... again: If so,. why do we make all that effort? We could simply > > keep using MD5/IDEA because for most cases that would be enough. > > In fact, a lot of people are still using MD5 and IDEA. The biggest > problem facing OpenPGP's adoption is the enormous amount of ClassicPGP > installations out there which are not upgrading because they see no need > to upgrade. Ok.... but if MD5 hashes are easily forgable,... it's perhaps not so clever to keep using those keys... > ... Also, to anyone who's thinking "wow, 3DES is really good!" after > reading this: yes, yes it is. So is AES. The defaults GnuPG gives you > are safe. You don't need to tweak them. You probably should "correct" the wiki on http://en.wikipedia.org/wiki/3DES#Usage which claims "Finally, AES offers markedly higher security margins: a larger block size and potentially longer keys." Herbert. From lhshas at googlemail.com Tue Apr 15 02:33:59 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Tue, 15 Apr 2008 02:33:59 +0200 Subject: Miscellaneous questions In-Reply-To: <4803E3D5.8090909@sixdemonbag.org> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <20080414174129.GE54766@jabberwocky.com> <1208208179.8757.8.camel@fermat.scientia.net> <4803E3D5.8090909@sixdemonbag.org> Message-ID: <1208219639.12772.5.camel@fermat.scientia.net> On Mon, 2008-04-14 at 18:08 -0500, Robert J. Hansen wrote: > Herbert Furting wrote: > > Ah thanks,.. wouldn't it make sense to merge this with the expert flag? > > Yes. No. Maybe. That's a word. > > So as far as I understand,.. I should actually gain some security, at > > least from the point that an attacker could no longer concentrate on > > attacking my SHA1 sigs. > Vault door, wooden wall, chainsaw. Ok... while this doesn't answer my question,.. thanks for the advise. I'll stop encrypting my data and just add a flag encrypted=true| false,... but move my storage to a bunker... Yeah... now I'm absolute secure,.. NSA can come for me XD H.F. From rjh at sixdemonbag.org Tue Apr 15 03:43:14 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 14 Apr 2008 20:43:14 -0500 Subject: Miscellaneous questions In-Reply-To: <1208219467.12772.2.camel@fermat.scientia.net> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> Message-ID: <48040832.1000909@sixdemonbag.org> Herbert Furting wrote: > While this doesn't make sense ("nothing" is bound to the key) it > wouldn't hurt either. It violates a de-facto standard. That hurts. > I just think, that an implementation should not forbid things, that > are allowed by the standard. The standard allows for terabit RSA keys. Should GnuPG allow them? All real-world implementations of real-world standards have to make decisions about what will be supported and how it will be supported. This is what engineering is all about. > If that breaks the best practise idea of the RFC,... it think - in > all doing respect - the RFC should be changed in that matter. Take it up with the working group and get the RFC changed. > gpg is probably THE main implementation of OpenPGP (sorry to the > commercial PGP folks ;) ),... as such I think it should support most > of the stuff from OpenPGP, or not? Depends on who you ask. A few people on-list (myself being one of them) think GnuPG supports too much of OpenPGP. > How many other major implementations are there? Not too much right? I can think of ten without needing to hit Google. > I know that this is opensource and all have their own lives and > business, but I have the felling that the attitude here is,.. most > average people don't need it,... it will perhaps break older/other or > even historical implementations (which ones ;) ) so don't even talk > about it or think about the idea the we could implement it. > > Got the point? Yes, but you're still wrong. If the GnuPG developers had that attitude, GnuPG would have only supported DSA, Elgamal, SHA-1 and 3DES. The fact that GnuPG supports essentially all of RFC 2440/4880, despite the fact the average person really doesn't need most of it, is strong evidence against your argument. > Interoperability,.. of course important,... but we should perhaps (at > least slowly) move to newer stuff (e.g. the sha512 sigs) or we won't > have any advancement at all... This is a WG issue. Take it up with them. > Ease of use,.. of course important to,... but that does not mean,.. > that one shouldn't be able to use every little bit of the standard Sure it does. What do you think SHOULDs and MAYs mean? Only the MUSTs in the standard must be present. Everything else is optional. > You're funny ;) You just said,.. an implementation can do what it > want (as long as it's meeting the lower mark) now you said it should > not. Yes. Where's the problem? You can play Russian roulette. You probably shouldn't. > And to be honest,... it's not so difficult to update gpg ;) A lot of groups can't do this. For instance, a bank's insurance company may require that any software used go through an expensive certification process. If it costs $50,000 to get the software certified, you're not going to want to upgrade for anything short of the direst emergency. GnuPG is used in a lot of places besides just people's desktops. In a lot of these places, upgrading is an uphill battle. > Ah,.. I waited for such a comment... this is the > you-dont-develop-so-you-dont-have-any-rights-to-ask-or-discuss > answer... Not at all. Discuss it all you like. But if you can't convince the developers of the correctness of your opinion, why should they spend time writing code to implement this opinion? There is something sociopathic about saying "I cannot convince you to do this, but you should do it anyway, and if you elect to tell me to do it myself I'm going to say you're denying me my rights." > btw: are you a gpg developer? GnuPG development is done primarily by g10 Code GmbH. I work for the National Science Foundation as a researcher in electronic voting security. There's no overlap between my work and GnuPG. >> And this is the problem: you _are_ including it. The RFC requires >> them to be present, and if they're not present, requires all >> implementations to add them. > > Could you please show me the place where it says, that those > algorithm IDs must be part of the prefered algorithm subpacktes? Section 13.2 of RFC4880. "Since TripleDES is the MUST-implement algorithm, if it is not explicitly in the list, it is tacitly at the end." > But they should... If this is what you want the RFC to say, take it up with the WG. > But in the meantime I fear,.. that he will run against closed doors > and highly conservative (not to say narrow-minded) attitudes :-( Just because someone disagrees with you vigorously does not make them "highly conservative" or "narrow-minded". It very often means they've been burned more than you have, and want to spare other people the anguish which will result if you are allowed to play with matches. > Yours: 3DES, AES256 Mine: AES256, 3DES Which one is chosen now? But > when I only include AES256 I can at least somewhat control it. No. You can't. 3DES is appended to the end. If you want this behavior to change, talk to the WG. > Because A user might think 3DES is unsafe for his needs. Then they need to use something other than OpenPGP. OpenPGP is not meant to be all things to all people. > I cannot discuss with you about algorithm details (have only little > knowledge about this)... but I know that e.g. NIST decided to replace > DES by AES and the only thing I can do is follow such hints,... to > decide which algorithm is currently "the best". NIST replaced DES because it was a 56-bit cipher. 3DES is a different beast. > That's not completely true... Close enough for jazz. > *g* who decides which sense matters? Please don't try and engage me in a silly freshman-level philosophy argument. From prlewis at letterboxes.org Tue Apr 15 11:52:51 2008 From: prlewis at letterboxes.org (Peter Lewis) Date: Tue, 15 Apr 2008 10:52:51 +0100 Subject: How trust works in gpg... In-Reply-To: <1208212963.9323.10.camel@fermat.scientia.net> References: <200804142205.59132.prlewis@letterboxes.org> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> Message-ID: <200804151052.51733.prlewis@letterboxes.org> On Monday 14 April 2008 at 23:42:43 Herbert Furting wrote: > If the new UID just contains a new email address, you should really > check if the keyholder "controlls" that email address. > You can do so, by sending him an encrypted challenge. Ah, thanks, that makes sense. And then I can sign his new UIDs too? Or just change their trust level? > > I was under the impression that the trust would be inferred automatically > > by gpg, according to the trust rules > > ("completes-needed", "marginals-needed", "max-cert-depth"). > > For example, in this case, I have trusted his key fully, and he has > > signed his UID, which is one complete link (or two from my own key), > > right? If not, what is the purpose of these parameters? > > First of all,... you don't sign a key,.. you sign the UID for a key. > > The trust stuff is there to let you recognize other keys as valid,... > that your directly signed people signed them self. > e.g. If you trust Bill, who signed Joe,.. you might (depending on which > trust, and your settings) consider Joe's signatures to,... and even > trust him ;) Thanks, this is helpful. So, if I have to set the trust of other keys myself in order to recognise them as valid, what is the function of the "completes-needed", "marginals-needed" and "max-cert-depth" options in my gpg.conf file? Thanks again! Pete. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part. URL: From sattva at pgpru.com Tue Apr 15 12:08:41 2008 From: sattva at pgpru.com (Vlad "SATtva" Miller) Date: Tue, 15 Apr 2008 17:08:41 +0700 Subject: Miscellaneous questions In-Reply-To: <4803E389.3090500@sixdemonbag.org> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> Message-ID: <48047EA9.5010609@pgpru.com> Robert J. Hansen (15.04.2008 06:06): > ... Rijndael is AES, incidentally. Rijndael was the name it was > submitted under to the AES competition. Once it was chosen as the > winner, it became AES. And yes, I have seen people passionately > advocating for the inclusion of Rijndael in OpenPGP, despite the fact > it's already there, just under the name AES. Not strictly so. IIRC, Rijndael has support for block size up to the 256 bits. AES (as a standard) has more tight restrictions -- 128 bits. -- SATtva | security & privacy consulting www.vladmiller.info | www.pgpru.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 513 bytes Desc: OpenPGP digital signature URL: From lhshas at googlemail.com Tue Apr 15 13:24:20 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Tue, 15 Apr 2008 13:24:20 +0200 Subject: Miscellaneous questions In-Reply-To: <48040832.1000909@sixdemonbag.org> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <48040832.1000909@sixdemonbag.org> Message-ID: <1b369b200804150424y7a083f3ax8ac91c4d24e1024@mail.gmail.com> On Tue, Apr 15, 2008 at 3:43 AM, Robert J. Hansen wrote: > > While this doesn't make sense ("nothing" is bound to the key) it > > wouldn't hurt either. > It violates a de-facto standard. That hurts. Don't see why,.. but... however. > > I just think, that an implementation should not forbid things, that > > are allowed by the standard. > The standard allows for terabit RSA keys. Should GnuPG allow them? Yes why not,... but only in an expert mode. > All real-world implementations of real-world standards have to make > decisions about what will be supported and how it will be supported. > This is what engineering is all about. Ah you think cryptography is engineering? Always thought it would be math. However I never said that gnupg should suggest those unusual stuff, but it does not make sense to forbid them. A user who whishes to make a terbit key can simply modify the source. I had hoped that gnupg neither shares the philosophy from Windows nor that of GNOME,... keep as much away from the user as possible, in other words, think he must be stupid. > > gpg is probably THE main implementation of OpenPGP (sorry to the > > commercial PGP folks ;) ),... as such I think it should support most > > of the stuff from OpenPGP, or not? > Depends on who you ask. A few people on-list (myself being one of them) > think GnuPG supports too much of OpenPGP. In all doing respect,.. I hope there are really few. Otherwise we really should consider "thorwing away" our current standard an release only a small subset of it as new standard. However,.. I didn't intend this as (nearly) a flame war. > How many other major implementations are there? Not too much right? > I can think of ten without needing to hit Google. So much? Wow... really, thought there would be at best 5 or so. > > I know that this is opensource and all have their own lives and > > business, but I have the felling that the attitude here is,.. most > > average people don't need it,... it will perhaps break older/other or > > even historical implementations (which ones ;) ) so don't even talk > > about it or think about the idea the we could implement it. > > Got the point? > Yes, but you're still wrong. Ok,.. but actually I'm no longer interested why you think so. > If the GnuPG developers had that attitude, GnuPG would have only > supported DSA, Elgamal, SHA-1 and 3DES. The fact that GnuPG supports > essentially all of RFC 2440/4880, despite the fact the average person > really doesn't need most of it, is strong evidence against your argument. Yes,... but despite of the the only thing I hear from you is,.. don't need this, don't need that, etc. etc. lol > > Ease of use,.. of course important to,... but that does not mean,.. > > that one shouldn't be able to use every little bit of the standard > Sure it does. What do you think SHOULDs and MAYs mean? Only the MUSTs > in the standard must be present. Everything else is optional. I know about RFC2119, too. Anyway,.. gpg isn't probably targeted as implementation for embedded systems only. So of course an implementation doesn't have to implement all that features,... but despite of that, I have the opinion that gnupg should. Yeah I know,.. I haven't submittet patches... Apart from that I had some discussions with Christoph and we both think, that the RFC should be much stricter, especially in what is required. I know that OpenPGP says, that it's "wishy-washy" style is a feature but there are several places where I think that could be a security problem. e.g. afaik the RFC does not require to implement the reason for revocation subpacket. If it get's a key with a revocation signature on it, it may simply behave, as if the key was superseeded (the rfc doesn't require that an implementation has to consider all signatures by a key invalid, if it doesn't understand its reason for revoc subpacket), but the keyholder might actually used the key was compromised reason. However,.. more on such ideas when Christoph has finished his text (which he'll probably post to WG list). > > And to be honest,... it's not so difficult to update gpg ;) > A lot of groups can't do this. For instance, a bank's insurance company > may require that any software used go through an expensive certification > process. If it costs $50,000 to get the software certified, you're not > going to want to upgrade for anything short of the direst emergency. Apart from the fact that most of such organisations probably use X509 (unfortunately),... what would they do if an security update to gpg is published? Anyway if we always say that someone might have problems with new features,.. we can never add them. And for your specific example, no one forces the insurance company or the bank to use the newer versions/features. But as with every software, it makes only to some degree sense to stick with historic reason. The applys to gpg as to the linux kernel... > > Ah,.. I waited for such a comment... this is the > > you-dont-develop-so-you-dont-have-any-rights-to-ask-or-discuss > > answer... > Not at all. Discuss it all you like. But if you can't convince the > developers of the correctness of your opinion, why should they spend > time writing code to implement this opinion? Of course,.. but I still can make feature requests. So perhaps let's ask David. He's both member of the WG (and even a named author since 4880 :-) ) and gnupg developer. Why did he agreed to the features in 4880 (as author) if (as developer) he thinks nobody needs them? > > Could you please show me the place where it says, that those > > algorithm IDs must be part of the prefered algorithm subpacktes? > Section 13.2 of RFC4880. "Since TripleDES is the MUST-implement > algorithm, if it is not explicitly in the list, it is tacitly at the end." So I'm right, or not? It doesn't have to be explicitly in the list. And we already agreed that the proper place to suggest my (of course only in my opinion) cleaner meaning of the (user) prefered algorithm subpacktes, is the WG list, so we really don't need to discuss that the standard implies a mixing of user preference and implementation capabilities at this place. > > *g* who decides which sense matters? > Please don't try and engage me in a silly freshman-level philosophy > argument. Ah interesting,.. I actually thought you were trying to do so... my 0,02? From lhshas at googlemail.com Tue Apr 15 13:39:43 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Tue, 15 Apr 2008 13:39:43 +0200 Subject: How trust works in gpg... In-Reply-To: <200804151052.51733.prlewis@letterboxes.org> References: <200804142205.59132.prlewis@letterboxes.org> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <200804151052.51733.prlewis@letterboxes.org> Message-ID: <1b369b200804150439j75b4a577ncccb78f346620f80@mail.gmail.com> 2008/4/15 Peter Lewis : > Ah, thanks, that makes sense. And then I can sign his new UIDs too? Or just > change their trust level? You'll "have" to sign his new UIDs, too. What you could to is do issue a so called non-exportable (gpg uses the term local, iirc) signature. That means this signature is (better said should be) only recognized by the signer (you) but not by other people. > Thanks, this is helpful. So, if I have to set the trust of other keys myself > in order to recognise them as valid, what is the function of Yes,.. but not always,.. for example gpg sets your own key automatically to an unlimited trust ;-) > the "completes-needed", "marginals-needed" and "max-cert-depth" options in my > gpg.conf file? gpg uses a so called trust modell (there ary actually several different), where you can each UID/key an specific amount of trust. You can give: n Never trust this key. m Marginally trusted. f Fully trusted. u Ultimately trusted. and you'll also see: - No ownertrust assigned / not yet calculated. e Trust calculation has failed; probably due to an expired key. q Not enough information for calculation. (I've stole that from the manpage,.. so credit should go to Werner or some of the other developers ;) ) Depending on how much you trust a user you normally give him n (e.g. your little brother who signs every key/uid without validating it, m or f and rarely perhaps even u (your wife, which you fully trust *g*.... or not). u means that you automatically recognize the key/UIDs that keyholder made as valid completes-needed specify how many trust-paths you need to a key from keys you trust fully. marginals-needed is the same for marginally trusted keys. suppose you are A and have signed following key/UIDs with following trust values: B(f) C(f) D(m) E(m) Now your gpg gets the key F, which you haven't signed yourself, but the others have, thus you'll have the following trust-paths: A->B(f)-F A->C(f)-F A->D(m)-F A->E(m)-F Suppose marginals-needed=3 and completes-needed=2: The two paths A->D(m)-F A->E(m)-F are not enough the recognize F as valid, because you'd need tree ?(m) paths, but the two other pathes are enough. (@the others,.. was that correct?) Herbert. From mkallas at schokokeks.org Tue Apr 15 12:21:43 2008 From: mkallas at schokokeks.org (Michael Kesper) Date: Tue, 15 Apr 2008 12:21:43 +0200 Subject: How trust works in gpg... In-Reply-To: <1208212963.9323.10.camel@fermat.scientia.net> References: <200804142205.59132.prlewis@letterboxes.org> <1208209846.9323.1.camel@fermat.scientia.net> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> Message-ID: <20080415102143.GC2774@kol06wsthv-it22.kaufhof.net> Hi, On Tue, Apr 15, 2008 at 12:42:43AM +0200, Herbert Furting wrote: > On Mon, 2008-04-14 at 23:20 +0100, Peter Lewis wrote: > > Ah yes, thanks. So I have now set the owner-trust for his key to "full", but > > still it says "unknown" for the other UIDs. So, I should manually set the > > trust for keys / UIDs that I think I trust based on who has signed them? > Sorry,.. I haven't read your initial post correctly. > As David said in the meantime new UIDs are of course _not_ recognised > automatically (a user could simply add a completely wrong name). You > have to sign the UID (better said, key+UID). > You should only do so, if the name is the same (or if you know that the > key holder goes by that name). > > If the new UID just contains a new email address, you should really > check if the keyholder "controlls" that email address. > You can do so, by sending him an encrypted challenge. I remember Werner saying that this was just nonsense. Werner, can you correct me if I'm wrong? Best wishes Michael -- Free Software Foundation Europe (FSFE) [] (http://fsfeurope.org) Join the Fellowship of FSFE! [][][] (http://fsfe.org/join) Your donation powers our work! [] (http://fsfeurope.org/donate) From email at sven-radde.de Tue Apr 15 14:18:39 2008 From: email at sven-radde.de (Sven Radde) Date: Tue, 15 Apr 2008 14:18:39 +0200 Subject: Miscellaneous questions In-Reply-To: <1208219467.12772.2.camel@fermat.scientia.net> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> Message-ID: <48049D1F.2000509@sven-radde.de> Herbert Furting schrieb: > But imagine the following: > Yours: 3DES, AES256 > Mine: AES256, 3DES > Which one is chosen now? But when I only include AES256 I can at least > somewhat control it. > If *you* send, it is AES; if RJH sent, it would be 3DES. It doesn't matter if your key indicates a preference for 3DES, as RJH's implementation will assume that you have the availability to handle 3DES, it will happily chose that. Maybe, the "preference" setting on keys should be renamed to "capability". In practice, the ordering of algorithms in your key's "preference" string does not have soo much influence about what others will use when sending messages to you. The mechanism practically only guarantees that you can handle whatever is sent to you. > Because A user might think 3DES is unsafe for his needs. That user should get professional advice in implementing a security solution for his/her extraordinary needs. Plain GnuPG/OpenPGP is not necessarily the best choice for such an advanced scenario. Mind you that "PGP" means "pretty good privacy" and not "perfect global protection". For most people, however, the "pretty good" offered by OpenPGP equals to "way more than they'll ever need". If you want to keep compatibility to OpenPGP, you should simply accept that you cannot completely control what algorithm is used for *incoming* messages. You can completely avoid sending 3DES encrypted messages, if you prefer. If any particular user group finds that 3DES is unsafe for their needs, they can arrange for it that it is never used in communications between them. (Same goes for SHA-1 or uncompressed or ...) You might consider to use a modified gpg that warns you when it would choose 3DES for a message and give you the option of encrypting anyway or not sending the message. You might even want to modify GnuPG in a way that is incorporates a custom algorithm, such as Quintuple-AES or an AES-Serpent-Twofish-RC6-MARS cascade and distribute that within the user group which you target. These changes of behaviour IMHO could even be done within the limits of the RFC. Alternatively, GnuPG could be modified in way that ignores the interoperability issues, which is probably fine if that version is only distributed within a closed group where you can control these issues for yourself. cu, Sven From prlewis at letterboxes.org Tue Apr 15 14:23:01 2008 From: prlewis at letterboxes.org (Peter Lewis) Date: Tue, 15 Apr 2008 13:23:01 +0100 Subject: How trust works in gpg... In-Reply-To: <1b369b200804150439j75b4a577ncccb78f346620f80@mail.gmail.com> References: <200804142205.59132.prlewis@letterboxes.org> <200804151052.51733.prlewis@letterboxes.org> <1b369b200804150439j75b4a577ncccb78f346620f80@mail.gmail.com> Message-ID: <200804151323.01771.prlewis@letterboxes.org> On Tuesday 15 April 2008 at 12:39:43 Herbert Furting wrote: > gpg uses a so called trust modell (there ary actually several > different), where you can each UID/key an specific amount of trust. > You can give: > n Never trust this key. > m Marginally trusted. > f Fully trusted. > u Ultimately trusted. > and you'll also see: > - No ownertrust assigned / not yet calculated. > e Trust calculation has failed; probably due to > an expired key. > q Not enough information for calculation. > > (I've stole that from the manpage,.. so credit should go to Werner or > some of the other developers ;) ) > > > Depending on how much you trust a user you normally give him n (e.g. > your little brother who signs every key/uid without validating it, m > or f and rarely perhaps even u (your wife, which you fully trust > *g*.... or not). > u means that you automatically recognize the key/UIDs that keyholder > made as valid > completes-needed specify how many trust-paths you need to a key from > keys you trust fully. > marginals-needed is the same for marginally trusted keys. > > suppose you are A and have signed following key/UIDs with following > trust values: > B(f) > C(f) > D(m) > E(m) > Now your gpg gets the key F, which you haven't signed yourself, but > the others have, thus you'll have the following trust-paths: > A->B(f)-F > A->C(f)-F > A->D(m)-F > A->E(m)-F > > Suppose marginals-needed=3 and completes-needed=2: > The two paths > A->D(m)-F > A->E(m)-F > are not enough the recognize F as valid, because you'd need tree ?(m) > paths, but the two other pathes are enough. Thanks, that makes sense. So I guess my question is: is this a guide for me, and then I should manually set the trust level on key F myself (if I am satisfied that the chains exist), or should gpg do this automatically for me based on the parameters in my gpg.conf? It doesn't seem to be calculating anything automatically at the moment. Thanks, Pete. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part. URL: From email at sven-radde.de Tue Apr 15 14:31:30 2008 From: email at sven-radde.de (Sven Radde) Date: Tue, 15 Apr 2008 14:31:30 +0200 Subject: Miscellaneous questions In-Reply-To: <1b369b200804150424y7a083f3ax8ac91c4d24e1024@mail.gmail.com> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <48040832.1000909@sixdemonbag.org> <1b369b200804150424y7a083f3ax8ac91c4d24e1024@mail.gmail.com> Message-ID: <4804A022.3060805@sven-radde.de> Herbert Furting schrieb: > Ah you think cryptography is engineering? Always thought it would be math. > Implementing crypto is purest engineering. Not even algorithm design is pure math if you think of timing or power consumption attacks that might have to be considered. > Anyway if we always say that someone might have problems with new > features,.. we can never add them. > See, that's were all that interoperability stuff comes in. ;-) By default, GnuPG uses all the new algorithms. Only if necessary, it resorts to the older ones. User groups can make sure that "unsafe" algorithms are avoided between them. I, personally, find this kind of an elegant solution to a complicated problem, actually... :-) cu, Sven From sttob at mailshack.com Tue Apr 15 14:13:51 2008 From: sttob at mailshack.com (Stan Tobias) Date: Tue, 15 Apr 2008 14:13:51 +0200 Subject: How trust works in gpg... In-Reply-To: <200804151052.51733.prlewis@letterboxes.org> References: <200804142205.59132.prlewis@letterboxes.org> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <200804151052.51733.prlewis@letterboxes.org> Message-ID: <48049BFF.nail56411UIHS@mailshack.com> Herbert Furting wrote: > If the new UID just contains a new email address, you should really > check if the keyholder "controlls" that email address. > You can do so, by sending him an encrypted challenge. [another newbie here] I don't understand this. If a public key has a UID1, which I already trust, and a new UID2 is added, why can't I infer trust for the new uid? My reasoning goes: UID1 is signed by its owner's private key, and I chose to trust it (directly, or through others' sigs). When new UID2 is added, it must be also signed by the same private key, which is connected to UID1, which I trust belongs to the person it says it belongs to. So the only person that could have added UID2 is the one that is in control of UID1 (supposedly, it's the same person). Why is there a need to check anything? Stan Tobias [ Apologies to Peter Lewis for sending this post to the wrong address, and thank-yous for notifying me. ] From rjh at sixdemonbag.org Tue Apr 15 15:03:10 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 15 Apr 2008 08:03:10 -0500 Subject: Miscellaneous questions In-Reply-To: <1b369b200804150424y7a083f3ax8ac91c4d24e1024@mail.gmail.com> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <48040832.1000909@sixdemonbag.org> <1b369b200804150424y7a083f3ax8ac91c4d24e1024@mail.gmail.com> Message-ID: <4804A78E.9050806@sixdemonbag.org> Herbert Furting wrote: >> The standard allows for terabit RSA keys. Should GnuPG allow them? > > Yes why not,... but only in an expert mode. You may want to consider re-reading your answer a few times and asking yourself, "why do I feel this way, and why do other people feel the way they do?" It may be informative. > Ah you think cryptography is engineering? Always thought it would be > math. There's a reason why University computer science departments are distinct from the math department. At a very high level, computer science is just an applied mathematical discipline. The reality is that very little programming work is actually computer science; it's software engineering. Developing the math behind an algorithm is a mathematical task. Implementing the algorithm is definitely a software engineering task. Coming up with a protocol in which these algorithms are used is even more clearly a software engineering task. > Yes,... but despite of the the only thing I hear from you is,.. don't > need this, don't need that, etc. etc. Yep. Welcome to software engineering. One of the best techniques available to us for controlling complexity in software--and definitely the simplest--is to take a chainsaw to the feature list. Go through the specification and copy down every single MUST. Stop right there. Implement the MUSTs, make them rock solid reliable. Only then allow yourself to start worrying about SHOULDs and MAYs. This is how GnuPG was developed, by and large. In the very early days, GnuPG supported only the bare minimum necessary to conform to the RFC. Features like Twofish support were not added until the MUSTs were well in hand. > Apart from that I had some discussions with Christoph and we both > think, that the RFC should be much stricter, especially in what is > required. Bring it up with the working group. I am not being sarcastic or facetious when I say that. I'm absolutely sincere. If you feel this strongly about it, then bring it up with the working group. However, complaining about the RFC here isn't going to accomplish anything. > Apart from the fact that most of such organisations probably use X509 > (unfortunately),... what would they do if an security update to gpg > is published? I know of at least one major telco which was, for a while, using OpenPGP to secure billing information on a national level. That was some years ago, though, and they may have changed their system since. (Due to NDA, I'm unable to disclose the telco name.) In the event of a security update to GnuPG, they look for ways to limit the problem without changing source. If they have to change source, they backport the fix and go through an abbreviated approval process which still costs them a good bit of money. > And for your specific example, no one forces the insurance company or > the bank to use the newer versions/features. Except for people like you, who say "it's not hard to upgrade GnuPG, so there's no reason to be concerned about interoperability with old versions". > So perhaps let's ask David. He's both member of the WG (and even a > named author since 4880 :-) ) and gnupg developer. Why did he agreed > to the features in 4880 (as author) if (as developer) he thinks > nobody needs them? I'm not going to presume to try to answer for David. I will suggest that you change the question. In English, the kind of question you've just asked is called "leading", if not outright "loaded". (A loaded question is an extreme form of a leading question.) Try asking instead: "it appears that OpenPGP is a very large specification, and few people need all of it. Is this true? If it's true, why does GnuPG support so much of it?" Same question, but not leading and not loaded. If David chooses to answer, I'm pretty sure his answer will be insightful and one which both of us will disagree with. But hey--he's writing the code, so he gets to do that. :) >> Section 13.2 of RFC4880. "Since TripleDES is the MUST-implement >> algorithm, if it is not explicitly in the list, it is tacitly at >> the end." > > So I'm right, or not? It doesn't have to be explicitly in the list. If it is not in the list, it is tacitly at the end. Tacit: "implied by necessity." A tacit agreement is one which no one has explicitly stated, but which is true nevertheless. Like many adjectives, it may be discarded from a sentence without changing the meaning of the sentence. "Since TripleDES is the MUST-implement algorithm, if it is not explicitly in the list, it is in the list." Regardless of whether 3DES is explicitly listed or not, it's going to be in your preference list. From lhshas at googlemail.com Tue Apr 15 15:10:47 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Tue, 15 Apr 2008 15:10:47 +0200 Subject: How trust works in gpg... In-Reply-To: <48049BFF.nail56411UIHS@mailshack.com> References: <200804142205.59132.prlewis@letterboxes.org> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <200804151052.51733.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> Message-ID: <1b369b200804150610r224ef516q136a4e54a9e5d987@mail.gmail.com> First of all,... unfortunately Chris forgot to CC the list (at least it seems so). So I post his answer again: On Tue, Apr 15, 2008 at 12:21 PM, Michael Kesper wrote: > I remember Werner saying that this was just nonsense. > Werner, can you correct me if I'm wrong? Well this is partly true as everybody can loose or change an email address. So the process of validating that a key-owner has "controll" over an email address does not say that this will last forever (btw: this also applies for the real name,.. imagine someone marries). But apart from that I think it still makes sense to really validate the email (e.g. via challenge response). Imagine Werner Koch (from GnuPG) who has wk at gnupg.org... and another Werner Koch who works at uhm perhaps Mikrosaft,...he has the email werner at mikrosaft.com. Both are really named "Werner Koch" and people validate this e.g. via their passports when they meet one of the two Werners in person and sign their key/UIDs. After some time the Werner Koch from Mikrosaft becomes evil and adds a new UID "Werner Koch "... and he asks his previous key signers to sign his new ID because he no longer goes by his "old" eMail address. If the signers say just,.. oh well the name is the same and I don't have to check if the evil Werner Koch actually has access to the eMail,... a lot of people might believe that he is our good gpg-programming Werner. To say it short: In my opinion every information that you sign/certify should be actually validaded. It probably makes even sense to check if a keyholder specified all of his given names,... and perhaps one shouldn't sign UIDs like "Geroge W. Bush" if the W. is an abbreviation, while "Harry S Truman" would be ok,.. as the S wasn't an abbreviation (iirc). Does this answer your post? Herbert From email at sven-radde.de Tue Apr 15 15:11:48 2008 From: email at sven-radde.de (Sven Radde) Date: Tue, 15 Apr 2008 15:11:48 +0200 Subject: How trust works in gpg... In-Reply-To: <48049BFF.nail56411UIHS@mailshack.com> References: <200804142205.59132.prlewis@letterboxes.org> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <200804151052.51733.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> Message-ID: <4804A994.6020508@sven-radde.de> Stan Tobias schrieb: > If a public key has a UID1, which I already > trust, and a new UID2 is added, why can't I infer trust for the new uid? > (...) > So the > only person that could have added UID2 is the one that is in control of > UID1 (supposedly, it's the same person). Why is there a need to check > anything? > Because you do not know whether the owner of UID1 is also the owner of UID2. Let's say, someone trusts my key and my user-id on that key. Now, I add another ID: "Stan Tobias "... No good idea to trust that without checking, is it? cu, Sven From lhshas at googlemail.com Tue Apr 15 15:21:26 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Tue, 15 Apr 2008 15:21:26 +0200 Subject: Miscellaneous questions In-Reply-To: <4804A78E.9050806@sixdemonbag.org> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <48040832.1000909@sixdemonbag.org> <1b369b200804150424y7a083f3ax8ac91c4d24e1024@mail.gmail.com> <4804A78E.9050806@sixdemonbag.org> Message-ID: <1b369b200804150621i1d30774cj3338c60f1e732dfe@mail.gmail.com> On Tue, Apr 15, 2008 at 3:03 PM, Robert J. Hansen wrote: > One of the best techniques available to us for controlling complexity in > software--and definitely the simplest--is to take a chainsaw to the > feature list. Go through the specification and copy down every single > MUST. Stop right there. Implement the MUSTs, make them rock solid > reliable. Only then allow yourself to start worrying about SHOULDs and > MAYs. I thought gpg already implements the MUSTs very well (ok sometimes there are security problems but this will probably never go away with any software). > > Apart from that I had some discussions with Christoph and we both think, > that the RFC should be much stricter, especially in what is required. > Bring it up with the working group. He's still writing ;-) > I know of at least one major telco which was, for a while, using OpenPGP > to secure billing information on a national level. That was some years > ago, though, and they may have changed their system since. (Due to NDA, > I'm unable to disclose the telco name.) Unfortunately I see a general trend to use the simpler but weaker hierarchical model of X509.... :-( Like the German national authorothy for digital signatures.... they only offer X509. btw: Some time ago I've asked them where I could met one of their officials to securely get the root certificate...they told me that this is not possible, and that the root certificate is only available via an ldap server... LOL (You must know,.. in Germany there are no man in the middle attacks, so this is actually secure *G*) > > And for your specific example, no one forces the insurance company or > > the bank to use the newer versions/features. > Except for people like you, who say "it's not hard to upgrade GnuPG, so > there's no reason to be concerned about interoperability with old > versions". Why? Just because new (perhaps incompatible) features are added in newer versions,... nobody has to use that newer versions, right? Best wishes, Herbert. From prlewis at letterboxes.org Tue Apr 15 15:33:08 2008 From: prlewis at letterboxes.org (Peter Lewis) Date: Tue, 15 Apr 2008 14:33:08 +0100 Subject: How trust works in gpg... In-Reply-To: <4804A994.6020508@sven-radde.de> References: <200804142205.59132.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <4804A994.6020508@sven-radde.de> Message-ID: <200804151433.08557.prlewis@letterboxes.org> On Tuesday 15 April 2008 at 14:11:48 Sven Radde wrote: > Stan Tobias schrieb: > > If a public key has a UID1, which I already > > trust, and a new UID2 is added, why can't I infer trust for the new uid? > > (...) > > So the > > only person that could have added UID2 is the one that is in control of > > UID1 (supposedly, it's the same person). Why is there a need to check > > anything? > > Because you do not know whether the owner of UID1 is also the owner of > UID2. > > Let's say, someone trusts my key and my user-id on that key. > Now, I add another ID: "Stan Tobias "... > No good idea to trust that without checking, is it? But isn't that the point of signing new UID's with the original one? Pete. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Tue Apr 15 15:40:17 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 15 Apr 2008 08:40:17 -0500 Subject: Miscellaneous questions In-Reply-To: <1b369b200804150621i1d30774cj3338c60f1e732dfe@mail.gmail.com> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <48040832.1000909@sixdemonbag.org> <1b369b200804150424y7a083f3ax8ac91c4d24e1024@mail.gmail.com> <4804A78E.9050806@sixdemonbag.org> <1b369b200804150621i1d30774cj3338c60f1e732dfe@mail.gmail.com> Message-ID: <4804B041.8030203@sixdemonbag.org> > Why? Just because new (perhaps incompatible) features are added in > newer versions,... nobody has to use that newer versions, right? If you put GnuPG 3.0 available for download, everyone who's looking for the latest release will grab it. The people who are quite happy with 1.2, 1.4 or 2.0 won't. Now imagine that 3.0 breaks backwards compatibility. Anarchy ensues. A lot of your users can't talk to each other. Most of them don't know why. "I'm using GnuPG 3.0, I don't know why it can't talk to PGP 5.0, I mean, GnuPG 2.0 could...!" Ensuring a migration path is so critically important in software engineering. Breaking backwards compatibility is seen as an extreme step. From lhshas at googlemail.com Tue Apr 15 15:44:30 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Tue, 15 Apr 2008 15:44:30 +0200 Subject: Miscellaneous questions In-Reply-To: <4804B041.8030203@sixdemonbag.org> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <48040832.1000909@sixdemonbag.org> <1b369b200804150424y7a083f3ax8ac91c4d24e1024@mail.gmail.com> <4804A78E.9050806@sixdemonbag.org> <1b369b200804150621i1d30774cj3338c60f1e732dfe@mail.gmail.com> <4804B041.8030203@sixdemonbag.org> Message-ID: <1b369b200804150644q6740e7a0l9fa703577a3fd397@mail.gmail.com> 1) This is the cost of advance... 2) btw: I've never said that one mustn't provide backward compatibility. Of course there are things that would break that (e.g. use something else than SHA1 for fingerprints) but my ideas about how to interpret the standard, and where to put some subpacktes wouldn't break the formats... On Tue, Apr 15, 2008 at 3:40 PM, Robert J. Hansen wrote: > > > Why? Just because new (perhaps incompatible) features are added in > > newer versions,... nobody has to use that newer versions, right? > > > > If you put GnuPG 3.0 available for download, everyone who's looking for the > latest release will grab it. The people who are quite happy with 1.2, 1.4 > or 2.0 won't. > > Now imagine that 3.0 breaks backwards compatibility. > > Anarchy ensues. A lot of your users can't talk to each other. Most of > them don't know why. "I'm using GnuPG 3.0, I don't know why it can't talk > to PGP 5.0, I mean, GnuPG 2.0 could...!" > > Ensuring a migration path is so critically important in software > engineering. Breaking backwards compatibility is seen as an extreme step. > From email at sven-radde.de Tue Apr 15 16:05:45 2008 From: email at sven-radde.de (Sven Radde) Date: Tue, 15 Apr 2008 16:05:45 +0200 Subject: How trust works in gpg... In-Reply-To: <200804151433.08557.prlewis@letterboxes.org> References: <200804142205.59132.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <4804A994.6020508@sven-radde.de> <200804151433.08557.prlewis@letterboxes.org> Message-ID: <4804B639.9030905@sven-radde.de> Peter Lewis schrieb: >> Because you do not know whether the owner of UID1 is also the owner of >> UID2. >> >> Let's say, someone trusts my key and my user-id on that key. >> Now, I add another ID: "Stan Tobias "... >> No good idea to trust that without checking, is it? >> > But isn't that the point of signing new UID's with the original one? > You don't sign with a UID. You always sign with a private key. Signing a new UID with the same key that was used to sign another UID proves that the same person that created the first UID created the second one. It does not prove that the person controls (or, is identified by) the second UID. As I said before: If you trust my key, I could simply add "Stan Tobias " as UID to my key. If this new UID was trusted immediately, you would use *my* key to encrypt emails intended to go to Stan..! The crucial thing is connecting the person identified by a UID with a private key. This is what is meant by "trust" in a UID and in OpenPGP, this trust is expressed by signing the UID with your key. cu, Sven From mca_debu at yahoo.co.in Tue Apr 15 13:06:44 2008 From: mca_debu at yahoo.co.in (Debabrata Das) Date: Tue, 15 Apr 2008 12:06:44 +0100 (BST) Subject: Need Help Message-ID: <11203.75197.qm@web94103.mail.in2.yahoo.com> Hi All, Currently we are using GnuPG 1.4.7 which is under GPL V2 on HP-UX ,but we came to know that there is a security vulnerability on GnuPG 1.4.8 & earlier version.Since Gnupg 1.4.9 is under GPL V3 & we don't want to move to product under GPL v3.Can you please tell us if it is permissible to back port all the changes made to GnuPg 1.4.9 on to Gnupg 1.4.7. We are interested to use whatever the changes made to bug-fix release Gnupg 1.4.9 on to Gnupg 1.4.7 which is under GPL V2 and use it. Looking forward for your response. Regards Debabrata India between 2007-09-19 and 9999-99-99
Explore your hobbies and interests. Click here to begin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwood at IUPUI.Edu Tue Apr 15 15:37:45 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Tue, 15 Apr 2008 09:37:45 -0400 Subject: How trust works in gpg... In-Reply-To: <200804151323.01771.prlewis@letterboxes.org> References: <200804142205.59132.prlewis@letterboxes.org> <200804151052.51733.prlewis@letterboxes.org> <1b369b200804150439j75b4a577ncccb78f346620f80@mail.gmail.com> <200804151323.01771.prlewis@letterboxes.org> Message-ID: <20080415133745.GB19228@IUPUI.Edu> On Tue, Apr 15, 2008 at 01:23:01PM +0100, Peter Lewis wrote: > So I guess my question is: is this a guide for me, and then I should manually > set the trust level on key F myself (if I am satisfied that the chains > exist), or should gpg do this automatically for me based on the parameters in > my gpg.conf? It doesn't seem to be calculating anything automatically at the > moment. What it is meant to do I can't say, but I hope that it does *not* assign trust to others' keys automatically. What I would expect is that what gpg does on its own is to authenticate a use of a key: does this crypto blob have the properties necessary to be judged a valid use of key X? But the *meaning* of that validity *to me* is a judgment that no machine can make. I should have to grant trust myself, because gpg cannot know enough about me to do it for me. I may trust B's handling of his own keys, but not trust B's judgments about F's handling of *his* keys. The safest thing for gpg to assume is that I assign no trust at all until I have instructed it otherwise. B's signature on F's key is information that I might take into consideration, but I might (for example) decide merely to remember that datum and observe F's behavior for a while before trusting F's key. As for whether you should do anything about your associate's additional UID, you should consider the proposition that what you are willing to say to the world about your associate as an individual, and what you are willing to say about his persona as a representative of his employers, may be two different things. For one thing, the handling of his "company" UID may be dictated by policy beyond his control and not altogether in his hands. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lhshas at googlemail.com Tue Apr 15 15:38:19 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Tue, 15 Apr 2008 15:38:19 +0200 Subject: How trust works in gpg... In-Reply-To: <200804151433.08557.prlewis@letterboxes.org> References: <200804142205.59132.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <4804A994.6020508@sven-radde.de> <200804151433.08557.prlewis@letterboxes.org> Message-ID: <1b369b200804150638qba790c7g3132cd8349eb2057@mail.gmail.com> Well but if Peter Lewis adds a new UID "Stan Tobias " you obviously can't sign it, because the keyholder is Peter Lewis and not Stan Tobias. hf From email at sven-radde.de Tue Apr 15 16:56:59 2008 From: email at sven-radde.de (Sven Radde) Date: Tue, 15 Apr 2008 16:56:59 +0200 Subject: How trust works in gpg... In-Reply-To: <20080415133745.GB19228@IUPUI.Edu> References: <200804142205.59132.prlewis@letterboxes.org> <200804151052.51733.prlewis@letterboxes.org> <1b369b200804150439j75b4a577ncccb78f346620f80@mail.gmail.com> <200804151323.01771.prlewis@letterboxes.org> <20080415133745.GB19228@IUPUI.Edu> Message-ID: <4804C23B.2040108@sven-radde.de> Mark H. Wood schrieb: > The safest thing for gpg to assume > is that I assign no trust at all until I have instructed it > otherwise. AFAIK this is the default behaviour, isn't it? You have the option of specifying "trusted introducers" (i.e. keys signed by those are automatically considered valid by you), but you don't have to. To me it looks like the two "trust" concepts of GnuPG are somewhat intermingled in this discussion: - First, there's the "trust" in a UID which means that you trust the assiciation betweed the key and the person identified by the UID. This is usually expressed by signing the UID in question. Another term would be "validity" of the key, IIRC. - Second, there's the "owner trust" assigned to a key, meaning that you trust that the key's owner, before signing other UIDs has made reasonable checks to the "trust" defined above. Default for this kind of trust is AFAIK "none", and you may manually set it to "marginal" or "full". You can then configure GnuPG to consider UIDs valid (i.e. you yourself "trust" them according to the first definition) when a certain number of "marginally" and/or "fully" trusted signatures already have been made on that UID. HTH, Sven From lhshas at googlemail.com Tue Apr 15 17:06:36 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Tue, 15 Apr 2008 17:06:36 +0200 Subject: How trust works in gpg... In-Reply-To: <4804C23B.2040108@sven-radde.de> References: <200804142205.59132.prlewis@letterboxes.org> <200804151052.51733.prlewis@letterboxes.org> <1b369b200804150439j75b4a577ncccb78f346620f80@mail.gmail.com> <200804151323.01771.prlewis@letterboxes.org> <20080415133745.GB19228@IUPUI.Edu> <4804C23B.2040108@sven-radde.de> Message-ID: <1b369b200804150806q63fc83dahb139edc3d47047c1@mail.gmail.com> On Tue, Apr 15, 2008 at 4:56 PM, Sven Radde wrote: >[snip snap] Well said :) From prlewis at letterboxes.org Tue Apr 15 17:09:51 2008 From: prlewis at letterboxes.org (Peter Lewis) Date: Tue, 15 Apr 2008 16:09:51 +0100 Subject: How trust works in gpg... In-Reply-To: <4804C23B.2040108@sven-radde.de> References: <200804142205.59132.prlewis@letterboxes.org> <20080415133745.GB19228@IUPUI.Edu> <4804C23B.2040108@sven-radde.de> Message-ID: <200804151609.51518.prlewis@letterboxes.org> On Tuesday 15 April 2008 at 15:05:45 Sven Radde wrote: > Signing a new UID with the same key that was used to sign another UID > proves that the same person that created the first UID created the > second one. > It does not prove that the person controls (or, is identified by) the > second UID. > > As I said before: If you trust my key, I could simply add "Stan Tobias > " as UID to my key. > If this new UID was trusted immediately, you would use *my* key to > encrypt emails intended to go to Stan..! > > The crucial thing is connecting the person identified by a UID with a > private key. > This is what is meant by "trust" in a UID and in OpenPGP, this trust is > expressed by signing the UID with your key. Right, that makes sense now. Thanks everyone for the help - I think I was rather confused about the differences and connections between "validity", "trust" and "ownertrust": On Tuesday 15 April 2008 at 15:56:59 Sven Radde wrote: > To me it looks like the two "trust" concepts of GnuPG are somewhat > intermingled in this discussion: > - First, there's the "trust" in a UID which means that you trust the > assiciation betweed the key and the person identified by the UID. This > is usually expressed by signing the UID in question. Another term would > be "validity" of the key, IIRC. > - Second, there's the "owner trust" assigned to a key, meaning that you > trust that the key's owner, before signing other UIDs has made > reasonable checks to the "trust" defined above. Default for this kind of > trust is AFAIK "none", and you may manually set it to "marginal" or > "full". You can then configure GnuPG to consider UIDs valid (i.e. you > yourself "trust" them according to the first definition) when a certain > number of "marginally" and/or "fully" trusted signatures already have > been made on that UID. Yes, that's what I now understand :-) Please excuse one final question: I have signed keys with one person (A), whom I trust fully, and he has signed keys with another person (B), whom I know, but with whom I have not signed keys. B's key is (correctly) showing as *valid*. Should I still wait until I can check his identity using the photo-id and fingerprint, or is this now good enough for me to sign B's key? I wouldn't have thought so, but I just want to make sure I'm absolutely clear about this stuff. Thanks again, Pete. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part. URL: From shavital at mac.com Tue Apr 15 17:07:39 2008 From: shavital at mac.com (Charly Avital) Date: Tue, 15 Apr 2008 11:07:39 -0400 Subject: How trust works in gpg... In-Reply-To: <1b369b200804150638qba790c7g3132cd8349eb2057@mail.gmail.com> References: <200804142205.59132.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <4804A994.6020508@sven-radde.de> <200804151433.08557.prlewis@letterboxes.org> <1b369b200804150638qba790c7g3132cd8349eb2057@mail.gmail.com> Message-ID: <4804C4BB.60908@mac.com> Herbert Furting wrote the following on 4/15/08 9:38 AM: > Well but if Peter Lewis adds a new UID "Stan > Tobias " you obviously can't sign it, because the > keyholder is Peter Lewis and not Stan Tobias. > > hf > To add a new UID, whichever it is, wouldn't Peter Lewis be prompted to self-sign the new UID, enter Peter Lewis's passphrase for the key, thus creating a self signature appended to the new UID, that will be visible? The "phony" additional UID would be signed by Peter Lewis, key owner? I have dry-tested it on one my keys. Charly From wk at gnupg.org Tue Apr 15 17:54:06 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 15 Apr 2008 17:54:06 +0200 Subject: Miscellaneous questions In-Reply-To: <4804A78E.9050806@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 15 Apr 2008 08:03:10 -0500") References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <48040832.1000909@sixdemonbag.org> <1b369b200804150424y7a083f3ax8ac91c4d24e1024@mail.gmail.com> <4804A78E.9050806@sixdemonbag.org> Message-ID: <87tzi3i069.fsf@wheatstone.g10code.de> On Tue, 15 Apr 2008 15:03, rjh at sixdemonbag.org said: > This is how GnuPG was developed, by and large. In the very early days, > GnuPG supported only the bare minimum necessary to conform to the RFC. > Features like Twofish support were not added until the MUSTs were well Actually GnuPG predates OpenPGP by a year and development of OpenPGP and GnuPG went hand in hand. For example, we added Twofish because we were in need of a 128 bit blocksize algorithm and Twofish was promising. This was during the AES process and we could not wait for the winner of the AES competition. However, in general you are right. We implement the MUSTs and then the optional features the users think are useful. >> So perhaps let's ask David. He's both member of the WG (and even a >> named author since 4880 :-) ) and gnupg developer. Why did he agreed >> to the features in 4880 (as author) if (as developer) he thinks >> nobody needs them? > > I'm not going to presume to try to answer for David. I will suggest There quite some people involved in the OpenPGP WG and we sometimes need to make pragmatic decisions. For instance the complicated partial block encoding is nothing anyone really desired. However the already existing PGP 5 code used that and thus we accepted this encoding and did not used the one gpg used in the beginning. As with most standards, the basics are set by existing applications. Another reasons for some features is pure marketing; for example the choice of 256 bit for Twofish. And of course there are political reasons like the inclusion of some ciphers (e.g. RIPE-MD160 and soon Camellia) and the avoidance of patented algorithms. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From JPClizbe at tx.rr.com Tue Apr 15 18:03:44 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Tue, 15 Apr 2008 11:03:44 -0500 Subject: Need Help In-Reply-To: <11203.75197.qm@web94103.mail.in2.yahoo.com> References: <11203.75197.qm@web94103.mail.in2.yahoo.com> Message-ID: <4804D1E0.4050508@tx.rr.com> Debabrata Das wrote: > Hi All, > > Currently we are using GnuPG 1.4.7 which is under GPL V2 on HP-UX ,but > we came to know that there is a security vulnerability on GnuPG 1.4.8 & > earlier version.Since Gnupg 1.4.9 is under GPL V3 & we don't want to > move to product under GPL v3.Can you please tell us if it is > permissible to back port all the changes made to GnuPg 1.4.9 on to > Gnupg 1.4.7. > > We are interested to use whatever the changes made to bug-fix release > Gnupg 1.4.9 on to Gnupg 1.4.7 which is under GPL V2 and use it. There is nothing to backport. David Shaw answered this exact same post last Friday on both GnuPG-Users and GnuPG-Devel. To save you the /herculean/ effort of actually reading either list, here again is his reply: "The recent bug only applies to 1.4.8 and 2.0.8. It does not apply to 1.4.7 or any earlier version. There is no need to backport any patches." David is one of the principal developers of GnuPG. I'd trust his answer on this. -- John P. Clizbe Inet: JPClizbe (a) tx DAWT rr DAHT con Ginger Bear Networks hkp://keyserver.gingerbear.net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- 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 Tue Apr 15 18:39:07 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 15 Apr 2008 12:39:07 -0400 Subject: How trust works in gpg... In-Reply-To: <200804151609.51518.prlewis@letterboxes.org> References: <200804142205.59132.prlewis@letterboxes.org> <20080415133745.GB19228@IUPUI.Edu> <4804C23B.2040108@sven-radde.de> <200804151609.51518.prlewis@letterboxes.org> Message-ID: <20080415163907.GB56745@jabberwocky.com> On Tue, Apr 15, 2008 at 04:09:51PM +0100, Peter Lewis wrote: > Please excuse one final question: I have signed keys with one person (A), whom > I trust fully, and he has signed keys with another person (B), whom I know, > but with whom I have not signed keys. B's key is (correctly) showing as > *valid*. Should I still wait until I can check his identity using the > photo-id and fingerprint, or is this now good enough for me to sign B's key? > > I wouldn't have thought so, but I just want to make sure I'm > absolutely clear about this stuff. You are correct. You should not sign his key until you check his identity. Signing his key is making a statement that you confirm his identity, and in the example above you cannot make such a statement. David From dshaw at jabberwocky.com Tue Apr 15 19:32:17 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 15 Apr 2008 13:32:17 -0400 Subject: How trust works in gpg... In-Reply-To: <20080415133745.GB19228@IUPUI.Edu> References: <200804142205.59132.prlewis@letterboxes.org> <200804151052.51733.prlewis@letterboxes.org> <1b369b200804150439j75b4a577ncccb78f346620f80@mail.gmail.com> <200804151323.01771.prlewis@letterboxes.org> <20080415133745.GB19228@IUPUI.Edu> Message-ID: <20080415173217.GC56745@jabberwocky.com> On Tue, Apr 15, 2008 at 09:37:45AM -0400, Mark H. Wood wrote: > On Tue, Apr 15, 2008 at 01:23:01PM +0100, Peter Lewis wrote: > > So I guess my question is: is this a guide for me, and then I should manually > > set the trust level on key F myself (if I am satisfied that the chains > > exist), or should gpg do this automatically for me based on the parameters in > > my gpg.conf? It doesn't seem to be calculating anything automatically at the > > moment. > > What it is meant to do I can't say, but I hope that it does *not* > assign trust to others' keys automatically. It does not. When you sign a key, you make that key *valid*, which just means "I believe this key does belong to the person it claims to belong to". When you set *trust* (aka "ownertrust") on that key, you are saying "I believe the person who owns this key makes signatures that I am willing to rely on". > I may trust B's handling of his own keys, but not trust B's judgments > about F's handling of *his* keys. The safest thing for gpg to assume > is that I assign no trust at all until I have instructed it > otherwise. B's signature on F's key is information that I might take > into consideration, but I might (for example) decide merely to > remember that datum and observe F's behavior for a while before > trusting F's key. Yep. David From dshaw at jabberwocky.com Tue Apr 15 19:37:52 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 15 Apr 2008 13:37:52 -0400 Subject: How trust works in gpg... In-Reply-To: <48049BFF.nail56411UIHS@mailshack.com> References: <200804142205.59132.prlewis@letterboxes.org> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <200804151052.51733.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> Message-ID: <20080415173752.GD56745@jabberwocky.com> On Tue, Apr 15, 2008 at 02:13:51PM +0200, Stan Tobias wrote: > Herbert Furting wrote: > > If the new UID just contains a new email address, you should really > > check if the keyholder "controlls" that email address. > > You can do so, by sending him an encrypted challenge. > > [another newbie here] > I don't understand this. If a public key has a UID1, which I already > trust, and a new UID2 is added, why can't I infer trust for the new uid? > My reasoning goes: UID1 is signed by its owner's private key, and I chose > to trust it (directly, or through others' sigs). When new UID2 is added, > it must be also signed by the same private key, which is connected to > UID1, which I trust belongs to the person it says it belongs to. So the > only person that could have added UID2 is the one that is in control of > UID1 (supposedly, it's the same person). Why is there a need to check > anything? Because of the word "supposedly" in your question above :) You don't really *know* that UID2 refers to the same real-world person as UID1 without checking. Now, if UID1 is "David Shaw", and UID2 is "Dave Shaw" (and the email address is the same for both), you can probably sign UID2 without too much worry. But if UID1 is "John Smith " and UID2 is "Bill Smith ", you need to ask some questions before signing UID2. David From dshaw at jabberwocky.com Tue Apr 15 19:45:33 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 15 Apr 2008 13:45:33 -0400 Subject: How trust works in gpg... In-Reply-To: <200804151433.08557.prlewis@letterboxes.org> References: <200804142205.59132.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <4804A994.6020508@sven-radde.de> <200804151433.08557.prlewis@letterboxes.org> Message-ID: <20080415174533.GE56745@jabberwocky.com> On Tue, Apr 15, 2008 at 02:33:08PM +0100, Peter Lewis wrote: > On Tuesday 15 April 2008 at 14:11:48 Sven Radde wrote: > > Stan Tobias schrieb: > > > If a public key has a UID1, which I already > > > trust, and a new UID2 is added, why can't I infer trust for the new uid? > > > (...) > > > So the > > > only person that could have added UID2 is the one that is in control of > > > UID1 (supposedly, it's the same person). Why is there a need to check > > > anything? > > > > Because you do not know whether the owner of UID1 is also the owner of > > UID2. > > > > Let's say, someone trusts my key and my user-id on that key. > > Now, I add another ID: "Stan Tobias "... > > No good idea to trust that without checking, is it? > > But isn't that the point of signing new UID's with the original one? That's not how signing works. You don't sign a UID with a UID. You sign a UID with a key. KEY = The primary key. It can issue signatures. UID = A name SIG = A signature that is made on the combination of KEY+UID. SELFSIG = Same as SIG, bit issued yourself (i.e. by KEY). When you make a key, you end up with (leaving out subkeys for now): KEY + UID + SELFSIG If someone wants to sign your key, you then end up with: KEY + UID + SELFSIG + SIG So SELFSIG is you saying "I bind this KEY and UID together", and SIG is the other person saying "Me too". If you add another UID at this point, you have: KEY + UID + SELFSIG + SIG + UID + SELFSIG Now, note that the other person hasn't made any statement about whether the second UID is valid. YOU have, but then, it's your key: you can make any statement you like. It only becomes believable when someone else adds their "me too". David From email at sven-radde.de Tue Apr 15 20:03:23 2008 From: email at sven-radde.de (Sven Radde) Date: Tue, 15 Apr 2008 20:03:23 +0200 Subject: Need Help In-Reply-To: <4804D1E0.4050508@tx.rr.com> References: <11203.75197.qm@web94103.mail.in2.yahoo.com> <4804D1E0.4050508@tx.rr.com> Message-ID: <1208282603.6337.12.camel@carbon> Hi! Am Dienstag, den 15.04.2008, 11:03 -0500 schrieb John Clizbe: > There is nothing to backport. David Shaw answered this exact same post last > Friday on both GnuPG-Users and GnuPG-Devel. I felt already last Friday that this was only a partial answer to the question. Although it might not be necessary to backport 1.4.9's changes to 1.4.7, nobody can guarantee that there won't be a 1.4.10 that fixes a vulnerability which exists since 1.4.7. It might be worth to solve the issue of possible backports now, when - as you rightly state - there is no need for immediate action. cu, Sven From dshaw at jabberwocky.com Tue Apr 15 20:04:26 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 15 Apr 2008 14:04:26 -0400 Subject: How trust works in gpg... In-Reply-To: <20080415102143.GC2774@kol06wsthv-it22.kaufhof.net> References: <200804142205.59132.prlewis@letterboxes.org> <1208209846.9323.1.camel@fermat.scientia.net> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <20080415102143.GC2774@kol06wsthv-it22.kaufhof.net> Message-ID: <20080415180426.GF56745@jabberwocky.com> On Tue, Apr 15, 2008 at 12:21:43PM +0200, Michael Kesper wrote: > Hi, > > On Tue, Apr 15, 2008 at 12:42:43AM +0200, Herbert Furting wrote: > > On Mon, 2008-04-14 at 23:20 +0100, Peter Lewis wrote: > > > Ah yes, thanks. So I have now set the owner-trust for his key to "full", but > > > still it says "unknown" for the other UIDs. So, I should manually set the > > > trust for keys / UIDs that I think I trust based on who has signed them? > > Sorry,.. I haven't read your initial post correctly. > > As David said in the meantime new UIDs are of course _not_ recognised > > automatically (a user could simply add a completely wrong name). You > > have to sign the UID (better said, key+UID). > > You should only do so, if the name is the same (or if you know that the > > key holder goes by that name). > > > > If the new UID just contains a new email address, you should really > > check if the keyholder "controlls" that email address. > > You can do so, by sending him an encrypted challenge. > > I remember Werner saying that this was just nonsense. > Werner, can you correct me if I'm wrong? Not enough information above to say nonsense or not. There are silly ways to use challenges and non-silly ways. The idea behind a challenge is to send something to the email address in the UID and ask the recipient to sign it, and send it back. Encryption is not involved here (you can encrypt it if you like, but it doesn't make a difference either way). You are verifying that the email address on the key goes to some entity that has the ability to actually use the key. David From dshaw at jabberwocky.com Tue Apr 15 20:09:02 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 15 Apr 2008 14:09:02 -0400 Subject: How trust works in gpg... In-Reply-To: <1b369b200804150610r224ef516q136a4e54a9e5d987@mail.gmail.com> References: <200804142205.59132.prlewis@letterboxes.org> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <200804151052.51733.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <1b369b200804150610r224ef516q136a4e54a9e5d987@mail.gmail.com> Message-ID: <20080415180902.GG56745@jabberwocky.com> On Tue, Apr 15, 2008 at 03:10:47PM +0200, Herbert Furting wrote: > To say it short: In my opinion every information that you sign/certify > should be actually validaded. > It probably makes even sense to check if a keyholder specified all of > his given names,... and perhaps one shouldn't sign UIDs like "Geroge > W. Bush" if the W. is an abbreviation, while "Harry S Truman" would be > ok,.. as the S wasn't an abbreviation (iirc). Not at all (though it is true that the S in Harry Truman's name isn't an abbreviation). When you sign a UID, you're signing what is there, and not making any statement beyond what is there. You don't need to insist they spell out all of their names. David From lhshas at googlemail.com Tue Apr 15 21:36:04 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Tue, 15 Apr 2008 21:36:04 +0200 Subject: How trust works in gpg... In-Reply-To: <20080415180902.GG56745@jabberwocky.com> References: <200804142205.59132.prlewis@letterboxes.org> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <200804151052.51733.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <1b369b200804150610r224ef516q136a4e54a9e5d987@mail.gmail.com> <20080415180902.GG56745@jabberwocky.com> Message-ID: <1208288164.4825.84.camel@fermat.scientia.net> On Tue, 2008-04-15 at 14:09 -0400, David Shaw wrote: > On Tue, Apr 15, 2008 at 03:10:47PM +0200, Herbert Furting wrote: > > To say it short: In my opinion every information that you sign/certify > > should be actually validaded. > > It probably makes even sense to check if a keyholder specified all of > > his given names,... and perhaps one shouldn't sign UIDs like "Geroge > > W. Bush" if the W. is an abbreviation, while "Harry S Truman" would be > > ok,.. as the S wasn't an abbreviation (iirc). > > Not at all (though it is true that the S in Harry Truman's name isn't > an abbreviation). > > When you sign a UID, you're signing what is there, and not making any > statement beyond what is there. You don't need to insist they spell > out all of their names. Well I think it's generally better to always use only full names,... that helps to prevent collisions like if my name would be "David Something Shaw". Of course I say that it only helps,.. it doesn't fully solve this. Anyway it is a matter of policy,... the stricter the policy is, the more likely it is, that it will require to include all official names. See for example the certificates of the German signature law... IIRC it is not allowed to skip names or switch names like "Hans-J?rgen" into "Hans J?rgen". Herbe From christoph.anton.mitterer at physik.uni-muenchen.de Tue Apr 15 21:27:26 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Tue, 15 Apr 2008 21:27:26 +0200 Subject: How trust works in gpg... In-Reply-To: <20080415174533.GE56745@jabberwocky.com> References: <200804142205.59132.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <4804A994.6020508@sven-radde.de> <200804151433.08557.prlewis@letterboxes.org> <20080415174533.GE56745@jabberwocky.com> Message-ID: <1208287646.4825.75.camel@fermat.scientia.net> On Tue, 2008-04-15 at 13:45 -0400, David Shaw wrote: > If someone wants to sign your key, you then end up with: > > KEY + UID + SELFSIG + SIG > Nicely illustrated,.. but let me please add (I know of course that _you_ know this) that the SIG is made only over the KEY+UID data,... thus the keyholder can happily change his SELFSIG whenever he wants without loosing the SIG's. Best wishes, -- Dipl.-Inf. (FH) Christoph Anton Mitterer eMail: christoph.anton.mitterer at physik.uni-muenchen.de mail at christoph.anton.mitterer.name Jabber/XMPP: chat at christoph.anton.mitterer.name Ludwig-Maximilians-Universit?t M?nchen Lehrstuhl f?r experimentelle Physik ? Elementarteilchenphysik Sektion Physik Am Coulombwall 1 85748 Garching bei M?nchen Germany From dshaw at jabberwocky.com Tue Apr 15 22:41:21 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 15 Apr 2008 16:41:21 -0400 Subject: How trust works in gpg... In-Reply-To: <1208288164.4825.84.camel@fermat.scientia.net> References: <200804142205.59132.prlewis@letterboxes.org> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <200804151052.51733.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <1b369b200804150610r224ef516q136a4e54a9e5d987@mail.gmail.com> <20080415180902.GG56745@jabberwocky.com> <1208288164.4825.84.camel@fermat.scientia.net> Message-ID: <20080415204121.GJ56745@jabberwocky.com> On Tue, Apr 15, 2008 at 09:36:04PM +0200, Herbert Furting wrote: > On Tue, 2008-04-15 at 14:09 -0400, David Shaw wrote: > > On Tue, Apr 15, 2008 at 03:10:47PM +0200, Herbert Furting wrote: > > > To say it short: In my opinion every information that you sign/certify > > > should be actually validaded. > > > It probably makes even sense to check if a keyholder specified all of > > > his given names,... and perhaps one shouldn't sign UIDs like "Geroge > > > W. Bush" if the W. is an abbreviation, while "Harry S Truman" would be > > > ok,.. as the S wasn't an abbreviation (iirc). > > > > Not at all (though it is true that the S in Harry Truman's name isn't > > an abbreviation). > > > > When you sign a UID, you're signing what is there, and not making any > > statement beyond what is there. You don't need to insist they spell > > out all of their names. > Well I think it's generally better to always use only full names,... > that helps to prevent collisions like if my name would be "David > Something Shaw". Of course I say that it only helps,.. it doesn't fully > solve this. It is irrelevant to this. There are a lot of "David Shaw"s in the world, and it's pointless to try and prevent collisions in a set that large. The disambiguation in OpenPGP keys is really the email address, not the name. David From dshaw at jabberwocky.com Tue Apr 15 22:43:37 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 15 Apr 2008 16:43:37 -0400 Subject: How trust works in gpg... In-Reply-To: <1208287646.4825.75.camel@fermat.scientia.net> References: <200804142205.59132.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <4804A994.6020508@sven-radde.de> <200804151433.08557.prlewis@letterboxes.org> <20080415174533.GE56745@jabberwocky.com> <1208287646.4825.75.camel@fermat.scientia.net> Message-ID: <20080415204337.GK56745@jabberwocky.com> On Tue, Apr 15, 2008 at 09:27:26PM +0200, Christoph Anton Mitterer wrote: > On Tue, 2008-04-15 at 13:45 -0400, David Shaw wrote: > > If someone wants to sign your key, you then end up with: > > > > KEY + UID + SELFSIG + SIG > > > Nicely illustrated,.. but let me please add (I know of course that _you_ > know this) that the SIG is made only over the KEY+UID data,... thus the > keyholder can happily change his SELFSIG whenever he wants without > loosing the SIG's. Yes indeed. OpenPGP even expects users to change their SELFSIGs occasionally - the preferences and other UID-specific information is stored there, so a change to preferences means a change in SELFSIG. David From lhshas at googlemail.com Tue Apr 15 23:03:43 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Tue, 15 Apr 2008 23:03:43 +0200 Subject: How trust works in gpg... In-Reply-To: <20080415204337.GK56745@jabberwocky.com> References: <200804142205.59132.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <4804A994.6020508@sven-radde.de> <200804151433.08557.prlewis@letterboxes.org> <20080415174533.GE56745@jabberwocky.com> <1208287646.4825.75.camel@fermat.scientia.net> <20080415204337.GK56745@jabberwocky.com> Message-ID: <1208293423.10031.4.camel@fermat.scientia.net> On Tue, 2008-04-15 at 16:43 -0400, David Shaw wrote: > Yes indeed. OpenPGP even expects users to change their SELFSIGs > occasionally - the preferences and other UID-specific information is > stored there, so a change to preferences means a change in SELFSIG. Yeah,.. I just try to browse to the sources to find out how to generate my custom self-sigs,... however it seems that I can't find my way... :-( Herbert. From dshaw at jabberwocky.com Tue Apr 15 23:09:42 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 15 Apr 2008 17:09:42 -0400 Subject: How trust works in gpg... In-Reply-To: <1208293423.10031.4.camel@fermat.scientia.net> References: <200804142205.59132.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <4804A994.6020508@sven-radde.de> <200804151433.08557.prlewis@letterboxes.org> <20080415174533.GE56745@jabberwocky.com> <1208287646.4825.75.camel@fermat.scientia.net> <20080415204337.GK56745@jabberwocky.com> <1208293423.10031.4.camel@fermat.scientia.net> Message-ID: <20080415210942.GL56745@jabberwocky.com> On Tue, Apr 15, 2008 at 11:03:43PM +0200, Herbert Furting wrote: > On Tue, 2008-04-15 at 16:43 -0400, David Shaw wrote: > > Yes indeed. OpenPGP even expects users to change their SELFSIGs > > occasionally - the preferences and other UID-specific information is > > stored there, so a change to preferences means a change in SELFSIG. > Yeah,.. I just try to browse to the sources to find out how to generate > my custom self-sigs,... however it seems that I can't find my way... :-( Change your preferences and GPG will make a new selfsig for you. No source hacking needed. David From christoph.anton.mitterer at physik.uni-muenchen.de Tue Apr 15 23:16:34 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Tue, 15 Apr 2008 23:16:34 +0200 Subject: How trust works in gpg... In-Reply-To: <20080415204121.GJ56745@jabberwocky.com> References: <200804142205.59132.prlewis@letterboxes.org> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <200804151052.51733.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <1b369b200804150610r224ef516q136a4e54a9e5d987@mail.gmail.com> <20080415180902.GG56745@jabberwocky.com> <1208288164.4825.84.camel@fermat.scientia.net> <20080415204121.GJ56745@jabberwocky.com> Message-ID: <1208294194.10031.18.camel@fermat.scientia.net> Dear David. On Tue, 2008-04-15 at 16:41 -0400, David Shaw wrote: > It is irrelevant to this. There are a lot of "David Shaw"s in the > world, and it's pointless to try and prevent collisions in a set that > large. The disambiguation in OpenPGP keys is really the email > address, not the name. Hm in my opinion this depends on how the User ID packet type is interpreted (I'll try discuss that on the WG list in some days). If it is actually only an ID in the sense to clearly differentiate all keys I think the name is actually irrelevant, as names always have collisions. But in that case the User ID packet type should be change (of course this is heavily incompatible) to only contain an unique identifier like an email adress, perhaps even DNS names, or UUIDs. And the Name should be moved to a user attribute package. You see what I mean? I consider the ID (which is by the meaning of the word just something to differentiate objects) as a different class of information than user attributes (like his name, birthday, birthplace, or his picture). Ok now back to the beginning: When the name in the UID would be just a cosmetic addition to the actual ID (the e-mail address) I'd say it's irrelevant if it's complete. But if it's interpreted as Name + e-mail of a person, I think one should only certify the whole name. With a certification a signator says is the keyholders name, but in my case my name is neither "Christoph Mitterer", nor "christoph mitterer", nor "Chris Mitterer" it is (even from a legal point of view "Christoph Anton Mitterer". See my point? I consider missing information as grave as wrong information. Each signature on a file or email would not validate if I simply remove something from the mail. Best wishes, -- Dipl.-Inf. (FH) Christoph Anton Mitterer eMail: christoph.anton.mitterer at physik.uni-muenchen.de mail at christoph.anton.mitterer.name Jabber/XMPP: chat at christoph.anton.mitterer.name Ludwig-Maximilians-Universit?t M?nchen Lehrstuhl f?r experimentelle Physik ? Elementarteilchenphysik Sektion Physik Am Coulombwall 1 85748 Garching bei M?nchen Germany From lhshas at googlemail.com Tue Apr 15 23:42:30 2008 From: lhshas at googlemail.com (Herbert Furting) Date: Tue, 15 Apr 2008 23:42:30 +0200 Subject: How trust works in gpg... In-Reply-To: <20080415210942.GL56745@jabberwocky.com> References: <200804142205.59132.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <4804A994.6020508@sven-radde.de> <200804151433.08557.prlewis@letterboxes.org> <20080415174533.GE56745@jabberwocky.com> <1208287646.4825.75.camel@fermat.scientia.net> <20080415204337.GK56745@jabberwocky.com> <1208293423.10031.4.camel@fermat.scientia.net> <20080415210942.GL56745@jabberwocky.com> Message-ID: <1208295750.10031.45.camel@fermat.scientia.net> On Tue, 2008-04-15 at 17:09 -0400, David Shaw wrote: > Change your preferences and GPG will make a new selfsig for you. No > source hacking needed. Yes but ok let me explain what I want or would like to have ;-) My current key has the following layout: ***[Pub key packet]*** ?***[UID]?*** ?***[0x13 selfsig (SHA1), with cipher-, hash-, compress- algo prefs, key flags, features, key expiration time and of course stuff like signature creation time]?*** What I would like to have is probably (I'm actually not yet sure ;) ): ?***[pub key packet]?*** ?***[0x1F selfsig]?*** I assume that would be inserted here? I think it should probably contain, key expiration time, key flags because as far as I understand this information is clearly bond to the key (would it make sense to have different key expiration times, or key flags for different UIDs/roles?) And perhaps even the algo prefs the and the features (if they are the same for all UIDs). Now here I'm note yet sure and I still discuss with Christoph. If the algorigthm preferences and features should be considered as role-preferences,.. the proper place would always be the 0x13 (because these are for the roles, which are effectively the UIDs). But if not, it could make sense to put them on a 0x1F, when they're the same for each UID(/role). I still could add them to single UIDs if some of them have different settings because of their environment. Hmm could one image to have different key-server-uri's per UID? Does this make sense? (And just to prevent any unnecessary discussion,.. I know that this is not the way gpg does handle this stuff (now), and that it is not necessary implied by the standard. I just think that this could make sense. So especially for Robert, please wait until Christoph finishes his paper and post it to the WG.) then the UDIs+0x13's ?***[UID]?*** ?***[the 0x13 selfsig (SHA1)) from above]?*** ?***[that sig nature revoked]?*** (you remember my last mail where I asked you if that makes sense, and you just told me that I still use SHA1 in some places),.. but I still haven't thought about the best fitting reason for revocation [new 0x13 selfsig(SHA512) perhaps with some of the subpackets from above (the algo prefs),.. or not, depending on whether the above makes sense). ?***[ the same for other UIDs ]?*** So just changing the prefs via setprefs doesn't do this :-( I've already found the make_keysig_packet which is called from main keyedit.c to create the selfsig,... but the I got stuck,.. I think what I wish to do needs too much in depth knowledge of gnupgs functions. Is there perhaps a tool that simply allows to edit every aspect of OpenPGP keys, and that then recreates the selfsigs as desired? Including lenght calculation of the packets, the hash contexts and the signature algorithms? Perhaps something like a counterpart to pgpdump (I love that tool XD). Ah and perhaps on last question (for now ;) ) if I have your attention right now. Does it make sense to put policy URI's on selfsigs? Could you imagine a possible meaning of such a thing? Thanks a lot, Herbert. btw: If anybody here thinks I'm a barrater,... blame Christoph,.. he brought me to read the RFC ;) From dshaw at jabberwocky.com Tue Apr 15 23:54:15 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 15 Apr 2008 17:54:15 -0400 Subject: Miscellaneous questions In-Reply-To: <1208219467.12772.2.camel@fermat.scientia.net> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> Message-ID: <20080415215415.GM56745@jabberwocky.com> On Tue, Apr 15, 2008 at 02:31:07AM +0200, Herbert Furting wrote: > On Mon, 2008-04-14 at 18:06 -0500, Robert J. Hansen wrote: > > 1. You didn't ask for the option to allow zero-length UIDs. If you'd > > asked for that option, I would have given it. You asked "why does > > GnuPG have a minimum size of five characters", "is this imposed by > > RFC4880", and "where can I report this bug". Your questions were > > answered. Don't blame me if you asked the wrong questions. > Well I don't want to go into such quibbling, but I've seen that gpg > complained for UIDs shorter than 5 characters,... I've seen that RFC4880 > doesn't require this, and I've asked why. > Not more not less. > > btw: as far as I remember,... zero-length UIDs are allowed by the > standard, aren't they? > While this doesn't make sense ("nothing" is bound to the key) it > wouldn't hurt either. There are a lot of things that fall into the category of "legal by the standard, but not good in the real world". A zero-length UID is one of them. GPG handles this the way it handles most such things - it will accept such a key from the outside world, but will not generate it itself. > > A specification does not set a high-water mark for implementations. It > > sets a low-water mark. Implementations are free to restrict keys in any > > way they want, so long as the low-water mark is met. If you want to > > write an RFC2440 implementation that supports only DSA, SHA-1 and 3DES, > > nobody will stop you. You're meeting the low-water mark. > Of course. But I didn't talk about this at all? Did you read my > arguments? I probably didn't explain it correctly (*not a native English > speaker*): > Preferred * Algorithm => Tells what the user prefers (and not what his > implementation support. Not exactly. It contains what the user prefers **among the algorithms that his implementation supports**. It's the intersection of the algorithms the user prefers for one reason or another and the algorithms that his implementation supports. > However,.. all of this does not answer my original question,.. whether > it works and makes sense (from a security and not interoperability point > of view) do revoke the old SHA1 selfsigs and create new (e.g.) SHA512, > if it works with _current_ versions of gpg, if it's possible at all, and > which revocation reason one should use. It will work. It's foolish and you'll hurt yourself doing it, but it will work. > > > I mean it exists,.. and there are several things (e.g. the examples > > > from my inital post) that would be better of with an 0x1F? > > You're ascribing magical meanings to things. You're not going to be > > safer under your scheme. It's different--it's not better. > Not? > When looking at the prefered * algos it definitely makes sense to allow > putting them on UIDs, because one might e.g. have different locations > (home, work) with different implementations that support different > algos. > > But I think that actually it _is_ better to make a global (key wide) > setting first (on a 0x1F) and just modify UIDs that really need other > settings. This is common sense in the world of computing, like you > have /etc/vim/vimrc with global settings first,.. and only create a > ~/.vimrc if you relly need to do so. This is another thing that GPG will accept from the outside, but not generate itself. > But for the preferred * algo subpackets I agree that it is not really > necessary (although I think it would be cleaner). > But I consider other subpackets e.g. key usage to be really key and nod > UID related. So why putting them on 0x13 selfsigs if we have the > possibility to use the indented signature on key. (Yes I know that the > RFC allows it on all self-sigs, but I think that could be improved). > > > > And this is the problem: you _are_ including it. The RFC requires them > > to be present, and if they're not present, requires all implementations > > to add them. > Could you please show me the place where it says, that those algorithm > IDs must be part of the prefered algorithm subpacktes? Like Robert said, the RFC requires them to be either present, or if they are not present, the implementation must act as if they were present. Section 13.2: Since TripleDES is the MUST-implement algorithm, if it is not explicitly in the list, it is tacitly at the end. However, it is good form to place it there explicitly. Note also that if an implementation does not implement the preference, then it is implicitly a TripleDES-only implementation. "...it is good form to place it there explicitly..." Feel free to change your preferences to not have it there if it makes you happier. Any program that reads your key will act as if it was there anyway. > > Speak for yourself. My personal-cipher-preferences has 3DES explicitly > > listed as my first preference. > Fine. If mine has listed AES256 (and yours too) first and lacks 3DES gpg > should choose AES256,... if yours doesn't list it,.. it should choose > 3DES (or of course another working match). > But imagine the following: > Yours: 3DES, AES256 > Mine: AES256, 3DES > Which one is chosen now? But when I only include AES256 I can at least > somewhat control it. No, you can't. If you only include AES256, your preference list is effectively "AES256, 3DES". You can't get rid of the 3DES. In the example above, you may end up with either 3DES or AES256. The spec requires that it is one of the two - it does not require a particular one to be chosen. That's why GPG has the personal-cipher-preference option, where users can set what they like in ranked order. OpenPGP puts most of the power in the hands of the sender, so the sender decides which algorithm to pick from the list. David From dshaw at jabberwocky.com Wed Apr 16 00:04:15 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 15 Apr 2008 18:04:15 -0400 Subject: Miscellaneous questions In-Reply-To: <1208208179.8757.8.camel@fermat.scientia.net> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <20080414174129.GE54766@jabberwocky.com> <1208208179.8757.8.camel@fermat.scientia.net> Message-ID: <20080415220415.GN56745@jabberwocky.com> On Mon, Apr 14, 2008 at 11:22:59PM +0200, Herbert Furting wrote: > > > While the standard seems to allow this,.. gpg does not (it won't sign a UID > > > when the a self-sig has been revoked before). > > > How can I solve this? > > GPG allows this. Add "--expert" to your command line when you want to > > re-sign the UID, and GPG will allow you to do what you want. > Ah great,... and it will work with gpg,... I mean a layout like, > [pubkey packet] > [UID packet] > [positive user certification 1] > [revoc of positive user certification 1] > ???[positive user certification 2 (with better algos)] It will work with GPG. I can't speak for other programs, but it's legal by the spec, so it should work everywhere. Mind you, you're going to hurt yourself, but it's legal by the spec. > > Mind you, while GPG can do it, I don't think what you are doing is a > > good idea: OpenPGP itself uses SHA1 in a number of places. > I know,.. but in the signatures,.. only the revocation key subpacket > uses it, right? > The signatures (even the certification sigs) are made directly on the > key (and additional data like the UID), right? > So as far as I understand,.. I should actually gain some security, at > least from the point that an attacker could no longer concentrate on > attacking my SHA1 sigs. > If he want's to do a downgrade attack (recreate an new SHA1 selfsig) he > would have to attack the signature algorithm itself (e.g. RSA) ... or > kick me until I gave him my private key ;) No, if he wants to do a downgrade attack, he can just strip off your revocation packet and the new selfsig packet and use the old selfsig. Revoking it doesn't make it vanish. > > These are > > not changeable, so even if you purge SHA1 from your key, note that > > you're still using SHA1. > btw: When is this going to be changed? i.e. the fingerprint algorithm? Most likely not until we tackle V5 keys. Current keys are V4. > > Also, SHA512 is not widely implemented yet. > > You can very easily render your key not usable by a large percentage > > of the population if you pick a hash they don't have. > Yeah,... I know this,... unfortunately (at least from my point of view) > gpg and this list, seems to be very conservative it such issues :-/ > (don't want to offend you ;) ) I'm not insulted. Being conservative with crypto is a compliment. > > > 3) On an existing key,.. how can I change the key usage flags with gpg? > > Modify the source. > Ok, if I modify it,.. and create a 0x1F with key usage, key > server-prefs, algorithm prefs, and so on... Will gpg understand this? No. > Last but not least,.. I've already browsed through the source code... > could you please point me at the functions where I can put together the > bits for a (signature) packet (the type of the sig, date, hashed > subpacktes, and so on),... and the function that creates the actual > signature (MPI and so on) on this data and the (in case of an 0x1F) on > the key and UID? See sign.c:make_keysig_packet(), and the functions that it calls internally. David From dshaw at jabberwocky.com Wed Apr 16 00:29:44 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 15 Apr 2008 18:29:44 -0400 Subject: Miscellaneous questions In-Reply-To: <48040832.1000909@sixdemonbag.org> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <48040832.1000909@sixdemonbag.org> Message-ID: <20080415222944.GO56745@jabberwocky.com> On Mon, Apr 14, 2008 at 08:43:14PM -0500, Robert J. Hansen wrote: > Herbert Furting wrote: > > gpg is probably THE main implementation of OpenPGP (sorry to the > > commercial PGP folks ;) ),... as such I think it should support most > > of the stuff from OpenPGP, or not? > > Depends on who you ask. A few people on-list (myself being one of them) > think GnuPG supports too much of OpenPGP. This is a very real issue. The problem is that GPG tries to support a very wide swath of users. Some want lots of ciphers, some don't care. Some want photo IDs, some don't care. Different keyserver types, different trust models, etc, etc. Then there is the third group of people, who not only don't want feature X, they don't even want it in the binary. We can't make all three groups happy with one program. At best, we can do the first two. There is an - admittedly limited - attempt at making the third group happy built in to the code, however. If you build GPG from source, you can tell autoconf to simply leave out chunks of code you don't want. For example, you can do "--disable-XXXXX" where XXXXX can be things like "AES" or "RSA", or even things like keyservers. Do a "./configure --help" for the complete list. See also "./configure --enable-minimal" which turns off (almost) everything that isn't required for OpenPGP compliance. The end result is a GPG that understands only DSA, Elgamal, 3DES, MD5, SHA1, RIPEMD160, ZIP and ZLIB. No keyserver support and no photo ID support. David From dshaw at jabberwocky.com Wed Apr 16 00:38:12 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 15 Apr 2008 18:38:12 -0400 Subject: Miscellaneous questions In-Reply-To: <4804B041.8030203@sixdemonbag.org> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <48040832.1000909@sixdemonbag.org> <1b369b200804150424y7a083f3ax8ac91c4d24e1024@mail.gmail.com> <4804A78E.9050806@sixdemonbag.org> <1b369b200804150621i1d30774cj3338c60f1e732dfe@mail.gmail.com> <4804B041.8030203@sixdemonbag.org> Message-ID: <20080415223812.GP56745@jabberwocky.com> On Tue, Apr 15, 2008 at 08:40:17AM -0500, Robert J. Hansen wrote: >> Why? Just because new (perhaps incompatible) features are added in >> newer versions,... nobody has to use that newer versions, right? > > If you put GnuPG 3.0 available for download, everyone who's looking for the > latest release will grab it. The people who are quite happy with 1.2, 1.4 > or 2.0 won't. > > Now imagine that 3.0 breaks backwards compatibility. > > Anarchy ensues. A lot of your users can't talk to each other. Most of > them don't know why. "I'm using GnuPG 3.0, I don't know why it can't talk > to PGP 5.0, I mean, GnuPG 2.0 could...!" > > Ensuring a migration path is so critically important in software > engineering. Breaking backwards compatibility is seen as an extreme step. It is frequently commented on, and not just in a tongue in cheek manner, that it is a shame that the earlier versions of PGP weren't broken. If the old stuff had been broken, we would have no reason to maintain compatibility with it. David From christoph.anton.mitterer at physik.uni-muenchen.de Wed Apr 16 01:19:17 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Wed, 16 Apr 2008 01:19:17 +0200 Subject: Miscellaneous questions In-Reply-To: <20080415215415.GM56745@jabberwocky.com> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <20080415215415.GM56745@jabberwocky.com> Message-ID: <1208301557.11857.45.camel@fermat.scientia.net> Dear David. On Tue, 2008-04-15 at 17:54 -0400, David Shaw wrote: > > > A specification does not set a high-water mark for implementations. It > > > sets a low-water mark. Implementations are free to restrict keys in any > > > way they want, so long as the low-water mark is met. If you want to > > > write an RFC2440 implementation that supports only DSA, SHA-1 and 3DES, > > > nobody will stop you. You're meeting the low-water mark. > > Of course. But I didn't talk about this at all? Did you read my > > arguments? I probably didn't explain it correctly (*not a native English > > speaker*): > > Preferred * Algorithm => Tells what the user prefers (and not what his > > implementation support. > Not exactly. It contains what the user prefers **among the algorithms > that his implementation supports**. It's the intersection of the > algorithms the user prefers for one reason or another and the > algorithms that his implementation supports. I first must admit that it was my idea,... to use the preference subpackets that way (I mean that they should only represent the preference of the user). But I also agree that this is not really implied by the standards (I'll suggest the WG to consider a change of this), but on the other hand: >5.2.3.7. Preferred Symmetric Algorithms > > > (array of one-octet values) > > Symmetric algorithm numbers that indicate which algorithms the key > holder prefers to use. That would support my idea that it's only the user preference. > The subpacket body is an ordered list of > octets with the most preferred listed first. It is assumed that only > algorithms listed are supported by the recipient's software. That just says that no algorithms are listed which the implementation does _not_ support. While this is a good decision for the average user, it should not be forbidden to list an algorithm, even if not supported by one's own implementation. But it does not say that it has to contain the must-have algos. Thus I think that my idea of the meaning of those packets is not only possible, but (because of "Symmetric algorithm numbers that indicate which algorithms the key holder prefers to use.") even logical. > Algorithm numbers are in Section 9. This is only found on a self- > signature. But of course there are the notes at the end which (in my opinion) lead to the current usage of those subpacktes: >Since TripleDES is the MUST-implement algorithm, if it is not >explicitly in the list, it is tacitly at the end. However, it is >good form to place it there explicitly. Note also that if an >implementation does not implement the preference, then it is >implicitly a TripleDES-only implementation. I think this passage is very strongly influenced from a developers view: ?Tacitly (implicit) at the _end_ simply says,... by putting 3DES at the end we automatically have a fallback if no other algorithm is found, without the need of any code. What it all comes down to is, I agree with you that this section is a hint for your cited use ("It contains what the user prefers **among the algorithms that his implementation supports**."), but I still think that my idea would be a cleaner approach as it separates different things. I'll suggest this to the WG. Even if those subpacktes would be used in my suggested way, each implementation would know "Nanana, 3DES is a fallback, so in each case I can find my algorithm match", but in addition to that a user could force his implementation (via a non conforming switch) to ignore that fallback stuff, and just look at the preference. If he'll have problems with this (interoperability) it's his own problem. And of course each implementation should (at least for the average user) allow only to add algos that it supports (or at least make some heave noise if the users decides to add unsupported algos). What do you think? > > However,.. all of this does not answer my original question,.. whether > > it works and makes sense (from a security and not interoperability point > > of view) do revoke the old SHA1 selfsigs and create new (e.g.) SHA512, > > if it works with _current_ versions of gpg, if it's possible at all, and > > which revocation reason one should use. > It will work. It's foolish and you'll hurt yourself doing it, but it > will work. While I don't want to disturb Herbert's questions I'm interested in this, too: Of course such a key might not work with some not conforming implementations and is perhaps fools from that perspective. As far as I understand, when the implementation fully conforms to the RFC this MUST work. But I'd like to know it this leads to improved security or not: If I understood it correctly all the selfsigs go directly over the keymaterial (+UID or subkey material or so), right? As far as I understood, e.g. SHA512 are considered to be better than SHA1 (meaning it's not "so easy" to find collisions), right? So it should be more difficult to attack an SHA512 selfsig than and SHA1 selfsig? One might argue that an attacker could still try a downgrade attack but then he'd have to hack the signature algorithm itself (e.g. RSA) which is the same for SHA1/RIPEMD160/SHA512/etc sigs. So the danger of a downgrade attack is equal for all of them, right? But if we hope that nobody is able to efficiently hack RSA, then selfsigs with "better" hash function should be more secure against attacks, or did (and if so what) I understand this wrong? btw: I assume that this is the reason why Herbert would like to revoke his SHA1 selfsigs, because as long as they're valid,.. the whole idea brings of course nothing. > > But I think that actually it _is_ better to make a global (key wide) > > setting first (on a 0x1F) and just modify UIDs that really need > other > > settings. This is common sense in the world of computing, like you > > have /etc/vim/vimrc with global settings first,.. and only create a > > ~/.vimrc if you relly need to do so. > This is another thing that GPG will accept from the outside, but not > generate itself. Ah nice to know,.. the WG list will probably the right place to discuss if some of the subpacktes should be allowed only on some types of subpacktes. So I hope to see you there (in a few days or a week or so ;) ). > > Which one is chosen now? But when I only include AES256 I can at least > > somewhat control it. > No, you can't. If you only include AES256, your preference list is > effectively "AES256, 3DES". You can't get rid of the 3DES. Ok in fact this belongs also to the WG,.. but (apart from the fact that I'm really unsure if I like the idea of must have algos at all - in each case they have some very practical use) it would be an idea, to change them or at least add some other must haves. As Robert already pointed out,.. one big advantage of AES is its speed. So i assume that a lot of especially embedded devices will only support AES,.. so this might become the de facto standard (or it even is it already). Thanks in advance for your insight :-) -- Dipl.-Inf. (FH) Christoph Anton Mitterer eMail: christoph.anton.mitterer at physik.uni-muenchen.de mail at christoph.anton.mitterer.name Jabber/XMPP: chat at christoph.anton.mitterer.name Ludwig-Maximilians-Universit?t M?nchen Lehrstuhl f?r experimentelle Physik ? Elementarteilchenphysik Sektion Physik Am Coulombwall 1 85748 Garching bei M?nchen Germany From christoph.anton.mitterer at physik.uni-muenchen.de Wed Apr 16 01:31:41 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Wed, 16 Apr 2008 01:31:41 +0200 Subject: Miscellaneous questions In-Reply-To: <20080415220415.GN56745@jabberwocky.com> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <20080414174129.GE54766@jabberwocky.com> <1208208179.8757.8.camel@fermat.scientia.net> <20080415220415.GN56745@jabberwocky.com> Message-ID: <1208302301.11857.57.camel@fermat.scientia.net> On Tue, 2008-04-15 at 18:04 -0400, David Shaw wrote: > It will work with GPG. I can't speak for other programs, but it's > legal by the spec, so it should work everywhere. > > Mind you, you're going to hurt yourself, but it's legal by the spec. Ok this I've already asked everything in my previous mail :-) > > > Mind you, while GPG can do it, I don't think what you are doing is a > > > good idea: OpenPGP itself uses SHA1 in a number of places. > > I know,.. but in the signatures,.. only the revocation key subpacket > > uses it, right? > > The signatures (even the certification sigs) are made directly on the > > key (and additional data like the UID), right? > > So as far as I understand,.. I should actually gain some security, at > > least from the point that an attacker could no longer concentrate on > > attacking my SHA1 sigs. > > If he want's to do a downgrade attack (recreate an new SHA1 selfsig) he > > would have to attack the signature algorithm itself (e.g. RSA) ... or > > kick me until I gave him my private key ;) > No, if he wants to do a downgrade attack, he can just strip off your > revocation packet and the new selfsig packet and use the old selfsig. > Revoking it doesn't make it vanish. Ah yes,.. BUT *G*,.. therefore we have keyservers, right? The place where we not only distribute keys but also revocations on them. If you now say everybody can always simply strip off (of course he can but each user can get them again from the keyservers) any revocations the whole idea of revocation would be non-sense (does this word exist in English). > > > These are > > > not changeable, so even if you purge SHA1 from your key, note that > > > you're still using SHA1. > > btw: When is this going to be changed? i.e. the fingerprint algorithm? > Most likely not until we tackle V5 keys. Current keys are V4. *G* I hope you won't finish V5 keys until I've finished my review/suggestions paper,... and convinced you with lot of ideas X-D Perhaps the most important ideas about fingerprints in advance: We should try to ban the use of fingerprints inside of as many packets as possible when it goes about certifying keys (I think currently this is only the revocation key subpacket, and the MDC packet). They should only be used by the user, so that he doesn't have to compare the whole key bit by bit. > > > Also, SHA512 is not widely implemented yet. > > > You can very easily render your key not usable by a large percentage > > > of the population if you pick a hash they don't have. > > Yeah,... I know this,... unfortunately (at least from my point of view) > > gpg and this list, seems to be very conservative it such issues :-/ > > (don't want to offend you ;) ) > I'm not insulted. Being conservative with crypto is a compliment. Such discussions are always difficult,... it's good if everybody keeps in mind that (normally) nobody means any harm :-) > > > > 3) On an existing key,.. how can I change the key usage flags with gpg? > > > Modify the source. > > Ok, if I modify it,.. and create a 0x1F with key usage, key > > server-prefs, algorithm prefs, and so on... Will gpg understand this? > No. Ah... is this by intention? Or just not yet implemented? To say it differently,.. which subpacktes or understood on the 0x1F signatures? Best wishes,... should go to bed now, -- Dipl.-Inf. (FH) Christoph Anton Mitterer eMail: christoph.anton.mitterer at physik.uni-muenchen.de mail at christoph.anton.mitterer.name Jabber/XMPP: chat at christoph.anton.mitterer.name Ludwig-Maximilians-Universit?t M?nchen Lehrstuhl f?r experimentelle Physik ? Elementarteilchenphysik Sektion Physik Am Coulombwall 1 85748 Garching bei M?nchen Germany btw: If you should ever be in a room full of particle physicians (and you are the only computer scientist),.. (who are looking for the Higgs-particle),... don't, I repeat don't do any jokes like "I found the Higgs-Boson,... it was in my bag. Extremely Dangerous. ^^ From rjh at sixdemonbag.org Wed Apr 16 03:35:46 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 15 Apr 2008 20:35:46 -0500 Subject: Miscellaneous questions In-Reply-To: <1208301557.11857.45.camel@fermat.scientia.net> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <20080415215415.GM56745@jabberwocky.com> <1208301557.11857.45.camel@fermat.scientia.net> Message-ID: <480557F2.6000900@sixdemonbag.org> Christoph Anton Mitterer wrote: > But it does not say that it has to contain the must-have algos. As has been mentioned here at least twice now, see section 13.2, where it explicitly says if the MUSTs are not listed, they are tacitly listed. I do not understand how much clearer I can make this. By the plain black-letter of RFC4880, the MUST algorithms are always present. Always. If you want this to change, take it to the WG. > I think this passage is very strongly influenced from a developers view: > ?Tacitly (implicit) at the _end_ simply says,... by putting 3DES at the > end we automatically have a fallback if no other algorithm is found, > without the need of any code. It's unwise to ascribe semantic meaning to a syntactic specification. The specification says what it says: nothing more, nothing less. > Even if those subpacktes would be used in my suggested way, each > implementation would know "Nanana, 3DES is a fallback, so in each case I > can find my algorithm match", but in addition to that a user could force > his implementation (via a non conforming switch) to ignore that fallback > stuff, and just look at the preference. If he'll have problems with this > (interoperability) it's his own problem. Arguing "GnuPG should support a nonconformant extension to the spec" is probably not going to get much of anywhere. > But I'd like to know it this leads to improved security or not: Define "security" first. From JPClizbe at tx.rr.com Wed Apr 16 07:11:40 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Wed, 16 Apr 2008 00:11:40 -0500 Subject: Need Help In-Reply-To: <1208282603.6337.12.camel@carbon> References: <11203.75197.qm@web94103.mail.in2.yahoo.com> <4804D1E0.4050508@tx.rr.com> <1208282603.6337.12.camel@carbon> Message-ID: <48058A8C.7050308@tx.rr.com> Sven Radde wrote: > Am Dienstag, den 15.04.2008, 11:03 -0500 schrieb John Clizbe: >> There is nothing to backport. David Shaw answered this exact same post last >> Friday on both GnuPG-Users and GnuPG-Devel. > > I felt already last Friday that this was only a partial answer to the > question. > Although it might not be necessary to backport 1.4.9's changes to 1.4.7, > nobody can guarantee that there won't be a 1.4.10 that fixes a > vulnerability which exists since 1.4.7. > It might be worth to solve the issue of possible backports now, when - > as you rightly state - there is no need for immediate action. Excellent! So we'll look to you to be submitting patch sets then? -- John P. Clizbe Inet: JPClizbe (a) tx DAWT rr DAHT con Ginger Bear Networks hkp://keyserver.gingerbear.net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 654 bytes Desc: OpenPGP digital signature URL: From email at sven-radde.de Wed Apr 16 08:13:37 2008 From: email at sven-radde.de (Sven Radde) Date: Wed, 16 Apr 2008 08:13:37 +0200 Subject: Miscellaneous questions In-Reply-To: <480557F2.6000900@sixdemonbag.org> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <20080415215415.GM56745@jabberwocky.com> <1208301557.11857.45.camel@fermat.scientia.net> <480557F2.6000900@sixdemonbag.org> Message-ID: <1208326417.6330.29.camel@carbon> Hi! Am Dienstag, den 15.04.2008, 20:35 -0500 schrieb Robert J. Hansen: > > Even if those subpacktes would be used in my suggested way, each > > implementation would know "Nanana, 3DES is a fallback, so in each case I > > can find my algorithm match", but in addition to that a user could force > > his implementation (via a non conforming switch) to ignore that fallback > > stuff, and just look at the preference. If he'll have problems with this > > (interoperability) it's his own problem. > > Arguing "GnuPG should support a nonconformant extension to the spec" is > probably not going to get much of anywhere. In a way, those switches are already there, look at "--cipher-algo name", "--digest-algo name" and "--compress-algo name" vs. the "--personal-...-preferences" parameters. These ignore the preference flags altogether. cu, Sven From wk at gnupg.org Wed Apr 16 09:42:05 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 Apr 2008 09:42:05 +0200 Subject: How trust works in gpg... In-Reply-To: <20080415180426.GF56745@jabberwocky.com> (David Shaw's message of "Tue, 15 Apr 2008 14:04:26 -0400") References: <200804142205.59132.prlewis@letterboxes.org> <1208209846.9323.1.camel@fermat.scientia.net> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <20080415102143.GC2774@kol06wsthv-it22.kaufhof.net> <20080415180426.GF56745@jabberwocky.com> Message-ID: <87ve2igsaa.fsf@wheatstone.g10code.de> On Tue, 15 Apr 2008 20:04, dshaw at jabberwocky.com said: >> I remember Werner saying that this was just nonsense. >> Werner, can you correct me if I'm wrong? > > Not enough information above to say nonsense or not. There are silly > ways to use challenges and non-silly ways. What I meant are proofs based on the ability to decrypt a message. That is not going to work if you do not have an encryption subkey. Regarding signing challenges; they are fine as along as a signing subkey is available. Like me, some folks keep their primary key offline and may even use a dedicated box for signing keys. The challenges are thus somewhat cumbersome. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From johannes_graumann at web.de Wed Apr 16 10:00:11 2008 From: johannes_graumann at web.de (Johannes Graumann) Date: Wed, 16 Apr 2008 10:00:11 +0200 Subject: Kontact Singature Validation Issue Message-ID: Hi all, I have an issue with mail signatures in my mail setup and want to ask whether anybody has experienced something similar and/or where to look for a solution. I standardly MIME-sign my mail using kontact, the kde PIM. Everything works fine and the sent mails in the "sent mail" folder validate just fine. However, mail I send to myself - no matter through which of a number of smtp servers at my disposal - fail the signature test after arrival. Might be one element of my overly-elaborate mail collection scheme is to blame? It looks like so: 1. A number of mail accounts all forewarding to a gmail account 2. fetchmail imap-pulling the messages from the gmail account and inserting it into a local kolab installation 3. kontact imap-retrieves the mail from kolab. Any insight into this is highly appreciated! Cheers, Joh From christoph.anton.mitterer at physik.uni-muenchen.de Wed Apr 16 10:46:08 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Wed, 16 Apr 2008 10:46:08 +0200 Subject: Miscellaneous questions In-Reply-To: <480557F2.6000900@sixdemonbag.org> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <20080415215415.GM56745@jabberwocky.com> <1208301557.11857.45.camel@fermat.scientia.net> <480557F2.6000900@sixdemonbag.org> Message-ID: <1208335568.29504.18.camel@etppc19> Dear Robert. On Tue, 2008-04-15 at 20:35 -0500, Robert J. Hansen wrote: > Christoph Anton Mitterer wrote: > > But it does not say that it has to contain the must-have algos. > As has been mentioned here at least twice now, see section 13.2, where > it explicitly says if the MUSTs are not listed, they are tacitly listed. > I do not understand how much clearer I can make this. By the plain > black-letter of RFC4880, the MUST algorithms are always present. > Always. I'm not sure if the meaning of tacitly is something different in English as its translation in German, but as my dictionary lists implicit as synonym it is probably not. So while I actually couldn't care about, why is it wrong why I say the binary representation doesn't have to contain it, but it is automatically added internally? However I became bored of this... either read again what I've posted (that big section where I tried to describe what I consider to be improvable in the RFC) understand it or not, I don't care. > If you want this to change, take it to the WG. I think I've actually said this at least one time, didn't I? > > I think this passage is very strongly influenced from a developers view: > > ?Tacitly (implicit) at the _end_ simply says,... by putting 3DES at the > > end we automatically have a fallback if no other algorithm is found, > > without the need of any code. > It's unwise to ascribe semantic meaning to a syntactic specification. > The specification says what it says: nothing more, nothing less. Yeah,.. that part was about how I could think that current handling of that stuff came into existence. It was not a "That's what the standard says" it was a "I think that's the original reason". It was just a step to justify my proposed changed. > Arguing "GnuPG should support a nonconformant extension to the spec" is > probably not going to get much of anywhere. > > But I'd like to know it this leads to improved security or not: Specs are moving,... and implementations do so, too. And as others have already pointed out, there are several places where gpg is non-conformant (or at least doesn't care about some SHOULDs), e.g. it allows you to export non-exportable signatures. And if you argue that way "GnuPG should support a nonconformant extension to the spec", you should also condemn reasonable things like GnuPG's default minimum size of UIDs. We all agree that this makes definitely sense, but it is as if gpg would add it's own rule to OpenPGP saying, "UIDs should be longer than 5 characters". While this is not forbidden, it is _like_ an addition to the standard. Imagine I'd say "Oh lets add zz to the ISO 3166 list because it might be reasonable" (btw: I think that it's good that gpg allows this) Best wishes, -- Dipl.-Inf. (FH) Christoph Anton Mitterer eMail: christoph.anton.mitterer at physik.uni-muenchen.de mail at christoph.anton.mitterer.name Jabber/XMPP: chat at christoph.anton.mitterer.name Ludwig-Maximilians-Universit?t M?nchen Lehrstuhl f?r experimentelle Physik ? Elementarteilchenphysik Sektion Physik Am Coulombwall 1 85748 Garching bei M?nchen Germany From christoph.anton.mitterer at physik.uni-muenchen.de Wed Apr 16 10:57:38 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Wed, 16 Apr 2008 10:57:38 +0200 Subject: How trust works in gpg... In-Reply-To: <87ve2igsaa.fsf@wheatstone.g10code.de> References: <200804142205.59132.prlewis@letterboxes.org> <1208209846.9323.1.camel@fermat.scientia.net> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <20080415102143.GC2774@kol06wsthv-it22.kaufhof.net> <20080415180426.GF56745@jabberwocky.com> <87ve2igsaa.fsf@wheatstone.g10code.de> Message-ID: <1208336258.29504.29.camel@etppc19> Dear Werner. On Wed, 2008-04-16 at 09:42 +0200, Werner Koch wrote: > What I meant are proofs based on the ability to decrypt a message. That > is not going to work if you do not have an encryption subkey. Could you please find the time to explain this further? Why would it only work with an encryption subkey (or didn't you want to exclude encryption primary keys - I know they're not supposed to be used for encryption)? > Regarding signing challenges; they are fine as along as a signing subkey > is available. This sounds interesting. What would I now from a signing challenge? What is it exactly? Ask the peer to sign my challenge? Any why wouldn't it work with the primary (signing) key. > Like me, some folks keep their primary key offline and > may even use a dedicated box for signing keys. The challenges are thus > somewhat cumbersome. I do the same. Just out of curiosity, would you suggest that those certification-only primary-keys use just the "C" flag (I forgot the hex-code) for the key usage, to explicitly denotes "this key is only used for certification"? I've already thought about this, but you might such a certification-only primary not only to sign OpenPGP keys, but e.g. to "certify" (in a human readable form" your own X.509 (root) certificate, or perhaps symmetric shared secrets, or OTR keys for the Pidgin IM. If that makes sense, it would depend on whether the RFC means with the C flag a general certification use (not only OpenPGP keys/UIDs) or only certification of OpenPGP keys/UIDs. In the later case one should probably stick with "CS" What do you think? Greetings, -- Dipl.-Inf. (FH) Christoph Anton Mitterer eMail: christoph.anton.mitterer at physik.uni-muenchen.de mail at christoph.anton.mitterer.name Jabber/XMPP: chat at christoph.anton.mitterer.name Ludwig-Maximilians-Universit?t M?nchen Lehrstuhl f?r experimentelle Physik ? Elementarteilchenphysik Sektion Physik Am Coulombwall 1 85748 Garching bei M?nchen Germany From dshaw at jabberwocky.com Wed Apr 16 14:41:15 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 16 Apr 2008 08:41:15 -0400 Subject: Miscellaneous questions In-Reply-To: <1208335568.29504.18.camel@etppc19> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <20080415215415.GM56745@jabberwocky.com> <1208301557.11857.45.camel@fermat.scientia.net> <480557F2.6000900@sixdemonbag.org> <1208335568.29504.18.camel@etppc19> Message-ID: <20080416124115.GA71474@jabberwocky.com> On Wed, Apr 16, 2008 at 10:46:08AM +0200, Christoph Anton Mitterer wrote: > > Arguing "GnuPG should support a nonconformant extension to the spec" is > > probably not going to get much of anywhere. > > > But I'd like to know it this leads to improved security or not: > Specs are moving,... and implementations do so, too. And as others have > already pointed out, there are several places where gpg is > non-conformant (or at least doesn't care about some SHOULDs), e.g. it > allows you to export non-exportable signatures. I was pretty much getting out of this thread as non-useful, but I have to comment on this. It's not true. GPG does not export non-exportable signatures. You can choose to configure GPG to do so, but this is not default behavior, and does not enable you to do anything you couldn't do by just copying the keyring around. David From christoph.anton.mitterer at physik.uni-muenchen.de Wed Apr 16 15:04:28 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Wed, 16 Apr 2008 15:04:28 +0200 Subject: Miscellaneous questions In-Reply-To: <20080416124115.GA71474@jabberwocky.com> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <20080415215415.GM56745@jabberwocky.com> <1208301557.11857.45.camel@fermat.scientia.net> <480557F2.6000900@sixdemonbag.org> <1208335568.29504.18.camel@etppc19> <20080416124115.GA71474@jabberwocky.com> Message-ID: <1208351068.29504.56.camel@etppc19> On Wed, 2008-04-16 at 08:41 -0400, David Shaw wrote: > I was pretty much getting out of this thread as non-useful, but I have > to comment on this. It's not true. GPG does not export > non-exportable signatures. Hmm I wonder if it's worth the effort to publish a review on the RFC, would ideas be rejected simply because they change the current way or sight on things. What do you think? > You can choose to configure GPG to do so, but this is not default > behavior, and does not enable you to do anything you couldn't do by > just copying the keyring around. Well,.. I didn't claim that it would do it by default ;) Regards, -- Dipl.-Inf. (FH) Christoph Anton Mitterer eMail: christoph.anton.mitterer at physik.uni-muenchen.de mail at christoph.anton.mitterer.name Jabber/XMPP: chat at christoph.anton.mitterer.name Ludwig-Maximilians-Universit?t M?nchen Lehrstuhl f?r experimentelle Physik ? Elementarteilchenphysik Sektion Physik Am Coulombwall 1 85748 Garching bei M?nchen Germany From mkallas at schokokeks.org Wed Apr 16 14:18:55 2008 From: mkallas at schokokeks.org (Michael Kesper) Date: Wed, 16 Apr 2008 14:18:55 +0200 Subject: Need Help In-Reply-To: <11203.75197.qm@web94103.mail.in2.yahoo.com> References: <11203.75197.qm@web94103.mail.in2.yahoo.com> Message-ID: <20080416121855.GC2847@kol06wsthv-it22.kaufhof.net> Hi, On Tue, Apr 15, 2008 at 12:06:44PM +0100, Debabrata Das wrote: > Hi All, > > Currently we are using GnuPG 1.4.7 which is under GPL V2 on HP-UX > ,but we came to know that there is a security vulnerability on GnuPG > 1.4.8 & earlier version.Since Gnupg 1.4.9 is under GPL V3 & we don't > want to move to product under GPL v3. I suppose that GnuPG did not move just for fun to GPLv3 but for a reason. So if you can't comply with GNU GPL v3, better be prepared to switch. Best wishes Michael -- Free Software Foundation Europe (FSFE) [] (http://fsfeurope.org) Join the Fellowship of FSFE! [][][] (http://fsfe.org/join) Your donation powers our work! [] (http://fsfeurope.org/donate) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature URL: From dshaw at jabberwocky.com Wed Apr 16 15:29:34 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 16 Apr 2008 09:29:34 -0400 Subject: Miscellaneous questions In-Reply-To: <1208351068.29504.56.camel@etppc19> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <20080415215415.GM56745@jabberwocky.com> <1208301557.11857.45.camel@fermat.scientia.net> <480557F2.6000900@sixdemonbag.org> <1208335568.29504.18.camel@etppc19> <20080416124115.GA71474@jabberwocky.com> <1208351068.29504.56.camel@etppc19> Message-ID: On Apr 16, 2008, at 9:04 AM, Christoph Anton Mitterer wrote: > On Wed, 2008-04-16 at 08:41 -0400, David Shaw wrote: >> I was pretty much getting out of this thread as non-useful, but I >> have >> to comment on this. It's not true. GPG does not export >> non-exportable signatures. > Hmm I wonder if it's worth the effort to publish a review on the RFC, > would ideas be rejected simply because they change the current way or > sight on things. > What do you think? I think - and please understand I do not mean this as an attack on you - that before someone proposes sweeping changes to an RFC, they must really understand the history and reasoning behind the original design. Without that understanding, the proposed changes tend to become "I don't like this - please change it", without actual understanding. I contributed a lot of work to 4880, over the span of years. I found that the more I learned, the smaller the change I proposed was. Skipping the actual security issue for a moment and just looking at code realities, OpenPGP and its ancestors have been around for so long, and there is such a huge base of installed code, that this is pretty much the only way to work with it. It's not a blank sheet of paper where anything goes. This is why V5 keys are so appealing - it's not exactly a blank sheet of paper, but it's as close as we've had for a very long time. I don't want to discourage you from suggesting changes, but I do advise that you really understand what you are suggesting. For example, the ideas around user IDs being required to be full names show misunderstanding of the OpenPGP trust model. The ideas around different parts of the user ID living in different packets (attribute packets vs user ID packets) would break a large percentage of existing systems. This is fine, of course, if that breakage is balanced out by a corresponding gain in the rest of the system, but I don't see that corresponding gain. Work with a scalpel, not a cutlass. David From jbmaz at cox.net Wed Apr 16 15:57:52 2008 From: jbmaz at cox.net (Brad Morrow) Date: Wed, 16 Apr 2008 06:57:52 -0700 Subject: Problem with Windows binaries Message-ID: I am a new GPG user. I have looked everywhere (manuals, bug site, mailing lists, Google search, etc.) for information on this error, but have been unsuccessful. My guess is that there is a simple solution to such a basic error right out of the chute, but I need some help finding that answer. Could someone please help me learn how to navigate through this? I downloaded the GPG4Win binaries (gpg4win-1.1.3.exe). I have installed everything in the package including GnuPG2 and Claws-Mail on three of my computers and have not encountered any issues. Unfortunately, however, I am having a show stopper on the one computer that needs to have this up and running the most. After installation I get an error when I try to create the first key pair using WinPT, GPA or the gpg command line. It does not seem to matter what options I use during the gpg -gen-key process. They all error out in the same fashion: "Unhandled exception at 0x0210342a in gpg.exe: 0xC0000005: Access violation reading location 0x0210342a." When using GPA it follows with the following error: "The GPGME library returned an unexpected error. The error was: General error This is probably a bug in GPA. GPA will now try to recover from this error." Here is some basic system configuration information on the machine that is not working: System Information report written at: 04/16/08 06:43:13 [System Summary] Item Value OS Name Microsoft Windows XP Professional Version 5.1.2600 Service Pack 2 Build 2600 OS Manufacturer Microsoft Corporation System Manufacturer ASUS System Model Canterwood+ICH5 System Type X86-based PC Processor x86 Family 15 Model 2 Stepping 5 GenuineIntel ~2405 Mhz Processor x86 Family 15 Model 2 Stepping 5 GenuineIntel ~2405 Mhz Processor x86 Family 15 Model 2 Stepping 5 GenuineIntel ~2405 Mhz Processor x86 Family 15 Model 2 Stepping 5 GenuineIntel ~2405 Mhz BIOS Version/Date Phoenix Technologies, LTD ASUS PC-DL ACPI BIOS Revision 1008, 11/15/2004 SMBIOS Version 2.3 Windows Directory C:\WINDOWS System Directory C:\WINDOWS\system32 Boot Device \Device\HarddiskVolume9 Locale United States Hardware Abstraction Layer Version = "5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)" Total Physical Memory 2,048.00 MB Total Virtual Memory 2.00 GB Page File Space 3.85 GB Page File C:\pagefile.sys -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.anton.mitterer at physik.uni-muenchen.de Wed Apr 16 17:20:25 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Wed, 16 Apr 2008 17:20:25 +0200 Subject: Miscellaneous questions In-Reply-To: References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <20080415215415.GM56745@jabberwocky.com> <1208301557.11857.45.camel@fermat.scientia.net> <480557F2.6000900@sixdemonbag.org> <1208335568.29504.18.camel@etppc19> <20080416124115.GA71474@jabberwocky.com> <1208351068.29504.56.camel@etppc19> Message-ID: <1208359225.29504.82.camel@etppc19> Dear David. On Wed, 2008-04-16 at 09:29 -0400, David Shaw wrote: > I think - and please understand I do not mean this as an attack on you Of course not :) > - that before someone proposes sweeping changes to an RFC, they must > really understand the history and reasoning behind the original > design. Without that understanding, the proposed changes tend to > become "I don't like this - please change it", without actual > understanding. > > I contributed a lot of work to 4880, over the span of years. I found > that the more I learned, the smaller the change I proposed was. Yes you're absolutely right, but I think sometimes one have to make changes even at the cost of backward compatibility. Some of the changes I'd like to propose to the WG won't probably break the binary format of the standard at all, and some of my semantic changes won't even really hurt if an older implementation won't apply those changes. But I also have some drastic changes that would really break the current way, and that is... > Skipping the actual security issue for a moment and just looking at > code realities, OpenPGP and its ancestors have been around for so > long, and there is such a huge base of installed code, that this is > pretty much the only way to work with it. It's not a blank sheet of > paper where anything goes. This is why V5 keys are so appealing - > it's not exactly a blank sheet of paper, but it's as close as we've > had for a very long time. ... where V5 keys come into the game. So a lot of my ideas are actually targeted to V5 keys and the "redesign" of OpenPGP that will or at least could come with them. I think that a big redesign would especially important because I feel like OpenPGP would loose more and more ground to X.509, which I consider broken by design due to its hierarchical model. > I don't want to discourage you from suggesting changes, but I do > advise that you really understand what you are suggesting. For > example, the ideas around user IDs being required to be full names > show misunderstanding of the OpenPGP trust model. Hm could you please explain me why? I always thought that completeness is also important correctness? > The ideas around > different parts of the user ID living in different packets (attribute > packets vs user ID packets) would break a large percentage of existing > systems. Yes it would,... it would actually break all existing keys. I was not about coming here and say,.. change all current keys to that model, but I meant, if we ever have to start from scratch or at least nearly from scratch (and I thought that would come with V5 keys), we should reconsider all the historical grown stuff. Perhaps it would even make sense to provide a XML based OpenPGP format,... and a binary mapping just for stuff (embedded systems, streaming) where size matters. If we'd actually made such a big cut, e.g. between V4 and V5 keys, that would not necessary mean that both cannot life side on side. A V4 key could still sign (with little modifications) newer V5 keys, and a V5 key could still sign V4's or even V3's. And over time,... V4's might be phased out, just as currently V3 keys are being phased out. > This is fine, of course, if that breakage is balanced out by > a corresponding gain in the rest of the system, but I don't see that > corresponding gain. Hmm my main intention is probably to get a cleaner, more aesthetic design, but of course this is probably not enough to convince everybody to make such a big cut. But I think there are also several points where we could increase security and tidy things up (e.g. the separation of ID's from attributes, describing a user, such attributes could be his name town, ZIP-code or even his ebay account). And I would like to see a redesigned standard much more stricter and definite. The RFC itself says, that it uses a "wishy-washy" style, I think that could lead to security problems. > Work with a scalpel, not a cutlass. Yes,.. but keep in mind,.. most of my sugesstions are targeted on a real redesign, if it comes to a cut (like due to V5 keys). Honestly, -- Dipl.-Inf. (FH) Christoph Anton Mitterer eMail: christoph.anton.mitterer at physik.uni-muenchen.de mail at christoph.anton.mitterer.name Jabber/XMPP: chat at christoph.anton.mitterer.name Ludwig-Maximilians-Universit?t M?nchen Lehrstuhl f?r experimentelle Physik ? Elementarteilchenphysik Sektion Physik Am Coulombwall 1 85748 Garching bei M?nchen Germany From yaverot at nerdshack.com Wed Apr 16 17:18:46 2008 From: yaverot at nerdshack.com (Matt) Date: Wed, 16 Apr 2008 09:18:46 -0600 Subject: Backport to GPL2 was: Re: Need Help In-Reply-To: <20080416121855.GC2847@kol06wsthv-it22.kaufhof.net> References: <11203.75197.qm@web94103.mail.in2.yahoo.com> <20080416121855.GC2847@kol06wsthv-it22.kaufhof.net> Message-ID: <480618D6.1030609@nerdshack.com> Michael Kesper wrote: > On Tue, Apr 15, 2008 at 12:06:44PM +0100, Debabrata Das wrote: >> > I suppose that GnuPG did not move just for fun to GPLv3 but for a > reason. The reason is that the FSF released a new version of GPL. I understand somewhat why a v3 was needed, and why some would prefer to stay v2. Political solidarity, or "just following party line", are not sufficient justification to //some// people to move to move to a new (and to them possibly inferior) license. If a "stronger" reason was given on this list, then __I__ missed it. The reasons are 'good enough' to me, and I suspect that those who have a say in GnuPG's license would prefer to focus on 'fun coding challenges' than waste their time on a 'dull political fight'. >So if you can't comply with GNU GPL v3, better be prepared to switch. I'm uncertain if Michael means to switch to GPL3 or switch to another OpenPGP implementation that is not GPL (to avoid v3 issues). If Debabrata's organization has ruled out GPLv3, then a page that lists some non-GPL OpenPGPs is: http://www.cypherspace.org/openpgp/ It doesn't reference RFC4880, so if heading that route you might need to hit the second page of a google search. I've probably stuck my foot in my mouth, so I'll stop here before I make it worse. From ml at mareichelt.de Wed Apr 16 17:11:16 2008 From: ml at mareichelt.de (markus reichelt) Date: Wed, 16 Apr 2008 17:11:16 +0200 Subject: FYI: Keysigning at Linuxtag 2008 in Berlin (May 30th) Message-ID: <20080416151116.GB4098@tatooine.rebelbase.local> Hi, for those interested, there's going to be again a keysigning party at Linuxtag 2008 in Berlin (May 30th): http://wiki.linuxtag.net/w/Keysigning_2008 -- left blank, right bald -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mpant at ncsa.uiuc.edu Wed Apr 16 22:37:11 2008 From: mpant at ncsa.uiuc.edu (Meenal Pant) Date: Wed, 16 Apr 2008 15:37:11 -0500 Subject: --gen-revoke in batch Message-ID: <48066377.3040907@ncsa.uiuc.edu> Hello all, Can the "gpg --gen-revoke user" command be executed in batch mode? I am trying to generate revocation certificate for a gpg keypair through a Python script. Thanks Meenal From JPClizbe at tx.rr.com Thu Apr 17 01:49:57 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Wed, 16 Apr 2008 18:49:57 -0500 Subject: --gen-revoke in batch In-Reply-To: <48066377.3040907@ncsa.uiuc.edu> References: <48066377.3040907@ncsa.uiuc.edu> Message-ID: <480690A5.80309@tx.rr.com> Meenal Pant wrote: > Hello all, > Can the "gpg --gen-revoke user" command be executed in batch mode? I am > trying to generate revocation certificate for a gpg keypair through a > Python script. jpclizbe at ICECHEST ~ $ gpg --batch --yes --gen-revoke "Test Key" > foo.asc gpg: can't do this in batch mode jpclizbe at ICECHEST ~ $ It would appear not. Maybe gpgme will do it(?) -- John P. Clizbe Inet: JPClizbe (a) tx DAWT rr DAHT con Golden Bear Networks hkp://keyserver.gingerbear.net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 654 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Apr 17 12:47:20 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Apr 2008 12:47:20 +0200 Subject: FYI: Keysigning at Linuxtag 2008 in Berlin (May 30th) In-Reply-To: <20080416151116.GB4098@tatooine.rebelbase.local> (markus reichelt's message of "Wed, 16 Apr 2008 17:11:16 +0200") References: <20080416151116.GB4098@tatooine.rebelbase.local> Message-ID: <87zlrsdah3.fsf@wheatstone.g10code.de> On Wed, 16 Apr 2008 17:11, ml at mareichelt.de said: > http://wiki.linuxtag.net/w/Keysigning_2008 Please don't use this procedure - it just don't works. Within a group of cryptographers it is a nice protocol but not in the real world. The procedure does not cope with the problem that people don't understand what they have to do, don't have a pencil at hand, they need to juggle with a long list a pencil and several passports. Worst of all there will be quit esome folks who pop up to late and want to get their keys signed too. Rejecting them is not an option and thus you need to resort to the fingerprint slip method anyway. The only pocedure which works is to ask the attendees to print there fingerprint on paper slips in regular typewriter mode. With two user IDs this yields 10 slips per A4 page. At the party you walk along all other attendees, look at the passport etc and receive the paper slip if you accept the identify. For those who don't want to sign all user IDs, they will porbably have a pencil and can cross-out the other user IDs. That procedure is way faster than anything else, easy to explain, scales well and can even handle those arriving too late or not properly prepared. It is also more like a party than that mumbling of numbers without proper use of the ICAO phonetic alphabet. At the last conference we had about 20 sending in their keys, 6 actually attending, about 3 arriving too late and about 5 not having send in their keys but carrying paper slips around. Processing the 5 with the paper slips was faster than those on the list. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Apr 17 13:00:23 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Apr 2008 13:00:23 +0200 Subject: How trust works in gpg... In-Reply-To: <1208336258.29504.29.camel@etppc19> (Christoph Anton Mitterer's message of "Wed, 16 Apr 2008 10:57:38 +0200") References: <200804142205.59132.prlewis@letterboxes.org> <1208209846.9323.1.camel@fermat.scientia.net> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <20080415102143.GC2774@kol06wsthv-it22.kaufhof.net> <20080415180426.GF56745@jabberwocky.com> <87ve2igsaa.fsf@wheatstone.g10code.de> <1208336258.29504.29.camel@etppc19> Message-ID: <87ve2gd9vc.fsf@wheatstone.g10code.de> On Wed, 16 Apr 2008 10:57, christoph.anton.mitterer at physik.uni-muenchen.de said: >> What I meant are proofs based on the ability to decrypt a message. That >> is not going to work if you do not have an encryption subkey. > Could you please find the time to explain this further? Why would it > only work with an encryption subkey (or didn't you want to exclude > encryption primary keys - I know they're not supposed to be used for Those proofs work by sending you an encrypted message with a nonce. You have to decrypt it and send it back so that the sender knows that you have access to the secret key and will then sign your key. If you don't have a key with encryption capability on you key, that can't work. For may years I used a signing only key for certifciation and I can't count the numerous complaints, resulting from that. >> Regarding signing challenges; they are fine as along as a signing subkey >> is available. > This sounds interesting. > What would I now from a signing challenge? What is it exactly? Ask the > peer to sign my challenge? Right. > Any why wouldn't it work with the primary (signing) key. Because in my case that is off line and I would need to implement quite some code to take the signing challenge to the secure offline box with the primary key, sign that the challenge, copy the result back to a networked box and send it. Yeah, it is possible to do but it does not make much sense to me. A signing subkey would be easier. > I do the same. Just out of curiosity, would you suggest that those > certification-only primary-keys use just the "C" flag (I forgot the > hex-code) for the key usage, to explicitly denotes "this key is only > used for certification"? I have no opnion on this. > If that makes sense, it would depend on whether the RFC means with the C > flag a general certification use (not only OpenPGP keys/UIDs) or only > certification of OpenPGP keys/UIDs. That's up to you. OpenPGP does not enforce a strict meaning on everything, so some things are vague on purpose. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Apr 17 14:27:40 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Apr 2008 14:27:40 +0200 Subject: --gen-revoke in batch In-Reply-To: <480690A5.80309@tx.rr.com> (John Clizbe's message of "Wed, 16 Apr 2008 18:49:57 -0500") References: <48066377.3040907@ncsa.uiuc.edu> <480690A5.80309@tx.rr.com> Message-ID: <87hce0d5tv.fsf@wheatstone.g10code.de> On Thu, 17 Apr 2008 01:49, JPClizbe at tx.rr.com said: > Meenal Pant wrote: >> Hello all, >> Can the "gpg --gen-revoke user" command be executed in batch mode? I am >> trying to generate revocation certificate for a gpg keypair through a >> Python script. > > jpclizbe at ICECHEST ~ > $ gpg --batch --yes --gen-revoke "Test Key" > foo.asc > gpg: can't do this in batch mode Right. The only way to do this from scripts is by using: gpg2 --status-fd 2 --command-fd 0 --gen-revoke foo The script needs to parse the status and react on it accordingly. Here is a sample: $ gpg2 --status-fd 2 --command-fd 0 --gen-revoke joe sec 1024D/9CD9FD55 2000-12-14 Joe Random Hacker [GNUPG:] GET_BOOL gen_revoke.okay y [GNUPG:] GOT_IT Please select the reason for the revocation: 0 = No reason specified 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used Q = Cancel (Probably you want to select 1 here) [GNUPG:] GET_LINE ask_revocation_reason.code 0 [GNUPG:] GOT_IT Enter an optional description; end it with an empty line: [GNUPG:] GET_LINE ask_revocation_reason.text Pre-created revocation. [GNUPG:] GOT_IT [GNUPG:] GET_LINE ask_revocation_reason.text [GNUPG:] GOT_IT Reason for revocation: No reason specified Pre-created revocation. [GNUPG:] GET_BOOL ask_revocation_reason.okay y [GNUPG:] GOT_IT NOTE: This key is not protected! ASCII armored output forced. [GNUPG:] GOOD_PASSPHRASE I have not indented the answers sent to stdin on response to the GET_foo lines. The script should parse the tags after the GET_foo to see what has been requested and best use FSM to process this. Unknown tags should be answered with just a LF. Of course you would use the fingerprint of the key and not just the name to invoking the command. As a quick solution for unattended key generation I am going to add a "%revokefile" command to write a simple revocation certificate to the given file after key generation. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Apr 17 14:40:03 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Apr 2008 14:40:03 +0200 Subject: Backport to GPL2 was: Re: Need Help In-Reply-To: <480618D6.1030609@nerdshack.com> (yaverot@nerdshack.com's message of "Wed, 16 Apr 2008 09:18:46 -0600") References: <11203.75197.qm@web94103.mail.in2.yahoo.com> <20080416121855.GC2847@kol06wsthv-it22.kaufhof.net> <480618D6.1030609@nerdshack.com> Message-ID: <87d4ood598.fsf@wheatstone.g10code.de> On Wed, 16 Apr 2008 17:18, yaverot at nerdshack.com said: > Political solidarity, or "just following party line", are not sufficient > justification to //some// people to move to move to a new (and to them > possibly inferior) license. If a "stronger" reason was given on this I can't see what problems a company may have with GnuPG under GPLv3+. It is a standalone application and thus you won't get into license problems like you may get with libraries. There are really good reason to move to GPLv3+. In particular it makes it harder for free-riders to use GnuPG and don't allow any update as required by the GPL. Thus the GPLv3 closes a loophole more and more used on embedded platforms and with appliances. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Apr 17 14:47:27 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Apr 2008 14:47:27 +0200 Subject: Need Help In-Reply-To: <1208282603.6337.12.camel@carbon> (Sven Radde's message of "Tue, 15 Apr 2008 20:03:23 +0200") References: <11203.75197.qm@web94103.mail.in2.yahoo.com> <4804D1E0.4050508@tx.rr.com> <1208282603.6337.12.camel@carbon> Message-ID: <878wzcd4ww.fsf@wheatstone.g10code.de> On Tue, 15 Apr 2008 20:03, email at sven-radde.de said: > Although it might not be necessary to backport 1.4.9's changes to 1.4.7, > nobody can guarantee that there won't be a 1.4.10 that fixes a > vulnerability which exists since 1.4.7. Well as long as we maintain these versions we will provide the fixes in a way that it does not affec the license. In most cases this is a fair-use case. For old versions you are of our own but the GPL allows you to change the code as you like. Note that - in contrast to small bug fixes - backporting large parts of a 1.4.8 etc to 1.4.7 will also copy the GPLv3 and thus effectivly putting the 1.4.7 under the GPLv3. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From rick at ttys0.us Thu Apr 17 17:18:03 2008 From: rick at ttys0.us (rick) Date: Thu, 17 Apr 2008 10:18:03 -0500 (CDT) Subject: editing User ID Message-ID: In setting up a user I managed to fat finger the email address. The pgp documentation shows how to edit the user information using the -ke (key edit) flag, but I am unable to find a similar capability in gpg. I thought that possibly I could remove the user id, then recreate the user with the corrected email address but I was unsure if I could retain the ability to decrypt existing files. Is it possible to edit the user information in pgp? Can someone point me to the applicable documentation for this item? Thanks rick From jh at jameshoward.us Thu Apr 17 18:11:26 2008 From: jh at jameshoward.us (James P. Howard, II) Date: Thu, 17 Apr 2008 12:11:26 -0400 Subject: editing User ID In-Reply-To: References: Message-ID: <20080417161124.GA11777@ivy.phpwebhosting.com> On Thu, Apr 17, 2008 at 10:18:03AM -0500, rick wrote: > In setting up a user I managed to fat finger the email address. > The pgp documentation shows how to edit the user information using the -ke > (key edit) flag, but I am unable to find a similar capability in gpg. I > thought that possibly I could remove the user id, then recreate the user > with the corrected email address but I was unsure if I could retain the > ability to decrypt existing files. > > Is it possible to edit the user information in pgp? Can someone point me > to the applicable documentation for this item? This will not affect your ability to decrypt existing files. If you have published the key to a keyserver, the only options are to revoke the user id and add a new one or revoke the entire key, and generate a new key. However, you will still require the old key to decrypt previously encrypted files. James -- James P. Howard, II jh at jameshoward.us http://jameshoward.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dshaw at jabberwocky.com Thu Apr 17 18:13:30 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 17 Apr 2008 12:13:30 -0400 Subject: editing User ID In-Reply-To: References: Message-ID: <20080417161330.GA1019@jabberwocky.com> On Thu, Apr 17, 2008 at 10:18:03AM -0500, rick wrote: > In setting up a user I managed to fat finger the email address. > The pgp documentation shows how to edit the user information using the -ke > (key edit) flag, but I am unable to find a similar capability in gpg. I > thought that possibly I could remove the user id, then recreate the user > with the corrected email address but I was unsure if I could retain the > ability to decrypt existing files. > > Is it possible to edit the user information in pgp? Can someone point me > to the applicable documentation for this item? You can't really edit user information. The reason is that the information is "bound" to the key with a self-signature - editing the user ID info would cause that signature to become invalid. This is for reasons of self integrity, as you wouldn't want an attacker to be able to edit your user ID information. The way to do what you want is to add a new user ID, with the correct information (gpg --edit-key then "adduid"), then remove the old incorrect UID. There are two ways to remove that: gpg --edit-key then "deluid". If you haven't sent the key to anyone, then this is safe. It deletes the bad user ID completely and that is that. If you have sent the key to anyone (and that includes the keyserver), the best you can do is revoke the user ID, which tags it with a flag to indicate it should not be used: gpg --edit-key then "revuid". David From rick at ttys0.us Thu Apr 17 18:21:37 2008 From: rick at ttys0.us (rick) Date: Thu, 17 Apr 2008 11:21:37 -0500 (CDT) Subject: editing User ID In-Reply-To: <20080417161330.GA1019@jabberwocky.com> References: <20080417161330.GA1019@jabberwocky.com> Message-ID: On Thu, 17 Apr 2008, David Shaw wrote: :Date: Thu, 17 Apr 2008 12:13:30 -0400 :From: David Shaw :To: gnupg-users at gnupg.org :Subject: Re: editing User ID : :On Thu, Apr 17, 2008 at 10:18:03AM -0500, rick wrote: :> In setting up a user I managed to fat finger the email address. :> The pgp documentation shows how to edit the user information using the -ke :> (key edit) flag, but I am unable to find a similar capability in gpg. I :> thought that possibly I could remove the user id, then recreate the user :> with the corrected email address but I was unsure if I could retain the :> ability to decrypt existing files. :> :> Is it possible to edit the user information in pgp? Can someone point me :> to the applicable documentation for this item? : :You can't really edit user information. The reason is that the :information is "bound" to the key with a self-signature - editing the :user ID info would cause that signature to become invalid. This is :for reasons of self integrity, as you wouldn't want an attacker to be :able to edit your user ID information. : :The way to do what you want is to add a new user ID, with the correct :information (gpg --edit-key then "adduid"), then remove the old :incorrect UID. There are two ways to remove that: : : gpg --edit-key then "deluid". : :If you haven't sent the key to anyone, then this is safe. It deletes :the bad user ID completely and that is that. : :If you have sent the key to anyone (and that includes the keyserver), :the best you can do is revoke the user ID, which tags it with a flag :to indicate it should not be used: : : gpg --edit-key then "revuid". Thanks, I did use the --edit-key - revuid then adduid and recreated the user. Everything seems to check out OK. Thanks again rick From mpant at ncsa.uiuc.edu Thu Apr 17 20:28:49 2008 From: mpant at ncsa.uiuc.edu (Meenal Pant) Date: Thu, 17 Apr 2008 13:28:49 -0500 Subject: --gen-revoke in batch In-Reply-To: <87hce0d5tv.fsf@wheatstone.g10code.de> References: <48066377.3040907@ncsa.uiuc.edu> <480690A5.80309@tx.rr.com> <87hce0d5tv.fsf@wheatstone.g10code.de> Message-ID: <480796E1.6020906@ncsa.uiuc.edu> Thanks for the prompt response Werner. I have a few more questions. Werner Koch wrote: > > Right. The only way to do this from scripts is by using: > > gpg2 --status-fd 2 --command-fd 0 --gen-revoke foo > > The script needs to parse the status and react on it accordingly. Here > is a sample: > > $ gpg2 --status-fd 2 --command-fd 0 --gen-revoke joe I guess I can use gpg here ? > > sec 1024D/9CD9FD55 2000-12-14 Joe Random Hacker I can get till here. > > [GNUPG:] GET_BOOL gen_revoke.okay Are these commands generated by GPG ? > y This I see is the user input. This is what I have to capture. > [GNUPG:] GOT_IT > Please select the reason for the revocation: > 0 = No reason specified > 1 = Key has been compromised > 2 = Key is superseded > 3 = Key is no longer used > Q = Cancel > (Probably you want to select 1 here) > [GNUPG:] GET_LINE ask_revocation_reason.code > 0 > [GNUPG:] GOT_IT > Enter an optional description; end it with an empty line: > [GNUPG:] GET_LINE ask_revocation_reason.text > Pre-created revocation. > [GNUPG:] GOT_IT > [GNUPG:] GET_LINE ask_revocation_reason.text > > [GNUPG:] GOT_IT > Reason for revocation: No reason specified > Pre-created revocation. > [GNUPG:] GET_BOOL ask_revocation_reason.okay > y > [GNUPG:] GOT_IT > NOTE: This key is not protected! > ASCII armored output forced. > [GNUPG:] GOOD_PASSPHRASE > > I have not indented the answers sent to stdin on response to the GET_foo > lines. The script should parse the tags after the GET_foo to see what > has been requested and best use FSM to process this. Unknown tags What is FSM ? Finite State Machine. How can I use this? > should be answered with just a LF. Of course you would use the What if LF ? > fingerprint of the key and not just the name to invoking the command. > > As a quick solution for unattended key generation I am going to add a > "%revokefile" command to write a simple revocation certificate to the > given file after key generation. > I need to write the revocation certificate to a file too. > > Shalom-Salam, > > Werner Many Thanks Meenal From kloecker at kde.org Fri Apr 18 00:00:05 2008 From: kloecker at kde.org (Ingo =?iso-8859-1?q?Kl=F6cker?=) Date: Fri, 18 Apr 2008 00:00:05 +0200 Subject: Kontact Singature Validation Issue In-Reply-To: References: Message-ID: <200804180000.10725@erwin.ingo-kloecker.de> On Wednesday 16 April 2008, Johannes Graumann wrote: > Hi all, > > I have an issue with mail signatures in my mail setup and want to ask > whether anybody has experienced something similar and/or where to > look for a solution. > I standardly MIME-sign my mail using kontact, the kde PIM. I think it would make more sense to discuss this on the kdepim-users(@kde.org) mailing list. But anyway... > Everything > works fine and the sent mails in the "sent mail" folder validate just > fine. However, mail I send to myself - no matter through which of a > number of smtp servers at my disposal - fail the signature test after > arrival. Might be one element of my overly-elaborate mail collection > scheme is to blame? It looks like so: > 1. A number of mail accounts all forewarding to a gmail account > 2. fetchmail imap-pulling the messages from the gmail account and > inserting it into a local kolab installation > 3. kontact imap-retrieves the mail from kolab. What happens if you access the GMail account directly with Kontact leaving out 2 and 3? Did you compare the sent message with the received message to find out what exactly breaks the signature? Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part. URL: From johannes_graumann at web.de Fri Apr 18 09:47:45 2008 From: johannes_graumann at web.de (Johannes Graumann) Date: Fri, 18 Apr 2008 09:47:45 +0200 Subject: Kontact Singature Validation Issue References: <200804180000.10725__47752.6283277713$1208469973$gmane$org@erwin.ingo-kloecker.de> Message-ID: Ingo Kl?cker wrote: > On Wednesday 16 April 2008, Johannes Graumann wrote: >> Hi all, >> >> I have an issue with mail signatures in my mail setup and want to ask >> whether anybody has experienced something similar and/or where to >> look for a solution. >> I standardly MIME-sign my mail using kontact, the kde PIM. > > I think it would make more sense to discuss this on the > kdepim-users(@kde.org) mailing list. But anyway... > > >> Everything >> works fine and the sent mails in the "sent mail" folder validate just >> fine. However, mail I send to myself - no matter through which of a >> number of smtp servers at my disposal - fail the signature test after >> arrival. Might be one element of my overly-elaborate mail collection >> scheme is to blame? It looks like so: >> 1. A number of mail accounts all forewarding to a gmail account >> 2. fetchmail imap-pulling the messages from the gmail account and >> inserting it into a local kolab installation >> 3. kontact imap-retrieves the mail from kolab. > > What happens if you access the GMail account directly with Kontact > leaving out 2 and 3? > > Did you compare the sent message with the received message to find out > what exactly breaks the signature? > > > Regards, > Ingo Thanks for your time. I have since gotten a nudge from others (see below) and compared the sent and received mail. This led me to the discovery that kolab is changing my headers (google-archived copy of the mail is alright, only after piping it through kolab does the header get screwed up). I therefore disagree that this is a kde-pim issue and have taken it to the kolab mailing list instead ... where nobody reacted to it yet ... Thanks, Joh On Wednesday 16 April 2008 14:27:03 Peter Pentchev wrote: > On Wed, Apr 16, 2008 at 10:00:11AM +0200, Johannes Graumann wrote: > > Hi all, > > > > I have an issue with mail signatures in my mail setup and want to ask > > whether anybody has experienced something similar and/or where to look > > for a solution. > > I standardly MIME-sign my mail using kontact, the kde PIM. Everything > > works fine and the sent mails in the "sent mail" folder validate just > > fine. However, mail I send to myself - no matter through which of a > > number of smtp servers at my disposal - fail the signature test after > > arrival. Might be one element of my overly-elaborate mail collection > > scheme is to blame? It looks like so: > > 1. A number of mail accounts all forewarding to a gmail account > > 2. fetchmail imap-pulling the messages from the gmail account and > > inserting it into a local kolab installation > > 3. kontact imap-retrieves the mail from kolab. > > > > Any insight into this is highly appreciated! > > Can you compare the two e-mail messages - the one in your "sent mail" > folder and the received one in your inbox - and see if they are the > same - and what the differences are? > > I've had a problem with a Microsoft Exchange installation with a slew of > anti-virus software - it took a MIME-signed message and split a header > *in the signed portion* - inserted a new-line character there. > The "new" message was a valid e-mail message, but of course it failed > the signature check :) > > Once you've seen what differences there are between the messages, it > might be easier to figure out which program makes the changes at which > part of the cycle. Thanks. Went and diffed the complete messages as exported to disk ... and sure enough, here we go: # diff Message_Sent Message_Received 0a1 > 2,3c3 < Content-Type: text/plain; < ? charset="us-ascii" --- > Content-Type: text/plain; charset="us-ascii" 21c21 < Content-Type: application/pgp-signature; name=signature.asc --- > Content-Type: application/pgp-signature; name=signature.asc Since this is happening through multiple smtp servers, it's most likely that it is happening in kolab. I already shifted this over to their newsgroup ... Thanks for your nudge, Joh From wk at gnupg.org Fri Apr 18 10:33:05 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 18 Apr 2008 10:33:05 +0200 Subject: --gen-revoke in batch In-Reply-To: <480796E1.6020906@ncsa.uiuc.edu> (Meenal Pant's message of "Thu, 17 Apr 2008 13:28:49 -0500") References: <48066377.3040907@ncsa.uiuc.edu> <480690A5.80309@tx.rr.com> <87hce0d5tv.fsf@wheatstone.g10code.de> <480796E1.6020906@ncsa.uiuc.edu> Message-ID: <87iqyf4l6m.fsf@wheatstone.g10code.de> On Thu, 17 Apr 2008 20:28, mpant at ncsa.uiuc.edu said: >> $ gpg2 --status-fd 2 --command-fd 0 --gen-revoke joe > I guess I can use gpg here ? Yes. >> [GNUPG:] GET_BOOL gen_revoke.okay > Are these commands generated by GPG ? The option --status-fd N generates them and writes the to the file descriptor N (in the example 2 = stderr), you may want to use 1 for stdout. > What is FSM ? Finite State Machine. How can I use this? Right. This the proper way to automate gpg using --command-fd/--status-fd . It is a bit of work but has the advantage that it won't break or, even worse, yields unexpected results if gpg adds other status messages. The GPA frontend uses this approach (src/gpgmeedit.c). >> should be answered with just a LF. Of course you would use the > What if LF ? linefeed or in C notation "\n" (ASCII code 0x10). > I need to write the revocation certificate to a file too. Use the gpg option --output FILE Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From anthonybryan at gmail.com Fri Apr 18 23:26:26 2008 From: anthonybryan at gmail.com (Anthony Bryan) Date: Fri, 18 Apr 2008 17:26:26 -0400 Subject: Automated signature verification for downloads Message-ID: Hi, Metalink Checker (Python) now supports automated signature verification for downloads with .metalink files. .metalink files are XML and list mirrors, checksums, signatures, and other information, used for improving downloads and automating advanced features. There are about 20 metalink download clients, from CLI to GUI, on all platforms, from download managers to Web browsers. Currently, only the cURL project includes signatures in their .metalinks and only Metalink Checker supports verifying them. To try it out, download Metalink Checker [1]. You need gnupg or gpg4win installed for signature verification. Go to the cURL download page [2] and get a .metalink [3] If you don't already have it, import the cURL GPG key (you can find it at the upper right of [2]) or put it in a key.asc file in the same directory. At the command line type: python metalink.py -d -f metalink.cgi (In most situations, the file would be called curl-7.18.1.tar.gz.metalink instead of metalink.cgi). You'll then see: Downloading to curl-7.18.1.tar.gz [#########################------------------------------] 47% 1.00/2.12 MB -----BEGIN PGP SIGNATURE INFORMATION----- timestamp: Sun, 30 Mar 2008 05:10:27 (Eastern Daylight Time) fingerprint: 914C533DF9B2ADA2204F586D78E11C6B279D5C91 uid: Daniel Stenberg (Haxx) -----END PGP SIGNATURE INFORMATION----- [#######################################################] 100% 2.12/2.12 MB Any comments/suggestions? More metalink info at http://en.wikipedia.org/wiki/Metalink -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads [1] http://metamirrors.nl/metalinks_project [2] http://curl.haxx.se/download.html [3] http://curl.haxx.se/metalink.cgi?curl=tar.gz From hidekis at gmail.com Sat Apr 19 02:16:30 2008 From: hidekis at gmail.com (Hideki Saito) Date: Fri, 18 Apr 2008 17:16:30 -0700 Subject: Naming of GnuPG Message-ID: <480939DE.5080108@gmail.com> Hello, How will version number convention will continue, as there are 1.4.x and 2.0.x lines concurrently running? 1.4.x line will be evolving on its own separately from 2.0.x line, right? Just curious, because now it is at 1.4.9 and 2.0.9... >From user's perspective, I think 1.4.x should be called something like GnuPG Standalone, instead of having two different version numbers... Well, I guess some programs go like 1.4.10, 2.0.10, etc., so this may not be relevant at all! Cheers, -- Hideki Saito From dshaw at jabberwocky.com Sun Apr 20 02:37:48 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 19 Apr 2008 20:37:48 -0400 Subject: Naming of GnuPG In-Reply-To: <480939DE.5080108@gmail.com> References: <480939DE.5080108@gmail.com> Message-ID: <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> On Apr 18, 2008, at 8:16 PM, Hideki Saito wrote: > Hello, > How will version number convention will continue, as there are 1.4.x > and > 2.0.x lines concurrently running? > > 1.4.x line will be evolving on its own separately from 2.0.x line, > right? > Just curious, because now it is at 1.4.9 and 2.0.9... Not exactly evolving on its own. 1.4.x is not about to grow S/MIME capabilities like 2.0.x, but some changes will certainly apply to both. >> From user's perspective, I think 1.4.x should be called something >> like > GnuPG Standalone, instead of having two different version numbers... > Well, I guess some programs go like 1.4.10, 2.0.10, etc., so this may > not be relevant at all! Do people find the 1.4.x / 2.0.x thing confusing? David From mkinni at calpoly.edu Sun Apr 20 03:16:08 2008 From: mkinni at calpoly.edu (Matt Kinni) Date: Sat, 19 Apr 2008 18:16:08 -0700 Subject: Naming of GnuPG In-Reply-To: <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> Message-ID: <480A9958.9000101@calpoly.edu> I find it very confusing. In fact I don't know the difference between the two! David Shaw wrote: > On Apr 18, 2008, at 8:16 PM, Hideki Saito wrote: > >> Hello, >> How will version number convention will continue, as there are 1.4.x and >> 2.0.x lines concurrently running? >> >> 1.4.x line will be evolving on its own separately from 2.0.x line, >> right? >> Just curious, because now it is at 1.4.9 and 2.0.9... > > Not exactly evolving on its own. 1.4.x is not about to grow S/MIME > capabilities like 2.0.x, but some changes will certainly apply to both. > >>> From user's perspective, I think 1.4.x should be called something like >> GnuPG Standalone, instead of having two different version numbers... >> Well, I guess some programs go like 1.4.10, 2.0.10, etc., so this may >> not be relevant at all! > > Do people find the 1.4.x / 2.0.x thing confusing? > > David > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 535 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sun Apr 20 02:45:06 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 19 Apr 2008 19:45:06 -0500 Subject: Naming of GnuPG In-Reply-To: <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> Message-ID: <480A9212.6070606@sixdemonbag.org> David Shaw wrote: > Do people find the 1.4.x / 2.0.x thing confusing? Speaking for myself, no. But I'm pretty far from a normal user. Regular users are taught to think that bigger version numbers are better, more recent, more capable, more bug-free, etc. Windows NT 3.51 --> Windows NT 4.0 Windows 2000 --> Windows 2003 Server FreeBSD 5.2 --> FreeBSD 6.0 Fedora Core 8 --> Fedora Core 9 GnuPG 1.4 --> GnuPG 2.0 One of those is not like the other, but I think the average user would be hard-pressed to figure which is which. From hidekis at gmail.com Sun Apr 20 03:30:30 2008 From: hidekis at gmail.com (Hideki Saito) Date: Sat, 19 Apr 2008 18:30:30 -0700 Subject: Naming of GnuPG In-Reply-To: <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> Message-ID: <480A9CB6.2070101@gmail.com> Hello David, As for 1.4.x / 2.0.x naming thing, what I meant is that I don't think it necessary confusing. (although, I know a case that one got confused whether he should download 1.4.8 or 2.0.8; but this person was on Windows, so it wasn't too much of problem, as there weren't any choices.) A lot of general public might think, however, higher the version, more features (which in GnuPG case, it is true), and perhaps less buggy, etc. And also there are many programs out there, which has version number inferior put into "maintenance mode" with only vulnerability fixes being conducted, which certainly not the case with GnuPG, as new features and enhancements are being introduced to it. It was just my opinion, that if having 1.4.x and 2.0.x is about making choices available for standalone OpenPGP, and integrated solution with S/MIME, I just felt it makes sense more to have similar versioning scheme as I assume, that capability of OpenPGP part would be identical or similar to their 2.0.x counterpart. Cheers, -- Hideki Saito > On Apr 18, 2008, at 8:16 PM, Hideki Saito wrote: > >> Hello, >> How will version number convention will continue, as there are 1.4.x and >> 2.0.x lines concurrently running? >> >> 1.4.x line will be evolving on its own separately from 2.0.x line, >> right? >> Just curious, because now it is at 1.4.9 and 2.0.9... > > Not exactly evolving on its own. 1.4.x is not about to grow S/MIME > capabilities like 2.0.x, but some changes will certainly apply to both. > >>> From user's perspective, I think 1.4.x should be called something like >> GnuPG Standalone, instead of having two different version numbers... >> Well, I guess some programs go like 1.4.10, 2.0.10, etc., so this may >> not be relevant at all! > > Do people find the 1.4.x / 2.0.x thing confusing? > > David > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From JPClizbe at tx.rr.com Sun Apr 20 03:36:26 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Sat, 19 Apr 2008 20:36:26 -0500 Subject: Naming of GnuPG In-Reply-To: <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> Message-ID: <480A9E1A.7080602@tx.rr.com> David Shaw wrote: > > Do people find the 1.4.x / 2.0.x thing confusing? From what I've seen of this as well as other lists, I'd say that the answer to that is a hearty, YES. Rather than seeing 1.4.x & 2.0.x as different paths to accomplish the same task, less-experienced users tend to fall into the "greater version # must mean 'New&Improved?' *AND* BETTER" trap. The "Well, isn't 2.0 better?" question is common. -- John P. Clizbe Inet: John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10/0x18BB373A "what's the key to success?" / "two words: good decisions." "what's the key to good decisions?" / "one word: experience." "how do i get experience?" / "two words: bad decisions." "Just how do the residents of Haiku, Hawai'i hold conversations?" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 677 bytes Desc: OpenPGP digital signature URL: From christoph.anton.mitterer at physik.uni-muenchen.de Sun Apr 20 03:42:08 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Sun, 20 Apr 2008 03:42:08 +0200 Subject: Naming of GnuPG In-Reply-To: <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> Message-ID: <1208655728.14929.11.camel@fermat.scientia.net> On Sat, 2008-04-19 at 20:37 -0400, David Shaw wrote: > Do people find the 1.4.x / 2.0.x thing confusing? Well,.. partly,... (at least when speaking for myself). Of course it makes sense to provide security fixes for the 1.x branch, but I always wonder why you don't switch to the 2.x for the main development branch. And two branches like this always provide the risk that fixes, enhancements, etc. are not correctly applied to both, and that bigger differences arise. Regards, Chris. From christoph.anton.mitterer at physik.uni-muenchen.de Sun Apr 20 03:45:46 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Sun, 20 Apr 2008 03:45:46 +0200 Subject: Naming of GnuPG In-Reply-To: <480A9212.6070606@sixdemonbag.org> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480A9212.6070606@sixdemonbag.org> Message-ID: <1208655946.14929.15.camel@fermat.scientia.net> On Sat, 2008-04-19 at 19:45 -0500, Robert J. Hansen wrote: > Regular users are taught to think that bigger version numbers are > better, more recent, more capable, more bug-free, etc. Well,.. that's what nearly each version naming model implies. Of course those examples are different, however for all of them it is supposed to use the newer versions if possible. That's even true for different branches like Apache's http server. One should probably only use the 1.x branch if using the 2.x is impossible for some reason. Chris. From jamie at fastmail.net Sun Apr 20 03:35:44 2008 From: jamie at fastmail.net (Jamie Griffin) Date: Sun, 20 Apr 2008 02:35:44 +0100 Subject: Naming of GnuPG In-Reply-To: <480A9212.6070606@sixdemonbag.org> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480A9212.6070606@sixdemonbag.org> Message-ID: <20080420013544.GA8538@jinx.home> now that you've clarified that you're better than us 'normal' folk, perhaps you'd care to explain it in more detail. For the benefit of the list of course. On Sat, Apr 19, 2008 at 07:45:06PM -0500, Robert J. Hansen wrote: > David Shaw wrote: > > Do people find the 1.4.x / 2.0.x thing confusing? > > Speaking for myself, no. But I'm pretty far from a normal user. > Regular users are taught to think that bigger version numbers are > better, more recent, more capable, more bug-free, etc. > > Windows NT 3.51 --> Windows NT 4.0 > Windows 2000 --> Windows 2003 Server > FreeBSD 5.2 --> FreeBSD 6.0 > Fedora Core 8 --> Fedora Core 9 > GnuPG 1.4 --> GnuPG 2.0 > > One of those is not like the other, but I think the average user would > be hard-pressed to figure which is which. > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From rjh at sixdemonbag.org Sun Apr 20 04:23:46 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 19 Apr 2008 21:23:46 -0500 Subject: Naming of GnuPG In-Reply-To: <20080420013544.GA8538@jinx.home> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480A9212.6070606@sixdemonbag.org> <20080420013544.GA8538@jinx.home> Message-ID: <480AA932.9050108@sixdemonbag.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jamie Griffin wrote: > now that you've clarified that you're better than us 'normal' folk "Better" is a word I did not use and would not use. Your attempt to put that word in my mouth tells us a lot more about you than about me. Given that your message appears to be an attempt to get a reaction from me, the preceding is the only reaction you will get. Goodbye. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJICqkyAAoJELcA9IL+r4EJUgEIAMgYGE3krbDh350NmI9onORE tQ7o5sSjzShqvp4AvJxQRYJOqKvmuIFoZgqNaUKid5MfZ8JRvVnxsIEs09Nbcn4R T5GwOx6ETpFppObHVdbAxmMHA8mFRQgyWZLi7TsrxyR+LYfiiKJd99v9tYW0I1zW s99vmiqaS728zzaReLuHLaTRvN4rhnWZgLakYH0PECu3GMusf/71TI3PROqg7GkV nRHT1y4Gaj1/F5ejT50GoIF3ssvpGw4KvAag6U0o6ggKozVpOgCZTm+/4fZqEaLw vLxP97092uluesoIxX+9DRecH1xjA7+PVBDSLbbcKJPhUFqaMD7uoayYblyx/pQ= =z5DQ -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sun Apr 20 04:41:15 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 19 Apr 2008 21:41:15 -0500 Subject: Naming of GnuPG In-Reply-To: <1208655946.14929.15.camel@fermat.scientia.net> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480A9212.6070606@sixdemonbag.org> <1208655946.14929.15.camel@fermat.scientia.net> Message-ID: <480AAD4B.8010902@sixdemonbag.org> Christoph Anton Mitterer wrote: > On Sat, 2008-04-19 at 19:45 -0500, Robert J. Hansen wrote: >> Regular users are taught to think that bigger version numbers are >> better, more recent, more capable, more bug-free, etc. > > Well,.. that's what nearly each version naming model implies. Yes: that's the point I was making. Regular users are taught to think this. This is generally true. GnuPG is not following the regular versioning conventions. From mkinni at calpoly.edu Sun Apr 20 06:21:19 2008 From: mkinni at calpoly.edu (Matt Kinni) Date: Sat, 19 Apr 2008 21:21:19 -0700 Subject: Naming of GnuPG In-Reply-To: <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> Message-ID: <480AC4BF.4060702@calpoly.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 So theres already been a lot of arguing over this and bla bla bla. Basicaly, for a newbie, what is the difference between the two product lines? Should an average user go with 1.4.x or 2.x? David Shaw wrote: | On Apr 18, 2008, at 8:16 PM, Hideki Saito wrote: | |> Hello, |> How will version number convention will continue, as there are 1.4.x and |> 2.0.x lines concurrently running? |> |> 1.4.x line will be evolving on its own separately from 2.0.x line, right? |> Just curious, because now it is at 1.4.9 and 2.0.9... | | Not exactly evolving on its own. 1.4.x is not about to grow S/MIME capabilities like 2.0.x, but some changes will certainly apply to both. | |>> From user's perspective, I think 1.4.x should be called something like |> GnuPG Standalone, instead of having two different version numbers... |> Well, I guess some programs go like 1.4.10, 2.0.10, etc., so this may |> not be relevant at all! | | Do people find the 1.4.x / 2.0.x thing confusing? | | David | | _______________________________________________ | Gnupg-users mailing list | Gnupg-users at gnupg.org | http://lists.gnupg.org/mailman/listinfo/gnupg-users | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: comment line 1 Comment: comment line 2 iQEcBAEBCAAGBQJICsS9AAoJELlJAlPUfypQR2cH/RoFO9KFQllUTE5ZkqQkUY07 pkQmgqaW+9AmvZpXRpe9TmRo3QePSdBeCsnfejot+0hLJGOWvZVh3/9J0KpNg5+T 92Nd5j1Nd4DUgkRB4tzNMAGdz2V9OU2k6N6QgR5AW+MnWi77YIYJv0XZVPHYz8Po XR8lsxajLHE8PYa3QFZ1YoKsJ0+Ji67gMPuwjIry4hkqFtmQODJSektcN0cWZupa 4caesn12IF1jJhexcOaIwmxoJ5ZXqQVrr0Zj0ltafhDpUeahEr0QIVLnjUzRHKJW mft9PEAX6luuGWg1M1F4x80WtX3IOUAUelE6UZb+LnmVy273gOtCL0V9M5bXPYg= =teCD -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sun Apr 20 06:28:15 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 19 Apr 2008 23:28:15 -0500 Subject: Naming of GnuPG In-Reply-To: <480AC4BF.4060702@calpoly.edu> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> Message-ID: <480AC65F.3000104@sixdemonbag.org> Matt Kinni wrote: > Basicaly, for a newbie, what is the difference between the two product > lines? GnuPG 2.0 adds S/MIME support, which is a totally different cryptographic standard than OpenPGP. If you need FOSS S/MIME, then you need GnuPG 2.0. Otherwise, I'd stick with 1.4, for reasons I've mentioned before on list. Check the archives from a couple of weeks ago. From jmoore3rd at bellsouth.net Sun Apr 20 06:34:48 2008 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Sun, 20 Apr 2008 00:34:48 -0400 Subject: Naming of GnuPG In-Reply-To: <480AC4BF.4060702@calpoly.edu> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> Message-ID: <480AC7E8.8070407@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Matt Kinni wrote: > So theres already been a lot of arguing over this and bla bla bla. > Basicaly, for a newbie, what is the difference between the two product > lines? Should an average user go with 1.4.x or 2.x? "Go with" the 1.4.x Branch and ignore the 2.0.x Trunk until You've acquired more experience. 1.4.x is smaller, faster and easier to find compatible distributions with. The x.509 capabilities of the 2.0.x Trunk aren't used all that much so You won't 'miss' 'em. Later, You can always install 2.0.x and run it side-by-side with 1.4.x should You desire. JOHN ;) Timestamp: Sunday 20 Apr 2008, 00:34 --400 (Eastern Daylight Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.5.0-svn4748: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: https://www.gswot.org Comment: Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJICsfmAAoJEBCGy9eAtCsPdEwH/RpJ3zssBq2cJdT+1xqR/vjL msGPI726ihGUq5ipp/qn287tIPV2He1hp5N2vjwbN5c1vneOACzGG6R0b5IH6inT MtQZvQw8JPwYe3fnsu7P6oADTVsVX0lGbCuNQkVduGRf7tVuzvJ2wAuWfSaaw7eo lR/wDF6dm+MoepNhMT6SpWSe17vnwlez5ofozFwKPU0Fv5c17p9XWe61+zQaMNRt xPxOqswk/Kk76jcyf+HbIyUej3Ruew1l/FhUdQD4+sbFqUQBmVEXaHtfOmz+zybo bnldnXBbL675SwEKIihV2aTTHGQW9FNs06zWSP16VKHIj5G/5g6leSEcGzy5AHU= =g9HM -----END PGP SIGNATURE----- From JPClizbe at tx.rr.com Sun Apr 20 06:50:58 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Sat, 19 Apr 2008 23:50:58 -0500 Subject: Naming of GnuPG In-Reply-To: <480AC65F.3000104@sixdemonbag.org> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> Message-ID: <480ACBB2.1020301@tx.rr.com> Robert J. Hansen wrote: > Matt Kinni wrote: >> Basically, for a newbie, what is the difference between the two product >> lines? > > GnuPG 2.0 adds S/MIME support, which is a totally different > cryptographic standard than OpenPGP. If you need FOSS S/MIME, then you > need GnuPG 2.0. For those using Enigmail with Thunderbird/Seamonkey, 2.0.x is _only_ required if one needs gpg-agent support. -- John P. Clizbe Inet: John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net "what's the key to success?" / "two words: good decisions." "what's the key to good decisions?" / "one word: experience." "how do i get experience?" / "two words: bad decisions." "Just how do the residents of Haiku, Hawai'i hold conversations?" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 677 bytes Desc: OpenPGP digital signature URL: From Bill.Royds at Royds.net Sun Apr 20 06:40:51 2008 From: Bill.Royds at Royds.net (Bill Royds) Date: Sun, 20 Apr 2008 00:40:51 -0400 Subject: Naming of GnuPG In-Reply-To: <480AC65F.3000104@sixdemonbag.org> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> Message-ID: <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> On 20-Apr-08, at 24:28 , Robert J. Hansen wrote: > GnuPG 2.0 adds S/MIME support, which is a totally different > cryptographic standard than OpenPGP. If you need FOSS S/MIME, then > you > need GnuPG 2.0. > Which is why they should have different names, rather thtn just different version numbers. the present GNUPG 2.x line should be called GNUPG-SMIME y.x While the GNUPG 1.x line should be GNUPG-OpenPGP y.x They are different so they should have different names. Bill Royds From email at sven-radde.de Sun Apr 20 10:31:36 2008 From: email at sven-radde.de (Sven Radde) Date: Sun, 20 Apr 2008 10:31:36 +0200 Subject: Naming of GnuPG In-Reply-To: <1208655946.14929.15.camel@fermat.scientia.net> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480A9212.6070606@sixdemonbag.org> <1208655946.14929.15.camel@fermat.scientia.net> Message-ID: <1208680297.6318.10.camel@carbon> Hi! Am Sonntag, den 20.04.2008, 03:45 +0200 schrieb Christoph Anton Mitterer: > That's even true for different branches like Apache's http server. One > should probably only use the 1.x branch if using the 2.x is impossible > for some reason. While it isn't directly true for GnuPG, interpreting the issue in this way (i.e. "use 1.4 only if 2.x isn't possible for you") would not do any harm, would it? cu, Sven From email at sven-radde.de Sun Apr 20 10:37:13 2008 From: email at sven-radde.de (Sven Radde) Date: Sun, 20 Apr 2008 10:37:13 +0200 Subject: Naming of GnuPG In-Reply-To: <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> Message-ID: <1208680633.6318.15.camel@carbon> Hi! Am Sonntag, den 20.04.2008, 00:40 -0400 schrieb Bill Royds: > the present GNUPG 2.x line should be called GNUPG-SMIME y.x > While the GNUPG 1.x line should be GNUPG-OpenPGP y.x This would imply that 2.x could not do OpenPGP anymore, which simply isn't the case. cu, Sven From kloecker at kde.org Sun Apr 20 11:40:26 2008 From: kloecker at kde.org (Ingo =?iso-8859-1?q?Kl=F6cker?=) Date: Sun, 20 Apr 2008 11:40:26 +0200 Subject: Naming of GnuPG In-Reply-To: <480A9212.6070606@sixdemonbag.org> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480A9212.6070606@sixdemonbag.org> Message-ID: <200804201140.26840@erwin.ingo-kloecker.de> On Sunday 20 April 2008, Robert J. Hansen wrote: > David Shaw wrote: > > Do people find the 1.4.x / 2.0.x thing confusing? > > Speaking for myself, no. But I'm pretty far from a normal user. > Regular users are taught to think that bigger version numbers are > better, more recent, more capable, more bug-free, etc. > > Windows NT 3.51 --> Windows NT 4.0 > Windows 2000 --> Windows 2003 Server > FreeBSD 5.2 --> FreeBSD 6.0 > Fedora Core 8 --> Fedora Core 9 > GnuPG 1.4 --> GnuPG 2.0 > > One of those is not like the other, but I think the average user > would be hard-pressed to figure which is which. One of those is no operating system (plus some more stuff), but I guess that's not what you meant. ;-) Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Sun Apr 20 11:56:20 2008 From: kloecker at kde.org (Ingo =?iso-8859-1?q?Kl=F6cker?=) Date: Sun, 20 Apr 2008 11:56:20 +0200 Subject: Naming of GnuPG In-Reply-To: <20080420013544.GA8538@jinx.home> References: <480939DE.5080108@gmail.com> <480A9212.6070606@sixdemonbag.org> <20080420013544.GA8538@jinx.home> Message-ID: <200804201156.20860@erwin.ingo-kloecker.de> On Sunday 20 April 2008, Jamie Griffin wrote: > now that you've clarified that you're better than us 'normal' folk, > perhaps you'd care to explain it in more detail. For the benefit of > the list of course. Robert neither wrote nor implied this. The lesson you should learn from Robert is that you should not blindly install the version with the higher version number, but that you should first get some information about the difference between the two versions in order to find out whether you really need the one with the higher version number. With respect to the differences between GnuPG 1.4 and GnuPG 2.0 please refer to the archive of this mailing list, e.g. read Werner Koch's announcement of GnuPG 2.0 [1]. The website (www.gnupg.org) is pretty cryptic about the difference. All it says is GnuPG comes in two flavours: 1.4.9 is the well known and portable standalone version, whereas 2.0.9 is the enhanced and somewhat harder to build version. This text could be improved. Or it could link to a page explaining the difference because this is obviously an FAQ. Unfortunately the FAQ hasn't been updated since July 30, 2003. Regards, Ingo [1] http://lists.gnupg.org/pipermail/gnupg-announce/2006q4/000239.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part. URL: From christoph.anton.mitterer at physik.uni-muenchen.de Sun Apr 20 12:37:07 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Sun, 20 Apr 2008 12:37:07 +0200 Subject: Naming of GnuPG In-Reply-To: <480AAD4B.8010902@sixdemonbag.org> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480A9212.6070606@sixdemonbag.org> <1208655946.14929.15.camel@fermat.scientia.net> <480AAD4B.8010902@sixdemonbag.org> Message-ID: <1208687827.3369.4.camel@fermat.scientia.net> Dear Robert. On Sat, 2008-04-19 at 21:41 -0500, Robert J. Hansen wrote: > Yes: that's the point I was making. Regular users are taught to think > this. This is generally true. GnuPG is not following the regular > versioning conventions. Uhm what I mainly wonder is,... what is the main difference between those two? Ok CMS support but that's not a difference between the shared codebase, is it? So in my opinion there are only rare cases where it's justified to have different continuing branches (which are actually like forks). One example is perhaps flex and flex-old.. Best wishes, Chris. From christoph.anton.mitterer at physik.uni-muenchen.de Sun Apr 20 12:37:53 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Sun, 20 Apr 2008 12:37:53 +0200 Subject: Naming of GnuPG In-Reply-To: <1208680297.6318.10.camel@carbon> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480A9212.6070606@sixdemonbag.org> <1208655946.14929.15.camel@fermat.scientia.net> <1208680297.6318.10.camel@carbon> Message-ID: <1208687873.3369.6.camel@fermat.scientia.net> On Sun, 2008-04-20 at 10:31 +0200, Sven Radde wrote: > While it isn't directly true for GnuPG, interpreting the issue in this > way (i.e. "use 1.4 only if 2.x isn't possible for you") would not do any > harm, would it? Yes, that's what I'd prefer. Chris. From christoph.anton.mitterer at physik.uni-muenchen.de Sun Apr 20 12:40:04 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Sun, 20 Apr 2008 12:40:04 +0200 Subject: Naming of GnuPG In-Reply-To: <200804201140.26840@erwin.ingo-kloecker.de> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480A9212.6070606@sixdemonbag.org> <200804201140.26840@erwin.ingo-kloecker.de> Message-ID: <1208688004.3369.8.camel@fermat.scientia.net> On Sun, 2008-04-20 at 11:40 +0200, Ingo Kl?cker wrote: > On Sunday 20 April 2008, Robert J. Hansen wrote: > > Windows NT 3.51 --> Windows NT 4.0 > > Windows 2000 --> Windows 2003 Server > > FreeBSD 5.2 --> FreeBSD 6.0 > > Fedora Core 8 --> Fedora Core 9 > > GnuPG 1.4 --> GnuPG 2.0 > One of those is no operating system (plus some more stuff), but I guess > that's not what you meant. ;-) One? You think Windows* are operating systems?? ;-) Chris. From faramir.cl at gmail.com Sun Apr 20 11:54:27 2008 From: faramir.cl at gmail.com (Faramir) Date: Sun, 20 Apr 2008 05:54:27 -0400 Subject: Naming of GnuPG In-Reply-To: <480ACBB2.1020301@tx.rr.com> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <480ACBB2.1020301@tx.rr.com> Message-ID: <480B12D3.9090205@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does it means Enigmail adds to 1.4.x most of the features of 2.0.x? Now I must check what is gpg-agent (yes, I am so noob) | John Clizbe escribi?: | Robert J. Hansen wrote: |> Matt Kinni wrote: |>> Basically, for a newbie, what is the difference between the two product |>> lines? |> GnuPG 2.0 adds S/MIME support, which is a totally different |> cryptographic standard than OpenPGP. If you need FOSS S/MIME, then you |> need GnuPG 2.0. | | For those using Enigmail with Thunderbird/Seamonkey, 2.0.x is _only_ required if | one needs gpg-agent support. | | | ------------------------- | | _______________________________________________ | Gnupg-users mailing list | Gnupg-users at gnupg.org | http://lists.gnupg.org/mailman/listinfo/gnupg-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJICxLTAAoJEIISGkVDGUEOA+8IAIIBg9erHD+Zo164cKCQ//Qx uNO9edJbpFoBTENYfXsQfvRKcQG5b/Xk193BU6jwUHAqv7v2JH7BtDLBsuEvuvN1 NEXVSuCAFoAzElh6YHJEuC9tvcwLbvXCwPPtGbm5ESNAb7Wvc/fpp201/tW0P9j+ f7VKeO8GLc/KKkx1YseksPLizZOcB3to43UNglbwuzJjquCLg9dRfvyzBxWMTYnI T6K5zfpfb2mmkn2fDewSkXbwvCFHaKacC5PksLVgz7hQ1zzflYaddmsH1rINtICi IbjG4w/mMom2JQ2m5rBylswdnxx1ubr0WUylRFK5isUGhq9cS6TB8RY3agCFABg= =CaY6 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From email at sven-radde.de Sun Apr 20 13:26:15 2008 From: email at sven-radde.de (Sven Radde) Date: Sun, 20 Apr 2008 13:26:15 +0200 Subject: Naming of GnuPG In-Reply-To: <480B12D3.9090205@gmail.com> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <480ACBB2.1020301@tx.rr.com> <480B12D3.9090205@gmail.com> Message-ID: <1208690775.6318.32.camel@carbon> Hi! Am Sonntag, den 20.04.2008, 05:54 -0400 schrieb Faramir: > Does it means Enigmail adds to 1.4.x most of the features of 2.0.x? Absolutely not. Enigmail is a Frontend/GUI for some of GnuPG's functions. In fact, Enigmail does not use any of the added functions that GnuPG 2.x offers, as Enigmail is only for OpenPGP-based email encryption. So, what John meant is, if you use Enigmail, using GnuPG 2.x won't give you any benefits (apart from gpg-agent, which is not too useful in this scenario, as Enigmail can cache passphrases on its own, too). cu, Sven From jamie at fastmail.net Sun Apr 20 13:35:09 2008 From: jamie at fastmail.net (Jamie Griffin) Date: Sun, 20 Apr 2008 12:35:09 +0100 Subject: Naming of GnuPG In-Reply-To: <480AA932.9050108@sixdemonbag.org> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480A9212.6070606@sixdemonbag.org> <20080420013544.GA8538@jinx.home> <480AA932.9050108@sixdemonbag.org> Message-ID: <20080420113509.GA11013@jinx.home> i apologize. That was provocative of me. I just think you come across very patronizing sometimes which isn't necessary. On Sat, Apr 19, 2008 at 09:23:46PM -0500, Robert J. Hansen wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jamie Griffin wrote: > now that you've clarified that you're better than us 'normal' folk "Better" is a word I did not use and would not use. Your attempt to put that word in my mouth tells us a lot more about you than about me. Given that your message appears to be an attempt to get a reaction from me, the preceding is the only reaction you will get. Goodbye. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJICqkyAAoJELcA9IL+r4EJUgEIAMgYGE3krbDh350NmI9onORE tQ7o5sSjzShqvp4AvJxQRYJOqKvmuIFoZgqNaUKid5MfZ8JRvVnxsIEs09Nbcn4R T5GwOx6ETpFppObHVdbAxmMHA8mFRQgyWZLi7TsrxyR+LYfiiKJd99v9tYW0I1zW s99vmiqaS728zzaReLuHLaTRvN4rhnWZgLakYH0PECu3GMusf/71TI3PROqg7GkV nRHT1y4Gaj1/F5ejT50GoIF3ssvpGw4KvAag6U0o6ggKozVpOgCZTm+/4fZqEaLw vLxP97092uluesoIxX+9DRecH1xjA7+PVBDSLbbcKJPhUFqaMD7uoayYblyx/pQ= =z5DQ -----END PGP SIGNATURE----- From jmoore3rd at bellsouth.net Sun Apr 20 14:03:14 2008 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Sun, 20 Apr 2008 08:03:14 -0400 Subject: Naming of GnuPG In-Reply-To: <480ACD8A.9060700@calpoly.edu> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC7E8.8070407@bellsouth.net> <480ACD8A.9060700@calpoly.edu> Message-ID: <480B3102.3010405@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Matt Kinni wrote: > links to your public key, and noticed it's REAAAAALLY long. Why is your > public key so much longer than mine? Longer? I am guessing that You are referring to 'how long' You had to scroll down to Copy the Key Block to the Clipboard? [this also tells Me that You followed the Big Lumber Link :) ] The 'length' of the Key Block is a function of the number of Signatures attached to My Key. The 'size' of the Key is 3072 bit. JOHN ;) Timestamp: Sunday 20 Apr 2008, 08:01 --400 (Eastern Daylight Time) - -- If you think you're a person of influence, try ordering somebody else's dog around. WILL ROGERS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.5.0-svn4748: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: https://www.gswot.org Comment: Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJICzD+AAoJEBCGy9eAtCsP21wH/jPWn2acEdGRCTQjZeH3LXa7 vgCKp3FFOtN2csrdHObiPr7JfRlVugYzH9s5kmuh2wXw2btFvg7MFeV3l9UD32CR zkQyBpUSJQRuK9T4VqmrR1nz/y28q6NpKxj1qr7ThEZDKfWw08XQrnNzTZTiA75u m8kcOTGAl5WKEOWAullgGPS2rdEhE5C9zngs1xLrOcf30hsXgl44wcvqpZ8anKdU YEg2flxrGX1raNS7MZ59+8JHQgX1vZ4iKbJ9SGb5vqFuj7Y6V4gDQ6bjSUHqeJsl IWA84zZhvcDMkRRY+E6GefF562r2Xszp5aGscJlFjhF8VE17Amt0PRCQHN877OY= =WfyU -----END PGP SIGNATURE----- From al at gcguk.demon.co.uk Sun Apr 20 14:26:52 2008 From: al at gcguk.demon.co.uk (Al Girling) Date: Sun, 20 Apr 2008 13:26:52 +0100 Subject: List Archive Message-ID: <20080420122652.GC3216@herodotus> Hi folks, This is my first post here, I still have much reading to do to get fully up to speed with GnuPG. I just wanted to point out that the List-Archive header doesn't point to a URL. It simply shows: List-Archive: Not a biggy I know, but thought I should let you know. Toodle pip, Al -- Al Girling Linux User: #290080 Home-page: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From wk at gnupg.org Sun Apr 20 16:15:44 2008 From: wk at gnupg.org (Werner Koch) Date: Sun, 20 Apr 2008 16:15:44 +0200 Subject: Naming of GnuPG In-Reply-To: <200804201156.20860@erwin.ingo-kloecker.de> ("Ingo =?utf-8?Q?Kl=C3=B6cker=22's?= message of "Sun, 20 Apr 2008 11:56:20 +0200") References: <480939DE.5080108@gmail.com> <480A9212.6070606@sixdemonbag.org> <20080420013544.GA8538@jinx.home> <200804201156.20860@erwin.ingo-kloecker.de> Message-ID: <87abjozk6n.fsf@wheatstone.g10code.de> On Sun, 20 Apr 2008 11:56, kloecker at kde.org said: > GnuPG comes in two flavours: 1.4.9 is the well known and portable > standalone version, whereas 2.0.9 is the enhanced and somewhat harder > to build version. > > This text could be improved. Or it could link to a page explaining the Anyone with a text suggestion? Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From shavital at mac.com Sun Apr 20 17:27:05 2008 From: shavital at mac.com (Charly Avital) Date: Sun, 20 Apr 2008 11:27:05 -0400 Subject: List Archive In-Reply-To: <20080420122652.GC3216@herodotus> References: <20080420122652.GC3216@herodotus> Message-ID: <480B60C9.5050307@mac.com> Al Girling wrote the following on 4/20/08 8:26 AM: > Hi folks, > > This is my first post here, I still have much reading to do to get fully > up to speed with GnuPG. > > I just wanted to point out that the List-Archive header doesn't point to > a URL. It simply shows: > > List-Archive: > > Not a biggy I know, but thought I should let you know. > > Toodle pip, > > Al Hi Al, Good signature from Alistair Girling Key ID: 0x83A37BA1 / Signed on: 4/20/08 8:26 AM Key fingerprint: 7272 39A1 A783 43A7 CC52 674E AE3C 2316 83A3 7BA1 About List-Archive: In headers of older postings to the list, I have found: that seems to be the right URL. Charly From JPClizbe at tx.rr.com Sun Apr 20 18:05:52 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Sun, 20 Apr 2008 11:05:52 -0500 Subject: Naming of GnuPG In-Reply-To: <1208690775.6318.32.camel@carbon> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <480ACBB2.1020301@tx.rr.com> <480B12D3.9090205@gmail.com> <1208690775.6318.32.camel@carbon> Message-ID: <480B69E0.1070507@tx.rr.com> Sven Radde wrote: > Hi! > > Am Sonntag, den 20.04.2008, 05:54 -0400 schrieb Faramir: > >> Does it means Enigmail adds to 1.4.x most of the features of 2.0.x? > > Absolutely not. Enigmail is a Frontend/GUI for some of GnuPG's > functions. True. Enigmail is a security extension to Mozilla Thunderbird and Seamonkey. It integrates functionality of GnuPG's OpenPGP implementation to support the sending and receiving of OpenPGP encrypted and digitally signed email (and news). It will work with either GnuPG 1.4.x or 2.0.x. It does not provide a full interface to whichever version of GnuPG it is configured to use. Nor does it add any additional functionality not already present in the particular version of GnuPG in use. > In fact, Enigmail does not use any of the added functions that GnuPG 2.x > offers, as Enigmail is only for OpenPGP-based email encryption. > So, what John meant is, if you use Enigmail, using GnuPG 2.x won't give > you any benefits (apart from gpg-agent, which is not too useful in this > scenario, as Enigmail can cache passphrases on its own, too). Which is why I specified "is _only_ required if one needs gpg-agent support." It might be best if I speak to what I meant. gpg-agent is required in the case the user uses more than one key and those keys have different passphrases. Enigmail's passphrase caching is limited to the cases of a single key or multiple keys sharing a common passphrase. So, yes, in general, gpg-agent doesn't get you much. But in these the /specific/ use case I specified it is essential. -- John P. Clizbe Inet: JPClizbe (a) tx DAWT rr DAHT con Ginger Bear Networks hkp://keyserver.gingerbear.net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 677 bytes Desc: OpenPGP digital signature URL: From ladislav.hagara at unob.cz Sun Apr 20 18:48:39 2008 From: ladislav.hagara at unob.cz (Ladislav Hagara) Date: Sun, 20 Apr 2008 18:48:39 +0200 Subject: List Archive In-Reply-To: <480B60C9.5050307@mac.com> References: <20080420122652.GC3216@herodotus> <480B60C9.5050307@mac.com> Message-ID: <480B73E7.2020808@unob.cz> > In headers of older postings to the list, I have found: > that seems to be the > right URL. https://bugs.g10code.com/gnupg/issue900 -- Ladislav Hagara From al at gcguk.demon.co.uk Sun Apr 20 23:08:31 2008 From: al at gcguk.demon.co.uk (Al Girling) Date: Sun, 20 Apr 2008 22:08:31 +0100 Subject: List Archive In-Reply-To: <480B73E7.2020808@unob.cz> References: <20080420122652.GC3216@herodotus> <480B60C9.5050307@mac.com> <480B73E7.2020808@unob.cz> Message-ID: <20080420210831.GA3981@herodotus> On Sun, Apr 20, 2008 at 05:48:39PM BST, Ladislav Hagara wrote: > > >In headers of older postings to the list, I have found: > > that seems to be the > >right URL. > > https://bugs.g10code.com/gnupg/issue900 I didn't know a bug had already been filed. Sorry for the noise! Al -- Al Girling Linux User: #290080 Home-page: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From yochanon at localnet.com Mon Apr 21 01:38:04 2008 From: yochanon at localnet.com (John B) Date: Sun, 20 Apr 2008 18:38:04 -0500 Subject: my apologies...needed to test if this gets to the list Message-ID: <200804201838.04474.yochanon@localnet.com> a test. -- 911 - government sponsored Dial-a-Prayer. From mkinni at calpoly.edu Mon Apr 21 08:25:54 2008 From: mkinni at calpoly.edu (Matt Kinni) Date: Sun, 20 Apr 2008 23:25:54 -0700 Subject: quickly batch lsign 50 keys? Message-ID: <480C3372.3060907@calpoly.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I have 50 or so keys I need to --lsign-key as quickly as possible. Is there any way I can accomplish this in one foul swoop? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBCAAGBQJIDDNwAAoJELlJAlPUfypQENEIAJ+UBcUAfxpbUW5JzWkBOMER ezyKEnc/UPtlGXRkIWJJn3yezSw7wXKCw5sYKrxqPOX4eO0UvaJUzbifSBVI2btz 5ZqheHrIXHnY9X9pNKRLUQXQaQO7FnkBm3ttm13+qbFl7yaCtehxHQn8R72zRGnd yoaaiHTw5DdtWYBlvMUV1u6Kc8pJ59rxl/k2c+g6IW/oea8h7BR0crZ/sT9HHTBj qYUlAvLOVnQ269adwXQmnbIPS4keCcoS9fOGRZHofL9IpNIS9qXkdfgCMCummYY/ uLbcqnKkaQ9r4Q2fpwVGcutLhmVqvV//j7NgFN+0YioS61ys77AI8Sawt8zoDZc= =0C/m -----END PGP SIGNATURE----- From reinhard.mueller at bytewise.at Wed Apr 16 13:44:02 2008 From: reinhard.mueller at bytewise.at (Reinhard Mueller) Date: Wed, 16 Apr 2008 13:44:02 +0200 Subject: SCM SCR-333 card reader: works! Message-ID: <1208346242.5384.3.camel@dublin.local> Hi, just to let you know that I installed the SCM SCR333 card reader and it worked out of the box. Seems to be a recommendable device if somebody is looking for an internal card reader for a desktop computer. Thanks, Reinhard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From johannes_graumann at web.de Wed Apr 16 15:44:20 2008 From: johannes_graumann at web.de (Johannes Graumann) Date: Wed, 16 Apr 2008 15:44:20 +0200 Subject: Kontact Singature Validation Issue In-Reply-To: <20080416122703.GA2210@straylight.m.ringlet.net> References: <20080416122703.GA2210@straylight.m.ringlet.net> Message-ID: <200804161544.20604.johannes_graumann@web.de> On Wednesday 16 April 2008 14:27:03 Peter Pentchev wrote: > On Wed, Apr 16, 2008 at 10:00:11AM +0200, Johannes Graumann wrote: > > Hi all, > > > > I have an issue with mail signatures in my mail setup and want to ask > > whether anybody has experienced something similar and/or where to look > > for a solution. > > I standardly MIME-sign my mail using kontact, the kde PIM. Everything > > works fine and the sent mails in the "sent mail" folder validate just > > fine. However, mail I send to myself - no matter through which of a > > number of smtp servers at my disposal - fail the signature test after > > arrival. Might be one element of my overly-elaborate mail collection > > scheme is to blame? It looks like so: > > 1. A number of mail accounts all forewarding to a gmail account > > 2. fetchmail imap-pulling the messages from the gmail account and > > inserting it into a local kolab installation > > 3. kontact imap-retrieves the mail from kolab. > > > > Any insight into this is highly appreciated! > > Can you compare the two e-mail messages - the one in your "sent mail" > folder and the received one in your inbox - and see if they are the > same - and what the differences are? > > I've had a problem with a Microsoft Exchange installation with a slew of > anti-virus software - it took a MIME-signed message and split a header > *in the signed portion* - inserted a new-line character there. > The "new" message was a valid e-mail message, but of course it failed > the signature check :) > > Once you've seen what differences there are between the messages, it > might be easier to figure out which program makes the changes at which > part of the cycle. Thanks. Went and diffed the complete messages as exported to disk ... and sure enough, here we go: # diff Message_Sent Message_Received 0a1 > 2,3c3 < Content-Type: text/plain; < charset="us-ascii" --- > Content-Type: text/plain; charset="us-ascii" 21c21 < Content-Type: application/pgp-signature; name=signature.asc --- > Content-Type: application/pgp-signature; name=signature.asc Since this is happening through multiple smtp servers, it's most likely that it is happening in kolab. I already shifted this over to their newsgroup ... Thanks for your nudge, Joh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jcrisafi at chbullco.com Thu Apr 17 23:23:47 2008 From: jcrisafi at chbullco.com (bul123) Date: Thu, 17 Apr 2008 14:23:47 -0700 (PDT) Subject: Using GPG on a Windows 2003 enterprise server Message-ID: <16756088.post@talk.nabble.com> I have been trying for the last 3-4 month to get GPG working on a company website and just can not get GPG working - I set it up exactly to specs. I can go to a dos prompt and encrypt any file with out problem, but when I try to use any type of scripting - all I get is plain text from a form. Before I completely go bald or bonkers, can someone tell me if it just won't work on a Windows server. Or if someone has a prepared script that they know works on a windows server - would you be willing to share it with me. I currently have the simplesubmit script on there and have everything working in regards to the emailing but I can not get the program to see GPG. Which in turn just sends plain text emails. Thank you in advance for any help. -- View this message in context: http://www.nabble.com/Using-GPG-on-a-Windows-2003-enterprise-server-tp16756088p16756088.html Sent from the GnuPG - User mailing list archive at Nabble.com. From mkinni at calpoly.edu Sat Apr 19 03:31:29 2008 From: mkinni at calpoly.edu (Matt Kinni) Date: Fri, 18 Apr 2008 18:31:29 -0700 Subject: changing the default keyring location in windows Message-ID: <48094B71.9050806@calpoly.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, I want to move my keyring files from %appdata%/gnupg to R:/ I know you can do this somehow, I just can't figure out how. Is there something I can add to ggp.conf? Or is there an environment variable I can set? Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBCAAGBQJICUtcAAoJELlJAlPUfypQccMH/1wiwgo1km1OCjD7QdZYM7c8 7CB3do+HuU4Mm9wRa71zCWuln6/CQM+TsC5X8BAgWr8uRwCPWW4YxF05/3QKBUvv FTd/UDyjMWBY5hAZZTsH4qArvYCUQSviKujsR91izQT6CgGDveUuyDOjg6JPlMCt xOu/EbQ9bFuH7pYkSAEg6Qbee5bvqyFhKj/xS+rNLfeePldTgZdlW3SUEhH1b72Q EFwJ+w3dPuJeSVjdQxjmggzgvC/C0/TYZBzXcpSXF875aLkJYQ5DTqswqBDyUjMl 8ApV2OSct3KiuAIAxKI76aVgTPn4NW8NgB/Yo5u1cHZdmdl5pVmFO62TQgqoFyk= =iHnv -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: OpenPGP digital signature URL: From yonaton at localnet.com Sun Apr 20 14:09:11 2008 From: yonaton at localnet.com (JB2) Date: Sun, 20 Apr 2008 07:09:11 -0500 Subject: Naming of GnuPG In-Reply-To: <1208655728.14929.11.camel@fermat.scientia.net> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <1208655728.14929.11.camel@fermat.scientia.net> Message-ID: <200804200709.11545.yonaton@localnet.com> > > Do people find the 1.4.x / 2.0.x thing confusing? Speaking as a regular Joe, who can do very little cli stuff and just uses Linux (e-mail, web surfing, and an rpg game) because it looks and performs better than winblows and is safer, I'd simply just 'ask' what the difference was if I was new to encryption and such. I don't see the big deal here with the question and all the hulabaloo. -- "Democracy cannot survive overpopulation... The more people there are the less one individual matters." Isaac Asimov From lists at michel-messerschmidt.de Mon Apr 21 10:23:14 2008 From: lists at michel-messerschmidt.de (Michel Messerschmidt) Date: Mon, 21 Apr 2008 10:23:14 +0200 (CEST) Subject: changing the default keyring location in windows In-Reply-To: <48094B71.9050806@calpoly.edu> References: <48094B71.9050806@calpoly.edu> Message-ID: <29121.195.124.114.37.1208766194.squirrel@webmail.artfiles.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Hello, I want to move my keyring files from %appdata%/gnupg to R:/ You can either set GNUPGHOME=R:/ or add/change the entry "HomeDir" in the registry under the key HKEY_CURRENT_USER\Software\GNU\GnuPG Michel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQFIDE7yBi3LpOkEzmoRAvoSAJ4tawtc7qYgrxv6lri4UD1CqhnUfACZAQbw PO1qU0lWyilikCf10jfellA= =aXh4 -----END PGP SIGNATURE----- From jmoore3rd at bellsouth.net Mon Apr 21 10:56:45 2008 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Mon, 21 Apr 2008 04:56:45 -0400 Subject: quickly batch lsign 50 keys? In-Reply-To: <480C3372.3060907@calpoly.edu> References: <480C3372.3060907@calpoly.edu> Message-ID: <480C56CD.3000607@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Matt Kinni wrote: > Hello, I have 50 or so keys I need to --lsign-key as quickly as > possible. Is there any way I can accomplish this in one foul swoop? I suspect that You are doing this to stop the 'Warning Box appearing when Encrypting to Untrusted Keys. :-D The easiest method is to add the following line to gpg.conf trust-model always You can also accomplish this by checking the appropriate box under Enigmail's Preferences. JOHN ;) Timestamp: Monday 21 Apr 2008, 04:54 --400 (Eastern Daylight Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.5.0-svn4748: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: https://www.gswot.org Comment: Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJIDFbKAAoJEBCGy9eAtCsPC40H/2Fg5o0McN9P5wxIzhUBZ1bm PBile/Ae1oIxCf9c0IHIz0lQFAjxaRCuOdKoonCKYqLrxscnKQCPYzKqkaS9Sbbs s071OBGPM745P6OtKgxvtMeXLSkHz2LxtoETRKN73iV8QMCSPfoCnQ3OFImwrtCS t1UZNvAi8cuO07ELgAXYjH0Ldb+gU3CMpbYs5se8a0sX6fsKWb8wfWcXMN3zIbMf rs22Pdbb2AVcsOCuZ+56GJwXbhyyD2YKG/na9H2K0euMxUz35WBlfCdP/KlvAjXA +08rsntBtWBb1HByIoNcnQSdTXvR+5cm+6mNwTrL3lnexqNAx8BO1n2AtVkb2aM= =d7RC -----END PGP SIGNATURE----- From smenzel at gmx-gmbh.de Mon Apr 21 10:45:06 2008 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Mon, 21 Apr 2008 10:45:06 +0200 Subject: [GPGSM][GPGME] thawte freemail certificates? Message-ID: <200804211045.11787.smenzel@gmx-gmbh.de> Hi there, I have a very hard time trying to get a mail signature verified which was created using a Thawte Freemail certificate. I'm using GPGME to access GPGSM. The Problem appears to be not a new one: http://archive.netbsd.se/?ml=gnupg-users&a=2007-07&t=4770328 It says here, the certificate contains the information that it's only fully valid when the CRL has been checked, but fails to specify the location of that CRL. Using KMail with the same backend I can have the siganture valid (green) when I specify "disable-crl-checks" in gpgsm.conf. If I don't, it's yellow (unknown). But gpgme doesn't seem to recognize it. It says "validity=unkown", even when I add the fingerprints of all relevant Thawte root certs in trustlist.txt I know, it sounds all a bit weird, but there must be a way to have Thawte's Freemail signatures verified. Please let me know if I can provide any further information. Thanks and Greetings... Stephan Menzel -- Stephan Menzel, Senior Technical Architect, Spam and virus protection GMX GmbH, Frankfurter Ring 129, D-80807 Muenchen - http://www.gmx.net Telephon +49 89 14339-506, stephan.menzel at 1und1.de Amtsgericht Muenchen HRB 144261, Geschaeftsfuehrer: Eva Heil, Achim Weiss -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From smenzel at gmx-gmbh.de Mon Apr 21 14:15:42 2008 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Mon, 21 Apr 2008 14:15:42 +0200 Subject: [GPGSM][GPGME] thawte freemail certificates? In-Reply-To: <200804211045.11787.smenzel@gmx-gmbh.de> References: <200804211045.11787.smenzel@gmx-gmbh.de> Message-ID: <200804211415.46656.smenzel@gmx-gmbh.de> Am Montag, 21. April 2008 10:45:06 schrieb Stephan Menzel: > I know, it sounds all a bit weird, but there must be a way to have Thawte's > Freemail signatures verified. Please let me know if I can provide any > further information. Of course, there's one thing I can do. I can attach a sample. This mail is signed with one of them vicious Thawte Certificates. Is there a way to have it verified with or without checking CRLs so validity is "valid" and not longer "unknown"? Greetings... Stephan -------------- next part -------------- Return-Path: Delivered-To: GMX delivery to smenzel at gmx-gmbh.de Received: (qmail invoked by alias); 21 Apr 2008 12:05:56 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: test email with thawte freemail signature Date: Mon, 21 Apr 2008 14:06:00 +0200 Content-Type: multipart/signed; micalg=MD5; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0012_01C8A3B8.D23815A0" Message-ID: X-MS-Has-Attach: yes Thread-Topic: test email with thawte freemail signature Thread-Index: AcijqA5uISZSS/bWRuiRryHxBXSlTQ== From: To: "Stephan Menzel" X-GMX-Antivirus: 0 (no virus found) X-GMX-UID: bcVqInN/aHIGT/h+SSQlRCpqamdhZESO X-Length: 7437 X-UID: 27735 This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C8A3B8.D23815A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0013_01C8A3B8.D23815A0" ------=_NextPart_001_0013_01C8A3B8.D23815A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit hi stephan, here is your test email. have fun. thomas ------=_NextPart_001_0013_01C8A3B8.D23815A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi=20 stephan,
 
here = is your test=20 email.
 
 
have = fun.
 
thomas
 
------=_NextPart_001_0013_01C8A3B8.D23815A0-- ------=_NextPart_000_0012_01C8A3B8.D23815A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDjAMBggqhkiG9w0CBQUAMIAGCSqGSIb3DQEHAQAAoIII1DCC AlwwggHFoAMCAQICEBf6PC3lNHSJ3yh1LV6yJbowDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDMzMTExMzUwNVoXDTA5MDMzMTEx MzUwNVowRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYT dHJvZWRlckBnbXgtZ21iaC5kZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyNc62yAvNlQM 6+nNxXJ4HnaOZJyzRegnXz2jE5spfw9dMI5t69mkANXQcksStgo2X4fHWWW9cT2nH/AFXP/XR9wk F3h9eKSCEgnrEzha+DEloOaO6WshCE0eV7bhVuTkk7fb+BnSC2KpOEsbpnEBYtbF1nA7TIEoF86X EVp7XykCAwEAAaMwMC4wHgYDVR0RBBcwFYETdHJvZWRlckBnbXgtZ21iaC5kZTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBQUAA4GBAGF2RAHO9V3Y2AkoCfV6Lndnf9a82o2IVjfXpE/MsBK4EMzP FAfMgEyp9KoXs6TetMJHXMOqJWC6R22DN50fEmTPkGRjWdVGqUBDdvvzfsUbKGfl4+ac+qH273mV +hcStEtY9hK14KO/ggLsBkMYegsYqTwXXZ/TwX+dlOWSMCRbMIIDLTCCApagAwIBAgIBADANBgkq hkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlm aWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2 MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKR sIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOH ePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEA AaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0R YNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UN KOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggLvMIIC6wIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQF/o8LeU0dInfKHUtXrIlujAMBggq hkiG9w0CBQUAoIIBzDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w ODA0MjExMjA1NTdaMB8GCSqGSIb3DQEJBDESBBBEOeqpKmGGNcIr1YhTGGPYMF8GCSqGSIb3DQEJ DzFSMFAwDgYIKoZIhvcNAwICAgCAMAsGCWCGSAFlAgEBBDANBggqhkiG9w0DAgIBQDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAKBggqhkiG9w0CBTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBf6PC3lNHSJ3yh1LV6yJbowgYcGCyqG SIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EC EBf6PC3lNHSJ3yh1LV6yJbowDQYJKoZIhvcNAQEBBQAEgYC6c9Ns+d4d9yKzuNNop/BxM9F4Fe/H Fdy4MRXmmmtUXaH+qjhP5aSDIOTygGCUHm7GEROLAvz4WyIgVk4CA8JcvZ5jNDHfGoPoOUcAtIyS 4j4asPN+Eb6G9lJRoY25JGTYu5rI3BhFg4vRbN8B/MBOxOLY/KIg7vKYltR7Zy4o5AAAAAAAAA== ------=_NextPart_000_0012_01C8A3B8.D23815A0-- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From mwood at IUPUI.Edu Mon Apr 21 15:30:34 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Mon, 21 Apr 2008 09:30:34 -0400 Subject: Naming of GnuPG In-Reply-To: <1208680633.6318.15.camel@carbon> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> Message-ID: <20080421133034.GB7699@IUPUI.Edu> So, GnuPG 1.4 implements OpenPGP. GnuPG 2.0 implements OpenPGP and S/MIME. So 2.0 is "better" than 1.4 if you need S/MIME, otherwise not. So, perhaps 1.4 should be GnuPG and 2.0 should be GnuPG-Plus. (Please, no "++"!) -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From christoph.anton.mitterer at physik.uni-muenchen.de Mon Apr 21 15:42:52 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Mon, 21 Apr 2008 15:42:52 +0200 Subject: Naming of GnuPG In-Reply-To: <20080421133034.GB7699@IUPUI.Edu> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> Message-ID: <1208785372.4955.37.camel@etppc19> On Mon, 2008-04-21 at 09:30 -0400, Mark H. Wood wrote: > So, perhaps 1.4 should be GnuPG and 2.0 should be GnuPG-Plus. > (Please, no "++"!) I think that renaming would actually increase the confusion. It would be better to consider to slowly phase out the 1.4x branch. Chris- From dshaw at jabberwocky.com Mon Apr 21 15:43:01 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 21 Apr 2008 09:43:01 -0400 Subject: Naming of GnuPG In-Reply-To: <20080421133034.GB7699@IUPUI.Edu> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> Message-ID: <2AF9AECC-2F51-49F4-8D53-7E9D3FB648A2@jabberwocky.com> On Apr 21, 2008, at 9:30 AM, Mark H. Wood wrote: > So, GnuPG 1.4 implements OpenPGP. GnuPG 2.0 implements OpenPGP and > S/MIME. > > So 2.0 is "better" than 1.4 if you need S/MIME, otherwise not. > > So, perhaps 1.4 should be GnuPG and 2.0 should be GnuPG-Plus. > (Please, no "++"!) How about: 1.4 == GnuPG Classic 2.0 == GnuPG Plus David From christoph.anton.mitterer at physik.uni-muenchen.de Mon Apr 21 15:55:59 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Mon, 21 Apr 2008 15:55:59 +0200 Subject: Naming of GnuPG In-Reply-To: <2AF9AECC-2F51-49F4-8D53-7E9D3FB648A2@jabberwocky.com> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> <2AF9AECC-2F51-49F4-8D53-7E9D3FB648A2@jabberwocky.com> Message-ID: <1208786159.4955.39.camel@etppc19> On Mon, 2008-04-21 at 09:43 -0400, David Shaw wrote: > How about: > > 1.4 == GnuPG Classic > 2.0 == GnuPG Plus If both should continue to develop (on a long time view) why not: 1.4 == GnuPG Classic 2.0 == GnuPG Chris. From rjh at sixdemonbag.org Mon Apr 21 15:59:46 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 21 Apr 2008 08:59:46 -0500 Subject: Naming of GnuPG In-Reply-To: <1208785372.4955.37.camel@etppc19> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> <1208785372.4955.37.camel@etppc19> Message-ID: <480C9DD2.4020405@sixdemonbag.org> Christoph Anton Mitterer wrote: > I think that renaming would actually increase the confusion. It would > be better to consider to slowly phase out the 1.4x branch. I imagine this idea would get a lot of pushback from 1.4 users. I know that I'd be bothered by it. From christoph.anton.mitterer at physik.uni-muenchen.de Mon Apr 21 15:59:45 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Mon, 21 Apr 2008 15:59:45 +0200 Subject: Naming of GnuPG In-Reply-To: <480C9DD2.4020405@sixdemonbag.org> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> <1208785372.4955.37.camel@etppc19> <480C9DD2.4020405@sixdemonbag.org> Message-ID: <1208786385.4955.41.camel@etppc19> On Mon, 2008-04-21 at 08:59 -0500, Robert J. Hansen wrote: > I imagine this idea would get a lot of pushback from 1.4 users. I know > that I'd be bothered by it. What's the reason? From rjh at sixdemonbag.org Mon Apr 21 16:21:50 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 21 Apr 2008 09:21:50 -0500 Subject: Naming of GnuPG In-Reply-To: <1208786385.4955.41.camel@etppc19> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> <1208785372.4955.37.camel@etppc19> <480C9DD2.4020405@sixdemonbag.org> <1208786385.4955.41.camel@etppc19> Message-ID: <480CA2FE.3020406@sixdemonbag.org> Christoph Anton Mitterer wrote: > What's the reason? My reason, or the general reason? The general reason... pick your poison, really. There are a lot of them. 1. The paranoids. Read alt.security.pgp sometime and you'll find a bunch of people who are in critical need of getting their tinfoil hats readjusted. These are people who continue to use PGP 6.5.8 because "obviously, they closed the source in PGP 7 so they could put in a back door." And then there are people who swear by PGP 2.6 because they heard a rumor somewhere that Phil Z. got off the law-enforcement hook by promising to put a back door in PGP 5+. Even on this list, we've seen people who have come really close to making accusations against Werner of being complicit with law-enforcement authorities. (See "Using Old PC as Hardware Security Module" in the archives, from May of 2007.) If GnuPG 1.4.x suddenly gets marked "deprecated" and begins to be phased out, a whole lot of people are going to start asking "why? Official word on the GnuPG list was that GnuPG 1.4 was still perfectly safe and would be maintained for some time." And those are the good ones. The rest will begin to make conspiracy theories. 2. The conservatives. As David pointed out, being conservative in cryptography is often a sign of maturity. There are a _ton_ of PGP 2.6 users out there who never upgraded because they never saw the need to jump on the bandwagon. If you mark GnuPG 1.4.x as deprecated, you'll see a lot of users just quietly ignore the developers' decision. The question is not whether any OpenPGP changes from 2.0 will be backported to 1.4. They will. The only question is who will do the backporting. The instant the GnuPG developers drop 1.4 support, someone else will pick it up... and maybe not someone who's especially competent. We have already seen this happen with PGP 6.5.8 and Imad Faiad's CKT builds; there is no reason to think the same would not happen to GnuPG. 3. The installed base. GnuPG 1.4 is used in a lot of places. A lot of the installed base simply can't upgrade on a dime. Ask anyone who's worked in telecom precisely how many forests had to be cut down just to make the paperwork involved in making a small change to the deployed software. Healthcare is another high-bureaucracy field. Banking. ... My own reason for pushing back against this idea is #2. However, don't underestimate #s 1 and 3. From wk at gnupg.org Mon Apr 21 16:33:07 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Apr 2008 16:33:07 +0200 Subject: Naming of GnuPG In-Reply-To: <1208785372.4955.37.camel@etppc19> (Christoph Anton Mitterer's message of "Mon, 21 Apr 2008 15:42:52 +0200") References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> <1208785372.4955.37.camel@etppc19> Message-ID: <87ve2buvks.fsf@wheatstone.g10code.de> On Mon, 21 Apr 2008 15:42, christoph.anton.mitterer at physik.uni-muenchen.de said: > I think that renaming would actually increase the confusion. > It would be better to consider to slowly phase out the 1.4x branch. This will not happen. 1.4. builds on a wide variety of platforms whereas 2.0 requires a decent POSIX or Windows platform. 1.4. is really useful. Frankly, I do not see the problem. The BInd folks are running Bind 8 and Bind 9 for a long time already and not long ago Bind 4 was also activly maintained. 2.0 has more features that 1.4 and thus it "better" in the common sense. It is just that if you machine is not powerful (modern) enough, you can't use it. From the OpenPGP perspective tehre is no difference between the two versions. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From christoph.anton.mitterer at physik.uni-muenchen.de Mon Apr 21 16:39:57 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Mon, 21 Apr 2008 16:39:57 +0200 Subject: Naming of GnuPG In-Reply-To: <480CA2FE.3020406@sixdemonbag.org> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> <1208785372.4955.37.camel@etppc19> <480C9DD2.4020405@sixdemonbag.org> <1208786385.4955.41.camel@etppc19> <480CA2FE.3020406@sixdemonbag.org> Message-ID: <1208788797.4955.70.camel@etppc19> On Mon, 2008-04-21 at 09:21 -0500, Robert J. Hansen wrote: > If GnuPG 1.4.x suddenly gets marked "deprecated" and begins to be phased > out, a whole lot of people are going to start asking "why? Official > word on the GnuPG list was that GnuPG 1.4 was still perfectly safe and > would be maintained for some time." And those are the good ones. The > rest will begin to make conspiracy theories. Well I did not ask to mark it deprecated... it's also ok to maintain it for some time (probably one or two years?). But in the end we'll either have two different gpg's (which could lead to a lot of problems, even security related) or one of the two will be phased out. > As David pointed out, being conservative in cryptography is often a sign > of maturity. There are a _ton_ of PGP 2.6 users out there who never > upgraded because they never saw the need to jump on the bandwagon. If > you mark GnuPG 1.4.x as deprecated, you'll see a lot of users just > quietly ignore the developers' decision. Yes,... but than I'd say, that it's even better to "simply" have two different branches and make some explicit statement like "normally everybody (wo has no specific reason against) could use 2.x, it contains everything the 1.4.x has and even more, it will also contain all features of future developments".. than using two different names. Something like "classic/plus" could even more confuse the average user. On the other hand,... if we actually want to spread the use of 2.x we should perhaps suggest the distributors to use the 2.x branch as default (i.e. the package named gnupg) and provide 1.4.x as something like gnupg14. Current practise (at least in debian) is 1.4.x package: gnupg executable: gpg 2.x package: gnupg2 executable: gpg2 > The question is not whether any OpenPGP changes from 2.0 will be > backported to 1.4. They will. Ok,.. but to backport nearly everything would make little sense,... in that case we could simply add the CMS stuff to gpg 1.4.x and drop 2.x completely ;) What if ECC or V5 keys will finally come? Should they be backported? > GnuPG 1.4 is used in a lot of places. A lot of the installed base > simply can't upgrade on a dime. Ask anyone who's worked in telecom > precisely how many forests had to be cut down just to make the paperwork > involved in making a small change to the deployed software. Healthcare > is another high-bureaucracy field. Banking. Uhm,.. the only problem that I could see here are possible build problems with 2.x (are there any?). Any I never asked to stop security support for the 1.4.x branch, I just suggested to let the main development take place in 2.x and to explicitly state this. Best wishes, Chris. From wk at gnupg.org Mon Apr 21 16:36:37 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Apr 2008 16:36:37 +0200 Subject: [GPGSM][GPGME] thawte freemail certificates? In-Reply-To: <200804211045.11787.smenzel@gmx-gmbh.de> (Stephan Menzel's message of "Mon, 21 Apr 2008 10:45:06 +0200") References: <200804211045.11787.smenzel@gmx-gmbh.de> Message-ID: <87r6czuvey.fsf@wheatstone.g10code.de> On Mon, 21 Apr 2008 10:45, smenzel at gmx-gmbh.de said: > Using KMail with the same backend I can have the siganture valid (green) when > I specify "disable-crl-checks" in gpgsm.conf. If I don't, it's yellow Check the dirmngr's log file. Are all certificates for the CRL available to dirmngr? Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From christoph.anton.mitterer at physik.uni-muenchen.de Mon Apr 21 16:44:29 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Mon, 21 Apr 2008 16:44:29 +0200 Subject: Naming of GnuPG In-Reply-To: <87ve2buvks.fsf@wheatstone.g10code.de> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> <1208785372.4955.37.camel@etppc19> <87ve2buvks.fsf@wheatstone.g10code.de> Message-ID: <1208789069.4955.75.camel@etppc19> On Mon, 2008-04-21 at 16:33 +0200, Werner Koch wrote: > This will not happen. 1.4. builds on a wide variety of platforms > whereas 2.0 requires a decent POSIX or Windows platform. I've already thought that... > Frankly, I do not see the problem. The BInd folks are running Bind 8 > and Bind 9 for a long time already and not long ago Bind 4 was also > activly maintained. Well I don't have a problem too. The only things that I wanted to suggest when I've entered this thread was: - Don't use different names for different gnupg branches. - Set up some place (perhaps in the FAQ and even in the download area) where you just say all that, namely: New features will probably go to 2.x, both will have the same security support, for the places where both provide the same stuff (openPGP) both provide exactly the same features... etc. Best wishes, Chris. From rjh at sixdemonbag.org Mon Apr 21 16:51:05 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 21 Apr 2008 09:51:05 -0500 Subject: Naming of GnuPG In-Reply-To: <1208788797.4955.70.camel@etppc19> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> <1208785372.4955.37.camel@etppc19> <480C9DD2.4020405@sixdemonbag.org> <1208786385.4955.41.camel@etppc19> <480CA2FE.3020406@sixdemonbag.org> <1208788797.4955.70.camel@etppc19> Message-ID: <480CA9D9.8070506@sixdemonbag.org> Christoph Anton Mitterer wrote: > Well I did not ask to mark it deprecated... it's also ok to maintain it > for some time (probably one or two years?). You said to phase it out. The engineering term for that is "deprecation". When something is marked deprecated, that means it works now but there are active plans to move on to something else. > But in the end we'll either have two different gpg's (which could lead > to a lot of problems, even security related) or one of the two will be > phased out. The latter will not happen, judging from our experiences with PGP 2.6. >> The question is not whether any OpenPGP changes from 2.0 will be >> backported to 1.4. They will. > > Ok,.. but to backport nearly everything would make little sense,... in > that case we could simply add the CMS stuff to gpg 1.4.x and drop 2.x > completely ;) Please read what I wrote. I did not say everything from 2.0 would be backported. I said OpenPGP changes would be. > What if ECC or V5 keys will finally come? Should they be backported? They would be backported. Look at how many hacks people have come up with to the 2.6 codebase to support new ciphers, new hash algorithms, new... etc. The only question is who backports them. Keep in mind that I'm not saying wk, David, etc., are forced to do the backporting. I'm just saying that it will happen even if they wash their hands of it. 1.4 is not going anywhere, for two very big reasons: 1. Werner has said it's not going anywhere 2. The community won't let it go anywhere Any proposal of "well, we should phase out GnuPG 1.4" needs to address both of those reasons why phasing it out is impractical. > Uhm,.. the only problem that I could see here are possible build > problems with 2.x (are there any?). Tons. Building on POSIX is pretty easy. Building on Windows is a torment of the damned -- I think the way the developers do it is with a cross-compiler hosted on a UNIX system. I don't even want to think about building it on OS/2 or VMS. From walter at torres.ws Mon Apr 21 17:25:08 2008 From: walter at torres.ws (Walter Torres) Date: Mon, 21 Apr 2008 09:25:08 -0600 Subject: changing the default keyring location in windows In-Reply-To: <48094B71.9050806@calpoly.edu> References: <48094B71.9050806@calpoly.edu> Message-ID: <20080421092508.xa77n8or6s80og0c@69.89.31.199> Quoting Matt Kinni : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello, I want to move my keyring files from %appdata%/gnupg to R:/ > > I know you can do this somehow, I just can't figure out how. Is there > something I can add to ggp.conf? Or is there an environment variable I > can set? Matt, First, take a look at my wiki, it describes how I install GnuGP and moved the files to where I think they should belong... http://walters-way.com/doku.php/wamp:security:gpg Second, it seems that my description is a bit old since a non-installer ZIP is no longer offer. I hope my method of moving the keys still works, but... Gnu Gurus at large, I would love to have a non-installer ZIP version available again. I don't like installers. I don't know where files are being put. I don't know what keys are being created. Take a look at my install method. (Above URL) My methodology has a linux-type setup on my windows. Files "live" where they are supposed to live (as if it was a linux box). Yes, I know, "if you want linux Walter, why not just use linux ". Long story. But that doesn't change the fact that too many Gnu apps developers for Windows think they have to change the way the Gnu app works (or at least where the files reside) because they are on Windows. Registry keys are not mandatory! You can develop an app without them, for the most part. I don't have a single file in my Windows System directory. I have only 4 or 5 registry keys (and 2 of them are for GnuGP!). When my Windows machine needs to be rebuilt (and as you know, Windows does far too often!) I don't have to spend days rebuilding my linux side. All my "linux apps" are on their own volume, so they are not effected when I wipe C: drive. Then all I do is re-enter the ENV VARS (and the 4 or 5 keys) and I'm back in business. 10 minutes and I done! And BTW: GnuGP and the USERS directory path directive in Apache are the only two items that I *have* to use a volume letter. I don't know if the "left click and encrpyt" feature (I like that one!) can be moved from the registry, but I do know that the KEYS location can be removed from the registry. If GnuGP used the HOME ENV VAR (or at least looked for it) than that key could be removed. Hope someone understands all this. Walter From reynt0 at cs.albany.edu Mon Apr 21 20:02:43 2008 From: reynt0 at cs.albany.edu (reynt0) Date: Mon, 21 Apr 2008 14:02:43 -0400 (EDT) Subject: Naming of GnuPG In-Reply-To: <1208789069.4955.75.camel@etppc19> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> <1208785372.4955.37.camel@etppc19> <87ve2buvks.fsf@wheatstone.g10code.de> <1208789069.4955.75.camel@etppc19> Message-ID: On Mon, 21 Apr 2008, Christoph Anton Mitterer wrote: . . . > - Set up some place (perhaps in the FAQ and even in the download area) > where you just say all that, namely: New features will probably go to > 2.x, both will have the same security support, for the places where both > provide the same stuff (openPGP) both provide exactly the same > features... etc. FWIW, one way to make this information clear would be to make it part of a *theme* of information presentation. For example, something like starting the FAQ, and maybe starting any page which contains much information, with something like (I'm quickly now trying to use grammatical forms which are as globally language-neutral as possible): "To use encryption wisely requires thought and making decisions. GnuPG is not an exception. One decision is which version of GnuPG to use." And then bla bla bla about what the different versions are like, and so on. This could set up a cognition structure ("What is the decision being worked on?") within which various information, not only version information, could be presented efficiently; and doing so might take some of the confusion out of applied PKI, leaving only the complexity. For people who want a turnkey encryption package (which is something to which I have no opposition), this kind of theme (mantra??) could be a clue they'll maybe have to ask for help from people who provide such, or else be prepared to do some thinking on their own. As I said, FWIW, & HTH. From CronoCloud at mchsi.com Mon Apr 21 21:18:32 2008 From: CronoCloud at mchsi.com (Ron Rogers Jr.) Date: Mon, 21 Apr 2008 14:18:32 -0500 Subject: [GPGSM][GPGME] thawte freemail certificates? In-Reply-To: <200804211415.46656.smenzel@gmx-gmbh.de> References: <200804211045.11787.smenzel@gmx-gmbh.de> <200804211415.46656.smenzel@gmx-gmbh.de> Message-ID: <20080421141832.5e08b77a@mchsi.com> On Mon, 21 Apr 2008 14:15:42 +0200 Stephan Menzel wrote: > > Of course, there's one thing I can do. I can attach a sample. > > This mail is signed with one of them vicious Thawte > Certificates. Is there a way to have it verified with or > without checking CRLs so validity is "valid" and not longer > "unknown"? > The sample checks out fine for me: "Good signature from Thawte Freemail Member", using Claws-Mail with gpgme/gpgsm S/MIME plugin. Can you verify my S/MIME signature? Ron Rogers Jr. (CronoCloud) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1355 bytes Desc: not available URL: From JPClizbe at tx.rr.com Mon Apr 21 22:04:13 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Mon, 21 Apr 2008 15:04:13 -0500 Subject: changing the default keyring location in windows In-Reply-To: <48094B71.9050806@calpoly.edu> References: <48094B71.9050806@calpoly.edu> Message-ID: <480CF33D.60106@tx.rr.com> Matt Kinni wrote: > Hello, I want to move my keyring files from %appdata%/gnupg to R:/ > > I know you can do this somehow, I just can't figure out how. Is there > something I can add to ggp.conf? Or is there an environment variable I > can set? The answer to both is yes, but each is a separate solution. There are four methods that I know. The first three require you additionally move gpg.conf. All require that you move the three keyring files: pubring.gpg, secring.gpg, & trustdb.gpg. 1) Add --homedir= to _every_ invocation of gpg. Fine if you don't ever make tpyos and don't forget to add it. 2) Set the environment variable GNUPGHOME to the location. Best done in the User variables part of the Environment variable panel of System properties. (Control panel --> System --> Advanced --> 'Environment Variables' button) 3) Change the value of HomeDir in the HKCU\Software\Gnu\GnuPG key. Some users are uncomfortable directly editing the Registry. Later runs of the installer may or may not mess with this. Most likely not, feeling lucky? 4) Set values in gpg.conf to redirect the location. (My preferred method) Add the following lines to gpg.conf: no-default-keyring primary-keyring R:\pubring.gpg secret-keyring R:\secring.gpg trustdb-name R:\trustdb.gpg You may also need keyring R:\pubring.gpg Depending on the size of your portable storage device, you may find organizing with directories a bit easier. I use O;\GnuPG and O:\PGP for my keyrings BTW, I may have forgotten to mention it over the weekend. Please turn HTML composition off completely with (Open)PGP. It produces messages that usually will fail signature verification. It will sometimes work, but rarely. format=flowed is another message composition "feature" that tends to break signatures. It's most common in Mozilla mailers. -John -- John P. Clizbe Inet: JPClizbe (a) tx DAWT rr DAHT con Ginger Bear Networks hkp://keyserver.gingerbear.net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 677 bytes Desc: OpenPGP digital signature URL: From jmoore3rd at bellsouth.net Mon Apr 21 22:04:45 2008 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Mon, 21 Apr 2008 16:04:45 -0400 Subject: Naming of GnuPG In-Reply-To: <1208785372.4955.37.camel@etppc19> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> <1208785372.4955.37.camel@etppc19> Message-ID: <480CF35D.7000609@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Christoph Anton Mitterer wrote: > It would be better to consider to slowly phase out the 1.4x branch. I disagree! I much prefer using the 1.4.x Branch in static format because it is faster, smaller and not dependent upon accessing so many independent libraries. Additionally, I have no use for the S/MIME capabilities contained within the 2.0.x Trunk. IMHO, the labels 'Branch' & Trunk' should be sufficient to designate between the 2 versions. JOHN ;) Timestamp: Monday 21 Apr 2008, 16:04 --400 (Eastern Daylight Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.5.0-svn4748: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: https://www.gswot.org Comment: Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJIDPNcAAoJEBCGy9eAtCsP7ZgIAKCJj3Y6WFHShvMxO0HcyOOC 03c9GQ3vbdxf3i/f3lcQwjX6bbLr6/ARNzrudInbWHjVMCCsaNrCxZvdhrGoLlE3 C5JpAJvHwctTUaBViPcCwHEP0gM2uNjw2BCPzDDF+JQqiSRQ8NkTfZw7p9Oup1QP h/538om8n0IMlG+GIa1XuhMqYoZvoe1hVGSmbzral44n9EjuICn9iBFQT9D6yDnJ QxTA0h32Pd2KGWfNW58E90rAxwI2noyDkSJ9ayhvPq9OP8v0+IxOYEqb6Qkyvj/2 dt+e6GNhkDiRK1ZStYWilWdpqpiGRBaEEzhqAB+du7Hjscin33iVlF0uRQyDl4o= =q7aV -----END PGP SIGNATURE----- From mkinni at calpoly.edu Mon Apr 21 22:14:34 2008 From: mkinni at calpoly.edu (Matt Kinni) Date: Mon, 21 Apr 2008 13:14:34 -0700 Subject: changing the default keyring location in windows In-Reply-To: <480CF33D.60106@tx.rr.com> References: <48094B71.9050806@calpoly.edu> <480CF33D.60106@tx.rr.com> Message-ID: <480CF5AA.4010206@calpoly.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I got it working, thanks John! John Clizbe wrote: | Matt Kinni wrote: |> Hello, I want to move my keyring files from %appdata%/gnupg to R:/ |> |> I know you can do this somehow, I just can't figure out how. Is there |> something I can add to ggp.conf? Or is there an environment variable I |> can set? | | The answer to both is yes, but each is a separate solution. | | There are four methods that I know. The first three require you additionally | move gpg.conf. All require that you move the three keyring files: pubring.gpg, | secring.gpg, & trustdb.gpg. | | 1) Add --homedir= to _every_ invocation of gpg. Fine if you don't ever make | tpyos and don't forget to add it. | | 2) Set the environment variable GNUPGHOME to the location. Best done in the User | variables part of the Environment variable panel of System properties. (Control | panel --> System --> Advanced --> 'Environment Variables' button) | | 3) Change the value of HomeDir in the HKCU\Software\Gnu\GnuPG key. Some users | are uncomfortable directly editing the Registry. Later runs of the installer may | or may not mess with this. Most likely not, feeling lucky? | | 4) Set values in gpg.conf to redirect the location. (My preferred method) | Add the following lines to gpg.conf: | | no-default-keyring | primary-keyring R:\pubring.gpg | secret-keyring R:\secring.gpg | trustdb-name R:\trustdb.gpg | | You may also need | keyring R:\pubring.gpg | | Depending on the size of your portable storage device, you may find organizing | with directories a bit easier. I use O;\GnuPG and O:\PGP for my keyrings | | BTW, I may have forgotten to mention it over the weekend. Please turn HTML | composition off completely with (Open)PGP. It produces messages that usually | will fail signature verification. It will sometimes work, but rarely. | | format=flowed is another message composition "feature" that tends to break | signatures. It's most common in Mozilla mailers. | | -John | | | | ------------------------------------------------------------------------ | | _______________________________________________ | Gnupg-users mailing list | Gnupg-users at gnupg.org | http://lists.gnupg.org/mailman/listinfo/gnupg-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBCAAGBQJIDPWoAAoJELlJAlPUfypQqvQH/jlnCoKo1eBR+sMuiqCcPjje n52ozl/9RCEb951ndN9IqJ/qkMp6XgrXIyVlMtv/pJ09VVuTF4F54vYkknEeCpno AyIWiph/APYudbSCXdPy3Iqj1y7lnBHENlg96zvCIjJ8RCQrNojAqaY2iatoSnF4 4fbIINQF7vblATMb+N2ixnfw7e3Li8J5hwbzeWz34H5rQSYHtlODDr8FM5o9Kq1S FydANravrQan5cQIBERy43pE5rj50O57cjOr8Zz2XvnpbhyuJK48ZTi7gSum3VsB +Vdy+4RuGYvRQBCMilxs+/9fMLg/YlVc4k1+fOVoGtyqWjzBsefLrDKZoy5yu/w= =JkJN -----END PGP SIGNATURE----- From JPClizbe at tx.rr.com Mon Apr 21 22:17:24 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Mon, 21 Apr 2008 15:17:24 -0500 Subject: Naming of GnuPG In-Reply-To: <480CF35D.7000609@bellsouth.net> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> <1208785372.4955.37.camel@etppc19> <480CF35D.7000609@bellsouth.net> Message-ID: <480CF654.6070801@tx.rr.com> John W. Moore III wrote: > Additionally, I have no use for the S/MIME capabilities contained within the > 2.0.x Trunk. Which is why I think the name GnuPG-Plus makes sense for 2.0. 2.0 is OpenPGP *plus* S/MIME -- John P. Clizbe Inet: JPClizbe (a) tx DAWT rr DAHT con Ginger Bear Networks hkp://keyserver.gingerbear.net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 677 bytes Desc: OpenPGP digital signature URL: From jmoore3rd at bellsouth.net Mon Apr 21 22:22:00 2008 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Mon, 21 Apr 2008 16:22:00 -0400 Subject: Naming of GnuPG In-Reply-To: <1208788797.4955.70.camel@etppc19> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> <1208785372.4955.37.camel@etppc19> <480C9DD2.4020405@sixdemonbag.org> <1208786385.4955.41.camel@etppc19> <480CA2FE.3020406@sixdemonbag.org> <1208788797.4955.70.camel@etppc19> Message-ID: <480CF768.1010202@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Christoph Anton Mitterer wrote: > But in the end we'll either have two different gpg's (which could lead > to a lot of problems, even security related) or one of the two will be > phased out. How do You reach this conclusion? "different GPG's" is far from accurate since the Cryptographic code is identical in both the Branch & the Trunk. The only 'difference' is the inclusion of S/MIME capability within the 2.x Trunk. This 'feature' is used by a small minority & I see no reason to force 'extra capability' upon those who have no desire for it. :-\ > On the other hand,... if we actually want to spread the use of 2.x we > should perhaps suggest the distributors to use the 2.x branch as default > (i.e. the package named gnupg) and provide 1.4.x as something like > gnupg14. Default = forced, IMHO. > What if ECC or V5 keys will finally come? Should they be backported? The WG has discussed this and backwards compatibility [as pertains to the mandatory cipher] has been somewhat agreed on. I am confident that some form of backwards compatibility will be present when ECC becomes commonplace. :-D > Any I never asked to stop security support for the 1.4.x branch, I just > suggested to let the main development take place in 2.x and to > explicitly state this. At present the majority of R&D is focused upon the 2.x Trunk and desirable features & fixes are rapidly backported into the 1.4.x Branch. What caused You to assume different? JOHN ;) Timestamp: Monday 21 Apr 2008, 16:20 --400 (Eastern Daylight Time) - -- "One of the greatest delusions in the world is the HOPE that the evils of this world are to be cured by legislation" Thomas B. Reed (1886) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.5.0-svn4748: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: https://www.gswot.org Comment: Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJIDPdnAAoJEBCGy9eAtCsPFPgH/iL/zzER9D21FMa0L99cYP7R /KkhNjxfXnNHV62ljxWN/gF+qGrXbPqIDcolVxqtWGcJ1MCGGqdessAKNrQKSHCO 14Zd+LtvbsxG/7ZhEutGs+x3UH6pomRDT6FWAZi/zd1fwy/TTuJtYoCnNBb64/zE QVMhiC5irArbI8LA6Lh3V4fHZeP76wm/ezU6AkENvd/191sBdeeRF4H/hTkyRT0A l+41KJEEmXCSNVs7d4t1ir7X4sXG3PRzMYoVS5aJ7ub4w2mRzeY7YcjX255+waIH jcdNYgMDQ34aLaN0ovCjjx/97vd3ADyJDDtejwfmv4hqaitKX6+pqE75aYaN0Y8= =7Z90 -----END PGP SIGNATURE----- From hidekis at gmail.com Mon Apr 21 22:24:28 2008 From: hidekis at gmail.com (Hideki Saito) Date: Mon, 21 Apr 2008 13:24:28 -0700 Subject: Naming of GnuPG In-Reply-To: <87ve2buvks.fsf@wheatstone.g10code.de> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> <1208785372.4955.37.camel@etppc19> <87ve2buvks.fsf@wheatstone.g10code.de> Message-ID: <480CF7FC.4060300@gmail.com> I think this is well appropriate in backend situation, however, GnuPG intended for general users. I often advocate use of GnuPG, and OpenPGP to people, and, from that experience, I think making this clear makes it much easier for people to adopt it. (it won't be necessary showstopper for them, but then I think it wouldn't hurt...) > > Frankly, I do not see the problem. The BInd folks are running Bind 8 > and Bind 9 for a long time already and not long ago Bind 4 was also > activly maintained. > > From tcurdt at vafer.org Mon Apr 21 23:55:29 2008 From: tcurdt at vafer.org (Torsten Curdt) Date: Mon, 21 Apr 2008 23:55:29 +0200 Subject: upgrading from 1.x to 2.x Message-ID: <61EA07CF-25F7-47AE-A5A9-83752F9E84B6@vafer.org> I have just "migrated" from 1.x to 2. (just installed 2.x instead of 1.x) and while I can still sign files with $ gpg2 --armor --output test.asc --detach-sig test refreshing the keys fails. $ gpg2 --refresh-keys an mpi of size 0 is not allowed gpg: keyring_get_keyblock: read error: Invalid packet gpg: error reading keyblock: Invalid keyring gpg: keyserver refresh failed: Invalid keyring And even importing a file that (at least) looks perfectly OK gives me $ gpg2 --import msg.asc gpg: no valid OpenPGP data found. gpg: Total number processed: 0 This is GnuPG 2.0.8 on OSX 10.5.2 installed via MacPorts Any hints? cheers -- Torsten From wk at gnupg.org Tue Apr 22 08:30:21 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Apr 2008 08:30:21 +0200 Subject: Naming of GnuPG In-Reply-To: <1208788797.4955.70.camel@etppc19> (Christoph Anton Mitterer's message of "Mon, 21 Apr 2008 16:39:57 +0200") References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> <1208785372.4955.37.camel@etppc19> <480C9DD2.4020405@sixdemonbag.org> <1208786385.4955.41.camel@etppc19> <480CA2FE.3020406@sixdemonbag.org> <1208788797.4955.70.camel@etppc19> Message-ID: <871w4ytn9e.fsf@wheatstone.g10code.de> On Mon, 21 Apr 2008 16:39, christoph.anton.mitterer at physik.uni-muenchen.de said: > What if ECC or V5 keys will finally come? Should they be backported? It is unlikely that this will go into 1.4 - these would be huge changes and I see no reason to backport them. If you really want this future OpenPGP you need to invest a lot of time to deploy it and thus the desciosn whether to use 1.4 or 2.0 would be a minor one. > Uhm,.. the only problem that I could see here are possible build > problems with 2.x (are there any?). Sure. It might even build on some platforms but won't be usable due to missing OS features (descriptor passing comes to mind). > Any I never asked to stop security support for the 1.4.x branch, I just > suggested to let the main development take place in 2.x and to > explicitly state this. That is already the case. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Tue Apr 22 08:33:12 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Apr 2008 08:33:12 +0200 Subject: Naming of GnuPG In-Reply-To: <480CA9D9.8070506@sixdemonbag.org> (Robert J. Hansen's message of "Mon, 21 Apr 2008 09:51:05 -0500") References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <480AC4BF.4060702@calpoly.edu> <480AC65F.3000104@sixdemonbag.org> <8522A7BA-1DC0-4716-B335-20B8E9D24535@Royds.net> <1208680633.6318.15.camel@carbon> <20080421133034.GB7699@IUPUI.Edu> <1208785372.4955.37.camel@etppc19> <480C9DD2.4020405@sixdemonbag.org> <1208786385.4955.41.camel@etppc19> <480CA2FE.3020406@sixdemonbag.org> <1208788797.4955.70.camel@etppc19> <480CA9D9.8070506@sixdemonbag.org> Message-ID: <87wsmqs8k7.fsf@wheatstone.g10code.de> On Mon, 21 Apr 2008 16:51, rjh at sixdemonbag.org said: > Any proposal of "well, we should phase out GnuPG 1.4" needs to address > both of those reasons why phasing it out is impractical. Nobody would suggest to remove Awk from Unix because everyone uses perl these days. Well, almost everyone but tehre are a lot of awk people. Same with 1.4 I think. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Tue Apr 22 08:47:06 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Apr 2008 08:47:06 +0200 Subject: changing the default keyring location in windows In-Reply-To: <20080421092508.xa77n8or6s80og0c@69.89.31.199> (Walter Torres's message of "Mon, 21 Apr 2008 09:25:08 -0600") References: <48094B71.9050806@calpoly.edu> <20080421092508.xa77n8or6s80og0c@69.89.31.199> Message-ID: <87skxes7x1.fsf@wheatstone.g10code.de> On Mon, 21 Apr 2008 17:25, walter at torres.ws said: > I would love to have a non-installer ZIP version available again. I > don't like installers. I don't know where files are being put. I don't > know what keys are being created. Most people demanded an installer and thus we provide an installer. Creating a ZIP version would just be too much overhead in terms of testing and maintaining. You may use Wine on a Unix box to extract the files and zip them up. Or write a tool for nsis to repackage an nsis installer as zip file. > Windows. Registry keys are not mandatory! You can develop an app > without them, for the most part. GnuPG should work just fine without any GnuPG specific registry key. We use the standard locations under Windows and the Registry is just one way to override it. GNUPGHOME is another one. > And BTW: GnuGP and the USERS directory path directive in Apache are > the only two items that I *have* to use a volume letter. Why to you need to use a drive letter? It works without. > location can be removed from the registry. If GnuGP used the HOME ENV > VAR (or at least looked for it) than that key could be removed. There is no HOME envvar under Windows. The best approximation is the CSIDL_APPDATA identifier used with shgetfolderpath. That is why we use it. We can't use HOME optionally because it would brak too much. HOME might be set by some users for certain applications and it would come to a big surprise if GnuPG would suddenly make use of it. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Tue Apr 22 08:54:28 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Apr 2008 08:54:28 +0200 Subject: upgrading from 1.x to 2.x In-Reply-To: <61EA07CF-25F7-47AE-A5A9-83752F9E84B6@vafer.org> (Torsten Curdt's message of "Mon, 21 Apr 2008 23:55:29 +0200") References: <61EA07CF-25F7-47AE-A5A9-83752F9E84B6@vafer.org> Message-ID: <87od82s7kr.fsf@wheatstone.g10code.de> On Mon, 21 Apr 2008 23:55, tcurdt at vafer.org said: > refreshing the keys fails. > > $ gpg2 --refresh-keys > an mpi of size 0 is not allowed > gpg: keyring_get_keyblock: read error: Invalid packet Incidently this problem was reported to me yesterday and figured out that the http key helper tool did not worked at all. Teh windows socket layer was not initialized and at another point we did a dup for a socket which is not going to work. I don't know why this bug lurked around for so long. It might be that gpg2 accidently used the gpg1 key helper tools (which works) or that we only tested direct hkp server and finger support. Fixed in svn. > And even importing a file that (at least) looks perfectly OK gives me > > $ gpg2 --import msg.asc > gpg: no valid OpenPGP data found. > gpg: Total number processed: 0 > > This is GnuPG 2.0.8 on OSX 10.5.2 installed via MacPorts Well, this is anotehr problem. I bet the msg.asc is not okay or there is a problem with the MacPorts version of gpg2. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From smenzel at gmx-gmbh.de Tue Apr 22 09:24:42 2008 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Tue, 22 Apr 2008 09:24:42 +0200 Subject: [GPGSM][GPGME] thawte freemail certificates? In-Reply-To: <20080421141832.5e08b77a@mchsi.com> References: <200804211045.11787.smenzel@gmx-gmbh.de> <200804211415.46656.smenzel@gmx-gmbh.de> <20080421141832.5e08b77a@mchsi.com> Message-ID: <200804220924.42887.smenzel@gmx-gmbh.de> Am Montag, 21. April 2008 21:18:32 schrieb Ron Rogers Jr.: > > This mail is signed with one of them vicious Thawte > > Certificates. Is there a way to have it verified with or > > without checking CRLs so validity is "valid" and not longer > > "unknown"? > > The sample checks out fine for me: "Good signature from Thawte > Freemail Member", using Claws-Mail with gpgme/gpgsm S/MIME > plugin. Can you verify my S/MIME signature? Yes, I can, but under the same limitations. When I activate "disable-crl-checks" it is green, when I don't it's yellow. Same now with gpgme! I realized yesterday after working on this bugger for 4 days that I do the validation remote on a different machine, which I forgot and kept wondering why my local changes had no effect whatsoever ;-) Given that I wrote that remote daemon and set up this architecture long ago it gives me a new impression about the meaning of the word irony. Anyway, i think given the way those thawte certificates are made, the above behaviour is how it should be: The CRL can't be checked because it's not specified in the certificate and so the signature is only valid as long as I trust the certificate and disable CRL checks. Or am I wrong here? Greetings... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From tcurdt at vafer.org Tue Apr 22 09:41:09 2008 From: tcurdt at vafer.org (Torsten Curdt) Date: Tue, 22 Apr 2008 09:41:09 +0200 Subject: upgrading from 1.x to 2.x In-Reply-To: <87od82s7kr.fsf@wheatstone.g10code.de> References: <61EA07CF-25F7-47AE-A5A9-83752F9E84B6@vafer.org> <87od82s7kr.fsf@wheatstone.g10code.de> Message-ID: <4118C9F4-E7AD-41AE-BA04-079535834839@vafer.org> Hey Werner, Thanks for the response! >> refreshing the keys fails. >> >> $ gpg2 --refresh-keys >> an mpi of size 0 is not allowed >> gpg: keyring_get_keyblock: read error: Invalid packet > > Incidently this problem was reported to me yesterday and figured out > that the http key helper tool did not worked at all. Teh windows > socket > layer was not initialized and at another point we did a dup for a > socket > which is not going to work. uh! ....but then using hkp should work for the update, right? > I don't know why this bug lurked around for > so long. It might be that gpg2 accidently used the gpg1 key helper > tools (which works) or that we only tested direct hkp server and > finger > support. But actually I don't think this is download related. $ gpg2 --list-keys /Users/tcurdt/.gnupg/pubring.gpg -------------------------------- pub 1024D/7C200941 2004-04-24 uid Torsten Curdt uid Torsten Curdt sub 1024g/87C5307C 2004-04-24 ... list some more keys - but not all ... an mpi of size 0 is not allowed gpg: keyring_get_keyblock: read error: Invalid packet gpg: keydb_get_keyblock failed: Invalid keyring Seems like also other people run into it http://lists.opensuse.org/opensuse-bugs/2007-09/msg05835.html http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463270 http://www.gossamer-threads.com/lists/gnupg/devel/43532?page=last Fankly speaking - it awfully reminds me on a problem I run into with 1.x before ...that was fixed in later releases of 1.x http://marc.info/?l=gnupg-devel&m=114694741924376&w=2 http://lists.gnupg.org/pipermail/gnupg-users/2006-May.txt >> And even importing a file that (at least) looks perfectly OK gives me >> >> $ gpg2 --import msg.asc >> gpg: no valid OpenPGP data found. >> gpg: Total number processed: 0 >> >> This is GnuPG 2.0.8 on OSX 10.5.2 installed via MacPorts > > Well, this is anotehr problem. I bet the msg.asc is not okay or there > is a problem with the MacPorts version of gpg2. -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.6 (GNU/Linux) hQEOAz5rX/KHxTB8EAP/QqFwC0/p/6l7mRLvojOA+WjBq74URkaX6W6L4YPrpDvq L42waXpfAhMmjLe3zw35+7ViLd/nICP8JB8Qjtbdt3iMIST62IMHbA1L9PxO7BHS jRs+MwbEzddPnh3Gn/sDdiz3kmq810BcXKpFNuGCIyBqTu8zwxjVhs2nvI1tbBoD /1wjSpCoJkeG76ZD5sbewiRE2H0Ft2P/S7GqTF6BtWmg1bpCHIN4O0uzkfex0jvk .... ftWzVVsGPI8qjtfruCzRiRjjNF/a1ErnVWFR/V6fe7bTUNAgouuUJzKWDLdKc56E IpcZ1wUPl/zKFVdIwhNP9RUf3gfZKBzySs/xWRs= =yoCf -----END PGP MESSAGE----- ...looks quite OK to me :-/ cheers -- Torsten From alokkumar.yadav at gdatech.co.in Tue Apr 22 14:51:06 2008 From: alokkumar.yadav at gdatech.co.in (Alok Kumar Yadav) Date: Tue, 22 Apr 2008 12:51:06 +0000 Subject: Reg:Cross compilation problem libgcrypt-1.2.4 against Powerpc Message-ID: <480DDF3A.5080807@gdatech.co.in> Hi Libgcrypt-Team , I am crosscompiling libgcrypt-1.2.4 against powerpc.But I am suffering from a problem while doing make. log is : ****************************************************** [root at localhost libgcrypt-1.2.4]# make make all-recursive make[1]: Entering directory `/root/Desktop/libcrypt/libgcrypt-1.2.4' Making all in m4 make[2]: Entering directory `/root/Desktop/libcrypt/libgcrypt-1.2.4/m4' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/root/Desktop/libcrypt/libgcrypt-1.2.4/m4' Making all in mpi make[2]: Entering directory `/root/Desktop/libcrypt/libgcrypt-1.2.4/mpi' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/root/Desktop/libcrypt/libgcrypt-1.2.4/mpi' Making all in cipher make[2]: Entering directory `/root/Desktop/libcrypt/libgcrypt-1.2.4/cipher' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/root/Desktop/libcrypt/libgcrypt-1.2.4/cipher' Making all in src make[2]: Entering directory `/root/Desktop/libcrypt/libgcrypt-1.2.4/src' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/root/Desktop/libcrypt/libgcrypt-1.2.4/src' Making all in doc make[2]: Entering directory `/root/Desktop/libcrypt/libgcrypt-1.2.4/doc' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/root/Desktop/libcrypt/libgcrypt-1.2.4/doc' Making all in tests make[2]: Entering directory `/root/Desktop/libcrypt/libgcrypt-1.2.4/tests' /bin/sh ../libtool --tag=CC --mode=link /opt/freescale/usr/local/gcc-4.1.78-eglibc-2.5.78-dp-2/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-gcc -I/usr/local/libgpg-error/include/ -Wall -L/usr/local/libgpg-error/lib -o prime prime.o ../src/libgcrypt.la -lnsl -lnsl /opt/freescale/usr/local/gcc-4.1.78-eglibc-2.5.78-dp-2/powerpc-none-linux-gnuspe/bin/powerpc-none-linux-gnuspe-gcc -I/usr/local/libgpg-error/include/ -Wall -o .libs/prime prime.o -L/usr/local/libgpg-error/lib ../src/.libs/libgcrypt.so -lnsl -Wl,--rpath -Wl,/usr/local/libgcrypt/lib /opt/freescale/usr/local/gcc-4.1.78-eglibc-2.5.78-dp-2/powerpc-none-linux-gnuspe/lib/gcc/powerpc-none-linux-gnuspe/4.1.2/../../../../powerpc-none-linux-gnuspe/bin/ld: warning: libgpg-error.so.0, needed by ../src/.libs/libgcrypt.so, not found (try using -rpath or -rpath-link) ../src/.libs/libgcrypt.so: undefined reference to `_gcry_mpih_addmul_1' ../src/.libs/libgcrypt.so: undefined reference to `_gcry_mpih_rshift' ../src/.libs/libgcrypt.so: undefined reference to `_gcry_mpih_add_n' ../src/.libs/libgcrypt.so: undefined reference to `_gcry_mpih_mul_1' ../src/.libs/libgcrypt.so: undefined reference to `_gcry_mpih_submul_1' ../src/.libs/libgcrypt.so: undefined reference to `_gcry_mpih_lshift' ../src/.libs/libgcrypt.so: undefined reference to `gpg_err_code_from_errno' ../src/.libs/libgcrypt.so: undefined reference to `_gcry_mpih_sub_n' ../src/.libs/libgcrypt.so: undefined reference to `gpg_strerror' ../src/.libs/libgcrypt.so: undefined reference to `gpg_strsource' collect2: ld returned 1 exit status make[2]: *** [prime] Error 1 make[2]: Leaving directory `/root/Desktop/libcrypt/libgcrypt-1.2.4/tests' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/Desktop/libcrypt/libgcrypt-1.2.4' make: *** [all] Error 2 *************************************************** I have also crosscompiled libgpg-error-1.6 package for PPC. Please help me to solving that issue. Thanks and regards Alok ------------------- We recently installed the spam filter from Abaca. It's over 99% accurate. Check it out - http://www.abaca.com/success/story.cgi?domain=gdatech.co.in ------------------- From ivalladt at gmail.com Tue Apr 22 16:43:39 2008 From: ivalladt at gmail.com (Ismael Valladolid Torres) Date: Tue, 22 Apr 2008 16:43:39 +0200 Subject: editing User ID In-Reply-To: <20080417161330.GA1019@jabberwocky.com> References: <20080417161330.GA1019@jabberwocky.com> Message-ID: On Thu, Apr 17, 2008 at 6:13 PM, David Shaw wrote: > The way to do what you want is to add a new user ID, with the correct > information (gpg --edit-key then "adduid"), then remove the old > incorrect UID. There are two ways to remove that: Isn't it more logical to revoke the old ID instead of removing it? There could be a lot of public keyrings out there with the incorrect ID and it won't get revoked by simply deleting it from the original key. Sorry if I misunderstood the point... From jh at jameshoward.us Tue Apr 22 20:45:02 2008 From: jh at jameshoward.us (James P. Howard, II) Date: Tue, 22 Apr 2008 14:45:02 -0400 Subject: editing User ID In-Reply-To: References: <20080417161330.GA1019@jabberwocky.com> Message-ID: <88a2333a0804221145r164be5f0yca55bff8facb4607@mail.gmail.com> Generally speaking, yes. But if the user has not yet published his key, there is no harm in just removing it. James On 4/22/08, Ismael Valladolid Torres wrote: > On Thu, Apr 17, 2008 at 6:13 PM, David Shaw wrote: > > The way to do what you want is to add a new user ID, with the correct > > information (gpg --edit-key then "adduid"), then remove the old > > incorrect UID. There are two ways to remove that: > > Isn't it more logical to revoke the old ID instead of removing it? > There could be a lot of public keyrings out there with the incorrect > ID and it won't get revoked by simply deleting it from the original > key. > > Sorry if I misunderstood the point... > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- James P. Howard, II jh at jameshoward.us http://jameshoward.us From micah at riseup.net Wed Apr 23 04:07:41 2008 From: micah at riseup.net (Micah Anderson) Date: Tue, 22 Apr 2008 22:07:41 -0400 Subject: OpenPGP card stopped working Message-ID: <877iepmihe.fsf@lillypad.riseup.net> I have an OmniKey CardMan 4040 and it was working fine for the last two months that I've had the OpenPGP card. Suddenly, it seems to think there is no card present. I never needed pcscd running as I could just use the internal driver (I just needed libpcsclite1 installed). Did my card die already? Or is there something else going on? Two things I noticed in the strace output (included below) that jumped out at my untrained eye: write(3, "SCD SERIALNO openpgp", 20) = 20 write(3, "\n", 1) = 1 read(3, "ERR 100663356 Not supported \n", 1002) = 34 And the attempted access to /dev/cmx0: open("/dev/cmx0", O_RDWR|O_LARGEFILE) = -1 EBUSY (Device or resource busy) (although earlier in the strace stack, it was seemingly communicating). Thanks for any ideas or mechanisms I can use for debug. Micah $ gpg --card-status gpg: apdu_send_simple(0) failed: no card Please insert the card and hit return or enter 'c' to cancel: gpg: pcsc_establish_context failed: no service (0x8010001d) gpg: card reader not available gpg: OpenPGP card not available: general error $ gpg --debug 2048 --debug-ccid-driver -v --card-status gpg: reading options from `/home/micah/.gnupg/gpg.conf' gpg: DBG: ccid-driver: setting up transport for CardMan 4040 gpg: DBG: ccid-driver: using CCID reader 0 (ID=0000:0001:/dev/cmx0:0) gpg: DBG: ccid-driver: status: 41 error: FE octet[9]: 00 data: gpg: DBG: ccid-driver: CCID command failed: CCID timed out while talking to the ICC gpg: reader slot 0: using ccid driver gpg: DBG: send apdu: c=00 i=A4 p0=04 p1=00 lc=6 le=-1 gpg: DBG: ccid-driver: status: 41 error: FE octet[9]: 00 data: gpg: DBG: ccid-driver: CCID command failed: CCID timed out while talking to the ICC gpg: apdu_send_simple(0) failed: card inactive gpg: DBG: ccid-driver: status: 01 error: 00 octet[9]: 01 data: gpg: DBG: ccid-driver: no CCID reader with ID 0000:0001:/dev/cmx0:0 Please insert the card and hit return or enter 'c' to cancel: gpg: DBG: ccid-driver: no CCID reader with number 0 gpg: pcsc_establish_context failed: no service (0x8010001d) gpg: card reader not available gpg: OpenPGP card not available: general error secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 execve("/usr/bin/gpg", ["gpg", "--card-status"], [/* 43 vars */]) = 0 brk(0) = 0x8111000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f7e000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=94031, ...}) = 0 mmap2(NULL, 94031, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f67000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/i686/cmov/libresolv.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@!\0\0004\0\0\0\310\2\1\0\0\0\0\0004\0 \0\10"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=67408, ...}) = 0 mmap2(NULL, 75972, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f54000 mmap2(0xb7f63000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf) = 0xb7f63000 mmap2(0xb7f65000, 6340, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f65000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libz.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\30\0\0004\0\0\0\0248\1\0\0\0\0\0004\0 "..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=81012, ...}) = 0 mmap2(NULL, 83740, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f3f000 mmap2(0xb7f53000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13) = 0xb7f53000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libbz2.so.1.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\20\0\0004\0\0\0\374\376\0\0\0\0\0\0004"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=66276, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f3e000 mmap2(NULL, 65092, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f2e000 mmap2(0xb7f3d000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf) = 0xb7f3d000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libreadline.so.5", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260\316\0\0004\0\0\0\234\373\2\0\0\0\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=196484, ...}) = 0 mmap2(NULL, 199764, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7efd000 mmap2(0xb7f29000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2c) = 0xb7f29000 mmap2(0xb7f2d000, 3156, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f2d000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/i686/cmov/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\n\0\0004\0\0\0L!\0\0\0\0\0\0004\0 \0\10\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=9684, ...}) = 0 mmap2(NULL, 12412, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ef9000 mmap2(0xb7efb000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7efb000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libusb-0.1.so.4", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\23\0\0004\0\0\0\320k\0\0\0\0\0\0004\0 \0\4"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=28560, ...}) = 0 mmap2(NULL, 31544, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7ef1000 mmap2(0xb7ef7000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5) = 0xb7ef7000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/i686/cmov/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260e\1\0004\0\0\0\4\267\24\0\0\0\0\0004\0 "..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1360292, ...}) = 0 mmap2(NULL, 1365616, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7da3000 mmap2(0xb7eeb000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x148) = 0xb7eeb000 mmap2(0xb7eee000, 9840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7eee000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libncurses.so.5", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\242\0\0004\0\0\0\244\370\2\0\0\0\0\0004\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=195724, ...}) = 0 mmap2(NULL, 199636, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7d72000 mmap2(0xb7da0000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2d) = 0xb7da0000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d71000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d70000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7d706b0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xb7eeb000, 4096, PROT_READ) = 0 munmap(0xb7f67000, 94031) = 0 fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 fstat64(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 brk(0) = 0x8111000 brk(0x8132000) = 0x8132000 setrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=0}) = 0 rt_sigaction(SIGINT, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGINT, {0x80764f0, [], 0}, NULL, 8) = 0 rt_sigaction(SIGHUP, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGHUP, {0x80764f0, [], 0}, NULL, 8) = 0 rt_sigaction(SIGTERM, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTERM, {0x80764f0, [], 0}, NULL, 8) = 0 rt_sigaction(SIGQUIT, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGQUIT, {0x80764f0, [], 0}, NULL, 8) = 0 rt_sigaction(SIGSEGV, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGSEGV, {0x80764f0, [], 0}, NULL, 8) = 0 rt_sigaction(SIGUSR1, {0x8076310, [], 0}, NULL, 8) = 0 rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=1282816, ...}) = 0 mmap2(NULL, 1282816, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7c36000 close(3) = 0 mmap2(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f76000 getuid32() = 1000 mlock(0xb7f76000, 32768) = 0 geteuid32() = 1000 getuid32() = 1000 geteuid32() = 1000 access("/home/micah/.gnupg/gpg.conf-1.4.6", R_OK) = -1 ENOENT (No such file or directory) access("/home/micah/.gnupg/gpg.conf-1.4", R_OK) = -1 ENOENT (No such file or directory) access("/home/micah/.gnupg/gpg.conf-1", R_OK) = -1 ENOENT (No such file or directory) access("/home/micah/.gnupg/gpg.conf", R_OK) = 0 access("/home/micah/.gnupg/options", R_OK) = -1 ENOENT (No such file or directory) stat64("~/.gnupg", 0xbfeee32c) = -1 ENOENT (No such file or directory) stat64("/home/micah/.gnupg/gpg.conf", {st_mode=S_IFREG|0600, st_size=8276, ...}) = 0 stat64("/home/micah/.gnupg", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 getuid32() = 1000 getuid32() = 1000 open("/home/micah/.gnupg/gpg.conf", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0600, st_size=8276, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f75000 read(3, "# Options for GnuPG\n# Copyright 1998, 1999, 2000, "..., 4096) = 4096 read(3, " proxies (keyserver option honor-http-proxy)\n#\n# M"..., 4096) = 4096 read(3, "ent-info=::1\n#\n# may be used to overrid"..., 4096) = 84 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7f75000, 4096) = 0 access("/home/micah/.gnupg/random_seed", F_OK) = 0 open("/home/micah/.gnupg/secring.gpg", O_RDONLY|O_LARGEFILE) = 3 access("/home/micah/.gnupg/secring.gpg", F_OK) = 0 open("/home/micah/.gnupg/pubring.gpg", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0600, st_size=15103776, ...}) = 0 access("/home/micah/.gnupg/pubring.gpg", F_OK) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 3 connect(3, {sa_family=AF_FILE, path="/tmp/gpg-Slfdao/S.gpg-agent"}, 29) = 0 read(3, "OK Pleased to meet you\n", 1002) = 23 write(3, "OPTION display=:0.0", 19) = 19 write(3, "\n", 1) = 1 read(3, "OK\n", 1002) = 3 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon -echo ...}) = 0 readlink("/proc/self/fd/0", "/dev/pts/1", 4095) = 10 write(3, "OPTION ttyname=/dev/pts/1", 25) = 25 write(3, "\n", 1) = 1 read(3, "OK\n", 1002) = 3 write(3, "OPTION ttytype=dumb", 19) = 19 write(3, "\n", 1) = 1 read(3, "OK\n", 1002) = 3 write(3, "OPTION lc-ctype=en_US.UTF-8", 27) = 27 write(3, "\n", 1) = 1 read(3, "OK\n", 1002) = 3 write(3, "OPTION lc-messages=en_US.UTF-8", 30) = 30 write(3, "\n", 1) = 1 read(3, "OK\n", 1002) = 3 write(3, "SCD SERIALNO openpgp", 20) = 20 write(3, "\n", 1) = 1 read(3, "ERR 100663356 Not supported \n", 1002) = 34 write(3, "BYE", 3) = 3 write(3, "\n", 1) = 1 close(3) = 0 open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents(3, /* 6 entries */, 4096) = 96 close(3) = 0 open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents(3, /* 6 entries */, 4096) = 96 getdents(3, /* 0 entries */, 4096) = 0 close(3) = 0 open("/dev/bus/usb/004", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents(3, /* 3 entries */, 4096) = 48 open("/dev/bus/usb/004/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/004/001", O_RDONLY) = 4 ioctl(4, USBDEVFS_CONNECTINFO, 0xbfeedd14) = -1 EPERM (Operation not permitted) read(4, "\22\1\0\2\t\0\1@\0\0\0\0\6\2\3\2\1\1", 18) = 18 read(4, "\t\2\31\0\1\1\0\340", 8) = 8 read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\4\0\f", 17) = 17 close(4) = 0 getdents(3, /* 0 entries */, 4096) = 0 close(3) = 0 open("/dev/bus/usb/004/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/004/001", O_RDONLY) = 3 ioctl(3, USBDEVFS_IOCTL, 0xbfeedd10) = -1 EPERM (Operation not permitted) close(3) = 0 open("/dev/bus/usb/003", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents(3, /* 3 entries */, 4096) = 48 open("/dev/bus/usb/003/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/003/001", O_RDONLY) = 4 ioctl(4, USBDEVFS_CONNECTINFO, 0xbfeedd14) = -1 EPERM (Operation not permitted) read(4, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18 read(4, "\t\2\31\0\1\1\0\340", 8) = 8 read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17 close(4) = 0 getdents(3, /* 0 entries */, 4096) = 0 close(3) = 0 open("/dev/bus/usb/003/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/003/001", O_RDONLY) = 3 ioctl(3, USBDEVFS_IOCTL, 0xbfeedd10) = -1 EPERM (Operation not permitted) close(3) = 0 open("/dev/bus/usb/002", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents(3, /* 3 entries */, 4096) = 48 open("/dev/bus/usb/002/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/002/001", O_RDONLY) = 4 ioctl(4, USBDEVFS_CONNECTINFO, 0xbfeedd14) = -1 EPERM (Operation not permitted) read(4, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18 read(4, "\t\2\31\0\1\1\0\340", 8) = 8 read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17 close(4) = 0 getdents(3, /* 0 entries */, 4096) = 0 close(3) = 0 open("/dev/bus/usb/002/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/002/001", O_RDONLY) = 3 ioctl(3, USBDEVFS_IOCTL, 0xbfeedd10) = -1 EPERM (Operation not permitted) close(3) = 0 open("/dev/bus/usb/001", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents(3, /* 3 entries */, 4096) = 48 open("/dev/bus/usb/001/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/001/001", O_RDONLY) = 4 ioctl(4, USBDEVFS_CONNECTINFO, 0xbfeedd14) = -1 EPERM (Operation not permitted) read(4, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18 read(4, "\t\2\31\0\1\1\0\340", 8) = 8 read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17 close(4) = 0 getdents(3, /* 0 entries */, 4096) = 0 close(3) = 0 open("/dev/bus/usb/001/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/001/001", O_RDONLY) = 3 ioctl(3, USBDEVFS_IOCTL, 0xbfeedd10) = -1 EPERM (Operation not permitted) close(3) = 0 open("/dev/cmx0", O_RDWR|O_LARGEFILE) = 3 write(3, "e\0\0\0\0\0\0\0\0\0", 10) = 10 read(3, "\201\0\0\0\0\0\0\1\0\1", 100) = 10 write(3, "b\0\0\0\0\0\1\0\0\0", 10) = 10 read(3, "\200\0\0\0\0\0\1A\376\0", 100) = 10 write(3, "e\0\0\0\0\0\2\0\0\0", 10) = 10 read(3, "\201\0\0\0\0\0\2\1\0\1", 100) = 10 write(3, "b\0\0\0\0\0\3\0\0\0", 10) = 10 read(3, "\200\0\0\0\0\0\3A\376\0", 100) = 10 write(2, "gpg: ", 5gpg: ) = 5 write(2, "apdu_send_simple(0) failed: card inactive\n", 42apdu_send_simple(0) failed: card inactive ) = 42 write(3, "c\0\0\0\0\0\4\0\0\0", 10) = 10 read(3, "\201\0\0\0\0\0\4\1\0\1", 100) = 10 close(3) = 0 open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents(3, /* 6 entries */, 4096) = 96 getdents(3, /* 0 entries */, 4096) = 0 close(3) = 0 open("/dev/bus/usb/004", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents(3, /* 3 entries */, 4096) = 48 open("/dev/bus/usb/004/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/004/001", O_RDONLY) = 4 ioctl(4, USBDEVFS_CONNECTINFO, 0xbfeede74) = -1 EPERM (Operation not permitted) read(4, "\22\1\0\2\t\0\1@\0\0\0\0\6\2\3\2\1\1", 18) = 18 read(4, "\t\2\31\0\1\1\0\340", 8) = 8 read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\4\0\f", 17) = 17 close(4) = 0 getdents(3, /* 0 entries */, 4096) = 0 close(3) = 0 open("/dev/bus/usb/004/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/004/001", O_RDONLY) = 3 ioctl(3, USBDEVFS_IOCTL, 0xbfeede70) = -1 EPERM (Operation not permitted) close(3) = 0 open("/dev/bus/usb/003", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents(3, /* 3 entries */, 4096) = 48 open("/dev/bus/usb/003/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/003/001", O_RDONLY) = 4 ioctl(4, USBDEVFS_CONNECTINFO, 0xbfeede74) = -1 EPERM (Operation not permitted) read(4, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18 read(4, "\t\2\31\0\1\1\0\340", 8) = 8 read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17 close(4) = 0 getdents(3, /* 0 entries */, 4096) = 0 close(3) = 0 open("/dev/bus/usb/003/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/003/001", O_RDONLY) = 3 ioctl(3, USBDEVFS_IOCTL, 0xbfeede70) = -1 EPERM (Operation not permitted) close(3) = 0 open("/dev/bus/usb/002", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents(3, /* 3 entries */, 4096) = 48 open("/dev/bus/usb/002/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/002/001", O_RDONLY) = 4 ioctl(4, USBDEVFS_CONNECTINFO, 0xbfeede74) = -1 EPERM (Operation not permitted) read(4, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18 read(4, "\t\2\31\0\1\1\0\340", 8) = 8 read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17 close(4) = 0 getdents(3, /* 0 entries */, 4096) = 0 close(3) = 0 open("/dev/bus/usb/002/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/002/001", O_RDONLY) = 3 ioctl(3, USBDEVFS_IOCTL, 0xbfeede70) = -1 EPERM (Operation not permitted) close(3) = 0 open("/dev/bus/usb/001", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents(3, /* 3 entries */, 4096) = 48 open("/dev/bus/usb/001/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/001/001", O_RDONLY) = 4 ioctl(4, USBDEVFS_CONNECTINFO, 0xbfeede74) = -1 EPERM (Operation not permitted) read(4, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18 read(4, "\t\2\31\0\1\1\0\340", 8) = 8 read(4, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17 close(4) = 0 getdents(3, /* 0 entries */, 4096) = 0 close(3) = 0 open("/dev/bus/usb/001/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/001/001", O_RDONLY) = 3 ioctl(3, USBDEVFS_IOCTL, 0xbfeede70) = -1 EPERM (Operation not permitted) close(3) = 0 open("/dev/cmx0", O_RDWR|O_LARGEFILE) = 3 open("/usr/share/locale/locale.alias", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=2586, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f75000 read(4, "# Locale name alias data base.\n# Copyright (C) 199"..., 4096) = 2586 read(4, "", 4096) = 0 close(4) = 0 munmap(0xb7f75000, 4096) = 0 open("/locale/en_US.UTF-8/LC_MESSAGES/gnupg.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/locale/en_US.utf8/LC_MESSAGES/gnupg.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/locale/en_US/LC_MESSAGES/gnupg.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/locale/en.UTF-8/LC_MESSAGES/gnupg.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/locale/en.utf8/LC_MESSAGES/gnupg.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/locale/en/LC_MESSAGES/gnupg.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/dev/tty", O_RDWR|O_LARGEFILE) = 4 open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0644, st_size=25700, ...}) = 0 mmap2(NULL, 25700, PROT_READ, MAP_SHARED, 5, 0) = 0xb7f6f000 close(5) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon -echo ...}) = 0 stat64("/home/micah/.terminfo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 access("/home/micah/.terminfo/d/dumb", R_OK) = -1 ENOENT (No such file or directory) stat64("/etc/terminfo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 access("/etc/terminfo/d/dumb", R_OK) = -1 ENOENT (No such file or directory) stat64("/lib/terminfo", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 access("/lib/terminfo/d/dumb", R_OK) = 0 open("/lib/terminfo/d/dumb", O_RDONLY|O_LARGEFILE) = 5 read(5, "\32\1\30\0\2\0\1\0\202\0\10\0dumb|80-column dumb tty\0\0\1P\0\377\377\0\0\2\0\377\377\377\377"..., 4097) = 308 close(5) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon -echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon -echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon -echo ...}) = 0 ioctl(1, TIOCGWINSZ, {ws_row=0, ws_col=0, ws_xpixel=0, ws_ypixel=0}) = 0 ioctl(4, TIOCGWINSZ, {ws_row=0, ws_col=0, ws_xpixel=0, ws_ypixel=0}) = 0 ioctl(4, TIOCGWINSZ, {ws_row=0, ws_col=0, ws_xpixel=0, ws_ypixel=0}) = 0 ioctl(4, TIOCSWINSZ, {ws_row=0, ws_col=0, ws_xpixel=0, ws_ypixel=0}) = 0 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon -echo ...}) = 0 stat64("/home/micah/.inputrc", 0xbfeedf74) = -1 ENOENT (No such file or directory) stat64("/etc/inputrc", {st_mode=S_IFREG|0644, st_size=1698, ...}) = 0 open("/etc/inputrc", O_RDONLY) = 5 read(5, "# /etc/inputrc - global inputrc for libreadline\n# "..., 1698) = 1698 close(5) = 0 rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0 ioctl(4, TIOCGWINSZ, {ws_row=0, ws_col=0, ws_xpixel=0, ws_ypixel=0}) = 0 ioctl(4, TIOCSWINSZ, {ws_row=0, ws_col=0, ws_xpixel=0, ws_ypixel=0}) = 0 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon -echo ...}) = 0 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon -echo ...}) = 0 ioctl(4, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = 0 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon -echo ...}) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigaction(SIGWINCH, {0xb7f1bc40, [], SA_RESTART}, {SIG_DFL}, 8) = 0 fstat64(4, {st_mode=S_IFCHR|0666, st_rdev=makedev(5, 0), ...}) = 0 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon -echo ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f6e000 write(4, "Please insert the card and hit return or enter \'c\'"..., 62Please insert the card and hit return or enter 'c' to cancel: ) = 62 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 read(4, "\n", 1) = 1 rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon -echo ...}) = 0 ioctl(4, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon -echo ...}) = 0 ioctl(4, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon -echo ...}) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigaction(SIGWINCH, {SIG_DFL}, {0xb7f1bc40, [], SA_RESTART}, 8) = 0 open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 5 fstat64(5, {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 getdents(5, /* 6 entries */, 4096) = 96 getdents(5, /* 0 entries */, 4096) = 0 close(5) = 0 open("/dev/bus/usb/004", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 5 fstat64(5, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 getdents(5, /* 3 entries */, 4096) = 48 open("/dev/bus/usb/004/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/004/001", O_RDONLY) = 6 ioctl(6, USBDEVFS_CONNECTINFO, 0xbfeedd14) = -1 EPERM (Operation not permitted) read(6, "\22\1\0\2\t\0\1@\0\0\0\0\6\2\3\2\1\1", 18) = 18 read(6, "\t\2\31\0\1\1\0\340", 8) = 8 read(6, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\4\0\f", 17) = 17 close(6) = 0 getdents(5, /* 0 entries */, 4096) = 0 close(5) = 0 open("/dev/bus/usb/004/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/004/001", O_RDONLY) = 5 ioctl(5, USBDEVFS_IOCTL, 0xbfeedd10) = -1 EPERM (Operation not permitted) close(5) = 0 open("/dev/bus/usb/003", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 5 fstat64(5, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 getdents(5, /* 3 entries */, 4096) = 48 open("/dev/bus/usb/003/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/003/001", O_RDONLY) = 6 ioctl(6, USBDEVFS_CONNECTINFO, 0xbfeedd14) = -1 EPERM (Operation not permitted) read(6, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18 read(6, "\t\2\31\0\1\1\0\340", 8) = 8 read(6, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17 close(6) = 0 getdents(5, /* 0 entries */, 4096) = 0 close(5) = 0 open("/dev/bus/usb/003/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/003/001", O_RDONLY) = 5 ioctl(5, USBDEVFS_IOCTL, 0xbfeedd10) = -1 EPERM (Operation not permitted) close(5) = 0 open("/dev/bus/usb/002", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 5 fstat64(5, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 getdents(5, /* 3 entries */, 4096) = 48 open("/dev/bus/usb/002/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/002/001", O_RDONLY) = 6 ioctl(6, USBDEVFS_CONNECTINFO, 0xbfeedd14) = -1 EPERM (Operation not permitted) read(6, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18 read(6, "\t\2\31\0\1\1\0\340", 8) = 8 read(6, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17 close(6) = 0 getdents(5, /* 0 entries */, 4096) = 0 close(5) = 0 open("/dev/bus/usb/002/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/002/001", O_RDONLY) = 5 ioctl(5, USBDEVFS_IOCTL, 0xbfeedd10) = -1 EPERM (Operation not permitted) close(5) = 0 open("/dev/bus/usb/001", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 5 fstat64(5, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 getdents(5, /* 3 entries */, 4096) = 48 open("/dev/bus/usb/001/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/001/001", O_RDONLY) = 6 ioctl(6, USBDEVFS_CONNECTINFO, 0xbfeedd14) = -1 EPERM (Operation not permitted) read(6, "\22\1\20\1\t\0\0@\0\0\0\0\6\2\3\2\1\1", 18) = 18 read(6, "\t\2\31\0\1\1\0\340", 8) = 8 read(6, "\0\t\4\0\0\1\t\0\0\0\7\5\201\3\2\0\377", 17) = 17 close(6) = 0 getdents(5, /* 0 entries */, 4096) = 0 close(5) = 0 open("/dev/bus/usb/001/001", O_RDWR) = -1 EACCES (Permission denied) open("/dev/bus/usb/001/001", O_RDONLY) = 5 ioctl(5, USBDEVFS_IOCTL, 0xbfeedd10) = -1 EPERM (Operation not permitted) close(5) = 0 open("/dev/cmx0", O_RDWR|O_LARGEFILE) = -1 EBUSY (Device or resource busy) open("/dev/cmx1", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFREG|0644, st_size=94031, ...}) = 0 mmap2(NULL, 94031, PROT_READ, MAP_PRIVATE, 5, 0) = 0xb7c1f000 close(5) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libpcsclite.so.1", O_RDONLY) = 5 read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\30\0\0004\0\0\0\20\203\0\0\0\0\0\0004\0"..., 512) = 512 fstat64(5, {st_mode=S_IFREG|0644, st_size=34512, ...}) = 0 mmap2(NULL, 35972, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0xb7c16000 mmap2(0xb7c1e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x8) = 0xb7c1e000 close(5) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/i686/cmov/libpthread.so.0", O_RDONLY) = 5 read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20H\0\0004\0\0\0\330C\1\0\0\0\0\0004\0 \0\t"..., 512) = 512 fstat64(5, {st_mode=S_IFREG|0755, st_size=112354, ...}) = 0 mmap2(NULL, 94688, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0xb7bfe000 mmap2(0xb7c12000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x13) = 0xb7c12000 mmap2(0xb7c14000, 4576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7c14000 close(5) = 0 set_tid_address(0xb7d706f8) = 25583 set_robust_list(0xb7d70700, 0xc) = 0 futex(0xbfeedc10, 0x81 /* FUTEX_??? */, 1) = 0 rt_sigaction(SIGRTMIN, {0xb7c022c0, [], SA_SIGINFO}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xb7c02340, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 uname({sys="Linux", node="lillypad", ...}) = 0 munmap(0xb7c1f000, 94031) = 0 stat64("/var/run/pcscd/pcscd.pub", 0xbfeed604) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon -echo ...}) = 0 write(2, "gpg: ", 5gpg: ) = 5 write(2, "pcsc_establish_context failed: no service (0x80100"..., 55pcsc_establish_context failed: no service (0x8010001d) ) = 55 write(2, "gpg: ", 5gpg: ) = 5 write(2, "card reader not available\n", 26card reader not available ) = 26 write(2, "gpg: ", 5gpg: ) = 5 write(2, "OpenPGP card not available: general error\n", 42OpenPGP card not available: general error ) = 42 munmap(0xb7f76000, 32768) = 0 exit_group(2) = ? Process 25583 detached From wk at gnupg.org Wed Apr 23 08:35:30 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Apr 2008 08:35:30 +0200 Subject: Automated signature verification for downloads In-Reply-To: (Anthony Bryan's message of "Fri, 18 Apr 2008 17:26:26 -0400") References: Message-ID: <87r6cxnknh.fsf@wheatstone.g10code.de> On Fri, 18 Apr 2008 23:26, anthonybryan at gmail.com said: > .metalink files are XML and list mirrors, checksums, signatures, and > other information, used for improving downloads and automating > advanced features. There are about 20 metalink download clients, from > CLI to GUI, on all platforms, from download managers to Web browsers. I read the wikipedia article and brosed the emtalink site but was not abale to find any speicification. A list of supporting programs is not that helpful to understand the format. > Downloading to curl-7.18.1.tar.gz > [#########################------------------------------] 47% 1.00/2.12 MB > -----BEGIN PGP SIGNATURE INFORMATION----- > timestamp: Sun, 30 Mar 2008 05:10:27 (Eastern Daylight Time) > fingerprint: 914C533DF9B2ADA2204F586D78E11C6B279D5C91 > uid: Daniel Stenberg (Haxx) > -----END PGP SIGNATURE INFORMATION----- I do not understand what this is about. Using header lines very similar to those defined by OpenPGP is a bit questionable. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From anthonybryan at gmail.com Wed Apr 23 09:33:27 2008 From: anthonybryan at gmail.com (Anthony Bryan) Date: Wed, 23 Apr 2008 03:33:27 -0400 Subject: Automated signature verification for downloads In-Reply-To: <87r6cxnknh.fsf@wheatstone.g10code.de> References: <87r6cxnknh.fsf@wheatstone.g10code.de> Message-ID: Hi Werner, thanks for replying. On Wed, Apr 23, 2008 at 2:35 AM, Werner Koch wrote: > On Fri, 18 Apr 2008 23:26, anthonybryan at gmail.com said: > > > .metalink files are XML and list mirrors, checksums, signatures, and > > other information, used for improving downloads and automating > > advanced features. There are about 20 metalink download clients, from > > CLI to GUI, on all platforms, from download managers to Web browsers. > > I read the wikipedia article and brosed the emtalink site but was not > abale to find any speicification. A list of supporting programs is not > that helpful to understand the format. The metalink specification is at http://www.metalinker.org/implementation.html#spec I agree, it's not easy enough to find. That will be fixed. > > Downloading to curl-7.18.1.tar.gz > > [#########################------------------------------] 47% 1.00/2.12 MB > > -----BEGIN PGP SIGNATURE INFORMATION----- > > timestamp: Sun, 30 Mar 2008 05:10:27 (Eastern Daylight Time) > > fingerprint: 914C533DF9B2ADA2204F586D78E11C6B279D5C91 > > uid: Daniel Stenberg (Haxx) > > -----END PGP SIGNATURE INFORMATION----- > > I do not understand what this is about. Using header lines very similar > to those defined by OpenPGP is a bit questionable. In case it wasn't clear, the file is downloaded using the mirrors and checksum listed in the metalink. Then the file is verified using the signature in the metalink. The headers are produced by GnuPG when it verifies the signature (AFAIK). Is there a problem with this? The metalink is XML and can be viewed in a text editor. The metalink used in the example is at http://curl.haxx.se/metalink.cgi?curl=tar.gz - I think if you view it, it will be clear what's going on. Here is the portion of the metalink you would probably be most interested in: 6315db7c4373b586bac5f528322ba10e 5d72f9fbf3eab6474a8dc22192056119030087f6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBH71kDeOEcayedXJERAmfWAJ0bsBFUJ6ooykT2qPeegvIH4KIVqACfRtt5 Rv6MJSuz/b6NItnG7zoYGFw= =GKuk -----END PGP SIGNATURE----- -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From tcurdt at vafer.org Wed Apr 23 10:42:53 2008 From: tcurdt at vafer.org (Torsten Curdt) Date: Wed, 23 Apr 2008 10:42:53 +0200 Subject: upgrading from 1.x to 2.x In-Reply-To: <4118C9F4-E7AD-41AE-BA04-079535834839@vafer.org> References: <61EA07CF-25F7-47AE-A5A9-83752F9E84B6@vafer.org> <87od82s7kr.fsf@wheatstone.g10code.de> <4118C9F4-E7AD-41AE-BA04-079535834839@vafer.org> Message-ID: <12D54F05-D792-4D92-8CA3-68412B90A3AA@vafer.org> I've just reverted back to 1.x. Version 2.x does not seem to be worth the hassle. 1.x works like charm. But couldn't import the msg.asc here either ...so it really seems to be broken. Anyway. Not a particular good error message though. cheers -- Torsten On Apr 22, 2008, at 09:41, Torsten Curdt wrote: > Hey Werner, > > Thanks for the response! > >>> refreshing the keys fails. >>> >>> $ gpg2 --refresh-keys >>> an mpi of size 0 is not allowed >>> gpg: keyring_get_keyblock: read error: Invalid packet >> >> Incidently this problem was reported to me yesterday and figured out >> that the http key helper tool did not worked at all. Teh windows >> socket >> layer was not initialized and at another point we did a dup for a >> socket >> which is not going to work. > > uh! ....but then using hkp should work for the update, right? > >> I don't know why this bug lurked around for >> so long. It might be that gpg2 accidently used the gpg1 key helper >> tools (which works) or that we only tested direct hkp server and >> finger >> support. > > But actually I don't think this is download related. > > $ gpg2 --list-keys > /Users/tcurdt/.gnupg/pubring.gpg > -------------------------------- > pub 1024D/7C200941 2004-04-24 > uid Torsten Curdt > uid Torsten Curdt > sub 1024g/87C5307C 2004-04-24 > > ... > list some more keys - but not all > ... > > an mpi of size 0 is not allowed > gpg: keyring_get_keyblock: read error: Invalid packet > gpg: keydb_get_keyblock failed: Invalid keyring > > > Seems like also other people run into it > > http://lists.opensuse.org/opensuse-bugs/2007-09/msg05835.html > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463270 > http://www.gossamer-threads.com/lists/gnupg/devel/43532?page=last > > Fankly speaking - it awfully reminds me on a problem I run into with > 1.x before ...that was fixed in later releases of 1.x > > http://marc.info/?l=gnupg-devel&m=114694741924376&w=2 > http://lists.gnupg.org/pipermail/gnupg-users/2006-May.txt > > >>> And even importing a file that (at least) looks perfectly OK gives >>> me >>> >>> $ gpg2 --import msg.asc >>> gpg: no valid OpenPGP data found. >>> gpg: Total number processed: 0 >>> >>> This is GnuPG 2.0.8 on OSX 10.5.2 installed via MacPorts >> >> Well, this is anotehr problem. I bet the msg.asc is not okay or >> there >> is a problem with the MacPorts version of gpg2. > > -----BEGIN PGP MESSAGE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > hQEOAz5rX/KHxTB8EAP/QqFwC0/p/6l7mRLvojOA+WjBq74URkaX6W6L4YPrpDvq > L42waXpfAhMmjLe3zw35+7ViLd/nICP8JB8Qjtbdt3iMIST62IMHbA1L9PxO7BHS > jRs+MwbEzddPnh3Gn/sDdiz3kmq810BcXKpFNuGCIyBqTu8zwxjVhs2nvI1tbBoD > /1wjSpCoJkeG76ZD5sbewiRE2H0Ft2P/S7GqTF6BtWmg1bpCHIN4O0uzkfex0jvk > .... > ftWzVVsGPI8qjtfruCzRiRjjNF/a1ErnVWFR/V6fe7bTUNAgouuUJzKWDLdKc56E > IpcZ1wUPl/zKFVdIwhNP9RUf3gfZKBzySs/xWRs= > =yoCf > -----END PGP MESSAGE----- > > ...looks quite OK to me :-/ > > cheers > -- > Torsten > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users From wk at gnupg.org Wed Apr 23 13:23:34 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Apr 2008 13:23:34 +0200 Subject: Automated signature verification for downloads In-Reply-To: (Anthony Bryan's message of "Wed, 23 Apr 2008 03:33:27 -0400") References: <87r6cxnknh.fsf@wheatstone.g10code.de> Message-ID: <87prsglsqx.fsf@wheatstone.g10code.de> On Wed, 23 Apr 2008 09:33, anthonybryan at gmail.com said: > The metalink specification is at > http://www.metalinker.org/implementation.html#spec > I agree, it's not easy enough to find. That will be fixed. Okay. (The plain text version is not very good readable). > The headers are produced by GnuPG when it verifies the signature > (AFAIK). Is there a problem with this? No, that is not generated by GnuPG. The script probably preents the information in this way. It should also state whether the signature is good or broken.. >From the metalink 3.0 specs: Also, PGP signatures can be embedded with and can contain an optional file attribute which references another file (for example, ) listed in the Metalink as so: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) [...] it is not clear to me why there is the file attribute as well as the armored version of the signature. Is that signature a signature over the "linux.sign" file or one over the the actual file "linux"? Referencing a copy does not seem to be a good idea because of error reporting problems if they don't match. If it is just a (armored) copy, I suggest to drop the file attribute. Keeping the armored signature in the XML is just fine. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From henry.bremridge at xobie.com Wed Apr 23 13:54:32 2008 From: henry.bremridge at xobie.com (Henry Bremridge) Date: Wed, 23 Apr 2008 12:54:32 +0100 Subject: OpenPGP card stopped working In-Reply-To: <877iepmihe.fsf@lillypad.riseup.net> References: <877iepmihe.fsf@lillypad.riseup.net> Message-ID: <20080423115432.GD25385@newdebian.science> On Tue, Apr 22, 2008 at 10:07:41PM -0400, Micah Anderson wrote: > > I have an OmniKey CardMan 4040 and it was working fine for the last two > months that I've had the OpenPGP card. Suddenly, it seems to think there > is no card present. I never needed pcscd running as I could just use the > internal driver (I just needed libpcsclite1 installed). Did my card die > already? Or is there something else going on? > > Two things I noticed in the strace output (included below) that jumped > out at my untrained eye: > > write(3, "SCD SERIALNO openpgp", 20) = 20 > write(3, "\n", 1) = 1 > read(3, "ERR 100663356 Not supported \n", 1002) = 34 > > And the attempted access to /dev/cmx0: > > open("/dev/cmx0", O_RDWR|O_LARGEFILE) = -1 EBUSY (Device or resource > busy) > > (although earlier in the strace stack, it was seemingly communicating). > > Thanks for any ideas or mechanisms I can use for debug. > Micah > > > $ gpg --card-status > gpg: apdu_send_simple(0) failed: no card > Please insert the card and hit return or enter 'c' to cancel: > gpg: pcsc_establish_context failed: no service (0x8010001d) > gpg: card reader not available > gpg: OpenPGP card not available: general error > I have a SCR-335 (on Debian Lenny) and this failed this morning $ gpg --card-status gpg: pcsc_establish_context failed: no service (0x8010001d) gpg: card reader not available gpg: OpenPGP card not available: general error -- Henry From henry.bremridge at xobie.com Wed Apr 23 14:35:49 2008 From: henry.bremridge at xobie.com (Henry Bremridge) Date: Wed, 23 Apr 2008 13:35:49 +0100 Subject: OpenPGP card stopped working In-Reply-To: <20080423115432.GD25385@newdebian.science> References: <877iepmihe.fsf@lillypad.riseup.net> <20080423115432.GD25385@newdebian.science> Message-ID: <20080423123549.GA5763@newdebian.science> On Wed, Apr 23, 2008 at 12:54:32PM +0100, Henry Bremridge wrote: > I have a SCR-335 (on Debian Lenny) and this failed this morning > > $ gpg --card-status > gpg: pcsc_establish_context failed: no service (0x8010001d) > gpg: card reader not available > gpg: OpenPGP card not available: general error > Must have been a patch on one update this morning. Rebooted and all working -- Henry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature URL: From johannes_graumann at web.de Wed Apr 23 16:26:10 2008 From: johannes_graumann at web.de (Johannes Graumann) Date: Wed, 23 Apr 2008 16:26:10 +0200 Subject: Timestamping Service: Existing Services or Software Project? Message-ID: Hi all, I've done some superficial googleing, but didn't get far ... so I'm asking here: Is anybody aware of a software project implementing a time stamping service via gnupg: you submit your signature of a file and it comes back signed by a time stamping authority, which goes to some length to make sure there machine time is semi-correct, thereby saying that you signed this file before time X? Thanks for any hints, Joh From dshaw at jabberwocky.com Wed Apr 23 16:39:14 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 23 Apr 2008 10:39:14 -0400 Subject: Timestamping Service: Existing Services or Software Project? In-Reply-To: References: Message-ID: <418D359E-323A-417C-B763-15A4849113F7@jabberwocky.com> On Apr 23, 2008, at 10:26 AM, Johannes Graumann wrote: > Hi all, > > I've done some superficial googleing, but didn't get far ... so I'm > asking > here: > Is anybody aware of a software project implementing a time stamping > service > via gnupg: you submit your signature of a file and it comes back > signed by > a time stamping authority, which goes to some length to make sure > there > machine time is semi-correct, thereby saying that you signed this file > before time X? Try http://www.itconsult.co.uk/stamper.htm David From jh at jameshoward.us Wed Apr 23 16:50:27 2008 From: jh at jameshoward.us (James P. Howard, II) Date: Wed, 23 Apr 2008 10:50:27 -0400 Subject: Timestamping Service: Existing Services or Software Project? In-Reply-To: References: Message-ID: <88a2333a0804230750m37ed01cfv9b30969ca469f2bc@mail.gmail.com> I have one at http://jameshoward.us/pgp-robots. James On 4/23/08, Johannes Graumann wrote: > Hi all, > > I've done some superficial googleing, but didn't get far ... so I'm asking > here: > Is anybody aware of a software project implementing a time stamping service > via gnupg: you submit your signature of a file and it comes back signed by > a time stamping authority, which goes to some length to make sure there > machine time is semi-correct, thereby saying that you signed this file > before time X? > > Thanks for any hints, Joh > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- James P. Howard, II jh at jameshoward.us http://jameshoward.us From micah at riseup.net Wed Apr 23 16:57:54 2008 From: micah at riseup.net (Micah Anderson) Date: Wed, 23 Apr 2008 10:57:54 -0400 Subject: OpenPGP card stopped working References: <877iepmihe.fsf@lillypad.riseup.net> <20080423115432.GD25385__5906.08652350983$1208953748$gmane$org@newdebian.science> Message-ID: <87zlrklitp.fsf@lillypad.riseup.net> Henry Bremridge writes: > On Tue, Apr 22, 2008 at 10:07:41PM -0400, Micah Anderson wrote: >> $ gpg --card-status >> gpg: apdu_send_simple(0) failed: no card >> Please insert the card and hit return or enter 'c' to cancel: >> gpg: pcsc_establish_context failed: no service (0x8010001d) >> gpg: card reader not available >> gpg: OpenPGP card not available: general error >> > I have a SCR-335 (on Debian Lenny) and this failed this morning > > $ gpg --card-status > gpg: pcsc_establish_context failed: no service (0x8010001d) > gpg: card reader not available > gpg: OpenPGP card not available: general error I too am using Debian (sid), and wonder if this is related to some library update. I tried downgrading my libpcsclite1 to the previous version, but that didn't change anything. I've tried 2.6.24 and 2.6.22 kernels, with similar results. Had you updated any packages right before you started seeing that? Micah From johannes_graumann at web.de Wed Apr 23 16:58:00 2008 From: johannes_graumann at web.de (Johannes Graumann) Date: Wed, 23 Apr 2008 16:58:00 +0200 Subject: Timestamping Service: Existing Services or Software Project? References: <88a2333a0804230750m37ed01cfv9b30969ca469f2bc__22623.4243753881$1208962364$gmane$org@mail.gmail.com> Message-ID: 404 Not Found The requested page was not found. !? Joh James P. Howard, II wrote: > I have one at http://jameshoward.us/pgp-robots. > > James > > > > On 4/23/08, Johannes Graumann wrote: >> Hi all, >> >> I've done some superficial googleing, but didn't get far ... so I'm >> asking here: >> Is anybody aware of a software project implementing a time stamping >> service via gnupg: you submit your signature of a file and it comes back >> signed by a time stamping authority, which goes to some length to make >> sure there machine time is semi-correct, thereby saying that you signed >> this file before time X? >> >> Thanks for any hints, Joh >> >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > > From henry.bremridge at xobie.com Wed Apr 23 17:23:25 2008 From: henry.bremridge at xobie.com (Henry Bremridge) Date: Wed, 23 Apr 2008 16:23:25 +0100 Subject: OpenPGP card stopped working In-Reply-To: <87zlrklitp.fsf@lillypad.riseup.net> References: <877iepmihe.fsf@lillypad.riseup.net> <20080423115432.GD25385__5906.08652350983$1208953748$gmane$org@newdebian.science> <87zlrklitp.fsf@lillypad.riseup.net> Message-ID: <20080423152325.GC5763@newdebian.science> On Wed, Apr 23, 2008 at 10:57:54AM -0400, Micah Anderson wrote: > Henry Bremridge writes: > > > On Tue, Apr 22, 2008 at 10:07:41PM -0400, Micah Anderson wrote: > >> $ gpg --card-status > >> gpg: apdu_send_simple(0) failed: no card > >> Please insert the card and hit return or enter 'c' to cancel: > >> gpg: pcsc_establish_context failed: no service (0x8010001d) > >> gpg: card reader not available > >> gpg: OpenPGP card not available: general error > >> > > I have a SCR-335 (on Debian Lenny) and this failed this morning > > > > $ gpg --card-status > > gpg: pcsc_establish_context failed: no service (0x8010001d) > > gpg: card reader not available > > gpg: OpenPGP card not available: general error > > I too am using Debian (sid), and wonder if this is related to some > library update. I tried downgrading my libpcsclite1 to the previous > version, but that didn't change anything. I've tried 2.6.24 and 2.6.22 > kernels, with similar results. > > Had you updated any packages right before you started seeing that? > My cron-apt this morning updated the following this morning avahi-daemon avahi-utils bind9-host console-common dbus dbus-x11 libavahi-client3 libavahi-common-data libavahi-common3 libavahi-compat-libdnssd1 libavahi-core5 libavahi-glib1 libbind9-30 libdbus-1-3 libdns32 libgl1-mesa-dri libgl1-mesa-glx libglu1-mesa libgstreamer0.10-0 libisc32 libisccc30 libisccfg30 liblwres30 xsane xsane-common -- Henry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature URL: From jh at jameshoward.us Wed Apr 23 18:08:16 2008 From: jh at jameshoward.us (=?utf-8?B?SmFtZXMgUC4gSG93YXJkLCBJSQ==?=) Date: Wed, 23 Apr 2008 16:08:16 +0000 Subject: Timestamping Service: Existing Services or Software Project? In-Reply-To: <480F4E81.7070602@radde.name> References: <88a2333a0804230750m37ed01cfv9b30969ca469f2bc@mail.gmail.com><480F4E81.7070602@radde.name> Message-ID: <773557482-1208966898-cardhu_decombobulator_blackberry.rim.net-1985753767-@bxe140.bisx.prod.on.blackberry> Yep, sorry about that. Try this instead: http://jameshoward.us/robot-digital-signature-authority James -- James P. Howard, II jh at jameshoward.us http://jameshoward.us -----Original Message----- From: Sven Radde Date: Wed, 23 Apr 2008 16:58:09 To:jh at jameshoward.us Subject: Re: Timestamping Service: Existing Services or Software Project? James P. Howard, II schrieb: > http://jameshoward.us/pgp-robots. > Gives a 404, with and without the trailing "." :-( cu, Sven From reynt0 at cs.albany.edu Wed Apr 23 19:41:42 2008 From: reynt0 at cs.albany.edu (reynt0) Date: Wed, 23 Apr 2008 13:41:42 -0400 (EDT) Subject: Miscellaneous questions In-Reply-To: <1208359225.29504.82.camel@etppc19> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <20080415215415.GM56745@jabberwocky.com> <1208301557.11857.45.camel@fermat.scientia.net> <480557F2.6000900@sixdemonbag.org> <1208335568.29504.18.camel@etppc19> <20080416124115.GA71474@jabberwocky.com> <1208351068.29504.56.camel@etppc19> <1208359225.29504.82.camel@etppc19> Message-ID: On Wed, 16 Apr 2008, Christoph Anton Mitterer wrote: . . . >> I don't want to discourage you from suggesting changes, but I do >> advise that you really understand what you are suggesting. For >> example, the ideas around user IDs being required to be full names >> show misunderstanding of the OpenPGP trust model. > Hm could you please explain me why? I always thought that completeness > is also important correctness? . . . > But I think there are also several points where we could increase > security and tidy things up (e.g. the separation of ID's from > attributes, describing a user, such attributes could be his name town, > ZIP-code or even his ebay account). . . . (This is a late comment, I'm catching up reading email, and Herr C.A.M has mentioned his idea a couple of times.) Isn't one issue concerning requiring "full" names, zip code, or similar, that you are not getting some good "completeness", but are rather giving some responsibility for some aspects of verification to big organizations, especially political ones like whoever keeps full name records, etc? So aspects of identity used to verify some user are no longer under the control of the user to the extent the user wants, but might be required to be able to check with some central authority? I think gpg wants to respect user self-control? And tries hard to find good ways to make things work that way? "My parents wanted a boy baby, so they named me Robert Christoph and call me Bob, some friends call me Alice, but I really want people to know me as Cassandra; and besides, I'm shy and don't want strangers to laugh at me." :-) From christoph.anton.mitterer at physik.uni-muenchen.de Wed Apr 23 20:19:00 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Wed, 23 Apr 2008 20:19:00 +0200 Subject: Miscellaneous questions In-Reply-To: References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <20080415215415.GM56745@jabberwocky.com> <1208301557.11857.45.camel@fermat.scientia.net> <480557F2.6000900@sixdemonbag.org> <1208335568.29504.18.camel@etppc19> <20080416124115.GA71474@jabberwocky.com> <1208351068.29504.56.camel@etppc19> <1208359225.29504.82.camel@etppc19> Message-ID: <1208974740.9157.1.camel@fermat.scientia.net> On Wed, 2008-04-23 at 13:41 -0400, reynt0 wrote: > (This is a late comment, I'm catching up reading email, and > Herr C.A.M has mentioned his idea a couple of times.) [snip snap] Does this contain any question? Regards, Chris. From albert at fsfe.org Wed Apr 23 21:03:51 2008 From: albert at fsfe.org (Albert Dengg) Date: Wed, 23 Apr 2008 21:03:51 +0200 Subject: gpg smartcard troubles Message-ID: <20080423190351.GB4982@odin.lan> hi currently i had to switch from my notebook to my workstation and i now have a problem: while my openpgp smartcard works with gpg-agent (ssh auth works), i'm unable to decrypt files encrypted for the encryption subkey or signing with the sign subkey, though they are listed when i do a "gpg --edit-key" as beeing subkeys... any ideas what's going wrong or how i can tell gpg where to find the secret subkeys? tia yours albert -- Albert Dengg From jh at jameshoward.us Wed Apr 23 20:48:01 2008 From: jh at jameshoward.us (James P. Howard, II) Date: Wed, 23 Apr 2008 14:48:01 -0400 Subject: Timestamping Service: Existing Services or Software Project? In-Reply-To: <480F8124.6070301@mac.com> References: <88a2333a0804230750m37ed01cfv9b30969ca469f2bc@mail.gmail.com> <480F4E81.7070602@radde.name> <773557482-1208966898-cardhu_decombobulator_blackberry.rim.net-1985753767-@bxe140.bisx.prod.on.blackberry> <480F8124.6070301@mac.com> Message-ID: <88a2333a0804231148v44abd3eehd9182921583cc4a6@mail.gmail.com> This is embarrassing. I've contacted my provider to find out why mail is bouncing. Thank you, James On Wed, Apr 23, 2008 at 2:34 PM, Charly Avital wrote: > James P. Howard wrote the following on 4/23/08 12:08 PM: > > > Yep, sorry about that. Try this instead: > > > > http://jameshoward.us/robot-digital-signature-authority > > > > James > > > > -- > > James P. Howard, II > > jh at jameshoward.us > > http://jameshoward.us > > > [...] > > Sent a signed test message using my gmail account (please see below), > with sign as subject. > Received the following: > > Hi. This is the qmail-send program at ivy.phpwebhosting.com. > I'm afraid I wasn't able to deliver your message to the following addresses. > This is a permanent error; I've given up. Sorry it didn't work out. > > : > Sorry. Although I'm listed as a best-preference MX or A for that host, > it isn't in my control/locals file, so I don't treat it as local. (#5.4.6) > > --- Below this line is a copy of the message. > > Return-Path: > Received: (qmail 2907 invoked by uid 457); 23 Apr 2008 18:23:08 -0000 > Delivered-To: jphoward.com-pgprobots at jphoward.com > Received: (qmail 2905 invoked by uid 457); 23 Apr 2008 18:23:08 -0000 > Delivered-To: jameshoward.us-robot-dsa at jameshoward.us > Received: (qmail 2903 invoked from network); 23 Apr 2008 18:23:08 -0000 > Received: from unknown (HELO ug-out-1314.google.com) (66.249.92.172) > by c5.e0.5746.static.theplanet.com with SMTP; Wed, 23 Apr 2008 14:23:08 > -0400 > Received: by ug-out-1314.google.com with SMTP id o38so624527ugd.17 > for ; Wed, 23 Apr 2008 11:21:01 -0700 > (PDT) > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > d=gmail.com; s=gamma; > > h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; > bh=OsiFsFEMx5La7hrc4yqTYJX3pg3pcND3tHuLpJ2oLAI=; > > b=SetRA2kCairxtsHC1kOewT2PFezXmEzlJj0O+TJIxuazQabnVOsPpgH99xV1cCP8ECUcepBON/xEWZOk9oYwqJtPlhrc4dLmpvJ4+rWYN8U89NmIno1ncp8p+1pMmsYBpVvVhFBgse1ohMU0Q0F0iu83GbPqI2Lqqs0NLLsa8m0= > DomainKey-Signature: a=rsa-sha1; c=nofws; > d=gmail.com; s=gamma; > > h=message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; > > b=E7dya/Py5jbcDhzOBvViy4+haGJn/4wQjOYTqUGrmPR171w4e2ayK9J0+kuQC6sVgVs5tvMOO6gugzSzO3807sw2aCCsiEXDKCsr3FdPSpahDfyYjuUv+tgx7VgDoTJZ6kS1Dv5c45uO7rAUBM9Kcdnv6x0+g5l4oTftkO712Io= > Received: by 10.66.254.19 with SMTP id b19mr8816545ugi.7.1208974861524; > Wed, 23 Apr 2008 11:21:01 -0700 (PDT) > Return-Path: > Received: from admin-s-computer-2.local ( [85.250.18.230]) > by mx.google.com with ESMTPS id j33sm36906ugc.63.2008.04.23.11.20.59 > (version=SSLv3 cipher=RC4-MD5); > Wed, 23 Apr 2008 11:21:00 -0700 (PDT) > Message-ID: <480F7E09.9070005 at gmail.com> > Date: Wed, 23 Apr 2008 14:20:57 -0400 > From: Charly Avital > User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; > rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0 > MIME-Version: 1.0 > To: robot-dsa at jameshoward.us > Subject: sign > X-Enigmail-Version: 0.95.6 > OpenPGP: id=A57A8EFA > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > this is test message to robot > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (Darwin) > Comment: GnuPG for Privacy > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iQEcBAEBCAAGBQJID34GAAoJEM3GMi2FW4Pv71MH/iWcbR3F1CGepQyXP3siuTqQ > sN+J2EkWoFISEdeDqWBwG5XSfScwAkvdPEYXK+oACfz5+9MJxS6XrjtgbfD8OGDL > HqcAnYNMUhSextS+LZMkQVFSmBYkdoXGj0UoaG5x0E1fYu7dtN/Zqn7zYtEm1Rw8 > 0xguL6q5M6uHOdI8CybpfgNOXoTs5CKx+WYMcm4oC+ePVlQ6ByjyeVRklrxD0C/M > 77uX5n4ERLM4NeC72NSk8CGoc6ckiPRtciFjwoL+Lt0opJ2o9KfvMdOp2QXls1hi > Zs4/QRB6iyZ1Xoer41pbV4jfnVRVT8uHTxs29QsORTBSkglkcK18y4gSL550d1c= > =I9W8 > -----END PGP SIGNATURE----- > -- James P. Howard, II jh at jameshoward.us http://jameshoward.us From reynt0 at cs.albany.edu Wed Apr 23 21:53:54 2008 From: reynt0 at cs.albany.edu (reynt0) Date: Wed, 23 Apr 2008 15:53:54 -0400 (EDT) Subject: Miscellaneous questions In-Reply-To: <1208974740.9157.1.camel@fermat.scientia.net> References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <20080415215415.GM56745@jabberwocky.com> <1208301557.11857.45.camel@fermat.scientia.net> <480557F2.6000900@sixdemonbag.org> <1208335568.29504.18.camel@etppc19> <20080416124115.GA71474@jabberwocky.com> <1208351068.29504.56.camel@etppc19> <1208359225.29504.82.camel@etppc19> <1208974740.9157.1.camel@fermat.scientia.net> Message-ID: On Wed, 23 Apr 2008, Christoph Anton Mitterer wrote: > On Wed, 2008-04-23 at 13:41 -0400, reynt0 wrote: >> (This is a late comment, I'm catching up reading email, and >> Herr C.A.M has mentioned his idea a couple of times.) > [snip snap] > > Does this contain any question? Well, not specially (ignoring the polite grammar using the form of questions). What it was is a suggestion, stated in third person and a first person example, why one part of your suggestions/opinions might not be a good fit with gpg. IMHO, of course. That's all... From micah at riseup.net Thu Apr 24 01:36:47 2008 From: micah at riseup.net (Micah Anderson) Date: Wed, 23 Apr 2008 19:36:47 -0400 Subject: OpenPGP card stopped working References: <877iepmihe.fsf@lillypad.riseup.net> <20080423115432.GD25385__5906.08652350983$1208953748$gmane$org@newdebian.science> <87zlrklitp.fsf@lillypad.riseup.net> <20080423152325.GC5763__45973.3855016113$1208966500$gmane$org@newdebian.science> Message-ID: <87ve28kusw.fsf@lillypad.riseup.net> Henry Bremridge writes: > On Wed, Apr 23, 2008 at 10:57:54AM -0400, Micah Anderson wrote: >> I too am using Debian (sid), and wonder if this is related to some >> library update. I tried downgrading my libpcsclite1 to the previous >> version, but that didn't change anything. I've tried 2.6.24 and 2.6.22 >> kernels, with similar results. >> >> Had you updated any packages right before you started seeing that? >> > My cron-apt this morning updated the following this morning > > avahi-daemon avahi-utils bind9-host console-common dbus dbus-x11 > libavahi-client3 libavahi-common-data libavahi-common3 > libavahi-compat-libdnssd1 libavahi-core5 libavahi-glib1 libbind9-30 > libdbus-1-3 libdns32 libgl1-mesa-dri libgl1-mesa-glx libglu1-mesa > libgstreamer0.10-0 libisc32 libisccc30 libisccfg30 liblwres30 xsane > xsane-common >From what I can tell, none of those packages should have any affect on the card itself, but I am no expert in this matter. Although it sounds like you just had to reboot, and things worked fine. I'm still unable to access my card. micah From Christoph.Anton.Mitterer at physik.uni-muenchen.de Thu Apr 24 02:59:40 2008 From: Christoph.Anton.Mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Thu, 24 Apr 2008 02:59:40 +0200 Subject: Miscellaneous questions In-Reply-To: References: <1b369b200804140746r29814ea6rb345fe370d91c7e6@mail.gmail.com> <48039215.6010808@sixdemonbag.org> <1208206999.8238.7.camel@fermat.scientia.net> <4803E389.3090500@sixdemonbag.org> <1208219467.12772.2.camel@fermat.scientia.net> <20080415215415.GM56745@jabberwocky.com> <1208301557.11857.45.camel@fermat.scientia.net> <480557F2.6000900@sixdemonbag.org> <1208335568.29504.18.camel@etppc19> <20080416124115.GA71474@jabberwocky.com> <1208351068.29504.56.camel@etppc19> <1208359225.29504.82.camel@etppc19> <1208974740.9157.1.camel@fermat.scientia.net> Message-ID: <20080424025940.g77ez0zm1kc80cw4@webmail.physik.uni-muenchen.de> Quoting reynt0 : > Well, not specially (ignoring the polite grammar using the > form of questions). What it was is a suggestion, stated > in third person and a first person example, why one part > of your suggestions/opinions might not be a good fit > with gpg. IMHO, of course. That's all... Well regarding my opinion on certifications,... I think the list an I won't come to the same understanding in that issue (and probably lots of oter questions, too). Apart from any of our rules or suggestions or whatever you call it, nobody can force users (the signers) to do anyting, as everyone can sign what he/she wants. What I wanted to do, was a suggestion, namely: signers should look at the completeness of the. And if the signer thinks the name is incomplete, he/she should (IMHO) not sign at all, or at leas use perhaps a "lower" signature type (perhaps 0x12 or so; btw: gpg ignores this currently, doesn't it?) Of course we could even discuss what's part of the name?! What about academic titles like "Dr." or "PhD", stuff from monarchy (OBE, Sir, Dame, HRH, Prince, etc.) religious "titles" like "PP", "Cardinal", etc.? Despite of the fact, that it's difficutl to decide what's a complete name, I (= my opinion) think, that signers should have a look on completeness. The reason: As a mathematicion I consider incompleteness as incorrectness, that's even what OpenPGP (and actually every digital signature system) does: If you "just" remove something from the signed data, signatures won't validate. If that reason is to far away from the real world for anyone: Just think if VeriSign or some govermental agency would give you a certificate or some ID card with an incomplete name, e.g. only the family name, or the given name, or even just the first of the given names? Or would it give you a certificate of some ID card with the family name that you had before marriage? It would probably not (for - in my opinion - obvious reason). Of course this doesn not solve problems of ambiguity, but at least it helps a little. That's the same with family names: When they were introduced (probably in the middle-ages?!) one reason surely was to solve the problems of ambiguity of given names. Today there are millions of Christophs,.. but is this a reason to drop the family names? What it all comes down to,... I didn't want to offend anyone on the list, when writing my ideas opinions (thought that this list was open for all ideas and so on). If my tone was a little bit rude, I apologize myself, but it's somewhat frustrating, that (nearly) the only answers I get consist of arguments like, "nobody needs this", "this would break this and that", "be more conservative", "at no way try to possibly clean things up or give part of the standard a cleaner semantics".... I think OpenPGP is quite widespread, neverless it might (this is only a might!!) face extinction. X509/CMS is used more and more in a lot of areas, even gnupg implements it. I think the reason for this is simply that the hierarchical trust model of X509 is much easier for lazy people (lazy in terms of security). Of course OpenPGP is mightier in that way (a hierarchical model is only a subset of its web of trust), but this won't save it on a long term view. As OpenPGP will always be more difficult to use (if you want to build a strong web of trust) I thought that we should concentrate to really improve and perhaps redesign OpenPG from scratch. Stuff like clean separation between IDs and attributes and epsecially _more_ attributes than just name, email and photo are really needed by the industry. However... it seems nearly impossible to me, that such improvements will find consent. :( ... that's why I'm frustrated.... Best wishes, *hoping that he has nobody offended again or started a senseless discussion (Robert?! ;) )*, Chris. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From kevhilton at gmail.com Thu Apr 24 06:33:59 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Wed, 23 Apr 2008 23:33:59 -0500 Subject: Cygwin gpg 1.4.10 -- svn 4752 make error Message-ID: <96c450350804232133p1bdbae68u6167b03e7106e39c@mail.gmail.com> Hmmm seems to be another gettext problem -- Any solutions $ gettext --version gettext (GNU gettext-runtime) 0.17 Copyright (C) 1995-1997, 2000-2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Ulrich Drepper. Making all in intl make[2]: Entering directory `/home/klal/temp/gnupg/svn_gnupg_trunk/intl' gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/local/ share/locale\" -DLIBDIR=\"/usr/local/lib\" -DBUILDING_LIBINTL -DBUILDING_DLL -DI N_LIBINTL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/local/lib\" -D NO_XMALLOC -Dset_relocation_prefix=libintl_set_relocation_prefix -Drelocate=libi ntl_relocate -DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat-nonliteral version.c version.c:26: error: `LIBINTL_VERSION' undeclared here (not in a function) make[2]: *** [version.o] Error 1 make[2]: Leaving directory `/home/klal/temp/gnupg/svn_gnupg_trunk/intl' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/klal/temp/gnupg/svn_gnupg_trunk' make: *** [all] Error 2 -- Kevin Hilton From lists at michel-messerschmidt.de Thu Apr 24 07:56:02 2008 From: lists at michel-messerschmidt.de (Michel Messerschmidt) Date: Thu, 24 Apr 2008 07:56:02 +0200 Subject: Miscellaneous questions In-Reply-To: <20080424025940.g77ez0zm1kc80cw4@webmail.physik.uni-muenchen.de> References: <480557F2.6000900@sixdemonbag.org> <1208335568.29504.18.camel@etppc19> <20080416124115.GA71474@jabberwocky.com> <1208351068.29504.56.camel@etppc19> <1208359225.29504.82.camel@etppc19> <1208974740.9157.1.camel@fermat.scientia.net> <20080424025940.g77ez0zm1kc80cw4@webmail.physik.uni-muenchen.de> Message-ID: <20080424055602.GB5278@koshi.matrix> On Thu, Apr 24, 2008 at 02:59:40AM +0200, Christoph Anton Mitterer wrote: > Of course we could even discuss what's part of the name?! What about > academic titles like "Dr." or "PhD", stuff from monarchy (OBE, Sir, > Dame, HRH, Prince, etc.) religious "titles" like "PP", "Cardinal", etc.? What about second/third ... names, name changes (e.g. marriage), offical pseudonyms (e.g. artist names in Germany), ... ? > Despite of the fact, that it's difficutl to decide what's a complete > name, I (= my opinion) think, that signers should have a look on > completeness. > The reason: As a mathematicion I consider incompleteness as > incorrectness, that's even what OpenPGP (and actually every digital > signature system) does: If you "just" remove something from the signed > data, signatures won't validate. I think you're confusing the "completeness" of the identity with the complete name. Although commonly used, a name is not a good measure for identity. For example, I have different spellings of my name on different official ID cards :) If you require a mathematical completeness, use the key ID. If used for mail encryption/signatures it makes no sense to be more strict than for the email address itself. Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: Digital signature URL: From lists at michel-messerschmidt.de Thu Apr 24 08:26:48 2008 From: lists at michel-messerschmidt.de (Michel Messerschmidt) Date: Thu, 24 Apr 2008 08:26:48 +0200 Subject: OpenPGP card stopped working In-Reply-To: <87ve28kusw.fsf@lillypad.riseup.net> References: <877iepmihe.fsf@lillypad.riseup.net> <20080423115432.GD25385__5906.08652350983$1208953748$gmane$org@newdebian.science> <87zlrklitp.fsf@lillypad.riseup.net> <20080423152325.GC5763__45973.3855016113$1208966500$gmane$org@newdebian.science> <87ve28kusw.fsf@lillypad.riseup.net> Message-ID: <20080424062647.GC5278@koshi.matrix> On Wed, Apr 23, 2008 at 07:36:47PM -0400, Micah Anderson wrote: > >From what I can tell, none of those packages should have any affect on > the card itself, but I am no expert in this matter. > > Although it sounds like you just had to reboot, and things worked > fine. I'm still unable to access my card. Just updated my Debian Lenny system this morning, but the cardman 4040 is still working with gpg and gpg2. But I noticed, that mail signing fails with a similar error, if I just start the mail client. After executing "gpg --card-status" in another terminal, everything works fine. Can you post some configuration details ? $ pccardctl info PRODID_1="OMNIKEY" PRODID_2="CardMan 4040" PRODID_3="" PRODID_4="" MANFID=0223,0200 FUNCID=255 $ pccardctl status Socket 0: 5.0V 16-bit PC Card Subdevice 0 (function 0) bound to driver "cm4040_cs" $ cat /etc/udev/gnupg-ccid.rules # CardMan 4040 (PCMCIA device) ACTION=="add", SUBSYSTEM=="cardman_4040", GROUP="scard", MODE="0660" Package version should be the same in sid and lenny at the moment: ii gnupg 1.4.6-2.1 GNU privacy guard - a free PGP replacement ii gnupg2 2.0.9-1 GNU privacy guard - a free PGP replacement ii gpgv 1.4.6-2.1 GNU privacy guard - signature verification tool ii hal 0.5.11~rc2-1 Hardware Abstraction Layer ii libccid 1.3.5-1 PC/SC driver for USB CCID smart card readers ii libgcrypt11 1.4.0-3 LGPL Crypto library - runtime library ii libgpg-error0 1.4-2 library for common error values and messages in GnuPG ii libpcsclite1 1.4.100-3 Middleware to access a smart card using PC/SC (library ii udev 0.114-2 /dev/ and hotplug management daemon Michel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: Digital signature URL: From sattva at pgpru.com Thu Apr 24 10:59:12 2008 From: sattva at pgpru.com (Vlad "SATtva" Miller) Date: Thu, 24 Apr 2008 15:59:12 +0700 Subject: Timestamping Service: Existing Services or Software Project? In-Reply-To: References: Message-ID: <48104BE0.1020504@pgpru.com> Johannes Graumann (23.04.2008 21:26): > Hi all, > > I've done some superficial googleing, but didn't get far ... so I'm asking > here: > Is anybody aware of a software project implementing a time stamping service > via gnupg: you submit your signature of a file and it comes back signed by > a time stamping authority, which goes to some length to make sure there > machine time is semi-correct, thereby saying that you signed this file > before time X? > > Thanks for any hints, Joh http://timemarker.org/ It's currently in roll-out phase, so keep your eyes open. -- SATtva | security & privacy consulting www.vladmiller.info | www.pgpru.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 513 bytes Desc: OpenPGP digital signature URL: From christoph.anton.mitterer at physik.uni-muenchen.de Thu Apr 24 14:13:33 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Thu, 24 Apr 2008 14:13:33 +0200 Subject: Miscellaneous questions In-Reply-To: <20080424055602.GB5278@koshi.matrix> References: <480557F2.6000900@sixdemonbag.org> <1208335568.29504.18.camel@etppc19> <20080416124115.GA71474@jabberwocky.com> <1208351068.29504.56.camel@etppc19> <1208359225.29504.82.camel@etppc19> <1208974740.9157.1.camel@fermat.scientia.net> <20080424025940.g77ez0zm1kc80cw4@webmail.physik.uni-muenchen.de> <20080424055602.GB5278@koshi.matrix> Message-ID: <1209039213.6656.14.camel@fermat.scientia.net> On Thu, 2008-04-24 at 07:56 +0200, Michel Messerschmidt wrote: > What about second/third ... names, name changes (e.g. marriage), > offical pseudonyms (e.g. artist names in Germany), ... ? Yes of course,.. and lots of other things in other countries and cultures. > > The reason: As a mathematicion I consider incompleteness as > > incorrectness, that's even what OpenPGP (and actually every digital > > signature system) does: If you "just" remove something from the signed > > data, signatures won't validate. > I think you're confusing the "completeness" of the identity with the > complete name. I don't think so, because it is unspecified (and probably unspecifyable) what attributes are part of an identity. You could even say things like your ICQ-number, your eBay-Account or else are part of your identity. > Although commonly used, a name is not a good measure for identity. That's true, that's why I suggested to move the User ID packet away from holding user attributes and use it as a real ID (something the "should" be unique, like and email, DNS-address, a "unique" number or string, etc. etc.). Instead every attributes should go to the User Attribute package, which could be easily expanded for stuff like titles, birthday, brithplace, etc. etc. > For example, I have different spellings of my name on different > official ID cards :) Ok that's strange ^^. But I know that this happens in Germany too, but only on "lesser important" documents. AFAIK the personal ID card (Personalausweis), the Passport and the certificate of birth always have to contain the complete name. > If you require a mathematical completeness, use the key ID. > If used for mail encryption/signatures it makes no sense to be more > strict than for the email address itself. ??? First of all,... the key ID is only the last 8 octets of the fingerprint (IIRC)... and are much easier to forge than the fingerprint. However,.. the neither fingerprint nor the key ID are anything that the user/keyholder is described by (I mean in the real world). Best wishes, Chris. From dan at geer.org Thu Apr 24 14:45:02 2008 From: dan at geer.org (dan at geer.org) Date: Thu, 24 Apr 2008 08:45:02 -0400 Subject: Miscellaneous questions In-Reply-To: Your message of "Thu, 24 Apr 2008 14:13:33 +0200." <1209039213.6656.14.camel@fermat.scientia.net> Message-ID: <20080424124502.5B9B733E97@absinthe.tinho.net> > Although commonly used, a name is not a good measure for identity. My reply is probably very nearly pedantic, but the question raised is a venerable one: Do you want your system to be name-centric or key-centric. A name-centric system is one where the name is the identity, per se, and the key is an attribute of that name. A key-centric system is one where the key is the identity, per se, and the name is an attribute of that key. By analogy, just as there are advantages and disadvantages when comparing bearer bonds versus registered securities, there are advantages and disadvantages when comparing name-centric versus key-centric systems. A reference to an early discussion of binding would be Carl Ellison's 1996 USENIX paper, found at http://world.std.com/~cme/usenix.html. Within an enterprise, name-centric might be the better choice as moves and adds are the principal things that happen to individuals and their roles. As an individual, I prefer key-centric as I've a fairly strong bias toward preserving the benefits of pseudonymity in the face of spreading surveillance. YMMV, --dan From dan at geer.org Thu Apr 24 14:21:59 2008 From: dan at geer.org (dan at geer.org) Date: Thu, 24 Apr 2008 08:21:59 -0400 Subject: Timestamping Service: Existing Services or Software Project? In-Reply-To: Your message of "Thu, 24 Apr 2008 15:59:12 +0700." <48104BE0.1020504@pgpru.com> Message-ID: <20080424122159.7B98433E5D@absinthe.tinho.net> See www.proofspace.com Disclaimer: I am an advisor to this company --dan From mwood at IUPUI.Edu Thu Apr 24 15:22:40 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Thu, 24 Apr 2008 09:22:40 -0400 Subject: Miscellaneous questions In-Reply-To: <20080424055602.GB5278@koshi.matrix> References: <1208335568.29504.18.camel@etppc19> <20080416124115.GA71474@jabberwocky.com> <1208351068.29504.56.camel@etppc19> <1208359225.29504.82.camel@etppc19> <1208974740.9157.1.camel@fermat.scientia.net> <20080424025940.g77ez0zm1kc80cw4@webmail.physik.uni-muenchen.de> <20080424055602.GB5278@koshi.matrix> Message-ID: <20080424132240.GB15574@IUPUI.Edu> Besides, as the Bard says, what's in a name? Binding a key to a name doesn't tell you much. First consider what it is you want to prove, and then you will know what bindings you require. Consider also the distinction between the information required to investigate an identity and the information required to use it. Banks, insurers, employers, etc. want a great deal of information to establish the identities of those with whom they do business, but they don't write it all on the outsides of envelopes that they mail to us. Maybe you want to check my DNA before signing my key, but should I make my genome part of my identifier? Trust in a signature derives from the signer, not from the subject. The user ID really only needs to be a label with sufficient information to decide: "this seems to be the person I want, so I will investigate further." No matter what information is asserted in the user ID, you would have to test the assertion by other means before accepting the identity as meaning what you require. *Once the identity is authenticated* you can use the key binding as a shortcut, assuming that you trust the key's holder to take proper care with it. And then there's the question of roles. "HRH Izzy IV, King of Upper Loa, Duke of Absentia, Protector of the Faith" is a bit much when exchanging mail with relatives, but a salesman might want to provide quite a bit of detail when cultivating business relationships with strangers all over the globe. Generalizing, your business role ID might need more information than your personal role ID, and details would be different and different in nature when acting for your employer vs. for your church or civic organization. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mwood at IUPUI.Edu Thu Apr 24 15:34:52 2008 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Thu, 24 Apr 2008 09:34:52 -0400 Subject: Miscellaneous questions In-Reply-To: <20080424124502.5B9B733E97@absinthe.tinho.net> References: <1209039213.6656.14.camel@fermat.scientia.net> <20080424124502.5B9B733E97@absinthe.tinho.net> Message-ID: <20080424133452.GC15574@IUPUI.Edu> On Thu, Apr 24, 2008 at 08:45:02AM -0400, dan at geer.org wrote: > My reply is probably very nearly pedantic, but the question > raised is a venerable one: Do you want your system to be > name-centric or key-centric. A name-centric system is one > where the name is the identity, per se, and the key is an > attribute of that name. Well, if you want to be pedantic (and I think this is a good place for it), no object can be an identity. An identity is a testable relationship among collections of objects, such as "(1+1) = 2". A given object may be part of many identities -- for example, (4/2) = 2. A name or a key may *label* a particular identity. So your question perhaps should be: which set of labels do you want to use? This is why I keep banging on about what a binding *means*, or what you want to prove. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Typically when a software vendor says that a product is "intuitive" he means the exact opposite. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dshaw at jabberwocky.com Thu Apr 24 18:16:44 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 24 Apr 2008 12:16:44 -0400 Subject: How trust works in gpg... In-Reply-To: <87ve2gd9vc.fsf@wheatstone.g10code.de> References: <200804142205.59132.prlewis@letterboxes.org> <1208209846.9323.1.camel@fermat.scientia.net> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <20080415102143.GC2774@kol06wsthv-it22.kaufhof.net> <20080415180426.GF56745@jabberwocky.com> <87ve2igsaa.fsf@wheatstone.g10code.de> <1208336258.29504.29.camel@etppc19> <87ve2gd9vc.fsf@wheatstone.g10code.de> Message-ID: <20080424161644.GF21811@jabberwocky.com> On Thu, Apr 17, 2008 at 01:00:23PM +0200, Werner Koch wrote: > >> Regarding signing challenges; they are fine as along as a signing subkey > >> is available. > > This sounds interesting. > > What would I now from a signing challenge? What is it exactly? Ask the > > peer to sign my challenge? > > Right. > > > Any why wouldn't it work with the primary (signing) key. > > Because in my case that is off line and I would need to implement quite > some code to take the signing challenge to the secure offline box with > the primary key, sign that the challenge, copy the result back to a > networked box and send it. Yeah, it is possible to do but it does not > make much sense to me. A signing subkey would be easier. A signing subkey doesn't really work here though. A given signing subkey can be attached to any number of keys, and still issue signatures. When a make a certification, I am signing the primary key and a UID. Thus the things I need to "prove" are that primary key and that UID. A signing subkey (or encryption) aren't really involved in that. David From dshaw at jabberwocky.com Thu Apr 24 19:21:08 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 24 Apr 2008 13:21:08 -0400 Subject: How trust works in gpg... In-Reply-To: <1208295750.10031.45.camel@fermat.scientia.net> References: <200804142205.59132.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <4804A994.6020508@sven-radde.de> <200804151433.08557.prlewis@letterboxes.org> <20080415174533.GE56745@jabberwocky.com> <1208287646.4825.75.camel@fermat.scientia.net> <20080415204337.GK56745@jabberwocky.com> <1208293423.10031.4.camel@fermat.scientia.net> <20080415210942.GL56745@jabberwocky.com> <1208295750.10031.45.camel@fermat.scientia.net> Message-ID: <20080424172108.GB21861@jabberwocky.com> On Tue, Apr 15, 2008 at 11:42:30PM +0200, Herbert Furting wrote: > On Tue, 2008-04-15 at 17:09 -0400, David Shaw wrote: > > Change your preferences and GPG will make a new selfsig for you. No > > source hacking needed. > Yes but ok let me explain what I want or would like to have ;-) > > My current key has the following layout: > ***[Pub key packet]*** > ???***[UID]???*** > ???***[0x13 selfsig (SHA1), with cipher-, hash-, compress- algo prefs, key > flags, features, key expiration time and of course stuff like signature > creation time]???*** > > What I would like to have is probably (I'm actually not yet sure ;) ): > ???***[pub key packet]???*** > ???***[0x1F selfsig]???*** > I assume that would be inserted here? > I think it should probably contain, key expiration time, key flags > because as far as I understand this information is clearly bond to the > key (would it make sense to have different key expiration times, or key > flags for different UIDs/roles?) No. Key flags do not pertain to UIDs or roles. They pertain only to keys. What you sketch out above is legal by the spec. No program that I know of does it that way, but it's legal. > And perhaps even the algo prefs the and the features (if they are the > same for all UIDs). Again, legal, but nobody does it that way. > Now here I'm note yet sure and I still discuss with Christoph. > If the algorigthm preferences and features should be considered as > role-preferences,.. the proper place would always be the 0x13 (because > these are for the roles, which are effectively the UIDs). > But if not, it could make sense to put them on a 0x1F, when they're the > same for each UID(/role). > I still could add them to single UIDs if some of them have different > settings because of their environment. Same. > Hmm could one image to have different key-server-uri's per UID? Sure. Say I use the same key for home and work, so I have two UIDs on the key. Work has a keyserver, and home uses a public keyserver. > Is there perhaps a tool that simply allows to edit every aspect of > OpenPGP keys, and that then recreates the selfsigs as desired? Including > lenght calculation of the packets, the hash contexts and the signature > algorithms? > Perhaps something like a counterpart to pgpdump (I love that tool XD). None that I know of. > Ah and perhaps on last question (for now ;) ) if I have your attention > right now. > Does it make sense to put policy URI's on selfsigs? Could you imagine a > possible meaning of such a thing? It's not up to me to say whether it makes sense or not. Policy URIs are for specifying the policy under which a signature was issued. If you want to state the policy for your self sigs, this is how you do it. If you don't, don't. David From dshaw at jabberwocky.com Thu Apr 24 21:12:06 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 24 Apr 2008 15:12:06 -0400 Subject: How trust works in gpg... In-Reply-To: <1208294194.10031.18.camel@fermat.scientia.net> References: <200804142205.59132.prlewis@letterboxes.org> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <200804151052.51733.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <1b369b200804150610r224ef516q136a4e54a9e5d987@mail.gmail.com> <20080415180902.GG56745@jabberwocky.com> <1208288164.4825.84.camel@fermat.scientia.net> <20080415204121.GJ56745@jabberwocky.com> <1208294194.10031.18.camel@fermat.scientia.net> Message-ID: <20080424191206.GD21861@jabberwocky.com> On Tue, Apr 15, 2008 at 11:16:34PM +0200, Christoph Anton Mitterer wrote: > Ok now back to the beginning: When the name in the UID would be just a > cosmetic addition to the actual ID (the e-mail address) I'd say it's > irrelevant if it's complete. > > But if it's interpreted as Name + e-mail of a person, I think one should > only certify the whole name. You are of course free to do so. You are not free to mandate this for others. You can't stand behind people and insist they follow your definition of a "whole name". If nothing else, it's impractical. > With a certification a signator says is the keyholders name, > but in my case my name is neither "Christoph Mitterer", nor "christoph > mitterer", nor "Chris Mitterer" it is (even from a legal point of view > "Christoph Anton Mitterer". > > See my point? I consider missing information as grave as wrong > information. I do see your point, but I think the problem with your idea is that is not how the OpenPGP trust system works. The person who gets to decide if a key+uid should be signed is the person who makes the signature. Nobody else gets a say. David From JPClizbe at tx.rr.com Thu Apr 24 21:36:40 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Thu, 24 Apr 2008 14:36:40 -0500 Subject: Cygwin gpg 1.4.10 -- svn 4752 make error In-Reply-To: <96c450350804232133p1bdbae68u6167b03e7106e39c@mail.gmail.com> References: <96c450350804232133p1bdbae68u6167b03e7106e39c@mail.gmail.com> Message-ID: <4810E148.7050601@tx.rr.com> Kevin Hilton wrote: > Hmmm seems to be another gettext problem -- Any solutions > > $ gettext --version > gettext (GNU gettext-runtime) 0.17 > Copyright (C) 1995-1997, 2000-2007 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Written by Ulrich Drepper. > > Making all in intl > make[2]: Entering directory `/home/klal/temp/gnupg/svn_gnupg_trunk/intl' > gcc -c -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/local/ > share/locale\" -DLIBDIR=\"/usr/local/lib\" -DBUILDING_LIBINTL -DBUILDING_DLL -DI > N_LIBINTL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/local/lib\" -D > NO_XMALLOC -Dset_relocation_prefix=libintl_set_relocation_prefix -Drelocate=libi > ntl_relocate -DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall > -Wcast-align -Wshadow -Wstrict-prototypes -Wformat-nonliteral version.c > version.c:26: error: `LIBINTL_VERSION' undeclared here (not in a function) > make[2]: *** [version.o] Error 1 > make[2]: Leaving directory `/home/klal/temp/gnupg/svn_gnupg_trunk/intl' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/klal/temp/gnupg/svn_gnupg_trunk' > make: *** [all] Error 2 I fired up Cygwin, checked out 4752, and kicked off a build. =================== All 27 tests passed =================== make[2]: Leaving directory `/home/jpclizbe/gnupg-svn/gnupg14r4752/checks' make[1]: Leaving directory `/home/jpclizbe/gnupg-svn/gnupg14r4752/checks' make[1]: Entering directory `/home/jpclizbe/gnupg-svn/gnupg14r4752' make[1]: Nothing to be done for `check-am'. make[1]: Leaving directory `/home/jpclizbe/gnupg-svn/gnupg14r4752' Same result I got with MinGW under MSYS. gettext is 0.16.1 with one patch required to get it to build, AIR. It's probably easier to start with a release (like 1.4.9) and make sure all the bugs are out of your build environment before trying to checkout and build subversion revisions. BTW, this really isn't a *-Users type type problem. You might do better posting to *-Devel. -- John P. Clizbe Inet:JPClizbe (a) tx DAWT rr DAHT con Ginger Bear Networks hkp://keyserver.gingerbear.net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 677 bytes Desc: OpenPGP digital signature URL: From abi.gupta at gmail.com Thu Apr 24 23:52:38 2008 From: abi.gupta at gmail.com (Abhishek Gupta) Date: Thu, 24 Apr 2008 16:52:38 -0500 Subject: Multiple Encrypted Files in one file. Message-ID: <269e9cda0804241452v1d31292epefe865dbdccad50b@mail.gmail.com> Hi All, I have the following issue: I get pgp encrypted files from my service provider in the following format: -----BEGIN PGP MESSAGE----- Version: PGP 7.1 qANQR1DBwEwDYWHBfd1Jrp0BCADsfc9DsOFrdIUI1nb3pRndB2gPTWFskScUQsek JbpliLPK/QhbBHnxYcrS3kFc/HvWGudPUGaitePxe8rpuZLUPpVV5FJGQN7Wln8k e49rVqRa9HC7BcRc2iAB/IJO8cjTtoakuf7PZyvP1njNWxoCycGEpTshTWiwMsmT r9+/ABH40jJyYLDZowrfUMhROH1Xe34Zv8DjO6A+URxulK+WFeQ3oVctmpPsY+Kc M9Vnl/vM6Gbk6g6I1CfZXhKlXrJ/iH8I1SvX6+jnJyTl1rb8nU2iwiEhaA== =OUtn -----END PGP MESSAGE----- -----BEGIN PGP MESSAGE----- Version: PGP 7.1 qANQR1DBwEwDYWHBfd1Jrp0BB/9YjX5hZWvyUBosQT7cJkTZ75gq+HPxXj74RIWN JbpliLPK/QhbBHnxYcrS3kFc/HvWGudPUGaitePxe8rpuZLUPpVV5FJGQN7Wln8k e49rVqRa9HC7BcRc2iAB/IJO8cjTtoakuf7PZyvP1njNWxoCycGEpTshTWiwMsmT r9+/ABH40jJyYLDZowrfUMhROH1Xe34Zv8DjO6A+URxulK+WFeQ3oVctmpPsY+Kc M9Vnl/vM6Gbk6g6I1CfZXhKlXrJ/iH8I1SvX6+jnJyTl1rb8nU2iwiEhaA== =eZ9h -----END PGP MESSAGE----- I am getting this data in 1 file named ABC_12345.dat.asc. I need to decrypt this file without splitting the file but when it try this i am getting the following message: gpg: [don't know]: invalid packet (ctb=1e). I wanted to know if it is possible to decrypt the file without splitting it? If yes, how? Regards, Abhishek. -------------- next part -------------- An HTML attachment was scrubbed... URL: From micah at riseup.net Fri Apr 25 01:22:22 2008 From: micah at riseup.net (Micah Anderson) Date: Thu, 24 Apr 2008 19:22:22 -0400 Subject: OpenPGP card stopped working References: <877iepmihe.fsf@lillypad.riseup.net> <20080423115432.GD25385__5906.08652350983$1208953748$gmane$org@newdebian.science> <87zlrklitp.fsf@lillypad.riseup.net> <20080423152325.GC5763__45973.3855016113$1208966500$gmane$org@newdebian.science> <87ve28kusw.fsf@lillypad.riseup.net> <20080424062647.GC5278__15606.8919612609$1209018577$gmane$org@koshi.matrix> Message-ID: <87lk32j0sx.fsf@lillypad.riseup.net> Michel Messerschmidt writes: > On Wed, Apr 23, 2008 at 07:36:47PM -0400, Micah Anderson wrote: >> >From what I can tell, none of those packages should have any affect on >> the card itself, but I am no expert in this matter. >> >> Although it sounds like you just had to reboot, and things worked >> fine. I'm still unable to access my card. > > Just updated my Debian Lenny system this morning, but the cardman 4040 > is still working with gpg and gpg2. > But I noticed, that mail signing fails with a similar error, if I just > start the mail client. After executing "gpg --card-status" in another > terminal, everything works fine. > > Can you post some configuration details ? > > > $ pccardctl info > PRODID_1="OMNIKEY" > PRODID_2="CardMan 4040" > PRODID_3="" > PRODID_4="" > MANFID=0223,0200 > FUNCID=255 > $ pccardctl status > Socket 0: > 5.0V 16-bit PC Card > Subdevice 0 (function 0) bound to driver "cm4040_cs" # pccardctl info PRODID_1="OMNIKEY" PRODID_2="CardMan 4040" PRODID_3="" PRODID_4="" MANFID=0223,0200 FUNCID=255 PRODID_1="" PRODID_2="" PRODID_3="" PRODID_4="" MANFID=0000,0000 FUNCID=255 > $ cat /etc/udev/gnupg-ccid.rules > # CardMan 4040 (PCMCIA device) > ACTION=="add", SUBSYSTEM=="cardman_4040", GROUP="scard", MODE="0660" My rules are in /etc/udev/rules.d/45-gnupg-ccid.rules and are as follows: # cat 45-gnupg-ccid.rules ## Omnikey CardMan 4040 ACTION=="add", SUBSYSTEM=="cardman_4040", GROUP="scard", MODE="0660" Interestingly, I had also these rules: z60_openct.rules: # omnikey cardman 4040 SUBSYSTEM=="cardman_4040", RUN+="/lib/udev/openct_pcmcia" Due to having libopenct1 openct packages installed. I removed those as they are not needed and I wanted to make sure they weren't interfering. > Package version should be the same in sid and lenny at the moment: > ii gnupg 1.4.6-2.1 GNU privacy guard - a free PGP replacement > ii gnupg2 2.0.9-1 GNU privacy guard - a free PGP replacement > ii gpgv 1.4.6-2.1 GNU privacy guard - signature verification tool > ii hal 0.5.11~rc2-1 Hardware Abstraction Layer > ii libccid 1.3.5-1 PC/SC driver for USB CCID smart card readers > ii libgcrypt11 1.4.0-3 LGPL Crypto library - runtime library > ii libgpg-error0 1.4-2 library for common error values and messages in GnuPG > ii libpcsclite1 1.4.100-3 Middleware to access a smart card using PC/SC (library > ii udev 0.114-2 /dev/ and hotplug management daemon This is what I have: ii gnupg 1.4.6-2.1 GNU privacy guard - a free PGP replacement un gnupg2 (no description available) ii gpgv 1.4.6-2.1 GNU privacy guard - signature verification tool ii hal 0.5.11~rc2-1 Hardware Abstraction Layer un libccid (no description available) ii libgcrypt11 1.4.0-3 LGPL Crypto library - runtime library ii libgpg-error0 1.4-2 library for common error values and messages in GnuPG components ii libpcsclite1 1.4.100-2 Middleware to access a smart card using PC/SC (library) ii udev 0.114-2 /dev/ and hotplug management daemon It was my understanding that libccid was not installed, because gnupg has its own implementation, and gnupg2 is similarly not required, although I have some of the binary packages built from the gnupg2 package, such as gpg-agent, installed. Just to make sure, I installed libccid (1.3.5-1) and gnupg2 (2.0.9-1), which gets this set of packages to the same as yours I've also rebooted and have not had any luck, using kernel 2.6.24-1-686. Micah From dshaw at jabberwocky.com Fri Apr 25 01:22:53 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 24 Apr 2008 19:22:53 -0400 Subject: Multiple Encrypted Files in one file. In-Reply-To: <269e9cda0804241452v1d31292epefe865dbdccad50b@mail.gmail.com> References: <269e9cda0804241452v1d31292epefe865dbdccad50b@mail.gmail.com> Message-ID: <27AA4FB2-C0DE-43B8-A156-53F11A76FCA4@jabberwocky.com> On Apr 24, 2008, at 5:52 PM, Abhishek Gupta wrote: > Hi All, > > I have the following issue: I get pgp encrypted files from my > service provider in the following format: > > -----BEGIN PGP MESSAGE----- > Version: PGP 7.1 > qANQR1DBwEwDYWHBfd1Jrp0BCADsfc9DsOFrdIUI1nb3pRndB2gPTWFskScUQsek > JbpliLPK/QhbBHnxYcrS3kFc/HvWGudPUGaitePxe8rpuZLUPpVV5FJGQN7Wln8k > e49rVqRa9HC7BcRc2iAB/IJO8cjTtoakuf7PZyvP1njNWxoCycGEpTshTWiwMsmT > r9+/ABH40jJyYLDZowrfUMhROH1Xe34Zv8DjO6A+URxulK+WFeQ3oVctmpPsY+Kc > M9Vnl/vM6Gbk6g6I1CfZXhKlXrJ/iH8I1SvX6+jnJyTl1rb8nU2iwiEhaA== > =OUtn > -----END PGP MESSAGE----- > -----BEGIN PGP MESSAGE----- > Version: PGP 7.1 > qANQR1DBwEwDYWHBfd1Jrp0BB/9YjX5hZWvyUBosQT7cJkTZ75gq+HPxXj74RIWN > JbpliLPK/QhbBHnxYcrS3kFc/HvWGudPUGaitePxe8rpuZLUPpVV5FJGQN7Wln8k > e49rVqRa9HC7BcRc2iAB/IJO8cjTtoakuf7PZyvP1njNWxoCycGEpTshTWiwMsmT > r9+/ABH40jJyYLDZowrfUMhROH1Xe34Zv8DjO6A+URxulK+WFeQ3oVctmpPsY+Kc > M9Vnl/vM6Gbk6g6I1CfZXhKlXrJ/iH8I1SvX6+jnJyTl1rb8nU2iwiEhaA== > =eZ9h > -----END PGP MESSAGE----- > > I am getting this data in 1 file named ABC_12345.dat.asc. I need to > decrypt this file without splitting the file but when it try this i > am getting the following message: gpg: [don't know]: invalid packet > (ctb=1e). > > I wanted to know if it is possible to decrypt the file without > splitting it? If yes, how? Sorry, no. You must split the file before passing it to GPG. David From wk at gnupg.org Fri Apr 25 09:57:41 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Apr 2008 09:57:41 +0200 Subject: How trust works in gpg... In-Reply-To: <20080424191206.GD21861@jabberwocky.com> (David Shaw's message of "Thu, 24 Apr 2008 15:12:06 -0400") References: <200804142205.59132.prlewis@letterboxes.org> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <200804151052.51733.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <1b369b200804150610r224ef516q136a4e54a9e5d987@mail.gmail.com> <20080415180902.GG56745@jabberwocky.com> <1208288164.4825.84.camel@fermat.scientia.net> <20080415204121.GJ56745@jabberwocky.com> <1208294194.10031.18.camel@fermat.scientia.net> <20080424191206.GD21861@jabberwocky.com> Message-ID: <8763u6bc3u.fsf@wheatstone.g10code.de> On Thu, 24 Apr 2008 21:12, dshaw at jabberwocky.com said: > not how the OpenPGP trust system works. The person who gets to decide > if a key+uid should be signed is the person who makes the signature. Nitpicking: It is not the OpenPGP trust system, but the way almost all OpenPGP applications are used (basically Web of Trust). OpenPGP is just a framework and you may implement any trust system on top of it; using the mechanisms provided by OpenPGP. I have to mention this because many people believe OpenPGP demands the WoT and exclude OpenPGP from further inspection when searching for a specialized PKI. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Fri Apr 25 15:11:55 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 25 Apr 2008 09:11:55 -0400 Subject: How trust works in gpg... In-Reply-To: <8763u6bc3u.fsf@wheatstone.g10code.de> References: <200804142205.59132.prlewis@letterboxes.org> <200804142320.29571.prlewis@letterboxes.org> <1208212963.9323.10.camel@fermat.scientia.net> <200804151052.51733.prlewis@letterboxes.org> <48049BFF.nail56411UIHS@mailshack.com> <1b369b200804150610r224ef516q136a4e54a9e5d987@mail.gmail.com> <20080415180902.GG56745@jabberwocky.com> <1208288164.4825.84.camel@fermat.scientia.net> <20080415204121.GJ56745@jabberwocky.com> <1208294194.10031.18.camel@fermat.scientia.net> <20080424191206.GD21861@jabberwocky.com> <8763u6bc3u.fsf@wheatstone.g10code.de> Message-ID: On Apr 25, 2008, at 3:57 AM, Werner Koch wrote: > On Thu, 24 Apr 2008 21:12, dshaw at jabberwocky.com said: > >> not how the OpenPGP trust system works. The person who gets to >> decide >> if a key+uid should be signed is the person who makes the signature. > > Nitpicking: It is not the OpenPGP trust system, but the way almost all > OpenPGP applications are used (basically Web of Trust). OpenPGP is > just > a framework and you may implement any trust system on top of it; using > the mechanisms provided by OpenPGP. > > I have to mention this because many people believe OpenPGP demands the > WoT and exclude OpenPGP from further inspection when searching for a > specialized PKI. Absolutely. At one point there was talk about putting together an RFC for a defined OpenPGP trust system (essentially documenting what we have now), but there didn't seem to be much interest in it. A significant use of OpenPGP is without the WoT at all. David From gnupg-users at 3bdr.com Fri Apr 25 05:52:12 2008 From: gnupg-users at 3bdr.com (David Stults) Date: Thu, 24 Apr 2008 20:52:12 -0700 Subject: Vandalizing keyserver UID's Message-ID: <520C36A8-E45A-48B4-93E4-D3D19B5E94EC@3bdr.com> Greetings, This evening I've been working on stamping old public keys (long since lost the secret key) with a bogus UID to inspire people to avoid trying to use them. I'm curious as to how I can tell the UID is fake. For example, here is the GPG output of --list-keys for one of the keys I branded: pub 1024D/DF71515D 2000-02-21 uid David Stults sig DF71515D 2000-02-21 David Stults uid DO NOT USE THIS KEY! sig DF71515D 2000-02-21 David Stults sub 2048g/78B9A888 2000-02-21 sig DF71515D 2000-02-21 David Stults That seems to imply that even the bogus UID (the second one, as you may have guessed ;-)) is in fact signed. The keyserver displays it differently, but seems to make the same assertion: uid DO NOT USE THIS KEY! sig sig DF71515D 2000-02-21 __________ __________ [selfsig] uid David Stults sig sig DF71515D 2000-02-21 __________ __________ [selfsig] sub 2048g/78B9A888 2000-02-21 sig sbind DF71515D 2000-02-21 __________ __________ [] Forgive me I've just been obtuse. It isn't making sense to me, and I'd like it to. I want to be able to look at a public key and determine if any bogus UID's have been added to it. The only thing I've noticed is that my newer keys say "sig 3", while the older ones don't have a certification level given. Thanks! Dave --- David Stults PGP Key 0x97715d12 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0x97715D12 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshaw at jabberwocky.com Fri Apr 25 18:06:42 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 25 Apr 2008 12:06:42 -0400 Subject: Vandalizing keyserver UID's In-Reply-To: <520C36A8-E45A-48B4-93E4-D3D19B5E94EC@3bdr.com> References: <520C36A8-E45A-48B4-93E4-D3D19B5E94EC@3bdr.com> Message-ID: <20080425160642.GA6012@jabberwocky.com> On Thu, Apr 24, 2008 at 08:52:12PM -0700, David Stults wrote: > > Greetings, > > This evening I've been working on stamping old public keys (long since lost > the secret key) with a bogus UID to inspire people to avoid trying to use > them. I'm curious as to how I can tell the UID is fake. For example, here > is the GPG output of --list-keys for one of the keys I branded: > > pub 1024D/DF71515D 2000-02-21 > uid David Stults > sig DF71515D 2000-02-21 David Stults > uid DO NOT USE THIS KEY! > sig DF71515D 2000-02-21 David Stults > sub 2048g/78B9A888 2000-02-21 > sig DF71515D 2000-02-21 David Stults > > That seems to imply that even the bogus UID (the second one, as you may > have guessed ;-)) is in fact signed. > > The keyserver displays it differently, but seems to make the same > assertion: > > uid DO NOT USE THIS KEY! > sig sig DF71515D 2000-02-21 __________ __________ [selfsig] > > uid David Stults > sig sig DF71515D 2000-02-21 __________ __________ [selfsig] > > sub 2048g/78B9A888 2000-02-21 > sig sbind DF71515D 2000-02-21 __________ __________ [] > > Forgive me I've just been obtuse. It isn't making sense to me, and I'd > like it to. I want to be able to look at a public key and determine if any > bogus UID's have been added to it. The only thing I've noticed is that my > newer keys say "sig 3", while the older ones don't have a certification > level given. The problem is that you aren't asking GPG to check that signature, just dump the whole key. Note what happens when you do '--check-sigs' instead of '--list-sigs'. GPG won't use that user ID for anything, as it is not certified. In fact, GPG won't even import the unsigned UID unless you specifically tell it to. Current keyservers don't have crypto at all (they're pure storage) so they never check signatures. David From wk at gnupg.org Fri Apr 25 18:51:21 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Apr 2008 18:51:21 +0200 Subject: [Announce] Libgcrypt 1.4.1 released Message-ID: <87ve2598ty.fsf@wheatstone.g10code.de> Hello! The GNU project is pleased to announce the availability of Libgcrypt version 1.4.1. This is a maintenance release to fix a few problems. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on code used by GnuPG. It does not provide any implementation of OpenPGP or other protocols. Thorough understanding of applied cryptography is required to use Libgcrypt. Noteworthy changes in version 1.4.1 (2008-04-25) ------------------------------------------------ * Fixed a bug introduced by 1.3.1 which led to the comsumption of far too much entropy for the intial seeding. * Improved AES performance for CFB and CBC modes. * Removed build problems for the Padlock support. Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source file and its digital signatures is: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.1.tar.bz2 (946k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.1.tar.bz2.sig This file is bzip2 compressed. A gzip compressed version is also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.1.tar.gz (1179k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.1.tar.gz.sig Alternativley you may upgrade version 1.4.0 using this patch file: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.4.0-1.4.1.diff.bz2 (49k) The SHA-1 checksums are: 367fe7fecd2ed4ab743849279dbc2f7e148f9956 libgcrypt-1.4.1.tar.bz2 36f1c6632fa06a6d3c92f83c3cdca8c7731a4220 libgcrypt-1.4.1.tar.gz 458fa5939df46da383df64b27ed8f8f580931618 libgcrypt-1.4.0-1.4.1.diff.bz2 For help on developing with Libgcrypt you should read the included manual and optional ask on the gcrypt-devel mailing list [1]. Improving Libgcrypt is costly, but you can help! We are looking for organizations that find Libgcrypt useful and wish to contribute back. You can contribute by reporting bugs, improve the software [2], order extensions or support or more general by donating money to the Free Software movement [3]. Commercial support contracts for Libgcrypt are available [4], and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company, is currently funding Libgcrypt development. We are always looking for interesting development projects. Many thanks to all who contributed to Libgcrypt development, be it bug fixes, code, documentation, testing or helping users. Happy hacking, Werner [1] See http://www.gnupg.org/documentation/mailing-lists.html . [2] Note that copyright assignments to the FSF are required. [3] For example http://www.fsfeurope.org/help/donate.en.html . [4] See the service directory at http://www.gnupg.org/service.html . -- 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 cwal989 at comcast.net Fri Apr 25 21:46:50 2008 From: cwal989 at comcast.net (Chris Walters) Date: Fri, 25 Apr 2008 15:46:50 -0400 Subject: Naming of GnuPG In-Reply-To: <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> Message-ID: <4812352A.6080303@comcast.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 David Shaw wrote: | Do people find the 1.4.x / 2.0.x thing confusing? I can only speak for myself. I don't find the 1.4.x / 2.0.x version numbering thing confusing at all. They each serve a different purpose and a different audience. I note that, currently, 1.4.x needs to be patched to compile in support for IDEA, while 2.0.x has it, and a lot of other capabilities already there. I have compiled both on both GNU/Linux and Win32, and found that, as long as I have the appropriate libraries, they both will compile and work correctly. Of course, I am a programmer, so I am used to separate versions of the same program. Regards, Chris PS: Sorry David, I hit the wrong button and forgot to check who I was sending this message to. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJIEjUkAAoJEE8J0h3nbis2eg4P/2ovKaUecM856KlyqY0kDKSe R03oVKjVOvi1i/e9j7JY0Ql2fJ84iWD1Z4Hxt7Yie7Orjse67XEkKI1E4B5JUraD zScM/x2UpqdF6yt7NvYN4WNSNAU6/EHIyPQBFRdyYepI/NI6U/lARUaSFjikBX67 uqtXneqoV6mikLwsb3clAmRphpHGtYYmAcSJxVccuQZCz9RsoLpBfAvkGoLHc2sV Q9vwPX7cCtUcmC/XeZGWQdcXWM9cZKrKblVOrNSdq7UqtqcThYYAN1WFPPZCg5VV 8HQML02dNKT7PAS29vtKYFOqs4D5bGvQfvfkAdUA9nuHZjWuj//x4K516WLaj3dh YxMgE2bKOHI+31yf1R6CSpE1Cgy84eZSAeZRMWOwdetRA9ElrUTWvOc3q+vAxEec 3Mny7ahw0B63cQjs9LGviFvxqVGHAzxaW9hj1zGpNy4npkWuNwvewZlXybcPAyQw w6CHnGyTGshwRyJKQU0SHTvOm1jwjgV6Qx4aYL8AUneD/VwcIf4UWppmVKU+fTk6 P7QztZkZFJf+e0Oo/Yl5g4iZehhfBcKZwlAyMubTDeG/sgCRDP10jTthakERbnZr +2BgXIz+ElT84KYKl4GIxR2+16q8vj7HB/LSHsxDur83MPP4mGcJCajnolm0zc/0 M7EiWOc4IJaasFNVBH5P =fY17 -----END PGP SIGNATURE----- From jh at jameshoward.us Sat Apr 26 00:23:21 2008 From: jh at jameshoward.us (James P. Howard, II) Date: Fri, 25 Apr 2008 18:23:21 -0400 Subject: Timestamping Service: Existing Services or Software Project? In-Reply-To: <88a2333a0804231148v44abd3eehd9182921583cc4a6@mail.gmail.com> References: <88a2333a0804230750m37ed01cfv9b30969ca469f2bc@mail.gmail.com> <480F4E81.7070602@radde.name> <773557482-1208966898-cardhu_decombobulator_blackberry.rim.net-1985753767-@bxe140.bisx.prod.on.blackberry> <480F8124.6070301@mac.com> <88a2333a0804231148v44abd3eehd9182921583cc4a6@mail.gmail.com> Message-ID: <88a2333a0804251523m32eda5dai20d2bf80f60deb3b@mail.gmail.com> Aha! My provider fixed a doohickey somewhere (it was an error in a mail forwarding configuration file) and it now works. James On 4/23/08, James P. Howard, II wrote: > This is embarrassing. I've contacted my provider to find out why mail > is bouncing. > > Thank you, James > > On Wed, Apr 23, 2008 at 2:34 PM, Charly Avital wrote: > > James P. Howard wrote the following on 4/23/08 12:08 PM: > > > > > Yep, sorry about that. Try this instead: > > > > > > http://jameshoward.us/robot-digital-signature-authority > > > > > > James > > > > > > -- > > > James P. Howard, II > > > jh at jameshoward.us > > > http://jameshoward.us > > > > > [...] > > > > Sent a signed test message using my gmail account (please see below), > > with sign as subject. > > Received the following: > > > > Hi. This is the qmail-send program at ivy.phpwebhosting.com. > > I'm afraid I wasn't able to deliver your message to the following > addresses. > > This is a permanent error; I've given up. Sorry it didn't work out. > > > > : > > Sorry. Although I'm listed as a best-preference MX or A for that host, > > it isn't in my control/locals file, so I don't treat it as local. > (#5.4.6) > > > > --- Below this line is a copy of the message. > > > > Return-Path: > > Received: (qmail 2907 invoked by uid 457); 23 Apr 2008 18:23:08 -0000 > > Delivered-To: jphoward.com-pgprobots at jphoward.com > > Received: (qmail 2905 invoked by uid 457); 23 Apr 2008 18:23:08 -0000 > > Delivered-To: jameshoward.us-robot-dsa at jameshoward.us > > Received: (qmail 2903 invoked from network); 23 Apr 2008 18:23:08 -0000 > > Received: from unknown (HELO ug-out-1314.google.com) (66.249.92.172) > > by c5.e0.5746.static.theplanet.com with SMTP; Wed, 23 Apr 2008 > 14:23:08 > > -0400 > > Received: by ug-out-1314.google.com with SMTP id o38so624527ugd.17 > > for ; Wed, 23 Apr 2008 11:21:01 -0700 > > (PDT) > > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > > d=gmail.com; s=gamma; > > > > > h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; > > bh=OsiFsFEMx5La7hrc4yqTYJX3pg3pcND3tHuLpJ2oLAI=; > > > > > b=SetRA2kCairxtsHC1kOewT2PFezXmEzlJj0O+TJIxuazQabnVOsPpgH99xV1cCP8ECUcepBON/xEWZOk9oYwqJtPlhrc4dLmpvJ4+rWYN8U89NmIno1ncp8p+1pMmsYBpVvVhFBgse1ohMU0Q0F0iu83GbPqI2Lqqs0NLLsa8m0= > > DomainKey-Signature: a=rsa-sha1; c=nofws; > > d=gmail.com; s=gamma; > > > > > h=message-id:date:from:user-agent:mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; > > > > > b=E7dya/Py5jbcDhzOBvViy4+haGJn/4wQjOYTqUGrmPR171w4e2ayK9J0+kuQC6sVgVs5tvMOO6gugzSzO3807sw2aCCsiEXDKCsr3FdPSpahDfyYjuUv+tgx7VgDoTJZ6kS1Dv5c45uO7rAUBM9Kcdnv6x0+g5l4oTftkO712Io= > > Received: by 10.66.254.19 with SMTP id b19mr8816545ugi.7.1208974861524; > > Wed, 23 Apr 2008 11:21:01 -0700 (PDT) > > Return-Path: > > Received: from admin-s-computer-2.local ( [85.250.18.230]) > > by mx.google.com with ESMTPS id > j33sm36906ugc.63.2008.04.23.11.20.59 > > (version=SSLv3 cipher=RC4-MD5); > > Wed, 23 Apr 2008 11:21:00 -0700 (PDT) > > Message-ID: <480F7E09.9070005 at gmail.com> > > Date: Wed, 23 Apr 2008 14:20:57 -0400 > > From: Charly Avital > > User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; > > rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0 > > MIME-Version: 1.0 > > To: robot-dsa at jameshoward.us > > Subject: sign > > X-Enigmail-Version: 0.95.6 > > OpenPGP: id=A57A8EFA > > Content-Type: text/plain; charset=ISO-8859-1 > > Content-Transfer-Encoding: 7bit > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > this is test message to robot > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.9 (Darwin) > > Comment: GnuPG for Privacy > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iQEcBAEBCAAGBQJID34GAAoJEM3GMi2FW4Pv71MH/iWcbR3F1CGepQyXP3siuTqQ > > sN+J2EkWoFISEdeDqWBwG5XSfScwAkvdPEYXK+oACfz5+9MJxS6XrjtgbfD8OGDL > > HqcAnYNMUhSextS+LZMkQVFSmBYkdoXGj0UoaG5x0E1fYu7dtN/Zqn7zYtEm1Rw8 > > 0xguL6q5M6uHOdI8CybpfgNOXoTs5CKx+WYMcm4oC+ePVlQ6ByjyeVRklrxD0C/M > > 77uX5n4ERLM4NeC72NSk8CGoc6ckiPRtciFjwoL+Lt0opJ2o9KfvMdOp2QXls1hi > > Zs4/QRB6iyZ1Xoer41pbV4jfnVRVT8uHTxs29QsORTBSkglkcK18y4gSL550d1c= > > =I9W8 > > -----END PGP SIGNATURE----- > > > > > > -- > James P. Howard, II > jh at jameshoward.us > http://jameshoward.us > -- James P. Howard, II jh at jameshoward.us http://jameshoward.us From dirk.traulsen at lypso.de Sat Apr 26 08:54:52 2008 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Sat, 26 Apr 2008 08:54:52 +0200 Subject: Naming of GnuPG In-Reply-To: <2AF9AECC-2F51-49F4-8D53-7E9D3FB648A2@jabberwocky.com> References: <480939DE.5080108@gmail.com>, <20080421133034.GB7699@IUPUI.Edu>, <2AF9AECC-2F51-49F4-8D53-7E9D3FB648A2@jabberwocky.com> Message-ID: <4812EDDC.20483.23AC2374@dirk.traulsen.lypso.de> Am 21 Apr 2008 um 9:43 hat David Shaw geschrieben: > On Apr 21, 2008, at 9:30 AM, Mark H. Wood wrote: > > > So, GnuPG 1.4 implements OpenPGP. GnuPG 2.0 implements OpenPGP > > and S/MIME. > > > > So 2.0 is "better" than 1.4 if you need S/MIME, otherwise not. > > > > So, perhaps 1.4 should be GnuPG and 2.0 should be GnuPG-Plus. > > (Please, no "++"!) > > How about: > > 1.4 == GnuPG Classic > 2.0 == GnuPG Plus > > David As gpg2 seems to generate a lot of confusion, I second the renaming to make the different purposes as clear as possible. The main and most important difference is the addition of S/MIME, so it should be part of the new name and command. How about: gpg == GnuPG == GnuPG Classic gpgs == GnuPG+S == GnuPG+S/MIME Dirk From rjh at sixdemonbag.org Sat Apr 26 09:20:16 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 26 Apr 2008 02:20:16 -0500 Subject: Naming of GnuPG In-Reply-To: <4812EDDC.20483.23AC2374@dirk.traulsen.lypso.de> References: <480939DE.5080108@gmail.com>, <20080421133034.GB7699@IUPUI.Edu>, <2AF9AECC-2F51-49F4-8D53-7E9D3FB648A2@jabberwocky.com> <4812EDDC.20483.23AC2374@dirk.traulsen.lypso.de> Message-ID: <4812D7B0.3020002@sixdemonbag.org> Dirk Traulsen wrote: > gpg == GnuPG == GnuPG Classic > gpgs == GnuPG+S == GnuPG+S/MIME My own two cents' worth: GnuPG was originally named as such, as I understand it, as a sort of play on PGP. GPG was a Free Software alternative to PGP. The metonymy (if that's the appropriate word) made it easy to understand how GPG fit into the software landscape. PGP. GPG. Closely related and interoperable programs. I'd like to see GPG remain the name for only 1.4. GnuPG 2.x introduces a lot of new crypto support that is not related to OpenPGP. The original metonymy is no longer appropriate. Call it GnuPS, for the GNU Privacy Suite. If additional tools, technologies, etc., are added to GnuPG 2.x or a future 3.0, then the GnuPS name can remain unchanged. In order to limit confusion with the Global Positioning System (GPS), it should always be spelled out as GnuPS. From dirk.traulsen at lypso.de Sat Apr 26 12:24:31 2008 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Sat, 26 Apr 2008 12:24:31 +0200 Subject: Naming of GnuPG In-Reply-To: <4812D7B0.3020002@sixdemonbag.org> References: <480939DE.5080108@gmail.com>, <4812EDDC.20483.23AC2374@dirk.traulsen.lypso.de>, <4812D7B0.3020002@sixdemonbag.org> Message-ID: <48131EFF.6437.246C3A9F@dirk.traulsen.lypso.de> Am 26 Apr 2008 um 2:20 hat Robert J. Hansen geschrieben: > Dirk Traulsen wrote: > > gpg == GnuPG == GnuPG Classic > > gpgs == GnuPG+S == GnuPG+S/MIME > > My own two cents' worth: (...) > Call it GnuPS, for the GNU Privacy Suite. If additional tools, > technologies, etc., are added to GnuPG 2.x or a future 3.0, then the > GnuPS name can remain unchanged. > > In order to limit confusion with the Global Positioning System (GPS), > it should always be spelled out as GnuPS. Funny, I first had exactly the same idea! But I choose "gpgs", because besides being a bit longer to type, "gnups" has one point, which is not perfect: It doesn't contain the well-known "gpg" in the name in spite of sharing the same code base for OpenPGP. But I'm sure, either name gives less problems than GnuPG 2.0. If you keep this name, you will have to explain again and again and again... Dirk From tinloaf at goerresonline.de Sat Apr 26 17:39:14 2008 From: tinloaf at goerresonline.de (Lukas Barth) Date: Sat, 26 Apr 2008 17:39:14 +0200 Subject: Web of Trust Message-ID: <48134CA2.7070607@goerresonline.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have a question regarding the way GPG handles the way of trust. Let's say i have four keys (A-D). Key A is my own one, so I trust it ultimately and it is valid by definition. I signed B with A and set B's ownertrust to "full". B signed C, and B trusts C only marginally. C signed D, so it's like: A->B->C->D Now, since B is valid (I signed it) and I trust B fully C will be considered valid, too. But how about D? I can think of three possibilities: 1) Since B is trusted fully, C is also trusted fully (after verifying it with B's signature), and so D is considered valid. This would be *bad* since B originally had only marginal trust in C, and I would now have full trust in C. 2) Since I did not assign an ownertrust to C myself, gpg does not trust C at all and so D is not valid. This would also be kind of bad since I would have to set a whole lot of ownertrusts for my PKI to be established. (For every key to be verified it would have to be signed by at least one key I manually set the ownertrust for) 3) B's trust in C is included in B's signature and so GPG knows that it should trust C only marginally and searches for other signatures of C, until it are enough for C to be trusted. This would be great! Which way is implemented in GPG? Kind regards, Lukas Barth -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgTTKAACgkQgsbFi6ZpoGFUywCeNR8iIAxwkU/Yn9zXTNcLgV6o EEwAoIVn1QFmd0eHXwiPu+acJiN/9Xr0 =J2zP -----END PGP SIGNATURE----- From camrdale at gmail.com Sun Apr 27 04:22:50 2008 From: camrdale at gmail.com (Cameron Dale) Date: Sat, 26 Apr 2008 19:22:50 -0700 Subject: dearmor in GPGME In-Reply-To: References: Message-ID: Hi, I have an armored detached signature that I want to dearmor (without using the original plain text). I can do it on the command line with the --dearmor option, but how can I do it in GPGME? Is it possible? Thanks, Cameron From dshaw at jabberwocky.com Sun Apr 27 05:08:34 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 26 Apr 2008 23:08:34 -0400 Subject: Web of Trust In-Reply-To: <48134CA2.7070607@goerresonline.de> References: <48134CA2.7070607@goerresonline.de> Message-ID: <1674E43E-EAEA-4574-9CAD-D6CC6664493A@jabberwocky.com> On Apr 26, 2008, at 11:39 AM, Lukas Barth wrote: > I have a question regarding the way GPG handles the way of trust. > Let's > say i have four keys (A-D). Key A is my own one, so I trust it > ultimately and it is valid by definition. I signed B with A and set > B's > ownertrust to "full". B signed C, and B trusts C only marginally. C > signed D, so it's like: > > A->B->C->D > > Now, since B is valid (I signed it) and I trust B fully C will be > considered valid, too. But how about D? I can think of three > possibilities: > > 1) Since B is trusted fully, C is also trusted fully (after > verifying it > with B's signature), and so D is considered valid. This would be *bad* > since B originally had only marginal trust in C, and I would now have > full trust in C. > > 2) Since I did not assign an ownertrust to C myself, gpg does not > trust > C at all and so D is not valid. This would also be kind of bad since I > would have to set a whole lot of ownertrusts for my PKI to be > established. (For every key to be verified it would have to be > signed by > at least one key I manually set the ownertrust for) > > 3) B's trust in C is included in B's signature and so GPG knows that > it > should trust C only marginally and searches for other signatures of C, > until it are enough for C to be trusted. This would be great! > > Which way is implemented in GPG? I think there is some confusion between "validity" and "trust" in the above, so it is very difficult to understand what you are asking here. Basically, in the 4-key universe above, A is valid (you), B is valid (you signed it), C is valid (B signed it, B is valid, and has full ownertrust). D is not valid because even though C signed it, C has no ownertrust. I'm not sure what you are trying to get at with #3. It doesn't seem to follow the problem statement of the 4-key universe. If there are other keys in play here with other signatures, then you need to state them in the problem. David From mlisten at hammernoch.net Sun Apr 27 12:04:30 2008 From: mlisten at hammernoch.net (=?ISO-8859-1?Q?Ludwig_H=FCgelsch=E4fer?=) Date: Sun, 27 Apr 2008 12:04:30 +0200 Subject: Naming of GnuPG In-Reply-To: <4812D7B0.3020002@sixdemonbag.org> References: <480939DE.5080108@gmail.com>, <20080421133034.GB7699@IUPUI.Edu>, <2AF9AECC-2F51-49F4-8D53-7E9D3FB648A2@jabberwocky.com> <4812EDDC.20483.23AC2374@dirk.traulsen.lypso.de> <4812D7B0.3020002@sixdemonbag.org> Message-ID: <48144FAE.8090209@hammernoch.net> Robert J. Hansen wrote on 26.04.2008 9:20 Uhr: > (...) > I'd like to see GPG remain the name for only 1.4. > > GnuPG 2.x introduces a lot of new crypto support that is not related to > OpenPGP. The original metonymy is no longer appropriate. > > Call it GnuPS, for the GNU Privacy Suite. If additional tools, > technologies, etc., are added to GnuPG 2.x or a future 3.0, then the > GnuPS name can remain unchanged. Good idea on the first thought! On the second thought, however, I associate the name "suite" not only with a command line tool (or a family of), but additionally with a GUI and something like an encrypted file system (e.g. PGP-Disc, truecrypt). Just my impression. Ludwig From cronos at ntlworld.com Tue Apr 22 20:27:42 2008 From: cronos at ntlworld.com (cronos) Date: Tue, 22 Apr 2008 19:27:42 +0100 Subject: decrypting a message. Message-ID: <1208888862.6822.1.camel@darkstar> Hi, I'm at a bit of a loss decrypting a message. No matter what I do I always seem to get: gpg: encrypted with ELG-E key, ID C8A0C2BB gpg: decryption failed: secret key not available when I run gpg like this: $gpg --list-packets msg.pgp :pubkey enc packet: version 3, algo 16, keyid 9C53A76FC8A0C2BB data: [1023 bits] data: [1023 bits] :encrypted data packet: length: 149 mdc_method: 2 gpg: encrypted with ELG-E key, ID C8A0C2BB gpg: decryption failed: secret key not available Shouldn't it be asking me for the passphrase at some point? Thanks From ivalladt at gmail.com Wed Apr 23 09:41:35 2008 From: ivalladt at gmail.com (Ismael Valladolid Torres) Date: Wed, 23 Apr 2008 09:41:35 +0200 Subject: editing User ID In-Reply-To: <88a2333a0804221145r164be5f0yca55bff8facb4607@mail.gmail.com> References: <20080417161330.GA1019@jabberwocky.com> <88a2333a0804221145r164be5f0yca55bff8facb4607@mail.gmail.com> Message-ID: On Tue, Apr 22, 2008 at 8:45 PM, James P. Howard, II wrote: > Generally speaking, yes. But if the user has not yet published his > key, there is no harm in just removing it. Of course, nonetheless "revoking" instead of "deleting" is usually the way to go talking about pgp/gnupg. From david at stults.com Fri Apr 25 05:52:12 2008 From: david at stults.com (David Stults) Date: Thu, 24 Apr 2008 20:52:12 -0700 Subject: Vandalizing keyserver UID's Message-ID: <520C36A8-E45A-48B4-93E4-D3D19B5E94EC@stults.com> Greetings, This evening I've been working on stamping old public keys (long since lost the secret key) with a bogus UID to inspire people to avoid trying to use them. I'm curious as to how I can tell the UID is fake. For example, here is the GPG output of --list-keys for one of the keys I branded: pub 1024D/DF71515D 2000-02-21 uid David Stults sig DF71515D 2000-02-21 David Stults uid DO NOT USE THIS KEY! sig DF71515D 2000-02-21 David Stults sub 2048g/78B9A888 2000-02-21 sig DF71515D 2000-02-21 David Stults That seems to imply that even the bogus UID (the second one, as you may have guessed ;-)) is in fact signed. The keyserver displays it differently, but seems to make the same assertion: uid DO NOT USE THIS KEY! sig sig DF71515D 2000-02-21 __________ __________ [selfsig] uid David Stults sig sig DF71515D 2000-02-21 __________ __________ [selfsig] sub 2048g/78B9A888 2000-02-21 sig sbind DF71515D 2000-02-21 __________ __________ [] Forgive me I've just been obtuse. It isn't making sense to me, and I'd like it to. I want to be able to look at a public key and determine if any bogus UID's have been added to it. The only thing I've noticed is that my newer keys say "sig 3", while the older ones don't have a certification level given. Thanks! Dave --- David Stults PGP Key 0x97715d12 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0x97715D12 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjw2004d at comcast.net Fri Apr 25 15:29:14 2008 From: cjw2004d at comcast.net (Chris Walters) Date: Fri, 25 Apr 2008 09:29:14 -0400 Subject: Naming of GnuPG In-Reply-To: <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> Message-ID: <4811DCAA.40808@comcast.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 David Shaw wrote: | Do people find the 1.4.x / 2.0.x thing confusing? I can only speak for myself. I don't find the 1.4.x / 2.0.x version numbering thing confusing at all. They each serve a different purpose and a different audience. I note that, currently, 1.4.x needs to be patched to compile in support for IDEA, while 2.0.x has it, and a lot of other capabilities already there. I have compiled both on both GNU/Linux and Win32, and found that, as long as I have the appropriate libraries, they both will compile and work correctly. Of course, I am a programmer, so I am used to separate versions of the same program. Regards, Chris PS: Sorry David, I hit the wrong button and forgot to check who I was sending this message to. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJIEdylAAoJEIAhA8M9p9DAiNwP/0APf1YH/LI7CRVuhBDhFa59 gSML9T7eMz27FYJTMTlpHJIzICePdj17LMHIicKMsNcMPStjwEqJZL1KXAJRS7/s U6zttpup8N4ePeKuGEUxxKHGpysBCaEMRb+GoOxKz2cjLhSMDFmBsyvKlgZz+lLF hLmNzMA40VryvrmopbhkOBP/dYywaw3MzaDswwoOeypA5OqMfPYl/WK26WgpgeOZ mBiPloOx5xoXOBpK/IkWvktxghjAcauhw7apXxewZl/j6LarArUbUWbeENckFD/6 /qyzP2GZo+xbpV+KIQHlyR1E3ICAhFjIz9tn0A76HuHQy8d5/aG11RCmuPdA378N Uw66dZXEu5kd+7AuHQ5+IcX20GNCLBI6CYSoXdnXPGnh0fM3GgLxhqkikIU8ejDX ltzhuoMZSxrJMXB7ZwWwVToDBShXX7EKkr6GgHg0k+rg8/OOjne6OyJXENzTTlof HyxToBg/R/j5ZsFZEo+VyL5w8nVWPeWP7VWHawbX4PemsE9m64HHbhh/smCGbkDP gN47uBg3H62rZhRdsz8L/t+bC1jvF9vPLSzvmP8ye2biTdoAbLiHmYDuRReM4M7w fCtRXkesg3+4Va32VwmU9a7opFxFjti148nbIssQaG3a0HjIJYDfzJzSzWCfbmZM UKzaTl0hoWfIn3onEuhy =jtAs -----END PGP SIGNATURE----- From email at sven-radde.de Sun Apr 27 14:07:41 2008 From: email at sven-radde.de (Sven Radde) Date: Sun, 27 Apr 2008 14:07:41 +0200 Subject: Naming of GnuPG In-Reply-To: <4811DCAA.40808@comcast.net> References: <480939DE.5080108@gmail.com> <77B50640-F3B4-4C81-BED6-1BA17D67196A@jabberwocky.com> <4811DCAA.40808@comcast.net> Message-ID: <1209298061.6752.17.camel@carbon> Hi! Am Freitag, den 25.04.2008, 09:29 -0400 schrieb Chris Walters: > | Do people find the 1.4.x / 2.0.x thing confusing? > > I can only speak for myself. I don't find the 1.4.x / 2.0.x version numbering > thing confusing at all. (...) > I have compiled both on both GNU/Linux and Win32... Which means that you are far from an average user... ;-) Speaking for myself, I used to find it confusing at the time of release. In the meantime, I have gained trust into the fact that 1.4.x will continue to be supported and therefore I am not bothered anymore by the fact that I don't seem to get 2.x set up properly. But if I had to choose today what to use as a beginner and was not subscribed to this list, I would find it confusing, I guess. IMHO, we don't need a naming change, however, but rather a end-user-suitable "HowTo: Choose your version of GnuPG." Unfortunately, due to the fact that I know nearly nothing about things like GnuPG's build-time requirements, I don't feel really confident enough to do it myself... cu, Sven From shavital at mac.com Sun Apr 27 14:26:52 2008 From: shavital at mac.com (Charly Avital) Date: Sun, 27 Apr 2008 08:26:52 -0400 Subject: decrypting a message. In-Reply-To: <1208888862.6822.1.camel@darkstar> References: <1208888862.6822.1.camel@darkstar> Message-ID: <1209299212.5387.20.camel@Ubuntu7.04> On Tue, 2008-04-22 at 19:27 +0100, cronos wrote: [...] > gpg: decryption failed: secret key not available > > Shouldn't it be asking me for the passphrase at some point? > > Thanks I am a Mac user, running Ubuntu 8.04 under virtual ware Parallels 3.0 for the Mac., and using here Evolution 2.22.1, which is not my first choice. I don't know how Evolution interacts with GnuPG, or what version of GnuPG it is using. Maybe I should be trying to know more about Evolution :-) ?You should be asked to type the passphrase IF the secret key of your key pair ?C8A0C2BB was available. But the system is claiming that it is not available 1. Does your secret key show in your secret keyring? Terminal $ gpg -K Kgpg (if you are using it) should display an icon showing two keys, at the left of the row where your key ?C8A0C2BB is displayed. 2. IF 'use-agent' is enabled, but for some reason gpg-agent it is not running and available (Terminal $ gpg-agent), that *could* be the reason why your systems claims that the secret key is not available. Too many IFs, and too many questions, sorry I can't help. Charly -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: This is a digitally signed message part URL: From dshaw at jabberwocky.com Sun Apr 27 14:59:58 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 27 Apr 2008 08:59:58 -0400 Subject: Web of Trust In-Reply-To: <48146B23.8040808@goerresonline.de> References: <48134CA2.7070607@goerresonline.de> <1674E43E-EAEA-4574-9CAD-D6CC6664493A@jabberwocky.com> <48146B23.8040808@goerresonline.de> Message-ID: On Apr 27, 2008, at 8:01 AM, Lukas Barth wrote: > > David Shaw schrieb: > | On Apr 26, 2008, at 11:39 AM, Lukas Barth wrote: > |> I have a question regarding the way GPG handles the way of trust. > Let's > |> say i have four keys (A-D). Key A is my own one, so I trust it > |> ultimately and it is valid by definition. I signed B with A and > set B's > |> ownertrust to "full". B signed C, and B trusts C only marginally. C > |> signed D, so it's like: > |> > |> A->B->C->D > |> [...] > |> 3) B's trust in C is included in B's signature and so GPG knows > that it > |> should trust C only marginally and searches for other signatures > of C, > |> until it are enough for C to be trusted. This would be great! > |> > |> Which way is implemented in GPG? > | > | I think there is some confusion between "validity" and "trust" in > the > | above, so it is very difficult to understand what you are asking > here. > > Sorry, my fault.. > > | Basically, in the 4-key universe above, A is valid (you), B is valid > | (you signed it), C is valid (B signed it, B is valid, and has full > | ownertrust). D is not valid because even though C signed it, C > has no > | ownertrust. > > Right, that was possibility 2: Since C has no ownertrust, D is not > valid. So it's really like "I have to assign an ownertrust to each and > every key that I want to be able to sign another key"? If I have a big > Web of Trust with a lot of keys, and not one "master key" signing them > all, then I will have to set a whole lot of ownertrusts for my Web > being > validated, right? > > In this case, for each key to be valid, it has to be signed by at > least > one key i manually set the ownertrust for, is that right? Yes. That's how the "classic" trust model works. The logic behind it is that you must know if C is making *good* signatures and not just signing anything that comes along without checking. If you don't know that, you can't really use C's signatures safely. > | I'm not sure what you are trying to get at with #3. It doesn't > seem to > | follow the problem statement of the 4-key universe. If there are > other > | keys in play here with other signatures, then you need to state > them in > | the problem. > > No, no. The "problem" is that GPG does not know an ownertrust for > key C, > right? Otherwise it would be possible to validate key D. Now if I do > not > want to set this huge amount of ownertrusts as I depicted above, > wouldn't it be a solution if B included in it's signature of C that B > trusts C marginally. Now if I trust B fully, and I know that B > trusts C > marginally, then my GPG is able to say "Great! B trusts C marginally, > and I trust B fully, that means I also can trust C marginally!" That is called a trust signature, and it's part of the "PGP" trust model in GPG. You can make them with "tsign" instead of "sign" in the --edit-key menu. They look like regular signatures except they have the ownertrust level built-in to the signature along with some ways to restrict the flows of that trust (hop counts and domain regular expressions). Trust signatures work more or less as you describe above. However, note that they are not really used very much outside of corporate (very hierarchical) environments. In the example above, if B made a trust signature on C at the marginal level, you'd get what you describe: A (you), B (valid + full trust), C (valid + marginal trust). David From christoph.anton.mitterer at physik.uni-muenchen.de Mon Apr 28 00:44:08 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Mon, 28 Apr 2008 00:44:08 +0200 Subject: Naming of GnuPG In-Reply-To: <4812D7B0.3020002@sixdemonbag.org> References: <480939DE.5080108@gmail.com>, <20080421133034.GB7699@IUPUI.Edu> , <2AF9AECC-2F51-49F4-8D53-7E9D3FB648A2@jabberwocky.com> <4812EDDC.20483.23AC2374@dirk.traulsen.lypso.de> <4812D7B0.3020002@sixdemonbag.org> Message-ID: <1209336248.7435.4.camel@fermat.scientia.net> ?On Sat, 2008-04-26 at 02:20 -0500, Robert J. Hansen wrote: > I'd like to see GPG remain the name for only 1.4. > > GnuPG 2.x introduces a lot of new crypto support that is not related > to > OpenPGP. The original metonymy is no longer appropriate. > > Call it GnuPS, for the GNU Privacy Suite. If additional tools, > technologies, etc., are added to GnuPG 2.x or a future 3.0, then the > GnuPS name can remain unchanged. I think renaming gpg would have the disadvantage of breaking with a well known and traditional name. It could even more confuse users because they might think it's an unofficial fork or it's not as good as the "real" GnuPG. Despite of this I like you idea, because, as you argue, gpg2 has more than just OpenPGP. However I would prefer a name like gnucrypt (and perhaps as shortcut gc or gnuc). "suite" sounds like "more", e.g. including an email client or so ;) Best wishes, Chris. From JPClizbe at tx.rr.com Mon Apr 28 05:55:02 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Sun, 27 Apr 2008 22:55:02 -0500 Subject: decrypting a message. In-Reply-To: <1208888862.6822.1.camel@darkstar> References: <1208888862.6822.1.camel@darkstar> Message-ID: <48154A96.3080202@tx.rr.com> cronos wrote: > Hi, > > I'm at a bit of a loss decrypting a message. No matter what I do I > always seem to get: > > gpg: encrypted with ELG-E key, ID C8A0C2BB > gpg: decryption failed: secret key not available > > when I run gpg like this: > $gpg --list-packets msg.pgp > :pubkey enc packet: version 3, algo 16, keyid 9C53A76FC8A0C2BB > data: [1023 bits] > data: [1023 bits] > :encrypted data packet: > length: 149 > mdc_method: 2 > gpg: encrypted with ELG-E key, ID C8A0C2BB > gpg: decryption failed: secret key not available > > Shouldn't it be asking me for the passphrase at some point? The error couldn't be more obvious to me: secret key not available. I was able to dig around with a keyserver and found that the encryption subkey, 0x9C53A76FC8A0C2BB, belongs to the key 0x137D149825833A20, "Sphinx " What's the result of running the command; gpg--list-secret-key 0xC8A0C2BB If the key is in your secret keyring, you'll get something like: sec 1024D/25833A20 2007-09-04 uid Sphinx ssb 1024g/C8A0C2BB 2007-09-04 -- John P. Clizbe Inet: JPClizbe(a)tx DAWT rr DAHT con Ginger Bear Networks hkp://keyserver.gingerbear.net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 677 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Apr 28 10:38:24 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Apr 2008 10:38:24 +0200 Subject: gpg smartcard troubles In-Reply-To: <20080423190351.GB4982@odin.lan> (Albert Dengg's message of "Wed, 23 Apr 2008 21:03:51 +0200") References: <20080423190351.GB4982@odin.lan> Message-ID: <87lk2y74sf.fsf@wheatstone.g10code.de> On Wed, 23 Apr 2008 21:03, albert at fsfe.org said: > unable to decrypt files encrypted for the encryption subkey or signing > with the sign subkey, though they are listed when i do a "gpg > --edit-key" as beeing subkeys... Are they also listed as secret subkeys (sbb)? 1.4.8 fixed a stub key creation issue; so if you are using 1.4.7 or earlier you should update (to 1.4.9). Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon Apr 28 10:42:12 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Apr 2008 10:42:12 +0200 Subject: Naming of GnuPG In-Reply-To: <4812D7B0.3020002@sixdemonbag.org> (Robert J. Hansen's message of "Sat, 26 Apr 2008 02:20:16 -0500") References: <480939DE.5080108@gmail.com> <20080421133034.GB7699@IUPUI.Edu> <2AF9AECC-2F51-49F4-8D53-7E9D3FB648A2@jabberwocky.com> <4812EDDC.20483.23AC2374@dirk.traulsen.lypso.de> <4812D7B0.3020002@sixdemonbag.org> Message-ID: <87ej8q74m3.fsf@wheatstone.g10code.de> On Sat, 26 Apr 2008 09:20, rjh at sixdemonbag.org said: > GnuPG 2.x introduces a lot of new crypto support that is not related to > OpenPGP. The original metonymy is no longer appropriate. Well, PGP also has support for X.509 and a lot more. It is funny that the naming issue is such a hot topic. We had a similar thread 10 years ago when I asked for a name of GnuPG (at that time called g10). Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Mon Apr 28 10:51:38 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Apr 2008 10:51:38 +0200 Subject: dearmor in GPGME In-Reply-To: (Cameron Dale's message of "Sat, 26 Apr 2008 19:22:50 -0700") References: Message-ID: <87abje746d.fsf@wheatstone.g10code.de> On Sun, 27 Apr 2008 04:22, camrdale at gmail.com said: > I have an armored detached signature that I want to dearmor (without > using the original plain text). I can do it on the command line with > the --dearmor option, but how can I do it in GPGME? Is it possible? You can't. However the format is pretty simple: It is the usual base-64 encoding enclosed in header lines. Look for the 5-dash header line, then wait for an empty line and start your base-64 decoder with the next line. A plain base-64 decoder should stop righjt before the OpenPGP CRC checksum, which you can ignore. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From hidekis at gmail.com Mon Apr 28 11:46:02 2008 From: hidekis at gmail.com (Hideki Saito) Date: Mon, 28 Apr 2008 02:46:02 -0700 Subject: Naming of GnuPG In-Reply-To: <87ej8q74m3.fsf@wheatstone.g10code.de> References: <480939DE.5080108@gmail.com> <20080421133034.GB7699@IUPUI.Edu> <2AF9AECC-2F51-49F4-8D53-7E9D3FB648A2@jabberwocky.com> <4812EDDC.20483.23AC2374@dirk.traulsen.lypso.de> <4812D7B0.3020002@sixdemonbag.org> <87ej8q74m3.fsf@wheatstone.g10code.de> Message-ID: <48159CDA.8040200@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, 10 years ago, probably there was just a single variety of GnuPG (g10)... - -- Hideki Saito | On Sat, 26 Apr 2008 09:20, rjh at sixdemonbag.org said: | |> GnuPG 2.x introduces a lot of new crypto support that is not related to |> OpenPGP. The original metonymy is no longer appropriate. | | Well, PGP also has support for X.509 and a lot more. | | It is funny that the naming issue is such a hot topic. We had a similar | thread 10 years ago when I asked for a name of GnuPG (at that time | called g10). | | | | Salam-Shalom, | | Werner | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgVnNoACgkQsMFNnAQed4yZXQCfQthgJdctm7l0o4GsNkI1bFmX BfEAnAsGjl6vfu4SUo7R4BUNt2cBZX0B =E35g -----END PGP SIGNATURE----- From camrdale at gmail.com Mon Apr 28 17:48:22 2008 From: camrdale at gmail.com (Cameron Dale) Date: Mon, 28 Apr 2008 08:48:22 -0700 Subject: dearmor in GPGME In-Reply-To: <87abje746d.fsf@wheatstone.g10code.de> References: <87abje746d.fsf@wheatstone.g10code.de> Message-ID: On 4/28/08, Werner Koch wrote: > However the format is pretty simple: It is the usual base-64 encoding > enclosed in header lines. Look for the 5-dash header line, then wait > for an empty line and start your base-64 decoder with the next line. > A plain base-64 decoder should stop righjt before the OpenPGP CRC > checksum, which you can ignore. Thanks, I was aware of that, but hoping for a built-in method that would do it better, including checking the checksum for me. Oh well, a dirty hack it is then. ;) Thanks, Cameron From wk at gnupg.org Mon Apr 28 20:11:31 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 28 Apr 2008 20:11:31 +0200 Subject: dearmor in GPGME In-Reply-To: (Cameron Dale's message of "Mon, 28 Apr 2008 08:48:22 -0700") References: <87abje746d.fsf@wheatstone.g10code.de> Message-ID: <87mynd3l4c.fsf@wheatstone.g10code.de> On Mon, 28 Apr 2008 17:48, camrdale at gmail.com said: > Thanks, I was aware of that, but hoping for a built-in method that > would do it better, including checking the checksum for me. Oh well, a Forget about the CRC checksum. It is cruft from old days when mail gateways garbled messages and PGP did not want to trouble the user with a passphrase dialog. If the checksum fails the actual crypto integrity checks will bet triggered anyway. In particular with gpg which does stream processing and won't see the CRC before it has parsed the crypto stuff. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Mon Apr 28 20:21:39 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 28 Apr 2008 14:21:39 -0400 Subject: dearmor in GPGME In-Reply-To: <87mynd3l4c.fsf@wheatstone.g10code.de> References: <87abje746d.fsf@wheatstone.g10code.de> <87mynd3l4c.fsf@wheatstone.g10code.de> Message-ID: <20080428182139.GE31584@jabberwocky.com> On Mon, Apr 28, 2008 at 08:11:31PM +0200, Werner Koch wrote: > On Mon, 28 Apr 2008 17:48, camrdale at gmail.com said: > > > Thanks, I was aware of that, but hoping for a built-in method that > > would do it better, including checking the checksum for me. Oh well, a > > Forget about the CRC checksum. It is cruft from old days when mail > gateways garbled messages and PGP did not want to trouble the user with > a passphrase dialog. If the checksum fails the actual crypto integrity > checks will bet triggered anyway. In particular with gpg which does > stream processing and won't see the CRC before it has parsed the crypto > stuff. Also note that the CRC is optional in OpenPGP. It's not even always there. David From cwal989 at comcast.net Mon Apr 28 21:06:11 2008 From: cwal989 at comcast.net (Chris Walters) Date: Mon, 28 Apr 2008 15:06:11 -0400 Subject: Naming of GnuPG In-Reply-To: <1209336248.7435.4.camel@fermat.scientia.net> References: <480939DE.5080108@gmail.com>, <20080421133034.GB7699@IUPUI.Edu> , <2AF9AECC-2F51-49F4-8D53-7E9D3FB648A2@jabberwocky.com> <4812EDDC.20483.23AC2374@dirk.traulsen.lypso.de> <4812D7B0.3020002@sixdemonbag.org> <1209336248.7435.4.camel@fermat.scientia.net> Message-ID: <48162023.2060902@comcast.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Christoph Anton Mitterer wrote: | On Sat, 2008-04-26 at 02:20 -0500, Robert J. Hansen wrote: |> I'd like to see GPG remain the name for only 1.4. |> |> GnuPG 2.x introduces a lot of new crypto support that is not related |> to |> OpenPGP. The original metonymy is no longer appropriate. |> |> Call it GnuPS, for the GNU Privacy Suite. If additional tools, |> technologies, etc., are added to GnuPG 2.x or a future 3.0, then the |> GnuPS name can remain unchanged. | I think renaming gpg would have the disadvantage of breaking with a well | known and traditional name. | It could even more confuse users because they might think it's an | unofficial fork or it's not as good as the "real" GnuPG. | | Despite of this I like you idea, because, as you argue, gpg2 has more | than just OpenPGP. | | However I would prefer a name like gnucrypt (and perhaps as shortcut gc | or gnuc). | "suite" sounds like "more", e.g. including an email client or so ;) | | Best wishes, | Chris. Even though I would prefer not renaming anything (except maybe randomly renaming all of the streets in big cities on a weekly basis...lol), I do have an idea on what GnuPG 2.0.x could be called. My idea is to call it GnuPG+ or GnuPG++, as each would show that it has more capabilities than GnuPG 1.4.x. The executable could be called 'gpg++', though this would be close to g++ which is the GCC program for compiling c++ files. Regards, Chris -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJIFiAdAAoJEE8J0h3nbis2WsUP/0hwsAl4V/ENSzjG7BRZeFV9 HZFGIkGWEqeqpRf9/poUBJcQkHosr5F5UNg3mR6M0R6WZgpfH4S8ys3QMyFsJBeD ey4XyZAPGNf3N19H129gBq/r8Y7GSpe4Cyp6Ea/UOlIzlpaPJrRY4fFJ3oU0eSQU yxI/p2jvHTTJZiWSm4YW8gMb4YVEBW2nNw91TrMsu/Ag8dRnd+yI6xubN/g2VcCS 9n1KzIVKCDIhnumszqCsEdqU0CKrGJBx9YxK2s+nsmgJXu+xrxu0SdVqmkX36JNm Tm6C4fvnwIfWYBcPZs0z6XmcPv0SRDpYfDD1wlkVxDTJEBGgKZGo9lzBV5a0uLqh K/VHT7Lr3pTjGiPhBQ4O0tKjZG2mTb6gg3HRPFFsS5AgKv4yJCcyV1PGt2dTQMWT xSe02/JOPRgGPJ87MvId7ht3LXAu/kvBIGrONo+vNHisIdGCj/0mRfJZXF9BhD+c IF+hb1+H6/7YC1Wt4LDy50WA8Xw1vCWgzzvpgF9RjCg1LaKR71u4SqgfN8/YBH1y j75WrUGwCmCYEhOI8nzxXKTZ9j5/Cp4GC4vCNhfLlOBFcE/ThTF/mGXIk+kohdq/ RCsGvl7Oo1pNWS+DH7Wy+kl+sipzXBez+WKWc2fLqlVIOCrAVVHM5p/OQjKorOXY GiXFR+xiA3xCpjojvyzN =P1BN -----END PGP SIGNATURE----- From mpant at ncsa.uiuc.edu Tue Apr 29 18:09:35 2008 From: mpant at ncsa.uiuc.edu (Meenal Pant) Date: Tue, 29 Apr 2008 11:09:35 -0500 Subject: --gen-revoke in batch In-Reply-To: <87iqyf4l6m.fsf@wheatstone.g10code.de> References: <48066377.3040907@ncsa.uiuc.edu> <480690A5.80309@tx.rr.com> <87hce0d5tv.fsf@wheatstone.g10code.de> <480796E1.6020906@ncsa.uiuc.edu> <87iqyf4l6m.fsf@wheatstone.g10code.de> Message-ID: <4817483F.4090803@ncsa.uiuc.edu> Based on Werner's suggestion, I have a test script now to create revocation certificates. I use this command in the script: gpg -a -o "rev.asc" --command-fd 0 --status-fd 2 --gen-revoke 409900FC The responses entered by the script are all strings followed by an LF. The output is as follows: .... [GNUPG:] GOT_IT Reason for revocation: Key has been compromised (No description given) [GNUPG:] GET_BOOL ask_revocation_reason.okay y [GNUPG:] GOT_IT [GNUPG:] USERID_HINT 90FBD027409900FC Testkey (test) [GNUPG:] NEED_PASSPHRASE 90FBD027409900FC 90FBD027409900FC 17 0 You need a passphrase to unlock the secret key for user: "Testkey (test) " 1024-bit DSA key, ID 409900FC, created 2008-04-17 [GNUPG:] GET_HIDDEN passphrase.enter revokekey [GNUPG:] GOT_IT [GNUPG:] BAD_PASSPHRASE 90FBD027409900FC gpg: Invalid passphrase; please try again ... [GNUPG:] USERID_HINT 90FBD027409900FC Testkey (test) [GNUPG:] NEED_PASSPHRASE 90FBD027409900FC 90FBD027409900FC 17 0 You need a passphrase to unlock the secret key for user: "Testkey (test) " 1024-bit DSA key, ID 409900FC, created 2008-04-17 [GNUPG:] GET_HIDDEN passphrase.enter revokekey [GNUPG:] GOT_IT [GNUPG:] MISSING_PASSPHRASE [GNUPG:] BAD_PASSPHRASE 90FBD027409900FC gpg: Invalid passphrase; please try again ... [GNUPG:] USERID_HINT 90FBD027409900FC Testkey (test) [GNUPG:] NEED_PASSPHRASE 90FBD027409900FC 90FBD027409900FC 17 0 Now when I run the same command on command line it works and a revocation certificate is created. ... Correct y [GNUPG:] GET_BOOL ask_revocation_reason.okay y [GNUPG:] GOT_IT [GNUPG:] USERID_HINT 90FBD027409900FC Testkey (test) [GNUPG:] NEED_PASSPHRASE 90FBD027409900FC 90FBD027409900FC 17 0 You need a passphrase to unlock the secret key for user: "Testkey (test) " 1024-bit DSA key, ID 409900FC, created 2008-04-17 [GNUPG:] GET_HIDDEN passphrase.enter revokekey [GNUPG:] GOT_IT [GNUPG:] GOOD_PASSPHRASE ASCII armored output forced. File `rev.asc' exists. [GNUPG:] GET_BOOL openfile.overwrite.okay y [GNUPG:] GOT_IT [GNUPG:] GOOD_PASSPHRASE Revocation certificate created. Please move it to a medium which you can hide away; if Mallory gets access to this certificate he can use it to make your key unusable. It is smart to print this certificate and store it away, just in case your media become unreadable. But have some caution: The print system of your machine might store the data and make it available to others! Any idea why entering the passphrase as a string in the script is not working ? Thanks Meenal Werner Koch wrote: > On Thu, 17 Apr 2008 20:28, mpant at ncsa.uiuc.edu said: > >>> $ gpg2 --status-fd 2 --command-fd 0 --gen-revoke joe >> I guess I can use gpg here ? > > Yes. > >>> [GNUPG:] GET_BOOL gen_revoke.okay >> Are these commands generated by GPG ? > > The option --status-fd N generates them and writes the to the file > descriptor N (in the example 2 = stderr), you may want to use 1 for stdout. > > >> What is FSM ? Finite State Machine. How can I use this? > > Right. This the proper way to automate gpg using > --command-fd/--status-fd . It is a bit of work but has the advantage > that it won't break or, even worse, yields unexpected results if gpg > adds other status messages. The GPA frontend uses this approach > (src/gpgmeedit.c). > >>> should be answered with just a LF. Of course you would use the >> What if LF ? > > linefeed or in C notation "\n" (ASCII code 0x10). > >> I need to write the revocation certificate to a file too. > > Use the gpg option > > --output FILE > > > > Shalom-Salam, > > Werner > From eddrobinson at gmail.com Tue Apr 29 20:18:06 2008 From: eddrobinson at gmail.com (Edward Robinson) Date: Tue, 29 Apr 2008 19:18:06 +0100 Subject: Open Pgp Smartcard ssh authentication Woes :( Message-ID: <4817665E.1030603@gmail.com> Hello All, I am having both success and failure with regard to getting ssh authentication to work with my openpgp smartcard. On my Ubuntu Gutsy (Gnome) Box things are great, `ssh-add -l' reports the key correctly and I can successfully authenticate myself when ssh'ing to another box. However, on my laptop, which is running Debain Lenny (Gnome), I can't get it to work. ssh-add -l returns the annoying `The agent has no identities'. I have done no end of fiddling to get this working. Here is a list of things that I think may be relevant and that I have installed at the moment: Ubuntu Box (Working) gnupg: 1.4.6-2ubuntu4 gnupg2: Not Installed gnupg-agent: 2.0.4-1ubuntu3 pcscd: 1.4.3-1 gpgsm: 2.0.4 seahorse: 2.20.1-0ubuntu1 pinentry-gtk-2: 0.7.3-1ubuntu2 gpg.conf contains `use-agent' gpg-agent.conf: ------ pinentry-program /usr/bin/pinentry-gtk-2 default-cache-ttl 1800 enable-ssh-support ------ Further, the loading line in my /etc/X11/Xsessions.d/90-gpg-agent looks like: ------ if ! $GPGAGENT 2>/dev/null; then $GPGAGENT --daemon --sh --enable-ssh-support>"$PID_FILE" . "$PID_FILE" fi ------ Debain Lenny Laptop (NOT Working) gnupg: 1.4.6-2.1 gnupg2: 2.0.9-1 gnupg-agent: 2.0.9-1 pcscd: 1.4.3-1 gpgsm: 2.0.9-1 seahorse: 2.22.0-1 pinentry-gtk-2: 0.7.5-1 gpg.conf contains `use-agent' gpg-agent.conf: ------ pinentry-program /usr/bin/pinentry-gtk-2 default-cache-ttl 1800 enable-ssh-support ------ Further, the loading line in my /etc/X11/Xsessions.d/90-gpg-agent looks like: ------ if ! $GPGAGENT 2>/dev/null; then STARTUP="$GPGAGENT --daemon --sh --enable-ssh-support --write-env-file=$PID_FILE $STARTUP" fi ------ I have tried using it without gnupg2 on lenny (so it was same packages as ubuntu box) but doesn't make a difference... The card works on the laptop in all other respects (signing, encrypting) but wont work with the ssh authentication. Anyone have any thoughts? I guess it's down to the different package versions?? Also, can someone explain to me exactly what I need for this to work, I am confused if I actually need gpgsm installed for example. many thanks, Edd From harakiri_23 at yahoo.com Wed Apr 30 17:20:57 2008 From: harakiri_23 at yahoo.com (Harakiri) Date: Wed, 30 Apr 2008 08:20:57 -0700 (PDT) Subject: LDAP Basic Auth not working for key search, keyserver-options ignored! Message-ID: <322999.25976.qm@web52212.mail.re2.yahoo.com> Hello, following the example here : http://lists.gnupg.org/pipermail/gnupg-users/2006-February/028058.html i used the binddn and bindpw option to do a simple auth against an ldap server gpg.exe --keyserver ldap://localhost --keyserver-options "binddn=\"uid=someuser\"" --keyserver-options bindpw=somepw --keyserver-options verbose --search-keys somemail However - neither binddn nor bindpw is passed to the ldap server - my LDAP Server is disabled for anonymous bind so gpg returns an error about insufficant access rights - i debugged the ldap server and gpg never calls a bind/lookup with the credentials just : Search Request Base Object : 'cn=pgpServerInfo' Scope : base object Deref Aliases : never Deref Aliases Size Limit : no limit Time Limit : no limit Types Only : false Filter : '(objectClass=*)' Attributes : pgpBaseKeySpaceDN, software, version What is wrong? LDAP Server Basic Auth is working fine for other clients like outlook, thunderbird etc when searching for x509 from the same server Thanks ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From ramon.loureiro at upf.edu Wed Apr 30 20:39:57 2008 From: ramon.loureiro at upf.edu (Ramon Loureiro) Date: Wed, 30 Apr 2008 20:39:57 +0200 Subject: Merging trusts... Message-ID: <4818BCFD.9070300@upf.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I'm new with GPG so excuse if my question is stupid or ridiculous... I use to read my IMAP email at home and at work. In both machines I use Enigmail with Thunderbird Is it possible to have an unique trustdb file, so that I've the same trusted signatures in both computers? Is there a way to synchronize them? Thanks ___ ramon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJIGLz1AAoJEMVZKsuAx9ZHS+YIAIofr7TS+Kof8oc0w+KjFYg6 ju57lH0hdvmWoS8s2Bc861STQmY9Lki2feu3ENIpkR7P4PVIYpWRQep9wbAOuD2Q P1Y71WnJyueCqzMrjZu3MetSMUXZBtoYWu3l5+LHeapYVfPXdzai4rbh21XLaOD2 ckPvTZE371IQ9GtbEgunjxd9a3b1hKhwDyR1flGhuXH4uZnkPrWqjCGS/tmU0WFG d3rNMSfMq0+pM6CqxCA1ofQhCpUPR5DRocpWnf9pyYSlqEs/Bs7Fx0tv3hu9WWUH NODPhM2DIh8hOb5v7bMGzpgyh1gXjdX1Ca8pitv8uY684/2AkbZEGzVg8k2y/hw= =yWla -----END PGP SIGNATURE----- From eddrobinson at gmail.com Wed Apr 30 22:57:58 2008 From: eddrobinson at gmail.com (Edward Robinson) Date: Wed, 30 Apr 2008 21:57:58 +0100 Subject: Merging trusts... In-Reply-To: <4818BCFD.9070300@upf.edu> References: <4818BCFD.9070300@upf.edu> Message-ID: <4818DD56.5020706@gmail.com> Ramon Loureiro wrote: > > Hi! > I'm new with GPG so excuse if my question is stupid or ridiculous... > I use to read my IMAP email at home and at work. In both machines I use > Enigmail with Thunderbird > > Is it possible to have an unique trustdb file, so that I've the same > trusted signatures in both computers? > Is there a way to synchronize them? If you use Linux then something like seahorse or gpa can store your keys for you. You just need to export your keys and import them on the other computer. Further, you can sync your keys with a keyserver of your choice so all of your trusted sigs etc are kept synced on both machines. Cheers Edd _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users