From smenzel at gmx-gmbh.de Tue May 2 16:51:37 2006 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Tue May 2 16:51:19 2006 Subject: [GPGME] gpgme_get_key vs. gpgme_op_keylist_start Message-ID: <200605021651.41884.smenzel@gmx-gmbh.de> Sorry for posting this twice. Wrong address :-( ----------------------- Hi there, I am about to check S/MIME signatures using GPGME which already works fine. Now I would like to get further information about a certificate which was used to sign a key. As I understand the manual, the easiest way to get this is: gpgme_key_t key; gpgme_get_key(_ctx, fingerprint, &key, 0) However, this gives me always NULL in the key which means as much as 'fingerprint not found' But gpgsm --list-keys shows the specific key in question! When I try this: gpgme_op_keylist_start(ctx, 0, 0); while ((gpgme_op_keylist_next(ctx, &key) != GPG_ERR_EOF) && key) { fprintf(stderr, "key found:\n"); fprintf(stderr, "issuer : %s\n", key->issuer_name); fprintf(stderr, "serial : %s\n", key->issuer_serial); fprintf(stderr, "chain id : %s\n", key->chain_id); } The key shows up, but I cannot see the fingerprint in this struct gpgme_key_t. There is only a chain ID which is different from the keys fingerprint. So what is the difference here? Why does gpgme_get_key not give me the key? Or am I completely wrong here? Would you have any hint for me? Greetings... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : /pipermail/attachments/20060502/14294c74/attachment.pgp From albrecht.dress at arcor.de Tue May 2 19:25:01 2006 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Tue May 2 21:26:03 2006 Subject: [GPGME] gpgme_get_key vs. gpgme_op_keylist_start In-Reply-To: <200605021651.41884.smenzel@gmx-gmbh.de> (from smenzel@gmx-gmbh.de on Tue May 2 16:51:37 2006) References: <200605021651.41884.smenzel@gmx-gmbh.de> Message-ID: <1146590709l.3068l.0l@antares.localdomain> Am 02.05.06 16:51 schrieb(en) Stephan Menzel: > I am about to check S/MIME signatures using GPGME which already works > fine. > Now I would like to get further information about a certificate which > was used to sign a key. [snip] > Would you have any hint for me? To have a working example, you may want to have a look at my "transparent" implementation in the MUA balsa for evaluating gpg and s/mime signatures using gpgme: Hth, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de GnuPG public key: http://www.mynetcologne.de/~nc-dreszal/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/attachments/20060502/2829d0b4/attachment.pgp From wk at gnupg.org Wed May 3 12:17:30 2006 From: wk at gnupg.org (Werner Koch) Date: Wed May 3 13:45:09 2006 Subject: [PATCH] libksba bug in building OCSP request In-Reply-To: (Daiki Ueno's message of "Mon, 24 Apr 2006 16:30:35 +0900") References: Message-ID: <87ejzbs98l.fsf@wheatstone.g10code.de> On Mon, 24 Apr 2006 16:30:35 +0900, Daiki Ueno said: > According to RFC2560, requestExtensions should be an element of > TBSRequest. However, ocsp.c:ksba_ocsp_prepare_request lies > requestExtensions outside of TBSRequest. > Here is a patch to fix this. Thanks, Werner From npcole at yahoo.co.uk Thu May 4 12:29:16 2006 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Thu May 4 12:28:53 2006 Subject: pgp/mime support in gpg Message-ID: <20060504102916.44159.qmail@web26701.mail.ukl.yahoo.com> Just a thought. Would it not be very helpful for plugin writers if the gpg binary was able to generate pgp/mime emails? What I have in mind is a flag like --email which would alter encryption/decryption/signing operations so that an email was expected as input, and the encrypted/decrypted email given as output. Recipient lists could still be specified explicitly, but it would mean that the plugin writer would only have to deal with the work of managing keys etc., not the work of mangling the message to comply with the pgp/mime spec. As I say, just a thought. Best, N. ___________________________________________________________ 24 FIFA World Cup tickets to be won with Yahoo! Mail http://uk.mail.yahoo.com From smenzel at gmx-gmbh.de Thu May 4 15:48:18 2006 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Thu May 4 15:48:32 2006 Subject: [GPGME] gpgme_get_key vs. gpgme_op_keylist_start In-Reply-To: <1146590709l.3068l.0l@antares.localdomain> References: <200605021651.41884.smenzel@gmx-gmbh.de> <1146590709l.3068l.0l@antares.localdomain> Message-ID: <200605041548.24836.smenzel@gmx-gmbh.de> Am Dienstag, 2. Mai 2006 19:25 schrieben Sie: > To have a working example, you may want to have a look at my "transparent" > implementation in the MUA balsa for evaluating gpg and s/mime signatures > using gpgme: signature.c?rev=1.8&view=log> Very interesting. You are doing this pretty much the same way I did. In the meantime I even figuered out what was wrong. I had this in my initialization routines: gpgme_set_keylist_mode(_ctx, GPGME_KEYLIST_MODE_EXTERN); ...assuming that would imply MODE_INTERN plus some efforts to retrieve the keys via keyservers. This was apparently not the case. When I erased this part, gpgme_get_gey() got me the right key to the fingerprint. Very weird indeed, I must have misunderstood the manual here. However, thanks for your example! I didn't know balsa does S/MIME. I used to be a balsa user before I switched to Evolution because in those times balsa wasn't capable of S/MIME. Thanks and greetings.... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : /pipermail/attachments/20060504/2601fae9/attachment-0001.pgp From albrecht.dress at arcor.de Thu May 4 21:29:41 2006 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Thu May 4 21:29:12 2006 Subject: [GPGME] gpgme_get_key vs. gpgme_op_keylist_start In-Reply-To: <200605041548.24836.smenzel@gmx-gmbh.de> (from smenzel@gmx-gmbh.de on Thu May 4 15:48:18 2006) References: <200605021651.41884.smenzel@gmx-gmbh.de> <1146590709l.3068l.0l@antares.localdomain> <200605041548.24836.smenzel@gmx-gmbh.de> Message-ID: <1146770981l.3070l.1l@antares.localdomain> Am 04.05.06 15:48 schrieb(en) Stephan Menzel: > I didn't know balsa does S/MIME. I used to be a balsa user before I > switched to Evolution because in those times balsa wasn't capable of > S/MIME. I'm not sure if many people use it with balsa. It needs gpgsm and the whole chain of tools which are usually not included in the mainstream distos. Therefore, the feature is still marked as experimental. It would be great, though, if somebody (maybe you ;-) could try it again; I'm pretty sure that the crypto stuff works fine (as it uses gpgme), but probably the UI needs some polish... Cheers, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de GnuPG public key: http://www.mynetcologne.de/~nc-dreszal/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/attachments/20060504/b355ae1d/attachment.pgp From albrecht.dress at arcor.de Thu May 4 14:07:30 2006 From: albrecht.dress at arcor.de (Albrecht Dreß) Date: Fri May 5 01:15:20 2006 Subject: pgp/mime support in gpg In-Reply-To: <20060504102916.44159.qmail@web26701.mail.ukl.yahoo.com> References: <20060504102916.44159.qmail@web26701.mail.ukl.yahoo.com> Message-ID: <1496991.1146744450846.JavaMail.ngmail@webmail-09.arcor-online.net> > Just a thought. Would it not be very helpful for > plugin writers if the gpg binary was able to generate > pgp/mime emails? IMO, this is out of the scope of GnuPG. RFC 3156 [1] is rather complex, and parts of the actual implementation will depend upon the MUA. If you need an excellent library to work with MIME messages, including RFC 3156 support, you may want to have a look at gmime [2]. Note that gmime talks directly to gpg and does not support RFC 2440 [3] or RFC 2633 [4]. OTOH, i doesn't need gpgme. For the MUA Balsa, which is based upon gmime, I wrote a few gpgme based gmime extensions which support all aforementioned crypto protocols. Please see the gmime-* files in http://cvs.gnome.org/viewcvs/balsa/libbalsa/ Just my EUR 0.01, though... Cheers, Albrecht. [1] http://www.ietf.org/rfc/rfc3156.txt [2] http://spruce.sourceforge.net/gmime/ [3] http://www.ietf.org/rfc/rfc2440.txt [4] http://www.ietf.org/rfc/rfc2633.txt Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: g?nstig und schnell mit DSL - das All-Inclusive-Paket f?r clevere Doppel-Sparer, nur 44,85 ? inkl. DSL- und ISDN-Grundgeb?hr! http://www.arcor.de/rd/emf-dsl-2 From alex at bofh.net.pl Fri May 5 14:31:29 2006 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Fri May 5 14:30:56 2006 Subject: pgp/mime support in gpg In-Reply-To: <20060504102916.44159.qmail@web26701.mail.ukl.yahoo.com> References: <20060504102916.44159.qmail@web26701.mail.ukl.yahoo.com> Message-ID: <20060505123129.GT2908@hell.pl> On Thu, May 04, 2006 at 11:29:16AM +0100, Nicholas Cole wrote: > Just a thought. Would it not be very helpful for > plugin writers if the gpg binary was able to generate > pgp/mime emails? No. > What I have in mind is a flag like --email which would > alter encryption/decryption/signing operations so that > an email was expected as input, and the > encrypted/decrypted email given as output. Recipient > lists could still be specified explicitly, but it > would mean that the plugin writer would only have to > deal with the work of managing keys etc., not the work > of mangling the message to comply with the pgp/mime > spec. In the scheme you propose, GPG would have to: 1) parse MIME structure of the message that it is passed 2) do proper decoding/encoding of parts that may be mangled in transit 3) sign/encrypt then the MUA 4 has to MIME-parse the result and put it in its own data structures in place of the original message. From the design point of view, 4 is redundant and 1 and 2 are MUA's and not GPG job. If GPG relies on MUA to do 1 and 2, doing just 3 is the easiest part to implement without messing within GPG code. And really, you DON'T want to do MIME yourself if you don't really have to. Alex From smenzel at gmx-gmbh.de Sat May 6 11:00:37 2006 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Sat May 6 11:00:27 2006 Subject: [GPGME] gpgme_get_key vs. gpgme_op_keylist_start In-Reply-To: <1146770981l.3070l.1l@antares.localdomain> References: <200605021651.41884.smenzel@gmx-gmbh.de> <200605041548.24836.smenzel@gmx-gmbh.de> <1146770981l.3070l.1l@antares.localdomain> Message-ID: <200605061100.42443.smenzel@gmx-gmbh.de> Am Donnerstag, 4. Mai 2006 21:29 schrieb Albrecht Dre?: > I'm not sure if many people use it with balsa. It needs gpgsm and the > whole chain of tools which are usually not included in the mainstream > distos. Therefore, the feature is still marked as experimental. The toolchain appears to be a big problem for a great many users these days. Right now I am a gentoo user (kmail/kontact) and only a few weeks ago those tools found their way into testing ~x86. Before that, you couldn't use S/MIME with kmail at all unless of course you do the installation yourself which can be quite tricky. This is not a comfortable way for most users. And this situation is probably not likely to change as long as gpgsm is still marked as alpha. I think it would be good to change that to reach a wider spectrum of beta testers. I have done quite a lot of development integrating gpgme into our software and up to now I didn't have any serious problems, which makes me wonder why it is still considered way experimental. Can anyone here tell me if there's any kind of schedule for gpgme/gpgsm to become beta? > It would be great, though, if somebody (maybe you ;-) could try it again; > I'm pretty sure that the crypto stuff works fine (as it uses gpgme), but > probably the UI needs some polish... I'll give it a try. Greetings... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060506/79bb2d7b/attachment.pgp From dvgevers at xs4all.nl Sat May 6 11:14:36 2006 From: dvgevers at xs4all.nl (Dick Gevers) Date: Sat May 6 12:26:34 2006 Subject: gpg --search-keys correct behaviour? Message-ID: <20060506091436.78f5e463.dvgevers@xs4all.nl> When I give the command gpg --search-keys , I get an x number of results and if more than 10 (for example), one sees the question: Enter number(s), N)ext, or Q)uit > However, when the last of the available names has been printed the same question is posed again. I would expect (and believe I saw in previous versions) that the question is not repeated after the last name. I know I can type "q" for quit, but it seems not elegant. I am using gpg version 1.4.3. HTH =Dick Gevers= From albrecht.dress at arcor.de Sat May 6 14:20:42 2006 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Sat May 6 14:20:27 2006 Subject: [GPGME] gpgme_get_key vs. gpgme_op_keylist_start In-Reply-To: <200605061100.42443.smenzel@gmx-gmbh.de> (from smenzel@gmx-gmbh.de on Sat May 6 11:00:37 2006) References: <200605021651.41884.smenzel@gmx-gmbh.de> <200605041548.24836.smenzel@gmx-gmbh.de> <1146770981l.3070l.1l@antares.localdomain> <200605061100.42443.smenzel@gmx-gmbh.de> Message-ID: <1146918050l.3071l.0l@antares.localdomain> Am 06.05.06 11:00 schrieb(en) Stephan Menzel: > Before that, you couldn't use S/MIME with kmail at all unless of course > you do the installation yourself which can be quite tricky. I know, so I collected some instructions for Balsa (looked over them today, but they /may/ be somewhat out of date): http://www.mynetcologne.de/~nc-dreszal/balsa/balsa23-secure-mail.html > I have done quite a lot of development integrating gpgme into our > software and up to now I didn't have any serious problems, which makes > me wonder why it is still considered way experimental. Can anyone here > tell me if there's any kind of schedule for gpgme/gpgsm to become beta? I would *strongly* support such a move, at least for the gpgsm part! > I'll give it a try. Thanks in advance! Cheers, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de GnuPG public key: http://www.mynetcologne.de/~nc-dreszal/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/attachments/20060506/f650b14b/attachment.pgp From dshaw at jabberwocky.com Sat May 6 15:29:29 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sat May 6 15:28:34 2006 Subject: gpg --search-keys correct behaviour? In-Reply-To: <20060506091436.78f5e463.dvgevers@xs4all.nl> References: <20060506091436.78f5e463.dvgevers@xs4all.nl> Message-ID: <20060506132929.GB23972@jabberwocky.com> On Sat, May 06, 2006 at 09:14:36AM +0000, Dick Gevers wrote: > When I give the command gpg --search-keys , I get an x number of > results and if more than 10 (for example), one sees the question: > > Enter number(s), N)ext, or Q)uit > > > However, when the last of the available names has been printed the same > question is posed again. I would expect (and believe I saw in previous > versions) that the question is not repeated after the last name. > > I know I can type "q" for quit, but it seems not elegant. > > I am using gpg version 1.4.3. I just tried this, but it works for me. Can you give me an example of it not working? That is, give me the keyserver you were searching against, and the name you were searching for. David From dvgevers at xs4all.nl Sat May 6 16:41:42 2006 From: dvgevers at xs4all.nl (Dick Gevers) Date: Sat May 6 16:40:35 2006 Subject: gpg --search-keys correct behaviour? In-Reply-To: <20060506132929.GB23972@jabberwocky.com> References: <20060506091436.78f5e463.dvgevers@xs4all.nl> <20060506132929.GB23972@jabberwocky.com> Message-ID: <20060506144142.f4af165f.dvgevers@xs4all.nl> On Sat, 6 May 2006 09:29:29 -0400, David Shaw wrote about Re: gpg --search-keys correct behaviour?: >On Sat, May 06, 2006 at 09:14:36AM +0000, Dick Gevers wrote: >> When I give the command gpg --search-keys , I get an x number >> of results and if more than 10 (for example), one sees the question: >> >> Enter number(s), N)ext, or Q)uit > >> >> However, when the last of the available names has been printed the same >> question is posed again. I would expect (and believe I saw in previous >> versions) that the question is not repeated after the last name. >> >> I know I can type "q" for quit, but it seems not elegant. >> >> I am using gpg version 1.4.3. > >I just tried this, but it works for me. Can you give me an example of >it not working? That is, give me the keyserver you were searching >against, and the name you were searching for. Sure: keyserver hkp://random.sks.keyserver.penguin.de I tried with 'barth' (271 results) and 'gevers' (33 results) and the behaviour is as above each time. But if I try keyserver hkp://subkeys.pgp.net and search for 'gevers' I get the same behaviour. Cheers, =Dick Gevers= From dshaw at jabberwocky.com Sat May 6 18:09:03 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sat May 6 18:08:15 2006 Subject: gpg --search-keys correct behaviour? In-Reply-To: <20060506144142.f4af165f.dvgevers@xs4all.nl> References: <20060506091436.78f5e463.dvgevers@xs4all.nl> <20060506132929.GB23972@jabberwocky.com> <20060506144142.f4af165f.dvgevers@xs4all.nl> Message-ID: <20060506160903.GA8493@jabberwocky.com> On Sat, May 06, 2006 at 02:41:42PM +0000, Dick Gevers wrote: > On Sat, 6 May 2006 09:29:29 -0400, David Shaw wrote about Re: gpg > --search-keys correct behaviour?: > > >On Sat, May 06, 2006 at 09:14:36AM +0000, Dick Gevers wrote: > >> When I give the command gpg --search-keys , I get an x number > >> of results and if more than 10 (for example), one sees the question: > >> > >> Enter number(s), N)ext, or Q)uit > > >> > >> However, when the last of the available names has been printed the same > >> question is posed again. I would expect (and believe I saw in previous > >> versions) that the question is not repeated after the last name. > >> > >> I know I can type "q" for quit, but it seems not elegant. > >> > >> I am using gpg version 1.4.3. > > > >I just tried this, but it works for me. Can you give me an example of > >it not working? That is, give me the keyserver you were searching > >against, and the name you were searching for. > > Sure: keyserver hkp://random.sks.keyserver.penguin.de > I tried with 'barth' (271 results) and 'gevers' (33 results) and the > behaviour is as above each time. > > But if I try keyserver hkp://subkeys.pgp.net and search for 'gevers' I get > the same behaviour. I still can't duplicate it. Can anyone here duplicate this? David From dshaw at jabberwocky.com Sat May 6 18:13:32 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sat May 6 18:12:51 2006 Subject: gpg --search-keys correct behaviour? In-Reply-To: <20060506160903.GA8493@jabberwocky.com> References: <20060506091436.78f5e463.dvgevers@xs4all.nl> <20060506132929.GB23972@jabberwocky.com> <20060506144142.f4af165f.dvgevers@xs4all.nl> <20060506160903.GA8493@jabberwocky.com> Message-ID: <20060506161332.GC23972@jabberwocky.com> On Sat, May 06, 2006 at 12:09:03PM -0400, David Shaw wrote: > On Sat, May 06, 2006 at 02:41:42PM +0000, Dick Gevers wrote: > > On Sat, 6 May 2006 09:29:29 -0400, David Shaw wrote about Re: gpg > > --search-keys correct behaviour?: > > > > >On Sat, May 06, 2006 at 09:14:36AM +0000, Dick Gevers wrote: > > >> When I give the command gpg --search-keys , I get an x number > > >> of results and if more than 10 (for example), one sees the question: > > >> > > >> Enter number(s), N)ext, or Q)uit > > > >> > > >> However, when the last of the available names has been printed the same > > >> question is posed again. I would expect (and believe I saw in previous > > >> versions) that the question is not repeated after the last name. > > >> > > >> I know I can type "q" for quit, but it seems not elegant. > > >> > > >> I am using gpg version 1.4.3. > > > > > >I just tried this, but it works for me. Can you give me an example of > > >it not working? That is, give me the keyserver you were searching > > >against, and the name you were searching for. > > > > Sure: keyserver hkp://random.sks.keyserver.penguin.de > > I tried with 'barth' (271 results) and 'gevers' (33 results) and the > > behaviour is as above each time. > > > > But if I try keyserver hkp://subkeys.pgp.net and search for 'gevers' I get > > the same behaviour. > > I still can't duplicate it. Can anyone here duplicate this? Wait a moment here - your problem is that the prompt IS repeated? That's not a bug, and has been the same since 1.0.7. David From mo at g10code.com Sat May 6 18:22:30 2006 From: mo at g10code.com (Moritz Schulte) Date: Sat May 6 18:21:38 2006 Subject: gpg --search-keys correct behaviour? In-Reply-To: <20060506160903.GA8493@jabberwocky.com> References: <20060506091436.78f5e463.dvgevers@xs4all.nl> <20060506132929.GB23972@jabberwocky.com> <20060506144142.f4af165f.dvgevers@xs4all.nl> <20060506160903.GA8493@jabberwocky.com> Message-ID: <1146932550.3394.12.camel@localhost.localdomain> > I still can't duplicate it. Can anyone here duplicate this? Yes, I can. Atleast if I understood the problem correctly. When I trigger a search, some keys are displayed, followed by the "Keys x-y of z for . Enter number(s), N)ext, or Q)uit >"-prompt. Now, this prompt is displayed again after I have pressed "N" and Y has already reached Z. "N" doesn't get me out of the loop, it seems. I tried it with 1.4.4-svn4131 and 1.4.1. Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: This is a digitally signed message part Url : /pipermail/attachments/20060506/860f2f91/attachment.pgp From dvgevers at xs4all.nl Sat May 6 18:39:29 2006 From: dvgevers at xs4all.nl (Dick Gevers) Date: Sat May 6 18:38:23 2006 Subject: gpg --search-keys correct behaviour? In-Reply-To: <20060506161332.GC23972@jabberwocky.com> References: <20060506091436.78f5e463.dvgevers@xs4all.nl> <20060506132929.GB23972@jabberwocky.com> <20060506144142.f4af165f.dvgevers@xs4all.nl> <20060506160903.GA8493@jabberwocky.com> <20060506161332.GC23972@jabberwocky.com> Message-ID: <20060506163929.b83cabb7.dvgevers@xs4all.nl> On Sat, 6 May 2006 12:13:32 -0400, David Shaw wrote about Re: gpg --search-keys correct behaviour?: >Wait a moment here - your problem is that the prompt IS repeated? >That's not a bug, and has been the same since 1.0.7. Okay, I thought it didn't appear again after the last name. I'd think it would be more elegant if it stopped coming back. I didn't say it was a 'problem', though. Thanks =Dick Gevers= From tcurdt at vafer.org Sat May 6 20:40:15 2006 From: tcurdt at vafer.org (Torsten Curdt) Date: Sat May 6 22:26:33 2006 Subject: mpi larger than indicated length Message-ID: <98e4f1cd0605061140w11b2d496uacfdf04367e36ec2@mail.gmail.com> Hey guys, Could some tell me the story of this problem in a bit more detail? When I do a 'gpg ---fingerprint' or try to list the keys I get a few keys and then an error message: gpg: mpi larger than indicated length (2 bytes) gpg: keyring_get_keyblock: read error: invalid packet gpg: keydb_get_keyblock failed: invalid keyring So I had a browse and I saw a few people having the same problem. IIUC what it means is that there are some key packages broken in my keyring. So now I have a couple of questions: 1. Is this fixed in CVS already? (I believe I read something like that) 2. Will that help to at least recover part of my keyring (by ignoring the broken packages)? 3. How could that happen at all? I did not do anything nasty to my keyring 4. Is there any way I could my keyring ...because atm I cannot use my gnupg at all. I am using gnupg 1.4.2.2 via fink on latest 10.4 Would be great if someone could provide me with enough information to fix this. cheers -- Torsten From benjamin at pythagoras.no-ip.org Sat May 6 21:00:45 2006 From: benjamin at pythagoras.no-ip.org (Benjamin Donnachie) Date: Sun May 7 00:56:39 2006 Subject: Mac OS X - Installing and configuring 'gpg-agent' In-Reply-To: <4455219B.9020903@mac.com> References: <444E029A.5030202@mac.com> <4454FBAE.5040007@py-soft.co.uk> <4455219B.9020903@mac.com> Message-ID: <445CF25D.5010802@pythagoras.no-ip.org> For the benefit of the lists... To get gpg-agent v1.9.20 (required for smartcards) working under Mac OS with darwin ports: Replace the file /opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/security/gpg-agent/Portfile with the attached, and place the attached *.diff files in /opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/security/gpg-agent/files/ Then type the following: sudo port clean gpg-agent sudo port install gpg-agent Some of the gpg modules do not correctly link with the pth library and for now the Portfile contains the following messy fix: configure.env LDFLAGS="-L/opt/local/lib -lpth". This will need tidying up at some point, perhaps through changes in the Makefiles (hence copy to devel list). See also http://bugzilla.opendarwin.org/show_bug.cgi?id=3730 Ben Donnachie. -------------- next part -------------- --- tools/gpgparsemail.c 2005-12-14 10:45:28.000000000 +0000 +++ tools/gpgparsemail.c 2006-04-10 09:52:49.000000000 +0100 @@ -145,7 +145,7 @@ return p; } -static char * +/* static */ char * stpcpy (char *a,const char *b) { while (*b) -------------- next part -------------- --- scd/scdaemon.c 2005-10-27 09:37:09.000000000 +0100 +++ scd/scdaemon.c 2006-05-03 16:03:07.000000000 +0100 @@ -139,11 +139,12 @@ /* The card dirver we use by default for PC/SC. */ #if defined(HAVE_W32_SYSTEM) || defined(__CYGWIN__) #define DEFAULT_PCSC_DRIVER "winscard.dll" +#elif defined(__APPLE__) + #define DEFAULT_PCSC_DRIVER "/System/Library/Frameworks/PCSC.framework/PCSC" #else #define DEFAULT_PCSC_DRIVER "libpcsclite.so" #endif - /* Flag to indicate that a shutdown was requested. */ static int shutdown_pending; -------------- next part -------------- # $Id: Portfile,v 1.6 2005/11/05 13:32:30 yeled Exp $ PortSystem 1.0 name gpg-agent version 1.9.20 revision 2 categories security maintainers yeled@opendarwin.org description GPG key agent long_description gpg-agent is a key management agent similar \ in function to ssh-agent. homepage http://www.gnupg.org/ platforms darwin distname gnupg-${version} distfiles gnupg-${version}.tar.bz2 extract.cmd bunzip2 master_sites ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/ \ ftp://ftp.freenet.de/pub/ftp.gnupg.org/gcrypt/alpha/gnupg/ checksums md5 93899203fc0530f03e146d49b65c1e28 configure.env LDFLAGS="-L/opt/local/lib -lpth" configure.args --mandir=${prefix}/share/man \ --infodir=${prefix}/share/info \ --with-pinentry-pgm=${prefix}/bin/pinentry \ --enable-agent-only depends_lib port:gettext port:libiconv port:zlib port:bison \ port:libgpg-error port:libassuan port:libgcrypt port:libksba \ port:pth port:pinentry destroot.dir ${worksrcpath}/agent test.run yes test.dir ${worksrcpath}/checks test.target check patchfiles patch-scdaemon.diff patch-gpgparsemail.diff variant darwin { configure.args-append --disable-asm --disable-dynload } variant sunos { configure.args-append --disable-asm --disable-dynload } post-destroot { file delete -force ${destroot}${prefix}/share/info/dir } From gordon at funky.co.uk Sun May 7 14:08:33 2006 From: gordon at funky.co.uk (gordi555) Date: Sun May 7 14:36:32 2006 Subject: clearsign a variable? Message-ID: <4268683.post@talk.nabble.com> Hi, Just wondering how do you clear sign a variable please on the command line? I'm running this in a php script... $emailbody = "reg-city:Ely\n"; $emailbody .= "reg-postcode:CB6 1RA\n"; $emailbody .= "reg-country:GB\n"; $cmd = "echo $passphrase | $gpg --passphrase-fd 0 --no-tty -u $key --force-v3-sigs --no-secmem-warning --clearsign $emailbody" . "" . " &> /tmp/error "; $encrypted_message = shell_exec($cmd); But it's simply not working. Does anyone know how I can clearsign a variable without all this file interaction please? Many thanks, Gordon -- View this message in context: http://www.nabble.com/clearsign-a-variable--t1572056.html#a4268683 Sent from the GnuPG - Dev forum at Nabble.com. From atom at smasher.org Tue May 9 03:11:49 2006 From: atom at smasher.org (Atom Smasher) Date: Tue May 9 03:11:02 2006 Subject: corrupt trustdb caused by commandline? Message-ID: <20060509011153.14060.qmail@smasher.org> this is weird... i can run this: gpg --list-public-keys smasher ; echo $? all day long, and everything is fine (returns 0). but when i close stdout: gpg --list-public-keys smasher 1>&- ; echo $? it works once and corrupts my trustdb. running it again returns "2". gpg: /home/atom/.gnupg/trustdb.gpg: invalid record type 112 at recnum 1 if i change the "1" to a "2" (closing stderr instead of stdout), it works fine. if i omit the "1" and leave it implied (still closing stdout) it still causes problems. this is even weirder... this works fine: { gpg --list-public-keys smasher ; } ; echo $? but this causes problems: { gpg --list-public-keys smasher ; } >&- ; echo $? why on earth would gpg choke because i'm redirecting stdout *outside* of the curly braces?? i've only noticed this since upgrading to 1.4.3. i was previously running 1.4.2 and the didn't have any problems with the exact same command. FreeBSD 5.4-RELEASE gnupg-1.4.3 (libiconv-1.9.2_2, gettext-0.14.5_2) -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "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 From benjamin at py-soft.co.uk Tue May 9 15:15:19 2006 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Tue May 9 15:15:03 2006 Subject: Running pinentry natively under MacOS. Message-ID: <446095E7.2040204@py-soft.co.uk> Charly Avital has kindly helped me check the following instructions and they should now be correct. The following steps are required to run pinentry natively under Mac OS, ie without X11. These steps also have the advantage that GUI programs which use ssh, such as Fugu, can now work with smartcard logins. NB These steps assume that you previously used darwinports to install gpg2 and associated libraries in /opt/local. 1. Firstly, install qt3-mac. Available from www.trolltech.com or using sudo port install qt3-mac. (If using ports make sure you deactivate other versions of qt first! eg sudo port deactivate qt3) 2. Download and extract pinentry. In the pinentry sub-directory apply the attached patch-pinentry.diff patch. ie patch -p0 < /path/to/patch-pinentry.diff 3. Then export MOC=/opt/local/bin/moc and export LDFLAGS="-L/opt/local/lib -liconv" followed by ./configure --enable-pinentry-qt --prefix=/opt/local --with-qt-includes=/opt/local/include/qt3/ --with-qt-libraries=/opt/local/lib/ --disable-rpath --disable-fallback-curses 4. Make and then sudo make install. 5. Create the directory /opt/local/pinentry-qt.app Create the subdirectories /opt/local/pinentry-qt.app/Contents/ and /opt/local/pinentry-qt.app/Contents/MacOS If performing these steps in finder pinentry-qt.app will appear as an application, you will need to right click and select Show Package Contents before creating the subdirectories. 6. Copy /opt/local/bin/pinentry-qt to /opt/local/pinentry-qt.app/Contents/MacOS/ 7. Place attached files Info.plist and PkgInfo in /opt/local/pinentry-qt.app/Contents/ 8. Modify ~/.gnupg/gpg-agent.conf so that pinentry-program points to /opt/local/pinentry-qt.app/Contents/MacOS/pinentry-qt 9. Download and extract the gpg2 source code (Currently v1.9.20). Then apply attached patch-gpgparsemail.diff, patch-scdaemon.diff and patch-query.diff patches. 10. Then export LDFLAGS="-L/opt/local/lib -lpth" followed by ./configure --prefix=/opt/local --with-pinentry-pgm=/opt/local/pinentry-qt.app/Contents/MacOS/pinentry-qt --enable-agent-only 11. make and then sudo make install Now test it has all worked - open a terminal, type eval $(/opt/local/bin/gpg-agent --daemon) followed by echo test | gpg -ase -r "your email address" | gpg BE PATIENT! It can take a few moments for pinentry to pop up. At the moment - to work with Thunderbird/Enigmail you will need to start it from a terminal. The steps required are: open terminal, type eval $(gpg-agent --daemon) and then /Applications/Thunderbird/Contents/MacOS/thunderbird-bin I am currently working on a solution which will negate this step. (Any Mac OS gurus out there, please get in touch!) Ben cc: gnu-devel For developers to incorporate my Mac OS patches if they wish. opendarwin For information of the gpg-agent and pinentry maintainers. enigmail For information of readers wishing to use Engimail with gpg-agent under Mac OS. macgpg-users Details of patches required to run gpg-agent and pinentry under Mac OS. -------------- next part -------------- --- pinentry/pinentry.c 2004-12-22 11:37:50.000000000 +0000 +++ pinentry/pinentry.c 2006-05-08 01:54:55.000000000 +0100 @@ -255,12 +255,17 @@ int pinentry_have_display (int argc, char **argv) { +#if defined(Q_OS_MACX) + // If running native QT under Mac OS display is irrelevant + return 1; +#else if (getenv ("DISPLAY")) return 1; for (; argc; argc--, argv++) if (!strcmp (*argv, "--display")) return 1; return 0; +#endif } -------------- next part -------------- A non-text attachment was scrubbed... Name: Info.plist Type: text/xml Size: 318 bytes Desc: not available Url : /pipermail/attachments/20060509/6bcf89df/Info-0001.bin -------------- next part -------------- APPL -------------- next part -------------- --- scd/scdaemon.c 2005-10-27 09:37:09.000000000 +0100 +++ scd/scdaemon.c 2006-05-03 16:03:07.000000000 +0100 @@ -139,11 +139,12 @@ /* The card dirver we use by default for PC/SC. */ #if defined(HAVE_W32_SYSTEM) || defined(__CYGWIN__) #define DEFAULT_PCSC_DRIVER "winscard.dll" +#elif defined(__APPLE__) + #define DEFAULT_PCSC_DRIVER "/System/Library/Frameworks/PCSC.framework/PCSC" #else #define DEFAULT_PCSC_DRIVER "libpcsclite.so" #endif - /* Flag to indicate that a shutdown was requested. */ static int shutdown_pending; -------------- next part -------------- --- tools/gpgparsemail.c 2005-12-14 10:45:28.000000000 +0000 +++ tools/gpgparsemail.c 2006-04-10 09:52:49.000000000 +0100 @@ -145,7 +145,7 @@ return p; } -static char * +/* static */ char * stpcpy (char *a,const char *b) { while (*b) -------------- next part -------------- --- agent/query.c 2005-11-28 09:55:57.000000000 +0000 +++ agent/query.c 2006-05-08 16:06:13.000000000 +0100 @@ -217,6 +217,16 @@ else pgmname++; +#if defined(__APPLE__) + // If running under MacOS then pinentry must be invoked by sh + // otherwise bundle information is not processed and pinentry will + // be unable to grab keyboard / screen. + + argv[0] = "sh"; + argv[1] = "-c"; + argv[2] = opt.pinentry_program; + argv[3] = NULL; +#else argv[0] = pgmname; if (ctrl->display && !opt.keep_display) { @@ -226,7 +236,8 @@ } else argv[1] = NULL; - +#endif + i=0; if (!opt.running_detached) { @@ -237,8 +248,13 @@ no_close_list[i] = -1; /* Connect to the pinentry and perform initial handshaking */ - rc = assuan_pipe_connect2 (&ctx, opt.pinentry_program, (char**)argv, - no_close_list, atfork_cb, NULL); + rc = assuan_pipe_connect2 (&ctx, + #if defined(__APPLE__) + "/bin/sh" // See above. + #else + opt.pinentry_program + #endif + , (char**)argv, no_close_list, atfork_cb, NULL); if (rc) { log_error ("can't connect to the PIN entry module: %s\n", From dshaw at jabberwocky.com Tue May 9 19:13:52 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Tue May 9 19:12:56 2006 Subject: corrupt trustdb caused by commandline? In-Reply-To: <20060509011153.14060.qmail@smasher.org> References: <20060509011153.14060.qmail@smasher.org> Message-ID: <20060509171352.GD24267@jabberwocky.com> On Mon, May 08, 2006 at 09:11:49PM -0400, Atom Smasher wrote: > this is weird... > > i can run this: > gpg --list-public-keys smasher ; echo $? > all day long, and everything is fine (returns 0). > > but when i close stdout: > gpg --list-public-keys smasher 1>&- ; echo $? > > it works once and corrupts my trustdb. running it again returns "2". > > gpg: /home/atom/.gnupg/trustdb.gpg: invalid record type 112 at recnum 1 > > if i change the "1" to a "2" (closing stderr instead of stdout), it works > fine. if i omit the "1" and leave it implied (still closing stdout) it > still causes problems. Good one. Open up your trustdb.gpg in a text editor to see what happened. ;) > i've only noticed this since upgrading to 1.4.3. i was previously running > 1.4.2 and the didn't have any problems with the exact same command. I'm not sure why you didn't have the problem in 1.4.2. It should happen there as well. Try this patch. David -------------- next part -------------- Index: gpg.c =================================================================== --- gpg.c (revision 4131) +++ gpg.c (working copy) @@ -1625,6 +1625,23 @@ log_error("unknown trust model `%s'\n",model); } +static void +reopen_std(void) +{ +#ifdef HAVE_STAT + struct stat statbuf; + + if(fstat(STDIN_FILENO,&statbuf)==-1 && errno==EBADF) + open("/dev/null",O_RDONLY); + + if(fstat(STDOUT_FILENO,&statbuf)==-1 && errno==EBADF) + open("/dev/null",O_WRONLY); + + if(fstat(STDERR_FILENO,&statbuf)==-1 && errno==EBADF) + open("/dev/null",O_WRONLY); +#endif +} + int main (int argc, char **argv ) { @@ -1675,6 +1692,7 @@ opt.lock_once = 1; #endif /* __riscos__ */ + reopen_std(); trap_unaligned(); secmem_set_flags( secmem_get_flags() | 2 ); /* suspend warnings */ /* Please note that we may running SUID(ROOT), so be very CAREFUL From wk at gnupg.org Wed May 10 11:56:21 2006 From: wk at gnupg.org (Werner Koch) Date: Wed May 10 12:01:18 2006 Subject: [GPGME] gpgme_get_key vs. gpgme_op_keylist_start In-Reply-To: <200605061100.42443.smenzel@gmx-gmbh.de> (Stephan Menzel's message of "Sat, 6 May 2006 11:00:37 +0200") References: <200605021651.41884.smenzel@gmx-gmbh.de> <200605041548.24836.smenzel@gmx-gmbh.de> <1146770981l.3070l.1l@antares.localdomain> <200605061100.42443.smenzel@gmx-gmbh.de> Message-ID: <87ejz29pa2.fsf@wheatstone.g10code.de> Stephan Menzel writes: > Can anyone here tell me if there's any kind of schedule for gpgme/gpgsm to > become beta? I consider gpgsm and gpg-agent as beta or even production code. It is actually used at some larger places and with one distro. It is a bit unfortunate that you have to install gnupg 1.9 and 1.4 alongside and that tehre is no GnuPG 2.0. The main missing point for 2.0 is reintegration of the current gpg 1.4 line of code, so that this double installation won't be required anymore. KDE people are asking for a 2.0 for more than a year but due to a lack of time we were not able to get to there. I revised the old roadmap in that GnuPG 2.0 won't bring all the features orginally planned (secret key operations delegated to gpg-agent, a new keyring format, etc.) but be the GnuPG 1.9 as of now plus a gpg2 binary including all the features from 1.4.x. gpgme will then try to use the gpg2 binary if available. There is still some work of coding and testing left but expect a version this summer. Salam-Shalom, Werner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20060510/67b51133/attachment.pgp From rdieter at math.unl.edu Thu May 11 21:58:49 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu May 11 23:56:10 2006 Subject: ftp.gnupg.org down? Message-ID: I've been unable to download anything from ftp.gnupg.org for about a week. I can connect, then it hangs/waits forever. Is there some problem? -- Rex From rdieter at math.unl.edu Thu May 11 22:01:50 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu May 11 23:56:12 2006 Subject: ftp.gnupg.org down? Message-ID: <4463982E.8040700@math.unl.edu> I've been unable to download anything from ftp.gnupg.org for about a week. I can connect, then it hangs/waits forever. Is there some problem? -- Rex From benjamin at py-soft.co.uk Fri May 12 01:37:34 2006 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Fri May 12 01:37:12 2006 Subject: ftp.gnupg.org down? In-Reply-To: References: Message-ID: <4463CABE.2000307@py-soft.co.uk> Rex Dieter wrote: > I've been unable to download anything from ftp.gnupg.org for about a week. > I can connect, then it hangs/waits forever. Is there some problem? I've noticed this too. Ben From rdieter at math.unl.edu Fri May 12 13:58:34 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri May 12 13:57:39 2006 Subject: ftp.gnupg.org down? References: <4463CABE.2000307@py-soft.co.uk> Message-ID: Benjamin Donnachie wrote: > Rex Dieter wrote: >> I've been unable to download anything from ftp.gnupg.org for about a >> week. >> I can connect, then it hangs/waits forever. Is there some problem? > > I've noticed this too. Anyone know of alternate download sites and/or mirrors? -- Rex From benjamin at py-soft.co.uk Fri May 12 14:11:49 2006 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Fri May 12 14:11:34 2006 Subject: ftp.gnupg.org down? In-Reply-To: References: <4463CABE.2000307@py-soft.co.uk> Message-ID: <44647B85.7010302@py-soft.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rex Dieter wrote: > Anyone know of alternate download sites and/or mirrors? Lots! See http://www.gnupg.org/(en)/download/mirrors.html Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRGR7fugNmph0Y1E2AQLGiQ//QapnOTYUpW1S4IAJtAB9Ey9AV24oXaWU MPbuABb4o94SA/gia56fB2Ou/Y1u0J/VOYTu/rT9IZflfCInzwdsSueONV/Qm2H0 hLpG0hkiC/RQX491GT8DzhslPmKFwNcZBwGtEVRhb/qklVhFBmtv5KjQkFCDkRym zi9Ctxiqlgb7k/nMkvpM/WPvTV7ZNGQaHZMnvbRU40E2x1ZsgQ7Ki0j5aJT8UADY BvsRu7vcSC6JIxKqkJ0jACDvVuFWXcLZTlddLdzy1g+LRcqcZw8kz+X64aIR+96V IaN772dWm6WiYKE7KzfHTngMZmeNhss9QaI2p70yw3X8u7r2vPK1EWTpPC6aVeLu A5uuV/Fry0nEyTQjcaZ7ljLQaviWMIw+9M1z9Qf/kGkT9peCsCRD595TtX/rG9Hd NhsoRXnTby/ghMTeoxLMGi1GuYrTYsjE1iquSEuJCZb30RLVLkFfBxkB4B5pnywq XaPGHrgINV4VBBXE/ZCdDJ2H9KMbzgbPibuZAlZYIhXcOpTIm7sgS0f2Jjr+dyby 1mZ7BhohqIP6Ims7GdlYobboEDYSkyYpRlmtcSqxK6dYiMjuQ4WBbIRq3OH7vrau ZWUv3OlGiLvWeCVBCsnAJX8oWmyKste6f9+A4SqexYIZSiVj/eqZ+xy7j6mQ6aAM 3QpdxSrsEaw= =tZOE -----END PGP SIGNATURE----- From nagydani at epointsystem.org Mon May 1 00:56:03 2006 From: nagydani at epointsystem.org (Daniel A. Nagy) Date: Tue May 16 11:39:30 2006 Subject: Feature request Message-ID: <20060430212359.GA7234@epointsystem.org> Dear GnuPG developers, Right now, it is not possible to decrypt a signed encrypted message while retaining the signature. Similarly, it is not possible to encrypt a signed message so that it becomes a signed encrypted message. With the exception of certain PGP/MIME messages (e.g. those created by OS X's Mail.app), of course. These features would be immensely useful. In applications where signatures are used as third-party evidence, yet confidentiality is required, such features are indispensible. While it is technically possible to hack together a script using gpg for forwarding a signed & encrypted message to someone who does not possess a decryption key to the original, it would be very ugly. Thank you in advance! Regards, -- Daniel PS: With these features, gnupg would become more useful for large-scale conspiracies that need to protect themselves against infiltrators. :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 392 bytes Desc: Digital signature Url : /pipermail/attachments/20060430/eac3e727/attachment-0001.pgp From stephan-menzel at web.de Tue May 2 14:09:24 2006 From: stephan-menzel at web.de (Stephan Menzel) Date: Tue May 16 11:39:34 2006 Subject: [GPGME] gpgme_get_key vs. gpgme_op_keylist_start Message-ID: <200605021409.25124.stephan-menzel@web.de> Hi there, I am about to check S/MIME signatures using GPGME which already works fine. Now I would like to get further information about a certificate which was used to sign a key. As I understand the manual, the easiest way to get this is: gpgme_key_t key; gpgme_get_key(_ctx, fingerprint, &key, 0) However, this gives me always NULL in the key which means as much as 'fingerprint not found' But gpgsm --list-keys shows the specific key in question! When I try this: gpgme_op_keylist_start(ctx, 0, 0); while ((gpgme_op_keylist_next(ctx, &key) != GPG_ERR_EOF) && key) { fprintf(stderr, "key found:\n"); fprintf(stderr, "issuer : %s\n", key->issuer_name); fprintf(stderr, "serial : %s\n", key->issuer_serial); fprintf(stderr, "chain id : %s\n", key->chain_id); } The key shows up, but I cannot see the fingerprint in this struct gpgme_key_t. There is only a chain ID which is different from the keys fingerprint. So what is the difference here? Why does gpgme_get_key not give me the key? Or am I completely wrong here? Would you have any hint for me? Greetings... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 190 bytes Desc: not available Url : /pipermail/attachments/20060502/1b4532b3/attachment.pgp From benjamin at py-soft.co.uk Wed May 3 21:51:26 2006 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Tue May 16 11:39:37 2006 Subject: Mac OS X - Installing and configuring 'gpg-agent' In-Reply-To: <4455219B.9020903@mac.com> References: <444E029A.5030202@mac.com> <4454FBAE.5040007@py-soft.co.uk> <4455219B.9020903@mac.com> Message-ID: <445909BE.50702@py-soft.co.uk> For the benefit of the lists... To get gpg-agent v1.9.20 (required for smartcards) working under Mac OS with darwin ports: Replace the file /opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/security/gpg-agent/Portfile with the attached, and place the attached *.diff files in /opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/security/gpg-agent/files/ Then type the following: sudo port clean gpg-agent sudo port install gpg-agent Some of the gpg modules do not correctly link with the pth library and for now the Portfile contains the following messy fix: configure.env LDFLAGS="-L/opt/local/lib -lpth". This will need tidying up at some point, perhaps through changes in the Makefiles (hence copy to devel list). See also http://bugzilla.opendarwin.org/show_bug.cgi?id=3730 Ben Donnachie. -------------- next part -------------- --- tools/gpgparsemail.c 2005-12-14 10:45:28.000000000 +0000 +++ tools/gpgparsemail.c 2006-04-10 09:52:49.000000000 +0100 @@ -145,7 +145,7 @@ return p; } -static char * +/* static */ char * stpcpy (char *a,const char *b) { while (*b) -------------- next part -------------- --- scd/scdaemon.c 2005-10-27 09:37:09.000000000 +0100 +++ scd/scdaemon.c 2006-05-03 16:03:07.000000000 +0100 @@ -139,11 +139,12 @@ /* The card dirver we use by default for PC/SC. */ #if defined(HAVE_W32_SYSTEM) || defined(__CYGWIN__) #define DEFAULT_PCSC_DRIVER "winscard.dll" +#elif defined(__APPLE__) + #define DEFAULT_PCSC_DRIVER "/System/Library/Frameworks/PCSC.framework/PCSC" #else #define DEFAULT_PCSC_DRIVER "libpcsclite.so" #endif - /* Flag to indicate that a shutdown was requested. */ static int shutdown_pending; -------------- next part -------------- # $Id: Portfile,v 1.6 2005/11/05 13:32:30 yeled Exp $ PortSystem 1.0 name gpg-agent version 1.9.20 revision 2 categories security maintainers yeled@opendarwin.org description GPG key agent long_description gpg-agent is a key management agent similar \ in function to ssh-agent. homepage http://www.gnupg.org/ platforms darwin distname gnupg-${version} distfiles gnupg-${version}.tar.bz2 extract.cmd bunzip2 master_sites ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/ \ ftp://ftp.freenet.de/pub/ftp.gnupg.org/gcrypt/alpha/gnupg/ checksums md5 93899203fc0530f03e146d49b65c1e28 configure.env LDFLAGS="-L/opt/local/lib -lpth" configure.args --mandir=${prefix}/share/man \ --infodir=${prefix}/share/info \ --with-pinentry-pgm=${prefix}/bin/pinentry \ --enable-agent-only depends_lib port:gettext port:libiconv port:zlib port:bison \ port:libgpg-error port:libassuan port:libgcrypt port:libksba \ port:pth port:pinentry destroot.dir ${worksrcpath}/agent test.run yes test.dir ${worksrcpath}/checks test.target check patchfiles patch-scdaemon.diff patch-gpgparsemail.diff variant darwin { configure.args-append --disable-asm --disable-dynload } variant sunos { configure.args-append --disable-asm --disable-dynload } post-destroot { file delete -force ${destroot}${prefix}/share/info/dir } From jan-oliver.wagner at intevation.de Mon May 15 22:58:02 2006 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue May 16 11:39:40 2006 Subject: gnupg.org bugtracker is sub-optimal Message-ID: <200605152258.05246.jan-oliver.wagner@intevation.de> Hello, I realized as part of the gpg4win project that there are some practical problems with the bugtracker of GPGol: It is not possible to add comments (e.g. further findings of the reporter or additional hints from others) to a report once it has been submitted. This behaviour is different from most other bug trackers and thus users are confused on how to report/discuss bugs best. Is there a particular reason why the gnupg.org bug tracker behaves as it does? If not, could it be changed to allow adding of comments? Best Jan -- Jan-Oliver Wagner: www.intevation.de/~jan | GISpatcher: www.gispatcher.de Kolab Konsortium : www.kolab-konsortium.de | Thuban : thuban.intevation.org Intevation GmbH : www.intevation.de | Kolab : www.kolab.org FreeGIS : www.freegis.org | GAV : www.grass-verein.de From wk at gnupg.org Tue May 16 12:25:19 2006 From: wk at gnupg.org (Werner Koch) Date: Tue May 16 12:31:17 2006 Subject: gnupg.org bugtracker is sub-optimal In-Reply-To: <200605152258.05246.jan-oliver.wagner@intevation.de> (Jan-Oliver Wagner's message of "Mon, 15 May 2006 22:58:02 +0200") References: <200605152258.05246.jan-oliver.wagner@intevation.de> Message-ID: <87slnae06o.fsf@wheatstone.g10code.de> Jan-Oliver Wagner writes: > It is not possible to add comments (e.g. further findings of the reporter > or additional hints from others) to a report once it has been submitted. Reply to the email notifications. > Is there a particular reason why the gnupg.org bug tracker behaves > as it does? yes, for antispam reasons. Salam-Shalom, Werner From wk at gnupg.org Tue May 16 12:34:11 2006 From: wk at gnupg.org (Werner Koch) Date: Tue May 16 12:36:17 2006 Subject: Tru64 cc: Pointer mismatch warnings not suppressed because of an error in the configure script In-Reply-To: <34BC148854A945478F102E09A1272C1C02C3DB6D@BSWEXC01.emea.cpqcorp.net> (Joerg Honegger's message of "Thu, 27 Apr 2006 14:42:37 +0200") References: <34BC148854A945478F102E09A1272C1C02C3DB6D@BSWEXC01.emea.cpqcorp.net> Message-ID: <87hd3qdzrw.fsf@wheatstone.g10code.de> "Honegger, Joerg" writes: > Pointer mismatch warnings during the compilation are not suppressed because there is a tipo (ptrmismatch instead of ptrmismatch1) in the GnuPG configure script. Thanks. Fixed. > The compiler option is also misspelled in the GnuPG README file. In > section "Specific problems on some machines" the option I have removed the note. Salam-Shalom, Werner From dshaw at jabberwocky.com Tue May 16 15:54:21 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Tue May 16 15:53:34 2006 Subject: SHA224 Question In-Reply-To: <4447A454.4040002@joimail.com> References: <4447A454.4040002@joimail.com> Message-ID: <20060516135421.GB3821@jabberwocky.com> On Thu, Apr 20, 2006 at 11:10:12AM -0400, John W. Moore III wrote: > With the inclusion of SHA224 beginning with svn-4117 I have be > unsuccessful in finding and documentation regarding this has in the > release. I am assuming that it is *not* backward compatible with any > pre-existing Key and am wondering if Keys generated with 4117 will > support SHA224. It is backwards compatible as any hash is - you can certainly use it, but if your recipient can't handle it, they can't verify the signature. > Also, what type of Key is SHA224 designed for use with? I am assuming > it has to do with the 'new' DSA Keys; but I am often wrong when I assume. Yes, it's mainly a DSA2 thing. DSA2 finally allows for DSA keys larger than 1024 bits, and isn't locked at a 160-bit hash. SHA-224 is an unusual beast. It's a chopped-down variant of SHA-256, so it's weaker than SHA-256, but takes the same amount of CPU to process. It's in the OpenPGP standard (and GnuPG) basically because it's in the DSA2 standard. > Please NOTE: I am *not* a Member of this mailing list and therefore > will not be able to read any Reply posted here. If this list isn't > 'Closed' I would appreciate a link for registration. http://lists.gnupg.org/mailman/listinfo/gnupg-devel David From mooney at dogbert.cc.ndsu.NoDak.edu Tue May 16 17:22:38 2006 From: mooney at dogbert.cc.ndsu.NoDak.edu (Tim Mooney) Date: Tue May 16 18:56:06 2006 Subject: Tru64 cc: Pointer mismatch warnings not suppressed because of an error in the configure script In-Reply-To: <34BC148854A945478F102E09A1272C1C02C3DB6D@BSWEXC01.emea.cpqcorp.net> References: <34BC148854A945478F102E09A1272C1C02C3DB6D@BSWEXC01.emea.cpqcorp.net> Message-ID: In regard to: Tru64 cc: Pointer mismatch warnings not suppressed because of...: > Dear all > > I am just installing GnuPG on some HP Tru64 UNIX Version 5.1B-3 systems. > C compiler version: Compaq C V6.5-011 on Compaq Tru64 UNIX V5.1B (Rev. 2650) > Compiler Driver V6.5-003 (sys) cc Driver > > Pointer mismatch warnings during the compilation are not suppressed > because there is a tipo (ptrmismatch instead of ptrmismatch1) in the > GnuPG configure script. I don't believe that's a typo, J?rg. There are both "ptrmismatch" and "ptrmismatch1" tags that the C compiler will skip warning about under different situations. With earlier versions of the compiler, though, there was just "ptrmismatch". That's why it appears in the configure script -- when that part of the configure script was written, there was no "ptrmismatch1". I think your change is still a good one. With the compiler behavior under 5.x, ptrmismatch1 is very likely the tag you want to suppress warnings for. Tim -- Tim Mooney mooney@dogbert.cc.ndsu.NoDak.edu Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 From albrecht.dress at arcor.de Tue May 16 19:29:10 2006 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Tue May 16 19:28:48 2006 Subject: Feature request In-Reply-To: <20060430212359.GA7234@epointsystem.org> (from nagydani@epointsystem.org on Sun Apr 30 23:23:59 2006) References: <20060430212359.GA7234@epointsystem.org> Message-ID: <1147800558l.3227l.0l@antares.localdomain> Am 30.04.06 23:23 schrieb(en) Daniel A. Nagy: > Right now, it is not possible to decrypt a signed encrypted message > while retaining the signature. Similarly, it is not possible to encrypt > a signed message so that it becomes a signed encrypted message. Hmmm, I guess you are referring to RFC 3156 [1] signed and encrypted messages, i.e. something with the MIME structure multipart/encrypted; protocol="application/pgp-encrypted"; ... +-- application/pgp-encrypted +-- application/octet-stream <<< encrypted contents of which the application/octet-stream after decryption is actually multipart/signed; protocol="application/pgp-signature"; ... +-- [signed content, might be multipart/mixed, text/plain, ...] +-- application/pgp-signature <<< the signature In this case, you need indeed two steps: first create the multipart/signed, and then encrypt it, forming the multipart/encrypted. > With the exception of certain PGP/MIME messages (e.g. those created by > OS X's Mail.app), of course. RFC 3156, sect. 6.2, allows to create a combined signed /and/ encrypted multipart/encrypted. Is that what OSX's mail creates? Also used by Enigmail (Mozilla/Thunderbird). > These features would be immensely useful. In applications where > signatures are used as third-party evidence, yet confidentiality is > required, such features are indispensible. Well, /if/ you are talking about what I outlined above, IMO this is out of GnuPG's scope (it had to implement all of RFC 3156, which in turn needs all details of MIME support, the nifty details depend upon the MUA used, etc. etc.). If you need an excellent library to work with MIME messages, including RFC 3156 support, please have a look at gmime [2]. Gmime talks directly to gpg and supports RFC 3156 ootb. For the MUA Balsa, which is based upon gmime, I wrote a few gpgme based gmime extensions which support RFC 2440 (OpenPGP), RFC 2633 (s/mine) and RFC 3156 (pgp/mime). Please see the gmime-* files in http://cvs.gnome.org/viewcvs/balsa/libbalsa/ - it might be possible to re-use them in your application (if you need something else than a MUA). Or did I /completely/ miss your point here? Cheers, Albrecht. [1] http://www.ietf.org/rfc/rfc3156.txt [2] http://spruce.sourceforge.net/gmime/ -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de GnuPG public key: http://www.mynetcologne.de/~nc-dreszal/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/attachments/20060516/99101206/attachment-0001.pgp From svwright.lists at gmail.com Tue May 16 21:37:09 2006 From: svwright.lists at gmail.com (Stewart Wright) Date: Tue May 16 23:26:01 2006 Subject: gpg-agent fails when adding a RSA ssh key Message-ID: <70dd5800605161237p1a93259dgbe5ff59f8f643a8d@mail.gmail.com> I've just submitted this to the BTS (#657) but I thought I'd send it here too. Has anyone else seen this behaviour? * Release: svn:GNUPG-1-9-BRANCH rev:4135 * Environment: FC3 svn:GNUPG-1-9-BRANCH rev:4135 automake-1.9.6, libassuan-0.6.10 libksba-0.9.13, pinentry-0.7.2 pth-2.0.6 * Description: When trying to add a 4096 bit RSA ssh key to the gpg agent it fails with "Error reading response length from authentication socket." If there aren't keys already in the agent, this is a fatal error: "Fatal error: Resource temporarily unavailable" The error code (for both the fatal and the non-fatal error cases) is 141. * How-To-Repeat: eval `gpg-agent --enable-ssh-support --daemon` ssh-add rsa_4096 From ueno at unixuser.org Wed May 17 09:40:04 2006 From: ueno at unixuser.org (Daiki Ueno) Date: Wed May 17 09:39:17 2006 Subject: gpgsm OCSP question (key usage checking for response verification) Message-ID: <98f51b73-f4d0-43c7-bbd0-0145271ffde0@well-done.deisui.org> Hello, I have been playing with gpgsm with --enable-ocsp, I got an error $ gpgsm --sign /dev/null gpgsm: certificate should have not been used for OCSP response signing This error was caused by cert_usage_p in gnupg19/sm/certlist.c. 147: if (mode == 5) 148: { 149: if (use != ~0 150: && (have_ocsp_signing 151: || (use & (KSBA_KEYUSAGE_KEY_CERT_SIGN 152: |KSBA_KEYUSAGE_CRL_SIGN)))) 153: return 0; 154: log_info (_("certificate should have not " 155: "been used for OCSP response signing\n")); 156: return gpg_error (GPG_ERR_WRONG_KEY_USAGE); 157: } I stepped through the execution using GDB, in line 149 use == 0xffffffff (== ~0) and have_ocsp_signing == 1. Now, my question is, why doesn't it accept the value ~0 for the variable use? use is corresponding to the key usage of the given certificate. I'm testing against the CAcert OCSP responder. Regards, -- Daiki Ueno From wk at gnupg.org Thu May 18 09:38:05 2006 From: wk at gnupg.org (Werner Koch) Date: Thu May 18 09:41:18 2006 Subject: gpgsm OCSP question (key usage checking for response verification) In-Reply-To: <98f51b73-f4d0-43c7-bbd0-0145271ffde0@well-done.deisui.org> (Daiki Ueno's message of "Wed, 17 May 2006 16:40:04 +0900") References: <98f51b73-f4d0-43c7-bbd0-0145271ffde0@well-done.deisui.org> Message-ID: <87iro3dbqa.fsf@wheatstone.g10code.de> Daiki Ueno writes: > I stepped through the execution using GDB, in line 149 use == 0xffffffff > (== ~0) and have_ocsp_signing == 1. Now, my question is, why doesn't it > accept the value ~0 for the variable use? use is corresponding to the if (use != ~0 && (have_ocsp_signing || (use & (KSBA_KEYUSAGE_KEY_CERT_SIGN |KSBA_KEYUSAGE_CRL_SIGN)))) return 0; With use == 0xffffffff (assuming 32 bit unsigned int) this evaluates to if ( 0 && (have_ocsp_signing || (0xffffffff & (KSBA_KEYUSAGE_KEY_CERT_SIGN |KSBA_KEYUSAGE_CRL_SIGN)))) return 0; Thus you won't get to the return. Shalom-Salam, Werner From ueno at unixuser.org Thu May 18 09:55:54 2006 From: ueno at unixuser.org (Daiki Ueno) Date: Thu May 18 09:55:17 2006 Subject: gpgsm OCSP question (key usage checking for response verification) In-Reply-To: <87iro3dbqa.fsf@wheatstone.g10code.de> (Werner Koch's message of "Thu, 18 May 2006 09:38:05 +0200") References: <98f51b73-f4d0-43c7-bbd0-0145271ffde0@well-done.deisui.org> <87iro3dbqa.fsf@wheatstone.g10code.de> Message-ID: <6cc244bb-d6f1-4763-b2dc-662f98efcbdc@well-done.deisui.org> >>>>> In <87iro3dbqa.fsf@wheatstone.g10code.de> >>>>> Werner Koch wrote: > Daiki Ueno writes: > > I stepped through the execution using GDB, in line 149 use == 0xffffffff > > (== ~0) and have_ocsp_signing == 1. Now, my question is, why doesn't it > > accept the value ~0 for the variable use? use is corresponding to the > With use == 0xffffffff (assuming 32 bit unsigned int) this evaluates to > if ( 0 && (have_ocsp_signing > || (0xffffffff & (KSBA_KEYUSAGE_KEY_CERT_SIGN > |KSBA_KEYUSAGE_CRL_SIGN)))) > return 0; > Thus you won't get to the return. Yes, I know that :-) I think that use == 0xfffffff is valid condition, so I would like to know why use != ~0 is necessary here. use is set as err = ksba_cert_get_key_usage (cert, &use); if (gpg_err_code (err) == GPG_ERR_NO_DATA) { err = 0; if (opt.verbose && mode < 2) log_info (_("no key usage specified - assuming all usages\n")); use = ~0; } Thus,, use == ~0 indicates cert is usable for all usages. Regards, -- Daiki Ueno From ueno at unixuser.org Thu May 18 10:45:26 2006 From: ueno at unixuser.org (Daiki Ueno) Date: Thu May 18 10:44:24 2006 Subject: gpgsm OCSP question (key usage checking for response verification) In-Reply-To: <6cc244bb-d6f1-4763-b2dc-662f98efcbdc@well-done.deisui.org> (Daiki Ueno's message of "Thu, 18 May 2006 16:55:54 +0900") References: <98f51b73-f4d0-43c7-bbd0-0145271ffde0@well-done.deisui.org> <87iro3dbqa.fsf@wheatstone.g10code.de> <6cc244bb-d6f1-4763-b2dc-662f98efcbdc@well-done.deisui.org> Message-ID: <90497af7-ab73-4348-add9-e50bbd45950f@well-done.deisui.org> Hello, >>>>> In <6cc244bb-d6f1-4763-b2dc-662f98efcbdc@well-done.deisui.org> >>>>> Daiki Ueno wrote: > > > I stepped through the execution using GDB, in line 149 use == 0xffffffff > > > (== ~0) and have_ocsp_signing == 1. Now, my question is, why doesn't it > > > accept the value ~0 for the variable use? use is corresponding to the > I think that use == 0xfffffff is valid condition, so I would like to > know why use != ~0 is necessary here. FYI, I removed use != ~0 from the above condition and tried to --sign again, then I finally succeeded to do that with OCSP checking enabled. Regards, -- Daiki Ueno From wk at gnupg.org Thu May 18 16:51:14 2006 From: wk at gnupg.org (Werner Koch) Date: Thu May 18 16:56:16 2006 Subject: gpgsm OCSP question (key usage checking for response verification) In-Reply-To: <6cc244bb-d6f1-4763-b2dc-662f98efcbdc@well-done.deisui.org> (Daiki Ueno's message of "Thu, 18 May 2006 16:55:54 +0900") References: <98f51b73-f4d0-43c7-bbd0-0145271ffde0@well-done.deisui.org> <87iro3dbqa.fsf@wheatstone.g10code.de> <6cc244bb-d6f1-4763-b2dc-662f98efcbdc@well-done.deisui.org> Message-ID: <87u07ntmhp.fsf@wheatstone.g10code.de> Daiki Ueno writes: > I think that use == 0xfffffff is valid condition, so I would like to > know why use != ~0 is necessary here. Can't remember. Will check, though. Shalom-Salam, Werner From wk at gnupg.org Thu May 18 17:43:55 2006 From: wk at gnupg.org (Werner Koch) Date: Thu May 18 17:46:19 2006 Subject: gpg-agent fails when adding a RSA ssh key In-Reply-To: <70dd5800605161237p1a93259dgbe5ff59f8f643a8d@mail.gmail.com> (Stewart Wright's message of "Tue, 16 May 2006 14:37:09 -0500") References: <70dd5800605161237p1a93259dgbe5ff59f8f643a8d@mail.gmail.com> Message-ID: <87psibtk1w.fsf@wheatstone.g10code.de> "Stewart Wright" writes: > I've just submitted this to the BTS (#657) but I thought I'd send it here too. Thanks. > * How-To-Repeat: > eval `gpg-agent --enable-ssh-support --daemon` > ssh-add rsa_4096 gpg-agent ran out of secure memory. You won't see the error message because it just goes to stderr. The reason for this is that we won't be able to log a proper error message if we are short of memory. Well in the case of secure memory, this is wrong and we could do a proper diagnostic. Will be changed in Libgcrypt. A workaround is to change in gnupg/agent/gpg-agent.c the line gcry_control (GCRYCTL_INIT_SECMEM, 16384, 0); to something like 32768 or even more. I think we should do this in all cases. I have not tested this but it is pretty obvious. There is also another bug. Deep inside of libgcrypt an xrealoc is used but we should not do this and return an error. Will be fixed. Thanks, Werner From mike.winter at gmail.com Sat May 20 00:05:29 2006 From: mike.winter at gmail.com (Mike Winter) Date: Sat May 20 00:08:58 2006 Subject: GPGME Problem: Unspecified source: Invalid argument Message-ID: Hi, I get the above error when trying to do a seek on a cleartext gpgme_data_t variable after a gpgme_op_verify() operation. Does anyone have any ideas? Thanks for any help. My system: Ubuntu Linux CPU: AMD64 gcc: gcc-3.4 gpg: 1.4.3 gpgme: 1.1.2 Program (modified from tests/t-verify.c): [...] int main (int argc, char *argv[]) { gpgme_ctx_t ctx; gpgme_error_t err; gpgme_data_t in; gpgme_data_t mesg; gpgme_data_t cleartext; const char *pubkey_1_asc = make_filename ("my.key.asc"); const char *sig_asc = make_filename("encrypt.gpg"); init_gpgme (GPGME_PROTOCOL_OpenPGP); err = gpgme_new (&ctx); fail_if_err (err); err = gpgme_data_new_from_file (&in, pubkey_1_asc, 1); fail_if_err (err); err = gpgme_data_new_from_file (&mesg, sig_asc, 1); fail_if_err (err); err = gpgme_op_import (ctx, in); fail_if_err (err); err = gpgme_data_new(&cleartext); fail_if_err(err); err = gpgme_op_verify(ctx, mesg, NULL, cleartext); fail_if_err (err); print_data(cleartext); [...] From robbat2 at gentoo.org Sat May 20 07:18:24 2006 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Sat May 20 08:26:40 2006 Subject: High performance GnuPG - Assuan interface to g10? Message-ID: <20060520051824.GB18463@curie-int.vc.shawcable.net> Hi I'm trying to get a high performance GnuPG going - using pgme just isn't cutting it - the repeated execv overhead is killing me. First, an explanation of my problem/objectives - somebody might be able to offer an alternative to my plan. I have a dataset, consisting of N chunks of data, of which some are GPG signed (not all of them, although we are encouraging everybody to move towards signing). The existing format of the data is at least one chunk of data per file, although in some cases a file has multiple chunks, with no separators - if two adjacent chunks are unsigned, they are just considered as one chunk. The present value of N is 11k, but it will shortly increase to at least 4x. For each chunk, I want to be able to verify it using an existing keyring (gpg --verify), and be told "Good Signature"/"Bad Signature"/"No valid OpenPGP data found". Using gpgme leads to N execv's of gpg, which hurts badly in performance. I clock it at ~120 seconds for the present 11k items. Using gpg --multifile, I get it down to 40 seconds for 11k items, but I have to first put each chunk into a unique file, and then pass that long commandline into GnuPG. But file writing is a not acceptable for the final application. I don't mind separating the chunks myself - I need to do that for another part of the application anyway, but I'm still stuck with the problem of verifying lots of them efficiently. What I'd like considered (I may implement the majority of it myself if the idea is acceptable) is the following: - An Assuan interface to the g10 code, much like the Assuan interface to GPGSM, so a user could call 'gpg --server', and then use that interface as needed - feeding off the status output for verification results. -- Robin Hugh Johnson E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 241 bytes Desc: not available Url : /pipermail/attachments/20060519/49d6070b/attachment.pgp From robbat2 at gentoo.org Sat May 20 10:49:55 2006 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Sat May 20 10:48:56 2006 Subject: High performance GnuPG - Assuan interface to g10? In-Reply-To: <20060520092029.GA5544@zax.ifi.uio.no> References: <20060520051824.GB18463@curie-int.vc.shawcable.net> <20060520092029.GA5544@zax.ifi.uio.no> Message-ID: <20060520084955.GA28516@curie-int.vc.shawcable.net> On Sat, May 20, 2006 at 11:20:29AM +0200, zvrba@globalnet.hr wrote: > On Fri, May 19, 2006 at 10:18:24PM -0700, Robin H. Johnson wrote: > > > > First, an explanation of my problem/objectives - somebody might be able > > to offer an alternative to my plan. > > > Depending on the ultimate use of your application, you might be able to use > Peter Gutmann's cryptlib: http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ > It supports the OpenPGP message format. Unfortunately it's lack of full cross-platform Linux support is a definite stumbling block - in a quick test, it fails to compile under my PPC Linux machine, claiming 'Need to define CPU type for non-x86/non-PPC Linux' I will however keep it in mind. I know for our users, that Alpha and Sparc linux are a big deal, so that's already a strike against cryptlib. -- Robin Hugh Johnson E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 241 bytes Desc: not available Url : /pipermail/attachments/20060520/98ecd1a8/attachment-0001.pgp From zvrba at globalnet.hr Sat May 20 11:20:29 2006 From: zvrba at globalnet.hr (zvrba@globalnet.hr) Date: Sat May 20 11:25:54 2006 Subject: High performance GnuPG - Assuan interface to g10? In-Reply-To: <20060520051824.GB18463@curie-int.vc.shawcable.net> References: <20060520051824.GB18463@curie-int.vc.shawcable.net> Message-ID: <20060520092029.GA5544@zax.ifi.uio.no> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Fri, May 19, 2006 at 10:18:24PM -0700, Robin H. Johnson wrote: > > First, an explanation of my problem/objectives - somebody might be able > to offer an alternative to my plan. > Depending on the ultimate use of your application, you might be able to use Peter Gutmann's cryptlib: http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ It supports the OpenPGP message format. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEbt9dUIHQih3H6ZQRA8gjAJ4yU8v5CHpfI9P/LcFq3LkOr+hUXACeKCif Bf5jiol8Ctwt2hsomUHVYRU= =N9lw -----END PGP SIGNATURE----- From mila61 at gmx.de Sat May 20 17:40:42 2006 From: mila61 at gmx.de (Michael Lampard) Date: Sat May 20 19:26:05 2006 Subject: RegEx for ASCII public keys? Message-ID: <20060520154042.314950@gmx.net> Hy, is there some kind of regular expression for ASCII public keys (*) in GnuPG? If so, where can I find it? Greetings Michael (*) like the ones I get by "gpg --armor --export " -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer From stephane at sente.ch Sun May 21 11:56:53 2006 From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Sun May 21 13:56:16 2006 Subject: Problems compiling gpg-agent fat on MacOSX Message-ID: Hi, I compiled gpg-agent on MacOSX as fat/universal, i.e. compiled for ppc and i386 architectures at the same time; I already did that for gpg, gpgme and gpg-error, and encountered some identical problems, as well as new ones. To compile libgcrypt (1.2.2), I needed to use libtool 1.5.22's config.guess, config.sub, install-sh and ltmain.sh, like I had to with gpg 1.4.2, before David kindly fixed that. Can you upgrade libgcrypt to, please? I also needed to change the endianness detection code, which doesn't work when you compile for 2 different architectures atthe same time; David already fixed that in gpg 1.4.3; if you could fix libgcrypt the same way, that would be nice. libassuan 0.6.10 compiled fine. I compiled also libksba 0.9.13 (though it is not necessary for gpg- agent); I had to tweak makefiles (I configured it with --disable- shared) and remove references to gl directory in Makefile and src/ Makefile. I had to fix the endianness configuration code too, like for libgcrypt. I compiled gpg2 (1.9.20), configured with --disable-gpgsm, and had to fix the endianness configuration code. Also, like mentioned by Benjamin Donnachie some days ago, in tools/gpgparsemail.c:148, the 'static' declaration of stpcpy() had to be removed. I also had to modify tools/Makefile to add $(PTH_LIBS) to gpg_connect_agent_LDADD definition, and add $(LIBINTL) $(PTH_LIBS) to gpgkey2ssh_LDADD definition. I still have a problem though: 'make check' fails (but gpg-agent itself works, hopefully). /tmp/gnupg-1.9.20> make check Making check in m4 make[1]: Nothing to be done for `check'. Making check in intl make[1]: Nothing to be done for `check'. Making check in gl make check-am make[2]: Nothing to be done for `check-am'. Making check in jnlib make[1]: Nothing to be done for `check'. Making check in common make[1]: Nothing to be done for `check'. Making check in agent make check-TESTS PASS: t-protect ================== All 1 tests passed ================== Making check in scd make[1]: Nothing to be done for `check'. Making check in tools make[1]: Nothing to be done for `check'. Making check in po make[1]: Nothing to be done for `check'. Making check in doc make check-am make[2]: Nothing to be done for `check-am'. Making check in tests make check-TESTS asschk: read_assuan: received incomplete line on fd 10 FAIL: sm-sign+verify asschk: read_assuan: received incomplete line on fd 8 FAIL: sm-verify ====================================== 2 of 2 tests failed Please report to gnupg-devel@gnupg.org ====================================== make[2]: *** [check-TESTS] Error 1 make[1]: *** [check-am] Error 2 make: *** [check-recursive] Error 1 Finally, a question about pinentry: why pinentry's assuan library is not replaceable by libassuan? Best regards, St?phane From wk at gnupg.org Mon May 22 16:02:17 2006 From: wk at gnupg.org (Werner Koch) Date: Mon May 22 16:06:23 2006 Subject: High performance GnuPG - Assuan interface to g10? In-Reply-To: <20060520051824.GB18463@curie-int.vc.shawcable.net> (Robin H. Johnson's message of "Fri, 19 May 2006 22:18:24 -0700") References: <20060520051824.GB18463@curie-int.vc.shawcable.net> Message-ID: <87bqtqcg46.fsf@wheatstone.g10code.de> "Robin H. Johnson" writes: > What I'd like considered (I may implement the majority of it myself if > the idea is acceptable) is the following: > - An Assuan interface to the g10 code, much like the Assuan interface to > GPGSM, so a user could call 'gpg --server', and then use that > interface as needed - feeding off the status output for verification > results. That is actually on the TODO list but it will take quite some time to get implemented. We need to modify basically all code paths to convey some state - unless you don't need any concurrency. There is another performance problem, I consider even more important than the repeated fork/exec: The searching within the keyrings is highly inefficient and need to be tackled at the same time. I have some basic code to do this. The current plan however is to get out a GnuPG 2.0 asap and then to work on the server issue and keyring searching. Shalom-Salam, Werner From robbat2 at gentoo.org Mon May 22 20:20:34 2006 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Mon May 22 20:19:33 2006 Subject: High performance GnuPG - Assuan interface to g10? In-Reply-To: <87bqtqcg46.fsf@wheatstone.g10code.de> Message-ID: <20060522182034.GF8889@curie-int.vc.shawcable.net> (Sorry if this doesn't come through correctly, only some gnupg-devel mail seems to be reaching me, and wk's reply wasn't one of those, so I constructed this based on the reply on the web). >wk writes: >> "Robin H. Johnson" writes: >> What I'd like considered (I may implement the majority of it myself if >> the idea is acceptable) is the following: >> - An Assuan interface to the g10 code, much like the Assuan interface to >> GPGSM, so a user could call 'gpg --server', and then use that >> interface as needed - feeding off the status output for verification >> results. > That is actually on the TODO list but it will take quite some time to > get implemented. We need to modify basically all code paths to convey > some state - unless you don't need any concurrency. I don't need any concurrency for verification - all I need to do is a lot of verifications ;-). > There is another performance problem, I consider even more important > than the repeated fork/exec: The searching within the keyrings is > highly inefficient and need to be tackled at the same time. I have > some basic code to do this. Not an immediate problem for me, as the set of keys is pretty small - under 50 at the moment, with potential to expand to ~350. > The current plan however is to get out a GnuPG 2.0 asap and then to > work on the server issue and keyring searching. Is the TODO list in the 1.9 branch accurate? If 2.0 is close, then I'll hold off for a little while before starting on a server interface for g10. -- Robin Hugh Johnson E-Mail : robbat2@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 241 bytes Desc: not available Url : /pipermail/attachments/20060522/87016fc2/attachment.pgp From wk at gnupg.org Mon May 22 20:49:36 2006 From: wk at gnupg.org (Werner Koch) Date: Mon May 22 20:51:25 2006 Subject: High performance GnuPG - Assuan interface to g10? In-Reply-To: <20060522182034.GF8889@curie-int.vc.shawcable.net> (Robin H. Johnson's message of "Mon, 22 May 2006 11:20:34 -0700") References: <20060522182034.GF8889@curie-int.vc.shawcable.net> Message-ID: <877j4d99of.fsf@wheatstone.g10code.de> "Robin H. Johnson" writes: > I don't need any concurrency for verification - all I need to do is a lot of > verifications ;-). That makes it easier. So you may make use of a first limited version. > Is the TODO list in the 1.9 branch accurate? Not sure, some things might only be in my head. > If 2.0 is close, then I'll hold off for a little while before starting on a > server interface for g10. Unfortunately 2.0 will not have the server interface. We need to do this release for some distributions who really want something claimed to be a stable versions and where there is no need to install 1.4 in addition to 1.9. After that we can work on enhancements. Please keep in mind that we need copyright assignments to the FSF for all contributions. Salam-Shalom, Werner From jan-oliver.wagner at intevation.de Mon May 22 22:53:45 2006 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Mon May 22 22:51:51 2006 Subject: gnupg.org bugtracker is sub-optimal In-Reply-To: <87slnae06o.fsf@wheatstone.g10code.de> References: <200605152258.05246.jan-oliver.wagner@intevation.de> <87slnae06o.fsf@wheatstone.g10code.de> Message-ID: <200605222253.46009.jan-oliver.wagner@intevation.de> Am Dienstag, 16. Mai 2006 12:25 schrieb Werner Koch: > Jan-Oliver Wagner writes: > > It is not possible to add comments (e.g. further findings of the reporter > > or additional hints from others) to a report once it has been submitted. > > Reply to the email notifications. but then only me and no others can add comments? > > Is there a particular reason why the gnupg.org bug tracker behaves > > as it does? > > yes, for antispam reasons. isn't it sufficient to require people to create a account to get rid of most spam? Many bug trackers work this way. Best Jan -- Jan-Oliver Wagner: www.intevation.de/~jan | GISpatcher: www.gispatcher.de Kolab Konsortium : www.kolab-konsortium.de | Thuban : thuban.intevation.org Intevation GmbH : www.intevation.de | Kolab : www.kolab.org FreeGIS : www.freegis.org | GAV : www.grass-verein.de From dshaw at jabberwocky.com Mon May 22 23:10:12 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Mon May 22 23:09:10 2006 Subject: make check failure in gnupg 1.4.4-svn4139 In-Reply-To: <44721BA5.50500@comcast.net> References: <44721BA5.50500@comcast.net> Message-ID: <20060522211012.GB7222@jabberwocky.com> On Mon, May 22, 2006 at 03:14:29PM -0500, John Clizbe wrote: > Had been passing all tests. MinGW and Cygwin builds > > make check > > PASS: armdetachm.test > PASS: detachm.test > PASS: genkey1024.test > PASS: conventional.test > PASS: conventional-mdc.test > PASS: multisig.test > PASS: verify.test > armor.test: the armored_key_8192 bug is back in town > FAIL: armor.test My mistake as part of the auto-key-locate patch. Fixed now. David From JPClizbe at comcast.net Mon May 22 22:14:29 2006 From: JPClizbe at comcast.net (John Clizbe) Date: Mon May 22 23:26:01 2006 Subject: make check failure in gnupg 1.4.4-svn4139 Message-ID: <44721BA5.50500@comcast.net> Had been passing all tests. MinGW and Cygwin builds make check PASS: armdetachm.test PASS: detachm.test PASS: genkey1024.test PASS: conventional.test PASS: conventional-mdc.test PASS: multisig.test PASS: verify.test armor.test: the armored_key_8192 bug is back in town FAIL: armor.test ================================== 1 of 27 tests failed $ g10/gpg --version gpg (GnuPG) 1.4.4-svn4139 Copyright (C) 2006 Free Software Foundation, Inc. -- John P. Clizbe Inet: JPClizbe(a)comcast DOT nyet Golden Bear Networks PGP/GPG KeyID: 0x608D2A10 "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: 663 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060522/0ebea898/signature-0001.pgp From JPClizbe at comcast.net Mon May 22 23:36:37 2006 From: JPClizbe at comcast.net (John Clizbe) Date: Tue May 23 00:09:14 2006 Subject: make check failure in gnupg 1.4.4-svn4139 In-Reply-To: <20060522211012.GB7222@jabberwocky.com> References: <44721BA5.50500@comcast.net> <20060522211012.GB7222@jabberwocky.com> Message-ID: <44722EE5.3030705@comcast.net> David Shaw wrote: > On Mon, May 22, 2006 at 03:14:29PM -0500, John Clizbe wrote: >> Had been passing all tests. MinGW and Cygwin builds >> >> make check >> >> PASS: armdetachm.test >> PASS: detachm.test >> PASS: genkey1024.test >> PASS: conventional.test >> PASS: conventional-mdc.test >> PASS: multisig.test >> PASS: verify.test >> armor.test: the armored_key_8192 bug is back in town >> FAIL: armor.test > > My mistake as part of the auto-key-locate patch. Fixed now. > confirmed. -- John P. Clizbe Inet: JPClizbe(a)comcast DOT nyet Golden Bear Networks PGP/GPG KeyID: 0x608D2A10 "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: 663 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060522/0a4e790f/signature.pgp From dshaw at jabberwocky.com Tue May 23 00:29:30 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Tue May 23 00:28:29 2006 Subject: RegEx for ASCII public keys? In-Reply-To: <20060520154042.314950@gmx.net> References: <20060520154042.314950@gmx.net> Message-ID: <20060522222930.GE7222@jabberwocky.com> On Sat, May 20, 2006 at 05:40:42PM +0200, Michael Lampard wrote: > Hy, > > is there some kind of regular expression for ASCII public keys (*) in GnuPG? If so, where can I find it? > > Greetings > > Michael > > (*) like the ones I get by "gpg --armor --export " You could probably cook one up with the information in RFC-2440. Basically, they're base64 data apart from the headers. David From ilugo at bridonsecurity.com Wed May 24 05:48:18 2006 From: ilugo at bridonsecurity.com (Israel G. Lugo) Date: Wed May 24 05:47:19 2006 Subject: [patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath In-Reply-To: <4473C682.2090808@bridonsecurity.com> References: <4473C682.2090808@bridonsecurity.com> Message-ID: <4473D782.7000609@bridonsecurity.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I forgot to ask in my previous email whether there was a need for some sort of legal disclaimer for the patch. I would be happy to provide one if necessary (although if one were necessary, I would appreciate it if someone could please point me to what the steps are in producing it). Regards, Israel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEc9eCgn9msFnMGkcRAiCqAJ4ryUqQdDQKpG8WYTy2jj5l6oH57QCfX8rH zep6R4ZAznZKakxb0Yf2H2c= =Hv/N -----END PGP SIGNATURE----- From ilugo at bridonsecurity.com Wed May 24 04:35:46 2006 From: ilugo at bridonsecurity.com (Israel G. Lugo) Date: Wed May 24 05:56:13 2006 Subject: [patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath Message-ID: <4473C682.2090808@bridonsecurity.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, There is a problem in GnuPG, in the way g10/exec.c's make_tempdir() obtains the temporary directory path on Windows systems. There is a hardcoded limit of 256 characters (including the '\0') for the length of the path (if a hard-limit is to be imposed, it should at least be MAX_PATH+1). What's worse, there is no verification being made as to whether the buffer was large enough to fit the path. In the event that the hardcoded 256 bytes are not enough to hold the path plus '\0', GetTempPath will do nothing and return the size of the buffer required to hold the path. The current code will take that as success and continue on, using uninitialized data as the temporary directory path. The problem exists in both the stable and development branches, both in the CVS and in the releases (1.4.3 and 1.9.20); the relevant portion of code is the same in all of them. I am attaching a patch that will make the appropriate corrections. As mentioned the code is the same in both the stable and development branches, so the patch is applicable to both. ChangeLog entry follows: 2006-05-24 Israel G. Lugo * exec.c (make_tempdir) [_WIN32]: Modified to properly handle arbitrarily long temporary directory paths. Fix lack of verification that would cause uninitialized data to be used as temporary directory path if the path was too long to fit in the buffer. I also saw something which I believe could be changed, in the same function: in case of failure to obtain the temporary directory (GetTempPath failure), make_tempdir() is using the hardcoded string "c:\\windows\\temp". This will break on NT/2000 systems, for example (the Windows directory is \WINNT), on some non-English systems and, of course, on systems where the user chose to customize his/her installation directory (or installed to a partition other than C:). I would propose doing away with the hardcoded string and obtaining the Windows directory from the API. If that fails as well then the hardcoded string could be used as a last resort. I would be more than willing to produce such a patch, if it was agreeable to the development team. Regards, Israel G. Lugo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEc8aCgn9msFnMGkcRAmYWAKCz3Zdx9X/CUQf4QrCzCVUyTUCsIQCfVgUe ny8uWCw9HVcXcqAeI42nX6Q= =NyfZ -----END PGP SIGNATURE----- -------------- next part -------------- diff -durp gnupg-1.4.3/g10/exec.c gnupg-1.4.3-gettemppath/g10/exec.c --- gnupg-1.4.3/g10/exec.c Wed Sep 7 16:23:10 2005 +++ gnupg-1.4.3-gettemppath/g10/exec.c Wed May 24 02:38:58 2006 @@ -129,13 +129,31 @@ static int make_tempdir(struct exec_info if(tmp==NULL) { #if defined (_WIN32) - tmp=xmalloc(256); - if(GetTempPath(256,tmp)==0) - strcpy(tmp,"c:\\windows\\temp"); - else + /* Get size of the required buffer (including '\0') */ + int len=(int)GetTempPath(0, NULL); + int tmp_siz; + + /* The tmp path could change between us polling its length and + * getting it; loop just in case (should work at first pass). */ + do { - int len=strlen(tmp); + tmp_siz=len; + + if (tmp!=NULL) + xfree(tmp); + tmp=xmalloc(tmp_siz); + len=(int)GetTempPath(tmp_siz,tmp); + } + while(len>tmp_siz); + /* len is the number of characters copied to tmp, not counting '\0' */ + if(len==0) + { + xfree(tmp); + tmp=xstrdup("c:\\windows\\temp"); + } + else + { /* GetTempPath may return with \ on the end */ while(len>0 && tmp[len-1]=='\\') { From dshaw at jabberwocky.com Wed May 24 07:10:03 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed May 24 07:09:07 2006 Subject: [patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath In-Reply-To: <4473C682.2090808@bridonsecurity.com> References: <4473C682.2090808@bridonsecurity.com> Message-ID: <20060524051003.GA17558@jabberwocky.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, May 24, 2006 at 03:35:46AM +0100, Israel G. Lugo wrote: > Greetings, > > There is a problem in GnuPG, in the way g10/exec.c's make_tempdir() > obtains the temporary directory path on Windows systems. There is a > hardcoded limit of 256 characters (including the '\0') for the length > of the path (if a hard-limit is to be imposed, it should at least be > MAX_PATH+1). What's worse, there is no verification being made as to > whether the buffer was large enough to fit the path. In the event that > the hardcoded 256 bytes are not enough to hold the path plus '\0', > GetTempPath will do nothing and return the size of the buffer required > to hold the path. The current code will take that as success and > continue on, using uninitialized data as the temporary directory path. > > The problem exists in both the stable and development branches, both > in the CVS and in the releases (1.4.3 and 1.9.20); the relevant > portion of code is the same in all of them. I think the proposed fix is a bit of overkill. I'd rather do something simpler, like (not tested yet): Index: exec.c =================================================================== - --- exec.c (revision 4145) +++ exec.c (working copy) @@ -129,8 +129,11 @@ if(tmp==NULL) { #if defined (_WIN32) - - tmp=xmalloc(256); - - if(GetTempPath(256,tmp)==0) + char tmp[MAX_PATH+1]; + int err; + + err=GetTempPath(MAX_PATH+1,tmp); + if(err==0 || err>MAX_PATH+1) strcpy(tmp,"c:\\windows\\temp"); else { @@ -165,10 +168,6 @@ sprintf(info->tempdir,"%s" DIRSEP_S "gpg-XXXXXX",tmp); - -#if defined (_WIN32) - - xfree(tmp); - -#endif - - if(mkdtemp(info->tempdir)==NULL) log_error(_("can't create directory `%s': %s\n"), info->tempdir,strerror(errno)); > I also saw something which I believe could be changed, in the same > function: in case of failure to obtain the temporary directory > (GetTempPath failure), make_tempdir() is using the hardcoded string > "c:\\windows\\temp". This will break on NT/2000 systems, for example > (the Windows directory is \WINNT), on some non-English systems and, > of course, on systems where the user chose to customize his/her > installation directory (or installed to a partition other than > C:). I would propose doing away with the hardcoded string and > obtaining the Windows directory from the API. If that fails as well > then the hardcoded string could be used as a last resort. I would be > more than willing to produce such a patch, if it was agreeable to > the development team. There is no need to get the Windows directory specially, as GetTempPath will return the Windows directory as a last resort. It tries $TMP, $TEMP, $USERPROFILE, and finally the Windows directory. I must admit I'm not terribly concerned that some version of Windows somewhere can't handle c:\windows\temp. If we get that far, it means GetTempPath failed in some manner, and if GetTempPath fails with MAX_PATH+1, then the system is sufficiently broken that we likely don't *want* to continue executing. ;) David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4-svn4114 (GNU/Linux) iGoEARECACoFAkRz6qsjGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2tleS5h c2MACgkQ4mZch0nhy8lSDgCeIJox4iiLBwcbANsT4oiHFkSnFX4An1iNht1egSrN egRmrxXfKGwp0kKW =znhe -----END PGP SIGNATURE----- From ueno at unixuser.org Wed May 24 08:49:17 2006 From: ueno at unixuser.org (Daiki Ueno) Date: Wed May 24 08:48:28 2006 Subject: --output support for gpgsm Message-ID: <64094f34-292c-484e-b861-a6dc6e215d68@well-done.deisui.org> Hello, I have been working on an Emacs interface to gpgsm and I found that --output is indispensable because Emacs can't handle separate file descripters for input. While I know that this is in the TODO list, I see no difficulty in implementing it, so I wrote the patch attached below. -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgsm.c.diff Type: application/octet-stream Size: 4102 bytes Desc: not available Url : /pipermail/attachments/20060524/a17d2430/gpgsm.c.obj -------------- next part -------------- Regards, -- Daiki Ueno From ilugo at bridonsecurity.com Wed May 24 23:50:23 2006 From: ilugo at bridonsecurity.com (Israel G. Lugo) Date: Wed May 24 23:49:50 2006 Subject: [patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath In-Reply-To: <20060524051003.GA17558@jabberwocky.com> References: <4473C682.2090808@bridonsecurity.com> <20060524051003.GA17558@jabberwocky.com> Message-ID: <4474D51F.8060106@bridonsecurity.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw wrote: > I think the proposed fix is a bit of overkill. I'd rather do > something simpler, like (not tested yet): That is still enforcing a hardcoded limit, though, of MAX_PATH characters (which is defined to 260 in the 2003 SDK). If we can behave elegantly and support arbitrarily long paths with ease, why would we want to impose an unnecessary artificial limit on ourselves? If the user's temporary directory happens to be longer than 260 bytes (think localized Windows versions, or large usernames, or multibyte locales or whatever), the alternative solution you quoted will reject it (and fall back to the non-portable c:\windows\temp thing), when it wasn't really necessary to do so. It kind of reminds me of the whole "2 digits should be more than enough to represent the year" thing - or, in this case, "260 bytes should be more than enough for everyone" ;) Why not aim to be scalable and flexible now, if we can easily do it without introducing any other problems? (in fact it's already done in the solution I proposed) I believe if it is possible to improve on something, even if only a bit, then it should be done, unless it is counterproductive to do so. After all, a very important part of the Free Software spirit (or Open Source, however one might prefer to think of it) is to have an open development model, with people from the community trying to work together and with those people from outside the project who are motivated enough to contribute and want to help the project be the best it can be. > There is no need to get the Windows directory specially, as > GetTempPath will return the Windows directory as a last resort. It > tries $TMP, $TEMP, $USERPROFILE, and finally the Windows > directory. That is true; I suppose I was only trying to make the program a bit more resilient. We don't really know for what reasons GetTempPath might fail (some internal error, etc). It could fail for a reason other than not being able to detect the Windows directory; in such a case, GPG might still be able to get the Windows directory, by using GetWindowsDirectory (if that fails too then we could always fall back to the hardcoded thing). > I must admit I'm not terribly concerned that some version of > Windows somewhere can't handle c:\windows\temp. If we get that > far, it means GetTempPath failed in some manner, and if GetTempPath > fails with MAX_PATH+1, then the system is sufficiently broken that > we likely don't *want* to continue executing. ;) My own Windows installation is a good example which would not work with c:\windows\temp ;) I have it on F:\winnt. Any NT or 2000 Windows will be on \winnt by default, for example. Localized versions in some languages will probably install in a different path as well (or at least the \temp part, it might be called something else). And of course, one can always customize his installation path upon installing the OS. So, I don't think hardcoding is the best solution, at least not the way it was done in the alternative solution you posted, since the hardcoded case can be entered for more reasons than just a broken system (temp path longer than the hardcoded limit of MAX_PATH, or some internal error inside GetTempPath, for example). Falling back to c:\windows\temp as a last resort if GetLastTemp errored out might make sense (although it could potentially still be a recoverable error), but doing so because the path is longer than some artificially imposed limit would seem a bit odd. Ideally, I still think there should be an explicit check using GetWindowsDirectory before giving up, but I suppose that might be overkill if we're at least sure that we do handle valid temp paths properly, regardless of their length. Now, I dislike Windows as much as anyone else. I would be a happy man if everyone used some form of free operating system such as GNU, *BSD or whatever. However, that is besides the point. If GnuPG is officially supposed to work on Windows, then it should do so to the best of its abilities, like it does on the other OSes for which it is developed. If GnuPG breaks on Windows because the user's temporary path was longer than some imposed limit, people are not going to blame Windows, they're going to blame GnuPG. I understand it may perhaps be difficult for some of the GPG developers to be motivated to develop for the Windows platform, or even to test the program on it. I myself use GNU/Linux for most of my computing tasks, but I do regrettably have to use Windows as well. Should there be a need, I would be happy to help with any development work, as I am comfortable with both platforms and could run and test the program on either. In any event, I would submit that the solution I proposed initially, with the handling of arbitrarily long paths, would be a good compromise between not being flexible enough (hardcoded limits, etc) and being "too" flexible (checking the Windows dir after GetTempPath failed, and so on). It may add 4 or 5 lines of code, but there really isn't much getting around the GetTempPath interface: there is simply no guarantee on what the temp path length will be. One really has to poll and fetch (or at least make an initial guess hoping that it will be long enough, but a loop is inevitable to cover the case when the initial guess is not long enough). Regards, Israel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEdNUfgn9msFnMGkcRAnMWAKCKV+fDpnAsCZIFFfBfydyIFEhm8wCfebTd rQFmOD3SaTQKdK3vq74dGxE= =g60v -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Thu May 25 00:38:57 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu May 25 00:38:00 2006 Subject: [patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath In-Reply-To: <4474D51F.8060106@bridonsecurity.com> References: <4473C682.2090808@bridonsecurity.com> <20060524051003.GA17558@jabberwocky.com> <4474D51F.8060106@bridonsecurity.com> Message-ID: <20060524223857.GH18893@jabberwocky.com> On Wed, May 24, 2006 at 10:50:23PM +0100, Israel G. Lugo wrote: > David Shaw wrote: > > I think the proposed fix is a bit of overkill. I'd rather do > > something simpler, like (not tested yet): > That is still enforcing a hardcoded limit, though, of MAX_PATH > characters (which is defined to 260 in the 2003 SDK). If we can behave > elegantly and support arbitrarily long paths with ease, why would we > want to impose an unnecessary artificial limit on ourselves? > > If the user's temporary directory happens to be longer than 260 bytes > (think localized Windows versions, or large usernames, or multibyte > locales or whatever), the alternative solution you quoted will reject > it (and fall back to the non-portable c:\windows\temp thing), when it > wasn't really necessary to do so. So MAX_PATH is not, in fact, the maximum path on Windows? Wow, that's a good idea. Is there a MAX_PATH_WE_REALLY_MEAN_IT or similar that I can use here? What is the real maximum path? > > There is no need to get the Windows directory specially, as > > GetTempPath will return the Windows directory as a last resort. It > > tries $TMP, $TEMP, $USERPROFILE, and finally the Windows > > directory. > That is true; I suppose I was only trying to make the program a bit > more resilient. We don't really know for what reasons GetTempPath > might fail (some internal error, etc). It could fail for a reason > other than not being able to detect the Windows directory; in such a > case, GPG might still be able to get the Windows directory, by using > GetWindowsDirectory (if that fails too then we could always fall back > to the hardcoded thing). To what end? We could write a dozen fallbacks: "well, if GetTempPath fails, we'll figure out the localization of the particular system and try a few directories, if that fails we'll figure out what version of Windows it is and try a few directories..." No, therein lies madness. The OS provides GetTempPath. If it fails, then the answer is to tell the user so and they can fix it. It's rather like how GnuPG uses a wrapper around malloc. If malloc fails, it aborts the process. It doesn't try and use a file on disk as temporary swap space so it can keep going. If /dev/random doesn't exist, we tell the user that and exit. We don't call mknod. Similarly, if we're fetching a key from a keyserver on port 11371 (the HKP port) and get a connection refused, we don't try port 80 just in case it'll work. If the user wanted port 80, they'd have asked for port 80. You're quite right that the existing code uses GetTempPath incorrectly, and that the code won't work (probably crash) if the temporary path is longer than 256 bytes. Give me a number and I'll raise the size, but layers of fallbacks strikes me as unnecessary complication in a relatively unimportant place in the code. Note also that this incorrect code has been in GnuPG for around 4 years now, and nobody noticed, meaning nobody used a temporary directory path larger than 256 bytes... > I understand it may perhaps be difficult for some of the GPG > developers to be motivated to develop for the Windows platform, or > even to test the program on it. I myself use GNU/Linux for most of my > computing tasks, but I do regrettably have to use Windows as well. This is not a "Windows=Bad, Unix=Good" thing! Both Windows and Unix provide an API for getting a temporary directory. If that API fails, then that's it, on whatever platform. In the Unix code, if you set $TMPDIR to garbage, then it won't work. In neither case do I think that trying many different directories to try and find a "good" one is advisable. David From ilugo at bridonsecurity.com Thu May 25 02:21:36 2006 From: ilugo at bridonsecurity.com (Israel G. Lugo) Date: Thu May 25 02:50:05 2006 Subject: [patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath In-Reply-To: <20060524223857.GH18893@jabberwocky.com> References: <4473C682.2090808@bridonsecurity.com> <20060524051003.GA17558@jabberwocky.com> <4474D51F.8060106@bridonsecurity.com> <20060524223857.GH18893@jabberwocky.com> Message-ID: <4474F890.8050504@bridonsecurity.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw wrote: > So MAX_PATH is not, in fact, the maximum path on Windows? Wow, > that's a good idea. Is there a MAX_PATH_WE_REALLY_MEAN_IT or > similar that I can use here? What is the real maximum path? The GetTempPath reference says nothing of there being a limit of any sort, in particular of the buffer being limited to MAX_PATH bytes. It is certainly perfectly possible to set an environment variable longer than MAX_PATH (the API reference mentions the limit for an environment variable being 32768 including '\0'). I don't know whether a large $TMP will work or not in current versions of Windows. However, I say again: why impose an unnecessary limit of our own when we can elegantly deal with arbitrarily long data? There was a time when 8+3 characters for a filename seemed to some "everything you would ever need". There was a time when no one would think of using more than 2 digits to store the year - that turned out nicely. Then there's the other side of the coin: when $TMP is a small string, why waste space allocating a huge MAX_PATH array? You can easily allocate just the necessary amount of space, no more, no less. > To what end? We could write a dozen fallbacks: "well, if > GetTempPath fails, we'll figure out the localization of the > particular system and try a few directories, if that fails we'll > figure out what version of Windows it is and try a few > directories..." I was hardly suggesting that... I had mentioned the GetWindowsDirectory API, and I had also mentioned that it might also make sense to just fallback to the hardcoded path since GetTempPath does try to obtain the Windows directory as well, as long as this was done in case of error and not just because a $TMP path was larger than some arbitrary limit. > Give me a number and I'll raise the size, but layers of fallbacks > strikes me as unnecessary complication in a relatively unimportant > place in the code. Why have a number at all? The solution I had proposed would have dealt with any size in an efficient manner, without wasting memory allocating 1,000,000 bytes "just to be sure" or failing because "42 is more than enough for anyone". > Note also that this incorrect code has been in GnuPG for around 4 > years now, and nobody noticed, meaning nobody used a temporary > directory path larger than 256 bytes... Uhh... I'm sorry for trying to help, then? I don't see the need to become so defensive. I very much enjoy the GnuPG program, and I very much appreciate all the effort made by the GnuPG team. I saw something which could be improved, and I wanted to give something back and contribute, as a fellow developer, in the spirit of open source. I saw a hardcoded 256 limit that could easily be gotten rid of, a possibly large problem (which might even be a security risk) as there was no check being made as to whether or not GetTempPath succeeded before using tmp (setting $TMP to something > 256 bytes would at the very least DoS the program as tmp would not be initialized, which could conceivably even bring worse consequences later on). I thought "hey why not help and give something back" so I made a patch, reported the problem and offered a solution. Quite frankly, the reaction I've gotten makes me feel that I should have said nothing in the first place... > This is not a "Windows=Bad, Unix=Good" thing! Both Windows and > Unix provide an API for getting a temporary directory. If that API > fails, then that's it, on whatever platform. In the Unix code, if > you set $TMPDIR to garbage, then it won't work. In neither case do > I think that trying many different directories to try and find a > "good" one is advisable. The c:\windows\temp thing wasn't even my main point... You will notice I did not address that in the patch I sent. My point was fixing a quite real problem (GetTempPath's result was not being checked and tmp could be used with complete garbage inside if, say, $TMP was > 256, for example) and improving something which could be improved (loosing the hardcoded malloc and switching to a flexible, non-limited and non-wasting solution). I wanted to to offer my help in a project which I find worthy and noble, to contribute and engage in a friendly technical discussion with fellow developers; not to argue with them. Regards, Israel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEdPiPgn9msFnMGkcRAoUcAJ9DFkxIl3UHQh8xCLYzi5DfSnkBkACgrOqc kvZw63Bp9d2KcTbPCBfYx2g= =Y88O -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Thu May 25 04:47:37 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu May 25 04:46:37 2006 Subject: [patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath In-Reply-To: <4474D51F.8060106@bridonsecurity.com> References: <4473C682.2090808@bridonsecurity.com> <20060524051003.GA17558@jabberwocky.com> <4474D51F.8060106@bridonsecurity.com> Message-ID: <20060525024737.GA19658@jabberwocky.com> FYI: I just committed a fix for the original uninitialized data bug you reported. Please don't interpret that as my cutting off this discussion. I just didn't want to leave a potential crash case outstanding. David From atom at smasher.org Thu May 25 05:38:17 2006 From: atom at smasher.org (Atom Smasher) Date: Thu May 25 05:37:13 2006 Subject: corrupt trustdb caused by commandline? In-Reply-To: <20060509171352.GD24267@jabberwocky.com> References: <20060509011153.14060.qmail@smasher.org> <20060509171352.GD24267@jabberwocky.com> Message-ID: <20060525033821.80142.qmail@smasher.org> On Tue, 9 May 2006, David Shaw wrote: > I'm not sure why you didn't have the problem in 1.4.2. It should happen > there as well. > > Try this patch. =================== took me some time to try this out... i tweaked the patch to drop it into /usr/ports/security/gnupg/files/patch-stdout.reopen.patch (freeBSD ports), reinstalled gpg and everything is now running smooth. so... * why was closing stdout causing gpg to have problems? * will this patch be incorporated into production? * why was 1.4.2 not having problems with this? thanks... -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "According to the Bible, God created the heavens and the Earth. It is man's prerogative - and woman's - to create their own particular and private hell." -- Rod Serling From dshaw at jabberwocky.com Thu May 25 05:55:23 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu May 25 05:54:40 2006 Subject: [patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath In-Reply-To: <4474F890.8050504@bridonsecurity.com> References: <4473C682.2090808@bridonsecurity.com> <20060524051003.GA17558@jabberwocky.com> <4474D51F.8060106@bridonsecurity.com> <20060524223857.GH18893@jabberwocky.com> <4474F890.8050504@bridonsecurity.com> Message-ID: <20060525035523.GB27463@jabberwocky.com> On Thu, May 25, 2006 at 01:21:36AM +0100, Israel G. Lugo wrote: > > Note also that this incorrect code has been in GnuPG for around 4 > > years now, and nobody noticed, meaning nobody used a temporary > > directory path larger than 256 bytes... > Uhh... I'm sorry for trying to help, then? I don't see the need to > become so defensive. I don't mention it in terms of defensiveness, I mention it to try and put some perspective to this discussion: we're not talking about a fatal flaw in a cipher here. We're talking about *picking a temporary directory*. (By the way, on Win32, GnuPG has MAX_PATH bytes hardcoded in multiple places. It's not just temporary directories.) > > This is not a "Windows=Bad, Unix=Good" thing! Both Windows and > > Unix provide an API for getting a temporary directory. If that API > > fails, then that's it, on whatever platform. In the Unix code, if > > you set $TMPDIR to garbage, then it won't work. In neither case do > > I think that trying many different directories to try and find a > > "good" one is advisable. > The c:\windows\temp thing wasn't even my main point... You will notice > I did not address that in the patch I sent. My point was fixing a > quite real problem (GetTempPath's result was not being checked and tmp > could be used with complete garbage inside if, say, $TMP was > 256, > for example) and improving something which could be improved (loosing > the hardcoded malloc and switching to a flexible, non-limited and > non-wasting solution). As I have said, I completely agree with you about the problem with temporary paths over 256 bytes. There was never any question about that, and in fact it has already been fixed. The improvement that you proposed in the same mail, however, I disagree with. I don't think that the cost/benefit ratio justifies it. It's complex, involving (potentially) multiple passes just to get a temporary directory. You also suggested fallbacks if GetTempDir did not succeed. If this was a crucial part of the system, I'd probably be more eager to dive into it, but again, we're talking about picking a temporary directory here. > I wanted to to offer my help in a project which I find worthy and > noble, to contribute and engage in a friendly technical discussion > with fellow developers; not to argue with them. I'm sorry you interpret someone disagreeing with you as an argument. I feel quite friendly about this discussion. David From dshaw at jabberwocky.com Thu May 25 06:02:13 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu May 25 06:01:08 2006 Subject: corrupt trustdb caused by commandline? In-Reply-To: <20060525033821.80142.qmail@smasher.org> References: <20060509011153.14060.qmail@smasher.org> <20060509171352.GD24267@jabberwocky.com> <20060525033821.80142.qmail@smasher.org> Message-ID: <20060525040213.GA27614@jabberwocky.com> On Wed, May 24, 2006 at 11:38:17PM -0400, Atom Smasher wrote: > On Tue, 9 May 2006, David Shaw wrote: > > >I'm not sure why you didn't have the problem in 1.4.2. It should happen > >there as well. > > > >Try this patch. > =================== > > took me some time to try this out... > > i tweaked the patch to drop it into > /usr/ports/security/gnupg/files/patch-stdout.reopen.patch (freeBSD ports), > reinstalled gpg and everything is now running smooth. > > so... > * why was closing stdout causing gpg to have problems? It's not a GPG thing, specifically. Closing stdout (or stderr) is actually a pretty dangerous thing to do on *any* program that opens files and also uses printf. Here's an example: fd=open("foo",O_WRONLY,0777); printf("hi there - I'm writing to a file\n"); write(fd,"whee",4); Normally, if you run this, you get "hi there" on stdout, and "whee" in the file. Close stdout before you run it, and the open() can end up with fd 1 attached to "foo". When you printf, you'll be printf-ing to "foo" as well, mangling it. If the goal is to squish stdout, you should redirect stdout to /dev/null rather than closing it outright. > * will this patch be incorporated into production? Yes. Already has, actually. > * why was 1.4.2 not having problems with this? Luck? I'm honestly not sure - the code in 1.4.2 and 1.4.3 here is nearly identical. David From atom at smasher.org Thu May 25 06:15:40 2006 From: atom at smasher.org (Atom Smasher) Date: Thu May 25 06:14:58 2006 Subject: corrupt trustdb caused by commandline? In-Reply-To: <20060525040213.GA27614@jabberwocky.com> References: <20060509011153.14060.qmail@smasher.org> <20060509171352.GD24267@jabberwocky.com> <20060525033821.80142.qmail@smasher.org> <20060525040213.GA27614@jabberwocky.com> Message-ID: <20060525041543.4820.qmail@smasher.org> On Thu, 25 May 2006, David Shaw wrote: >> * why was closing stdout causing gpg to have problems? > > It's not a GPG thing, specifically. Closing stdout (or stderr) is > actually a pretty dangerous thing to do on *any* program that opens > files and also uses printf. ... > If the goal is to squish stdout, you should redirect stdout to > /dev/null rather than closing it outright. > >> * will this patch be incorporated into production? > > Yes. Already has, actually. ========================== this is being used in part of a script that just tests for return status, and any output is undesired. would you recommend changing the script to redirect stdout/stderr to /dev/null? or should it be ok, now, to just close stdout/stderr? or is there a better way altogether that i'm overlooking? thanks... -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "A farmer's duty, is protecting the earth, maintaining it's fertility, and maintaining the fertility of seed. That is part of being a farmer. A farmer is not a low-paid tractor driver, that's a modern definition of what a farmer is. The real definition of a farmer is a person who relates to the land and relates to the seed and keeps it for future generations, keeps renewing it, fertility." -- Dr. Vandana Shiva From ilugo at bridonsecurity.com Thu May 25 07:43:56 2006 From: ilugo at bridonsecurity.com (Israel G. Lugo) Date: Thu May 25 07:43:12 2006 Subject: [patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath In-Reply-To: <20060525035523.GB27463@jabberwocky.com> References: <4473C682.2090808@bridonsecurity.com> <20060524051003.GA17558@jabberwocky.com> <4474D51F.8060106@bridonsecurity.com> <20060524223857.GH18893@jabberwocky.com> <4474F890.8050504@bridonsecurity.com> <20060525035523.GB27463@jabberwocky.com> Message-ID: <4475441C.3080008@bridonsecurity.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw wrote: > we're not talking about a fatal flaw in a cipher here. We're > talking about *picking a temporary directory*. (By the way, on > Win32, GnuPG has MAX_PATH bytes hardcoded in multiple places. It's > not just temporary directories.) The fall back to GetWindowsDirectory was just a lateral suggestion, not the point in itself - I did agree, when you noted that GetTempPath tries the Windows directory before giving up, that a fallback to GetWindowsDirectory might be somewhat overdoing it. I would, however, note that picking a temporary directory in itself is not the problem: the problem is if we pick one which does not exist (such as c:\windows\temp on any NT/2000 system) and fail because of that. I'm thinking for example --refresh-keys; that would fail from this. I just wanted to make the program as robust as possible and avoid failures that could potentially be recovered from. But yes, it is may be overkill, considering that GetTempPath already tries the Windows directory. > As I have said, I completely agree with you about the problem with > temporary paths over 256 bytes. There was never any question about > that, and in fact it has already been fixed. The improvement that > you proposed in the same mail, however, I disagree with. I don't > think that the cost/benefit ratio justifies it. It's complex, > involving (potentially) multiple passes just to get a temporary > directory. You also suggested fallbacks if GetTempDir did not > succeed. If this was a crucial part of the system, I'd probably be > more eager to dive into it, but again, we're talking about picking > a temporary directory here. The passes thing is only there to take care of the race condition where $TMP might change between us polling the temp length and actually obtaining it the second time around. It is highly unlikely that it would happen (except for some sort of timed attack), but in the event that it does, I wanted the code to be protected against it. This is, after all, a security program. In other words, I did not want to see CERT publishing "race condition bug in GnuPG leads to crash with potential data leak" or whatever one year from now, due to my additions to the code. In practical terms there would only ever be one pass, save for some sort of timed attack (from which we would be safe thanks to the passes) or some *really* bad timing from the user happening to change $TMP precisely at that instant. I just don't think we should treat a valid $TMP that happens to be longer than FOO (256, MAX_PATH, whatever) as if it was an error. In case of error, GetTempPath returns 0. If it returned a value larger than our self-imposed FOO, there was no error; our FOO simply was not big enough. We shouldn't die or fall back to some last-resort hardcoded string that might work on some systems and might not work on others... We have a tmp path right there. We just need to fetch it properly. Now, as doing a bunch of trial and error attempts would be rather silly, the simple and straight solution would seem to be simply to poll for the size, malloc the correct amount, then fetch the string. Nothing complicated about that. The one thing that does add a couple of extra lines to the code would be the loop, but that is just a necessary precaution to safeguard against the (very unlikely but possible nonetheless) event of the tmp length changing between the poll and the fetch. Sure, it would look nicer if we didn't have to check after the fetch to make sure we weren't sidetracked along the way, and it would look even nicer if GetTempPath returned a malloc'ed string with the right size already, letting us do it all in one single API call. But that's not what we have to work with. What we do have is an API that returns a tmp path of a size which, to us, needs to be treated as arbitrary, since there is no documented maximum (further supported by the fact that the function even has a mechanism to obtain the length at runtime). How do we deal with such a function? 1. Take a guess, think up some number that we reckon is large enough, and arbitrarily reject anything larger than that - "640KB of RAM is more than anyone will ever need" 2. Use what the function provides us with. Poll it to get the required buffer size, then fetch the string with the proper buffer. Yes, if GetTempPath returns an error because it can't find the temp directory, we can just use the hardcoded string as a last-ditch resort, for simplicity's sake - since GetTempPath will have already tried to use the Windows directory before giving up. We can't be sure that not finding the temp dir is the only possible reason for GetTempPath to fail, though (if only the W32 API reference was kind enough to at least hint at the possible error causes like real API references do...). But still, for simplicity's sake, and since it's not really a life-or-death part of the program, I suppose it does make sense to just try hardcoded (at least it's better than outright dieing). That is different, however, from a $TMP happening to be longer than a given arbitrary length. That should not be treated the same as an error; if GetTempPath is happy with it (doesn't return 0), why shouldn't we be? > I'm sorry you interpret someone disagreeing with you as an > argument. That is a straw man assertion... I do not interpret someone disagreeing with me as an argument. It is simply that I had made the report, worked on the patch and offered the solution, with the best of intents, wanting to help by fixing a bug and improving a given piece of code to make it more robust. And, to be honest, the feeling I got from your replies was more that of being dismissive, or defensive, than just a technical disagreement (had you for example said initially what you said in the paragraphs I've quoted in this email, I would've been left with a totally different feeling). It can be, however, quite difficult to properly interpret (and convey) tone and intent through text, more so between people who do not know each other. So, if I misinterpreted you, I do apologize. Regards, Israel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEdUQcgn9msFnMGkcRAqUfAKDSn43sNTL8XgAwtO5NgLZDx5W++ACeOdXH syvTdrGuIbv6DjRA21wHAXQ= =lRvr -----END PGP SIGNATURE----- From alphasigmax at gmail.com Thu May 25 11:12:45 2006 From: alphasigmax at gmail.com (Alphax) Date: Thu May 25 13:26:06 2006 Subject: corrupt trustdb caused by commandline? In-Reply-To: <20060525040213.GA27614@jabberwocky.com> References: <20060509011153.14060.qmail@smasher.org> <20060509171352.GD24267@jabberwocky.com> <20060525033821.80142.qmail@smasher.org> <20060525040213.GA27614@jabberwocky.com> Message-ID: <4475750D.3020209@gmail.com> David Shaw wrote: > On Wed, May 24, 2006 at 11:38:17PM -0400, Atom Smasher wrote: >> On Tue, 9 May 2006, David Shaw wrote: >> >>> I'm not sure why you didn't have the problem in 1.4.2. It should happen >>> there as well. >>> >>> Try this patch. >> =================== >> >> took me some time to try this out... >> >> i tweaked the patch to drop it into >> /usr/ports/security/gnupg/files/patch-stdout.reopen.patch (freeBSD ports), >> reinstalled gpg and everything is now running smooth. >> >> so... >> * why was closing stdout causing gpg to have problems? > > It's not a GPG thing, specifically. Closing stdout (or stderr) is > actually a pretty dangerous thing to do on *any* program that opens > files and also uses printf. > > Here's an example: > > fd=open("foo",O_WRONLY,0777); > printf("hi there - I'm writing to a file\n"); > write(fd,"whee",4); > > Normally, if you run this, you get "hi there" on stdout, and "whee" in > the file. Close stdout before you run it, and the open() can end up > with fd 1 attached to "foo". When you printf, you'll be printf-ing to > "foo" as well, mangling it. > > If the goal is to squish stdout, you should redirect stdout to > /dev/null rather than closing it outright. > >> * will this patch be incorporated into production? > > Yes. Already has, actually. > >> * why was 1.4.2 not having problems with this? > > Luck? I'm honestly not sure - the code in 1.4.2 and 1.4.3 here is > nearly identical. > Well, I've experienced this problem before - mainly when CTRL+C-ing an operation that's acting on the keyring and/or the trustdb. Not much fun to recover from. -- Alphax Death to all fanatics! Down with categorical imperative! OpenPGP key: http://tinyurl.com/lvq4g -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 564 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060525/6b9f46e0/signature.pgp From dshaw at jabberwocky.com Thu May 25 15:57:31 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu May 25 15:56:28 2006 Subject: corrupt trustdb caused by commandline? In-Reply-To: <20060525041543.4820.qmail@smasher.org> References: <20060509011153.14060.qmail@smasher.org> <20060509171352.GD24267@jabberwocky.com> <20060525033821.80142.qmail@smasher.org> <20060525040213.GA27614@jabberwocky.com> <20060525041543.4820.qmail@smasher.org> Message-ID: <20060525135731.GA28955@jabberwocky.com> On Thu, May 25, 2006 at 12:15:40AM -0400, Atom Smasher wrote: > On Thu, 25 May 2006, David Shaw wrote: > > >> * why was closing stdout causing gpg to have problems? > > > >It's not a GPG thing, specifically. Closing stdout (or stderr) is > >actually a pretty dangerous thing to do on *any* program that opens > >files and also uses printf. > ... > >If the goal is to squish stdout, you should redirect stdout to > >/dev/null rather than closing it outright. > > > >> * will this patch be incorporated into production? > > > >Yes. Already has, actually. > ========================== > > this is being used in part of a script that just tests for return status, > and any output is undesired. would you recommend changing the script to > redirect stdout/stderr to /dev/null? or should it be ok, now, to just > close stdout/stderr? or is there a better way altogether that i'm > overlooking? The "right" answer is always to redirect to /dev/null. Again, this isn't a GPG thing, but a general Unix thing. David From dshaw at jabberwocky.com Thu May 25 15:58:20 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu May 25 15:57:14 2006 Subject: corrupt trustdb caused by commandline? In-Reply-To: <4475750D.3020209@gmail.com> References: <20060509011153.14060.qmail@smasher.org> <20060509171352.GD24267@jabberwocky.com> <20060525033821.80142.qmail@smasher.org> <20060525040213.GA27614@jabberwocky.com> <4475750D.3020209@gmail.com> Message-ID: <20060525135820.GB28955@jabberwocky.com> On Thu, May 25, 2006 at 06:42:45PM +0930, Alphax wrote: > David Shaw wrote: > > On Wed, May 24, 2006 at 11:38:17PM -0400, Atom Smasher wrote: > >> On Tue, 9 May 2006, David Shaw wrote: > >> > >>> I'm not sure why you didn't have the problem in 1.4.2. It should happen > >>> there as well. > >>> > >>> Try this patch. > >> =================== > >> > >> took me some time to try this out... > >> > >> i tweaked the patch to drop it into > >> /usr/ports/security/gnupg/files/patch-stdout.reopen.patch (freeBSD ports), > >> reinstalled gpg and everything is now running smooth. > >> > >> so... > >> * why was closing stdout causing gpg to have problems? > > > > It's not a GPG thing, specifically. Closing stdout (or stderr) is > > actually a pretty dangerous thing to do on *any* program that opens > > files and also uses printf. > > > > Here's an example: > > > > fd=open("foo",O_WRONLY,0777); > > printf("hi there - I'm writing to a file\n"); > > write(fd,"whee",4); > > > > Normally, if you run this, you get "hi there" on stdout, and "whee" in > > the file. Close stdout before you run it, and the open() can end up > > with fd 1 attached to "foo". When you printf, you'll be printf-ing to > > "foo" as well, mangling it. > > > > If the goal is to squish stdout, you should redirect stdout to > > /dev/null rather than closing it outright. > > > >> * will this patch be incorporated into production? > > > > Yes. Already has, actually. > > > >> * why was 1.4.2 not having problems with this? > > > > Luck? I'm honestly not sure - the code in 1.4.2 and 1.4.3 here is > > nearly identical. > > > > Well, I've experienced this problem before - mainly when CTRL+C-ing an > operation that's acting on the keyring and/or the trustdb. Not much fun > to recover from. Terminating a process acting on the keyring should not cause this unless you are closing stdout or stderr. David From dshaw at jabberwocky.com Thu May 25 16:23:58 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu May 25 16:22:56 2006 Subject: [patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath In-Reply-To: <4475441C.3080008@bridonsecurity.com> References: <4473C682.2090808@bridonsecurity.com> <20060524051003.GA17558@jabberwocky.com> <4474D51F.8060106@bridonsecurity.com> <20060524223857.GH18893@jabberwocky.com> <4474F890.8050504@bridonsecurity.com> <20060525035523.GB27463@jabberwocky.com> <4475441C.3080008@bridonsecurity.com> Message-ID: <20060525142358.GC28955@jabberwocky.com> On Thu, May 25, 2006 at 06:43:56AM +0100, Israel G. Lugo wrote: > The passes thing is only there to take care of the race condition > where $TMP might change between us polling the temp length and > actually obtaining it the second time around. It is highly unlikely > that it would happen (except for some sort of timed attack), but in > the event that it does, I wanted the code to be protected against it. > This is, after all, a security program. In other words, I did not want > to see CERT publishing "race condition bug in GnuPG leads to crash > with potential data leak" or whatever one year from now, due to my > additions to the code. I do not believe there is a race there, and the multiple passes are needless complexity. GetTempDir is documented to return: 1. The path specified by the TMP environment variable. 2. The path specified by the TEMP environment variable. 3. The path specified by the USERPROFILE environment variable. 4. The Windows directory. On Win98, it goes a bit further and may return the current directory in some cases. Unless Windows can change environment variables out from under a running process, I don't see how any of these change in between passes. > > I'm sorry you interpret someone disagreeing with you as an > > argument. > That is a straw man assertion... I do not interpret someone > disagreeing with me as an argument. Equally as much as the old and tired "Free Software people hate Windows" thing? > It is simply that I had made the report, worked on the patch and > offered the solution, with the best of intents, wanting to help by > fixing a bug and improving a given piece of code to make it more > robust. This is the problem. I don't agree with your solution. I don't think you need multiple passes. I do question just how useful it is to allow arbitrarily large temporary directories when every other piece of directory fetching code for Win32 has a MAX_PATH limit anyway, but don't really care much either way about this. Either way, my disagreeing with you doesn't mean I hate Windows, don't follow Free Software ideals, or any such thing. It just means I don't agree with you. David From bjorn.mayer at staufen.net Thu May 25 19:20:21 2006 From: bjorn.mayer at staufen.net (=?iso-8859-15?Q?Bj=F6rn_Mayer?=) Date: Thu May 25 19:19:27 2006 Subject: GPGME Problem: Unspecified source: Invalid argument Message-ID: From bjorn.mayer at staufen.net Thu May 25 17:35:05 2006 From: bjorn.mayer at staufen.net (=?iso-8859-15?Q?Bj=F6rn_Mayer?=) Date: Thu May 25 19:26:01 2006 Subject: GPGME, problem in exporting a key Message-ID: Hi folks, I have a problem in exporting a public key within GPGME 1.1.2! The problem is, that everything seems to be correct but it's not working. I would like to export the public key of the key owner named "name". When I enter gpg --export -a "name" everything is handled correct and a public key is displayed. But within gpgme, the export process always fails: (for reasons of a better readability, I only write down the important error handling) --------------------------------------------------------- bool exportPublicKey(string fpr){ gpgme_ctx_t ctx; gpgme_error_t err; if(!startSession(ctx)) // initialize a new context return false; gpgme_data_t out; err = gpgme_data_new (&out); // ok const char *pattern = "name"; gpgme_set_armor(ctx, 1); err = gpgme_op_export(ctx, pattern, 0, out); // seems to be ok int ret = gpgme_data_seek(out, 0, SEEK_SET); if (ret){ cout << ret; err = gpgme_err_code_from_errno (errno); if(err){ // fails cout << "\n --> Exception in function \"exportPublicKey\" << \n " + string(gpgme_strerror (err)) + "\n"; endSession(ctx); return false; } } char buf[BUF_SIZE + 1]; while ((ret = gpgme_data_read (out, buf, BUF_SIZE)) > 0) fwrite (buf, ret, 1, stdout); gpgme_data_release (out); endSession(ctx); return true; } --------------------------------------------------------- The output is always "-1" (value of ret) as well as --> Exception in function "exportKey" Invalid argument I've no idea what the reason is, cause in GPG itself, everything seems to be correct. Does anyone of you guys have an idea? Best regards from Tuebingen/Germany, Bjorn From henkdebruijn at wanadoo.nl Thu May 25 20:17:12 2006 From: henkdebruijn at wanadoo.nl (Henk M. de Bruijn) Date: Thu May 25 21:31:01 2006 Subject: question about compiling gpg with cygwin Message-ID: <1907276329.20060525201712@wanadoo.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I succeeded in compiling 4146 and 4147 with msys. With cygwin however I get at the end op compiling prep.sh: configure: creating ./config.status config.status: creating .infig.status: error: cannot find input file: also after compiling build_gpg.sh: configure: creating ./config.status config.status: creating .infig.status: error: cannot find input file: After installing cygwin I succeeded in compiling 1.4.3. but compiling cvs-builds keep on giving this errormessage. Who can help me out? - -- Henk M. de Bruijn ______________________________________________________________________ The Bat! E-Mail System version 3.80.06 Pro on Windows XP SP2 PGPkey at: http://www.biglumber.com/x/web?qs=0X11EECBEEB464DD0F Gossamer Spider Web of Trust http://www.gswot.org A progressive and innovative Web of Trust -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4-svn-4148-HdB (MingW32) iQEVAwUBRHX0nRHuy+60ZN0PAQgijQf9EcJeAN3NABsWTPE6AqqTVkt795cYRmiP 05fZAv9b+7PsZu/mc42XjTKhZkJbi+0/hMriz4YVIAYreWKHoAlG8fyhb86JsolC FJxh7+TvhA11FNc3YDgxoXffupKLj0UslglyTEPCsyEnasa0UpWbcD+S6dYnHD7h qNri9SLNU6HbcBUjAVjyK5+i6QGG5f3eINA4jNxwuG6HUbkYcYq2+h3y+h1wjx/G /C4be6kIL7KA5VFcq5+0ZsvXmW2RTFzqJtxW/paMrXazxSsGyGBBjwfBiHKz0k84 Y57XvF53/nbyEcGhDCmJURWzvVr/HWY5CfzESKg6BDOwCl/kp4lK3Q== =Nv8r -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Thu May 25 21:50:38 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu May 25 21:49:35 2006 Subject: DSA2 keys Message-ID: <20060525195038.GA29280@jabberwocky.com> Hi folks, I just committed a change to allow generating new-style DSA keys. For those who haven't been following the discussion elsewhere, these are DSA keys that finally break the 1024-bit key size and the 160-bit hash limit. They are part of the new OpenPGP standard. Just like DSA1 keys have a 160-bit hash size hardcoded into them, DSA2 keys have their hash size hardcoded into them. This size cannot be changed once the key is generated. The hash you use when signing with this key must be at least the hash size hardcoded into the key. This means, for example, if you pick a 256-bit hash size, you cannot use SHA-1 at all (as it is only 160 bits). Using hashes that are too large is allowed, but the hash will be truncated to fit. The current key size / hash size lineup is to do 160 bits of hash for a key size of 1024 (same as DSA1), 224 bits of hash for key sizes from 1024 up to 2048, and 256 bits of hash for key sizes from 2048 up to 3072. I know that a number of people here track the latest svn copy of GnuPG, so I have both a request and warning. The request is to try this out and see how it works for you. The warning is to be very careful with using these keys - for today and the at least the near future, there are going to be severe compatibility problems with this. Many people won't even be able to import your DSA2 key (can't verify the self-signature). I know from some testing that PGP 8 and 9 can handle these keys and signatures. GnuPG 1.4.3 can also handle them. Anything else will probably break in various ways. The magic phrase to turn all this on is --enable-dsa2 on the GPG command line. David From ilugo at bridonsecurity.com Fri May 26 00:23:17 2006 From: ilugo at bridonsecurity.com (Israel G. Lugo) Date: Fri May 26 00:22:30 2006 Subject: [patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath In-Reply-To: <20060525142358.GC28955@jabberwocky.com> References: <4473C682.2090808@bridonsecurity.com> <20060524051003.GA17558@jabberwocky.com> <4474D51F.8060106@bridonsecurity.com> <20060524223857.GH18893@jabberwocky.com> <4474F890.8050504@bridonsecurity.com> <20060525035523.GB27463@jabberwocky.com> <4475441C.3080008@bridonsecurity.com> <20060525142358.GC28955@jabberwocky.com> Message-ID: <44762E55.50300@bridonsecurity.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw wrote: > Unless Windows can change environment variables out from under a > running process, I don't see how any of these change in between > passes. Not directly, no - process address space manipulation could happen, but of course then the tmp path would be the least of our worries. All the better then, this makes my solution even simpler to implement. I'm sending attached a revised patch, made against the current CVS version of exec.c. It gets rid of the unnecessary limit and is, I believe you can agree, quite lightweight. ChangeLog entry: 2006-05-25 Israel G. Lugo * exec.c (make_tempdir) [_WIN32]: Modified to properly handle arbitrarily long temporary directory paths. I trust this new patch does not seem "overkill" to you? > Equally as much as the old and tired "Free Software people hate > Windows" thing? I was not implying that as an accusation... I myself dislike Windows quite a lot. If I did assume that you did not like the OS, it was from the impression of dismissivenesses I was left with by your reaction - as noted in my former email. I believe that was already addressed, though? As I said before, I came here with nothing but a constructive purpose in mind; you've already made it clear that you have the same intentions as well so, at least from my part, all is good. > This is the problem. I don't agree with your solution. I don't think > you need multiple passes. Very well, I can agree to that, and it does make good sense as if we start worrying about external manipulation then we have much worse things to worry about than that. Please see the revised patch I am offering in this email. > I do question just how useful it is to allow arbitrarily large temporary > directories when every other piece of directory fetching code for Win32 > has a MAX_PATH limit anyway, but don't really care much either way about > this. Assuming you will agree that the patch I'm proposing this time solves the issue and is also very simple, I think there would be no reason *not* to allow arbitrarily large temporary directories? Regarding other MAX_PATH limitations built in different parts of the code... well, they can be dealt with as well, in their own time. Perhaps some of them could be changed to be more flexible as well. Someone might happen to come across one such piece of code, and offer an acceptable solution. In any case it's an independent matter; in any software program, there will always be areas that could be improved somehow, bugs to be discovered, features to be added. Assuming people are motivated enough to want to contribute, the program will keep evolving. Regards, Israel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEdi5Vgn9msFnMGkcRAi8zAJ96eBU+HgqCk4BgScnoC8q3JFgidgCfawjB fVjjCdeWE7jf3ylBX9Yl8zk= =FuWf -----END PGP SIGNATURE----- -------------- next part -------------- Only in gnupg-tmplen/g10: .exec.c.swp diff -durp gnupg/g10/exec.c gnupg-tmplen/g10/exec.c --- gnupg/g10/exec.c Thu May 25 22:28:08 2006 +++ gnupg-tmplen/g10/exec.c Thu May 25 22:47:22 2006 @@ -129,16 +129,19 @@ static int make_tempdir(struct exec_info if(tmp==NULL) { #if defined (_WIN32) - int err; + /* Poll temp path's length */ + int tmp_siz=GetTempPath(0, NULL); + int len=0; - tmp=xmalloc(MAX_PATH+1); - err=GetTempPath(MAX_PATH+1,tmp); - if(err==0 || err>MAX_PATH+1) - strcpy(tmp,"c:\\windows\\temp"); + if (tmp_siz!=0) + { + tmp=xmalloc(tmp_siz); + len=GetTempPath(tmp_siz,tmp); + } + if(len==0) + tmp=xstrdup("c:\\windows\\temp"); else { - int len=strlen(tmp); - /* GetTempPath may return with \ on the end */ while(len>0 && tmp[len-1]=='\\') { From qed at tiscali.it Fri May 26 12:41:47 2006 From: qed at tiscali.it (Qed) Date: Fri May 26 15:17:59 2006 Subject: DSA2 keys In-Reply-To: <20060525195038.GA29280@jabberwocky.com> References: <20060525195038.GA29280@jabberwocky.com> Message-ID: <4476DB6B.3000804@tiscali.it> On 05/25/2006 09:50 PM, David Shaw wrote: [..snip..] > The current key size / hash size lineup is to do 160 bits of hash for > a key size of 1024 (same as DSA1), 224 bits of hash for key sizes from > 1024 up to 2048, and 256 bits of hash for key sizes from 2048 up to > 3072. [..snip..] Question: full hash size will be enabled on certification signatures too or it will be truncated to 160 bits? > I know that a number of people here track the latest svn copy of > GnuPG, so I have both a request and warning. The request is to try > this out and see how it works for you. The warning is to be very > careful with using these keys - for today and the at least the near > future, there are going to be severe compatibility problems with this. > Many people won't even be able to import your DSA2 key (can't verify > the self-signature). I know from some testing that PGP 8 and 9 can > handle these keys and signatures. GnuPG 1.4.3 can also handle them. > Anything else will probably break in various ways. Any hints on sending a DSA2 key to keyservers? This should be avoided. -- Q.E.D. ICQ UIN: 301825501 OpenPGP key ID: 0x58D14EB3 Key fingerprint: 00B9 3E17 630F F2A7 FF96 DA6B AEE0 EC27 58D1 4EB3 Check fingerprints before trusting a key! From dshaw at jabberwocky.com Fri May 26 16:44:26 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Fri May 26 16:43:27 2006 Subject: DSA2 keys In-Reply-To: <4476DB6B.3000804@tiscali.it> References: <20060525195038.GA29280@jabberwocky.com> <4476DB6B.3000804@tiscali.it> Message-ID: <20060526144426.GA19437@jabberwocky.com> On Fri, May 26, 2006 at 12:41:47PM +0200, Qed wrote: > On 05/25/2006 09:50 PM, David Shaw wrote: > [..snip..] > > The current key size / hash size lineup is to do 160 bits of hash for > > a key size of 1024 (same as DSA1), 224 bits of hash for key sizes from > > 1024 up to 2048, and 256 bits of hash for key sizes from 2048 up to > > 3072. > [..snip..] > Question: full hash size will be enabled on certification signatures too > or it will be truncated to 160 bits? A signature is a signature is a signature. Whatever size hash the key supports, you can use. If you pick a larger hash, it'll be truncated. > > I know that a number of people here track the latest svn copy of > > GnuPG, so I have both a request and warning. The request is to try > > this out and see how it works for you. The warning is to be very > > careful with using these keys - for today and the at least the near > > future, there are going to be severe compatibility problems with this. > > Many people won't even be able to import your DSA2 key (can't verify > > the self-signature). I know from some testing that PGP 8 and 9 can > > handle these keys and signatures. GnuPG 1.4.3 can also handle them. > > Anything else will probably break in various ways. > Any hints on sending a DSA2 key to keyservers? This should be avoided. Keyservers don't validate keys, so this should work fine. Of course, not everyone will be able to download and use the key, but the keyserver shouldn't care either way. David From dshaw at jabberwocky.com Fri May 26 18:13:25 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Fri May 26 18:12:40 2006 Subject: DSA2 compatibility Message-ID: <20060526161325.GC19437@jabberwocky.com> I was not at all clear with my comments about which versions of PGP are compatible with DSA2 keys and signatures. The problem is that DSA2 means several things: 1) A DSA key with a key size > 1024 bits 2) A DSA key with a q size (i.e. hash size) > 160 bits 3) Allowing truncation of a bigger hash to fit into the however many bits the key allows. As far as I can tell at the moment, PGP 8 allows only #3. That is, if you have a regular DSA key (1024 bits, 160-bit hash), you can use a larger hash like SHA-256 with it. Of course, you still only get 160 bits of strength (you just can't fit 256 bits into a 160 bit field). Here's what we have so far: PGP 8.5 (PGP Command Line): Allows truncation, but no other DSA2 abilities. GnuPG 1.4.3: Will verify, but not generate DSA2 keys or signatures. If someone could check PGP 9, I'd appreciate it. David From dshaw at jabberwocky.com Sat May 27 03:44:03 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sat May 27 03:43:09 2006 Subject: [patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath In-Reply-To: <44762E55.50300@bridonsecurity.com> References: <4473C682.2090808@bridonsecurity.com> <20060524051003.GA17558@jabberwocky.com> <4474D51F.8060106@bridonsecurity.com> <20060524223857.GH18893@jabberwocky.com> <4474F890.8050504@bridonsecurity.com> <20060525035523.GB27463@jabberwocky.com> <4475441C.3080008@bridonsecurity.com> <20060525142358.GC28955@jabberwocky.com> <44762E55.50300@bridonsecurity.com> Message-ID: <20060527014403.GA20102@jabberwocky.com> On Thu, May 25, 2006 at 11:23:17PM +0100, Israel G. Lugo wrote: > > This is the problem. I don't agree with your solution. I don't think > > you need multiple passes. > Very well, I can agree to that, and it does make good sense as if we > start worrying about external manipulation then we have much worse > things to worry about than that. Please see the revised patch I am > offering in this email. The patch looks better now, but something about this still bothers me. I still think there is something wrong. Microsoft's own site insists that this is incorrect. Read: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/naming_a_file.asp Regular paths (as opposed to Unicode) are limited to 260 bytes - MAX_PATH. Even with this patch, if the user managed to specify a temporary directory longer than 260 bytes, we still wouldn't be able to write a file into it. GnuPG doesn't use the Unicode functions in Win32. It would be decidedly non-trivial to change over all file handling to use wchar_t everywhere, especially as it would render a lot of code non-portable. David From ilugo at bridonsecurity.com Sat May 27 04:05:56 2006 From: ilugo at bridonsecurity.com (Israel G. Lugo) Date: Sat May 27 04:04:57 2006 Subject: [patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath In-Reply-To: <20060527014403.GA20102@jabberwocky.com> References: <4473C682.2090808@bridonsecurity.com> <20060524051003.GA17558@jabberwocky.com> <4474D51F.8060106@bridonsecurity.com> <20060524223857.GH18893@jabberwocky.com> <4474F890.8050504@bridonsecurity.com> <20060525035523.GB27463@jabberwocky.com> <4475441C.3080008@bridonsecurity.com> <20060525142358.GC28955@jabberwocky.com> <44762E55.50300@bridonsecurity.com> <20060527014403.GA20102@jabberwocky.com> Message-ID: <4477B404.8080603@bridonsecurity.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw wrote: > Regular paths (as opposed to Unicode) are limited to 260 bytes - > MAX_PATH. Even with this patch, if the user managed to specify a > temporary directory longer than 260 bytes, we still wouldn't be > able to write a file into it. > > [...] > > GnuPG doesn't use the Unicode functions in Win32. It would be > decidedly non-trivial to change over all file handling to use > wchar_t everywhere, especially as it would render a lot of code > non-portable. Oh, good point. I hadn't noticed that particular section. This would indeed mean most of the benefits would only really apply if we supported Unicode. There is still the point of introducing the least amount of limitations of our own, all things being equal (so as to be as future-proof as possible). That would be the main reason I would see for applying this patch. However, since no other place in the program would even function with paths larger than 260 bytes, making the change here would be of little consequence. Also, since it is documented that paths are no longer than 260 bytes, GPG would very likely not be the only program in these conditions. The only real benefit I can see, then, would be that using only the required amount of memory to hold the tmp path (e.g. not allocating 260 bytes to possibly hold something as small as "c:\temp"). However, since tmp is being freed shortly after being allocated, that doesn't really make much of a difference either. Well, at least the crash bug is fixed :) Israel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEd7QEgn9msFnMGkcRArsPAKDrNJAdINWWn1r7SQHFA/h9YWoBQQCeMi0Z Hr0lotYZS+UwL3bjibGD5y0= =HFzW -----END PGP SIGNATURE----- From marcus.brinkmann at ruhr-uni-bochum.de Sat May 27 13:30:32 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sat May 27 13:33:37 2006 Subject: [GPGME] gpgme_get_key vs. gpgme_op_keylist_start In-Reply-To: <200605021409.25124.stephan-menzel@web.de> References: <200605021409.25124.stephan-menzel@web.de> Message-ID: <87fyiv3dt3.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 2 May 2006 14:09:24 +0200, Stephan Menzel wrote: > I am about to check S/MIME signatures using GPGME which already works fine. > Now I would like to get further information about a certificate which was used > to sign a key. > > As I understand the manual, the easiest way to get this is: > > gpgme_key_t key; > gpgme_get_key(_ctx, fingerprint, &key, 0) > > However, this gives me always NULL in the key which means as much > as 'fingerprint not found' Mmh. What string do you pass in fingerprint? > When I try this: > > gpgme_op_keylist_start(ctx, 0, 0); > while ((gpgme_op_keylist_next(ctx, &key) != GPG_ERR_EOF) && key) { > fprintf(stderr, "key found:\n"); > fprintf(stderr, "issuer : %s\n", key->issuer_name); > fprintf(stderr, "serial : %s\n", key->issuer_serial); > fprintf(stderr, "chain id : %s\n", key->chain_id); > } > > The key shows up, but I cannot see the fingerprint in this struct gpgme_key_t. > There is only a chain ID which is different from the keys fingerprint. Can you also try the keylist_start with your fingerprint as search pattern? This may at least give you an indication why gpgme_get_key fails. The fingerprint is in key->subkeys->fpr and key->subkeys->keyid. The first subkey is always the primary key (and should always be there). > So what is the difference here? Why does gpgme_get_key not give me the key? > Or am I completely wrong here? I suspect that the search pattern fails. If you look into the code keylist.c::gpgme_get_key, you will see that it is a simple wrapper around keylist_start. Actually, do you use an engine configuration for the context? I am just realizing that the engine configuration is not copied over to the cloned context that gpgme_get_key is using. If you are relying on this feature, please try out the patch below. Thanks, Marcus 2006-05-27 Marcus Brinkmann * keylist.c (gpgme_get_key): Also clone the engine info. Index: keylist.c =================================================================== --- keylist.c (revision 1170) +++ keylist.c (working copy) @@ -939,8 +939,22 @@ err = gpgme_new (&listctx); if (err) return err; - gpgme_set_protocol (listctx, gpgme_get_protocol (ctx)); - gpgme_set_keylist_mode (listctx, ctx->keylist_mode); + { + gpgme_protocol_t proto; + gpgme_engine_info_t info; + + /* Clone the relevant state. */ + proto = gpgme_get_protocol (ctx); + gpgme_set_protocol (listctx, proto); + gpgme_set_keylist_mode (listctx, gpgme_get_keylist_mode (ctx)); + info = gpgme_ctx_get_engine_info (ctx); + while (info && info->protocol != proto) + info = info->next; + if (info) + gpgme_ctx_set_engine_info (listctx, proto, + info->file_name, info->home_dir); + } + err = gpgme_op_keylist_start (listctx, fpr, secret); if (!err) err = gpgme_op_keylist_next (listctx, r_key); From marcus.brinkmann at ruhr-uni-bochum.de Sat May 27 13:41:15 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sat May 27 13:43:31 2006 Subject: High performance GnuPG - Assuan interface to g10? In-Reply-To: <20060520051824.GB18463@curie-int.vc.shawcable.net> References: <20060520051824.GB18463@curie-int.vc.shawcable.net> Message-ID: <87ejyf3db8.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Fri, 19 May 2006 22:18:24 -0700, "Robin H. Johnson" wrote: > I'm trying to get a high performance GnuPG going - using pgme just isn't > cutting it - the repeated execv overhead is killing me. As Werner said, we are aware of the problem, and definitely want the server mode. In addition to what Werner said, we also want to make use of the server mode from GPGME. After that is done, there will only be one execv invocation per context --- sequential operations in the same context will not need to respawn. The basic infrastructure for this is already in place for a long time, at least for GPGSM, and no changes to GPGME applications will be necessary (unless they create a new context for every operation of course :). Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Sat May 27 14:05:48 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sat May 27 14:08:39 2006 Subject: [patch] Fix g10/exec.c (make_tempdir) [_WIN32] not properly handling GetTempPath In-Reply-To: <4474F890.8050504@bridonsecurity.com> References: <4473C682.2090808@bridonsecurity.com> <20060524051003.GA17558@jabberwocky.com> <4474D51F.8060106@bridonsecurity.com> <20060524223857.GH18893@jabberwocky.com> <4474F890.8050504@bridonsecurity.com> Message-ID: <87d5dz3c6b.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Thu, 25 May 2006 01:21:36 +0100, "Israel G. Lugo" wrote: > > Give me a number and I'll raise the size, but layers of fallbacks > > strikes me as unnecessary complication in a relatively unimportant > > place in the code. > Why have a number at all? The solution I had proposed would have dealt > with any size in an efficient manner, without wasting memory > allocating 1,000,000 bytes "just to be sure" or failing because "42 is > more than enough for anyone". This is a bit beside the point, but I feel qualified to comment on this, due to my experience with OS design, in particular the GNU/Hurd, which does not define PATH_MAX or other constants like that. The discussion is actually quite involved. However, there are a couple of notes that can be easily seen: First, no operating system can allow arbitrary long string transfers in a single operation, be it a kernel system call or an IPC string transfer between two user space programs. The reason is that it is a good idea to arrange everything so that all kernel operations are bounded in time, and the bound should be reasonably small (ie, not scale with the amount of available memory, which in a persistent system may be as much as the total disk memory available, ie Terabytes). Although in theory you can build protocols where a string is transfered piece-wise in more than one operation, the same argument as above prevents us from using such protocols in the kernels or servers that provide services to potentially non-cooperating clients. This effectively limits at least the size of NAME_MAX, which is a pathname component. Even in Unixes with a fixed PATH_MAX you can make use of longer path names by repeatedly "cd'ing" into directories. This is an idiosyncratic inconsistency that can lead to subtle problems all over the place. You know have nameable resources whose complete names are invalid. This should make us suspicious about the wisdom in such a feature. From the perspective of an application, if you want to allow arbitrary long pathnames or not is a question that has no universal answer. It depends, for example, on which agent provides the name to which other agent, and what the relationship between these agents is. Just as a trivial example, you do not want to accept arbitrary long pathnames in the query interface of an HTTP server on a public network. Similar situations can arise locally. I have supported arbitrary long path names in the past, but in the light of that experience and the above analysis I am somewhat backing off. In the presence of always unbounded sizes, you lose some of the ability to reason about the dynamic properties of the system. On the other hand, in support of your argument, _arbitrary_ limits on pathnames are bound to cause spurious failures as well. Any real system will impose some sort of limits of some sort, at various levels (storage, communication, application), which may be dynamic. So, I think that in the end, the choice between fixed constant size and unbounded size is incomplete: The right answer is in the middle: A bounded size which is dynamically determined. This however requires more theory on operation than we have to our support in existing legacy operating systems, so a compromise is necessary. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Sat May 27 14:16:37 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sat May 27 14:18:39 2006 Subject: GPGME, problem in exporting a key In-Reply-To: References: Message-ID: <87bqtj3boa.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Thu, 25 May 2006 17:35:05 +0200, Bj?rn Mayer wrote: > I have a problem in exporting a public key within GPGME 1.1.2! > The problem is, that everything seems to be correct but it's not > working. I would like to export the public key of the key owner > named "name". When I enter > gpg --export -a "name" > > everything is handled correct and a public key is displayed. But > within gpgme, the export process always fails: > > (for reasons of a better readability, I only write down the > important error handling) Most likely you did not compile your program with a 64 bit off_t type. See also http://www.gnupg.org/(en)/faq/gpgme-faq.html and section 2.3 Largefile support of the GPGME Reference Manual. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Sat May 27 14:17:08 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sat May 27 14:18:57 2006 Subject: GPGME Problem: Unspecified source: Invalid argument In-Reply-To: References: Message-ID: <87ac933bnf.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Fri, 19 May 2006 22:05:29 +0000 (UTC), Mike Winter wrote: > > Hi, I get the above error when trying to do a seek on a cleartext gpgme_data_t > variable after a gpgme_op_verify() operation. Does anyone have any ideas? > Thanks for any help. Most likely you did not compile your program with a 64 bit off_t type. See also http://www.gnupg.org/(en)/faq/gpgme-faq.html and section 2.3 Largefile support of the GPGME Reference Manual. Thanks, Marcus From henkdebruijn at wanadoo.nl Sat May 27 20:07:03 2006 From: henkdebruijn at wanadoo.nl (Henk M. de Bruijn) Date: Sat May 27 20:05:58 2006 Subject: MSYS and Cygwin Message-ID: <1371892336.20060527200703@wanadoo.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi all, I keep on having problems compiling SVN builds with Cygwin. After installing I manage to compile the official release (1.4.3) but after trying to build a SVN version I keep in having this error: configure: creating ./config.status config.status: creating .infig.status: error: cannot find input file: I am running Windows XP SP2 on a Pentium 4 computer. Compiling with MSYS works like a charm! It would be a pity if I have to uninstall Cygwin :-( - -- Henk M. de Bruijn ______________________________________________________________________ The Bat! E-Mail System version 3.80.06 Pro on Windows XP SP2 PGPkey at: http://www.biglumber.com/x/web?qs=0X11EECBEEB464DD0F Gossamer Spider Web of Trust http://www.gswot.org A progressive and innovative Web of Trust -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4-svn-4151-HdB-MSYS (MSYS/MingW32) iQEVAwUBRHiVJxHuy+60ZN0PAQiJgAgAn5rsDkGhCnmCbwOOYgSKmIyQ9BgJx9WQ 44hdStG6QduiyDAq/bz4TlidxwbemXkEL466bhJM9RrTq/PZi2iAeWehie96HNrI VJPd92g3Jc2ZapoSCarF201z+T+KK3e4rfI1GkckuaZCuKu6VM+8Sx6bu/lfh1j2 dgUin7cgrjNIdzX9L9GPZHpAIChYwmsvZ59L2wo4TQWZEBEb7/nGRVeHQ8eOWc3w HnSTdUvFLfuK76+hmbDUYSszQiGXfC+pplIwoEDQ8z258Vq+e8EcxBR0MQ4LHzIk H8DNO6GcsTLbcyq5YNGJxEre9gc1z5vvtNBEYe1NcRmkvk9kvOaIJg== =rnaX -----END PGP SIGNATURE----- From henkdebruijn at wanadoo.nl Sun May 28 12:25:38 2006 From: henkdebruijn at wanadoo.nl (Henk M. de Bruijn) Date: Sun May 28 12:24:25 2006 Subject: MSYS and Cygwin In-Reply-To: <1371892336.20060527200703@wanadoo.nl> References: <1371892336.20060527200703@wanadoo.nl> Message-ID: <1757078962.20060528122538@wanadoo.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, 27 May 2006 20:07:03 +0200GMT (27-5-2006, 20:07 +0200, where I live), Henk M. de Bruijn wrote: > I keep on having problems compiling SVN builds with Cygwin. > After installing I manage to compile the official release (1.4.3) but > after trying to build a SVN version I keep in having this error: > configure: creating ./config.status > config.status: creating > .infig.status: error: cannot find input file: My notepad2 was on Windows instead of Unix, sorry! - -- Henk M. de Bruijn ______________________________________________________________________ The Bat! E-Mail System version 3.80.06 Pro on Windows XP SP2 PGPkey at: http://www.biglumber.com/x/web?qs=0X11EECBEEB464DD0F Gossamer Spider Web of Trust http://www.gswot.org A progressive and innovative Web of Trust -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4-svn-4149-HdB (Cygwin/MingW32) iQEVAwUBRHl6mhHuy+60ZN0PAQj6TQf/foAJ92zSq5TeOq/2JcKMK8m95B573qNV 2nB2rp2bXy/kHxJHtVspqMPgvbR+SvOjE/XIE345arhpWaEXaoSpdQkihzmfhT6K DESbVoN7BOrBwdyED1BnGN4RkCL90NYwX4DqYLABP1gpoACk/Cgdk348zyZ4QCov SJr1f9GnCvWYylXtVJhUvPn8mUlJT3F5euMdExOhxQdnG19dSkbfIpUfXLJbz342 JjhYSLGv4PaUovv8g1wgH1KaafOu8W1gkoUEZqXlariiP+BXxMQT6C4Kzk28nix0 C/IodcbPKq6bOHRCStf7umyPxBnZ1RASFVlo2wyZJKPgjz/7ffPzkQ== =3s0I -----END PGP SIGNATURE-----