From wk at gnupg.org Mon Oct 2 14:54:33 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Oct 2 14:57:46 2006 Subject: [PATCH 0/3] Fix the "gpg: [don't know]: invalid packet (ctb=14)" bug In-Reply-To: <82mz8ol0jr.fsf@mid.bfk.de> (Florian Weimer's message of "Mon, 25 Sep 2006 12:10:00 +0200") References: <82mz8ol0jr.fsf@mid.bfk.de> Message-ID: <87y7rylvxy.fsf@wheatstone.g10code.de> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20061002/db76d513/attachment.pgp From johnmoore3rd at joimail.com Mon Oct 2 22:56:30 2006 From: johnmoore3rd at joimail.com (John W. Moore III) Date: Mon Oct 2 22:54:52 2006 Subject: 1.4/BRANCH svn4280 & 4281 Message-ID: <45217CFE.5090505@joimail.com> Let me state first I am attempting to Compile using MSYS/MinGW per instruction from the Honorable C. Bianco. Early in the process I see the line: checking for strsep.....no The Compile process terminates with: keygen.o:keygen.c:(.text+0x47c): more undefined references to `strsep' follow make[1]: *** [gpg.exe] Error 1 make[1]: Leaving directory `/home/Compaq_Owner/4281/g10' make: *** [install-recursive] Error 1 Making check in m4 make[1]: Entering directory `/home/Compaq_Owner/4281/m4' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/Compaq_Owner/4281/m4' Making check in intl make[1]: Entering directory `/home/Compaq_Owner/4281/intl' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/Compaq_Owner/4281/intl' Making check in zlib make[1]: Entering directory `/home/Compaq_Owner/4281/zlib' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/Compaq_Owner/4281/zlib' Making check in util make[1]: Entering directory `/home/Compaq_Owner/4281/util' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/Compaq_Owner/4281/util' Making check in mpi make[1]: Entering directory `/home/Compaq_Owner/4281/mpi' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/Compaq_Owner/4281/mpi' Making check in cipher make[1]: Entering directory `/home/Compaq_Owner/4281/cipher' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/Compaq_Owner/4281/cipher' Making check in tools make[1]: Entering directory `/home/Compaq_Owner/4281/tools' make[1]: Nothing to be done for `check'. make[1]: Leaving directory `/home/Compaq_Owner/4281/tools' Making check in g10 make[1]: Entering directory `/home/Compaq_Owner/4281/g10' gcc -O3 -mmmx -m3dnow -msse -mfpmath=sse -march=athlon-4 -Wall -s -static -o gpg.exe gpg.o build-packet.o compress.o compress-bz2.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-packet.o status.o plaintext.o sig-check.o keylist.o signal.o cardglue.o tlv.o card-util.o app-openpgp.o iso7816.o apdu.o ccid-driver.o pkclist.o skclist.o pubkey-enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdbio.o delkey.o keygen.o pipemode.o helptext.o keyserver.o photoid.o exec.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -lz -lbz2 -lwsock32 gpg.o:gpg.c:(.text+0x2478): undefined reference to `strsep' gpg.o:gpg.c:(.text+0x39d9): undefined reference to `strsep' gpg.o:gpg.c:(.text+0x3bb4): undefined reference to `strsep' gpg.o:gpg.c:(.text+0x57f1): undefined reference to `strsep' misc.o:misc.c:(.text+0x18bf): undefined reference to `strsep' keygen.o:keygen.c:(.text+0x47c): more undefined references to `strsep' follow make[1]: *** [gpg.exe] Error 1 make[1]: Leaving directory `/home/Compaq_Owner/4281/g10' make: *** [check-recursive] Error 1 I would very much appreciate any advice or direction available! JOHN :( Timestamp: Monday 02 Oct 2006, 16:56 --400 (Eastern Daylight Time) From dshaw at jabberwocky.com Tue Oct 3 03:01:11 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Oct 3 02:59:36 2006 Subject: 1.4/BRANCH svn4280 & 4281 In-Reply-To: <45217CFE.5090505@joimail.com> References: <45217CFE.5090505@joimail.com> Message-ID: <20061003010111.GA553@jabberwocky.com> On Mon, Oct 02, 2006 at 04:56:30PM -0400, John W. Moore III wrote: > Let me state first I am attempting to Compile using MSYS/MinGW per > instruction from the Honorable C. Bianco. > > Early in the process I see the line: > > checking for strsep.....no > > The Compile process terminates with: > > keygen.o:keygen.c:(.text+0x47c): more undefined references to `strsep' > follow Fixed. It was a typo. David From rw at rlworkman.net Wed Oct 4 06:49:00 2006 From: rw at rlworkman.net (Robby Workman) Date: Wed Oct 4 06:48:00 2006 Subject: gnupg-1.9.90 build problem In-Reply-To: <4519300B.3020700@unob.cz> References: <4519300B.3020700@unob.cz> Message-ID: <45233D3C.1010700@rlworkman.net> Ladislav Hagara wrote: > trying to compile gnupg-1.9.90 and seems I have some problem with > readline (from gnupg's NEWS: Made readline work for gpg). > I have installed last 5.1 readline with last patches. > Please, is it a problem of my box (readline) or gnupg? Similar/same error here on Slackware 11.0 (readline 5.1). Adding --with-readline=no to configure results in different error message. The first message pasted is from configure --prefix=/usr, and the second (at the bottom) is from adding the extra readline=no flag. Any suggestions? I don't really know C well enough to even read it, much less figure out what's wrong. Thanks in advance, Robby if i486-slackware-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I/usr/include -O2 -march=i486 -mtune=i686 -Wall -MT gpgrlhelp.o -MD -MP -MF ".deps/gpgrlhelp.Tpo" -c -o gpgrlhelp.o gpgrlhelp.c; \ then mv -f ".deps/gpgrlhelp.Tpo" ".deps/gpgrlhelp.Po"; else rm -f ".deps/gpgrlhelp.Tpo"; exit 1; fi In file included from /usr/include/readline/readline.h:37, from gpgrlhelp.c:34: /usr/include/readline/rltypedefs.h:65: error: syntax error before '*' token In file included from gpgrlhelp.c:34: /usr/include/readline/readline.h:416: error: syntax error before '*' token /usr/include/readline/readline.h:532: error: syntax error before '*' token /usr/include/readline/readline.h:533: error: syntax error before '*' token /usr/include/readline/readline.h:823: error: syntax error before "FILE" /usr/include/readline/readline.h:840: error: syntax error before '}' token gpgrlhelp.c: In function `init_stream': gpgrlhelp.c:66: warning: assignment from incompatible pointer type make[2]: *** [gpgrlhelp.o] Error 1 make[2]: Leaving directory `/tmp/gnupg-1.9.90/common' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/gnupg-1.9.90' make: *** [all] Error 2 However, adding --with-readline=no to configure results in this: if i486-slackware-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I/usr/include -O2 -march=i486 -mtune=i686 -Wall -MT gpgrlhelp.o -MD -MP -MF ".deps/gpgrlhelp.Tpo" -c -o gpgrlhelp.o gpgrlhelp.c; \ then mv -f ".deps/gpgrlhelp.Tpo" ".deps/gpgrlhelp.Po"; else rm -f ".deps/gpgrlhelp.Tpo"; exit 1; fi gpgrlhelp.c: In function `set_completer': gpgrlhelp.c:45: error: `rl_attempted_completion_function' undeclared (first use in this function) gpgrlhelp.c:45: error: (Each undeclared identifier is reported only once gpgrlhelp.c:45: error: for each function it appears in.) gpgrlhelp.c:46: error: `rl_inhibit_completion' undeclared (first use in this function) gpgrlhelp.c: In function `inhibit_completion': gpgrlhelp.c:52: error: `rl_inhibit_completion' undeclared (first use in this function) gpgrlhelp.c: In function `cleanup_after_signal': gpgrlhelp.c:58: warning: implicit declaration of function `rl_free_line_state' gpgrlhelp.c:59: warning: implicit declaration of function `rl_cleanup_after_signal' gpgrlhelp.c: In function `init_stream': gpgrlhelp.c:65: error: `rl_catch_signals' undeclared (first use in this function) gpgrlhelp.c:66: error: `rl_instream' undeclared (first use in this function) gpgrlhelp.c:66: error: `rl_outstream' undeclared (first use in this function) gpgrlhelp.c:67: error: `rl_inhibit_completion' undeclared (first use in this function) gpgrlhelp.c: In function `gnupg_rl_initialize': gpgrlhelp.c:80: error: `readline' undeclared (first use in this function) gpgrlhelp.c:81: error: `add_history' undeclared (first use in this function) gpgrlhelp.c:82: error: `rl_readline_name' undeclared (first use in this function) make[2]: *** [gpgrlhelp.o] Error 1 make[2]: Leaving directory `/tmp/gnupg-1.9.90/common' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/gnupg-1.9.90' make: *** [all] Error 2 -- http://rlworkman.net From wk at gnupg.org Wed Oct 4 19:15:20 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 4 19:22:29 2006 Subject: GnuPG 1.9.91 released Message-ID: <87k63ggfyv.fsf@wheatstone.g10code.de> Hi, just a brief note, that version 1.9.91 of GnuPG has been released. To build it, you also need to get the latest libassuan (0.9.2). ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.91.bz2 ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.91.bz2.sig ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.90-1.9.91.diff.bz2 (Note that the diff file is smaller than usual because it does not include diffs for the po files.) ftp://ftp.gnupg.org/gcrypt/alpha/libassuan/libassuan-0.9.2.bz2 ftp://ftp.gnupg.org/gcrypt/alpha/libassuan/libassuan-0.9.2.bz2.sig Salam-Shalom, Werner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20061004/c74adb5b/attachment.pgp From rdieter at math.unl.edu Wed Oct 4 21:36:16 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed Oct 4 21:35:42 2006 Subject: GnuPG 1.9.91 released References: <87k63ggfyv.fsf@wheatstone.g10code.de> Message-ID: Werner Koch wrote: > just a brief note, that version 1.9.91 of GnuPG has been released. build (still) fails for me on Fedora Core (6), details appended... Is this a problem with my install/copy of readline-5.1? -- Rex ... gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I/usr/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -f stack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wall -Wno-point er-sign -c gpgrlhelp.c In file included from /usr/include/readline/readline.h:37, from gpgrlhelp.c:34: /usr/include/readline/rltypedefs.h:65: error: expected ')' before '*' token In file included from gpgrlhelp.c:34: /usr/include/readline/readline.h:416: error: expected ')' before '*' token /usr/include/readline/readline.h:532: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token /usr/include/readline/readline.h:533: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token /usr/include/readline/readline.h:555: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token /usr/include/readline/readline.h:823: error: expected specifier-qualifier-list before 'FILE' gpgrlhelp.c: In function 'init_stream': gpgrlhelp.c:66: error: 'rl_instream' undeclared (first use in this function) gpgrlhelp.c:66: error: (Each undeclared identifier is reported only once gpgrlhelp.c:66: error: for each function it appears in.) gpgrlhelp.c:66: error: 'rl_outstream' undeclared (first use in this function) make[2]: *** [gpgrlhelp.o] Error 1 make[2]: Leaving directory `/builddir/build/BUILD/gnupg-1.9.91/common' From dshaw at jabberwocky.com Wed Oct 4 22:39:38 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Oct 4 22:37:52 2006 Subject: GnuPG 1.9.91 released In-Reply-To: References: <87k63ggfyv.fsf@wheatstone.g10code.de> Message-ID: <20061004203938.GB10741@jabberwocky.com> On Wed, Oct 04, 2006 at 02:36:16PM -0500, Rex Dieter wrote: > Werner Koch wrote: > > > just a brief note, that version 1.9.91 of GnuPG has been released. > > build (still) fails for me on Fedora Core (6), details appended... Is this a > problem with my install/copy of readline-5.1? No. Here is a patch. David -------------- next part -------------- Index: gpgrlhelp.c =================================================================== --- gpgrlhelp.c (revision 4287) +++ gpgrlhelp.c (working copy) @@ -31,6 +31,7 @@ #ifdef HAVE_LIBREADLINE #define GNUPG_LIBREADLINE_H_INCLUDED +#include #include #include #endif From wk at gnupg.org Thu Oct 5 09:22:05 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Oct 5 09:27:39 2006 Subject: GnuPG 1.9.91 released In-Reply-To: <20061004203938.GB10741@jabberwocky.com> (David Shaw's message of "Wed, 4 Oct 2006 16:39:38 -0400") References: <87k63ggfyv.fsf@wheatstone.g10code.de> <20061004203938.GB10741@jabberwocky.com> Message-ID: <87odsrfcrm.fsf@wheatstone.g10code.de> On Wed, 4 Oct 2006 22:39, David Shaw said: > No. Here is a patch. I wonder why this did not happen on my Debian. I guess I need to release another gnupg 1.9 soon. However please test so that we can detect other grave problems first. Salam-Shalom, Werner From wk at gnupg.org Thu Oct 5 09:33:37 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Oct 5 09:37:33 2006 Subject: libassuan 0.6.10 build fails on old Linux In-Reply-To: <20060920151849.GB12647@free.fr> (Alain Guibert's message of "Wed, 20 Sep 2006 17:18:49 +0200 (CEST)") References: <20060910063154.GB9023@free.fr> <20060920151849.GB12647@free.fr> Message-ID: <87k63ffc8e.fsf@wheatstone.g10code.de> On Wed, 20 Sep 2006 17:18, Alain Guibert said: > Also tried libassuan 0.9.0, it fails a little earlier: > > | gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -c assuan-pipe-connect.c > | assuan-pipe-connect.c: In function `socketpair_connect': > | assuan-pipe-connect.c:380: `AF_LOCAL' undeclared (first use this function) > | assuan-pipe-connect.c:380: (Each undeclared identifier is reported only once This has been fixed in 0.9.2. > | /tmp/libassuan-0.9.0/src/assuan-handler.c:525: undefined reference to `gpg_strerror_r' int gpg_strerror_r (unsigned int err, char *buf, size_t buflen) __attribute__ ((weak)); Does anyone know which version of gcc introduced the weak attribute? A workaround is to replace it by the weak pragma as done in assuan-io.c . > | ../src/libassuan.a(assuan-uds.o): In function `uds_reader': > | /tmp/libassuan-0.9.0/src/assuan-uds.c:69: undefined reference to `CMSG_SPACE' > | /tmp/libassuan-0.9.0/src/assuan-uds.c:95: undefined reference to `CMSG_FIRSTHDR' We need better detection for this. Need to check whether we have such a detection at all. > | /tmp/libassuan-0.9.0/src/assuan-io.c:162: undefined reference to `FD_ZERO' Can you please add #include above the sys/types.h? All other incldue files for select are included although I wonder why FD_foo might be defined in that include file. Shalom-Salam, Werner From robbat2 at gentoo.org Thu Oct 5 09:41:27 2006 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Thu Oct 5 11:21:20 2006 Subject: GnuPG 1.9.91 released In-Reply-To: <87odsrfcrm.fsf@wheatstone.g10code.de> References: <87k63ggfyv.fsf@wheatstone.g10code.de> <20061004203938.GB10741@jabberwocky.com> <87odsrfcrm.fsf@wheatstone.g10code.de> Message-ID: <20061005074127.GC14741@curie-int.orbis-terrarum.net> On Thu, Oct 05, 2006 at 09:22:05AM +0200, Werner Koch wrote: > On Wed, 4 Oct 2006 22:39, David Shaw said: > > No. Here is a patch. > I wonder why this did not happen on my Debian. I guess I need to > release another gnupg 1.9 soon. However please test so that we can > detect other grave problems first. Compiles and works fine (ppc, x86, amd64) here on Gentoo without that patch as well. I've stuck it into our ~arch tree as I usually do. -- Robin Hugh Johnson E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : /pipermail/attachments/20061005/8f4f8b7c/attachment.pgp From ariga at os.rim.or.jp Thu Oct 5 13:38:32 2006 From: ariga at os.rim.or.jp (ARIGA Seiji) Date: Thu Oct 5 13:36:48 2006 Subject: x509 v1 certificate In-Reply-To: <20060930.111136.35717327.say@khaotic.net> References: <20060925.220849.167661107.kazu@iij.ad.jp> <87fyeft2gq.fsf@wheatstone.g10code.de> <20060929.172600.88529589.say@khaotic.net> <87mz8iodd5.fsf@wheatstone.g10code.de> <20060930.111136.35717327.say@khaotic.net> Message-ID: <20061005.203832.22558992.say@khaotic.net> hi. On Sat, 30 Sep 2006 11:11:36 +0900 (JST), ARIGA Seiji wrote, > > > ---- > > > gpgsm: error getting key usage information: No value > > > gpgsm: invalid certification chain: No value > > > ---- > > > > Sure, that you added the "relax" flag to the appropriate line of the > > trustlist.txt and also updated the gpg-agent.? > > do you mean that is expected ? i thought you've changed gpgsm to allow > us to use/validate old VeriSign cert (v1 certs). > > # but as i showed, "--verify" still failed. > > without "relax", i only got this. > > ---- > gpgsm: invalid certification chain: No value > ---- > > i think certlist.c:cert_usage_p() returns message > above ("... key usage ..."). > > # this is called by certchain.c:gpgsm_cert_use_cert_p() > # (which looks irrelevant to "relax" flag). did i misunderstand something ? i cannot still verify certs signed by VeriSign's old cert. // ARIGA Seiji From beebe at math.utah.edu Thu Oct 5 18:01:27 2006 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Thu Oct 5 18:54:53 2006 Subject: [gnupg-devel] libassuan-0.9.2 build feedback Message-ID: In builds of libassuan-0.9.2 in 34 compilation environments on a score of different Unix systems, the builds and validation tests succeeded in 18 of them. Here is a summary of the failures: ============================================================ Machinetype: Apple MacPro (2 dual-core 3000 MHz Xeon CPUs, 4GB RAM); Darwin 8.7.3 (Mac OS X 10.4.7 (8K1124)) Remote gcc version: i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363) Configure environment: CC=gcc CXX=g++ LDFLAGS=-L/usr/local/lib Linking failed: gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -L/usr/local/lib -o fdpassing fdpassing.o ../src/libassuan.a /usr/bin/ld: Undefined symbols: _pth_fdmode _pth_read _pth_select _pth_waitpid _pth_write collect2: ld returned 1 exit status make[3]: *** [fdpassing] Error 1 This happens because LDFLAGS is not propagated properly from the configure environment to the Makefile. A restart with make LIBS='-L/usr/local/lib -lpth' all check produced a successful build and validation. The same thing happened in a Mac OS X 10.3.9 PowerPC system. ============================================================ Machinetype: Apple MacPro (2 dual-core 3000 MHz Xeon CPUs, 4GB RAM); Darwin 8.7.3 (Mac OS X 10.4.7 (8K1124)) Remote gcc version: i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363) Configure environment: CC=gcc CFLAGS=-m64 CXX=g++ CXXFLAGS=-m64 LDFLAGS=-L/usr/local/lib checking for socklen_t equivalent... configure: error: Cannot find a type to use in place of socklen_t 9.45 real 1.59 user 4.42 sys make: *** No targets specified and no makefile found. Stop. Like GNU/Linux on the AMD64 architecture, Mac OS X on the Intel Xeon EM64T system provides a 32-bit world and a 64-bit world. Apple supplies fat binaries and libraries that contain code for both worlds, and often, also for the same worlds in the older PowerPC systems. However, at end user sites, preparation of fat files is too problematic and failure prone, so I follow the practice on the AMD64 of having /usr/local/lib32 for 32-bit libraries, and /usr/local/lib for 64-bit libraries. Something prevents socklen_t from being seen in the 64-bit world on Mac OS X. ============================================================ Machinetype: SGI Origin/200-4 (180 MHz) (4 R10000 CPUs); IRIX 6.5 Remote gcc version: gcc (GCC) 3.4.3 Configure environment: CC=gcc CFLAGS=-I/usr/local/include CXX=g++ CXXFLAGS=-I/usr/local/include LDFLAGS=-Wl,-rpath,/usr/local/libn32 if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT assuan-uds.o -MD -MP -MF ".deps/assuan-uds.Tpo" -c -o assuan-uds.o assuan-uds.c; \ then mv -f ".deps/assuan-uds.Tpo" ".deps/assuan-uds.Po"; else rm -f ".deps/assuan-uds.Tpo"; exit 1; fi assuan-uds.c: In function `uds_reader': assuan-uds.c:73: warning: implicit declaration of function `CMSG_SPACE' assuan-uds.c:95: warning: cast increases required alignment of target type assuan-uds.c:96: warning: implicit declaration of function `CMSG_LEN' assuan-uds.c:99: error: `SCM_RIGHTS' undeclared (first use in this function) assuan-uds.c:99: error: (Each undeclared identifier is reported only once assuan-uds.c:99: error: for each function it appears in.) ... ======================================================================== Machinetype: Sun W40z (4 CPUs, 2400 MHz AMD64 Opteron, 8GB RAM); FreeBSD 5.0-RELEASE #0 Remote gcc version: gcc (GCC) 3.4.3 Configure environment: CC=gcc CFLAGS=-I/usr/local/include CXX=g++ LDFLAGS=-Wl,-rpath,/usr/local/lib if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT assuan-util.o -MD -MP -MF ".deps/assuan-util.Tpo" -c -o assuan-util.o assuan-util.c; \ then mv -f ".deps/assuan-util.Tpo" ".deps/assuan-util.Po"; else rm -f ".deps/assuan-util.Tpo"; exit 1; fi assuan-util.c:31: error: redefinition of '__sputc' /usr/local/lib/gcc/i386-unknown-freebsd5.0/3.4.3/include/stdio.h:405: error: previous definition of '__sputc' was here assuan-util.c: In function `__sputc': assuan-util.c:31: error: storage class specified for parameter `alloc_func' assuan-util.c:31: error: parameter `alloc_func' is initialized assuan-util.c:32: error: storage class specified for parameter `realloc_func' assuan-util.c:32: error: parameter `realloc_func' is initialized assuan-util.c:33: error: storage class specified for parameter `free_func' assuan-util.c:33: error: parameter `free_func' is initialized ... ============================================================ Machinetype: DEC Alpha 4100-5/466 (4 21164 EV5 CPUs, 466 MHz, 2GB RAM); OSF/1 4.0F Remote gcc version: gcc (GCC) 3.3.3 Configure environment: CC=gcc CFLAGS="-mieee -I/usr/local/include" CXX=g++ CXXFLAGS="-mieee -I/usr/local/include" LDFLAGS="-Wl,-rpath,/usr/local/lib -L/usr/local/lib" LIBS="-lgccsnprintf" if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -mieee -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT assuan-socket-connect.o -MD -MP -MF ".deps/assuan-socket-connect.Tpo" -c -o assuan-socket-connect.o assuan-socket-connect.c; \ then mv -f ".deps/assuan-socket-connect.Tpo" ".deps/assuan-socket-connect.Po"; else rm -f ".deps/assuan-socket-connect.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -mieee -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT assuan-uds.o -MD -MP -MF ".deps/assuan-uds.Tpo" -c -o assuan-uds.o assuan-uds.c; \ then mv -f ".deps/assuan-uds.Tpo" ".deps/assuan-uds.Po"; else rm -f ".deps/assuan-uds.Tpo"; exit 1; fi assuan-uds.c: In function `uds_reader': assuan-uds.c:73: warning: implicit declaration of function `CMSG_SPACE' assuan-uds.c:85: error: structure has no member named `msg_control' assuan-uds.c:86: error: structure has no member named `msg_controllen' assuan-uds.c:95: error: structure has no member named `msg_control' ... ======================================================================== Machinetype: Sun Sun Fire V240 (2 UltraSPARC-IIIi CPUs, 1280 MHz, 8GB RAM); Solaris 9 Configure environment: CC=gcc CFLAGS=-I/usr/local/include CXX=g++ CXXFLAGS=-I/usr/local/include LDFLAGS="-R/usr/local/lib -L/usr/local/lib" if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT fdpassing.o -MD -MP -MF ".deps/fdpassing.Tpo" -c -o fdpassing.o fdpassing.c; \ then mv -f ".deps/fdpassing.Tpo" ".deps/fdpassing.Po"; else rm -f ".deps/fdpassing.Tpo"; exit 1; fi gcc -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -R/usr/local/lib -L/usr/local/lib -o fdpassing fdpassing.o ../src/libassuan.a Undefined first referenced symbol in file __xnet_connect ../src/libassuan.a(assuan-socket.o) CMSG_LEN ../src/libassuan.a(assuan-uds.o) __xnet_socket ../src/libassuan.a(assuan-socket.o) __xnet_socketpair ../src/libassuan.a(assuan-pipe-connect.o) __xnet_bind ../src/libassuan.a(assuan-socket.o) CMSG_SPACE ../src/libassuan.a(assuan-uds.o) __xnet_recvmsg ../src/libassuan.a(assuan-io.o) __xnet_sendmsg ../src/libassuan.a(assuan-io.o) ld: fatal: Symbol referencing errors. No output written to fdpassing collect2: ld returned 1 exit status ======================================================================== Machinetype: Sun Ultra Enterprise 450/400 (4 UltraSPARC-II CPUs, 400 MHz); Solaris 7 Remote gcc version: 2.95.3 Configure environment: CC=gcc CFLAGS=-I/usr/local/include CXX=g++ CXXFLAGS=-I/usr/local/include LDFLAGS="-R/usr/local/lib -L/usr/local/lib" gcc -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -R/usr/local/lib -L/usr/local/lib -o fdpassing fdpassing.o ../src/libassuan.a ../src/libassuan.a(assuan-pipe-connect.o): In function `socketpair_connect': assuan-pipe-connect.o(.text+0xc10): undefined reference to `__xnet_socketpair' ../src/libassuan.a(assuan-uds.o): In function `uds_reader': assuan-uds.o(.text+0x168): undefined reference to `CMSG_SPACE' assuan-uds.o(.text+0x2c8): undefined reference to `CMSG_LEN' ../src/libassuan.a(assuan-uds.o): In function `uds_sendfd': assuan-uds.o(.text+0x568): undefined reference to `CMSG_SPACE' assuan-uds.o(.text+0x694): undefined reference to `CMSG_LEN' ../src/libassuan.a(assuan-io.o): In function `_assuan_simple_sendmsg': assuan-io.o(.text+0x3f8): undefined reference to `__xnet_sendmsg' ../src/libassuan.a(assuan-io.o): In function `_assuan_simple_recvmsg': assuan-io.o(.text+0x5a8): undefined reference to `__xnet_recvmsg' ../src/libassuan.a(assuan-socket.o): In function `_assuan_sock_new': assuan-socket.o(.text+0x10c): undefined reference to `__xnet_socket' ../src/libassuan.a(assuan-socket.o): In function `_assuan_sock_connect': assuan-socket.o(.text+0x144): undefined reference to `__xnet_connect' ../src/libassuan.a(assuan-socket.o): In function `_assuan_sock_bind': assuan-socket.o(.text+0x17c): undefined reference to `__xnet_bind' collect2: ld returned 1 exit status make[3]: *** [fdpassing] Error 1 ======================================================================== Machinetype: Intel Pentium 4 (1800 MHz); Solaris 10 x86 Remote c99 version: cc: Sun C 5.8 Patch 121016-02 2006/03/31 Configure environment: CC=/opt/SUNWspro/bin/c99 CFLAGS="-I/usr/local/include" CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-I/usr/local/include" LDFLAGS="-R/usr/local/lib -L/usr/local/lib" checking for socklen_t equivalent... configure: error: Cannot find a type to use in place of socklen_t Command exited with non-zero status 1 ======================================================================== Machinetype: Intel Pentium 4 (1800 MHz); Solaris 10 x86 Remote gcc version: gcc (GCC) 3.3 Configure environment: CC=gcc CFLAGS=-I/usr/local/include CXX=g++ CXXFLAGS=-I/usr/local/include LDFLAGS="-R/usr/local/lib -L/usr/local/lib" if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT fdpassing.o -MD -MP -MF ".deps/fdpassing.Tpo" -c -o fdpassing.o fdpassing.c; \ then mv -f ".deps/fdpassing.Tpo" ".deps/fdpassing.Po"; else rm -f ".deps/fdpassing.Tpo"; exit 1; fi gcc -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -R/usr/local/lib -L/usr/local/lib -o fdpassing fdpassing.o ../src/libassuan.a Undefined first referenced symbol in file __xnet_connect ../src/libassuan.a(assuan-socket.o) __xnet_socket ../src/libassuan.a(assuan-socket.o) __xnet_socketpair ../src/libassuan.a(assuan-pipe-connect.o) __xnet_bind ../src/libassuan.a(assuan-socket.o) __xnet_recvmsg ../src/libassuan.a(assuan-io.o) __xnet_sendmsg ../src/libassuan.a(assuan-io.o) ld: fatal: Symbol referencing errors. No output written to fdpassing collect2: ld returned 1 exit status make[3]: *** [fdpassing] Error 1 ======================================================================== Machinetype: Sun Ultra Enterprise 2900 (4 CPUs, 1050 MHz UltraSPARC-IV, 16GB); Solaris 10 Remote gcc version: gcc (GCC) 3.3.6 Configure environment: CC=gcc CFLAGS=-I/usr/local/include CXX=g++ CXXFLAGS=-I/usr/local/include LDFLAGS="-R/usr/local/lib -L/usr/local/lib" if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT fdpassing.o -MD -MP -MF ".deps/fdpassing.Tpo" -c -o fdpassing.o fdpassing.c; \ then mv -f ".deps/fdpassing.Tpo" ".deps/fdpassing.Po"; else rm -f ".deps/fdpassing.Tpo"; exit 1; fi gcc -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -R/usr/local/lib -L/usr/local/lib -o fdpassing fdpassing.o ../src/libassuan.a Undefined first referenced symbol in file __xnet_connect ../src/libassuan.a(assuan-socket.o) __xnet_socket ../src/libassuan.a(assuan-socket.o) __xnet_socketpair ../src/libassuan.a(assuan-pipe-connect.o) __xnet_bind ../src/libassuan.a(assuan-socket.o) __xnet_recvmsg ../src/libassuan.a(assuan-io.o) __xnet_sendmsg ../src/libassuan.a(assuan-io.o) ld: fatal: Symbol referencing errors. No output written to fdpassing collect2: ld returned 1 exit status ======================================================================== Machinetype: Sun Ultra Enterprise 5500 (4 CPUs, 400 MHz UltraSPARC-II); Solaris 8 Remote gcc version: gcc (GCC) 3.3 Configure environment: CC=gcc CFLAGS=-I/usr/local/include CXX=g++ CXXFLAGS=-I/usr/local/include LDFLAGS="-R/usr/local/lib -L/usr/local/lib" gcc -I/usr/local/include -Wall -Wcast-align -Wshadow -Wstrict-prototypes -R/usr/local/lib -L/usr/local/lib -o fdpassing fdpassing.o ../src/libassuan.a Undefined first referenced symbol in file __xnet_connect ../src/libassuan.a(assuan-socket.o) CMSG_LEN ../src/libassuan.a(assuan-uds.o) __xnet_socket ../src/libassuan.a(assuan-socket.o) __xnet_socketpair ../src/libassuan.a(assuan-pipe-connect.o) __xnet_bind ../src/libassuan.a(assuan-socket.o) CMSG_SPACE ../src/libassuan.a(assuan-uds.o) __xnet_recvmsg ../src/libassuan.a(assuan-io.o) __xnet_sendmsg ../src/libassuan.a(assuan-io.o) ld: fatal: Symbol referencing errors. No output written to fdpassing ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From alguibert+gpd at free.fr Thu Oct 5 23:39:23 2006 From: alguibert+gpd at free.fr (Alain Guibert) Date: Thu Oct 5 23:42:37 2006 Subject: libassuan 0.6.10 build fails on old Linux In-Reply-To: <87k63ffc8e.fsf@wheatstone.g10code.de> References: <20060910063154.GB9023@free.fr> <20060920151849.GB12647@free.fr> <87k63ffc8e.fsf@wheatstone.g10code.de> Message-ID: <20061005213923.GA492@free.fr> Hello Werner, On Thursday, October 5, 2006 at 9:33:37 +0200, Werner Koch wrote: > On Wed, 20 Sep 2006 17:18, Alain Guibert said: >> Also tried libassuan 0.9.0, it fails a little earlier: >>| assuan-pipe-connect.c:380: `AF_LOCAL' undeclared (first use this function) > This has been fixed in 0.9.2. Again thank you very much for your support, Werner. >>| /tmp/libassuan-0.9.0/src/assuan-handler.c:525: undefined reference to `gpg_strerror_r' > A workaround is to replace it by the weak pragma as done in > assuan-io.c . OK: These 2 gpg_strerror_r/gpg_strsource errors are gone with those lines added after the definitions: | #pragma weak gpg_strerror_r | #pragma weak gpg_strsource >>| /tmp/libassuan-0.9.0/src/assuan-uds.c:69: undefined reference to `CMSG_SPACE' > We need better detection for this. Need to check whether we have such > a detection at all. A recursive grep in all includes finds not a single "CMSG_" here. >>| /tmp/libassuan-0.9.0/src/assuan-io.c:162: undefined reference to `FD_ZERO' > Can you please add #include above the sys/types.h? OK: Those undefined FD_ZERO/FD_SET errors are gone. I tried libassuan 0.9.2, and unfortunately I failed at a new place: | gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -c assuan-util.c | assuan-util.c: In function `putc_unlocked': | assuan-util.c:31: storage class specified for parameter `alloc_func' | assuan-util.c:31: parameter `alloc_func' is initialized | assuan-util.c:32: storage class specified for parameter `realloc_func' | assuan-util.c:32: parameter `realloc_func' is initialized | assuan-util.c:33: storage class specified for parameter `free_func' | assuan-util.c:33: parameter `free_func' is initialized | assuan-util.c:39: warning: declaration of `assuan_set_malloc_hooks' shadows global declaration | assuan-util.c:39: parse error before `{' | assuan-util.c:31: parm types given both in parmlist and separately | assuan-util.c:40: `alloc_func' undeclared (first use this function) | assuan-util.c:40: (Each undeclared identifier is reported only once | assuan-util.c:40: for each function it appears in.) | assuan-util.c:40: `new_alloc_func' undeclared (first use this function) | assuan-util.c:41: `realloc_func' undeclared (first use this function) | assuan-util.c:41: `new_realloc_func' undeclared (first use this function) | assuan-util.c:42: `free_func' undeclared (first use this function) | assuan-util.c:42: `new_free_func' undeclared (first use this function) | assuan-util.c:43: warning: control reaches end of non-void function | assuan-util.c: In function `_assuan_malloc': | assuan-util.c:48: `alloc_func' used prior to declaration | assuan-util.c:48: warning: implicit declaration of function `alloc_func' | assuan-util.c:48: warning: return makes pointer from integer without a cast | assuan-util.c: In function `_assuan_realloc': | assuan-util.c:54: `realloc_func' used prior to declaration | assuan-util.c:54: warning: implicit declaration of function `realloc_func' | assuan-util.c:54: warning: return makes pointer from integer without a cast | assuan-util.c: In function `_assuan_free': | assuan-util.c:80: `free_func' used prior to declaration | assuan-util.c:80: warning: implicit declaration of function `free_func' | make[3]: *** [assuan-util.o] Error 1 | make[3]: Leaving directory `/tmp/libassuan-0.9.2/src' | make[2]: *** [all] Error 2 | make[2]: Leaving directory `/tmp/libassuan-0.9.2/src' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/tmp/libassuan-0.9.2' | make: *** [all] Error 2 Alain. From JPClizbe at comcast.net Fri Oct 6 08:15:02 2006 From: JPClizbe at comcast.net (John Clizbe) Date: Fri Oct 6 08:53:24 2006 Subject: Build error Stable_1.4 r 4920 Message-ID: <4525F466.7090701@comcast.net> make[2]: Entering directory `/home/jpclizbe/gnupg-cvs/gnupg14/g10' gcc -O3 -mtune=pentium3 -march=pentium3 -mfpmath=sse -mmmx -mms-bitfields -msse -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat-nonliteral -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat-nonliteral -o gpg.exe gpg.o build-packet.o compress.o compress-bz2.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-packet.o status.o plaintext.o sig-check.o keylist.o signal.o cardglue.o tlv.o card-util.o app-openpgp.o iso7816.o apdu.o ccid-driver.o pkclist.o skclist.o pubkey-enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdbio.o delkey.o keygen.o pipemode.o helptext.o keyserver.o photoid.o exec.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -lz -lbz2 -lwsock32 -lreadline getkey.o(.text+0x7b8):getkey.c: undefined reference to `hextobyte' getkey.o(.text+0x914):getkey.c: undefined reference to `hextobyte' getkey.o(.text+0x9c5):getkey.c: undefined reference to `hextobyte' card-util.o(.text+0x38c7):card-util.c: undefined reference to `hextobyte' pubkey-enc.o(.text+0x824):pubkey-enc.c: undefined reference to `hextobyte' keyedit.o(.text+0x4d47):keyedit.c: more undefined references to `hextobyte' follow collect2: ld returned 1 exit status hextobyte is defines in util/compat.c but compat.c isn't mentioned in util/Makefile, nor is libcompat. They are mentioned in Makefile.am Tpyo? -- John P. Clizbe Inet: JPClizbe(a)comcast DOT nyet Golden Bear Networks PGP/GPG KeyID: 0x608D2A10 "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 663 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20061006/cdc19a91/signature.pgp From dshaw at jabberwocky.com Fri Oct 6 14:12:38 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Oct 6 14:10:57 2006 Subject: Build error Stable_1.4 r 4920 In-Reply-To: <4525F466.7090701@comcast.net> References: <4525F466.7090701@comcast.net> Message-ID: <20061006121238.GE14247@jabberwocky.com> On Fri, Oct 06, 2006 at 01:15:02AM -0500, John Clizbe wrote: > make[2]: Entering directory `/home/jpclizbe/gnupg-cvs/gnupg14/g10' > gcc -O3 -mtune=pentium3 -march=pentium3 -mfpmath=sse -mmmx -mms-bitfields -msse > -Wall -Wcast-align -Wshadow -Wstrict-prototypes -Wformat-nonliteral -Wall > -Wcast-align -Wshadow -Wstrict-prototypes -Wformat-nonliteral -o gpg.exe > gpg.o build-packet.o compress.o compress-bz2.o free-packet.o getkey.o keydb.o > keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o > progress.o misc.o openfile.o keyid.o parse-packet.o status.o plaintext.o > sig-check.o keylist.o signal.o cardglue.o tlv.o card-util.o app-openpgp.o > iso7816.o apdu.o ccid-driver.o pkclist.o skclist.o pubkey-enc.o passphrase.o > seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o > keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdbio.o delkey.o > keygen.o pipemode.o helptext.o keyserver.o photoid.o exec.o > ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -lz -lbz2 -lwsock32 > -lreadline > getkey.o(.text+0x7b8):getkey.c: undefined reference to `hextobyte' > getkey.o(.text+0x914):getkey.c: undefined reference to `hextobyte' > getkey.o(.text+0x9c5):getkey.c: undefined reference to `hextobyte' > card-util.o(.text+0x38c7):card-util.c: undefined reference to `hextobyte' > pubkey-enc.o(.text+0x824):pubkey-enc.c: undefined reference to `hextobyte' > keyedit.o(.text+0x4d47):keyedit.c: more undefined references to `hextobyte' follow > collect2: ld returned 1 exit status > > hextobyte is defines in util/compat.c but compat.c isn't mentioned in > util/Makefile, nor is libcompat. They are mentioned in Makefile.am > > Tpyo? I'm presuming you're using Mingw here, based on the link to wsock32. Is that correct? I don't think it's a typo as I am able to build on Mingw without error. Please send me the make output from building the util/ directory. Also, what version of autoconf and automake are you using? David From ametzler at downhill.at.eu.org Fri Oct 6 19:50:03 2006 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Fri Oct 6 19:53:13 2006 Subject: libksba CVE-2006-5111 Message-ID: Hello, just FYI, the issue addressed by these changes in libksba _____________________________________________________________ Noteworthy changes in version 0.9.15 (2006-06-20) ------------------------------------------------- * Fixed BER parser which was broken in the last release. Noteworthy changes in version 0.9.14 (2006-05-16) ------------------------------------------------- * Fixed broken OCSP requests. * Ignore invalid bytes appended to a certificate. _____________________________________________________________ Is now know as CVE-2006-5111. I guess Suse requested it. http://www.novell.com/linux/security/advisories/2006_23_sr.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5111 cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken. (c) Jasper Ffforde From coldredlemur at gmail.com Sat Oct 7 01:58:14 2006 From: coldredlemur at gmail.com (Ry Dahl) Date: Sat Oct 7 03:51:48 2006 Subject: gpgme 1.0 for ruby Message-ID: <21ee31950610061658t27fdcca3mb4618543784d0b89@mail.gmail.com> I am attempting to extend the ruby-gpgme bindings by Daiki Ueno to work with the gpgme 1.x API. I've made some changes to the Ruby API in order to make it more Ruby-ish. It's far from complete, but I have a preview version on my website at http://tinyclouds.org/info/gpgme. Cheers, Ry From wk at gnupg.org Tue Oct 10 09:54:41 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 10 09:57:56 2006 Subject: libassuan 0.6.10 build fails on old Linux In-Reply-To: <20061005213923.GA492@free.fr> (Alain Guibert's message of "Thu, 5 Oct 2006 23:39:23 +0200 (CEST)") References: <20060910063154.GB9023@free.fr> <20060920151849.GB12647@free.fr> <87k63ffc8e.fsf@wheatstone.g10code.de> <20061005213923.GA492@free.fr> Message-ID: <87bqok7ghq.fsf@wheatstone.g10code.de> On Thu, 5 Oct 2006 23:39, Alain Guibert said: > OK: These 2 gpg_strerror_r/gpg_strsource errors are gone with those > lines added after the definitions: > > | #pragma weak gpg_strerror_r > | #pragma weak gpg_strsource Okay, added this for old gccs > A recursive grep in all includes finds not a single "CMSG_" here. Will write a test. > OK: Those undefined FD_ZERO/FD_SET errors are gone. Okay. > | assuan-util.c: In function `putc_unlocked': > | assuan-util.c:31: storage class specified for parameter `alloc_func' A missing semicolon after the declaration in assuan-defs.h. Shalom-Salam, Werner From wk at gnupg.org Tue Oct 10 12:46:12 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 10 12:53:04 2006 Subject: libassuan 0.9.3 released Message-ID: <877iz878jv.fsf@wheatstone.g10code.de> Hi, I have just released libassuan 0.9.3: ftp://ftp.gnupg.org/gcrypt/alpha/libassuan/libassuan-0.9.3.bz2 ftp://ftp.gnupg.org/gcrypt/alpha/libassuan/libassuan-0.9.3.bz2.sig with these changes: * Portability fixes. * Pth is not anymore linked by means of weak symbol tricks. It is now required to link to the pth version of libassuan. New aufoconf macros are provided to to check for this. The pth version is only build if Pth is available. * configure does now check that descriptor passing is available. A way to check at runtime for this is also provided Unfortunately I realized to late that the autoconf macro libassuan.m4 was broken. Either use the one from gnupg's SVN or apply the attached fix. The major change is that we build wto libs: libassuan.a and libassuan-pth.a. The configure macros (or just libassuan-config) take care of this. See the GnuPG code from SVN to see how this can be done. Salam-Shalom, Werner -------------- next part -------------- Index: src/libassuan.m4 =================================================================== --- src/libassuan.m4 (revision 218) +++ src/libassuan.m4 (working copy) @@ -125,8 +125,8 @@ AC_DEFUN([AM_PATH_LIBASSUAN_PTH], [ _AM_PATH_LIBASSUAN_COMMON($1,pth) if test $ok = yes; then - LIBASSUAN_PTH_CFLAGS=`$LIBASSUAN_CONFIG $libassuan_config_args --cflags` - LIBASSUAN_PTH_LIBS=`$LIBASSUAN_CONFIG $libassuan_config_args --libs` + LIBASSUAN_PTH_CFLAGS=`$LIBASSUAN_CONFIG $libassuan_config_args --thread=pth --cflags` + LIBASSUAN_PTH_LIBS=`$LIBASSUAN_CONFIG $libassuan_config_args --thread=pth --libs` ifelse([$2], , :, [$2]) else LIBASSUAN_PTH_CFLAGS="" @@ -146,8 +146,8 @@ AC_DEFUN([AM_PATH_LIBASSUAN_PTHREAD], [ _AM_PATH_LIBASSUAN_COMMON($1,pth) if test $ok = yes; then - LIBASSUAN_PTHREAD_CFLAGS=`$LIBASSUAN_CONFIG $libassuan_config_args --cflags` - LIBASSUAN_PTHREAD_LIBS=`$LIBASSUAN_CONFIG $libassuan_config_args --libs` + LIBASSUAN_PTHREAD_CFLAGS=`$LIBASSUAN_CONFIG $libassuan_config_args --thread=pthread --cflags` + LIBASSUAN_PTHREAD_LIBS=`$LIBASSUAN_CONFIG $libassuan_config_args --thread=pthread --libs` ifelse([$2], , :, [$2]) else LIBASSUAN_PTHREAD_CFLAGS="" Index: configure.ac From wk at gnupg.org Tue Oct 10 12:48:05 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 10 12:53:10 2006 Subject: libassuan 0.6.10 build fails on old Linux In-Reply-To: <20061005213923.GA492@free.fr> (Alain Guibert's message of "Thu, 5 Oct 2006 23:39:23 +0200 (CEST)") References: <20060910063154.GB9023@free.fr> <20060920151849.GB12647@free.fr> <87k63ffc8e.fsf@wheatstone.g10code.de> <20061005213923.GA492@free.fr> Message-ID: <873b9w78gq.fsf@wheatstone.g10code.de> On Thu, 5 Oct 2006 23:39, Alain Guibert said: > A recursive grep in all includes finds not a single "CMSG_" here. 0.9.3 has now proper detection of the cmsghdr structure and provides replacements for the CMSG macros for systems lacking them. This should allow you to build libassuan. Shalom-Salam, Werner From wk at gnupg.org Tue Oct 10 12:57:22 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 10 13:02:41 2006 Subject: [gnupg-devel] libassuan-0.9.2 build feedback In-Reply-To: (Nelson H. F. Beebe's message of "Thu, 5 Oct 2006 10:01:27 -0600 (MDT)") References: Message-ID: <87y7ro5tgt.fsf@wheatstone.g10code.de> On Thu, 5 Oct 2006 18:01, Nelson H. F. Beebe said: > In builds of libassuan-0.9.2 in 34 compilation environments on a score > of different Unix systems, the builds and validation tests succeeded > in 18 of them. Thanks. > This happens because LDFLAGS is not propagated properly from the > configure environment to the Makefile. A restart with > > make LIBS='-L/usr/local/lib -lpth' all check > > produced a successful build and validation. I have fixed this by not using the pth version of the library in the test. > checking for socklen_t equivalent... configure: error: Cannot find a type to use in place of socklen_t > 9.45 real 1.59 user 4.42 sys > make: *** No targets specified and no makefile found. Stop. > > Like GNU/Linux on the AMD64 architecture, Mac OS X on the Intel Xeon > EM64T system provides a 32-bit world and a 64-bit world. Apple > supplies fat binaries and libraries that contain code for both worlds, > and often, also for the same worlds in the older PowerPC systems. > However, at end user sites, preparation of fat files is too > problematic and failure prone, so I follow the practice on the AMD64 > of having /usr/local/lib32 for 32-bit libraries, and /usr/local/lib > for 64-bit libraries. Something prevents socklen_t from being seen in > the 64-bit world on Mac OS X. Thanks for explaining. Can you cut out the part from config.log where this happens. Maybe I can find a way to work around it. > ============================================================ > Machinetype: SGI Origin/200-4 (180 MHz) (4 R10000 CPUs); IRIX 6.5 > Remote gcc version: gcc (GCC) 3.4.3 > assuan-uds.c: In function `uds_reader': > assuan-uds.c:73: warning: implicit declaration of function `CMSG_SPACE' > assuan-uds.c:95: warning: cast increases required alignment of target type > assuan-uds.c:96: warning: implicit declaration of function `CMSG_LEN' There are now replacements for this. > assuan-uds.c:99: error: `SCM_RIGHTS' undeclared (first use in this function) But unfortunately not for this. Need to check stevens how it worked with odler systems. > > ======================================================================== > Machinetype: Sun W40z (4 CPUs, 2400 MHz AMD64 Opteron, 8GB RAM); FreeBSD 5.0-RELEASE #0 > Remote gcc version: gcc (GCC) 3.4.3 > /usr/local/lib/gcc/i386-unknown-freebsd5.0/3.4.3/include/stdio.h:405: error: previous definition of '__sputc' was here > assuan-util.c: In function `__sputc': > assuan-util.c:31: error: storage class specified for parameter `alloc_func' Not yet fixed. > ============================================================ > Machinetype: DEC Alpha 4100-5/466 (4 21164 EV5 CPUs, 466 MHz, 2GB RAM); OSF/1 4.0F > Remote gcc version: gcc (GCC) 3.3.3 > assuan-uds.c:85: error: structure has no member named `msg_control' > assuan-uds.c:86: error: structure has no member named `msg_controllen' > assuan-uds.c:95: error: structure has no member named `msg_control' Should work now However without descripot passing. It is not yet used by gnupg and that should no pose any problem. We will use descriptor passing merely for performance acceleration. > ======================================================================== > Machinetype: Sun Sun Fire V240 (2 UltraSPARC-IIIi CPUs, 1280 MHz, 8GB RAM); Solaris 9 > __xnet_sendmsg ../src/libassuan.a(assuan-io.o) > ld: fatal: Symbol referencing errors. No output written to fdpassing Might work now as the required libs are now passed to ld. > ======================================================================== > Machinetype: Sun Ultra Enterprise 450/400 (4 UltraSPARC-II CPUs, 400 MHz); Solaris 7 > ======================================================================== > Machinetype: Intel Pentium 4 (1800 MHz); Solaris 10 x86 > Remote c99 version: cc: Sun C 5.8 Patch 121016-02 2006/03/31 > Configure environment: CC=/opt/SUNWspro/bin/c99 CFLAGS="-I/usr/local/include" CXX=/opt/SUNWspro/bin/CC CXXFLAGS="-I/usr/local/include" LDFLAGS="-R/usr/local/lib -L/usr/local/lib" > > checking for socklen_t equivalent... configure: error: Cannot find a type to use in place of socklen_t Interesting. The code to check socklen_t is from gnulib and thus should be tests, but well, there must be something wrong. Salam-Shalom, Werner From rdieter at math.unl.edu Tue Oct 10 16:04:49 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue Oct 10 16:03:10 2006 Subject: gnupg2-1.9.91 build failure (fedora core/x86_64) Message-ID: gnupg2 on x86_64 segfaulting in tests again/still. I had been mostly ignoring those (hoping that they'd just go away someday), but now the tests seem to run during the regular build not just 'make check'. Tail end of the build.log is appended. Any further debugging that I can do (now that I actually have an x86_64 box to test with)? Making all in openpgp make[3]: Entering directory `/builddir/build/BUILD/gnupg-1.9.91/tests/openpgp' echo '#!/bin/sh' >./gpg_dearmor echo "../../g10/gpg2 --no-options --no-greeting \ --no-secmem-warning --batch --dearmor" >>./gpg_dearmor chmod 755 ./gpg_dearmor ./gpg_dearmor > ./pubring.gpg < ./pubring.asc ./gpg_dearmor > ./secring.gpg < ./secring.asc ./gpg_dearmor > ./plain-1 < ./plain-1o.asc ./gpg_dearmor > ./plain-2 < ./plain-2o.asc ./gpg_dearmor > ./plain-3 < ./plain-3o.asc ./gpg_dearmor > ./pubring.pkr < ./pubring.pkr.asc ./gpg_dearmor > ./secring.skr < ./secring.skr.asc ../../tools/mk-tdata 500 >data-500 ../../tools/mk-tdata 9000 >data-9000 ../../tools/mk-tdata 32000 >data-32000 ../../tools/mk-tdata 80000 >data-80000 cat ./../../doc/HACKING \ ./../../doc/DETAILS \ ./../../doc/FAQ >plain-large ../../g10/gpg2 --homedir . --quiet --yes --no-permission-warning --import ./pubdemo.asc gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: signal Segmentation fault caught ... exiting make[3]: *** [prepared.stamp] Segmentation fault make[3]: Leaving directory `/builddir/build/BUILD/gnupg-1.9.91/tests/openpgp' From wk at gnupg.org Tue Oct 10 16:58:09 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 10 17:02:35 2006 Subject: gnupg2-1.9.91 build failure (fedora core/x86_64) In-Reply-To: (Rex Dieter's message of "Tue, 10 Oct 2006 09:04:49 -0500") References: Message-ID: <878xjo5ibi.fsf@wheatstone.g10code.de> On Tue, 10 Oct 2006 16:04, Rex Dieter said: > Any further debugging that I can do (now that I actually have an x86_64 box > to test with)? Yes: cd /builddir/build/BUILD/gnupg-1.9.91/tests/openpgp gdb ../../g10/gpg2 run --homedir . --quiet --yes --no-permission-warning --import ./pubdemo.asc and after the crash, do a "bt full". Salam-Shalom, Werner From rdieter at math.unl.edu Tue Oct 10 17:54:38 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue Oct 10 17:53:29 2006 Subject: gnupg2-1.9.91 build failure (fedora core/x86_64) References: <878xjo5ibi.fsf@wheatstone.g10code.de> Message-ID: Werner Koch wrote: > On Tue, 10 Oct 2006 16:04, Rex Dieter said: > >> Any further debugging that I can do (now that I actually have an x86_64 >> box to test with)? > > Yes: > > cd /builddir/build/BUILD/gnupg-1.9.91/tests/openpgp > gdb ../../g10/gpg2 > > run --homedir . --quiet --yes --no-permission-warning --import > ./pubdemo.asc > > and after the crash, do a "bt full". mock-chroot> gdb ../../g10/gpg2 GNU gdb Red Hat Linux (6.5-8.fc6rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/libthread_db.so.1". (gdb) run --homedir . --quiet --yes --no-permission-warning --import ./pubdemo.asc Starting program: /builddir/build/BUILD/gnupg-1.9.91/g10/gpg2 --homedir . --quiet --yes --no-permission-warning --import ./pubdemo.asc gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! Program received signal SIGSEGV, Segmentation fault. parse_key (inp=0x6a38e0, pkttype=, pktlen=412, hdr=, hdrlen=, pkt=) at parse-packet.c:1956 1956 n = pktlen; pk->pkey[i] = mpi_read(inp, &n, 0 ); pktlen -=n; (gdb) bt full #0 parse_key (inp=0x6a38e0, pkttype=, pktlen=412, hdr=, hdrlen=, pkt=) at parse-packet.c:1956 pk = i = 0 version = algorithm = n = 130 timestamp = expiredate = npkey = 4 nskey = 5 is_v4 = 1 rc = 0 #1 0x0000000000426d7f in parse (inp=0x6a38e0, pkt=0x6a7b10, onlykeypkts=0, retpos=, skip=0x7fbffff43c, out=0x0, do_skip=0, dbg_w=0x47cfb2 "parse", dbg_f=0x4855bd "import.c", dbg_l=375) at parse-packet.c:535 rc = c = ctb = pkttype = 6 lenbytes = 2 pktlen = hdr = "\231\001\177\000\000" hdrlen = 3 new_ctb = 0 partial = 0 __PRETTY_FUNCTION__ = "parse" #2 0x0000000000427e6e in dbg_parse_packet (inp=0x6a38e0, pkt=0x6a7b10, dbg_f=0x4855bd "import.c", dbg_l=375) at parse-packet.c:212 skip = 0 rc = 6978944 #3 0x0000000000448738 in import (inp=0x6a38e0, fname=0x7fbfffff35 "./pubdemo.asc", stats=0x6a3850, fpr=0x0, fpr_len=0x0, options=8) at import.c:375 afx = ---Type to continue, or q to quit--- pending_pkt = (PACKET *) 0x6a7b10 keyblock = (KBNODE) 0x0 rc = 0 #4 0x0000000000449486 in import_keys_internal (inp=, fnames=0x7fbffffd70, nnames=1, stats_handle=0x0, fpr=0x0, fpr_len=0x0, options=8) at import.c:198 fname = 0x7fbfffff35 "./pubdemo.asc" inp2 = (IOBUF) 0x6a38e0 i = 0 rc = 0 stats = (struct stats_s *) 0x6a3850 #5 0x000000000044957c in import_keys (fnames=0x6a7cf0, nnames=-1073745284, stats_handle=0x0, options=) at import.c:231 No locals. #6 0x000000000040b720 in main (argc=dwarf2_read_address: Corrupted DWARF expression. ) at gpg.c:3456 cmdname = 0x1
pargs = dwarf2_read_address: Corrupted DWARF expression. From wk at gnupg.org Tue Oct 10 18:06:40 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 10 18:12:45 2006 Subject: gnupg2-1.9.91 build failure (fedora core/x86_64) In-Reply-To: (Rex Dieter's message of "Tue, 10 Oct 2006 10:54:38 -0500") References: <878xjo5ibi.fsf@wheatstone.g10code.de> Message-ID: <87wt7840kv.fsf@wheatstone.g10code.de> On Tue, 10 Oct 2006 17:54, Rex Dieter said: > Program received signal SIGSEGV, Segmentation fault. > parse_key (inp=0x6a38e0, pkttype=, pktlen=412, > hdr=, hdrlen=, > pkt=) at parse-packet.c:1956 > 1956 n = pktlen; pk->pkey[i] = mpi_read(inp, &n, 0 ); My guess is that the erro happens in mpi_read. To better debug it, you should configure it with --disable-optimization, build again and run gdb again. We can do this off list. Salam-Shalom, Werner From rdieter at math.unl.edu Tue Oct 10 18:23:30 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue Oct 10 19:51:29 2006 Subject: gnupg2-1.9.91 build failure (fedora core/x86_64) In-Reply-To: <87wt7840kv.fsf@wheatstone.g10code.de> References: <878xjo5ibi.fsf@wheatstone.g10code.de> <87wt7840kv.fsf@wheatstone.g10code.de> Message-ID: <452BC902.9080206@math.unl.edu> Werner Koch wrote: > On Tue, 10 Oct 2006 17:54, Rex Dieter said: > >> Program received signal SIGSEGV, Segmentation fault. >> parse_key (inp=0x6a38e0, pkttype=, pktlen=412, >> hdr=, hdrlen=, >> pkt=) at parse-packet.c:1956 >> 1956 n = pktlen; pk->pkey[i] = mpi_read(inp, &n, 0 ); > > > My guess is that the erro happens in mpi_read. To better debug it, > you should configure it with --disable-optimization, build again and > run gdb again. > > We can do this off list. Can do. -- Rex From rdieter at math.unl.edu Tue Oct 10 19:05:39 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue Oct 10 20:21:15 2006 Subject: gnupg2-1.9.91 build failure (fedora core/x86_64) In-Reply-To: <87wt7840kv.fsf@wheatstone.g10code.de> References: <878xjo5ibi.fsf@wheatstone.g10code.de> <87wt7840kv.fsf@wheatstone.g10code.de> Message-ID: <452BD2E3.3080202@math.unl.edu> Werner Koch wrote: > On Tue, 10 Oct 2006 17:54, Rex Dieter said: > >> Program received signal SIGSEGV, Segmentation fault. >> parse_key (inp=0x6a38e0, pkttype=, pktlen=412, >> hdr=, hdrlen=, >> pkt=) at parse-packet.c:1956 >> 1956 n = pktlen; pk->pkey[i] = mpi_read(inp, &n, 0 ); > > > My guess is that the erro happens in mpi_read. To better debug it, > you should configure it with --disable-optimization, build again and Oh, fun, no crashes with CFLAGS="" + --disable-optimization. I'll keep looking. -- Rex From rdieter at math.unl.edu Tue Oct 10 20:35:45 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue Oct 10 20:34:21 2006 Subject: gnupg2-1.9.91 build failure (fedora core/x86_64) References: <878xjo5ibi.fsf@wheatstone.g10code.de> <87wt7840kv.fsf@wheatstone.g10code.de> <452BD2E3.3080202@math.unl.edu> Message-ID: Rex Dieter wrote: > Werner Koch wrote: >> On Tue, 10 Oct 2006 17:54, Rex Dieter said: >> >>> Program received signal SIGSEGV, Segmentation fault. >>> parse_key (inp=0x6a38e0, pkttype=, pktlen=412, >>> hdr=, hdrlen=, >>> pkt=) at parse-packet.c:1956 >>> 1956 n = pktlen; pk->pkey[i] = mpi_read(inp, &n, 0 ); >> >> >> My guess is that the erro happens in mpi_read. To better debug it, >> you should configure it with --disable-optimization, build again and > > Oh, fun, no crashes with CFLAGS="" + --disable-optimization. Are you willing to try to debug this without --disable-optimization? Regardless, at least I have something that works now. -- Rex From alguibert+gpd at free.fr Wed Oct 11 00:28:54 2006 From: alguibert+gpd at free.fr (Alain Guibert) Date: Wed Oct 11 00:32:06 2006 Subject: libassuan 0.6.10 build fails on old Linux In-Reply-To: <873b9w78gq.fsf@wheatstone.g10code.de> References: <20060910063154.GB9023@free.fr> <20060920151849.GB12647@free.fr> <87k63ffc8e.fsf@wheatstone.g10code.de> <20061005213923.GA492@free.fr> <873b9w78gq.fsf@wheatstone.g10code.de> Message-ID: <20061010222854.GA22144@free.fr> Hello Werner, On Tuesday, October 10, 2006 at 12:48:05 +0200, Werner Koch wrote: > 0.9.3 has now proper detection of the cmsghdr structure and provides > replacements for the CMSG macros for systems lacking them. This should > allow you to build libassuan. Yes! Very much thank you: Libassuan 0.9.3 tar.bz2 builds properly. However "make check" fails a test: | Making check in tests | make[1]: Entering directory `/tmp/libassuan-0.9.3/tests' | make check-am | make[2]: Entering directory `/tmp/libassuan-0.9.3/tests' | make check-TESTS | make[3]: Entering directory `/tmp/libassuan-0.9.3/tests' | fdpassing[10810.8] DBG: -> OK Pleased to meet you | fdpassing[10810.8] DBG: <- # descriptor 8 is in flight | fdpassing[10810.8] DBG: <- INPUT FD | fdpassing[10810.8] DBG: -> OK | fdpassing[10810.8] DBG: <- ECHO | fdpassing[10810.8] DBG: -> OK | fdpassing[10809]: too many descriptors pending - closing received descriptor 1 | fdpassing[10810.8] DBG: <- # descriptor 1 is in flight | fdpassing[10810]: too many descriptors pending - closing received descriptor 1074338940 | fdpassing[10810]: too many descriptors pending - closing received descriptor 1074338940 | fdpassing[10810.8] DBG: <- INPUT FD | fdpassing[10810.8] DBG: -> OK | fdpassing[10809]: too many descriptors pending - closing received descriptor 1 | fdpassing[10809]: too many descriptors pending - closing received descriptor 1 | fdpassing[10810]: too many descriptors pending - closing received descriptor 0 | fdpassing[10810.8] DBG: <- ECHO | fdpassing[10810]: fdopen failed on input fd: Bad file number | fdpassing[10810.8] DBG: -> ERR 101 server fault (general error) | fdpassing[10809]: too many descriptors pending - closing received descriptor 1 | fdpassing[10809]: too many descriptors pending - closing received descriptor 1 | fdpassing[10809]: sending ECHO failed: server fault | fdpassing[10810]: too many descriptors pending - closing received descriptor 0 | fdpassing[10810]: too many descriptors pending - closing received descriptor 0 | fdpassing[10810.8] DBG: <- BYE | fdpassing[10810.8] DBG: -> OK closing connection | FAIL: fdpassing | ====================================== | 1 of 1 tests failed | Please report to gnupg-devel@gnupg.org | ====================================== | make[3]: *** [check-TESTS] Error 1 | make[3]: Leaving directory `/tmp/libassuan-0.9.3/tests' | make[2]: *** [check-am] Error 2 | make[2]: Leaving directory `/tmp/libassuan-0.9.3/tests' | make[1]: *** [check] Error 2 | make[1]: Leaving directory `/tmp/libassuan-0.9.3/tests' | make: *** [check-recursive] Error 1 Alain. From jvender at owensboro.net Wed Oct 11 02:10:00 2006 From: jvender at owensboro.net (Joe Vender) Date: Wed Oct 11 03:21:24 2006 Subject: GnuPG RNG on Windows Message-ID: <002901c6ecc9$9f019320$7d1b87d8@computer> An I correct in assuming that, on Linux, GnuPG uses the Linux OS RNG which starts with the OS and runs as a service constantly stirring the random pool, but on Windows, GnuPG uses the RNG included with the source and the random pool only gets stirred when GnuPG is called? From wk at gnupg.org Wed Oct 11 09:54:19 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 11 09:58:01 2006 Subject: GnuPG RNG on Windows In-Reply-To: <002901c6ecc9$9f019320$7d1b87d8@computer> (Joe Vender's message of "Tue, 10 Oct 2006 19:10:00 -0500") References: <002901c6ecc9$9f019320$7d1b87d8@computer> Message-ID: <87fydv479w.fsf@wheatstone.g10code.de> On Wed, 11 Oct 2006 02:10, Joe Vender said: > An I correct in assuming that, on Linux, GnuPG uses the Linux OS RNG which > starts with the OS and runs as a service constantly stirring the random > pool, but on Windows, GnuPG uses the RNG included with the source and the > random pool only gets stirred when GnuPG is called? No, it is far more complicated than that. I don't have the time to elaborate on it now. If you are interested, you should study cipher/random.c from libgcrypt which is a bit better documented. For a general description of the RNG architecture see Peter Gutmann's paper: "Software Generation of Practically Strong Random Numbers". See also chapter 6 in his book "Cryptographic Security Architecture", New York, 2004, ISBN 0-387-95387-6. His website is at http://www.cs.auckland.ac.nz/~pgut001/. I could post a brief writeup on the implementation, however this is in German. Salam-Shalom, Werner From wk at gnupg.org Wed Oct 11 09:59:34 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 11 10:03:02 2006 Subject: gnupg2-1.9.91 build failure (fedora core/x86_64) In-Reply-To: (Rex Dieter's message of "Tue, 10 Oct 2006 13:35:45 -0500") References: <878xjo5ibi.fsf@wheatstone.g10code.de> <87wt7840kv.fsf@wheatstone.g10code.de> <452BD2E3.3080202@math.unl.edu> Message-ID: <87bqoj4715.fsf@wheatstone.g10code.de> On Tue, 10 Oct 2006 20:35, Rex Dieter said: > Are you willing to try to debug this without --disable-optimization? Sure, this needs to be debugged. BTW, --disabled optimization is nothing else than removing -O? from the CFLAGS. Does it crash when only using --disable-optimization while keeping the other CFLAGS? Shalom-Salam, Werner From wk at gnupg.org Wed Oct 11 10:05:36 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 11 10:12:40 2006 Subject: libassuan 0.6.10 build fails on old Linux In-Reply-To: <20061010222854.GA22144@free.fr> (Alain Guibert's message of "Wed, 11 Oct 2006 00:28:54 +0200 (CEST)") References: <20060910063154.GB9023@free.fr> <20060920151849.GB12647@free.fr> <87k63ffc8e.fsf@wheatstone.g10code.de> <20061005213923.GA492@free.fr> <873b9w78gq.fsf@wheatstone.g10code.de> <20061010222854.GA22144@free.fr> Message-ID: <877iz746r3.fsf@wheatstone.g10code.de> On Wed, 11 Oct 2006 00:28, Alain Guibert said: > | fdpassing[10809]: too many descriptors pending - closing received descriptor 1 I am not sure whether such an old kernel properly implements descriptor passing. However it does something and thus we should figure out what is actually going on. Can you please send me an strace of running ./fdpassing --verbose Salam-Shalom, Werner From wk at gnupg.org Wed Oct 11 12:18:15 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 11 12:41:55 2006 Subject: [Announce] GnuPG 1.9.92 released Message-ID: <87mz832m1k.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From rdieter at math.unl.edu Wed Oct 11 14:03:26 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed Oct 11 14:02:24 2006 Subject: gnupg2-1.9.91 build failure (fedora core/x86_64) In-Reply-To: <87bqoj4715.fsf@wheatstone.g10code.de> References: <878xjo5ibi.fsf@wheatstone.g10code.de> <87wt7840kv.fsf@wheatstone.g10code.de> <452BD2E3.3080202@math.unl.edu> <87bqoj4715.fsf@wheatstone.g10code.de> Message-ID: <452CDD8E.906@math.unl.edu> Werner Koch wrote: > On Tue, 10 Oct 2006 20:35, Rex Dieter said: > >> Are you willing to try to debug this without --disable-optimization? > > Sure, this needs to be debugged. BTW, --disabled optimization is > nothing else than removing -O? from the CFLAGS. Does it crash when > only using --disable-optimization while keeping the other CFLAGS? No. For the record, fc6's default optflags for which gnupg2 crashes is: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic Take out the -O2, and all is well. -- Rex From wk at gnupg.org Wed Oct 11 15:37:31 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 11 15:42:41 2006 Subject: gnupg2-1.9.91 build failure (fedora core/x86_64) In-Reply-To: <452CDD8E.906@math.unl.edu> (Rex Dieter's message of "Wed, 11 Oct 2006 07:03:26 -0500") References: <878xjo5ibi.fsf@wheatstone.g10code.de> <87wt7840kv.fsf@wheatstone.g10code.de> <452BD2E3.3080202@math.unl.edu> <87bqoj4715.fsf@wheatstone.g10code.de> <452CDD8E.906@math.unl.edu> Message-ID: <874pub2ctg.fsf@wheatstone.g10code.de> On Wed, 11 Oct 2006 14:03, Rex Dieter said: > For the record, fc6's default optflags for which gnupg2 crashes is: > -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic > > Take out the -O2, and all is well. What I would do now is to replace -O2 by -O1 and if this does not anymore crahs, add these options: -fstrict-aliasing -fstrength-reduce -fthread-jumps -fcrossjumping -foptimize-sibling-calls -fcse-follow-jumps -fcse-skip-blocks -fgcse -fgcse-lm -fexpensive-optimizations -frerun-cse-after-loop -frerun-loop-opt -fcaller-saves -fpeephole2 -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec -fregmove -fdelete-null-pointer-checks -freorder-blocks -freorder-functions -falign-functions -falign-jumps -falign-loops -falign-labels -ftree-vrp -ftree-pre one after another until it crashes. A lot of work, though. Shalom-Salam, Werner From rdieter at math.unl.edu Wed Oct 11 15:57:12 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed Oct 11 16:03:11 2006 Subject: bits of gnupg2-1.9.92 conflict with gnupg-1.4.5 Message-ID: Some bits from gnupg2-1.9.92 conflict with gnupg-1.4.5: /usr/bin/gpg-zip /usr/bin/gpgsplit /usr/share/man/man7/gnupg.7.gz was this an oversight? Should I simply omit these from gnupg2 packaging? Suggestions? -- Rex From rdieter at math.unl.edu Wed Oct 11 16:09:32 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed Oct 11 16:17:42 2006 Subject: gnupg2-1.9.91 build failure (fedora core/x86_64) References: <878xjo5ibi.fsf@wheatstone.g10code.de> <87wt7840kv.fsf@wheatstone.g10code.de> <452BD2E3.3080202@math.unl.edu> <87bqoj4715.fsf@wheatstone.g10code.de> <452CDD8E.906@math.unl.edu> <874pub2ctg.fsf@wheatstone.g10code.de> Message-ID: Werner Koch wrote: > On Wed, 11 Oct 2006 14:03, Rex Dieter said: > >> For the record, fc6's default optflags for which gnupg2 crashes is: >> -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic >> >> Take out the -O2, and all is well. > > What I would do now is to replace -O2 by -O1 and if this does not > anymore crahs, -O1 -> segfault. -- Rex From wk at gnupg.org Wed Oct 11 17:07:07 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 11 17:12:30 2006 Subject: bits of gnupg2-1.9.92 conflict with gnupg-1.4.5 In-Reply-To: (Rex Dieter's message of "Wed, 11 Oct 2006 08:57:12 -0500") References: Message-ID: <87vemq28o4.fsf@wheatstone.g10code.de> On Wed, 11 Oct 2006 15:57, Rex Dieter said: > /usr/bin/gpg-zip > /usr/bin/gpgsplit > /usr/share/man/man7/gnupg.7.gz > > was this an oversight? Should I simply omit these from gnupg2 packaging? I am not sure what to do about them. I think it is okay to just omit them. Shalom-Salam, Werner From rdieter at math.unl.edu Wed Oct 11 18:13:31 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed Oct 11 18:19:43 2006 Subject: bits of gnupg2-1.9.92 conflict with gnupg-1.4.5 References: <87vemq28o4.fsf@wheatstone.g10code.de> Message-ID: Werner Koch wrote: > On Wed, 11 Oct 2006 15:57, Rex Dieter said: > >> /usr/bin/gpg-zip >> /usr/bin/gpgsplit >> /usr/share/man/man7/gnupg.7.gz >> >> was this an oversight? Should I simply omit these from gnupg2 packaging? > > I am not sure what to do about them. I think it is okay to just omit > them. Thanks, will do. -- Rex From jvender at owensboro.net Wed Oct 11 18:34:37 2006 From: jvender at owensboro.net (Joe Vender) Date: Wed Oct 11 18:33:59 2006 Subject: GnuPG RNG on Windows References: <002901c6ecc9$9f019320$7d1b87d8@computer> <87fydv479w.fsf@wheatstone.g10code.de> Message-ID: <000c01c6ed53$27871330$6c1b87d8@computer> From: "Werner Koch" To: "Joe Vender" Cc: Sent: Wednesday, October 11, 2006 2:54 AM Subject: Re: GnuPG RNG on Windows > On Wed, 11 Oct 2006 02:10, Joe Vender said: > > No, it is far more complicated than that. I don't have the time to > elaborate on it now. If you are interested, you should study > cipher/random.c from libgcrypt which is a bit better documented. For > a general description of the RNG architecture see Peter Gutmann's > paper: "Software Generation of Practically Strong Random Numbers". See > also chapter 6 in his book "Cryptographic Security Architecture", New > York, 2004, ISBN 0-387-95387-6. His website is at > http://www.cs.auckland.ac.nz/~pgut001/. > > I could post a brief writeup on the implementation, however this is in > German. > > > Salam-Shalom, > > Werner > O.K. I'll take a look at the references you mentioned. Thanks for the offer to post the writeup, but I can't read German. Joe From alguibert+gpd at free.fr Wed Oct 11 18:01:23 2006 From: alguibert+gpd at free.fr (Alain Guibert) Date: Wed Oct 11 20:28:54 2006 Subject: libassuan 0.6.10 build fails on old Linux In-Reply-To: <877iz746r3.fsf@wheatstone.g10code.de> References: <20060910063154.GB9023@free.fr> <20060920151849.GB12647@free.fr> <87k63ffc8e.fsf@wheatstone.g10code.de> <20061005213923.GA492@free.fr> <873b9w78gq.fsf@wheatstone.g10code.de> <20061010222854.GA22144@free.fr> <877iz746r3.fsf@wheatstone.g10code.de> Message-ID: <20061011160123.GA21795@free.fr> On Wednesday, October 11, 2006 at 10:05:36 +0200, Werner Koch wrote: > On Wed, 11 Oct 2006 00:28, Alain Guibert said: >> | fdpassing[10809]: too many descriptors pending - closing received descriptor 1 > Can you please send me an strace of running ./fdpassing --verbose Sure, thank you! It comes attached as strace-fdpassing-verbose.txt. Alain. -------------- next part -------------- A non-text attachment was scrubbed... Name: strace-fdpassing-verbose.txt.gz Type: application/x-gunzip Size: 1548 bytes Desc: not available Url : /pipermail/attachments/20061011/af224ed0/strace-fdpassing-verbose.txt.bin From alguibert+gpd at free.fr Wed Oct 11 20:18:03 2006 From: alguibert+gpd at free.fr (Alain Guibert) Date: Wed Oct 11 20:29:08 2006 Subject: GnuPG 1.9.92 build failures on old Linux Message-ID: <20061011181803.GB21795@free.fr> Hello, On my old Linux box (Intel Pentium 200 MMX, Debian bo, kernel 2.0.40, gcc 2.7.2.1, libc 5.4.33, GNU ld cygnus-2.7.1, pth 2.0.7) during GnuPG 1.9.92 build, make fails: | $ ./configure; make | [...] | gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I../common -I../intl -DLOCALEDIR=\"/usr/local/share/locale\" -DGNUPG_BINDIR="\"/usr/local/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/local/libexec\"" -DGNUPG_LIBDIR="\"/usr/local/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/local/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/local/etc/gnupg\"" -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -g -O2 -Wall -c protect-tool.c | protect-tool.c: In function `get_passphrase': | protect-tool.c:1187: `orig_codeset' undeclared (first use this function) | protect-tool.c:1187: (Each undeclared identifier is reported only once | protect-tool.c:1187: for each function it appears in.) | make[2]: *** [protect-tool.o] Error 1 | make[2]: Leaving directory `/tmp/gnupg-1.9.92/agent' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/tmp/gnupg-1.9.92' | make: *** [all] Error 2 I disabled agent for now. But I still failed: | $ ./configure --disable-agent; make | [...] | gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I../intl -I../common -DLOCALEDIR=\"/usr/local/share/locale\" -DGNUPG_BINDIR="\"/usr/local/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/local/libexec\"" -DGNUPG_LIBDIR="\"/usr/local/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/local/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/local/etc/gnupg\"" -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -g -O2 -Wall -c apdu.c | In file included from apdu.c:37: | /usr/include/unistd.h:656: conflicting types for `pth_usleep' | /usr/local/include/pth.h:531: previous declaration of `pth_usleep' | make[2]: *** [apdu.o] Error 1 | make[2]: Leaving directory `/tmp/gnupg-1.9.92/scd' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/tmp/gnupg-1.9.92' | make: *** [all] Error 2 My system /usr/include/unistd.h line 656 is: | extern void usleep __P((unsigned long __usec)); While libpth 2.0.7 /usr/local/include/pth.h contains: | extern int pth_usleep(unsigned int); | #define usleep pth_usleep I temporarily commented out the unistd.h usleep to get past this error. But I still failed later: | gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I../intl -I../common -DLOCALEDIR=\"/usr/local/share/locale\" -DGNUPG_BINDIR="\"/usr/local/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/local/libexec\"" -DGNUPG_LIBDIR="\"/usr/local/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/local/share/gnupg\"" -DGNUPG_SYSCONFDIR="\"/usr/local/etc/gnupg\"" -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -g -O2 -Wall -c watchgnupg.c | watchgnupg.c: In function `main': | watchgnupg.c:227: `socklen_t' undeclared (first use this function) | watchgnupg.c:227: (Each undeclared identifier is reported only once | watchgnupg.c:227: for each function it appears in.) | watchgnupg.c:227: parse error before `addrlen' | watchgnupg.c:290: `addrlen' undeclared (first use this function) | make[2]: *** [watchgnupg.o] Error 1 | make[2]: Leaving directory `/tmp/gnupg-1.9.92/tools' | make[1]: *** [all-recursive] Error 1 | make[1]: Leaving directory `/tmp/gnupg-1.9.92' | make: *** [all] Error 2 So I replaced socklen_t by int in watchgnupg.c, and this time build succeeded. Make check passed all PGP tests OK, but failed the 2 gpgsm tests: | asschk: cmd_expect_ok: expected OK but got `ERR 50331649 General error ' | FAIL: sm-sign+verify | FAIL: sm-verify | ==================================== | 2 of 2 tests failed | Please report to bug-gnupg@gnupg.org | ==================================== | make[3]: *** [check-TESTS] Error 1 | make[3]: Leaving directory `/tmp/gnupg-1.9.92/tests' | make[2]: *** [check-am] Error 2 | make[2]: Leaving directory `/tmp/gnupg-1.9.92/tests' | make[1]: *** [check-recursive] Error 1 | make[1]: Leaving directory `/tmp/gnupg-1.9.92/tests' | make: *** [check-recursive] Error 1 Alain. From wk at gnupg.org Thu Oct 12 17:35:36 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Oct 12 17:42:38 2006 Subject: GnuPG 1.9.92 build failures on old Linux In-Reply-To: <20061011181803.GB21795@free.fr> (Alain Guibert's message of "Wed, 11 Oct 2006 20:18:03 +0200 (CEST)") References: <20061011181803.GB21795@free.fr> Message-ID: <87bqohzgvr.fsf@wheatstone.g10code.de> On Wed, 11 Oct 2006 20:18, Alain Guibert said: > | protect-tool.c:1187: `orig_codeset' undeclared (first use this function) > | protect-tool.c:1187: (Each undeclared identifier is reported only once > | protect-tool.c:1187: for each function it appears in.) Fixed: --- agent/protect-tool.c (revision 4295) +++ agent/protect-tool.c (working copy) @@ -1170,7 +1170,7 @@ char *pw; int err; const char *desc; -#ifdef HAVE_LANGINFO_CODESET +#ifdef ENABLE_NLS char *orig_codeset = NULL; #endif int error_msgno; > | extern void usleep __P((unsigned long __usec)); > > While libpth 2.0.7 /usr/local/include/pth.h contains: > > | extern int pth_usleep(unsigned int); > | #define usleep pth_usleep That seems to be a regression in Pth. 2.0.1 requires the definition of PTH_SYSCALL_SOFT for this define. I'll check the lates Pth version. > | watchgnupg.c: In function `main': > | watchgnupg.c:227: `socklen_t' undeclared (first use this function) Well the usual socklen_t problem. Will include a test to configure. > | asschk: cmd_expect_ok: expected OK but got `ERR 50331649 General error ' Without the agent this is expected. In fact, --disable-agent is not very useful except for package building. Shalom-Salam, Werner From wk at gnupg.org Thu Oct 12 17:52:14 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Oct 12 17:57:35 2006 Subject: GnuPG 1.9.92 build failures on old Linux In-Reply-To: <20061011181803.GB21795@free.fr> (Alain Guibert's message of "Wed, 11 Oct 2006 20:18:03 +0200 (CEST)") References: <20061011181803.GB21795@free.fr> Message-ID: <877iz5zg41.fsf@wheatstone.g10code.de> On Wed, 11 Oct 2006 20:18, Alain Guibert said: > | In file included from apdu.c:37: > | /usr/include/unistd.h:656: conflicting types for `pth_usleep' > | /usr/local/include/pth.h:531: previous declaration of `pth_usleep' Please try this: --- scd/apdu.c (revision 4295) +++ scd/apdu.c (working copy) @@ -33,9 +33,9 @@ #include #include #ifdef USE_GNU_PTH -# include # include # include +# include #endif Salam-Shalom, Werner From zvrba at globalnet.hr Thu Oct 12 16:57:56 2006 From: zvrba at globalnet.hr (Zeljko Vrba) Date: Thu Oct 12 18:51:26 2006 Subject: [Announce] PKCS#11 support for GnuPG Message-ID: <87d58xy423.fsf@globalnet.hr> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 We[1] are pleased to announce the availability of PKCS#11 support for gpg2. The first release that we deem decent enough to be publicly released can be found at the following link: http://gnupg-pkcs11.sourceforge.net/ [1] Me and Alon Bar-Lev are current developers. The programs works (hopefully) as a drop-in replacement for "scd" distributed with GnuPG. It has been tested with some PKCS#11 providers (including IBM's OpenCryptoki softtoken), and card learning, signing as well as encryption are working. You are welcome to test it and report any problems via sourceforge. Creating this "fork" of scd for was neccessary because of Werner Koch's view upon PKCS#11 (which we don't agree with at all), and consequent refusal to integrate PKCS#11 support with regular GnuPG distribution. More information on the website is coming soon. Documentation and setup instructions are included in the source distribution. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFFLlf6FtofFpCIfhMRAybHAJ9vubalzEvFFO6JLh0rhxb2Hl533QCfWakb twjIhyPJpalSKD503d9gq6s= =yWxd -----END PGP SIGNATURE----- From alguibert+gpd at free.fr Fri Oct 13 00:51:27 2006 From: alguibert+gpd at free.fr (Alain Guibert) Date: Fri Oct 13 01:10:13 2006 Subject: GnuPG 1.9.92 build failures on old Linux In-Reply-To: <877iz5zg41.fsf@wheatstone.g10code.de> <87bqohzgvr.fsf@wheatstone.g10code.de> References: <20061011181803.GB21795@free.fr> <877iz5zg41.fsf@wheatstone.g10code.de> <20061011181803.GB21795@free.fr> <87bqohzgvr.fsf@wheatstone.g10code.de> Message-ID: <20061012225126.GA29248@free.fr> Hello Werner, you are The Boss! On Thursday, October 12, 2006 at 17:35:36 +0200, Werner Koch wrote: > On Wed, 11 Oct 2006 20:18, Alain Guibert said: >>| protect-tool.c:1187: `orig_codeset' undeclared (first use this function) > Fixed: Indeed the agent now builds OK. >>| asschk: cmd_expect_ok: expected OK but got `ERR 50331649 General error ' > Without the agent this is expected. In fact, --disable-agent is not > very useful except for package building. Understood. And now with the agent all is OK: | PASS: sm-sign+verify | PASS: sm-verify | ================== | All 2 tests passed | ================== On Thursday, October 12, 2006 at 17:52:14 +0200, Werner Koch wrote: >>| In file included from apdu.c:37: >>| /usr/include/unistd.h:656: conflicting types for `pth_usleep' >>| /usr/local/include/pth.h:531: previous declaration of `pth_usleep' > Please try this: Works fine, despite my restored original unistd.h. Great! Thank you very much for all, Werner. Alain. From jmoore3rd at bellsouth.net Fri Oct 13 05:54:30 2006 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Fri Oct 13 06:51:34 2006 Subject: My BAD! Message-ID: <452F0DF6.40203@bellsouth.net> I missed the change in 'options.h' with the svn4298 Release. Sorry for any confusion. I think it'll Compile fine now. JOHN :-! Timestamp: Thursday 12 Oct 2006, 23:54 --400 (Eastern Daylight Time) From jmoore3rd at bellsouth.net Fri Oct 13 06:17:31 2006 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Fri Oct 13 06:51:37 2006 Subject: Again; svn4298 Message-ID: <452F135B.5080604@bellsouth.net> Sadly, I now receive (under MingW/MSYS) this Error: F:/msys/home/Compaq_Owner/4298/g10/gpg.c:1732: undefined reference to `S2K_DECODE_COUNT' Either I'm totally confused or something else has changed. :-\ JOHN :( Timestamp: Friday 13 Oct 2006, 00:17 --400 (Eastern Daylight Time) From jmoore3rd at bellsouth.net Fri Oct 13 05:41:01 2006 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Fri Oct 13 06:51:46 2006 Subject: svn4298 Message-ID: <452F0ACD.6070405@bellsouth.net> Compiling under MingW/MSYS the following Error was encountered: gpg.c: In function `encode_s2k_iterations': gpg.c:1732: warning: implicit declaration of function `S2K_DECODE_COUNT' gpg.c: In function `main': gpg.c:1810: error: structure has no member named `s2k_count' gpg.c:2385: error: structure has no member named `s2k_count' make[1]: *** [gpg.o] Error 1 make[1]: Leaving directory `/home/Compaq_Owner/4298/g10' make: *** [check-recursive] Error 1 ????? JOHN :( Timestamp: Thursday 12 Oct 2006, 23:40 --400 (Eastern Daylight Time) From ms at mschilling.com Fri Oct 13 12:32:31 2006 From: ms at mschilling.com (Monika Schilling) Date: Fri Oct 13 13:51:29 2006 Subject: Windows Installer: Inproper creation of start menu entries Message-ID: <200610131132.35822.ms@mschilling.com> Hi, The windows installer gnupg-w32cli-1.4.5.exe (and earlier version) creates the start menu entries wrongly below %USERPROFILE% instead of correctly below %ALLUSERSPROFILE%. As a consequence users different from the installing user do not have entries for GnuPG in their start menu. Monika From patrick at mozilla-enigmail.org Fri Oct 13 17:57:36 2006 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Fri Oct 13 19:51:21 2006 Subject: [Announce] GnuPG 1.9.92 released In-Reply-To: <87mz832m1k.fsf__5769.03691185198$1160566985$gmane$org@wheatstone.g10code.de> References: <87mz832m1k.fsf__5769.03691185198$1160566985$gmane$org@wheatstone.g10code.de> Message-ID: <452FB770.5090609@mozilla-enigmail.org> Werner Koch wrote: [...] > > * The gpg code from 1.4.5 has been fully merged into this release. > The configure option --enable-gpg is still required to build this > gpg part. For production use of OpenPGP the gpg version 1.4.5 is > still recommended. Note, that gpg will be installed under the name > gpg2 to allow coexisting with an 1.4.x gpg. [...] Does it make sense to start testing GnuPG 1.4 frontends (such as Enigmail) with this release and work on making them compatible to gpg2? -Patrick From ametzler at downhill.at.eu.org Sat Oct 14 09:53:19 2006 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat Oct 14 09:52:00 2006 Subject: Co-installabilty of gnup2 1.9.91 and gpg 1.4.x Message-ID: Hello, even if I build gnupg2 with ./configure --build i486-linux-gnu --enable-maintainer-mode \ --prefix=/usr --libexecdir=/usr/lib/gnupg2 \ --sysconfdir=/etc --with-included-gettext \ --with-zlib=/usr --infodir=/usr/share/info/ --enable-gpg \ --mandir='${prefix}/share/man' I get if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../gl -I../common -I../intl -DLOCALEDIR=\ "/usr/share/locale\" -DGNUPG_BINDIR="\"/usr/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/li b/gnupg2\"" -DGNUPG_LIBDIR="\"/usr/lib/gnupg\"" -DGNUPG_DATADIR="\"/usr/share/gn upg\"" -DGNUPG_SYSCONFDIR="\"/etc/gnupg\"" [...] and after make install pcsc-wrapper ends up in /usr/lib/gnupg/. I guess am/cmacros.am is responsible for this, shouldn't it refer to @PACKAGE_GT@ instead of @PACKAGE@? to use gnupg2 instead of gnupg everywhere? cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken. (c) Jasper Ffforde From wk at gnupg.org Sat Oct 14 13:43:04 2006 From: wk at gnupg.org (Werner Koch) Date: Sat Oct 14 13:47:40 2006 Subject: [Announce] GnuPG 1.9.92 released In-Reply-To: <452FB770.5090609@mozilla-enigmail.org> (Patrick Brunschwig's message of "Fri, 13 Oct 2006 17:57:36 +0200") References: <87mz832m1k.fsf__5769.03691185198$1160566985$gmane$org@wheatstone.g10code.de> <452FB770.5090609@mozilla-enigmail.org> Message-ID: <87r6xbunqv.fsf@wheatstone.g10code.de> On Fri, 13 Oct 2006 17:57, Patrick Brunschwig said: > Does it make sense to start testing GnuPG 1.4 frontends (such as > Enigmail) with this release and work on making them compatible to gpg2? You should not experience any difference unkless you use one of the deprecated options. So well, tesing would be a good idea to see what has accidently be broken. Shalom-Salam, Werner From wk at gnupg.org Sat Oct 14 13:45:48 2006 From: wk at gnupg.org (Werner Koch) Date: Sat Oct 14 13:52:51 2006 Subject: Co-installabilty of gnup2 1.9.91 and gpg 1.4.x In-Reply-To: (Andreas Metzler's message of "Sat, 14 Oct 2006 09:53:19 +0200") References: Message-ID: <87mz7zunmb.fsf@wheatstone.g10code.de> On Sat, 14 Oct 2006 09:53, Andreas Metzler said: > and after make install pcsc-wrapper ends up in /usr/lib/gnupg/. pcsc-wrapper is only needed by gnupg2 and /usr/lib/gnupg is a good place for it. In fact some other software expects it there. > I guess am/cmacros.am is responsible for this, shouldn't it refer to > @PACKAGE_GT@ instead of @PACKAGE@? to use gnupg2 instead of gnupg _GT stands for gettext - this is to keep the translations separate. Salam-Shalom, Werner From alon.barlev at gmail.com Sat Oct 14 21:51:57 2006 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat Oct 14 23:51:46 2006 Subject: gnupg and friends under win32 Message-ID: <200610142151.57316.alon.barlev@gmail.com> Hello, I've tried to use gnupg components under win32, I had several problems, I hope it will help. libassuan: 1. Trivial modification to autogen.sh, adding new host and fixing call to configure. 2. Add some missing types. 3. Modify include location. 4. Removed _get_osfhandle from pipe server... read (0...), write (1...) works, while read (handle, ...), write (handle...) does not. BTW: Why don't you use named pipes in order to emulate linux domain sockets? It will be standard implementation and allow quite simple handling. libgcrypt: 1. Trivial modification to autogen.sh, adding new host and fixing call to configure. 2. tests should not be called for w32... I did not complete this using ifdef... libgpg-error: 1. Trivial modification to autogen.sh, adding new host and fixing call to configure. 2. get_locale_dir should return valid value in any path, so default to '\' if failed. Best Regards, Alon Bar-Lev. -------------- next part -------------- A non-text attachment was scrubbed... Name: libassuan-0.9.3-win32.diff Type: text/x-diff Size: 3909 bytes Desc: not available Url : /pipermail/attachments/20061014/435d353b/libassuan-0.9.3-win32.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: libgpg-error-1.3-win32.diff Type: text/x-diff Size: 1300 bytes Desc: not available Url : /pipermail/attachments/20061014/435d353b/libgpg-error-1.3-win32.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: libgcrypt-1.2.2-win32.diff Type: text/x-diff Size: 1392 bytes Desc: not available Url : /pipermail/attachments/20061014/435d353b/libgcrypt-1.2.2-win32.bin From wk at gnupg.org Sun Oct 15 17:19:17 2006 From: wk at gnupg.org (Werner Koch) Date: Sun Oct 15 17:22:41 2006 Subject: gnupg and friends under win32 In-Reply-To: <200610142151.57316.alon.barlev@gmail.com> (Alon Bar-Lev's message of "Sat, 14 Oct 2006 21:51:57 +0200") References: <200610142151.57316.alon.barlev@gmail.com> Message-ID: <87y7rhtxmy.fsf@wheatstone.g10code.de> On Sat, 14 Oct 2006 21:51, Alon Bar-Lev said: > I've tried to use gnupg components under win32, I had several > problems, I hope it will help. They are know to currently not work under W32 and we won't do any changes before a 2.0 release. > BTW: Why don't you use named pipes in order to emulate linux domain > sockets? It will be standard implementation and allow quite simple Because named pipe have different semantics than sockets. Salam-Shalom, Werner From patrick at mozilla-enigmail.org Mon Oct 16 09:18:08 2006 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Mon Oct 16 09:16:58 2006 Subject: GnuPG 1.9.92 -- first findings Message-ID: <45333230.5030009@mozilla-enigmail.org> I have tried gpg2 on my Linux box and found several issues: * gpg2 reproducibly destroyed my keyring with the following sequence of commands: # gpg2 --charset utf8 --no-tty --status-fd 1 --logger-fd 1 \ --command-fd 0 --ask-cert-level --edit-key <0xKeyid> trust # gpg2 --charset utf8 --batch --no-tty --status-fd 2 \ --with-fingerprint --fixed-list-mode --with-colons --list-keys * gpg2 always uses pinentry instead of the passphrase-fd in the following example: # gpg2 --charset utf8 --passphrase-fd 0 --no-use-agent --no-tty \ --status-fd 1 --logger-fd 1 --command-fd 0 -u 0xD8A807C7CCEC227B \ --ask-cert-level --edit-key 9CD4D060D74A14F3 lsign * Importing a key from a keyserver doesn't work: gpg2 --debug-all --recv-keys 0x810271D5 gpg: reading options from `/home/pbr/.gnupg/gpg.conf' gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: DBG: execlp: /usr/local/libexec/gpg2keys_hkp gpg: DBG: iobuf-1.0: fdopen `[fd 5]' gpg: DBG: iobuf-1.0: ioctl `file_filter(fd)' no_cache=1 gpg: DBG: iobuf-1.0: ioctl `file_filter(fd)' no_cache=1 gpg: requesting key 810271D5 from hkp server wwwkeys.eu.pgp.net gpg: DBG: iobuf-1.0: underflow: req=8192 gpg: DBG: iobuf-1.0: underflow: got=0 rc=-1 gpg: DBG: [fd 5]: close fd 5 gpg: DBG: fd_cache_close (0x5) real gpg: DBG: iobuf-1.0: underflow: eof gpg: DBG: iobuf-1.0: close `(null)' gpg: unnatural exit of external program gpg: no handler for keyserver scheme `hkp' gpg: keyserver receive failed: Keyserver error random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 secmem usage: 0/32768 bytes in 0 blocks Happy bugfixing :-) -Patrick From wk at gnupg.org Mon Oct 16 14:24:38 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Oct 16 14:27:49 2006 Subject: GnuPG 1.9.92 -- first findings In-Reply-To: <45333230.5030009@mozilla-enigmail.org> (Patrick Brunschwig's message of "Mon, 16 Oct 2006 09:18:08 +0200") References: <45333230.5030009@mozilla-enigmail.org> Message-ID: <87iriktpmh.fsf@wheatstone.g10code.de> On Mon, 16 Oct 2006 09:18, Patrick Brunschwig said: > * gpg2 reproducibly destroyed my keyring with the following sequence of > commands: > # gpg2 --charset utf8 --no-tty --status-fd 1 --logger-fd 1 \ > --command-fd 0 --ask-cert-level --edit-key <0xKeyid> trust > > # gpg2 --charset utf8 --batch --no-tty --status-fd 2 \ > --with-fingerprint --fixed-list-mode --with-colons --list-keys I tried that suing a copy of my own key and answering 4, save. No signs of a currupted keyring. Did you used that on the command line or are these the invoctions from enigmail. It would be good to see an lsof output then. > > * gpg2 always uses pinentry instead of the passphrase-fd in the > following example: > # gpg2 --charset utf8 --passphrase-fd 0 --no-use-agent --no-tty \ > --status-fd 1 --logger-fd 1 --command-fd 0 -u 0xD8A807C7CCEC227B \ > --ask-cert-level --edit-key 9CD4D060D74A14F3 lsign I can't replicate this. --use-agent and --no-use-agent have no effect as the agent is always used unless --passphrase-fd is given. BTW, using passphrase-fd along with --command-fd is questionable because --passphrase-fd reads the passphrase once and right at startup whereas --command-fd ask for the passphrase as needed. > gpg2 --debug-all --recv-keys 0x810271D5 Well, I can't find this key at all. Using gpg2 --keyserver hkp://minsky.surfnet.nl --recv-keys \ --no-permission-warning 0x5b0358a2 works just fine. (--no-permission-warnig is needed only in my test setup.) > gpg: no handler for keyserver scheme `hkp' What options did you set in your gpg.conf? Also check that there is no gpg.conf-1.9*. Build options? Can you send me the config.log by PM? Salam-Shalom, Werner From patrick at mozilla-enigmail.org Mon Oct 16 20:07:15 2006 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Mon Oct 16 20:05:20 2006 Subject: GnuPG 1.9.92 -- first findings In-Reply-To: <87iriktpmh.fsf@wheatstone.g10code.de> References: <45333230.5030009@mozilla-enigmail.org> <87iriktpmh.fsf@wheatstone.g10code.de> Message-ID: <4533CA53.8060406@mozilla-enigmail.org> Werner Koch wrote: > On Mon, 16 Oct 2006 09:18, Patrick Brunschwig said: > >> * gpg2 reproducibly destroyed my keyring with the following sequence of >> commands: >> # gpg2 --charset utf8 --no-tty --status-fd 1 --logger-fd 1 \ >> --command-fd 0 --ask-cert-level --edit-key <0xKeyid> trust >> >> # gpg2 --charset utf8 --batch --no-tty --status-fd 2 \ >> --with-fingerprint --fixed-list-mode --with-colons --list-keys > > I tried that suing a copy of my own key and answering 4, save. No > signs of a currupted keyring. Did you used that on the command line > or are these the invoctions from enigmail. It would be good to see an > lsof output then. I could reproduce it on the command line without Enigmail. I believe it's related to my keyring; using just a subset of the keyring, everything works fine. On the other hand I don't have the same issue with gpg 1.4.5. >> * gpg2 always uses pinentry instead of the passphrase-fd in the >> following example: >> # gpg2 --charset utf8 --passphrase-fd 0 --no-use-agent --no-tty \ >> --status-fd 1 --logger-fd 1 --command-fd 0 -u 0xD8A807C7CCEC227B \ >> --ask-cert-level --edit-key 9CD4D060D74A14F3 lsign > > I can't replicate this. --use-agent and --no-use-agent have no effect > as the agent is always used unless --passphrase-fd is given. > > BTW, using passphrase-fd along with --command-fd is questionable > because --passphrase-fd reads the passphrase once and right at startup > whereas --command-fd ask for the passphrase as needed. Indeed, I'll have to change it. > >> gpg2 --debug-all --recv-keys 0x810271D5 > > Well, I can't find this key at all. Using > > gpg2 --keyserver hkp://minsky.surfnet.nl --recv-keys \ > --no-permission-warning 0x5b0358a2 > > works just fine. (--no-permission-warnig is needed only in my test setup.) > >> gpg: no handler for keyserver scheme `hkp' > > What options did you set in your gpg.conf? Also check that there is > no gpg.conf-1.9*. Build options? Can you send me the config.log by > PM? Sure -- done. Patrick From patrick at mozilla-enigmail.org Tue Oct 17 09:35:51 2006 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Tue Oct 17 09:34:06 2006 Subject: GnuPG 1.9.92 -- first findings In-Reply-To: <4533CA53.8060406@mozilla-enigmail.org> References: <45333230.5030009@mozilla-enigmail.org> <87iriktpmh.fsf@wheatstone.g10code.de> <4533CA53.8060406@mozilla-enigmail.org> Message-ID: <453487D7.20202@mozilla-enigmail.org> [...] >>> gpg2 --debug-all --recv-keys 0x810271D5 >> Well, I can't find this key at all. Using >> >> gpg2 --keyserver hkp://minsky.surfnet.nl --recv-keys \ >> --no-permission-warning 0x5b0358a2 >> >> works just fine. (--no-permission-warnig is needed only in my test setup.) I have narrowed this down to a segmentation fault in libpth. Here is the stack trace from gdb -- I got the same stack trace with pth 1.4.1 and 2.0.7. Program received signal SIGSEGV, Segmentation fault. 0x4004e8d8 in __pth_ring_append () from /usr/local/lib/libpth.so.14 bt: #0 0x4004e8d8 in __pth_ring_append () from /usr/local/lib/libpth.so.14 #1 0x40052db4 in pth_mutex_acquire () from /usr/local/lib/libpth.so.14 #2 0x0804d089 in es_create (stream=0xbf8bb380, cookie=, fd=, functions= {func_read = 0x804fc00 , func_write = 0x8050820 , func_seek = 0, func_close = 0x804fc40 }) at estream.c:218 #3 0x0804e0e6 in es_fopencookie (cookie=0x80556c0, mode=0x200
, functions= {func_read = 0x804fc00 , func_write = 0x8050820 , func_seek = 0, func_close = 0x804fc40 }) at estream.c:1937 #4 0x08050603 in http_open (r_hd=0x80550e8, reqtype=HTTP_REQ_GET, url=0xbf8bb4c1 "http://wwwkeys.eu.pgp.net:11371/pks/lookup?op=get&options=mr&search=0x4E463A6A", auth=0x0, flags=0, proxy=0x0, tls_context=0x200) at http.c:1022 #5 0x0804c3da in curl_easy_perform (curl=0x80550c0) at curl-shim.c:208 #6 0x0804aa65 in main (argc=1, argv=0xbf8bbfc4) at gpgkeys_hkp.c:282 Any ideas? Patrick From lionel at mamane.lu Tue Oct 17 11:45:36 2006 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Tue Oct 17 11:42:41 2006 Subject: DSA2 In-Reply-To: <451CDAC8.7070700@sixdemonbag.org> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060929051112.GA1551@capsaicin.mamane.lu> <451CDAC8.7070700@sixdemonbag.org> Message-ID: <20061017094536.GB29585@capsaicin.mamane.lu> On Fri, Sep 29, 2006 at 03:35:20AM -0500, Robert J. Hansen wrote: > Lionel Elie Mamane wrote: >>> - DSA does not support "firewalled hashes" >> Not exactly. Version 3 DSA signatures lack a hash firewall. But >> version 4 DSA signatures do have a hash firewall. The version refers >> not to a version of DSA itself, but the version of the OpenPGP packet >> format being used. > if memory serves we can talk about one set of versions for keys, and > another set of versions for signatures, etc., etc. Exactly. > It is my understanding--and I would welcome being pointed to > language in the RFC showing that I am wrong--that v4 DSA keys lack a > satisfactory hash function firewall. I'm not talking about v4 DSA _keys_ but about v4 _signatures_ issued by DSA keys. And, to quote an email from an earlier discussion with you (on the PGP-Basics ML, Message-ID: <20050905141121.GB22994@tofu.mamane.lu>): ?5.2.4 of the RFC: Once the data body is hashed, then a trailer is hashed. A V3 signature hashes five octets of the packet body, starting from the signature type field. This data is the signature type, followed by the four-octet signature time. and A V4 signature hashes the packet body starting from its first field, the version number, through the end of the hashed subpacket data. Thus, the fields hashed are the signature version, the signature type, the public key algorithm, the hash algorithm, the hashed subpacket length, and the hashed subpacket body. So, the signed data contains (via a hash) the hash algorithm, which constitutes a hash function firewall. Do you have any argument to say it is not "satisfactory"? -- Lionel From rjh at sixdemonbag.org Tue Oct 17 11:57:59 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue Oct 17 12:52:08 2006 Subject: DSA2 In-Reply-To: <20061017094536.GB29585@capsaicin.mamane.lu> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060929051112.GA1551@capsaicin.mamane.lu> <451CDAC8.7070700@sixdemonbag.org> <20061017094536.GB29585@capsaicin.mamane.lu> Message-ID: <4534A927.20709@sixdemonbag.org> Lionel Elie Mamane wrote: > So, the signed data contains (via a hash) the hash algorithm, which > constitutes a hash function firewall. Do you have any argument to say > it is not "satisfactory"? I just got this email today, despite the fact it's a response to a message from September 29. I figure that either Lionel was delayed in responding to mail or else my mailserver ate something in a big way. Either way, my response is the same. I'll quote David Shaw, again from September 29: ===== On Fri, Sep 29, 2006 at 07:11:12AM +0200, Lionel Elie Mamane wrote: > ... Version 3 DSA signatures lack a hash firewall. But version 4 DSA > signatures do have a hash firewall. The version refers not to a > version of DSA itself, but the version of the OpenPGP packet format > being used. This is not correct. No DSA signatures in OpenPGP, whether v3 or v4, have a hash firewall. > > - RSA does support "firewalled hashes". > > All RSA signatures (V3 or V4) do have a hash firewall, yes. Yes. It's important to not focus unduly on one thing. This gives hash firewalls too much import. Today it's hash firewalls. Yesterday it was hash length. Before that it was key size, etc, etc. ===== ... I've edited David's response slightly for space concerns, but I think I've quoted him accurately. I agree with David that the lack of a HFF is not the end of the world. However, it's something that sets off my own twitch sensors and causes me to look to RSA instead. From lionel at mamane.lu Tue Oct 17 12:59:54 2006 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Tue Oct 17 12:56:44 2006 Subject: DSA2 In-Reply-To: <20060929124146.GB25664@jabberwocky.com> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060929051112.GA1551@capsaicin.mamane.lu> <20060929124146.GB25664@jabberwocky.com> Message-ID: <20061017105954.GA30197@capsaicin.mamane.lu> On Fri, Sep 29, 2006 at 08:41:46AM -0400, David Shaw wrote: > On Fri, Sep 29, 2006 at 07:11:12AM +0200, Lionel Elie Mamane wrote: >> On Sat, Sep 23, 2006 at 03:15:07PM +0200, Carlo Luciano Bianco wrote: >>> I just try to summarize what I understood from this thread about >>> OpenPGP implementation of DSA and RSA signatures, so you can correct >>> me if I am wrong: ;-) >>> - DSA does not support "firewalled hashes" >> Not exactly. Version 3 DSA signatures lack a hash firewall. But >> version 4 DSA signatures do have a hash firewall. The version refers >> not to a version of DSA itself, but the version of the OpenPGP packet >> format being used. > This is not correct. No DSA signatures in OpenPGP, whether v3 or > v4, have a hash firewall. I got that idea from this language in the RFC: A V4 signature hashes the packet body starting from its first field, the version number, through the end of the hashed subpacket data. Thus, the fields hashed are the signature version, the signature type, the public key algorithm, the hash algorithm, the hashed subpacket length, and the hashed subpacket body. Doesn't the fact that the they hash algorithm identifier is hashed into what is DSA-signed establish a hash firewall? -- Lionel From wk at gnupg.org Tue Oct 17 13:09:35 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 17 13:12:38 2006 Subject: GnuPG 1.9.92 -- first findings In-Reply-To: <453487D7.20202@mozilla-enigmail.org> (Patrick Brunschwig's message of "Tue\, 17 Oct 2006 09\:35\:51 +0200") References: <45333230.5030009@mozilla-enigmail.org> <87iriktpmh.fsf@wheatstone.g10code.de> <4533CA53.8060406@mozilla-enigmail.org> <453487D7.20202@mozilla-enigmail.org> Message-ID: <87fydn5hcg.fsf@wheatstone.g10code.de> On Tue, 17 Oct 2006 09:35, Patrick Brunschwig said: > #5 0x0804c3da in curl_easy_perform (curl=0x80550c0) at curl-shim.c:208 > #6 0x0804aa65 in main (argc=1, argv=0xbf8bbfc4) at gpgkeys_hkp.c:282 > > Any ideas? Ah okay, you are building with the libcurl repalcement. I need to test this. Salam-Shalom, Werner From dshaw at jabberwocky.com Tue Oct 17 14:41:18 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Oct 17 14:39:32 2006 Subject: DSA2 In-Reply-To: <20061017105954.GA30197@capsaicin.mamane.lu> References: <20060921123803.85621.qmail@web26709.mail.ukl.yahoo.com> <20060921130605.GB3928@jabberwocky.com> <20060929051112.GA1551@capsaicin.mamane.lu> <20060929124146.GB25664@jabberwocky.com> <20061017105954.GA30197@capsaicin.mamane.lu> Message-ID: <20061017124118.GC27060@jabberwocky.com> On Tue, Oct 17, 2006 at 12:59:54PM +0200, Lionel Elie Mamane wrote: > > This is not correct. No DSA signatures in OpenPGP, whether v3 or > > v4, have a hash firewall. > > I got that idea from this language in the RFC: > > A V4 signature hashes the packet body > starting from its first field, the version number, through the end of > the hashed subpacket data. Thus, the fields hashed are the signature > version, the signature type, the public key algorithm, the hash > algorithm, the hashed subpacket length, and the hashed subpacket > body. > > Doesn't the fact that the they hash algorithm identifier is hashed > into what is DSA-signed establish a hash firewall? No. That puts the hash algorithm inside the document being hashed. If the hash is broken, then that's the worst place for the identifier to be :) What DSA does is (more or less): DSA( Hash( Identifier + document ) ) What RSA, with its hash firewall does is (again, more or less): RSA( Identifier + Hash( document ) ) Note that the identifier is present outside of the hash in the material given to the RSA algorithm (it's actually present inside the hash as well, but that's not relevant here). If the hash is broken, that doesn't impact the identifier that isn't in the hash. David From wk at gnupg.org Tue Oct 17 16:03:17 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 17 16:07:47 2006 Subject: GnuPG 1.9.92 -- first findings In-Reply-To: <453487D7.20202@mozilla-enigmail.org> (Patrick Brunschwig's message of "Tue\, 17 Oct 2006 09\:35\:51 +0200") References: <45333230.5030009@mozilla-enigmail.org> <87iriktpmh.fsf@wheatstone.g10code.de> <4533CA53.8060406@mozilla-enigmail.org> <453487D7.20202@mozilla-enigmail.org> Message-ID: <877iyz59ay.fsf@wheatstone.g10code.de> On Tue, 17 Oct 2006 09:35, Patrick Brunschwig said: > #5 0x0804c3da in curl_easy_perform (curl=0x80550c0) at curl-shim.c:208 > #6 0x0804aa65 in main (argc=1, argv=0xbf8bbfc4) at gpgkeys_hkp.c:282 > > Any ideas? Yes: Unitialized used of Pth. I have changed how we link to Pth and so that only those tools actually requiring it are linked to pth. these are then intialized. I'll try to do another release tomorrow. Salam-Shalom, Werner From ariga at os.rim.or.jp Wed Oct 18 03:12:59 2006 From: ariga at os.rim.or.jp (ARIGA Seiji) Date: Wed Oct 18 03:11:19 2006 Subject: x509 v1 certificate In-Reply-To: <20060930.111136.35717327.say@khaotic.net> References: <20060925.220849.167661107.kazu@iij.ad.jp> <87fyeft2gq.fsf@wheatstone.g10code.de> <20060929.172600.88529589.say@khaotic.net> <87mz8iodd5.fsf@wheatstone.g10code.de> <20060930.111136.35717327.say@khaotic.net> Message-ID: <20061018.101259.127828878.say@khaotic.net> # please let me resend message as i didn't see my email from the list. i upgraded to gnupg-1.9.92 (and libksba-1.0.0 & libassuan-0.9.3). but i still failed to verify cert whose root cert doesn't have X509v3 extensions even after adding "relax" flag in trustlist.txt. any suggestion ? # i've attached mail body, signature for it, gpgsm output and # trustlist.txt. // ARIGA Seiji On Sat, 30 Sep 2006 11:11:36 +0900 (JST), ARIGA Seiji wrote, > > > ---- > > > gpgsm: error getting key usage information: No value > > > gpgsm: invalid certification chain: No value > > > ---- > > > > Sure, that you added the "relax" flag to the appropriate line of the > > trustlist.txt and also updated the gpg-agent.? > > do you mean that is expected ? i thought you've changed gpgsm to allow > us to use/validate old VeriSign cert (v1 certs). > > # but as i showed, "--verify" still failed. > > without "relax", i only got this. > > ---- > gpgsm: invalid certification chain: No value > ---- > > i think certlist.c:cert_usage_p() returns message > above ("... key usage ..."). > > # this is called by certchain.c:gpgsm_cert_use_cert_p() > # (which looks irrelevant to "relax" flag). > > // ARIGA Seiji -------------- next part -------------- Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit ??????????????????????? ?????????????????????????????????? ???????????????????????????????????? ???????? ???????????????????????????????????? ??????????????????????????? ???????????????????????????????????? ????????? ????????????????????????????? ?????????? ??18?08?30? ????? ??????? 3,597? ??? ? ??? ???18?08?28?17?34????????? 08290038-0010? ???????????????????????????????? ???????????One's?????(????????????)? ??????????????? ???????????????? ? http://direct.smbc.co.jp/ ???????????????? ???????????????????????????????????? ???????????????????????????????????? ?????????? ?????????????????????????????? ???????????????????????????? ???????????????????????????????????? ???????????????????????????????????? ???????????????????? ??????????????????????????????????? ??????????????????????????????????? ??????????????????????????????????? ???????????????????????????? ?????????????????????????????????? ??????????????????????????????????? ??????????????????????????????? ??????????????????? ???????????????????????????????? ??????? ???????????????????????????????????? ?????? http://www.smbc.co.jp/kojin/direct/faq/info.html ???????????????????????????????????? ?????????????One's?????????????????? ???????????????????????????????? ???????????????????????? ???????????????????????? -------------- next part -------------- A non-text attachment was scrubbed... Name: mail.sig Type: application/octet-stream Size: 4011 bytes Desc: not available Url : /pipermail/attachments/20061018/f79cac58/mail-0001.obj -------------- next part -------------- i run following commands: gpgsm --version -> succeed gpgsm --debug-level=guru --verify mail.sig mail -> failed gpgsm --debug-level=guru --debug-no-chain-validation --verify mail.sig mail -> succeed =============================================================================== > gpgsm --version gpgsm (GnuPG) 1.9.92 Copyright (C) 2006 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Home: ~/.gnupg Supported algorithms: =============================================================================== > gpgsm --debug-level=guru --verify mail.sig mail gpgsm: detached signature gpgsm: DBG: signer 0 - issuer: `CN=VeriSign Class 3 Organizational CA,OU=Terms of use at https://www.verisign.com/rpa (c)04,OU=VeriSign Trust Network,O=VeriSign\, Inc.,C=US' gpgsm: DBG: signer 0 - serial: 5129BDA938A6B9C95DD559E5AE548730 gpgsm: DBG: signer 0 - digest algo: 2 gpgsm: DBG: signer 0 - content-type attribute: 1.2.840.113549.1.7.1 gpgsm: DBG: signer 0 - signature available gpgsm: Signature made 2006-08-28 22:00:38 using certificate ID 30BFD581 gpgsm: DBG: public key: 28 31 30 3A 70 75 62 6C 69 63 2D 6B 65 79 28 33 3A 72 73 61 28 31 3A 6E 31 32 39 3A 00 D9 01 B6 30 36 40 96 F9 6B 5D 74 3D BC B2 55 8B B0 28 E6 BC AC DB A8 8A 20 97 C7 57 97 05 1E D8 1A B8 50 82 D4 25 37 45 DA 36 2E AC 2E D5 BC 9E A1 66 6F AC AD A1 E7 4D 86 FD 21 E6 CA D8 0D 14 3F 50 58 81 9B 76 37 77 7F 80 03 02 EF 69 9E 93 7F E4 FB 39 C7 B0 F1 74 0D 53 C2 D6 4A E8 58 DF 20 4E 1E 1D 78 66 1C 91 E9 19 60 73 70 66 DF C1 5F AD 47 D5 6D 2C 01 DB CC 49 E7 0E 67 77 FD 1F 29 28 31 3A 65 33 3A 01 00 01 29 29 29 gpgsm: DBG: encoded hash: 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 C6 FD E3 57 8A BA 1E D0 E1 99 4F CD A8 6D B8 D1 44 46 21 43 DBG: pubkey_verify: algo=1 pkey:: D901B630364096F96B5D743DBCB2558BB028E6BCACDBA88A2097C75797051ED81AB85082D4253745DA362EAC2ED5BC9EA1666FACADA1E74D86FD21E6CAD80D143F5058819B7637777F800302EF699E937FE4FB39C7B0F1740D53C2D64AE858DF204E1E1D78661C91E91960737066DFC15FAD47D56D2C01DBCC49E70E6777FD1F pkey:: 10001 sig:: 4642F9C8618599A578BA03F8C2FF414E6EBBEA5B7AE9E74BA4B3BC03DA4E473BE9FCA74C48F2830908E6E58A22B548BDF76AA3194C3794FBAB12941D6016F50B34DD789F40C9628496141345C26D6CBAE08F6138EE62B78BF0169173F4BF92EFBF596A368EFDA953D84DE7ED04AD0EFBAD3B04DE5453E966324EA6F4155DD11E hash:: 1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF003021300906052B0E03021A05000414C6FDE3578ABA1ED0E1994FCDA86DB8D144462143 gpgsm: DBG: gcry_pk_verify: Success gpgsm: DBG: signature okay - checking certs gpgsm: DBG: BEGIN Certificate `target': gpgsm: DBG: serial: 5129BDA938A6B9C95DD559E5AE548730 gpgsm: DBG: notBefore: 2006-04-12 00:00:00 gpgsm: DBG: notAfter: 2007-04-11 23:59:59 gpgsm: DBG: issuer: CN=VeriSign Class 3 Organizational CA,OU=Terms of use at https://www.verisign.com/rpa (c)04,OU=VeriSign Trust Network,O=VeriSign\, Inc.,C=US gpgsm: DBG: subject: 1.2.840.113549.1.9.1=#534D42435F7365727669636540646E2E736D62632E636F2E6A70,CN=SUMITOMO MITSUI BANKING CORPORATION,OU=Class 3 Organizational E-Mail Certificate,OU=Terms of use at https://www.verisign.com/rpa (c)05,OU=Mass Retail Dept.\,Consumer Banking Unit,O=SUMITOMO MITSUI BANKING CORPORATION,L=Chiyoda-ku,ST=Tokyo,C=JP gpgsm: DBG: hash algo: 1.2.840.113549.1.1.5 gpgsm: DBG: SHA1 Fingerprint: 7B:84:E9:0E:15:2F:B3:F1:CC:06:24:22:A4:72:F5:A5:30:BF:D5:81 gpgsm: DBG: END Certificate gpgsm: DBG: got issuer's certificate: gpgsm: DBG: BEGIN Certificate `issuer': gpgsm: DBG: serial: 7A83358F7FE2A90B56F6A62D825A64FE gpgsm: DBG: notBefore: 2004-12-14 00:00:00 gpgsm: DBG: notAfter: 2009-12-13 23:59:59 gpgsm: DBG: issuer: OU=VeriSign Trust Network,OU=(c) 1998 VeriSign\, Inc. - For authorized use only,OU=Class 3 Public Primary Certification Authority - G2,O=VeriSign\, Inc.,C=US gpgsm: DBG: subject: CN=VeriSign Class 3 Organizational CA,OU=Terms of use at https://www.verisign.com/rpa (c)04,OU=VeriSign Trust Network,O=VeriSign\, Inc.,C=US gpgsm: DBG: hash algo: 1.2.840.113549.1.1.5 gpgsm: DBG: SHA1 Fingerprint: F2:5B:1D:61:DE:B5:86:B5:37:C0:1C:26:AC:A8:3E:FE:14:8A:33:C6 gpgsm: DBG: END Certificate gpgsm: DBG: signature value: 28 37 3A 73 69 67 2D 76 61 6C 28 33 3A 72 73 61 28 31 3A 73 32 35 36 3A 3E B7 C3 95 A9 48 88 12 78 FB 33 29 1B 25 0F 3F DE 9C 1B C2 03 A4 A6 F4 02 CD DC 26 9C F1 42 80 6F 26 8E E8 C7 3B 69 B3 E1 DF AB 1D 68 87 AD D8 9D 9C 75 31 45 FB 39 C2 29 48 49 01 9E C9 12 7C F0 09 F7 39 E8 5A A0 AD 1C 9B 54 E9 AB E2 F2 0E 65 44 B2 B9 0F 84 CB 99 68 54 0E F9 6B F8 EC C6 10 B7 26 CB 60 E2 EB 18 41 82 13 F7 88 F1 C4 3A F4 62 FE 95 5D C1 5F 31 A3 F2 9F D1 F6 89 0F 05 79 0A 60 B6 A0 FA 58 0B 34 8A C0 80 20 3C B4 0E C8 04 67 34 86 74 11 94 8C C5 51 EC B3 08 51 03 5D 25 2C 25 88 66 DA 12 8F 94 09 E9 EB 04 55 D6 9D AF AE B9 5A EC 74 AD A1 CE 75 22 89 39 27 51 85 D4 2F 7A 54 C6 9D 4E 09 3C BD F1 20 F9 1E 8F 13 09 AD AC EF 90 DD 59 56 EF CE 0E 33 2C 7C C1 B4 D5 E0 D6 99 B2 2B B6 40 A4 C1 89 BD BA DE 98 56 E5 28 ED 86 18 1B F4 A6 4E 2F 7B 10 F6 F3 1C 29 29 29 gpgsm: DBG: encoded hash: 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 AB C0 11 56 FC 13 EB C8 CA FE 92 DA 4D 1A 46 8D 00 2D 62 00 DBG: pubkey_verify: algo=1 pkey:: C3E6D47E53C9828A982CF75B488C83AEA0E557FE41349F007E80924061092E113F258369E1A398D70824848EC87AEF37FD7B7F37661D461EC180545DB20F5EB1CC19E9B84E21707DF05A0F3716AF1FBC90FB5773AC3937796D36BB96E387D61F43D0308E7947BD8C7041A96208BD29B0817F18E712509130989B02F3466D35B423186E5B8AA0DA43618E60C68E5833AC1588C7D487541EB4577C9DEC26103DA0227EE4EE1734BB8D909240F2A26DC282168DFC700CDA4CA126C1CB0877D7C73FB8B70E5E8DE95B3E37AF3F576E27979149B5419834F525BBFD0188D3D36F9CA71F24DFC79A6E9B4A1F34C450CBCA06647B0D4A74093C4BF5408D3B1C80923EED pkey:: 10001 sig:: 3EB7C395A948881278FB33291B250F3FDE9C1BC203A4A6F402CDDC269CF142806F268EE8C73B69B3E1DFAB1D6887ADD89D9C753145FB39C2294849019EC9127CF009F739E85AA0AD1C9B54E9ABE2F20E6544B2B90F84CB9968540EF96BF8ECC610B726CB60E2EB18418213F788F1C43AF462FE955DC15F31A3F29FD1F6890F05790A60B6A0FA580B348AC080203CB40EC8046734867411948CC551ECB30851035D252C258866DA128F9409E9EB0455D69DAFAEB95AEC74ADA1CE75228939275185D42F7A54C69D4E093CBDF120F91E8F1309ADACEF90DD5956EFCE0E332C7CC1B4D5E0D699B22BB640A4C189BDBADE9856E528ED86181BF4A64E2F7B10F6F31C hash:: 1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF003021300906052B0E03021A05000414ABC01156FC13EBC8CAFE92DA4D1A468D002D6200 gpgsm: DBG: gcry_pk_verify: Success gpgsm: certificate is good gpgsm: DBG: got issuer's certificate: gpgsm: DBG: BEGIN Certificate `issuer': gpgsm: DBG: serial: 7DD9FE07CFA81EB7107967FBA78934C6 gpgsm: DBG: notBefore: 1998-05-18 00:00:00 gpgsm: DBG: notAfter: 2028-08-01 23:59:59 gpgsm: DBG: issuer: OU=VeriSign Trust Network,OU=(c) 1998 VeriSign\, Inc. - For authorized use only,OU=Class 3 Public Primary Certification Authority - G2,O=VeriSign\, Inc.,C=US gpgsm: DBG: subject: OU=VeriSign Trust Network,OU=(c) 1998 VeriSign\, Inc. - For authorized use only,OU=Class 3 Public Primary Certification Authority - G2,O=VeriSign\, Inc.,C=US gpgsm: DBG: hash algo: 1.2.840.113549.1.1.5 gpgsm: DBG: SHA1 Fingerprint: 85:37:1C:A6:E5:50:14:3D:CE:28:03:47:1B:DE:3A:09:E8:F8:77:0F gpgsm: DBG: END Certificate gpgsm: DBG: signature value: 28 37 3A 73 69 67 2D 76 61 6C 28 33 3A 72 73 61 28 31 3A 73 31 32 38 3A 93 C9 76 B9 7E D5 42 E3 F9 57 88 54 4C E7 79 13 67 C5 93 08 64 88 CE 76 C5 71 F7 F6 04 B6 04 5F 2B 49 58 CC 74 4E 89 E2 2D 41 2F C7 D6 BE 44 52 88 9F E0 9E 39 76 08 FA FE 0E DA 82 A9 E8 CE 26 6F CA 84 12 FA 4B 58 9A 27 7D B4 9B AD 41 D5 21 08 D3 B0 D6 EC 9C E7 8D B5 21 A0 F7 50 11 A6 D7 11 92 99 2D 1F FE FC 98 F8 4E 6E C9 B8 3C 2C 89 39 3D 30 FF 81 11 3D F2 8C 31 6E 36 63 2D 7A 9C 29 29 29 gpgsm: DBG: encoded hash: 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 62 E4 AF 15 B0 30 B4 A1 C2 4C 5C E1 CB 71 49 96 7B 04 C6 CC DBG: pubkey_verify: algo=1 pkey:: CC5ED1115D5C69D0ABD3B96A4C991F5998308E168520466D473FD4852084E16DB3F8A4ED0CF1170F3BF9A7F925D7C1CF8463F27C63CFA247F2C65B338E64400468C180B9641C4577C7D86EF595293C50E834D7781FA8BA6D4391958F45575E7EC5FBCAA404EBEA973754306FBB01473233CDDC579B646961F89B1D1C894F5C67 pkey:: 10001 sig:: 93C976B97ED542E3F95788544CE7791367C593086488CE76C571F7F604B6045F2B4958CC744E89E22D412FC7D6BE4452889FE09E397608FAFE0EDA82A9E8CE266FCA8412FA4B589A277DB49BAD41D52108D3B0D6EC9CE78DB521A0F75011A6D71192992D1FFEFC98F84E6EC9B83C2C89393D30FF81113DF28C316E36632D7A9C hash:: 1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF003021300906052B0E03021A0500041462E4AF15B030B4A1C24C5CE1CB7149967B04C6CC gpgsm: DBG: gcry_pk_verify: Success gpgsm[60398]: can't connect to `/home/say/.gnupg/S.gpg-agent': No such file or directory gpgsm: no running gpg-agent - starting one gpgsm: DBG: connection to agent established gpgsm: error getting key usage information: No value gpgsm: invalid certification chain: No value random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 secmem usage: 0/16384 bytes in 0 blocks =============================================================================== > gpgsm --debug-level=guru --debug-no-chain-validation --verify mail.sig mail gpgsm: detached signature gpgsm: DBG: signer 0 - issuer: `CN=VeriSign Class 3 Organizational CA,OU=Terms of use at https://www.verisign.com/rpa (c)04,OU=VeriSign Trust Network,O=VeriSign\, Inc.,C=US' gpgsm: DBG: signer 0 - serial: 5129BDA938A6B9C95DD559E5AE548730 gpgsm: DBG: signer 0 - digest algo: 2 gpgsm: DBG: signer 0 - content-type attribute: 1.2.840.113549.1.7.1 gpgsm: DBG: signer 0 - signature available gpgsm: Signature made 2006-08-28 22:00:38 using certificate ID 30BFD581 gpgsm: DBG: public key: 28 31 30 3A 70 75 62 6C 69 63 2D 6B 65 79 28 33 3A 72 73 61 28 31 3A 6E 31 32 39 3A 00 D9 01 B6 30 36 40 96 F9 6B 5D 74 3D BC B2 55 8B B0 28 E6 BC AC DB A8 8A 20 97 C7 57 97 05 1E D8 1A B8 50 82 D4 25 37 45 DA 36 2E AC 2E D5 BC 9E A1 66 6F AC AD A1 E7 4D 86 FD 21 E6 CA D8 0D 14 3F 50 58 81 9B 76 37 77 7F 80 03 02 EF 69 9E 93 7F E4 FB 39 C7 B0 F1 74 0D 53 C2 D6 4A E8 58 DF 20 4E 1E 1D 78 66 1C 91 E9 19 60 73 70 66 DF C1 5F AD 47 D5 6D 2C 01 DB CC 49 E7 0E 67 77 FD 1F 29 28 31 3A 65 33 3A 01 00 01 29 29 29 gpgsm: DBG: encoded hash: 00 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 C6 FD E3 57 8A BA 1E D0 E1 99 4F CD A8 6D B8 D1 44 46 21 43 DBG: pubkey_verify: algo=1 pkey:: D901B630364096F96B5D743DBCB2558BB028E6BCACDBA88A2097C75797051ED81AB85082D4253745DA362EAC2ED5BC9EA1666FACADA1E74D86FD21E6CAD80D143F5058819B7637777F800302EF699E937FE4FB39C7B0F1740D53C2D64AE858DF204E1E1D78661C91E91960737066DFC15FAD47D56D2C01DBCC49E70E6777FD1F pkey:: 10001 sig:: 4642F9C8618599A578BA03F8C2FF414E6EBBEA5B7AE9E74BA4B3BC03DA4E473BE9FCA74C48F2830908E6E58A22B548BDF76AA3194C3794FBAB12941D6016F50B34DD789F40C9628496141345C26D6CBAE08F6138EE62B78BF0169173F4BF92EFBF596A368EFDA953D84DE7ED04AD0EFBAD3B04DE5453E966324EA6F4155DD11E hash:: 1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF003021300906052B0E03021A05000414C6FDE3578ABA1ED0E1994FCDA86DB8D144462143 gpgsm: DBG: gcry_pk_verify: Success gpgsm: DBG: signature okay - checking certs gpgsm: WARNING: bypassing certificate chain validation gpgsm: Good signature from "/CN=SUMITOMO MITSUI BANKING CORPORATION/OU=Class 3 Organizational E-Mail Certificate/OU=Terms of use at https:\x2f\x2fwww.verisign.com\x2frpa (c)05/OU=Mass Retail Dept.,Consumer Banking Unit/O=SUMITOMO MITSUI BANKING CORPORATION/L=Chiyoda-ku/ST=Tokyo/C=JP/EMail=SMBC_service@dn.smbc.co.jp" gpgsm: aka "SMBC_service@dn.smbc.co.jp" random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 secmem usage: 0/16384 bytes in 0 blocks -------------- next part -------------- F2:5B:1D:61:DE:B5:86:B5:37:C0:1C:26:AC:A8:3E:FE:14:8A:33:C6 S 85:37:1C:A6:E5:50:14:3D:CE:28:03:47:1B:DE:3A:09:E8:F8:77:0F S relax 0B:77:BE:BB:CB:7A:A2:47:05:DE:CC:0F:BD:6A:02:FC:7A:BD:9B:52 S 27:3E:E1:24:57:FD:C4:F9:0C:55:E8:2B:56:16:7F:62:F5:32:E5:47 S B3:EA:C4:47:76:C9:C8:1C:EA:F2:9D:95:B6:CC:A0:08:1B:67:EC:9D S CD:D4:EE:AE:60:00:AC:7F:40:C3:80:2C:17:1E:30:14:80:30:C0:72 S BE:36:A4:56:2F:B2:EE:05:DB:B3:D3:23:23:AD:F4:45:08:4E:D6:56 S 23:E5:94:94:51:95:F2:41:48:03:B4:D5:64:D2:A3:A3:F5:D8:8B:8C S 62:7F:8D:78:27:65:63:99:D2:7D:7F:90:44:C9:FE:B3:F3:3E:FA:9A S 36:86:35:63:FD:51:28:C7:BE:A6:F0:05:CF:E9:B4:36:68:08:6C:CE S 20:99:00:B6:3D:95:57:28:14:0C:D1:36:22:D8:C6:87:A4:EB:00:85 S 40:E7:8C:1D:52:3D:1C:D9:95:4F:AC:1A:1A:B3:BD:3C:BA:A1:5B:FC S A4:34:89:15:9A:52:0F:0D:93:D0:32:CC:AF:37:E7:FE:20:A8:B4:19 S 8E:B0:3F:C3:CF:7B:B2:92:86:62:68:B7:51:22:3D:B5:10:34:05:CB S 00:EA:52:2C:8A:9C:06:AA:3E:CC:E0:B4:FA:6C:DC:21:D9:2E:80:99 S CA:BB:51:67:24:00:58:8E:64:19:F1:D4:08:78:D0:40:3A:A2:02:64 S 6A:17:45:70:A9:16:FB:E8:44:53:EE:D3:D0:70:A1:D8:DA:44:28:29 S 7E:78:4A:10:1C:82:65:CC:2D:E1:F1:6D:47:B4:40:CA:D9:0A:19:45 S DA:40:18:8B:91:89:A3:ED:EE:AE:DA:97:FE:2F:9D:F5:B7:D1:8A:41 S E4:55:43:33:CA:39:0E:12:8B:8B:F8:1D:90:B7:0F:40:02:D1:D6:E9 S 43:DD:B1:FF:F3:B4:9B:73:83:14:07:F6:BC:8B:97:50:23:D0:7C:50 S 85:A4:08:C0:9C:19:3E:5D:51:58:7D:CD:D6:13:30:FD:8C:DE:37:BF S 9E:6C:EB:17:91:85:A2:9E:C6:06:0C:A5:3E:19:74:AF:94:AF:59:D4 S 5D:98:9C:DB:15:96:11:36:51:65:64:1B:56:0F:DB:EA:2A:C2:3E:F1 S E1:2D:FB:4B:41:D7:D9:C3:2B:30:51:4B:AC:1D:81:D8:38:5E:2D:46 S 04:83:ED:33:99:AC:36:08:05:87:22:ED:BC:5E:46:00:E3:BE:F9:D7 S B1:72:B1:A5:6D:95:F9:1F:E5:02:87:E1:4D:37:EA:6A:44:63:76:8A S 5E:5A:16:88:67:BF:FF:00:98:7D:0B:1D:C2:AB:46:6C:42:64:F9:56 S 4B:42:1F:75:15:F6:AE:8A:6E:CE:F9:7F:69:82:A4:00:A4:D9:22:4E S F4:40:95:C2:38:AC:73:FC:4F:77:BF:8F:98:DF:70:F8:F0:91:BC:52 S 21:6B:2A:29:E6:2A:00:CE:82:01:46:D8:24:41:41:B9:25:11:B2:79 S D2:ED:F8:8B:41:B6:FE:01:46:1D:6E:28:34:EC:7C:8F:6C:77:72:1E S 74:20:74:41:72:9C:DD:92:EC:79:31:D8:23:10:8D:C2:81:92:E2:BB S 40:72:BA:31:FE:C3:51:43:84:80:F6:2E:6C:B9:55:08:46:1E:AB:2F S 63:72:C4:9D:A9:FF:F0:51:B8:B5:C7:D4:E5:AA:E3:03:84:02:4B:9C S 4C:95:A9:90:2A:BE:07:77:CE:D1:8D:6A:CC:C3:37:2D:27:48:38:1E S 1F:55:E8:83:9B:AC:30:72:8B:E7:10:8E:DE:7B:0B:B0:D3:29:82:24 S 69:BD:8C:F4:9C:D3:00:FB:59:2E:17:93:CA:55:6A:F3:EC:AA:35:FB S 31:7A:2A:D0:7F:2B:33:5E:F5:A1:C3:4E:4B:57:E8:B7:D8:F1:FC:A6 S E5:DF:74:3C:B6:01:C4:9B:98:43:DC:AB:8C:E8:6A:81:10:9F:E4:8E S 58:11:9F:0E:12:82:87:EA:50:FD:D9:87:45:6F:4F:78:DC:FA:D6:D4 S 39:4F:F6:85:0B:06:BE:52:E5:18:56:CC:10:E1:80:E8:82:B3:85:CC S 99:A6:9B:E6:1A:FE:88:6B:4D:2B:82:00:7C:B8:54:FC:31:7E:15:39 S 43:F9:B1:10:D5:BA:FD:48:22:52:31:B0:D0:08:2B:37:2F:EF:9A:54 S B5:D3:03:BF:86:82:E1:52:91:9D:83:F1:84:ED:05:F1:DC:E5:37:0C S 87:9F:4B:EE:05:DF:98:58:3B:E3:60:D6:33:E7:0D:3F:FE:98:71:AF S E3:92:51:2F:0A:CF:F5:05:DF:F6:DE:06:7F:75:37:E1:65:EA:57:4B S AC:ED:5F:65:53:FD:25:CE:01:5F:1F:7A:48:3B:6A:74:9F:61:78:C6 S 81:96:8B:3A:EF:1C:DC:70:F5:FA:32:69:C2:92:A3:63:5B:D1:23:D3 S AB:48:F3:33:DB:04:AB:B9:C0:72:DA:5B:0C:C1:D0:57:F0:36:9B:46 S 76:39:C7:18:47:E1:51:B5:C7:EA:01:C7:58:FB:F1:2A:BA:29:8F:7A S BC:92:19:DD:C9:8E:14:BF:1A:78:1F:6E:28:0B:04:C2:7F:90:27:12 S 5B:4E:0E:C2:8E:BD:82:92:A5:17:82:24:12:81:AD:9F:EE:DD:4E:4C S D2:32:09:AD:23:D3:14:23:21:74:E4:0D:7F:9D:62:13:97:86:63:3A S 97:81:79:50:D8:1C:96:70:CC:34:D8:09:CF:79:44:31:36:7E:F4:74 S CF:F8:10:FB:2C:4F:FC:01:56:BF:E1:E1:FA:BC:B4:18:C6:8D:31:C5 S 00:48:F8:D3:7B:15:3F:6E:A2:79:8C:32:3E:F4:F3:18:A5:62:4A:9E S 54:F9:C1:63:75:9F:19:04:51:21:A3:19:F6:4C:2D:05:55:B7:E0:73 S 4E:FC:ED:9C:6B:DD:0C:98:5C:A3:C7:D2:53:06:3C:5B:E6:FC:62:0C S 28:4F:55:C4:1A:1A:7A:3F:83:28:D4:C2:62:FB:37:6E:D6:09:6F:24 S EB:BC:0E:2D:02:0C:A6:9B:22:2C:2B:FF:D2:03:CB:8B:F5:A8:27:66 S 04:98:11:05:6A:FE:9F:D0:F5:BE:01:68:5A:AC:E6:A5:D1:C4:45:4C S 3F:85:F2:BB:4A:62:B0:B5:8B:E1:61:4A:BB:0D:46:31:B4:BE:F8:BA S 97:E2:E9:96:36:A5:47:55:4F:83:8F:BA:38:B8:2E:74:F8:9A:83:0A S CF:F3:60:F5:24:CB:20:F1:FE:AD:89:00:6F:7F:58:6A:28:5B:2D:5B S 13:31:F4:8A:5D:A8:E0:1D:AA:CA:1B:B0:C1:70:44:AC:FE:F7:55:BB S 2F:17:3F:7D:E9:96:67:AF:A5:7A:F8:0A:A2:D1:B1:2F:AC:83:03:38 S 74:CD:D2:1C:2F:1D:10:4F:89:40:DF:FE:7E:6F:03:57:56:E2:F5:D0 S A3:99:F7:6F:0C:BF:4C:9D:A5:5E:4A:C2:4E:89:60:98:4B:29:05:B6 S D2:9F:6C:98:BE:FC:6D:98:65:21:54:3E:E8:BE:56:CE:BC:28:8C:F3 S 9F:C7:96:E8:F8:52:4F:86:3A:E1:49:6D:38:12:42:10:5F:1B:78:F5 S 83:8E:30:F7:7F:DD:14:AA:38:5E:D1:45:00:9C:0E:22:36:49:4F:AA S 72:0F:C1:5D:DC:27:D4:56:D0:98:FA:BF:3C:DD:78:D3:1E:F5:A8:DA S 7C:A0:4F:D8:06:4C:1C:AA:32:A3:7A:A9:43:75:03:8E:8D:F8:DD:C0 S 4B:A7:B9:DD:D6:87:88:E1:2F:F8:52:E1:A0:24:20:4B:F2:86:A8:F6 S 4E:F2:E6:67:0A:C9:B5:09:1F:E0:6B:E0:E5:48:3E:AA:D6:BA:32:D9 S 24:BA:6D:6C:8A:5B:58:37:A4:8D:B5:FA:E9:19:EA:67:5C:94:D2:17 S 68:7E:C1:7E:06:02:E3:CD:3F:7D:FB:D7:E2:8D:57:A0:19:9A:3F:44 S 7A:C5:FF:F8:DC:BC:55:83:17:68:77:07:3B:F7:51:73:5E:9B:D3:58 S 5E:99:7C:A5:94:5A:AB:75:FF:D1:48:04:A9:74:BF:2A:E1:DF:E7:E1 S F8:80:15:D3:F9:84:79:E1:DA:55:3D:24:FD:42:BA:3F:43:88:6A:EF S 47:AF:B9:15:CD:A2:6D:82:46:7B:97:FA:42:91:44:68:72:61:38:DD S 9B:AC:F3:B6:64:EA:C5:A1:7B:ED:08:43:7C:72:E4:AC:DA:12:F7:E7 S 68:ED:18:B3:09:CD:52:91:C0:D3:35:7C:1D:11:41:BF:88:38:66:B1 S 7A:74:41:0F:B0:CD:5C:97:2A:36:4B:71:BF:03:1D:88:A6:51:0E:9E S A3:E3:1E:20:B2:E4:6A:32:85:20:47:2D:0C:DE:95:23:E7:26:0C:6D S EF:2D:AC:CB:EA:BB:68:2D:32:CE:4A:BD:6C:B9:00:25:23:6C:07:BC S B6:AF:5B:E5:F8:78:A0:01:14:C3:D7:FE:F8:C7:75:C3:4C:CD:17:B6 S 90:78:C5:A2:8F:9A:43:25:C2:A7:C7:38:13:CD:FE:13:C2:0F:93:4E S CF:DE:FE:10:2F:DA:05:BB:E4:C7:8D:2E:44:23:58:90:05:B2:57:1D S EC:0C:37:16:EA:9E:DF:AD:D3:5D:FB:D5:56:08:E6:0A:05:D3:CB:F3 S B7:2F:FF:92:D2:CE:43:DE:0A:8D:4C:54:8C:50:37:26:A8:1E:2B:93 S 67:EB:33:7B:68:4C:EB:0E:C2:B0:76:0A:B4:88:27:8C:DD:95:97:DD S 35:60:18:5D:83:DC:CB:B7:0E:BB:45:AD:1E:9B:F5:29:A8:16:05:62 S 90:DE:DE:9E:4C:4E:9F:6F:D8:86:17:57:9D:D3:91:BC:65:A6:89:64 S 2B:F6:57:ED:B2:90:08:AD:2E:76:C2:6F:D5:73:94:B8:6F:90:AC:34 S 3F:B8:1D:D2:5E:C1:CA:3F:3F:A9:1A:5C:22:7C:DC:31:40:78:80:4E S 20:C0:EA:AD:8A:C3:7B:B4:CE:AD:F0:AC:8E:24:E0:99:41:F6:49:EE S BE:97:AE:7F:C0:37:D2:CB:C5:F2:3B:EB:D3:2C:F5:07:74:C3:EF:FE S 27:FA:6B:C3:25:6D:4F:0F:6B:3D:F2:A5:B6:8A:83:0A:53:33:7F:45 S 4C:57:B2:D5:6B:94:C2:5F:F2:CA:4A:D1:A8:3D:A4:C0:6F:EE:5C:2C S From umq.461 at gmail.com Wed Oct 18 05:17:58 2006 From: umq.461 at gmail.com (Hirohisa Yamaguchi) Date: Wed Oct 18 07:21:22 2006 Subject: gpg2 handles 1024R keys incorrectly Message-ID: <86r6x6pb15.wl%umq@ueo.co.jp> Hi While I'm testing gpg2 (1.9.92) on FreeBSD/amd64. I got messages below a thousand times. gpg: packet(2) too short gpg: keyring_get_keyblock: read error: invalid packet gpg: keydb_get_keyblock failed: invalid keyring I removed pubring.gpg from ~/.gnupg and tried to rebuild it. while adding 1024R keys (e.g. 0x16F4CCE9 from sendmail.org) I got following $ gpg2 --verbose --recv-keys 0x16F4CCE9 gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! Warning: using insecure memory! gpg: requesting key 16F4CCE9 from hkp server subkeys.pgp.net Version: SKS 1.0.9 gpg: armor header: Sendmail Security gpg: pub 1024R/E9CCF416 1999-06-23 gpg: key E9CCF416: skipped user ID "Sendmail Security " gpg: key E9CCF416: no valid user IDs gpg: this may be caused by a missing self-signature gpg: Total number processed: 1 gpg: w/o user IDs: 1 The key id 16F4CCE9 is shown as E9CCF416. It seems that the byte-order was inverted somewhere. I have not encountered this problem other than 1024R keys. -- end Hirohisa Yamaguchi umq.461@gmail.com From patrick at mozilla-enigmail.org Wed Oct 18 08:39:42 2006 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Wed Oct 18 08:37:39 2006 Subject: gpg2 handles 1024R keys incorrectly In-Reply-To: <86r6x6pb15.wl%umq@ueo.co.jp> References: <86r6x6pb15.wl%umq@ueo.co.jp> Message-ID: <4535CC2E.1090108@mozilla-enigmail.org> Hirohisa Yamaguchi wrote: > Hi > > While I'm testing gpg2 (1.9.92) on FreeBSD/amd64. > I got messages below a thousand times. > > gpg: packet(2) too short > gpg: keyring_get_keyblock: read error: invalid packet > gpg: keydb_get_keyblock failed: invalid keyring > > > I removed pubring.gpg from ~/.gnupg and tried to rebuild it. > > while adding 1024R keys (e.g. 0x16F4CCE9 from sendmail.org) > I got following > > $ gpg2 --verbose --recv-keys 0x16F4CCE9 > gpg: NOTE: THIS IS A DEVELOPMENT VERSION! > gpg: It is only intended for test purposes and should NOT be > gpg: used in a production environment or with production keys! > Warning: using insecure memory! > gpg: requesting key 16F4CCE9 from hkp server subkeys.pgp.net > Version: SKS 1.0.9 > gpg: armor header: > Sendmail Security > gpg: pub 1024R/E9CCF416 1999-06-23 > gpg: key E9CCF416: skipped user ID "Sendmail Security " > gpg: key E9CCF416: no valid user IDs > gpg: this may be caused by a missing self-signature > gpg: Total number processed: 1 > gpg: w/o user IDs: 1 I can confirm this (also with 2048R keys). E.g. import David's old key with gpg (v1.4) and then list it with gpg2: gpg2 --list-key 0x3CB3B415 gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: error reading key: No public key -Patrick From ueno at unixuser.org Wed Oct 18 12:07:48 2006 From: ueno at unixuser.org (Daiki Ueno) Date: Wed Oct 18 14:21:58 2006 Subject: [GPGME] statefulness of gpgme_op_keylist_* Message-ID: <3377d31f-3f1c-4026-8949-8be5ac91dd6d@well-done.deisui.org> Hi, As gpgme_op_keylist_* are expected to be called in certain order, and gpgme_op_delete resets the opdata, the following code dumps core on 1. gpgme_new (&ctx); gpgme_op_keylist_start (ctx, NULL, 0); gpgme_op_keylist_next (ctx, &key); gpgme_op_delete (ctx, key); gpgme_op_keylist_next (ctx, &key); /* 1 */ Program terminated with signal 11, Segmentation fault. #0 gpgme_op_keylist_next (ctx=0x804a030, r_key=0xbf867974) at keylist.c:887 887 if (!opd->key_queue) (gdb) where #0 gpgme_op_keylist_next (ctx=0x804a030, r_key=0xbf867974) at keylist.c:887 #1 0x0804866e in main () at test-keylist-next.c:28 Though this behavior might be intentional, may I request to change it to return an error (possibly GPG_ERR_INV_STATE?) on 1 rather than SEGV? Regards, -- Daiki Ueno From moerv at gmx.de Wed Oct 18 13:15:57 2006 From: moerv at gmx.de (riseX) Date: Wed Oct 18 14:56:55 2006 Subject: Get Key from OpenPGP-Card in Java for en-/decrytion Message-ID: <6873981.post@talk.nabble.com> Hello, I'm new in working with GnuPG and i've wrote a program in Java which encrypt and decrypt files. But only with public and private Keys which are still on my computer. Now i want that at every en- and decryption the program take the keys from the Card in the Card-Reader. The CardReader and the access to the card are still working. Should I save the public or the private key on the card? ... However I'm new in working with that and I hope you can help me Sorry because of my bad english. bye riseX -- View this message in context: http://www.nabble.com/Get-Key-from-OpenPGP-Card-in-Java-for-en--decrytion-tf2465898.html#a6873981 Sent from the GnuPG - Dev mailing list archive at Nabble.com. From rdieter at math.unl.edu Wed Oct 18 16:03:18 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed Oct 18 16:02:10 2006 Subject: libassuan-0.9.3: libassuan.m4 bugs/typos Message-ID: It appears the libassuan.m4 contained in libassuan-0.9.3 has a couple other small bugs/typos. Please review the attached patch. -- Rex -------------- next part -------------- A non-text attachment was scrubbed... Name: libassuan-more-m4.patch Type: text/x-diff Size: 908 bytes Desc: not available Url : /pipermail/attachments/20061018/4f1b3f20/libassuan-more-m4.bin From wk at gnupg.org Wed Oct 18 16:07:33 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 18 16:12:42 2006 Subject: GnuPG 1.9.92 -- first findings In-Reply-To: <4533CA53.8060406@mozilla-enigmail.org> (Patrick Brunschwig's message of "Mon\, 16 Oct 2006 20\:07\:15 +0200") References: <45333230.5030009@mozilla-enigmail.org> <87iriktpmh.fsf@wheatstone.g10code.de> <4533CA53.8060406@mozilla-enigmail.org> Message-ID: <87lknd3efu.fsf@wheatstone.g10code.de> On Mon, 16 Oct 2006 20:07, Patrick Brunschwig said: > I could reproduce it on the command line without Enigmail. I believe > it's related to my keyring; using just a subset of the keyring, > everything works fine. On the other hand I don't have the same issue > with gpg 1.4.5. Thanks for stripping it down to one key. The culprit was a 16384 bit RSA key (Pretty please, don't use such keys at all. They actually reduce security because you are bothering people with long verification and encryption times. Eventually they will stop using encryption at all.). Of course gpg should have properly detect that and tell this error. It used to write only parts of the key and thus reading later stopped. The reason why it fails only in gpg2 is due to the use of libgcrypt with a slightly different API. With the fixes you would see: gpg: mpi too large (16380 bits) gpg: build_packet(2) failed: Provided object is too large gpg: error writing keyring [..]/pubring.gpg': Provided object is too large gpg: key xxxxxxxx: public key "[User ID not found]" imported gpg: error reading `xxxxxxx-pub.gpg': Provided object is too large gpg: import from `xxxxxxxxx-pub.gpg' failed: Provided object is too large However we allow reading 16384 bit keys, so I changed the writing limit calculation in that such a key will actually work. 2006-10-18 Werner Koch * build-packet.c (do_public_key): Care about mpi_write errors. (do_secret_key, do_pubkey_enc, do_signature): Ditto. (mpi_write): Print an extra warning on error. The fix is in the SVN. A new release will follow ASAP. Salam-Shalom, Werner From wk at gnupg.org Wed Oct 18 16:13:37 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 18 16:17:40 2006 Subject: [GPGME] statefulness of gpgme_op_keylist_* In-Reply-To: <3377d31f-3f1c-4026-8949-8be5ac91dd6d@well-done.deisui.org> (Daiki Ueno's message of "Wed\, 18 Oct 2006 19\:07\:48 +0900") References: <3377d31f-3f1c-4026-8949-8be5ac91dd6d@well-done.deisui.org> Message-ID: <87hcy13e5q.fsf@wheatstone.g10code.de> On Wed, 18 Oct 2006 12:07, Daiki Ueno said: > Though this behavior might be intentional, may I request to change it to > return an error (possibly GPG_ERR_INV_STATE?) on 1 rather than SEGV? Sure. http://bugs.gnupg.org/715 Shalom-Salam, Werner From wk at gnupg.org Wed Oct 18 17:04:11 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 18 17:07:44 2006 Subject: gpg2 handles 1024R keys incorrectly In-Reply-To: <86r6x6pb15.wl%umq@ueo.co.jp> (Hirohisa Yamaguchi's message of "Wed\, 18 Oct 2006 12\:17\:58 +0900") References: <86r6x6pb15.wl%umq@ueo.co.jp> Message-ID: <8764eh3btg.fsf@wheatstone.g10code.de> On Wed, 18 Oct 2006 05:17, Hirohisa Yamaguchi said: > The key id 16F4CCE9 is shown as E9CCF416. > It seems that the byte-order was inverted somewhere. Fixed in SVN 4306. 2006-10-18 Werner Koch * keyid.c (v3_keyid): Don't use mempcy as we need to hold the keyids in the native endian format. Shalom-Salam, Werner From wk at gnupg.org Wed Oct 18 17:11:18 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 18 17:17:39 2006 Subject: Problem with email addresses beginning with 0x In-Reply-To: <451C8019.9090302@gmail.com> (Luke J.'s message of "Fri\, 29 Sep 2006 03\:08\:25 +0100") References: <451C8019.9090302@gmail.com> Message-ID: <87zmbt1wx5.fsf@wheatstone.g10code.de> On Fri, 29 Sep 2006 04:08, Luke J said: > gpg: skipped "0xlukej@gmail.com": malformed user id > gpg: signing failed: malformed user id Use <0xlukej@gmail.com> To indicate that it is an email address. Take care of shell quoting rules. From the manual: @item By exact match on an email address. This is indicated by enclosing the email address in the usual way with left and right angles. @cartouche @example @end example @end cartouche Salam-Shalom, Werner From wk at gnupg.org Wed Oct 18 17:45:19 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 18 17:52:58 2006 Subject: libassuan-0.9.3: libassuan.m4 bugs/typos In-Reply-To: (Rex Dieter's message of "Wed\, 18 Oct 2006 09\:03\:18 -0500") References: Message-ID: <87slhl1vcg.fsf@wheatstone.g10code.de> On Wed, 18 Oct 2006 16:03, Rex Dieter said: > It appears the libassuan.m4 contained in libassuan-0.9.3 has a couple other > small bugs/typos. Please review the attached patch. Thanks, Werner From alguibert+gpd at free.fr Wed Oct 18 16:52:10 2006 From: alguibert+gpd at free.fr (Alain Guibert) Date: Wed Oct 18 18:18:43 2006 Subject: GnuPG 1.9.92 build failures on old Linux In-Reply-To: <87bqohzgvr.fsf@wheatstone.g10code.de> References: <20061011181803.GB21795@free.fr> <87bqohzgvr.fsf@wheatstone.g10code.de> Message-ID: <20061018145209.GA12867@free.fr> Hello Werner, On Thursday, October 12, 2006 at 17:35:36 +0200, Werner Koch wrote: > On Wed, 11 Oct 2006 20:18, Alain Guibert said: >>| watchgnupg.c:227: `socklen_t' undeclared (first use this function) > Well the usual socklen_t problem. Will include a test to configure. Checking gnupg SVN trunk revision 4304, all my other problems are fixed, outside of this socklen_t one. Thank you again. Additionally I had two minor problems when doing ./autogen.sh on this old Linux: | sh: (svn info 2>/dev/null || echo 'Revision: 0')|sed -n '/^Revision:/ {s/[^0-9]//gp;q}': bad arithmetic substitution And: | sed: -e expression #1, char 29: Extra characters after command Both problems come from configure.ac line 33 and 34: | m4_define([svn_revision], m4_esyscmd([echo -n $((svn info 2>/dev/null \ | || echo 'Revision: 0')|sed -n '/^Revision:/ {s/[^0-9]//gp;q}')])) First problem is that some bash versions (at least 2.0.0) wrongly take "$((" as beginning an arithmetic substitution, and that fails. A space between opening parenthesis "$( (" fixes it. Second problem is that some sed versions (at least 2.05 and 3.02) dislike grouped commands that do not end in ";". Inserting a semicolon between "q" and "}" fixes it. I hope that such syntax does not break on more recent platforms: | m4_define([svn_revision], m4_esyscmd([echo -n $( (svn info 2>/dev/null \ | || echo 'Revision: 0')|sed -n '/^Revision:/ {s/[^0-9]//gp;q;}')])) Alain. -------------- next part -------------- Index: configure.ac =================================================================== --- configure.ac (revision 4304) +++ configure.ac (working copy) @@ -30,8 +30,8 @@ m4_define([my_issvn], [yes]) -m4_define([svn_revision], m4_esyscmd([echo -n $((svn info 2>/dev/null \ - || echo 'Revision: 0')|sed -n '/^Revision:/ {s/[^0-9]//gp;q}')])) +m4_define([svn_revision], m4_esyscmd([echo -n $( (svn info 2>/dev/null \ + || echo 'Revision: 0')|sed -n '/^Revision:/ {s/[^0-9]//gp;q;}')])) AC_INIT([gnupg], my_version[]m4_if(my_issvn,[yes],[-svn[]svn_revision]), [bug-gnupg@gnupg.org]) # Set development_version to yes if the minor number is odd or you From wk at gnupg.org Wed Oct 18 19:18:09 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 18 19:21:33 2006 Subject: [Announce] GnuPG 1.9.93 released Message-ID: <87k62x1r1q.fsf@wheatstone.g10code.de> Hi, as promised here is another release of GnuPG. This is mainly to fix bugs found in 1.9.92. Thanks to all testers. Noteworthy changes in version 1.9.93 (2006-10-18) ------------------------------------------------- * In --with-validation mode gpgsm will now also ask whether a root certificate should be trusted. * Link to Pth only if really necessary. * Fixed a pubring corruption bug in gpg2 occurring when importing signatures or keys with insane lengths. * Fixed v3 keyID calculation bug in gpg2. * More tweaks for certificates without extensions. Available at the usual place: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.93.tar.bz2 (3772k) ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.93.tar.bz2.sig or as a patch (without PO file updates): ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.92-1.9.93.diff.bz2 (30k) BTW, the logo-contest is still running and the submitters would probably like to see some more donations ;-). See www.gnupg.org/misc/logo-contest.html . Shalom-Salam, Werner -- Werner Koch The GnuPG Experts http://g10code.com Join the Fellowship and protect your Freedom! http://www.fsfe.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20061018/541c8c2c/attachment.pgp From wk at gnupg.org Wed Oct 18 19:28:09 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Oct 18 19:32:45 2006 Subject: GnuPG 1.9.92 build failures on old Linux In-Reply-To: <20061018145209.GA12867@free.fr> (Alain Guibert's message of "Wed\, 18 Oct 2006 16\:52\:10 +0200 \(CEST\)") References: <20061011181803.GB21795@free.fr> <87bqohzgvr.fsf@wheatstone.g10code.de> <20061018145209.GA12867@free.fr> Message-ID: <87fydl1ql2.fsf@wheatstone.g10code.de> On Wed, 18 Oct 2006 16:52, Alain Guibert said: > First problem is that some bash versions (at least 2.0.0) wrongly take > "$((" as beginning an arithmetic substitution, and that fails. A space > between opening parenthesis "$( (" fixes it. Fixed in SVN. > Second problem is that some sed versions (at least 2.05 and 3.02) > dislike grouped commands that do not end in ";". Inserting a semicolon > between "q" and "}" fixes it. > > I hope that such syntax does not break on more recent platforms: Fixed. It may only break for those building form SVN ;-). Thanks, Werner From ariga at os.rim.or.jp Thu Oct 19 05:17:59 2006 From: ariga at os.rim.or.jp (ARIGA Seiji) Date: Thu Oct 19 05:16:19 2006 Subject: memrchr is missing ? (was Re: [Announce] GnuPG 1.9.93 released) In-Reply-To: <87k62x1r1q.fsf@wheatstone.g10code.de> References: <87k62x1r1q.fsf@wheatstone.g10code.de> Message-ID: <20061019.121759.12118322.say@khaotic.net> On Wed, 18 Oct 2006 19:18:09 +0200, Werner Koch wrote, > as promised here is another release of GnuPG. This is mainly to fix > bugs found in 1.9.92. Thanks to all testers. it seems to me that memrchr() is missing on platform where standard library doesn't have it. // ARIGA Seiji From patrick at mozilla-enigmail.org Thu Oct 19 08:54:03 2006 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Thu Oct 19 08:52:09 2006 Subject: GnuPG 1.9.93 Key Generation with --btatch Message-ID: <4537210B.8040202@mozilla-enigmail.org> I found a small (documentation?) issue when generating a new key with --batch. According to the DETAILS file, the subkey type for an Elgamal key can be specified with this line (like in gpg 1.2.x and 1.4.x): Subkey-Type: ELG-E But doing so, results in the following error message: gpg: -:3: invalid algorithm Instead it seems that "Subkey-Type: ELG" (or "Subkey-Type: 16") work OK. -Patrick From patrick at mozilla-enigmail.org Thu Oct 19 09:49:59 2006 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Thu Oct 19 09:48:01 2006 Subject: gpg 1.9.93 -- wrong use of gpg-agent Message-ID: <45372E27.2060504@mozilla-enigmail.org> I think there's definitely something wrong with using gpg-agent in gpg2. It seems that I'm unable to provide the passphrase via --command-fd, gpg2 always calls the gpg-agent, even if I explicitly disable this. # gpg2 -v -v --batch --no-use-agent --charset utf8 --no-tty \ --status-fd 1 --logger-fd 1 --command-fd 0 --ask-cert-level \ --edit-key 412D23A373B467E0 gpg: using classic trust model gpg: key CCEC227B: accepted as trusted key gpg: key 73B467E0: accepted as trusted key [GNUPG:] GET_LINE keyedit.prompt passwd [GNUPG:] GOT_IT [GNUPG:] USERID_HINT 412D23A373B467E0 enigmail [GNUPG:] NEED_PASSPHRASE 412D23A373B467E0 412D23A373B467E0 17 0 gpg: no running gpg-agent - starting one gpg: DBG: connection to agent established cant lock memory: Cannot allocate memory Warning: using insecure memory! gpg-agent[2954]: command get_passphrase failed: Operation cancelled gpg: cancelled by user [GNUPG:] MISSING_PASSPHRASE This is my gpg.conf file (it's also interesting that the "no-secmem-warning" entry is disregarded): no-secmem-warning keyserver hkp://subkeys.pgp.net -Patrick From wk at gnupg.org Thu Oct 19 10:25:44 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Oct 19 10:32:46 2006 Subject: memrchr is missing ? In-Reply-To: <20061019.121759.12118322.say@khaotic.net> (ARIGA Seiji's message of "Thu\, 19 Oct 2006 12\:17\:59 +0900 \(JST\)") References: <87k62x1r1q.fsf@wheatstone.g10code.de> <20061019.121759.12118322.say@khaotic.net> Message-ID: <87wt6wzp87.fsf@wheatstone.g10code.de> On Thu, 19 Oct 2006 05:17, ARIGA Seiji said: > it seems to me that memrchr() is missing on platform where standard > library doesn't have it. Right. Here is an untested fix: 2006-10-19 Werner Koch * stringhelp.c (memrchr) [!HAVE_MEMRCHR]: Provide a replacement. * mischelp.c: New. Index: jnlib/stringhelp.c =================================================================== --- jnlib/stringhelp.c (revision 4307) +++ jnlib/stringhelp.c (working copy) @@ -796,3 +796,15 @@ #endif +#ifndef HAVE_MEMRCHR +void * +memrchr (const void *buffer, int c, size_t n) +{ + const unsigned char *p = buffer; + + for (p += n; n ; n--) + if (*--p == c) + return p; + return NULL; +} +#endif /*HAVE_MEMRCHR*/ Index: jnlib/stringhelp.h =================================================================== --- jnlib/stringhelp.h (revision 4307) +++ jnlib/stringhelp.h (working copy) @@ -95,7 +95,11 @@ #ifndef HAVE_STRICMP # define stricmp(a,b) strcasecmp( (a), (b) ) #endif +#ifndef HAVE_MEMRCHR +void *memrchr (const void *buffer, int c, size_t n); +#endif + #ifndef HAVE_ISASCII static inline int isascii (int c) From wk at gnupg.org Thu Oct 19 10:38:03 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Oct 19 10:42:43 2006 Subject: GnuPG 1.9.93 Key Generation with --btatch In-Reply-To: <4537210B.8040202@mozilla-enigmail.org> (Patrick Brunschwig's message of "Thu\, 19 Oct 2006 08\:54\:03 +0200") References: <4537210B.8040202@mozilla-enigmail.org> Message-ID: <87slhkzono.fsf@wheatstone.g10code.de> On Thu, 19 Oct 2006 08:54, Patrick Brunschwig said: > But doing so, results in the following error message: > gpg: -:3: invalid algorithm > > Instead it seems that "Subkey-Type: ELG" (or "Subkey-Type: 16") work OK. I have added a special case for ELG-E. You better use 16 as this will work with all versions of gpg. Salam-Shalom, Werner From wk at gnupg.org Thu Oct 19 12:21:38 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Oct 19 12:28:25 2006 Subject: gpg 1.9.93 -- wrong use of gpg-agent In-Reply-To: <45372E27.2060504@mozilla-enigmail.org> (Patrick Brunschwig's message of "Thu\, 19 Oct 2006 09\:49\:59 +0200") References: <45372E27.2060504@mozilla-enigmail.org> Message-ID: <87ods8zjv1.fsf@wheatstone.g10code.de> On Thu, 19 Oct 2006 09:49, Patrick Brunschwig said: > I think there's definitely something wrong with using gpg-agent in gpg2. > It seems that I'm unable to provide the passphrase via --command-fd, > gpg2 always calls the gpg-agent, even if I explicitly disable this. That is intended. The plan is to move all secret key oeprations to gpg-agent and thus gpg2 won't need a passphrase at all. As of now we use the agent only for passphrase caching. To prepare for the real change, gpg-agent is now required and --no-use-agent is a dummy option. The reason why --passphrase-fd still works is for using gpg2 with symmetric keys taken out of a database or similar. > This is my gpg.conf file (it's also interesting that the > "no-secmem-warning" entry is disregarded): I can't replicate that. However this is done in libgcrypt and you might have an older one. --require-secmem didn't worked either. I just fixed that but unfortunately this needs a libgcrypt update to work. Shalom-Salam, Werner From patrick at mozilla-enigmail.org Thu Oct 19 17:55:58 2006 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Thu Oct 19 17:54:14 2006 Subject: gpg 1.9.93 -- wrong use of gpg-agent In-Reply-To: <87ods8zjv1.fsf@wheatstone.g10code.de> References: <45372E27.2060504@mozilla-enigmail.org> <87ods8zjv1.fsf@wheatstone.g10code.de> Message-ID: <4537A00E.4070306@mozilla-enigmail.org> Werner Koch wrote: > On Thu, 19 Oct 2006 09:49, Patrick Brunschwig said: > >> I think there's definitely something wrong with using gpg-agent in gpg2. >> It seems that I'm unable to provide the passphrase via --command-fd, >> gpg2 always calls the gpg-agent, even if I explicitly disable this. > > That is intended. The plan is to move all secret key oeprations to > gpg-agent and thus gpg2 won't need a passphrase at all. As of now we > use the agent only for passphrase caching. To prepare for the real > change, gpg-agent is now required and --no-use-agent is a dummy > option. The reason why --passphrase-fd still works is for using gpg2 > with symmetric keys taken out of a database or similar. I see. So if I get you right, then I should disable any kind of passphrase management if I detect gpg2, just like if a user configured manually the use of gpg-agent (on all platforms, including Windows). -Patrick From wk at gnupg.org Thu Oct 19 17:58:19 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Oct 19 18:02:46 2006 Subject: gpg 1.9.93 -- wrong use of gpg-agent In-Reply-To: <4537A00E.4070306@mozilla-enigmail.org> (Patrick Brunschwig's message of "Thu\, 19 Oct 2006 17\:55\:58 +0200") References: <45372E27.2060504@mozilla-enigmail.org> <87ods8zjv1.fsf@wheatstone.g10code.de> <4537A00E.4070306@mozilla-enigmail.org> Message-ID: <87y7rcxppg.fsf@wheatstone.g10code.de> On Thu, 19 Oct 2006 17:55, Patrick Brunschwig said: > I see. So if I get you right, then I should disable any kind of > passphrase management if I detect gpg2, just like if a user configured > manually the use of gpg-agent (on all platforms, including Windows). Yes. There is no Widnows version yet but we might start to work on it next year. Shalom-Salam, Werner From ueno at unixuser.org Fri Oct 20 04:57:16 2006 From: ueno at unixuser.org (Daiki Ueno) Date: Fri Oct 20 04:55:52 2006 Subject: [GPGME] gpgme_wait causes an assertion failure on successful operation Message-ID: <67cae95c-1813-4988-b4e8-013ec08a834b@well-done.deisui.org> Hi, It seems that ./tests/gpg/t-wait which expects an error GPG_ERR_NO_DATA is only example of gpgme_wait. I tried to make it to expect an successful operation, then I got an assertion failure. $ ./t-wait lt-t-wait: ath.c:71: _gpgme_ath_mutex_lock: Assertion `*lock == ((ath_mutex_t) 0)' failed. zsh: abort ./t-wait t-wait is not linked against any thread libraries. $ libtool --mode=execute ldd t-wait linux-gate.so.1 => (0xffffe000) libgpgme.so.11 => /home/ueno/gpgme1.0-1.1.2/gpgme/.libs/libgpgme.so.11 (0xb7f64000) libc.so.6 => /lib/tls/libc.so.6 (0xb7e1c000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb7e18000) /lib/ld-linux.so.2 (0xb7f88000) Did I missed something? Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: t-wait.c.diff Type: application/octet-stream Size: 1307 bytes Desc: not available Url : /pipermail/attachments/20061020/49487c28/t-wait.c.obj From jmoore3rd at bellsouth.net Fri Oct 20 06:27:41 2006 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Fri Oct 20 06:26:51 2006 Subject: svn4310 Message-ID: <4538503D.4030102@bellsouth.net> Building for M$ using MSYS/MingW: checking for strsep.........no and the Compile fails with: make[1]: Entering directory `/home/Compaq_Owner/4310/g10' gcc -g -O2 -march=i386 -mfpmath=387 -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-3dnow -Wall -s -static -o gpg.exe gpg.o build-packet.o compress.o compress-bz2.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-packet.o status.o plaintext.o sig-check.o keylist.o signal.o cardglue.o tlv.o card-util.o app-openpgp.o iso7816.o apdu.o ccid-driver.o pkclist.o skclist.o pubkey-enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdbio.o delkey.o keygen.o pipemode.o helptext.o keyserver.o photoid.o exec.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a -lz -lbz2 -lwsock32 gpg.o: In function `main': F:/msys/home/Compaq_Owner/4310/g10/gpg.c:1732: undefined reference to `S2K_DECODE_COUNT' make[1]: *** [gpg.exe] Error 1 make[1]: Leaving directory `/home/Compaq_Owner/4310/g10' make: *** [check-recursive] Error 1 Since is the same point at which the Compile failed earlier I am wondering if there is something precluding it from building on Windows? Now, in all fairness; When Compiling without /any/ Modifications the seat.test FAILs: Home: . Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 PASS: version.test PASS: mds.test PASS: decrypt.test PASS: decrypt-dsa.test PASS: sigs.test PASS: sigs-dsa.test PASS: encrypt.test PASS: encrypt-dsa.test plain-1 y differ: char 60, line 1 seat.test: plain-1: mismatch FAIL: seat.test PASS: clearsig.test PASS: encryptp.test PASS: detach.test PASS: armsigs.test PASS: armencrypt.test PASS: armencryptp.test PASS: signencrypt.test PASS: signencrypt-dsa.test PASS: armsignencrypt.test PASS: armdetach.test PASS: armdetachm.test PASS: detachm.test PASS: genkey1024.test PASS: conventional.test PASS: conventional-mdc.test PASS: multisig.test PASS: verify.test PASS: armor.test ================================== 1 of 27 tests failed Please report to bug-gnupg@gnu.org ================================== JOHN :-\ Timestamp: Friday 20 Oct 2006, 00:27 --400 (Eastern Daylight Time) From JPClizbe at comcast.net Fri Oct 20 08:01:29 2006 From: JPClizbe at comcast.net (John Clizbe) Date: Fri Oct 20 08:00:25 2006 Subject: svn4310 In-Reply-To: <4538503D.4030102@bellsouth.net> References: <4538503D.4030102@bellsouth.net> Message-ID: <45386639.4030406@comcast.net> John W. Moore III wrote: > Building for M$ using MSYS/MingW: > > checking for strsep.........no checking for strsep... (cached) no deleted config.cache and reran configure: checking for strsep... no > and the Compile fails with: > > gpg.o: In function `main': > F:/msys/home/Compaq_Owner/4310/g10/gpg.c:1732: undefined reference to > `S2K_DECODE_COUNT' > make[1]: *** [gpg.exe] Error 1 > make[1]: Leaving directory `/home/Compaq_Owner/4310/g10' > make: *** [check-recursive] Error 1 > > > Since is the same point at which the Compile failed earlier I am > wondering if there is something precluding it from building on Windows? Works/worked for me. What are you doing in your build environment outside of checkout, autogen, configure & make? > Now, in all fairness; When Compiling without /any/ Modifications the > seat.test FAILs: > > plain-1 y differ: char 60, line 1 > seat.test: plain-1: mismatch > FAIL: seat.test "> Now, in all fairness;" it's a long documented build behavior under MSYS/MinGW. See Carlo Bianco's Build page. Here's the patch: >>>> --- checks/seat.test~ Tue May 31 01:29:54 2005 +++ checks/seat.test Fri Aug 12 21:37:51 2005 @@ -6,6 +6,7 @@ echo "$usrpass1" | $GPG --passphrase-fd 0 --always-trust -seat \ -r two -o x --yes $i $GPG -o y --yes x - cmp $i y || error "$i: mismatch" + unix2dos -c 7bit -n $i z + cmp z y || error "$i: mismatch" done <<<< -- John P. Clizbe Inet: JPClizbe(a)comcast DOT nyet Golden Bear Networks PGP/GPG KeyID: 0x608D2A10 "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 663 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20061020/3d935c97/signature.pgp From wk at gnupg.org Fri Oct 20 11:14:22 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Oct 20 11:17:50 2006 Subject: Cryptoflex 32K support patch In-Reply-To: <20060905085014.GA9651@xyzzy.org.uk> (Bob Dunlop's message of "Tue\, 5 Sep 2006 09\:50\:14 +0100") References: <20060905085014.GA9651@xyzzy.org.uk> Message-ID: <873b9jxsb5.fsf@wheatstone.g10code.de> On Tue, 5 Sep 2006 10:50, Bob Dunlop said: > I've been trying to use a new Cryptoflex 32K card (sold as a Cryptoflex > for Windows card) working with GnuPG under Gentoo linux. The resultant > patch to the scd directory below works for me. Sorry, we won't add support for a specific card. We want to stick to the ISO-7816 standard. If this is about a specific application as used with that card, an app-foo.c modules needs to be written. As soon as 2k RSA keys are more widespread support for extended Lc and Le will be added. > All the code and changes are released under GPL2 although as I post this > I realise I've not added the statement to the new file cryptofex.h but > then again it might be better to merge this file with one of the existing > headers. For the record, we need copyright assignments to the FSF for all contributions. > Shalom-Salam, Werner From bob at xyzzy.org.uk Fri Oct 20 14:37:11 2006 From: bob at xyzzy.org.uk (Bob Dunlop) Date: Fri Oct 20 14:35:46 2006 Subject: Cryptoflex 32K support patch In-Reply-To: <873b9jxsb5.fsf@wheatstone.g10code.de> References: <20060905085014.GA9651@xyzzy.org.uk> <873b9jxsb5.fsf@wheatstone.g10code.de> Message-ID: <20061020123711.GA25334@xyzzy.org.uk> On Fri, Oct 20 at 11:14, Werner Koch wrote: > > Sorry, we won't add support for a specific card. We want to stick to > the ISO-7816 standard. If this is about a specific application as > used with that card, an app-foo.c modules needs to be written. Well thankyou for looking at it. Fortunatly I've already found a better path for supporting this card. The recently announced gnupg-pkcs11 project provides support for the Cryptoflex card via OpenSC and I won't have to maintain my own GnuPG patches. -- Bob Dunlop From marcus.brinkmann at ruhr-uni-bochum.de Mon Oct 23 20:29:47 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Oct 23 20:24:29 2006 Subject: [GPGME] gpgme_wait causes an assertion failure on successful operation In-Reply-To: <67cae95c-1813-4988-b4e8-013ec08a834b@well-done.deisui.org> References: <67cae95c-1813-4988-b4e8-013ec08a834b@well-done.deisui.org> Message-ID: <87slheans4.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Fri, 20 Oct 2006 11:57:16 +0900, Daiki Ueno wrote: > > [1 ] > Hi, > > It seems that ./tests/gpg/t-wait which expects an error GPG_ERR_NO_DATA > is only example of gpgme_wait. I tried to make it to expect an > successful operation, then I got an assertion failure. Thanks for reporting this. The active context list lock needs to be released while signaling the DONE event. I have applied a fix for that in revision 1184 which is not very efficient, but it should be OK for now. 2006-10-23 Marcus Brinkmann * wait-global.c (gpgme_wait): Unlock CTX_LIST_LOCK while calling _gpgme_engine_io_event(). Thanks, Marcus From ueno at unixuser.org Tue Oct 24 04:52:34 2006 From: ueno at unixuser.org (Daiki Ueno) Date: Tue Oct 24 04:50:52 2006 Subject: [GPGME] gpgme_wait causes an assertion failure on successful operation In-Reply-To: <87slheans4.wl%marcus.brinkmann@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "Mon, 23 Oct 2006 20:29:47 +0200") References: <67cae95c-1813-4988-b4e8-013ec08a834b@well-done.deisui.org> <87slheans4.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: >>>>> In <87slheans4.wl%marcus.brinkmann@ruhr-uni-bochum.de> >>>>> Marcus Brinkmann wrote: > > It seems that ./tests/gpg/t-wait which expects an error GPG_ERR_NO_DATA > > is only example of gpgme_wait. I tried to make it to expect an > > successful operation, then I got an assertion failure. > Thanks for reporting this. The active context list lock needs to be > released while signaling the DONE event. I have applied a fix for > that in revision 1184 which is not very efficient, but it should be OK > for now. > 2006-10-23 Marcus Brinkmann > * wait-global.c (gpgme_wait): Unlock CTX_LIST_LOCK while calling > _gpgme_engine_io_event(). I confirmed it. Thanks! Regards, -- Daiki Ueno From ueno at unixuser.org Tue Oct 24 05:56:38 2006 From: ueno at unixuser.org (Daiki Ueno) Date: Tue Oct 24 05:55:19 2006 Subject: [GPGME] statefulness of gpgme_op_keylist_* In-Reply-To: <87hcy13e5q.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 18 Oct 2006 16:13:37 +0200") References: <3377d31f-3f1c-4026-8949-8be5ac91dd6d@well-done.deisui.org> <87hcy13e5q.fsf@wheatstone.g10code.de> Message-ID: <6d4185b5-26c8-46fb-bb52-2973dd7d9b94@well-done.deisui.org> >>>>> In <87hcy13e5q.fsf@wheatstone.g10code.de> >>>>> Werner Koch wrote: > > Though this behavior might be intentional, may I request to change it to > > return an error (possibly GPG_ERR_INV_STATE?) on 1 rather than SEGV? > Sure. http://bugs.gnupg.org/715 I confirmed Marcus' fix of this issue. Thanks. https://bugs.g10code.com/gnupg/msg1794 By the way, a similar change would be needed for trustlist_next? Regards, -- Daiki Ueno From marcus.brinkmann at ruhr-uni-bochum.de Tue Oct 24 11:35:32 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue Oct 24 11:34:17 2006 Subject: [GPGME] statefulness of gpgme_op_keylist_* In-Reply-To: <6d4185b5-26c8-46fb-bb52-2973dd7d9b94@well-done.deisui.org> References: <3377d31f-3f1c-4026-8949-8be5ac91dd6d@well-done.deisui.org> <87hcy13e5q.fsf@wheatstone.g10code.de> <6d4185b5-26c8-46fb-bb52-2973dd7d9b94@well-done.deisui.org> Message-ID: <87r6wy9huj.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 24 Oct 2006 12:56:38 +0900, Daiki Ueno wrote: > > >>>>> In <87hcy13e5q.fsf@wheatstone.g10code.de> > >>>>> Werner Koch wrote: > > > Though this behavior might be intentional, may I request to change it to > > > return an error (possibly GPG_ERR_INV_STATE?) on 1 rather than SEGV? > > > Sure. http://bugs.gnupg.org/715 > > I confirmed Marcus' fix of this issue. Thanks. > https://bugs.g10code.com/gnupg/msg1794 > > By the way, a similar change would be needed for trustlist_next? Yes, applied. Thanks a lot for this. Marcus From wk at gnupg.org Tue Oct 24 16:45:03 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 24 16:48:31 2006 Subject: [Announce] GnuPG 1.9.94 released Message-ID: <87hcxt7oy8.fsf@wheatstone.g10code.de> Hi, as promised here is another release of GnuPG. This is mainly to fix bugs found in 1.9.93. Thanks to all testers. Noteworthy changes in version 1.9.94 (2006-10-24) ------------------------------------------------- * Keys for gpgsm may now be specified using a keygrip. A keygrip is indicated by a prefixing it with an ampersand. * gpgconf now supports switching the CMS cipher algo (e.g. to AES). * New command --gpgconf-test for all major tools. This may be used to check whether the configuration file is sane. Available at the usual place: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.94.tar.bz2 (3780k) ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.94.tar.bz2.sig or as a patch (without PO file updates): ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.93-1.9.94.diff.bz2 (19k) If you have a smart card (either OpenPGP or the Belgian eID), you may want to play with the enhanced gpgsm-gencert.sh tool. BTW, 7 days to go for the logo-contest. You may however donate until we have finished the selection. http://logo-contest.gnupg.org/ Shalom-Salam, Werner -- Werner Koch The GnuPG Experts http://g10code.com Join the Fellowship and protect your Freedom! http://www.fsfe.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 205 bytes Desc: not available Url : /pipermail/attachments/20061024/703e9fa2/attachment.pgp From nicholas.cole at gmail.com Tue Oct 24 20:38:45 2006 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Wed Oct 25 02:25:13 2006 Subject: [Announce] GnuPG 1.9.94 released In-Reply-To: <87hcxt7oy8.fsf@wheatstone.g10code.de> References: <87hcxt7oy8.fsf@wheatstone.g10code.de> Message-ID: > BTW, 7 days to go for the logo-contest. You may however donate until > we have finished the selection. http://logo-contest.gnupg.org/ I really like the one by Jeffrey F. Bloss. Colours might need a bit of work, but I love the concept. From j.lysdal at gmail.com Tue Oct 24 20:34:46 2006 From: j.lysdal at gmail.com (=?UTF-8?Q?J=C3=B8rgen_Lysdal?=) Date: Wed Oct 25 16:22:00 2006 Subject: [Announce] GnuPG 1.9.94 released In-Reply-To: <87hcxt7oy8.fsf@wheatstone.g10code.de> References: <87hcxt7oy8.fsf@wheatstone.g10code.de> Message-ID: <9afe34fe0610241134yde91fafu51b748d8a5a34cff@mail.gmail.com> Are there any version compiled for windows or do i have to do this myself? From JPClizbe at comcast.net Wed Oct 25 18:03:46 2006 From: JPClizbe at comcast.net (John Clizbe) Date: Wed Oct 25 18:09:28 2006 Subject: [Announce] GnuPG 1.9.94 released In-Reply-To: <9afe34fe0610241134yde91fafu51b748d8a5a34cff@mail.gmail.com> References: <87hcxt7oy8.fsf@wheatstone.g10code.de> <9afe34fe0610241134yde91fafu51b748d8a5a34cff@mail.gmail.com> Message-ID: <453F8AE2.1030404@comcast.net> J?rgen Lysdal wrote: > Are there any version compiled for windows or do i have to do this myself? Don't bother. Windows isn't supported (yet). -- John P. Clizbe Inet: JPClizbe(a)comcast DOT nyet Golden Bear Networks PGP/GPG KeyID: 0x608D2A10 "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 663 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20061025/230fdd84/signature.pgp From wk at gnupg.org Thu Oct 26 09:54:52 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Oct 26 10:19:58 2006 Subject: [Announce] GnuPG logo contest - 5 days to go Message-ID: <874ptrfr5f.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From nicholas.cole at gmail.com Fri Oct 27 18:20:00 2006 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri Oct 27 18:24:19 2006 Subject: RFC 2015 Message-ID: The RFC for PGP/MIME email specifies that the type of signature used must be specified as "pgp-md5" or "pgp-sha1" when creating signed-only messages. Is there an updated version now that the OpenPGP spec lets one use other alogorithms? Best wishes, N. From albrecht.dress at arcor.de Sat Oct 28 18:18:59 2006 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Sat Oct 28 19:55:13 2006 Subject: RFC 2015 In-Reply-To: (from nicholas.cole@gmail.com on Fri Oct 27 18:20:00 2006) References: Message-ID: <1162052347l.3152l.0l@antares.localdomain> Am 27.10.06 18:20 schrieb(en) Nicholas Cole: > The RFC for PGP/MIME email specifies that the type of signature used > must be specified as "pgp-md5" or "pgp-sha1" when creating signed-only > messages. > > Is there an updated version now that the OpenPGP spec lets one use > other alogorithms? RFC 2015 has been updated by RFC 3156 in 2001. Quoting from Sect. 5 "OpenPGP signed data": The "micalg" parameter for the "application/pgp-signature" protocol MUST contain exactly one hash-symbol of the format "pgp-", where identifies the Message Integrity Check (MIC) algorithm used to generate the signature. Hash-symbols are constructed from the text names registered in [1] or according to the mechanism defined in that document by converting the text name to lower case and prefixing it with the four characters "pgp-". Currently defined values are "pgp-md5", "pgp-sha1", "pgp-ripemd160", "pgp-md2", "pgp-tiger192", and "pgp-haval-5-160". Cheers, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de GnuPG public key: http://www.mynetcologne.de/~nc-dreszal/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20061028/ea73b6c9/attachment.pgp From dshaw at jabberwocky.com Sat Oct 28 20:14:17 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sat Oct 28 20:12:31 2006 Subject: RFC 2015 In-Reply-To: References: Message-ID: <20061028181417.GA5187@jabberwocky.com> On Fri, Oct 27, 2006 at 12:20:00PM -0400, Nicholas Cole wrote: > The RFC for PGP/MIME email specifies that the type of signature used > must be specified as "pgp-md5" or "pgp-sha1" when creating signed-only > messages. > > Is there an updated version now that the OpenPGP spec lets one use > other alogorithms? RFC 3156 is the new PGP/MIME spec. It basically defines pgp-* as tracking whatever is in RFC 2440 or later. Thus, you can feel free to use pgp-sha256, pgp-sha384, etc. David From nicholas.cole at gmail.com Sun Oct 29 17:29:26 2006 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sun Oct 29 17:27:55 2006 Subject: RFC 2015 In-Reply-To: <20061028181417.GA5187@jabberwocky.com> References: <20061028181417.GA5187@jabberwocky.com> Message-ID: On 10/28/06, David Shaw wrote: > On Fri, Oct 27, 2006 at 12:20:00PM -0400, Nicholas Cole wrote: > > The RFC for PGP/MIME email specifies that the type of signature used > > must be specified as "pgp-md5" or "pgp-sha1" when creating signed-only > > messages. > > > > Is there an updated version now that the OpenPGP spec lets one use > > other alogorithms? > > RFC 3156 is the new PGP/MIME spec. It basically defines pgp-* as > tracking whatever is in RFC 2440 or later. Thus, you can feel free to > use pgp-sha256, pgp-sha384, etc. Thanks both of you. I'd missed the new RFC. Apologies! N. From wk at gnupg.org Tue Oct 31 20:54:07 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Oct 31 21:28:55 2006 Subject: [Announce] libassuan 1.0.0 released Message-ID: <8764e0gt28.fsf@wheatstone.g10code.de> Skipped content of type multipart/signed-------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce