From marcus.brinkmann at ruhr-uni-bochum.de Fri Jun 1 15:17:14 2007 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri, 01 Jun 2007 15:17:14 +0200 Subject: pinentry patches In-Reply-To: <20070525152415.GB5895@acer.localdomain> References: <20070525152415.GB5895@acer.localdomain> Message-ID: <877iqnhl0l.wl%marcus.brinkmann@ruhr-uni-bochum.de> Hi Peter, At Fri, 25 May 2007 10:24:15 -0500, "Peter O'Gorman" wrote: > We built pinentry-0.7.2, it required getopt (which required gettext > and iconv), so we added gnulib getopt. Let's walk through all the changes individually. I need your support for all but one of them to make sane decisions. You certainly mean getopt_long (which is a GNU extension), not getopt (which is POSIX). Is it correct that your platform doesn't have a GNU'ish getopt_long (BSD for example has a compatible replacement). > The IRIX compiler, for some reason, did not like this: > { "version", no_argument, &opt_version, 1 } > so, we changed it. What's the reason? getopt_long is a GNU extension, so if IRIX'es getopt_long does not comply with GNU's getopt_long, there is a bug in it. struct option is specified as taking an int * and an int as third and fourth member, and opt_version is an int. What's the compiler complaining about? How is struct option defined on IRIX? > Most compilers don't understand '\e', so replaced with its hex > equivalent. Ok. > Now for the big problem though. > In the normal situation when running pinentry it does not have a > terminal, so it does fopen(tty_name,"r") etc to get a terminal to ask > for the passphrase on. On hpux and tru64 ncurses is unable to properly > initialize this device, Why? > it remains in line buffered mode and echoes > the passphrase as it is typed, changing it to *** after the user > presses return. It also does not change the keymappings, so I had to > case '\r': > case '\n': > so the user could get out of the dialog. We "fixed" the echo to the > screen issue using tcsetattr, but I hope that there is some more > knowledgeable person here who knows a proper fix. With this "fix" the > device stays in line buffered mode, but does not echo the chars as > they are typed. It does still change them to '***' after the user > presses . The ncurses' library initscr() does just call newterm() on stdin and stdout. It's hard to imagine a reason why calling newterm() manually on appropriate file descriptors would fail to do the proper job. This requires more debugging. Maybe you could try to disable colors, or move start_colors() before noecho(), in case this trips things up. That's just a wild guess of course. There may be other things that are subtly different. Maybe the tty_type is given wrongly? Thanks, Marcus From benjamin at py-soft.co.uk Sun Jun 3 13:43:38 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sun, 03 Jun 2007 12:43:38 +0100 Subject: eccGnuPG In-Reply-To: <87mz25mef5.fsf@wheatstone.g10code.de> References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> <87tzweqxlm.fsf@wheatstone.g10code.de> <87mz25mef5.fsf@wheatstone.g10code.de> Message-ID: <4662A96A.6060408@py-soft.co.uk> Werner Koch wrote: > The Libgcrypt SVN now has experimental support for ECDSA. It is still > not finished and we need to do something about the performance: Does this mean that a suitable version of gpg2 would work with an OpenPGP smartcard with ECC support? I'm curious as ECC would be better on a card without hardware acceleration than RSA. Take care, Ben From benjamin at py-soft.co.uk Sun Jun 3 13:35:46 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sun, 03 Jun 2007 12:35:46 +0100 Subject: Pam Poldi development status In-Reply-To: <20070515112304.GA4053@piraos.com> References: <20070515112304.GA4053@piraos.com> Message-ID: <4662A792.3000205@py-soft.co.uk> German Gomez Garcia wrote: > I would like to know what is the current status of development for > pam_poldi, latest version is from December 2005 Might be worth contacting the author direct; Moritz Schulte > I would like to know if there is an ongoing effort to make it use > scdaemon when available so it can coexist with gpg-agent for sudoing, > xscreensaver, etc. Perhaps something the community should take on? Ben From wk at gnupg.org Sun Jun 3 19:42:51 2007 From: wk at gnupg.org (Werner Koch) Date: Sun, 03 Jun 2007 19:42:51 +0200 Subject: eccGnuPG In-Reply-To: <4662A96A.6060408@py-soft.co.uk> (Benjamin Donnachie's message of "Sun, 03 Jun 2007 12:43:38 +0100") References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> <87tzweqxlm.fsf@wheatstone.g10code.de> <87mz25mef5.fsf@wheatstone.g10code.de> <4662A96A.6060408@py-soft.co.uk> Message-ID: <873b19rl2c.fsf@wheatstone.g10code.de> On Sun, 3 Jun 2007 13:43, benjamin at py-soft.co.uk said: > Does this mean that a suitable version of gpg2 would work with an > OpenPGP smartcard with ECC support? No. OpenPGP does not specify any ECC algorithm. Shalom-Salam, Werner From benjamin at py-soft.co.uk Sun Jun 3 20:39:12 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sun, 03 Jun 2007 19:39:12 +0100 Subject: eccGnuPG In-Reply-To: <873b19rl2c.fsf@wheatstone.g10code.de> References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> <87tzweqxlm.fsf@wheatstone.g10code.de> <87mz25mef5.fsf@wheatstone.g10code.de> <4662A96A.6060408@py-soft.co.uk> <873b19rl2c.fsf@wheatstone.g10code.de> Message-ID: <46630AD0.5070509@py-soft.co.uk> Werner Koch wrote: > No. OpenPGP does not specify any ECC algorithm. Are there any plans to expand the OpenPGP spec to include it? Take care, Ben From jan-oliver.wagner at intevation.de Sun Jun 3 21:00:46 2007 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Sun, 3 Jun 2007 21:00:46 +0200 Subject: Missing announcement for 1.1.0? In-Reply-To: <200706032055.58182.jan-oliver.wagner@intevation.de> References: <200706032055.58182.jan-oliver.wagner@intevation.de> Message-ID: <200706032100.47928.jan-oliver.wagner@intevation.de> Sorry, this was meant to go to gpg4win-devel. On Sunday 03 June 2007 20:55, Jan-Oliver Wagner wrote: > Hello Werner, > > I haven't seen yet a announcement for 1.1.0. > > Has it gone lost or have you simply forgotten to send it? > > Best > > Jan -- Dr. Jan-Oliver Wagner Intevation GmbH Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jan-oliver.wagner at intevation.de Sun Jun 3 20:55:53 2007 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Sun, 3 Jun 2007 20:55:53 +0200 Subject: Missing announcement for 1.1.0? Message-ID: <200706032055.58182.jan-oliver.wagner@intevation.de> Hello Werner, I haven't seen yet a announcement for 1.1.0. Has it gone lost or have you simply forgotten to send it? Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From wk at gnupg.org Mon Jun 4 10:44:29 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Jun 2007 10:44:29 +0200 Subject: eccGnuPG In-Reply-To: <46630AD0.5070509@py-soft.co.uk> (Benjamin Donnachie's message of "Sun, 03 Jun 2007 19:39:12 +0100") References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> <87tzweqxlm.fsf@wheatstone.g10code.de> <87mz25mef5.fsf@wheatstone.g10code.de> <4662A96A.6060408@py-soft.co.uk> <873b19rl2c.fsf@wheatstone.g10code.de> <46630AD0.5070509@py-soft.co.uk> Message-ID: <87d50cxg5u.fsf@wheatstone.g10code.de> On Sun, 3 Jun 2007 20:39, benjamin at py-soft.co.uk said: > Are there any plans to expand the OpenPGP spec to include it? The WG is still waiting to get rfc2440bis published. No need for new plans before we have managed to get the new RFC through. Salam-Shalom, Werner From benjamin at py-soft.co.uk Mon Jun 4 11:53:35 2007 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Mon, 04 Jun 2007 10:53:35 +0100 Subject: eccGnuPG In-Reply-To: <87d50cxg5u.fsf@wheatstone.g10code.de> References: <200702082205.48034.sbt@megacceso.com> <200703211050.30253.sbt@megacceso.com> <87tzwerdqt.fsf@mocca.josefsson.org> <200703211734.43244.sbt@megacceso.com> <87tzweqxlm.fsf@wheatstone.g10code.de> <87mz25mef5.fsf@wheatstone.g10code.de> <4662A96A.6060408@py-soft.co.uk> <873b19rl2c.fsf@wheatstone.g10code.de> <46630AD0.5070509@py-soft.co.uk> <87d50cxg5u.fsf@wheatstone.g10code.de> Message-ID: <4663E11F.2010009@py-soft.co.uk> Werner Koch wrote: >> Are there any plans to expand the OpenPGP spec to include it? > The WG is still waiting to get rfc2440bis published. No need for new > plans before we have managed to get the new RFC through. Fair point! I was never very good at being patient... :-) Take care, Ben From wk at gnupg.org Mon Jun 4 20:02:07 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 04 Jun 2007 20:02:07 +0200 Subject: Pam Poldi development status In-Reply-To: <20070515112304.GA4053@piraos.com> (German Gomez Garcia's message of "Tue, 15 May 2007 13:23:04 +0200") References: <20070515112304.GA4053@piraos.com> Message-ID: <87r6ortx7k.fsf@wheatstone.g10code.de> On Tue, 15 May 2007 13:23, german at piraos.com said: > I would like to know what is the current status of development for > pam_poldi, latest version is from December 2005, I would like to know if > there is an ongoing effort to make it use scdaemon when available so it > can coexist with gpg-agent for sudoing, xscreensaver, etc. Moritz is a currently a bit busy with others things and thus there is not much progress. However, he is working on it with the goal to make it usable with scdaemon et al. Another goal is to allow the use of an existing X.509 infrastructure. Moritz, are there areas where you would like to get some help? Salam-Shalom, Werner From ahaas at airmail.net Fri Jun 8 15:46:21 2007 From: ahaas at airmail.net (Art Haas) Date: Fri, 8 Jun 2007 08:46:21 -0500 Subject: [PATCH] Add missing space in g10/Makefile.am Message-ID: <20070608134621.GH3820@artsapartment.org> Hi. This tiny patch adds a missing space between the library dependencies. Without it the dependency looks like '-lgcrypt-lassuan'. Art Haas Index: g10/Makefile.am =================================================================== --- g10/Makefile.am (revision 4508) +++ g10/Makefile.am (working copy) @@ -119,7 +119,7 @@ LDADD = $(needed_libs) ../common/libgpgrl.a \ $(ZLIBS) $(DNSLIBS) $(LIBREADLINE) \ $(LIBINTL) $(CAPLIBS) $(NETLIBS) -gpg2_LDADD = $(LDADD) $(LIBGCRYPT_LIBS)$(LIBASSUAN_LIBS) $(GPG_ERROR_LIBS) \ +gpg2_LDADD = $(LDADD) $(LIBGCRYPT_LIBS) $(LIBASSUAN_LIBS) $(GPG_ERROR_LIBS) \ $(LIBICONV) gpgv2_LDADD = $(LDADD) $(LIBGCRYPT_LIBS) $(LIBASSUAN_LIBS) $(GPG_ERROR_LIBS) \ $(LIBICONV) -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From wk at g10code.com Fri Jun 8 19:39:23 2007 From: wk at g10code.com (Werner Koch) Date: Fri, 08 Jun 2007 19:39:23 +0200 Subject: [PATCH] Add missing space in g10/Makefile.am In-Reply-To: <20070608134621.GH3820@artsapartment.org> (Art Haas's message of "Fri, 8 Jun 2007 08:46:21 -0500") References: <20070608134621.GH3820@artsapartment.org> Message-ID: <87ps462vn8.fsf@wheatstone.g10code.de> On Fri, 8 Jun 2007 15:46, ahaas at airmail.net said: > This tiny patch adds a missing space between the library dependencies. > Without it the dependency looks like '-lgcrypt-lassuan'. Ah right, I accidently introduced that but was to tired to fix that when I commited that bunch of Windows changes. Thanks, Werner -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 From freebsd-listen at fabiankeil.de Sun Jun 10 19:00:22 2007 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Sun, 10 Jun 2007 19:00:22 +0200 Subject: time zone problems with util/timegm.c on mingw32 Message-ID: <20070610190022.1fa3f24b@localhost> A while ago I needed a fallback timegm() version for Privoxy and chose the one from gnupg 1.x's util/timegm.c because it appeared to be working on mingw32 and the license was compatible. Apparently I didn't test it properly, because I just noticed that it causes time zone problems if getenv("TZ") is NULL. On my Windows test system this (now) seems to be the case. As a result the first timegm() call changes the time zone settings (for me it causes a 2h offset for localtime() called later on) while the next timegm() call fixes the problem again. The timegm() call after that restarts the cycle ... This, and a minor memory leak, can be fixed (on my mingw32 test system) with: --- util/timegm.c Wed Jul 27 19:02:56 2005 +++ util/timegm.c.patched Sun Jun 10 18:52:30 2007 @@ -54,13 +54,14 @@ strcpy(old_zone,"TZ="); strcat(old_zone,zone); putenv(old_zone); + free(old_zone); } } else #ifdef HAVE_UNSETENV unsetenv("TZ"); #else - putenv("TZ"); + putenv("TZ="); #endif tzset(); This is just FYI, I didn't check if it matters for gnupg or if mingw32 is even supported. I'm interested to know though, if you are aware of any platforms which have neither timegm() nor unsetenv(), but support putenv("TZ") to unset TZ, but not putenv("TZ=")? Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20070610/46441e21/attachment.pgp From dshaw at jabberwocky.com Mon Jun 11 01:42:38 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 10 Jun 2007 19:42:38 -0400 Subject: time zone problems with util/timegm.c on mingw32 In-Reply-To: <20070610190022.1fa3f24b@localhost> References: <20070610190022.1fa3f24b@localhost> Message-ID: <20070610234238.GA3681@jabberwocky.com> On Sun, Jun 10, 2007 at 07:00:22PM +0200, Fabian Keil wrote: > A while ago I needed a fallback timegm() version > for Privoxy and chose the one from gnupg 1.x's > util/timegm.c because it appeared to be working > on mingw32 and the license was compatible. > > Apparently I didn't test it properly, because I > just noticed that it causes time zone problems > if getenv("TZ") is NULL. On my Windows test system > this (now) seems to be the case. > > As a result the first timegm() call changes the time > zone settings (for me it causes a 2h offset for > localtime() called later on) while the next timegm() > call fixes the problem again. The timegm() call after > that restarts the cycle ... > > This, and a minor memory leak, can be fixed > (on my mingw32 test system) with: > > --- util/timegm.c Wed Jul 27 19:02:56 2005 > +++ util/timegm.c.patched Sun Jun 10 18:52:30 2007 > @@ -54,13 +54,14 @@ > strcpy(old_zone,"TZ="); > strcat(old_zone,zone); > putenv(old_zone); > + free(old_zone); That's intentional, and not a leak. putenv() is supposed to insert its argument directly into the environment. If you free that argument, you corrupt the environment when (eventually) something else uses that memory. There are some nonstandard putenv()s that make a copy like setenv() does, but the trick is knowing which you have - it is safest to assume that your putenv() follows the standard. > #ifdef HAVE_UNSETENV > unsetenv("TZ"); > #else > - putenv("TZ"); > + putenv("TZ="); > #endif This is mingw-specific (and wrong, as "TZ=" should insert an empty string, and not remove TZ from the environment). Most platforms use "TZ" (without the = sign) to remove something from the environment. Even that, however, is non-standard behavior, which is why we try to use unsetenv() when possible. Arguably for the most standards-based code in GnuPG (though probably not your usage), if unsetenv isn't available, we should just give up and leak the memory. Doing environment work without leaking memory is difficult on some platforms. Doing it portably across many platforms is nearly impossible. David From freebsd-listen at fabiankeil.de Mon Jun 11 19:52:17 2007 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Mon, 11 Jun 2007 19:52:17 +0200 Subject: time zone problems with util/timegm.c on mingw32 In-Reply-To: <20070610234238.GA3681@jabberwocky.com> References: <20070610190022.1fa3f24b@localhost> <20070610234238.GA3681@jabberwocky.com> Message-ID: <20070611195217.5b1a2534@localhost> David Shaw wrote: > On Sun, Jun 10, 2007 at 07:00:22PM +0200, Fabian Keil wrote: > > A while ago I needed a fallback timegm() version > > for Privoxy and chose the one from gnupg 1.x's > > util/timegm.c because it appeared to be working > > on mingw32 and the license was compatible. > > > > Apparently I didn't test it properly, because I > > just noticed that it causes time zone problems > > if getenv("TZ") is NULL. On my Windows test system > > this (now) seems to be the case. > > > > As a result the first timegm() call changes the time > > zone settings (for me it causes a 2h offset for > > localtime() called later on) while the next timegm() > > call fixes the problem again. The timegm() call after > > that restarts the cycle ... > > > > This, and a minor memory leak, can be fixed > > (on my mingw32 test system) with: > > > > --- util/timegm.c Wed Jul 27 19:02:56 2005 > > +++ util/timegm.c.patched Sun Jun 10 18:52:30 2007 > > @@ -54,13 +54,14 @@ > > strcpy(old_zone,"TZ="); > > strcat(old_zone,zone); > > putenv(old_zone); > > + free(old_zone); > > That's intentional, and not a leak. putenv() is supposed to insert > its argument directly into the environment. If you free that > argument, you corrupt the environment when (eventually) something else > uses that memory. There are some nonstandard putenv()s that make a > copy like setenv() does, but the trick is knowing which you have - it > is safest to assume that your putenv() follows the standard. > > > #ifdef HAVE_UNSETENV > > unsetenv("TZ"); > > #else > > - putenv("TZ"); > > + putenv("TZ="); > > #endif > > This is mingw-specific (and wrong, as "TZ=" should insert an empty > string, and not remove TZ from the environment). Most platforms use > "TZ" (without the = sign) to remove something from the environment. I guess I'll better #ifdef both cases for mingw32 then. > Even that, however, is non-standard behavior, which is why we try to > use unsetenv() when possible. Arguably for the most standards-based > code in GnuPG (though probably not your usage), if unsetenv isn't > available, we should just give up and leak the memory. I think the main point of unsetting TZ there is to make sure timegm() calls don't have side effects for other time functions called later on. Without the last putenv() call to unset TZ, timegm() would permanently set the time zone to UTC if TZ wasn't already set to something at the beginning (because the last tzset() call wouldn't restore the original time zone). A few leaked bytes per call are hard to notice, but if localtime() gets an offset, things get interesting ... Thanks a lot for your detailed response, David. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: not available Url : /pipermail/attachments/20070611/c60dec9d/attachment.pgp From dshaw at jabberwocky.com Mon Jun 11 20:00:01 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 11 Jun 2007 14:00:01 -0400 Subject: time zone problems with util/timegm.c on mingw32 In-Reply-To: <20070611195217.5b1a2534@localhost> References: <20070610190022.1fa3f24b@localhost> <20070610234238.GA3681@jabberwocky.com> <20070611195217.5b1a2534@localhost> Message-ID: <20070611180001.GC9020@jabberwocky.com> On Mon, Jun 11, 2007 at 07:52:17PM +0200, Fabian Keil wrote: > > Even that, however, is non-standard behavior, which is why we try to > > use unsetenv() when possible. Arguably for the most standards-based > > code in GnuPG (though probably not your usage), if unsetenv isn't > > available, we should just give up and leak the memory. > > I think the main point of unsetting TZ there is to make sure > timegm() calls don't have side effects for other time functions > called later on. Sure, that's why I say it probably doesn't apply to your usage. In GnuPG, timegm is only used in a single place (when accessing a LDAP keyserver), so it is harmless in GnuPG to not restore TZ for both the time and leak reasons. The gpgkeys_ldap process just doesn't last that long. David From jmoore3rd at bellsouth.net Thu Jun 14 20:25:50 2007 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Thu, 14 Jun 2007 14:25:50 -0400 Subject: Compiling svn4511 Message-ID: <4671882E.6030603@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Naturally, I had to give the 'Experimental' SVN 4511 a Go. I appropriately Modified: cipher\makefile.am cipher\algorithms.h include\cipher.h configure.ac Everything Compiled 'Normally' with the exception that nowhere is Camellia ever mentioned. I am attaching both the configure.ac File used as well as the Results of the Checks/Tests. I would appreciate any guidance in an Error on My part. TIA JOHN :-\ Timestamp: Thursday 14 Jun 2007, 14:24 --400 (Eastern Daylight Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8-svn4510: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: My Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJGcYgrAAoJEBCGy9eAtCsPWIIH/RYLpkBm9xLAP040NbmacWDI g8Xnb54CXlbllsNO+rrY1D9453T3w/NI0R7y51mGBbPxAaTGkV+KfN5Fi0w8ogCq we8mBRh/SBM2yYVxI58Y0cX/nw0TqTEzmldFlJlFK5fug+L5tub1b7pw6S3bqHoV nzEe+36wj8kq1d5TH132c8ysDy1T/ZNWkzPX5AZgnLMsotAtH3ZwTuBiQPTJR27D vo4MtzKNlLpuFn2/mv/Lrh9gULdVIN4kmzegH0rk2Kwd8TkgXgBNotg7b0XLtsrh fcxjxbto6iFLbXtCtoxycckkTuYl8+rw3GBJNd3f/EYVvLu2t3v+1hb6+jJ+LWg= =lbix -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 4511 Compile Results.txt Url: /pipermail/attachments/20070614/d67f7c50/attachment-0001.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: configure.ac Url: /pipermail/attachments/20070614/d67f7c50/attachment-0001.asc From dshaw at jabberwocky.com Fri Jun 15 00:42:24 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 14 Jun 2007 18:42:24 -0400 Subject: Compiling svn4511 In-Reply-To: <4671882E.6030603@bellsouth.net> References: <4671882E.6030603@bellsouth.net> Message-ID: <20070614224224.GB27651@jabberwocky.com> On Thu, Jun 14, 2007 at 02:25:50PM -0400, John W. Moore III wrote: > Naturally, I had to give the 'Experimental' SVN 4511 a Go. I > appropriately Modified: > > cipher\makefile.am > cipher\algorithms.h > include\cipher.h > configure.ac > > Everything Compiled 'Normally' with the exception that nowhere is > Camellia ever mentioned. I am attaching both the configure.ac File used > as well as the Results of the Checks/Tests. I would appreciate any > guidance in an Error on My part. Camellia is not for general use yet, and is disabled. Do not enable it. David From JPClizbe at tx.rr.com Fri Jun 15 03:05:17 2007 From: JPClizbe at tx.rr.com (John Clizbe) Date: Thu, 14 Jun 2007 20:05:17 -0500 Subject: Compiling svn4511 In-Reply-To: <4671882E.6030603@bellsouth.net> References: <4671882E.6030603@bellsouth.net> Message-ID: <4671E5CD.7000609@tx.rr.com> John W. Moore III wrote: > Naturally, I had to give the 'Experimental' SVN 4511 a Go. I > appropriately Modified: > > cipher\makefile.am > cipher\algorithms.h > include\cipher.h > configure.ac > > Everything Compiled 'Normally' with the exception that nowhere is > Camellia ever mentioned. I am attaching both the configure.ac File used > as well as the Results of the Checks/Tests. I would appreciate any > guidance in an Error on My part. Dunno. Except for some warning messages about underquoted definitions during autogen.sh under MSYS and Cygwin I hadn't seen before, both built just fine. Cygwin Running aclocal -I m4 ... /usr/share/aclocal/libsmi.m4:8: warning: underquoted definition of AM_PATH_LIBSMI /usr/share/aclocal/libsmi.m4:8: run info '(automake)Extending aclocal' /usr/share/aclocal/libsmi.m4:8: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal Running autoheader... Running automake --gnu --add-missing... doc/Makefile.am:80: `%'-style pattern rules are a GNU make extension keyserver/Makefile.am:34: compiling `gpgkeys_curl.c' with per-target flags requires `AM_PROG_CC_C_O' in `configure.ac' Running autoconf... You may now run "./configure --enable-maintainer-mode && make". MSYS $ scripts/autogen.sh Running aclocal -I m4 ... /usr/share/aclocal/autoopts.m4:22: warning: underquoted definition of AG_PATH_AUTOOPTS run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal Running autoheader... Running automake --gnu --add-missing... Running autoconf... You may now run "./configure --enable-maintainer-mode && make". Let me know if you need version info on those tools. Oh, BTW... the new algo built for both and passed all tests. -- John P. Clizbe Inet: JPClizbe(a) tx DAWT rr DAHT con Ginger 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/20070614/e8efd136/attachment.pgp From dshaw at jabberwocky.com Sun Jun 17 00:02:52 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 16 Jun 2007 18:02:52 -0400 Subject: Camellia Message-ID: <20070616220252.GA4705@jabberwocky.com> Some people have noticed that I recently committed support for the Camellia cipher in GnuPG. Here's the story behind that. Camellia is not currently part of OpenPGP, and will also not be part of the upcoming "2440bis" updating of RFC-2440. It has been proposed, however, that right after 2440bis is published, the OpenPGP Working Group take the necessary steps to add Camellia. To simplify interoperability testing between different OpenPGP implementations, I've added Camellia to GnuPG. Naturally, it is disabled by default and the only people who should really enable it are those doing interoperability work. While it is impossible for me to stop people from enabling and using it, be warned of a few things: first, Camellia isn't part of OpenPGP yet, and if for whatever reason it doesn't become part of OpenPGP, you won't be able to decrypt anything you've encrypted with Camellia. Similarly, as Camellia has not been assigned an OpenPGP cipher number, I've picked 11 (the next unassigned number). If Camellia gets approved with a different number, you won't be able to decrypt anything you've encrypted with this version of Camellia. Finally, if there is some error in the current GnuPG usage of Camellia that we later fix, you again won't be able to decrypt. I'm not going to go into whether Camellia is considered strong or not, as it's not really relevant to this discussion: even if Camellia was the strongest cipher in the world, you should still not enable it for the reasons given above. Rest assured that if/when Camellia is approved (or even on a reasonable track to approval), it will be enabled for general use. David From s-beyer at gmx.net Sun Jun 17 00:17:03 2007 From: s-beyer at gmx.net (Stephan Beyer) Date: Sun, 17 Jun 2007 00:17:03 +0200 Subject: Camellia In-Reply-To: <20070616220252.GA4705@jabberwocky.com> References: <20070616220252.GA4705@jabberwocky.com> Message-ID: <20070616221703.GA4444@leksak.p-netz> Hi, > Similarly, as Camellia has not been assigned an OpenPGP cipher number, > I've picked 11 (the next unassigned number). OpenPGP specifies numbers 100,...,110 as "private/experimental algorithm". [see 2440bis-22, section 9.2] Shouldn't that be used until Camellia is approved? Best Regards, Stephan Beyer -- Stephan Beyer , PGP 0x6EDDD207FCC5040F -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20070617/0681840e/attachment.pgp From dshaw at jabberwocky.com Sun Jun 17 04:40:17 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 16 Jun 2007 22:40:17 -0400 Subject: Camellia In-Reply-To: <20070616221703.GA4444@leksak.p-netz> References: <20070616220252.GA4705@jabberwocky.com> <20070616221703.GA4444@leksak.p-netz> Message-ID: <20070617024017.GA31743@jabberwocky.com> On Sun, Jun 17, 2007 at 12:17:03AM +0200, Stephan Beyer wrote: > Hi, > > > Similarly, as Camellia has not been assigned an OpenPGP cipher number, > > I've picked 11 (the next unassigned number). > > OpenPGP specifies numbers 100,...,110 as "private/experimental > algorithm". [see 2440bis-22, section 9.2] > Shouldn't that be used until Camellia is approved? No. To properly test interoperability, 11 is the presumed algorithm number. David From malayter at gmail.com Mon Jun 18 18:55:04 2007 From: malayter at gmail.com (Ryan Malayter) Date: Mon, 18 Jun 2007 11:55:04 -0500 Subject: Camellia In-Reply-To: <20070616220252.GA4705@jabberwocky.com> References: <20070616220252.GA4705@jabberwocky.com> Message-ID: <5d7f07420706180955w25a110celc89f8699d28050cf@mail.gmail.com> On 6/16/07, David Shaw wrote: > Some people have noticed that I recently committed support for the > Camellia cipher in GnuPG. Here's the story behind that. I have to ask... why? From what I've read, Camellia is so similar to AES in its construction that it offers little in the way of "cipher diversity" to OpenPGP. Wouldn't it make more sense to add experimental ciphers that have significantly different construction, ahould AES become compromised? Is Camellia's use mandated in some circumstances by a non-US-governmental organization? -- RPM From wk at gnupg.org Tue Jun 19 12:11:21 2007 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Jun 2007 12:11:21 +0200 Subject: Camellia In-Reply-To: <5d7f07420706180955w25a110celc89f8699d28050cf@mail.gmail.com> (Ryan Malayter's message of "Mon, 18 Jun 2007 11:55:04 -0500") References: <20070616220252.GA4705@jabberwocky.com> <5d7f07420706180955w25a110celc89f8699d28050cf@mail.gmail.com> Message-ID: <87645kuud2.fsf@wheatstone.g10code.de> On Mon, 18 Jun 2007 18:55, malayter at gmail.com said: > I have to ask... why? From what I've read, Camellia is so similar to It is a political thing and as such technical arguments are not of prime importance - as long as a cipher has no known weaknesses. This is much the same as why some governments in Europe recommended or even demanded the use of RIPE-MD160 over SHA-1. Eventually we might even need to add some Great-Wall cipher[1] or a Russian GOST into OpenPGP to make the use of this protocol easier for these countries. Fortunately Germany is not keen to demand the use of Magenta[1] :-) Shalom-Salam, Werner [1] Well, I have severe doubts that China is interested in strong cryptography today but that may change over time. [2] http://en.wikipedia.org/wiki/MAGENTA From jbglaw at lug-owl.de Tue Jun 19 14:59:23 2007 From: jbglaw at lug-owl.de (Jan-Benedict Glaw) Date: Tue, 19 Jun 2007 14:59:23 +0200 Subject: Camellia In-Reply-To: <87645kuud2.fsf@wheatstone.g10code.de> References: <20070616220252.GA4705@jabberwocky.com> <5d7f07420706180955w25a110celc89f8699d28050cf@mail.gmail.com> <87645kuud2.fsf@wheatstone.g10code.de> Message-ID: <20070619125923.GN11708@lug-owl.de> On Tue, 2007-06-19 12:11:21 +0200, Werner Koch wrote: > On Mon, 18 Jun 2007 18:55, malayter at gmail.com said: > > I have to ask... why? From what I've read, Camellia is so similar to > Eventually we might even need to add some Great-Wall cipher[1] or a > Russian GOST into OpenPGP to make the use of this protocol easier for > these countries. Fortunately Germany is not keen to demand the use of > Magenta[1] :-) [...] > [2] http://en.wikipedia.org/wiki/MAGENTA Hmmm. Maybe implement MAGENTA, too, together with a decryption function that doesn't ask for the passphrase :-> MfG, JBG -- Jan-Benedict Glaw jbglaw at lug-owl.de +49-172-7608481 Signature of: The course of history shows that as a government grows, liberty the second : decreases." (Thomas Jefferson) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20070619/038cb84e/attachment.pgp From atom at smasher.org Tue Jun 19 19:05:07 2007 From: atom at smasher.org (Atom Smasher) Date: Tue, 19 Jun 2007 13:05:07 -0400 (EDT) Subject: Camellia In-Reply-To: <20070619125923.GN11708@lug-owl.de> References: <20070616220252.GA4705@jabberwocky.com> <5d7f07420706180955w25a110celc89f8699d28050cf@mail.gmail.com> <87645kuud2.fsf@wheatstone.g10code.de> <20070619125923.GN11708@lug-owl.de> Message-ID: <20070619170508.73074.qmail@smasher.org> On Tue, 19 Jun 2007, Jan-Benedict Glaw wrote: >> [2] http://en.wikipedia.org/wiki/MAGENTA > > Hmmm. Maybe implement MAGENTA, too, together with a decryption function > that doesn't ask for the passphrase :-> ======================== for an example of *really* strong security, check out RFC-2440:6.6 "Example of an ASCII Armored Message". delete the leading spaces and run that through `gpg --output -` and see what happens ;) -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "No two men are alike, and both of them are happy for it." -- Morris Mandel From buanzo at buanzo.com.ar Wed Jun 20 15:30:56 2007 From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman) Date: Wed, 20 Jun 2007 10:30:56 -0300 Subject: Details for GPGME within Apache Message-ID: <46792C10.1050908@buanzo.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I've created an apache module that links to gpgme. Some GPGME functions, like verification, work ok, but others, like import do not. I've found out that the GPGHOME environment variable should exist, but using Apache's SetEnv does not work for modules. So, I'm posting these so others can benefit from my experience: The most generic way to provide Apache with env-vars is to export them before spawning it. The most generic hack would be to modify the /etc/init.d script. As a test, I've modified Gentoo's Apache script's start() function like this: start() { checkconfig || return 1 ebegin "Starting apache2" [ -f /var/log/apache2/ssl_scache ] && rm /var/log/apache2/ssl_scache # Enable this if you need debugging info # export GPGME_DEBUG=5:/tmp/apache-gpgme.out export GNUPGHOME=/var/www/.gnupg start-stop-daemon --start --exec ${APACHE2} -- ${APACHE2_OPTS} -k start eend $? } Depending on your GNU/Linux distribution, or other OS, you might discover better places where to put this. - -- Arturo "Buanzo" Busleiman - Consultor Independiente en Seguridad Informatica Free Music: http://www.buanzo.com.ar/files/buanzo-ultimamente.ogg Consulting and Secure Mail Hosting: http://www.buanzo.com.ar/pro/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeSwQAlpOsGhXcE0RCtOzAJ9KYvWiTO2vYfe6bmkjBu60cKZUBQCbBFch MEOoqqlTUIxGCmGWG1HUsD8= =CCUQ -----END PGP SIGNATURE----- From wk at gnupg.org Wed Jun 20 18:31:34 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 20 Jun 2007 18:31:34 +0200 Subject: Details for GPGME within Apache In-Reply-To: <46792C10.1050908@buanzo.com.ar> (Arturo Busleiman's message of "Wed, 20 Jun 2007 10:30:56 -0300") References: <46792C10.1050908@buanzo.com.ar> Message-ID: <87bqfamvtl.fsf@wheatstone.g10code.de> On Wed, 20 Jun 2007 15:30, buanzo at buanzo.com.ar said: > I've created an apache module that links to gpgme. Some GPGME > functions, like verification, work ok, but others, like import do > not. I've found out that the GPGHOME environment variable should > exist, Another way to set the home directory is by using: -- Function: gpgme_error_t gpgme_set_engine_info (gpgme_protocol_t PROTO, const char *FILE_NAME, const char *HOME_DIR) The function `gpgme_set_engine_info' changes the default configuration of the crypto engine implementing the protocol PROTO. FILE_NAME is the file name of the executable program implementing this protocol, and HOME_DIR is the directory name of the configuration directory for this crypto engine. If HOME_DIR is `NULL', the engine's default will be used. The new defaults are not applied to already created GPGME contexts. This function returns the error code `GPG_ERR_NO_ERROR' if successful, or an eror code on failure. So a gpgme_set_engine_info (GPGME_PROTOCOL_OpenPGP, NULL, "/var/www/.gnupg"); would do the trick. This function is available since version 1.0.3. Salam-Shalom, Werner From alon.barlev at gmail.com Sat Jun 23 09:11:13 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 23 Jun 2007 10:11:13 +0300 Subject: IDEA support Message-ID: <9e0cf0bf0706230011i4e6b275fpc183accedb1649cb@mail.gmail.com> Hello, The IDEA support now seems to be working now. You can get the latest from: http://www.kfwebs.net/articles/article/42/GnuPG-2.0---IDEA-support It contains an algorithm addition for libgcrypt and a small patch for gnupg in order to fixup the RSA key format. Enjoy, Alon Bar-Lev. From abush at microcenter.com Thu Jun 21 21:37:47 2007 From: abush at microcenter.com (Aaron Bush) Date: Thu, 21 Jun 2007 15:37:47 -0400 Subject: GPGME Large File Support on HPUX (seek) Message-ID: <4D05A6F477C1D0428123CB278461C3F203226E9B@EXCHANGE.ad.microcenter.com> I'm having some problems with GPGME (1.1.4) and GPG (1.4.7) and the large file support compile time options. I have compiled this on HPUX 11.00 and when I run the following C sample I get odd file offset results. I have tried building GPGME with both CFLAGS set to -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 and CFLAGS as nothing. ---- sample ---- #include int main (int argc, char *argv[]) { gpgme_data_t in; off_t len; gpgme_error_t err; err = gpgme_data_new_from_mem(&in, "Hallo Leute\n", 12, 0); printf("new_mem:%d %s->%d\n", __LINE__, gpgme_strerror(err), err); len = gpgme_data_seek(in, 0, SEEK_SET); printf("Offset SEEK_SET = %d\n", len); len = gpgme_data_seek(in, 0, SEEK_END); printf("Offset SEEK_END = %d\n", len); } Compiling as: 1) gcc b.c `gpgme-config --libs --cflags` -D_FILE_OFFSET_BITS=64 ./a.out new_mem:12 Success->0 Offset SEEK_SET = 27907 Offset SEEK_END = 1073762736 2) gcc b.c `gpgme-config --libs --cflags` ./a.out new_mem:12 Success->0 Offset SEEK_SET = -1 Offset SEEK_END = -1 I have read through similar posts and they all point to reading section 2.3 which refers to using the _FILE_OFFSET_BITS=64 and LARGEFILE_SUPPORT=1 and building gpgme with large file support. When I build with both preprocessor symbols I get: 3) gcc b.c `gpgme-config --libs --cflags` -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 ./a.out new_mem:12 Success->0 Offset SEEK_SET = 29206 Offset SEEK_END = 1073762752 Any suggestions or pointers would be greatly appreciated. Thanks, -ab From kloecker at kde.org Tue Jun 26 21:35:13 2007 From: kloecker at kde.org (Ingo =?iso-8859-15?q?Kl=F6cker?=) Date: Tue, 26 Jun 2007 21:35:13 +0200 Subject: [PATCH] Fix compilation of gpgme on Mac OS X Tiger Message-ID: <200706262135.22713@erwin.ingo-kloecker.de> [I'm not subscribed to gnupg-devel so please CC me on replies.] Hi, I tried to compile gpgme on Mac OS X Tiger and ran in a couple of problems: 1.) assuan/assuan.h fails to include socket.h which is needed for socklen_t. 2.) On Darwin funopen does exist. Nevertheless the code tries to compile the replacement in funopen.c and fails doing so. The attached patch fixes both problems. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme-fix-compilation-on-tiger.diff Type: text/x-diff Size: 639 bytes Desc: not available Url : /pipermail/attachments/20070626/7a4331ff/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070626/7a4331ff/attachment.pgp From christianbiere at gmx.de Wed Jun 27 00:59:38 2007 From: christianbiere at gmx.de (Christian Biere) Date: Wed, 27 Jun 2007 00:59:38 +0200 Subject: GPGME Large File Support on HPUX (seek) In-Reply-To: <4D05A6F477C1D0428123CB278461C3F203226E9B@EXCHANGE.ad.microcenter.com> References: <4D05A6F477C1D0428123CB278461C3F203226E9B@EXCHANGE.ad.microcenter.com> Message-ID: <20070626225938.GD7723@cyclonus> Aaron Bush wrote: > gpgme_data_t in; > off_t len; > gpgme_error_t err; > > err = gpgme_data_new_from_mem(&in, "Hallo Leute\n", 12, 0); > printf("new_mem:%d %s->%d\n", __LINE__, gpgme_strerror(err), > err); > > len = gpgme_data_seek(in, 0, SEEK_SET); > printf("Offset SEEK_SET = %d\n", len); You mustn't pass an off_t to printf() using %d as format specifier unless off_t is by incident the same as an int (as typically on old 32-bit systems). Always use -W -Wall -Wformat=2 for GCC. I'm almost sure it would scream bloody murder in at least one of both cases. -- Christian From wk at gnupg.org Wed Jun 27 09:45:25 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 27 Jun 2007 09:45:25 +0200 Subject: [PATCH] Fix compilation of gpgme on Mac OS X Tiger In-Reply-To: <200706262135.22713@erwin.ingo-kloecker.de> ("Ingo =?utf-8?Q?Kl=C3=B6cker=22's?= message of "Tue, 26 Jun 2007 21:35:13 +0200") References: <200706262135.22713@erwin.ingo-kloecker.de> Message-ID: <87k5tpkfhm.fsf@wheatstone.g10code.de> On Tue, 26 Jun 2007 21:35, kloecker at kde.org said: > 1.) assuan/assuan.h fails to include socket.h which is needed for > socklen_t. I don't see socklen_t type used in assuan.h. sys/socket.h is included by the internal header assuan-defs.h. Well, I am looking at the SVN code and did not checked wheter it recently changed. > 2.) On Darwin funopen does exist. Nevertheless the code tries to compile > the replacement in funopen.c and fails doing so. funopen.c is an AC_LIBOBJ function and as such won't be build if not required. Afaik, other have build gnupg2 and thus also libassuan on Darwin. Salam-Shalom, Werner From simon at josefsson.org Wed Jun 27 12:44:08 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 27 Jun 2007 12:44:08 +0200 Subject: libgpg-error fails with recent Mingw32 Message-ID: <87zm2loex3.fsf@mocca.josefsson.org> Hi! I noticed that libgpg-error failed to build with recent mingw32: make[3]: Entering directory `/home/jas/gnutls4win/build/libgpg-error-1.5/src' if /bin/sh ../libtool --tag=CC --mode=compile i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I../../../src/libgpg-error-1.5/src -I.. -DLOCALEDIR=\"/home/jas/gnutls4win/inst/share/locale\" -g -O2 -MT libgpg_error_la-w32-gettext.lo -MD -MP -MF ".deps/libgpg_error_la-w32-gettext.Tpo" -c -o libgpg_error_la-w32-gettext.lo `test -f 'w32-gettext.c' || echo '../../../src/libgpg-error-1.5/src/'`w32-gettext.c; \ then mv -f ".deps/libgpg_error_la-w32-gettext.Tpo" ".deps/libgpg_error_la-w32-gettext.Plo"; else rm -f ".deps/libgpg_error_la-w32-gettext.Tpo"; exit 1; fi mkdir .libs i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I../../../src/libgpg-error-1.5/src -I.. -DLOCALEDIR=\"/home/jas/gnutls4win/inst/share/locale\" -g -O2 -MT libgpg_error_la-w32-gettext.lo -MD -MP -MF .deps/libgpg_error_la-w32-gettext.Tpo -c ../../../src/libgpg-error-1.5/src/w32-gettext.c -DDLL_EXPORT -DPIC -o .libs/libgpg_error_la-w32-gettext.o ../../../src/libgpg-error-1.5/src/w32-gettext.c: In function `_nl_locale_name': ../../../src/libgpg-error-1.5/src/w32-gettext.c:851: error: duplicate case value ../../../src/libgpg-error-1.5/src/w32-gettext.c:850: error: previously used here ../../../src/libgpg-error-1.5/src/w32-gettext.c:1059: error: duplicate case value ../../../src/libgpg-error-1.5/src/w32-gettext.c:1058: error: previously used here ../../../src/libgpg-error-1.5/src/w32-gettext.c:1067: error: duplicate case value ../../../src/libgpg-error-1.5/src/w32-gettext.c:1066: error: previously used here make[3]: *** [libgpg_error_la-w32-gettext.lo] Error 1 make[3]: Leaving directory `/home/jas/gnutls4win/build/libgpg-error-1.5/src' The reason is that mingw32 defines some symbols: jas at mocca:~/gnutls4win$ grep SUBLANG_BENGALI /usr/i586-mingw32msvc/include/* /usr/i586-mingw32msvc/include/winnt.h:#define SUBLANG_BENGALI_INDIA 0x01 jas at mocca:~/gnutls4win$ And w32-gettext.c tries to do the same: /* Mingw headers don't have latest language and sublanguage codes. */ ... # ifndef SUBLANG_BENGALI_INDIA # define SUBLANG_BENGALI_INDIA 0x00 # endif # ifndef SUBLANG_BENGALI_BANGLADESH # define SUBLANG_BENGALI_BANGLADESH 0x01 # endif I don't know if these #define's are standardized somewhere, and if so, which of the definitions in mingw32 or libgpg-error is in error. Meanwhile, I'm using the patch below to work around the problem. /Simon --- src/libgpg-error-1.5/src/w32-gettext.c.orig 2007-06-27 12:40:37.000000000 +0200 +++ src/libgpg-error-1.5/src/w32-gettext.c 2007-06-27 12:41:11.000000000 +0200 @@ -522,10 +522,10 @@ # define SUBLANG_AZERI_CYRILLIC 0x02 # endif # ifndef SUBLANG_BENGALI_INDIA -# define SUBLANG_BENGALI_INDIA 0x00 +# define SUBLANG_BENGALI_INDIA 0x01 # endif # ifndef SUBLANG_BENGALI_BANGLADESH -# define SUBLANG_BENGALI_BANGLADESH 0x01 +# define SUBLANG_BENGALI_BANGLADESH 0x00 # endif # ifndef SUBLANG_CHINESE_MACAU # define SUBLANG_CHINESE_MACAU 0x05 @@ -618,16 +618,16 @@ # define SUBLANG_NEPALI_INDIA 0x02 # endif # ifndef SUBLANG_PUNJABI_INDIA -# define SUBLANG_PUNJABI_INDIA 0x00 +# define SUBLANG_PUNJABI_INDIA 0x01 # endif # ifndef SUBLANG_PUNJABI_PAKISTAN -# define SUBLANG_PUNJABI_PAKISTAN 0x01 +# define SUBLANG_PUNJABI_PAKISTAN 0x00 # endif # ifndef SUBLANG_ROMANIAN_ROMANIA -# define SUBLANG_ROMANIAN_ROMANIA 0x00 +# define SUBLANG_ROMANIAN_ROMANIA 0x01 # endif # ifndef SUBLANG_ROMANIAN_MOLDOVA -# define SUBLANG_ROMANIAN_MOLDOVA 0x01 +# define SUBLANG_ROMANIAN_MOLDOVA 0x00 # endif # ifndef SUBLANG_SERBIAN_LATIN # define SUBLANG_SERBIAN_LATIN 0x02 From fw at deneb.enyo.de Wed Jun 27 18:41:47 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 27 Jun 2007 18:41:47 +0200 Subject: Camellia In-Reply-To: <87645kuud2.fsf@wheatstone.g10code.de> (Werner Koch's message of "Tue, 19 Jun 2007 12:11:21 +0200") References: <20070616220252.GA4705@jabberwocky.com> <5d7f07420706180955w25a110celc89f8699d28050cf@mail.gmail.com> <87645kuud2.fsf@wheatstone.g10code.de> Message-ID: <87bqf1tkms.fsf@mid.deneb.enyo.de> * Werner Koch: > Eventually we might even need to add some Great-Wall cipher[1] or a > Russian GOST into OpenPGP to make the use of this protocol easier for > these countries. Fortunately Germany is not keen to demand the use of > Magenta[1] :-) I wouldn't be surprised if there were some private GnuPG versions in circulation, modified to use the semi-public Chiasmus algorithm. The other home-grown German algorithm, Libelle, is hardware-only, and implementing it in software would really, really piss off some people, I suppose. 8-) From linuxmanx at gmx.de Wed Jun 27 21:00:20 2007 From: linuxmanx at gmx.de (LinuxmanX) Date: Wed, 27 Jun 2007 21:00:20 +0200 Subject: gpg: [don't know]: invalid packet (ctb=7a) Message-ID: <4682B3C4.8080503@gmx.de> Hello, I'm running GPG on my Mac (10.4.10). Due to a power failure it powered off while optimizing the volume. After the crash I realized that GPG is corrupted :-/ Here you can see the complete error message: darwin: Rob$ gpg --list-keys gpg: [don't know]: invalid packet (ctb=7a) gpg: keydb_search_first failed: invalid packet I searched for "ctb=7a" but I found nothing regarding this error. "ctb=00", "ctb=03" and so on are listed everywhere but not the one above. Can anyone help me? If I have chosen the wrong list - sorry! But then tell me were I can help, please. Bye, Rob From rjh at sixdemonbag.org Wed Jun 27 23:27:40 2007 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 27 Jun 2007 16:27:40 -0500 Subject: gpg: [don't know]: invalid packet (ctb=7a) In-Reply-To: <4682B3C4.8080503@gmx.de> References: <4682B3C4.8080503@gmx.de> Message-ID: <1182979660.28930.1.camel@daley.cs.uiowa.edu> > After the crash I realized that GPG is corrupted :-/ This doesn't look as if GnuPG is corrupted, but rather that your keyrings have become corrupted. Try restoring them from backups and see if that fixes anything. From ken.takusagawa.2 at gmail.com Thu Jun 28 10:06:55 2007 From: ken.takusagawa.2 at gmail.com (Ken Takusagawa) Date: Thu, 28 Jun 2007 04:06:55 -0400 Subject: reading a passphrase out of an environment variable Message-ID: <4dcea1d80706280106j7b455955h2dbf2bcd2d31d25c@mail.gmail.com> I'd like to propose a feature: to read a passphrase out of an environment variable. When one wants to use a passphrase for symmetric encryption in an automated application, I've used the flag "--passphrase-fd 0". (Any better ideas?) But there is a problem: If you write the passphrase to a file and use input redirection, e.g., "gpg ... < passphrasefile" then that file (almost) certainly has to hit disk (/dev/shm is the thing to do, if it is available) and the person who buys this used hard disk on eBay might be able to recover the passphrase. If you use it as part of a pipeline, i.e., "echo mypassphrase | gpg ..." then it's vulnerable to another user running "ps" at just the right moment to see the echo command and its argument (Or so I think. Do shells "desugar" echo commands so that they never spawn a process?). Plus you have to be careful that it doesn't hit the command history file. If we had a feature of reading a passphrase out of an environment variable, one could write a script along these lines #! /bin/bash read -s GNUPG_PASSPHRASE # -s is a bash-special option to read that does not echo #multiple invocations of gpg that use the same passphrase for file in *.gpg do gpg --get-passphrase-from-environment ... done ... unset GNUPG_PASSPHRASE This has the vulnerability that the chunk of memory that is holding the value of the environment variable might get swapped out to disk, but I'm willing to live with that small possibility (or maybe implement encrypted swap). (Threat model: multi-user machine. I trust the super-user not to maliciously hack me. I do not trust the other local users of the machine. I do not trust that the hard drive of this machine to be eventually disposed/destroyed securely. I trust the OS to separate user environments.) --ken From dshaw at jabberwocky.com Thu Jun 28 13:41:39 2007 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 28 Jun 2007 07:41:39 -0400 Subject: reading a passphrase out of an environment variable In-Reply-To: <4dcea1d80706280106j7b455955h2dbf2bcd2d31d25c@mail.gmail.com> References: <4dcea1d80706280106j7b455955h2dbf2bcd2d31d25c@mail.gmail.com> Message-ID: <20070628114139.GA3362@jabberwocky.com> On Thu, Jun 28, 2007 at 04:06:55AM -0400, Ken Takusagawa wrote: > If we had a feature of reading a passphrase out of an environment > variable, one could write a script along these lines > > #! /bin/bash > read -s GNUPG_PASSPHRASE > # -s is a bash-special option to read that does not echo > > #multiple invocations of gpg that use the same passphrase > for file in *.gpg > do gpg --get-passphrase-from-environment ... > done > ... > unset GNUPG_PASSPHRASE This doesn't fully answer your question, I know, but have you looked at --multifile to accomplish this? gpg --multifile --decrypt *.gpg David From kloecker at kde.org Thu Jun 28 21:42:49 2007 From: kloecker at kde.org (Ingo =?iso-8859-1?q?Kl=F6cker?=) Date: Thu, 28 Jun 2007 21:42:49 +0200 Subject: [PATCH] Fix compilation of gpgme on Mac OS X Tiger In-Reply-To: <87k5tpkfhm.fsf@wheatstone.g10code.de> References: <200706262135.22713@erwin.ingo-kloecker.de> <87k5tpkfhm.fsf@wheatstone.g10code.de> Message-ID: <200706282143.01686@erwin.ingo-kloecker.de> On Wednesday 27 June 2007 09:45, Werner Koch wrote: > On Tue, 26 Jun 2007 21:35, kloecker at kde.org said: > > 1.) assuan/assuan.h fails to include socket.h which is needed for > > socklen_t. > > I don't see socklen_t type used in assuan.h. Just to make sure we are talking about the same file: I'm talking about gpgme/assuan/assuan.h > sys/socket.h is included by the internal header assuan-defs.h. But assuan.h does not include assuan-defs.h. > Well, I am looking at > the SVN code and did not checked wheter it recently changed. It is used in the latest released version and in svn trunk: http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/*checkout*/trunk/assuan/assuan.h?content-type=text%2Fplain&rev=1199&root=GPGME int _gpgme_ath_accept (int s, struct sockaddr *addr, socklen_t *length_ptr); int _gpgme_ath_connect (int s, struct sockaddr *addr, socklen_t length); This code is compile if #ifdef _ASSUAN_IN_GPGME_BUILD_ASSUAN. Should gpgme use an installed libassuan? > > 2.) On Darwin funopen does exist. Nevertheless the code tries to > > compile the replacement in funopen.c and fails doing so. > > funopen.c is an AC_LIBOBJ function and as such won't be build if not > required. > > Afaik, other have build gnupg2 and thus also libassuan on Darwin. Okay. Our confusion seems to stem from the fact that I'm not talking about libassuan but about gpgme (see the subject). Maybe the real problem is that gpgme's configure script did not find the previously build and installed libassuan and therefore tried to build its own (outdated) copy (is it a copy?) of assuan. All I did was build and install all everything needed for compiling gpgme. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070628/69019c08/attachment.pgp From alex at bofh.net.pl Thu Jun 28 21:05:49 2007 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Thu, 28 Jun 2007 21:05:49 +0200 Subject: Camellia In-Reply-To: <87bqf1tkms.fsf@mid.deneb.enyo.de> References: <20070616220252.GA4705@jabberwocky.com> <5d7f07420706180955w25a110celc89f8699d28050cf@mail.gmail.com> <87645kuud2.fsf@wheatstone.g10code.de> <87bqf1tkms.fsf@mid.deneb.enyo.de> Message-ID: <20070628190549.GF2460@hell.pl> On Wed, Jun 27, 2007 at 06:41:47PM +0200, Florian Weimer wrote: > * Werner Koch: > > > Eventually we might even need to add some Great-Wall cipher[1] or a > > Russian GOST into OpenPGP to make the use of this protocol easier for > > these countries. Fortunately Germany is not keen to demand the use of > > Magenta[1] :-) > > I wouldn't be surprised if there were some private GnuPG versions in > circulation, modified to use the semi-public Chiasmus algorithm. The > other home-grown German algorithm, Libelle, is hardware-only, and > implementing it in software would really, really piss off some people, > I suppose. 8-) But it seems that no spec is currently available? Alex -- JID: alex at hell.pl PGP: 0x46399138 od zwracania uwagi na detale s? lekarze, adwokaci, programi?ci i zegarmistrze -- Czerski From wk at gnupg.org Fri Jun 29 16:49:40 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Jun 2007 16:49:40 +0200 Subject: Camellia In-Reply-To: <20070628190549.GF2460@hell.pl> (Janusz A. Urbanowicz's message of "Thu, 28 Jun 2007 21:05:49 +0200") References: <20070616220252.GA4705@jabberwocky.com> <5d7f07420706180955w25a110celc89f8699d28050cf@mail.gmail.com> <87645kuud2.fsf@wheatstone.g10code.de> <87bqf1tkms.fsf@mid.deneb.enyo.de> <20070628190549.GF2460@hell.pl> Message-ID: <87sl8a95ob.fsf@wheatstone.g10code.de> On Thu, 28 Jun 2007 21:05, alex at bofh.net.pl said: > But it seems that no spec is currently available? There is no spec for Chisasm as they are still assuming that security through obscurity has advantages over a public researchable algorithms. Chiasmus has no relevance for us or the Internet. Shalom-Salam, Werner From wk at gnupg.org Fri Jun 29 16:46:19 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Jun 2007 16:46:19 +0200 Subject: [PATCH] Fix compilation of gpgme on Mac OS X Tiger In-Reply-To: <200706282143.01686@erwin.ingo-kloecker.de> ("Ingo =?utf-8?Q?Kl=C3=B6cker=22's?= message of "Thu, 28 Jun 2007 21:42:49 +0200") References: <200706262135.22713@erwin.ingo-kloecker.de> <87k5tpkfhm.fsf@wheatstone.g10code.de> <200706282143.01686@erwin.ingo-kloecker.de> Message-ID: <87wsxm95tw.fsf@wheatstone.g10code.de> On Thu, 28 Jun 2007 21:42, kloecker at kde.org said: > This code is compile if #ifdef _ASSUAN_IN_GPGME_BUILD_ASSUAN. Should > gpgme use an installed libassuan? Sorry, I missed that you have been talking about the included assuan. Yeah, you are right that needs to be fixed. We need to update the included Assuan version anyway. Please give us a few days until the standard Assuan is stable enough. Salam-Shalom, Werner