From henman at it.to-be.co.jp Fri Dec 1 03:32:35 2006 From: henman at it.to-be.co.jp (djh) Date: Fri Dec 1 03:30:48 2006 Subject: GPGME 1.0.3 Build Problem In-Reply-To: Your message of Thu, 30 Nov 2006 17:01:09 +0100 <87wt5cx6t6.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <20061130141425.2692@henman-np.b-eng.it.to-be.co.jp> <87wt5cx6t6.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <20061201113235.3912@henman-np.b-eng.it.to-be.co.jp> Thanks for your repsonse Marcus. > From: Marcus Brinkmann (GPGME member) > From: Henman: I have run into a build problem on cygwin system. > > > > > > I am not an expert in the utilities used to build gpgme. But, wonder why a library seems to be missing. Could this be a command line argument ordering problem?? > > It seems libtool doesn't support your target architecture well enough > for GPGME to build. libtool has been cygwin aware for several years and I've had no problems with it building many shared libraries. (Except for example, GMP in which they assumed possibly too much in libtool and was forced to explicity use CPPFLAGS="-DDLL_EXPORT" I can envision where something like that can be cause of non-portability in the gpgme building code. # # GPGME Make problem (November 30, 2006): (see below) # (cd .libs && rm -f libgpgme.la && ln -s ../libgpgme.la libgpgme.la) if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF ".deps/ath-pthread.Tpo" -c -o ath-pthread.lo ath-pthread.c; \ then mv -f ".deps/ath-pthread.Tpo" ".deps/ath-pthread.Plo"; else rm -f ".deps/ath-pthread.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF .deps/ath-pthread.Tpo -c ath-pthread.c -DPIC -o .libs/ath-pthread.o /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o libgpgme-pthread.la -rpath /usr/local/lib -version-info 15:0:4 ath-pthread.lo libgpgme-real.la stpcpy.lo memrchr.lo -lpthread -lgpg-error libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries ..... make[2]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/tests' Making all in gpg make[3]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/tests/gpg' if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../gpgme -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT t-encrypt.o -MD -MP -MF ".deps/t-encrypt.Tpo" -c -o t-encrypt.o t-encrypt.c; \ then mv -f ".deps/t-encrypt.Tpo" ".deps/t-encrypt.Po"; else rm -f ".deps/t-encrypt.Tpo"; exit 1; fi /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt.exe t-encrypt.o ../../gpgme/libgpgme.la mkdir .libs gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt.exe t-encrypt.o ../../gpgme/.libs/libgpgme.a /usr/lib/libgpg-error.dll.a -L/usr/lib /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a ../../gpgme/.libs/libgpgme.a(posix-sema.o): In posix-sema.c - undefined reference to `__gpgme_ath_mutex_destroy' - undefined reference to `__gpgme_ath_init' - undefined reference to `__gpgme_ath_mutex_lock' - undefined reference to `__gpgme_ath_mutex_unlock' - undefined reference to `__gpgme_ath_read' > We are using the mingw32 architecture, not cygwin, for our native Windows builds. I am using cygwin, a (unix) posix compliant system. GPGME should be able to be build without any problems. The problem should be looked into. I will do what I can, but need you experts help. Please look into the build code regarding building for "cygwin" ... Cygwin Group: Do any of you in the cygwin group know what the problem is? Regards, Henman From marcus.brinkmann at ruhr-uni-bochum.de Fri Dec 1 04:24:08 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri Dec 1 04:18:18 2006 Subject: GPGME 1.0.3 Build Problem In-Reply-To: <20061201113235.3912@henman-np.b-eng.it.to-be.co.jp> References: <20061130141425.2692@henman-np.b-eng.it.to-be.co.jp> <87wt5cx6t6.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <87slg0wb6v.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Fri, 01 Dec 2006 11:32:35 +0900, "djh" wrote: > > libtool has been cygwin aware for several years and I've had no problems with it building many shared libraries. (Except for example, GMP in which they assumed possibly too much in libtool and was forced to explicity use CPPFLAGS="-DDLL_EXPORT" Shared library support various dramatically across platforms. Libtool tries its best to patch it up and give a consistent picture, but it can not always provide. GPGME does some funny things with libraries to support multiple thread libraries. Read on. > I can envision where something like that can be cause of > non-portability in the gpgme building code. I gave it another look, and it seems to me that the problem could be the following: GPGME tries to build versions of GPGME linking against pthread and pth. These versions are built from a version of the library without any thread support (libgpgme-real.la), which is not installed. This non-installed library has undefined symbols, btw, but it seems that libtool does not hickup over those (possibly because it's not installed), or you didn't give us the warning message for that case. Then, GPGME builds the final library from the thread module, adding the non-installed libgpgme-real.la to the bundle via LIBADD. Ok, that's not really clean. The problem is that now the order is messed up: The thread module's symbols get first on the linker command line, then comes the non-installed library using those symbols, then comes the rest. However, this setup avoids building every file three times, cutting compile time to a third, and it seems to work OK on our main targets (and then some). Well, considering that it is not totally clean, I don't have a fundamental object to remove the libgpgme-real hack and build each file three times, if you test and submit a patch to that effect. I am also open to other suggestions. Thanks, Marcus > # > # GPGME Make problem (November 30, 2006): (see below) > # > (cd .libs && rm -f libgpgme.la && ln -s ../libgpgme.la libgpgme.la) > if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF ".deps/ath-pthread.Tpo" -c -o ath-pthread.lo ath-pthread.c; \ > then mv -f ".deps/ath-pthread.Tpo" ".deps/ath-pthread.Plo"; else rm -f ".deps/ath-pthread.Tpo"; exit 1; fi > gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF .deps/ath-pthread.Tpo -c ath-pthread.c -DPIC -o .libs/ath-pthread.o > /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o libgpgme-pthread.la -rpath /usr/local/lib -version-info 15:0:4 ath-pthread.lo libgpgme-real.la stpcpy.lo memrchr.lo -lpthread -lgpg-error > > libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries > > ..... > > make[2]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/tests' > Making all in gpg > make[3]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/tests/gpg' > if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../gpgme -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT t-encrypt.o -MD -MP -MF ".deps/t-encrypt.Tpo" -c -o t-encrypt.o t-encrypt.c; \ > then mv -f ".deps/t-encrypt.Tpo" ".deps/t-encrypt.Po"; else rm -f ".deps/t-encrypt.Tpo"; exit 1; fi > /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt.exe t-encrypt.o ../../gpgme/libgpgme.la > mkdir .libs > gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt.exe t-encrypt.o ../../gpgme/.libs/libgpgme.a /usr/lib/libgpg-error.dll.a -L/usr/lib /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a > ../../gpgme/.libs/libgpgme.a(posix-sema.o): In posix-sema.c > - undefined reference to `__gpgme_ath_mutex_destroy' > - undefined reference to `__gpgme_ath_init' > - undefined reference to `__gpgme_ath_mutex_lock' > - undefined reference to `__gpgme_ath_mutex_unlock' > - undefined reference to `__gpgme_ath_read' > > > We are using the mingw32 architecture, not cygwin, for our native Windows builds. > > I am using cygwin, a (unix) posix compliant system. GPGME should be able to be build without any problems. > > The problem should be looked into. I will do what I can, but need you experts help. > > Please look into the build code regarding building for "cygwin" ... > > Cygwin Group: > Do any of you in the cygwin group know what the problem is? > > Regards, > Henman > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > From henman at it.to-be.co.jp Fri Dec 1 05:09:32 2006 From: henman at it.to-be.co.jp (djh) Date: Fri Dec 1 05:07:20 2006 Subject: GPGME 1.0.3 Build Problem In-Reply-To: Your message of Fri, 01 Dec 2006 04:24:08 +0100 <87slg0wb6v.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <20061130141425.2692@henman-np.b-eng.it.to-be.co.jp> <87wt5cx6t6.wl%marcus.brinkmann@ruhr-uni-bochum.de> <87slg0wb6v.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <20061201130932.3152@henman-np.b-eng.it.to-be.co.jp> Thanks again for your response. > From: Marcus Brinkmann > ...Shared library support various dramatically across platforms. Libtool > tries its best to patch it up and give a consistent picture, but it > can not always provide. > .... > > I gave it another look, and it seems to me that the problem could be > the following: GPGME tries to build versions of GPGME linking against > pthread and pth. These versions are built from a version of the > library without any thread support (libgpgme-real.la), which is not > installed. This non-installed library has undefined symbols, btw, but > it seems that libtool does not hickup over those (possibly because > it's not installed), or you didn't give us the warning message for > that case. I did receive the below "warning" message prior to the undefined symbol errors as follow: ( This does contain the "libgpgme-real.la" that you mentioned. Is this what you meant? Regards, Henman ---- RE: libgpgme-real.la gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF .deps/ath-pthread.Tpo -c ath-pthread.c -DPIC -o .libs/ath-pthread.o /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o libgpgme-pthread.la -rpath /usr/local/lib -version-info 15:0:4 ath-pthread.lo libgpgme-real.la stpcpy.lo memrchr.lo -lpthread -lgpg-error libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries > Then, GPGME builds the final library from the thread module, adding > the non-installed libgpgme-real.la to the bundle via LIBADD. > .... > > # > > # GPGME Make problem (November 30, 2006): (see below) > > # > > (cd .libs && rm -f libgpgme.la && ln -s ../libgpgme.la libgpgme.la) > > if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF ".deps/ath-pthread.Tpo" -c -o ath-pthread.lo ath-pthread.c; \ > > then mv -f ".deps/ath-pthread.Tpo" ".deps/ath-pthread.Plo"; else rm -f ".deps/ath-pthread.Tpo"; exit 1; fi > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT ath-pthread.lo -MD -MP -MF .deps/ath-pthread.Tpo -c ath-pthread.c -DPIC -o .libs/ath-pthread.o > > /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o libgpgme-pthread.la -rpath /usr/local/lib -version-info 15:0:4 ath-pthread.lo libgpgme-real.la stpcpy.lo memrchr.lo -lpthread -lgpg-error > > > > libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries > > > > ..... > > > > make[2]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/tests' > > Making all in gpg > > make[3]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/tests/gpg' > > if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../gpgme -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT t-encrypt.o -MD -MP -MF ".deps/t-encrypt.Tpo" -c -o t-encrypt.o t-encrypt.c; \ > > then mv -f ".deps/t-encrypt.Tpo" ".deps/t-encrypt.Po"; else rm -f ".deps/t-encrypt.Tpo"; exit 1; fi > > /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt.exe t-encrypt.o ../../gpgme/libgpgme.la > > mkdir .libs > > gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt.exe t-encrypt.o ../../gpgme/.libs/libgpgme.a /usr/lib/libgpg-error.dll.a -L/usr/lib /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a > > ../../gpgme/.libs/libgpgme.a(posix-sema.o): In posix-sema.c > > - undefined reference to `__gpgme_ath_mutex_destroy' > > - undefined reference to `__gpgme_ath_init' > > - undefined reference to `__gpgme_ath_mutex_lock' > > - undefined reference to `__gpgme_ath_mutex_unlock' > > - undefined reference to `__gpgme_ath_read' > > > > ----- end ----- From marcus.brinkmann at ruhr-uni-bochum.de Fri Dec 1 05:32:54 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri Dec 1 05:28:22 2006 Subject: GPGME 1.0.3 Build Problem In-Reply-To: <20061201130932.3152@henman-np.b-eng.it.to-be.co.jp> References: <20061130141425.2692@henman-np.b-eng.it.to-be.co.jp> <87wt5cx6t6.wl%marcus.brinkmann@ruhr-uni-bochum.de> <87slg0wb6v.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <87r6vkw809.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Fri, 01 Dec 2006 13:09:32 +0900, "djh" wrote: > > > Thanks again for your response. > > > From: Marcus Brinkmann > > ...Shared library support various dramatically across platforms. Libtool > > tries its best to patch it up and give a consistent picture, but it > > can not always provide. > > > .... > > > > I gave it another look, and it seems to me that the problem could be > > the following: GPGME tries to build versions of GPGME linking against > > pthread and pth. These versions are built from a version of the > > library without any thread support (libgpgme-real.la), which is not > > installed. This non-installed library has undefined symbols, btw, but > > it seems that libtool does not hickup over those (possibly because > > it's not installed), or you didn't give us the warning message for > > that case. > > I did receive the below "warning" message prior to the undefined symbol errors as follow: ( This does contain the "libgpgme-real.la" that you mentioned. Is this what you meant? I saw that one in the original report. I meant rather a warning when linking the actual libgpgme-real.la file, which must be some lines before the one you posted. Thanks, Marcus From simon at josefsson.org Fri Dec 1 10:45:06 2006 From: simon at josefsson.org (Simon Josefsson) Date: Fri Dec 1 11:56:20 2006 Subject: safely concatenating strings in portable C (Re: GnuPG 1.4 and 2.0 buffer overflow) In-Reply-To: <20061130014135.GB1999@openwall.com> (Solar Designer's message of "Thu\, 30 Nov 2006 04\:41\:35 +0300") References: <87mz6cke3l.fsf@wheatstone.g10code.de> <20061130014135.GB1999@openwall.com> Message-ID: <87irgwuezh.fsf@latte.josefsson.org> Solar Designer writes: > However, in those (most common) cases when all you need is to concatenate > strings, relying on or providing an snprintf() implementation might be > an overkill. Gnulib's xvasprintf detects %s...%s format strings, which makes the code easy to analyse for that case. (Note that the x* memory allocation functions never returns NULL, it exits the program instead.) Unfortunately, it doesn't seem like this optimization has been ported to gnulib's non-x* printf replacement functions (snprintf, asprintf etc) yet. /Simon static inline char * xstrcat (size_t argcount, va_list args) { char *result; va_list ap; size_t totalsize; size_t i; char *p; /* Determine the total size. */ totalsize = 0; va_copy (ap, args); for (i = argcount; i > 0; i--) { const char *next = va_arg (ap, const char *); totalsize = xsum (totalsize, strlen (next)); } va_end (ap); /* Test for overflow in the summing pass above or in (totalsize + 1) below. Also, don't return a string longer than INT_MAX, for consistency with vasprintf(). */ if (totalsize == SIZE_MAX || totalsize > INT_MAX) { errno = EOVERFLOW; return NULL; } /* Allocate and fill the result string. */ result = XNMALLOC (totalsize + 1, char); p = result; for (i = argcount; i > 0; i--) { const char *next = va_arg (args, const char *); size_t len = strlen (next); memcpy (p, next, len); p += len; } *p = '\0'; return result; } char * xvasprintf (const char *format, va_list args) { char *result; /* Recognize the special case format = "%s...%s". It is a frequently used idiom for string concatenation and needs to be fast. We don't want to have a separate function xstrcat() for this purpose. */ { size_t argcount = 0; const char *f; for (f = format;;) { if (*f == '\0') /* Recognized the special case of string concatenation. */ return xstrcat (argcount, args); if (*f != '%') break; f++; if (*f != 's') break; f++; argcount++; } } if (vasprintf (&result, format, args) < 0) { if (errno == ENOMEM) xalloc_die (); return NULL; } return result; } From marcus.brinkmann at ruhr-uni-bochum.de Fri Dec 1 12:55:54 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri Dec 1 12:53:03 2006 Subject: Build Problem In-Reply-To: <20061130141425.2692@henman-np.b-eng.it.to-be.co.jp> References: <20061130141425.2692@henman-np.b-eng.it.to-be.co.jp> Message-ID: <87mz67x22d.wl%marcus.brinkmann@ruhr-uni-bochum.de> Hi, I checked in a change to GPGME to build all libraries directly from the sources, instead of going through a static lib. Automake is smart enough to not build source files twice if the CFLAGS/CPPFLAGS are identical, which we can achieve without too much trouble. Can you please test the below patch, or, even better, SVN repository revision 1192? Thanks, Marcus 2006-12-01 Marcus Brinkmann * Makefile.am (libgpgme_real_la_SOURCES): Rename to main_sources. (libgpgme_la_SOURCES, libgpgme_pthread_la_SOURCES, libgpgme_glib_la_SOURCES, libgpgme_pth_la_SOURCES): Add $(main_sources). (libgpgme_la_DEPENDENCIES, libgpgme_la_LIBADD, libgpgme_pthread_la_DEPENDENCIES, libgpgme_pthread_la_LIBADD, libgpgme_pth_la_DEPENDENCIES, libgpgme_pth_la_LIBADD, libgpgme_glib_la_DEPENDENCIES, libgpgme_glib_la_LIBADD): Remove libgpgme-real.la. (noinst_LTLIBRARIES): Removed. (libgpgme_glib_la_CFLAGS, libgpgme_pth_la_CFLAGS): Removed. (AM_CFLAGS): New variable. Index: gpgme/Makefile.am =================================================================== --- gpgme/Makefile.am (revision 1191) +++ gpgme/Makefile.am (working copy) @@ -45,7 +45,6 @@ ltlib_gpgme_extra = endif -noinst_LTLIBRARIES = libgpgme-real.la lib_LTLIBRARIES = libgpgme.la $(ltlib_gpgme_extra) \ $(ltlib_gpgme_pthread) $(ltlib_gpgme_pth) @@ -77,7 +76,12 @@ gpgsm_components = endif -libgpgme_real_la_SOURCES = \ +# These are the source files common to all library versions. We used +# to build a non-installed library for that, but that does not work +# correctly on all platforms (in particular, one can not specify the +# right linking order with libtool, as the non-installed version has +# unresolved symbols to the thread module. +main_sources = \ gpgme.h util.h conversion.c get-env.c context.h ops.h \ data.h data.c data-fd.c data-stream.c data-mem.c data-user.c \ data-compat.c \ @@ -92,18 +96,22 @@ $(gpgsm_components) sema.h priv-io.h $(system_components) \ debug.c debug.h gpgme.c version.c error.c -libgpgme_la_SOURCES = ath.h ath.c $(system_components_not_extra) -libgpgme_pthread_la_SOURCES = \ +libgpgme_la_SOURCES = $(main_sources) \ + ath.h ath.c $(system_components_not_extra) +libgpgme_pthread_la_SOURCES = $(main_sources) \ ath.h ath-pthread.c $(system_components_not_extra) -libgpgme_pth_la_SOURCES = ath.h ath-pth.c $(system_components_not_extra) +libgpgme_pth_la_SOURCES = $(main_sources) \ + ath.h ath-pth.c $(system_components_not_extra) if BUILD_W32_GLIB -libgpgme_glib_la_SOURCES = ath.h ath.c w32-glib-io.c +libgpgme_glib_la_SOURCES = $(main_sources) ath.h ath.c w32-glib-io.c endif -AM_CPPFLAGS = $(assuan_cppflags) @GPG_ERROR_CFLAGS@ +# We use a global CFLAGS and CPPFLAGS setting for all library +# versions, because then every object file is only compiled once. +AM_CPPFLAGS = $(assuan_cppflags) @GPG_ERROR_CFLAGS@ @PTH_CPPFLAGS@ +AM_CFLAGS = @PTH_CFLAGS@ @GLIB_CFLAGS@ - if HAVE_W32_SYSTEM LTRCCOMPILE = $(LIBTOOL) --mode=compile $(RC) \ @@ -141,36 +149,33 @@ libgpgme_la_LDFLAGS = $(gpgme_res_ldflag) $(no_undefined) $(export_symbols) \ $(libgpgme_version_script_cmd) -version-info \ @LIBGPGME_LT_CURRENT@:@LIBGPGME_LT_REVISION@:@LIBGPGME_LT_AGE@ -libgpgme_la_DEPENDENCIES = libgpgme-real.la $(assuan_libobjs) \ +libgpgme_la_DEPENDENCIES = $(assuan_libobjs) \ @LTLIBOBJS@ $(srcdir)/libgpgme.vers $(gpgme_deps) -libgpgme_la_LIBADD = libgpgme-real.la $(assuan_libobjs) @LTLIBOBJS@ \ +libgpgme_la_LIBADD = $(assuan_libobjs) @LTLIBOBJS@ \ @GPG_ERROR_LIBS@ @NETLIBS@ libgpgme_pthread_la_LDFLAGS = $(libgpgme_version_script_cmd) -version-info \ @LIBGPGME_LT_CURRENT@:@LIBGPGME_LT_REVISION@:@LIBGPGME_LT_AGE@ -libgpgme_pthread_la_DEPENDENCIES = libgpgme-real.la $(assuan_libobjs) \ +libgpgme_pthread_la_DEPENDENCIES = $(assuan_libobjs) \ @LTLIBOBJS@ $(srcdir)/libgpgme.vers -libgpgme_pthread_la_LIBADD = libgpgme-real.la $(assuan_libobjs) @LTLIBOBJS@ \ +libgpgme_pthread_la_LIBADD = $(assuan_libobjs) @LTLIBOBJS@ \ -lpthread @GPG_ERROR_LIBS@ @NETLIBS@ -libgpgme_pth_la_CFLAGS = $(AM_CFLAGS) @PTH_CFLAGS@ -libgpgme_pth_la_CPPFLAGS = $(AM_CPPFLAGS) @PTH_CPPFLAGS@ libgpgme_pth_la_LDFLAGS = @PTH_LDFLAGS@ \ $(libgpgme_version_script_cmd) -version-info \ @LIBGPGME_LT_CURRENT@:@LIBGPGME_LT_REVISION@:@LIBGPGME_LT_AGE@ -libgpgme_pth_la_DEPENDENCIES = libgpgme-real.la $(assuan_libobjs) \ +libgpgme_pth_la_DEPENDENCIES = $(assuan_libobjs) \ @LTLIBOBJS@ $(srcdir)/libgpgme.vers -libgpgme_pth_la_LIBADD = libgpgme-real.la $(assuan_libobjs) @LTLIBOBJS@ \ +libgpgme_pth_la_LIBADD = $(assuan_libobjs) @LTLIBOBJS@ \ @PTH_LIBS@ @GPG_ERROR_LIBS@ @NETLIBS@ if BUILD_W32_GLIB libgpgme_glib_la_LDFLAGS = $(gpgme_res_ldflag) $(no_undefined) \ $(export_symbols) $(libgpgme_version_script_cmd) -version-info \ @LIBGPGME_LT_CURRENT@:@LIBGPGME_LT_REVISION@:@LIBGPGME_LT_AGE@ -libgpgme_glib_la_CFLAGS = $(AM_CFLAGS) @GLIB_CFLAGS@ -libgpgme_glib_la_DEPENDENCIES = libgpgme-real.la $(assuan_libobjs) \ +libgpgme_glib_la_DEPENDENCIES = $(assuan_libobjs) \ @LTLIBOBJS@ $(srcdir)/libgpgme.vers $(gpgme_deps) -libgpgme_glib_la_LIBADD = libgpgme-real.la $(assuan_libobjs) @LTLIBOBJS@ \ +libgpgme_glib_la_LIBADD = $(assuan_libobjs) @LTLIBOBJS@ \ @GPG_ERROR_LIBS@ @GLIB_LIBS@ @NETLIBS@ endif From yselkowitz at users.sourceforge.net Fri Dec 1 05:17:23 2006 From: yselkowitz at users.sourceforge.net (Yaakov S (Cygwin Ports)) Date: Fri Dec 1 13:31:29 2006 Subject: GPGME 1.0.3 Build Problem In-Reply-To: <87slg0wb6v.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <20061130141425.2692@henman-np.b-eng.it.to-be.co.jp> <87wt5cx6t6.wl%marcus.brinkmann@ruhr-uni-bochum.de> <87slg0wb6v.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <456FACD3.7080700@users.sourceforge.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marcus Brinkmann wrote: > I gave it another look, and it seems to me that the problem could be > the following: GPGME tries to build versions of GPGME linking against > pthread and pth. These versions are built from a version of the > library without any thread support (libgpgme-real.la), which is not > installed. This non-installed library has undefined symbols, btw, but > it seems that libtool does not hickup over those (possibly because > it's not installed), or you didn't give us the warning message for > that case. > > Then, GPGME builds the final library from the thread module, adding > the non-installed libgpgme-real.la to the bundle via LIBADD. > > Ok, that's not really clean. The problem is that now the order is > messed up: The thread module's symbols get first on the linker command > line, then comes the non-installed library using those symbols, then > comes the rest. However, this setup avoids building every file three > times, cutting compile time to a third, and it seems to work OK on our > main targets (and then some). That's not a problem because libtool encloses the noinst libs with - -Wl,--{,no-}whole-archive, allowing for just this situation. > Well, considering that it is not totally clean, I don't have a > fundamental object to remove the libgpgme-real hack and build each > file three times, if you test and submit a patch to that effect. I am > also open to other suggestions. That should not be necessary. The following patch fixes the build of gpgme-1.1.2 on cygwin: http://cygwin-ports.cvs.sourceforge.net/*checkout*/cygwin-ports/ports/libs/gpgme/gpgme-1.1.2-1.src.patch A similar patch may be necessary for libgpgme_pth_la_LDFLAGS; pth isn't part of the distro however, so I haven't tried it. (If the above is true, you can just remove the $(no_undefined) conditional and use '-no-undefined' throughout.) Yaakov Cygwin Ports -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFb6zSpiWmPGlmQSMRAsxMAJ0YcUya+rtiCaoe+MmMb5b6QpRl/QCgl7BS eAhkZhaoOIx78L8EDSWWY74= =Ey/1 -----END PGP SIGNATURE----- From christianbiere at gmx.de Fri Dec 1 14:39:02 2006 From: christianbiere at gmx.de (Christian Biere) Date: Fri Dec 1 14:33:30 2006 Subject: FreeBSD ports for libassuan 1.0.1 and gnupg 2.0.1 In-Reply-To: <456DD2D6.3000501@dougbarton.us> References: <456D5A54.5070900@dougbarton.us> <456D76B6.8010905@gmail.com> <87lklus4na.fsf@wheatstone.g10code.de> <456DD2D6.3000501@dougbarton.us> Message-ID: <20061201133902.GA26108@cyclonus> Doug Barton wrote: > BTW, I'm still seeing the "Warning: using insecure memory!" error, in > spite of having the no-secmem-warning option in my gpg.conf. Are you talking about FreeBSD? If so, why do you use this option? One should rather check why mlock() fails or is not used. -- Christian From marcus.brinkmann at ruhr-uni-bochum.de Fri Dec 1 14:53:36 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Fri Dec 1 14:48:10 2006 Subject: GPGME 1.0.3 Build Problem In-Reply-To: <456FACD3.7080700@users.sourceforge.net> References: <20061130141425.2692@henman-np.b-eng.it.to-be.co.jp> <87wt5cx6t6.wl%marcus.brinkmann@ruhr-uni-bochum.de> <87slg0wb6v.wl%marcus.brinkmann@ruhr-uni-bochum.de> <456FACD3.7080700@users.sourceforge.net> Message-ID: <87lklrwwm7.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Thu, 30 Nov 2006 22:17:23 -0600, "Yaakov S (Cygwin Ports)" wrote: > > Then, GPGME builds the final library from the thread module, adding > > the non-installed libgpgme-real.la to the bundle via LIBADD. > > > > Ok, that's not really clean. The problem is that now the order is > > messed up: The thread module's symbols get first on the linker command > > line, then comes the non-installed library using those symbols, then > > comes the rest. However, this setup avoids building every file three > > times, cutting compile time to a third, and it seems to work OK on our > > main targets (and then some). > > That's not a problem because libtool encloses the noinst libs with > - -Wl,--{,no-}whole-archive, allowing for just this situation. Ah, ok. > > Well, considering that it is not totally clean, I don't have a > > fundamental object to remove the libgpgme-real hack and build each > > file three times, if you test and submit a patch to that effect. I am > > also open to other suggestions. > > That should not be necessary. The following patch fixes the build of > gpgme-1.1.2 on cygwin: > > http://cygwin-ports.cvs.sourceforge.net/*checkout*/cygwin-ports/ports/libs/gpgme/gpgme-1.1.2-1.src.patch > > A similar patch may be necessary for libgpgme_pth_la_LDFLAGS; pth isn't > part of the distro however, so I haven't tried it. > > (If the above is true, you can just remove the $(no_undefined) > conditional and use '-no-undefined' throughout.) Interesting. Can you explain why this works? Anyway, I have changed GPGME in SVN HEAD to not use a non-installed library at all. This should fix the problem as well. It would be good if someone tested out if that is indeed the case. Thanks, Marcus From wk at gnupg.org Sat Dec 2 18:45:07 2006 From: wk at gnupg.org (Werner Koch) Date: Sat Dec 2 19:04:01 2006 Subject: [Announce] Re: GnuPG Logo Contest In-Reply-To: <87ac4w9fji.fsf@wheatstone.g10code.de> (Werner Koch's message of "Tue\, 19 Sep 2006 15\:01\:05 +0200") References: <87ac4w9fji.fsf@wheatstone.g10code.de> Message-ID: <87slfy9opo.fsf@wheatstone.g10code.de> Hello, Back in September I announced a contest for a new GnuPG logo. By the end of October I received 41 submissions from 31 parties. The original plan was to let all the authors of GnuPG who signed a copyright assignment with the FSF to vote on a new logo. However, I only received 11 answers and there was no clear result: Only one submission got 2 votes. It would have been unfair to take this as a decision. So I looked around and found the CIVS [1] which implements a Condorcet voting system. I fed it with the addresses of all subscribers of the gnupg-users and gnupg-devel mailing lists and started the process. >From the 1231 unique subscribers, 199 took the time to rank the submissions and casted their vote. This time the result is pretty clear: Thomas Wittek [2] from Cologne is the lucky winner. He will soon see his design used with GnuPG and also receive 50 percent of the received donation (we received as of now 215 Euro but further donations won't be rejected [3]). Unfortunately I can't offer him a mail alias thomas at gnupg because this has been assigned to the creator of the old logo. Ranks 2 and 3 are held by Robbie Tingey and Michel Blinn. They will receive an email alias for their contribution. If you like to see the new logo, point your browser to http://logo-contest.gnupg.org You will also find also the detailed results of the ballot, all submissions and the list of sponsors. I want to thank all who submitted a logo to the contest as well as those who worked on a logo but submitted it too late. There are some really cool designs and I hope that some can be reused for another project. Special thanks to the sponsors: Intevation GmbH, Markus Komosinski, Parag Mehta, Folkert van Heusden, Ralph Angenendt, Alexander Tomisch, Robert Workman, Simon Josefsson. The remaining funds will be used to help with a new website design. Many thanks to all, Werner [1] http://www.cs.cornell.edu/andru/civs.html [2] http://gedankenkonstrukt.de/ueber/ (German) [3] http://www.gnupg.org/misc/logo-contest.html -- Werner Koch The GnuPG Experts http://g10code.com Join the Fellowship and protect your Freedom! http://www.fsfe.org _______________________________________________ Gnupg-announce mailing list Gnupg-announce@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dshaw at jabberwocky.com Sun Dec 3 06:33:52 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sun Dec 3 06:39:57 2006 Subject: Odd keyserver problem In-Reply-To: <45607427.9020106@kfwebs.net> References: <1163948165l.3378l.0l@antares.localdomain> <45607427.9020106@kfwebs.net> Message-ID: <20061203053352.GE28620@jabberwocky.com> On Sun, Nov 19, 2006 at 04:11:35PM +0100, Kristian Fiskerstrand wrote: > Albrecht Dre? wrote, On 11/19/2006 03:55 PM: > > Hi all, > > > > I have an odd problem searching for a key on a HKP keyserver using GnuPG > > 1.4.5. Searching for a key using the mail address works fine (name & > > address removed for privacy): > > ... snip ... > > > Using the http interface of the key server properly returns the key when > > I enter the key id. Using any other key server, I get the same > > results. I am pretty sure this /did/ work with earlier versions of > > GnuPG. Any idea what goes wrong here? > > > > Generally when knowing the key ID you'd just use gpg --recv-key > 0x7108E308 though. This is true, but nevertheless people sometimes do --search-key on a key ID (I'm not really sure why). I have fixed this to work again for the next release. David From dshaw at jabberwocky.com Sun Dec 3 06:53:59 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sun Dec 3 06:52:21 2006 Subject: minimize In-Reply-To: <44F18B1A.5629.441D764B@dirk.traulsen.lypso.de> References: <44F18B1A.5629.441D764B@dirk.traulsen.lypso.de> Message-ID: <20061203055359.GF28620@jabberwocky.com> On Sun, Aug 27, 2006 at 12:07:54PM +0200, Dirk Traulsen wrote: > 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. Thanks. This is applied. David From marcus.brinkmann at ruhr-uni-bochum.de Sun Dec 3 14:46:44 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Sun Dec 3 14:43:39 2006 Subject: Odd keyserver problem In-Reply-To: <20061203053352.GE28620@jabberwocky.com> References: <1163948165l.3378l.0l@antares.localdomain> <45607427.9020106@kfwebs.net> <20061203053352.GE28620@jabberwocky.com> Message-ID: <87vektt7ln.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Sun, 3 Dec 2006 00:33:52 -0500, David Shaw wrote: > > Generally when knowing the key ID you'd just use gpg --recv-key > > 0x7108E308 though. > > This is true, but nevertheless people sometimes do --search-key on a > key ID (I'm not really sure why). I have fixed this to work again for > the next release. Well, I have a theory. First, the key ID is not consistently displayed in this form. In fact, the key ID is consistently displayed without the 0x prefix. Also, there is a strong motivation to use cut&paste with key IDs, because it's so cumbersome to enter random hex strings manually. A programmer's rule of thumb is "be strict in what you output, and liberal in what input you accept". Reversing it does not do any good. Also, software should just do what's "right". At least from the user perspective, a key ID (even without the 0x prefix) is perfectly distinguishable from a user ID component in most if not all cases. Sure, this is not actually true. But for all practical purposes it is. Thanks, Marcus From albrecht.dress at arcor.de Sun Dec 3 15:34:26 2006 From: albrecht.dress at arcor.de (=?iso-8859-1?q?Albrecht_Dre=DF?=) Date: Sun Dec 3 15:33:02 2006 Subject: Odd keyserver problem In-Reply-To: <87vektt7ln.wl%marcus.brinkmann@ruhr-uni-bochum.de> (from marcus.brinkmann@ruhr-uni-bochum.de on Sun Dec 3 14:46:44 2006) Message-ID: <1165156479l.3435l.1l@antares.localdomain> Am 03.12.06 14:46 schrieb(en) Marcus Brinkmann: > At Sun, 3 Dec 2006 00:33:52 -0500, > David Shaw wrote: > > > Generally when knowing the key ID you'd just use gpg --recv-key > > > 0x7108E308 though. > > > > This is true, but nevertheless people sometimes do --search-key on a > > key ID (I'm not really sure why). I have fixed this to work again for > > the next release. This syntax was used in a /very/ old (dated 2001) and /very/ dumb script which I didn't use that often, and which simply stopped working at some point... I am not sure where it came from, but iirc some old howto or man page versions advertised using names *or* key ids. The 2.0.0 man pages are more explicit. > A programmer's rule of thumb is "be strict in what you output, and > liberal in what input you accept". Looking through the man page, at some points where options accept "names" it might be handy to also allow "key-id" as cut'n'paste with a key id (as Marcus pointed out) is simply less effort than typing a name. Maybe the man page should make the distinction between "key-id" and "names" parameters clearer, or add a description what "names" actually should look like? Cheers, Albrecht. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Albrecht Dre? - Johanna-Kirchner-Stra?e 13 - D-53123 Bonn (Germany) Phone (+49) 228 6199571 - mailto:albrecht.dress@arcor.de GnuPG public key: http://www.mynetcologne.de/~nc-dreszal/pubkey.asc _________________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20061203/4ca049ec/attachment-0001.pgp From dshaw at jabberwocky.com Sun Dec 3 15:08:31 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Sun Dec 3 15:56:36 2006 Subject: Odd keyserver problem In-Reply-To: <87vektt7ln.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <1163948165l.3378l.0l@antares.localdomain> <45607427.9020106@kfwebs.net> <20061203053352.GE28620@jabberwocky.com> <87vektt7ln.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <20061203140831.GG28620@jabberwocky.com> On Sun, Dec 03, 2006 at 02:46:44PM +0100, Marcus Brinkmann wrote: > At Sun, 3 Dec 2006 00:33:52 -0500, > David Shaw wrote: > > > Generally when knowing the key ID you'd just use gpg --recv-key > > > 0x7108E308 though. > > > > This is true, but nevertheless people sometimes do --search-key on a > > key ID (I'm not really sure why). I have fixed this to work again for > > the next release. > > Well, I have a theory. > > First, the key ID is not consistently displayed in this form. In > fact, the key ID is consistently displayed without the 0x prefix. > Also, there is a strong motivation to use cut&paste with key IDs, > because it's so cumbersome to enter random hex strings manually. Sure, but that's not exactly what I was wondering about. I was wondering why people did --search-key on a key ID at all, rather than --recv-keys. --search-key only finds the key, and doesn't retrieve and import it until the user selects it. Since (virtually all of the time), searching for a key ID will find exactly one response, it's not as if there are choices in which key to select :) Nevertheless, 0x will now work in --search-key. I'm actually going to make one more change so that it works without 0x as well (which isn't a regression - it never worked). As you point out, a key ID, even without 0x, is very distinguishable from a user ID. David From henman at it.to-be.co.jp Mon Dec 4 10:42:01 2006 From: henman at it.to-be.co.jp (djh) Date: Mon Dec 4 10:40:13 2006 Subject: GPGME 1.0.3 Build Problem In-Reply-To: Your message of Fri, 01 Dec 2006 14:53:36 +0100 <87lklrwwm7.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <20061130141425.2692@henman-np.b-eng.it.to-be.co.jp> <87wt5cx6t6.wl%marcus.brinkmann@ruhr-uni-bochum.de> <87slg0wb6v.wl%marcus.brinkmann@ruhr-uni-bochum.de> <456FACD3.7080700@users.sourceforge.net> <87lklrwwm7.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <20061204184201.2936@henman-np.b-eng.it.to-be.co.jp> Marcus, thanks for your efforts. > Anyway, I have changed GPGME in SVN HEAD to not use a non-installed > library at all. This should fix the problem as well. It would be > good if someone tested out if that is indeed the case. > > Thanks, > Marcus here are the results I get from using everthing in: * gpgme-1.0.3.tar.gz with the exceptipn of Makefile.am, which I used the new 1192 revision Makefile.am which was mv'd to Makefile.am for the following: Regards, Darel Henman -------------------------------- Results -------------------------------- $ ./configure # configured as: (December 4, 2006) # GPGME v1.0.3 has been configured as follows: # GnuPG path: /usr/local/bin/gpg # GnuPG version: 1.4.5, min. 1.2.2 # # GpgSM path: no # GpgSM version: unknown, min. 1.9.6 # # GPGME Pthread: yes # GPGME Pth: $ make -k make all-recursive make[1]: Entering directory `/usr/src/gpgme/gpgme-1.0.3' Making all in gpgme make[2]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/gpgme' make all-am make[3]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/gpgme' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/usr/src/gpgme/gpgme-1.0.3/gpgme' make[2]: Leaving directory `/usr/src/gpgme/gpgme-1.0.3/gpgme' Making all in tests make[2]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/tests' Making all in gpg make[3]: Entering directory `/usr/src/gpgme/gpgme-1.0.3/tests/gpg' /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt.exe t-encrypt.o ../../gpgme/libgpgme.la gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt.exe t-encrypt.o ../../gpgme/.libs/libgpgme.a /usr/lib/libgpg-error.dll.a -L/usr/lib /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_destroy': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:62: undefined reference to `__gpgme_ath_mutex_destroy' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_subsystem_init': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:44: undefined reference to `__gpgme_ath_init' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_enter': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:50: undefined reference to `__gpgme_ath_mutex_lock' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_leave': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:56: undefined reference to `__gpgme_ath_mutex_unlock' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_read': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:75: undefined reference to `__gpgme_ath_read' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_write': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:97: undefined reference to `__gpgme_ath_write' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_waitpid': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:283: undefined reference to `__gpgme_ath_waitpid' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_select': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:363: undefined reference to `__gpgme_ath_select' collect2: ld returned 1 exit status make[3]: *** [t-encrypt.exe] Error 1 /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt-sym.exe t-encrypt-sym.o ../../gpgme/libgpgme.la gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt-sym.exe t-encrypt-sym.o ../../gpgme/.libs/libgpgme.a /usr/lib/libgpg-error.dll.a -L/usr/lib /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_destroy': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:62: undefined reference to `__gpgme_ath_mutex_destroy' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_subsystem_init': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:44: undefined reference to `__gpgme_ath_init' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_enter': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:50: undefined reference to `__gpgme_ath_mutex_lock' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_leave': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:56: undefined reference to `__gpgme_ath_mutex_unlock' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_read': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:75: undefined reference to `__gpgme_ath_read' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_write': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:97: undefined reference to `__gpgme_ath_writ e' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_waitpid': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:283: undefined reference to `__gpgme_ath_waitpid' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_select': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:363: undefined reference to `__gpgme_ath_select' collect2: ld returned 1 exit status make[3]: *** [t-encrypt-sym.exe] Error 1 /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt-sign.exe t-encrypt-sign.o ../../gpgme/libgpgme.la gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-encrypt-sign.exe t-encrypt-sign.o ../../gpgme/.libs/libgpgme.a /usr/lib/libgpg-error.dll.a -L/usr/lib /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_destroy': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:62: undefined reference to `__gpgme_ath_mutex_destroy' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_subsystem_init': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:44: undefined reference to `__gpgme_ath_init' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_enter': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:50: undefined reference to `__gpgme_ath_mutex_lock' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_leave': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:56: undefined reference to `__gpgme_ath_mutex_unlock' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_read': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:75: undefined reference to `__gpgme_ath_read' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_write': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:97: undefined reference to `__gpgme_ath_write' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_waitpid': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:283: undefined reference to `__gpgme_ath_waitpid' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_select': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:363: undefined reference to `__gpgme_ath_select' collect2: ld returned 1 exit status make[3]: *** [t-encrypt-sign.exe] Error 1 /bin/sh ../../libtool --tag=CC --mode=link gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-sign.exe t-sign.o ../../gpgme/libgpgme.la gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o t-sign.exe t-sign.o ../../gpgme/.libs/libgpgme.a /usr/lib/libgpg-error.dll.a -L/usr/lib /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_destroy': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:62: undefined reference to `__gpgme_ath_mutex_destroy' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_subsystem_init': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:44: undefined reference to `__gpgme_ath_init' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_enter': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:50: undefined reference to `__gpgme_ath_mutex_lock' ../../gpgme/.libs/libgpgme.a(posix-sema.o): In function `_gpgme_sema_cs_leave': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-sema.c:56: undefined reference to `__gpgme_ath_mutex_unlock' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_read': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:75: undefined reference to `__gpgme_ath_read' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_write': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:97: undefined reference to `__gpgme_ath_write' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_waitpid': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:283: undefined reference to `__gpgme_ath_waitpid' ../../gpgme/.libs/libgpgme.a(posix-io.o): In function `_gpgme_io_select': /usr/src/gpgme/gpgme-1.0.3/gpgme/posix-io.c:363: undefined reference to `__gpgme_ath_select' collect2: ld returned 1 exit status make[3]: *** [t-sign.exe] Error 1 . . snipped more of the same type repitition for undefined symbols . . make: *** [all] Error 2 -------------------------------- End of Results -------------------------------- Note: That all of these symbols: are found in libgpgme.a with either a 'U' or a 'T' type. Example: $ nm ../../gpgme/.libs/libgpgme.a | grep _gpgme_sema_cs_destroy T __gpgme_sema_cs_destroy $ nm ../../gpgme/.libs/libgpgme.a | grep __gpgme_ath_write U __gpgme_ath_write ---- End From wk at gnupg.org Mon Dec 4 17:39:02 2006 From: wk at gnupg.org (Werner Koch) Date: Mon Dec 4 17:42:58 2006 Subject: FreeBSD ports for libassuan 1.0.1 and gnupg 2.0.1 In-Reply-To: <456DD2D6.3000501@dougbarton.us> (Doug Barton's message of "Wed\, 29 Nov 2006 10\:35\:02 -0800") References: <456D5A54.5070900@dougbarton.us> <456D76B6.8010905@gmail.com> <87lklus4na.fsf@wheatstone.g10code.de> <456DD2D6.3000501@dougbarton.us> Message-ID: <87psaz7h09.fsf@wheatstone.g10code.de> On Wed, 29 Nov 2006 19:35, dougb@dougbarton.us said: > BTW, I'm still seeing the "Warning: using insecure memory!" error, in > spite of having the no-secmem-warning option in my gpg.conf. I'm still > willing to help debug that if Werner can give me some pointers. Just tested it on 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 GENERIC $ ulimit -l unlimited without problems. --no-secmem-warning works as expected. I am using a very decent libgcrypt snapshot: 1.2.4-svn1174. However, I can't remember that we recently changed anything. Did you tried gpg2 --no-secmem-warning to explode the chance that gpg read's another conf file. Salam-Shalom, Werner From marcus.brinkmann at ruhr-uni-bochum.de Mon Dec 4 17:57:45 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Dec 4 17:52:54 2006 Subject: GPGME 1.0.3 Build Problem In-Reply-To: <20061204184201.2936@henman-np.b-eng.it.to-be.co.jp> References: <20061130141425.2692@henman-np.b-eng.it.to-be.co.jp> <87wt5cx6t6.wl%marcus.brinkmann@ruhr-uni-bochum.de> <87slg0wb6v.wl%marcus.brinkmann@ruhr-uni-bochum.de> <456FACD3.7080700@users.sourceforge.net> <87lklrwwm7.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <87r6vfegza.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 04 Dec 2006 18:42:01 +0900, "djh" wrote: > > here are the results I get from using everthing in: > > * gpgme-1.0.3.tar.gz > > with the exceptipn of Makefile.am, which I used the new 1192 revision Makefile.am > which was mv'd to Makefile.am for the following: That can't work. Makefile.am is the basis for the generated files Makefile.in and Makefile, the latter of which is actually used. These files are only automatically generated when in maintainer mode. If you have the development tools installed, you can easily recreate these files by running ./autogen.sh in the toplevel directory. Otherwise, please let me know and I will send you a patch against 1.0.3 or a complete tar ball. Thanks, Marcus From henman at it.to-be.co.jp Tue Dec 5 02:09:16 2006 From: henman at it.to-be.co.jp (djh) Date: Tue Dec 5 02:07:19 2006 Subject: GPGME 1.0.3 Build Problem In-Reply-To: Your message of Mon, 04 Dec 2006 17:57:45 +0100 <87r6vfegza.wl%marcus.brinkmann@ruhr-uni-bochum.de> References: <20061130141425.2692@henman-np.b-eng.it.to-be.co.jp> <87wt5cx6t6.wl%marcus.brinkmann@ruhr-uni-bochum.de> <87slg0wb6v.wl%marcus.brinkmann@ruhr-uni-bochum.de> <456FACD3.7080700@users.sourceforge.net> <87lklrwwm7.wl%marcus.brinkmann@ruhr-uni-bochum.de> <87r6vfegza.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <20061205100916.3688@henman-np.b-eng.it.to-be.co.jp> Marcus, > That can't work. Makefile.am is the basis for the generated files > Makefile.in and Makefile, the latter of which is actually used. These > files are only automatically generated when in maintainer mode. Yes, your right. I just read about the GNU build system last night and realized that. Sorry about my ignorance of the gnu autotools workflow. I see where the distribution was not in an "autoconfiscated" state when I changed the .am file. > If you have the development tools installed, you can easily recreate > these files by running ./autogen.sh in the toplevel directory. > Otherwise, please let me know and I will send you a patch against > 1.0.3 or a complete tar ball. > > Thanks, > Marcus I could find no no ./autogen.sh in the toplevel directory. But, I did try the below: gpgme-1.0.3 $ aclocal # aclocal (GNU automake) 1.9.6 --- result: /usr/share/aclocal/libmcrypt.m4:17: warning: underquoted definition of AM_PATH_LIBMCRYPT run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal gpgme-1.0.3 $ automake # automake (GNU automake) 1.9.6 --- result Makefile.am:42: BUILD_W32_GLIB does not appear in AM_CONDITIONAL Makefile.am:106: BUILD_W32_GLIB does not appear in AM_CONDITIONAL Makefile.am:115: HAVE_W32_SYSTEM does not appear in AM_CONDITIONAL Makefile.am:172: BUILD_W32_GLIB does not appear in AM_CONDITIONAL Makefile.am:178: required file `./stpcpy.c' not found Makefile.am:178: required file `./vasprintf.c' not found Makefile.am:178: required file `./isascii.c' not found Makefile.am:178: required file `./funopen.c' not found Makefile.am:178: required file `./putc_unlocked.c' not found Makefile.am:178: required file `./memrchr.c' not found Makefile.am:178: required file `./ttyname_r.c' not found Fails with $? = 1 --- Consequently, a new Makefile.in does not get created. Thanks, Darel Henman From wk at g10code.com Wed Dec 6 16:55:52 2006 From: wk at g10code.com (Werner Koch) Date: Wed, 06 Dec 2006 16:55:52 +0100 Subject: [Announce] GnuPG: remotely controllable function pointer [CVE-2006-6235] Message-ID: <87psaxc92v.fsf@wheatstone.g10code.de> GnuPG: remotely controllable function pointer [CVE-2006-6235] =============================================================== 2006-12-04 Summary ======= Tavis Ormandy of the Gentoo security team identified a severe and exploitable bug in the processing of encrypted packets in GnuPG. [ Please do not send private mail in response to this message. The mailing list gnupg-devel is the best place to discuss this problem (please subscribe first so you don't need moderator approval [1]). ] Impact ====== Using malformed OpenPGP packets an attacker is able to modify and dereference a function pointer in GnuPG. This is a remotely exploitable bug and affects any use of GnuPG where an attacker can control the data processed by GnuPG. It is not necessary limited to encrypted data, also signed data may be affected. Affected versions: All versions of GnuPG < 1.4.6 All versions of GnuPG-2 < 2.0.2 All beta versions of GnuPG-2 (1.9.0 .. 1.9.95) Affected tools: gpg, gpgv, gpg2 and gpgv2. Affected platforms: All. gpg-agent, gpgsm as well as other tools are not affected. A workaround is not known. Solution ======== If you are using a vendor supplied version of GnuPG: * Wait for an update from your vendor. Vendors have been informed on Saturday December 2, less than a day after this bug has been reported. If you are using GnuPG 1.4: * Update as soon as possible to GnuPG 1.4.6. It has been uploaded to the usual location: ftp://ftp.gnupg.org/gcrypt/gnupg/. This version was due to be released anyway this week. See http://www.gnupg.org/download/ for details. * Or: As another and less intrusive option, apply the attached patch to GnuPG 1.4.5. This is the smallest possible fix. If you are using GnuPG 2.0: * Apply the attached patch against GnuPG 2.0.1. * Or: Stop using gpg2 and gpgv2, install GnuPG 1.4.6 and use gpg and gpgv instead. If you are using a binary Windows version of GnuPG: * A binary version of GnuPG 1.4.6 for Windows is available as usual. * Gpg4win 1.0.8, including GnuPG 1.4.6, is available. Please go to http://www.gpg4win.org . Background ========== GnuPG uses data structures called filters to process OpenPGP messages. These filters ware used in a similar way as a pipelines in the shell. For communication between these filters context structures are used. These are usually allocated on the stack and passed to the filter functions. At most places the OpenPGP data stream fed into these filters is closed before the context structure gets deallocated. While decrypting encrypted packets, this may not happen in all cases and the filter may use a void contest structure filled with garbage. An attacker may control this garbage. The filter context includes another context used by the low-level decryption to access the decryption algorithm. This is done using a function pointer. By carefully crafting an OpenPGP message, an attacker may control this function pointer and call an arbitrary function of the process. Obviously an exploit needs to prepared for a specific version, compiler, libc, etc to be successful - but it is definitely doable. Fixing this is obvious: We need to allocate the context on the heap and use a reference count to keep it valid as long as either the controlling code or the filter code needs it. We have checked all other usages of such a stack based filter contexts but fortunately found no other vulnerable places. This allows to release a relatively small patch. However, for reasons of code cleanness and easier audits we will soon start to change all these stack based filter contexts to heap based ones. Support ======= g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. As evident by the two vulnerabilities found within a week, a review of the entire code base should be undertaken as soon as possible. As maintainers we try to do our best and are working slowly through the code. The long standing plan is to scrutinize the 2.0 code base, write more test cases and to backport new fixes and cleanups to 1.4. However, as a small company our resources are limited and we need to prioritize other projects which get us actual revenues. Support contracts or other financial backing would greatly help us to improve the quality of GnuPG. Thanks ====== Tavis Ormandy found this vulnerability. [1] See http://lists.gnupg.org/mailman/listinfo/gnupg-devel . -- g10 Code GmbH http://g10code.com AmtsGer. Wuppertal HRB 14459 H?ttenstr. 61 Gesch?ftsf?hrung Werner Koch D-40699 Erkrath -=- The GnuPG Experts -=- USt-Id DE215605608 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: filter-context-14-small.diff Url: /pipermail/attachments/20061206/3de5c112/attachment-0002.diff -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: filter-context-20-small.diff Url: /pipermail/attachments/20061206/3de5c112/attachment-0003.diff -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20061206/3de5c112/attachment-0001.pgp -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From g.esp at free.fr Thu Dec 7 08:14:24 2006 From: g.esp at free.fr (Gilles Espinasse) Date: Thu, 7 Dec 2006 08:14:24 +0100 Subject: gnupg-1.4.6 --import error Message-ID: <12a201c719cf$53b7af20$f9b5a8c0@pii350> Just after gnupg compilation, on same makefile, we have gpg --import /usr/src/config/cfgroot/ipcop.gpg With gpg-1.4.5 gpg --import /usr/src/config/cfgroot/ipcop.gpg gpg: directory `/root/.gnupg' created gpg: new configuration file `/root/.gnupg/gpg.conf' created gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/root/.gnupg/secring.gpg' created gpg: keyring `/root/.gnupg/pubring.gpg' created gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key 4A3BFD9E: public key "IPCop Development Group (http://www.ipcop.org/) " imported gpg: Total number processed: 1 gpg: imported: 1 Install done; saving file list to /usr/src/log/gnupg-1.4.5 ... With gpg-1.4.6 gpg --import /usr/src/config/cfgroot/ipcop.gpg gpg: directory `/root/.gnupg' created gpg: can't open `/gnupg/options.skel': No such file or directory gpg: keyring `/root/.gnupg/secring.gpg' created gpg: keyring `/root/.gnupg/pubring.gpg' created gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key 4A3BFD9E: public key "IPCop Development Group (http://www.ipcop.org/) " imported gpg: Total number processed: 1 gpg: imported: 1 make: *** [/usr/src/log/gnupg-1.4.6] Error 2 touch /root/.gnupg/options.skel solve the failure I find no references of this file. What should be the content of options.skel? Gilles From wk at gnupg.org Thu Dec 7 11:38:31 2006 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Dec 2006 11:38:31 +0100 Subject: gnupg-1.4.6 --import error In-Reply-To: <12a201c719cf$53b7af20$f9b5a8c0@pii350> (Gilles Espinasse's message of "Thu\, 7 Dec 2006 08\:14\:24 +0100") References: <12a201c719cf$53b7af20$f9b5a8c0@pii350> Message-ID: <87zma0f0t4.fsf@wheatstone.g10code.de> On Thu, 7 Dec 2006 08:14, g.esp at free.fr said: > touch /root/.gnupg/options.skel solve the failure > I find no references of this file. > What should be the content of options.skel? It is a configuration file template. It should be copied from /usr/local/share/gnupg/options.skel to a newly created homedir. As it is just a convenience file tehre should be no error retun in case itis missing. I'll fix that. Salam-Shalom, Werner From jmoore3rd at bellsouth.net Thu Dec 7 14:47:20 2006 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Thu, 07 Dec 2006 08:47:20 -0500 Subject: Compiling svn4370 w/MSYS-MingW Message-ID: <45781B68.4020209@bellsouth.net> While Compiling svn4370 under MSYS/MingW I encounter the following Error: F:/msys/home/Compaq_Owner/4370/g10/import.c:252: undefined reference to `new_arm or_context' F:/msys/home/Compaq_Owner/4370/g10/import.c:254: undefined reference to `push_ar mor_filter' F:/msys/home/Compaq_Owner/4370/g10/import.c:255: undefined reference to `release _armor_context' keyserver.o: In function `keyserver_work': F:/msys/home/Compaq_Owner/4370/g10/keyserver.c:1197: undefined reference to `new _armor_context' F:/msys/home/Compaq_Owner/4370/g10/keyserver.c:1206: undefined reference to `pus h_armor_filter' F:/msys/home/Compaq_Owner/4370/g10/keyserver.c:1207: undefined reference to `rel ease_armor_context' make[1]: *** [gpg.exe] Error 1 make[1]: Leaving directory `/home/Compaq_Owner/4370/g10' make: *** [check-recursive] Error 1 Can anyone offer a suggestion? TIA JOHN :-\ Timestamp: Thursday 07 Dec 2006, 08:47 --500 (Eastern Standard Time) From dshaw at jabberwocky.com Thu Dec 7 15:22:52 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 7 Dec 2006 09:22:52 -0500 Subject: Compiling svn4370 w/MSYS-MingW In-Reply-To: <45781B68.4020209@bellsouth.net> References: <45781B68.4020209@bellsouth.net> Message-ID: <20061207142252.GA4004@jabberwocky.com> On Thu, Dec 07, 2006 at 08:47:20AM -0500, John W. Moore III wrote: > While Compiling svn4370 under MSYS/MingW I encounter the following Error: > > F:/msys/home/Compaq_Owner/4370/g10/import.c:252: undefined reference to > `new_arm or_context' > F:/msys/home/Compaq_Owner/4370/g10/import.c:254: undefined reference to > `push_ar mor_filter' > F:/msys/home/Compaq_Owner/4370/g10/import.c:255: undefined reference to > `release _armor_context' > keyserver.o: In function `keyserver_work': > F:/msys/home/Compaq_Owner/4370/g10/keyserver.c:1197: undefined reference > to `new _armor_context' > F:/msys/home/Compaq_Owner/4370/g10/keyserver.c:1206: undefined reference > to `pus h_armor_filter' > F:/msys/home/Compaq_Owner/4370/g10/keyserver.c:1207: undefined reference > to `rel ease_armor_context' > make[1]: *** [gpg.exe] Error 1 > make[1]: Leaving directory `/home/Compaq_Owner/4370/g10' > make: *** [check-recursive] Error 1 Are you sure you actually have all the files from svn? Try deleting your armor.c and do another svn update. David From jmoore3rd at bellsouth.net Thu Dec 7 17:29:38 2006 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Thu, 07 Dec 2006 11:29:38 -0500 Subject: svn4370 under MSYS/MingW (again) Message-ID: <45784172.4000006@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 With the correct \g10\armor.c I find MSYS now bails out at: rm -rf $backupdir; exit $rc makeinfo: unrecognized option `--css-include=./texi.css' Try `makeinfo --help' for more information. Input file options: --commands-in-node-names allow @ commands in node names. -D VAR define the variable VAR, as with @set. -I DIR append DIR to the @include search path. -P DIR prepend DIR to the @include search path. -U VAR undefine the variable VAR, as with @clear. Conditional processing in input: --ifhtml process @ifhtml and @html even if not generating HTML. --ifinfo process @ifinfo even if not generating Info. --ifplaintext process @ifplaintext even if not generating plain text. --iftex process @iftex and @tex; implies --no-split. --ifxml process @ifxml and @xml. --no-ifhtml do not process @ifhtml and @html text. --no-ifinfo do not process @ifinfo text. --no-ifplaintext do not process @ifplaintext text. --no-iftex do not process @iftex and @tex text. --no-ifxml do not process @ifxml and @xml text. The defaults for the @if... conditionals depend on the output format: if generating HTML, --ifhtml is on and the others are off; if generating Info, --ifinfo is on and the others are off; if generating plain text, --ifplaintext is on and the others are off; Examples: makeinfo foo.texi write Info to foo's @setfilename makeinfo --html foo.texi write HTML to @setfilename makeinfo --xml foo.texi write Texinfo XML to @setfilename makeinfo --docbook foo.texi write DocBook XML to @setfilename makeinfo --no-headers foo.texi write plain text to standard output makeinfo --html --no-headers foo.texi write html without node lines, menus makeinfo --number-sections foo.texi write Info with numbered sections makeinfo --no-split foo.texi write one Info file however big Email bug reports to bug-texinfo at gnu.org, general questions and discussion to help-texinfo at gnu.org. Texinfo home page: http://www.gnu.org/software/texinfo/ make[2]: *** [gnupg1.info] Error 1 make[2]: Leaving directory `/home/Compaq_Owner/4370/doc' make[1]: *** [check] Error 2 make[1]: Leaving directory `/home/Compaq_Owner/4370/doc' make: *** [check-recursive] Error 1 I am now Open for more suggestions! JOHN :-\ Timestamp: Thursday 07 Dec 2006, 11:29 --500 (Eastern Standard Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: My Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJFeEFwAAoJEBCGy9eAtCsPx6QH/2yG4yu3sxNKX4CkFbXs8hC9 4X8ZUtnEmFl6AKhJSng5B8nhd0bmGWpm2qOEKExOwxS0tHCorhdyq6vEkCMJ0rrV Cbz6LUDYyRrhEzTVn49oBDJLCdk5ltFYu/4OS1+Ww+NBXVm9DC2e+9wp+4K9NipG 4gMMN9AKEQamvC4tC7S/AXceuINijmZqH94O9zY/fDHEIwtK2yesPB9N53cfhF2d LGhh3Pp3XoFb7mdR128YTFo4ECJJGK+V2BO5h+iJETBjnbdqZmepUhzhq0E6QWI0 mMI7HjKu4DmNwK0c6Rh87yH2U0qyvX/z1t09TcEw1UNCKLxu7FTLnDk7E5hV7vc= =PnA9 -----END PGP SIGNATURE----- From wk at gnupg.org Thu Dec 7 17:07:12 2006 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Dec 2006 17:07:12 +0100 Subject: [Announce] Maintenance release for GnuPG 1.2.x Message-ID: <87psavbsgf.fsf@wheatstone.g10code.de> Hello, I am pleased to announce a security update to the 1.2 series of GnuPG: Version 1.2.8. The 1.2.x series has reached end of life status about 2 years ago. However, I make an update available for the sake of those who can't migrate to 1.4. There is no guarantee that all problems are solved in 1.2 - it is in general better to migrate to the activly maintained 1.4 series. You will find that version as well as corresponding signatures at the usual place (ftp://ftp.gnupg.org/gcrypt/gnupg/). Noteworthy changes in version 1.2.8 (2006-12-07) ------------------------------------------------ Backported security fixes. Note, that the 1.2.x series has reached end of life status. You should migrate to 1.4.x. * Fixed a serious and exploitable bug in processing encrypted packages. [CVE-2006-6235]. * Fixed a buffer overflow in gpg. [bug#728, CVE-2006-6169] * User IDs are now capped at 2048 bytes. This avoids a memory allocation attack [CVE-2006-3082]. * Added countermeasures against the Mister/Zuccherato CFB attack . Happy Hacking, Werner -- Werner Koch The GnuPG Experts http://g10code.com Join the Fellowship and protect your Freedom! http://www.fsfe.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : /pipermail/attachments/20061207/2e2372f7/attachment.pgp -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dshaw at jabberwocky.com Thu Dec 7 17:57:43 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 7 Dec 2006 11:57:43 -0500 Subject: svn4370 under MSYS/MingW (again) In-Reply-To: <45784172.4000006@bellsouth.net> References: <45784172.4000006@bellsouth.net> Message-ID: <20061207165743.GA11411@jabberwocky.com> On Thu, Dec 07, 2006 at 11:29:38AM -0500, John W. Moore III wrote: > With the correct \g10\armor.c I find MSYS now bails out at: > > rm -rf $backupdir; exit $rc > makeinfo: unrecognized option `--css-include=./texi.css' > Try `makeinfo --help' for more information. You probably need to have an updated version of makeinfo. What version of makeinfo are you using? (makeinfo --version). David From JPClizbe at tx.rr.com Thu Dec 7 23:13:37 2006 From: JPClizbe at tx.rr.com (John Clizbe) Date: Thu, 07 Dec 2006 16:13:37 -0600 Subject: svn4370 under MSYS/MingW (again) In-Reply-To: <20061207165743.GA11411@jabberwocky.com> References: <45784172.4000006@bellsouth.net> <20061207165743.GA11411@jabberwocky.com> Message-ID: <45789211.3060401@tx.rr.com> David Shaw wrote: > On Thu, Dec 07, 2006 at 11:29:38AM -0500, John W. Moore III wrote: >> With the correct \g10\armor.c I find MSYS now bails out at: >> >> rm -rf $backupdir; exit $rc >> makeinfo: unrecognized option `--css-include=./texi.css' >> Try `makeinfo --help' for more information. > > You probably need to have an updated version of makeinfo. What > version of makeinfo are you using? (makeinfo --version). MSys* makeinfo (texinfo) is 4.3. Cygwin texinfo is 4.8.3 and appears to work fine John, You may want to try texinfo from the GnuWin32 project at SourceForge. It's version 4.8. Unzip the bin and dep package to /mingw. http://sourceforge.net/projects/gnuwin32. [*] A major update to MSys is in the works, but it'll take some time. -- 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/20061207/110b49ce/attachment-0001.pgp From rjh at sixdemonbag.org Fri Dec 8 23:28:18 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 08 Dec 2006 16:28:18 -0600 Subject: Libgpg-error 1.5 build failure (Mactel OS X 10.4.8) Message-ID: <4579E702.4090908@sixdemonbag.org> Libgpg-error 1.5 is bombing out on a MacBook Pro running OS X 10.4.8. It appears to be the result of a faulty awk script. Both the OS-supplied awk and GNU awk (provided by Fink) give the same results. A bug has been filed about this. This email is just a heads-up for people who are not closely watching the bug system. From jmoore3rd at bellsouth.net Fri Dec 8 21:39:20 2006 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Fri, 08 Dec 2006 15:39:20 -0500 Subject: svn4375 under MSYS/MinGW32 Message-ID: <4579CD78.2030204@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Well, I've switched to makeinfo v 4.8, updated/graded the binutls & runtime; but still 'crap out' with the error: gnupg1.texi:4: @include `version.texi': No such file or directory. gnupg1.texi:46: warning: undefined flag: VERSION. gnupg1.texi:46: warning: undefined flag: UPDATED. gnupg1.texi:103: warning: undefined flag: VERSION. gnupg1.texi:103: warning: undefined flag: UPDATED. makeinfo: Removing output file `gnupg1.info' due to errors; use --force to prese rve. I'm using MSYS v. 1.0.0.11 and am giving serious consideration to re-installing it again. Any more Suggestions will be most Welcome. JOHN :-\ Timestamp: Friday 08 Dec 2006, 15:38 --500 (Eastern Standard Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: My Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJFec1zAAoJEBCGy9eAtCsPaw0H/2wlvi5pxGFlsSR643NRr1uE KIaPLolv1dVcxJ+/rT7Yb9FmP/2Mkom/tGm2dhSlQbp+kFBQCpY56Mmqk7RZY6oI pPWGJAbHn41AbyIqRc4mxUr6f0Pv85Uxgs5rZqrkhetRgPS7LYtMw1pjSZyQh3JR GQtyq+RC/WIE76WtYjDqMwdCvXIwj7Z6c1Ac3di2i4k36r4J5UcwbzKSoWMsG/n1 sHyhXeiBfx+GpWwWYufS5N64Ka1NuVVr3/EbQfTn3SccKtwOWOMv8O375TkJGXaI hnlJeXztPy/mUnY+Aq4gjVQZ2J5ENYE3M1tEVdY32LmqD/TLDuF28z7GcLmodkQ= =JuJ7 -----END PGP SIGNATURE----- From g.esp at free.fr Sat Dec 9 08:58:28 2006 From: g.esp at free.fr (Gilles Espinasse) Date: Sat, 9 Dec 2006 08:58:28 +0100 Subject: gnupg-1.4.6 --import error References: <12a201c719cf$53b7af20$f9b5a8c0@pii350> <87zma0f0t4.fsf@wheatstone.g10code.de> Message-ID: <138301c71b67$d013f9e0$f9b5a8c0@pii350> ----- Original Message ----- From: "Werner Koch" To: "Gilles Espinasse" Cc: Sent: Thursday, December 07, 2006 11:38 AM Subject: Re: gnupg-1.4.6 --import error > On Thu, 7 Dec 2006 08:14, g.esp at free.fr said: > > > touch /root/.gnupg/options.skel solve the failure > > I find no references of this file. > > What should be the content of options.skel? > > It is a configuration file template. It should be copied from > /usr/local/share/gnupg/options.skel to a newly created homedir. > > As it is just a convenience file tehre should be no error retun in > case itis missing. I'll fix that. > > I have extracted the changes in g10 configure.ac, openfile.c, Makefile.am from svn and tested. The error is gone. But the behavior is different from 1.4.5. gnupg.conf was directly copied during --import and options.skel content is not copied. Is not this warning misleading? gpg: can't open `/gnupg/options.skel': No such file or directory You would think that you need to create a `/gnupg/options.skel' file. strace show that options.skel is not an name that gpg is looking at. access("/root/.gnupg/gpg.conf-1.4.6", R_OK) = -1 ENOENT (No such file or directory) access("/root/.gnupg/gpg.conf-1.4", R_OK) = -1 ENOENT (No such file or directory) access("/root/.gnupg/gpg.conf-1", R_OK) = -1 ENOENT (No such file or directory) access("/root/.gnupg/gpg.conf", R_OK) = -1 ENOENT (No such file or directory) stat64("/root/.gnupg", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 stat64("/root", {st_mode=S_IFDIR|0750, st_size=4096, ...}) = 0 getuid32() = 0 open("/root/.gnupg/options", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) options.skel as previous gpg.conf state that # These first three lines are not copied to the gpg.conf file in # the users home directory. I can't say it's totally false as there is no more a copy of the default configuration. Gilles From wk at gnupg.org Sat Dec 9 17:04:45 2006 From: wk at gnupg.org (Werner Koch) Date: Sat, 09 Dec 2006 17:04:45 +0100 Subject: gnupg-1.4.6 --import error In-Reply-To: <138301c71b67$d013f9e0$f9b5a8c0@pii350> (Gilles Espinasse's message of "Sat\, 9 Dec 2006 08\:58\:28 +0100") References: <12a201c719cf$53b7af20$f9b5a8c0@pii350> <87zma0f0t4.fsf@wheatstone.g10code.de> <138301c71b67$d013f9e0$f9b5a8c0@pii350> Message-ID: <874ps52gyq.fsf@wheatstone.g10code.de> On Sat, 9 Dec 2006 08:58, g.esp at free.fr said: > Is not this warning misleading? > gpg: can't open `/gnupg/options.skel': No such file or directory > You would think that you need to create a `/gnupg/options.skel' file. There is a glitch in the build system. I have fixed it in the SVN. Salam-Shalom, Werner From eric at debian.org Sun Dec 10 02:55:40 2006 From: eric at debian.org (Eric Dorland) Date: Sat, 09 Dec 2006 20:55:40 -0500 Subject: Why Is libassuan still a static lib? Message-ID: <457B691C.4010507@debian.org> Hello, I was curious why libassuan is still distributed as only a static lib? I can understand that while gnupg 2 was being developed this would have made more sense, because things were still in flux, but I would imagine that now the API has stabilized. There is at least one other program using libassuan (OpenSC) and from a distribution PoV, it would be much better to have this as a shared lib (easier security updates, less memory consumption). From eric at debian.org Sun Dec 10 01:46:25 2006 From: eric at debian.org (Eric Dorland) Date: Sat, 09 Dec 2006 19:46:25 -0500 Subject: Why Is libassuan still a static lib? Message-ID: <457B58E1.2000104@debian.org> Hello, I was curious why libassuan is still distributed as only a static lib? I can understand that while gnupg 2 was being developed this would have made more sense, because things were still in flux, but I would imagine that now the API has stabilized. There is at least one other program using libassuan (OpenSC) and from a distribution PoV, it would be much better to have this as a shared lib (easier security updates, less memory consumption). From wk at gnupg.org Mon Dec 11 10:13:59 2006 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Dec 2006 10:13:59 +0100 Subject: Why Is libassuan still a static lib? In-Reply-To: <457B691C.4010507@debian.org> (Eric Dorland's message of "Sat\, 09 Dec 2006 20\:55\:40 -0500") References: <457B691C.4010507@debian.org> Message-ID: <87mz5uztew.fsf@wheatstone.g10code.de> On Sun, 10 Dec 2006 02:55, eric at debian.org said: > I was curious why libassuan is still distributed as only a static lib? I Because we are not yet sure about the API. As soon as we are sure of it we will create a shared library. As a mainatiner you should be glad that we don't need to break the ABI too often. FWIW, GPGME and Pinentry both come with stipped down and source copied versions for libassuan. Shalom-Salam, Werner From Joerg.Honegger at hp.com Mon Dec 11 13:39:45 2006 From: Joerg.Honegger at hp.com (Honegger, Joerg) Date: Mon, 11 Dec 2006 13:39:45 +0100 Subject: GnuPG 1.4.6: configure with default options generates incorrect define statements in g10defs.h Message-ID: <34BC148854A945478F102E09A1272C1C03939A50@BSWEXC01.emea.cpqcorp.net> Dear all I installed GnuPG 1.4.6 on some HP Tru64 UNIX Version 5.1B-3 systems running configure without any options. This results in an g10defs.h file with 2 incorrect define statements for UNIX systems: #define G10_LOCALEDIR "/locale" #define GNUPG_LIBDIR "/usr/local/lib/gnupg" #define GNUPG_DATADIR "/gnupg" The above definitions for G10_LOCALEDIR and GNUPG_DATADIR are incorrect. A workaround is to specify the configure option --datadir=/usr/local/share even if this is the default. Kind regards J?rg Honegger Systems Engineer Hewlett-Packard (Schweiz) GmbH ?berlandstrasse 1 CH-8600 D?bendorf Office: +41 58 444 7399 Mobile: +41 79 616 4554 Fax: +41 58 444 7750 E-Mail: mailto:joerg.honegger at hp.com Internet: http://www.hp.com/ch -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4810 bytes Desc: not available Url : /pipermail/attachments/20061211/3c546996/attachment.bin From rjh at sixdemonbag.org Mon Dec 11 17:19:59 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 11 Dec 2006 10:19:59 -0600 Subject: Possible license violation Message-ID: <457D852F.6080508@sixdemonbag.org> http://portableapps.com/apps/internet/thunderbird_portable PortableApps is distributing a GnuPG-enabled version of Thunderbird as a package along with Thunderbird. I do not see an offer for source code on that page. Perhaps a politely-worded email from a GnuPG developer might be in order. From jmoore3rd at bellsouth.net Mon Dec 11 22:56:50 2006 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Mon, 11 Dec 2006 16:56:50 -0500 Subject: svn4377 under MinGW/MSYS Message-ID: <457DD422.5070105@bellsouth.net> After running ./autogen.sh I am confronted with a stoppage ending with the Error: config.status: error: cannot find input file: Makefile.in Has anyone else experienced this? JOHN :-\ Timestamp: Monday 11 Dec 2006, 16:56 --500 (Eastern Standard Time) From unknown_kev_cat at hotmail.com Tue Dec 12 01:12:44 2006 From: unknown_kev_cat at hotmail.com (Joe Smith) Date: Mon, 11 Dec 2006 19:12:44 -0500 Subject: Possible license violation References: <457D852F.6080508@sixdemonbag.org> Message-ID: "Robert J. Hansen" wrote in message news:457D852F.6080508 at sixdemonbag.org... > http://portableapps.com/apps/internet/thunderbird_portable > > PortableApps is distributing a GnuPG-enabled version of Thunderbird as a > package along with Thunderbird. I do not see an offer for source code > on that page. Perhaps a politely-worded email from a GnuPG developer > might be in order. They do distribute source code, they just don't have a link to it on that page. Click the sourceforge icon, then click the download tab, and you will see the source listed. Theya re offering both from the same loaction (The sourceforge download network) so they are complying with the GPL. I agree that a link on the page you linked to would be nice. From eric at debian.org Tue Dec 12 04:52:27 2006 From: eric at debian.org (Eric Dorland) Date: Mon, 11 Dec 2006 22:52:27 -0500 Subject: Why Is libassuan still a static lib? In-Reply-To: <87mz5uztew.fsf@wheatstone.g10code.de> References: <457B691C.4010507@debian.org> <87mz5uztew.fsf@wheatstone.g10code.de> Message-ID: <457E277B.50204@debian.org> Werner Koch wrote: > On Sun, 10 Dec 2006 02:55, eric at debian.org said: > >> I was curious why libassuan is still distributed as only a static lib? I > > Because we are not yet sure about the API. As soon as we are sure of > it we will create a shared library. As a mainatiner you should be > glad that we don't need to break the ABI too often. I sort of thought going 1.0 meant you had the API under control. > FWIW, GPGME and Pinentry both come with stipped down and source copied > versions for libassuan. Ugh, really? Will they be receptive to fixing that? From rjh at sixdemonbag.org Tue Dec 12 05:42:03 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 11 Dec 2006 22:42:03 -0600 Subject: Possible license violation In-Reply-To: References: <457D852F.6080508@sixdemonbag.org> Message-ID: <457E331B.30406@sixdemonbag.org> Joe Smith wrote: > Theya re offering both from the same loaction (The sourceforge download > network) so they are complying with the GPL. I'm not certain this argument holds water. Let's say they had a publicly accessible link to sf.net, but one which had no links going to it, so it was impossible to navigate to; the only way to get the source would be to have prior knowledge of this secret link. Would that be considered GPL-compliant? To my understanding, the GPL requires that you inform people source is available. I do not see any such notice on the PortableApps site. In the grand scheme of things this is a very minor violation, of course. But still, it's the principle of the thing. From henman at it.to-be.co.jp Tue Dec 12 06:41:03 2006 From: henman at it.to-be.co.jp (djh) Date: Tue, 12 Dec 2006 14:41:03 +0900 Subject: GPGME Message-ID: <20061212144103.3760@henman-np.b-eng.it.to-be.co.jp> I have been looking at configure.ac for the GPGME package, trying to find out what to do to enable it to build easily on cygwin systems. Not being an expert with GNU build tools I can only ask what I hope are good questions. configure.ac has no references to cygwin in it, but it does in line #128 or so have *-mingw32*) in a case statement. Shouldn't there also be a *-*-cygwin*) Though cygwin does not use dos-ish pathnames, shouldn't it have the follwing setting?? have_w32_system=yes I don't know if this is used for creating dlls or not? or if GPG_DEFAULT='/usr/local/bin/gpg.exe' would be needed or if the below is relevant or not. # XXX Assuan is not supported in this configuration. #GPGSM_DEFAULT='c:\\gnupg\\gpgsm.exe' #component_system='COM+' Please take a look at configure.ac and add a case for *-*-cygwin* and set the appropriate flags to enable w32 dll libraries for gpgme to be built. Regards, Darel Henman From henman at it.to-be.co.jp Tue Dec 12 08:09:34 2006 From: henman at it.to-be.co.jp (djh) Date: Tue, 12 Dec 2006 16:09:34 +0900 Subject: gpgme Message-ID: <20061212160934.1532@henman-np.b-eng.it.to-be.co.jp> After fiddling with configure.ac and providing a LDFLAGS=... I have been able to build gpgme up to the following error. I did a "find grep ... " for the undefined reference to "_assuan_set_assuan_err_source", but it only appears in the version.c source file as a reference. --- ../libtool --tag=CC --mode=link gcc -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -no-undefined -o libgpgme.la -rpath /usr/local/lib -version-info 17:1:6 conversion.lo get-env.lo data.l o data-fd.lo data-stream.lo data-mem.lo data-user.lo data-compat.lo signers.lo sig-notation.lo wait.lo wait-global.lo wait-private.lo wait-user.lo op-support.lo encrypt.lo encrypt-sign.lo decrypt.lo decrypt-verify.lo verify.lo sign.lo passphrase.lo progr ess.lo key.lo keylist.lo trust-item.lo trustlist.lo import.lo export.lo genkey.lo delete.lo edit.lo engine.lo rungpg.lo posix-util.lo posix-sema.lo posix-io.lo debug.lo gpgme.lo version.lo error.lo ath.lo memrchr.lo stpcpy.lo -lgpg-error /usr/src/gpgme/gpgme-1.1.3-cvs1196/gpgme/version.c:53: undefined reference to `_assuan_set_assuan_err_source' --- What am I missing? Thanks, Darel Henman From wk at gnupg.org Tue Dec 12 08:27:03 2006 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Dec 2006 08:27:03 +0100 Subject: Why Is libassuan still a static lib? In-Reply-To: <457E277B.50204@debian.org> (Eric Dorland's message of "Mon\, 11 Dec 2006 22\:52\:27 -0500") References: <457B691C.4010507@debian.org> <87mz5uztew.fsf@wheatstone.g10code.de> <457E277B.50204@debian.org> Message-ID: <87k60x8th4.fsf@wheatstone.g10code.de> On Tue, 12 Dec 2006 04:52, eric at debian.org said: > I sort of thought going 1.0 meant you had the API under control. I believe that this is the case. Others might only start looking at it because it is 1.0 now. As soon as GPGME fully supports descriptor passing we will come up with a shared lib. >> FWIW, GPGME and Pinentry both come with stipped down and source copied >> versions for libassuan. > > Ugh, really? Will they be receptive to fixing that? No. It does not make much sense. Both use only the client part and tehre is no point in adding all the support for servers. If is not much code anyway. Salam-Shalom, Werner From wk at gnupg.org Tue Dec 12 08:32:57 2006 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Dec 2006 08:32:57 +0100 Subject: GPGME In-Reply-To: <20061212144103.3760@henman-np.b-eng.it.to-be.co.jp> (henman@it.to-be.co.jp's message of "Tue\, 12 Dec 2006 14\:41\:03 +0900") References: <20061212144103.3760@henman-np.b-eng.it.to-be.co.jp> Message-ID: <87fybl8t7a.fsf@wheatstone.g10code.de> On Tue, 12 Dec 2006 06:41, henman at it.to-be.co.jp said: > Though cygwin does not use dos-ish pathnames, shouldn't it have the follwing setting?? > > have_w32_system=yes Definitely not. Cygwin is a Unix emulation and as such it is very different from the W32 API. > I don't know if this is used for creating dlls or not? It is used for all kind of stuff. It is actually an alias for _WIN32, a name some folks don't like to use in connection with Free Software ;-) > Please take a look at configure.ac and add a case for *-*-cygwin* and > set the appropriate flags to enable w32 dll libraries for gpgme to be built. If it does not work like a basic Unix system, something would wrong with Cygwin. Note, that you need to use aCygwin build of gpg.exe wiith a Cygwin build pf gpgme - you can't mix them. Shalom-Salam, Werner From wk at gnupg.org Tue Dec 12 12:05:41 2006 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Dec 2006 12:05:41 +0100 Subject: GnuPG 1.4.6: configure with default options generates incorrect define statements in g10defs.h In-Reply-To: <34BC148854A945478F102E09A1272C1C03939A50@BSWEXC01.emea.cpqcorp.net> (Joerg Honegger's message of "Mon\, 11 Dec 2006 13\:39\:45 +0100") References: <34BC148854A945478F102E09A1272C1C03939A50@BSWEXC01.emea.cpqcorp.net> Message-ID: <87fybl74sa.fsf@wheatstone.g10code.de> On Mon, 11 Dec 2006 13:39, Joerg.Honegger at hp.com said: > The above definitions for G10_LOCALEDIR and GNUPG_DATADIR are incorrect. A > workaround is to specify the configure option --datadir=/usr/local/share > even if this is the default. Yes, I realized this problem also. The use of g10defs.h is a hack required back in the early days of autoconf. I have now changed the build system to work without this file. Salam-Shalom, Werner From alphasigmax at gmail.com Tue Dec 12 16:15:05 2006 From: alphasigmax at gmail.com (Alphax) Date: Wed, 13 Dec 2006 01:45:05 +1030 Subject: Proxy problems Message-ID: <457EC779.2070000@gmail.com> I've now upgraded to the official build of 1.4.6 and still can't get GPG to talk to my proxy; I've confirmed that it's using Basic authentication: > $ telnet 8080 > Trying ... > Connected to . > Escape character is '^]'. > GET http://www.gnupg.org HTTP/1.1 > > HTTP/1.0 407 Proxy Authentication Required > Server: squid/2.5.STABLE12 > Mime-Version: 1.0 > Date: > Content-Type: text/html > Content-Length: 1345 > Expires: > X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0 > Proxy-Authenticate: Basic realm="" > X-Cache: MISS from > X-Cache-Lookup: NONE from > Proxy-Connection: close but trying --keyserver-options http-proxy="http://user:pass@:8080" doesn't work; all I get is > gpgkeys: HTTP search error 7: couldn't connect: eof Does anyone know how to fix this? -- 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: 542 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20061213/fe368618/attachment.pgp From dshaw at jabberwocky.com Tue Dec 12 16:24:00 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 12 Dec 2006 10:24:00 -0500 Subject: Proxy problems In-Reply-To: <457EC779.2070000@gmail.com> References: <457EC779.2070000@gmail.com> Message-ID: <20061212152400.GA6347@jabberwocky.com> On Wed, Dec 13, 2006 at 01:45:05AM +1030, Alphax wrote: > I've now upgraded to the official build of 1.4.6 and still can't get GPG > to talk to my proxy; I've confirmed that it's using Basic authentication: > > > $ telnet 8080 > > Trying ... > > Connected to . > > Escape character is '^]'. > > GET http://www.gnupg.org HTTP/1.1 > > > > HTTP/1.0 407 Proxy Authentication Required > > Server: squid/2.5.STABLE12 > > Mime-Version: 1.0 > > Date: > > Content-Type: text/html > > Content-Length: 1345 > > Expires: > > X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0 > > Proxy-Authenticate: Basic realm="" > > X-Cache: MISS from > > X-Cache-Lookup: NONE from > > Proxy-Connection: close > > but trying --keyserver-options > http-proxy="http://user:pass@:8080" doesn't work; all I get is > > > gpgkeys: HTTP search error 7: couldn't connect: eof > > Does anyone know how to fix this? Need some more information. Are you using curl or the internal HTTP support? I'm guessing internal, but I want to be sure. Also, can you post the output when you set "--keyserver-options debug" and do your search again? David From unknown_kev_cat at hotmail.com Tue Dec 12 16:46:40 2006 From: unknown_kev_cat at hotmail.com (Joe Smith) Date: Tue, 12 Dec 2006 10:46:40 -0500 Subject: Possible license violation References: <457D852F.6080508@sixdemonbag.org> <457E331B.30406@sixdemonbag.org> Message-ID: "Robert J. Hansen" wrote in message news:457E331B.30406 at sixdemonbag.org... > Joe Smith wrote: >> Theya re offering both from the same loaction (The sourceforge download >> network) so they are complying with the GPL. > > I'm not certain this argument holds water. Let's say they had a > publicly accessible link to sf.net, but one which had no links going to > it, so it was impossible to navigate to; the only way to get the source > would be to have prior knowledge of this secret link. Would that be > considered GPL-compliant? > > To my understanding, the GPL requires that you inform people source is > available. I do not see any such notice on the PortableApps site. > > In the grand scheme of things this is a very minor violation, of course. > But still, it's the principle of the thing. I know. On the other hand, it is common for sites to not link to source code on every page they link to the binary. That does not seem unreasonable in some cases. Like if they have a page on the sites that links to the sources of all packages requiring distribution of source code that can be found on their site. Is it a problem if that source link listing page is not linked to directly from ppage offering the download link, but is linked to on for example, the front page of the site, whcih in turn is linked to by the page with the binary download link? That seems reasonable enough to me. In this case, it is important to note that PortableApps are distributing the files from the same location, and that they do have link to a page on which there is a link to a page that includes download links to all the relevent source pakages. That is very similar to the hypothetical case listed above, except that the instead of a link to the page containing source links being on the site's main page, it on on the sourceforge Project page. Also not that the sourceforge project page links back to the portable app site as the project's web page. Also notice that while the thunderbird source is mentioned on the PortableApps page, it is not linked to on that page. Clearly they feel that users who are interested in the source code will generally know to check the sourceforge page for it. From rjh at sixdemonbag.org Wed Dec 13 00:17:11 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 12 Dec 2006 17:17:11 -0600 Subject: [Fwd: GnuPG source link on Thunderbird Portable page] Message-ID: <457F3877.8070502@sixdemonbag.org> John Haller has remedied the problem with there being no link to source code for GnuPG on PortableApps.com. It's nice to see that people can be polite and reasonable about things. Thanks a lot, John, for fixing it, as minor as it was. :) -------- Original Message -------- Subject: GnuPG source link on Thunderbird Portable page Date: Tue, 12 Dec 2006 11:36:09 -0500 From: John T. Haller To: rjh at spamblock.com Howdy Robert, Via a Technorati search, I stumbled across your thread regarding a link to GPG source from my Thunderbird Portable page here: http://www.gossamer-threads.com/lists/gnupg/devel/39108 I had actually assumed people would snag it from SourceForge since anyway interested in the source would know that the files were all SourceForge-hosted from the link to the Thunderbird Portable SourceForge project in that same Download Details section of the page. I can see that there may be a few people that may not realize that, though, so I've updated the page to specifically link to the source for Thunderbird, GPG and Enigmail. I'd post a reply to the thread, but it seems to be a mailing list only. Please feel free to let the other GPG folks know that the page has been updated. Kind Regards, John From jmoore3rd at bellsouth.net Wed Dec 13 05:29:50 2006 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Tue, 12 Dec 2006 23:29:50 -0500 Subject: 2 'Overlooked' Found Message-ID: <457F81BE.2010404@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 It is only because My good friend Shane Coughlan swears that Werner has a sense of humor that I bring this up in this forum. While attempting to de-bug My Build problem I discovered what I think are 2 errors in g10. \g10\gpgv.c (line 53): //#include "g10defs.h" // above line should not be there :-> \g10\gpg.c (line 68): //#include "g10defs.h" // above line should not be there :-> Once these 2 lines were 'Commented Out' My Build went smoothly. Thanks to everyone who kindly assisted in My education on the reason for eliminating the g10defs.h -- while I'm certainly *not* in Werner's or David's league; I am becoming increasingly familiar with the GnuPG Code. JOHN ;) Timestamp: Tuesday 12 Dec 2006, 23:29 --500 (Eastern Standard Time) - -- Programming is like sex: if you make a mistake, you have to support it for the rest of your life. --(unknown) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7-svn4377: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: My Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJFf4G5AAoJEBCGy9eAtCsPcA8H/1YjnrYxTY44ttq+1WOHRS+n akpfqZYU1jzIX3IdEB+FCLSv42l4JzfKzDOLAKxJT0uOYM8z/ouw9WQ2ygzh3Vbx QjnqAfXzF1ltPN/RvQpoql7ABHYIG3DB+W3zlrgUpbIJ7v0R1L43G12mo+kRMUSa 0knq4zOmqMjF2gPO7v3TRlq4gPrHrJ/08YL1Z+z6h64RNJXJ+XVoH9U0SaKt8XlB Y+iYfeZeyVdm+NB1O1BQOGTueE4tFGVeXhA6BhzEn2t2Q8nwuXb7N73lw8hoxQ+X k5IrKKulmp+keglNcBBz6oKQXAXZoXPrHLDYwr7YYf3Yz6mjmdMb5giDk3hCPBw= =qBme -----END PGP SIGNATURE----- From alphasigmax at gmail.com Wed Dec 13 08:49:27 2006 From: alphasigmax at gmail.com (Alphax) Date: Wed, 13 Dec 2006 18:19:27 +1030 Subject: Proxy problems In-Reply-To: <20061212152400.GA6347@jabberwocky.com> References: <457EC779.2070000@gmail.com> <20061212152400.GA6347@jabberwocky.com> Message-ID: <457FB087.7070100@gmail.com> David Shaw wrote: > On Wed, Dec 13, 2006 at 01:45:05AM +1030, Alphax wrote: >> I've now upgraded to the official build of 1.4.6 and still can't get GPG >> to talk to my proxy; I've confirmed that it's using Basic authentication: >> >> Does anyone know how to fix this? > > Need some more information. Are you using curl or the internal HTTP > support? I'm guessing internal, but I want to be sure. Also, can you > post the output when you set "--keyserver-options debug" and do your > search again? > gpg --no-options --keyserver hkp://keyserver.noreply.org:80 --keyserver-options debug --keyserver-options http-proxy="http://:@:8080" --keyserver-options verbose --keyserver-options verbose --search 0xDEADBEEF gpg: searching for "0xDEADBEEF" from hkp server keyserver.noreply.org gpgkeys: curl version = GnuPG curl-shim 1.4.6 Host: keyserver.noreply.org Port: 80 Command: SEARCH gpgkeys: search type is 5, and key is "DEADBEEF" * HTTP proxy is "http://:@:8080" gpgkeys: HTTP search error 7: couldn't connect: eof gpg: key "0xDEADBEEF" not found on keyserver This is using the released build of 1.4.6 on a W32 system. -- 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: 542 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20061213/a7f2c6a4/attachment.pgp From henman at it.to-be.co.jp Wed Dec 13 10:03:37 2006 From: henman at it.to-be.co.jp (djh) Date: Wed, 13 Dec 2006 18:03:37 +0900 Subject: HAVE_W32_SYSTEM Message-ID: <20061213180337.2224@henman-np.b-eng.it.to-be.co.jp> It was noted that cygwin has a a POSIX API wrapper for the Win32 API, with the gcc and other gnu tools. Mingw and DJGPP, unlike Cygwin, are designed for developing with the Win32 API directly and consequently they are not as useful for porting Unix projects to Windows or writing code that works on both Windows and Unix If you only need to build executables and static libraries the cygwin will normally build the source successfully (except from sometems win-32 quirks pop up). However, when it comes to shared libraries, ms-w32 dll format files are not the same as the *nix shared libraries (.so). At link time, a DLL effectively consists of two parts; the DLL itself which contains the shared object code, and an import library w hich consists of symbol stubs) functions which are actually linked into the executable, at a rate of one stub per entry point. So some differentiation is necessary for cygwin when building shared libraries, to allow for dll building. . "Cygwin can't replace the Windows runtime linker/loader so we're all stuck with it's behavior". I believe that this is still the case. Some of gpg related programs GNU auto-tools input files mention only mingw32 and set a W32 or some sort or other. It would be nice to also include a test case for cygwin and use the proper makefile.am and configure.in or .ac files. for example ----------- "makefile.in" ... so from makefile.am needs _LDF+AGS = -no-undefined -version-info x:y:z "configure.in" ------------- before the line containting AM_PROG_LIBTOOL the libtool provided macro, "AC_LIBTOOL_WIN32_DLL" needs to be added. From rjh at sixdemonbag.org Wed Dec 13 10:48:34 2006 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 13 Dec 2006 03:48:34 -0600 Subject: HAVE_W32_SYSTEM In-Reply-To: <20061213180337.2224@henman-np.b-eng.it.to-be.co.jp> References: <20061213180337.2224@henman-np.b-eng.it.to-be.co.jp> Message-ID: <457FCC72.2060009@sixdemonbag.org> djh wrote: > Mingw and DJGPP, unlike Cygwin, are designed for developing with the > Win32 API directly and consequently they are not as useful for > porting Unix projects to Windows or writing code that works on both > Windows and Unix This is true only from a certain point of view. >From a different point of view, they're more useful in creating crossplatform code. Their lack of heavy POSIX support encourages programmers to factor out OS-specific code into distinct modules, and discourages the All The World's A UNIX thinking that so many programmers fall into. From wk at gnupg.org Wed Dec 13 12:26:49 2006 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Dec 2006 12:26:49 +0100 Subject: 2 'Overlooked' Found In-Reply-To: <457F81BE.2010404@bellsouth.net> (John W. Moore, III's message of "Tue\, 12 Dec 2006 23\:29\:50 -0500") References: <457F81BE.2010404@bellsouth.net> Message-ID: <87u000yr2e.fsf@wheatstone.g10code.de> On Wed, 13 Dec 2006 05:29, jmoore3rd at bellsouth.net said: > \g10\gpgv.c (line 53): > > //#include "g10defs.h" > // above line should not be there :-> Thanks for noting. I did not run a make distcheck to catch this error before committing. Shalom-Salam, Werner From wk at gnupg.org Wed Dec 13 12:30:28 2006 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Dec 2006 12:30:28 +0100 Subject: Proxy problems In-Reply-To: <457FB087.7070100@gmail.com> (alphasigmax@gmail.com's message of "Wed\, 13 Dec 2006 18\:19\:27 +1030") References: <457EC779.2070000@gmail.com> <20061212152400.GA6347@jabberwocky.com> <457FB087.7070100@gmail.com> Message-ID: <87psaoyqwb.fsf@wheatstone.g10code.de> On Wed, 13 Dec 2006 08:49, alphasigmax at gmail.com said: > gpg: searching for "0xDEADBEEF" from hkp server keyserver.noreply.org > gpgkeys: curl version = GnuPG curl-shim 1.4.6 > Host: keyserver.noreply.org > Port: 80 > Command: SEARCH > gpgkeys: search type is 5, and key is "DEADBEEF" > * HTTP proxy is "http://:@:8080" > gpgkeys: HTTP search error 7: couldn't connect: eof > gpg: key "0xDEADBEEF" not found on keyserver > > This is using the released build of 1.4.6 on a W32 system. This is might be related to https://bugs.g10code.com/gnupg/issue739 although I never heard that Squid fails on half-closed connections. Salam-Shalom, Werner From alphasigmax at gmail.com Wed Dec 13 12:43:43 2006 From: alphasigmax at gmail.com (Alphax) Date: Wed, 13 Dec 2006 22:13:43 +1030 Subject: Proxy problems In-Reply-To: <87psaoyqwb.fsf@wheatstone.g10code.de> References: <457EC779.2070000@gmail.com> <20061212152400.GA6347@jabberwocky.com> <457FB087.7070100@gmail.com> <87psaoyqwb.fsf@wheatstone.g10code.de> Message-ID: <457FE76F.4070708@gmail.com> Werner Koch wrote: > On Wed, 13 Dec 2006 08:49, alphasigmax at gmail.com said: > >> gpg: searching for "0xDEADBEEF" from hkp server keyserver.noreply.org >> gpgkeys: curl version = GnuPG curl-shim 1.4.6 >> Host: keyserver.noreply.org >> Port: 80 >> Command: SEARCH >> gpgkeys: search type is 5, and key is "DEADBEEF" >> * HTTP proxy is "http://:@:8080" >> gpgkeys: HTTP search error 7: couldn't connect: eof >> gpg: key "0xDEADBEEF" not found on keyserver >> >> This is using the released build of 1.4.6 on a W32 system. > > This is might be related to https://bugs.g10code.com/gnupg/issue739 > although I never heard that Squid fails on half-closed connections. > So, would statically linking cURL into a W32 build fix this problem, and would there be licensing problems? -- 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: 542 bytes Desc: OpenPGP digital signature Url : /pipermail/attachments/20061213/bfef7e43/attachment-0001.pgp From dshaw at jabberwocky.com Wed Dec 13 14:43:59 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 13 Dec 2006 08:43:59 -0500 Subject: Proxy problems In-Reply-To: <87psaoyqwb.fsf@wheatstone.g10code.de> References: <457EC779.2070000@gmail.com> <20061212152400.GA6347@jabberwocky.com> <457FB087.7070100@gmail.com> <87psaoyqwb.fsf@wheatstone.g10code.de> Message-ID: <20061213134359.GC16382@jabberwocky.com> On Wed, Dec 13, 2006 at 12:30:28PM +0100, Werner Koch wrote: > On Wed, 13 Dec 2006 08:49, alphasigmax at gmail.com said: > > > gpg: searching for "0xDEADBEEF" from hkp server keyserver.noreply.org > > gpgkeys: curl version = GnuPG curl-shim 1.4.6 > > Host: keyserver.noreply.org > > Port: 80 > > Command: SEARCH > > gpgkeys: search type is 5, and key is "DEADBEEF" > > * HTTP proxy is "http://:@:8080" > > gpgkeys: HTTP search error 7: couldn't connect: eof > > gpg: key "0xDEADBEEF" not found on keyserver > > > > This is using the released build of 1.4.6 on a W32 system. > > This is might be related to https://bugs.g10code.com/gnupg/issue739 > although I never heard that Squid fails on half-closed connections. Drat. The HTTP_FLAG_NO_SHUTDOWN stuff was removed in the curl-shim. I can put it back for 1.4.7, but I wonder why do shutdown() at all? Whether (strictly speaking) this is a problem in the proxy or not, the half-closed connections seem to cause problems now and then. David From dshaw at jabberwocky.com Wed Dec 13 14:46:10 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 13 Dec 2006 08:46:10 -0500 Subject: Proxy problems In-Reply-To: <457FE76F.4070708@gmail.com> References: <457EC779.2070000@gmail.com> <20061212152400.GA6347@jabberwocky.com> <457FB087.7070100@gmail.com> <87psaoyqwb.fsf@wheatstone.g10code.de> <457FE76F.4070708@gmail.com> Message-ID: <20061213134610.GD16382@jabberwocky.com> On Wed, Dec 13, 2006 at 10:13:43PM +1030, Alphax wrote: > Werner Koch wrote: > > On Wed, 13 Dec 2006 08:49, alphasigmax at gmail.com said: > > > >> gpg: searching for "0xDEADBEEF" from hkp server keyserver.noreply.org > >> gpgkeys: curl version = GnuPG curl-shim 1.4.6 > >> Host: keyserver.noreply.org > >> Port: 80 > >> Command: SEARCH > >> gpgkeys: search type is 5, and key is "DEADBEEF" > >> * HTTP proxy is "http://:@:8080" > >> gpgkeys: HTTP search error 7: couldn't connect: eof > >> gpg: key "0xDEADBEEF" not found on keyserver > >> > >> This is using the released build of 1.4.6 on a W32 system. > > > > This is might be related to https://bugs.g10code.com/gnupg/issue739 > > although I never heard that Squid fails on half-closed connections. > > > > So, would statically linking cURL into a W32 build fix this problem, and > would there be licensing problems? There would be no licensing problem. cURL's license is GPL compatible, and there is a special exception to cover the cases where cURL happens to be linked to OpenSSL (the license of which isn't GPL compatible). David From wk at gnupg.org Wed Dec 13 16:09:52 2006 From: wk at gnupg.org (Werner Koch) Date: Wed, 13 Dec 2006 16:09:52 +0100 Subject: Proxy problems In-Reply-To: <20061213134359.GC16382@jabberwocky.com> (David Shaw's message of "Wed\, 13 Dec 2006 08\:43\:59 -0500") References: <457EC779.2070000@gmail.com> <20061212152400.GA6347@jabberwocky.com> <457FB087.7070100@gmail.com> <87psaoyqwb.fsf@wheatstone.g10code.de> <20061213134359.GC16382@jabberwocky.com> Message-ID: <87mz5rygqn.fsf@wheatstone.g10code.de> On Wed, 13 Dec 2006 14:43, dshaw at jabberwocky.com said: > Drat. The HTTP_FLAG_NO_SHUTDOWN stuff was removed in the curl-shim. I noticed that and it is on my list of things we need to clarify. > I can put it back for 1.4.7, but I wonder why do shutdown() at all? Shutting down the write end of the socket used to be necessary at the time I implemented HKP access. Looking at the ChangeLog does not reveal the actual reason except that it has been there since the beginning: Sat Jan 16 09:27:30 CET 1999 Werner Koch * http.c: New Wed Jan 20 21:40:21 CET 1999 Werner Koch * http.c (http_wait_response): Moved the shutdown behind the dup 2001-04-23 Werner Koch * http.c (http_wait_response): Implement new flag to inhibit the TCP shutdown. I assume that the original hkp keyserver required a shutdown because it implemented only pre HTTP 1.0 and failed to take the empty line after the headers of a GET as the end of a request. We used to have an option to suppress the shutdown: # If you have problems connecting to a HKP server through a buggy http # proxy, you can use keyserver option broken-http-proxy (see below), # but first you should make sure that you have read the man page # regarding proxies (keyserver option honor-http-proxy) David, you remember why we dropped it? Salam-Shalom, Werner From dshaw at jabberwocky.com Wed Dec 13 17:42:17 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 13 Dec 2006 11:42:17 -0500 Subject: Proxy problems In-Reply-To: <87mz5rygqn.fsf@wheatstone.g10code.de> References: <457EC779.2070000@gmail.com> <20061212152400.GA6347@jabberwocky.com> <457FB087.7070100@gmail.com> <87psaoyqwb.fsf@wheatstone.g10code.de> <20061213134359.GC16382@jabberwocky.com> <87mz5rygqn.fsf@wheatstone.g10code.de> Message-ID: <20061213164217.GA2541@jabberwocky.com> On Wed, Dec 13, 2006 at 04:09:52PM +0100, Werner Koch wrote: > I assume that the original hkp keyserver required a shutdown because > it implemented only pre HTTP 1.0 and failed to take the empty line > after the headers of a GET as the end of a request. We used to have > an option to suppress the shutdown: > > # If you have problems connecting to a HKP server through a buggy http > # proxy, you can use keyserver option broken-http-proxy (see below), > # but first you should make sure that you have read the man page > # regarding proxies (keyserver option honor-http-proxy) > > David, you remember why we dropped it? The real curl code clearly didn't use shutdown, and worked correctly with all the servers, so I dropped broken-http-proxy when I did the curl-shim. Unfortunately, I missed that the code defaults to use shutdown. I can see how this might have been necessary with old HKP servers in the past, but they don't really exist any longer. There certainly are no original PKS servers left at this point. The few (one?) that are left are running the fixed PKS I made to not eat subkeys. That PKS also properly handles HTTP/1.0 requests with the blank line. I think the right fix here is to either hardwire HTTP_FLAG_NO_SHUTDOWN to on in curl-shim, or just remove the shutdown stuff altogether. David From wk at gnupg.org Thu Dec 14 09:13:14 2006 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Dec 2006 09:13:14 +0100 Subject: Proxy problems In-Reply-To: <20061213164217.GA2541@jabberwocky.com> (David Shaw's message of "Wed\, 13 Dec 2006 11\:42\:17 -0500") References: <457EC779.2070000@gmail.com> <20061212152400.GA6347@jabberwocky.com> <457FB087.7070100@gmail.com> <87psaoyqwb.fsf@wheatstone.g10code.de> <20061213134359.GC16382@jabberwocky.com> <87mz5rygqn.fsf@wheatstone.g10code.de> <20061213164217.GA2541@jabberwocky.com> Message-ID: <87hcvyvqsl.fsf@wheatstone.g10code.de> On Wed, 13 Dec 2006 17:42, dshaw at jabberwocky.com said: > The real curl code clearly didn't use shutdown, and worked correctly > with all the servers, so I dropped broken-http-proxy when I did the > curl-shim. Unfortunately, I missed that the code defaults to use Okay. You did far more tests with keyservers than me. > I think the right fix here is to either hardwire HTTP_FLAG_NO_SHUTDOWN > to on in curl-shim, or just remove the shutdown stuff altogether. Lets remove the shutdown code in 1.4. As I use the http code from 2.0 also in other projects I feel safer to keep it but reverse the option and use HTTP_FLAG_SHUTDOWN. Shalom-Salam, Werner From wk at gnupg.org Thu Dec 14 10:22:18 2006 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Dec 2006 10:22:18 +0100 Subject: Proxy problems In-Reply-To: <457FB087.7070100@gmail.com> (alphasigmax@gmail.com's message of "Wed\, 13 Dec 2006 18\:19\:27 +1030") References: <457EC779.2070000@gmail.com> <20061212152400.GA6347@jabberwocky.com> <457FB087.7070100@gmail.com> Message-ID: <87psamu911.fsf@wheatstone.g10code.de> An embedded and charset-unspecified text was scrubbed... Name: ks-proxy-fix-14.diff Url: /pipermail/attachments/20061214/769b9870/attachment.diff From jmoore3rd at bellsouth.net Thu Dec 14 22:44:33 2006 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Thu, 14 Dec 2006 16:44:33 -0500 Subject: 9th STEP Time/Issue Message-ID: <4581C5C1.7050806@bellsouth.net> 48 hours ago I Posted on this List 2 'Overlooked' Changes in the GnuPG SVN Code. The appearance/wording of My Post indicated that I, alone, discovered these. This was NOT the accurate Case. I shall *not* offer a reason for this because of My belief that "Excuses are like assholes; Everybody has 1 and they all STINK!" My (former?) Mentor/Friend, Tom Pegios, originally pointed out these 2 File/Lines to Me. At Tom's suggestion I have run a WinMerge comparison against every File in svn4382 to check His findings. All this Explained; I Stand Corrected/Outed! JOHN :-[ Timestamp: Thursday 14 Dec 2006, 16:43 --500 (Eastern Standard Time) P.S. Private Email were sent to WK & DS about this immediately afterward. From patrick at mozilla-enigmail.org Tue Dec 19 09:33:25 2006 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Tue, 19 Dec 2006 09:33:25 +0100 Subject: How to Determine Digest Algorithm Message-ID: <4587A3D5.9060404@mozilla-enigmail.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm trying to find a good way to determine the digest algorithm that GnuPG uses for a signed message. My problem is this: for PGP/MIME signed messages, I need to know the algorithm before the message is created. Therefore I create a signed dummy message, and extract from it the hash algorithm. However, the problem is that this requires the user to type the passphrase twice, which I would like to avoid. Is there a better way to determine the hash algorithm without actually creating a signed message? Thanks, Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRYejz3cOpHodsOiwAQL5HQgAhuew2yehTH1M57rFAPWinGU3IKMHH/5k oh86sv45N0YqQJH8CyErnKwNqQCaAuozi4ij3duN3gmzJBRT9+t4BHKqQXyf7ZSw cYutIhrHGhvCtyosx/fpSe5p7VjN4uU+XwyDwM4pDlVirVrhdEn3zojqtUUhZn5g ESvp7xcNecF5j8q557Bzsw9dIsET94OusQ/PifWmZJ8JuVyEsB952N6GpZ7RLic3 5+4KIr2c8wxbSX+CGCxDZuSUwBBde5OhRU7BHpCtFu7gUkyWRckefc/nQwhJxVgx Q0b0jzhUFGL7BNPccUCDX3geW85y6s2Thg44JGPKT+jZN3Lc011ucA== =3IvX -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Tue Dec 19 14:50:31 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 19 Dec 2006 08:50:31 -0500 Subject: How to Determine Digest Algorithm In-Reply-To: <4587A3D5.9060404@mozilla-enigmail.org> References: <4587A3D5.9060404@mozilla-enigmail.org> Message-ID: <20061219135031.GB14338@jabberwocky.com> On Tue, Dec 19, 2006 at 09:33:25AM +0100, Patrick Brunschwig wrote: > I'm trying to find a good way to determine the digest algorithm that > GnuPG uses for a signed message. My problem is this: for PGP/MIME signed > messages, I need to know the algorithm before the message is created. > Therefore I create a signed dummy message, and extract from it the hash > algorithm. However, the problem is that this requires the user to type > the passphrase twice, which I would like to avoid. What mutt does for this is to make the signature first and grab the digest algorithm from that to make the micalg field. Does that method not work given the way Enigmail ties into the mail code? > Is there a better way to determine the hash algorithm without actually > creating a signed message? At the moment, not really, but it's not impossible to add a way to ask GPG the question "if you were going to make a signature, which hash algorithm would you use". David From patrick at mozilla-enigmail.org Wed Dec 20 17:40:41 2006 From: patrick at mozilla-enigmail.org (Patrick Brunschwig) Date: Wed, 20 Dec 2006 17:40:41 +0100 Subject: How to Determine Digest Algorithm In-Reply-To: <20061219135031.GB14338@jabberwocky.com> References: <4587A3D5.9060404@mozilla-enigmail.org> <20061219135031.GB14338@jabberwocky.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw wrote: > On Tue, Dec 19, 2006 at 09:33:25AM +0100, Patrick Brunschwig wrote: >> I'm trying to find a good way to determine the digest algorithm that >> GnuPG uses for a signed message. My problem is this: for PGP/MIME signed >> messages, I need to know the algorithm before the message is created. >> Therefore I create a signed dummy message, and extract from it the hash >> algorithm. However, the problem is that this requires the user to type >> the passphrase twice, which I would like to avoid. > > What mutt does for this is to make the signature first and grab the > digest algorithm from that to make the micalg field. Does that method > not work given the way Enigmail ties into the mail code? Unfortunately not, or at least not without a major rewrite of a large part. >> Is there a better way to determine the hash algorithm without actually >> creating a signed message? > > At the moment, not really, but it's not impossible to add a way to ask > GPG the question "if you were going to make a signature, which hash > algorithm would you use". That would be nice for the future, but I think in short term, I'll find a way to cache the passphrase for the 2nd call to gpg. - -Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRYlniHcOpHodsOiwAQJs5AgAhoi2EwjaaXgYqlk8eOLRkSZEw851Gveq UvizHDfDGJzZliGGD92l+xypE3Wqt6EvvsXVQQkrkTv4J5eXODosn5w5gvbswryn IYBCSUq2pTl22uZqxXpalE+1ouXaFJpEA4lmwZyP0LOP/0bbBt/1GPGSYAEZHWPq VEw4EaPtEZJaM+ZakCX03V11Cx4QM8SRD0Wz4Trfqu6YDkE/azEUZyFXNEzp0K8a JoLTwtDROdRLN5qck+hFWjNjtovppTV0RnUCjccGGIV56qV8OHgLRhXA6I9z0UuL NMxxRlvP0HAWg90Hic7tM7Py+/9FaqiEWXknVRUCTIgelgL1lapHJA== =cOMp -----END PGP SIGNATURE----- From g.esp at free.fr Thu Dec 14 00:31:42 2006 From: g.esp at free.fr (Gilles Espinasse) Date: Thu, 14 Dec 2006 00:31:42 +0100 Subject: --disable-card-support and libusb dependency Message-ID: <023701c71f0e$d9173b10$f9b5a8c0@pii350> After 1.4.6 compilation with --enable-minimal, when using strace with gpg, I find that libusb is called. As --enable-minimal imply --disable-card-support is set, should not --disable-card-support disable linking with libusb? I discover that only a configure with --with-libusb=no do that when libusb is installed. Gilles From dshaw at jabberwocky.com Thu Dec 21 18:15:46 2006 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 21 Dec 2006 12:15:46 -0500 Subject: --disable-card-support and libusb dependency In-Reply-To: <023701c71f0e$d9173b10$f9b5a8c0@pii350> References: <023701c71f0e$d9173b10$f9b5a8c0@pii350> Message-ID: <20061221171546.GA795@jabberwocky.com> On Thu, Dec 14, 2006 at 12:31:42AM +0100, Gilles Espinasse wrote: > After 1.4.6 compilation with --enable-minimal, when using strace with gpg, I > find that libusb is called. > > As --enable-minimal imply --disable-card-support is set, should > not --disable-card-support disable linking with libusb? > I discover that only a configure with --with-libusb=no do that when libusb > is installed. You're right. This is fixed for the next version. David From michael at vorlon.ping.de Fri Dec 22 22:34:29 2006 From: michael at vorlon.ping.de (Michael Bienia) Date: Fri, 22 Dec 2006 22:34:29 +0100 Subject: GnuPG 2.0 and RIPEMD160 signatures with gpg-agent and an OpenPGP card Message-ID: <20061222213429.GA9526@vorlon.ping.de> Hello, GnuPG 2.0 can only generate SHA1 signatures when used with gpg-agent and an OpenPGP card. I've already had the same problem with GnuPG 1.4 in March 2006 [1]. It was fixed with svn commits 4075 and 4076. Can the change from 4076 [2] be also applied to gnupg 2.0? Thanks, Michael 1: http://marc.theaimsgroup.com/?l=gnupg-devel&m=114294504827539&w=2 2: http://marc.theaimsgroup.com/?l=gnupg-commit-watchers&m=114294455224862&w=2 From ueno at unixuser.org Tue Dec 26 06:05:44 2006 From: ueno at unixuser.org (Daiki Ueno) Date: Tue, 26 Dec 2006 14:05:44 +0900 Subject: Request for a new status code for untrusted keys Message-ID: Hello, When I encrypt to a user whose key is not marked as trusted, gpg shows detail information about the key and asks me to confirm. However, if --no-tty is specified, there is no status code to indicate which (sub)key is untrusted. $ gpg2 --no-tty --status-fd=1 --command-fd=0 -r 5B0358A2 \ --encrypt /dev/null gpg: C3680A6E: There is no assurance this key belongs to the named user [GNUPG:] GET_BOOL untrusted_key.override Sorry for bothering you again, may I request a new status code (perhaps NEED_TRUST )? Regards, -- Daiki Ueno From moritz at barsnick.net Thu Dec 7 16:28:29 2006 From: moritz at barsnick.net (Moritz Barsnick) Date: Thu, 07 Dec 2006 15:28:29 -0000 Subject: 1.4.6: Build problem with doc/yat2m Message-ID: <20061207134444.GA9526@lx-xeon-8.ibw.intel.com> Hi, I'm to lazy to get YAPW (yet another password) for bugs.gnupg.org, so I'm posting here according to the README. (I'm not subscribed.) ;-) With gnupg-1.4.6, I have encountered a newly introduced build problem. doc/yat2m now uses the new $(CC_FOR_BUILD) [*]. This is generally okay, but it totally ignores if I explicitly set LDFLAGS which are _required_ for building. Background: I (try to) compile all my apps with the Intel C++ Compiler (icc). This compiler creates binaries which depend on a certain dynamic lib (libimf.so) if not explicitly told to link that lib statically (with the -i-static LDFLAG). I do _not_ provide this flag as CC="icc -i-static" because it is _not_ a compiler flag, and the compiler would warn with every call. My suggestion (it works for me, I don't think there are any drawbacks): Change yat2m: Makefile yat2m.c $(CC_FOR_BUILD) -o $@ $(srcdir)/yat2m.c to yat2m: Makefile yat2m.c $(CC_FOR_BUILD) $(LDFLAGS) -o $@ $(srcdir)/yat2m.c in doc/Makefile*. Or, more generically, add the LDFLAGS to CC_FOR_BUILD in autoconf. I did read configure.ac, and no, I am not cross-compiling. Thanks for listening, kind regards, Moritz [*] What for? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20061207/00f32f18/attachment.pgp From jari.aalto at cante.net Wed Dec 20 00:43:49 2006 From: jari.aalto at cante.net (Jari Aalto) Date: Wed, 20 Dec 2006 01:43:49 +0200 Subject: Bug#403833: gpg-agent: enhance --write-env-file to append $HOST to filename Message-ID: <20061219234349.29042.88378.reportbug@cante> Package: gnupg-agent Version: 2.0.0-5.2 Severity: minor Please enhance the --write-env-file to append current host to the filename: now : $HOME/.gpg-agent-info proposed: $HOME/.gpg-agent-info- The motivation is that hosts usually use NFS mounted home directories and reading the current $HOME/.gpg-agent-info will not work in another host. Host X +----- host A | /home ---+----- Host B | +----- Host C If user log into all hosts: ssh user at hostA ssh user at hostB ssh user at hostC The initialization code in ~/.profile could work if --write-env-file wrote host specific files: $HOME/.gpg-agent-info-hostA $HOME/.gpg-agent-info-hostB $HOME/.gpg-agent-info-hostC It would be even better if the host portion used FDQN instead of the hostname(1). -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-3-686 Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US) Versions of packages gnupg-agent depends on: ii libc6 2.3.6.ds1-9 GNU C Library: Shared libraries ii libgcrypt11 1.2.3-2 LGPL Crypto library - runtime libr ii libgpg-error0 1.4-2 library for common error values an ii libpth20 2.0.7-4 The GNU Portable Threads Versions of packages gnupg-agent recommends: ii gnupg 1.4.6-1 GNU privacy guard - a free PGP rep ii gnupg2 2.0.0-5.2 GNU privacy guard - a free PGP rep pn pinentry-curses | pinentry (no description available) -- no debconf information From sergi at calcurco.org Thu Dec 21 14:27:22 2006 From: sergi at calcurco.org (Sergi Blanch i Torne) Date: Thu, 21 Dec 2006 13:27:22 -0000 Subject: eccGnuPG 1.4.6-0.2.0beta1 Message-ID: <200612191151.21922.sergi@calcurco.org> Hi! Using the recent publication of GnuPG's version 1.4.6 a elliptic curve beta version of the branch 0.2 has been published. And also you have the experimental patch 0.1.6 of the current branch. I will not get tired of repeating this patch is experimental in the 0.1 branch, and imagine who this beta can be it more. You can read about this patch in: http://alumnes.eps.udl.es/%7Ed4372211/index.en.html Be careful and good hack! /Sergi. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 203 bytes Desc: not available Url : /pipermail/attachments/20061221/21e8e0c0/attachment.pgp From newsaccount at kfwebs.net Tue Dec 19 13:54:07 2006 From: newsaccount at kfwebs.net (Kristian Fiskerstrand) Date: Tue, 19 Dec 2006 12:54:07 -0000 Subject: How to Determine Digest Algorithm In-Reply-To: <4587A3D5.9060404@mozilla-enigmail.org> References: <4587A3D5.9060404@mozilla-enigmail.org> Message-ID: <4587C4BA.2060404@kfwebs.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Patrick Brunschwig wrote, On 12/19/2006 09:33 AM: > I'm trying to find a good way to determine the digest algorithm that > GnuPG uses for a signed message. My problem is this: for PGP/MIME signed > messages, I need to know the algorithm before the message is created. > Therefore I create a signed dummy message, and extract from it the hash > algorithm. However, the problem is that this requires the user to type > the passphrase twice, which I would like to avoid. If the gpg-agent is used it would be cached. Ditto for the password handling you're using in Enignamil > > Is there a better way to determine the hash algorithm without actually > creating a signed message? > In my opinion the digest algorithm is better decided by the sender in the first place. The message might not be addressed to everyone that is supposed to verify it at a later point, and the digest itself should be based upon the senders requirements. e.g. I wouldn't sign a contract with an md5 digest algorithm, in the light of the work being done on cracking such a message digest, because that was the only common denominator. Then I'd rather ask the others to upgrade. Post scriptum! I've been experimenting a bit with the gnupg key generation lately, and have at least a keyset of 15360 bit keys generated ( http://www.kfwebs.net/news/603/15360-bit-OpenPGP-key ) - -- - ---------------------------- Kristian Fiskerstrand http://www.kfwebs.net - ---------------------------- http://www.secure-my-email.com http://www.secure-my-internet.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBRYfEuhbgz41rC5UIAQgXxA/+MJmQLEb9ghqETy+fJhvzIkR1zpgu+x8i A9EXMl8fBQsYs3P9K1Q1y6puen16+aZG0cRH8xMCCl0OiC720jBiuRfC2pX+6Z7f q3BjQPlhtrdbXE7u6Ar2KM/6h+n0VoKQ0xGZJoXg2Aqlin64LFRNo1OTTIO5jQgw wG5RmxX8YbxvWKZk+cK5tTuGIgpofEotHBUZ6aPtqZBJMJKS41pdVdwtobcW+eDn yKYTRYjrg/wUMUTwTKzUrLe1iBdmVv36mwHMiwOdE3koITkmcdsv7rYUS5s0k7KZ 0WWRiuKXQDVkDOJ/kaZh+FHFbaoxhAUio183tSZegZX1eJphrow1jUPLLSJw6Td9 /XVjROqfKWgaxwd+khcVqClwVSyUfIUbnXTzinNWL2soiqeSPkMR0Uws1Fq0jYF+ 9s1gAdMjABUny/DazFOYPK4ue3JCJNgvsX4ISGG/7hC8eiurli0Owr/kRGX/sIpj L1dip/kP5CeWavaVFrJnyBx36DHRGMUADqZSMUvE9cdaXsAOIdxDPzt74Ezhkuj6 /9tBg9w6PKcFkIzkin0AW261wA/2gizxPniEGD7Yd/ZsoC1acUO32EftBPllZjIt qc9kUFAy1EDWzS4lLo/tk3aT8ZV1vZfMQw7SyUsdhXyysY6fTqqDhSznSTA1boiE 5dIi9/xjZIs= =dgPO -----END PGP SIGNATURE-----