From patrick.brunschwig at gmx.net Tue Mar 1 10:17:48 2005 From: patrick.brunschwig at gmx.net (Patrick Brunschwig) Date: Tue Mar 1 11:14:17 2005 Subject: File renaming bug still in gpg 1.4.1rc2 on Windows In-Reply-To: <4222F130.2050506__35396.9102995054$1109590032$gmane$org@mozilla-enigmail.org> References: <4222F130.2050506__35396.9102995054$1109590032$gmane$org@mozilla-enigmail.org> Message-ID: <4224333C.7080700@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick Brunschwig wrote: > I just stumbled (again) across the file renaming bug on Windows XP with > gpg 1.4.1 rc2. > > If my homedir is e.g. D:\patrick, then file renaming works fine. > > *But* if my homedir is: > D:/Documents and Settings/patrick/Application Data/GnuPG > then I still get the file renaming bug when trying to import a key: > > D:\gnupg\GnuPG\gpg.exe --charset utf8 --batch --no-tty --status-fd 2 - > -import > gpg: key D18D9C18: public key "..." imported > gpg: Total number processed: 1 > gpg: imported: 1 > gpg: public key 57BBB132 is 4104 seconds newer than the signature > gpg: renaming `D:/Documents and Settings/patrick/Application > Data/GnuPG\pubring.gpg' > to `D:/Documents and Settings/patrick/Application > Data/GnuPG\pubring.bak' failed: Permission denied > gpg: failed to rebuild keyring cache: file rename error I found some more points for the bug. If the sequence is: 1. --edit-key 2. --list-key then the error does not happen. If the sequence is: 1. --edit-key 2. --edit-key Then the error occurs regardless of the directory name. - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1rc2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJDM42KgHx8zsInsRAkABAJ0d4eW/xcrb8i+W4+E9VjcgK1jBegCeJEKt A7onpojo1oHryAhVYO2Z3rs= =pCA+ -----END PGP SIGNATURE----- From quetschke at scytek.de Wed Mar 2 17:53:41 2005 From: quetschke at scytek.de (Volker Quetschke) Date: Wed Mar 2 18:40:24 2005 Subject: Two patches for cygwin build of 1.4.1rc2 Message-ID: <4225EF95.8090308@scytek.de> Actually both problems were already present in gnupg 1.4.0 but I forgot to send them to this list. 1. To get a dynamically linked gpg $shlibext has to be 'lib.a' and not only 'lib' I use the following patch for the cygwin gnupg package, but there sure is a more elegant way: --- sorry for the line wrapping --- --- gnupg-1.4.1rc2-orig/scripts/config.rpath 2004-07-27 11:11:52.000000000 -0400 +++ gnupg-1.4.1rc2/scripts/config.rpath 2005-03-02 11:17:05.000000000 -0500 @@ -517,6 +517,12 @@ sed_quote_subst='s/\(["`$\\]\)/\\\1/g' escaped_wl=`echo "X$wl" | sed -e 's/^X//' -e "$sed_quote_subst"` shlibext=`echo "$shrext" | sed -e 's,^\.,,'` +# Cygwin needs 'lib.a' to find the import libraries +case "$host_os" in + cygwin*) + shlibext=${shlibext}.a + ;; +esac escaped_hardcode_libdir_flag_spec=`echo "X$hardcode_libdir_flag_spec" | sed -e 's/^X//' -e "$sed_quote_subst"` sed -e 's/^\([a-zA-Z0-9_]*\)=/acl_cv_\1=/' < Hi, (sorry for bringing this up again, but it is not fixed, so :-) ) When signing stuff with the subkey from my OpenPGP-Smartcard, the gpg-daemon will ask gtk-pinentry to ask me for my PIN. A subsequent signing will ask for the PIN again, although I expect gpg-daemon to cache it. How do I fix that? gpg-agent is running and is used. I checked using pstree: the gtk-pinenty that is asking for my pin was indeed started by gpg-agent. Same procedure with my primary key (using ! when specifying the keyid) will ask for the passphrase only once. ~ $ cat ~/.gnupg/gpg-agent.conf pinentry-program /usr/lib/pinentry/pinentry-gtk debug 64 The signature key on the card is a subkey for my primary key in my keyring: ~ $ gpg -K /home/jojo/.gnupg/secring.gpg ----------------------------- sec 1024D/4743206C 2002-08-27 uid Joachim Breitner uid Joachim Breitner (Jabber-ID) uid [NZ]Jojo uid Joachim Breitner ssb 2048g/0E160746 2002-08-27 ssb> 1024R/2758C57B 2004-10-05 ssb> 1024R/C7602275 2004-11-07 ssb> 1024R/F64A4797 2004-11-07 My versions are, both the stock debian unstable packages: gnupg 1.4.0-3 gnupg-agent 1.9.15-1 Do you need more informations? Thanks, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Bitte senden Sie mir keine Word- oder PowerPoint-Anh?nge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : /pipermail/attachments/20050306/4518cfe4/attachment.pgp From wk at gnupg.org Mon Mar 7 20:15:45 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Mar 8 14:48:47 2005 Subject: Two patches for cygwin build of 1.4.1rc2 In-Reply-To: <4225EF95.8090308@scytek.de> (Volker Quetschke's message of "Wed, 02 Mar 2005 11:53:41 -0500") References: <4225EF95.8090308@scytek.de> Message-ID: <87fyz72roe.fsf@wheatstone.g10code.de> On Wed, 02 Mar 2005 11:53:41 -0500, Volker Quetschke said: > --- sorry for the line wrapping --- > --- gnupg-1.4.1rc2-orig/scripts/config.rpath 2004-07-27 config.rpath is part of libtool and updated with an automake update. Please report to the libtool maintainers. > -AM_CFLAGS = -DGNUPG_LIBEXECDIR="\"$(libexecdir)\"" > +AM_CFLAGS = -DGNUPG_LIBEXECDIR="\"$(libexecdir):$(bindir)\"" This does not work. GNUPG_LIBEXECDIR is intended to be a single directory name and not a search path. Use the runtime option --exec-path to specify a search path or even better make sure to install the helpers in the correct directory. Salam-Shalom, Werner From dshaw at jabberwocky.com Mon Mar 7 19:46:07 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Mar 8 14:48:49 2005 Subject: Two patches for cygwin build of 1.4.1rc2 In-Reply-To: <4225EF95.8090308@scytek.de> References: <4225EF95.8090308@scytek.de> Message-ID: <20050307184607.GD10604@jabberwocky.com> On Wed, Mar 02, 2005 at 11:53:41AM -0500, Volker Quetschke wrote: > Actually both problems were already present in gnupg 1.4.0 but I forgot > to send them to this list. > > 1. To get a dynamically linked gpg $shlibext has to be 'lib.a' > and not only 'lib' > I use the following patch for the cygwin gnupg package, but there > sure is a more elegant way: config.rpath is actually part of gettext (?). You might want to talk to the gettext folks and see why they did things the way they did. David From quetschke at scytek.de Tue Mar 8 00:52:56 2005 From: quetschke at scytek.de (Volker Quetschke) Date: Tue Mar 8 14:48:52 2005 Subject: Two patches for cygwin build of 1.4.1rc2 In-Reply-To: <87fyz72roe.fsf@wheatstone.g10code.de> References: <4225EF95.8090308@scytek.de> <87fyz72roe.fsf@wheatstone.g10code.de> Message-ID: <422CE958.1030706@scytek.de> Hi Werner, >>--- gnupg-1.4.1rc2-orig/scripts/config.rpath 2004-07-27 > config.rpath is part of libtool and updated with an automake > update. Please report to the libtool maintainers. I thought so, OK. >>-AM_CFLAGS = -DGNUPG_LIBEXECDIR="\"$(libexecdir)\"" >>+AM_CFLAGS = -DGNUPG_LIBEXECDIR="\"$(libexecdir):$(bindir)\"" > > This does not work. GNUPG_LIBEXECDIR is intended to be a single > directory name and not a search path. Well, this works fine. See the gnupg 1.4.0 cygwin package. What you propably mean is that it is not supposed to work. ;) The set_exec_path(GNUPG_LIBEXECDIR,...) command in keyserver.c just adds/replaces the given string (here: GNUPG_LIBEXECDIR) into the path environment variable (that only contains the exec-path at that moment). Works fine. > Use the runtime option --exec-path to specify a search path Sure, that works but is not user friendly. Also using "exec-path /bin" in gpg.conf works but also is not user friendly. > or even better make sure to > install the helpers in the correct directory. They are, the problem is not finding the helper, but the helper needs to find cygwin1.dll, therfore the need for /bin. Volker -- PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050307/5f774185/signature.pgp From ivg2 at cornell.edu Tue Mar 8 20:48:10 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed Mar 9 10:43:37 2005 Subject: gpg: PT_GNU_STACK RWE In-Reply-To: <87acpv8t8t.fsf@wheatstone.g10code.de> References: <1109130154.4359.1.camel@cobra.ivg2.net> <87acpv8t8t.fsf@wheatstone.g10code.de> Message-ID: <1110311290.4508.4.camel@cobra.ivg2.net> Any progress on this issue - should I file a bugzilla to track it? On Wed, 2005-02-23 at 11:29 +0100, Werner Koch wrote: > On Tue, 22 Feb 2005 22:42:34 -0500, Ivan Gyurdiev said: > > > The question is, does gpg really require an executable stack? > > I don't think so. Some platforms might require it so; things to check > are mpi/longlong.h as well as all the assembler code at mpi//. > > Might be easier to just check it out by running a key generation on > all platforms. > > > Salam-Shalom, > > Werner > -- Ivan Gyurdiev Cornell University From wk at gnupg.org Wed Mar 9 11:19:33 2005 From: wk at gnupg.org (Werner Koch) Date: Wed Mar 9 11:16:05 2005 Subject: gpg-agent not caching smartcard PINs In-Reply-To: <1110136296.11220.23.camel@localhost.localdomain> (Joachim Breitner's message of "Sun, 06 Mar 2005 20:11:36 +0100") References: <1110136296.11220.23.camel@localhost.localdomain> Message-ID: <876501unnu.fsf@wheatstone.g10code.de> On Sun, 06 Mar 2005 20:11:36 +0100, Joachim Breitner said: > Hi, > (sorry for bringing this up again, but it is not fixed, so :-) ) > When signing stuff with the subkey from my OpenPGP-Smartcard, the > gpg-daemon will ask gtk-pinentry to ask me for my PIN. A subsequent > signing will ask for the PIN again, although I expect gpg-daemon to Sure that changed the default on the card from Signature PIN ....: forced to "not forced"? Force will always ask for the PIN. Salam-Shalom, Werner From nomeata at debian.org Mon Mar 7 11:37:42 2005 From: nomeata at debian.org (Joachim Breitner) Date: Wed Mar 9 12:05:26 2005 Subject: gpg-agent not caching smartcard PINs Message-ID: <1110191862.11281.4.camel@localhost.localdomain> Hi, (sorry for bringing this up again, but it is not fixed, so :-) ) When signing stuff with the subkey from my OpenPGP-Smartcard, the gpg-daemon will ask gtk-pinentry to ask me for my PIN. A subsequent signing will ask for the PIN again, although I expect gpg-daemon to cache it. How do I fix that? gpg-agent is running and is used. I checked using pstree: the gtk-pinenty that is asking for my pin was indeed started by gpg-agent. Same procedure with my primary key (using ! when specifying the keyid) will ask for the passphrase only once. ~ $ cat ~/.gnupg/gpg-agent.conf pinentry-program /usr/lib/pinentry/pinentry-gtk debug 64 The signature key on the card is a subkey for my primary key in my keyring: ~ $ gpg -K /home/jojo/.gnupg/secring.gpg ----------------------------- sec 1024D/4743206C 2002-08-27 uid Joachim Breitner uid Joachim Breitner (Jabber-ID) uid [NZ]Jojo uid Joachim Breitner ssb 2048g/0E160746 2002-08-27 ssb> 1024R/2758C57B 2004-10-05 ssb> 1024R/C7602275 2004-11-07 ssb> 1024R/F64A4797 2004-11-07 My versions are, both the stock debian unstable packages: gnupg 1.4.0-3 gnupg-agent 1.9.15-1 Do you need more informations? Thanks, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Bitte senden Sie mir keine Word- oder PowerPoint-Anh?nge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : /pipermail/attachments/20050307/fc961332/attachment.pgp From eutropos at hotmail.com Mon Mar 7 11:23:31 2005 From: eutropos at hotmail.com (Eutropos Eutropou) Date: Wed Mar 9 12:05:29 2005 Subject: GNUPG 1.4.0 KEYRINGS RELATED BUG Message-ID: Most of keyrings related operations (adding or importing a new key, modifying prefs) fail on GNUpg v1.4.0 for Win32 compiled with Visual C++ 6.0 (running on Windows NT 4.0 Workstation) due to a denied permission when renaming temporary keyring files. In fact, I found that remove/DeleteFile function call fails, obviously preventing subsequent file renaming. The problem is: why? Perhaps is there an open HANDLE object somewhere (it seems that Win32 refuses to delete open files, specially on NT)? I have no time to investigate, so I hope you will. Note that some operations fail with the downloaded (MinGW32 made) GPG binary, too! However, old versions I compiled myself with Visual C++ worked fine! _________________________________________________________________ Ricerche online pi? semplici e veloci con MSN Toolbar! http://toolbar.msn.it/ From mail at joachim-breitner.de Wed Mar 9 18:11:23 2005 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed Mar 9 18:07:31 2005 Subject: gpg-agent not caching smartcard PINs In-Reply-To: <876501unnu.fsf@wheatstone.g10code.de> References: <1110136296.11220.23.camel@localhost.localdomain> <876501unnu.fsf@wheatstone.g10code.de> Message-ID: <1110388284.14249.1.camel@localhost.localdomain> Hi, Am Mittwoch, den 09.03.2005, 11:19 +0100 schrieb Werner Koch: > > When signing stuff with the subkey from my OpenPGP-Smartcard, the > > gpg-daemon will ask gtk-pinentry to ask me for my PIN. A subsequent > > signing will ask for the PIN again, although I expect gpg-daemon to > > Sure that changed the default on the card from > > Signature PIN ....: forced > > to "not forced"? Force will always ask for the PIN. Yes, I forgot to tell you, I did check it with both settings, no help. Maybe because of the version discrepancy somehow: gnupg 1.4.0-3 gnupg-agent 1.9.15-1 But even then it's probably a bug. Or maybe because it is a subkey (though in the card's first keyslot). Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Bitte senden Sie mir keine Word- oder PowerPoint-Anh?nge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html From wk at gnupg.org Wed Mar 9 20:21:26 2005 From: wk at gnupg.org (Werner Koch) Date: Wed Mar 9 20:21:13 2005 Subject: Two patches for cygwin build of 1.4.1rc2 In-Reply-To: <422CE958.1030706@scytek.de> (Volker Quetschke's message of "Mon, 07 Mar 2005 18:52:56 -0500") References: <4225EF95.8090308@scytek.de> <87fyz72roe.fsf@wheatstone.g10code.de> <422CE958.1030706@scytek.de> Message-ID: <87acpcsk09.fsf@wheatstone.g10code.de> On Mon, 07 Mar 2005 18:52:56 -0500, Volker Quetschke said: > They are, the problem is not finding the helper, but the helper needs > to find cygwin1.dll, therfore the need for /bin. Make sure that the cygwin1.dll is in a directory Windows uses by default for module loading. Shalom-Salam, Werner From quetschke at scytek.de Wed Mar 9 22:18:05 2005 From: quetschke at scytek.de (Volker Quetschke) Date: Wed Mar 9 22:57:22 2005 Subject: Two patches for cygwin build of 1.4.1rc2 In-Reply-To: <87acpcsk09.fsf@wheatstone.g10code.de> References: <4225EF95.8090308@scytek.de> <87fyz72roe.fsf@wheatstone.g10code.de> <422CE958.1030706@scytek.de> <87acpcsk09.fsf@wheatstone.g10code.de> Message-ID: <422F680D.1030705@scytek.de> Hi Werner, >>They are, the problem is not finding the helper, but the helper needs >>to find cygwin1.dll, therfore the need for /bin. > > Make sure that the cygwin1.dll is in a directory Windows uses by > default for module loading. that would be either the location of the started executable or everything in the PATH variable. As the set_exec_path(GNUPG_LIBEXECDIR,...) command in keyserver.c resets the path to nothing plus exec-path obviously not many options are left. Therefore the cygwin only patch to add $(bindir) (means /bin) to find the required dll. Volker -- PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050309/1a15f929/signature.pgp From wk at gnupg.org Thu Mar 10 11:38:17 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Mar 10 11:36:05 2005 Subject: Two patches for cygwin build of 1.4.1rc2 In-Reply-To: <422F680D.1030705@scytek.de> (Volker Quetschke's message of "Wed, 09 Mar 2005 16:18:05 -0500") References: <4225EF95.8090308@scytek.de> <87fyz72roe.fsf@wheatstone.g10code.de> <422CE958.1030706@scytek.de> <87acpcsk09.fsf@wheatstone.g10code.de> <422F680D.1030705@scytek.de> Message-ID: <873bv3rdk6.fsf@wheatstone.g10code.de> On Wed, 09 Mar 2005 16:18:05 -0500, Volker Quetschke said: > that would be either the location of the started executable or > everything in the PATH variable. As the and 4 other locations. Windows looks for DLLs this way: 1. The directory from where the current process was loaded. 2. The current directory 3. The Windows system directory (cf. GetSystemDirectory) 4. The 16 bit system directory 5. The Windows directory (cf. GetWindowsDirectory) 6. The directories listen in $PATH. Given that this DLL is requirement for many application, you should install it into the Windows directory. Or modify cygwin to allow loading of that DLL from a different place; I bet there is at least an environment variable to do this. Shalom-Salam, Werner From wk at gnupg.org Thu Mar 10 11:39:50 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Mar 10 11:36:15 2005 Subject: GNUPG 1.4.0 KEYRINGS RELATED BUG In-Reply-To: (Eutropos Eutropou's message of "Mon, 07 Mar 2005 11:23:31 +0100") References: Message-ID: <87y8cvpyx5.fsf@wheatstone.g10code.de> On Mon, 07 Mar 2005 11:23:31 +0100, Eutropos Eutropou said: > I have no time to investigate, so I hope you will. Nor do I have. Use mingw and you are set. > Note that some operations fail with the downloaded (MinGW32 made) GPG > binary, too! There is one open bug report regarding this. Will soon look at it. Salam-Shalom, Werner From wk at gnupg.org Thu Mar 10 11:44:42 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Mar 10 11:41:15 2005 Subject: Explicitely choosing a subkey leads to breakdown of gpg 1.4.0a for windows In-Reply-To: <41C5FC92.19501.4BA819@localhost> (Dirk Traulsen's message of "Sun, 19 Dec 2004 22:11:30 +0100") References: <41C5FC92.19501.4BA819@localhost> Message-ID: <87u0njpyp1.fsf@wheatstone.g10code.de> Hi, after a longish debugging session Timo and me found secmem_realloc to be the culprit. Fixed in CVS of 1.2.x and 1.4.x. diff -u -p -r1.42 -r1.43 --- util/secmem.c 16 Dec 2004 05:16:09 -0000 1.42 +++ util/secmem.c 10 Mar 2005 09:52:05 -0000 1.43 @@ -398,8 +401,12 @@ secmem_realloc( void *p, size_t newsize mb = (MEMBLOCK*)((char*)p - ((size_t) &((MEMBLOCK*)0)->u.aligned.c)); size = mb->size; - if( newsize < size ) - return p; /* it is easier not to shrink the memory */ + if (size < sizeof(MEMBLOCK)) + log_bug ("secure memory corrupted at block %p\n", mb); + size -= ((size_t) &((MEMBLOCK*)0)->u.aligned.c); + + if( newsize <= size ) + return p; /* It is easier not to shrink the memory. */ a = secmem_malloc( newsize ); if ( a ) { memcpy(a, p, size); Shalom-Salam, Werner From quetschke at scytek.de Thu Mar 10 16:34:48 2005 From: quetschke at scytek.de (Volker Quetschke) Date: Thu Mar 10 16:31:09 2005 Subject: Two patches for cygwin build of 1.4.1rc2 In-Reply-To: <873bv3rdk6.fsf@wheatstone.g10code.de> References: <4225EF95.8090308@scytek.de> <87fyz72roe.fsf@wheatstone.g10code.de> <422CE958.1030706@scytek.de> <87acpcsk09.fsf@wheatstone.g10code.de> <422F680D.1030705@scytek.de> <873bv3rdk6.fsf@wheatstone.g10code.de> Message-ID: <42306918.2000003@scytek.de> * crossposted to cygwin ml in case my opinion is not shared by the cygwin developers. * >>that would be either the location of the started executable or >>everything in the PATH variable. As the > > and 4 other locations. Windows looks for DLLs this way: > > 1. The directory from where the current process was loaded. > 2. The current directory > 3. The Windows system directory (cf. GetSystemDirectory) > 4. The 16 bit system directory > 5. The Windows directory (cf. GetWindowsDirectory) > 6. The directories listen in $PATH. Thanks, but as the dll location is defined by the cygwin installation (cf. www.cygwin.com) nothing except 1., 2. and 6. is an option. > Given that this DLL is requirement for many application, you should > install it into the Windows directory. Or modify cygwin to allow > loading of that DLL from a different place; I bet there is at least an > environment variable to do this. This will never happen for the cygwin distribution. The dll lives in /bin. Period. This was deliberately chosen in the past and will most propably not change to please one package. As the gnupg package maintainer for cygwin I can live with the mentioned patch, gpg will just work for people who install it as a cygwin package. All people that compile a version on their own will have to use exec-path or (on their own risk) copy the dll around. Mit freundlichen Gruessen Volker -- PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050310/35f6a1b3/signature.pgp From wk at gnupg.org Thu Mar 10 18:33:01 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Mar 10 18:31:10 2005 Subject: Two patches for cygwin build of 1.4.1rc2 In-Reply-To: <42306918.2000003@scytek.de> (Volker Quetschke's message of "Thu, 10 Mar 2005 10:34:48 -0500") References: <4225EF95.8090308@scytek.de> <87fyz72roe.fsf@wheatstone.g10code.de> <422CE958.1030706@scytek.de> <87acpcsk09.fsf@wheatstone.g10code.de> <422F680D.1030705@scytek.de> <873bv3rdk6.fsf@wheatstone.g10code.de> <42306918.2000003@scytek.de> Message-ID: <874qfjmmnm.fsf@wheatstone.g10code.de> On Thu, 10 Mar 2005 10:34:48 -0500, Volker Quetschke said: > Thanks, but as the dll location is defined by the cygwin installation > (cf. www.cygwin.com) nothing except 1., 2. and 6. is an option. So what you are saying is that cygin passes a full filename to LoadModule and uses its own logic to find that module? Then they should also have a standard directory to look for or Cygwin is severly broken. > This will never happen for the cygwin distribution. The dll lives in > /bin. Period. This was deliberately chosen in the > past and will most propably not change to please one package. Sorry I don't understand: You say that there is a fixed location to look for DLLs and in particular for the cygwin DLL. Where is the problem then? GnuPG does not know about this DLL; the cygwin toolchain adds the code to load that DLL. Salam-Shalom, Werner From quetschke at scytek.de Thu Mar 10 19:01:29 2005 From: quetschke at scytek.de (Volker Quetschke) Date: Thu Mar 10 18:57:48 2005 Subject: Two patches for cygwin build of 1.4.1rc2 In-Reply-To: <874qfjmmnm.fsf@wheatstone.g10code.de> References: <4225EF95.8090308@scytek.de> <87fyz72roe.fsf@wheatstone.g10code.de> <422CE958.1030706@scytek.de> <87acpcsk09.fsf@wheatstone.g10code.de> <422F680D.1030705@scytek.de> <873bv3rdk6.fsf@wheatstone.g10code.de> <42306918.2000003@scytek.de> <874qfjmmnm.fsf@wheatstone.g10code.de> Message-ID: <42308B79.7080106@scytek.de> >>Thanks, but as the dll location is defined by the cygwin installation >>(cf. www.cygwin.com) nothing except 1., 2. and 6. is an option. > > So what you are saying is that cygin passes a full filename to > LoadModule and uses its own logic to find that module? Then they > should also have a standard directory to look for or Cygwin is > severly broken. No, what I mean is that copying cygwin1.dll to 3. 4. or 5. is not an option. >>This will never happen for the cygwin distribution. The dll lives in >>/bin. Period. This was deliberately chosen in the >>past and will most propably not change to please one package. > > Sorry I don't understand: You say that there is a fixed location to > look for DLLs and in particular for the cygwin DLL. Where is the > problem then? GnuPG does not know about this DLL; the cygwin > toolchain adds the code to load that DLL. No, what I mean is when you copy the cygwin1.dll into other directories than this location the install program is no longer able to update it when you use it to upgrade your installation. The dll is not explicitly loaded from a fixed location, but the first cygwin1.dll that is found is used. But to repeat myself, having more than one cygwin1.dll on the system is caling for trouble and prohibits an upgrade using the setup program. Volker P.S.: It might be a good idea to place the cygwin1.dll (not by yourself, but generally through the setup program into the Windows system directory but this is not my call, and definitely not the currenly supported/desired status. -- PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20050310/34996bed/signature.pgp From wk at gnupg.org Thu Mar 10 19:41:10 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Mar 10 19:41:07 2005 Subject: File renaming bug still in gpg 1.4.1rc2 on Windows In-Reply-To: <4224333C.7080700@gmx.net> (Patrick Brunschwig's message of "Tue, 01 Mar 2005 10:17:48 +0100") References: <4222F130.2050506__35396.9102995054$1109590032$gmane$org@mozilla-enigmail.org> <4224333C.7080700@gmx.net> Message-ID: <87oedrl4xl.fsf@wheatstone.g10code.de> On Tue, 01 Mar 2005 10:17:48 +0100, Patrick Brunschwig said: > If the sequence is: > 1. --edit-key > 2. --edit-key > Then the error occurs regardless of the directory name. Thanks. I found it. It is the check_trustdb_stale() call done too late. Fixed it by running it earlier at --edit-key. Salam-Shalom, Werner From jvender at owensboro.net Fri Mar 11 20:35:32 2005 From: jvender at owensboro.net (Joe Vender) Date: Fri Mar 11 20:33:12 2005 Subject: --enable-noexecstack causes make failure. Message-ID: <000701c52671$805f0d00$961387d8@computer> System is MinGW/MSYS on Windows98. If I use the --enable-noexecstack option on the latest cvs version of GnuPG 1.4.1rc2, make crashes. My configure line is: $ CFLAGS='-O3 -mtune=i386 -march=i386 -mfpmath=387 -mno-mmx -mno-sse -mno-3dno w -mno-sse2' ./configure --prefix=/home/gpg-inst --enable-noexecstack LDFLAGS=-static Default@COMPUTER /home/default/gnupg $ make if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -O3 -mtune=i386 -march =i386 -mfpmath=387 -mno-mmx -mno-sse -mno-3dnow -mno-sse2 -Wall -MT mpiutil.o -MD -MP -MF ".deps/mpiutil.Tpo" -c -o mpiutil.o mpiutil.c; \ then mv -f ".deps/mpiutil.Tpo" ".deps/mpiutil.Po"; else rm -f ".deps/mpiutil.Tpo"; exit 1; fi gcc -E -I.. -I../include -DHAVE_CONFIG_H mpih-mul1.S | grep -v '^#' > _mpih-mul1.s gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -O3 -mtune=i386 -march =i386 -mfpmath=387 -mno-mmx -mno-sse -mno-3dnow -mno-sse2 -Wall -Wa,--noexec stack -c _mpih-mul1.s c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\as.exe: unrecognized option `--noexecstack' make[2]: *** [mpih-mul1.o] Error 1 make[2]: Leaving directory `/home/default/gnupg/mpi' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/default/gnupg' make: *** [all] Error 2 From dshaw at jabberwocky.com Fri Mar 11 20:40:56 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Mar 11 20:37:32 2005 Subject: --enable-noexecstack causes make failure. In-Reply-To: <000701c52671$805f0d00$961387d8@computer> References: <000701c52671$805f0d00$961387d8@computer> Message-ID: <20050311194056.GB24612@jabberwocky.com> On Fri, Mar 11, 2005 at 01:35:32PM -0600, Joe Vender wrote: > System is MinGW/MSYS on Windows98. > > If I use the --enable-noexecstack option on the latest cvs version of GnuPG > 1.4.1rc2, make crashes. --enable-noexecstack only works for certain assemblers. If your assembler doesn't support it, then it will not work and you should not enable that option. David From maschoch at compuserve.com Sun Mar 13 17:27:30 2005 From: maschoch at compuserve.com (Martin Schoch) Date: Sun Mar 13 17:23:31 2005 Subject: How to synchronize keyrings? Message-ID: <1214868408.20050313172730@compuserve.com> Hello Perhaps a strange question: How to synchronize public keys? Background: I have GnuPG on a Windows and on a Linux system - on both of course public keys. Sometimes I import (on both systems) new keys. Now I would have the same public keys on both systems? I think I have to do it like this: On the Linux system (eg.) I import the keys from the Windows system. Then I go back the Windows system an import the updated key file form the Linux system. But - is there any better and faster solution? -- Best regards, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 361 bytes Desc: not available Url : /pipermail/attachments/20050313/656db0a3/attachment.pgp From eutropos at hotmail.com Mon Mar 14 10:22:27 2005 From: eutropos at hotmail.com (Eutropos Eutropou) Date: Mon Mar 14 10:19:02 2005 Subject: 1 patch and 1 thought about Win32 port (keyring related bugs) Message-ID: I found a little time to debug in the week-end, and discovered the following: BUG #1 This is the bug that prevented *ALL* keyring related operations on MSVC 6 compiled copy of GnuPG 1.4.0 (MSVC gives me something more than MinGW: fastest code generation, slight better optimization performances, static linking - which improves speed - and delay loading of WSOCK32/WS2_32...). In fd_cache_strcmp (const char *a, const char *b): DOSISH comparison gives wrong result (with MSVC only?). Try replacing return *(const unsigned *)a - *(const unsigned *)b; with this (since *a and *b already have omogeneous type, BUT FUNCTION MUST RETURN AN INT!!!): return (const int) *a - *b; BUG #2 When a pubkey trust level has been changed, on the next execution GPG complains that it can't rename pubring.gpg to pubring.bak. Again there is an open HANDLE object for file pubring.gpg that prevents renaming: but reason isn't BUG #1... Neither the reason is a pubring.tmp file laying around (why is it still there???) The problem could be a wrong design of FD cache system. In fact, when the pubring.gpg file is opened for the first time by direct_open, it isn't cached (since caching occurs on closing time only), nor it's marked as directfp, I suppose... so, it isn't invalidated nor closed by renaming function, since gpg knows nothing about it. Simply make direct_open add a cache slot seemed to resolve the problem, but has a *BIG* side effect - it can alter file pointer position of in-use open file handles, wasting data I/O (data are corrupted during encryption, for example). Perhaps someone should put an iobuf_close() somewhere (I tried it in keydb_search, with bad results!)... I have no time to debug anymore, so I hope this will help in some way. _________________________________________________________________ Blocca le pop-up pubblicitarie con MSN Toolbar! http://toolbar.msn.it/ From wk at gnupg.org Mon Mar 14 11:29:34 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Mar 14 11:26:11 2005 Subject: 1 patch and 1 thought about Win32 port (keyring related bugs) In-Reply-To: (Eutropos Eutropou's message of "Mon, 14 Mar 2005 10:22:27 +0100") References: Message-ID: <87r7iibjw1.fsf@wheatstone.g10code.de> On Mon, 14 Mar 2005 10:22:27 +0100, Eutropos Eutropou said: > This is the bug that prevented *ALL* keyring related operations on > MSVC 6 compiled copy of GnuPG 1.4.0 (MSVC gives me something more This as been fixed 3 months ago. In fact right after the release and included in the 1.4.0a binary we distribute. > BUG #2 > When a pubkey trust level has been changed, on the next execution GPG > complains that it can't rename pubring.gpg to pubring.bak. Already fixed in CVS. Please take care to get the latest version before trying to debug something. The latest version is always in the CVS and we often provide release candidates too. Thanks, Werner From JPClizbe at comcast.net Mon Mar 14 10:57:51 2005 From: JPClizbe at comcast.net (John Clizbe) Date: Mon Mar 14 11:31:38 2005 Subject: How to synchronize keyrings? In-Reply-To: <1214868408.20050313172730@compuserve.com> References: <1214868408.20050313172730@compuserve.com> Message-ID: <4235601F.1000109@comcast.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Schoch wrote: > Hello > > Perhaps a strange question: How to synchronize public keys? > > Background: I have GnuPG on a Windows and on a Linux system - on > both of course public keys. Sometimes I import (on both systems) > new keys. > > Now I would have the same public keys on both systems? > > I think I have to do it like this: On the Linux system (eg.) I > import the keys from the Windows system. Then I go back the Windows > system an import the updated key file form the Linux system. > > But - is there any better and faster solution? If the two systems are on one box ( a dual boot config) place the keyrings on a common FAT/FAT32 partition. Otherwise, you could binary transfer one system's pubring to file on the other system, call it tempring.gpg and issue the comand: gpg --import-options allow-local-sigs --import tempring.gpg Transfer the merged pubring to the original system and repeat the import. Note: the the merged keyring should be able to be used directly on the original system, just backup pubring.gpg before trying it. You can also use --export-ownertrust and import-ownertrust to merge trustdb files. - -- John P. Clizbe Inet: John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10 "what's the key to success?" / "two words: good decisions." "what's the key to good decisions?" / "one word: experience." "how do i get experience?" / "two words: bad decisions." "Just how do the residents of Haiku, Hawai'i hold conversations?" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1rc2 (MingW32) Comment: When cryptography is outlawed, b25seSBvdXRsYXdzIHdpbGwgdXNlIG Comment: Be part of the ?33t ECHELON -- Use Strong Encryption. Comment: It's YOUR right - for the time being. Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCNWAeHQSsSmCNKhARAvOLAJwMnMW6+hMX0sksf4k2uJ34uUwceQCdEwlQ SbVK3PpdpAkGYrlRuC1ZaVs= =87vN -----END PGP SIGNATURE----- From bh at intevation.de Tue Mar 15 16:20:46 2005 From: bh at intevation.de (Bernhard Herzog) Date: Tue Mar 15 17:18:44 2005 Subject: missing time.h include in dirmngr Message-ID: When compiling dirmngr 0.9.1 I noticed a compiler warning: ldap.c: In function `ldap_wrapper_thread': ldap.c:267: warning: implicit declaration of function `time' ldap.c is missing an #include Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ From wk at gnupg.org Tue Mar 15 17:53:36 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Mar 15 18:17:13 2005 Subject: [Announce] GnuPG 1.4.1 released Message-ID: <873buw7svj.fsf@wheatstone.g10code.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! We are pleased to announce the availability of a new stable GnuPG release: Version 1.4.1 The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility and is compliant with the proposed OpenPGP Internet standard as described in RFC2440. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 1.4.1 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the following files in the *gnupg* directory: gnupg-1.4.1.tar.bz2 (2756k) gnupg-1.4.1.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.4.1.tar.gz (3964k) gnupg-1.4.1.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.4.0-1.4.1.diff.bz2 (650k) A patch file to upgrade a 1.4.0 GnuPG source. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. In the *binary* directory, you should find these files: gnupg-w32cli-1.4.1.exe (1406k) gnupg-w32cli-1.4.1.exe.sig GnuPG compiled for Microsoft Windows and OpenPGP signature. Note that this is a command line version and now comes with a graphical installer tool. The source files are the same as given above. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.4.1.tar.bz2 you would use this command: gpg --verify gnupg-1.4.1.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using "finger wk 'at' g10code.com" or "finger dd9jn 'at' gnu.org" or using the keyservers. I recently prolonged the expiration date; thus you might need a fresh copy of that key. Never use a GnuPG version you just downloaded to check the integrity of the source - use an existing GnuPG installation! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-1.4.1.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-1.4.1.tar.bz2 and check that the output matches the first line from the following list: ebd16ef9d3fd3c38e38cf39e6347ed058fd12840 gnupg-1.4.1.tar.bz2 f8e982d5e811341a854ca9c15feda7d5aba6e09a gnupg-1.4.1.tar.gz db573a6c3707f65797b569efda7e0905c4c4469c gnupg-w32cli-1.4.1.exe Upgrade Information =================== If you are upgrading from a version prior to 1.0.7, you should run the script tools/convert-from-106 once. Please note also that due to a bug in versions prior to 1.0.6 it may not be possible to downgrade to such versions unless you apply the patch http://www.gnupg.org/developer/gpg-woody-fix.txt . If you have any problems, please see the FAQ and the mailing list archive at http://lists.gnupg.org. Please direct questions to the gnupg-users@gnupg.org mailing list. What's New =========== There are too many changes to list them here. Please check out the NEWS file or read the summary at the end of this announcement. Internationalization ==================== GnuPG comes with support for 28 languages: American English Indonesian (id)[*] Bela-Russian (be)[*] Italian (it)[*] Catalan (ca)[*] Japanese (ja) Czech (cs) Polish (pl)[*] Danish (da)[*] Brazilian Portuguese (pt_BR)[*] Dutch (nl)[*] Portuguese (pt)[*] Esperanto (eo)[*] Romanian (ro) Estonian (et)[*] Russian (ru)[*] Finnish (fi)[*] Slovak (sk)[*] French (fr) Spanish (es)[*] Galician (gl)[*] Swedish (sv)[*] German (de) [*] Traditional Chinese (zh_TW) Greek (el) [*] Simplified Chinese (zh_CN) Hungarian (hu) [*] Turkish (tr) [*] Languages marked with [*] were not updated for this release and you will most likely notice untranslated messages. Many thanks to the translators for their ongoing support of GnuPG. Due to a lot of stylistic changes to the strings and about 150 new strings, most translations are not up to date. However we don't think that this is reason enough to hold back the release. Updated translations will be added with the next releases. Future Directions ================= GnuPG 1.4.x is the current stable branch and will be kept as the easy to use and build single-executable versions. We plan to backport new features from the development series to 1.4. GnuPG 1.9.x is the new development series of GnuPG. This version merged the code from the Aegypten project and thus it includes the gpg-agent, a smartcard daemon and gpg's S/MIME cousin gpgsm. The design is different to the previous versions and we may not support all ancient systems - thus POSIX compatibility will be an absolute requirement for supported platforms. 1.9 is as of now based on an somewhat older 1.3 code but will peacefully coexist with other GnuPG versions. Support ======= Developing and maintaining GnuPG and related software is nothing one can do in the evening or on weekends. We all spend a lot of time and money on it. David is actually doing this in his spare time beside his day job; g10 Code employs Timo and Werner to work on this software and would appreciate to refinance it by entering into support contracts or other contributions. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Kudos to David Shaw who did most of the new features in 1.4 and discussed various OpenPGP problems in lengths at several working groups. Happy Hacking, The GnuPG Team (David, Timo and Werner) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iEYEARECAAYFAkI3Eu4ACgkQYHhOlAEKV+1lTwCfSVtlldBYT2G3MZrxk+jHcH0i gYcAnArQgwu1RvaLp+713awo0QX6E6im =PGws -----END PGP SIGNATURE----- _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Tue Mar 15 18:22:11 2005 From: wk at gnupg.org (Werner Koch) Date: Tue Mar 15 19:24:16 2005 Subject: [Announce] GnuPG 1.4.1 News Message-ID: <87wts86czg.fsf@wheatstone.g10code.de> Hello! I forgot to insert the NEWS for 1.4.1; there are actually not that many as those for the last release. Here we go: * New --rfc2440-text option which controls how text is handled in signatures. This is in response to some problems seen with certain PGP/MIME mail clients and GnuPG version 1.4.0. More details about this are available at . * New "import-unusable-sigs" and "export-unusable-sigs" tags for --import-options and --export-options. These are off by default, and cause GnuPG to not import or export key signatures that are not usable (e.g. expired signatures). * New experimental HTTP, HTTPS, FTP, and FTPS keyserver helper that uses the cURL library to retrieve keys. This is disabled by default, but may be enabled with the configure option --with-libcurl. Without this option, the existing HTTP code is used for HTTP, and HTTPS, FTP, and FTPS are not supported. * When running a --card-status or --card-edit and a public key is available, missing secret key stubs will be created on the fly. Details of the key are listed too. * The implicit packet dumping in double verbose mode is now sent to stderr and not to stdout. * Added countermeasures against the Mister/Zuccherato CFB attack . * [W32] The algorithm for the default home directory changed: First we look at the environment variable GNUPGHOME, if this one is not set, we check whether the registry entry {HKCU,HKLM}\Software\GNU\GnuPG:HomeDir has been set. If this fails we use a GnuPG directory below the standard application data directory (APPDATA) of the current user. Only in the case that this directory cannot be determined, the old default of c:\gnupg will be used. The option --homedir still overrides all of them. * [W32] The locale selection under Windows changed. You need to enter the locale in the registry at HKCU\Software\GNU\GnuPG:Lang. For German you would use "de". If it is not set, GnuPG falls back to HKLM. The languages files "*.mo" are expected in a directory named "gnupg.nls" below the installation directory; that directory must be stored in the registry at the same key as above with the name "Install Directory". * Add new --edit-key command "bkuptocard" to allow restoring a card key from a backup. * The "fetch" command of --card-edit now retrieves the key using the default keyserver if no URL has been stored on the card. * New configure option --enable-noexecstack. Shalom-Salam, Werner -- Werner Koch The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.org _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From jan at intevation.de Wed Mar 16 13:15:46 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Wed Mar 16 13:36:20 2005 Subject: dirmngr: 64bit patch? Message-ID: <20050316121546.GA9158@intevation.de> Hi, in a SUSE rpm for dirmngr 0.5.5 I found the attached patch that is meant to establish 64bit compatibility. (I checked: it has not changed in CVS head) I have no 64bit system to test, but maybe it is a nobrainer for your brains? Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ -------------- next part -------------- --- src/http.c +++ src/http.c @@ -659,7 +659,7 @@ parse_response (http_t hd) { unsigned char *line, *p, *p2; - unsigned maxlen, len; + size_t maxlen, len; /* Wait for the status line. */ do --- src/http.h +++ src/http.h @@ -66,7 +66,7 @@ parsed_uri_t uri; http_req_t req_type; unsigned char *buffer; /* Line buffer. */ - unsigned buffer_size; + size_t buffer_size; unsigned int flags; }; typedef struct http_context_s *http_t; From jan at intevation.de Wed Mar 16 12:52:00 2005 From: jan at intevation.de (Jan-Oliver Wagner) Date: Wed Mar 16 13:51:52 2005 Subject: libksba: ac patch Message-ID: <20050316115200.GA9095@intevation.de> Hi, found this (minor) problem in current CVS of libksba. Best Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/ -------------- next part -------------- Index: acinclude.m4 =================================================================== RCS file: /cvs/aegypten/libksba/acinclude.m4,v retrieving revision 1.1 diff -u -3 -p -r1.1 acinclude.m4 --- acinclude.m4 12 Nov 2003 13:10:40 -0000 1.1 +++ acinclude.m4 16 Mar 2005 11:40:15 -0000 @@ -24,7 +24,7 @@ dnl AM_PATH_GPG_ERROR([MINIMUM-VERSION, dnl [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]]) dnl Test for libgpg-error and define GPG_ERROR_CFLAGS and GPG_ERROR_LIBS dnl -AC_DEFUN(AM_PATH_GPG_ERROR, +AC_DEFUN([AM_PATH_GPG_ERROR], [ AC_ARG_WITH(gpg-error-prefix, AC_HELP_STRING([--with-gpg-error-prefix=PFX], [prefix where GPG Error is installed (optional)]), From bruno at clisp.org Wed Mar 16 21:31:33 2005 From: bruno at clisp.org (Bruno Haible) Date: Thu Mar 17 00:04:03 2005 Subject: registry entry for internationalization Message-ID: <200503162131.33794.bruno@clisp.org> Greetings, This piece of NEWS from the gnupg-1.4.1 announcement is puzzling me: > * [W32] The locale selection under Windows changed. You need to > enter the locale in the registry at HKCU\Software\GNU\GnuPG:Lang. > For German you would use "de". If it is not set, GnuPG falls > back to HKLM. The languages files "*.mo" are expected in a > directory named "gnupg.nls" below the installation directory; > that directory must be stored in the registry at the same key as > above with the name "Install Directory". Will gpg, on a Windows system where the user's regional settings are German, use the German language even if the HKCU\Software\GNU\GnuPG:Lang value is not set? Do you expect users to set their preferred language once for every program? If no, what is special about GPG that warrants a particular intervention of the user for this program? GNU gettext uses the Woe32 API call GetThreadLocale(). Do you see anything wrong with that? gnupg-1.4.1/util/simple-gettext.c implements special i18n support for Woe32 systems only. Whereas on Linux, gpg uses the gettext() and related functions from libc. Is there something which makes the GNU libintl library unsuitable for use on Woe32 systems? (I assume you would link statically with it and with GNU libiconv. It's not worth going into DLL hassles because of it.) Bruno From wk at gnupg.org Thu Mar 17 09:33:48 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Mar 17 09:31:19 2005 Subject: registry entry for internationalization In-Reply-To: <200503162131.33794.bruno@clisp.org> (Bruno Haible's message of "Wed, 16 Mar 2005 21:31:33 +0100") References: <200503162131.33794.bruno@clisp.org> Message-ID: <878y4m3c43.fsf@wheatstone.g10code.de> On Wed, 16 Mar 2005 21:31:33 +0100, Bruno Haible said: > Will gpg, on a Windows system where the user's regional settings are German, > use the German language even if the HKCU\Software\GNU\GnuPG:Lang value is > not set? No, it won't. The installer however asks for the language to install and defaults to the one used on the system. > Do you expect users to set their preferred language once for every program? > If no, what is special about GPG that warrants a particular intervention > of the user for this program? Due to different qualities of translations users might not want to use eird and unchecked lange XX but choose EN or DE. > GNU gettext uses the Woe32 API call GetThreadLocale(). Do you see anything > wrong with that? All those locale setting under W32 are weird: Thedepend on whether it is a GUI or command line application. We store it in the registry and let the user decide. > from libc. Is there something which makes the GNU libintl library unsuitable > for use on Woe32 systems? (I assume you would link statically with > it and simple-gettext has been around far longer than a port iof libintl to W32. And libintl requires the use of iconv.dll which we only recently started to use. There is also no need for all these translations back and forth - we now simply provide utf-8 encoded mo files for Windows. > with GNU libiconv. It's not worth going into DLL hassles because of it.) Except for iconv which is far too large to link statically and also useful for other implementations. The installer checks whether an iconv.dll is already available and installs it only (local to GnuPG then) if it is not available or too old. Shalom-Salam, Werner From harakiri_23 at yahoo.com Thu Mar 17 11:36:49 2005 From: harakiri_23 at yahoo.com (Harakiri) Date: Thu Mar 17 11:33:19 2005 Subject: Signing Keys in Batch Mode and signature expire question Message-ID: <20050317103650.56218.qmail@web53002.mail.yahoo.com> How can i disable the question : "Do you want your signature to expire at the same time?" when batch signing keys using : gpg -u [CA-KeyID] --status-fd 1 --passphrase-fd 0 --batch --yes --edit [KeyID-to-be-signed] sign save i tried using the option --no-ask-cert-expire but that doesnt work - i thought --yes should answer all these questions ? thanks __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From wk at gnupg.org Thu Mar 17 11:39:13 2005 From: wk at gnupg.org (Werner Koch) Date: Thu Mar 17 11:36:22 2005 Subject: dirmngr: 64bit patch? In-Reply-To: <20050316121546.GA9158@intevation.de> (Jan-Oliver Wagner's message of "Wed, 16 Mar 2005 13:15:46 +0100") References: <20050316121546.GA9158@intevation.de> Message-ID: <878y4m1rqm.fsf@wheatstone.g10code.de> On Wed, 16 Mar 2005 13:15:46 +0100, Jan-Oliver Wagner said: > I have no 64bit system to test, but maybe it is a > nobrainer for your brains? I checked their use and the changes are okay. unsigned int and size_t need not be the same but gcc won't flag that as a problem on 32 bit systems. Applied them to the CVS. Thanks, Werner From harakiri_23 at yahoo.com Thu Mar 17 12:13:17 2005 From: harakiri_23 at yahoo.com (Harakiri) Date: Thu Mar 17 12:09:43 2005 Subject: Signing Keys in Batch Mode and signature expire question In-Reply-To: <20050317103650.56218.qmail@web53002.mail.yahoo.com> Message-ID: <20050317111317.8113.qmail@web53006.mail.yahoo.com> Nevermind, i figured it out - i can use --command-fd 0 - doesnt make sense that this works but all questions are now answered with yes... anyway - i think there is a bug that --no-ask-cert-expire doesnt really work. --- Harakiri wrote: > How can i disable the question : > > "Do you want your signature to expire at the same > time?" > > when batch signing keys using : > > gpg -u [CA-KeyID] --status-fd 1 --passphrase-fd 0 > --batch --yes --edit [KeyID-to-be-signed] sign save > > i tried using the option --no-ask-cert-expire but > that > doesnt work - i thought --yes should answer all > these > questions ? > > thanks > > > > __________________________________ > Do you Yahoo!? > Yahoo! Small Business - Try our new resources site! > http://smallbusiness.yahoo.com/resources/ > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ From bruno at clisp.org Thu Mar 17 13:38:06 2005 From: bruno at clisp.org (Bruno Haible) Date: Thu Mar 17 13:43:00 2005 Subject: registry entry for internationalization In-Reply-To: <878y4m3c43.fsf@wheatstone.g10code.de> References: <200503162131.33794.bruno@clisp.org> <878y4m3c43.fsf@wheatstone.g10code.de> Message-ID: <200503171338.06752.bruno@clisp.org> Hello Werner, Thanks for your answers. > > Will gpg, on a Windows system where the user's regional settings are > > German, use the German language even if the HKCU\Software\GNU\GnuPG:Lang > > value is not set? > > No, it won't. The installer however asks for the language to install > and defaults to the one used on the system. OK, I see. This has the (minor) flaw that if the user changes his Regional Settings after gpg was installed, gpg continues to work in the old language. > > Do you expect users to set their preferred language once for every > > program? If no, what is special about GPG that warrants a particular > > intervention of the user for this program? > > Due to different qualities of translations users might not want to use > eird and unchecked lange XX but choose EN or DE. To protect against incomplete translations, on Unix a user would either remove the corresponding .mo file, or access the program through a wrapper script that sets LANGUAGE=en. The only protection against translations of bad quality is to allow user feedback from the users to the translators. > > GNU gettext uses the Woe32 API call GetThreadLocale(). Do you see > > anything wrong with that? > > All those locale setting under W32 are weird: Thedepend on whether it > is a GUI or command line application. Do you have details, please? (I haven't done GUI programs under Woe32 so far.) Isn't there an easier workaround than registry settings? I know about the difference in console display charset for command-line application. This has the consequence that e.g. on a German system, a program producing output for a GUI (e.g. gpg when invoked from within Emacs in M-x shell) should emit ISO-8859-1 encoded output, but when writing to a console window (DOS box) it should emit CP-437 or CP-850 encoded output. This is an old, known problem that is best solved through setting the OUTPUT_CHARSET environment variable. > > Is there something which makes the GNU libintl library > > unsuitable for use on Woe32 systems? > > ... libintl requires the use of iconv.dll which we only recently > started to use. I agree that iconv.dll is a bit big, but I preferred this, rather than using the native Woe32 charset conversion APIs, that would sometimes have resulted in different strings being displayed on Woe32 than on Unix. > There is also no need for all these translations back > and forth - we now simply provide utf-8 encoded mo files for Windows. libintl never does or did conversions "back and forth". It only convers from the .mo file's encoding to the encoding requested by the application (or, if the application does not specify one, to the user's locale encoding). Bruno From zuxy.meng at gmail.com Thu Mar 17 12:55:37 2005 From: zuxy.meng at gmail.com (Zuxy) Date: Thu Mar 17 13:52:14 2005 Subject: What if I wanna translate the man/info page? In-Reply-To: References: Message-ID: Well, I posted this quite a long ago but nobody answered me. I now repost it to get some more attention:-) On Thu, 4 Nov 2004 17:26:55 +0800, Zuxy wrote: > Recently GnuPG has added a Russian manpage, and how can I help > translate the manpage to my language? Chiefly I want to know about > three things: > > 1. Where do I get the manpage? The team delivers the new .pot before a > new offical release, but the manpage not included. > > 2. Which format should I take? There are sgml, man, info, texi and > xmls under ./doc directory, so which format is the source that can > produces all the others? > > 3. I'm no familiar with any of those formats except html and xml, and > am afraid that my edition might corrupt the original format tags. > -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6 From dshaw at jabberwocky.com Fri Mar 18 14:32:54 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Mar 18 14:29:28 2005 Subject: Testing the new http code in 1.4.1 Message-ID: <20050318133254.GE5615@jabberwocky.com> Hi folks, Now that 1.4.1 is out, can I get a few people to help exercise the new HTTP code? There are two main tests that would be very helpful: 1) Build with the configure option --with-libcurl. If you have libcurl installed, you should end up with a new program 'gpgkeys_curl', that supports HTTP, HTTPS, FTP, and FTPS. If you don't have libcurl installed, nothing should happen. 2) Build with the configure option --enable-fake-curl. This should also result in a 'gpgkeys_curl', but it only supports HTTP. Once built, if you could test the protocols by fetching some keys many times over, trying with different servers, etc, that would be very much appreciated. Note that this is for files via HTTP (or HTTPS or FTP or FTPS). It's not full keyserver support (with searching and so on). All you can do is fetch keys, genenerally from a preferred keyserver URL set on a key or signature. To make testing easier so you don't have to keep making preferred keyserver URLs all over the place, note you can test by doing something like this: gpg --keyserver http://www.example.com/a/key/is/stored/here.asc --recv-keys 99999999 or gpg --keyserver https://www.example.com/a/key/is/stored/here.asc --recv-keys 99999999 etc. The key stored in that file likely isn't key 99999999, but it'll work anyway to test. David From jas at extundo.com Fri Mar 18 15:55:25 2005 From: jas at extundo.com (Simon Josefsson) Date: Fri Mar 18 16:30:29 2005 Subject: Testing the new http code in 1.4.1 In-Reply-To: <20050318133254.GE5615__12504.2292442688$1111152802$gmane$org@jabberwocky.com> (David Shaw's message of "Fri, 18 Mar 2005 08:32:54 -0500") References: <20050318133254.GE5615__12504.2292442688$1111152802$gmane$org@jabberwocky.com> Message-ID: David Shaw writes: > 1) Build with the configure option --with-libcurl. If you have > libcurl installed, you should end up with a new program > 'gpgkeys_curl', that supports HTTP, HTTPS, FTP, and FTPS. If you > don't have libcurl installed, nothing should happen. CURL might be a good way to get DNS keyserver support into GPG. Simply add DNS functionality to CURL, according to my DNS URI spec: http://josefsson.org/dns-url/ And then it would work automatically. Or? Are the protocols that is supported via CURL in GPG hard coded? I note that CURL support many other protocols too. I would assume the situation is similar with them. What I'm asking is: is it possible to retrieve OpenPGP keys from, say, LDAP servers through the CURL support in GPG now? This might be better than the gpgkeys_dns Perl script, which has a dependency on Net::DNS that may not be widely available. Thoughts? Thanks, Simon From dshaw at jabberwocky.com Fri Mar 18 16:46:27 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Mar 18 16:43:02 2005 Subject: Testing the new http code in 1.4.1 In-Reply-To: References: <20050318133254.GE5615__12504.2292442688$1111152802$gmane$org@jabberwocky.com> Message-ID: <20050318154627.GA28771@jabberwocky.com> On Fri, Mar 18, 2005 at 03:55:25PM +0100, Simon Josefsson wrote: > David Shaw writes: > > > 1) Build with the configure option --with-libcurl. If you have > > libcurl installed, you should end up with a new program > > 'gpgkeys_curl', that supports HTTP, HTTPS, FTP, and FTPS. If you > > don't have libcurl installed, nothing should happen. > > CURL might be a good way to get DNS keyserver support into GPG. > Simply add DNS functionality to CURL, according to my DNS URI spec: > > http://josefsson.org/dns-url/ > > And then it would work automatically. Or? Are the protocols that is > supported via CURL in GPG hard coded? I note that CURL support many > other protocols too. I would assume the situation is similar with > them. What I'm asking is: is it possible to retrieve OpenPGP keys > from, say, LDAP servers through the CURL support in GPG now? That's a very good idea. The CURL support in GPG is fairly generic, so it should indeed work. We would just need to add "dns" to the list of protocols that GPG passes to gpgkeys_curl. CURL would take care of the rest. LDAP-via-CURL would work as well for getting keys, but LDAP is somewhat special where OpenPGP is concerned. CURL supports fetching a LDAP URI (a la RFC 2255), but gpgkeys_ldap does a few more things like sending keys to the keyserver, searching for keys, etc. David From jas at extundo.com Fri Mar 18 17:20:08 2005 From: jas at extundo.com (Simon Josefsson) Date: Fri Mar 18 17:16:48 2005 Subject: Testing the new http code in 1.4.1 In-Reply-To: <20050318154627.GA28771__16529.8413172879$1111161305$gmane$org@jabberwocky.com> (David Shaw's message of "Fri, 18 Mar 2005 10:46:27 -0500") References: <20050318133254.GE5615__12504.2292442688$1111152802$gmane$org@jabberwocky.com> <20050318154627.GA28771__16529.8413172879$1111161305$gmane$org@jabberwocky.com> Message-ID: David Shaw writes: > On Fri, Mar 18, 2005 at 03:55:25PM +0100, Simon Josefsson wrote: >> David Shaw writes: >> >> > 1) Build with the configure option --with-libcurl. If you have >> > libcurl installed, you should end up with a new program >> > 'gpgkeys_curl', that supports HTTP, HTTPS, FTP, and FTPS. If you >> > don't have libcurl installed, nothing should happen. >> >> CURL might be a good way to get DNS keyserver support into GPG. >> Simply add DNS functionality to CURL, according to my DNS URI spec: >> >> http://josefsson.org/dns-url/ >> >> And then it would work automatically. Or? Are the protocols that is >> supported via CURL in GPG hard coded? I note that CURL support many >> other protocols too. I would assume the situation is similar with >> them. What I'm asking is: is it possible to retrieve OpenPGP keys >> from, say, LDAP servers through the CURL support in GPG now? > > That's a very good idea. The CURL support in GPG is fairly generic, > so it should indeed work. We would just need to add "dns" to the list > of protocols that GPG passes to gpgkeys_curl. CURL would take care of > the rest. Yup. I'm not familiar with CURL, but I'll see if it is possible to come up with a suitable patch that add DNS support. > LDAP-via-CURL would work as well for getting keys, but LDAP is > somewhat special where OpenPGP is concerned. CURL supports fetching a > LDAP URI (a la RFC 2255), but gpgkeys_ldap does a few more things like > sending keys to the keyserver, searching for keys, etc. Seems like there is room for another layer that handle those things. Ideally, the DNS support should support sending keys too, although I'm not sure that will ever be the widespread use of it. Thanks, Simon From ddcc at email.com Sat Mar 19 02:48:03 2005 From: ddcc at email.com (ddcc@email.com) Date: Sun Mar 20 18:22:18 2005 Subject: Bug report: "Ohhhh jeeee" error when GnuPG 1.4.1 installed suid with caps enabled Message-ID: <20050318204803.6e3d08b8@TANG-ONE-FIFTY-NINE.MIT.EDU> Hi, This bug report is related to the problem discussed in these previous messages: I didn't see any resolution, and I think I've discovered what the problem is, so I'm filing this report. If you install GnuPG 1.4.1 with capabilities enabled, and suid the binary, when you run gpg, you get the error: gpg: Ohhhh jeeee: ... this is a bug (g10.c:1756:main) secmem usage: 0/0 bytes in 0/0 blocks of pool 0/32768 Aborted The code that triggers this error is: /* There should be no way to get to this spot while still carrying setuid privs. Just in case, bomb out if we are. */ if(getuid()!=geteuid()) BUG(); The code is making sure that suid has been dropped after setting up protected memory. The problem is that in secmem.c, in lock_pool() drops suid only when USE_CAPABILITIES is not enabled. Therefore, if gpg is suid AND capabilities are enabled, then suid never gets dropped. The function secmem_init() in secmem.c also has the same problem. One more thing: if capabilities are enabled, then we should NOT get the insecure memory warning, right, even if we don't suid gpg? The warning still gets printed for me though, so can someone fix that? Thanks, David From albrecht.dress at arcor.de Sun Mar 20 22:25:56 2005 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Sun Mar 20 22:45:02 2005 Subject: Bug report: "Ohhhh jeeee" error when GnuPG 1.4.1 installed suid with caps enabled In-Reply-To: <20050318204803.6e3d08b8@TANG-ONE-FIFTY-NINE.MIT.EDU> (from ddcc@email.com on Sat Mar 19 02:48:03 2005) References: <20050318204803.6e3d08b8@TANG-ONE-FIFTY-NINE.MIT.EDU> Message-ID: <1111353965l.12328l.0l@antares.localdomain> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 19.03.05 02:48 schrieb(en) ddcc@email.com: > This bug report is related to the problem discussed in these previous > messages: [snipped bug description] I discovered a similar problem in pinentry, see . Unfortunately, the list archive seems to have problems to deal with this message (which is a multipart/signed), so FYI here again are the content and the proposed fix: Am 28.01.05 21:38 schrieb(en) Albrecht Dre?: > Hi all, > > I installed the latest pinentry 0.7.2 tarball on my box and realised > that the gtk1 and 2 versions didn't accept them to be SUID root any > more. Since the latest release, I upgraded my box from Yellowdog Linux > v.3 to v.4 (the latter one is roughly FC 2 for the PowerMac). The only > difference is that the "new" system has libcap, wheres it was not > available with the old one. > > Investigating the problem in more depth, I found that without linking > against libcap, setuid() (called in util.c, func drop_priv) will set > both the effective and the saved user id to the passed value. When > linked against libcap, only the effective uid is reset, but the saved > uid remains 0, and thus gtk [12] refuses to start. > > I am not sure if this is the desired behaviour, or a bug in libcap, but > I wanted to have pinentry-gtk-2 be suid root again... To this end, the > attached patch tries to detect if the function setresuid() is available > and uses it if possible. Now the saved uid is also reversed fine. > > System details: > > * PowerMac running Linux 2.6.10 > * glibc 2.3.3 > * gcc 3.3.3 > * libcap-1.10-18.1 rpm > > Opinions? > > 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://home.arcor.de/dralbrecht.dress/pubkey.asc _________________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCPeptn/9unNAn/9ERAnNcAJ4l7AyQyydkWRAxRBh69//uYllxJACffYzP uHSiBUUEaih0rs25CzcxCIs= =AFmt -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: pinentry-setresuid.patch.gz Type: application/x-gzip Size: 464 bytes Desc: not available Url : /pipermail/attachments/20050320/86af7372/pinentry-setresuid.patch.bin From zuxy.meng at gmail.com Mon Mar 21 07:04:36 2005 From: zuxy.meng at gmail.com (Zuxy) Date: Mon Mar 21 07:01:08 2005 Subject: Is it acceptable to use Windows APIs instead of iconv.dll? Message-ID: There seems to be a lot of confusion caused by 1.4.x's dependency on iconv.dll. Besides, iconv.dll is really big compared with gpg.exe itself. Since GnuPG only uses iconv for conversion between utf-8 and the current codepage, is it acceptable to write a special piece of code to emulate iconv thru Windows APIs, e.g. MultiByteToWideChar and WideCharToMultiByte? Then we can assign the function pointers to this code, and hence other parts of the program will remain unaffected. Exact behavior isn't necessary because GnuPG only checks iconv's return value to see if there's an error, right? -- Zuxy Beauty is truth, While truth is beauty. PGP KeyID: E8555ED6 From wk at gnupg.org Mon Mar 21 14:04:19 2005 From: wk at gnupg.org (Werner Koch) Date: Mon Mar 21 14:01:24 2005 Subject: Is it acceptable to use Windows APIs instead of iconv.dll? In-Reply-To: (zuxy.meng@gmail.com's message of "Mon, 21 Mar 2005 14:04:36 +0800") References: Message-ID: <87br9dtajw.fsf@wheatstone.g10code.de> On Mon, 21 Mar 2005 14:04:36 +0800, Zuxy said: > the current codepage, is it acceptable to write a special piece of > code to emulate iconv thru Windows APIs, e.g. MultiByteToWideChar and > WideCharToMultiByte? Then we can assign the function pointers to this No, you can't do that. Windows has its own ugly tables and is not fully Unicode compliant. libiconv is far better. Installing the iconv.dll is the way to go. In fact you need it only once on a system Salam-Shalom, Werner From maschoch at compuserve.com Wed Mar 23 17:55:56 2005 From: maschoch at compuserve.com (Martin Schoch) Date: Wed Mar 23 17:52:02 2005 Subject: GPG 1.4.1 and RIPEMD160 problem Message-ID: <403021400.20050323175556@compuserve.com> Hello, is there a known problem with the new version GnuPG 1.4.1 with hash RIPEMD160? I got a message which was signed with RIPEMD160 and got the error message from gpg when I wanted to verify the signature: gpg: Signature made 03/23/05 13:21:07 using DSA key ID DBE6E678 gpg: WARNING: signature digest conflict in message gpg: Can't check signature: general error Or does the sender something wrong with the GnuPG setup? -- Best regards, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 252 bytes Desc: not available Url : /pipermail/attachments/20050323/e8b718b0/attachment.pgp From dshaw at jabberwocky.com Wed Mar 23 18:05:06 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Mar 23 18:01:34 2005 Subject: GPG 1.4.1 and RIPEMD160 problem In-Reply-To: <403021400.20050323175556@compuserve.com> References: <403021400.20050323175556@compuserve.com> Message-ID: <20050323170506.GB5690@jabberwocky.com> On Wed, Mar 23, 2005 at 05:55:56PM +0100, Martin Schoch wrote: > Hello, > > is there a known problem with the new version GnuPG 1.4.1 with > hash RIPEMD160? > > I got a message which was signed with RIPEMD160 and got the error > message from gpg when I wanted to verify the signature: > > gpg: Signature made 03/23/05 13:21:07 using DSA key ID DBE6E678 > gpg: WARNING: signature digest conflict in message > gpg: Can't check signature: general error > > Or does the sender something wrong with the GnuPG setup? There are two ways this could happen - one, a clearsigned message that has a "Hash:" header that doesn't match the actual hash used in the signature, and two, a onepass signed message that claims to be one hash, but is actually another. In short, this is a bad message. What program generated it? David From atom at smasher.org Thu Mar 24 05:20:34 2005 From: atom at smasher.org (Atom Smasher) Date: Thu Mar 24 05:13:09 2005 Subject: GPG 1.4.1 and RIPEMD160 problem In-Reply-To: <20050323170506.GB5690@jabberwocky.com> References: <403021400.20050323175556@compuserve.com> <20050323170506.GB5690@jabberwocky.com> Message-ID: <20050324041705.10133.qmail@smasher.org> On Wed, 23 Mar 2005, David Shaw wrote: > There are two ways this could happen - one, a clearsigned message that > has a "Hash:" header that doesn't match the actual hash used in the > signature, and two, a onepass signed message that claims to be one hash, > but is actually another. ================= use "pgpdump" or "gpg --list-packets" to see what hash the signature ~really~ uses. -- ...atom _________________________________________ PGP key - http://atom.smasher.org/pgp.txt 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- When cryptography is outlawed, b25seSBvdXRsYXdzIHdpbGwgdXNlIGNyeXB0b2dyYXBoeS4K From dshaw at jabberwocky.com Thu Mar 24 05:23:00 2005 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Mar 24 05:19:32 2005 Subject: GPG 1.4.1 and RIPEMD160 problem In-Reply-To: <20050324041705.10133.qmail@smasher.org> References: <403021400.20050323175556@compuserve.com> <20050323170506.GB5690@jabberwocky.com> <20050324041705.10133.qmail@smasher.org> Message-ID: <20050324042300.GB7816@jabberwocky.com> On Wed, Mar 23, 2005 at 11:20:34PM -0500, Atom Smasher wrote: > On Wed, 23 Mar 2005, David Shaw wrote: > > >There are two ways this could happen - one, a clearsigned message that > >has a "Hash:" header that doesn't match the actual hash used in the > >signature, and two, a onepass signed message that claims to be one hash, > >but is actually another. > ================= > > use "pgpdump" or "gpg --list-packets" to see what hash the signature > ~really~ uses. Normally, I'd agree, but this is a PGP/MIME message. There is only one hash in there, and so there is nothing to conflict with... I have this vague theory that TheBat is constructing a brand new OpenPGP message out of the MIME parts for verification. Not enough data to say for sure. David From rhwood at mac.com Fri Mar 25 13:22:55 2005 From: rhwood at mac.com (Randall Wood) Date: Fri Mar 25 14:00:47 2005 Subject: What is wrong with this key. Message-ID: <78ddaa838bf24d0ae70a97cd5f1479db@mac.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : /pipermail/attachments/20050325/63fad00e/PGP.pgp From gpgme at katehok.ac93.org Wed Mar 30 01:51:11 2005 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Wed Mar 30 02:47:16 2005 Subject: gpgme_cancel() does not stop gpg process from finishing asynchronous call Message-ID: <4249E9EF.8050504@katehok.ac93.org> Starting asynchronouse call and then canceling it with gpgme_cancel do cause gpgme_wait() return Canceled error but leaves gpg process working and finishing the call. I have a slightly modified t-genkey test which shows that the key is generated after cancelation. I can send it if you want to. I also have a patch (attached, since it's very small) fixing the problem in GPGME 1.0.2. :) Basically, what it does - it stores pid return from _gpgme_io_spawn() in a engine_gpg_t structure field and then gently kills the child in gpg_cancel() callback. I do believe it should also help with those "/* FIXME: kill the child */" thingies. Hope it helps, Igor -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme1.0-gpgme-cancel.patch Type: text/x-patch Size: 2427 bytes Desc: not available Url : /pipermail/attachments/20050329/980438c3/gpgme1.0-gpgme-cancel.bin From gpgme at katehok.ac93.org Wed Mar 30 01:59:53 2005 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Wed Mar 30 02:55:51 2005 Subject: Incorrect gpgme_wait behavior Message-ID: <4249EBF9.2090006@katehok.ac93.org> Hello, gpgme_wait(ctx, &status, 0) on timeout returns ctx instead of NULL which makes it difficult to distinguish from a program return when ctx in not NULL. Plus, on timeout status is unchanged instead of being forced into 0. As a work around I set status to 0xFFFF (an impossible error code) and check if it got changed during the call. Attached is a small patch making it to follow the documented way: returning NULL, status=0 on timeouts returning NULL, status= on gpgme_wait() failure returning ctx, status= on an asynchornous progrem return. Hope it helps, Igor -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme1.0-gpgme_wait.patch Type: text/x-patch Size: 451 bytes Desc: not available Url : /pipermail/attachments/20050329/c29020f3/gpgme1.0-gpgme_wait.bin From gpgme at katehok.ac93.org Wed Mar 30 05:16:21 2005 From: gpgme at katehok.ac93.org (Igor Belyi) Date: Wed Mar 30 05:12:19 2005 Subject: Typo causing segmentation fault for gpgme_wait(NULL, ..) Message-ID: <424A1A05.1000705@katehok.ac93.org> Ok, here's the last patch in this short burst of a desire to help. :) When the first argument of the gpgme_wait is NULL it causes segmentation fault due to a small typo in the code. The attached patch fixes the problem. Hope it helps, Igor --------------------- the old good cut here line --------------------- --- gpgme1.0-1.0.2/gpgme/wait-global.c.orig 2005-03-29 20:55:31.000000000 -0500 +++ gpgme1.0-1.0.2/gpgme/wait-global.c 2005-03-29 20:56:31.000000000 -0500 @@ -331,13 +331,13 @@ LOCK (ctx_list_lock); for (li = ctx_active_list; li; li = li->next) { - for (i = 0; i < ctx->fdt.size; i++) - if (ctx->fdt.fds[i].fd != -1) + for (i = 0; i < li->ctx->fdt.size; i++) + if (li->ctx->fdt.fds[i].fd != -1) break; - if (i == ctx->fdt.size) + if (i == li->ctx->fdt.size) { gpgme_error_t err = 0; - _gpgme_engine_io_event (ctx->engine, GPGME_EVENT_DONE, &err); + _gpgme_engine_io_event (li->ctx->engine, GPGME_EVENT_DONE, &err); } } UNLOCK (ctx_list_lock); From belyi at users.sourceforge.net Wed Mar 30 04:07:20 2005 From: belyi at users.sourceforge.net (Igor Belyi) Date: Wed Mar 30 10:34:04 2005 Subject: Typo causing segmentation fault for gpgme_wait(NULL, ..) Message-ID: <424A09D8.5030003@users.sourceforge.net> Ok, here's the last patch in this short burst of a desire to help. :) When the first argument of the gpgme_wait is NULL it causes segmentation fault due to a small typo in the code. The attached patch fixes the problem. Hope it helps, Igor -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme1.0-typo-in-gpgme_wait.patch Type: text/x-patch Size: 724 bytes Desc: not available Url : /pipermail/attachments/20050329/8e5fb106/gpgme1.0-typo-in-gpgme_wait-0001.bin From colin at fedoraproject.org Wed Mar 30 15:22:24 2005 From: colin at fedoraproject.org (Colin Charles) Date: Thu Mar 31 08:27:23 2005 Subject: Failed to build on PPC Message-ID: <1112188945.8582.185.camel@arena.soho.bytebot.net> Attached is a log of a build failure on PPC, with gcc4 (fedora core 4 test1) Would appreciate a fix or pointers to a fix Regards & thanks -- Colin Charles, {colin,byte}@fedoraproject.org http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg2-1.9.15-1.log Type: text/x-log Size: 155735 bytes Desc: not available Url : /pipermail/attachments/20050330/34ed9f4d/gnupg2-1.9.15-1-0001.bin From jan at gondor.com Thu Mar 31 20:37:28 2005 From: jan at gondor.com (Jan Niehusmann) Date: Thu Mar 31 21:09:48 2005 Subject: smartcard not working reliable with ccid driver Message-ID: <20050331183727.GA20103@gondor.com> Hi, I have the following problems with gnupg when using the builtin ccid driver: 1) --card-status is often very slow When that happens, strace shows the following line very often: ioctl(3, USBDEVFS_REAPURBNDELAY, 0xbfca34f4) = -1 EAGAIN (Resource temporarily unavailable) 2) Decryption does not work, I always get the following error: $ gpg test.gpg gpg: DBG: asking for PIN 'PIN' PIN gpg: ccid_transceive failed: (0x1000a) gpg: apdu_send_simple(0) failed: card I/O error gpg: encrypted with 1024-bit RSA key, ID 662A4433, created 2005-03-31 "Jan Niehusmann (openpgp card test) " gpg: public key decryption failed: general error gpg: decryption failed: secret key not available I didn't try many other things, but I found a way to work around that: With the options --disable-ccid --pcsc-driver /usr/lib/libpcsclite.so.1 gnupg seems to work reliably. (After starting pcscd, of course) This is on debian unstable, with linux 2.6.12-rc1, on an Asus M2400N laptop. All packages are current. The reader is the SCM SCR-335 as provided by kernel concepts. If you want, I can do some more debugging, to find the cause of this problem. My time is limited, but I bought the card for playing with it, and I'll happily spend some spare time if I can help improving gpg. Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20050331/621b5b85/attachment.pgp