From dshaw at jabberwocky.com Tue Aug 1 04:56:40 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Aug 1 04:55:13 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <44CB6616.1050605@gmail.com> References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> Message-ID: <20060801025640.GB3769@jabberwocky.com> On Sat, Jul 29, 2006 at 11:13:50PM +0930, Alphax wrote: > David Shaw wrote: > > On Sat, Jul 29, 2006 at 01:35:08AM +0930, Alphax wrote: > >> David Shaw wrote: > >>> On Fri, Jul 28, 2006 at 11:07:56AM +0930, Alphax wrote: > >>>> Since gnupg uses libcurl, and libcurl has support for authenticating > >>>> proxies... > >>>> > >>>> Shouldn't it be possible to have authenticating proxy support in gnupg? > >>> Yes, it's possible. At the moment, only BASIC auth is used. Which > >>> one did you need? > >>> > >> If BASIC is just username & password, it should be enough; I'll have to > >> check the manpage to see how to use it... > > > > Use a proxy like "http://user:pass@the.proxy.host". > > > > Note that this works with both curl and the built-in HTTP handler also. > > > > Is it at all likely to work on Windows, or is the networking code too > stupid? It should work on Windows just as well as Unix-ish machines, whether you are using cURL or not. > Where can I get a cURL package for MinGW that will actually work? http://curl.haxx.se David From dshaw at jabberwocky.com Tue Aug 1 04:57:59 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Tue Aug 1 04:56:34 2006 Subject: --enable-minimal In-Reply-To: <043501c6b32b$ee875510$f9b5a8c0@pii350> References: <043501c6b32b$ee875510$f9b5a8c0@pii350> Message-ID: <20060801025759.GC3769@jabberwocky.com> On Sat, Jul 29, 2006 at 06:27:48PM +0200, Gilles Espinasse wrote: > --enable-minimal is a shortcut to have a gpg with minimal size/functions > > Test on 1.4.5rc1 > With ./configure --prefix=/usr, size is 1017633 (unstripped) > With --enable-minimal, size is 786060 (unstripped) > With --enable-minimal --disable-nls , size is 770354 (unstripped) > With --enable-minimal --disable-nls --disable-dns-srv --disable-dns-pka --di > sable-dns-cert, size is > 769377 (unstripped) > > Should > not --disable-nls --disable-dns-srv --disable-dns-pka --disable-dns-cert be > include in > --enable-minimal selection? Yes, that's a good idea. However, we're currently in the middle of a release candidate for 1.4.5. I am reluctant to make a build change which would invalidate some of the information gained by the RC. If we do a 1.4.5rc2, I'll put it in, or failing that in 1.4.6. David From JPClizbe at comcast.net Tue Aug 1 07:32:09 2006 From: JPClizbe at comcast.net (John Clizbe) Date: Tue Aug 1 08:05:00 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <20060801025640.GB3769@jabberwocky.com> References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> Message-ID: <44CEE759.4080105@comcast.net> David Shaw wrote: > On Sat, Jul 29, 2006 at 11:13:50PM +0930, Alphax wrote: >> >> Is it at all likely to work on Windows, or is the networking code too >> stupid? > > It should work on Windows just as well as Unix-ish machines, whether > you are using cURL or not. > >> Where can I get a cURL package for MinGW that will actually work? > > http://curl.haxx.se > Curl and libcurl build fairly easily with MinGW/MSYS. I don't recall any problems with 7.15.1 and OpenSSL 0.9.8a back in December. Curl's INSTALL doc has instructions for Mingw (under CMD), Cygwin, and a few other compile environments. -- John P. Clizbe Inet: JPClizbe(a)comcast DOT nyet Golden Bear Networks PGP/GPG KeyID: 0x608D2A10 "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 662 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060801/246cb537/signature.pgp From wk at gnupg.org Tue Aug 1 10:23:08 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Aug 1 10:26:16 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <44CEE759.4080105@comcast.net> (John Clizbe's message of "Tue, 01 Aug 2006 00:32:09 -0500") References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> Message-ID: <87fyggx3tf.fsf@wheatstone.g10code.de> On Tue, 1 Aug 2006 07:32, John Clizbe said: > Curl and libcurl build fairly easily with MinGW/MSYS. I don't recall any > problems with 7.15.1 and OpenSSL 0.9.8a back in December. Curl's INSTALL doc has However, you may not distribute such a version unless cURL has been build without OpenSSL. That is the same thing as with other OSes: OpenSSL is not GPL compatible and thus we can't link to any library which in turn links to OpenSSL. Debian provides a libcurl3-gnutls-dev package for this reason. BTW, work is underway to get gnutls ready for Windows. David, we should see whether we can add an configure test to check for this. Shalom-Salam, Werner From wk at gnupg.org Tue Aug 1 17:37:08 2006 From: wk at gnupg.org (Werner Koch) Date: Tue Aug 1 19:58:21 2006 Subject: [Announce] GnuPG 1.4.5 released (another security fix) Message-ID: <87y7u8tql7.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 alphasigmax at gmail.com Wed Aug 2 01:49:45 2006 From: alphasigmax at gmail.com (Alphax) Date: Wed Aug 2 01:50:53 2006 Subject: [svn] GnuPG - r4216 - / branches In-Reply-To: References: Message-ID: <44CFE899.5060709@gmail.com> svn author wk wrote: > Author: wk > Date: 2006-08-01 14:23:34 +0200 (Tue, 01 Aug 2006) > New Revision: 4216 > > Added: > trunk/ > Removed: > branches/GNUPG-1-9-BRANCH/ > Log: > Moved 1.9 branch to trunk > > > Copied: trunk (from rev 4215, branches/GNUPG-1-9-BRANCH) > > So... what exactly will be get if we compile from trunk? -- Alphax Death to all fanatics! Down with categorical imperative! OpenPGP key: http://tinyurl.com/lvq4g -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 569 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060802/19ce1460/signature.pgp From dshaw at jabberwocky.com Wed Aug 2 02:36:06 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Aug 2 02:34:44 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <87fyggx3tf.fsf@wheatstone.g10code.de> References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> Message-ID: <20060802003606.GC7139@jabberwocky.com> On Tue, Aug 01, 2006 at 10:23:08AM +0200, Werner Koch wrote: > On Tue, 1 Aug 2006 07:32, John Clizbe said: > > > Curl and libcurl build fairly easily with MinGW/MSYS. I don't recall any > > problems with 7.15.1 and OpenSSL 0.9.8a back in December. Curl's INSTALL doc has > > However, you may not distribute such a version unless cURL has been > build without OpenSSL. That is the same thing as with other OSes: > OpenSSL is not GPL compatible and thus we can't link to any library > which in turn links to OpenSSL. Debian provides a libcurl3-gnutls-dev > package for this reason. > > BTW, work is underway to get gnutls ready for Windows. > > David, we should see whether we can add an configure test to check > for this. I'm not sure I understand. Check if cURL is linked to OpenSSL? What would we do differently if it was? David From wk at gnupg.org Wed Aug 2 08:47:13 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Aug 2 08:51:15 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <20060802003606.GC7139@jabberwocky.com> (David Shaw's message of "Tue, 1 Aug 2006 20:36:06 -0400") References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> Message-ID: <87lkq7tz0u.fsf@wheatstone.g10code.de> On Wed, 2 Aug 2006 02:36, David Shaw said: > I'm not sure I understand. Check if cURL is linked to OpenSSL? What > would we do differently if it was? In that case we can't use cURL at least a fat warning should be displayed. Salam-Shalom, Werner From wk at gnupg.org Wed Aug 2 08:46:03 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Aug 2 08:51:26 2006 Subject: [svn] GnuPG - r4216 - / branches In-Reply-To: <44CFE899.5060709@gmail.com> (alphasigmax@gmail.com's message of "Wed, 02 Aug 2006 09:19:45 +0930") References: <44CFE899.5060709@gmail.com> Message-ID: <87psfjtz2s.fsf@wheatstone.g10code.de> On Wed, 2 Aug 2006 01:49, Alphax said: > So... what exactly will be get if we compile from trunk? GnuPG 1.9.22 + latest changes Shalom-Salam, Werner From wk at gnupg.org Wed Aug 2 10:08:56 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Aug 2 10:25:41 2006 Subject: [Announce] Gpg4win 1.0.5 released (security fix) Message-ID: <874pwvtv8n.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 alex at bofh.net.pl Wed Aug 2 11:55:46 2006 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Wed Aug 2 11:54:31 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <87lkq7tz0u.fsf@wheatstone.g10code.de> References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> Message-ID: <20060802095546.GA10668@hell.pl> On Wed, Aug 02, 2006 at 08:47:13AM +0200, Werner Koch wrote: > On Wed, 2 Aug 2006 02:36, David Shaw said: > > > I'm not sure I understand. Check if cURL is linked to OpenSSL? What > > would we do differently if it was? > > In that case we can't use cURL at least a fat warning should be > displayed. Erm, why? It is illegal to distribute such a binary. It is not illegal to compile it for local use. Or GPL interpretations changed over the last few years? A. From gschmidt at gschmidt.org Wed Aug 2 08:25:09 2006 From: gschmidt at gschmidt.org (Geoff Schmidt) Date: Wed Aug 2 12:55:31 2006 Subject: Building libgpg-error on OS X 10.4 Message-ID: <9F1966AC-B547-4724-8A7F-2408E922CDD9@gschmidt.org> This is in response to Nicholas Cole's message of July 9, 2006. > I'm trying to build libgpg-error on OS X 10.4. > > ./configure runs fine, but the build fails with the > error copied at the end of this email. Any hints? [see bottom for the error] I found that this occurs under OS X 10.4.7 on PPC, not just Intel as Nicholas said. The problem is that the included libintl gets built as a static library, but is then linked into the dynamic libgpg-error. libtool doesn't catch on for some reason that this is happening and the libintl is built without the -fno-common that OS X requires for code that will eventually find its way into a dynamic library. This is the reason the link fails. I used this "brute force" workaround: CFLAGS="$CFLAGS -fno-common" CXXFLAGS="$CXXFLAGS -fno-common" ./ configure CFLAGS="$CFLAGS -fno-common" CXXFLAGS="$CXXFLAGS -fno-common" make install I still got this warning: *** Warning: Linking the shared library libgpg-error.la against the *** static library ../intl/libintl.a is not portable! but not the other warnings or errors. This message on the GCC mailing list suggests that passing - single_module would also make the link succeed: http://gcc.gnu.org/ml/gcc/2005-06/msg00184.html This poster says that -fno-common is the correct solution, and that under some circumstances libtool will use it automatically: http://gcc.gnu.org/ml/gcc/2005-06/msg00378.html Hope this helps someone. Please send replies to me directly, since I am not subscribed to this list. I am also happy to test patches, etc if you would like to work on this but don't have an appropriate OS X box handy or can't reproduce the problem. Thanks a lot! Geoff Schmidt > > *** Warning: Linking the shared library > libgpg-error.la against the > *** static library ../intl/libintl.a is not portable! > gcc -dynamiclib -flat_namespace -undefined suppress -o > .libs/libgpg-error.0.2.1.dylib > .libs/libgpg_error_la-init.o > .libs/libgpg_error_la-strsource.o > .libs/libgpg_error_la-strerror.o > .libs/libgpg_error_la-code-to-errno.o > .libs/libgpg_error_la-code-from-errno.o > ../intl/libintl.a /usr/lib/libiconv.dylib > -Wl,-framework -Wl,CoreFoundation -install_name > /usr/local/lib/libgpg-error.0.dylib > -Wl,-compatibility_version -Wl,3 -Wl,-current_version > -Wl,3.1 > ld: warning multiple definitions of symbol > _locale_charset > ../intl/libintl.a(localcharset.o) definition of > _locale_charset in section (__TEXT,__text) > /usr/lib/libiconv.dylib(localcharset.o) definition of > _locale_charset > ld: common symbols not allowed with MH_DYLIB output > format with the -multi_module option > ../intl/libintl.a(loadmsgcat.o) definition of common > __nl_msg_cat_cntr (size 16) > ../intl/libintl.a(dcigettext.o) definition of common > _libintl_nl_domain_bindings (size 16) > ../intl/libintl.a(plural-exp.o) definition of common > _libintl_gettext_germanic_plural (size 32) > /usr/bin/libtool: internal link edit command failed > make[3]: *** [libgpg-error.la] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > > From dshaw at jabberwocky.com Wed Aug 2 14:17:32 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Aug 2 14:16:10 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <87lkq7tz0u.fsf@wheatstone.g10code.de> References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> Message-ID: <20060802121732.GF7139@jabberwocky.com> On Wed, Aug 02, 2006 at 08:47:13AM +0200, Werner Koch wrote: > On Wed, 2 Aug 2006 02:36, David Shaw said: > > > I'm not sure I understand. Check if cURL is linked to OpenSSL? What > > would we do differently if it was? > > In that case we can't use cURL at least a fat warning should be > displayed. I must disagree. Unless I am seriously misreading the GPL, the restriction would be on *distributing* a binary with GPG linked to an OpenSSL libcurl, and even then the restriction depends on whether OpenSSL is considered part of the OS or not. Such a question (whether OpenSSL is part of the OS) should be up to the packager of the binary and the maker of the OS. Debian seems to have decided that OpenSSL is not part of the OS, while Fedora and Mac OSX decided it that it was. Either way the OS goes, it's not something we can reasonably answer within GPG. The packager of the binary has many choices: they can build with OpenSSL+libcurl, they can build with GnuTLS+libcurl, they can build with plain libcurl, or they can build without libcurl at all. We've given them all the tools they need to make GPL-compliant packages. It's up to them to decide what their platform requires. I'd be happy to write a paragraph or two for the README file about this. It's not even a libcurl-specific issue: the LDAP keyserver helper can link to OpenLDAP, which can also be built with OpenSSL. David From wk at gnupg.org Wed Aug 2 19:32:10 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Aug 2 19:36:17 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <20060802121732.GF7139@jabberwocky.com> (David Shaw's message of "Wed, 2 Aug 2006 08:17:32 -0400") References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> Message-ID: <878xm7rqlh.fsf@wheatstone.g10code.de> On Wed, 2 Aug 2006 14:17, David Shaw said: > I must disagree. Unless I am seriously misreading the GPL, the > restriction would be on *distributing* a binary with GPG linked to an That is right. However, the discussion was about about the W32 version of GnuPG and tehre it is pretty common to distribute binaries. In fact most people won't be able to build their own binary. Thus my suggestion to detect this or to print a warning. For example, libgcrypt does print such a warning if it may not be used unter terms of the LGPL (due to a missing /dev/random). > OpenSSL libcurl, and even then the restriction depends on whether > OpenSSL is considered part of the OS or not. OpenSSL is clearly not part of the OS (at least for almost all GNU/Linux systems). Being a GNU project we need to take such issues seriously. It is just that I did not thought about this because the keyserver helpers are rather new. We had similar discussion within other projects and came to the conclusion that indirect linking is indeed a problem and one that package maintainers are often not aware of. A warning will indeed help them. I just checked a stock SUSE system with gpg 1.4.0 installed - it indeed links to openssl - that is clearly not complying with the GPL. > OSX decided it that it was. Either way the OS goes, it's not > something we can reasonably answer within GPG. I will raise this point at the GNU maintainers list and report back then. > The packager of the binary has many choices: they can build with > OpenSSL+libcurl, they can build with GnuTLS+libcurl, they can build > with plain libcurl, or they can build without libcurl at all. We've It is not easy to do. For example with current Debian you may either install the gnutls or the openssl based version of cURL. > I'd be happy to write a paragraph or two for the README file about > this. It's not even a libcurl-specific issue: the LDAP keyserver > helper can link to OpenLDAP, which can also be built with OpenSSL. I know. All this deep linking chains raise a lot of problems and licensing questions are just one of them. Salam-Shalom, Werner From marcus.brinkmann at ruhr-uni-bochum.de Wed Aug 2 20:46:59 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed Aug 2 20:46:45 2006 Subject: Building libgpg-error on OS X 10.4 In-Reply-To: <9F1966AC-B547-4724-8A7F-2408E922CDD9@gschmidt.org> References: <9F1966AC-B547-4724-8A7F-2408E922CDD9@gschmidt.org> Message-ID: <8764hbt1p8.wl%marcus.brinkmann@ruhr-uni-bochum.de> Hi, (please keep the CC's intact on reply) it seems that the libtool+gettext+automake machinery does not work perfectly for libraries using gettext. If you use --with-included-gettext, then a static version of libintl will be built, and LTLIBINTL is set to the static library. But linking a static library with a shared library is not guaranteed to work. In fact, it gives a warning. Moreover, it actually fails on Mac OS X due to missing -fno-common (because the static library is not built as PIC). So, the question is, is there any solution to this, beside advising Mac OS X users to never use the included gettext, but link dynamically to an external gettext implementation? Thanks, Marcus At Wed, 2 Aug 2006 02:25:09 -0400, Geoff Schmidt wrote: > > This is in response to Nicholas Cole's message of July 9, 2006. > > > I'm trying to build libgpg-error on OS X 10.4. > > > > ./configure runs fine, but the build fails with the > > error copied at the end of this email. Any hints? > [see bottom for the error] > > I found that this occurs under OS X 10.4.7 on PPC, not just Intel as > Nicholas said. > > The problem is that the included libintl gets built as a static > library, but is then linked into the dynamic libgpg-error. libtool > doesn't catch on for some reason that this is happening and the > libintl is built without the -fno-common that OS X requires for code > that will eventually find its way into a dynamic library. This is the > reason the link fails. > > I used this "brute force" workaround: > CFLAGS="$CFLAGS -fno-common" CXXFLAGS="$CXXFLAGS -fno-common" ./ > configure > CFLAGS="$CFLAGS -fno-common" CXXFLAGS="$CXXFLAGS -fno-common" make > install > > I still got this warning: > *** Warning: Linking the shared library libgpg-error.la against the > *** static library ../intl/libintl.a is not portable! > > but not the other warnings or errors. > > This message on the GCC mailing list suggests that passing - > single_module would also make the link succeed: > http://gcc.gnu.org/ml/gcc/2005-06/msg00184.html > > This poster says that -fno-common is the correct solution, and that > under some circumstances libtool will use it automatically: > http://gcc.gnu.org/ml/gcc/2005-06/msg00378.html > > Hope this helps someone. Please send replies to me directly, since I > am not subscribed to this list. I am also happy to test patches, etc > if you would like to work on this but don't have an appropriate OS X > box handy or can't reproduce the problem. > > Thanks a lot! > > Geoff Schmidt > > > > > *** Warning: Linking the shared library > > libgpg-error.la against the > > *** static library ../intl/libintl.a is not portable! > > gcc -dynamiclib -flat_namespace -undefined suppress -o > > .libs/libgpg-error.0.2.1.dylib > > .libs/libgpg_error_la-init.o > > .libs/libgpg_error_la-strsource.o > > .libs/libgpg_error_la-strerror.o > > .libs/libgpg_error_la-code-to-errno.o > > .libs/libgpg_error_la-code-from-errno.o > > ../intl/libintl.a /usr/lib/libiconv.dylib > > -Wl,-framework -Wl,CoreFoundation -install_name > > /usr/local/lib/libgpg-error.0.dylib > > -Wl,-compatibility_version -Wl,3 -Wl,-current_version > > -Wl,3.1 > > ld: warning multiple definitions of symbol > > _locale_charset > > ../intl/libintl.a(localcharset.o) definition of > > _locale_charset in section (__TEXT,__text) > > /usr/lib/libiconv.dylib(localcharset.o) definition of > > _locale_charset > > ld: common symbols not allowed with MH_DYLIB output > > format with the -multi_module option > > ../intl/libintl.a(loadmsgcat.o) definition of common > > __nl_msg_cat_cntr (size 16) > > ../intl/libintl.a(dcigettext.o) definition of common > > _libintl_nl_domain_bindings (size 16) > > ../intl/libintl.a(plural-exp.o) definition of common > > _libintl_gettext_germanic_plural (size 32) > > /usr/bin/libtool: internal link edit command failed > > make[3]: *** [libgpg-error.la] Error 1 > > make[2]: *** [all] Error 2 > > make[1]: *** [all-recursive] Error 1 > > make: *** [all] Error 2 > > > > > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From dshaw at jabberwocky.com Wed Aug 2 21:08:08 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Aug 2 21:06:49 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <878xm7rqlh.fsf@wheatstone.g10code.de> References: <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> Message-ID: <20060802190808.GA27691@jabberwocky.com> On Wed, Aug 02, 2006 at 07:32:10PM +0200, Werner Koch wrote: > On Wed, 2 Aug 2006 14:17, David Shaw said: > > OpenSSL libcurl, and even then the restriction depends on whether > > OpenSSL is considered part of the OS or not. > > OpenSSL is clearly not part of the OS (at least for almost all > GNU/Linux systems). I don't know that this is true. Different people hold different opinions about this. Clearly Debian has made a statement that they do not consider OpenSSL part of the OS, but there are other cases that are not as clear cut. My point is not to argue whether OpenSSL can be part of the OS or not. My point is that I don't think we in the GPG world get a vote on this: it's not our OS and so not our decision to make. > > OSX decided it that it was. Either way the OS goes, it's not > > something we can reasonably answer within GPG. > > I will raise this point at the GNU maintainers list and report back > then. > > > The packager of the binary has many choices: they can build with > > OpenSSL+libcurl, they can build with GnuTLS+libcurl, they can build > > with plain libcurl, or they can build without libcurl at all. We've > > It is not easy to do. For example with current Debian you may either > install the gnutls or the openssl based version of cURL. I'd think that makes it easier (at least on the context of GPG). The GPG keyserver code doesn't do anything strange or unusual with its SSL support, and so will work equally well with OpenSSL or GnuTLS. All the SSL functionality is hidden behind the libcurl API. David From dshaw at jabberwocky.com Wed Aug 2 21:18:39 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Aug 2 21:17:19 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <878xm7rqlh.fsf@wheatstone.g10code.de> References: <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> Message-ID: <20060802191839.GB27691@jabberwocky.com> On Wed, Aug 02, 2006 at 07:32:10PM +0200, Werner Koch wrote: > > I'd be happy to write a paragraph or two for the README file about > > this. It's not even a libcurl-specific issue: the LDAP keyserver > > helper can link to OpenLDAP, which can also be built with OpenSSL. > > I know. All this deep linking chains raise a lot of problems and > licensing questions are just one of them. A thought: why not just put an exception in for OpenSSL? That's what Wget did, and it's a Gnu project as well: In addition, as a special exception, the Free Software Foundation gives permission to link the code of its release of Wget with the OpenSSL project's "OpenSSL" library (or with modified versions of it that use the same license as the "OpenSSL" library), and distribute the linked executables. You must obey the GNU General Public License in all respects for all of the code used other than "OpenSSL". If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. It seems significantly easier than forcing multiple versions of libcurl or refusing to build with OpenSSL, or the like. David From rjh at sixdemonbag.org Wed Aug 2 21:01:08 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed Aug 2 22:55:30 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <878xm7rqlh.fsf@wheatstone.g10code.de> References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> Message-ID: <44D0F674.5010006@sixdemonbag.org> Werner Koch wrote: > OpenSSL is clearly not part of the OS (at least for almost all > GNU/Linux systems). With due respect, Werner, the question about which libraries are a standard part of the environment under clause 3 of the GPL appears to be something only the distro maintainers can answer. As previously mentioned, OS X has apparently decided it's part of the standard system. Why, then, should it be unreasonable for SuSE to decide it's part of their standard system? From marcus.brinkmann at ruhr-uni-bochum.de Thu Aug 3 03:36:22 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Aug 3 03:36:45 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <20060802190808.GA27691@jabberwocky.com> References: <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <20060802190808.GA27691@jabberwocky.com> Message-ID: <873bcetxbd.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Wed, 2 Aug 2006 15:08:08 -0400, David Shaw wrote: > > On Wed, Aug 02, 2006 at 07:32:10PM +0200, Werner Koch wrote: > > On Wed, 2 Aug 2006 14:17, David Shaw said: > > > > OpenSSL libcurl, and even then the restriction depends on whether > > > OpenSSL is considered part of the OS or not. > > > > OpenSSL is clearly not part of the OS (at least for almost all > > GNU/Linux systems). > > I don't know that this is true. Different people hold different > opinions about this. Clearly Debian has made a statement that they do > not consider OpenSSL part of the OS, but there are other cases that > are not as clear cut. My point is not to argue whether OpenSSL can be > part of the OS or not. My point is that I don't think we in the GPG > world get a vote on this: it's not our OS and so not our decision to > make. I have two things to say about this. The first thing is that it is not up to the distro maintainers alone, but also to the copyright holder of the software, in this case the FSF. As we are talking about legal matters, in a disputed case the final ruling that settles the matter would come from a court (if no agreement can be reached). But a court will always consider actual practice and intent of involved parties. If the intent of the copyright holder is clearly to apply this exception to proprietary systems only, and the intent of distro builders is to circumvent the restrictions in the GPL, then I think it is a likely outcome that the court will rule against applicability of this exception. So, the publicly documented opinion of the FSF does matter. Second, this exception you are citing is overused. If some distros are trying to apply it, they are abusing it. The historical context of this exception is running GNU tools on proprietary operating systems, where you have to link the program against some of the vendor's proprietary system libraries. The distros can not use the exception, because they are shipping openssl as well as gnupg, thus "the component [openssl] itself accompanies the executable." This alone settles the matter. It would be very difficult for a free software distribution to separate openssl from gnupg in a way to successfully argue that openssl accompanies the major parts of the operating system, but gnupg does not. As a minimum, such a distribution would have to cease to distribute gnupg binaries linked against openssl (ie, the BSD ports setup may actually work out fine in this case). There are a number of solutions to this problem, including adding an exception for openssl, which you have mentioned in your other mail. Another is to get openssl relicensed under a GPL-compatible free software license[1]. Or distros can do the extra work to avoid linking GPL software against GPL. I do not have any strong opinions in either of these directions, but of course it is not up to me anyway. Thanks, Marcus [1] This has happened before with other projects licensed under BSD-style + advertisement clause terms. From marcus.brinkmann at ruhr-uni-bochum.de Thu Aug 3 03:40:49 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Aug 3 03:41:40 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <44D0F674.5010006@sixdemonbag.org> References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <44D0F674.5010006@sixdemonbag.org> Message-ID: <871wrytx3y.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Wed, 02 Aug 2006 12:01:08 -0700, "Robert J. Hansen" wrote: > > Werner Koch wrote: > > OpenSSL is clearly not part of the OS (at least for almost all > > GNU/Linux systems). > > With due respect, Werner, the question about which libraries are a > standard part of the environment under clause 3 of the GPL appears to be > something only the distro maintainers can answer. > > As previously mentioned, OS X has apparently decided it's part of the > standard system. Why, then, should it be unreasonable for SuSE to > decide it's part of their standard system? Please take note of the fine print: "However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, UNLESS THAT COMPONENT ITSELF ACCOMPANIES THE EXECUTABLE. Emphasis added. In practice, the exception is good only for system libraries like the C runtime of proprietary vendor systems that do not include the program (gnupg in this case). Thanks, Marcus From rjh at sixdemonbag.org Thu Aug 3 05:18:01 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu Aug 3 05:16:45 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <871wrytx3y.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <44D0F674.5010006@sixdemonbag.org> <871wrytx3y.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <44D16AE9.8020107@sixdemonbag.org> Marcus Brinkmann wrote: > Please take note of the fine print: When one party dictates terms and the other person has no say in their drafting, American jurisprudence tends to say that any and all ambiguities in the terms are interpreted in favor of the party who had no say. (This is usually referred to as a "contract of adhesion".) You may think there's no ambiguity there. I think there's enough ambiguity for a lawyer to credibly claim his or her client's interpretation is reasonable, especially given how technically illiterate most judges are. As a general rule, programmers make lousy lawyers. We live in a world where everything is clear-cut, black and white, where ultimately everything boils down to the mathematics of the lambda calculus. We live in a world where elegance in code is a virtue, and it's generally possible to determine the meaning of a well-written piece of code by looking at it in isolation. This is enshrined in our lives as a virtue: side-effect free programming and complete referential transparency. Lawyers live in a world that's completely opposite. In their world there are very few black and whites and almost anything is up for debate. The law is a Byzantine morass of legislation, regulation and precedent, all of them interacting with the other. Please note that I am not saying SuSE is off the hook. Nor am I saying that what OS X, SuSE and others are doing is kosher. All that I am doing is warning against the false sense of security that often accompanies programmers when we start talking about what the law does or does not mean, or how a judge would or would not construe the terms of a license. Let's be cautious, let's be prudent, and let's find a way that gets us out of the thicket of lawyers with a minimum of hubbub and stress. > In practice, the exception is good only for system libraries Could you please point me to a court precedent which affirms this interpretation? Because until a court decides what it means, we really don't know what it means. As a matter of practice on the engineering side of the fence, I'd agree with you, that's what it's always been read to be. But I'm very, very wary about walking on the legal side of the fence and telling the lawyers they need to subscribe to our interpretation. From wk at gnupg.org Thu Aug 3 10:58:59 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Aug 3 11:01:20 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <44D16AE9.8020107@sixdemonbag.org> (Robert J. Hansen's message of "Wed, 02 Aug 2006 20:18:01 -0700") References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <44D0F674.5010006@sixdemonbag.org> <871wrytx3y.wl%marcus.brinkmann@ruhr-uni-bochum.de> <44D16AE9.8020107@sixdemonbag.org> Message-ID: <87slkenqjw.fsf@wheatstone.g10code.de> On Thu, 3 Aug 2006 05:18, Robert J. Hansen said: > drafting, American jurisprudence tends to say that any and all > ambiguities in the terms are interpreted in favor of the party who had > no say. (This is usually referred to as a "contract of adhesion".) Consider that the GPL is not a contract. It gives you certain rights over those established in copyright law if and only if you obey to the terms of the GPL. Salam-Shalom, Werner From wk at gnupg.org Thu Aug 3 11:11:44 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Aug 3 11:16:21 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <20060802191839.GB27691@jabberwocky.com> (David Shaw's message of "Wed, 2 Aug 2006 15:18:39 -0400") References: <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <20060802191839.GB27691@jabberwocky.com> Message-ID: <87odv2npyn.fsf@wheatstone.g10code.de> On Wed, 2 Aug 2006 21:18, David Shaw said: > A thought: why not just put an exception in for OpenSSL? That's what > Wget did, and it's a Gnu project as well: I don't like these exceptions for practical reasons. Take Sylpheed as an example. There the OpenSSL exception is also stated. However there are a couple of problems: * It has been added without asking all contributors. For example I have never been asked despite that I did quite some work on Sylpheed. * Sylpheed links to a couple of libraries which are (or used to be) GPL. Thus they would have needed to negotiate with all authors to agree on this exception. One GPL part not coming with this exception renders the whole exception pointless. * To make real use of this exception most of the GPL software would end up with this exception. Hmmm, it is called an exception for a reason. The forthcoming GPLv3 will make these things easier but agreement of all authors will still be required. > It seems significantly easier than forcing multiple versions of > libcurl or refusing to build with OpenSSL, or the like. Thinks would be far easier if the OpenSSL folks had not decided to base their work on ssleay. ssleay's authors still refuse to change the licensing terms in favor of the modern BSD license. But well, it is mood to discuss this point now. BTW, I don't understand why everyone insists on OpenSSL instead of thinking of other libs. cryptlib seems to be a much more reliable implementaion than what most people are using these days. Shalom-Salam, Werner From rjh at sixdemonbag.org Thu Aug 3 11:31:08 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu Aug 3 11:29:43 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <87slkenqjw.fsf@wheatstone.g10code.de> References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <44D0F674.5010006@sixdemonbag.org> <871wrytx3y.wl%marcus.brinkmann@ruhr-uni-bochum.de> <44D16AE9.8020107@sixdemonbag.org> <87slkenqjw.fsf@wheatstone.g10code.de> Message-ID: <44D1C25C.7030707@sixdemonbag.org> Werner Koch wrote: > Consider that the GPL is not a contract. It gives you certain rights > over those established in copyright law if and only if you obey to the > terms of the GPL. The same idea applies to license grants. The legal principle behind adhesion and adhesion-like things is that ambiguities will generally be resolved in a manner favorable to the person who does not have a say in the wording of the agreement. Again, I'm not saying a court _would_ do so... only that we need to be very careful about the pronouncements we make about law. The law is just full of edge cases like this. What's the ultimate answer? I don't know--ask an IP lawyer. If Eben Moglen makes a statement about how the license ought to be interpreted, I'll take that very seriously. He's clearly qualified, he understands how to do legal research, and he's been very careful to differentiate what he can prove from what he can argue from what he believes. But we're not lawyers, and we need to be very careful with our armchair lawyering. From marcus.brinkmann at ruhr-uni-bochum.de Thu Aug 3 11:46:00 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Aug 3 11:46:45 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <44D16AE9.8020107@sixdemonbag.org> References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <44D0F674.5010006@sixdemonbag.org> <871wrytx3y.wl%marcus.brinkmann@ruhr-uni-bochum.de> <44D16AE9.8020107@sixdemonbag.org> Message-ID: <87zmemrw2v.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Wed, 02 Aug 2006 20:18:01 -0700, "Robert J. Hansen" wrote: > You may think there's no ambiguity there. I think there's enough > ambiguity for a lawyer to credibly claim his or her client's > interpretation is reasonable, especially given how technically > illiterate most judges are. I am very well aware of the fact that it is a lawyers job to sell an apple as an orange and get away with it. However, I think that as long as we are talking among ourselves, I think it is reasonable to stay within the boundaries of a sensible discussion, where apples are apples and oranges are oranges. If we agree that the FSF's intent is clearly what I said, and that the attempt to use the cited exception in a free software distribution to ship openssl linked with GPL is abusive of this intent, then I think it is a call to reason and partnership to act as if this intent was law (as long as the intent itself is not immoral or against law). It is not my objective here to make a case against any violations of this intent in front of a court. If we have to settle these things in front of a court, or in a lawyer-like manner, among ourselves, we are clearly in trouble. I think a proper manner to deal with these issues is to figure out what everybody involved wants to achieve, and then see how it can be done. This requires a dialogue where the real issues come on the table, not a discussion about legal corner cases. In this case, I think what the FSF wants to achieve is to keep up the integrity of the freedom of the software. For this, it is vital that the GPL is not weakened. This also benefits distributors like Suse (and maybe even openssl developers). What distributors want to achieve is to build a usable operation system with little effort. I consider the freedom of the software to be valuable enough to impose some effort on distributors and others (including ourselves) to fix this properly, in one of the several ways I outlined in my other mail (there may be others). Thanks, Marcus From smenzel at gmx-gmbh.de Thu Aug 3 12:11:55 2006 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Thu Aug 3 13:55:39 2006 Subject: gpgme after setuid Message-ID: <200608031212.02860.smenzel@gmx-gmbh.de> Hi, I have just discovered a really strange problem using libgpgme inside a daemon. This Daemon drops root privileges after being started with sudo and runs as a special user, let's call him 'nobody' gpgme is configured to work for 'nobody'. In his home dir are all the config files and gpgsm works well. And gpgme used to work in the daemon too but not anymore. I don't know what happend but strace shows me gpgme is looking for gpgsm's config files etc in the homedir of the user who actually started the daemon. an strace looks like this (user sm started the daemon with sudo here): [pid 10422] mmap2(NULL, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE| MAP_ANONYMOUS, -1, 0) = 0xa7fb6000 [pid 10422] getuid32() = 0 [pid 10422] mlock(0xa7fb6000, 16384) = 0 [pid 10422] open("/home/sm/.gnupg/gpgsm.conf", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 10422] open("/home/sm/.gnupg/pubring.kbx", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 10422] open("/home/sm/.gnupg/pubring.kbx", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) [pid 10422] open("/home/sm/.gnupg/pubring.kbx", O_WRONLY|O_CREAT|O_TRUNC| O_LARGEFILE, 0666) = -1 ENOENT (No such file or directory) [pid 10422] getuid32() = 0 [pid 10422] geteuid32() = 200 [pid 10422] mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE| MAP_ANONYMOUS, -1, 0) = 0xa7fb4000 [pid 10422] write(2, "gpgsm: error creating keybox `/home/sm/.gnupg/pubring.kbx\': No such file or directory\n", 86) = 86 [pid 10422] write(2, "gpgsm: you may want to start the gpg-agent first\n", 49) = 49 [pid 10422] write(2, "gpgsm: keyblock resource `/home/sm/.gnupg/pubring.kbx\': No such file or directory\n", 82) = 82 [pid 10422] munmap(0xa7fb6000, 16384) = 0 [pid 10422] munmap(0xa7fb4000, 8192) = 0 [pid 10422] exit_group(1) = ? Process 10422 detached The strange thing is, if I start the same daemon as 'nobody', it works fine. Did you change something in the was gpgsm locates it's homedir? Greetings... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060803/bad933dd/attachment.pgp From smenzel at gmx-gmbh.de Thu Aug 3 14:54:00 2006 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Thu Aug 3 14:53:12 2006 Subject: gpgme after setuid In-Reply-To: <200608031212.02860.smenzel@gmx-gmbh.de> References: <200608031212.02860.smenzel@gmx-gmbh.de> Message-ID: <200608031454.01279.smenzel@gmx-gmbh.de> Am Donnerstag, 3. August 2006 12:11 schrieb Stephan Menzel: > gpgme is configured to work for 'nobody'. In his home dir are all the > config files and gpgsm works well. > And gpgme used to work in the daemon too but not anymore. I don't know what > happend but strace shows me gpgme is looking for gpgsm's config files etc > in the homedir of the user who actually started the daemon. ... I forgot to mention here, this causes gpgme to fail verfication operations with a "General error" this is written on stderr: can't connect server: ec=255.16777215 Greetings... Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060803/c9b63929/attachment.pgp From dshaw at jabberwocky.com Thu Aug 3 15:08:28 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Aug 3 15:07:05 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <87odv2npyn.fsf@wheatstone.g10code.de> References: <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <20060802191839.GB27691@jabberwocky.com> <87odv2npyn.fsf@wheatstone.g10code.de> Message-ID: <20060803130828.GA32029@jabberwocky.com> On Thu, Aug 03, 2006 at 11:11:44AM +0200, Werner Koch wrote: > On Wed, 2 Aug 2006 21:18, David Shaw said: > > > A thought: why not just put an exception in for OpenSSL? That's what > > Wget did, and it's a Gnu project as well: > > I don't like these exceptions for practical reasons. Take Sylpheed as > an example. There the OpenSSL exception is also stated. However > there are a couple of problems: > > * It has been added without asking all contributors. For example I > have never been asked despite that I did quite some work on > Sylpheed. > > * Sylpheed links to a couple of libraries which are (or used to be) > GPL. Thus they would have needed to negotiate with all authors to > agree on this exception. One GPL part not coming with this > exception renders the whole exception pointless. > > * To make real use of this exception most of the GPL software would > end up with this exception. Hmmm, it is called an exception for a > reason. These are good objections, but I don't know how well they apply in the GPG case. Judging by the ChangeLogs, GPG (at least 1.4.x) does not have that many authors. Even that doesn't matter because if the goal is to allow linking with sub-dependencies of OpenLDAP and libcurl, we're only talking about the contents of the keyserver directory. In the keyserver directory, you really only need permission from one author, and I would give it. How about a license exception (or just LGPL) for gpgkeys_ldap, gpgkeys_curl, and gpgkeys_hkp? They're separate programs that communicate via pipes (the classic example of the barrier that the GPL does not cross). Their licensing need not be the same as the gpg program. > BTW, I don't understand why everyone insists on OpenSSL instead of > thinking of other libs. cryptlib seems to be a much more reliable > implementaion than what most people are using these days. At least for GPG, I suspect most people won't care (or even notice) whether it is OpenSSL or something else. They just want to be able to build the software and use keyservers. If that happens through OpenSSL, great. If that happens through GnuTLS, also great. David From wk at gnupg.org Thu Aug 3 15:28:09 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Aug 3 15:31:21 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <20060803130828.GA32029@jabberwocky.com> (David Shaw's message of "Thu, 3 Aug 2006 09:08:28 -0400") References: <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <20060802191839.GB27691@jabberwocky.com> <87odv2npyn.fsf@wheatstone.g10code.de> <20060803130828.GA32029@jabberwocky.com> Message-ID: <87ejvyne3a.fsf@wheatstone.g10code.de> On Thu, 3 Aug 2006 15:08, David Shaw said: > These are good objections, but I don't know how well they apply in the > GPG case. Judging by the ChangeLogs, GPG (at least 1.4.x) does not It is not actually a problem as the FSF holds copyright assignments. So they would need to decide unless I decide that for technical reasons we need to change the license. > gpgkeys_curl, and gpgkeys_hkp? They're separate programs that > communicate via pipes (the classic example of the barrier that the GPL > does not cross). Their licensing need not be the same as the gpg That is a common misunderstanding. The GPL does not specify the technical terms what makes up a derivative work. In many cases the process boundary is good guess but not always true. In our case the keyserver helpers have been written has part of gpg and are designed to work with them. They are not intended as a separate tool. Thus I won't see that as a mere aggregation. As we can't solve this problem right now and given that this is a general problem not related only to GnuPG, I suggest that we suspend this problem for now and wait for the GPLv3 which might help to fix the problem. I will open a bug so that we don't forget about it. Okay? Werner From wk at gnupg.org Thu Aug 3 15:34:46 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Aug 3 15:36:15 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <87zmemrw2v.wl%marcus.brinkmann@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "Thu, 03 Aug 2006 11:46:00 +0200") References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <44D0F674.5010006@sixdemonbag.org> <871wrytx3y.wl%marcus.brinkmann@ruhr-uni-bochum.de> <44D16AE9.8020107@sixdemonbag.org> <87zmemrw2v.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <87ac6mnds9.fsf@wheatstone.g10code.de> On Thu, 3 Aug 2006 11:46, Marcus Brinkmann said: > In this case, I think what the FSF wants to achieve is to keep up the > integrity of the freedom of the software. For this, it is vital that > the GPL is not weakened. This also benefits distributors like Suse In our case it is a mere compatibility problem between OpenSSL and the GPL. So I am confident that this may eventually be solved. However the general principle of indirect linking could also be carried over to a free (say new BSD license) library which in turn links to a proprietary library (say to implement some DRM). In this case it is pretty clear that this will be a way to limit the freedom granted by the GPLed software. And thus violates the intention as well as the actual terms of the GPL. Shalom-Salam, Werner From wk at gnupg.org Thu Aug 3 15:39:53 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Aug 3 15:41:15 2006 Subject: gpgme after setuid In-Reply-To: <200608031212.02860.smenzel@gmx-gmbh.de> (Stephan Menzel's message of "Thu, 3 Aug 2006 12:11:55 +0200") References: <200608031212.02860.smenzel@gmx-gmbh.de> Message-ID: <8764handjq.fsf@wheatstone.g10code.de> On Thu, 3 Aug 2006 12:11, Stephan Menzel said: > And gpgme used to work in the daemon too but not anymore. I don't know what > happend but strace shows me gpgme is looking for gpgsm's config files etc in > the homedir of the user who actually started the daemon. That is right. The home directory is determined by the HOME environment variable. sudo for example does not change HOME. Salam-Shalom, Werner From gdt at ir.bbn.com Thu Aug 3 15:48:44 2006 From: gdt at ir.bbn.com (Greg Troxel) Date: Thu Aug 3 15:47:37 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <878xm7rqlh.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 02 Aug 2006 19:32:10 +0200") References: <44C96A74.2050409@gmail.com> <20060728022729.GA19064@jabberwocky.com> <44CA35B4.3070203@gmail.com> <20060728163800.GA20813@jabberwocky.com> <44CB6616.1050605@gmail.com> <20060801025640.GB3769@jabberwocky.com> <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> Message-ID: OpenSSL is clearly not part of the OS (at least for almost all GNU/Linux systems). On NetBSD, OpenSSL is very definitely part of the operating system. details: OpenSSL sources are in src/crypto/dist/openssl, libssl is built from src/lib/libssl, and openssl from src/usr.bin/openssl (via reachover makefiles). The same reachover technique is used for groff, gcc, and a bunch of other things. A minimal install of NetBSD (just the 'base' set) includes /usr/bin/openssl and /usr/lib/libssl.4. On NetBSD, people tend to use GnuPG with pkgsrc, and binary packages are distributed, but they are kept separate from the base operating system. By default in pkgsrc, gnupg does not use curl. The resulting gpg binary and the 3 helpers do not link with openssl. If one sets PKG_OPTIONS.gnupg=curl, gnupg is built with curl. Then ssl is used: /usr/pkg/libexec/gnupg/gpgkeys_hkp: -lidn.11 => /usr/pkg/lib/libidn.so.11 -lcrypt.0 => /lib/libcrypt.so.0 -lcrypto.2 => /usr/lib/libcrypto.so.2 -lssl.3 => /usr/lib/libssl.so.3 -lz.0 => /usr/lib/libz.so.0 -lcurl.3 => /usr/pkg/lib/libcurl.so.3 -lcrypto.3 => /usr/lib/libcrypto.so.3 -lssl.4 => /usr/lib/libssl.so.4 -lz.1 => /usr/lib/libz.so.1 -lc.12 => /usr/lib/libc.so.12 (yes, something's wrong and I've got .2 and .3 of lihcrypto and .3 and .4 of libssl.!) As I understand the exception, it applies to NetBSD's usage, since gnupg binaries are distributed by pkgsrc which is separated from the operating system. And, binary packges that are distributed via netbsd.org are not built with curl. -- Greg Troxel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : /pipermail/attachments/20060803/359db72c/attachment.pgp From smenzel at gmx-gmbh.de Thu Aug 3 16:03:51 2006 From: smenzel at gmx-gmbh.de (Stephan Menzel) Date: Thu Aug 3 16:02:48 2006 Subject: gpgme after setuid In-Reply-To: <8764handjq.fsf@wheatstone.g10code.de> References: <200608031212.02860.smenzel@gmx-gmbh.de> <8764handjq.fsf@wheatstone.g10code.de> Message-ID: <200608031603.51909.smenzel@gmx-gmbh.de> Am Donnerstag, 3. August 2006 15:39 schrieb Werner Koch: > > And gpgme used to work in the daemon too but not anymore. I don't know > > what happend but strace shows me gpgme is looking for gpgsm's config > > files etc in the homedir of the user who actually started the daemon. > > That is right. The home directory is determined by the HOME > environment variable. sudo for example does not change HOME. That's it! Thank's a lot, you made my day happy despite the rain. Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20060803/39ab640d/attachment.pgp From dshaw at jabberwocky.com Thu Aug 3 16:17:15 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Aug 3 16:15:54 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <87ejvyne3a.fsf@wheatstone.g10code.de> References: <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <20060802191839.GB27691@jabberwocky.com> <87odv2npyn.fsf@wheatstone.g10code.de> <20060803130828.GA32029@jabberwocky.com> <87ejvyne3a.fsf@wheatstone.g10code.de> Message-ID: <20060803141715.GB32029@jabberwocky.com> On Thu, Aug 03, 2006 at 03:28:09PM +0200, Werner Koch wrote: > On Thu, 3 Aug 2006 15:08, David Shaw said: > > > These are good objections, but I don't know how well they apply in the > > GPG case. Judging by the ChangeLogs, GPG (at least 1.4.x) does not > > It is not actually a problem as the FSF holds copyright assignments. > So they would need to decide unless I decide that for technical > reasons we need to change the license. > > > gpgkeys_curl, and gpgkeys_hkp? They're separate programs that > > communicate via pipes (the classic example of the barrier that the GPL > > does not cross). Their licensing need not be the same as the gpg > > That is a common misunderstanding. The GPL does not specify the > technical terms what makes up a derivative work. In many cases the > process boundary is good guess but not always true. In our case the > keyserver helpers have been written has part of gpg and are designed > to work with them. They are not intended as a separate tool. Thus I > won't see that as a mere aggregation. That's not the case though - they were designed intentionally to be able to run outside of GPG for general keyserver access. That's one of the reasons the communications were versioned: if gpgkeys_* were strictly part of GPG, then there would be no reason to version the communications, as a GPG update would always give you the matching helpers. One of the front-ends was using this ability (was it WinPT?). Jason Harris also has a package that calls them directly. gpgkeys_* is not a derivative work of GPG. We could easily make gpgkeys_* a whole new package if necessary. Just like GnuPG 1.9 is made up of a bunch of smaller packages, the keyserver helpers could be a small package that works with (and is presumably included with) GnuPG. > As we can't solve this problem right now and given that this is a > general problem not related only to GnuPG, I suggest that we suspend > this problem for now and wait for the GPLv3 which might help to fix > the problem. I will open a bug so that we don't forget about it. > > Okay? Valid questions have been raised about distributing binaries. I'm certainly okay with doing nothing, so long as it isn't going to leave us in a state where people can't or won't package and distribute GnuPG for fear of violating the license. David From wk at gnupg.org Thu Aug 3 16:51:19 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Aug 3 16:56:23 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <20060803141715.GB32029@jabberwocky.com> (David Shaw's message of "Thu, 3 Aug 2006 10:17:15 -0400") References: <44CEE759.4080105@comcast.net> <87fyggx3tf.fsf@wheatstone.g10code.de> <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <20060802191839.GB27691@jabberwocky.com> <87odv2npyn.fsf@wheatstone.g10code.de> <20060803130828.GA32029@jabberwocky.com> <87ejvyne3a.fsf@wheatstone.g10code.de> <20060803141715.GB32029@jabberwocky.com> Message-ID: <87zmelna8o.fsf@wheatstone.g10code.de> On Thu, 3 Aug 2006 16:17, David Shaw said: > That's not the case though - they were designed intentionally to be > able to run outside of GPG for general keyserver access. That's one They are part of GnuPG proper. They are external helpers to isolate network access from the actual encryption process. Russell Coker asked me right after he started to work on SELinux for such a feature. > gpgkeys_* is not a derivative work of GPG. We could easily make Right, they are even part of GnuPG. > gpgkeys_* a whole new package if necessary. Just like GnuPG 1.9 is > made up of a bunch of smaller packages, the keyserver helpers could be This would most likely be viewed as an artificial split to work around the terms of the GPL. This is based onlong in-person discussions with FSF staff members on whether this is valid way to not comply with the GPL. > Valid questions have been raised about distributing binaries. I'm > certainly okay with doing nothing, so long as it isn't going to leave > us in a state where people can't or won't package and distribute > GnuPG for fear of violating the license. It is not only about GnuPG is is about most non-trivial GPL packages. My point here is to not forget about these things and work on a solution. Printing a warning is something which would help to raise awareness of this problem. Shalom-Salam, Werner From dshaw at jabberwocky.com Thu Aug 3 17:55:02 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu Aug 3 17:53:42 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <87zmelna8o.fsf@wheatstone.g10code.de> References: <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <20060802191839.GB27691@jabberwocky.com> <87odv2npyn.fsf@wheatstone.g10code.de> <20060803130828.GA32029@jabberwocky.com> <87ejvyne3a.fsf@wheatstone.g10code.de> <20060803141715.GB32029@jabberwocky.com> <87zmelna8o.fsf@wheatstone.g10code.de> Message-ID: <20060803155502.GA341@jabberwocky.com> On Thu, Aug 03, 2006 at 04:51:19PM +0200, Werner Koch wrote: > On Thu, 3 Aug 2006 16:17, David Shaw said: > > > That's not the case though - they were designed intentionally to be > > able to run outside of GPG for general keyserver access. That's one > > They are part of GnuPG proper. They are external helpers to isolate > network access from the actual encryption process. Russell Coker > asked me right after he started to work on SELinux for such a feature. I never spoke with Russell Coker, so all I can say is my intent when I wrote the keyserver code was that they could be callable outside of GPG. I explicitly designed the API to be able to do this. I was a little surprised when people actually DID do this, as I didn't think anyone would, but nevertheless, the intent was to make it possible. > > Valid questions have been raised about distributing binaries. I'm > > certainly okay with doing nothing, so long as it isn't going to leave > > us in a state where people can't or won't package and distribute > > GnuPG for fear of violating the license. > > It is not only about GnuPG is is about most non-trivial GPL packages. > My point here is to not forget about these things and work on a > solution. Printing a warning is something which would help to raise > awareness of this problem. I think a warning would have to have so many qualifications it would just confuse people: "Warning: this build of GnuPG has optional portions which are linked to libcurl which in turn uses OpenSSL. You may or may not be able to distribute these portions in binary form depending on whether the target platform considers OpenSSL part of the OS or not, and whether OpenSSL can be considered part of the OS in the first place". Even that is hard for gpgkeys_ldap where you can't easily tell if you're using OpenSSL or not, or even if the LDAP library is GPL-compatible. Like I said, I'm perfectly okay doing nothing, but now that the issue has been raised, it is difficult to just drop, as we have a problem today that needs an answer: it has been asserted that distributing binaries of GnuPG that link to libcurl built on OpenSSL violates the GPL. That is to say, it is *against the law* to do so, and the copyright holder of GnuPG (FSF) could, if they chose to, take the infringer to court. It is not right to make such a statement and then walk away. All that accomplishes is to create FUD, and if a packager decides to throw up their hands and not package GnuPG rather then get involved in these questions, then we have caused harm. I think we need an official answer yes or no whether this is legal as things are now. It is difficult to design for the future if we do not know where we stand today. David From marcus.brinkmann at ruhr-uni-bochum.de Thu Aug 3 22:05:09 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Thu Aug 3 22:01:55 2006 Subject: gpgme after setuid In-Reply-To: <200608031603.51909.smenzel@gmx-gmbh.de> References: <200608031212.02860.smenzel@gmx-gmbh.de> <8764handjq.fsf@wheatstone.g10code.de> <200608031603.51909.smenzel@gmx-gmbh.de> Message-ID: <87u04tshze.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Thu, 3 Aug 2006 16:03:51 +0200, Stephan Menzel wrote: > > [1 ] > [1.1 ] > Am Donnerstag, 3. August 2006 15:39 schrieb Werner Koch: > > > And gpgme used to work in the daemon too but not anymore. I don't know > > > what happend but strace shows me gpgme is looking for gpgsm's config > > > files etc in the homedir of the user who actually started the daemon. > > > > That is right. The home directory is determined by the HOME > > environment variable. sudo for example does not change HOME. > > That's it! > Thank's a lot, you made my day happy despite the rain. Note that you can also set the home directory to be used explicitely with gpgme_ctx_set_engine_info. Marcus From alphasigmax at gmail.com Fri Aug 4 01:27:03 2006 From: alphasigmax at gmail.com (Alphax) Date: Fri Aug 4 01:28:13 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <20060803155502.GA341@jabberwocky.com> References: <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <20060802191839.GB27691@jabberwocky.com> <87odv2npyn.fsf@wheatstone.g10code.de> <20060803130828.GA32029@jabberwocky.com> <87ejvyne3a.fsf@wheatstone.g10code.de> <20060803141715.GB32029@jabberwocky.com> <87zmelna8o.fsf@wheatstone.g10code.de> <20060803155502.GA341@jabberwocky.com> Message-ID: <44D28647.7030107@gmail.com> David Shaw wrote: > Like I said, I'm perfectly okay doing nothing, but now that the issue > has been raised, it is difficult to just drop, as we have a problem > today that needs an answer: it has been asserted that distributing > binaries of GnuPG that link to libcurl built on OpenSSL violates the > GPL. That is to say, it is *against the law* to do so, and the > copyright holder of GnuPG (FSF) could, if they chose to, take the > infringer to court. > > It is not right to make such a statement and then walk away. All that > accomplishes is to create FUD, and if a packager decides to throw up > their hands and not package GnuPG rather then get involved in these > questions, then we have caused harm. > How hard is it to determine if libcurl has been built against OpenSSL or not? One possible solution would be to detect if it had been during the autoconf/automake process and not link to libcurl if it was (overridable somehow?); if it was, /then/ start printing big warnings. > I think we need an official answer yes or no whether this is legal as > things are now. It is difficult to design for the future if we do not > know where we stand today. > Has anyone asked on debian-legal or similar? -- Alphax Death to all fanatics! Down with categorical imperative! OpenPGP key: http://tinyurl.com/lvq4g -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 569 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20060804/49e2d70d/signature.pgp From dshaw at jabberwocky.com Fri Aug 4 02:54:01 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Fri Aug 4 02:52:39 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <44D28647.7030107@gmail.com> References: <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <20060802191839.GB27691@jabberwocky.com> <87odv2npyn.fsf@wheatstone.g10code.de> <20060803130828.GA32029@jabberwocky.com> <87ejvyne3a.fsf@wheatstone.g10code.de> <20060803141715.GB32029@jabberwocky.com> <87zmelna8o.fsf@wheatstone.g10code.de> <20060803155502.GA341@jabberwocky.com> <44D28647.7030107@gmail.com> Message-ID: <20060804005401.GA1160@jabberwocky.com> On Fri, Aug 04, 2006 at 08:57:03AM +0930, Alphax wrote: > David Shaw wrote: > > > Like I said, I'm perfectly okay doing nothing, but now that the issue > > has been raised, it is difficult to just drop, as we have a problem > > today that needs an answer: it has been asserted that distributing > > binaries of GnuPG that link to libcurl built on OpenSSL violates the > > GPL. That is to say, it is *against the law* to do so, and the > > copyright holder of GnuPG (FSF) could, if they chose to, take the > > infringer to court. > > > > It is not right to make such a statement and then walk away. All that > > accomplishes is to create FUD, and if a packager decides to throw up > > their hands and not package GnuPG rather then get involved in these > > questions, then we have caused harm. > > > > How hard is it to determine if libcurl has been built against OpenSSL or > not? One possible solution would be to detect if it had been during the > autoconf/automake process and not link to libcurl if it was (overridable > somehow?); if it was, /then/ start printing big warnings. We are technical people and so always think in terms of a technical solution (if we just linked to XXXXX, or defined YYYYY as part of the OS, or did such-and-such in autoconf, etc, etc). I have been doing that also, and it is not getting anywhere. The reality is that we can't have a technical solution until we know what the problem is, or even if there is a problem. > > I think we need an official answer yes or no whether this is legal as > > things are now. It is difficult to design for the future if we do not > > know where we stand today. > > > > Has anyone asked on debian-legal or similar? Countless times. And countless programmers with no legal training (like me) have given our opinions. Just google for "openssl curl gpl violation" and watch the sparks fly. Like Robert Hansen noted, all that doesn't really amount to much as a) we're not copyright lawyers, and b) we're not the copyright holder. I really think the FSF, as the copyright holder, needs to say yes or no to this indirect linking question. Perhaps they already have, but I have looked and cannot find a reference to it. Once there is an official answer, then we at least know where we stand and can talk about a solution, if needed. David From ludwig at Fh-Worms.de Fri Aug 4 11:36:38 2006 From: ludwig at Fh-Worms.de (Christoph Ludwig) Date: Fri Aug 4 11:35:25 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <87zmelna8o.fsf@wheatstone.g10code.de> References: <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <20060802191839.GB27691@jabberwocky.com> <87odv2npyn.fsf@wheatstone.g10code.de> <20060803130828.GA32029@jabberwocky.com> <87ejvyne3a.fsf@wheatstone.g10code.de> <20060803141715.GB32029@jabberwocky.com> <87zmelna8o.fsf@wheatstone.g10code.de> Message-ID: <20060804093638.GA6107@castellio.textgrid.it.fh-worms.de> On Thu, Aug 03, 2006 at 04:51:19PM +0200, Werner Koch wrote: > On Thu, 3 Aug 2006 16:17, David Shaw said: > > > That's not the case though - they were designed intentionally to be > > able to run outside of GPG for general keyserver access. That's one > > They are part of GnuPG proper. They are external helpers to isolate > network access from the actual encryption process. Russell Coker > asked me right after he started to work on SELinux for such a feature. > > > gpgkeys_* is not a derivative work of GPG. We could easily make > > Right, they are even part of GnuPG. > > > gpgkeys_* a whole new package if necessary. Just like GnuPG 1.9 is > > made up of a bunch of smaller packages, the keyserver helpers could be > > This would most likely be viewed as an artificial split to work around > the terms of the GPL. This is based onlong in-person discussions with > FSF staff members on whether this is valid way to not comply with the > GPL. Sorry to intrude - are there any online resources that summarize these discussions? And that give some guidelines what does (according to the FSF) constitute an effective "license barrier" between two applications. (As soon as they communicate over the network? As soon as they communicate over a standard protocoll like http? ...) Depending on the answer, a project I am with may be forced not to use the GPL for its own software (and consequently to stay clear from any GPL'ed software). Till now we assumed (too naively, perhaps) that we avoid any conflict if we do not actually link (with ld or one of its compiler frontends) against non-GPL code. Thanks Christoph -- FH Worms - University of Applied Sciences Fachbereich Informatik / Telekommunikation Erenburgerstr. 19, 67549 Worms, Germany From wk at gnupg.org Fri Aug 4 13:19:09 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Aug 4 13:21:36 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <20060804093638.GA6107@castellio.textgrid.it.fh-worms.de> (Christoph Ludwig's message of "Fri, 4 Aug 2006 11:36:38 +0200") References: <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <20060802191839.GB27691@jabberwocky.com> <87odv2npyn.fsf@wheatstone.g10code.de> <20060803130828.GA32029@jabberwocky.com> <87ejvyne3a.fsf@wheatstone.g10code.de> <20060803141715.GB32029@jabberwocky.com> <87zmelna8o.fsf@wheatstone.g10code.de> <20060804093638.GA6107@castellio.textgrid.it.fh-worms.de> Message-ID: <8764h8n3yq.fsf@wheatstone.g10code.de> On Fri, 4 Aug 2006 11:36, Christoph Ludwig said: > Sorry to intrude - are there any online resources that summarize these > discussions? And that give some guidelines what does (according to the FSF) > constitute an effective "license barrier" between two applications. (As soon > as they communicate over the network? As soon as they communicate over a > standard protocoll like http? ...) The GPL FAQ has some answers for you. For example http://www.gnu.org/licenses/gpl-faq.html#MereAggregation says: What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. Salam-Shalom, Werner From wk at gnupg.org Fri Aug 4 13:25:14 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Aug 4 13:31:34 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <20060803155502.GA341@jabberwocky.com> (David Shaw's message of "Thu, 3 Aug 2006 11:55:02 -0400") References: <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <20060802191839.GB27691@jabberwocky.com> <87odv2npyn.fsf@wheatstone.g10code.de> <20060803130828.GA32029@jabberwocky.com> <87ejvyne3a.fsf@wheatstone.g10code.de> <20060803141715.GB32029@jabberwocky.com> <87zmelna8o.fsf@wheatstone.g10code.de> <20060803155502.GA341@jabberwocky.com> Message-ID: <871wrwn3ol.fsf@wheatstone.g10code.de> On Thu, 3 Aug 2006 17:55, David Shaw said: > today that needs an answer: it has been asserted that distributing > binaries of GnuPG that link to libcurl built on OpenSSL violates the > GPL. That is to say, it is *against the law* to do so, and the > copyright holder of GnuPG (FSF) could, if they chose to, take the > infringer to court. Not only that. Section 4 of the GPL will automatically terminate the right gained under the GPL, thus you may only run the software but not distribute or modify it anymore. Thus I'd like to warn people so they don't accidently fall into this trap. Point taken, I'll take this issue to the FSF. Shalom-Salam, Werner From marcus.brinkmann at ruhr-uni-bochum.de Fri Aug 4 19:49:03 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri Aug 4 19:47:01 2006 Subject: Better proxy support available via libcurl? In-Reply-To: <20060804093638.GA6107@castellio.textgrid.it.fh-worms.de> References: <20060802003606.GC7139@jabberwocky.com> <87lkq7tz0u.fsf@wheatstone.g10code.de> <20060802121732.GF7139@jabberwocky.com> <878xm7rqlh.fsf@wheatstone.g10code.de> <20060802191839.GB27691@jabberwocky.com> <87odv2npyn.fsf@wheatstone.g10code.de> <20060803130828.GA32029@jabberwocky.com> <87ejvyne3a.fsf@wheatstone.g10code.de> <20060803141715.GB32029@jabberwocky.com> <87zmelna8o.fsf@wheatstone.g10code.de> <20060804093638.GA6107@castellio.textgrid.it.fh-worms.de> Message-ID: <87odv0s86o.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Fri, 4 Aug 2006 11:36:38 +0200, Christoph Ludwig wrote: > Sorry to intrude - are there any online resources that summarize these > discussions? And that give some guidelines what does (according to the FSF) > constitute an effective "license barrier" between two applications. (As soon > as they communicate over the network? As soon as they communicate over a > standard protocoll like http? ...) See Werner's link to the FAQ. In addition, please note that there is a good reason to _not_ define what the "license barrier" is: The FSF wants the maximum protection available under law. Any definition on their part can only reduce their protection, not enlarge it. Thus, they remain vague. Also, the issue is _not_ a matter of technology (consider single-address space operating systems, just for example, or the other extreme, distributed computing with migrating threads). > Depending on the answer, a project I am with may be forced not to use the > GPL for its own software (and consequently to stay clear from any GPL'ed > software). Till now we assumed (too naively, perhaps) that we avoid any > conflict if we do not actually link (with ld or one of its compiler frontends) > against non-GPL code. You can send the details about your project to gnu@gnu.org, and they will look into it and give their advice. Thanks, Marcus From hp489 at hszk.bme.hu Tue Aug 8 22:38:17 2006 From: hp489 at hszk.bme.hu (=?ISO-8859-1?Q?Hajdu_P=E9ter?=) Date: Wed Aug 9 00:06:53 2006 Subject: signing message problem Message-ID: <44D8F639.6080501@hszk.bme.hu> Hi! I've got a problem while signing message with gpgme. I'm really new to gpgme, so please be patient. Here is my code: error = gpgme_data_new_from_file(&message,"./tempfile",1); error = gpgme_new( &context ); gpgme_set_armor( context, 1); error = gpgme_op_keylist_start(context,NULL,0); gpgme_key_ref( key ); while ( !(error = gpgme_op_keylist_next (context, &key)) ) { printf("%s\n",gpg_strerror(error)); uid = key->uids; str = uid->uid; printf("%s\n",str); error = gpgme_signers_add( context, key); printf("%s\n",gpg_strerror( error )); gpgme_key_release( key ); } gpgme_op_keylist_end( context ); memset(buf,0,sizeof(buf)); gpgme_data_new(&signature); error = gpgme_op_sign( context, message, signature, GPGME_SIG_MODE_NORMAL ); gpgme_data_release(message); printf("%s\n",gpg_strerror( error )); memset(buf,0,sizeof(buf)); printf("%d\n",gpgme_data_read( signature, buf, sizeof(buf) )); printf("%s",buf); gpgme_data_release(signature); gpgme_release(context); That's not the entire code, I've cut out error handling. At the end, gpgme_data_read reads 0 data from signature, it looks like it's empty. It reads in ./tempfile correctly, and it reads my keys too, and there were no errors. I really don't know what's wrong. Please help, and sorry for my bad english. Peter Hajdu From marcus.brinkmann at ruhr-uni-bochum.de Wed Aug 9 08:37:37 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed Aug 9 08:36:42 2006 Subject: signing message problem In-Reply-To: <44D8F639.6080501@hszk.bme.hu> References: <44D8F639.6080501@hszk.bme.hu> Message-ID: <8764h2s9ce.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 08 Aug 2006 22:38:17 +0200, Hajdu P?ter wrote: > > Hi! > > I've got a problem while signing message with gpgme. I'm really new to > gpgme, so please be patient. Here is my code: [...] > error = gpgme_op_sign( context, message, signature, > GPGME_SIG_MODE_NORMAL ); > gpgme_data_release(message); > printf("%s\n",gpg_strerror( error )); > memset(buf,0,sizeof(buf)); You need to rewind the file pointer here: gpgme_data_seek (signature, 0, SEEK_SET); > printf("%d\n",gpgme_data_read( signature, buf, sizeof(buf) )); > printf("%s",buf); > gpgme_data_release(signature); > gpgme_release(context); > > > That's not the entire code, I've cut out error handling. As a side note, it's recommended (by me :) to always send small, but complete examples, ie files that compile, and with error handling. This allows others to reproduce the problem easier. In this case, I could see the mistake immediately, but this is not always the case. Thanks, Marcus From wk at gnupg.org Wed Aug 9 10:19:27 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Aug 9 10:21:45 2006 Subject: signing message problem In-Reply-To: <44D8F639.6080501@hszk.bme.hu> (Hajdu =?utf-8?Q?P=C3=A9ter's?= message of "Tue, 08 Aug 2006 22:38:17 +0200") References: <44D8F639.6080501@hszk.bme.hu> Message-ID: <874pwme2y8.fsf@wheatstone.g10code.de> On Tue, 8 Aug 2006 22:38, Hajdu P?ter said: > gpgme_key_ref( key ); Why are you doing this? KEY will only be initialized with the next call. > while ( !(error = gpgme_op_keylist_next (context, &key)) ) { while ( !error && !(error = gpgme_op_keylist_next (context, &key)) ) Is better to catch an error in gpgme_op_keylist_next. BTW, better don't use the name "error" because it is commonly used as a fucntion name (e.g. in glibc). > memset(buf,0,sizeof(buf)); > printf("%d\n",gpgme_data_read( signature, buf, sizeof(buf) )); > printf("%s",buf); ret = gpgme_data_seek (signature, 0, SEEK_SET); printf("%d\n", (ret=gpgme_data_read( signature, buf, sizeof(buf)) )); printf("%.*s",(int)ret, buf); You should also use gpgme_set_armor if you want to use printf. Please also read the chapter about Largefile support in the gpgme manual. Better code to print a result goes like this: ret = gpgme_data_seek (dh, 0, SEEK_SET); if (ret) fail_if_err (gpgme_error_from_errno (errno)); while ((ret = gpgme_data_read (dh, buf, sizeof buf)) > 0) fwrite (buf, ret, 1, stdout); if (ret < 0) fail_if_err (gpgme_error_from_errno (errno)); Salam-Shalom, Werner From martin at linux-ip.net Thu Aug 10 08:48:43 2006 From: martin at linux-ip.net (Martin A. Brown) Date: Thu Aug 10 10:55:48 2006 Subject: gpg-agent: patch to provide --foreground option Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings GnuPG developers, I have recently begun using gpg-agent and have desired to be able to use one of the common process supervision utilities [0,1,2,3] to manage the gpg-agent process (to restart gpg-agent in the event the process croaks for any reason). My initial workaround [4] seems to work, but I thought I might be able to provide a patch to gpg-agent which would allow the process to remain in the foreground, but accept commands on a socket as it does in --daemon mode. Attached is a patch which adds the "--foreground" option to the gpg-agent binary for version gnupg-1.9.21 [5]. I welcome any feedback about the patch. - -Martin [0] http://cr.yp.to/daemontools/supervise.html [1] http://smarden.org/runit/runsv.8.html [2] http://offog.org/code/freedt.html [3] http://www.plope.com/software/supervisor/ http://www.plope.com/software/supervisor2/ [4] My supervised shell script ========================== #! /bin/bash # # -- start up gpg-agent in the foreground AGENT_FILE="$HOME/.gpg-agent-info" env - HOME=$HOME \ gpg-agent \ --write-env-file "$AGENT_FILE" \ --no-detach \ --daemon \ sleep 999d A line in $HOME/.bashrc: ======================== . $HOME/.gpg-agent-info >/dev/null ; export GPG_AGENT_INFO [5] ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.9.21.tar.bz2 - -- Martin A. Brown http://linux-ip.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFE2tbRHEoZD1iZ+YcRAquTAKC5eBVtHmK92Qc+dmST/zPe7amPbACgjfzp JFZJYLtEqBG/eU4Dx0/nOvk= =j6gU -----END PGP SIGNATURE----- -------------- next part -------------- diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index fc2a200..3bcacd6 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -74,6 +74,7 @@ enum cmd_and_opt_values oLogFile, oServer, oDaemon, + oForeground, oBatch, oPinentryProgram, @@ -108,8 +109,9 @@ static ARGPARSE_OPTS opts[] = { { 301, NULL, 0, N_("@Options:\n ") }, - { oServer, "server", 0, N_("run in server mode (foreground)") }, + { oServer, "server", 0, N_("run in server mode (pipe_server)") }, { oDaemon, "daemon", 0, N_("run in daemon mode (background)") }, + { oForeground, "foreground", 0, N_("do not fork") }, { oVerbose, "verbose", 0, N_("verbose") }, { oQuiet, "quiet", 0, N_("be somewhat more quiet") }, { oSh, "sh", 0, N_("sh-style command output") }, @@ -445,6 +447,7 @@ main (int argc, char **argv ) int nogreeting = 0; int pipe_server = 0; int is_daemon = 0; + int is_foreground = 0; int nodetach = 0; int csh_style = 0; char *logfile = NULL; @@ -619,6 +622,7 @@ #endif case oSh: csh_style = 0; break; case oServer: pipe_server = 1; break; case oDaemon: is_daemon = 1; break; + case oForeground: is_foreground = 1; nodetach = 1; break; case oDisplay: default_display = xstrdup (pargs.r.ret_str); break; case oTTYname: default_ttyname = xstrdup (pargs.r.ret_str); break; @@ -748,7 +752,7 @@ #define GC_OPT_FLAG_NO_ARG_DESC (1UL << /* If this has been called without any options, we merely check whether an agent is already running. We do this here so that we don't clobber a logfile but print it directly to stderr. */ - if (!pipe_server && !is_daemon) + if (!pipe_server && !is_daemon && !is_foreground) { log_set_prefix (NULL, JNLIB_LOG_WITH_PREFIX); check_for_running_agent (0); @@ -787,7 +791,7 @@ #endif { /* this is the simple pipe based server */ start_command_handler (-1, -1); } - else if (!is_daemon) + else if (!is_daemon && !is_foreground) ; /* NOTREACHED */ else { /* Regular server mode */ @@ -829,21 +833,34 @@ #endif parent_pid = getpid (); fflush (NULL); -#ifdef HAVE_W32_SYSTEM pid = getpid (); +#ifdef HAVE_W32_SYSTEM printf ("set GPG_AGENT_INFO=%s;%lu;1\n", socket_name, (ulong)pid); #else /*!HAVE_W32_SYSTEM*/ - pid = fork (); - if (pid == (pid_t)-1) + if (is_daemon) { - log_fatal ("fork failed: %s\n", strerror (errno) ); - exit (1); + pid = fork (); + if (pid == (pid_t)-1) + { + log_fatal ("fork failed: %s\n", strerror (errno) ); + exit (1); + } + else if (pid) + { /* parent; is_daemon = 1 */ + close(fd); + if (opt.ssh_support) + close(fd_ssh); + } + else + { /* child; is_daemon = 2 */ + ++is_daemon; + } } - else if (pid) - { /* We are the parent */ - char *infostr, *infostr_ssh_sock, *infostr_ssh_pid; - - close (fd); + + char *infostr, *infostr_ssh_sock, *infostr_ssh_pid; + + if ( is_foreground || is_daemon == 1 ) + { /* We are the proud parent (or in foreground mode) */ /* Create the info string: :: */ if (asprintf (&infostr, "GPG_AGENT_INFO=%s:%lu:1", @@ -871,11 +888,6 @@ #else /*!HAVE_W32_SYSTEM*/ } } - *socket_name = 0; /* Don't let cleanup() remove the socket - - the child should do this from now on */ - if (opt.ssh_support) - *socket_name_ssh = 0; - if (env_file_name) { FILE *fp; @@ -899,7 +911,17 @@ #else /*!HAVE_W32_SYSTEM*/ } } + if (is_daemon == 1) + { + *socket_name = 0; /* Don't let cleanup() remove the socket - + the child should do this from now on */ + if (opt.ssh_support) + *socket_name_ssh = 0; + } + } + if (is_daemon == 1) + { if (argc) { /* Run the program given on the commandline. */ if (putenv (infostr)) @@ -953,15 +975,19 @@ #else /*!HAVE_W32_SYSTEM*/ printf ("%s; export SSH_AGENT_PID;\n", infostr_ssh_pid); } } - free (infostr); /* (Note that a vanilla free is here correct.) */ - if (opt.ssh_support) - { - free (infostr_ssh_sock); - free (infostr_ssh_pid); - } - exit (0); } - /*NOTREACHED*/ + } + + if (is_foreground || is_daemon == 1) + { + free (infostr); /* (Note that a vanilla free is here correct.) */ + if (opt.ssh_support) + { + free (infostr_ssh_sock); + free (infostr_ssh_pid); + } + if (is_daemon == 1) /* traditional invocation, parent exits */ + exit (0); } /* End parent */ /* From hlmuller at yahoo.com Thu Aug 10 14:34:47 2006 From: hlmuller at yahoo.com (Harvey Muller) Date: Thu Aug 10 16:25:50 2006 Subject: gpg: invalid options Message-ID: <20060810123447.915.qmail@web53603.mail.yahoo.com> I previously installed gnupg 1.4.4 along with pcsc-lite 1.3.1 and the ozscrlx pcmcia driver, and had it successfully working. Additionally I have been working on an installation script, and added the necessary steps to the script. Everything installs as normal, the smartcard is recognized, but now I'm getting the following error message: gpg: invalid option "--card-status" Previously I had to set --disable-ccid or the driver would emit apdu errors, but now this also causes the same error message but the complaint changes to "--disable-ccid" I've reviewed all my notes, and the documentation thoroughly and cannot determine the cause of the error. Can anyone provide help? Thanks. From hlmuller at yahoo.com Thu Aug 10 19:21:12 2006 From: hlmuller at yahoo.com (Harvey Muller) Date: Thu Aug 10 19:20:11 2006 Subject: GPG errors Message-ID: <20060810172112.52032.qmail@web53604.mail.yahoo.com> I apologize if this is a dual post. I confirmed my subscription after I sent this, and wanted to make sure it was indeed received: I previously installed gnupg 1.4.4 along with pcsc-lite 1.3.1 and the ozscrlx pcmcia driver, and had it successfully working. Additionally I have been working on an installation script, and added the necessary steps to the script. Everything installs as normal, the smartcard is recognized, but now I'm getting the following error message: gpg: invalid option "--card-status" Previously I had to set --disable-ccid or the driver would emit apdu errors, but now this also causes the same error message but the complaint changes to "--disable-ccid" I've reviewed all my notes, and the documentation thoroughly and cannot determine the cause of the error. Can anyone provide help? Thanks. From stuff at babylonfarms.com Thu Aug 10 19:57:00 2006 From: stuff at babylonfarms.com (Troy) Date: Thu Aug 10 21:25:30 2006 Subject: Down load problems Message-ID: <44DB736C.3020604@babylonfarms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello, For a little over a month I have not been able to down load SVN/CVS files and more recently was not able to access gnupgs main ftp sites. After 4 days of trouble shooting my ISP came to the conclusion that some how a range of IPs were being blocked by the fore mentioned sites. They have given me a static IP for the time being (as temp. fix) and will re-assign some of there IP addresses so that I can access the files I've have used in the past. I don't know why this would happen and thought..... 1) you should know that this is happening 2) Maybe you could shed some light on the subject if your aware of this happening. If you have any other questions please feel free to contact me. Troy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5-wT192-tlw-p4 (MingW32) Comment: http://www.babylonfarms.com/secure/0xF8180E9E_pub.asc iQEVAwUBRNtzanWqn5z4GA6eAQgDIwf+PzYZZ85p8/P3DtAd1ZzcFMMZyDcFSrU5 t1XspvdNU9wCkQpr7/O6tt2zHX3/DJb0StgH3/coCy/FljswQglQqaFsKNhCE0lt roPtgC7f0wYCwH9TY1/6GUO92ZMPIaAbhZi1N58YS2QSS2eRjA6O5xvtkd2K+Ai0 f11M+GNyn8YC8g+c/vXb69wCVnttFxbbsOGDRDhKlESSMQe8Vgnu0EN6SOng0AAm bE8VaMBi/ZhQiw0qerIkSR2+8Nw2ZrjJr6lxl5tAdK0HeTGGrPc37VXVJ7Xp6s8F CAMC1VCmtbAyNo6VuHQVy+pvdsMCItgtZEE/YErWpK0uefh8xIcX8A== =lA+1 -----END PGP SIGNATURE----- From wk at gnupg.org Fri Aug 11 13:26:17 2006 From: wk at gnupg.org (Werner Koch) Date: Fri Aug 11 13:31:31 2006 Subject: GPG errors In-Reply-To: <20060810172112.52032.qmail@web53604.mail.yahoo.com> (Harvey Muller's message of "Thu, 10 Aug 2006 10:21:12 -0700 (PDT)") References: <20060810172112.52032.qmail@web53604.mail.yahoo.com> Message-ID: <871wrn5x9i.fsf@wheatstone.g10code.de> On Thu, 10 Aug 2006 19:21, Harvey Muller said: > gpg: invalid option "--card-status" Please tell us the entire command line you used to call gpg as well as the content of the gpg.conf. You might want to check that --card-status is not preceded by an non-option. Salam-Shalom, Werner From npcole at yahoo.co.uk Wed Aug 16 19:38:44 2006 From: npcole at yahoo.co.uk (Nicholas Cole) Date: Wed Aug 16 19:38:20 2006 Subject: --with-colons and --search Message-ID: <20060816173844.10210.qmail@web26705.mail.ukl.yahoo.com> I could be wrong(TM) but the --with-colons format when searching keyservers doesn't seem to be the same as the normal --with-colons listing. If I'm right, surely this is a bug? Or at least something that should be documented. :) Best wishes, N ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html From dshaw at jabberwocky.com Wed Aug 16 19:44:48 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Aug 16 19:43:20 2006 Subject: --with-colons and --search In-Reply-To: <20060816173844.10210.qmail@web26705.mail.ukl.yahoo.com> References: <20060816173844.10210.qmail@web26705.mail.ukl.yahoo.com> Message-ID: <20060816174448.GA28394@jabberwocky.com> On Wed, Aug 16, 2006 at 06:38:44PM +0100, Nicholas Cole wrote: > I could be wrong(TM) but the --with-colons format when > searching keyservers doesn't seem to be the same as > the normal --with-colons listing. If I'm right, > surely this is a bug? Or at least something that > should be documented. :) Not a bug. The needs of a keyserver and the needs of a crypto program occasionally overlap, but not the same. David From sms at antinode.org Wed Aug 16 23:30:18 2006 From: sms at antinode.org (Steven M. Schweda) Date: Wed Aug 16 23:33:45 2006 Subject: GnuPG 1.4.5 v, VMS. Message-ID: <06081616301846_2027FAC5@antinode.org> Greetings: I recently did a port of GnuPG 1.4.5 to VMS. As a result I have some questions, complaints, and suggestions which may be of some interest. For example: 1. I wrote a VMS-specific entropy gatherer (different from the one HP supplied in its GnuPG 1.2.3 kit), but I have no confidence in its value. Is there any handy test program to which I could attach it for testing (quality evaluation)? 2. On VMS (and Tru64), the DEC/Compaq/HP C compiler(s) would normally emit oodles of PTRMISMATCH and/or PTRMISMATCH1 warnings. The current scheme is to disable these warnings, but they could be prevented by some more careful variable typing and/or some well placed type casts. 3. Similarly, an oodle of QUESTCOMPARE and QUESTCOMPARE1 informationals could be prevented with some simple (and harmless) type casts. 4. The VMS compiler is happier with external names shorter than 32 characters. The VMS-specific "config.h" can "#define" its way around them, but things would look nicer if "libintl_nl_default_default_domain" (33) and "libintl_nl_current_default_domain" (33) were a little shorter. 5. Currently, the "g10defs.h" file is created by the "configure" script, which is not helpful on VMS (where that script is not used). It would be more convenient if the kit included a template file instead, which could then be edited, either by the "configure" script or by some VMS-specific procedure, to create the ultimate "g10defs.h" file. 6. As VMS currently runs on multiple system types, my normal builder scheme creates binaries in architecture-specific subdirectories with names like "alpha", "ia64", and "vax". On Alpha systems, this can cross paths with the "mpi/alpha" directory which contains assembly language source files instead of VMS Alpha binaries. For the time being, I've renamed the original "mpi/alpha" to "mpi/src-alpha" in my stuff, and if some change like that could be main-streamed, I'd be happier. As might be expected, there are several changes required to the source code to allow building and proper operation on VMS. The changes I've made could use more testing than I've done, but it might be nice, eventually, to get some VMS-specific code integrated into the mainstream sources. http://antinode.org/dec/sw/gnupg.html A summary of the changes is included in the release note there: http://antinode.org/ftp/gnupg/gnupg-1_4_5a_vms/vms_notes.txt If anyone has any interest, questions, complaints, suggestions, or whatever, feel free to let me know. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 From hlmuller at yahoo.com Thu Aug 17 21:42:52 2006 From: hlmuller at yahoo.com (Harvey Muller) Date: Thu Aug 17 22:41:59 2006 Subject: gpg: invalid options Message-ID: <20060817194252.3563.qmail@web53611.mail.yahoo.com> > > From: Werner Koch > CC: gnupg-devel@gnupg.org > To: Harvey Muller > Date: Fri, 11 Aug 2006 13:26:17 +0200 > Subject: Re: GPG errors > > On Thu, 10 Aug 2006 19:21, Harvey Muller said: > > > gpg: invalid option "--card-status" > > Please tell us the entire command line you used to > call gpg as well as Commands used to produce errors: gpg --card-status gpg --disable-ccid > the content of the gpg.conf. The gpg.conf stripped of comments: keyserver hkp://subkeys.pgp.net hidden-encrypt-to 0x12277FBC! hidden-encrypt-to 0xCC28B36C! default-recipient 0x12277FBC! default-recipient 0xCC28B36C! > > You might want to check that --card-status is not > preceded by an > non-option. As shown above, this wasn't the case. > > > Salam-Shalom, > > Werner I've since compared the install script used (system and gnupg), and could not find error. I'm in the process of a manual install, to see if I can identify where I may have gone wrong. When I first successfully installed gnupg, pcsc-lite, and the ozscrlx driver, it was from a base install. I still suspect the script may have an error, but cannot yet identify it. So I'm trying to recreate the first successful attempt, and then will try to identify the source of the error. I do not think any of the applications are at fault, just seeing if anyone has any clue where to look, as it isn't plain to me. Best regards. From bob at xyzzy.org.uk Fri Aug 18 11:08:14 2006 From: bob at xyzzy.org.uk (Bob Dunlop) Date: Fri Aug 18 20:44:21 2006 Subject: pcsc-wrapper dying problem + patch Message-ID: <20060818090814.GA27678@xyzzy.org.uk> Hi, I've been having problems with scdaemon or more correctly the pcsc-wrapper program dying on me after which no communication with the smartcard has been possible until the gpg-agent is restarted. I'm using gnupg 1.9.21 and pcsc-lite 1.3.1-r1 with a SCR335 reader on a Gentoo linux system. I've traced the problem to the fact that the USB hub my reader is attached to (my terminal) is powered down whenever the screen goes into deep sleep. When power is restored pcsc-wrapper gets confused on the next card access and terminates. The following is a patch to pcsc-wrapper.c to fix this problem. Actually most of it is minor code cleanups I'd made while investigating the problem, the actual fix is the very last entry which ignores a PCSC_E_INVALID_HANDLE error when attempting a pcsc_disconnect(). --- pcsc-wrapper.c-orig 2006-06-20 16:32:59.000000000 +0000 +++ pcsc-wrapper.c 2006-08-18 08:40:48.000000000 +0000 @@ -373,6 +373,16 @@ } +/* Release the card context and tidy a few related vars */ +static void +release_context_and_tidy () +{ + pcsc_release_context (pcsc_context); + free (current_rdrname); + current_rdrname = NULL; + pcsc_card = 0; + pcsc_protocol = 0; +} /* Handle a open request. The argument is expected to be a string @@ -471,9 +481,7 @@ { fprintf (stderr, PGM": pcsc_connect failed: %s (0x%lx)\n", pcsc_error_string (err), err); - pcsc_release_context (pcsc_context); - free (current_rdrname); - current_rdrname = NULL; + release_context_and_tidy (); request_failed (err); return; } @@ -524,9 +532,7 @@ return; } - free (current_rdrname); - current_rdrname = NULL; - pcsc_release_context (pcsc_context); + release_context_and_tidy (); request_succeeded (NULL, 0); } @@ -567,17 +573,20 @@ } status = 0; - if ( (rdrstates[0].event_state & PCSC_STATE_PRESENT) ) - status |= 2; - if ( !(rdrstates[0].event_state & PCSC_STATE_MUTE) ) - status |= 4; - /* We indicate a useful card if it is not in use by another - application. This is because we only use exclusive access - mode. */ - if ( (status & 6) == 6 - && !(rdrstates[0].event_state & PCSC_STATE_INUSE) ) - status |= 1; - + if ( !(rdrstates[0].event_state & PCSC_STATE_UNKNOWN) ) + { + if ( (rdrstates[0].event_state & PCSC_STATE_PRESENT) ) + status |= 2; + if ( !(rdrstates[0].event_state & PCSC_STATE_MUTE) ) + status |= 4; + /* We indicate a useful card if it is not in use by another + application. This is because we only use exclusive access + mode. */ + if ( (status & 6) == 6 + && !(rdrstates[0].event_state & PCSC_STATE_INUSE) ) + status |= 1; + } + /* First word is identical to the one used by apdu.c. */ buf[0] = 0; buf[1] = 0; @@ -618,6 +627,8 @@ if (pcsc_card) { err = pcsc_disconnect (pcsc_card, PCSC_LEAVE_CARD); + if (err == 0x80100003) /* Invalid handle. (already disconnected) */ + err = 0; if (err) { fprintf (stderr, PGM": pcsc_disconnect failed: %s (0x%lx)\n", -- Bob Dunlop From dirk.traulsen at lypso.de Sat Aug 19 11:05:42 2006 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Sat Aug 19 12:59:25 2006 Subject: bug report: showphoto on WinXP Message-ID: <44E6F086.20226.1AB1A3DD@dirk.traulsen.lypso.de> Hi, I've run into problems while looking into photo-IDs. Scenario: gpg 1.4.5 on German WinXP For this test the gpg.conf contains only "no-greeting", so no photo- viewer was chosen and I will use the keys with photo-IDs from doc/samplekeys.asc from the source of the stable branch. At the end, you will find a screencopy with comments. When I issue showphoto in the edit-key-shell, WinXP asks as expected which program I want to use to show the photo: the Open with-window. When I check in parallel, the image file exits where it should be, in the TEMP directory in a new random directory gpg-XYZXYZ. But when I choose in the WinXP-Open with-window a program to show the photo, it results in an error message by the program (but not from gpg in the console): For example mspaint issues: "C:DOKUME~\Dirk\LOKALE~\Temp\gpg-DC963C\CA57AD7C.jpg is no valid path." The reason is that the directory and file are deleted before the program can access them. When I alternatively choose "Quit" in the WinXP-Open with-window, the message "Access denied" comes in the console which seams to stem from WinXP. When I give the photo-viewer as option on the command line, it works. But giving the same line in the gpg.conf, does not work. Maybe I made a syntax mistake here? At last I have a proposal for the naming of the image file. When there is more than one photo-ID on the key and one does not preselect a uid, then both photo-IDs are shown one after the other. That's ok, but they both get the same name made of the key-ID, e.g. B2D7795E.jpg. My suggestion would be a name like KEYID-UID.jpg, e.g. B2D7795E-UID3.jpg. This is a really small change, but would make it clearer, if you want save the pictures for example. Hope this helps, Dirk ===== Screencopy with comments ============================ C:\>gpg -k C:/Dokumente und Einstellungen/Dirk/Anwendungsdaten/gnupg\pubring.gpg --------------------------------------------------------------------- pub 1024D/B2D7795E 2001-01-04 uid Philip R. Zimmermann uid Philip R. Zimmermann uid [jpeg image of size 3369] uid [jpeg image of size 3457] uid Philip R. Zimmermann sub 3072g/A8E92834 2001-01-04 pub 2048R/CA57AD7C 2004-12-06 uid PGP Global Directory Verification Key uid [jpeg image of size 3400] C:\>gpg --ed pgp pub 2048R/CA57AD7C created: 2004-12-06 expires: never usage: SC trust: unknown validity: unknown [ unknown] (1). PGP Global Directory Verification Key [ unknown] (2) [jpeg image of size 3400] Command> showphoto Displaying jpeg photo ID of size 3400 for key CA57AD7C (uid 2) #### Comment: Here I see the WinXP-Open with-window #### Comment: to choose a program for presenting the picture. #### Comment: In parallel on the XP-console: XP: C:\DOKUME~1\Dirk\LOKALE~1\Temp>dir gpg-* XP: XP: Verzeichnis von C:\DOKUME~1\Dirk\LOKALE~1\Temp XP: XP: 19.08.2006 10:55 gpg-2C4D5A #### Comment: After unsuccessfully choosing a program #### Comment: the directory gets deleted first and the #### Comment: opening fails. XP: C:\DOKUME~1\Dirk\LOKALE~1\Temp>dir gpg-* XP: XP: Verzeichnis von C:\DOKUME~1\Dirk\LOKALE~1\Temp XP: XP: Datei nicht gefunden #### Comment: Translated "File not found", but meaning #### Comment: directory not found. #### Comment: No message from gpg here. Command> showphoto Displaying jpeg photo ID of size 3400 for key CA57AD7C (uid 2) Zugriff verweigert #### Comment: Here I quitted the WinXP-Open with-window. #### Comment: "Zugriff verweigert" is "Access denied" and #### Comment: seams to be a WinXP message. Command> q C:\>gpg --photo-viewer "%SystemRoot%\system32\mspaint.exe %i" --ed pgp pub 2048R/CA57AD7C created: 2004-12-06 expires: never usage: SC trust: unknown validity: unknown [ unknown] (1). PGP Global Directory Verification Key [ unknown] (2) [jpeg image of size 3400] Command> showphoto Displaying jpeg photo ID of size 3400 for key CA57AD7C (uid 2) #### Comment: With a specified photo-viewer it worked fine. Command> q #### Comment: Now unsuccessful with the same string in the gpg.conf #### Comment: photo-viewer "%SystemRoot%\system32\mspaint.exe %i" #### Comment: I tried it without "" too. #### Comment: Maybe a syntax error by me? C:\>gpg --ed pgp pub 2048R/CA57AD7C created: 2004-12-06 expires: never usage: SC trust: unknown validity: unknown [ unknown] (1). PGP Global Directory Verification Key [ unknown] (2) [jpeg image of size 3400] Command> showphoto Displaying jpeg photo ID of size 3400 for key CA57AD7C (uid 2) gpg: system error while calling external program: No such file or directory gpg: unable to display photo ID! From dshaw at jabberwocky.com Sat Aug 19 16:08:08 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sat Aug 19 16:06:38 2006 Subject: bug report: showphoto on WinXP In-Reply-To: <44E6F086.20226.1AB1A3DD@dirk.traulsen.lypso.de> References: <44E6F086.20226.1AB1A3DD@dirk.traulsen.lypso.de> Message-ID: <20060819140808.GA3166@jabberwocky.com> On Sat, Aug 19, 2006 at 11:05:42AM +0200, Dirk Traulsen wrote: > C:\>gpg --photo-viewer "%SystemRoot%\system32\mspaint.exe %i" --ed > pgp This will work. > #### Comment: Now unsuccessful with the same string in the gpg.conf > #### Comment: photo-viewer "%SystemRoot%\system32\mspaint.exe %i" > #### Comment: I tried it without "" too. > #### Comment: Maybe a syntax error by me? No. %SystemRoot% is not a real path. It's a variable. In the first case, the shell expands it for you. David From dirk.traulsen at lypso.de Sun Aug 20 08:45:33 2006 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Sun Aug 20 08:42:54 2006 Subject: bug report: showphoto on WinXP In-Reply-To: <20060819140808.GA3166@jabberwocky.com> References: <44E6F086.20226.1AB1A3DD@dirk.traulsen.lypso.de>, <20060819140808.GA3166@jabberwocky.com> Message-ID: <44E8212D.3665.1F57AF1C@dirk.traulsen.lypso.de> Am 19 Aug 2006 um 10:08 hat David Shaw geschrieben: > > C:\>gpg --photo-viewer "%SystemRoot%\system32\mspaint.exe %i" > > --ed pgp > > This will work. Yes, I wrote it did: #### Comment: With a specified photo-viewer it worked fine. > > #### Comment: Now unsuccessful with the same string in the gpg.conf > > #### Comment: photo-viewer "%SystemRoot%\system32\mspaint.exe %i" > > #### Comment: I tried it without "" too. Comment: Maybe a syntax > > #### error by me? > > No. %SystemRoot% is not a real path. It's a variable. In the first > case, the shell expands it for you. Ah, thanks, I thought the paths in the option file would be delivered to the shell and so expanded, too. But what about the bug? Could you reproduce it? Dirk From wk at gnupg.org Mon Aug 21 09:57:37 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 21 10:02:05 2006 Subject: pcsc-wrapper dying problem + patch In-Reply-To: <20060818090814.GA27678@xyzzy.org.uk> (Bob Dunlop's message of "Fri, 18 Aug 2006 10:08:14 +0100") References: <20060818090814.GA27678@xyzzy.org.uk> Message-ID: <878xli7c7i.fsf@wheatstone.g10code.de> On Fri, 18 Aug 2006 11:08, Bob Dunlop said: > I've traced the problem to the fact that the USB hub my reader is attached > to (my terminal) is powered down whenever the screen goes into deep sleep. > When power is restored pcsc-wrapper gets confused on the next card access > and terminates. Thanks. Applied to SVN. Shalom-Salam, Werner From wk at gnupg.org Mon Aug 21 10:01:29 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 21 10:06:41 2006 Subject: gpg: invalid options In-Reply-To: <20060817194252.3563.qmail@web53611.mail.yahoo.com> (Harvey Muller's message of "Thu, 17 Aug 2006 12:42:52 -0700 (PDT)") References: <20060817194252.3563.qmail@web53611.mail.yahoo.com> Message-ID: <874pw67c12.fsf@wheatstone.g10code.de> On Thu, 17 Aug 2006 21:42, Harvey Muller said: > Commands used to produce errors: > > gpg --card-status > gpg --disable-ccid Please check that you get this result: $ grep CARD config.h #define ENABLE_CARD_SUPPORT 1 If not, something must be broken with your configure. For example the dlopen function is not available. Salam-Shalom, Werner From niki.waibel at wipro.com Tue Aug 22 15:31:51 2006 From: niki.waibel at wipro.com (Niki W Waibel) Date: Tue Aug 22 17:02:35 2006 Subject: libassuan-0.6.10 -- does not compile on solaris (yet) In-Reply-To: <442674df0608100102i46cc23f6sb2e0b4424334ec96@mail.gmail.com> References: <442674df0608100102i46cc23f6sb2e0b4424334ec96@mail.gmail.com> Message-ID: <20060822153151.7677f59b.niki.waibel@wipro.com> On Thu, 10 Aug 2006 10:02:32 +0200 Fabrizio Listello wrote: > Hi! > I'm trying to compiloe libassuan 0.6.10 on OpenSolaris and I'm looking for > the patch file libassuan-0.6.10.nww-wo-autoconf.patch.gz. > > Where can I find it? sorry for no reply for such a long time. i was (offline) on holidays ;-) hmmm, it is in the sf svn repo: http://svn.sourceforge.net/viewvc/fbuild/patches/ i'll send a separate email to you only, with the attached file... rds, niki -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : /pipermail/attachments/20060822/cdd7f8e6/attachment.pgp From dirk.traulsen at lypso.de Sun Aug 27 12:07:54 2006 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Sun Aug 27 12:05:29 2006 Subject: cross-certification Message-ID: <44F18B1A.12879.441D75BF@dirk.traulsen.lypso.de> Hi, I had a look at cross-certification and found a few points. 1. There is a typing error in the man page: Index: doc/gpg.texi =================================================================== --- doc/gpg.texi (Revision 4227) +++ doc/gpg.texi (Arbeitskopie) @@ -2178,7 +2178,7 @@ handing out the secret key. @item --require-cross-certification -@itemx --no-require-certification +@itemx --no-require-cross-certification When verifying a signature made from a subkey, ensure that the cross certification "back signature" on the subkey is present and valid. This protects against a subtle attack against subkeys that can sign. 2. When one issues the help command In the edit-key menu, there comes a list of commands. "cross-certify" is missing. I had a look at keyedit.c and the non-listed commands are the short cuts and the aliases. So it doesn't seem to be a deliberate ommision. Here is a proposal for a text. (The only other missing commands are delphoto and revphoto. Are they intentionally ommitted?) Index: g10/keyedit.c =================================================================== --- g10/keyedit.c (Revision 4227) +++ g10/keyedit.c (Arbeitskopie) @@ -1367,7 +1367,8 @@ { "key" , cmdSELKEY , 0, N_("select subkey N") }, { "check" , cmdCHECK , 0, N_("check signatures") }, { "c" , cmdCHECK , 0, NULL }, - { "cross-certify", cmdBACKSIGN , KEYEDIT_NOT_SK|KEYEDIT_NEED_SK, NULL }, + { "cross-certify", cmdBACKSIGN , KEYEDIT_NOT_SK|KEYEDIT_NEED_SK, N_("Add cross-certification signatures to signing subkeys") }, + /* Alias */ { "backsign", cmdBACKSIGN , KEYEDIT_NOT_SK|KEYEDIT_NEED_SK, NULL }, { "sign" , cmdSIGN , KEYEDIT_NOT_SK|KEYEDIT_TAIL_MATCH, N_("sign selected user IDs [* see below for related commands]") }, 3. When the option --require-cross-certification is given (and this will be default soon) and the signing subkey is not cross-certified, the following message comes and gpg stops. gpg: Signature made 08/22/06 10:02:04 using DSA key ID 0A77A149 gpg: WARNING: signing subkey 0A77A149 is not cross-certified gpg: please see http://www.gnupg.org/faq/subkey-cross-certify.html for more information gpg: Can't check signature: general error This seems a bit too harsh for me, especially when it will be default. The signature could be ok. It's really good, that gpg gives a link to follow, but not everyone can be forced to update its key. So a little help could be given for the ones who want to accept the risk. My proposal would be: gpg: Signature made 08/22/06 10:02:04 using DSA key ID 0A77A149 gpg: WARNING: signing subkey 0A77A149 is not cross-certified gpg: please see http://www.gnupg.org/faq/subkey-cross-certify.html for more information gpg: The option --require-cross-certification is set. gpg: To force signature check use option --no-require-cross-certification gpg: Can't check signature: general error Index: g10/sig-check.c =================================================================== --- g10/sig-check.c (Revision 4227) +++ g10/sig-check.c (Arbeitskopie) @@ -112,6 +112,11 @@ error. TODO: change the default to require this after more keys have backsigs. */ if(opt.flags.require_cross_cert) + /* The first log_info can be deleted, when + --require-cross-certification is default. */ + log_info("The option --require-cross-certification is set.\n"); + log_info("To force signature check use option --no-require-" + "cross-certification\n"); rc=G10ERR_GENERAL; } else if(pk->backsig==1) 4. I had a key with a signing subkey on one computer. I cross-certified it, which worked fine. Then I wanted to export and import it on another computer. gpg did not import (merge) the new key, because: gpg: key 12345678: already in secret keyring. gpg did not recognize the new cross-certification. I had to delete the old key before importing the new cross-certified one. Dirk From dirk.traulsen at lypso.de Sun Aug 27 12:07:55 2006 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Sun Aug 27 12:05:34 2006 Subject: gpgsplit Message-ID: <44F18B1B.23264.441D76E7@dirk.traulsen.lypso.de> Hi! gpgsplit is the nice programm which takes exported keys apart. But when the file is armoured, gpgsplit gives only a general error message: gpgsplit: invalid CTB 2d It would be nicer to give a hint what could be the reason: Index: tools/gpgsplit.c =================================================================== --- tools/gpgsplit.c (Revision 4227) +++ tools/gpgsplit.c (Arbeitskopie) @@ -782,7 +782,7 @@ if (!(ctb & 0x80)) { - log_error("invalid CTB %02x\n", ctb ); + log_error("invalid packet header CTB %02x (Possible reason: the file could be armoured.)\n", ctb ); return 1; } if ( (ctb & 0x40) ) Dirk From dirk.traulsen at lypso.de Sun Aug 27 12:07:54 2006 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Sun Aug 27 12:05:40 2006 Subject: minimize Message-ID: <44F18B1A.5629.441D764B@dirk.traulsen.lypso.de> Hi! When oone tries to minimize an already minimized key, gpg states that it is already clean, not minimized. This change would give the correct message. Dirk Index: g10/keyedit.c =================================================================== --- g10/keyedit.c (Revision 4227) +++ g10/keyedit.c (Arbeitskopie) @@ -3247,7 +3248,12 @@ modified=1; } else - tty_printf(_("User ID \"%s\": already clean\n"),user); + { + tty_printf(self_only==1? + "User ID \"%s\": already minimized\n": + "User ID \"%s\": already clean\n", + user); + } xfree(user); } From wk at gnupg.org Mon Aug 28 14:13:32 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 28 14:38:45 2006 Subject: [Announce] Libgcrypt 1.2.3 released Message-ID: <878xl93vo3.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 Mon Aug 28 19:19:05 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Aug 28 19:33:43 2006 Subject: [Announce] Gpg4win 1.0.6 released Message-ID: <87zmdo7p86.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 Wed Aug 30 08:50:12 2006 From: wk at gnupg.org (Werner Koch) Date: Wed Aug 30 08:56:30 2006 Subject: --output for --list-keys Message-ID: <87irka4t0b.fsf@wheatstone.g10code.de> Hi! While implementing --output for gpgsm I asked myself whether it will be useful and more consistent to allow the --output option also for commands like --list-keys. Sure, this won't go into gpg 1.4 but we can do such a change for gpg2 (from gnupg 1.9). Any opinions? Salam-Shalom, Werner From gdt at ir.bbn.com Wed Aug 30 13:59:09 2006 From: gdt at ir.bbn.com (Greg Troxel) Date: Wed Aug 30 13:57:39 2006 Subject: --output for In-Reply-To: <87irka4t0b.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 30 Aug 2006 08:50:12 +0200") References: <87irka4t0b.fsf@wheatstone.g10code.de> Message-ID: While implementing --output for gpgsm I asked myself whether it will be useful and more consistent to allow the --output option also for commands like --list-keys. Sure, this won't go into gpg 1.4 but we can do such a change for gpg2 (from gnupg 1.9). I didn't know about --output, so I read the help. Sure, I think it should be honored, and if not the command should fail. Stepping back: the big issue is metadata vs. data, so that one e.g. can verify a signature and put the sig validation output separately from the text. From this viewpoint, --list-keys outputs data, so it should respect --output. -- Greg Troxel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : /pipermail/attachments/20060830/8b2950c4/attachment.pgp From wk at gnupg.org Thu Aug 31 17:45:31 2006 From: wk at gnupg.org (Werner Koch) Date: Thu Aug 31 18:08:51 2006 Subject: [Announce] Libksba 1.0.0 released. Message-ID: <877j0o29k4.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 Ralf.Wildenhues at gmx.de Sat Aug 5 03:55:36 2006 From: Ralf.Wildenhues at gmx.de (Ralf Wildenhues) Date: Mon Sep 18 13:05:04 2006 Subject: Building libgpg-error on OS X 10.4 In-Reply-To: <8764hbt1p8.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <9F1966AC-B547-4724-8A7F-2408E922CDD9@gschmidt.org> <8764hbt1p8.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <20060805004709.GE17861@iam.uni-bonn.de> Hello, * Marcus Brinkmann wrote on Wed, Aug 02, 2006 at 08:46:59PM CEST: > > it seems that the libtool+gettext+automake machinery does not work > perfectly for libraries using gettext. If you use > --with-included-gettext, then a static version of libintl will be > built, and LTLIBINTL is set to the static library. But linking a > static library with a shared library is not guaranteed to work. In > fact, it gives a warning. Moreover, it actually fails on Mac OS X due > to missing -fno-common (because the static library is not built as > PIC). > > So, the question is, is there any solution to this, beside advising > Mac OS X users to never use the included gettext, but link dynamically > to an external gettext implementation? Shouldn't --with-included-gettext --disable-static work as well? I think using --disable-static on OS X is a good idea in general (but I'm clearly not an OS X expert). Cheers, Ralf From rgcpp at uol.com.br Wed Aug 30 13:58:01 2006 From: rgcpp at uol.com.br (Rafael Gustavo da Cunha Pereira Pinto) Date: Mon Sep 18 13:05:14 2006 Subject: SVN access problem Message-ID: <001a01c6cc1f$69fdc8d0$0101a8c0@steve> Hi folks, I just can't get the sources from the SVN servers. I am getting the same message over and over again > svn co svn://cvs.gnupg.org/gnupg/trunk gnupg svn: Connection closed unexpectedly BTW, I can access other SVN servers normally (GCC, Python, Wireshark, etc...) Any clue? Thanks Rafael -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.8/413 - Release Date: 8/8/2006