From jas at extundo.com Mon Jun 19 14:26:48 2006 From: jas at extundo.com (Simon Josefsson) Date: Mon Jun 19 16:25:52 2006 Subject: Link with -no-undefined Message-ID: <87bqsp72lz.fsf@latte.josefsson.org> Adding -no-undefined flag to libtool has a side-effect of producing an DLL of libgcrypt when cross-compiling to mingw32. The Libtool documentation for the flag is somewhat confusing, but the intention is that the flag is used when the library doesn't need any externals symbols, which is true for libgcrypt. 2006-06-19 Simon Josefsson * Makefile.am (libgcrypt_la_LDFLAGS): Add -no-undefined since libgcrypt doesn't depend on any external symbols. Index: Makefile.am =================================================================== --- Makefile.am (revision 1155) +++ Makefile.am (working copy) @@ -1,4 +1,4 @@ -# Copyright (C) 1998,1999,2000,2001,2002,2003,2004,2005 Free Software Foundation, Inc. +# Copyright (C) 1998,1999,2000,2001,2002,2003,2004,2005,2006 Free Software Foundation, Inc. # # This file is part of Libgcrypt. # @@ -42,7 +42,8 @@ ath.h ath.c libgcrypt_la_LDFLAGS = $(libgcrypt_version_script_cmd) -version-info \ - @LIBGCRYPT_LT_CURRENT@:@LIBGCRYPT_LT_REVISION@:@LIBGCRYPT_LT_AGE@ + @LIBGCRYPT_LT_CURRENT@:@LIBGCRYPT_LT_REVISION@:@LIBGCRYPT_LT_AGE@ \ + -no-undefined libgcrypt_la_DEPENDENCIES = ../cipher/libcipher.la ../mpi/libmpi.la \ $(srcdir)/libgcrypt.vers libgcrypt_la_LIBADD = ../cipher/libcipher.la ../mpi/libmpi.la \ From marcus.brinkmann at ruhr-uni-bochum.de Mon Jun 19 20:43:09 2006 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Mon Jun 19 20:43:03 2006 Subject: Link with -no-undefined In-Reply-To: <87bqsp72lz.fsf@latte.josefsson.org> References: <87bqsp72lz.fsf@latte.josefsson.org> Message-ID: <87irmxf0le.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Mon, 19 Jun 2006 14:26:48 +0200, Simon Josefsson wrote: > > Adding -no-undefined flag to libtool has a side-effect of producing an > DLL of libgcrypt when cross-compiling to mingw32. > > The Libtool documentation for the flag is somewhat confusing, but the > intention is that the flag is used when the library doesn't need any > externals symbols, which is true for libgcrypt. In GPGME, we have something like the below. We also have a resource file and a symbol export definition file (eg libgcrypt/w32-dll/libgcrypt.def). I think that any port of libgcrypt to the mingw32 target should have all of these, and whatever else is required to make libgcrypt work on w32 targets... Thanks, Marcus if HAVE_W32_SYSTEM LTRCCOMPILE = $(LIBTOOL) --mode=compile $(RC) \ `echo $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) | \ sed -e 's/-I/--include-dir /g;s/-D/--define /g'` %.lo : %.rc $(LTRCCOMPILE) -i $< -o $@ gpgme_res = versioninfo.lo gpgme_res_ldflag = -Wl,.libs/versioninfo.o no_undefined = -no-undefined export_symbols = -export-symbols $(srcdir)/gpgme.def install-def-file: $(INSTALL) $(srcdir)/gpgme.def $(DESTDIR)$(libdir)/gpgme.def uninstall-def-file: -rm $(DESTDIR)$(libdir)/gpgme.def gpgme_deps = $(gpgme_res) gpgme.def else gpgme_res = gpgme_res_ldflag = no_undefined = export_symbols = install-def-file: uninstall-def-file: gpgme_deps = endif 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) \ @LTLIBOBJS@ $(srcdir)/libgpgme.vers $(gpgme_deps) libgpgme_la_LIBADD = libgpgme-real.la $(assuan_libobjs) @LTLIBOBJS@ \ @GPG_ERROR_LIBS@ From jas at extundo.com Wed Jun 21 17:33:30 2006 From: jas at extundo.com (Simon Josefsson) Date: Wed Jun 21 17:32:25 2006 Subject: Link with -no-undefined In-Reply-To: <87irmxf0le.wl%marcus.brinkmann@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "Mon, 19 Jun 2006 20:43:09 +0200") References: <87bqsp72lz.fsf@latte.josefsson.org> <87irmxf0le.wl%marcus.brinkmann@ruhr-uni-bochum.de> Message-ID: <87hd2e34mt.fsf@latte.josefsson.org> Marcus Brinkmann writes: > At Mon, 19 Jun 2006 14:26:48 +0200, > Simon Josefsson wrote: >> >> Adding -no-undefined flag to libtool has a side-effect of producing an >> DLL of libgcrypt when cross-compiling to mingw32. >> >> The Libtool documentation for the flag is somewhat confusing, but the >> intention is that the flag is used when the library doesn't need any >> externals symbols, which is true for libgcrypt. > > In GPGME, we have something like the below. We also have a resource > file and a symbol export definition file (eg > libgcrypt/w32-dll/libgcrypt.def). I think that any port of libgcrypt > to the mingw32 target should have all of these, and whatever else is > required to make libgcrypt work on w32 targets... Thanks. My point was that with -no-undefined, I do get a DLL that seems to work fine on w32 machines. So I think my patch could be applied without your additional work. If someone wants to integrate your additional stuff, that would be fine too, of course. /Simon From jas at extundo.com Wed Jun 21 21:13:07 2006 From: jas at extundo.com (Simon Josefsson) Date: Wed Jun 21 21:12:03 2006 Subject: libgpg-error crash on MinGW Message-ID: <87irmu1fwc.fsf@latte.josefsson.org> I get a crash in libgpg-error: (gdb) bt #0 0x77c478ac in strlen () from /cygdrive/c/WINDOWS/system32/msvcrt.dll #1 0x00491420 in _gpg_err_bindtextdomain ( domainname=0x49593a "libgpg-error", dirname=0xffffffff
) at ../../libgpg-error-1.3/src/w32-gettext.c:1581 #2 0x004926ef in gpg_err_init () at ../../libgpg-error-1.3/src/init.c:58 The dirname parameter is off, and get_locale_dir is at fault: static char * get_locale_dir (void) { char *instdir; char *p; char *dname; instdir = read_w32_registry_string ("HKEY_LOCAL_MACHINE", REGKEY, "Install Directory"); if (!instdir) return; This will return garbage if the desired registry key is not present. For some reason this only happens on Windows XP but not Windows 2000. Maybe the stack happened to be different... The following patch fixes this. Thanks, Simon Index: init.c =================================================================== --- init.c (revision 173) +++ init.c (working copy) @@ -196,7 +196,7 @@ instdir = read_w32_registry_string ("HKEY_LOCAL_MACHINE", REGKEY, "Install Directory"); if (!instdir) - return; + return NULL; /* Build the key: "/share/locale". */ #define SLDIR "\\share\\locale" @@ -204,7 +204,7 @@ if (!dname) { free (instdir); - return; + return NULL; } p = dname; strcpy (p, instdir); From ametzler at downhill.at.eu.org Sun Jun 25 16:38:43 2006 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun Jun 25 17:08:50 2006 Subject: C'n'p error in ./cipher/sha512.c copyright statement Message-ID: Hello, cipher/sha512.c starts with: /* sha512.c - SHA384 and SHA512 hash functions * Copyright (C) 2003 Free Software Foundation, Inc. [...] * Libgcrypt is free software; you can redistribute it and/or modify * it under the terms of the GNU Lesser general Public License as [...] * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU Lesser General Public License for more details. * * You should have received a copy of the GNU General Public License [...] The last paragraph should also refer to "GNU Lesser general Public License" instead of "GNU General Public License". Thanks, cu andreas From ametzler at downhill.at.eu.org Sun Jun 25 18:55:57 2006 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun Jun 25 18:55:10 2006 Subject: Inconsisten usage of secure memory? (Debianbug #212329) Message-ID: Hej, I am trying to make sense out of . The bug used to manifest in mutt (or gaim) sometimes not being able to connect, because of "operation is not possible without initialized secure memory". Mutt is not using gcrypt directly but gnutls. I think the bug somehow does not re-appear in mutt nowadays, otherwise abovementioned report would probably show a recent followup. Anyway, what came out of it was this: I can't see any way that gnutls could possibly activate the secure memory code it's hardcoded that argument to zero yup, there are mixed guarded and unguarded calls to gcry_malloc_secure in one of the libgcrypt ciphers I can't see that being right at all hd = secure ? gcry_malloc_secure( n + sizeof( struct gcry_md_context ) ) : gcry_malloc( n + sizeof( struct gcry_md_context ) ); ... if( hmac ) { ctx->macpads = gcry_malloc_secure( 128 ); that seems logically inconsistant and the public key cipher doesn't guard the call at all any of the ciphers using HMAC will break like this I am not sure whether this is buggy, but I could not find anything in the documentation about it, and all the things said above still seem to apply in 1.2.2. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken. (c) Jasper Ffforde