From wk at gnupg.org Thu Feb 1 10:12:08 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Feb 2007 10:12:08 +0100 Subject: [patch] bus error in gcry_free Message-ID: <87odoe2qdz.fsf@wheatstone.g10code.de> A non-text attachment was scrubbed... Name: libgcrypt-secmem.patch Type: text/x-patch Size: 1511 bytes Desc: not available Url : /pipermail/attachments/20070201/10407555/attachment.bin From christianbiere at gmx.de Thu Feb 1 14:34:19 2007 From: christianbiere at gmx.de (Christian Biere) Date: Thu, 1 Feb 2007 14:34:19 +0100 Subject: [patch] bus error in gcry_free In-Reply-To: <87odoe2qdz.fsf@wheatstone.g10code.de> References: <87odoe2qdz.fsf@wheatstone.g10code.de> Message-ID: <20070201133419.GA298@cyclonus> Werner Koch wrote: > we got some reports about segvs or bus errors with libgcrypt. The > bugs has been fixed yesterday. For those who don't want to wait for a > new release, find attached a patch. This patch is nonsense. It may work if you cast to size_t or unsigned long. -- Christian From wk at gnupg.org Thu Feb 1 15:58:54 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Feb 2007 15:58:54 +0100 Subject: [patch] bus error in gcry_free In-Reply-To: <20070201133419.GA298@cyclonus> (Christian Biere's message of "Thu\, 1 Feb 2007 14\:34\:19 +0100") References: <87odoe2qdz.fsf@wheatstone.g10code.de> <20070201133419.GA298@cyclonus> Message-ID: <87sldpyle9.fsf@wheatstone.g10code.de> On Thu, 1 Feb 2007 14:34, christianbiere at gmx.de said: > This patch is nonsense. It may work if you cast to size_t or unsigned long. Huh? return (pool_okay && p >= pool && p < (const void*)((const char*)pool+pool_size)); I agree that the casts are not required but they don't harm either. Actually I committed this: int _gcry_private_is_secure (const void *p) { return (pool_okay && p >= pool && p < pool+pool_size); } with /* The pool of secure memory. */ static void *pool; /* Size of POOL in bytes. */ static size_t pool_size; So what is the nonsense here? This is a straightforward check to see whether P points into POOL. Compare this to the old code: if (pool_okay && BLOCK_VALID (ADDR_TO_BLOCK (p))) Where the second term expands to: ((char*)((memblock_t*) ((char*)p - BLOCK_HEAD_SIZE)) - (char*)pool) < pool_size As you can see we can easily get an address wrap here: If P == POOL+1 and assuming a BLOCK_HEAD_SIZE of 8 we get POOL + 1 - 8 - POOL == -7 and thus the test may or may not return false as it should. With P==POOL+8 we will even get 0 < pool_size which is always true. The function now falsely claims that P pointes into POOL and will act on it with all kinds of bad consequences. Shalom-Salam, Werner From christianbiere at gmx.de Thu Feb 1 16:24:11 2007 From: christianbiere at gmx.de (Christian Biere) Date: Thu, 1 Feb 2007 16:24:11 +0100 Subject: [patch] bus error in gcry_free In-Reply-To: <87sldpyle9.fsf@wheatstone.g10code.de> References: <87odoe2qdz.fsf@wheatstone.g10code.de> <20070201133419.GA298@cyclonus> <87sldpyle9.fsf@wheatstone.g10code.de> Message-ID: <20070201152411.GD298@cyclonus> Werner Koch wrote: > On Thu, 1 Feb 2007 14:34, christianbiere at gmx.de said: > > > This patch is nonsense. It may work if you cast to size_t or unsigned long. > > Huh? > > return (pool_okay > && p >= pool > && p < (const void*)((const char*)pool+pool_size)); > If p points into the pool or just one byte after it, everything is fine and well-defined. Otherwise, the behaviour of this code is completely undefined. A compile may optimize this into this: return pool_okay && p != (const void*)((const char*)pool+pool_size); That's probably not what you meant. > I agree that the casts are not required but they don't harm either. > Actually I committed this: > int > _gcry_private_is_secure (const void *p) > { > return (pool_okay > && p >= pool > && p < pool+pool_size); > } Then you've been GCCed. pointer arithmetic with "void *" is not covered by any C standard and usually GCC warns about this. > ((char*)((memblock_t*) ((char*)p - BLOCK_HEAD_SIZE)) - (char*)pool) > < pool_size > > As you can see we can easily get an address wrap here: Yes, that's obviously wrong too. -- Christian From wk at gnupg.org Thu Feb 1 16:55:00 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Feb 2007 16:55:00 +0100 Subject: [patch] bus error in gcry_free In-Reply-To: <20070201152411.GD298@cyclonus> (Christian Biere's message of "Thu\, 1 Feb 2007 16\:24\:11 +0100") References: <87odoe2qdz.fsf@wheatstone.g10code.de> <20070201133419.GA298@cyclonus> <87sldpyle9.fsf@wheatstone.g10code.de> <20070201152411.GD298@cyclonus> Message-ID: <87fy9pyisr.fsf@wheatstone.g10code.de> On Thu, 1 Feb 2007 16:24, christianbiere at gmx.de said: >> return (pool_okay >> && p >= pool >> && p < (const void*)((const char*)pool+pool_size)); >> > > If p points into the pool or just one byte after it, everything is fine and > well-defined. Otherwise, the behaviour of this code is completely undefined. > A compile may optimize this into this: > > return pool_okay && p != (const void*)((const char*)pool+pool_size); Sorry, I may be temporary blind but I can't see how you come to this conclusion. What is wrong with: (const void*) ((const char*)pool + pool_size) ================= ========= So that we can And add the size do pointer of the pool arithmetics ================================ Yielding a pointer right behind POOL ================================================== Casting it to void* for proper comparing against P ? How can the comparison be optimized away? > Then you've been GCCed. pointer arithmetic with "void *" is not covered by > any C standard and usually GCC warns about this. Damned, forgot to enable the extra gcc warnings. I knew that there must have been some reason that I originally casted it. That happens if you rely too much on warnings :-( Salam-Shalom, Werner From christianbiere at gmx.de Thu Feb 1 20:39:10 2007 From: christianbiere at gmx.de (Christian Biere) Date: Thu, 1 Feb 2007 20:39:10 +0100 Subject: [patch] bus error in gcry_free In-Reply-To: <87fy9pyisr.fsf@wheatstone.g10code.de> References: <87odoe2qdz.fsf@wheatstone.g10code.de> <20070201133419.GA298@cyclonus> <87sldpyle9.fsf@wheatstone.g10code.de> <20070201152411.GD298@cyclonus> <87fy9pyisr.fsf@wheatstone.g10code.de> Message-ID: <20070201193910.GA5210@cyclonus> Werner Koch wrote: > On Thu, 1 Feb 2007 16:24, christianbiere at gmx.de said: > > >> return (pool_okay > >> && p >= pool > >> && p < (const void*)((const char*)pool+pool_size)); > >> > > > > If p points into the pool or just one byte after it, everything is fine and > > well-defined. Otherwise, the behaviour of this code is completely undefined. > > A compile may optimize this into this: > > > > return pool_okay && p != (const void*)((const char*)pool+pool_size); > > Sorry, I may be temporary blind but I can't see how you come to this > conclusion. What is wrong with: > > (const void*) ((const char*)pool + pool_size) You're looking at the wrong part. > ? How can the comparison be optimized away? Because passing any other pointer yields either true or has undefined behaviour. Searching the web for the phrase "In all other cases, the behavior is undefined." will take you directly to relevant section of the standard. -- Christian From wk at gnupg.org Fri Feb 2 09:55:19 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Feb 2007 09:55:19 +0100 Subject: [patch] bus error in gcry_free In-Reply-To: <20070201193910.GA5210@cyclonus> (Christian Biere's message of "Thu\, 1 Feb 2007 20\:39\:10 +0100") References: <87odoe2qdz.fsf@wheatstone.g10code.de> <20070201133419.GA298@cyclonus> <87sldpyle9.fsf@wheatstone.g10code.de> <20070201152411.GD298@cyclonus> <87fy9pyisr.fsf@wheatstone.g10code.de> <20070201193910.GA5210@cyclonus> Message-ID: <8764alszuw.fsf@wheatstone.g10code.de> On Thu, 1 Feb 2007 20:39, christianbiere at gmx.de said: > Because passing any other pointer yields either true or has undefined behaviour. You mean using pointers with relational operators. C-99 says: 6.5.8 Relational operators [#5] When two pointers are compared, the result depends on the relative locations in the address space of the objects pointed to. If two pointers to object or incomplete types both point to the same object, or both point one past the last element of the same array object, they compare equal. If the objects pointed to are members of the same aggregate object, pointers to structure members declared later compare greater than pointers to members declared earlier in the structure, and pointers to array elements with larger subscript values compare greater than pointers to elements of the same array with lower subscript values. All pointers to members of the same union object compare equal. If the => expression P points to an element of an array object and the => expression Q points to the last element of the same array => object, the pointer expression Q+1 compares greater than P. In all other cases, the behavior is undefined. Well, strictly interpreting you may be right. However, this is irrelevant given that we assume a linear address space. I also doubt that C-89 has the same requirements and that is what we code for. Anyway, such an interpretation of the specs is similar to the rule that you can't clear a structure with pointer elements by using memset. Almost everyone is ignoring that and I don't want to get back to the time of segmented memory architectures. Shalom-Salam, Werner From wk at gnupg.org Fri Feb 2 10:14:16 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Feb 2007 10:14:16 +0100 Subject: Libgcrypt 1.2.4 released Message-ID: <87wt30syzb.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of Libgcrypt 1.2.4. Libgcrypt is a general purpose library of cryptographic building blocks. It is originally based on the code used in GnuPG. This is a bug fix release solving a few minor issues. There are no new features. If you experience problems with an application using libgcrypt, you might want to update to this version. Noteworthy changes are: * Fixed a bug in the memory allocator which could have been the reason for some non-duplicable bugs. * Other minor bug fixes. Source code is hosted at the GnuPG FTP server and its mirrors as listed at http://www.gnupg.org/download/mirrors.html . On the primary server the source files and there digital signatures are: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.4.tar.bz2 (781k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.4.tar.bz2.sig These files are bzip2 compressed. If you can't use the bunzip2 tool, gzip compressed versions of the files are also available: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.4.tar.gz (990k) ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.4.tar.gz.sig As an alternative a patch against version 1.2.3 is available as: ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.2.3-1.2.4.diff.bz2 (87k) SHA-1 checksums are: c72406c69d6ad9fb3fa1e9824b04566cf204093b libgcrypt-1.2.4.tar.bz2 d279e7a4464cccf0cc4e29c374a1e8325fc65b9a libgcrypt-1.2.4.tar.gz d4f5525fa26e92ade2914c6581435171f8b4fc44 libgcrypt-1.2.3-1.2.4.diff.bz2 For help on installing or developing with Libgcrypt you should send mail to the grcypt-devel mailing list. For details see http://www.gnupg.org/documentation/mailing-lists.html . Improving Libgcrypt is costly, but you can help! We are looking for organizations that find Libgcrypt useful and wish to contribute back. You can contribute by reporting bugs, improve the software [1], or by donating money. Commercial support contracts for Libgcrypt are available [2], and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by gpg's principal author, is currently funding Libgcrypt development. We are always looking for interesting development projects. Happy hacking, Werner [1] As a GNU project copyright assignments to the FSF are required. [2] See the service directory at http://www.gnupg.org/service.html . -- 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/20070202/6194bdae/attachment.pgp From bradh at frogmouth.net Fri Feb 2 11:03:55 2007 From: bradh at frogmouth.net (Brad Hards) Date: Fri, 2 Feb 2007 21:03:55 +1100 Subject: Libgcrypt 1.2.4 released In-Reply-To: <87wt30syzb.fsf@wheatstone.g10code.de> References: <87wt30syzb.fsf@wheatstone.g10code.de> Message-ID: <200702022104.02142.bradh@frogmouth.net> On Friday 02 February 2007 20:14, Werner Koch wrote: > This is a bug fix release solving a few minor issues. ?There are no > new features. ?If you experience problems with an application using > libgcrypt, you might want to update to this version. Are there plans for a 1.3 release at this stage? Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070202/ab69d600/attachment.pgp From wk at gnupg.org Fri Feb 2 12:53:22 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Feb 2007 12:53:22 +0100 Subject: Libgcrypt 1.2.4 released In-Reply-To: <200702022104.02142.bradh@frogmouth.net> (Brad Hards's message of "Fri\, 2 Feb 2007 21\:03\:55 +1100") References: <87wt30syzb.fsf@wheatstone.g10code.de> <200702022104.02142.bradh@frogmouth.net> Message-ID: <87wt30pyh9.fsf@wheatstone.g10code.de> On Fri, 2 Feb 2007 11:03, bradh at frogmouth.net said: > Are there plans for a 1.3 release at this stage? I agree that we should work on it. However, there are no concreate plans. Do you have immediate reason to require 1.3? Salam-Shalom, Werner From simon at josefsson.org Fri Feb 2 11:37:21 2007 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 02 Feb 2007 11:37:21 +0100 Subject: socklen problems with Libgcrypt 1.2.4 on mingw32 In-Reply-To: <87wt30syzb.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri\, 02 Feb 2007 10\:14\:16 +0100") References: <87wt30syzb.fsf@wheatstone.g10code.de> Message-ID: <87fy9o6e1q.fsf@latte.josefsson.org> Hi! Cross-compiling libgcrypt 1.2.4 to mingw32 fails: checking for socklen_t... yes ... make[2]: Entering directory `/home/jas/gnutls4win/build/libgcrypt-1.2.4/mpi' if /bin/sh ../libtool --tag=CC --mode=compile i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I../../../src/libgcrypt-1.2.4/mpi -I.. -I../../../src/libgcrypt-1.2.4/src -I/home/jas/gnutls4win/inst/include -g -O2 -Wall -MT mpi-add.lo -MD -MP -MF ".deps/mpi-add.Tpo" -c -o mpi-add.lo ../../../src/libgcrypt-1.2.4/mpi/mpi-add.c; \ then mv -f ".deps/mpi-add.Tpo" ".deps/mpi-add.Plo"; else rm -f ".deps/mpi-add.Tpo"; exit 1; fi i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I../../../src/libgcrypt-1.2.4/mpi -I.. -I../../../src/libgcrypt-1.2.4/src -I/home/jas/gnutls4win/inst/include -g -O2 -Wall -MT mpi-add.lo -MD -MP -MF .deps/mpi-add.Tpo -c ../../../src/libgcrypt-1.2.4/mpi/mpi-add.c -DDLL_EXPORT -DPIC -o .libs/mpi-add.o In file included from ../../../src/libgcrypt-1.2.4/src/g10lib.h:36, from ../../../src/libgcrypt-1.2.4/src/mpi.h:36, from ../../../src/libgcrypt-1.2.4/mpi/mpi-internal.h:52, from ../../../src/libgcrypt-1.2.4/mpi/mpi-add.c:31: ../../../src/libgcrypt-1.2.4/src/gcrypt.h:36: error: syntax error before "gcry_socklen_t" ../../../src/libgcrypt-1.2.4/src/gcrypt.h:36: warning: type defaults to `int' in declaration of `gcry_socklen_t' ../../../src/libgcrypt-1.2.4/src/gcrypt.h:36: warning: data definition has no type or storage class In file included from ../../../src/libgcrypt-1.2.4/src/g10lib.h:36, from ../../../src/libgcrypt-1.2.4/src/mpi.h:36, from ../../../src/libgcrypt-1.2.4/mpi/mpi-internal.h:52, from ../../../src/libgcrypt-1.2.4/mpi/mpi-add.c:31: ../../../src/libgcrypt-1.2.4/src/gcrypt.h:195: error: syntax error before "gcry_socklen_t" ../../../src/libgcrypt-1.2.4/src/gcrypt.h:196: error: syntax error before "gcry_socklen_t" make[2]: *** [mpi-add.lo] Error 1 The problem is that m4/socklen.m4 do some thing which gcrypt.h doesn't do, specifically: #elif HAVE_WS2TCPIP_H # include #endif])]) This patch for gcrypt.h fixes the problem for me: --- gcrypt.h~ 2007-02-02 11:11:11.000000000 +0100 +++ gcrypt.h 2007-02-02 11:22:55.000000000 +0100 @@ -1,6 +1,6 @@ /* gcrypt.h - GNU cryptographic library interface -*- c -*- * Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004 - * 2004, 2006 Free Software Foundation, Inc. + * 2004, 2006, 2007 Free Software Foundation, Inc. * * This file is part of Libgcrypt. * @@ -29,8 +29,10 @@ #include #include -#ifndef _WIN32 -#include +#if defined _WIN32 || defined __WIN32__ +# include +#else +# include #endif /*!_WIN32*/ typedef socklen_t gcry_socklen_t; The change of CPP's symbols was based on Bruno Haible's analysis of what WIN32 symbols are present on native/mingw32/cygwin, posted to the gnulib list some time ago. After fixing that, I get problems for src/secmem.c and src/ath.c: make[2]: Entering directory `/home/jas/gnutls4win/build/libgcrypt-1.2.4/src' if /bin/sh ../libtool --tag=CC --mode=compile i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I../../../src/libgcrypt-1.2.4/src -I.. -I/home/jas/gnutls4win/inst/include -g -O2 -Wall -MT libgcrypt_la-secmem.lo -MD -MP -MF ".deps/libgcrypt_la-secmem.Tpo" -c -o libgcrypt_la-secmem.lo `test -f 'secmem.c' || echo '../../../src/libgcrypt-1.2.4/src/'`secmem.c; \ then mv -f ".deps/libgcrypt_la-secmem.Tpo" ".deps/libgcrypt_la-secmem.Plo"; else rm -f ".deps/libgcrypt_la-secmem.Tpo"; exit 1; fi i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I. -I../../../src/libgcrypt-1.2.4/src -I.. -I/home/jas/gnutls4win/inst/include -g -O2 -Wall -MT libgcrypt_la-secmem.lo -MD -MP -MF .deps/libgcrypt_la-secmem.Tpo -c ../../../src/libgcrypt-1.2.4/src/secmem.c -DDLL_EXPORT -DPIC -o .libs/libgcrypt_la-secmem.o In file included from ../../../src/libgcrypt-1.2.4/src/secmem.c:40: ../../../src/libgcrypt-1.2.4/src/ath.h:83: error: syntax error before "socklen_t" ../../../src/libgcrypt-1.2.4/src/secmem.c: In function `init_pool': ../../../src/libgcrypt-1.2.4/src/secmem.c:340: warning: implicit declaration of function `getpagesize' make[2]: *** [libgcrypt_la-secmem.lo] Error 1 These patches seem to fix that: --- ath.c~ 2005-07-29 15:45:42.000000000 +0200 +++ ath.c 2007-02-02 11:27:26.000000000 +0100 @@ -1,5 +1,5 @@ /* ath.c - Thread-safeness library. - Copyright (C) 2002, 2003, 2004 g10 Code GmbH + Copyright (C) 2002, 2003, 2004, 2007 g10 Code GmbH This file is part of Libgcrypt. @@ -35,6 +35,7 @@ #endif #include +#include "g10lib.h" #include "ath.h" --- secmem.c~ 2007-02-01 19:04:30.000000000 +0100 +++ secmem.c 2007-02-02 11:28:31.000000000 +0100 @@ -1,6 +1,6 @@ /* secmem.c - memory allocation from a secure heap * Copyright (C) 1998, 1999, 2000, 2001, 2002, - * 2003 Free Software Foundation, Inc. + * 2003, 2007 Free Software Foundation, Inc. * * This file is part of Libgcrypt. * @@ -37,8 +37,8 @@ #endif #endif -#include "ath.h" #include "g10lib.h" +#include "ath.h" #include "secmem.h" #if defined (MAP_ANON) && ! defined (MAP_ANONYMOUS) With these changes, libgcrypt 1.2.4 build fine for me under mingw32. Thanks, Simon From wk at gnupg.org Fri Feb 2 13:31:40 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Feb 2007 13:31:40 +0100 Subject: socklen problems with Libgcrypt 1.2.4 on mingw32 In-Reply-To: <87fy9o6e1q.fsf@latte.josefsson.org> (Simon Josefsson's message of "Fri\, 02 Feb 2007 11\:37\:21 +0100") References: <87wt30syzb.fsf@wheatstone.g10code.de> <87fy9o6e1q.fsf@latte.josefsson.org> Message-ID: <878xfgpwpf.fsf@wheatstone.g10code.de> On Fri, 2 Feb 2007 11:37, simon at josefsson.org said: > Hi! Cross-compiling libgcrypt 1.2.4 to mingw32 fails: > > checking for socklen_t... yes Well the test has probably not been adjusted for cross-compiling. I'll take care of it. Shalom-Salam, Werner From wk at gnupg.org Fri Feb 2 13:36:32 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Feb 2007 13:36:32 +0100 Subject: socklen problems with Libgcrypt 1.2.4 on mingw32 In-Reply-To: <87fy9o6e1q.fsf@latte.josefsson.org> (Simon Josefsson's message of "Fri\, 02 Feb 2007 11\:37\:21 +0100") References: <87wt30syzb.fsf@wheatstone.g10code.de> <87fy9o6e1q.fsf@latte.josefsson.org> Message-ID: <874pq4pwhb.fsf@wheatstone.g10code.de> On Fri, 2 Feb 2007 11:37, simon at josefsson.org said: > Hi! Cross-compiling libgcrypt 1.2.4 to mingw32 fails: Have you tested your # socklen.m4 serial 4 for cross-compiling? Hmm, there seems to be a bug in it anyway: AC_CHECK_TYPE([socklen_t], , [AC_MSG_CHECKING([for socklen_t equivalent]) AC_CACHE_VAL([gl_cv_gl_cv_socklen_t_equiv], ^^^^^^^^^^^ [# Systems have either "struct sockaddr *" or # "void *" as the second argument to getpeername gl_cv_socklen_t_equiv= ^^^^^ Salam-Shalom, Werner From simon at josefsson.org Fri Feb 2 14:12:19 2007 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 02 Feb 2007 14:12:19 +0100 Subject: socklen problems with Libgcrypt 1.2.4 on mingw32 In-Reply-To: <874pq4pwhb.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri\, 02 Feb 2007 13\:36\:32 +0100") References: <87wt30syzb.fsf@wheatstone.g10code.de> <87fy9o6e1q.fsf@latte.josefsson.org> <874pq4pwhb.fsf@wheatstone.g10code.de> Message-ID: <87odocvh3g.fsf@latte.josefsson.org> Werner Koch writes: > On Fri, 2 Feb 2007 11:37, simon at josefsson.org said: > >> Hi! Cross-compiling libgcrypt 1.2.4 to mingw32 fails: > > Have you tested your > > # socklen.m4 serial 4 > > for cross-compiling? Yes. socklen_t exists on mingw32 if you include ws2tcpip.h. Code will have to include the same headers as the M4 test. > Hmm, there seems to be a bug in it anyway: > > AC_CHECK_TYPE([socklen_t], , > [AC_MSG_CHECKING([for socklen_t equivalent]) > AC_CACHE_VAL([gl_cv_gl_cv_socklen_t_equiv], > ^^^^^^^^^^^ > [# Systems have either "struct sockaddr *" or > # "void *" as the second argument to getpeername > gl_cv_socklen_t_equiv= > ^^^^^ Oops. I have fixed that in gnulib CVS, thanks! It didn't modify how the test worked, though, it only prevented caching from working. /Simon From wk at gnupg.org Fri Feb 2 16:16:07 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Feb 2007 16:16:07 +0100 Subject: [Announce] Libgcrypt 1.2.4 released In-Reply-To: <200702021545.43248.alon.barlev@gmail.com> (Alon Bar-Lev's message of "Fri\, 2 Feb 2007 15\:45\:43 +0200") References: <87wt30syzb.fsf@wheatstone.g10code.de> <200702021545.43248.alon.barlev@gmail.com> Message-ID: <87sldomvyg.fsf@wheatstone.g10code.de> On Fri, 2 Feb 2007 14:45, alon.barlev at gmail.com said: > I've sent you these in past, you did not include them. > The first one is for strict aliasing and the second one is for powerpc64. I fear that the ac functions have more problems than just that. Thus not included. I have not considered your patch because it had already been applied and I forgot to check 1.2. I just committed it to 1.2. There is another potential problem with netbsd and openbsd: powerpc*-*-netbsd* | powerpc*-*-openbsd*) echo '/* configured {Open,Net}BSD on powerpc */' >>./mpi/asm-syntax.h echo '#define ELF_SYNTAX' >>./mpi/asm-syntax.h cat $srcdir/mpi/powerpc32/syntax.h >>./mpi/asm-syntax.h mpi_sflags="-Wa,-mppc" path="powerpc32" ;; ppc620-*-* | \ powerpc64*-*-*) mpi_sflags="-Wa,-mppc" path="powerpc64" ;; If anyone with access to such a platform can tell how this needs to be configure, I will add it. Shalom-Salam, Werner From christianbiere at gmx.de Fri Feb 2 16:31:41 2007 From: christianbiere at gmx.de (Christian Biere) Date: Fri, 2 Feb 2007 16:31:41 +0100 Subject: [patch] bus error in gcry_free In-Reply-To: <8764alszuw.fsf@wheatstone.g10code.de> References: <87odoe2qdz.fsf@wheatstone.g10code.de> <20070201133419.GA298@cyclonus> <87sldpyle9.fsf@wheatstone.g10code.de> <20070201152411.GD298@cyclonus> <87fy9pyisr.fsf@wheatstone.g10code.de> <20070201193910.GA5210@cyclonus> <8764alszuw.fsf@wheatstone.g10code.de> Message-ID: <20070202153141.GA298@cyclonus> Werner Koch wrote: > 6.5.8 Relational operators > => expression P points to an element of an array object and the > => expression Q points to the last element of the same array > => object, the pointer expression Q+1 compares greater than P. > In all other cases, the behavior is undefined. > Well, strictly interpreting you may be right. However, this is > irrelevant given that we assume a linear address space. I also doubt > that C-89 has the same requirements and that is what we code for. GCC cannot be used as a strict C89 compiler and by default it assumes C99ish flavour. > Anyway, such an interpretation of the specs is similar to the rule > that you can't clear a structure with pointer elements by using > memset. Well, for float/double this isn't an esoteric issue at all. Also similar code can easily cause aliasing issues. I find it much cleaner to clear structures using struct copying using a static const variable. This will definitely do the right thing and isn't any more effort. Typically this happens in one or two places for each struct only anyway. > Almost everyone is ignoring that and I don't want to get > back to the time of segmented memory architectures. This has nothing to do with segmented memory. That's just one example to illustrate why such code might fail. The standard does not define this as "implementation-defined" in which case declaring platforms with segmented memory as unsupported would be fine. The standard say "undefined behavior" and that's emphasized by mentioning it. It would still be "undefined behavior" without the last sentence, as explained in some earlier section of the standard. In your case you might (still) be lucky because the compiler isn't sufficiently smart but since everything happens in a single file with static variables, it would be easy to prove that pool points to a memory object of pool_size bytes. For example, very similar checks definitely do not work at all with GCC 4.x: http://www.securityfocus.com/archive/1/431184/30/0/threaded Casting pointers to integers and vice-versa is implementation-defined and will typically do exactly what you expect. So if I wanted to use such checks at all, I'd certainly use size_t (or unsigned long) because arithmetic with unsigned integers is well-defined. -- Christian From alon.barlev at gmail.com Fri Feb 2 14:45:43 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Fri, 2 Feb 2007 15:45:43 +0200 Subject: [Announce] Libgcrypt 1.2.4 released In-Reply-To: <87wt30syzb.fsf@wheatstone.g10code.de> References: <87wt30syzb.fsf@wheatstone.g10code.de> Message-ID: <200702021545.43248.alon.barlev@gmail.com> On Friday 02 February 2007, Werner Koch wrote: > * Other minor bug fixes. Hello Werner, I've sent you these in past, you did not include them. The first one is for strict aliasing and the second one is for powerpc64. Best Regards, Alon Bar-Lev. diff -urNp libgcrypt-1.2.3.org/cipher/ac.c libgcrypt-1.2.3/cipher/ac.c --- libgcrypt-1.2.3.org/cipher/ac.c 2005-07-29 16:45:48.000000000 +0300 +++ libgcrypt-1.2.3/cipher/ac.c 2007-01-10 22:13:05.000000000 +0200 @@ -137,9 +137,11 @@ gcry_ac_data_copy_internal (gcry_ac_data data_new->data_n = data->data_n; if (! err) - /* Allocate space for named MPIs. */ - err = _gcry_malloc (sizeof (gcry_ac_mpi_t) * data->data_n, 0, - (void **) &data_new->data); + { + /* Allocate space for named MPIs. */ + err = _gcry_malloc (sizeof (gcry_ac_mpi_t) * data->data_n, 0, &p); + data_new->data = (gcry_ac_mpi_t *)p; + } if (! err) { --- mpi/config.links.orig 2005-11-25 21:37:25.000000000 -0600 +++ mpi/config.links 2005-11-25 21:39:37.000000000 -0600 @@ -221,6 +221,11 @@ path="m68k/mc68020 m68k" ;; + powerpc64*-*-linux*) + mpi_sflags="-Wa,-mppc" + path="powerpc64" + ;; + powerpc*-*-linux*) echo '/* configured for powerpc/ELF */' >>./mpi/asm-syntax.h echo '#define ELF_SYNTAX' >>./mpi/asm-syntax.h From wk at gnupg.org Fri Feb 2 18:43:38 2007 From: wk at gnupg.org (Werner Koch) Date: Fri, 02 Feb 2007 18:43:38 +0100 Subject: [patch] bus error in gcry_free In-Reply-To: <20070202153141.GA298@cyclonus> (Christian Biere's message of "Fri\, 2 Feb 2007 16\:31\:41 +0100") References: <87odoe2qdz.fsf@wheatstone.g10code.de> <20070201133419.GA298@cyclonus> <87sldpyle9.fsf@wheatstone.g10code.de> <20070201152411.GD298@cyclonus> <87fy9pyisr.fsf@wheatstone.g10code.de> <20070201193910.GA5210@cyclonus> <8764alszuw.fsf@wheatstone.g10code.de> <20070202153141.GA298@cyclonus> Message-ID: <87d54slak5.fsf@wheatstone.g10code.de> On Fri, 2 Feb 2007 16:31, christianbiere at gmx.de said: > can easily cause aliasing issues. I find it much cleaner to clear structures > using struct copying using a static const variable. This will definitely do the > right thing and isn't any more effort. Typically this happens in one or two > places for each struct only anyway. This break a bunch of code, be it calloc or memset cleared structs. But I have other things to do than to nitpicking on this. > This has nothing to do with segmented memory. That's just one example to Yes sure. The first premises is to make the code secure and mostly bug free. Over-optimization of modern compilers makes this even harder. > "implementation-defined" in which case declaring platforms with segmented > memory as unsupported would be fine. The standard say "undefined behavior" and > that's emphasized by mentioning it. It would still be "undefined behavior" Okay, granted. > Casting pointers to integers and vice-versa is implementation-defined and will > typically do exactly what you expect. So if I wanted to use such checks at all, > I'd certainly use size_t (or unsigned long) because arithmetic with unsigned > integers is well-defined. So we end up with this: size_t p_addr = (size_t)p; size_t pool_addr = (size_t)pool; return (pool_okay && p_addr >= pool_addr && p_addr < pool_addr+pool_size); Thanks, Werner From bradh at frogmouth.net Fri Feb 2 22:47:51 2007 From: bradh at frogmouth.net (Brad Hards) Date: Sat, 3 Feb 2007 08:47:51 +1100 Subject: Libgcrypt 1.2.4 released In-Reply-To: <87wt30pyh9.fsf@wheatstone.g10code.de> References: <87wt30syzb.fsf@wheatstone.g10code.de> <200702022104.02142.bradh@frogmouth.net> <87wt30pyh9.fsf@wheatstone.g10code.de> Message-ID: <200702030847.58349.bradh@frogmouth.net> On Friday 02 February 2007 22:53, Werner Koch wrote: > On Fri, 2 Feb 2007 11:03, bradh at frogmouth.net said: > > Are there plans for a 1.3 release at this stage? > > I agree that we should work on it. However, there are no concreate > plans. Do you have immediate reason to require 1.3? No immediate reason. However there are a couple of newer features (e.g. the OFB mode for encryption) that are only in trunk, and I'm more interested in a rough timeline (weeks/months/years is enough granularity) for release. Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : /pipermail/attachments/20070203/fdc2b658/attachment.pgp From wk at gnupg.org Sun Feb 4 13:43:53 2007 From: wk at gnupg.org (Werner Koch) Date: Sun, 04 Feb 2007 13:43:53 +0100 Subject: Libgcrypt 1.2.4 released In-Reply-To: <200702030847.58349.bradh@frogmouth.net> (Brad Hards's message of "Sat\, 3 Feb 2007 08\:47\:51 +1100") References: <87wt30syzb.fsf@wheatstone.g10code.de> <200702022104.02142.bradh@frogmouth.net> <87wt30pyh9.fsf@wheatstone.g10code.de> <200702030847.58349.bradh@frogmouth.net> Message-ID: <87r6t6w0s6.fsf@wheatstone.g10code.de> On Fri, 2 Feb 2007 22:47, bradh at frogmouth.net said: > No immediate reason. However there are a couple of newer features (e.g. the > OFB mode for encryption) that are only in trunk, and I'm more interested in a > rough timeline (weeks/months/years is enough granularity) for release. I see. What we need to do before a release is: * Fix the signed/unsigned pointer mismatches as already done in 1.2. * Checking that all changes in 1.2 have also be applied to 1.3. Due to private reasons Moritz has had not the time to keep them in sync and I am not 100% sure that completly kept of with it. It is amgtter of checking the Chnagelogs. * Then the experimental random daemon needs to be clearly marked as experimental. * Werner Dittman wrote new .S code for AMD64, however we are waiting on the FSF folks to complete the legal papers. * Make sure that it also works under Windows. So, it is only a matter of a few days work. Lets say we do a release by end of March. Salam-Shalom, Werner From ametzler at downhill.at.eu.org Sun Feb 11 13:31:07 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 11 Feb 2007 13:31:07 +0100 Subject: [trivial patch] pkg-config support for libgcrypt Message-ID: <20070211123107.GB3717@downhill.g.la> Hello, attached you can find a quite trivial patch for adding pkg-config support to gcrypt. It is based on gnutls' pkg-config support (which explains the copyright statement in the pc file). (SID)ametzler at argenau:$ pkg-config --libs libgcrypt -lgcrypt (SID)ametzler at argenau:$ pkg-config --libs libgcrypt --static -lgcrypt -lgpg-error (SID)ametzler at argenau:$ pkg-config --variable=digests libgcrypt crc md4 md5 rmd160 sha1 sha256 sha512 tiger thanks, cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -------------- next part -------------- A non-text attachment was scrubbed... Name: newlyadded.diff Type: text/x-diff Size: 2230 bytes Desc: not available Url : /pipermail/attachments/20070211/62652097/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : /pipermail/attachments/20070211/62652097/attachment.pgp From ametzler at downhill.at.eu.org Sun Feb 11 13:59:47 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 11 Feb 2007 13:59:47 +0100 Subject: gcrypt.h uses malloc without including stdlib.h Message-ID: <3jg3a4-h3b.ln1@argenau.downhill.at.eu.org> Hello, gcry_pth_init defined in gcrypt.h invokes malloc without #include . Is this done by purpose and should every program using threading include the header or should gcrypt.h be changed? cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From wk at gnupg.org Mon Feb 12 14:06:50 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Feb 2007 14:06:50 +0100 Subject: [trivial patch] pkg-config support for libgcrypt In-Reply-To: <20070211123107.GB3717@downhill.g.la> (Andreas Metzler's message of "Sun\, 11 Feb 2007 13\:31\:07 +0100") References: <20070211123107.GB3717@downhill.g.la> Message-ID: <87zm7j7cet.fsf@wheatstone.g10code.de> On Sun, 11 Feb 2007 13:31, ametzler at downhill.at.eu.org said: > attached you can find a quite trivial patch for adding pkg-config > support to gcrypt. It is based on gnutls' pkg-config support (which I don't like pkg-config becuase it does not allow for proper cross-compilation for Windows. I don't want to maintain a second tool to get the configuration. I know that you would like this to overcome debian's problems with libgpg-error dependencies. However, that is too distribution specific. Salam-Shalom, Werner From wk at gnupg.org Mon Feb 12 14:08:18 2007 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Feb 2007 14:08:18 +0100 Subject: gcrypt.h uses malloc without including stdlib.h In-Reply-To: <3jg3a4-h3b.ln1@argenau.downhill.at.eu.org> (Andreas Metzler's message of "Sun\, 11 Feb 2007 13\:59\:47 +0100") References: <3jg3a4-h3b.ln1@argenau.downhill.at.eu.org> Message-ID: <87vei77ccd.fsf@wheatstone.g10code.de> On Sun, 11 Feb 2007 13:59, ametzler at downhill.at.eu.org said: > gcry_pth_init defined in gcrypt.h invokes malloc without > #include . Is this done by purpose and should every program > using threading include the header or should gcrypt.h be changed? I always include stdlib.h so thatproblem never hit me. No problem to change gcrypt.h. Will do so. Shalom-Salam, Werner From ametzler at downhill.at.eu.org Mon Feb 12 19:12:47 2007 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon, 12 Feb 2007 19:12:47 +0100 Subject: gcrypt.h uses malloc without including stdlib.h In-Reply-To: <87vei77ccd.fsf@wheatstone.g10code.de> References: <3jg3a4-h3b.ln1@argenau.downhill.at.eu.org> <87vei77ccd.fsf@wheatstone.g10code.de> Message-ID: <20070212181247.GA4474@downhill.g.la> On 2007-02-12 Werner Koch wrote: > On Sun, 11 Feb 2007 13:59, ametzler at downhill.at.eu.org said: >> gcry_pth_init defined in gcrypt.h invokes malloc without >> #include . Is this done by purpose and should every program >> using threading include the header or should gcrypt.h be changed? > I always include stdlib.h so thatproblem never hit me. An example program in gnutls' docs triggered the problem. ;-) > No problem to change gcrypt.h. Will do so. Thanks. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'