From wk at gnupg.org  Tue May  1 17:29:34 2007
From: wk at gnupg.org (Werner Koch)
Date: Tue, 01 May 2007 17:29:34 +0200
Subject: small patches for libksba-1.0.1 and libassuan-1.0.1
In-Reply-To: <20070430214730.GO8893@localhost.localdomain> (Peter O'Gorman's
	message of "Mon\, 30 Apr 2007 16\:47\:30 -0500")
References: <20070430214730.GO8893@localhost.localdomain>
Message-ID: <87ejm0r28x.fsf@wheatstone.g10code.de>

On Mon, 30 Apr 2007 23:47, gnupg-devel at mlists.thewrittenword.com said:

> ksba
> On AIX-4.3, xlc complains if enums end in a comma. HPUX does not like
> doing pointer math with void* pointers.

Well, the usual GCC-isms.  Fixed.

> assuan
> We need to define _XOPEN_SOURCE etc for irix and Tru64. There was

I try to avoid these hardwired things.  We need to check whether there an
autoconf tests for this already exists.

> another pointer math issue, and Tru64 4.0D does not have snprintf,

Applied.

> rather than using trio or another replacement, I just used sprintf
> and made sure that the result would be small enough.

Using sprintf is not an option in this case.  I consider sprintf only
okay for things like numeric conversions.  It should not be used in new
code.  We need to use a replacement function.  I will care about it.


Thanks,

   Werner



From JPClizbe at tx.rr.com  Tue May  1 22:39:51 2007
From: JPClizbe at tx.rr.com (John Clizbe)
Date: Tue, 01 May 2007 15:39:51 -0500
Subject: Build error on Windows with OpenLDAP
Message-ID: <4637A597.80905@tx.rr.com>

If building GnuPG for Win32 with OpenLDAP instead of Win32's wlpda32, the wrong
header file is being included.

From configure:
configure: creating cache config.cache
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
<snip>
checking whether LDAP via "-lldap" is present and sane... no
checking whether I can make LDAP be sane with lber.h... yes
checking for ldap_get_option... yes
checking for ldap_set_option... yes
checking for ldap_start_tls_s... yes


$ make
gcc  -O3 -s -mms-bitfields -march=pentium3 -Wall -Wcast-align -Wshadow
-Wstrict-prototypes -Wformat-nonliteral -o gpgkeys_ldap.exe
gpgkeys_ldap-gpgkeys_ldap.o gpgkeys_ldap-ksutil.o ../util/libcompat.a  -lldap
   -lwsock32
gpgkeys_ldap-gpgkeys_ldap.o:gpgkeys_ldap.c:(.text+0xe25): undefined reference to
`_imp__ldap_modify_sA'
gpgkeys_ldap-gpgkeys_ldap.o:gpgkeys_ldap.c:(.text+0xe4f): undefined reference to
`_imp__ldap_add_sA'
gpgkeys_ldap-gpgkeys_ldap.o:gpgkeys_ldap.c:(.text+0xe6f): undefined reference to
`_imp__ldap_err2stringA'

The 'A' suffixed names are supplied by winldap.h, but that should only be
included if also linking with wldap32.dll.

I couldn't think of a non-fugly way to fix the source.

The section of keyserver/gpgkeys_ldap.c is
#ifdef _WIN32
#include <winsock2.h>
#include <winldap.h>
#else
#ifdef NEED_LBER_H
#include <lber.h>
#endif
/* For OpenLDAP, to enable the API that we're using. */
#define LDAP_DEPRECATED 1
#include <ldap.h>
#endif

Also, if including winsock2.h, shouldn't the linking be with -lws2_32 instead of
-lwsock32?


-- 
John P. Clizbe                      Inet:   John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10/0x18BB373A
"what's the key to success?"        / "two words: good decisions."
"what's the key to good decisions?" /  "one word: experience."
"how do i get experience?"          / "two words: bad decisions."

"Just how do the residents of Haiku, Hawai'i hold conversations?"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 662 bytes
Desc: OpenPGP digital signature
Url : /pipermail/attachments/20070501/1bd5611b/attachment.pgp 

From wk at gnupg.org  Wed May  2 15:36:27 2007
From: wk at gnupg.org (Werner Koch)
Date: Wed, 02 May 2007 15:36:27 +0200
Subject: Build error on Windows with OpenLDAP
In-Reply-To: <4637A597.80905@tx.rr.com> (John Clizbe's message of "Tue\, 01 May
	2007 15\:39\:51 -0500")
References: <4637A597.80905@tx.rr.com>
Message-ID: <87ejlzl544.fsf@wheatstone.g10code.de>

On Tue,  1 May 2007 22:39, JPClizbe at tx.rr.com said:

> If building GnuPG for Win32 with OpenLDAP instead of Win32's wlpda32, the wrong
> header file is being included.

That is simply not supported. 


Salam-Shalom,

   Werner



From dshaw at jabberwocky.com  Wed May  2 15:46:40 2007
From: dshaw at jabberwocky.com (David Shaw)
Date: Wed, 2 May 2007 09:46:40 -0400
Subject: Build error on Windows with OpenLDAP
In-Reply-To: <4637A597.80905@tx.rr.com>
References: <4637A597.80905@tx.rr.com>
Message-ID: <20070502134640.GE7101@jabberwocky.com>

On Tue, May 01, 2007 at 03:39:51PM -0500, John Clizbe wrote:

> The 'A' suffixed names are supplied by winldap.h, but that should only be
> included if also linking with wldap32.dll.
> 
> I couldn't think of a non-fugly way to fix the source.

Yeah, that is pretty fugly.  The source doesn't allow for OpenLDAP on
Win32 - if it's Win32, it must be winldap.  I'll take a look at it.

David


From wk at gnupg.org  Wed May  2 16:17:37 2007
From: wk at gnupg.org (Werner Koch)
Date: Wed, 02 May 2007 16:17:37 +0200
Subject: Build error on Windows with OpenLDAP
In-Reply-To: <87ejlzl544.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Wed\, 02 May 2007 15\:36\:27 +0200")
References: <4637A597.80905@tx.rr.com> <87ejlzl544.fsf@wheatstone.g10code.de>
Message-ID: <87odl3jon2.fsf@wheatstone.g10code.de>

On Wed,  2 May 2007 15:36, wk at gnupg.org said:

> That is simply not supported. 

BTW, why do you want to use OpenLDAP under Windows?  I can see no reason
for it.


Shalom-Salam,

   Werner




From JPClizbe at tx.rr.com  Wed May  2 21:34:42 2007
From: JPClizbe at tx.rr.com (John Clizbe)
Date: Wed, 02 May 2007 14:34:42 -0500
Subject: Build error on Windows with OpenLDAP
In-Reply-To: <87odl3jon2.fsf@wheatstone.g10code.de>
References: <4637A597.80905@tx.rr.com> <87ejlzl544.fsf@wheatstone.g10code.de>
	<87odl3jon2.fsf@wheatstone.g10code.de>
Message-ID: <4638E7D2.8050401@tx.rr.com>

Werner Koch wrote:
> On Wed,  2 May 2007 15:36, wk at gnupg.org said:
> 
>> That is simply not supported. 
> 
> BTW, why do you want to use OpenLDAP under Windows?  I can see no reason
> for it.

LDAPS support doesn't work on Windows with wldap32. OpenLDAP is the standard in
OSS LDAP implementations and is supported by GnuPG on all other operating
systems. So why not use OpenLDAP when looking for a LDAP implementation that works.

With wldap32:

  C:\WINDOWS>gpg --refresh-keys 0x600fa001
  gpg: requesting key 600FA001 from ldaps server keys.pgp.com
  gpgkeys: unable to make SSL connection: not built with LDAPS support

LDAPS works on other platforms. Why not Win32?

If the TLS/SSL code in gpgkeys_ldap linked with wldap32 would made a LDAPS
connection, there wouldn't be a need for OpenLDAP.


-- 
John P. Clizbe                      Inet:   John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10/0x18BB373A
"what's the key to success?"        / "two words: good decisions."
"what's the key to good decisions?" /  "one word: experience."
"how do i get experience?"          / "two words: bad decisions."

"Just how do the residents of Haiku, Hawai'i hold conversations?"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 662 bytes
Desc: OpenPGP digital signature
Url : /pipermail/attachments/20070502/d0968722/attachment.pgp 

From buanzo at buanzo.com.ar  Thu May  3 00:24:54 2007
From: buanzo at buanzo.com.ar (Arturo 'Buanzo' Busleiman)
Date: Wed, 02 May 2007 19:24:54 -0300
Subject: roadmap for gpgme key exchange
Message-ID: <46390FB6.2050609@buanzo.com.ar>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I see in the TODO file for gpgme the following item:

*** Exchanging keys with key servers.

What is the implementation priority of this? Any plans already? Can I help implement it?

Why I need this? For mod_auth_openpgp. If this funcitonality is not prioritary, I might start adding
other functionality to m_a_o.

Sincerely,
Buanzo

- --
Arturo "Buanzo" Busleiman - Consultor Independiente en Seguridad Informatica
OpenPGP for HTTP: New Web-Auth Scheme: http://freshmeat.net/articles/view/2599
Consulting and Secure Mail Hosting: http://www.buanzo.com.ar/pro/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGOQ+2AlpOsGhXcE0RCmHnAJ9IM+90fKomtLeyWgvUIYJn+9MxvgCfawj8
Pg0TNcA4c6QV3ixGoYPO1qE=
=TMs3
-----END PGP SIGNATURE-----


From hawke at hawkesnest.net  Thu May  3 08:01:01 2007
From: hawke at hawkesnest.net (Alex Mauer)
Date: Thu, 03 May 2007 01:01:01 -0500
Subject: UID ordering
In-Reply-To: <20070216200042.GC32368@jabberwocky.com>
References: <au6bt2pgnv1iu2llajgvaqrq79efr7ub51@domain.is.invalid>	<20070216141055.GC27943@jabberwocky.com>	<6osbt2tjgnp6mt6jpoklsa40b0442cdm2t@domain.is.invalid>	<20070216190020.GB32368@jabberwocky.com>	<er51ot$ueq$1@sea.gmane.org>
	<20070216200042.GC32368@jabberwocky.com>
Message-ID: <f1btr3$7jq$1@sea.gmane.org>

David Shaw wrote:
> 
> No.  Like I said, there is a signature subpacket that tags the UID as
> the primary one.  If you don't tag any UID, then GnuPG will sort the
> most recent one first, but that doesn't make it primary.
> 
>> Also, if it's just a flag that says "this one is
>> primary", what happens if different UIDs are set as primary on different
>> keyrings, and then they're merged?
> 
> The most recent of the UIDs tagged as primary will be treated as the
> "true" primary.

Hate to revive this old thread, but:
So does gpg create UIDs marked as primary by default?  It seems that it
does, since if I generate a new key, and then add a UID, the new UID is
marked as primary.

Or is it that no key is marked as primary by default, and if no key is
marked as primary then the most recent self-sig is considered primary?

-Alex Mauer "hawke"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : /pipermail/attachments/20070503/b13feab0/attachment.pgp 

From wk at gnupg.org  Thu May  3 09:03:39 2007
From: wk at gnupg.org (Werner Koch)
Date: Thu, 03 May 2007 09:03:39 +0200
Subject: roadmap for gpgme key exchange
In-Reply-To: <46390FB6.2050609@buanzo.com.ar> (Arturo Busleiman's message of
	"Wed\, 02 May 2007 19\:24\:54 -0300")
References: <46390FB6.2050609@buanzo.com.ar>
Message-ID: <877irqgzhw.fsf@wheatstone.g10code.de>

On Thu,  3 May 2007 00:24, buanzo at buanzo.com.ar said:

> *** Exchanging keys with key servers.
>
> What is the implementation priority of this? Any plans already? Can I help implement it?

We have not defined any priority.  We are thinking about enhancing GPA,
this might be an opportunity to move the keyserver sending stuff to
gpgme.  However it is not yet clear whether this makes sense

You might want to look at GPA's code (src/server-access.c) to see how to
employ gpg's keyserver helper programs.


Salam-Shalom,

   Werner






From dshaw at jabberwocky.com  Thu May  3 13:57:28 2007
From: dshaw at jabberwocky.com (David Shaw)
Date: Thu, 3 May 2007 07:57:28 -0400
Subject: UID ordering
In-Reply-To: <f1btr3$7jq$1@sea.gmane.org>
References: <au6bt2pgnv1iu2llajgvaqrq79efr7ub51@domain.is.invalid>
	<20070216141055.GC27943@jabberwocky.com>
	<6osbt2tjgnp6mt6jpoklsa40b0442cdm2t@domain.is.invalid>
	<20070216190020.GB32368@jabberwocky.com>
	<er51ot$ueq$1@sea.gmane.org>
	<20070216200042.GC32368@jabberwocky.com>
	<f1btr3$7jq$1@sea.gmane.org>
Message-ID: <20070503115728.GB25662@jabberwocky.com>

On Thu, May 03, 2007 at 01:01:01AM -0500, Alex Mauer wrote:
> David Shaw wrote:
> > 
> > No.  Like I said, there is a signature subpacket that tags the UID as
> > the primary one.  If you don't tag any UID, then GnuPG will sort the
> > most recent one first, but that doesn't make it primary.
> > 
> >> Also, if it's just a flag that says "this one is
> >> primary", what happens if different UIDs are set as primary on different
> >> keyrings, and then they're merged?
> > 
> > The most recent of the UIDs tagged as primary will be treated as the
> > "true" primary.
> 
> Hate to revive this old thread, but:
> So does gpg create UIDs marked as primary by default?  It seems that it
> does, since if I generate a new key, and then add a UID, the new UID is
> marked as primary.

It doesn't mark a UID as primary by default.  However, if there is no
UID marked as primary, then the most recently added UID is treated as
primary.

David


From nsushkin at sushkins.net  Thu May  3 22:34:15 2007
From: nsushkin at sushkins.net (Nicholas Sushkin)
Date: Thu, 3 May 2007 16:34:15 -0400
Subject: gpgsm 1.9.22 supports no RC2 Algorithm ?
Message-ID: <200705031634.20528.nsushkin@sushkins.net>

Werner, others,

There has been a bug filed today in Mozilla bugzilla, 
https://bugzilla.mozilla.org/show_bug.cgi?id=379625. If any of you can 
vote, track, or help troubleshoot the issue, the affected users (including 
me) will greatly appreciate.

(Original gnupg-devel thread archived at 
http://lists.gnupg.org/pipermail/gnupg-devel/2007-April/thread.html#23761)

Many thanks,
-- 
Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1388 bytes
Desc: not available
Url : /pipermail/attachments/20070503/231a764d/attachment.bin 

From nsushkin at sushkins.net  Fri May  4 03:19:28 2007
From: nsushkin at sushkins.net (Nicholas Sushkin)
Date: Thu, 3 May 2007 21:19:28 -0400
Subject: gpgsm 1.9.22 supports no RC2 Algorithm ?
Message-ID: <200705032119.35320.nsushkin@sushkins.net>

Werner, others,

There has been a bug filed today in Mozilla bugzilla, 
https://bugzilla.mozilla.org/show_bug.cgi?id=379625. If any of you can 
vote, track, or help troubleshoot the issue, the affected users (including 
me) will greatly appreciate.

(Original gnupg-devel thread archived at 
http://lists.gnupg.org/pipermail/gnupg-devel/2007-April/thread.html#23761)

Many thanks,
-- 
Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1388 bytes
Desc: not available
Url : /pipermail/attachments/20070503/1058dfc5/attachment.bin 

From thisisnotapipe at hotmail.com  Fri May  4 03:22:04 2007
From: thisisnotapipe at hotmail.com (Bernard Leak)
Date: Fri, 04 May 2007 01:22:04 +0000
Subject: Inconsistent naming of gpg{,2}keys_mailto
Message-ID: <BAY123-F136784E9F53B46CD4811A9CB400@phx.gbl>

Dear List,
               I've been trying to build the 2.0.3 release of GnuPG with
--enable-mailto, and it's broken.  The Makefile assumes the existence of
keyserver/gpg2keys_mailto, but 'configure' actually constructs
keyserver/gpgkeys_mailto from the corresponding .in file.

Presumably this was carried forward on autopilot from GnuPG 1.4.x .
The other (executable) keyservers do seem to have been given
gpg2keys_* names, but this script has not.  It's not clear whether th
appropriate correction is to rename the script (internally and in
configure.ac) or to change the name (back) in the build dependencies
in keyserver/Makefile.am .

I haven't checked the live sources for changes.  I'm trying to get other
things done, I'm lazy, and the Web interface to the CVS server seems
to be stuck.

Bernard Leak.

_________________________________________________________________
Solve the Conspiracy and win fantastic prizes.  
http://www.theconspiracygame.co.uk/



From wk at gnupg.org  Fri May  4 10:07:46 2007
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 May 2007 10:07:46 +0200
Subject: Inconsistent naming of gpg{,2}keys_mailto
In-Reply-To: <BAY123-F136784E9F53B46CD4811A9CB400@phx.gbl> (Bernard Leak's
	message of "Fri\, 04 May 2007 01\:22\:04 +0000")
References: <BAY123-F136784E9F53B46CD4811A9CB400@phx.gbl>
Message-ID: <87d51hau5p.fsf@wheatstone.g10code.de>

On Fri,  4 May 2007 03:22, thisisnotapipe at hotmail.com said:

>                I've been trying to build the 2.0.3 release of GnuPG with
> --enable-mailto, and it's broken.  The Makefile assumes the existence of
> keyserver/gpg2keys_mailto, but 'configure' actually constructs

Thanks for reporting.  I have just fixed it by renaming them to gpg2keys*


Shalom-Salam,

   Werner



From wk at gnupg.org  Fri May  4 10:17:18 2007
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 May 2007 10:17:18 +0200
Subject: gpgsm 1.9.22 supports no RC2 Algorithm ?
In-Reply-To: <200705031634.20528.nsushkin@sushkins.net> (Nicholas Sushkin's
	message of "Thu\, 3 May 2007 16\:34\:15 -0400")
References: <200705031634.20528.nsushkin@sushkins.net>
Message-ID: <878xc5atpt.fsf@wheatstone.g10code.de>

On Thu,  3 May 2007 22:34, nsushkin at sushkins.net said:

> There has been a bug filed today in Mozilla bugzilla, 
> https://bugzilla.mozilla.org/show_bug.cgi?id=379625. If any of you can 
> vote, track, or help troubleshoot the issue, the affected users (including 
> me) will greatly appreciate.

The issue is simply that Mozilla allows (and even worse, sometimes
forces) the use of RC2.  This should be fixed asap in Mozilla.

I consider any application using RC2 for encryption not only broken but
playing a false game with its users by telling them: Your mail has been
encrypted.  They are not telling them that it is the "NSA approved" 40
bit cipher used in the dark ages for US-exportable software.

Go and drop RC2!


Salam-Shalom,

   Werner


p.s.  
I am aware that it is possible to use other key lengths with RC2
but due to trade secrets, FUD and a wealth of proven and free cipher
algorithms, RC2 has no reasons to exist (maybe except for its needless
use in pkcs#11).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : /pipermail/attachments/20070504/9e7112c3/attachment.pgp 

From thisisnotapipe at hotmail.com  Fri May  4 12:00:17 2007
From: thisisnotapipe at hotmail.com (Bernard Leak)
Date: Fri, 04 May 2007 10:00:17 +0000
Subject: GnuPG documentation
Message-ID: <BAY123-F15C66BC3794905A13E23EFCB400@phx.gbl>

Dear List,
                now for the documentation: not always the Cinderella of
development (2.0.3 8? that looks busy!), but almost always the
Cinderella of clean building...

make gnupg.html fails because gnupg.dvi is missing (!)
make gnupg.dvi "works", but produces gnupg.pdf

That last sounded suspiciously like something I'd seen before,
but it turned out not to be a previous gnupg build.
After much tedious grovelling with ad hoc patched versions
of texi2dvi, I found my notes on the similar bug (in gdb, which
ought to get a message from me too).  It's the local copy of
texinfo.tex, in the scripts/ directory.  This is old (though not
nearly as old as the one in gdb-6.6!).  Deleting it and using the
copy installed with tetex-3.0 doesn't work either (in fact, it
seems even worse).   Installing the latest version, as suggested
in texinfo.tex itself, works like a charm.  Well, like one of those
charms that work, anyway.  Charmingly.
My latest download from http://www.gnu.org/software/texinfo/
is brand, spankingly new - with version "2007-05-03.09" .

I suggest
(a)
(i) shipping with a more recent texinfo.tex as a
    matter of routine (something to do with each release?).
(ii) Issuing a warning in the README about the use of the
    local copy

or

(b)
(i) remove texinfo.tex from GnuPG
(ii) tell the reader to have a working TeX installation,
     including a recent texinfo.tex. .

So much for gnupg.dvi .

Now back to gnupg.html...

gnupg-badge-openpgp.gif is missing (and the document
generation stops at once when this is discovered).
Simply adding in a random *.gif file named
gnupg-badge-openpgp.gif into the doc/ directory (source
OR build tree) seems to solve the problem.  But let's have
the proper *.gif file, please!

Oh, another thing which caught my eye:
The "glossary" is briefly described as "Short descrition of used terms".
I suppose "description" was meant.  Also, it's better English to say
"terms used", not "used terms".  This is one of the (few) English
adjectives whose meaning varies with position.  A "used term" is
like a used car.  I wouldn't want to use one of those in my nice
clean expressions.

Bernard Leak.
--
GnuPG - now protecting your English as well as your privacy!
Soon to replace the Acad?mie Fran?aise too!

_________________________________________________________________
MSN Hotmail is evolving - check out the new Windows Live Hotmail  
http://get.live.com/betas/mail_betas



From wk at gnupg.org  Fri May  4 13:11:23 2007
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 May 2007 13:11:23 +0200
Subject: GnuPG documentation
In-Reply-To: <BAY123-F15C66BC3794905A13E23EFCB400@phx.gbl> (Bernard Leak's
	message of "Fri\, 04 May 2007 10\:00\:17 +0000")
References: <BAY123-F15C66BC3794905A13E23EFCB400@phx.gbl>
Message-ID: <87bqh0alno.fsf@wheatstone.g10code.de>

On Fri,  4 May 2007 12:00, thisisnotapipe at hotmail.com said:

> seems even worse).   Installing the latest version, as suggested
> in texinfo.tex itself, works like a charm.  Well, like one of those
> charms that work, anyway.  Charmingly.
> My latest download from http://www.gnu.org/software/texinfo/
> is brand, spankingly new - with version "2007-05-03.09" .

Okay, I will use this one.

> (i) shipping with a more recent texinfo.tex as a
>    matter of routine (something to do with each release?).

>From time to time I update the standard files (e.g. config.guess).  This
is usually done with automake --add-missing --force.  I have just
upgraded to automake 1.10 and that one installs a relatively fresh copy
of texinfo.tex - however I'll keep the one mentioned above.

> gnupg-badge-openpgp.gif is missing (and the document

Hmm, the GNU project does not use GUIF files (well the patent recently
expied, so it might be okay now).  Anyway, we have a new logo and the
manual uses that one now.  But it is still missing.  I added the PNG to
the Makefile.am

> The "glossary" is briefly described as "Short descrition of used terms".
> I suppose "description" was meant.  Also, it's better English to say
> "terms used", not "used terms".  This is one of the (few) English
> adjectives whose meaning varies with position.  A "used term" is
> like a used car.  I wouldn't want to use one of those in my nice
> clean expressions.

Fixed.  I will remember this in future.


Thanks,

  Werner



From wk at gnupg.org  Fri May  4 13:48:43 2007
From: wk at gnupg.org (Werner Koch)
Date: Fri, 04 May 2007 13:48:43 +0200
Subject: [Announce] Libgcrypt 1.3.0 (development) released
Message-ID: <87r6pw95d0.fsf@wheatstone.g10code.de>

Hello! 

We are pleased to announce the availability of Libgcrypt 1.3.0.  This
is the first release of a series of development versions ebentually
leading to a new stable 1.4 series.

Libgcrypt is a general purpose library of cryptographic building
blocks.  It is originally based on code used by GnuPG.  It does not
provide any implementaion of OpenPGP or other protocols.  Thorough
understanding of applied cryptography is required to use libgcrypt.


Changes relative to 1.2.4 are:

 * Reading and writing the random seed file is now protected by a
   fcntl style file lock on systems that provide this function.

 * Support for SHA-224 and HMAC using SHA-384 and SHA-512.

 * Support for the SEED cipher.

 * Support for the Camellia cipher.  Note that Camellia is disabled by
   default, and that enabling it changes the license of libgcrypt from
   LGPL to GPL.

 * Support for OFB encryption mode.

 * gcry_mpi_rshift does not anymore truncate the shift count.

 * Reserved algorithm ranges for use by applications.

 * Support for DSA2.

 * The new function gcry_md_debug should be used instead of the
   gcry_md_start_debug and gcry_md_stop_debug macros.

 * New configure option --enable-random-daemon to support a system
   wide random daemon.  The daemon code is experimental and not yet
   very well working.  It will eventually allow to keep a global
   random pool for the sake of short living processes.

 * Non executable stack support is now used by default on systems
   supporting it.

 * Support for Microsoft Windows.

 * Assembler support for the AMD64 architecture.

 * New configure option --enable-mpi-path for optimized builds.

 * Experimental support for ECDSA; should only be used for testing.

 * New control code GCRYCTL_PRINT_CONFIG to print the build
   configuration.


Source code is hosted at the GnuPG FTP server and its mirrors as
listed at http://www.gnupg.org/download/mirrors.html .  On the primary
server the source file and its digital signatures is:

 ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.3.0.tar.bz2 (922k)
 ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt/libgcrypt-1.3.0.tar.bz2.sig

This file is bzip2 compressed.  The SHA-1 checksum is:

38361925fef99715eccb8a1f73110ce2f3c3896a  libgcrypt-1.3.0.tar.bz2

For help on developing with Libgcrypt you should send mail to the
grcypt-devel mailing list [1].

Improving Libgcrypt is costly, but you can help!  We are looking for
organizations that find Libgcrypt useful and wish to contribute back.
You can contribute by reporting bugs, improve the software [2], or by
donating money.

Commercial support contracts for Libgcrypt are available [3], and they
help finance continued maintenance.  g10 Code GmbH, a Duesseldorf
based company, is currently funding Libgcrypt development.  We are
always looking for interesting development projects.


Happy hacking,

  Werner


[1] See http://www.gnupg.org/documentation/mailing-lists.html .
[2] Note that copyright assignments to the FSF are required.
[3] See the service directory at http://www.gnupg.org/service.html .

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 204 bytes
Desc: not available
Url : /pipermail/attachments/20070504/84497c9e/attachment.pgp 
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From nsushkin at sushkins.net  Fri May  4 15:07:20 2007
From: nsushkin at sushkins.net (Nicholas Sushkin)
Date: Fri, 4 May 2007 09:07:20 -0400
Subject: gpgsm 1.9.22 supports no RC2 Algorithm ?
In-Reply-To: <878xc5atpt.fsf@wheatstone.g10code.de>
References: <200705031634.20528.nsushkin@sushkins.net>
	<878xc5atpt.fsf@wheatstone.g10code.de>
Message-ID: <200705040907.30836.nsushkin@sushkins.net>

On Friday 04 May 2007 04:17, Werner Koch wrote: 

> On Thu,  3 May 2007 22:34, nsushkin at sushkins.net said:
> > There has been a bug filed today in Mozilla bugzilla,
> > https://bugzilla.mozilla.org/show_bug.cgi?id=379625. If any of you can
> > vote, track, or help troubleshoot the issue, the affected users
> > (including me) will greatly appreciate.
>
> The issue is simply that Mozilla allows (and even worse, sometimes
> forces) the use of RC2.  This should be fixed asap in Mozilla.
>
> I consider any application using RC2 for encryption not only broken but
> playing a false game with its users by telling them: Your mail has been
> encrypted.  They are not telling them that it is the "NSA approved" 40
> bit cipher used in the dark ages for US-exportable software.
>
> Go and drop RC2!

Werner, 

Did you read the bug report? There may be another problem with the 
encryption protocol negotiation between gpgsm and Thunderbird.

Dropping RC2 has also been requested via a different Thunderbird bug,
https://bugzilla.mozilla.org/show_bug.cgi?id=84213 
The bug status indicates that it has been assigned to a developer on May 
1st. I think it's pretty clear to many that the weak algorithm shouldn't be 
supported and they are working on it. But I think that Thunderbird 
developers may use help of gpgsm developers if you have anything to say 
about the protocol negotiation. See Nelson Bolyard's analysis at
https://bugzilla.mozilla.org/show_bug.cgi?id=379625#c2 

Thank you.
-- 
Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1388 bytes
Desc: not available
Url : /pipermail/attachments/20070504/3d0e6014/attachment.bin 

From nsushkin at sushkins.net  Fri May  4 18:16:26 2007
From: nsushkin at sushkins.net (Nicholas Sushkin)
Date: Fri, 4 May 2007 12:16:26 -0400
Subject: gpgsm 1.9.22 supports no RC2 Algorithm ?
In-Reply-To: <200705040907.30836.nsushkin@sushkins.net>
References: <200705031634.20528.nsushkin@sushkins.net>
	<878xc5atpt.fsf@wheatstone.g10code.de>
	<200705040907.30836.nsushkin@sushkins.net>
Message-ID: <200705041216.31772.nsushkin@sushkins.net>

Werner,

I searched the internet for clarifications on how SMimeCapabilities should 
be used. I found that S/MIME Version 3.1 specifically says that NULLs 
should not be used to encode parameters.

Quoting http://www.apps.ietf.org/rfc/rfc3851.html#sec-2.5.2

"The registered SMIMECapabilities list specifies the parameters for OIDs 
that need them, most notably key lengths in the case of variable-length 
symmetric ciphers. In the event that there are no differentiating 
parameters for a particular OID, the parameters MUST be omitted, and MUST 
NOT be encoded as NULL."

However, as seen in https://bugzilla.mozilla.org/show_bug.cgi?id=379625#c2, 
gpgsm (at least in 1.9.92) generates NULLs.



On Friday 04 May 2007 09:07, Nicholas Sushkin wrote: 

>  But I think that Thunderbird
> developers may use help of gpgsm developers if you have anything to say
> about the protocol negotiation. See Nelson Bolyard's analysis at
> https://bugzilla.mozilla.org/show_bug.cgi?id=379625#c2

-- 
Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1388 bytes
Desc: not available
Url : /pipermail/attachments/20070504/808482b0/attachment.bin 

From thisisnotapipe at hotmail.com  Sat May  5 16:18:55 2007
From: thisisnotapipe at hotmail.com (Bernard Leak)
Date: Sat, 05 May 2007 14:18:55 +0000
Subject: gnupg: a(nother) documentation patch, and configure.ac
Message-ID: <BAY123-F20428DF71C27A09B4D869FCB470@phx.gbl>

Dear List,
               thanks to all responsible for the shiny new release
of libgcrypt.

The version of libgcrypt required for the current live gnupg should be
found and set in configure.ac (the latest stable release is too old,
and this wasn't detected until the build failed).  A check-out from the live
tree made in small hours of this morning, and it builds (so, not too
old, then!).

Should configure.ac still say it's for the '1.9' release, as it does at
the top?  I think it would be useful if configure.ac noted (as it does
for libgcrypt) the latest svn revision number.  Then I could refer to
it unambiguously.

I attach a patch which should make building the docs. in a separate
build tree cleaner (and work).  It has UN*X (LF) -style line-breaks.
A bzipped version should be available for the foreseeable future in

http://www.brenda-arkle.demon.co.uk/patches/gnupg/

Several of the rules merely add to dependency lists.
The only "magic" is that fake.html (a pseudo-target for putting
the images in the gnupg.html output tree) is added AFTER
the automatically-generated dependency list, so it acts as
a sort of "do me last".  Thus, the gnupg.html directory is
assumed to exist already.
If you like, make it squeaky-clean by giving fake.html
dependencies on the copies of the files:

A VERY Gnu Make - dependent version might look like this

HTMLIMAGES = gnupg-logo.png gnupg-card-architecture.png
INSTALLEDHTMLIMAGES = $(foreach i,$(HTMLIMAGES),gnupg.html/$i)

fake.html : gnupg.html $(INSTALLEDHTMLIMAGES)
	echo $(INSTALLEDHTMLIMAGES)

$(INSTALLEDHTMLIMAGES): gnupg.html/%.png : %.png
	cp $< $@

Here HTMLIMAGES and INSTALLEDHTMLIMAGES should
be used as appropriate in the OTHER lists of distribution files,
targets, sources, &c.

Once again (see patch...) an alternative is to invoke 'make'
recursively to provide a 'wrapper' around default rules.
Preconditions are easy: postactions are tiresome.


Bernard Leak.<

_________________________________________________________________
Could you be the guest MSN Movies presenter? Click Here to Audition 
http://www.lightscameraaudition.co.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg-2007-05-05-sepbuild-1.patch.bz2
Type: application/x-bzip
Size: 0 bytes
Desc: not available
Url : /pipermail/attachments/20070505/75996cc7/attachment.bin 

From thisisnotapipe at hotmail.com  Sat May  5 16:19:54 2007
From: thisisnotapipe at hotmail.com (Bernard Leak)
Date: Sat, 05 May 2007 14:19:54 +0000
Subject: gnupg: a(nother) documentation patch, and configure.ac
Message-ID: <BAY123-F24EE2034FC1F7DA9DCD657CB470@phx.gbl>

Dear List,
               thanks to all responsible for the shiny new release
of libgcrypt.

The version of libgcrypt required for the current live gnupg should be
found and set in configure.ac (the latest stable release is too old,
and this wasn't detected until the build failed).  A check-out from the live
tree made in small hours of this morning, and it builds (so, not too
old, then!).

Should configure.ac still say it's for the '1.9' release, as it does at
the top?  I think it would be useful if configure.ac noted (as it does
for libgcrypt) the latest svn revision number.  Then I could refer to
it unambiguously.

I attach a patch which should make building the docs. in a separate
build tree cleaner (and work).  It has UN*X (LF) -style line-breaks.
A bzipped version should be available for the foreseeable future in

http://www.brenda-arkle.demon.co.uk/patches/gnupg/

Several of the rules merely add to dependency lists.
The only "magic" is that fake.html (a pseudo-target for putting
the images in the gnupg.html output tree) is added AFTER
the automatically-generated dependency list, so it acts as
a sort of "do me last".  Thus, the gnupg.html directory is
assumed to exist already.
If you like, make it squeaky-clean by giving fake.html
dependencies on the copies of the files:

A VERY Gnu Make - dependent version might look like this

HTMLIMAGES = gnupg-logo.png gnupg-card-architecture.png
INSTALLEDHTMLIMAGES = $(foreach i,$(HTMLIMAGES),gnupg.html/$i)

fake.html : gnupg.html $(INSTALLEDHTMLIMAGES)
	echo $(INSTALLEDHTMLIMAGES)

$(INSTALLEDHTMLIMAGES): gnupg.html/%.png : %.png
	cp $< $@

Here HTMLIMAGES and INSTALLEDHTMLIMAGES should
be used as appropriate in the OTHER lists of distribution files,
targets, sources, &c.

Once again (see patch...) an alternative is to invoke 'make'
recursively to provide a 'wrapper' around default rules.
Preconditions are easy: postactions are tiresome.


Bernard Leak.<

_________________________________________________________________
Txt a lot? Get Messenger FREE on your mobile. 
https://livemessenger.mobile.uk.msn.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg-2007-05-05-sepbuild-1.patch.bz2
Type: application/x-bzip
Size: 0 bytes
Desc: not available
Url : /pipermail/attachments/20070505/94f06c15/attachment-0001.bin 

From thisisnotapipe at hotmail.com  Sat May  5 16:27:31 2007
From: thisisnotapipe at hotmail.com (Bernard Leak)
Date: Sat, 05 May 2007 14:27:31 +0000
Subject: gnupg: a(nother) documentation patch, and configure.ac
In-Reply-To: <BAY123-F20428DF71C27A09B4D869FCB470@phx.gbl>
Message-ID: <BAY123-F364C91D8522CF42A8A4FA8CB470@phx.gbl>

Dear List,
                sorry - here are a few notes which didn't make it
into my last posting.

Should gnupg-badge-openpgp.* still be in there?
The string 'gnupg-badge' currently only occurs inside these
files themselves, their shadows in .svn, and in .svn/entries,
and the Changelog.  Unless there's an encrypted build script
or something in there, these files now seem to be entirely
useless.

An odditiy: gnupg.ps reports failing to find the subordinate
*.eps sources, but carries on anyway, without an error.
This, in addition to having no way (outside TEXINPUTS)
of adding search paths...

By the way, as usual,
makeinfo --plaintext -o gnupg.txt  <source directory>/doc/gnupg.texi
works fine.


Bernard Leak

_________________________________________________________________
Get Hotmail, News, Sport and Entertainment from MSN on your mobile.  
http://www.msn.txt4content.com/



From ametzler at downhill.at.eu.org  Sat May  5 18:49:07 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 5 May 2007 18:49:07 +0200
Subject: shlib-with-non-pic-code (was: [Announce] Libgcrypt 1.3.0
	(development) released)
References: <87r6pw95d0.fsf__22945.5061410137$1178281125$gmane$org@wheatstone.g10code.de>
Message-ID: <35pug4-ajn.ln1@argenau.downhill.at.eu.org>

Werner Koch <wk at gnupg.org> wrote:
[...]

Hello,

if built on i386, (./configure --build=i486-linux-gnu) I end up with
non-PIC code in the shared library, which is a regression compared to
1.2.4.

SID)ametzler at argenau:/tmp/GCR/libgcrypt11-1.3.0$ objdump --private-headers \
        src/.libs/libgcrypt.so.11.4.0 | grep TEXTREL
  TEXTREL     0x0

(SID)ametzler at argenau:/tmp/GCR/libgcrypt11-1.3.0$ scanelf -qT src/.libs/libgcryp
t.so.11.4.0
  libgcrypt.so.11.4.0: (memory/fake?) [0x476D6] in _gcry_mpih_add_n [0x476A8]
  libgcrypt.so.11.4.0: (memory/fake?) [0x47766] in _gcry_mpih_sub_n [0x47738]
  src/.libs/libgcrypt.so.11.4.0

I do not know how to go on from that, but I will happily try to provide further information.

thanks, cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



From wk at gnupg.org  Mon May  7 16:09:15 2007
From: wk at gnupg.org (Werner Koch)
Date: Mon, 07 May 2007 16:09:15 +0200
Subject: shlib-with-non-pic-code
In-Reply-To: <35pug4-ajn.ln1@argenau.downhill.at.eu.org> (Andreas Metzler's
	message of "Sat\, 5 May 2007 18\:49\:07 +0200")
References: <87r6pw95d0.fsf__22945.5061410137$1178281125$gmane$org@wheatstone.g10code.de>
	<35pug4-ajn.ln1@argenau.downhill.at.eu.org>
Message-ID: <87wszk7mk4.fsf@wheatstone.g10code.de>

On Sat,  5 May 2007 18:49, ametzler at downhill.at.eu.org said:

> I do not know how to go on from that, but I will happily try to provide further information.

Marcus found the problem and we will change the build system.
Automake 1.10 should make all the old build hacks obsolete.


Shalom-Salam,

   Werner



From ametzler at downhill.at.eu.org  Mon May  7 19:40:03 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 7 May 2007 19:40:03 +0200
Subject: shlib-with-non-pic-code
In-Reply-To: <87wszk7mk4.fsf@wheatstone.g10code.de>
References: <87r6pw95d0.fsf__22945.5061410137$1178281125$gmane$org@wheatstone.g10code.de>
	<35pug4-ajn.ln1@argenau.downhill.at.eu.org>
	<87wszk7mk4.fsf@wheatstone.g10code.de>
Message-ID: <20070507174002.GA3706@downhill.g.la>

On 2007-05-07 Werner Koch <wk at gnupg.org> wrote:
> On Sat,  5 May 2007 18:49, ametzler at downhill.at.eu.org said:

>> I do not know how to go on from that, but I will happily try to
>> provide further information.

> Marcus found the problem and we will change the build system.
> Automake 1.10 should make all the old build hacks obsolete.

Splendid. Thanks for the thumbs up.
cu andreas


From wk at gnupg.org  Tue May  8 09:34:09 2007
From: wk at gnupg.org (Werner Koch)
Date: Tue, 08 May 2007 09:34:09 +0200
Subject: gnupg: a(nother) documentation patch, and configure.ac
In-Reply-To: <BAY123-F20428DF71C27A09B4D869FCB470@phx.gbl> (Bernard Leak's
	message of "Sat\, 05 May 2007 14\:18\:55 +0000")
References: <BAY123-F20428DF71C27A09B4D869FCB470@phx.gbl>
Message-ID: <87bqgvwyz2.fsf@wheatstone.g10code.de>

On Sat,  5 May 2007 16:18, thisisnotapipe at hotmail.com said:

> The version of libgcrypt required for the current live gnupg should be
> found and set in configure.ac (the latest stable release is too old,
> and this wasn't detected until the build failed).  A check-out from the live

That was actually a regression in the SVN.  I have fixed it and tested
with libgcrypt 1.2.2.

> Should configure.ac still say it's for the '1.9' release, as it does at
> the top?  I think it would be useful if configure.ac noted (as it does

Changed.

> for libgcrypt) the latest svn revision number.  Then I could refer to
> it unambiguously.

You mean the AC_REVISION?  This is a bit problematic as it does not
indicate whether the whole tree has been updated to this revision.  It
might only be this file.  There is no simple way to check for it. You
need to manually do an

  svn up
  ./autogen.sh --force

to get the correct svn revision into the version string.

> I attach a patch which should make building the docs. in a separate
> build tree cleaner (and work).  It has UN*X (LF) -style line-breaks.
> A bzipped version should be available for the foreseeable future in

Thanks.  I fixed it in another way using the install-html-local target.
The postscript building has also been fixed by changing the DVIPS
command (this is less intrusive that changing default rules).



Shalom-Salam,

   Werner



From wk at gnupg.org  Tue May  8 09:59:26 2007
From: wk at gnupg.org (Werner Koch)
Date: Tue, 08 May 2007 09:59:26 +0200
Subject: gpgsm 1.9.22 supports no RC2 Algorithm ?
In-Reply-To: <200705041216.31772.nsushkin@sushkins.net> (Nicholas Sushkin's
	message of "Fri\, 4 May 2007 12\:16\:26 -0400")
References: <200705031634.20528.nsushkin@sushkins.net>
	<878xc5atpt.fsf@wheatstone.g10code.de>
	<200705040907.30836.nsushkin@sushkins.net>
	<200705041216.31772.nsushkin@sushkins.net>
Message-ID: <873b27wxsx.fsf@wheatstone.g10code.de>

On Fri,  4 May 2007 18:16, nsushkin at sushkins.net said:

> I searched the internet for clarifications on how SMimeCapabilities should 
> be used. I found that S/MIME Version 3.1 specifically says that NULLs 
> should not be used to encode parameters.

That is what the RFC says but not what everone else is doing.  The
capabilities are basically algorithm identifiers and thus we should
apply the same rules to them.  To quote Peter Gutmann's X.509 guide:

|   Another pitfall to be aware of is that algorithms which have no
|   parameters have this specified as a NULL value rather than omitting
|   the parameters field entirely.  The reason for this is that when the
|   1988 syntax for AlgorithmIdentifier was translated into the 1997
|   syntax, the OPTIONAL associated with the AlgorithmIdentifier
|   parameters got lost.  Later it was recovered via a defect report, but
|   by then everyone thought that algorithm parameters were mandatory.
|   Because of this the algorithm parameters should be specified as NULL,
|   regardless of what you read elsewhere.

Thus we do it this way.  Given that gpgsm passed a lot of compatibility
tests [1], I don't see a reason to change it.  IIRC, the test lab once
also did some unoffcial tests with Mozilla and they had a few problems
with it.


Shalom-Salam,

   Werner


[1] http://www.bsi.de/fachthem/verwpki/interoptests/testberichte.htm
   (German)



From wk at gnupg.org  Tue May  8 10:03:21 2007
From: wk at gnupg.org (Werner Koch)
Date: Tue, 08 May 2007 10:03:21 +0200
Subject: gpgsm 1.9.22 supports no RC2 Algorithm ?
In-Reply-To: <200705040907.30836.nsushkin@sushkins.net> (Nicholas Sushkin's
	message of "Fri\, 4 May 2007 09\:07\:20 -0400")
References: <200705031634.20528.nsushkin@sushkins.net>
	<878xc5atpt.fsf@wheatstone.g10code.de>
	<200705040907.30836.nsushkin@sushkins.net>
Message-ID: <87y7jzvj1y.fsf@wheatstone.g10code.de>

On Fri,  4 May 2007 15:07, nsushkin at sushkins.net said:

> Did you read the bug report? There may be another problem with the 
> encryption protocol negotiation between gpgsm and Thunderbird.

I browsed it.  The important point is that Mozilla should never ever use
RC2 for encryption.  Plainly implementing something from one of the
standards is not a viable solution.  See also my other reply.


Salam-Shalom,

   Werner



From nsushkin at sushkins.net  Tue May  8 17:09:48 2007
From: nsushkin at sushkins.net (Nicholas Sushkin)
Date: Tue, 8 May 2007 11:09:48 -0400
Subject: gpgsm 1.9.22 supports no RC2 Algorithm ?
In-Reply-To: <873b27wxsx.fsf@wheatstone.g10code.de>
References: <200705031634.20528.nsushkin@sushkins.net>
	<200705041216.31772.nsushkin@sushkins.net>
	<873b27wxsx.fsf@wheatstone.g10code.de>
Message-ID: <200705081109.53240.nsushkin@sushkins.net>

Werner,

Thanks for looking into this. Thunderbird will be generating RFC syntax, but 
accepting NULLs, so I guess it will work out for now. Hope all the clients 
will be trying to get into compliance with the RFC.

Also, I noticed that the last interop test was done in 2005 and Thunderbird 
was not included. Was that a German government requirement to do the test 
or industry initiative? Hopefully we will see more tests in the future.

On Tuesday 08 May 2007 03:59, Werner Koch wrote: 

> On Fri,  4 May 2007 18:16, nsushkin at sushkins.net said:
> > I searched the internet for clarifications on how SMimeCapabilities
> > should be used. I found that S/MIME Version 3.1 specifically says that
> > NULLs should not be used to encode parameters.
>
> That is what the RFC says but not what everone else is doing.  The
> capabilities are basically algorithm identifiers and thus we should
>
> apply the same rules to them.  To quote Peter Gutmann's X.509 guide:
> |   Another pitfall to be aware of is that algorithms which have no
> |   parameters have this specified as a NULL value rather than omitting
> |   the parameters field entirely.  The reason for this is that when the
> |   1988 syntax for AlgorithmIdentifier was translated into the 1997
> |   syntax, the OPTIONAL associated with the AlgorithmIdentifier
> |   parameters got lost.  Later it was recovered via a defect report, but
> |   by then everyone thought that algorithm parameters were mandatory.
> |   Because of this the algorithm parameters should be specified as NULL,
> |   regardless of what you read elsewhere.
>
> Thus we do it this way.  Given that gpgsm passed a lot of compatibility
> tests [1], I don't see a reason to change it.  IIRC, the test lab once
> also did some unoffcial tests with Mozilla and they had a few problems
> with it.
>
>
> Shalom-Salam,
>
>    Werner
>
>
> [1] http://www.bsi.de/fachthem/verwpki/interoptests/testberichte.htm
>    (German)

-- 
Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1388 bytes
Desc: not available
Url : /pipermail/attachments/20070508/03e078b7/attachment.bin 

From wk at gnupg.org  Wed May  9 12:58:43 2007
From: wk at gnupg.org (Werner Koch)
Date: Wed, 09 May 2007 12:58:43 +0200
Subject: [Announce] GnuPG 2.0.4 released
Message-ID: <87lkfyb6vw.fsf@wheatstone.g10code.de>

Hello!
    
We are pleased to announce the availability of a new stable GnuPG-2
release:  Version 2.0.4

This is maintenance release with a few minor enhancements.

The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication
and data storage.  It can be used to encrypt data, create digital
signatures, help authenticating using Secure Shell and to provide a
framework for public key cryptography.  It includes an advanced key
management facility and is compliant with the OpenPGP and S/MIME
standards.

GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.7) in that
it splits up functionality into several modules.  However, both
versions may be installed alongside without any conflict.  In fact,
the gpg version from GnuPG-1 is able to make use of the gpg-agent as
included in GnuPG-2 and allows for seamless passphrase caching.  The
advantage of GnuPG-1 is its smaller size and the lack of dependency on
other modules at run and build time.  We will keep maintaining GnuPG-1
versions because they are very useful for small systems and for server
based applications requiring only OpenPGP support.

GnuPG is distributed under the terms of the GNU General Public License
(GPL).  GnuPG-2 works best on GNU/Linux or *BSD systems. 


Getting the Software
====================

Please follow the instructions found at http://www.gnupg.org/download/
or read on:

GnuPG 2.0.4 may be downloaded from one of the GnuPG mirror sites or
direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ .  The list of mirrors
can be found at http://www.gnupg.org/mirrors.html .  Note, that GnuPG
is not available at ftp.gnu.org.

On the FTP server and ist mirrors you should find the following files
in the gnupg/ directory:

  gnupg-2.0.4.tar.bz2 (3491k)
  gnupg-2.0.4.tar.bz2.sig

      GnuPG source compressed using BZIP2 and OpenPGP signature.

  gnupg-2.0.3-2.0.4.diff.bz2 (237k)

      A patch file to upgrade a 2.0.3 GnuPG source tree.  This patch
      does not include updates of the language files.

Note, that we don't distribute gzip compressed tarballs.  


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a trusted version of GnuPG installed, you
   can simply check the supplied signature.  For example to check the
   signature of the file gnupg-2.0.4.tar.bz2 you would use this command:

     gpg --verify gnupg-2.0.4.tar.bz2.sig

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by that signing key.  Make sure that you have the right key,
   either by checking the fingerprint of that key with other sources
   or by checking that the key has been signed by a trustworthy other
   key.  Note, that you can retrieve the signing key using the command

     finger wk ,at' g10code.com

   or using a keyserver like

     gpg --recv-key 1CE0C630

   The distribution key 1CE0C630 is signed by the well known key
   5B0358A2.  If you get an key expired message, you should retrieve a
   fresh copy as the expiration date might have been prolonged.

   NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE
   INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION!

 * If you are not able to use an old version of GnuPG, you have to verify
   the SHA-1 checksum.  Assuming you downloaded the file
   gnupg-2.0.4.tar.bz2, you would run the sha1sum command like this:

     sha1sum gnupg-2.0.4.tar.bz2

   and check that the output matches the first line from the
   following list:

cc230636bb4226f6d7ac2db9b259d8e7f5529f84  gnupg-2.0.4.tar.bz2
9f1ad40f88ef567498b07dab718defc2ac319c35  gnupg-2.0.3-2.0.4.diff.bz2



What's New
===========

 * The server mode key listing commands are now also working for
   systems without the funopen/fopencookie API.

 * PKCS#12 import now tries several encodings in case the passphrase
   was not utf-8 encoded.  New option --p12-charset for gpgsm.

 * Improved the libgcrypt logging support in all modules.


Internationalization
====================

GnuPG comes with support for 27 languages.  Due to a lot of new and
changed strings most translations are not entirely complete.  The
Swedish, Turkish, German and Russian translations close to be complete.


Documentation
=============

We are currently working on an installation guide to explain in more
detail how to configure the new features.  As of now the chapters on
gpg-agent and gpgsm include brief information on how to set up the
whole thing.  Please watch the GnuPG website for updates of the
documentation.  In the meantime you may search the GnuPG mailing list
archives or ask on the gnupg-users mailing lists for advise on how to
solve problems.  Many of the new features are around for several years
and thus enough public knowledge is already available.  KDE's KMail is
the most prominent user of GnuPG.  In fact it has been developed along
with the Kmail folks.  Mutt users might want to use the configure
option "--enable-gpgme" and "set use_crypt_gpgme" in ~/.muttrc to make
use of GnuPG-2 to enable S/MIME in addition to a reworked OpenPGP
support.

The manual is also available online in HTML format at
  http://www.gnupg.org/documentation/manuals/gnupg/ 
and as an PDF at
  http://www.gnupg.org/documentation/manuals/gnupg.pdf .


Support
=======

Improving GnuPG is costly, but you can help!  We are looking for
organizations that find GnuPG useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or by donating
money.

Commercial support contracts for GnuPG are available, and they help
finance continued maintenance.  g10 Code GmbH, a Duesseldorf based
company owned and headed by GnuPG's principal author, is currently
funding GnuPG development.  We are always looking for interesting
development projects.

The GnuPG service directory is available at:

  http://www.gnupg.org/service.html


Thanks
======

We have to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word or answering questions on the mailing
lists.  


Happy Hacking,

  The GnuPG Team (David, Marcus, Werner and all other contributors)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : /pipermail/attachments/20070509/6d957c08/attachment-0001.pgp 
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From wk at gnupg.org  Wed May  9 13:54:52 2007
From: wk at gnupg.org (Werner Koch)
Date: Wed, 09 May 2007 13:54:52 +0200
Subject: gpgsm 1.9.22 supports no RC2 Algorithm ?
In-Reply-To: <200705081109.53240.nsushkin@sushkins.net> (Nicholas Sushkin's
	message of "Tue\, 8 May 2007 11\:09\:48 -0400")
References: <200705031634.20528.nsushkin@sushkins.net>
	<200705041216.31772.nsushkin@sushkins.net>
	<873b27wxsx.fsf@wheatstone.g10code.de>
	<200705081109.53240.nsushkin@sushkins.net>
Message-ID: <876472b4ab.fsf@wheatstone.g10code.de>

On Tue,  8 May 2007 17:09, nsushkin at sushkins.net said:

> accepting NULLs, so I guess it will work out for now. Hope all the clients 
> will be trying to get into compliance with the RFC.

Recall that X.509 is not defined by an RFC.  PKIX is just one profile of
X.509.  There are myriads of other profiles.  If you want something
better defined than X.509 you should use OpenPGP ;-)

> Also, I noticed that the last interop test was done in 2005 and Thunderbird 
> was not included. Was that a German government requirement to do the test 
> or industry initiative? Hopefully we will see more tests in the future.

These tests are due to a governement initiative to help making different
implementations work together.


Salam-Shalom,

   Werner




From marcus.brinkmann at ruhr-uni-bochum.de  Wed May  9 20:20:23 2007
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Wed, 09 May 2007 20:20:23 +0200
Subject: shlib-with-non-pic-code
In-Reply-To: <20070507174002.GA3706@downhill.g.la>
References: <87r6pw95d0.fsf__22945.5061410137$1178281125$gmane$org@wheatstone.g10code.de>
	<35pug4-ajn.ln1@argenau.downhill.at.eu.org>
	<87wszk7mk4.fsf@wheatstone.g10code.de>
	<20070507174002.GA3706@downhill.g.la>
Message-ID: <87wszhzwns.wl%marcus.brinkmann@ruhr-uni-bochum.de>

At Mon, 7 May 2007 19:40:03 +0200,
Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
> 
> On 2007-05-07 Werner Koch <wk at gnupg.org> wrote:
> > On Sat,  5 May 2007 18:49, ametzler at downhill.at.eu.org said:
> 
> >> I do not know how to go on from that, but I will happily try to
> >> provide further information.
> 
> > Marcus found the problem and we will change the build system.
> > Automake 1.10 should make all the old build hacks obsolete.
> 
> Splendid. Thanks for the thumbs up.

Hi,

I applied the below change, which removes the relocations for me.
Thanks for the report!

2007-05-09  Marcus Brinkmann  <marcus at g10code.de>

        * configure.ac (ac_cv_mpi_config_done): Unused variable removed.
        (ac_cv_mpi_mod_list, MPI_MOD_LIST_LO, MPI_MOD_LIST_O): Removed.
        (MPI_MOD_ASM_MPIH_ADD1, MPI_MOD_ASM_MPIH_SUB1,
        MPI_MOD_ASM_MPIH_MUL1, MPI_MOD_ASM_MPIH_MUL2,
        MPI_MOD_ASM_MPIH_MUL3, MPI_MOD_ASM_MPIH_LSHIFT,
        MPI_MOD_ASM_MPIH_RSHIFT, MPI_MOD_ASM_MPIH_UDIV,
        MPI_MOD_ASM_MPIH_UDIV_QRNND, MPI_MOD_C_MPIH_ADD1,
        MPI_MOD_C_MPIH_SUB1, MPI_MOD_C_MPIH_MUL1, MPI_MOD_C_MPIH_MUL2,
        MPI_MOD_C_MPIH_MUL3, MPI_MOD_C_MPIH_LSHIFT, MPI_MOD_C_MPIH_RSHIFT,
        MPI_MOD_C_MPIH_UDIV, MPI_MOD_C_MPIH_UDIV_QRNND): New automake
        variables.

mpi/
2007-05-09  Marcus Brinkmann  <marcus at g10code.de>

        * config.links: Rename assembler file links by suffixing "-asm".
        * Makefile.am (CCASCOMPILE, LTCCASCOMPILE, CLEANFILES,
        libmpi_la_LIBADD, libmpi_la_DEPENDENCIES, SUFFIXES, .S.o, .S.obj,
        .S.lo): Removed variables and targets.
        (mpih_add1, mpih_sub1, mpih_mul1, mpih_mul2, mpih_mul3,
        mpih_lshift, mpih_rshift, mpih_udiv, mpih_udiv_qrnnd,
        nodist_libmpi_la_SOURCES): New variables.
        (DISTCLEANFILES): Rename assembler file links by suffixing "-asm".
        Add variants for C file links.



From gnupg-devel at mlists.thewrittenword.com  Fri May 11 04:01:14 2007
From: gnupg-devel at mlists.thewrittenword.com (Peter O'Gorman)
Date: Thu, 10 May 2007 21:01:14 -0500
Subject: a few patches for gnupg-2.0.4
Message-ID: <20070511020114.GA4300@acer.localdomain>

Hi,

We just built gnupg-2.0.4, thanks. We did make some changes though.
HP-UX 10.20 does not have dlopen() and its gmtime_r returns 0 on
success.

Added a configure test to see if #pragma weak works, and another test
for socklen_t (we could have used to socklen_t test from gnulib, but
this one seemed somehow better at the time).

Tru64-4.0 does not have snprintf and IRIX6.5 does not have strsep, we
added these gnulib modules (patches not attached, do you want them?).

AIX-4.3.3 compiler does not like ',' at the end of enum.

Some older compilers did not like the key_rsa_valid.string construct,
replaced with #define.

HP-UX compilers bailed when they saw 'static const char const
*charsets[]', so we removed a const.

IRIX and other compilers refuse to do pointer math on void* pointers.
'The expression must be a pointer to a complete object type.'

Some compilers bailed with the extra semi-colon in 'int error;;'

We wanted to do a configure check for __func__, but it seems as
though the file asschk.c does not #include <config.h> and may be
meant as a standalone? So we used preprocessor defines to get it
compiling. SUNPRO_C on solaris2.6 did not like the #define die.

We built with curl support everywhere and found that some libraries
were not added in this case.

Thank you,
Peter
-------------- next part --------------
Index: configure.ac
===================================================================
--- configure.ac.orig	2007-05-10 22:09:34.587106000 +0000
+++ configure.ac	2007-05-10 22:09:38.765314000 +0000
@@ -459,8 +459,14 @@
 AC_SYS_LARGEFILE
 GNUPG_CHECK_FAQPROG
 GNUPG_CHECK_USTAR
-
-
+GPG_TYPE_SOCKLEN_T
+AC_CACHE_CHECK([for pragma weak],[gpg_cv_pragma_weak],[
+AC_TRY_COMPILE([
+#pragma weak pth_fork
+],[],[gpg_cv_pragma_weak=yes],[gpg_cv_pragma_weak=no])])
+if test "x$gpg_cv_pragma_weak" = "xyes"; then
+AC_DEFINE([HAVE_PRAGMA_WEAK],[1],[define if pragma weak works])
+fi
 try_gettext=yes
 have_dosish_system=no
 have_w32_system=no
@@ -625,7 +611,7 @@
 #
 gnupg_dlopen_save_libs="$LIBS"
 LIBS=""
-AC_SEARCH_LIBS(dlopen, c dl,,,)
+AC_SEARCH_LIBS(dlopen, c dl,,[AC_SEARCH_LIBS(shl_load, dld,,,)],)
 DL_LIBS=$LIBS
 AC_SUBST(DL_LIBS)
 LIBS="$gnupg_dlopen_save_libs"
@@ -890,7 +876,7 @@
 #
 AC_HEADER_STDC
 AC_CHECK_HEADERS([string.h unistd.h langinfo.h termio.h locale.h getopt.h])
-AC_CHECK_HEADERS([pty.h pwd.h inttypes.h])
+AC_CHECK_HEADERS([pty.h pwd.h inttypes.h dlfcn.h dl.h])
 AC_HEADER_TIME
 
 
@@ -986,7 +972,7 @@
 #
 gl_SOURCE_BASE([gl])
 gl_M4_BASE([gl/m4])
-gl_MODULES([setenv mkdtemp vasprintf xsize])
+gl_MODULES([setenv mkdtemp vasprintf xsize snprintf strsep])
 gl_INIT
 
 
Index: keyserver/Makefile.am
===================================================================
--- keyserver/Makefile.am.orig	2007-05-10 22:09:34.828908000 +0000
+++ keyserver/Makefile.am	2007-05-11 00:25:45.228451000 +0000
@@ -45,7 +45,6 @@
                       $(NETLIBS) $(other_libs)
 
 gpg2keys_finger_SOURCES = gpgkeys_finger.c ksutil.c ksutil.h no-libgcrypt.c
-gpg2keys_finger_CPPFLAGS = $(AM_CPPFLAGS)
 gpg2keys_finger_LDADD = $(common_libs) $(GPG_ERROR_LIBS) \
                         $(NETLIBS) $(other_libs)
 
@@ -61,11 +60,15 @@
 gpg2keys_hkp_CPPFLAGS = $(AM_CPPFLAGS)
 gpg2keys_hkp_LDADD = $(common_libs) $(GPG_ERROR_LIBS) $(NETLIBS) $(DNSLIBS) \
 	             $(other_libs) 
+gpg2keys_finger_CPPFLAGS = $(AM_CPPFLAGS)
 else
 gpg2keys_curl_CPPFLAGS = $(LIBCURL_CPPFLAGS) $(AM_CPPFLAGS)
-gpg2keys_curl_LDADD = $(LIBCURL) $(GETOPT)
+gpg2keys_curl_LDADD = $(common_libs) $(LIBCURL)  $(GPG_ERROR_LIBS) $(GETOPT) \
+		$(NETLIBS) $(DNSLIBS) $(other_libs)
 gpg2keys_hkp_CPPFLAGS = $(LIBCURL_CPPFLAGS) $(AM_CPPFLAGS)
-gpg2keys_hkp_LDADD = $(LIBCURL) $(GETOPT)
+gpg2keys_hkp_LDADD = $(common_libs) $(LIBCURL)  $(GPG_ERROR_LIBS) $(GETOPT) \
+		$(NETLIBS) $(DNSLIBS) $(other_libs)
+gpg2keys_finger_CPPFLAGS = $(LIBCURL_CPPFLAGS) $(AM_CPPFLAGS)
 endif
 
 # Make sure that all libs are build before we use them.  This is
Index: tests/asschk.c
===================================================================
--- tests/asschk.c.orig	2007-05-10 22:09:34.865014000 +0000
+++ tests/asschk.c	2007-05-10 22:09:38.944579000 +0000
@@ -121,13 +121,13 @@
 # if __GNUC__ >= 2
 #  define __func__ __FUNCTION__
 # else
-/* Let's try our luck here.  Some systems may provide __func__ without
-   providing __STDC_VERSION__ 199901L.  */
-#  if 0
 #   define __func__ "<unknown>"
-#  endif
+#   define _NO_REDEF_DIE_ 
 # endif
 #endif
+#if __SUNPRO_C<=0x530
+#   define _NO_REDEF_DIE_
+#endif
 
 #define spacep(p) (*(p) == ' ' || *(p) == '\t')
 
@@ -138,7 +138,7 @@
   LINE_ERR,
   LINE_STAT,
   LINE_DATA,
-  LINE_END,
+  LINE_END
 } LINETYPE;
 
 typedef enum {
@@ -200,9 +200,9 @@
 
   exit (1);
 }
-
+#ifndef _NO_REDEF_DIE_
 #define die(format, args...) (die) ("%s: " format, __func__ , ##args)
-
+#endif
 static void
 err (const char *format, ...)
 {
@@ -310,7 +310,7 @@
 	{
 	  int i;
 
-	  printf ("%s: read \"", __FUNCTION__);
+	  printf ("%s: read \"",__func__);
 	  for (i = 0; i < n; i ++)
 	    putc (buf[i], stdout);
 	  printf ("\"\n");
Index: agent/learncard.c
===================================================================
--- agent/learncard.c.orig	2007-05-10 22:09:34.901120000 +0000
+++ agent/learncard.c	2007-05-10 22:09:38.985453000 +0000
@@ -78,7 +78,7 @@
 typedef struct sinfo_s *SINFO;  
 
 struct sinfo_cb_parm_s {
-  int error;;
+  int error;
   SINFO info;
 };
 
Index: scd/app-openpgp.c
===================================================================
--- scd/app-openpgp.c.orig	2007-05-10 22:09:34.997628000 +0000
+++ scd/app-openpgp.c	2007-05-10 22:09:39.034018000 +0000
@@ -2223,13 +2223,13 @@
   else if (indatalen == (15 + 20) && hashalgo == GCRY_MD_SHA1
            && !memcmp (indata, sha1_prefix, 15))
     {
-      indata += 15;
+      indata = (char *)indata + 15;
       indatalen -= 15;
     }
   else if (indatalen == (15 + 20) && hashalgo == GCRY_MD_RMD160
            && !memcmp (indata, rmd160_prefix, 15))
     {
-      indata += 15;
+      indata = (char *)indata + 15;
       indatalen -= 15;
     }
   else
Index: m4/socklen.m4
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ m4/socklen.m4	2007-05-10 22:09:39.225443000 +0000
@@ -0,0 +1,42 @@
+dnl Copyright (C) 2005, 2006, 2007 Free Software Foundation, Inc.
+dnl This file is free software; the Free Software Foundation
+dnl gives unlimited permission to copy and/or distribute it,
+dnl with or without modifications, as long as this notice is preserved.
+
+dnl From Albert Chin, Windows fixes from Simon Josefsson.
+
+dnl Check for socklen_t: historically on BSD it is an int, and in
+dnl POSIX 1g it is a type of its own, but some platforms use different
+dnl types for the argument to getsockopt, getpeername, etc.  So we
+dnl have to test to find something that will work.
+
+dnl Windows fixes removed for db. Functions renamed, basic check
+dnl remains the same though.
+
+AC_DEFUN([GPG_TYPE_SOCKLEN_T],[
+   AC_CHECK_HEADERS_ONCE(sys/socket.h)
+     AC_MSG_CHECKING([for socklen_t or equivalent])
+      AC_CACHE_VAL([gpg_cv_socklen_t_equiv],[
+       gpg_cv_socklen_t_equiv=
+	   for t in socklen_t int size_t "unsigned int" "long int" "unsigned long int"; do
+	     AC_TRY_COMPILE(
+       [#include <sys/types.h>
+         #if HAVE_SYS_SOCKET_H
+         # include <sys/socket.h>
+         #elif HAVE_WS2TCPIP_H
+         # include <ws2tcpip.h>
+         #endif],
+        [$t len;
+         getpeername (0, 0, &len);],
+	       [gpg_cv_socklen_t_equiv="$t"])
+	     test "$gpg_cv_socklen_t_equiv" != "" && break
+	   done
+      ])
+      if test "$gpg_cv_socklen_t_equiv" = ""; then
+	AC_MSG_ERROR([Cannot find a type to use in place of socklen_t])
+      fi
+      AC_MSG_RESULT([$gpg_cv_socklen_t_equiv])
+	  if test "$gpg_cv_socklen_t_equiv" != "socklen_t"; then
+      AC_DEFINE_UNQUOTED([socklen_t], [$gpg_cv_socklen_t_equiv],
+	[type to use in place of socklen_t if not defined])
+	  fi])
Index: common/exechelp.c
===================================================================
--- common/exechelp.c.orig	2007-05-10 22:09:35.045872000 +0000
+++ common/exechelp.c	2007-05-10 22:09:39.251034000 +0000
@@ -61,7 +61,7 @@
    here. Using a weak symbol works but is not portable - we should
    provide a an explicit dummy pth module instead of using the
    pragma.  */ 
-#ifndef _WIN32
+#ifdef HAVE_PRAGMA_WEAK 
 #pragma weak pth_fork
 #pragma weak pth_waitpid
 #endif
Index: jnlib/Makefile.am
===================================================================
--- jnlib/Makefile.am.orig	2007-05-10 22:09:36.314332000 +0000
+++ jnlib/Makefile.am	2007-05-10 22:09:41.405833000 +0000
@@ -24,7 +24,7 @@
 
 EXTRA_DIST = README
 
-AM_CPPFLAGS = -I$(top_srcdir)/intl
+AM_CPPFLAGS = -I$(top_srcdir)/gl -I../gl  -I$(top_srcdir)/intl
 
 # We need libgcrypt because libjnlib-config includes gcrypt.h
 AM_CFLAGS = $(LIBGCRYPT_CFLAGS)
Index: agent/t-protect.c
===================================================================
--- agent/t-protect.c.orig	2007-05-10 22:09:34.949440000 +0000
+++ agent/t-protect.c	2007-05-10 22:09:41.443167000 +0000
@@ -48,97 +48,93 @@
     const char *string;
   };
   /* Valid RSA key.  */
-  struct key_spec key_rsa_valid =
-    {
-      "\x28\x31\x31\x3A\x70\x72\x69\x76\x61\x74\x65\x2D\x6B\x65\x79\x28\x33\x3A\x72\x73"
-      "\x61\x28\x31\x3A\x6E\x31\x32\x39\x3A\x00\xB6\xB5\x09\x59\x6A\x9E\xCA\xBC\x93\x92"
-      "\x12\xF8\x91\xE6\x56\xA6\x26\xBA\x07\xDA\x85\x21\xA9\xCA\xD4\xC0\x8E\x64\x0C\x04"
-      "\x05\x2F\xBB\x87\xF4\x24\xEF\x1A\x02\x75\xA4\x8A\x92\x99\xAC\x9D\xB6\x9A\xBE\x3D"
-      "\x01\x24\xE6\xC7\x56\xB1\xF7\xDF\xB9\xB8\x42\xD6\x25\x1A\xEA\x6E\xE8\x53\x90\x49"
-      "\x5C\xAD\xA7\x3D\x67\x15\x37\xFC\xE5\x85\x0A\x93\x2F\x32\xBA\xB6\x0A\xB1\xAC\x1F"
-      "\x85\x2C\x1F\x83\xC6\x25\xE7\xA7\xD7\x0C\xDA\x9E\xF1\x6D\x5C\x8E\x47\x73\x9D\x77"
-      "\xDF\x59\x26\x1A\xBE\x84\x54\x80\x7F\xF4\x41\xE1\x43\xFB\xD3\x7F\x85\x45\x29\x28"
-      "\x31\x3A\x65\x33\x3A\x01\x00\x01\x29\x28\x31\x3A\x64\x31\x32\x38\x3A\x07\x7A\xD3"
-      "\xDE\x28\x42\x45\xF4\x80\x6A\x1B\x82\xB7\x9E\x61\x6F\xBD\xE8\x21\xC8\x2D\x69\x1A"
-      "\x65\x66\x5E\x57\xB5\xFA\xD3\xF3\x4E\x67\xF4\x01\xE7\xBD\x2E\x28\x69\x9E\x89\xD9"
-      "\xC4\x96\xCF\x82\x19\x45\xAE\x83\xAC\x7A\x12\x31\x17\x6A\x19\x6B\xA6\x02\x7E\x77"
-      "\xD8\x57\x89\x05\x5D\x50\x40\x4A\x7A\x2A\x95\xB1\x51\x2F\x91\xF1\x90\xBB\xAE\xF7"
-      "\x30\xED\x55\x0D\x22\x7D\x51\x2F\x89\xC0\xCD\xB3\x1A\xC0\x6F\xA9\xA1\x95\x03\xDD"
-      "\xF6\xB6\x6D\x0B\x42\xB9\x69\x1B\xFD\x61\x40\xEC\x17\x20\xFF\xC4\x8A\xE0\x0C\x34"
-      "\x79\x6D\xC8\x99\xE5\x29\x28\x31\x3A\x70\x36\x35\x3A\x00\xD5\x86\xC7\x8E\x5F\x1B"
-      "\x4B\xF2\xE7\xCD\x7A\x04\xCA\x09\x19\x11\x70\x6F\x19\x78\x8B\x93\xE4\x4E\xE2\x0A"
-      "\xAF\x46\x2E\x83\x63\xE9\x8A\x72\x25\x3E\xD8\x45\xCC\xBF\x24\x81\xBB\x35\x1E\x85"
-      "\x57\xC8\x5B\xCF\xFF\x0D\xAB\xDB\xFF\x8E\x26\xA7\x9A\x09\x38\x09\x6F\x27\x29\x28"
-      "\x31\x3A\x71\x36\x35\x3A\x00\xDB\x0C\xDF\x60\xF2\x6F\x2A\x29\x6C\x88\xD6\xBF\x9F"
-      "\x8E\x5B\xE4\x5C\x0D\xDD\x71\x3C\x96\xCC\x73\xEB\xCB\x48\xB0\x61\x74\x09\x43\xF2"
-      "\x1D\x2A\x93\xD6\xE4\x2A\x72\x11\xE7\xF0\x2A\x95\xDC\xED\x6C\x39\x0A\x67\xAD\x21"
-      "\xEC\xF7\x39\xAE\x8A\x0C\xA4\x6F\xF2\xEB\xB3\x29\x28\x31\x3A\x75\x36\x34\x3A\x33"
-      "\x14\x91\x95\xF1\x69\x12\xDB\x20\xA4\x8D\x02\x0D\xBC\x3B\x9E\x38\x81\xB3\x9D\x72"
-      "\x2B\xF7\x93\x78\xF6\x34\x0F\x43\x14\x8A\x6E\x9F\xC5\xF5\x3E\x28\x53\xB7\x38\x7B"
-      "\xA4\x44\x3B\xA5\x3A\x52\xFC\xA8\x17\x3D\xE6\xE8\x5B\x42\xF9\x78\x3D\x4A\x78\x17"
+#define key_rsa_valid \
+      "\x28\x31\x31\x3A\x70\x72\x69\x76\x61\x74\x65\x2D\x6B\x65\x79\x28\x33\x3A\x72\x73" \
+      "\x61\x28\x31\x3A\x6E\x31\x32\x39\x3A\x00\xB6\xB5\x09\x59\x6A\x9E\xCA\xBC\x93\x92" \
+      "\x12\xF8\x91\xE6\x56\xA6\x26\xBA\x07\xDA\x85\x21\xA9\xCA\xD4\xC0\x8E\x64\x0C\x04" \
+      "\x05\x2F\xBB\x87\xF4\x24\xEF\x1A\x02\x75\xA4\x8A\x92\x99\xAC\x9D\xB6\x9A\xBE\x3D" \
+      "\x01\x24\xE6\xC7\x56\xB1\xF7\xDF\xB9\xB8\x42\xD6\x25\x1A\xEA\x6E\xE8\x53\x90\x49" \
+      "\x5C\xAD\xA7\x3D\x67\x15\x37\xFC\xE5\x85\x0A\x93\x2F\x32\xBA\xB6\x0A\xB1\xAC\x1F" \
+      "\x85\x2C\x1F\x83\xC6\x25\xE7\xA7\xD7\x0C\xDA\x9E\xF1\x6D\x5C\x8E\x47\x73\x9D\x77" \
+      "\xDF\x59\x26\x1A\xBE\x84\x54\x80\x7F\xF4\x41\xE1\x43\xFB\xD3\x7F\x85\x45\x29\x28" \
+      "\x31\x3A\x65\x33\x3A\x01\x00\x01\x29\x28\x31\x3A\x64\x31\x32\x38\x3A\x07\x7A\xD3" \
+      "\xDE\x28\x42\x45\xF4\x80\x6A\x1B\x82\xB7\x9E\x61\x6F\xBD\xE8\x21\xC8\x2D\x69\x1A" \
+      "\x65\x66\x5E\x57\xB5\xFA\xD3\xF3\x4E\x67\xF4\x01\xE7\xBD\x2E\x28\x69\x9E\x89\xD9" \
+      "\xC4\x96\xCF\x82\x19\x45\xAE\x83\xAC\x7A\x12\x31\x17\x6A\x19\x6B\xA6\x02\x7E\x77" \
+      "\xD8\x57\x89\x05\x5D\x50\x40\x4A\x7A\x2A\x95\xB1\x51\x2F\x91\xF1\x90\xBB\xAE\xF7" \
+      "\x30\xED\x55\x0D\x22\x7D\x51\x2F\x89\xC0\xCD\xB3\x1A\xC0\x6F\xA9\xA1\x95\x03\xDD" \
+      "\xF6\xB6\x6D\x0B\x42\xB9\x69\x1B\xFD\x61\x40\xEC\x17\x20\xFF\xC4\x8A\xE0\x0C\x34" \
+      "\x79\x6D\xC8\x99\xE5\x29\x28\x31\x3A\x70\x36\x35\x3A\x00\xD5\x86\xC7\x8E\x5F\x1B" \
+      "\x4B\xF2\xE7\xCD\x7A\x04\xCA\x09\x19\x11\x70\x6F\x19\x78\x8B\x93\xE4\x4E\xE2\x0A" \
+      "\xAF\x46\x2E\x83\x63\xE9\x8A\x72\x25\x3E\xD8\x45\xCC\xBF\x24\x81\xBB\x35\x1E\x85" \
+      "\x57\xC8\x5B\xCF\xFF\x0D\xAB\xDB\xFF\x8E\x26\xA7\x9A\x09\x38\x09\x6F\x27\x29\x28" \
+      "\x31\x3A\x71\x36\x35\x3A\x00\xDB\x0C\xDF\x60\xF2\x6F\x2A\x29\x6C\x88\xD6\xBF\x9F" \
+      "\x8E\x5B\xE4\x5C\x0D\xDD\x71\x3C\x96\xCC\x73\xEB\xCB\x48\xB0\x61\x74\x09\x43\xF2" \
+      "\x1D\x2A\x93\xD6\xE4\x2A\x72\x11\xE7\xF0\x2A\x95\xDC\xED\x6C\x39\x0A\x67\xAD\x21" \
+      "\xEC\xF7\x39\xAE\x8A\x0C\xA4\x6F\xF2\xEB\xB3\x29\x28\x31\x3A\x75\x36\x34\x3A\x33" \
+      "\x14\x91\x95\xF1\x69\x12\xDB\x20\xA4\x8D\x02\x0D\xBC\x3B\x9E\x38\x81\xB3\x9D\x72" \
+      "\x2B\xF7\x93\x78\xF6\x34\x0F\x43\x14\x8A\x6E\x9F\xC5\xF5\x3E\x28\x53\xB7\x38\x7B" \
+      "\xA4\x44\x3B\xA5\x3A\x52\xFC\xA8\x17\x3D\xE6\xE8\x5B\x42\xF9\x78\x3D\x4A\x78\x17" \
       "\xD0\x68\x0B\x29\x29\x29\x00"
-    };
+
   /* This RSA key is missing the last closing brace.  */
-  struct key_spec key_rsa_bogus_0 =
-    {
-      "\x28\x31\x31\x3A\x70\x72\x69\x76\x61\x74\x65\x2D\x6B\x65\x79\x28\x33\x3A\x72\x73"
-      "\x61\x28\x31\x3A\x6E\x31\x32\x39\x3A\x00\xB6\xB5\x09\x59\x6A\x9E\xCA\xBC\x93\x92"
-      "\x12\xF8\x91\xE6\x56\xA6\x26\xBA\x07\xDA\x85\x21\xA9\xCA\xD4\xC0\x8E\x64\x0C\x04"
-      "\x05\x2F\xBB\x87\xF4\x24\xEF\x1A\x02\x75\xA4\x8A\x92\x99\xAC\x9D\xB6\x9A\xBE\x3D"
-      "\x01\x24\xE6\xC7\x56\xB1\xF7\xDF\xB9\xB8\x42\xD6\x25\x1A\xEA\x6E\xE8\x53\x90\x49"
-      "\x5C\xAD\xA7\x3D\x67\x15\x37\xFC\xE5\x85\x0A\x93\x2F\x32\xBA\xB6\x0A\xB1\xAC\x1F"
-      "\x85\x2C\x1F\x83\xC6\x25\xE7\xA7\xD7\x0C\xDA\x9E\xF1\x6D\x5C\x8E\x47\x73\x9D\x77"
-      "\xDF\x59\x26\x1A\xBE\x84\x54\x80\x7F\xF4\x41\xE1\x43\xFB\xD3\x7F\x85\x45\x29\x28"
-      "\x31\x3A\x65\x33\x3A\x01\x00\x01\x29\x28\x31\x3A\x64\x31\x32\x38\x3A\x07\x7A\xD3"
-      "\xDE\x28\x42\x45\xF4\x80\x6A\x1B\x82\xB7\x9E\x61\x6F\xBD\xE8\x21\xC8\x2D\x69\x1A"
-      "\x65\x66\x5E\x57\xB5\xFA\xD3\xF3\x4E\x67\xF4\x01\xE7\xBD\x2E\x28\x69\x9E\x89\xD9"
-      "\xC4\x96\xCF\x82\x19\x45\xAE\x83\xAC\x7A\x12\x31\x17\x6A\x19\x6B\xA6\x02\x7E\x77"
-      "\xD8\x57\x89\x05\x5D\x50\x40\x4A\x7A\x2A\x95\xB1\x51\x2F\x91\xF1\x90\xBB\xAE\xF7"
-      "\x30\xED\x55\x0D\x22\x7D\x51\x2F\x89\xC0\xCD\xB3\x1A\xC0\x6F\xA9\xA1\x95\x03\xDD"
-      "\xF6\xB6\x6D\x0B\x42\xB9\x69\x1B\xFD\x61\x40\xEC\x17\x20\xFF\xC4\x8A\xE0\x0C\x34"
-      "\x79\x6D\xC8\x99\xE5\x29\x28\x31\x3A\x70\x36\x35\x3A\x00\xD5\x86\xC7\x8E\x5F\x1B"
-      "\x4B\xF2\xE7\xCD\x7A\x04\xCA\x09\x19\x11\x70\x6F\x19\x78\x8B\x93\xE4\x4E\xE2\x0A"
-      "\xAF\x46\x2E\x83\x63\xE9\x8A\x72\x25\x3E\xD8\x45\xCC\xBF\x24\x81\xBB\x35\x1E\x85"
-      "\x57\xC8\x5B\xCF\xFF\x0D\xAB\xDB\xFF\x8E\x26\xA7\x9A\x09\x38\x09\x6F\x27\x29\x28"
-      "\x31\x3A\x71\x36\x35\x3A\x00\xDB\x0C\xDF\x60\xF2\x6F\x2A\x29\x6C\x88\xD6\xBF\x9F"
-      "\x8E\x5B\xE4\x5C\x0D\xDD\x71\x3C\x96\xCC\x73\xEB\xCB\x48\xB0\x61\x74\x09\x43\xF2"
-      "\x1D\x2A\x93\xD6\xE4\x2A\x72\x11\xE7\xF0\x2A\x95\xDC\xED\x6C\x39\x0A\x67\xAD\x21"
-      "\xEC\xF7\x39\xAE\x8A\x0C\xA4\x6F\xF2\xEB\xB3\x29\x28\x31\x3A\x75\x36\x34\x3A\x33"
-      "\x14\x91\x95\xF1\x69\x12\xDB\x20\xA4\x8D\x02\x0D\xBC\x3B\x9E\x38\x81\xB3\x9D\x72"
-      "\x2B\xF7\x93\x78\xF6\x34\x0F\x43\x14\x8A\x6E\x9F\xC5\xF5\x3E\x28\x53\xB7\x38\x7B"
-      "\xA4\x44\x3B\xA5\x3A\x52\xFC\xA8\x17\x3D\xE6\xE8\x5B\x42\xF9\x78\x3D\x4A\x78\x17"
+#define key_rsa_bogus_0 \
+      "\x28\x31\x31\x3A\x70\x72\x69\x76\x61\x74\x65\x2D\x6B\x65\x79\x28\x33\x3A\x72\x73" \
+      "\x61\x28\x31\x3A\x6E\x31\x32\x39\x3A\x00\xB6\xB5\x09\x59\x6A\x9E\xCA\xBC\x93\x92" \
+      "\x12\xF8\x91\xE6\x56\xA6\x26\xBA\x07\xDA\x85\x21\xA9\xCA\xD4\xC0\x8E\x64\x0C\x04" \
+      "\x05\x2F\xBB\x87\xF4\x24\xEF\x1A\x02\x75\xA4\x8A\x92\x99\xAC\x9D\xB6\x9A\xBE\x3D" \
+      "\x01\x24\xE6\xC7\x56\xB1\xF7\xDF\xB9\xB8\x42\xD6\x25\x1A\xEA\x6E\xE8\x53\x90\x49" \
+      "\x5C\xAD\xA7\x3D\x67\x15\x37\xFC\xE5\x85\x0A\x93\x2F\x32\xBA\xB6\x0A\xB1\xAC\x1F" \
+      "\x85\x2C\x1F\x83\xC6\x25\xE7\xA7\xD7\x0C\xDA\x9E\xF1\x6D\x5C\x8E\x47\x73\x9D\x77" \
+      "\xDF\x59\x26\x1A\xBE\x84\x54\x80\x7F\xF4\x41\xE1\x43\xFB\xD3\x7F\x85\x45\x29\x28" \
+      "\x31\x3A\x65\x33\x3A\x01\x00\x01\x29\x28\x31\x3A\x64\x31\x32\x38\x3A\x07\x7A\xD3" \
+      "\xDE\x28\x42\x45\xF4\x80\x6A\x1B\x82\xB7\x9E\x61\x6F\xBD\xE8\x21\xC8\x2D\x69\x1A" \
+      "\x65\x66\x5E\x57\xB5\xFA\xD3\xF3\x4E\x67\xF4\x01\xE7\xBD\x2E\x28\x69\x9E\x89\xD9" \
+      "\xC4\x96\xCF\x82\x19\x45\xAE\x83\xAC\x7A\x12\x31\x17\x6A\x19\x6B\xA6\x02\x7E\x77" \
+      "\xD8\x57\x89\x05\x5D\x50\x40\x4A\x7A\x2A\x95\xB1\x51\x2F\x91\xF1\x90\xBB\xAE\xF7" \
+      "\x30\xED\x55\x0D\x22\x7D\x51\x2F\x89\xC0\xCD\xB3\x1A\xC0\x6F\xA9\xA1\x95\x03\xDD" \
+      "\xF6\xB6\x6D\x0B\x42\xB9\x69\x1B\xFD\x61\x40\xEC\x17\x20\xFF\xC4\x8A\xE0\x0C\x34" \
+      "\x79\x6D\xC8\x99\xE5\x29\x28\x31\x3A\x70\x36\x35\x3A\x00\xD5\x86\xC7\x8E\x5F\x1B" \
+      "\x4B\xF2\xE7\xCD\x7A\x04\xCA\x09\x19\x11\x70\x6F\x19\x78\x8B\x93\xE4\x4E\xE2\x0A" \
+      "\xAF\x46\x2E\x83\x63\xE9\x8A\x72\x25\x3E\xD8\x45\xCC\xBF\x24\x81\xBB\x35\x1E\x85" \
+      "\x57\xC8\x5B\xCF\xFF\x0D\xAB\xDB\xFF\x8E\x26\xA7\x9A\x09\x38\x09\x6F\x27\x29\x28" \
+      "\x31\x3A\x71\x36\x35\x3A\x00\xDB\x0C\xDF\x60\xF2\x6F\x2A\x29\x6C\x88\xD6\xBF\x9F" \
+      "\x8E\x5B\xE4\x5C\x0D\xDD\x71\x3C\x96\xCC\x73\xEB\xCB\x48\xB0\x61\x74\x09\x43\xF2" \
+      "\x1D\x2A\x93\xD6\xE4\x2A\x72\x11\xE7\xF0\x2A\x95\xDC\xED\x6C\x39\x0A\x67\xAD\x21" \
+      "\xEC\xF7\x39\xAE\x8A\x0C\xA4\x6F\xF2\xEB\xB3\x29\x28\x31\x3A\x75\x36\x34\x3A\x33" \
+      "\x14\x91\x95\xF1\x69\x12\xDB\x20\xA4\x8D\x02\x0D\xBC\x3B\x9E\x38\x81\xB3\x9D\x72" \
+      "\x2B\xF7\x93\x78\xF6\x34\x0F\x43\x14\x8A\x6E\x9F\xC5\xF5\x3E\x28\x53\xB7\x38\x7B" \
+      "\xA4\x44\x3B\xA5\x3A\x52\xFC\xA8\x17\x3D\xE6\xE8\x5B\x42\xF9\x78\x3D\x4A\x78\x17" \
       "\xD0\x68\x0B\x29\x29\x00"
-    };
+
   /* This RSA key is the `e' value.  */
-  struct key_spec key_rsa_bogus_1 =
-    {
-      "\x28\x31\x31\x3A\x70\x72\x69\x76\x61\x74\x65\x2D\x6B\x65\x79\x28\x33\x3A\x72\x73"
-      "\x61\x28\x31\x3A\x6E\x31\x32\x39\x3A\x00\xA8\x80\xB6\x71\xF4\x95\x9F\x49\x84\xED"
-      "\xC1\x1D\x5F\xFF\xED\x14\x7B\x9C\x6A\x62\x0B\x7B\xE2\x3E\x41\x48\x49\x85\xF5\x64"
-      "\x50\x04\x9D\x30\xFC\x84\x1F\x01\xC3\xC3\x15\x03\x48\x6D\xFE\x59\x0B\xB0\xD0\x3E"
-      "\x68\x8A\x05\x7A\x62\xB0\xB9\x6E\xC5\xD2\xA8\xEE\x0C\x6B\xDE\x5E\x3D\x8E\xE8\x8F"
-      "\xB3\xAE\x86\x99\x7E\xDE\x2B\xC2\x4D\x60\x51\xDB\xB1\x2C\xD0\x38\xEC\x88\x62\x3E"
-      "\xA9\xDD\x11\x53\x04\x17\xE4\xF2\x07\x50\xDC\x44\xED\x14\xF5\x0B\xAB\x9C\xBC\x24"
-      "\xC6\xCB\xAD\x0F\x05\x25\x94\xE2\x73\xEB\x14\xD5\xEE\x5E\x18\xF0\x40\x31\x29\x28"
-      "\x31\x3A\x64\x31\x32\x38\x3A\x40\xD0\x55\x9D\x2A\xA7\xBC\xBF\xE2\x3E\x33\x98\x71"
-      "\x7B\x37\x3D\xB8\x38\x57\xA1\x43\xEA\x90\x81\x42\xCA\x23\xE1\xBF\x9C\xA8\xBC\xC5"
-      "\x9B\xF8\x9D\x77\x71\xCD\xD3\x85\x8B\x20\x3A\x92\xE9\xBC\x79\xF3\xF7\xF5\x6D\x15"
-      "\xA3\x58\x3F\xC2\xEB\xED\x72\xD4\xE0\xCF\xEC\xB3\xEC\xEB\x09\xEA\x1E\x72\x6A\xBA"
-      "\x95\x82\x2C\x7E\x30\x95\x66\x3F\xA8\x2D\x40\x0F\x7A\x12\x4E\xF0\x71\x0F\x97\xDB"
-      "\x81\xE4\x39\x6D\x24\x58\xFA\xAB\x3A\x36\x73\x63\x01\x77\x42\xC7\x9A\xEA\x87\xDA"
-      "\x93\x8F\x6C\x64\xAD\x9E\xF0\xCA\xA2\x89\xA4\x0E\xB3\x25\x73\x29\x28\x31\x3A\x70"
-      "\x36\x35\x3A\x00\xC3\xF7\x37\x3F\x9D\x93\xEC\xC7\x5E\x4C\xB5\x73\x29\x62\x35\x80"
-      "\xC6\x7C\x1B\x1E\x68\x5F\x92\x56\x77\x0A\xE2\x8E\x95\x74\x87\xA5\x2F\x83\x2D\xF7"
-      "\xA1\xC2\x78\x54\x18\x6E\xDE\x35\xF0\x9F\x7A\xCA\x80\x5C\x83\x5C\x44\xAD\x8B\xE7"
-      "\x5B\xE2\x63\x7D\x6A\xC7\x98\x97\x29\x28\x31\x3A\x71\x36\x35\x3A\x00\xDC\x1F\xB1"
-      "\xB3\xD8\x13\xE0\x09\x19\xFD\x1C\x58\xA1\x2B\x02\xB4\xC8\xF2\x1C\xE7\xF9\xC6\x3B"
-      "\x68\xB9\x72\x43\x86\xEF\xA9\x94\x68\x02\xEF\x7D\x77\xE0\x0A\xD1\xD7\x48\xFD\xCD"
-      "\x98\xDA\x13\x8A\x76\x48\xD4\x0F\x63\x28\xFA\x01\x1B\xF3\xC7\x15\xB8\x53\x22\x7E"
-      "\x77\x29\x28\x31\x3A\x75\x36\x35\x3A\x00\xB3\xBB\x4D\xEE\x5A\xAF\xD0\xF2\x56\x8A"
-      "\x10\x2D\x6F\x4B\x2D\x76\x49\x9B\xE9\xA8\x60\x5D\x9E\x7E\x50\x86\xF1\xA1\x0F\x28"
-      "\x9B\x7B\xE8\xDD\x1F\x87\x4E\x79\x7B\x50\x12\xA7\xB4\x8B\x52\x38\xEC\x7C\xBB\xB9"
+#define key_rsa_bogus_1 \
+      "\x28\x31\x31\x3A\x70\x72\x69\x76\x61\x74\x65\x2D\x6B\x65\x79\x28\x33\x3A\x72\x73" \
+      "\x61\x28\x31\x3A\x6E\x31\x32\x39\x3A\x00\xA8\x80\xB6\x71\xF4\x95\x9F\x49\x84\xED" \
+      "\xC1\x1D\x5F\xFF\xED\x14\x7B\x9C\x6A\x62\x0B\x7B\xE2\x3E\x41\x48\x49\x85\xF5\x64" \
+      "\x50\x04\x9D\x30\xFC\x84\x1F\x01\xC3\xC3\x15\x03\x48\x6D\xFE\x59\x0B\xB0\xD0\x3E" \
+      "\x68\x8A\x05\x7A\x62\xB0\xB9\x6E\xC5\xD2\xA8\xEE\x0C\x6B\xDE\x5E\x3D\x8E\xE8\x8F" \
+      "\xB3\xAE\x86\x99\x7E\xDE\x2B\xC2\x4D\x60\x51\xDB\xB1\x2C\xD0\x38\xEC\x88\x62\x3E" \
+      "\xA9\xDD\x11\x53\x04\x17\xE4\xF2\x07\x50\xDC\x44\xED\x14\xF5\x0B\xAB\x9C\xBC\x24" \
+      "\xC6\xCB\xAD\x0F\x05\x25\x94\xE2\x73\xEB\x14\xD5\xEE\x5E\x18\xF0\x40\x31\x29\x28" \
+      "\x31\x3A\x64\x31\x32\x38\x3A\x40\xD0\x55\x9D\x2A\xA7\xBC\xBF\xE2\x3E\x33\x98\x71" \
+      "\x7B\x37\x3D\xB8\x38\x57\xA1\x43\xEA\x90\x81\x42\xCA\x23\xE1\xBF\x9C\xA8\xBC\xC5" \
+      "\x9B\xF8\x9D\x77\x71\xCD\xD3\x85\x8B\x20\x3A\x92\xE9\xBC\x79\xF3\xF7\xF5\x6D\x15" \
+      "\xA3\x58\x3F\xC2\xEB\xED\x72\xD4\xE0\xCF\xEC\xB3\xEC\xEB\x09\xEA\x1E\x72\x6A\xBA" \
+      "\x95\x82\x2C\x7E\x30\x95\x66\x3F\xA8\x2D\x40\x0F\x7A\x12\x4E\xF0\x71\x0F\x97\xDB" \
+      "\x81\xE4\x39\x6D\x24\x58\xFA\xAB\x3A\x36\x73\x63\x01\x77\x42\xC7\x9A\xEA\x87\xDA" \
+      "\x93\x8F\x6C\x64\xAD\x9E\xF0\xCA\xA2\x89\xA4\x0E\xB3\x25\x73\x29\x28\x31\x3A\x70" \
+      "\x36\x35\x3A\x00\xC3\xF7\x37\x3F\x9D\x93\xEC\xC7\x5E\x4C\xB5\x73\x29\x62\x35\x80" \
+      "\xC6\x7C\x1B\x1E\x68\x5F\x92\x56\x77\x0A\xE2\x8E\x95\x74\x87\xA5\x2F\x83\x2D\xF7" \
+      "\xA1\xC2\x78\x54\x18\x6E\xDE\x35\xF0\x9F\x7A\xCA\x80\x5C\x83\x5C\x44\xAD\x8B\xE7" \
+      "\x5B\xE2\x63\x7D\x6A\xC7\x98\x97\x29\x28\x31\x3A\x71\x36\x35\x3A\x00\xDC\x1F\xB1" \
+      "\xB3\xD8\x13\xE0\x09\x19\xFD\x1C\x58\xA1\x2B\x02\xB4\xC8\xF2\x1C\xE7\xF9\xC6\x3B" \
+      "\x68\xB9\x72\x43\x86\xEF\xA9\x94\x68\x02\xEF\x7D\x77\xE0\x0A\xD1\xD7\x48\xFD\xCD" \
+      "\x98\xDA\x13\x8A\x76\x48\xD4\x0F\x63\x28\xFA\x01\x1B\xF3\xC7\x15\xB8\x53\x22\x7E" \
+      "\x77\x29\x28\x31\x3A\x75\x36\x35\x3A\x00\xB3\xBB\x4D\xEE\x5A\xAF\xD0\xF2\x56\x8A" \
+      "\x10\x2D\x6F\x4B\x2D\x76\x49\x9B\xE9\xA8\x60\x5D\x9E\x7E\x50\x86\xF1\xA1\x0F\x28" \
+      "\x9B\x7B\xE8\xDD\x1F\x87\x4E\x79\x7B\x50\x12\xA7\xB4\x8B\x52\x38\xEC\x7C\xBB\xB9" \
       "\x55\x87\x11\x1C\x74\xE7\x7F\xA0\xBA\xE3\x34\x5D\x61\xBF\x29\x29\x29\x00"
-    };
       
   struct
   {
@@ -158,15 +154,15 @@
       { "",
 	"passphrase", 1, 0, NULL, 0, GPG_ERR_INV_SEXP, NULL, 0 },
       /* - NULL; disabled, this segfaults  */
-      //{ NULL,
-      //  "passphrase", 1, NULL, 0, GPG_ERR_INV_SEXP, NULL, 0 },
+      /*{ NULL,
+        "passphrase", 1, NULL, 0, GPG_ERR_INV_SEXP, NULL, 0 }, */
 
       /* Valid and invalid keys.  */
-      { key_rsa_valid.string,
+      { key_rsa_valid,
 	"passphrase", 0, 0, NULL, 0, 0, NULL, 0 },
-      { key_rsa_bogus_0.string,
+      { key_rsa_bogus_0,
 	"passphrase", 0, 0, NULL, 0, GPG_ERR_INV_SEXP, NULL, 0 },
-      { key_rsa_bogus_1.string,
+      { key_rsa_bogus_1,
 	"passphrase", 0, 0, NULL, 0, GPG_ERR_INV_SEXP, NULL, 0 },
 
       /* FIXME: add more test data.  */
Index: agent/minip12.c
===================================================================
--- agent/minip12.c.orig	2007-05-10 22:09:34.973491000 +0000
+++ agent/minip12.c	2007-05-10 22:09:41.484108000 +0000
@@ -505,7 +505,7 @@
                int iter, const char *pw, int cipher_algo,
                int (*check_fnc) (const void *, size_t))
 {
-  static const char const *charsets[] = {
+  static const char *charsets[] = {
     "",   /* No conversion - use the UTF-8 passphrase direct.  */
     "ISO-8859-1",
     "ISO-8859-15",
Index: g10/Makefile.am
===================================================================
--- g10/Makefile.am.orig	2007-05-10 22:09:36.362440000 +0000
+++ g10/Makefile.am	2007-05-10 22:09:41.556503000 +0000
@@ -119,9 +119,9 @@
 LDADD =  $(needed_libs) ../common/libgpgrl.a \
          $(ZLIBS) $(DNSLIBS) $(LIBREADLINE) \
          $(LIBINTL) $(CAPLIBS) $(NETLIBS)
-gpg2_LDADD = $(LIBGCRYPT_LIBS) $(LDADD) $(LIBASSUAN_LIBS) $(GPG_ERROR_LIBS) \
+gpg2_LDADD = $(LDADD) $(LIBGCRYPT_LIBS) $(LIBASSUAN_LIBS) $(GPG_ERROR_LIBS) \
 	     $(LIBICONV)
-gpgv2_LDADD = $(LIBGCRYPT_LIBS) $(LDADD) $(LIBASSUAN_LIBS) $(GPG_ERROR_LIBS) \
+gpgv2_LDADD = $(LDADD) $(LIBGCRYPT_LIBS) $(LIBASSUAN_LIBS) $(GPG_ERROR_LIBS) \
 	      $(LIBICONV)
 
 $(PROGRAMS): $(needed_libs) ../common/libgpgrl.a
Index: common/dynload.h
===================================================================
--- common/dynload.h.orig	2007-05-10 22:09:35.070028000 +0000
+++ common/dynload.h	2007-05-10 22:09:41.586637000 +0000
@@ -21,8 +21,67 @@
 
 #ifndef GNUPG_DYNLOAD_H
 #define GNUPG_DYNLOAD_H
+
 #ifndef __MINGW32__
+#include <config.h>
+#if HAVE_DLFCN_H
 #include <dlfcn.h>
+#elif HAVE_DL_H
+#include <dl.h>
+#if !defined(DYNAMIC_PATH)
+#  define DYNAMIC_PATH		0
+#endif
+#if !defined(BIND_RESTRICTED)
+#  define BIND_RESTRICTED	0
+#endif
+
+#define RTLD_LAZY 0
+
+#define	BIND_FLAGS	(BIND_IMMEDIATE | BIND_NONFATAL | DYNAMIC_PATH)
+
+
+
+static inline void *
+dlopen (const char * name, int flag)
+{
+  void * hd = shl_load (name,BIND_FLAGS,0L);
+  return hd;
+}
+
+static inline void *
+dlsym (void *hd, const char *sym)
+{
+  if (hd && sym)
+    {
+      void * fnc;
+	  if (shl_findsym((shl_t*)&hd,sym,TYPE_UNDEFINED,&fnc)) {
+		return NULL;
+	  } 
+      return fnc;
+    }
+  return NULL;
+}
+
+
+static inline const char *
+dlerror (void)
+{
+	return "Error";
+}
+
+
+static inline int
+dlclose (void * hd)
+{
+  if (hd)
+    {
+	  shl_unload(hd);
+      return 0;
+    }
+  return -1;
+}  
+#endif
+
 #else
 #include <windows.h>
 
Index: scd/pcsc-wrapper.c
===================================================================
--- scd/pcsc-wrapper.c.orig	2007-05-10 22:09:35.021757000 +0000
+++ scd/pcsc-wrapper.c	2007-05-10 22:09:41.625112000 +0000
@@ -48,8 +48,11 @@
 #include <errno.h>
 #include <stdarg.h>
 #include <assert.h>
+#if HAVE_DLFCN_H
 #include <dlfcn.h>
-
+#else
+#include <dynload.h>
+#endif
 
 #define PGM "pcsc-wrapper"
 
Index: common/gettime.c
===================================================================
--- common/gettime.c.orig	2007-05-10 22:09:35.094130000 +0000
+++ common/gettime.c	2007-05-10 22:09:41.671454000 +0000
@@ -63,6 +63,12 @@
       struct tm tmbuf;
       
       tp = gmtime_r (&atime, &tmbuf);
+
+/* The man page for gm_time_r on HP-UX 10.20 says:                     */
+/*  For asctime_r(), ctime_r(), gmtime_r(), and localtime_r(), if the  */
+/*  operation is successful, 0 is returned.                            */
+
+      if (!tp) tp = &tmbuf;
 #else
       tp = gmtime (&atime);
 #endif

From gnupg-devel at mlists.thewrittenword.com  Sat May 12 05:09:48 2007
From: gnupg-devel at mlists.thewrittenword.com (Peter O'Gorman)
Date: Fri, 11 May 2007 22:09:48 -0500
Subject: test failures with gnupg-2.0.4 on solaris, Tru64 and IRIX
Message-ID: <20070512030948.GB4300@acer.localdomain>

Hi,
The sm-sign+verify test is the only test we have failing, here is a
sample of the output on Tru64-5.1 (other platforms have the same 
error, root certificate not trusted-  gpg-agent[13640]: command
marktrusted failed: Not supported)

Any ideas?

gpgsm: WARNING: running with faked system time: 2002-12-02 13:29:59
read_assuan: read "OK GNU Privacy Guard's S/M server 2.0.4 ready
"
sending `INPUT FD=3'
expecting OK
read_assuan: read "OK
"
sending `OUTPUT FD=4'
expecting OK
read_assuan: read "OK
"
sending `SIGN'
expecting OK
gpgsm[325479]: can't connect to `/opt/build/gnupg-2.0.4/tests/S.gpg-agent': No such file or directory
gpgsm: CRLs not checked due to --disable-crl-checks option
gpgsm: DBG: adding certificates at level 1
gpgsm: signature created
read_assuan: read "S PROGRESS starting_agent ? 0 0
"
read_assuan: read "S SIG_CREATED S 1 2 00 20021202T132959 3CF405464F66ED4A7DF45BBDD1E4282E33BDB76E
OK
"
read_assuan: read "OK
"
sending `RESET'
expecting OK
read_assuan: read "OK
"
sending `INPUT FD=5'
expecting OK
read_assuan: read "OK
"
sending `OUTPUT FD=6'
expecting OK
read_assuan: read "OK
"
sending `VERIFY'
gpgsm: Signature made 2002-12-02 13:29:59 using certificate ID 33BDB76E
expecting OK
gpgsm: root certificate is not marked trusted
gpgsm: fingerprint=3C:F4:05:46:4F:66:ED:4A:7D:F4:5B:BD:D1:E4:28:2E:33:BD:B7:6E
gpg-agent[325468]: command marktrusted failed: Not supported
gpgsm: DBG: BEGIN Certificate `issuer':
gpgsm: DBG:      serial: 00
gpgsm: DBG:   notBefore: 2001-12-03 09:36:38
gpgsm: DBG:    notAfter: 2002-12-03 09:36:38
gpgsm: DBG:      issuer: CN=test cert 1,OU=Aegypten Project,O=g10 Code GmbH,L=D?sseldorf,C=DE
gpgsm: DBG:     subject: CN=test cert 1,OU=Aegypten Project,O=g10 Code GmbH,L=D?sseldorf,C=DE
gpgsm: DBG:   hash algo: 1.2.840.113549.1.1.4
gpgsm: DBG:   SHA1 Fingerprint: 3C:F4:05:46:4F:66:ED:4A:7D:F4:5B:BD:D1:E4:28:2E:33:BD:B7:6E
gpgsm: DBG: END Certificate
gpgsm: after checking the fingerprint, you may want to add it manually to the list of trusted certificates.
gpgsm: interactive marking as trusted not enabled in gpg-agent
gpgsm: invalid certification chain: Not trusted
read_assuan: read "S NEWSIG
"
read_assuan: read "S GOODSIG 3CF405464F66ED4A7DF45BBDD1E4282E33BDB76E CN=test cert 1,OU=Aegypten Project,O=g10 Code GmbH,L=D?sseldorf,C=DE
S VALIDSIG 3CF405464F66ED4A7DF45BBDD1E4282E33BDB76E 2002-12-02 20021202T132959 20021203T093638
S TRUST_UNDEFINED 98
OK
"
read_assuan: read "S VALIDSIG 3CF405464F66ED4A7DF45BBDD1E4282E33BDB76E 2002-12-02 20021202T132959 20021203T093638
S TRUST_UNDEFINED 98
OK
"
read_assuan: read "S TRUST_UNDEFINED 98
OK
"
read_assuan: read "OK
"
goodsig=1 trusted=0




From marcus.brinkmann at ruhr-uni-bochum.de  Mon May 14 14:08:38 2007
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Mon, 14 May 2007 14:08:38 +0200
Subject: Scute: feature request: Support CKA_TRUSTED attribute on X.509
	certs
In-Reply-To: <87hcr6azie.fsf@wheatstone.g10code.de>
References: <87r6qc63a7.fsf@mocca.josefsson.org>	<87wt04f673.fsf@wheatstone.g10code.de>	<87ps5v1lir.fsf@mocca.josefsson.org>	<87hcr6azie.fsf@wheatstone.g10code.de>
Message-ID: <87veev620p.wl%marcus.brinkmann@ruhr-uni-bochum.de>

Hi,

sorry this didn't get sent out earlier, it was stuck in my drafts box.

At Tue, 24 Apr 2007 11:32:41 +0200,
'Werner Koch' wrote:
> 
> On Mon, 23 Apr 2007 11:35, simon at josefsson.org said:
> 
> > Thanks.  Btw, do you know what the best way to find out which
> > certificate correspond to a private key?  Using the key id seems
> > somewhat fragile, but it is what I'll use unless I learn of a better
> > way.
> 
> GnuPG uses a thing called keygrip
> 
>  unsigned char *gcry_pk_get_keygrip (gcry_sexp_t key, unsigned char *array)

We only export the fingerprint in the PKCS #11 token data (via
CKA_ID).  I don't think there is a good space to export the grip as
well.  Shouldn't the fingerprint be good enough?

Thanks,
Marcus



From simon at josefsson.org  Mon May 14 14:21:59 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 14 May 2007 14:21:59 +0200
Subject: Scute: feature request: Support CKA_TRUSTED attribute on X.509
	certs
In-Reply-To: <87veev620p.wl%marcus.brinkmann@ruhr-uni-bochum.de> (Marcus
	Brinkmann's message of "Mon\, 14 May 2007 14\:08\:38 +0200")
References: <87r6qc63a7.fsf@mocca.josefsson.org>
	<87wt04f673.fsf@wheatstone.g10code.de>
	<87ps5v1lir.fsf@mocca.josefsson.org>
	<87hcr6azie.fsf@wheatstone.g10code.de>
	<87veev620p.wl%marcus.brinkmann@ruhr-uni-bochum.de>
Message-ID: <877irbfvdk.fsf@mocca.josefsson.org>

Marcus Brinkmann <marcus.brinkmann at ruhr-uni-bochum.de> writes:

> Hi,
>
> sorry this didn't get sent out earlier, it was stuck in my drafts box.
>
> At Tue, 24 Apr 2007 11:32:41 +0200,
> 'Werner Koch' wrote:
>> 
>> On Mon, 23 Apr 2007 11:35, simon at josefsson.org said:
>> 
>> > Thanks.  Btw, do you know what the best way to find out which
>> > certificate correspond to a private key?  Using the key id seems
>> > somewhat fragile, but it is what I'll use unless I learn of a better
>> > way.
>> 
>> GnuPG uses a thing called keygrip
>> 
>>  unsigned char *gcry_pk_get_keygrip (gcry_sexp_t key, unsigned char *array)
>
> We only export the fingerprint in the PKCS #11 token data (via
> CKA_ID).  I don't think there is a good space to export the grip as
> well.  Shouldn't the fingerprint be good enough?

Yes it has worked fine.  My logic is to search for the CKA_ID's of
certificates and keys, and if they match, I assume the certificate is
the user certificate.  I don't really care about whether the data is a
fingerprint or keygrip, just that it is persistant and memcmp properly.

/Simon


From cam at mathematica.scientia.net  Tue May 15 20:35:16 2007
From: cam at mathematica.scientia.net (Christoph Anton Mitterer)
Date: Tue, 15 May 2007 20:35:16 +0200
Subject: gpgme: documentation error
Message-ID: <4649FD64.4010204@mathematica.scientia.net>

Hi.

The info page of gpgme describes the function gpgme_strerror_r as follows:
 -- Funktion: char * gpgme_strerror_r (gpgme_error_t ERR)
     The function `gpgme_strerror_r' returns a pointer to a dynamically
     allocated string containing a description of the error code
     contained in the error value ERR.  This string can be used to
     output a diagnostic message to the user.  When it is not needed
     anymore, the user must deallocate it with `free'.

But this is different from what's actually in gpgme.h.
Which one of the two is correct?

Chris.



From gnupg-devel at mlists.thewrittenword.com  Wed May 16 09:45:48 2007
From: gnupg-devel at mlists.thewrittenword.com (Peter O'Gorman)
Date: Wed, 16 May 2007 02:45:48 -0500
Subject: gpgme make check pinentry dialogs
Message-ID: <20070516074548.GA6721@acer.localdomain>

Hi,
We have gnupg-2.0.4, and are building gpgme-1.1.4 with
--with-gpg=/path/to/gpg2, during make check (in the tests/gpg subdir)
a lot of pinentry dialogs ask for passphrases. If I type 'abc<RETURN>'
a lot then the tests will pass, but it does not seem normal to have to
do so.

Is the presentation of these dialogs expected behavior?

Thanks,
Peter




From wk at gnupg.org  Wed May 16 14:18:38 2007
From: wk at gnupg.org (Werner Koch)
Date: Wed, 16 May 2007 14:18:38 +0200
Subject: gpgme make check pinentry dialogs
Message-ID: <87lkfpufkx.fsf@wheatstone.g10code.de>

An embedded message was scrubbed...
From: Werner Koch <wk at gnupg.org>
Subject: Re: gpgme make check pinentry dialogs
Date: Wed, 16 May 2007 14:17:50 +0200
Size: 1375
Url: /pipermail/attachments/20070516/a18c800e/attachment.mht 

From gnupg-devel at mlists.thewrittenword.com  Wed May 16 17:21:21 2007
From: gnupg-devel at mlists.thewrittenword.com (Peter O'Gorman)
Date: Wed, 16 May 2007 10:21:21 -0500
Subject: gpgme make check pinentry dialogs
In-Reply-To: <87lkfpufkx.fsf@wheatstone.g10code.de>
References: <87lkfpufkx.fsf@wheatstone.g10code.de>
Message-ID: <20070516152121.GA2195@acer.localdomain>

On Wed, May 16, 2007 at 02:18:38PM +0200, Werner Koch wrote:
> On Wed, 16 May 2007 09:45, gnupg-devel at mlists.thewrittenword.com said:
> 
> > We have gnupg-2.0.4, and are building gpgme-1.1.4 with
> > --with-gpg=/path/to/gpg2, during make check (in the tests/gpg subdir)
> > a lot of pinentry dialogs ask for passphrases. If I type 'abc<RETURN>'
> > a lot then the tests will pass, but it does not seem normal to have to
> > do so.
> >
> > Is the presentation of these dialogs expected behavior?
> 
> With the corrent code: yes.  We need to enhance the tests to overcomethe
> problem.  This can either be done using gpg-preset-passphrase, by
> writing a loopback pinentry or having keys without a passphrase.

Okay, good to know. Until thiese changes are made, a README in the
tests subdir mentioning that pinentry dialogs might be shown to the
user (and that the passphrase is 'abc') is, I think, a good idea.

Thanks for the prompt reply,
Peter




From ametzler at downhill.at.eu.org  Thu May 17 10:08:40 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Thu, 17 May 2007 10:08:40 +0200
Subject: Libgcrypt svn trunk build failure on HPPA
Message-ID: <85fth4-51o.ln1@argenau.downhill.at.eu.org>

Hello,

libgcrypt SVN HEAD (Revision 1251) fails to build from source on hppa,
the source of trouble seems to be the asm/mpi build-system:

|config.status: linking ./mpi/pa7100/mpih-lshift.S to mpi/mpih-lshift-asm.S
|config.status: linking ./mpi/pa7100/mpih-rshift.S to mpi/mpih-rshift-asm.S
|config.status: linking ./mpi/hppa1.1/udiv-qrnnd.S to mpi/udiv-qrnnd-asm.S
|config.status: linking ./mpi/generic/mpi-asm-defs.h to mpi/mpi-asm-defs.h
|config.status: executing depfiles commands
...
[However udiv-qrnnd.lo is not generated and not linked into libmpi.la and therefore..]
|make[3]: Entering directory `/build/buildd/libgcrypt11-1.3.0/tests'
|cc -DHAVE_CONFIG_H -I. -I..  -I../src -I../src   -g -Wall -O2 -Wall -c version.c
|/bin/bash ../libtool --tag=CC   --mode=link cc  -g -Wall -O2 -Wall   -o version version.o ../src/libgcrypt.la
|mkdir .libs
|cc -g -Wall -O2 -Wall -o .libs/version version.o  ../src/.libs/libgcrypt.so
|../src/.libs/libgcrypt.so: undefined reference to `__udiv_qrnnd'
|collect2: ld returned 1 exit status
|make[3]: *** [version] Error 1


ametzler at paer:~/GCR/libgcrypt11-1.3.0.buildtree/src/.libs$ ldd -r libgcrypt.so.11.4.0
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x40138000)
        libc.so.6 => /lib/libc.so.6 (0x403ce000)
        /lib/ld.so.1 (0x41215000)
undefined symbol: __udiv_qrnnd  (./libgcrypt.so.11.4.0)

FWIW 1.3.0 vanilla seems to build fine. If there is more information
needed (complete buildlog, config.status et, ...) I will happily
provide it.

thanks, cu andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



From marcus.brinkmann at ruhr-uni-bochum.de  Fri May 18 23:29:44 2007
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Fri, 18 May 2007 23:29:44 +0200
Subject: Libgcrypt svn trunk build failure on HPPA
In-Reply-To: <85fth4-51o.ln1@argenau.downhill.at.eu.org>
References: <85fth4-51o.ln1@argenau.downhill.at.eu.org>
Message-ID: <87abw14y7r.wl%marcus.brinkmann@ruhr-uni-bochum.de>

Hi Andreas,

At Thu, 17 May 2007 10:08:40 +0200,
Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
> 
> Hello,
> 
> libgcrypt SVN HEAD (Revision 1251) fails to build from source on hppa,
> the source of trouble seems to be the asm/mpi build-system:

I redid the Automake magic because the old way caused assembler files
to be compiled without PIC.
 
> |config.status: linking ./mpi/pa7100/mpih-lshift.S to mpi/mpih-lshift-asm.S
> |config.status: linking ./mpi/pa7100/mpih-rshift.S to mpi/mpih-rshift-asm.S
> |config.status: linking ./mpi/hppa1.1/udiv-qrnnd.S to mpi/udiv-qrnnd-asm.S
> |config.status: linking ./mpi/generic/mpi-asm-defs.h to mpi/mpi-asm-defs.h
> |config.status: executing depfiles commands
> ...
> [However udiv-qrnnd.lo is not generated and not linked into libmpi.la and therefore..]

You mean udiv-qrnnd-asm.lo.  The name changed necessarily.

> FWIW 1.3.0 vanilla seems to build fine. If there is more information
> needed (complete buildlog, config.status et, ...) I will happily
> provide it.

Can you please send me the files config.log and mpi/Makefile ?  This
might be enough (but to be honest, I don't yet know what I am looking
for).

Thanks,
Marcus



From marcus.brinkmann at ruhr-uni-bochum.de  Fri May 18 23:41:51 2007
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Fri, 18 May 2007 23:41:51 +0200
Subject: gpgme: documentation error
In-Reply-To: <4649FD64.4010204@mathematica.scientia.net>
References: <4649FD64.4010204@mathematica.scientia.net>
Message-ID: <878xbl4xnk.wl%marcus.brinkmann@ruhr-uni-bochum.de>

At Tue, 15 May 2007 20:35:16 +0200,
Christoph Anton Mitterer <cam at mathematica.scientia.net> wrote:
> 
> Hi.
> 
> The info page of gpgme describes the function gpgme_strerror_r as follows:
>  -- Funktion: char * gpgme_strerror_r (gpgme_error_t ERR)
[...]

> But this is different from what's actually in gpgme.h.
> Which one of the two is correct?

The header file.  I updated the manual, thanks a lot.

Marcus



From ametzler at downhill.at.eu.org  Sat May 19 09:48:28 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 19 May 2007 09:48:28 +0200
Subject: Libgcrypt svn trunk build failure on HPPA
In-Reply-To: <87abw14y7r.wl%marcus.brinkmann@ruhr-uni-bochum.de>
References: <85fth4-51o.ln1@argenau.downhill.at.eu.org>
	<87abw14y7r.wl%marcus.brinkmann@ruhr-uni-bochum.de>
Message-ID: <20070519074828.GA3779@downhill.g.la>

On 2007-05-18 Marcus Brinkmann <marcus.brinkmann at ruhr-uni-bochum.de> wrote:
> At Thu, 17 May 2007 10:08:40 +0200,
> Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
...]
>> FWIW 1.3.0 vanilla seems to build fine. If there is more information
>> needed (complete buildlog, config.status et, ...) I will happily
>> provide it.

> Can you please send me the files config.log and mpi/Makefile ?  This
> might be enough (but to be honest, I don't yet know what I am looking
> for).

Hello,
I have uploaded the whole thing as browseable tree to the web.
http://www.bebt.de/debian/libgcrypt/libgcrypt11-1.3.0/config.log
http://www.bebt.de/debian/libgcrypt/libgcrypt11-1.3.0/mpi/Makefile

Additionally the whole build-tree (libgcrypt11-1.3.0/*) is in
http://www.bebt.de/debian/libgcrypt/buildtree.tar.gz
the complete ditrectory structure with additionally buildlog and
libgcrypt11_1.3.0.orig.tar.gz and libgcrypt11_1.3.0-1.diff.gz
libgcrypt11_1.3.0-1.dsc is in
http://www.bebt.de/debian/libgcrypt/everything.tgz


I am starting with vanilla source, then apply 
svn diff -r1249:1251
(stored in debian/patches/13_fixPIC.diff) and then apply the patch
containing the changes from re-running auto-*
(debian/patches/14_re_autofoo.diff).

thanks, cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From marcus.brinkmann at ruhr-uni-bochum.de  Sat May 19 22:44:04 2007
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Sat, 19 May 2007 22:44:04 +0200
Subject: Libgcrypt svn trunk build failure on HPPA
In-Reply-To: <20070519074828.GA3779@downhill.g.la>
References: <85fth4-51o.ln1@argenau.downhill.at.eu.org>
	<87abw14y7r.wl%marcus.brinkmann@ruhr-uni-bochum.de>
	<20070519074828.GA3779@downhill.g.la>
Message-ID: <87y7jk8rxn.wl%marcus.brinkmann@ruhr-uni-bochum.de>

At Sat, 19 May 2007 09:48:28 +0200,
Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
> 
> On 2007-05-18 Marcus Brinkmann <marcus.brinkmann at ruhr-uni-bochum.de> wrote:
> > At Thu, 17 May 2007 10:08:40 +0200,
> > Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
> ...]
> >> FWIW 1.3.0 vanilla seems to build fine. If there is more information
> >> needed (complete buildlog, config.status et, ...) I will happily
> >> provide it.
> 
> > Can you please send me the files config.log and mpi/Makefile ?  This
> > might be enough (but to be honest, I don't yet know what I am looking
> > for).
> 
> Hello,
> I have uploaded the whole thing as browseable tree to the web.
> http://www.bebt.de/debian/libgcrypt/libgcrypt11-1.3.0/config.log
> http://www.bebt.de/debian/libgcrypt/libgcrypt11-1.3.0/mpi/Makefile

Thanks.  config.log confirmed that the automake conditionals were not
set correctly, and I noticed then that I had the wrong function names
in the configure.ac test (the udiv functions were prefixed by mpih,
but actually they shouldn't be).  I put in a fix, which I hope will
fix this for you.  Please let me know if there are any further problems.

2007-05-19  Marcus Brinkmann  <marcus at g10code.de>

        * configure.ac: Fix test for optional UDIV and UDIV_QRNND MPI
        modules.

Thanks,
Marcus



From ametzler at downhill.at.eu.org  Sun May 20 09:25:25 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 20 May 2007 09:25:25 +0200
Subject: Libgcrypt svn trunk build failure on HPPA
In-Reply-To: <87y7jk8rxn.wl%marcus.brinkmann@ruhr-uni-bochum.de>
References: <85fth4-51o.ln1@argenau.downhill.at.eu.org>
	<87abw14y7r.wl%marcus.brinkmann@ruhr-uni-bochum.de>
	<20070519074828.GA3779@downhill.g.la>
	<87y7jk8rxn.wl%marcus.brinkmann@ruhr-uni-bochum.de>
Message-ID: <20070520072525.GA3774@downhill.g.la>

On 2007-05-19 Marcus Brinkmann <marcus.brinkmann at ruhr-uni-bochum.de> wrote:
[build failure on hppa]
> Thanks.  config.log confirmed that the automake conditionals were not
> set correctly, and I noticed then that I had the wrong function names
> in the configure.ac test (the udiv functions were prefixed by mpih,
> but actually they shouldn't be).  I put in a fix, which I hope will
> fix this for you.  Please let me know if there are any further problems.

> 2007-05-19  Marcus Brinkmann  <marcus at g10code.de>

>         * configure.ac: Fix test for optional UDIV and UDIV_QRNND MPI
>         modules.

Hello,
thanks for the quick fix. I have just run a successfull testbuild on
hppa.

cu andreas


From gnupg-devel at mlists.thewrittenword.com  Fri May 25 17:24:15 2007
From: gnupg-devel at mlists.thewrittenword.com (Peter O'Gorman)
Date: Fri, 25 May 2007 10:24:15 -0500
Subject: pinentry patches
Message-ID: <20070525152415.GB5895@acer.localdomain>

[sent before, but message was too long, resending with shorter patch]

Hi,
We built pinentry-0.7.2, it required getopt (which required gettext
and iconv), so we added gnulib getopt.

The IRIX compiler, for some reason, did not like this:
{ "version", no_argument, &opt_version, 1 }
so, we changed it.

Most compilers don't understand '\e', so replaced with its hex
equivalent.

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, 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>.

Anyway, patches, bad as they are, attached.

Peter

[patch does not include added files
getopt.m4, pinentry/getopt.c, pinentry/getopt1.c, 
pinentry/getopt_.h, pinentry/getopt_int.h, pinentry/gettext.h which
can be found in gnulib]

-------------- next part --------------
Index: configure.ac
===================================================================
--- configure.ac.orig	2005-01-27 08:04:19.000000000 +0000
+++ configure.ac	2007-05-14 21:06:06.665999000 +0000
@@ -108,14 +98,10 @@
 AC_CHECK_FUNCS(seteuid stpcpy mmap)
 GNUPG_CHECK_MLOCK
 
-dnl Checks for libassuan.
-dnl -> None required becuase we use a stripped down version of libassuan.
-
-
 dnl Checks for libsecmem.
 GNUPG_CHECK_TYPEDEF(byte, HAVE_BYTE_TYPEDEF)
 GNUPG_CHECK_TYPEDEF(ulong, HAVE_ULONG_TYPEDEF)
-
+gl_GETOPT
 AC_PATH_PROG(SETCAP, setcap, :, "$PATH:/sbin:/usr/sbin")
 AC_CHECK_LIB(cap, cap_set_proc, [
   AC_DEFINE(USE_CAPABILITIES,1,[The capabilities support library is installed])
@@ -274,6 +260,9 @@
 AM_CONDITIONAL(BUILD_PINENTRY_GTK_2, test "$pinentry_gtk_2" = "yes")
 
 
+AM_GNU_GETTEXT_VERSION([0.15.0])
+AM_GNU_GETTEXT([external])
+AM_ICONV
 dnl
 dnl Check for Qt pinentry program.
 dnl
Index: secmem/util.c
===================================================================
--- secmem/util.c.orig	2004-12-22 11:38:10.000000000 +0000
+++ secmem/util.c	2007-05-14 19:47:07.015863000 +0000
@@ -32,15 +32,6 @@
 
 #include "util.h"
 
-#ifndef TEMP_FAILURE_RETRY
-#define TEMP_FAILURE_RETRY(expression) \
-  (__extension__							      \
-    ({ long int __result;						      \
-       do __result = (long int) (expression);				      \
-       while (__result == -1L && errno == EINTR);			      \
-       __result; }))
-#endif
-
 #ifndef HAVE_DOSISH_SYSTEM
 static int uid_set = 0;
 static uid_t real_uid, file_uid;
@@ -54,8 +45,13 @@
   ssize_t written = 0;
 
   for (ptr = (char *)data, todo = bytes; todo; ptr += written, todo -= written)
-    if ((written = TEMP_FAILURE_RETRY(write(fd, ptr, todo))) < 0)
-      break;
+	{
+	long int __result;
+	do {
+		__result = write(fd, ptr, todo); } 
+	while (__result == -1L && errno == EINTR);
+    if ((written = __result) < 0)
+      break; }
   return written;
 }
 
Index: pinentry/Makefile.am
===================================================================
--- pinentry/Makefile.am.orig	2003-12-23 08:41:40.000000000 +0000
+++ pinentry/Makefile.am	2007-05-14 20:03:43.702584000 +0000
@@ -31,5 +31,18 @@
 
 AM_CPPFLAGS = -I$(top_srcdir)/assuan -I$(top_srcdir)/secmem
 
-libpinentry_a_SOURCES = pinentry.h pinentry.c
+libpinentry_a_SOURCES = pinentry.h pinentry.c 
+libpinentry_a_LIBADD = $(LIBOBJS)
+
 libpinentry_curses_a_SOURCES = pinentry-curses.h pinentry-curses.c
+
+BUILT_SOURCES = $(GETOPT_H)
+
+# We need the following in order to create <getopt.h> when the system
+# doesn't have one that works with the given compiler.
+getopt.h: getopt_.h
+	{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \                 
+	  cat $(srcdir)/getopt_.h; \
+	} > $@-t                                                                
+	mv -f $@-t $@
+MOSTLYCLEANFILES = getopt.h getopt.h-t 
Index: pinentry/pinentry.c
===================================================================
--- pinentry/pinentry.c.orig	2004-12-22 11:37:50.000000000 +0000
+++ pinentry/pinentry.c	2007-05-14 21:26:31.039167000 +0000
@@ -281,7 +281,7 @@
 "      --parent-wid	 Parent window ID (for positioning)\n"
 "  -d, --debug           Turn on debugging output\n"
 "  -h, --help            Display this help and exit\n"
-"      --version         Output version information and exit\n", this_pgmname);
+"  -V, --version         Output version information and exit\n", this_pgmname);
 }
 
 
@@ -305,7 +305,7 @@
      { "no-global-grab", no_argument,    0, 'g' },
      { "parent-wid", required_argument,  0, 'W' },
      { "help", no_argument,              0, 'h' },
-     { "version", no_argument, &opt_version, 1 },
+     { "version", no_argument, 			 0, 'V' },
      { NULL, 0, NULL, 0 }};
   
   while ((opt = getopt_long (argc, argv, "degh", opts, NULL)) != -1)
@@ -327,7 +327,9 @@
         case 'h':
           opt_help = 1;
           break;
-
+		case 'V':
+		  opt_version =1;
+		  break;
 	case 'D':
           /* Note, this is currently not used because the GUI engine
              has already been initialized when parsing these options. */
Index: pinentry/pinentry-curses.c
===================================================================
--- pinentry/pinentry-curses.c.orig	2007-05-21 20:43:17.466427000 +0000
+++ pinentry/pinentry-curses.c	2007-05-22 01:49:57.845437000 +0000
@@ -34,6 +34,9 @@
 #include <string.h>
 #include <errno.h>
 
+#if defined(__hpux) || defined (__osf__)
+#include <termios.h>
+#endif
 #include <memory.h>
 
 #include "pinentry.h"
@@ -561,6 +564,18 @@
 	  errno = err;
 	  return -1;
 	}
+#if defined(__hpux) || defined (__osf__)
+{
+/* HP-UX and Tru64 echo the passphrase on input */
+/* lets set noecho.  I don't know why ncurses is unable to properly
+ * initialize the terminal device. */
+	struct termios tios;
+	tcgetattr(fileno(ttyfi),&tios);
+	tios.c_lflag = (ICANON|ISIG);
+	tios.c_iflag = (INLCR|ICRNL|BRKINT);
+	tcsetattr(fileno(ttyfi),0,&tios);
+}
+#endif
       screen = newterm (tty_type, ttyfo, ttyfi);
       set_term (screen);
     }
@@ -653,11 +666,12 @@
 	    }
 	  break;
   
-	case '\e':
+	case 0x1b:
 	  done = -2;
 	  break;
 
 	case '\r':
+	case '\n':
 	  switch (diag.pos)
 	    {
 	    case DIALOG_POS_PIN:

From german at piraos.com  Tue May 15 14:26:07 2007
From: german at piraos.com (German Gomez Garcia)
Date: Tue, 15 May 2007 12:26:07 -0000
Subject: Pam Poldi development status
Message-ID: <20070515112304.GA4053@piraos.com>

Hello,

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.

Regards,

- german

PS: Please CC to me as I am not subscribed to the list.


From calestyo at scientia.net  Tue May 15 20:25:22 2007
From: calestyo at scientia.net (Christoph Anton Mitterer)
Date: Tue, 15 May 2007 18:25:22 -0000
Subject: gpgme: documentation error
Message-ID: <4649E0C4.9020906@scientia.net>

Hi.

The info page of gpgme describes the function gpgme_strerror_r as follows:
 -- Funktion: char * gpgme_strerror_r (gpgme_error_t ERR)
     The function `gpgme_strerror_r' returns a pointer to a dynamically
     allocated string containing a description of the error code
     contained in the error value ERR.  This string can be used to
     output a diagnostic message to the user.  When it is not needed
     anymore, the user must deallocate it with `free'.

But this is different from what's actually in gpgme.h.
Which one of the two is correct?

Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: calestyo.vcf
Type: text/x-vcard
Size: 155 bytes
Desc: not available
Url : /pipermail/attachments/20070515/48c38f39/attachment-0001.vcf 

From gnupg-devel at mlists.thewrittenword.com  Tue May 22 17:37:23 2007
From: gnupg-devel at mlists.thewrittenword.com (Peter O'Gorman)
Date: Tue, 22 May 2007 10:37:23 -0500
Subject: pinentry patches
Message-ID: <20070522153723.GB3911@acer.localdomain>

Hi,
We built pinentry-0.7.2, it required getopt (which required gettext
and iconv), so we added gnulib getopt.

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, 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.

Anyway, patches, bad as they are, attached.

Peter
-------------- next part --------------
Index: configure.ac
===================================================================
--- configure.ac.orig	2005-01-27 08:04:19.000000000 +0000
+++ configure.ac	2007-05-14 21:06:06.665999000 +0000
@@ -108,14 +98,10 @@
 AC_CHECK_FUNCS(seteuid stpcpy mmap)
 GNUPG_CHECK_MLOCK
 
-dnl Checks for libassuan.
-dnl -> None required becuase we use a stripped down version of libassuan.
-
-
 dnl Checks for libsecmem.
 GNUPG_CHECK_TYPEDEF(byte, HAVE_BYTE_TYPEDEF)
 GNUPG_CHECK_TYPEDEF(ulong, HAVE_ULONG_TYPEDEF)
-
+gl_GETOPT
 AC_PATH_PROG(SETCAP, setcap, :, "$PATH:/sbin:/usr/sbin")
 AC_CHECK_LIB(cap, cap_set_proc, [
   AC_DEFINE(USE_CAPABILITIES,1,[The capabilities support library is installed])
@@ -274,6 +260,9 @@
 AM_CONDITIONAL(BUILD_PINENTRY_GTK_2, test "$pinentry_gtk_2" = "yes")
 
 
+AM_GNU_GETTEXT_VERSION([0.15.0])
+AM_GNU_GETTEXT([external])
+AM_ICONV
 dnl
 dnl Check for Qt pinentry program.
 dnl
Index: secmem/util.c
===================================================================
--- secmem/util.c.orig	2004-12-22 11:38:10.000000000 +0000
+++ secmem/util.c	2007-05-14 19:47:07.015863000 +0000
@@ -32,15 +32,6 @@
 
 #include "util.h"
 
-#ifndef TEMP_FAILURE_RETRY
-#define TEMP_FAILURE_RETRY(expression) \
-  (__extension__							      \
-    ({ long int __result;						      \
-       do __result = (long int) (expression);				      \
-       while (__result == -1L && errno == EINTR);			      \
-       __result; }))
-#endif
-
 #ifndef HAVE_DOSISH_SYSTEM
 static int uid_set = 0;
 static uid_t real_uid, file_uid;
@@ -54,8 +45,13 @@
   ssize_t written = 0;
 
   for (ptr = (char *)data, todo = bytes; todo; ptr += written, todo -= written)
-    if ((written = TEMP_FAILURE_RETRY(write(fd, ptr, todo))) < 0)
-      break;
+	{
+	long int __result;
+	do {
+		__result = write(fd, ptr, todo); } 
+	while (__result == -1L && errno == EINTR);
+    if ((written = __result) < 0)
+      break; }
   return written;
 }
 
Index: getopt.m4
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ getopt.m4	2007-05-14 19:51:03.579064000 +0000
@@ -0,0 +1,83 @@
+# getopt.m4 serial 13
+dnl Copyright (C) 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
+dnl This file is free software; the Free Software Foundation
+dnl gives unlimited permission to copy and/or distribute it,
+dnl with or without modifications, as long as this notice is preserved.
+
+# The getopt module assume you want GNU getopt, with getopt_long etc,
+# rather than vanilla POSIX getopt.  This means your code should
+# always include <getopt.h> for the getopt prototypes.
+
+AC_DEFUN([gl_GETOPT_SUBSTITUTE],
+[
+  AC_LIBOBJ([getopt])
+  AC_LIBOBJ([getopt1])
+  gl_GETOPT_SUBSTITUTE_HEADER
+  gl_PREREQ_GETOPT
+])
+
+AC_DEFUN([gl_GETOPT_SUBSTITUTE_HEADER],
+[
+  GETOPT_H=getopt.h
+  AC_DEFINE([__GETOPT_PREFIX], [[rpl_]],
+    [Define to rpl_ if the getopt replacement functions and variables
+     should be used.])
+  AC_SUBST([GETOPT_H])
+])
+
+AC_DEFUN([gl_GETOPT_CHECK_HEADERS],
+[
+  if test -z "$GETOPT_H"; then
+    AC_CHECK_HEADERS([getopt.h], [], [GETOPT_H=getopt.h])
+  fi
+
+  if test -z "$GETOPT_H"; then
+    AC_CHECK_FUNCS([getopt_long_only], [], [GETOPT_H=getopt.h])
+  fi
+
+  dnl BSD getopt_long uses an incompatible method to reset option processing,
+  dnl and (as of 2004-10-15) mishandles optional option-arguments.
+  if test -z "$GETOPT_H"; then
+    AC_CHECK_DECL([optreset], [GETOPT_H=getopt.h], [], [#include <getopt.h>])
+  fi
+
+  dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+  dnl option string (as of 2005-05-05).
+  if test -z "$GETOPT_H"; then
+    AC_CACHE_CHECK([for working GNU getopt function], [gl_cv_func_gnu_getopt],
+      [AC_RUN_IFELSE(
+	[AC_LANG_PROGRAM([#include <getopt.h>],
+	   [[
+	     char *myargv[3];
+	     myargv[0] = "conftest";
+	     myargv[1] = "-+";
+	     myargv[2] = 0;
+	     return getopt (2, myargv, "+a") != '?';
+	   ]])],
+	[gl_cv_func_gnu_getopt=yes],
+	[gl_cv_func_gnu_getopt=no],
+	[dnl cross compiling - pessimistically guess based on decls
+	 dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+	 dnl option string (as of 2005-05-05).
+	 AC_CHECK_DECL([getopt_clip],
+	   [gl_cv_func_gnu_getopt=no], [gl_cv_func_gnu_getopt=yes],
+	   [#include <getopt.h>])])])
+    if test "$gl_cv_func_gnu_getopt" = "no"; then
+      GETOPT_H=getopt.h
+    fi
+  fi
+])
+
+AC_DEFUN([gl_GETOPT_IFELSE],
+[
+  AC_REQUIRE([gl_GETOPT_CHECK_HEADERS])
+  AS_IF([test -n "$GETOPT_H"], [$1], [$2])
+])
+
+AC_DEFUN([gl_GETOPT], [gl_GETOPT_IFELSE([gl_GETOPT_SUBSTITUTE])])
+
+# Prerequisites of lib/getopt*.
+AC_DEFUN([gl_PREREQ_GETOPT],
+[
+  AC_CHECK_DECLS_ONCE([getenv])
+])
Index: pinentry/getopt.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ pinentry/getopt.c	2007-05-14 19:54:31.732285000 +0000
@@ -0,0 +1,1191 @@
+/* Getopt for GNU.
+   NOTE: getopt is now part of the C library, so if you don't know what
+   "Keep this file name-space clean" means, talk to drepper at gnu.org
+   before changing it!
+   Copyright (C) 1987,88,89,90,91,92,93,94,95,96,98,99,2000,2001,2002,2003,2004,2006
+	Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License along
+   with this program; if not, write to the Free Software Foundation,
+   Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
+
+#ifndef _LIBC
+# include <config.h>
+#endif
+
+#include "getopt.h"
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+#ifdef __VMS
+# include <unixlib.h>
+#endif
+
+#ifdef _LIBC
+# include <libintl.h>
+#else
+# include "gettext.h"
+# define _(msgid) gettext (msgid)
+#endif
+
+#if defined _LIBC && defined USE_IN_LIBIO
+# include <wchar.h>
+#endif
+
+#ifndef attribute_hidden
+# define attribute_hidden
+#endif
+
+/* Unlike standard Unix `getopt', functions like `getopt_long'
+   let the user intersperse the options with the other arguments.
+
+   As `getopt_long' works, it permutes the elements of ARGV so that,
+   when it is done, all the options precede everything else.  Thus
+   all application programs are extended to handle flexible argument order.
+
+   Using `getopt' or setting the environment variable POSIXLY_CORRECT
+   disables permutation.
+   Then the application's behavior is completely standard.
+
+   GNU application programs can use a third alternative mode in which
+   they can distinguish the relative order of options and other arguments.  */
+
+#include "getopt_int.h"
+
+/* For communication from `getopt' to the caller.
+   When `getopt' finds an option that takes an argument,
+   the argument value is returned here.
+   Also, when `ordering' is RETURN_IN_ORDER,
+   each non-option ARGV-element is returned here.  */
+
+char *optarg;
+
+/* Index in ARGV of the next element to be scanned.
+   This is used for communication to and from the caller
+   and for communication between successive calls to `getopt'.
+
+   On entry to `getopt', zero means this is the first call; initialize.
+
+   When `getopt' returns -1, this is the index of the first of the
+   non-option elements that the caller should itself scan.
+
+   Otherwise, `optind' communicates from one call to the next
+   how much of ARGV has been scanned so far.  */
+
+/* 1003.2 says this must be 1 before any call.  */
+int optind = 1;
+
+/* Callers store zero here to inhibit the error message
+   for unrecognized options.  */
+
+int opterr = 1;
+
+/* Set to an option character which was unrecognized.
+   This must be initialized on some systems to avoid linking in the
+   system's own getopt implementation.  */
+
+int optopt = '?';
+
+/* Keep a global copy of all internal members of getopt_data.  */
+
+static struct _getopt_data getopt_data;
+
+
+#if defined HAVE_DECL_GETENV && !HAVE_DECL_GETENV
+extern char *getenv ();
+#endif
+
+#ifdef _LIBC
+/* Stored original parameters.
+   XXX This is no good solution.  We should rather copy the args so
+   that we can compare them later.  But we must not use malloc(3).  */
+extern int __libc_argc;
+extern char **__libc_argv;
+
+/* Bash 2.0 gives us an environment variable containing flags
+   indicating ARGV elements that should not be considered arguments.  */
+
+# ifdef USE_NONOPTION_FLAGS
+/* Defined in getopt_init.c  */
+extern char *__getopt_nonoption_flags;
+# endif
+
+# ifdef USE_NONOPTION_FLAGS
+#  define SWAP_FLAGS(ch1, ch2) \
+  if (d->__nonoption_flags_len > 0)					      \
+    {									      \
+      char __tmp = __getopt_nonoption_flags[ch1];			      \
+      __getopt_nonoption_flags[ch1] = __getopt_nonoption_flags[ch2];	      \
+      __getopt_nonoption_flags[ch2] = __tmp;				      \
+    }
+# else
+#  define SWAP_FLAGS(ch1, ch2)
+# endif
+#else	/* !_LIBC */
+# define SWAP_FLAGS(ch1, ch2)
+#endif	/* _LIBC */
+
+/* Exchange two adjacent subsequences of ARGV.
+   One subsequence is elements [first_nonopt,last_nonopt)
+   which contains all the non-options that have been skipped so far.
+   The other is elements [last_nonopt,optind), which contains all
+   the options processed since those non-options were skipped.
+
+   `first_nonopt' and `last_nonopt' are relocated so that they describe
+   the new indices of the non-options in ARGV after they are moved.  */
+
+static void
+exchange (char **argv, struct _getopt_data *d)
+{
+  int bottom = d->__first_nonopt;
+  int middle = d->__last_nonopt;
+  int top = d->optind;
+  char *tem;
+
+  /* Exchange the shorter segment with the far end of the longer segment.
+     That puts the shorter segment into the right place.
+     It leaves the longer segment in the right place overall,
+     but it consists of two parts that need to be swapped next.  */
+
+#if defined _LIBC && defined USE_NONOPTION_FLAGS
+  /* First make sure the handling of the `__getopt_nonoption_flags'
+     string can work normally.  Our top argument must be in the range
+     of the string.  */
+  if (d->__nonoption_flags_len > 0 && top >= d->__nonoption_flags_max_len)
+    {
+      /* We must extend the array.  The user plays games with us and
+	 presents new arguments.  */
+      char *new_str = malloc (top + 1);
+      if (new_str == NULL)
+	d->__nonoption_flags_len = d->__nonoption_flags_max_len = 0;
+      else
+	{
+	  memset (__mempcpy (new_str, __getopt_nonoption_flags,
+			     d->__nonoption_flags_max_len),
+		  '\0', top + 1 - d->__nonoption_flags_max_len);
+	  d->__nonoption_flags_max_len = top + 1;
+	  __getopt_nonoption_flags = new_str;
+	}
+    }
+#endif
+
+  while (top > middle && middle > bottom)
+    {
+      if (top - middle > middle - bottom)
+	{
+	  /* Bottom segment is the short one.  */
+	  int len = middle - bottom;
+	  register int i;
+
+	  /* Swap it with the top part of the top segment.  */
+	  for (i = 0; i < len; i++)
+	    {
+	      tem = argv[bottom + i];
+	      argv[bottom + i] = argv[top - (middle - bottom) + i];
+	      argv[top - (middle - bottom) + i] = tem;
+	      SWAP_FLAGS (bottom + i, top - (middle - bottom) + i);
+	    }
+	  /* Exclude the moved bottom segment from further swapping.  */
+	  top -= len;
+	}
+      else
+	{
+	  /* Top segment is the short one.  */
+	  int len = top - middle;
+	  register int i;
+
+	  /* Swap it with the bottom part of the bottom segment.  */
+	  for (i = 0; i < len; i++)
+	    {
+	      tem = argv[bottom + i];
+	      argv[bottom + i] = argv[middle + i];
+	      argv[middle + i] = tem;
+	      SWAP_FLAGS (bottom + i, middle + i);
+	    }
+	  /* Exclude the moved top segment from further swapping.  */
+	  bottom += len;
+	}
+    }
+
+  /* Update records for the slots the non-options now occupy.  */
+
+  d->__first_nonopt += (d->optind - d->__last_nonopt);
+  d->__last_nonopt = d->optind;
+}
+
+/* Initialize the internal data when the first call is made.  */
+
+static const char *
+_getopt_initialize (int argc, char **argv, const char *optstring,
+		    int posixly_correct, struct _getopt_data *d)
+{
+  /* Start processing options with ARGV-element 1 (since ARGV-element 0
+     is the program name); the sequence of previously skipped
+     non-option ARGV-elements is empty.  */
+
+  d->__first_nonopt = d->__last_nonopt = d->optind;
+
+  d->__nextchar = NULL;
+
+  d->__posixly_correct = posixly_correct || !!getenv ("POSIXLY_CORRECT");
+
+  /* Determine how to handle the ordering of options and nonoptions.  */
+
+  if (optstring[0] == '-')
+    {
+      d->__ordering = RETURN_IN_ORDER;
+      ++optstring;
+    }
+  else if (optstring[0] == '+')
+    {
+      d->__ordering = REQUIRE_ORDER;
+      ++optstring;
+    }
+  else if (d->__posixly_correct)
+    d->__ordering = REQUIRE_ORDER;
+  else
+    d->__ordering = PERMUTE;
+
+#if defined _LIBC && defined USE_NONOPTION_FLAGS
+  if (!d->__posixly_correct
+      && argc == __libc_argc && argv == __libc_argv)
+    {
+      if (d->__nonoption_flags_max_len == 0)
+	{
+	  if (__getopt_nonoption_flags == NULL
+	      || __getopt_nonoption_flags[0] == '\0')
+	    d->__nonoption_flags_max_len = -1;
+	  else
+	    {
+	      const char *orig_str = __getopt_nonoption_flags;
+	      int len = d->__nonoption_flags_max_len = strlen (orig_str);
+	      if (d->__nonoption_flags_max_len < argc)
+		d->__nonoption_flags_max_len = argc;
+	      __getopt_nonoption_flags =
+		(char *) malloc (d->__nonoption_flags_max_len);
+	      if (__getopt_nonoption_flags == NULL)
+		d->__nonoption_flags_max_len = -1;
+	      else
+		memset (__mempcpy (__getopt_nonoption_flags, orig_str, len),
+			'\0', d->__nonoption_flags_max_len - len);
+	    }
+	}
+      d->__nonoption_flags_len = d->__nonoption_flags_max_len;
+    }
+  else
+    d->__nonoption_flags_len = 0;
+#endif
+
+  return optstring;
+}
+
+/* Scan elements of ARGV (whose length is ARGC) for option characters
+   given in OPTSTRING.
+
+   If an element of ARGV starts with '-', and is not exactly "-" or "--",
+   then it is an option element.  The characters of this element
+   (aside from the initial '-') are option characters.  If `getopt'
+   is called repeatedly, it returns successively each of the option characters
+   from each of the option elements.
+
+   If `getopt' finds another option character, it returns that character,
+   updating `optind' and `nextchar' so that the next call to `getopt' can
+   resume the scan with the following option character or ARGV-element.
+
+   If there are no more option characters, `getopt' returns -1.
+   Then `optind' is the index in ARGV of the first ARGV-element
+   that is not an option.  (The ARGV-elements have been permuted
+   so that those that are not options now come last.)
+
+   OPTSTRING is a string containing the legitimate option characters.
+   If an option character is seen that is not listed in OPTSTRING,
+   return '?' after printing an error message.  If you set `opterr' to
+   zero, the error message is suppressed but we still return '?'.
+
+   If a char in OPTSTRING is followed by a colon, that means it wants an arg,
+   so the following text in the same ARGV-element, or the text of the following
+   ARGV-element, is returned in `optarg'.  Two colons mean an option that
+   wants an optional arg; if there is text in the current ARGV-element,
+   it is returned in `optarg', otherwise `optarg' is set to zero.
+
+   If OPTSTRING starts with `-' or `+', it requests different methods of
+   handling the non-option ARGV-elements.
+   See the comments about RETURN_IN_ORDER and REQUIRE_ORDER, above.
+
+   Long-named options begin with `--' instead of `-'.
+   Their names may be abbreviated as long as the abbreviation is unique
+   or is an exact match for some defined option.  If they have an
+   argument, it follows the option name in the same ARGV-element, separated
+   from the option name by a `=', or else the in next ARGV-element.
+   When `getopt' finds a long-named option, it returns 0 if that option's
+   `flag' field is nonzero, the value of the option's `val' field
+   if the `flag' field is zero.
+
+   LONGOPTS is a vector of `struct option' terminated by an
+   element containing a name which is zero.
+
+   LONGIND returns the index in LONGOPT of the long-named option found.
+   It is only valid when a long-named option has been found by the most
+   recent call.
+
+   If LONG_ONLY is nonzero, '-' as well as '--' can introduce
+   long-named options.
+
+   If POSIXLY_CORRECT is nonzero, behave as if the POSIXLY_CORRECT
+   environment variable were set.  */
+
+int
+_getopt_internal_r (int argc