From j.scott.edwards.nwos at gmail.com Thu Mar 2 04:57:04 2006 From: j.scott.edwards.nwos at gmail.com (J. Scott Edwards) Date: Thu Mar 2 05:56:41 2006 Subject: Is there any interest in submitting added comments? In-Reply-To: <4095da870602191812j465fd719t7200256965281a8c@mail.gmail.com> References: <4095da870602170507k6b1f959dua618db20e54684e5@mail.gmail.com> <87ek21x3q9.fsf@wheatstone.g10code.de> <4095da870602191812j465fd719t7200256965281a8c@mail.gmail.com> Message-ID: <4095da870603011957o3785d3adh23598857a353712a@mail.gmail.com> I read the instructions on assigning the copyrights at http://www.fsf.org/licensing/assigning.html and if you can send me the questionaire I would be happy to fill it out and send it to the FSF for approval. So do submitters make their changes directly in CVS on Savannah? Thanks -Scott On 2/19/06, J. Scott Edwards wrote: > On 2/17/06, Werner Koch wrote: > > On Fri, 17 Feb 2006 06:07:09 -0700, J Scott Edwards said: > > > > > While I was digging around in the source files to understand gpg, I > > > added a few comments in a couple of files to help me remember what was > > > happening (I have a terrible memory). Is there any interest in my > > > submitting them back? If so what is the best way to do that? > > > > In general yes. However I believe that such commenst are > > copyrightab;le works and thus we would need copyright assignments to > > the FSF. So if you want to do that paperwork, I'd appreciate to > > receive those comments. > > That wouldn't be a problem, just let me know what to do. > > > I plan to update the internal documentation anyway while migrating the > > current code to the 1.9 code line. You might want to give some hints > > where better commenting is eally needed to understand the code. > > > > Sure, I could do that. What kind of time frame is the 1.9 migration? > > Thanks > -Scott > From marcus.brinkmann at ruhr-uni-bochum.de Fri Mar 3 10:47:02 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri Mar 3 11:13:05 2006 Subject: [Announce] GPGME 1.1.2 released Message-ID: <8764mvhnc9.wl%marcus.brinkmann@ruhr-uni-bochum.de> Hi, We are pleased to announce version 1.1.2 of GnuPG Made Easy, a library designed to make access to GnuPG easier for applications. It may be found in the file (about 860 KB/663 KB compressed) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.1.2.tar.gz ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.1.2.tar.bz2 The following files are also available: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.1.2.tar.gz.sig ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.1.2.tar.bz2.sig ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.1.1-1.1.2.diff.gz It should soon appear on the mirrors listed at: http://www.gnupg.org/mirrors.html Bug reports and requests for assistance should be sent to: gnupg-devel@gnupg.org The sha1sum checksums for this distibution are d235499c72af6becb65846722575dfb535ed3938 gpgme-1.1.1-1.1.2.diff.gz ebf8c278e967588acd7c416bd14bfe35615b7e81 gpgme-1.1.2.tar.bz2 f295e2af9a1e9de8267c45165e1172b80b412c42 gpgme-1.1.2.tar.bz2.sig 336d94e3bf2facedd06c52bd016bce647667c347 gpgme-1.1.2.tar.gz 367b51143bafde9bd5958ad521146a0d270e4ccd gpgme-1.1.2.tar.gz.sig Noteworthy changes in version 1.1.2 (2006-03-02) ------------------------------------------------ * Fixed a bug in the W32 glib backend. Noteworthy changes in version 1.1.1 (2006-02-22) ------------------------------------------------ * Fixed a bug in that the fingerprints of subkeys are not available. * Clarified usage of the SECRET flag in key listings. It is now reset for stub keys. * Reading signature notations and policy URLs on key signatures is supported. They can be found in the new field notations of the gpgme_key_sig_t structure. This has to be enabled with the keylist mode flag GPGME_KEYLIST_MODE_SIG_NOTATIONS. * A new gpgme_free() function solves the problem of using different allocators in a single program. This function should now be used instead calling free() to release the buffer returned by gpgme_data_release_and_get_mem. It is recommended that you always do this, but it is only necessary on certain platforms, so backwards compatibility is provided. In other words: If free() worked for you before, it will keep working. * New status codes GPGME_PKA_TRUST_GOOD and GPGME_PKA_TRUST_BAD. They are analyzed by the verify handlers and made available in the new PKA_TRUST and PKA_ADDRESS fields of the signature result structure. * Interface changes relative to the 1.1.0 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gpgme_key_sig_t EXTENDED: New field notations. GPGME_KEYLIST_MODE_SIG_NOTATIONS NEW gpgme_free NEW GPGME_STATUS_PKA_TRUST_BAD NEW GPGME_STATUS_PKA_TRUST_GOOD NEW gpgme_signature_t EXTENDED: New field pka_trust. gpgme_signature_t EXTENDED: New field pka_address. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Marcus Brinkmann mb@g10code.de _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From marcus.brinkmann at ruhr-uni-bochum.de Fri Mar 3 15:51:43 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri Mar 3 16:53:59 2006 Subject: [Announce] GPA 0.7.2 released Message-ID: <87u0affuo0.wl%marcus.brinkmann@ruhr-uni-bochum.de> Hello, We are pleased to announce the release of GPA 0.7.2. GPA is a graphical frontend for the GNU Privacy Guard (GnuPG, http://www.gnupg.org). GPA can be used to encrypt, decrypt, and sign files, to verify signatures and to manage the private and public keys. This is a development release. Please be careful when using it on production keys. You can find the release here: http://wald.intevation.org/frs/download.php/141/gpa-0.7.2.tar.bz2 http://wald.intevation.org/frs/download.php/142/gpa-0.7.2.tar.bz2.sig The SHA1 checksums for this release are: f3c0c400cc5b01b69b36704fdbe26f26abc8531b gpa-0.7.2.tar.bz2 c68868cf6aa383b6ad304d979be301d8620c0ec4 gpa-0.7.2.tar.bz2.sig Noteworthy changes in version 0.7.2 (2006-03-03) ------------------------------------------------ * The key generation wizard does not allow to set a comment anymore. This is an advanced feature available in the advanced GUI version of key generation. * Bug fixes for the Windows target, in particular internationalization and binary mode file handling. Marcus Brinkmann mb@g10code.de _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From marcus.brinkmann at ruhr-uni-bochum.de Fri Mar 3 15:47:58 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri Mar 3 16:58:13 2006 Subject: [Announce] libgpg-error 1.2 released Message-ID: <87veuvfuu9.wl%marcus.brinkmann@ruhr-uni-bochum.de> Hi, We are pleased to announce version 1.2 of libgpg-error, a library for common error values and messages in GnuPG components. This is a shared library so it can be updated independently of each individual component, while still allowing the use of new error values in inter-process communication. It may be found in the file (about 438 KB/328 KB compressed) ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.2.tar.gz ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.2.tar.bz2 The following files are also available: ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.2.tar.gz.sig ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.2.tar.bz2.sig ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.1-1.2.diff.gz It should soon appear on the mirrors listed at: http://www.gnupg.org/mirrors.html Bug reports and requests for assistance should be sent to: gnupg-devel@gnupg.org The sha1sum checksums for this distibution are f9b757d1ebdf9dbdbaa6341fe10bc08d1c943ae6 libgpg-error-1.1-1.2.diff.gz 468657e5bccd534f350b1a0109e19d2a9cc5d027 libgpg-error-1.2.tar.bz2 77fa306f82cdab01b7efb41b2bfa68da0911dfb2 libgpg-error-1.2.tar.bz2.sig 54068686e109f28bb64c0d8e52bd79172cdf56ae libgpg-error-1.2.tar.gz c1a49600856c15865222647723aca1e71bbec2c2 libgpg-error-1.2.tar.gz.sig Noteworthy changes in version 1.2 (2006-03-03) ---------------------------------------------- * New function gpg_err_init, which binds the locale directory to the text domain. This function is a constructor on GCC targets, so it does not need to be called explicitely. The header file defines GPG_ERR_INITIALIZED in this case. This is experimental for now. * "./autogen.sh --build-w32" does now also build a DLL for W32. Translations are not yet provided for this platform. * New error codes GPG_ERR_UNKNOWN_EXTN and GPG_ERR_UNKNOWN_CRIT_EXTN. * New error code GPG_ERR_LOCKED. * New translations included for France, Romania, and Vietnamese. * Interface changes relative to the 1.1 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GPG_ERR_UNKNOWN_EXTN NEW GPG_ERR_UNKNOWN_CRIT_EXTN NEW GPG_ERR_LOCKED NEW gpg_err_init NEW GPG_ERR_INITIALIZED NEW ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Marcus Brinkmann mb@g10code.de _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From stephane at sente.ch Sat Mar 4 19:04:08 2006 From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Sat Mar 4 20:47:58 2006 Subject: Need help compiling gpgme fat Message-ID: Hi, I'm trying to compile gpgme 1.1.2 on MacOSX, as a fat static library. I could compile gpg-error 1.2 as a fat library; I had some troubles, but could solve them: that new version needs now libintl (version 1.0 didn't), and the configure script doesn't say anything when it doesn't find it; user notices it only when compiling library. I needed to modify the libtool after having configured the build; on OSX, to compile as fat binary (ppc+i386) we need to use gcc 4's - isysroot option, but libtool doesn't use that root path when building system library search path, that's why I needed to patch it. env CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -I/usr/local/include" \ LDFLAGS="-L/usr/local/lib -lintl -framework CoreFoundation" \ ./configure --disable-shared --disable-dependency-tracking -- with-libintl-prefix=/usr/local mv libtool libtool-original sed 's,/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../ ,/Developer/ SDKs/MacOSX10.4u.sdk&,;s, /usr/lib",/Developer/SDKs/ MacOSX10.4u.sdk&,' < libtool-original > libtool sudo make install $ file /usr/local/lib/libgpg-error.a /usr/local/lib/libgpg-error.a: Mach-O fat file with 2 architectures /usr/local/lib/libgpg-error.a (for architecture i386): current ar archive random library /usr/local/lib/libgpg-error.a (for architecture ppc): current ar archive I applied the same patch to gpgme's libtool, but it seems it is not enough, as I think gpgme is not built/linked the same way as gpg-error: env CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 - arch ppc -I/usr/local/include" \ LDFLAGS="-L/usr/local/lib -lintl -framework CoreFoundation" \ ./configure --disable-shared --disable-dependency-tracking -- with-gpg-error-prefix=/usr/local --with-gpg=/usr/local/bin/gpg -- without-pth mv libtool libtool-original sed 's,/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../ ,/Developer/ SDKs/MacOSX10.4u.sdk&,;s, /usr/lib",/Developer/SDKs/ MacOSX10.4u.sdk&,' < libtool-original > libtool sudo make install ... make all-recursive Making all in gpgme make all-am /bin/sh ../libtool --tag=CC --mode=link gcc -isysroot /Developer/ SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -I/usr/local/include -Wall - Wcast-align -Wshadow -Wstrict-prototypes -L/usr/local/lib -lintl - framework CoreFoundation -o libgpgme.la -rpath /usr/local/lib - version-info 17:1:6 ath.lo libgpgme-real.la memrchr.lo -L/usr/ local/lib -lgpg-error rm -fr .libs/libgpgme.lax rm -fr .libs/libgpgme.lax mkdir .libs/libgpgme.lax rm -fr .libs/libgpgme.lax/libgpgme-real.a mkdir .libs/libgpgme.lax/libgpgme-real.a (cd .libs/libgpgme.lax/libgpgme-real.a && ar x /tmp/gpgme-1.1.2/ gpgme/./.libs/libgpgme-real.a) ar: /tmp/gpgme-1.1.2/gpgme/./.libs/libgpgme-real.a is a fat file (use libtool(1) or lipo(1) and ar(1) on it) ar: /tmp/gpgme-1.1.2/gpgme/./.libs/libgpgme-real.a: Inappropriate file type or format make[3]: *** [libgpgme.la] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Can anyone help me? Why is ar used here (it is not, when building libgpg-error, else it would have failed the same way)? Couldn't libgpgme be built the same way as libgpg-error? If so, what do I need to modify? BTW, I tried to use libgpg-error's libtool instead of libgpgme's, as it is more recent, but it makes no difference. Cheers, St?phane From marcus.brinkmann at ruhr-uni-bochum.de Sun Mar 5 17:37:13 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sun Mar 5 18:18:21 2006 Subject: Need help compiling gpgme fat In-Reply-To: References: Message-ID: <87acc47squ.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sat, 4 Mar 2006 19:04:08 +0100, St?phane Corth?sy wrote: > I'm trying to compile gpgme 1.1.2 on MacOSX, as a fat static library. Can you enlighten me? What's a "fat" library? > I could compile gpg-error 1.2 as a fat library; I had some troubles, > but could solve them: that new version needs now libintl (version 1.0 > didn't), and the configure script doesn't say anything when it > doesn't find it; user notices it only when compiling library. Well, we need to call bindtextdomain. It should be easy to add a configure check for that, can you submit a patch? (Alternatively, I can send you a patch for testing). > I applied the same patch to gpgme's libtool, but it seems it is not > enough, as I think gpgme is not built/linked the same way as gpg-error: gpgme links a shared library from some files and a static library (which it built itself). This requires special support on some platforms, and in fact may not be available on all platforms. libtool encapsulates this properly. You may need to extend libtool to support "fat" libraries (whatever they are :) The alternative would be to recompile every file for each of the thread packages. This is certainly possible, however, there are other packages where this trick is used. It's quite convenient. Thanks, Marcus From stephane at sente.ch Sun Mar 5 18:18:32 2006 From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Sun Mar 5 18:18:32 2006 Subject: Need help compiling gpgme fat In-Reply-To: <87acc47squ.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <87acc47squ.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <6D6515FE-5C14-4C57-832A-84817583A38B@sente.ch> Hi, On Mar 5, 2006, at 17:37 , Marcus Brinkmann wrote: > At Sat, 4 Mar 2006 19:04:08 +0100, > St?phane Corth?sy wrote: >> I'm trying to compile gpgme 1.1.2 on MacOSX, as a fat static library. > > Can you enlighten me? What's a "fat" library? A library containing code for multiple processor architectures. In my case, OSX for intel and ppc. >> I could compile gpg-error 1.2 as a fat library; I had some troubles, >> but could solve them: that new version needs now libintl (version 1.0 >> didn't), and the configure script doesn't say anything when it >> doesn't find it; user notices it only when compiling library. > > Well, we need to call bindtextdomain. It should be easy to add a > configure check for that, can you submit a patch? (Alternatively, I > can send you a patch for testing). Sorry, I know absolutely nothing about automake, autoconf and these tools. Anyway, I have libintl installed on my machine, so it's no longer a problem for me. >> I applied the same patch to gpgme's libtool, but it seems it is not >> enough, as I think gpgme is not built/linked the same way as gpg- >> error: > > gpgme links a shared library from some files and a static library > (which it built itself). This requires special support on some > platforms, and in fact may not be available on all platforms. libtool > encapsulates this properly. You may need to extend libtool to support > "fat" libraries (whatever they are :) Hmm, well, too hard for me. I tried tweaking resulting libtool, and went further in the build, until stumbling on the fact that 'ar' doesn't like adding files with multiple architectures on an existing archive; creating a single archive for multiple architectures works though. Maybe a limitation of 'ar'. > The alternative would be to recompile every file for each of the > thread packages. This is certainly possible, however, there are other > packages where this trick is used. It's quite convenient. > > Thanks, > Marcus That would do the trick, if libtool was invoked only once for all files, like it is the case for libgpg-error. Problem is that I don't know where I should patch makefiles. I'll try to compile gpgme twice, one for each architecture, and then 'lipo' them. And I'll post the question about GNU libtool on macosx mailing lists. Cheers, St?phane From stephane at sente.ch Sun Mar 5 18:49:20 2006 From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Sun Mar 5 18:49:25 2006 Subject: Need help compiling gpgme fat In-Reply-To: <6D6515FE-5C14-4C57-832A-84817583A38B@sente.ch> References: <87acc47squ.wl%marcus.brinkmann@ruhr-uni-bochum.de> <6D6515FE-5C14-4C57-832A-84817583A38B@sente.ch> Message-ID: Hi, I've just downloaded latest libtool (1.5.22), and replaced config.guess, config.sub, install-sh and ltmain.sh, applied my previous patch on generated libtool, and now it works :-) I can now build libgpgme for both ppc and intel in one pass/one lib. (maybe my patch is not even needed, I haven't tried yet without it) When will you upgrade your libtool (as well as gpg's, as I guess there is the same problem when trying to compile gpg as fat binary)? St?phane On Mar 5, 2006, at 18:18 , St?phane Corth?sy wrote: > Hi, > > On Mar 5, 2006, at 17:37 , Marcus Brinkmann wrote: > >> At Sat, 4 Mar 2006 19:04:08 +0100, >> St?phane Corth?sy wrote: >>> I'm trying to compile gpgme 1.1.2 on MacOSX, as a fat static >>> library. >> >> Can you enlighten me? What's a "fat" library? > > > A library containing code for multiple processor architectures. In > my case, OSX for intel and ppc. > > >>> I could compile gpg-error 1.2 as a fat library; I had some troubles, >>> but could solve them: that new version needs now libintl (version >>> 1.0 >>> didn't), and the configure script doesn't say anything when it >>> doesn't find it; user notices it only when compiling library. >> >> Well, we need to call bindtextdomain. It should be easy to add a >> configure check for that, can you submit a patch? (Alternatively, I >> can send you a patch for testing). > > > Sorry, I know absolutely nothing about automake, autoconf and these > tools. > Anyway, I have libintl installed on my machine, so it's no longer a > problem for me. > > >>> I applied the same patch to gpgme's libtool, but it seems it is not >>> enough, as I think gpgme is not built/linked the same way as gpg- >>> error: >> >> gpgme links a shared library from some files and a static library >> (which it built itself). This requires special support on some >> platforms, and in fact may not be available on all platforms. >> libtool >> encapsulates this properly. You may need to extend libtool to >> support >> "fat" libraries (whatever they are :) > > > Hmm, well, too hard for me. I tried tweaking resulting libtool, and > went further in the build, until stumbling on the fact that 'ar' > doesn't like adding files with multiple architectures on an > existing archive; creating a single archive for multiple > architectures works though. Maybe a limitation of 'ar'. > > >> The alternative would be to recompile every file for each of the >> thread packages. This is certainly possible, however, there are >> other >> packages where this trick is used. It's quite convenient. >> >> Thanks, >> Marcus > > > That would do the trick, if libtool was invoked only once for all > files, like it is the case for libgpg-error. Problem is that I > don't know where I should patch makefiles. > I'll try to compile gpgme twice, one for each architecture, and > then 'lipo' them. And I'll post the question about GNU libtool on > macosx mailing lists. > > Cheers, > > St?phane > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From dshaw at jabberwocky.com Sun Mar 5 21:49:58 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sun Mar 5 21:49:24 2006 Subject: Need help compiling gpgme fat In-Reply-To: References: <87acc47squ.wl%marcus.brinkmann@ruhr-uni-bochum.de> <6D6515FE-5C14-4C57-832A-84817583A38B@sente.ch> Message-ID: <20060305204958.GA11246@jabberwocky.com> On Sun, Mar 05, 2006 at 06:49:20PM +0100, St?phane Corth?sy wrote: > Hi, > > I've just downloaded latest libtool (1.5.22), and replaced > config.guess, config.sub, install-sh and ltmain.sh, applied my > previous patch on generated libtool, and now it works :-) I can now > build libgpgme for both ppc and intel in one pass/one lib. > (maybe my patch is not even needed, I haven't tried yet without it) > When will you upgrade your libtool (as well as gpg's, as I guess > there is the same problem when trying to compile gpg as fat binary)? No, GPG doesn't use libtool. In theory, compiling a fat GPG binary is pretty simple. The main difficulty is getting the endian stuff for the ciphers right (ppc being big, and intel being little). I'm able to build a fat binary that passes the selftest on my ppc OSX box. If you (or anyone here) has an intel OSX box and is willing to test as well, let me know. In theory, it should be as simple as a change to the configure script, but there is no way to tell without trying it. I have to admit, though, I'm not sure what the benefit of a fat GPG is. The idea behind fat binaries is a good one (companies don't need to maintain two different products generated from the same source code, with twice as much space in warehouses, etc). For free software like GPG that is "shipped" as source, I'm curious where is the benefit? David From marcus.brinkmann at ruhr-uni-bochum.de Mon Mar 6 10:46:24 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Mar 6 10:49:41 2006 Subject: Need help compiling gpgme fat In-Reply-To: References: <87acc47squ.wl%marcus.brinkmann@ruhr-uni-bochum.de> <6D6515FE-5C14-4C57-832A-84817583A38B@sente.ch> Message-ID: <878xrn7vnz.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sun, 5 Mar 2006 18:49:20 +0100, St?phane Corth?sy wrote: > I've just downloaded latest libtool (1.5.22), and replaced > config.guess, config.sub, install-sh and ltmain.sh, applied my > previous patch on generated libtool, and now it works :-) I can now > build libgpgme for both ppc and intel in one pass/one lib. > (maybe my patch is not even needed, I haven't tried yet without it) > When will you upgrade your libtool (as well as gpg's, as I guess > there is the same problem when trying to compile gpg as fat binary)? Yeah, it seems there is now fatting support in libtool. I have upgraded libgpg-error now to latest automake and libtool. Can you please test this from SVN? (See README.CVS for details). If this works for you (without any custom patches), I can update GPGME as well, for a second test. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Mon Mar 6 11:10:44 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Mar 6 11:14:19 2006 Subject: [Announce] GPGME 1.1.2 released In-Reply-To: <1141586420l.4770l.5l@antares.localdomain> References: <8764mvhnc9.wl%marcus.brinkmann@ruhr-uni-bochum.de> <1141586420l.4770l.5l@antares.localdomain> Message-ID: <877j777ujf.wl%marcus.brinkmann@ruhr-uni-bochum.de> Hi, (please don't post to gnupg-announce). Yes, you are right. The support for pthread in gpgme-config was accidentially removed. I put it back in CVS. Will be in next release: 2006-03-06 Marcus Brinkmann * gpgme-config.in (cflags_pth): Revert accidential removal of pthread support with last change. Thanks! Marcus At Sun, 05 Mar 2006 20:20:20 +0100, Albrecht Dre? wrote: > > Am 03.03.06 10:47 schrieb(en) Marcus Brinkmann: > > We are pleased to announce version 1.1.2 of GnuPG Made Easy, > > a library designed to make access to GnuPG easier for applications. > > It looks as if the gpgme-config script in this version is broken regarding > the proper reporting of pthread-safe libs. In earlier versions, > 'gpgme-config --thread=pthread --libs' was used to get the necessary > dependencies when building a pthread application. With 1.1.2, the script > ejects with an error. A possible fix for that is attached. From rdieter at math.unl.edu Mon Mar 6 15:21:04 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon Mar 6 15:19:53 2006 Subject: drop extraneous libs from gpgme-config Message-ID: Attached is a patch that drops extraneous libs(*) from gpgme-config output, as these dependancies are already in the installed .la files. (*) In particular, PTHREAD_LIBS, PTH_LIBS, GPG_ERROR_LIBS. GLIB_LIBS could probably go too, but I'm unfamiliar with those bits, so left it alone. -- Rex -------------- next part -------------- --- gpgme-1.1.2/gpgme/gpgme-config.in.extras 2005-11-18 17:03:28.000000000 -0600 +++ gpgme-1.1.2/gpgme/gpgme-config.in 2006-03-06 08:15:14.000000000 -0600 @@ -16,13 +16,13 @@ # Configure libgpg-error. gpg_error_cflags="@GPG_ERROR_CFLAGS@" -gpg_error_libs="@GPG_ERROR_LIBS@" +#gpg_error_libs="@GPG_ERROR_LIBS@" # Configure thread packages. thread_modules="" @HAVE_PTH_TRUE@thread_modules="$thread_modules pth" -libs_pth="@PTH_LDFLAGS@ @PTH_LIBS@" +#libs_pth="@PTH_LDFLAGS@ @PTH_LIBS@" cflags_pth="@PTH_CFLAGS@" # Configure glib. From marcus.brinkmann at ruhr-uni-bochum.de Mon Mar 6 15:40:58 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Mar 6 15:44:23 2006 Subject: drop extraneous libs from gpgme-config In-Reply-To: References: Message-ID: <8764mr7i11.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 06 Mar 2006 08:21:04 -0600, Rex Dieter wrote: > > [1 ] > Attached is a patch that drops extraneous libs(*) from gpgme-config > output, as these dependancies are already in the installed .la files. > > (*) In particular, PTHREAD_LIBS, PTH_LIBS, GPG_ERROR_LIBS. GLIB_LIBS > could probably go too, but I'm unfamiliar with those bits, so left it alone. gpgme-config is for those who do not use the .la files. If you use the .la files, you don't need to use gpgme-config --libs. Thanks, Marcus From rdieter at math.unl.edu Mon Mar 6 15:57:47 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon Mar 6 17:47:52 2006 Subject: drop extraneous libs from gpgme-config In-Reply-To: <8764mr7i11.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <8764mr7i11.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <440C4DEB.6090907@math.unl.edu> Marcus Brinkmann wrote: > At Mon, 06 Mar 2006 08:21:04 -0600, > Rex Dieter wrote: > >>[1 ] >>Attached is a patch that drops extraneous libs(*) from gpgme-config >>output, as these dependancies are already in the installed .la files. >> >>(*) In particular, PTHREAD_LIBS, PTH_LIBS, GPG_ERROR_LIBS. GLIB_LIBS >>could probably go too, but I'm unfamiliar with those bits, so left it alone. > > > gpgme-config is for those who do not use the .la files. And for those (poor souls): * Without proper shared libs or * Linking statically. Hopefully, that's a small target audience. > If you use the .la files, you don't need to use gpgme-config --libs. Yep, that was part of the point. (-: -- Rex From wk at gnupg.org Thu Mar 9 19:53:40 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Mar 9 20:16:59 2006 Subject: [Announce] GnuPG does not detect injection of unsigned data Message-ID: <87d5gvh2kr.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 dshaw at jabberwocky.com Fri Mar 10 01:36:05 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Mar 10 01:35:34 2006 Subject: [Announce] Second release candidate for 1.4.3 available Message-ID: <20060310003605.GA9614@jabberwocky.com> We are pleased to announce the availability of the second release candidate for the forthcoming 1.4.3 version of GnuPG: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.3rc2.tar.bz2 (3.0M) ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.4.3rc2.tar.bz2.sig SHA-1 checksums for the above files are: eb5b839555ff1957b5956aaf4c96505223a2f9d0 gnupg-1.4.3rc2.tar.bz2 2168b475f49100f5c41fa3830d90eb6d863220e7 gnupg-1.4.3rc2.tar.bz2.sig Note that this is only a release candidate, and as such is not intended for use on production systems. If you are inclined to help test, however, we would appreciate you trying this new version and reporting any problems. Note that this release candidate contains fixes for both the "False positive signature verification in GnuPG" and "GnuPG does not detect injection of unsigned data" problems reported against 1.4.2. Noteworthy changes since 1.4.2: * If available, cURL-based keyserver helpers are built that can retrieve keys using HKP or any protocol that cURL supports (HTTP, HTTPS, FTP, FTPS, etc). If cURL is not available, HKP and HTTP are still supported using a built-in cURL emulator. To force building the old pre-cURL keyserver helpers, use the configure option --enable-old-keyserver-helpers. Note that none of this affects finger or LDAP support, which are unchanged. Note also that a future version of GnuPG will remove the old keyserver helpers altogether. * Implemented Public Key Association (PKA) signature verification. This uses special DNS records and notation data to associate a mail address with an OpenPGP key to prove that mail coming from that address is legitimate without the need for a full trust path to the signing key. * When exporting subkeys, those specified with a key ID or fingerpint and the '!' suffix are now merged into one keyblock. * Added "gpg-zip", a program to create encrypted archives that can interoperate with PGP Zip. * Added support for signing subkey cross-certification "back signatures". Requiring cross-certification to be present is currently off by default, but will be changed to on by default in the future, once more keys use it. A new "cross-certify" command in the --edit-key menu can be used to update signing subkeys to have cross-certification. * The key cleaning options for --import-options and --export-options have been further polished. "import-clean" and "export-clean" replace the older import-clean-sigs/import-clean-uids and export-clean-sigs/export-clean-uids option pairs. * New "minimize" command in the --edit-key menu removes everything that can be removed from a key, rendering it as small as possible. There are corresponding "export-minimal" and "import-minimal" commands for --export-options and --import-options. * New --fetch-keys command to retrieve keys by specifying a URI. This allows direct key retrieval from a web page or other location that can be specified in a URI. Available protocols are HTTP and finger, plus anything that cURL supplies, if built with cURL support. * Files containing several signed messages are not allowed any longer as there is no clean way to report the status of such files back to the caller. To partly revert to the old behaviour the new option --allow-multisig-verification may be used. * The keyserver helpers can now handle keys in either ASCII armor or binary format. * New auto-key-locate option that takes an ordered list of methods to locate a key if it is not available at encryption time (-r or --recipient). Possible methods include "cert" (use DNS CERT as per RFC2538bis, "pka" (use DNS PKA), "ldap" (consult the LDAP server for the domain in question), "keyserver" (use the currently defined keyserver), as well as arbitrary keyserver URIs that will be contacted for the key. * Able to retrieve keys using DNS CERT records as per RFC-2538bis (currently in draft): http://www.josefsson.org/rfc2538bis Happy Hacking, David, Timo, Werner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 249 bytes Desc: not available Url : /pipermail/attachments/20060309/6f69ee57/attachment-0001.pgp From stephane at sente.ch Sat Mar 11 17:03:34 2006 From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Sat Mar 11 17:03:28 2006 Subject: Need help compiling gpgme fat In-Reply-To: <20060305204958.GA11246@jabberwocky.com> References: <87acc47squ.wl%marcus.brinkmann@ruhr-uni-bochum.de> <6D6515FE-5C14-4C57-832A-84817583A38B@sente.ch> <20060305204958.GA11246@jabberwocky.com> Message-ID: Hi, On Mar 5, 2006, at 21:49 , David Shaw wrote: > On Sun, Mar 05, 2006 at 06:49:20PM +0100, St?phane Corth?sy wrote: >> Hi, >> >> I've just downloaded latest libtool (1.5.22), and replaced >> config.guess, config.sub, install-sh and ltmain.sh, applied my >> previous patch on generated libtool, and now it works :-) I can now >> build libgpgme for both ppc and intel in one pass/one lib. >> (maybe my patch is not even needed, I haven't tried yet without it) >> When will you upgrade your libtool (as well as gpg's, as I guess >> there is the same problem when trying to compile gpg as fat binary)? > > No, GPG doesn't use libtool. In theory, compiling a fat GPG binary is > pretty simple. The main difficulty is getting the endian stuff for > the ciphers right (ppc being big, and intel being little). > > I'm able to build a fat binary that passes the selftest on my ppc OSX > box. If you (or anyone here) has an intel OSX box and is willing to > test as well, let me know. In theory, it should be as simple as a > change to the configure script, but there is no way to tell without > trying it. OK. I've just tried it, and it doesn't work: endianness is wrongly determined by 'configure' when passing '-arch i386 -arch ppc' (or in reverse order) to the CFLAGS in order to build a fat version: when compiling on my ppc, endianness is determined as little, whereas it is big! (If I don't compile it fat, endianness is correct). So, I wonder how your binary could even work on your ppc, if gpg relies on the 'configure' endianness info - tests shouldn't pass. Here's how I invoked configure: env CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 - arch ppc -I/usr/local/include" \ LDFLAGS="-L/usr/local/lib -lusb -Wl,-framework -Wl,IOKit -Wl,- framework -Wl,CoreFoundation -Wl,-prebind" \ ./configure --enable-m-guard --enable-noexecstack --disable- dependency-tracking --with-included-gettext --with-libintl-prefix=/ usr/local --with-libusb=/usr/local --with-readline=/usr/local I grep'd for 'endian' in gpg source code and found several places where code relies on macro 'BIG_ENDIAN_HOST' (cipher/blowfish.c, cipher/md5.c, cipher/rmd160.c, cipher/rndunix.c, cipher/sha1.c, cipher/sha256.ccipher/sha512.c). Problem is that this macro is defined statically, after configure has been executed, whereas it should still be defined dynamically, depending on compiled target; can you change that? > I have to admit, though, I'm not sure what the benefit of a fat GPG > is. The idea behind fat binaries is a good one (companies don't need > to maintain two different products generated from the same source > code, with twice as much space in warehouses, etc). For free software > like GPG that is "shipped" as source, I'm curious where is the > benefit? MacGPG Group provides a binary of gpg for MacOSX; unlike most Linux users, Mac users are not used to build the binaries of everything they want to use; most of them know nothing about command line and code compilation; I agree that building gpg is not difficult, but it's still too frightening for most users, that's why MacGPG provides the fat binary: just download the package, double-click it, and it will install everything for you. Regards, St?phane > David > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel From dshaw at jabberwocky.com Sat Mar 11 18:39:47 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sat Mar 11 18:39:15 2006 Subject: Need help compiling gpgme fat In-Reply-To: References: <87acc47squ.wl%marcus.brinkmann@ruhr-uni-bochum.de> <6D6515FE-5C14-4C57-832A-84817583A38B@sente.ch> <20060305204958.GA11246@jabberwocky.com> Message-ID: <20060311173947.GC30568@jabberwocky.com> On Sat, Mar 11, 2006 at 05:03:34PM +0100, St?phane Corth?sy wrote: > Hi, > > On Mar 5, 2006, at 21:49 , David Shaw wrote: > > >On Sun, Mar 05, 2006 at 06:49:20PM +0100, St?phane Corth?sy wrote: > >>Hi, > >> > >>I've just downloaded latest libtool (1.5.22), and replaced > >>config.guess, config.sub, install-sh and ltmain.sh, applied my > >>previous patch on generated libtool, and now it works :-) I can now > >>build libgpgme for both ppc and intel in one pass/one lib. > >>(maybe my patch is not even needed, I haven't tried yet without it) > >>When will you upgrade your libtool (as well as gpg's, as I guess > >>there is the same problem when trying to compile gpg as fat binary)? > > > >No, GPG doesn't use libtool. In theory, compiling a fat GPG binary is > >pretty simple. The main difficulty is getting the endian stuff for > >the ciphers right (ppc being big, and intel being little). > > > >I'm able to build a fat binary that passes the selftest on my ppc OSX > >box. If you (or anyone here) has an intel OSX box and is willing to > >test as well, let me know. In theory, it should be as simple as a > >change to the configure script, but there is no way to tell without > >trying it. > > > OK. I've just tried it, and it doesn't work: endianness is wrongly > determined by 'configure' when passing '-arch i386 -arch ppc' (or in > reverse order) to the CFLAGS in order to build a fat version: when > compiling on my ppc, endianness is determined as little, whereas it > is big! (If I don't compile it fat, endianness is correct). So, I > wonder how your binary could even work on your ppc, if gpg relies on > the 'configure' endianness info - tests shouldn't pass. I'm not running the stock configure stuff ;) Here's how to do it - edit config.h.in (not config.h) and remove this: /* Defined if the host has big endian byte ordering */ #undef BIG_ENDIAN_HOST and this: /* Defined if the host has little endian byte ordering */ #undef LITTLE_ENDIAN_HOST Then add this: #define BIG_ENDIAN_HOST __BIG_ENDIAN__ #define LITTLE_ENDIAN_HOST __LITTLE_ENDIAN__ Then configure with: ./configure CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386" --disable-dependency-tracking --disable-asm Let me know if this works for you. If you are doing the build on Intel, can you also try this with skipping the -isysroot /Developer/SDKs/MacOSX10.4u.sdk part? Let me know if this works for you (as I said, it builds correctly on ppc and passes the selftest, but I can't test Intel). If it works ok for Intel, I'll include the patch as part of 1.4.3. > >I have to admit, though, I'm not sure what the benefit of a fat GPG > >is. The idea behind fat binaries is a good one (companies don't need > >to maintain two different products generated from the same source > >code, with twice as much space in warehouses, etc). For free software > >like GPG that is "shipped" as source, I'm curious where is the > >benefit? > > MacGPG Group provides a binary of gpg for MacOSX; unlike most Linux > users, Mac users are not used to build the binaries of everything > they want to use; most of them know nothing about command line and > code compilation; I agree that building gpg is not difficult, but > it's still too frightening for most users, that's why MacGPG provides > the fat binary: just download the package, double-click it, and it > will install everything for you. Fair enough. David From stephane at sente.ch Sat Mar 11 19:58:39 2006 From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Sat Mar 11 19:58:26 2006 Subject: Need help compiling gpgme fat In-Reply-To: <878xrn7vnz.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <87acc47squ.wl%marcus.brinkmann@ruhr-uni-bochum.de> <6D6515FE-5C14-4C57-832A-84817583A38B@sente.ch> <878xrn7vnz.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: Hi, On Mar 6, 2006, at 10:46 , Marcus Brinkmann wrote: > At Sun, 5 Mar 2006 18:49:20 +0100, > St?phane Corth?sy wrote: >> I've just downloaded latest libtool (1.5.22), and replaced >> config.guess, config.sub, install-sh and ltmain.sh, applied my >> previous patch on generated libtool, and now it works :-) I can now >> build libgpgme for both ppc and intel in one pass/one lib. >> (maybe my patch is not even needed, I haven't tried yet without it) >> When will you upgrade your libtool (as well as gpg's, as I guess >> there is the same problem when trying to compile gpg as fat binary)? > > Yeah, it seems there is now fatting support in libtool. I have > upgraded libgpg-error now to latest automake and libtool. Thanks. > Can you > please test this from SVN? (See README.CVS for details). OK. Done. I still need to apply my patch (the search path for libs is not correct; it doesn't search for fat libs, only installed libs - which are not fat); I filed a bug report to libtool people, and they are investigating the problem. > If this works for you (without any custom patches), I can update GPGME > as well, for a second test. > > Thanks, > Marcus > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel Regards, St?phane From stephane at sente.ch Sat Mar 11 20:07:58 2006 From: stephane at sente.ch (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Sat Mar 11 20:07:47 2006 Subject: Need help compiling gpgme fat In-Reply-To: <20060311173947.GC30568@jabberwocky.com> References: <87acc47squ.wl%marcus.brinkmann@ruhr-uni-bochum.de> <6D6515FE-5C14-4C57-832A-84817583A38B@sente.ch> <20060305204958.GA11246@jabberwocky.com> <20060311173947.GC30568@jabberwocky.com> Message-ID: Hi, On Mar 11, 2006, at 18:39 , David Shaw wrote: > On Sat, Mar 11, 2006 at 05:03:34PM +0100, St?phane Corth?sy wrote: >> Hi, >> >> On Mar 5, 2006, at 21:49 , David Shaw wrote: >> >>> On Sun, Mar 05, 2006 at 06:49:20PM +0100, St?phane Corth?sy wrote: >>>> Hi, >>>> >>>> I've just downloaded latest libtool (1.5.22), and replaced >>>> config.guess, config.sub, install-sh and ltmain.sh, applied my >>>> previous patch on generated libtool, and now it works :-) I can now >>>> build libgpgme for both ppc and intel in one pass/one lib. >>>> (maybe my patch is not even needed, I haven't tried yet without it) >>>> When will you upgrade your libtool (as well as gpg's, as I guess >>>> there is the same problem when trying to compile gpg as fat >>>> binary)? >>> >>> No, GPG doesn't use libtool. In theory, compiling a fat GPG >>> binary is >>> pretty simple. The main difficulty is getting the endian stuff for >>> the ciphers right (ppc being big, and intel being little). >>> >>> I'm able to build a fat binary that passes the selftest on my ppc >>> OSX >>> box. If you (or anyone here) has an intel OSX box and is willing to >>> test as well, let me know. In theory, it should be as simple as a >>> change to the configure script, but there is no way to tell without >>> trying it. >> >> >> OK. I've just tried it, and it doesn't work: endianness is wrongly >> determined by 'configure' when passing '-arch i386 -arch ppc' (or in >> reverse order) to the CFLAGS in order to build a fat version: when >> compiling on my ppc, endianness is determined as little, whereas it >> is big! (If I don't compile it fat, endianness is correct). So, I >> wonder how your binary could even work on your ppc, if gpg relies on >> the 'configure' endianness info - tests shouldn't pass. > > I'm not running the stock configure stuff ;) > > Here's how to do it - edit config.h.in (not config.h) and remove this: > > /* Defined if the host has big endian byte ordering */ > #undef BIG_ENDIAN_HOST > > and this: > > /* Defined if the host has little endian byte ordering */ > #undef LITTLE_ENDIAN_HOST > > Then add this: > > #define BIG_ENDIAN_HOST __BIG_ENDIAN__ > #define LITTLE_ENDIAN_HOST __LITTLE_ENDIAN__ I finally solved it like that: I modified config.h and added #include #ifdef BIG_ENDIAN && LITTLE_ENDIAN #if BYTE_ORDER==BIG_ENDIAN #define BIG_ENDIAN_HOST 1 #undef LITTLE_ENDIAN_HOST #elif BYTE_ORDER==LITTLE_ENDIAN #undef BIG_ENDIAN_HOST #define LITTLE_ENDIAN_HOST 1 #else #error Unsupported endianness #endif #else #error Endianness macros are undefined! #endif Maybe it's portable for other platforms? > Then configure with: > > ./configure CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch > ppc -arch i386" --disable-dependency-tracking --disable-asm I don't need to disable asm, do I? I didn't and it worked. Actually, I had to use that config line (the one I posted before wasn't correct; system's libreadline is too old, and I need to pass full path to new libreadline; I also need libtermcap): env CFLAGS="-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 - arch ppc -I/usr/local/include" \ LDFLAGS="-L/usr/local/lib -lusb -Wl,-framework -Wl,IOKit -Wl,- framework -Wl,CoreFoundation -Wl,-prebind -ltermcap -Wl,/usr/local/ lib/libreadline.a" \ ./configure --enable-m-guard --enable-noexecstack --disable- dependency-tracking --with-included-gettext --with-libintl-prefix=/ usr/local --with-libusb=/usr/local --with-readline=/usr/local BTW, is it better or not to enable memory-guard and noexecstack? Why aren't they enabled by default? > Let me know if this works for you. It probably does, as it solves the endiannes problem, and doesn't use any special lib. I'll see that tomorrow. > If you are doing the build on > Intel, can you also try this with skipping the > > -isysroot /Developer/SDKs/MacOSX10.4u.sdk > > part? I don't have an Intel; anyway, I think you're right, in that case we don't need the isysroot, because on Intel libs are fat, IIRC. > Let me know if this works for you (as I said, it builds correctly on > ppc and passes the selftest, but I can't test Intel). If it works ok > for Intel, I'll include the patch as part of 1.4.3. > >>> I have to admit, though, I'm not sure what the benefit of a fat GPG >>> is. The idea behind fat binaries is a good one (companies don't >>> need >>> to maintain two different products generated from the same source >>> code, with twice as much space in warehouses, etc). For free >>> software >>> like GPG that is "shipped" as source, I'm curious where is the >>> benefit? >> >> MacGPG Group provides a binary of gpg for MacOSX; unlike most Linux >> users, Mac users are not used to build the binaries of everything >> they want to use; most of them know nothing about command line and >> code compilation; I agree that building gpg is not difficult, but >> it's still too frightening for most users, that's why MacGPG provides >> the fat binary: just download the package, double-click it, and it >> will install everything for you. > > Fair enough. > > David Thanks for your help, St?phane From dshaw at jabberwocky.com Sat Mar 11 20:47:52 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sat Mar 11 20:47:16 2006 Subject: Need help compiling gpgme fat In-Reply-To: References: <87acc47squ.wl%marcus.brinkmann@ruhr-uni-bochum.de> <6D6515FE-5C14-4C57-832A-84817583A38B@sente.ch> <20060305204958.GA11246@jabberwocky.com> <20060311173947.GC30568@jabberwocky.com> Message-ID: <20060311194752.GD30568@jabberwocky.com> On Sat, Mar 11, 2006 at 08:07:58PM +0100, St?phane Corth?sy wrote: > >Here's how to do it - edit config.h.in (not config.h) and remove this: > > > > /* Defined if the host has big endian byte ordering */ > > #undef BIG_ENDIAN_HOST > > > >and this: > > > > /* Defined if the host has little endian byte ordering */ > > #undef LITTLE_ENDIAN_HOST > > > >Then add this: > > > > #define BIG_ENDIAN_HOST __BIG_ENDIAN__ > > #define LITTLE_ENDIAN_HOST __LITTLE_ENDIAN__ > > > I finally solved it like that: I modified config.h and added > > #include > #ifdef BIG_ENDIAN && LITTLE_ENDIAN > #if BYTE_ORDER==BIG_ENDIAN > #define BIG_ENDIAN_HOST 1 > #undef LITTLE_ENDIAN_HOST > #elif BYTE_ORDER==LITTLE_ENDIAN > #undef BIG_ENDIAN_HOST > #define LITTLE_ENDIAN_HOST 1 > #else > #error Unsupported endianness > #endif > #else > #error Endianness macros are undefined! > #endif > > > Maybe it's portable for other platforms? No. There is no guarantee that any of machine/endian.h, BIG_ENDIAN, or LITTLE_ENDIAN exists. If any of those are missing, that code will break. There are safe ways to do this in autoconf. > I don't need to disable asm, do I? I didn't and it worked. On ppc it will work, since there aren't ppc asm modules in the code (it uses straight C). On i386, there are asm modules, so if you compile the fat binary on ppc, it'll work, but if you compile the fat binary on i386 configure will detect the i386 and use the asm modules which would break ppc. --disable-asm fixes all that that and makes the MPI code processor agnostic. > BTW, is it better or not to enable memory-guard and noexecstack? Why > aren't they enabled by default? Experimental and gcc specific. > >Let me know if this works for you. > > It probably does, as it solves the endiannes problem, and doesn't use > any special lib. > I'll see that tomorrow. Ok, let me know. David From marcus.brinkmann at ruhr-uni-bochum.de Mon Mar 13 08:17:36 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Mar 13 08:19:06 2006 Subject: Need help compiling gpgme fat In-Reply-To: References: <87acc47squ.wl%marcus.brinkmann@ruhr-uni-bochum.de> <6D6515FE-5C14-4C57-832A-84817583A38B@sente.ch> <878xrn7vnz.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <87pskq7qzz.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sat, 11 Mar 2006 19:58:39 +0100, St?phane Corth?sy wrote: > I still need to apply my patch (the search path for libs is not > correct; it doesn't search for fat libs, only installed libs - which > are not fat); I filed a bug report to libtool people, and they are > investigating the problem. Ok. Please keep me up to date on this. As soon as we have a solution that works and has some blessing from the libtool maintainers, we can get our libraries fattable. Thanks, Marcus From wk at gnupg.org Thu Mar 9 19:53:40 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Mar 14 00:47:53 2006 Subject: [Announce] GnuPG does not detect injection of unsigned data Message-ID: <87d5gvh2kr.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 wk at gnupg.org Thu Mar 9 19:53:40 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Mar 14 03:23:12 2006 Subject: [Announce] GnuPG does not detect injection of unsigned data Message-ID: <87d5gvh2kr.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 marcus.brinkmann at ruhr-uni-bochum.de Tue Mar 14 14:00:34 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Tue Mar 14 14:20:38 2006 Subject: [Announce] libgpg-error 1.3 released Message-ID: <87hd616v0t.wl%marcus.brinkmann@ruhr-uni-bochum.de> Hi, We are pleased to announce version 1.3 of libgpg-error, a library for common error values and messages in GnuPG components. This is a shared library so it can be updated independently of each individual component, while still allowing the use of new error values in inter-process communication. It may be found in the file (about 561 KB/441 KB compressed) ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.3.tar.gz ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.3.tar.bz2 The following files are also available: ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.3.tar.gz.sig ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.3.tar.bz2.sig ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.2-1.3.diff.gz It should soon appear on the mirrors listed at: http://www.gnupg.org/mirrors.html Bug reports and requests for assistance should be sent to: gnupg-devel@gnupg.org The sha1sum checksums for this distibution are 8f354d70a54ec2d9f8d24b43237c08165ed19478 libgpg-error-1.2-1.3.diff.gz 10bd8d8503b674e114ecc6620324d5d1c8c918b7 libgpg-error-1.3.tar.bz2 2b46aed8b21703bcbbdc85b696b37b0d528046fb libgpg-error-1.3.tar.bz2.sig 6c7425b3634af05a0314287fff7ba13010c4c26a libgpg-error-1.3.tar.gz 4c3ab083706a21a30ffd2bd06989ecd3d9b6db17 libgpg-error-1.3.tar.gz.sig Noteworthy changes in version 1.3 (2006-03-14) ---------------------------------------------- * GNU gettext is included for systems that do not provide it. Marcus Brinkmann mb@g10code.de _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From npcole at yahoo.co.uk Tue Mar 14 14:16:38 2006 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Tue Mar 14 15:56:23 2006 Subject: OpenPGP spec as manpage Message-ID: <20060314131638.32790.qmail@web26711.mail.ukl.yahoo.com> Could I make a quick request? Would it make sense for the latest version of the OpenPGP spec to be distributed with gpg - perhaps even as a manpage. I know that I would find it useful, and perhaps other people would too. Best wishes, Nicholas ___________________________________________________________ Yahoo! Photos ? NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com From atom at smasher.org Tue Mar 14 17:30:48 2006 From: atom at smasher.org (Atom Smasher) Date: Tue Mar 14 19:26:22 2006 Subject: OpenPGP spec as manpage In-Reply-To: <20060314131638.32790.qmail@web26711.mail.ukl.yahoo.com> References: <20060314131638.32790.qmail@web26711.mail.ukl.yahoo.com> Message-ID: <20060314163051.14955.qmail@smasher.org> On Tue, 14 Mar 2006, Nicholas Cole wrote: > Could I make a quick request? Would it make sense for the latest > version of the OpenPGP spec to be distributed with gpg - perhaps even as > a manpage. I know that I would find it useful, and perhaps other people > would too. ================== i suspect that if you (or someone else) formats the spec as a man page, they'll have no objections to including it. -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "I am a great mayor; I am an upstanding Christian man; I am an intelligent man; I am a deeply educated man; I am a humble man." -- Marion Barry Mayor, Washington, D.C From wk at gnupg.org Wed Mar 15 12:42:33 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Mar 15 12:47:01 2006 Subject: OpenPGP spec as manpage In-Reply-To: <20060314131638.32790.qmail@web26711.mail.ukl.yahoo.com> (Nicholas Cole's message of "Tue, 14 Mar 2006 13:16:38 +0000 (GMT)") References: <20060314131638.32790.qmail@web26711.mail.ukl.yahoo.com> Message-ID: <87bqw86ija.fsf@wheatstone.g10code.de> On Tue, 14 Mar 2006 13:16:38 +0000 (GMT), Nicholas Cole said: > Could I make a quick request? Would it make sense for > the latest version of the OpenPGP spec to be > distributed with gpg - perhaps even as a manpage. I RFCs are available at several places and thus it makes not much sense to distribute them again. I-Ds (Internet drafts) even expire after 6 months and MUST not be referenced at all. Shalom-Salam, Werner From lionel at mamane.lu Thu Mar 16 09:35:07 2006 From: lionel at mamane.lu (Lionel Elie Mamane) Date: Thu Mar 16 09:34:22 2006 Subject: OpenPGP spec as manpage In-Reply-To: <87bqw86ija.fsf@wheatstone.g10code.de> References: <20060314131638.32790.qmail@web26711.mail.ukl.yahoo.com> <87bqw86ija.fsf@wheatstone.g10code.de> Message-ID: <20060316083507.GA7969@capsaicin.mamane.lu> On Wed, Mar 15, 2006 at 12:42:33PM +0100, Werner Koch wrote: > On Tue, 14 Mar 2006 13:16:38 +0000 (GMT), Nicholas Cole said: >> Could I make a quick request? Would it make sense for >> the latest version of the OpenPGP spec to be >> distributed with gpg - perhaps even as a manpage. I > RFCs are available at several places and thus it makes not much > sense to distribute them again. Well, it is convenient to have the standard with the (source of) the implementation. But I've the license of the RFCs is non-free these days. Would the GNU project want to distribute them? -- Lionel From fret at memecode.com Fri Mar 17 01:06:12 2006 From: fret at memecode.com (Matthew Allen) Date: Fri Mar 17 02:56:28 2006 Subject: Homedir problem Message-ID: I downloaded the latest gpg (gnupg-w32cli-1.4.2.2.exe) and I'm having an issue when I combine --homedir and --list-secret-keys, e.g. C:\Documents and Settings\matthew\Desktop\spanish-test\GnuPG>gpg --list-secret-keys --homedir "." C:\Documents and Settings\matthew\Desktop\spanish-test\GnuPG>gpg --list-secret-keys C:/Documents and Settings/matthew/Application Data/gnupg\secring.gpg -------------------------------------------------------------------- sec 1024D/CCAA6006 2006-03-16 uid Matthew Allen (Myself) ssb 2048g/1F0FD55A 2006-03-16 When I combine --homedir and --list-secret-keys it lists nothing, however when I just use --list-secret-keys it works fine. Whats up with that? regards -- Matthew Allen From jerojasro at gmail.com Mon Mar 13 00:19:18 2006 From: jerojasro at gmail.com (Javier Rojas) Date: Mon Mar 20 18:59:46 2006 Subject: make check of gnupg 1.9.20 fails Message-ID: <200603121819.21294.jerojasro@gmail.com> Hi, I'm trying to make KMail to cipher my emails... so far I've only made it to sign them, not ciphering them. I have readed that I must have gpg-agent installed, which is why I'm writing to you when compiling gnupg 1.9.20, and making the test, they fail (and ask me to email you... :) Here is the output ==================== %< ==================== make check-TESTS make[2]: Entering directory `/home/jerojasro/Desktop/gnupg-1.9.20/tests' asschk: read_assuan: received incomplete line on fd 7 FAIL: sm-sign+verify asschk: read_assuan: received incomplete line on fd 5 FAIL: sm-verify ====================================== 2 of 2 tests failed Please report to gnupg-devel@gnupg.org ====================================== ==================== %< ==================== Other info perhaps useful: Distro: Slackware 10.2 GPG: 1.4.2.2 libassuan-0.6.10 libgcrypt-1.2.2 libgpg-error-1.2 libksba-0.9.13 pinentry-0.7.2 pth-2.0.6 Perhaps the most important thing is that, after all, decryption works properly, despite the tests Greets, -- Javier Rojas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available Url : /pipermail/attachments/20060312/c5fb14dd/attachment.pgp From marcus.brinkmann at ruhr-uni-bochum.de Mon Mar 20 20:17:05 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Mar 20 20:18:51 2006 Subject: gpgme memory leak? What's wrong? In-Reply-To: <200602271941.46142.vladimir@sycore.org> References: <200602271941.46142.vladimir@sycore.org> Message-ID: <87y7z553ke.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 27 Feb 2006 19:41:45 +0300, "Vladimir S. Petukhov" wrote: > GpgmeCtx gpgme_ctx; > gpgme_new (&gpgme_ctx); > gpgme_set_textmode (gpgme_ctx, 1); > gpgme_set_armor (gpgme_ctx, 1); > gpgme_set_passphrase_cb (gpgme_ctx, &passphrase_cb, NULL); > while (true) { > > gpgme_data_new_from_mem (&gpgme_data_in, "test", 5, 0); > gpgme_data_new (&gpgme_data_out); > gpgme_op_sign gpgme_data_out, GPGME_SIG_MODE_CLEAR); > gpgme_data_release (gpgme_data_out); > gpgme_data_release (gpgme_data_in); > } > gpgme_release (gpgme_ctx); > > > .. sign mesage well, but allocate memory incrementally. > What's wrong? (version 1.4.2) The code you quoted is not valid C code. After fixing the syntactical errors, I produced the below version, which runs fine without any memory leaks. If you give me a self-standing, compiling source code file, I can try it out as well. You can also try running valgrind on your program. gpgme_new (&gpgme_ctx); gpgme_set_textmode (gpgme_ctx, 1); gpgme_set_armor (gpgme_ctx, 1); gpgme_set_passphrase_cb (gpgme_ctx, passphrase_cb, NULL); while (1) { gpgme_data_new_from_mem (&gpgme_data_in, "test", 5, 0); gpgme_data_new (&gpgme_data_out); gpgme_op_sign (gpgme_ctx, gpgme_data_in, gpgme_data_out, GPGME_SIG_MODE_CLEAR); gpgme_data_release (gpgme_data_out); gpgme_data_release (gpgme_data_in); } gpgme_release (gpgme_ctx); return 0; Thanks, Marcus From christianbiere at gmx.de Mon Mar 20 21:21:32 2006 From: christianbiere at gmx.de (Christian Biere) Date: Mon Mar 20 21:21:14 2006 Subject: gpgme memory leak? What's wrong? In-Reply-To: <87y7z553ke.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <200602271941.46142.vladimir@sycore.org> <87y7z553ke.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <20060320202132.GA8304@cyclonus> Marcus Brinkmann wrote: > At Mon, 27 Feb 2006 19:41:45 +0300, > "Vladimir S. Petukhov" wrote: > The code you quoted is not valid C code. Neither is yours. Obviously, the code was compiled with an ISO C99 compiler which defines "true". Real men use "for (;;)" of course. The address operator before a function name is redundant. Identation style has nothing to do with validity and is not defined by any revision of the C standard. That said the GNU style is rather unpopular. What is missing, though, is a main function, #include lines, variable and function declarations. > After fixing the syntactical errors, I produced the below version, > which runs fine without any memory leaks. No, the real issue have not been fixed at all. > If you give me a self-standing, compiling source code file, I can try > it out as well. You can also try running valgrind on your program. *flame thrower off* Okay, you have a point here. -- Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : /pipermail/attachments/20060320/b78316be/attachment.pgp From michael at vorlon.ping.de Mon Mar 20 20:25:22 2006 From: michael at vorlon.ping.de (Michael Bienia) Date: Mon Mar 20 22:26:24 2006 Subject: Bug in gpg-agent? [fwd: Re: OpenPGP card and signing] Message-ID: <20060320192521.GA4470@vorlon.ping.de> Hello, can a developer comment on this? Short summary: We want to use an OpenPGP card for signing. When using gpg with gpg-agent only SHA1 as hash algorithm generates a valid signature. gpg without gpg-agent generates for both RIPEMD160 and SHA1 valid signatures. As a we also want use the OpenPGP card for ssh authentication we are reliant on the use of gpg-agent. Thanks, Michael ----- Forwarded message from Daniel Hess ----- Date: Wed, 15 Mar 2006 18:10:28 +0100 Subject: Re: OpenPGP card and signing From: Daniel Hess To: gnupg-users@gnupg.org Hello, as my last mail did not get through, here is a new one (maybe the list-moderators could drop the old one). On Tue, Mar 14, 2006 at 11:42:52PM +0100, Michael Bienia wrote: > On 2006-03-14 08:23:58 +0100, Remco Post wrote: > > Michael Bienia wrote: > > > does signing with the OpenPGP card only work with SHA1 as digest-algo? > > > > > > With SHA1 and RIPEMD160 gpg asks for the PIN but only SHA1 generates a > > > working signature. Trying RIPEMD160 I get: > > > | gpg: checking created signature failed: bad signature > > > | gpg: signing failed: bad signature > > > | gpg: signing failed: bad signature > > > > > > > From the basiccard website I read that it only supports sha-1, so this > > might be true. I noticed the same just recently. The "OpenPGP Card 1.1" specification mentions that ripemd as digest (page 35). > A friend who uses his OpenPGP card with enigmail under windows can > successfully create a RIPEMD160 signature. > I could also create one if I use gpg with pcscd. I could do even without pcscd. > Can someone explain me, why it works if I use gpg with pcscd and not if > I use gpg alone? What Michael has not mentioned was, that he (as well as i) do use gpg-agent. Using the agent enables openssh to use the key for public-key auth. When using the --use-agent switch (with gpg), the agent will communicate to the openpgp card using scdaemon. To sign a message gpg will send an PKSIGN command along with the Data to sign (e.g. the fingerprint of an message). What is missing is the information about which digest (e.g. sha1 or ripemd160) has been used to create the fingerprint that should be signed by scdaemon. In scd/command.c PKSIGN gets mapped to the function cmd_pksig which sets sha1 as digest when calling app_sign. As this information gets part of the pgp block which contains the signed data a sha1 signature with the ripemd160 hash is created. This obviously ends in a bad signature. Altering the call to app_sign by replacing GCRY_MD_SHA1 with GCRY_MD_RMD160 enables gpg to create valid ripemd160 signatures, but also make it impossible to create sha1 signatures. Maybe gpg and gpg-agent could get altered to pass the digest along with the call to PKSIGN? This would be a real improvement :) Hope that one of the gnupg developers can say something about this. TIA Daniel _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users ----- End forwarded message ----- From marcus.brinkmann at ruhr-uni-bochum.de Mon Mar 20 23:33:26 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Mar 20 23:33:56 2006 Subject: gpgme memory leak? What's wrong? In-Reply-To: <20060320202132.GA8304@cyclonus> References: <200602271941.46142.vladimir@sycore.org> <87y7z553ke.wl%marcus.brinkmann@ruhr-uni-bochum.de> <20060320202132.GA8304@cyclonus> Message-ID: <87veu8691l.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 20 Mar 2006 21:21:32 +0100, Christian Biere wrote: > > Marcus Brinkmann wrote: > > At Mon, 27 Feb 2006 19:41:45 +0300, > > "Vladimir S. Petukhov" wrote: > > The code you quoted is not valid C code. > > Neither is yours. The difference is that I don't see any leaks, thus I do not need to help others reproducing a bug. The main problem I had with Vladimirs code snippet was that it did not show the passphrase callback (which may do allocation), and that it contained an obviously broken line: > gpgme_op_sign gpgme_data_out, GPGME_SIG_MODE_CLEAR); which raises doubts if I could faithfully reproduce his test case. In fact, because I did not see any memory leak, I am sure I could not reproduce his test case. If your mail was sarcasm, I didn't get it. I lost my funny hat ;) Thanks, Marcus From schierlm at gmx.de Mon Mar 20 23:14:49 2006 From: schierlm at gmx.de (Michael Schierl) Date: Tue Mar 21 00:56:39 2006 Subject: Homedir problem In-Reply-To: References: Message-ID: <441F2959.1010102@gmx.de> Matthew Allen schrieb: > I downloaded the latest gpg (gnupg-w32cli-1.4.2.2.exe) and I'm having an issue when I combine --homedir and --list-secret-keys, e.g. > > C:\Documents and Settings\matthew\Desktop\spanish-test\GnuPG>gpg --list-secret-keys --homedir "." > > C:\Documents and Settings\matthew\Desktop\spanish-test\GnuPG>gpg --list-secret-keys > C:/Documents and Settings/matthew/Application Data/gnupg\secring.gpg > -------------------------------------------------------------------- > sec 1024D/CCAA6006 2006-03-16 > uid Matthew Allen (Myself) > ssb 2048g/1F0FD55A 2006-03-16 > > When I combine --homedir and --list-secret-keys it lists nothing, however when I just use --list-secret-keys it works fine. Your home directory is different from "." (the current directory). And there are no secret keys in your latter secring.gpg. homedir: C:\Documents and Settings\matthew\Application Data\gnupg your current directory: C:\Documents and Settings\matthew\Desktop\spanish-test\GnuPG "cd" to your homedir first and it will work (it does at least for me). Michael From ahasenack at terra.com.br Tue Mar 21 01:18:53 2006 From: ahasenack at terra.com.br (Andreas Hasenack) Date: Tue Mar 21 02:56:25 2006 Subject: make check of gnupg 1.9.20 fails In-Reply-To: <200603121819.21294.jerojasro@gmail.com> References: <200603121819.21294.jerojasro@gmail.com> Message-ID: <200603202118.53828.ahasenack@terra.com.br> Em Dom 12 Mar 2006 20:19, Javier Rojas escreveu: > Hi, > I'm trying to make KMail to cipher my emails... so far I've only made it to > sign them, not ciphering them. I have readed that I must have gpg-agent > installed, which is why I'm writing to you > > when compiling gnupg 1.9.20, and making the test, they fail (and ask me to > email you... :) Here is the output > > ==================== %< ==================== > make check-TESTS > make[2]: Entering directory `/home/jerojasro/Desktop/gnupg-1.9.20/tests' > asschk: read_assuan: received incomplete line on fd 7 > FAIL: sm-sign+verify > asschk: read_assuan: received incomplete line on fd 5 > FAIL: sm-verify > ====================================== > 2 of 2 tests failed > Please report to gnupg-devel@gnupg.org What arch is this? x86_64 perhaps? From wk at gnupg.org Tue Mar 21 13:35:49 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Mar 21 13:42:02 2006 Subject: Bug in gpg-agent? [fwd: Re: OpenPGP card and signing] In-Reply-To: <20060320192521.GA4470@vorlon.ping.de> (Michael Bienia's message of "Mon, 20 Mar 2006 20:25:22 +0100") References: <20060320192521.GA4470@vorlon.ping.de> Message-ID: <877j6o9dqy.fsf@wheatstone.g10code.de> On Mon, 20 Mar 2006 20:25:22 +0100, Michael Bienia said: > We want to use an OpenPGP card for signing. When using gpg with > gpg-agent only SHA1 as hash algorithm generates a valid signature. gpg > without gpg-agent generates for both RIPEMD160 and SHA1 valid > signatures. I just added support for Ripemd-160 to the svn version. Please update gnupg 1.9[1] as well as gnupg 1.4[2] from Subversion. Shalom-Salam, Werner [1] svn://cvs.gnupg.org/gnupg/branches/GNUPG-1-9-BRANCH [2] svn://cvs.gnupg.org/gnupg/trunk From wk at gnupg.org Tue Mar 21 20:17:34 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Mar 21 20:36:08 2006 Subject: [Announce] GPA 0.7.3 released Message-ID: <87wten1ub5.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 ed at fxq.nl Mon Mar 20 23:16:41 2006 From: ed at fxq.nl (Ed Schouten) Date: Wed Mar 22 13:38:50 2006 Subject: [mutt+gpg-agent+pinentry] command get_passphrase failed: Unknown system error Message-ID: <20060320221641.GA55527@hoeg.nl> Hello GnuPG folks, This afternoon, I decided to tamper around with GPGME on my FreeBSD 7.0-CURRENT box, using Mutt 1.5.11. The FreeBSD port didn't support the --enable-gpgme flag, so I patched the port and sent the patch to the FreeBSD camp: http://www.freebsd.org/cgi/query-pr.cgi?pr=94745 The cool thing is that reading email works like a charm. Mutt prints messages like these: | [-- Begin signature information --] | Good signature from: Ed Schouten | created: Mon Mar 20 19:25:46 2006 | [-- End signature information --] Because sending email would also come in handy, I installed pinentry. After finally getting gpg-agent and pinentry up and running, I still can't send any email with Mutt. When I compose a new message, which is signed by Mutt and press the 'y' button (send), I get a fancy pinentry dialog. For some reason, gpg-agent cannot figure out the passphrase. Mutt shows the following error: | error signing data: Bad passphrase? gpg-agent logs the following message: | 2006-03-20 22:57:18 gpg-agent[62511] command get_passphrase failed: Unknown system error I looked through the gpg-agent sourcecode and added some log_error()'s to it. A faulty return value is raised in the following piece of code in query.c, line 516: | assuan_begin_confidential (entry_ctx); | rc = assuan_transact (entry_ctx, "GETPIN", getpin_cb, &parm, NULL, NULL, NULL, NULL); | if (rc) | { | xfree (parm.buffer); | return unlock_pinentry (map_assuan_err (rc)); | } assuan_transact() returns a non-zero value. I tried using the pinentry utility from the console, but GETPIN works okay. Is this a known issue? -- Ed Schouten WWW: http://g-rave.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060320/172537df/attachment.pgp From ed at fxq.nl Tue Mar 21 17:18:56 2006 From: ed at fxq.nl (Ed Schouten) Date: Wed Mar 22 13:38:54 2006 Subject: [mutt+gpg-agent+pinentry] command get_passphrase failed: Unknown system error In-Reply-To: <20060320221641.GA55527@hoeg.nl> References: <20060320221641.GA55527@hoeg.nl> Message-ID: <20060321161856.GF55527@hoeg.nl> * Ed Schouten wrote: > Because sending email would also come in handy, I installed pinentry. > After finally getting gpg-agent and pinentry up and running, I still > can't send any email with Mutt. > > When I compose a new message, which is signed by Mutt and press the 'y' > button (send), I get a fancy pinentry dialog. For some reason, gpg-agent > cannot figure out the passphrase. Mutt shows the following error: > > | error signing data: Bad passphrase? > > gpg-agent logs the following message: > > | 2006-03-20 22:57:18 gpg-agent[62511] command get_passphrase failed: Unknown system error > > I looked through the gpg-agent sourcecode and added some log_error()'s > to it. A faulty return value is raised in the following piece of code in > query.c, line 516: > > | assuan_begin_confidential (entry_ctx); > | rc = assuan_transact (entry_ctx, "GETPIN", getpin_cb, &parm, NULL, NULL, NULL, NULL); > | if (rc) > | { > | xfree (parm.buffer); > | return unlock_pinentry (map_assuan_err (rc)); > | } > > assuan_transact() returns a non-zero value. I tried using the pinentry > utility from the console, but GETPIN works okay. Is this a known issue? It looks like I found the bug. I built the GTK2 version of the pinentry application instead of the curses one and that one works fine. The bug is probably in the pinentry curses code. Yours, -- Ed Schouten WWW: http://g-rave.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060321/50ed63f3/attachment.pgp From acarrico at memebeam.org Thu Mar 23 03:15:29 2006 From: acarrico at memebeam.org (Anthony Carrico) Date: Thu Mar 23 04:26:31 2006 Subject: --raw-sign, --raw-verify Message-ID: <20060323021529.GA14889@memebeam.org> I'm working on a raw signature patch in a local svk branch of GnuPG's svn repository. Here is my design document. If I am successful, I intend to provide this as a public domain patch, which I hope might be accepted into the official sources. Please provide any feedback, especially if I have missed something obvious. Thank you! SUMMARY The OpenPGP key infrastructure is a very valuable resource, but OpenPGP packets are not the appropriate container in every authentication protocol. Raw sign and verify commands would allow other authentication protocols to capitalize on the OpenPGP key infrastructure and the GnuPG implementation. MOTIVATION Our motivating case was xmldsig (http://www.w3.org/TR/xmldsig-core/). Xmldsig is an authentication protocol, like OpenPGP, but it uses an XML syntax instead of the OpenPGP packet syntax. Briefly, the xmldsig syntax has SignedInfo and SignatureValue elements. The SignedInfo is transformed (hashed, etc.) and then signed to create the SignatureValue. Like OpenPGP, xmldsig is flexible about which algorithms it can use, and so we originally attempted to define the OpenPGP packet as a signature algorithm for xmldsig. In this initial attempt, we canonicalized the SignedInfo and passed it to GnuPG and deemed the resulting OpenPGP packet to be our SignatureValue--we defined OpenPGP packets to be a SignatureMethod. One problem with this method was that the OpenPGP packet would actually be a signature over more data than would be apparent in the SignedInfo. In particular, a timestamp and other data specified in the OpenPGP spec would also be signed. This would be a semantic error, since all of the signed data should be apparent in the SignedInfo element. A cleaner, more correct, solution would be to use a DSA key (for example) from an OpenPGP key to produce a raw DSA signature (for example). The only "patch free" way to accomplish this with GnuPG would be to export a key and run the algorithm(s) externally. This seemed to be unwise, since it would bypass and duplicate the most important aspects of the GnuPG and GnuPG-agent implementations. A -raw patch seemed to be the best option. DESIGN We desire simpler subsets of the "--detach-sign" and "--verify" command pair. This is the existing v3 "--detach-sign" command: create-V3-sig-packet( sig-algo( hash-algo( concatenate(MESSAGE-DATA, signature type, creation time))), ...) -> DETACHED-SIGNATURE Where MESSAGE-DATA is user input and DETACHED-SIGNATURE is user output. We desire the following new "--raw-sign" signature command: hash-algo(MESSAGE-DATA) -> MESSAGE-DIGEST sig-algo(MESSAGE-DIGEST) -> RAW-SIGNATURE Where MESSAGE-DATA is user input and both MESSAGE-DIGEST and RAW-SIGNATURE are user output. We also desire the following "--raw-sign-md" command: sig-algo(MESSAGE-DIGEST) -> RAW-SIGNATURE Where MESSAGE-DIGEST is user input and RAW-SIGNATURE is user output. We also desire the corresponding "--raw-verify" and "--raw-verify-md" commands. In some sense, the desired new commands are similar to the existing "--print-md" command which exposes the raw hash algorithms. USER INTERFACE The raw commands could be implemented as options of the --detach-sign/--verify pair, or with new commands. The GnuPG manual's "kludge" comment about the --textmode option, prompted us to choose new commands rather than adding options. The first command pair correspond to the existing --detach-sign and --verify commands: --raw-sign file [files] Make a raw signature of the given message data. The output is a raw signature, defined by the signature algorithm, and not an OpenPGP packet. The message digest is also available on the status fd. --raw-verify sigfile [signed-files] Assume that sigfile is a raw signature and verify it without generating any output. If only a sigfile is given then the message data is expected in a file without the final extension. With more than 1 argument, the first should be a raw signature and the remaining files are the message data. To read the message data from stdin, use - as the second filename. For security reasons, a raw signature cannot read the message data from stdin without denoting it in the above way. The message digest is also available on the status fd. The second pair differ in that they work with a message digest instead of message data: --raw-sign-md md-file Make a raw signature of the given message digest. The output is a raw signature, defined by the signature algorithm, and not an OpenPGP packet. The message digest must be compatible with the signature algorithm. --raw-verify-md sigfile [md-file] Assume that sigfile is a raw signature and verify it without generating any output. If only a sigfile is given then the message digest is expected in a file without the final extension. With two arguments, the first should be a raw signature and the second the message digest. To read the message digest from stdin, use - as the second filename. For security reasons a raw signature cannot read the message digest from stdin without denoting it in the above way. -- Anthony Carrico http://giftfile.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20060322/87012994/attachment.pgp From james at ryley.com Thu Mar 23 07:15:45 2006 From: james at ryley.com (James) Date: Thu Mar 23 11:35:48 2006 Subject: Suggestion for http://lists.gnupg.org/pipermail/gnupg-devel/2003-August/020389.html Message-ID: <200603230615.k2N6Fjso019944@smtp.ryley.com> Hi, I saw that you have a link to the USPTO's search engine and I wanted to let you know about www.FreePatentsOnline.com. FreePatentsOnline.com has free PDF downloading, European data in addition to U.S. data, and free accounts to allow you to organize patent searches. Overall, it is much more powerful than the USPTO's search, and more features are planned for the near future. Sincerely, James From rjh at sixdemonbag.org Fri Mar 24 22:43:18 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat Mar 25 00:26:25 2006 Subject: Order of keyserver results Message-ID: <442467F6.1060704@sixdemonbag.org> While trying to write code to fetch keys from a keyserver automagically, I ran across this case while doing testing. Options were the standard stuff for machine-readable output--fixed-list-mode and --with-colons. * * * * * gpg: searching for "0xDEADBEEF" from hkp server random.sks.keyserver.penguin.de info:1:5 pub:DEADBEEF:1:2048:933688385:: uid:Imad R. Faiad:933688385:: pub:DEADBEEF:17:1024:925285688:: uid:Imad R. Faiad:934573220:: uid:Preston Wilson ::: pub:DEADBEEF:1:384:1080720427:: pub:DEADBEEF:1:1024:812327879:: pub:DEADBEEF:17:1024:980061169:: uid:Imad R. Faiad::: uid:Preston Wilson :993420630:: * * * * * My question here is... why are the UIDs and pub identifiers not interleaved? In all the other tests I ran, they came out neatly interleaved, which made it easy to figure out which pub row was associated with each uid row. What's the proper way to parse this? Should I just create two arrays, one for pub and one for uid, store them as they come in and then assume that pub[x] is associated with uid[x]? From dshaw at jabberwocky.com Sat Mar 25 00:59:36 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sat Mar 25 00:59:08 2006 Subject: Order of keyserver results In-Reply-To: <442467F6.1060704@sixdemonbag.org> References: <442467F6.1060704@sixdemonbag.org> Message-ID: <20060324235936.GA25793@jabberwocky.com> On Fri, Mar 24, 2006 at 03:43:18PM -0600, Robert J. Hansen wrote: > While trying to write code to fetch keys from a keyserver automagically, > I ran across this case while doing testing. Options were the standard > stuff for machine-readable output--fixed-list-mode and --with-colons. > > * * * * * > > gpg: searching for "0xDEADBEEF" from hkp server > random.sks.keyserver.penguin.de > info:1:5 > pub:DEADBEEF:1:2048:933688385:: > uid:Imad R. Faiad:933688385:: > pub:DEADBEEF:17:1024:925285688:: > uid:Imad R. Faiad:934573220:: > uid:Preston Wilson ::: > pub:DEADBEEF:1:384:1080720427:: > pub:DEADBEEF:1:1024:812327879:: > pub:DEADBEEF:17:1024:980061169:: > uid:Imad R. Faiad::: > uid:Preston Wilson :993420630:: > > * * * * * > > My question here is... why are the UIDs and pub identifiers not > interleaved? In all the other tests I ran, they came out neatly > interleaved, which made it easy to figure out which pub row was > associated with each uid row. Believe it or not, those are interleaved. The problem is that in the keyserver database, some keys have no uids. Every time you see "pub" that indicates the start of a new key. There may or may not be any uids attached. Try searching for 0xDEADBEEF from the regular web interface and you'll see the same thing. David From ueno at unixuser.org Tue Mar 28 03:37:43 2006 From: ueno at unixuser.org (Daiki Ueno) Date: Tue Mar 28 04:56:26 2006 Subject: Missing newline before status line Message-ID: <10a64b32-6d65-474b-82ca-9d18402bc644@well-done.deisui.org> Hello, I found a small oddity of --status-fd output when --command-fd is specified. $ touch test.txt test.txt.gpg $ gpg --status-fd 1 --command-fd 0 --symmetric test.txt [GNUPG:] NEED_PASSPHRASE_SYM 3 3 2 [GNUPG:] GET_HIDDEN passphrase.enter test [GNUPG:] GOT_IT File `test.txt.gpg' exists. [GNUPG:] GET_BOOL openfile.overwrite.okay y "[GNUPG:]" should appear as the prefix of the line. The attached patch will fix this. -------------- next part -------------- A non-text attachment was scrubbed... Name: openfile.c.diff Type: application/octet-stream Size: 425 bytes Desc: not available Url : /pipermail/attachments/20060328/6558fc34/openfile.c.obj -------------- next part -------------- Regards, -- Daiki Ueno From wk at gnupg.org Tue Mar 28 09:09:58 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Mar 28 09:11:43 2006 Subject: Missing newline before status line In-Reply-To: <10a64b32-6d65-474b-82ca-9d18402bc644@well-done.deisui.org> (Daiki Ueno's message of "Tue, 28 Mar 2006 10:37:43 +0900") References: <10a64b32-6d65-474b-82ca-9d18402bc644@well-done.deisui.org> Message-ID: <87ek0ncaex.fsf@wheatstone.g10code.de> On Tue, 28 Mar 2006 10:37:43 +0900, Daiki Ueno said: > "[GNUPG:]" should appear as the prefix of the line. > The attached patch will fix this. Thanks, Werner From ueno at unixuser.org Tue Mar 28 11:50:40 2006 From: ueno at unixuser.org (Daiki Ueno) Date: Tue Mar 28 11:49:59 2006 Subject: Missing newline before status line In-Reply-To: <87ek0ncaex.fsf@wheatstone.g10code.de> (Werner Koch's message of "Tue, 28 Mar 2006 09:09:58 +0200") References: <10a64b32-6d65-474b-82ca-9d18402bc644@well-done.deisui.org> <87ek0ncaex.fsf@wheatstone.g10code.de> Message-ID: <89b338d3-8304-471a-b88f-bde1f50a2f7e@well-done.deisui.org> Hello Werner, >>>>> In <87ek0ncaex.fsf@wheatstone.g10code.de> >>>>> Werner Koch wrote: > On Tue, 28 Mar 2006 10:37:43 +0900, Daiki Ueno said: > > "[GNUPG:]" should appear as the prefix of the line. > > The attached patch will fix this. Sorry, I missed that ttyio is used. This is not a bug. Please ignore. Regards, -- Daiki Ueno From ueno at unixuser.org Tue Mar 28 12:19:14 2006 From: ueno at unixuser.org (Daiki Ueno) Date: Tue Mar 28 12:18:29 2006 Subject: Request for new status code for signing Message-ID: Hello, As you may know, I recently changed the Emacs frontend of GnuPG (pgg.el) to utilize --status-fd output much more. When testing this code, Simon Josefsson found that there was no way to wait until all passphrase are ready for signing. http://article.gmane.org/gmane.emacs.devel/52063 May I request new status code to mark the beginning of the actual signing process? Sample patch is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: sign.diff Type: application/octet-stream Size: 1829 bytes Desc: not available Url : /pipermail/attachments/20060328/f4f830b0/sign.obj -------------- next part -------------- Regards, -- Daiki Ueno From 8 at iki.fi Tue Mar 28 15:40:31 2006 From: 8 at iki.fi (8@iki.fi) Date: Tue Mar 28 16:56:30 2006 Subject: Windows installation crashes Message-ID: <44293CCF.5090306@iki.fi> I uninstalled version 1.4.2 via the Control Panel (of Windows 98SE) and ran gnupg-w32cli-1.4.2.2.exe thereafter. If I choose NLS in the installation wizard, the program crashes after I press Next. I get the following details: GNUPG-W32CLI-1 caused a general protection fault in module KRNL386.EXE at 0002:00005c48. Registers: EAX=1887000a CS=014f EIP=00005c48 EFLGS=00000297 EBX=00760239 SS=11c7 ESP=000082ea EBP=000082fc ECX=0000fff9 DS=1887 ESI=00000000 FS=124f EDX=00010005 ES=0177 EDI=00000240 GS=0000 Bytes at CS:EIP: f2 ae e9 a9 ff 33 c0 33 d2 e9 05 00 47 8b c7 8c Stack dump: 124f015f 023f15ff 18870005 00050000 830c0005 00005a92 00291887 20000177 83240177 00005941 00001887 15ff67bf 15ff124f 83308340 8444581b 20005209 From wk at gnupg.org Tue Mar 28 20:07:40 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Mar 28 20:11:47 2006 Subject: Request for new status code for signing In-Reply-To: (Daiki Ueno's message of "Tue, 28 Mar 2006 19:19:14 +0900") References: Message-ID: <87acbabfyr.fsf@wheatstone.g10code.de> On Tue, 28 Mar 2006 19:19:14 +0900, Daiki Ueno said: > As you may know, I recently changed the Emacs frontend of GnuPG > (pgg.el) to utilize --status-fd output much more. When testing this > code, Simon Josefsson found that there was no way to wait until all Seems that I need to switch to SVN Emacs again. > http://article.gmane.org/gmane.emacs.devel/52063 > May I request new status code to mark the beginning of the actual > signing process? Okay. However you might get into a similar problem with decryption. So what about something like STATUS_SECRETKEY_READR and you can match on this and eventually ignore GOOD_PASSPHRASE. Shalom-Salam, Werner From ueno at unixuser.org Wed Mar 29 11:03:35 2006 From: ueno at unixuser.org (Daiki Ueno) Date: Wed Mar 29 11:03:24 2006 Subject: Request for new status code for signing In-Reply-To: <87acbabfyr.fsf@wheatstone.g10code.de> (Werner Koch's message of "Tue, 28 Mar 2006 20:07:40 +0200") References: <87acbabfyr.fsf@wheatstone.g10code.de> Message-ID: Hello, >>>>> In <87acbabfyr.fsf@wheatstone.g10code.de> >>>>> Werner Koch wrote: > > http://article.gmane.org/gmane.emacs.devel/52063 > > May I request new status code to mark the beginning of the actual > > signing process? > Okay. However you might get into a similar problem with decryption. > So what about something like STATUS_SECRETKEY_READR and you can > match on this and eventually ignore GOOD_PASSPHRASE. In case of decryption the problem can be avoided by waiting for BEGIN_DECRYPTION. It sounds good though. Regards, -- Daiki Ueno From mo at g10code.com Fri Mar 31 23:51:50 2006 From: mo at g10code.com (Moritz Schulte) Date: Sat Apr 1 01:56:23 2006 Subject: poldi bug: SIGSEGV if no reader In-Reply-To: <20060216212652.GA31891@capsaicin.mamane.lu> References: <20060216212652.GA31891@capsaicin.mamane.lu> Message-ID: <1143841910.14483.12.camel@localhost.localdomain> > Besides the wait-timeout option is not documented (but should really > be set by default!). Why is that? For e.g. login, I wouldn't want Poldi to use a timeout so that login is respawned every few minutes, because of failed logins. Moritz