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" <gnupg-devel at mlists.thewrittenword.com> 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 <ENTER>.

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 <moritz AT
g10code.com>

> 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 <dshaw at jabberwocky.com> 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 <s-beyer at gmx.net>, 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 <dshaw at jabberwocky.com> 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 <wk at gnupg.org> 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 <gpgme.h>

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