From mrsam at courier-mta.com Mon Sep 1 00:42:53 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 31 Aug 2008 18:42:53 -0400 Subject: _list() and _id() functions not implemented for gnutls_pk_algorithm_t and gnutls_sign_algorithm_t Message-ID: There are various list functions in the API -- gnutls_cipher_list(), gnutls_mac_list(), and others -- that enumerate all known corresponding algorithm/codes. The API also provides corresponding *_get_id() and *_get_name() functions that map between the identifiers and their names. For gnutls_pk_algorithm_t and gnutls_sign_algorithm_t, I find only the *_get_name() functions. There is no _list() or _id() function available. It would be rather nice to have them defined, as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From nmav at gnutls.org Mon Sep 1 07:48:34 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 01 Sep 2008 08:48:34 +0300 Subject: [PATCH] Document all gnutls-cli options in the manpage In-Reply-To: <1220027148.8580.49.camel@flash> References: <1220027148.8580.49.camel@flash> Message-ID: <48BB8232.4050802@gnutls.org> James Westby wrote: > Hi, > > In response to > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492775 > > I went though and added all the missing options from gnutls-cli's > manpage, removing --xml along the way. > > Please find attached the resulting diff. Thank you, applied! regards, Nikos From simon at josefsson.org Mon Sep 1 18:59:46 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 01 Sep 2008 18:59:46 +0200 Subject: GNU extensions to read_s2k for GnuTLS 2.4.x In-Reply-To: <87d4k1m5io.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 22 Aug 2008 11:30:23 -0400") References: <87zlng2vg6.fsf@squeak.fifthhorseman.net> <873al8j9fu.fsf@mocca.josefsson.org> <87r68rhz42.fsf@squeak.fifthhorseman.net> <87iqttpr6k.fsf_-_@squeak.fifthhorseman.net> <87hc9do8si.fsf_-_@squeak.fifthhorseman.net> <87zln5usk0.fsf@mocca.josefsson.org> <87d4k1m5io.fsf@squeak.fifthhorseman.net> Message-ID: <871w036bul.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > On Fri 2008-08-22 08:45:35 -0400, Simon Josefsson wrote: > >> Daniel, it would be excellent if you could implement a small self-test >> of the functionality using that dummy private key, to be placed in >> tests/. It should use the public gnutls interfaces, not the direct >> opencdk interfaces. For inspiration, look at for example >> tests/certificate_set_x509_crl.c. > > Attached is such a test. On a system running 2.4.1 without the > patches, it gives me rc -59 on the gnutls_openpgp_privkey_import. > With a patched GnuTLS, it exits cleanly: > > 0 vulcan:~# ./openpgp_gnu-dummy_extension > gnutls_openpgp_privkey_import rc -59: GnuTLS internal error. > 1 vulcan:~# dpkg --install ~dkg/src/gnutls/tmp.rLUgIlxWJV/libgnutls26_2.4.1-1.s2kext1_amd64.deb > (Reading database ... 22502 files and directories currently installed.) > Preparing to replace libgnutls26 2.4.1-1 (using .../libgnutls26_2.4.1-1.s2kext1_amd64.deb) ... > Unpacking replacement libgnutls26 ... > Setting up libgnutls26 (2.4.1-1.s2kext1) ... > 0 vulcan:~# ./openpgp_gnu-dummy_extension > 0 vulcan:~# > > I see no reason why the same shouldn't be a valid test for the 2.5.x > series. Neat! Please push it. > There are too many Makefiles in my git tests/ directory (and i assume > that some of them are generated from others -- why are they all in the > git repo? i'm confused.) for me to know where/how to properly include > this in the actual tests that get run. I'll watch the git repo > changes to see how it's done if this gets added for future reference, > though. The Makefile's are not stored in git, they are generated by autoconf/automake. To add a new self-test, you only modify tests/Makefile.am. Add the name of your self test next to the others. And a NEWS entry. :) Btw, please chose a shorter filename for the tests, like pgps2kgnu.c instead. Thanks, Simon From simon at josefsson.org Tue Sep 2 10:41:46 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 02 Sep 2008 10:41:46 +0200 Subject: Gnutls Build Error In-Reply-To: <20080901204500.GA20465@charter.net> (Dave Uhring's message of "Mon, 1 Sep 2008 15:45:00 -0500") References: <20080901204500.GA20465@charter.net> Message-ID: <87d4jn3po5.fsf@mocca.josefsson.org> Dave Uhring writes: > System: Solaris Express b96 on amd64 x2 4800+ > Compiler: Sun Studio 12 > Configuration: duhring at dirac:~/gnutls-2.4.1$ ./configure --prefix=/usr --disable-nls --disable-rpath --disable-camellia --enable-random-device=/dev/random --with-libiconv-prefix=/usr/gnu --without-libintl-prefix --with-included-libtasn1 --with-included-libcfg --with-libz-prefix=/usr --with-lzo --with-libreadline-prefix=/usr/gnu --with-libgcrypt --with-libgcrypt-prefix=/usr > > Compiler reports the following error not seen in gnutls-2.2.5, same system, > same compiler: > > /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/usr/share/locale\" -I../lgl -I../lgl -I../includes -I../includes -I./x509 -I../libextra -I../lib/openpgp/ -I./opencdk -I../lib/opencdk -I./minitasn1 -I/usr/gnu/include -xO3 -m32 -xarch=native -c gnutls_cipher_int.c -KPIC -DPIC -o .libs/gnutls_cipher_int.o > "gnutls_cipher_int.c", line 108: warning: argument #3 is incompatible with prototype: > prototype: pointer to const char : "../lgl/gc.h", line 123 > argument : const pointer to unsigned char > "gnutls_cipher_int.c", line 110: warning: argument #3 is incompatible with prototype: > prototype: pointer to const char : "../lgl/gc.h", line 125 > argument : const pointer to unsigned char > "gnutls_cipher_int.c", line 177: void function cannot return value > cc: acomp failed for gnutls_cipher_int.c > *** Error code 1 > make: Fatal error: Command failed for target `gnutls_cipher_int.lo' > Current working directory /export/home/duhring/gnutls-2.4.1/lib > *** Error code 1 > > Is a void function really supposed to return a value? No. Thanks for the report. I have applied the patch below. If you apply it, does the rest of GnuTLS 2.4.1 build? If anyone knows how to get gcc to warn about constructs like the one below, that would help to catch similar problems in the future. I have enabled a lot of warnings in the current gnutls dev branch (in fact all of the warnings in the GCC-4.3 manual except those that generate too many warnings, see comments in configure.in), but I don't get a warning on this (the deinit function called return a void value): void _gnutls_cipher_deinit (cipher_hd_st * handle) { if (handle != NULL) { if (handle->registered && handle->hd.rh.ctx != NULL) { return handle->hd.rh.cc->deinit (handle->hd.rh.ctx); } _gnutls_cipher_ops.deinit (handle->hd.gc); } } Thanks, /Simon >From fd702bc2d625ebc02cb15240ac05aadf9f424093 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Tue, 2 Sep 2008 10:26:13 +0200 Subject: [PATCH] Don't return from a void function. Reported by Dave Uhring . --- lib/gnutls_cipher_int.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/gnutls_cipher_int.c b/lib/gnutls_cipher_int.c index badb074..e8f7df7 100644 --- a/lib/gnutls_cipher_int.c +++ b/lib/gnutls_cipher_int.c @@ -42,7 +42,7 @@ _gnutls_cipher_init (cipher_hd_st * handle, gnutls_cipher_algorithm_t cipher, int ret = GNUTLS_E_INTERNAL_ERROR; gnutls_crypto_single_cipher_st *cc = NULL; - /* check if a cipher has been registered + /* check if a cipher has been registered */ cc = _gnutls_get_crypto_cipher (cipher); if (cc != NULL) @@ -140,7 +140,8 @@ _gnutls_cipher_deinit (cipher_hd_st * handle) { if (handle->registered && handle->hd.rh.ctx != NULL) { - return handle->hd.rh.cc->deinit (handle->hd.rh.ctx); + handle->hd.rh.cc->deinit (handle->hd.rh.ctx); + return; } _gnutls_cipher_ops.deinit (handle->hd.gc); } -- 1.5.6.3 From simon at josefsson.org Tue Sep 2 13:18:56 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 02 Sep 2008 13:18:56 +0200 Subject: Gnutls Build Error In-Reply-To: <87d4jn3po5.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 02 Sep 2008 10:41:46 +0200") References: <20080901204500.GA20465@charter.net> <87d4jn3po5.fsf@mocca.josefsson.org> Message-ID: <87hc8yn6cf.fsf@mocca.josefsson.org> I posted the patch against 2.5.x. The following should work against 2.4.1. /Simon >From ccfc7155f6ee1c21d56073ba3d114b55fa8cdad0 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Tue, 2 Sep 2008 10:26:13 +0200 Subject: [PATCH] Don't return from a void function. Reported by Dave Uhring . --- lib/gnutls_cipher_int.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/lib/gnutls_cipher_int.c b/lib/gnutls_cipher_int.c index a7b50b9..b9cc304 100644 --- a/lib/gnutls_cipher_int.c +++ b/lib/gnutls_cipher_int.c @@ -173,8 +173,11 @@ _gnutls_cipher_deinit (cipher_hd_st* handle) { if (handle != NULL) { - if (handle->registered && handle->hd.rh.ctx != NULL) { - return handle->hd.rh.cc->deinit( handle->hd.rh.ctx); + if (handle->registered && handle->hd.rh.ctx != NULL) + { + handle->hd.rh.cc->deinit( handle->hd.rh.ctx); + return; + } } gc_cipher_close (handle->hd.gc); } -- 1.5.6.3 From simon at josefsson.org Mon Sep 8 15:30:47 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 08 Sep 2008 15:30:47 +0200 Subject: GnuTLS 2.5.6, second release candidate for 2.6.0 Message-ID: <87ej3uwyrc.fsf@mocca.josefsson.org> The GnuTLS 2.5.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. No serious issues were brought up for 2.5.5, so let's set a goal date for the 2.6.0 stable release: 1 October. This is the second release candidate. Test it as if it were a new stable release! Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.6.tar.bz2 (4.9MB) ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.6.tar.bz2 Here is the OpenPGP signature: http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.6.tar.bz2.sig ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.6.tar.bz2.sig Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. /Simon * Version 2.5.6 (released 2008-09-08) ** libgnutls: Add interface to deal with public key and signature algorithms. The functions are called gnutls_pk_list, gnutls_pk_get_id, gnutls_sign_list, and gnutls_sign_get_id. Suggested by Sam Varshavchik . ** libgnutls: Refactor and clean up some code. ** libgnutls: Fix compile error with Sun CC. ** gnutls-cli: Improve --list output to include public key and signature algs. ** gnutls-cli, gnutls-serv: Remove --copyright parameter. Use standard --version to get license info. ** gnutls-cli.1: Document all new parameters. Thanks to James Westby . ** API and ABI modifications: gnutls_pk_list: ADDED gnutls_pk_get_id: ADDED gnutls_sign_list: ADDED gnutls_sign_get_id: ADDED From simon at josefsson.org Tue Sep 9 14:30:48 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 09 Sep 2008 14:30:48 +0200 Subject: Using LGPLv3+ license for libgnutls? Message-ID: <87y721pklj.fsf@mocca.josefsson.org> RMS asked if there are is reason GnuTLS should remain LGPLv2.1+ instead of using LGPLv3+. The reasons I'm familiar with includes lynx under GPLv2-only. Gnucash is also said to contain GPLv2-only code. Are there other reasons not to use LGPLv3+? I recall hearing about policies that mandate LGPLv2.1+ in some projects, for example the core libraries in GNOME, but I cannot find any reference to this out there. Anyone? /Simon From ludo at gnu.org Tue Sep 9 16:30:59 2008 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Tue, 09 Sep 2008 16:30:59 +0200 Subject: GnuTLS 2.4.1 with libgcrypt 1.4.2 Message-ID: <87vdx5z90c.fsf@gnu.org> Hello, GnuTLS 2.4.1's `openssl' test fails with libgcrypt 1.4.2: Program received signal SIGSEGV, Segmentation fault. gc_hash_write (handle=0x0, len=3, data=0x8049042 "abc") at gc-libgcrypt.c:431 431 if (ctx->alg == GC_MD2) (gdb) bt #0 gc_hash_write (handle=0x0, len=3, data=0x8049042 "abc") at gc-libgcrypt.c:431 #1 0xb7ef474d in MD5_Update (ctx=0xbff38988, buf=0x8049042, len=3) at gnutls_openssl.c:1011 #2 0x080489c7 in doit () at openssl.c:43 #3 0x08048b25 in main (argc=1, argv=0xbff38a84) at utils.c:148 The root of the problem is this: (gdb) p gc_hash_open (GC_MD5, 0, &ctx->handle) $3 = GC_INVALID_HASH ... despite the fact that `libgcrypt-config --algorithms' does list MD5. Any idea? Thanks, Ludo'. From joe at manyfish.co.uk Tue Sep 9 17:37:08 2008 From: joe at manyfish.co.uk (Joe Orton) Date: Tue, 9 Sep 2008 16:37:08 +0100 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <87y721pklj.fsf@mocca.josefsson.org> References: <87y721pklj.fsf@mocca.josefsson.org> Message-ID: <20080909153708.GD14713@manyfish.co.uk> On Tue, Sep 09, 2008 at 02:30:48PM +0200, Simon Josefsson wrote: > RMS asked if there are is reason GnuTLS should remain LGPLv2.1+ instead > of using LGPLv3+. > > The reasons I'm familiar with includes lynx under GPLv2-only. Gnucash > is also said to contain GPLv2-only code. > > Are there other reasons not to use LGPLv3+? Here's a list of packages from Fedora Raw Hide which link against GnuTLS and have license tags indicating GPLv2-only licensing: aria2-0.12.0-5.fc10.src.rpm - GPLv2 climm-0.6.3-1.fc10.src.rpm - GPLv2 cups-1.3.8-5.fc10.src.rpm - GPLv2 ekg2-0.2-0.4.rc1.fc10.src.rpm - GPLv2 gobby-0.4.6-1.fc10.src.rpm - GPLv2 hardinfo-0.4.2.3-6.fc10.src.rpm - GPLv2 jd-2.0.1-0.2.beta080901.fc10.src.rpm - GPLv2 snort-2.8.1-5.fc10.src.rpm - GPLv2 sobby-0.4.4-5.fc10.src.rpm - GPLv2 xfce4-mailwatch-plugin-1.0.1-10.fc10.src.rpm - GPLv2 (Note that this list is not necessarily complete since it won't include packages which have not yet had their License tags audited.) Regards, Joe From simon at josefsson.org Tue Sep 9 18:01:23 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 09 Sep 2008 18:01:23 +0200 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <20080909153708.GD14713@manyfish.co.uk> (Joe Orton's message of "Tue, 9 Sep 2008 16:37:08 +0100") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> Message-ID: <87y721nwa4.fsf@mocca.josefsson.org> Joe Orton writes: > On Tue, Sep 09, 2008 at 02:30:48PM +0200, Simon Josefsson wrote: >> RMS asked if there are is reason GnuTLS should remain LGPLv2.1+ instead >> of using LGPLv3+. >> >> The reasons I'm familiar with includes lynx under GPLv2-only. Gnucash >> is also said to contain GPLv2-only code. >> >> Are there other reasons not to use LGPLv3+? > > Here's a list of packages from Fedora Raw Hide which link against GnuTLS > and have license tags indicating GPLv2-only licensing: > > aria2-0.12.0-5.fc10.src.rpm - GPLv2 > climm-0.6.3-1.fc10.src.rpm - GPLv2 > cups-1.3.8-5.fc10.src.rpm - GPLv2 > ekg2-0.2-0.4.rc1.fc10.src.rpm - GPLv2 > gobby-0.4.6-1.fc10.src.rpm - GPLv2 > hardinfo-0.4.2.3-6.fc10.src.rpm - GPLv2 > jd-2.0.1-0.2.beta080901.fc10.src.rpm - GPLv2 > snort-2.8.1-5.fc10.src.rpm - GPLv2 > sobby-0.4.4-5.fc10.src.rpm - GPLv2 > xfce4-mailwatch-plugin-1.0.1-10.fc10.src.rpm - GPLv2 > > (Note that this list is not necessarily complete since it won't include > packages which have not yet had their License tags audited.) Thanks for the list! I tried to do some systematic searches, but the debian copyright information tends to be incorrect (not mentioning versions) or difficult to parse. I recognize cups, snort and ekg, and they are fairly well known. /Simon From simon at josefsson.org Tue Sep 9 18:29:27 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 09 Sep 2008 18:29:27 +0200 Subject: GnuTLS 2.4.1 with libgcrypt 1.4.2 In-Reply-To: <87vdx5z90c.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Tue, 09 Sep 2008 16:30:59 +0200") References: <87vdx5z90c.fsf@gnu.org> Message-ID: <87hc8pnuzc.fsf@mocca.josefsson.org> ludo at gnu.org (Ludovic Court?s) writes: > Hello, > > GnuTLS 2.4.1's `openssl' test fails with libgcrypt 1.4.2: > > Program received signal SIGSEGV, Segmentation fault. > gc_hash_write (handle=0x0, len=3, data=0x8049042 "abc") at gc-libgcrypt.c:431 > 431 if (ctx->alg == GC_MD2) > (gdb) bt > #0 gc_hash_write (handle=0x0, len=3, data=0x8049042 "abc") at gc-libgcrypt.c:431 > #1 0xb7ef474d in MD5_Update (ctx=0xbff38988, buf=0x8049042, len=3) at gnutls_openssl.c:1011 > #2 0x080489c7 in doit () at openssl.c:43 > #3 0x08048b25 in main (argc=1, argv=0xbff38a84) at utils.c:148 > > The root of the problem is this: > > (gdb) p gc_hash_open (GC_MD5, 0, &ctx->handle) > $3 = GC_INVALID_HASH > > ... despite the fact that `libgcrypt-config --algorithms' does list MD5. > > Any idea? It is a bug in the openssl example, fixed in: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=9a8474986d53be944b0f91b10199c5986a43069f I'm backporting it to 2.4.x now, thanks for testing. I think we need to do a 2.4.2... /Simon From dkg at fifthhorseman.net Tue Sep 9 19:46:17 2008 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 09 Sep 2008 13:46:17 -0400 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <87y721nwa4.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue\, 09 Sep 2008 18\:01\:23 +0200") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> Message-ID: <87sks98b6e.fsf@squeak.fifthhorseman.net> On Tue 2008-09-09 12:01:23 -0400, Simon Josefsson wrote: > I tried to do some systematic searches, but the debian copyright > information tends to be incorrect (not mentioning versions) or difficult > to parse. This is sadly true. Automatic resolution of this sort of question would be much easier if the machine-readable debian/copyright proposal was more widely-adopted: http://wiki.debian.org/Proposals/CopyrightFormat > I recognize cups, snort and ekg, and they are fairly well known. fwiw, gobby seems to be GPL-2+, not GPL-2, at least according to the debian copyright info, so it's possilbe that the fedora tags are wrong on that package: [0 dkg at squeak ~]$ grep -A5 ^License: /usr/share/doc/libobby-0.4-1/copyright License: This library is written by the 0x539 dev group and is licensed under the GNU General Public License (GPL) version 2 or any later version. A copy of the license is included in the distribution. [0 dkg at squeak ~]$ And cups appears to be ambiguous as far as the GPL'ed bits (though the LGPL'ed bits are pretty clearly V2-only): [0 dkg at squeak ~]$ grep -A6 ^INTRODUCTION /usr/share/doc/cups-common/copyright INTRODUCTION The Common UNIX Printing System(tm), ("CUPS(tm)"), is provided under the GNU General Public License ("GPL") and GNU Library General Public License ("LGPL"), Version 2, with exceptions for Apple operating systems and the OpenSSL toolkit. A copy of the exceptions and licenses follow this introduction. [0 dkg at squeak ~]$ I couldn't come up with an automated way to pull the answers to these questions out of debian automatically either :( --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From ludo at gnu.org Tue Sep 9 22:18:15 2008 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Tue, 09 Sep 2008 22:18:15 +0200 Subject: GnuTLS 2.4.1 with libgcrypt 1.4.2 References: <87vdx5z90c.fsf@gnu.org> <87hc8pnuzc.fsf@mocca.josefsson.org> Message-ID: <87y721axa0.fsf@gnu.org> Hi Simon, Simon Josefsson writes: > It is a bug in the openssl example, fixed in: > > http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=9a8474986d53be944b0f91b10199c5986a43069f It does fix the problem, thanks! > I'm backporting it to 2.4.x now, thanks for testing. I think we need to > do a 2.4.2... Perhaps, yes. Thanks, Ludo'. From joe at manyfish.co.uk Tue Sep 9 22:59:51 2008 From: joe at manyfish.co.uk (Joe Orton) Date: Tue, 9 Sep 2008 21:59:51 +0100 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <87sks98b6e.fsf@squeak.fifthhorseman.net> References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> Message-ID: <20080909205951.GA18961@manyfish.co.uk> On Tue, Sep 09, 2008 at 01:46:17PM -0400, Daniel Kahn Gillmor wrote: > On Tue 2008-09-09 12:01:23 -0400, Simon Josefsson wrote: > > > I tried to do some systematic searches, but the debian copyright > > information tends to be incorrect (not mentioning versions) or difficult > > to parse. > > This is sadly true. Automatic resolution of this sort of question > would be much easier if the machine-readable debian/copyright proposal > was more widely-adopted: > > http://wiki.debian.org/Proposals/CopyrightFormat We have such a standard agreed at Fedora but the hard work is really in auditing N thousand packages to meet it. > > I recognize cups, snort and ekg, and they are fairly well known. > > fwiw, gobby seems to be GPL-2+, not GPL-2, at least according to the > debian copyright info, so it's possilbe that the fedora tags are wrong > on that package: I agree, good catch, thanks; I've filed a bug to get this fixed in Fedora. > And cups appears to be ambiguous as far as the GPL'ed bits (though the > LGPL'ed bits are pretty clearly V2-only): > > [0 dkg at squeak ~]$ grep -A6 ^INTRODUCTION /usr/share/doc/cups-common/copyright > INTRODUCTION > > The Common UNIX Printing System(tm), ("CUPS(tm)"), is provided > under the GNU General Public License ("GPL") and GNU Library > General Public License ("LGPL"), Version 2, with exceptions for > Apple operating systems and the OpenSSL toolkit. A copy of the > exceptions and licenses follow this introduction. Following the guidance at http://fedoraproject.org/wiki/Licensing/FAQ I would say that since the code is explicit about being licensed per the terms in LICENSE.txt, "GPLv2 only" is a reasonable interpretation. If anybody thinks this is important to clarify I can chase it with the Fedora licensing guys. Regards, Joe From davefx at gmail.com Wed Sep 10 07:59:36 2008 From: davefx at gmail.com (=?UTF-8?Q?David_Mar=C3=ADn_Carre=C3=B1o?=) Date: Wed, 10 Sep 2008 07:59:36 +0200 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <20080909205951.GA18961@manyfish.co.uk> References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> Message-ID: But I don't catch what is the problem: a proprietary licensed product can be dinamically linked to a LGPL3 library. And, as far as I know (and, please, correct me if I am wrong, as I am not a lawyer), a GPL2 product can still be dinamically (or even statically) linked with a LGPL3 library. We are not talking about GPLv3. It's LGPLv3. Perhaps, the problem would be the GPL'd parts of gnutls... -- David Mar?n Carre?o 2008/9/9 Joe Orton : > On Tue, Sep 09, 2008 at 01:46:17PM -0400, Daniel Kahn Gillmor wrote: >> On Tue 2008-09-09 12:01:23 -0400, Simon Josefsson wrote: >> >> > I tried to do some systematic searches, but the debian copyright >> > information tends to be incorrect (not mentioning versions) or difficult >> > to parse. >> >> This is sadly true. Automatic resolution of this sort of question >> would be much easier if the machine-readable debian/copyright proposal >> was more widely-adopted: >> >> http://wiki.debian.org/Proposals/CopyrightFormat > > We have such a standard agreed at Fedora but the hard work is really in > auditing N thousand packages to meet it. > >> > I recognize cups, snort and ekg, and they are fairly well known. >> >> fwiw, gobby seems to be GPL-2+, not GPL-2, at least according to the >> debian copyright info, so it's possilbe that the fedora tags are wrong >> on that package: > > I agree, good catch, thanks; I've filed a bug to get this fixed in > Fedora. > >> And cups appears to be ambiguous as far as the GPL'ed bits (though the >> LGPL'ed bits are pretty clearly V2-only): >> >> [0 dkg at squeak ~]$ grep -A6 ^INTRODUCTION /usr/share/doc/cups-common/copyright >> INTRODUCTION >> >> The Common UNIX Printing System(tm), ("CUPS(tm)"), is provided >> under the GNU General Public License ("GPL") and GNU Library >> General Public License ("LGPL"), Version 2, with exceptions for >> Apple operating systems and the OpenSSL toolkit. A copy of the >> exceptions and licenses follow this introduction. > > Following the guidance at http://fedoraproject.org/wiki/Licensing/FAQ I > would say that since the code is explicit about being licensed per the > terms in LICENSE.txt, "GPLv2 only" is a reasonable interpretation. > > If anybody thinks this is important to clarify I can chase it with the > Fedora licensing guys. > > Regards, Joe > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > From wk at gnupg.org Wed Sep 10 08:33:00 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Sep 2008 08:33:00 +0200 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: ("David =?utf-8?Q?Mar=C3=ADn_Carre=C3=B1o=22's?= message of "Wed, 10 Sep 2008 07:59:36 +0200") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> Message-ID: <87y720o6hv.fsf@wheatstone.g10code.de> On Wed, 10 Sep 2008 07:59, davefx at gmail.com said: > can be dinamically linked to a LGPL3 library. And, as far as I know > (and, please, correct me if I am wrong, as I am not a lawyer), a GPL2 > product can still be dinamically (or even statically) linked with a > LGPL3 library. [ The way you technical combine code does not matter in regard to the GPL. Thus it is irrelevant whether it is runtime or build time linked. What makes up a derivative work needs to be decided in each case by considering a lot of facts. Thus even GPL code linked at build time may - under certain circumstances - not even be a derivative work. OTOH, is is quite possible that just by spawning another program you create a derivative work. ] The LGPLv3 has a bug which makes this license incompatible to the GPLv2. However if the GPLv2 program is actually under the GPLv2+ (version 2 or later), you may combine it with LGPLv3 code by claiming that you took advantage of the "or any later version" clause and thus push up the code to the GPLv3. This is not possible if the code is GPLv2(only). Salam-Shalom, Werner -- Linux-Kongress 2008 + Hamburg + October 7-10 + www.linux-kongress.org Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Wed Sep 10 09:28:29 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 10 Sep 2008 09:28:29 +0200 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: ("David =?iso-8859-1?Q?Mar=EDn_Carre=F1o=22's?= message of "Wed, 10 Sep 2008 07:59:36 +0200") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> Message-ID: <878wu0o3xe.fsf@mocca.josefsson.org> The license compatibility matrix is useful, see: http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility The problem is for GPLv2-only projects that wants to use a LGPLv3 library. Using LGPLv3+ also has consequences for projects that wants to copy code from GnuTLS (they need to be GPLv3+ or LGPLv3+), but that is not something that happens widely enough to care about as far as I am aware. If anyone knows of significant code re-use from gnutls, let me know. /Simon "David Mar?n Carre?o" writes: > But I don't catch what is the problem: a proprietary licensed product > can be dinamically linked to a LGPL3 library. And, as far as I know > (and, please, correct me if I am wrong, as I am not a lawyer), a GPL2 > product can still be dinamically (or even statically) linked with a > LGPL3 library. > > We are not talking about GPLv3. It's LGPLv3. > > Perhaps, the problem would be the GPL'd parts of gnutls... > > > -- > David Mar?n Carre?o > > > 2008/9/9 Joe Orton : >> On Tue, Sep 09, 2008 at 01:46:17PM -0400, Daniel Kahn Gillmor wrote: >>> On Tue 2008-09-09 12:01:23 -0400, Simon Josefsson wrote: >>> >>> > I tried to do some systematic searches, but the debian copyright >>> > information tends to be incorrect (not mentioning versions) or difficult >>> > to parse. >>> >>> This is sadly true. Automatic resolution of this sort of question >>> would be much easier if the machine-readable debian/copyright proposal >>> was more widely-adopted: >>> >>> http://wiki.debian.org/Proposals/CopyrightFormat >> >> We have such a standard agreed at Fedora but the hard work is really in >> auditing N thousand packages to meet it. >> >>> > I recognize cups, snort and ekg, and they are fairly well known. >>> >>> fwiw, gobby seems to be GPL-2+, not GPL-2, at least according to the >>> debian copyright info, so it's possilbe that the fedora tags are wrong >>> on that package: >> >> I agree, good catch, thanks; I've filed a bug to get this fixed in >> Fedora. >> >>> And cups appears to be ambiguous as far as the GPL'ed bits (though the >>> LGPL'ed bits are pretty clearly V2-only): >>> >>> [0 dkg at squeak ~]$ grep -A6 ^INTRODUCTION /usr/share/doc/cups-common/copyright >>> INTRODUCTION >>> >>> The Common UNIX Printing System(tm), ("CUPS(tm)"), is provided >>> under the GNU General Public License ("GPL") and GNU Library >>> General Public License ("LGPL"), Version 2, with exceptions for >>> Apple operating systems and the OpenSSL toolkit. A copy of the >>> exceptions and licenses follow this introduction. >> >> Following the guidance at http://fedoraproject.org/wiki/Licensing/FAQ I >> would say that since the code is explicit about being licensed per the >> terms in LICENSE.txt, "GPLv2 only" is a reasonable interpretation. >> >> If anybody thinks this is important to clarify I can chase it with the >> Fedora licensing guys. >> >> Regards, Joe >> >> >> _______________________________________________ >> Gnutls-devel mailing list >> Gnutls-devel at gnu.org >> http://lists.gnu.org/mailman/listinfo/gnutls-devel >> > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls From colin at colino.net Wed Sep 10 09:39:07 2008 From: colin at colino.net (Colin Leroy) Date: Wed, 10 Sep 2008 09:39:07 +0200 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <878wu0o3xe.fsf@mocca.josefsson.org> References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> Message-ID: <20080910093907.6f867b14@paperstreet.colino.net> On Wed, 10 Sep 2008 09:28:29 +0200, Simon Josefsson wrote: Hi, > The problem is for GPLv2-only projects that wants to use a LGPLv3 > library. The inverse problem exists too (GPLv3+ projects that wants to use a LGPLv2 only library). It doesn't concern GnuTLS, but I thought I'd mention it (we've been bitten twice when switching Claws Mail to GPLv3, first with libclamav (their fault) then libpoppler (bad audit)). > Using LGPLv3+ also has consequences for projects that wants to copy > code from GnuTLS (they need to be GPLv3+ or LGPLv3+), but that is not > something that happens widely enough to care about as far as I am > aware. If anyone knows of significant code re-use from gnutls, let me > know. If such code re-use existed, upgrading GnuTLS to v3 wouldn't impact the existing code re-uses, but the v2 projects reusing GnuTLS code wouldn't be able to update from new GnuTLS code. -- Colin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From alvaro at gnu.org Wed Sep 10 10:10:37 2008 From: alvaro at gnu.org (Alvaro Lopez Ortega) Date: Wed, 10 Sep 2008 09:10:37 +0100 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <878wu0o3xe.fsf@mocca.josefsson.org> References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> Message-ID: <48C780FD.6040504@gnu.org> Hello Simon, Relicensing GnuTLS under LGPLv3 could be a problem for some other Free Software projects, actually. As you have pointed, it would not be legal for GPLv2 software to link against a LGPLv3 library, and that would turn to be a major problem for those projects and, at the end of the day, a handicap for GnuTLS. If I looked after GnuTLS' wellbeing, I'd personally stick with the current license. It is a perfectly fine Free Software license that wouldn't decrease GnuTLS' potential target audience. Besides, it would be definitely much more friendly with the Free Software developers who either don't follow the GPLv3 way or they are not ready yet to do so. Simon Josefsson wrote: > The license compatibility matrix is useful, see: > > http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility > > The problem is for GPLv2-only projects that wants to use a LGPLv3 > library. > > Using LGPLv3+ also has consequences for projects that wants to copy code > from GnuTLS (they need to be GPLv3+ or LGPLv3+), but that is not > something that happens widely enough to care about as far as I am aware. > If anyone knows of significant code re-use from gnutls, let me know. > > /Simon > > "David Mar?n Carre?o" writes: > >> But I don't catch what is the problem: a proprietary licensed product >> can be dinamically linked to a LGPL3 library. And, as far as I know >> (and, please, correct me if I am wrong, as I am not a lawyer), a GPL2 >> product can still be dinamically (or even statically) linked with a >> LGPL3 library. >> >> We are not talking about GPLv3. It's LGPLv3. >> >> Perhaps, the problem would be the GPL'd parts of gnutls... >> >> >> -- >> David Mar?n Carre?o >> >> >> 2008/9/9 Joe Orton : >>> On Tue, Sep 09, 2008 at 01:46:17PM -0400, Daniel Kahn Gillmor wrote: >>>> On Tue 2008-09-09 12:01:23 -0400, Simon Josefsson wrote: >>>> >>>>> I tried to do some systematic searches, but the debian copyright >>>>> information tends to be incorrect (not mentioning versions) or difficult >>>>> to parse. >>>> This is sadly true. Automatic resolution of this sort of question >>>> would be much easier if the machine-readable debian/copyright proposal >>>> was more widely-adopted: >>>> >>>> http://wiki.debian.org/Proposals/CopyrightFormat >>> We have such a standard agreed at Fedora but the hard work is really in >>> auditing N thousand packages to meet it. >>> >>>>> I recognize cups, snort and ekg, and they are fairly well known. >>>> fwiw, gobby seems to be GPL-2+, not GPL-2, at least according to the >>>> debian copyright info, so it's possilbe that the fedora tags are wrong >>>> on that package: >>> I agree, good catch, thanks; I've filed a bug to get this fixed in >>> Fedora. >>> >>>> And cups appears to be ambiguous as far as the GPL'ed bits (though the >>>> LGPL'ed bits are pretty clearly V2-only): >>>> >>>> [0 dkg at squeak ~]$ grep -A6 ^INTRODUCTION /usr/share/doc/cups-common/copyright >>>> INTRODUCTION >>>> >>>> The Common UNIX Printing System(tm), ("CUPS(tm)"), is provided >>>> under the GNU General Public License ("GPL") and GNU Library >>>> General Public License ("LGPL"), Version 2, with exceptions for >>>> Apple operating systems and the OpenSSL toolkit. A copy of the >>>> exceptions and licenses follow this introduction. >>> Following the guidance at http://fedoraproject.org/wiki/Licensing/FAQ I >>> would say that since the code is explicit about being licensed per the >>> terms in LICENSE.txt, "GPLv2 only" is a reasonable interpretation. >>> >>> If anybody thinks this is important to clarify I can chase it with the >>> Fedora licensing guys. >>> >>> Regards, Joe -- Greetings, alo http://www.alobbs.com/ From simon at josefsson.org Wed Sep 10 10:24:37 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 10 Sep 2008 10:24:37 +0200 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <87sks98b6e.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 09 Sep 2008 13:46:17 -0400") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> Message-ID: <87ljy0mmre.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > On Tue 2008-09-09 12:01:23 -0400, Simon Josefsson wrote: > >> I tried to do some systematic searches, but the debian copyright >> information tends to be incorrect (not mentioning versions) or difficult >> to parse. > > This is sadly true. Automatic resolution of this sort of question > would be much easier if the machine-readable debian/copyright proposal > was more widely-adopted: > > http://wiki.debian.org/Proposals/CopyrightFormat I have changed one of my debian packages to use it, and will do the same for another. Thanks for the pointer. > And cups appears to be ambiguous as far as the GPL'ed bits (though the > LGPL'ed bits are pretty clearly V2-only): > > [0 dkg at squeak ~]$ grep -A6 ^INTRODUCTION /usr/share/doc/cups-common/copyright > INTRODUCTION > > The Common UNIX Printing System(tm), ("CUPS(tm)"), is provided > under the GNU General Public License ("GPL") and GNU Library > General Public License ("LGPL"), Version 2, with exceptions for > Apple operating systems and the OpenSSL toolkit. A copy of the > exceptions and licenses follow this introduction. > [0 dkg at squeak ~]$ > > I couldn't come up with an automated way to pull the answers to these > questions out of debian automatically either :( Looking at the source code headers in CUPS indicate a somewhat confusing situation. At least some of the files definitely just reference version 2 though. /Simon From simon at josefsson.org Wed Sep 10 10:32:00 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 10 Sep 2008 10:32:00 +0200 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <20080910093907.6f867b14@paperstreet.colino.net> (Colin Leroy's message of "Wed, 10 Sep 2008 09:39:07 +0200") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> <20080910093907.6f867b14@paperstreet.colino.net> Message-ID: <87d4jcmmf3.fsf@mocca.josefsson.org> Colin Leroy writes: >> Using LGPLv3+ also has consequences for projects that wants to copy >> code from GnuTLS (they need to be GPLv3+ or LGPLv3+), but that is not >> something that happens widely enough to care about as far as I am >> aware. If anyone knows of significant code re-use from gnutls, let me >> know. > > If such code re-use existed, upgrading GnuTLS to v3 wouldn't impact the > existing code re-uses, but the v2 projects reusing GnuTLS code wouldn't > be able to update from new GnuTLS code. Ah, right. So ignoring the code re-use problem should be fine. Summarizing, the only significant problem I've seen raised so far has been incompatibility with GPLv2-only projects, and we have a concrete list of such projects to look more closely at. /Simon From simon at josefsson.org Wed Sep 10 10:37:09 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 10 Sep 2008 10:37:09 +0200 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <48C780FD.6040504@gnu.org> (Alvaro Lopez Ortega's message of "Wed, 10 Sep 2008 09:10:37 +0100") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> <48C780FD.6040504@gnu.org> Message-ID: <878wu0mm6i.fsf@mocca.josefsson.org> I understand, although RMS asked if there were any _concrete_ reasons to not go with LGPLv3+ now, as opposed to just preferences. The only concrete reason I've seen so far is a list of GPLv2 only projects. If you think GnuTLS should remain licensed under LGPLv2.1+, finding more GPLv2-only projects that use GnuTLS is useful. Reviewing these projects and finding out how difficult it would be to make them GPLv2+ instead would also provide more facts. /Simon Alvaro Lopez Ortega writes: > Hello Simon, > > Relicensing GnuTLS under LGPLv3 could be a problem for some other Free > Software projects, actually. As you have pointed, it would not be > legal for GPLv2 software to link against a LGPLv3 library, and that > would turn to be a major problem for those projects and, at the end of > the day, a handicap for GnuTLS. > > If I looked after GnuTLS' wellbeing, I'd personally stick with the > current license. It is a perfectly fine Free Software license that > wouldn't decrease GnuTLS' potential target audience. > > Besides, it would be definitely much more friendly with the Free > Software developers who either don't follow the GPLv3 way or they are > not ready yet to do so. > > > Simon Josefsson wrote: > >> The license compatibility matrix is useful, see: >> >> http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility >> >> The problem is for GPLv2-only projects that wants to use a LGPLv3 >> library. >> >> Using LGPLv3+ also has consequences for projects that wants to copy code >> from GnuTLS (they need to be GPLv3+ or LGPLv3+), but that is not >> something that happens widely enough to care about as far as I am aware. >> If anyone knows of significant code re-use from gnutls, let me know. >> >> /Simon >> >> "David Mar?n Carre?o" writes: >> >>> But I don't catch what is the problem: a proprietary licensed product >>> can be dinamically linked to a LGPL3 library. And, as far as I know >>> (and, please, correct me if I am wrong, as I am not a lawyer), a GPL2 >>> product can still be dinamically (or even statically) linked with a >>> LGPL3 library. >>> >>> We are not talking about GPLv3. It's LGPLv3. >>> >>> Perhaps, the problem would be the GPL'd parts of gnutls... >>> >>> >>> -- >>> David Mar?n Carre?o >>> >>> >>> 2008/9/9 Joe Orton : >>>> On Tue, Sep 09, 2008 at 01:46:17PM -0400, Daniel Kahn Gillmor wrote: >>>>> On Tue 2008-09-09 12:01:23 -0400, Simon Josefsson wrote: >>>>> >>>>>> I tried to do some systematic searches, but the debian copyright >>>>>> information tends to be incorrect (not mentioning versions) or difficult >>>>>> to parse. >>>>> This is sadly true. Automatic resolution of this sort of question >>>>> would be much easier if the machine-readable debian/copyright proposal >>>>> was more widely-adopted: >>>>> >>>>> http://wiki.debian.org/Proposals/CopyrightFormat >>>> We have such a standard agreed at Fedora but the hard work is really in >>>> auditing N thousand packages to meet it. >>>> >>>>>> I recognize cups, snort and ekg, and they are fairly well known. >>>>> fwiw, gobby seems to be GPL-2+, not GPL-2, at least according to the >>>>> debian copyright info, so it's possilbe that the fedora tags are wrong >>>>> on that package: >>>> I agree, good catch, thanks; I've filed a bug to get this fixed in >>>> Fedora. >>>> >>>>> And cups appears to be ambiguous as far as the GPL'ed bits (though the >>>>> LGPL'ed bits are pretty clearly V2-only): >>>>> >>>>> [0 dkg at squeak ~]$ grep -A6 ^INTRODUCTION /usr/share/doc/cups-common/copyright >>>>> INTRODUCTION >>>>> >>>>> The Common UNIX Printing System(tm), ("CUPS(tm)"), is provided >>>>> under the GNU General Public License ("GPL") and GNU Library >>>>> General Public License ("LGPL"), Version 2, with exceptions for >>>>> Apple operating systems and the OpenSSL toolkit. A copy of the >>>>> exceptions and licenses follow this introduction. >>>> Following the guidance at http://fedoraproject.org/wiki/Licensing/FAQ I >>>> would say that since the code is explicit about being licensed per the >>>> terms in LICENSE.txt, "GPLv2 only" is a reasonable interpretation. >>>> >>>> If anybody thinks this is important to clarify I can chase it with the >>>> Fedora licensing guys. >>>> >>>> Regards, Joe > > -- > Greetings, alo > http://www.alobbs.com/ From wk at gnupg.org Wed Sep 10 10:40:12 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Sep 2008 10:40:12 +0200 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <87d4jcmmf3.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 10 Sep 2008 10:32:00 +0200") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> <20080910093907.6f867b14@paperstreet.colino.net> <87d4jcmmf3.fsf@mocca.josefsson.org> Message-ID: <87d4jcmm1f.fsf@wheatstone.g10code.de> On Wed, 10 Sep 2008 10:32, simon at josefsson.org said: > Summarizing, the only significant problem I've seen raised so far has > been incompatibility with GPLv2-only projects, and we have a concrete > list of such projects to look more closely at. Did you also checked for applications using GnuTLS indirectly? For example by using libldap or libcurl or *libgtk2.0*? I doubt that there is any way to change gnutls to LGPLv3+ without causing great harm to our software ecosystem. Shalom-Salam, Werner -- Linux-Kongress 2008 + Hamburg + October 7-10 + www.linux-kongress.org Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From alvaro at gnu.org Wed Sep 10 11:48:49 2008 From: alvaro at gnu.org (Alvaro Lopez Ortega) Date: Wed, 10 Sep 2008 10:48:49 +0100 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <878wu0mm6i.fsf@mocca.josefsson.org> References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> <48C780FD.6040504@gnu.org> <878wu0mm6i.fsf@mocca.josefsson.org> Message-ID: <48C79801.5090007@gnu.org> Simon Josefsson wrote: > I understand, although RMS asked if there were any _concrete_ reasons to > not go with LGPLv3+ now, as opposed to just preferences. The only > concrete reason I've seen so far is a list of GPLv2 only projects. If > you think GnuTLS should remain licensed under LGPLv2.1+, finding more > GPLv2-only projects that use GnuTLS is useful. Reviewing these projects > and finding out how difficult it would be to make them GPLv2+ instead > would also provide more facts. The Cherokee Web Server could be one for the project impacted by the change. It's licensed under GPLv2, so in case GnuTLS was relicensed under LGPLv3 it could not legally use GnuTLS any longer. GnuTLS is an essential dependency for many Free Software projects, so it is specially important to make the right decision here. Right now, everybody can use GnuTLS; that a good thing. However, changing the license would force even some Free Software projects to stop using it. That's worrying because it would leave those GPL projects without any choice: neither GnuTLS nor OpenSSL would be a legal option. As I said, there are developers (and companies) who, for a number of reasons, are not ready to follow the GPLv3 path quite yet; and I don't personally think that ignoring them would be the right thing to do. My two cents: IMHO, speaking of such a high impact piece of software, delaying the relicense for some time could be one of the most reasonable options. > Alvaro Lopez Ortega writes: > >> Hello Simon, >> >> Relicensing GnuTLS under LGPLv3 could be a problem for some other Free >> Software projects, actually. As you have pointed, it would not be >> legal for GPLv2 software to link against a LGPLv3 library, and that >> would turn to be a major problem for those projects and, at the end of >> the day, a handicap for GnuTLS. >> >> If I looked after GnuTLS' wellbeing, I'd personally stick with the >> current license. It is a perfectly fine Free Software license that >> wouldn't decrease GnuTLS' potential target audience. >> >> Besides, it would be definitely much more friendly with the Free >> Software developers who either don't follow the GPLv3 way or they are >> not ready yet to do so. >> >> >> Simon Josefsson wrote: >> >>> The license compatibility matrix is useful, see: >>> >>> http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility >>> >>> The problem is for GPLv2-only projects that wants to use a LGPLv3 >>> library. >>> >>> Using LGPLv3+ also has consequences for projects that wants to copy code >>> from GnuTLS (they need to be GPLv3+ or LGPLv3+), but that is not >>> something that happens widely enough to care about as far as I am aware. >>> If anyone knows of significant code re-use from gnutls, let me know. >>> >>> /Simon >>> >>> "David Mar?n Carre?o" writes: >>> >>>> But I don't catch what is the problem: a proprietary licensed product >>>> can be dinamically linked to a LGPL3 library. And, as far as I know >>>> (and, please, correct me if I am wrong, as I am not a lawyer), a GPL2 >>>> product can still be dinamically (or even statically) linked with a >>>> LGPL3 library. >>>> >>>> We are not talking about GPLv3. It's LGPLv3. >>>> >>>> Perhaps, the problem would be the GPL'd parts of gnutls... >>>> >>>> >>>> -- >>>> David Mar?n Carre?o >>>> >>>> >>>> 2008/9/9 Joe Orton : >>>>> On Tue, Sep 09, 2008 at 01:46:17PM -0400, Daniel Kahn Gillmor wrote: >>>>>> On Tue 2008-09-09 12:01:23 -0400, Simon Josefsson wrote: >>>>>> >>>>>>> I tried to do some systematic searches, but the debian copyright >>>>>>> information tends to be incorrect (not mentioning versions) or difficult >>>>>>> to parse. >>>>>> This is sadly true. Automatic resolution of this sort of question >>>>>> would be much easier if the machine-readable debian/copyright proposal >>>>>> was more widely-adopted: >>>>>> >>>>>> http://wiki.debian.org/Proposals/CopyrightFormat >>>>> We have such a standard agreed at Fedora but the hard work is really in >>>>> auditing N thousand packages to meet it. >>>>> >>>>>>> I recognize cups, snort and ekg, and they are fairly well known. >>>>>> fwiw, gobby seems to be GPL-2+, not GPL-2, at least according to the >>>>>> debian copyright info, so it's possilbe that the fedora tags are wrong >>>>>> on that package: >>>>> I agree, good catch, thanks; I've filed a bug to get this fixed in >>>>> Fedora. >>>>> >>>>>> And cups appears to be ambiguous as far as the GPL'ed bits (though the >>>>>> LGPL'ed bits are pretty clearly V2-only): >>>>>> >>>>>> [0 dkg at squeak ~]$ grep -A6 ^INTRODUCTION /usr/share/doc/cups-common/copyright >>>>>> INTRODUCTION >>>>>> >>>>>> The Common UNIX Printing System(tm), ("CUPS(tm)"), is provided >>>>>> under the GNU General Public License ("GPL") and GNU Library >>>>>> General Public License ("LGPL"), Version 2, with exceptions for >>>>>> Apple operating systems and the OpenSSL toolkit. A copy of the >>>>>> exceptions and licenses follow this introduction. >>>>> Following the guidance at http://fedoraproject.org/wiki/Licensing/FAQ I >>>>> would say that since the code is explicit about being licensed per the >>>>> terms in LICENSE.txt, "GPLv2 only" is a reasonable interpretation. >>>>> >>>>> If anybody thinks this is important to clarify I can chase it with the >>>>> Fedora licensing guys. -- Greetings, alo http://www.alobbs.com/ From simon at josefsson.org Wed Sep 10 12:06:23 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 10 Sep 2008 12:06:23 +0200 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <87d4jcmm1f.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 10 Sep 2008 10:40:12 +0200") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> <20080910093907.6f867b14@paperstreet.colino.net> <87d4jcmmf3.fsf@mocca.josefsson.org> <87d4jcmm1f.fsf@wheatstone.g10code.de> Message-ID: <874p4omi1s.fsf@mocca.josefsson.org> Werner Koch writes: > On Wed, 10 Sep 2008 10:32, simon at josefsson.org said: > >> Summarizing, the only significant problem I've seen raised so far has >> been incompatibility with GPLv2-only projects, and we have a concrete >> list of such projects to look more closely at. > > Did you also checked for applications using GnuTLS indirectly? For > example by using libldap or libcurl or *libgtk2.0*? Good point. I think we need a wiki page to track this... /Simon From simon at josefsson.org Wed Sep 10 14:10:04 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 10 Sep 2008 14:10:04 +0200 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <20080910120113.GA11677@nic.fr> (Stephane Bortzmeyer's message of "Wed, 10 Sep 2008 14:01:13 +0200") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> <20080910120113.GA11677@nic.fr> Message-ID: <874p4otd5v.fsf@mocca.josefsson.org> Stephane Bortzmeyer writes: > On Wed, Sep 10, 2008 at 09:28:29AM +0200, > Simon Josefsson wrote > a message of 94 lines which said: > >> The problem is for GPLv2-only projects that wants to use a LGPLv3 >> library. > > :-( > > My case: http://echoping.sourceforge.net/ > > Since echoping has the OpenSSL exception, switching GNUTLS to LGPLv3 > would mean dropping GNUTLS support, just to please the FSF lawyers. Is echoping licensed under GPLv2 or GPLv2-or-later? I can't find anything conclusive in the echoping sources (probably something you want to fix :)). GPLv2-or-later with OpenSSL exception is compatible with LGPLv3 if I understand correctly. Anyway, it seems we have gathered plenty of arguments that probably will delay re-licensing for some time. /Simon From simon at josefsson.org Wed Sep 10 14:38:37 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 10 Sep 2008 14:38:37 +0200 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <20080910121741.GA14911@nic.fr> (Stephane Bortzmeyer's message of "Wed, 10 Sep 2008 14:17:41 +0200") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> <20080910120113.GA11677@nic.fr> <874p4otd5v.fsf@mocca.josefsson.org> <20080910121741.GA14911@nic.fr> Message-ID: <87hc8orx9u.fsf@mocca.josefsson.org> Stephane Bortzmeyer writes: > On Wed, Sep 10, 2008 at 02:10:04PM +0200, > Simon Josefsson wrote > a message of 27 lines which said: > >> Is echoping licensed under GPLv2 or GPLv2-or-later? > > v2 only > >> I can't find anything conclusive in the echoping sources (probably >> something you want to fix :)). > > COPYING says: > > GNU GENERAL PUBLIC LICENSE > Version 2, June 1991 > > To me, in the absence of other mention, it means v2 only. > > COPYING later says: > > Each version is given a distinguishing version number. If the Program > specifies a version number of this License which applies to it and > "any later version", you have the option of following the terms and > conditions either of that version or of any later version published by > the Free Software Foundation. > > And the magical sentence "any later version" does not appear in the > source code (only in autotools-generated files). I didn't see a specific version number mentioned in the _program_ (there are no license headers in the *.c files). The license continues: If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation. FWIW, adding a license headers to each file (and making sure it specify the version of the GPL) would help to clarify the intended license. Including a verbatim copy of the GPL doesn't mean the program is automatically licensed under the GPL. There needs to be some statement that binds the program with the license. Anyway, I think we have established a long list of GPLv2-only projects that use GnuTLS that needs to be studied more closely before we make any decision to move to LGPLv3+. /Simon From wk at gnupg.org Wed Sep 10 14:51:43 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Sep 2008 14:51:43 +0200 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <87hc8orx9u.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 10 Sep 2008 14:38:37 +0200") References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> <20080910120113.GA11677@nic.fr> <874p4otd5v.fsf@mocca.josefsson.org> <20080910121741.GA14911@nic.fr> <87hc8orx9u.fsf@mocca.josefsson.org> Message-ID: <87d4jckvts.fsf@wheatstone.g10code.de> On Wed, 10 Sep 2008 14:38, simon at josefsson.org said: > Anyway, I think we have established a long list of GPLv2-only projects > that use GnuTLS that needs to be studied more closely before we make any Quite a long list on my Sid box: Alone 1534 packages list a dependency to libgtk2.0 and that in turn to gnutls. It will be huge task to check them all for GPLv2(only) code. Shalom-Salam, Werner -- Linux-Kongress 2008 + Hamburg + October 7-10 + www.linux-kongress.org Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From bortzmeyer at nic.fr Wed Sep 10 14:17:41 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 10 Sep 2008 14:17:41 +0200 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <874p4otd5v.fsf@mocca.josefsson.org> References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> <20080910120113.GA11677@nic.fr> <874p4otd5v.fsf@mocca.josefsson.org> Message-ID: <20080910121741.GA14911@nic.fr> On Wed, Sep 10, 2008 at 02:10:04PM +0200, Simon Josefsson wrote a message of 27 lines which said: > Is echoping licensed under GPLv2 or GPLv2-or-later? v2 only > I can't find anything conclusive in the echoping sources (probably > something you want to fix :)). COPYING says: GNU GENERAL PUBLIC LICENSE Version 2, June 1991 To me, in the absence of other mention, it means v2 only. COPYING later says: Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. And the magical sentence "any later version" does not appear in the source code (only in autotools-generated files). From bortzmeyer at nic.fr Wed Sep 10 14:01:13 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 10 Sep 2008 14:01:13 +0200 Subject: Using LGPLv3+ license for libgnutls? In-Reply-To: <878wu0o3xe.fsf@mocca.josefsson.org> References: <87y721pklj.fsf@mocca.josefsson.org> <20080909153708.GD14713@manyfish.co.uk> <87y721nwa4.fsf@mocca.josefsson.org> <87sks98b6e.fsf@squeak.fifthhorseman.net> <20080909205951.GA18961@manyfish.co.uk> <878wu0o3xe.fsf@mocca.josefsson.org> Message-ID: <20080910120113.GA11677@nic.fr> On Wed, Sep 10, 2008 at 09:28:29AM +0200, Simon Josefsson wrote a message of 94 lines which said: > The problem is for GPLv2-only projects that wants to use a LGPLv3 > library. :-( My case: http://echoping.sourceforge.net/ Since echoping has the OpenSSL exception, switching GNUTLS to LGPLv3 would mean dropping GNUTLS support, just to please the FSF lawyers. From mrsam at courier-mta.com Sat Sep 13 21:45:17 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 13 Sep 2008 15:45:17 -0400 Subject: What happens if client is sending data when rehandshake is issued on the server Message-ID: I'm trying to understand the proper usage of gnutls_rehandshake(). I have only a vague understanding of the technical details of TLS. The man page for gnutls_rehandshake says: # If this function succeeds (returns 0), you must call the # gnutls_handshake() function in order to negotiate the new parameters. # # If the client does not wish to renegotiate parameters he will should with # an alert message, thus the return code will be # GNUTLS_E_WARNING_ALERT_RECEIVED and the alert will be # GNUTLS_A_NO_RENEGOTIATION. A client may also choose to ignore this # message. So, as I understand this, gnutls_rehandshake() sends a message to the client side, and waits for the client to respond. The man page does not address what happens when the underlying transport is non-blocking. I presume what's going to happen is that I'll get a GNUTLS_E_INTERRUPTED or GNUTLS_E_AGAIN, I must call gnutls_record_get_direction(), wait for the appropriate I/O to be ready, then call gnutls_rehandshake() again. What's not clear to me is what happens when the server calls gnutls_rehandshake() while the client is in a middle of sending a record at the same time, so instead of receiving the response from the rehandshake request, the server receives a data record, that was sent by the client before it got the handshake request. What happens to that record, does it get discarded, or does gnutls_rehandshake() return an error code that tells me that I need to call gnutls_record_recv() to take it (GNUTLS_E_UNEXPECTED_PACKET?), then call gnutls_rehandshake() again. Can this be clarified in the man page? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From nmav at gnutls.org Mon Sep 15 09:37:23 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 15 Sep 2008 10:37:23 +0300 Subject: What happens if client is sending data when rehandshake is issued on the server In-Reply-To: References: Message-ID: Hello Sam, The behavior I remember is: The server once calls the rehandshake() will send a handshake request to the client, nothing more. It is up to the client to ignore this message (continue sending data), or start a rehandshake (call gnutls_handshake). Any message received before the actual rehandshake (gnutls_handshake) is being cached. regards, Nikos On Sat, Sep 13, 2008 at 10:45 PM, Sam Varshavchik wrote: > I'm trying to understand the proper usage of gnutls_rehandshake(). I have > only a vague understanding of the technical details of TLS. The man page for > gnutls_rehandshake says: > > # If this function succeeds (returns 0), you must call the > # gnutls_handshake() function in order to negotiate the new parameters. > # > # If the client does not wish to renegotiate parameters he will should with > # an alert message, thus the return code will be # > GNUTLS_E_WARNING_ALERT_RECEIVED and the alert will be # > GNUTLS_A_NO_RENEGOTIATION. A client may also choose to ignore this > # message. > > So, as I understand this, gnutls_rehandshake() sends a message to the client > side, and waits for the client to respond. > > The man page does not address what happens when the underlying transport is > non-blocking. I presume what's going to happen is that I'll get a > GNUTLS_E_INTERRUPTED or GNUTLS_E_AGAIN, I must call > gnutls_record_get_direction(), wait for the appropriate I/O to be ready, > then call gnutls_rehandshake() again. > > What's not clear to me is what happens when the server calls > gnutls_rehandshake() while the client is in a middle of sending a record at > the same time, so instead of receiving the response from the rehandshake > request, the server receives a data record, that was sent by the client > before it got the handshake request. What happens to that record, does it > get discarded, or does gnutls_rehandshake() return an error code that tells > me that I need to call gnutls_record_recv() to take it > (GNUTLS_E_UNEXPECTED_PACKET?), then call gnutls_rehandshake() again. > > Can this be clarified in the man page? > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > > From simon at josefsson.org Tue Sep 16 00:22:04 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Sep 2008 00:22:04 +0200 Subject: GnuTLS 2.4.2 Message-ID: <87hc8h6odv.fsf@mocca.josefsson.org> We are proud to announce a new stable GnuTLS release: Version 2.4.2. GnuTLS is a modern C library that implement the standard network security protocol Transport Layer Security (TLS), for use by network applications. GnuTLS is developed for GNU/Linux, but works on many Unix-like systems and comes with a binary installer for Windows. The core GnuTLS library is distributed under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS libraries -- which contains TLS/IA support, LZO compression -- and the OpenSSL compatibility library self tests and command line tools are distributed under the GNU General Public License version 3.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.2 (or later). The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ What's New ========== Changes compared to the last stable release version 2.4.1: ** libgnutls: Don't crash when gnutls_credentials_set is called twice. ** libgnutls: Corrected memory leak in X.509 functions. Thanks to Colin Leroy . ** libgnutls: Fix compile error with Sun CC. ** gnutls-cli.1: Document all new parameters. Thanks to James Westby . ** tests/openssl: initialize gnutls before use. Fixes crash with libgcrypt 1.4.2. Reported by Ludovic Courtes . ** doc/: Fix texinfo markup for old texinfo versions. ** Included copy of libtasn1 is upgraded to version 1.5. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the mirror sites or direct from . The list of mirrors can be found at . Here are the BZIP2 compressed sources (4.8MB): ftp://ftp.gnu.org/pub/gnu/gnutls/gnutls-2.4.2.tar.bz2 http://ftp.gnu.org/pub/gnu/gnutls/gnutls-2.4.2.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnu.org/pub/gnu/gnutls/gnutls-2.4.2.tar.bz2.sig http://ftp.gnu.org/pub/gnu/gnutls/gnutls-2.4.2.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs. In order to check that the version of GnuTLS which you are going to install is an original and unmodified one, you should verify the OpenPGP signature. You can use the command gpg --verify gnutls-2.4.2.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. The signing key can be identified with the following information: pub 1280R/B565716F 2002-05-05 [expires: 2009-04-21] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2009-04-21] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Alternatively, after successfully verifying the OpenPGP signature of this announcement, you could verify that the files match the following checksum values. The values are for SHA-1 and SHA-224 respectively: 79f66b47cccf9700778218b5582969255d623dc2 gnutls-2.4.2.tar.bz2 b30dc032271a052e0e5e08df2050217f4d14d37f4f5b92985a2b85da gnutls-2.4.2.tar.bz2 Documentation ============= The manual is available online at: http://www.gnu.org/software/gnutls/documentation.html In particular the following formats are available: HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf For developers there is a GnuTLS API reference manual formatted using the GTK-DOC tools: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html Community ========= If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: http://lists.gnu.org/mailman/listinfo/help-gnutls If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-devel mailing list, see: http://lists.gnu.org/mailman/listinfo/gnutls-devel Windows installer ================= GnuTLS has been ported to the Windows operating system, and a binary installer is available. The installer contains DLLs for application development, manuals, examples, and source code. The installer consists of libgpg-error 1.6, libgcrypt 1.4.2, libtasn1 1.5, and GnuTLS 2.4.2. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ The Windows binary installer and PGP signature: http://josefsson.org/gnutls4win/gnutls-2.4.2.exe (14MB) http://josefsson.org/gnutls4win/gnutls-2.4.2.exe.sig The checksum values for SHA-1 and SHA-224 are: 4b7b5a268386dc0393094e7517730f8e77f381d7 gnutls-2.4.2.exe fd1e6fa1abf4d3a9ab18ec83434aca55d78126f6b602452017a0adfb gnutls-2.4.2.exe Thanks to Enrico Tassi, we also have mingw32 *.deb's available: http://josefsson.org/gnutls4win/mingw32-gnutls_2.4.2-1_all.deb The checksum values for SHA-1 and SHA-224 are: d9dbb77b220f48a155723b3c3b5f05067df99ee7 mingw32-gnutls_2.4.2-1_all.deb f7676ba8af27f47a2bab56c6e2e88129d6334c61eaf114c0eb5821b4 mingw32-gnutls_2.4.2-1_all.deb Internationalization ==================== GnuTLS messages have been translated into Dutch, German, Malay, Polish, Swedish, and Vietnamese. We welcome the addition of more translations. Support ======= Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. The GnuTLS service directory is available at: http://www.gnu.org/software/gnutls/commercial.html Happy Hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Tue Sep 16 11:58:35 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Sep 2008 11:58:35 +0200 Subject: request for help: openpgp under windows doesn't work Message-ID: <87tzcg5s50.fsf@mocca.josefsson.org> Windows builds of GnuTLS seem to have some problems in the opencdk library, which causes parsing of packets to fail. This can be seen with the 'pgps2kgnu' self-test, which unfortunately results the same error as if the problem it is supposed to test for exists (I've made sure the s2k patch is still working). The problem appears to be in the low-level stream reading code in opencdk. It could be that pgp has never worked under Windows, since the pgp self tests have been disabled because of missing fork(). I'm inclined to disable openpgp authentication under windows for the 2.6.x build, and note in the release notes that it doesn't work currently. Help in debugging the problem would be appreciated, it is easy to get a windows build and debug it under debian, see . I tried to do this, but I'm not familiar with opencdk and didn't understand exactly how the code was supposed to work anyway. /Simon From n.mavrogiannopoulos at gmail.com Tue Sep 16 13:15:43 2008 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue, 16 Sep 2008 14:15:43 +0300 Subject: request for help: openpgp under windows doesn't work In-Reply-To: <87tzcg5s50.fsf@mocca.josefsson.org> References: <87tzcg5s50.fsf@mocca.josefsson.org> Message-ID: On Tue, Sep 16, 2008 at 12:58 PM, Simon Josefsson wrote: > Windows builds of GnuTLS seem to have some problems in the opencdk > library, which causes parsing of packets to fail. This can be seen with > the 'pgps2kgnu' self-test, which unfortunately results the same error as > if the problem it is supposed to test for exists (I've made sure the s2k > patch is still working). The problem appears to be in the low-level > stream reading code in opencdk. > It could be that pgp has never worked under Windows, since the pgp self > tests have been disabled because of missing fork(). I'm inclined to > disable openpgp authentication under windows for the 2.6.x build, and > note in the release notes that it doesn't work currently. I had test the openpgp code in windows a while (year) ago and it worked. I had some issues though, functions like tmpfile() could only be used if run as administrator in windows. Can it be that case? > Help in debugging the problem would be appreciated, it is easy to get a > windows build and debug it under debian, see > . I tried to do this, but I'm not > familiar with opencdk and didn't understand exactly how the code was > supposed to work anyway. I might be able to check it within this week. regards, Nikos From simon at josefsson.org Tue Sep 16 13:29:19 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Sep 2008 13:29:19 +0200 Subject: request for help: openpgp under windows doesn't work In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue, 16 Sep 2008 14:15:43 +0300") References: <87tzcg5s50.fsf@mocca.josefsson.org> Message-ID: <87prn45nxs.fsf@mocca.josefsson.org> "Nikos Mavrogiannopoulos" writes: > On Tue, Sep 16, 2008 at 12:58 PM, Simon Josefsson wrote: >> Windows builds of GnuTLS seem to have some problems in the opencdk >> library, which causes parsing of packets to fail. This can be seen with >> the 'pgps2kgnu' self-test, which unfortunately results the same error as >> if the problem it is supposed to test for exists (I've made sure the s2k >> patch is still working). The problem appears to be in the low-level >> stream reading code in opencdk. >> It could be that pgp has never worked under Windows, since the pgp self >> tests have been disabled because of missing fork(). I'm inclined to >> disable openpgp authentication under windows for the 2.6.x build, and >> note in the release notes that it doesn't work currently. > > I had test the openpgp code in windows a while (year) ago and it > worked. I had some issues though, functions like tmpfile() could only > be used if run as administrator in windows. Can it be that case? I am using wine. I didn't get a hard failure -- instead I got an EOF at a surprising position (middle of stream). Maybe some fseek problem... I suspected binary vs text too, but it looks like the files are opened in binary mode. The idea of using a temporary file seemed somewhat strange to me, and I'm not familiar with the code so it was hard to debug. >> Help in debugging the problem would be appreciated, it is easy to get a >> windows build and debug it under debian, see >> . I tried to do this, but I'm not >> familiar with opencdk and didn't understand exactly how the code was >> supposed to work anyway. > > I might be able to check it within this week. Great! I had to disable the C++ library too, in order to get a Windows build, because the C++ library depends on having all features present. Possibly the C++ library could build even if openpgp is missing... Still, I think we can release 2.6.0 even with this problem. /Simon From simon at josefsson.org Tue Sep 16 14:38:59 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Sep 2008 14:38:59 +0200 Subject: draft release notes for 2.6.0 Message-ID: <87hc8g5kpo.fsf@mocca.josefsson.org> All, here are draft release notes for 2.6.0. Please review. /Simon We are proud to announce a new stable GnuTLS release: Version 2.6.0. GnuTLS is a modern C library that implement the standard network security protocol Transport Layer Security (TLS), for use by network applications. GnuTLS is developed for GNU/Linux, but works on many Unix-like systems and comes with a binary installer for Windows. The GnuTLS library is distributed under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS library (which contains TLS/IA support and LZO compression), the OpenSSL compatibility library, the self tests and the command line tools are all distributed under the GNU General Public License version 3.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.2 (or later). The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ What's New ========== Major end-user visible changes compared to the v2.4 branch: ** The OpenPGP backend can parse (but not decrypt) encrypted secret keys. Contributed by Daniel Kahn Gillmor . ** libgnutls: Remove code to import certificate chains in PKCS#7 format. The code has not worked since v0.9.0 and apparently nobody has missed it, so we decided to remove the code rather than fix it. If you have old certificate chains stored in PKCS#7 format, you can convert them to a list of PEM certificates by using 'certtool --p7-info'. Reported by Christian Grothoff . ** gnutls-cli: Improve --list output to include public key and signature algs. ** gnutls-cli, gnutls-serv: Remove --copyright parameter. Use standard --version to get license info. Major developer visible changes compared to the v2.2 branch: ** Added API to replace and update the crypto backend. The header gnutls/crypto.h is now officially supported, and declares the symbols below. gnutls_crypto_bigint_register2: ADDED. gnutls_crypto_cipher_register2: ADDED. gnutls_crypto_digest_register2: ADDED. gnutls_crypto_mac_register2: ADDED. gnutls_crypto_pk_register2: ADDED. gnutls_crypto_rnd_register2: ADDED. gnutls_crypto_single_cipher_register2: ADDED. gnutls_crypto_single_digest_register2: ADDED. gnutls_crypto_single_mac_register2: ADDED. ** libgnutls: Add interface to deal with public key and signature algorithms. The functions are called gnutls_pk_list, gnutls_pk_get_id, gnutls_sign_list, and gnutls_sign_get_id. Suggested by Sam Varshavchik . ** libgnutls: New API to get a string corresponding to a error symbol. The function is gnutls_strerror_name. ** libgnutls: New API to set the public parameters in a certificate request ** from a private key. The function is gnutls_x509_crq_set_key_rsa_raw. Inspired by discussion with "Zach C." . ** libgnutls: New API to set a callback to extract TLS Finished data. The function to register is gnutls_session_set_finished_function and it takes a callback of the gnutls_finished_callback_func type. ** libgnutls: Fix namespace problem with TLS_MASTER_SIZE and TLS_RANDOM_SIZE. The new names are GNUTLS_MASTER_SIZE and GNUTLS_RANDOM_SIZE. The old names are mapped to the new names in compat.h. These mappings will likely be removed more quickly than other mappings in that file due to the namespace violation. ** libgnutls: New interface to register a new TLS extension handler. The new function gnutls_ext_register can be used to register handlers for specific TLS extension types. The callback functions have the new types gnutls_ext_recv_func and gnutls_ext_send_func. A type to classify TLS extensions, gnutls_ext_parse_type_t, has been added as well. Of course, many smaller fixes have been made, see the ChangeLog file. API/ABI changes in GnuTLS 2.6 ============================= No functions have been removed or modified. The library should be fully backwards compatible both on the source level and on the binary level. A new header file 'gnutls/crypto.h' have been added. It contains definitions related to replacing the internal crypto functionality. We have realized that the symbols TLS_MASTER_SIZE and TLS_RANDOM_SIZE does not use the normal namespace. We have added GNUTLS_MASTER_SIZE and GNUTLS_RANDOM_SIZE, but the old symbols are still defined. The following functions have been added: gnutls_crypto_bigint_register2 gnutls_crypto_cipher_register2 gnutls_crypto_digest_register2 gnutls_crypto_mac_register2 gnutls_crypto_pk_register2 gnutls_crypto_rnd_register2 gnutls_crypto_single_cipher_register2 gnutls_crypto_single_digest_register2 gnutls_crypto_single_mac_register2 gnutls_pk_list gnutls_pk_get_id gnutls_sign_list gnutls_sign_get_id gnutls_x509_crq_set_key_rsa_raw gnutls_session_set_finished_function gnutls_finished_callback_func GNUTLS_MASTER_SIZE GNUTLS_RANDOM_SIZE gnutls_ext_recv_func gnutls_ext_send_func gnutls_ext_parse_type_t gnutls_ext_register gnutls_strerror_name Getting the Software ==================== GnuTLS may be downloaded from one of the mirror sites or direct from . The list of mirrors can be found at . Here are the BZIP2 compressed sources (4.8MB): ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.6.0.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-2.6.0.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.6.0.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-2.6.0.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs. In order to check that the version of GnuTLS which you are going to install is an original and unmodified one, you should verify the OpenPGP signature. You can use the command gpg --verify gnutls-2.4.2.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. The signing key can be identified with the following information: pub 1280R/B565716F 2002-05-05 [expires: 2009-04-21] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2009-04-21] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Alternatively, after successfully verifying the OpenPGP signature of this announcement, you could verify that the files match the following checksum values. The values are for SHA-1 and SHA-224 respectively: 9bb3be9f2ad67037d3a571bec4fac65e0ffbadbb gnutls-2.6.0.tar.bz2 9dc4435b637a4841a88ec294b8a82841eb257cee4948bc957c1a96d7 gnutls-2.6.0.tar.bz2 Documentation ============= The manual is available online at: http://www.gnu.org/software/gnutls/documentation.html In particular the following formats are available: HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf For developers there is a GnuTLS API reference manual formatted using the GTK-DOC tools: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html Community ========= If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: http://lists.gnu.org/mailman/listinfo/help-gnutls If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-dev mailing list, see: http://lists.gnupg.org/mailman/listinfo/gnutls-dev Windows installer ================= GnuTLS has been ported to the Windows operating system, and a binary installer is available. The installer contains DLLs for application development, manuals, examples, and source code. The installer consists of libgpg-error 1.6, libgcrypt 1.4.2, libtasn1 1.5, and GnuTLS 2.6.0. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ The Windows binary installer and PGP signature: http://josefsson.org/gnutls4win/gnutls-2.6.0.exe (14MB) http://josefsson.org/gnutls4win/gnutls-2.6.0.exe.sig The checksum values for SHA-1 and SHA-224 are: e704df715ed6cad14c7a6e4350d7557d81de655b gnutls-2.6.0.exe b548c3178f89669d1245b266c7caa834feeea63b142a8871f1185097 gnutls-2.6.0.exe Thanks to Enrico Tassi, we also have mingw32 *.deb's available: http://josefsson.org/gnutls4win/mingw32-gnutls_2.3.15-1_all.deb The checksum values for SHA-1 and SHA-224 are: 3fc1e58fe58ac77c6dc433052685d59400a88559 mingw32-gnutls_2.6.0-1_all.deb 601549a449ce25dc4520c591bad42d833b23f05a8f67cf4fe732f7de mingw32-gnutls_2.6.0-1_all.deb Internationalization ==================== GnuTLS messages have been translated into Dutch, French, German, Malay, Polish, Swedish, and Vietnamese. We welcome the addition of more translations. Support ======= Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. The GnuTLS service directory is available at: http://www.gnu.org/software/gnutls/commercial.html Happy Hacking, Simon From dkg at fifthhorseman.net Tue Sep 16 16:27:09 2008 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 16 Sep 2008 10:27:09 -0400 Subject: draft release notes for 2.6.0 In-Reply-To: <87hc8g5kpo.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue\, 16 Sep 2008 14\:38\:59 +0200") References: <87hc8g5kpo.fsf@mocca.josefsson.org> Message-ID: <873ak06u9u.fsf@squeak.fifthhorseman.net> On Tue 2008-09-16 08:38:59 -0400, Simon Josefsson wrote: > All, here are draft release notes for 2.6.0. Please review. > > ** The OpenPGP backend can parse (but not decrypt) encrypted secret keys. > Contributed by Daniel Kahn Gillmor . I'm (slowly) phasing out in favor of the simpler -- would it be OK to change this here? The rest of the announcement looks reasonable to me. Thanks for preparing it, Simon. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From simon at josefsson.org Tue Sep 16 16:33:47 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Sep 2008 16:33:47 +0200 Subject: draft release notes for 2.6.0 In-Reply-To: <873ak06u9u.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 16 Sep 2008 10:27:09 -0400") References: <87hc8g5kpo.fsf@mocca.josefsson.org> <873ak06u9u.fsf@squeak.fifthhorseman.net> Message-ID: <87vdww40tw.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > On Tue 2008-09-16 08:38:59 -0400, Simon Josefsson wrote: > >> All, here are draft release notes for 2.6.0. Please review. >> >> ** The OpenPGP backend can parse (but not decrypt) encrypted secret keys. >> Contributed by Daniel Kahn Gillmor . > > I'm (slowly) phasing out in favor > of the simpler -- would it be OK to change > this here? > > The rest of the announcement looks reasonable to me. Thanks for > preparing it, Simon. Changed, thanks for reading it. /Simon From simon at josefsson.org Tue Sep 16 17:15:37 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Sep 2008 17:15:37 +0200 Subject: GnuTLS 2.5.7, third release candidate for 2.6.0 Message-ID: <87iqsw3yw6.fsf@mocca.josefsson.org> The GnuTLS 2.5.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. The intention is to release a new stable branch on October 1th, unless problems are reported. Test this as if it were the new stable release! Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.7.tar.bz2 (4.9MB) ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.7.tar.bz2 Here is the OpenPGP signature: http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.7.tar.bz2.sig ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.7.tar.bz2.sig Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. /Simon * Version 2.5.7 (released 2008-09-16) ** libgnutls: New interfaces to get name of public key and signing algorithms. The functions are gnutls_sign_get_name and gnutls_pk_get_name. ** libgnutls: Don't crash when gnutls_credentials_set is called twice. ** libgnutls: Fix libgnutls shared library version. It wasn't properly incremented after adding symbols in the last release. ** manual: Now mention supported public key and public key signing algorithms. ** tests/openssl: initialize gnutls before use. ** tests/setcredcrash: New test to catch regressions of gnutls_credentials_set. ** GTK-DOC manual: mention new symbols in 2.6.x. Mention crypto.h functions. ** API and ABI modifications: gnutls_sign_get_name: ADDED gnutls_pk_get_name: ADDED From mrsam at courier-mta.com Wed Sep 17 02:31:22 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 16 Sep 2008 20:31:22 -0400 Subject: Formatting fix in gnutls-cli man page Message-ID: --- sources/gnutls/gnutls-2.5.7/doc/manpages/gnutls-cli.1~ 2008-09-01 13:54:36.000000000 -0400 +++ sources/gnutls/gnutls-2.5.7/doc/manpages/gnutls-cli.1 2008-09-16 20:17:16.000000000 -0400 @@ -106,10 +106,10 @@ MACs to enable (use \fBgnutls\-cli \-\-list\fR to show the supported MACs). .IP "\-\-kx \fIkx1 kx2...\fR" -Key exchange methods to enable (use gnutls\-cli \-\-list\fR to +Key exchange methods to enable (use \fBgnutls\-cli \-\-list\fR to show the supported methods). .IP "\-\-ctypes \fIcertType1 certType2...\fR" -Certificate types to enable (use gnutls\-cli \-\-list\fR to show +Certificate types to enable (use \fBgnutls\-cli \-\-list\fR to show the supported types). .IP "\-\-recordsize \fIinteger\fR" The maximum record size to advertize. From mrsam at courier-mta.com Wed Sep 17 03:06:35 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 16 Sep 2008 21:06:35 -0400 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST Message-ID: The following short test program runs when compiled against 2.4.0. Compiling it against 2.5.7 causes it to report a GNUTLS_E_INVALID_REQUEST from the second call to gnutls_x509_privkey_generate(). #include #include #include #include #include GCRY_THREAD_OPTION_PTHREAD_IMPL; int main() { int i; gcry_control(GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); gcry_control(GCRYCTL_ENABLE_QUICK_RANDOM); gnutls_global_init(); for (i=0; i<2; i++) { gnutls_x509_privkey_t privkey; int err; gnutls_x509_privkey_init(&privkey); err=gnutls_x509_privkey_generate(privkey, GNUTLS_PK_RSA, 512, 0); if (err < 0) { fprintf(stderr, "Error %d\n", err); exit(1); } gnutls_x509_privkey_deinit(privkey); } return(0); } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From simon at josefsson.org Wed Sep 17 10:32:38 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 17 Sep 2008 10:32:38 +0200 Subject: Formatting fix in gnutls-cli man page In-Reply-To: (Sam Varshavchik's message of "Tue, 16 Sep 2008 20:31:22 -0400") References: Message-ID: <87ej3j5g0p.fsf@mocca.josefsson.org> Thanks, applied. /Simon From simon at josefsson.org Wed Sep 17 10:35:07 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 17 Sep 2008 10:35:07 +0200 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST In-Reply-To: (Sam Varshavchik's message of "Tue, 16 Sep 2008 21:06:35 -0400") References: Message-ID: <87abe75fwk.fsf@mocca.josefsson.org> Sam Varshavchik writes: > The following short test program runs when compiled against > 2.4.0. Compiling it against 2.5.7 causes it to report a > GNUTLS_E_INVALID_REQUEST from the second call to > gnutls_x509_privkey_generate(). I can't reproduce this, adding this somewhere: printf ("vers %s %s\n", LIBGNUTLS_VERSION, gnutls_check_version (NULL)); Does print 2.5.7 for both, confirming that I really use 2.5.7. So it seems something else is required to reproduce this. Can you try to debug gnutls_x509_privkey_generate and see what happens? Does 'certtool -p' trigger the same problem for you? /Simon From wk at gnupg.org Wed Sep 17 11:06:58 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Sep 2008 11:06:58 +0200 Subject: gnutls_calloc Message-ID: <87iqsvf8el.fsf@wheatstone.g10code.de> Hi, as it happens I stepped over some gnutls code and noticed void * _gnutls_calloc (size_t nmemb, size_t size) { void *ret; size *= nmemb; ret = gnutls_malloc (size); if (ret != NULL) memset (ret, 0, size); return ret; } in lib/gnutls_mem.c (2.4.1 as well as in older versions). That code may lead to an integer overflow. I don't know how it is used and whether there is a way to actually exploit it but for general code cleanness, it should be fixed. Gnulib has xsize macros to use for this purpose or you may just change it this way: void * _gnutls_calloc (size_t nmemb, size_t size) { void *ret; size_t nbytes; nbytes = nmemb * size; if (size && nbytes / size != nmemb) { errno = ENOMEM; return NULL; } ret = gnutls_malloc (nbytes); if (ret != NULL) memset (ret, 0, nbytes); return ret; } Shalom-Salam, Werner -- Linux-Kongress 2008 + Hamburg + October 7-10 + www.linux-kongress.org Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From mrsam at courier-mta.com Wed Sep 17 13:01:38 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Wed, 17 Sep 2008 07:01:38 -0400 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST References: <87abe75fwk.fsf@mocca.josefsson.org> Message-ID: Simon Josefsson writes: > Sam Varshavchik writes: > >> The following short test program runs when compiled against >> 2.4.0. Compiling it against 2.5.7 causes it to report a >> GNUTLS_E_INVALID_REQUEST from the second call to >> gnutls_x509_privkey_generate(). > > I can't reproduce this, adding this somewhere: > > printf ("vers %s %s\n", LIBGNUTLS_VERSION, gnutls_check_version (NULL)); > > Does print 2.5.7 for both, confirming that I really use 2.5.7. So it Yes. > seems something else is required to reproduce this. Can you try to > debug gnutls_x509_privkey_generate and see what happens? > > Does 'certtool -p' trigger the same problem for you? Yes, certtool also bombs out. $ certtool -p Generating a 2048 bit RSA private key? certtool: privkey_generate: The request is invalid. I'm going to debug this. Debugging code compiled with -O is a pain. I'll need to recompile the library without optimization. The only thing I have to add is that this is on x86_64, which may or may not be a factor. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From simon at josefsson.org Wed Sep 17 13:02:58 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 17 Sep 2008 13:02:58 +0200 Subject: gnutls_calloc In-Reply-To: <87iqsvf8el.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 17 Sep 2008 11:06:58 +0200") References: <87iqsvf8el.fsf@wheatstone.g10code.de> Message-ID: <87vdwv2fx9.fsf@mocca.josefsson.org> Werner Koch writes: > Hi, > > as it happens I stepped over some gnutls code and noticed > > void * > _gnutls_calloc (size_t nmemb, size_t size) > { > void *ret; > size *= nmemb; > ret = gnutls_malloc (size); > if (ret != NULL) > memset (ret, 0, size); > return ret; > } > > in lib/gnutls_mem.c (2.4.1 as well as in older versions). > > That code may lead to an integer overflow. I don't know how it is used > and whether there is a way to actually exploit it but for general code > cleanness, it should be fixed. Gnulib has xsize macros to use for this > purpose or you may just change it this way: I used xsize macros instead (we already had xsize.h in lgl/). Please review: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=9e576dbebf3352b4ae9fc02f276a6b886f05f808 Thanks, Simon > void * > _gnutls_calloc (size_t nmemb, size_t size) > { > void *ret; > size_t nbytes; > > nbytes = nmemb * size; > if (size && nbytes / size != nmemb) > { > errno = ENOMEM; > return NULL; > } > > ret = gnutls_malloc (nbytes); > if (ret != NULL) > memset (ret, 0, nbytes); > return ret; > } > > > > Shalom-Salam, > > Werner > > > -- > Linux-Kongress 2008 + Hamburg + October 7-10 + www.linux-kongress.org > > Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From mrsam at courier-mta.com Wed Sep 17 13:07:24 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Wed, 17 Sep 2008 07:07:24 -0400 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST References: <87abe75fwk.fsf@mocca.josefsson.org> Message-ID: Simon Josefsson writes: > Sam Varshavchik writes: > >> The following short test program runs when compiled against >> 2.4.0. Compiling it against 2.5.7 causes it to report a >> GNUTLS_E_INVALID_REQUEST from the second call to >> gnutls_x509_privkey_generate(). > > I can't reproduce this, adding this somewhere: > > printf ("vers %s %s\n", LIBGNUTLS_VERSION, gnutls_check_version (NULL)); > > Does print 2.5.7 for both, confirming that I really use 2.5.7. So it > seems something else is required to reproduce this. Can you try to > debug gnutls_x509_privkey_generate and see what happens? > > Does 'certtool -p' trigger the same problem for you? The bug seems to be easy to spot. I think this is it: int gnutls_x509_privkey_generate (gnutls_x509_privkey_t key, gnutls_pk_algorithm_t algo, unsigned int bits, unsigned int flags) { int ret; unsigned int params_len; // . . . ret = _gnutls_rsa_generate_params (key?params, ¶ms_len, bits); This goes into: static int _generate_params (int algo, bigint_t *resarr, unsigned int *resarr_len, int bits) // . . . if (resarr && resarr_len && *resarr_len > params.params_nr) =========== Looks like *resarr_len points to uninitialized memory at this point. gnutls_x509_privkey_generate() never initialized params_len, as far as I can tell. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From wk at gnupg.org Wed Sep 17 13:09:38 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 17 Sep 2008 13:09:38 +0200 Subject: gnutls_calloc In-Reply-To: <87iqsvf8el.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 17 Sep 2008 11:06:58 +0200") References: <87iqsvf8el.fsf@wheatstone.g10code.de> Message-ID: <87abe7f2q5.fsf@wheatstone.g10code.de> Hi, A quick grep shows: lib/auth_cert.c: gnutls_calloc (1, sizeof (gnutls_datum_t) * ncerts); lib/gnutls_cert.c: *alg = gnutls_calloc (1, sizeof (gnutls_kx_algorithm_t) * i); lib/gnutls_session_pack.c: gnutls_calloc (1, sizeof (gnutls_datum_t) * info->ncerts); libextra/openssl_compat.c: gnutls_calloc (1, ca_certificate_list_size * sizeof (gnutls_x509_crt_t)); libextra/openssl_compat.c: crl_list = gnutls_calloc (1, crl_list_size * sizeof (gnutls_x509_crl_t)); Thus even with a correct gnutls_calloc, it is still vulernable to integer overflows. The above code (there might be more of this) needs to be changed to: gnutls_calloc (ncerts, sizeof (gnutls_datum_t)); and so on. Shalom-Salam, Werner -- Linux-Kongress 2008 + Hamburg + October 7-10 + www.linux-kongress.org Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Wed Sep 17 13:15:54 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 17 Sep 2008 13:15:54 +0200 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST In-Reply-To: (Sam Varshavchik's message of "Wed, 17 Sep 2008 07:07:24 -0400") References: <87abe75fwk.fsf@mocca.josefsson.org> Message-ID: <87iqsv2fbp.fsf@mocca.josefsson.org> Sam Varshavchik writes: > Simon Josefsson writes: > >> Sam Varshavchik writes: >> >>> The following short test program runs when compiled against >>> 2.4.0. Compiling it against 2.5.7 causes it to report a >>> GNUTLS_E_INVALID_REQUEST from the second call to >>> gnutls_x509_privkey_generate(). >> >> I can't reproduce this, adding this somewhere: >> >> printf ("vers %s %s\n", LIBGNUTLS_VERSION, gnutls_check_version (NULL)); >> >> Does print 2.5.7 for both, confirming that I really use 2.5.7. So it >> seems something else is required to reproduce this. Can you try to >> debug gnutls_x509_privkey_generate and see what happens? >> >> Does 'certtool -p' trigger the same problem for you? > > The bug seems to be easy to spot. I think this is it: > > int > gnutls_x509_privkey_generate (gnutls_x509_privkey_t key, > gnutls_pk_algorithm_t algo, unsigned int bits, > unsigned int flags) > { > int ret; > unsigned int params_len; > > // . . . > > ret = _gnutls_rsa_generate_params (key?params, ¶ms_len, bits); > > This goes into: > > static int > _generate_params (int algo, bigint_t *resarr, unsigned int *resarr_len, > int bits) > > // . . . > > if (resarr && resarr_len && *resarr_len > params.params_nr) > =========== > > Looks like *resarr_len points to uninitialized memory at this > point. gnutls_x509_privkey_generate() never initialized params_len, as > far as I can tell. Thanks for analysis, I guess it broke during the crypto.h conversion. How about this patch? diff --git a/lib/x509/privkey.c b/lib/x509/privkey.c index 82408c6..e5e6de3 100644 --- a/lib/x509/privkey.c +++ b/lib/x509/privkey.c @@ -1316,7 +1316,7 @@ gnutls_x509_privkey_generate (gnutls_x509_privkey_t key, unsigned int flags) { int ret; - unsigned int params_len; + unsigned int params_len = MAX_PRIV_PARAMS_SIZE; unsigned int i; if (key == NULL) Nikos, do you think this is correct? /Simon From simon at josefsson.org Wed Sep 17 13:30:55 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 17 Sep 2008 13:30:55 +0200 Subject: gnutls_calloc In-Reply-To: <87abe7f2q5.fsf@wheatstone.g10code.de> (Werner Koch's message of "Wed, 17 Sep 2008 13:09:38 +0200") References: <87iqsvf8el.fsf@wheatstone.g10code.de> <87abe7f2q5.fsf@wheatstone.g10code.de> Message-ID: <87ej3j2emo.fsf@mocca.josefsson.org> Werner Koch writes: > Hi, > > A quick grep shows: Thanks, fixed: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=e8cffa0e953fc4961a0d3b5575f175b2201d791c I went through the problems in libgnutls to look for exploitability: > lib/auth_cert.c: > gnutls_calloc (1, sizeof (gnutls_datum_t) * ncerts); This allocates a copy of something that is already allocated, so I don't think that can overflow. > lib/gnutls_cert.c: > *alg = gnutls_calloc (1, sizeof (gnutls_kx_algorithm_t) * i); This would overflow if the other end sent a very large number of certificates. The certificates are checked for appropriate key usage to increment the counter, so they would have to be at least somewhat correct certificates. Sending that many certificates seems difficult to use to overflow the counter. gnutls_kx_algorithm_t is an int, so this amounts to 2^30 certificates, which would run into the handshake size limit much earlier. > lib/gnutls_session_pack.c: > gnutls_calloc (1, sizeof (gnutls_datum_t) * info->ncerts); This unpacks user-supplied data. If the data were corrupt, it could overflow. However, if an attacker could influence this data, all the security is gone anyway since it contains master secret keys. /Simon From dkg at fifthhorseman.net Wed Sep 17 17:16:58 2008 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 17 Sep 2008 11:16:58 -0400 Subject: gnutls_calloc In-Reply-To: <87ej3j2emo.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed\, 17 Sep 2008 13\:30\:55 +0200") Message-ID: <87abe6g5ud.fsf@squeak.fifthhorseman.net> On Wed 2008-09-17 07:30:55 -0400, Simon Josefsson wrote: > Werner Koch writes: > >> lib/gnutls_session_pack.c: >> gnutls_calloc (1, sizeof (gnutls_datum_t) * info->ncerts); > > This unpacks user-supplied data. If the data were corrupt, it could > overflow. However, if an attacker could influence this data, all the > security is gone anyway since it contains master secret keys. When you say "user-supplied", do you mean the user running the local GnuTLS process, or the user controlling the remote peer? One concern is that an attacker could defeat the security provided by the TLS layer by introducing arbitrary master secret keys. But the possibility of executing arbitrary code based on the contents of a keyring is an entirely different threat, though, which it seems like GnuTLS shouldn't be vulnerable to. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From davefx at gmail.com Wed Sep 17 18:55:13 2008 From: davefx at gmail.com (=?UTF-8?Q?David_Mar=C3=ADn_Carre=C3=B1o?=) Date: Wed, 17 Sep 2008 18:55:13 +0200 Subject: Missing gnutls_x509_crq_sest_subject_alternative_name ? Message-ID: Hello all. As some of you probably know, I am developing gnoMint, a graphical X.509 CA manager. Some of my users are asking for creating certificates with subject alternative names. Until now, my procedure for creating new certificates involves the initial creation of certificate signing requests. Examining the API, it seems that there exists a "gnutls_x509_set_subject_alternative_name" that adds an alternative name extension to a certificate structure, but it doesn't exist a similar function for adding alternative name(s) to certificate requests. Is there a reason for that? Do you plan to add that function? Thanks a lot you all for this library. -- David Mar?n Carre?o From dkg at fifthhorseman.net Wed Sep 17 19:12:32 2008 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 17 Sep 2008 13:12:32 -0400 Subject: Missing gnutls_x509_crq_sest_subject_alternative_name ? In-Reply-To: ("David =?utf-8?Q?Mar=C3=ADn_Carre=C3=B1o=22's?= message of "Wed\, 17 Sep 2008 18\:55\:13 +0200") Message-ID: <87skryelxb.fsf@squeak.fifthhorseman.net> Hi David-- On Wed 2008-09-17 12:55:13 -0400, David Mar?n Carre?o wrote: > As some of you probably know, I am developing gnoMint, a graphical > X.509 CA manager. Cool, thanks for working on that! > Examining the API, it seems that there exists a > "gnutls_x509_set_subject_alternative_name" that adds an alternative > name extension to a certificate structure, but it doesn't exist a > similar function for adding alternative name(s) to certificate > requests. This question was just asked on help-gnutls: http://lists.gnu.org/archive/html/help-gnutls/2008-09/msg00013.html The answer seems to be that the capability doesn't exist yet in certtool. Looking at includes/gnutls/x509.h, i don't see any similar functionality for certificate requests in the library itself either. :( > Is there a reason for that? Do you plan to add that function? I don't think there is a good reason to *not* have it; adding this feature would be a really good thing, given how popular this particular v3 extension is today. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From simon at josefsson.org Thu Sep 18 03:54:31 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 18 Sep 2008 03:54:31 +0200 Subject: gnutls_calloc In-Reply-To: <87abe6g5ud.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 17 Sep 2008 11:16:58 -0400") References: <87ej3j2emo.fsf@mocca.josefsson.org> <87abe6g5ud.fsf@squeak.fifthhorseman.net> Message-ID: <874p4e1anc.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > On Wed 2008-09-17 07:30:55 -0400, Simon Josefsson wrote: > >> Werner Koch writes: >> >>> lib/gnutls_session_pack.c: >>> gnutls_calloc (1, sizeof (gnutls_datum_t) * info->ncerts); >> >> This unpacks user-supplied data. If the data were corrupt, it could >> overflow. However, if an attacker could influence this data, all the >> security is gone anyway since it contains master secret keys. > > When you say "user-supplied", do you mean the user running the local > GnuTLS process, or the user controlling the remote peer? Running the local process. The session pack code packs and unpacks all information about a certain session, and contains the symmetric keys used and so on. > One concern is that an attacker could defeat the security provided by > the TLS layer by introducing arbitrary master secret keys. But the > possibility of executing arbitrary code based on the contents of a > keyring is an entirely different threat, though, which it seems like > GnuTLS shouldn't be vulnerable to. Right, and it's fixed now. If you have time to analyze more in detail exactly how this could be exploited by an attacker, and write it down, that might be useful. I'm not sure there are any realistic scenarios where attackers have write control over session resumption information but cannot execute code as the gnutls process. /Simon From simon at josefsson.org Thu Sep 18 03:57:23 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 18 Sep 2008 03:57:23 +0200 Subject: Missing gnutls_x509_crq_sest_subject_alternative_name ? In-Reply-To: <87skryelxb.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 17 Sep 2008 13:12:32 -0400") References: <87skryelxb.fsf@squeak.fifthhorseman.net> Message-ID: <87zlm6z058.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > Hi David-- > > On Wed 2008-09-17 12:55:13 -0400, David Mar?n Carre?o wrote: > >> As some of you probably know, I am developing gnoMint, a graphical >> X.509 CA manager. > > Cool, thanks for working on that! > >> Examining the API, it seems that there exists a >> "gnutls_x509_set_subject_alternative_name" that adds an alternative >> name extension to a certificate structure, but it doesn't exist a >> similar function for adding alternative name(s) to certificate >> requests. > > This question was just asked on help-gnutls: > > http://lists.gnu.org/archive/html/help-gnutls/2008-09/msg00013.html > > The answer seems to be that the capability doesn't exist yet in > certtool. Looking at includes/gnutls/x509.h, i don't see any similar > functionality for certificate requests in the library itself > either. :( I think there are two separate issues here: 1) Support for adding more than one SAN to a certificate. 2) Support for adding SAN(s) to a certificate requests. >> Is there a reason for that? Do you plan to add that function? > > I don't think there is a good reason to *not* have it; adding this > feature would be a really good thing, given how popular this > particular v3 extension is today. Yup, patches welcome. :) I suspect it is not a difficult task, and could even make it for the 2.6.x release. /Simon From nmav at gnutls.org Thu Sep 18 08:33:26 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 18 Sep 2008 09:33:26 +0300 Subject: Missing gnutls_x509_crq_sest_subject_alternative_name ? In-Reply-To: References: Message-ID: <48D1F636.4050002@gnutls.org> David Mar?n Carre?o wrote: > Hello all. > > As some of you probably know, I am developing gnoMint, a graphical > X.509 CA manager. > > Some of my users are asking for creating certificates with subject > alternative names. > Until now, my procedure for creating new certificates involves the > initial creation of certificate signing requests. > > Examining the API, it seems that there exists a > "gnutls_x509_set_subject_alternative_name" that adds an alternative > name extension to a certificate structure, but it doesn't exist a > similar function for adding alternative name(s) to certificate > requests. > > Is there a reason for that? Do you plan to add that function? I believe the PKCS #10 format we use for requests doesn't explicitly support this field. I don't know what others (openssl/nss) do in this respect (maybe it can be added as a custom extension). I'll check it later today. regards, Nikos From arfrever.fta at gmail.com Thu Sep 18 19:33:34 2008 From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 18 Sep 2008 19:33:34 +0200 Subject: [PATCH] GnuTLS 2.5.7 fails to build Message-ID: <200809181933.41721.Arfrever.FTA@gmail.com> GnuTLS 2.5.7 fails to build: Making all in libextra make[2]: Entering directory `/var/tmp/portage/net-libs/gnutls-2.5.7/work/gnutls-2.5.7/libextra' make[3]: Entering directory `/var/tmp/portage/net-libs/gnutls-2.5.7/work/gnutls-2.5.7/libextra' /bin/sh ../libtool --tag=CC --mode=compile i686-pc-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lgl -I../lgl -I../lib -I../includes -I../includes -I../lib/minitasn1 -I/usr/include -pipe -march=athlon64 -msse3 -pipe -O3 -finline-limit=800 -fivopts -fno-ident -fomit-frame-pointer -Wno-pointer-sign -DG_DISABLE_ASSERT -DNDEBUG -Wno-pointer-sign -MT gnutls_extra.lo -MD -MP -MF .deps/gnutls_extra.Tpo -c -o gnutls_extra.lo gnutls_extra.c mkdir .libs i686-pc-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lgl -I../lgl -I../lib -I../includes -I../includes -I../lib/minitasn1 -I/usr/include -pipe -march=athlon64 -msse3 -pipe -O3 -finline-limit=800 -fivopts -fno-ident -fomit-frame-pointer -Wno-pointer-sign -DG_DISABLE_ASSERT -DNDEBUG -Wno-pointer-sign -MT gnutls_extra.lo -MD -MP -MF .deps/gnutls_extra.Tpo -c gnutls_extra.c -fPIC -DPIC -o .libs/gnutls_extra.o gnutls_extra.c:51: error: expected '=', ',', ';', 'asm' or '__attribute__' before '_gnutls_compression_algorithms' gnutls_extra.c: In function '_gnutls_add_lzo_comp': gnutls_extra.c:61: error: '_gnutls_compression_algorithms' undeclared (first use in this function) gnutls_extra.c:61: error: (Each undeclared identifier is reported only once gnutls_extra.c:61: error: for each function it appears in.) make[3]: *** [gnutls_extra.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.5.7/work/gnutls-2.5.7/libextra' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.5.7/work/gnutls-2.5.7/libextra' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-libs/gnutls-2.5.7/work/gnutls-2.5.7' make: *** [all] Error 2 The attached patch fixes this problem. -- Arfrever Frehtes Taifersar Arahesis -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-2.5.7-gnutls_compression_entry.patch Type: text/x-diff Size: 1350 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From simon at josefsson.org Fri Sep 19 08:06:02 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 19 Sep 2008 08:06:02 +0200 Subject: [PATCH] GnuTLS 2.5.7 fails to build In-Reply-To: <200809181933.41721.Arfrever.FTA@gmail.com> (Arfrever Frehtes Taifersar Arahesis's message of "Thu, 18 Sep 2008 19:33:34 +0200") References: <200809181933.41721.Arfrever.FTA@gmail.com> Message-ID: <87k5d8656d.fsf@mocca.josefsson.org> Arfrever Frehtes Taifersar Arahesis writes: > The attached patch fixes this problem. Thanks for the report, I solved it slightly differently. http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=b64e11fdc1deab66b8e0c5334fbb8c7eb1d8eb56 /Simon From nmav at gnutls.org Sat Sep 20 13:12:22 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 20 Sep 2008 14:12:22 +0300 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST In-Reply-To: <87iqsv2fbp.fsf@mocca.josefsson.org> References: <87abe75fwk.fsf@mocca.josefsson.org> <87iqsv2fbp.fsf@mocca.josefsson.org> Message-ID: <48D4DA96.5000105@gnutls.org> Simon Josefsson wrote: >> // . . . >> >> if (resarr && resarr_len && *resarr_len > params.params_nr) >> =========== >> >> Looks like *resarr_len points to uninitialized memory at this >> point. gnutls_x509_privkey_generate() never initialized params_len, as >> far as I can tell. > > Thanks for analysis, I guess it broke during the crypto.h conversion. > How about this patch? > > diff --git a/lib/x509/privkey.c b/lib/x509/privkey.c > index 82408c6..e5e6de3 100644 > --- a/lib/x509/privkey.c > +++ b/lib/x509/privkey.c > @@ -1316,7 +1316,7 @@ gnutls_x509_privkey_generate (gnutls_x509_privkey_t key, > unsigned int flags) > { > int ret; > - unsigned int params_len; > + unsigned int params_len = MAX_PRIV_PARAMS_SIZE; > unsigned int i; > > if (key == NULL) > > Nikos, do you think this is correct? Yes, indeed! regards, Nikos From nmav at gnutls.org Sat Sep 20 13:21:49 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 20 Sep 2008 14:21:49 +0300 Subject: Missing gnutls_x509_crq_sest_subject_alternative_name ? In-Reply-To: <87zlm6z058.fsf@mocca.josefsson.org> References: <87skryelxb.fsf@squeak.fifthhorseman.net> <87zlm6z058.fsf@mocca.josefsson.org> Message-ID: <48D4DCCD.6060109@gnutls.org> Simon Josefsson wrote: >> http://lists.gnu.org/archive/html/help-gnutls/2008-09/msg00013.html >> >> The answer seems to be that the capability doesn't exist yet in >> certtool. Looking at includes/gnutls/x509.h, i don't see any similar >> functionality for certificate requests in the library itself >> either. :( > > I think there are two separate issues here: > > 1) Support for adding more than one SAN to a certificate. I've just commited a fix for this issue. Now certtool can add multiple subject alternative names to a certificate. http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commit;h=4ed6efe3f9711b16fda407d90896ab67def7156d > 2) Support for adding SAN(s) to a certificate requests. I checked again PKCS #10 and didn't see any obvious way to include subject alternative names. Thus currently this project is outside my time restrictions. However if anyone submits a patch for this we'll be happy to include it. regards, Nikos From mrsam at courier-mta.com Sun Sep 21 05:43:04 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 20 Sep 2008 23:43:04 -0400 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST References: <87abe75fwk.fsf@mocca.josefsson.org> <87iqsv2fbp.fsf@mocca.josefsson.org> <48D4DA96.5000105@gnutls.org> Message-ID: Nikos Mavrogiannopoulos writes: >> --- a/lib/x509/privkey.c >> +++ b/lib/x509/privkey.c >> @@ -1316,7 +1316,7 @@ gnutls_x509_privkey_generate (gnutls_x509_privkey_t key, >> unsigned int flags) >> { >> int ret; >> - unsigned int params_len; >> + unsigned int params_len = MAX_PRIV_PARAMS_SIZE; >> unsigned int i; >> >> if (key == NULL) >> >> Nikos, do you think this is correct? > > Yes, indeed! No, even with this fix in place, this bug remains. In _generate_params(): if (resarr && resarr_len && *resarr_len > params.params_nr) Now, *resarr_len is initialized to 6, however, for RSA, params.params_nr is also 6, so this test still fails, and GNUTLS_E_INVALID_REQUEST gets returned. This line in gnutls_pk.c needs to be changed to: if (resarr && resarr_len && *resarr_len >= params.params_nr) ======================================================================= Unfortunately, there appears to be more problems with private key functions in 2.5.7. I'm now getting segfaults in gnutls_x509_privkey_import(). My debugging results are as follows: * I'm passing a DER-formatted DSA key for input to gnutls_x509_privkey_import(). * Execution reaches the following code in gnutls_x509_privkey_import(): key->pk_algorithm = GNUTLS_PK_RSA; key->key = _gnutls_privkey_decode_pkcs1_rsa_key (&_data, key); if (key->key == NULL) { key->pk_algorithm = GNUTLS_PK_DSA; key->key = decode_dsa_key (&_data, key); if (key->key == NULL) gnutls_assert (); } * _gnutls_privkey_decode_pkcs1_rsa_key() gets called, and tries to parse my DER-formatted DSA key: result = asn1_der_decoding (&pkey_asn, raw_key->data, raw_key->size, NULL); if (result != ASN1_SUCCESS) { gnutls_assert (); goto error; } Here, asn1_der_decoding() fails, and the "goto error" branch gets taken: error: asn1_delete_structure (&pkey_asn); _gnutls_mpi_release (&pk_params.params[0]); Unfortunately, this function never got far enough to initialize pk_params.params, so the entire array is uninitialized memory, _gnutls_mpi_release dereferences a random memory address, and segfaults. It looks to me like the temp_params local variable needs to be cleared. I tried the following patch, and it seems to fix the segfaults: --- lib/x509/privkey.c~ 2008-09-20 23:09:27.000000000 -0400 +++ lib/x509/privkey.c 2008-09-20 23:31:06.000000000 -0400 @@ -162,6 +162,8 @@ pk_params.params = temp_params; pk_params.params_nr = RSA_PRIVATE_PARAMS; + memset(temp_params, 0, sizeof(temp_params)); + if ((result = asn1_create_element (_gnutls_get_gnutls_asn (), "GNUTLS.RSAPrivateKey", This fixes the segfaults, and my app runs, but valgrind complains about a couple of memory leaks, in the same general bits of code: ==3339== 240 bytes in 5 blocks are definitely lost in loss record 2 of 9 ==3339== at 0x4A0739E: malloc (vg_replace_malloc.c:207) ==3339== by 0x4C689C4: wrap_gcry_pk_generate_params (pk-libgcrypt.c:773) ==3339== by 0x4C57881: _generate_params (gnutls_pk.c:527) ==3339== by 0x4C83591: gnutls_x509_privkey_generate (privkey.c:1354) and ==3339== 5,886 (168 direct, 5,718 indirect) bytes in 3 blocks are definitely lost in loss record 8 of 9 ==3339== at 0x4A05174: calloc (vg_replace_malloc.c:397) ==3339== by 0x3158C0A211: (within /usr/lib64/libtasn1.so.3.0.14) ==3339== by 0x3158C0A3F2: (within /usr/lib64/libtasn1.so.3.0.14) ==3339== by 0x3158C0A7BD: asn1_create_element (in /usr/lib64/libtasn1.so.3.0.14) ==3339== by 0x4C829B2: _gnutls_asn1_encode_rsa (privkey.c:1075) ==3339== by 0x4C83E0B: gnutls_x509_privkey_export (privkey.c:739) I'll try to chase these down? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From nmav at gnutls.org Sun Sep 21 09:30:08 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 21 Sep 2008 10:30:08 +0300 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST In-Reply-To: References: <87abe75fwk.fsf@mocca.josefsson.org> <87iqsv2fbp.fsf@mocca.josefsson.org> <48D4DA96.5000105@gnutls.org> Message-ID: <48D5F800.9090707@gnutls.org> Sam Varshavchik wrote: > Unfortunately, there appears to be more problems with private key > functions in 2.5.7. I'm now getting segfaults in > gnutls_x509_privkey_import(). My debugging results are as follows: > [...] > ==3339== 5,886 (168 direct, 5,718 indirect) bytes in 3 blocks are > definitely lost in loss record 8 of 9 > ==3339== at 0x4A05174: calloc (vg_replace_malloc.c:397) > ==3339== by 0x3158C0A211: (within /usr/lib64/libtasn1.so.3.0.14) > ==3339== by 0x3158C0A3F2: (within /usr/lib64/libtasn1.so.3.0.14) > ==3339== by 0x3158C0A7BD: asn1_create_element (in > /usr/lib64/libtasn1.so.3.0.14) > ==3339== by 0x4C829B2: _gnutls_asn1_encode_rsa (privkey.c:1075) > ==3339== by 0x4C83E0B: gnutls_x509_privkey_export (privkey.c:739) Hello Sam, I've commited fixes for these issues, so that latest code in git should not have these issues. All except the last one (quoted). It would be very helpful to give me some pointers on how to reproduce it. As far as I understand it should happening when gnutls_rsa_params_export_raw() is called? Thank you for all your work! regards, Nikos From simon at josefsson.org Sun Sep 21 13:02:09 2008 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 21 Sep 2008 13:02:09 +0200 Subject: GnuTLS 2.5.8, fourth release candidate for 2.6.0 Message-ID: <87tzc9n4ni.fsf@mocca.josefsson.org> The GnuTLS 2.5.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. The intention is to release a new stable branch on October 1th, unless problems are reported. Test this as if it were the new stable release! Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.8.tar.bz2 (4.9MB) ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.8.tar.bz2 Here is the OpenPGP signature: http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.8.tar.bz2.sig ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.8.tar.bz2.sig Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. /Simon * Version 2.5.8 (released 2008-09-21) ** certtool: updated so it can add several subject alternative names using the template file. ** libgnutls: gnutls_x509_crt_set_subject_alt_name() was added that can either set or append alternative names. It can also handle binary structures such as IP addresses. ** libgnutls: Fix crash in hashing code when using non-libgcrypt handlers. ** libgnutls: New function to set minimum acceptable SRP bits. The function is gnutls_srp_set_prime_bits. Tiny patch by Kevin Quick in . ** libgnutls: Check for overflows in gnutls_calloc and gnutls_secure_calloc. Also fix overflows in calls to those functions. Reported by Werner Koch . ** libgnutls-extra: Add function to work with Libgcrypt in FIPS mode. The function is gnutls_register_md5_handler. When libgcrypt is in FIPS mode, MD5 is disabled, but TLS normally requires use of MD5 in the PRF. ** Opencdk: Add calls to gnutls_assert to ease debugging. ** Indent code. ** API and ABI modifications: gnutls_srp_set_prime_bits: ADDED gnutls_register_md5_handler: ADDED gnutls_x509_crt_set_crl_dist_points2: ADDED gnutls_x509_crt_set_subject_alt_name: ADDED From simon at josefsson.org Sun Sep 21 13:07:33 2008 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 21 Sep 2008 13:07:33 +0200 Subject: How to work with Libgcrypt in FIPS mode In-Reply-To: <87tzc9n4ni.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Sun, 21 Sep 2008 13:02:09 +0200") References: <87tzc9n4ni.fsf@mocca.josefsson.org> Message-ID: <87prmxn4ei.fsf@mocca.josefsson.org> Simon Josefsson writes: > ** libgnutls-extra: Add function to work with Libgcrypt in FIPS mode. > The function is gnutls_register_md5_handler. When libgcrypt is in > FIPS mode, MD5 is disabled, but TLS normally requires use of MD5 in > the PRF. Some more explanation related to this may be in order. If you have libgcrypt 1.4.3 or later, and create a file /etc/gcrypt/fips_enabled libgcrypt will run in FIPS mode. One consequence of this is that MD5 is disabled... alas, TLS typically requires MD5, so GnuTLS will not be very useful with Libgcrypt in FIPS mode. However, if you link your application to libgnutls-extra and call gnutls_register_md5_handler, GnuTLS will begin to use an internal MD5 implementation instead of calling libgcrypt. GnuTLS should then be fully functional. The command line tools gnutls-cli, gnutls-serv, and certtool use this function, and I can successfully use libgcrypt in FIPS mode and connect to various sites. Note that this doesn't make GnuTLS FIPS certified, but it is a step forward. I believe it is possible to get an exception for MD5 as used in TLS, and possible all of that code could be moved down into libgcrypt. In theory I don't see any reason why GnuTLS can't be FIPS certified. Someone needs to sponsor this though. /Simon From mrsam at courier-mta.com Sun Sep 21 19:30:44 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 21 Sep 2008 13:30:44 -0400 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST References: <87abe75fwk.fsf@mocca.josefsson.org> <87iqsv2fbp.fsf@mocca.josefsson.org> <48D4DA96.5000105@gnutls.org> <48D5F800.9090707@gnutls.org> Message-ID: Nikos Mavrogiannopoulos writes: > Sam Varshavchik wrote: > >> Unfortunately, there appears to be more problems with private key >> functions in 2.5.7. I'm now getting segfaults in >> gnutls_x509_privkey_import(). My debugging results are as follows: >> > [...] >> ==3339== 5,886 (168 direct, 5,718 indirect) bytes in 3 blocks are >> definitely lost in loss record 8 of 9 >> ==3339== at 0x4A05174: calloc (vg_replace_malloc.c:397) >> ==3339== by 0x3158C0A211: (within /usr/lib64/libtasn1.so.3.0.14) >> ==3339== by 0x3158C0A3F2: (within /usr/lib64/libtasn1.so.3.0.14) >> ==3339== by 0x3158C0A7BD: asn1_create_element (in >> /usr/lib64/libtasn1.so.3.0.14) >> ==3339== by 0x4C829B2: _gnutls_asn1_encode_rsa (privkey.c:1075) >> ==3339== by 0x4C83E0B: gnutls_x509_privkey_export (privkey.c:739) > > Hello Sam, > I've commited fixes for these issues, so that latest code in git should > not have these issues. All except the last one (quoted). It would be > very helpful to give me some pointers on how to reproduce it. > > As far as I understand it should happening when > gnutls_rsa_params_export_raw() is called? The following minimal program triggers the leak: #include #include #include #include #include #include GCRY_THREAD_OPTION_PTHREAD_IMPL; int main() { int i; gnutls_rsa_params_t rsa; size_t buflen; gcry_control(GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); gcry_control(GCRYCTL_ENABLE_QUICK_RANDOM); gnutls_global_init(); gnutls_rsa_params_init(&rsa); printf("vers %s %s\n", LIBGNUTLS_VERSION, gnutls_check_version (NULL)); gnutls_rsa_params_generate2(rsa, 1024); gnutls_rsa_params_export_pkcs1(rsa, GNUTLS_X509_FMT_DER, NULL, &buflen); char b[buflen]; gnutls_rsa_params_export_pkcs1(rsa, GNUTLS_X509_FMT_DER, b, &buflen); gnutls_rsa_params_deinit(rsa); return(0); } The leak gets triggered only when gnutls_rsa_params_export_pkcs1() gets invoked twice, once with a NULL buffer pointer, to compute the buffer size, and a second time with the real buffer pointer. Invoking it just once is not sufficient. What looks like is happening is that in gnutls_x509_privkey_export(): case GNUTLS_PK_RSA: ret = _gnutls_asn1_encode_rsa (&key->key, key->params); First time through, key->key is NULL, and _gnutls_asn1_encode_rsa() allocates it using asn1_create_element(). On the second call, key->key holds the previously allocated buffer, but _gnutls_asn1_encode_rsa() allocates a new one, without freeing the first one, and leaks it. I also see similar logic for the GNUTLS_PK_DSA case, and _gnutls_asn1_encode_dsa(), so there may also be a similar leak there. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From nmav at gnutls.org Sun Sep 21 22:32:08 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 21 Sep 2008 23:32:08 +0300 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST In-Reply-To: References: <87abe75fwk.fsf@mocca.josefsson.org> <87iqsv2fbp.fsf@mocca.josefsson.org> <48D4DA96.5000105@gnutls.org> <48D5F800.9090707@gnutls.org> Message-ID: Fix commited. Thank you! On Sun, Sep 21, 2008 at 8:30 PM, Sam Varshavchik wrote: > Nikos Mavrogiannopoulos writes: > >> Sam Varshavchik wrote: >> >>> Unfortunately, there appears to be more problems with private key >>> functions in 2.5.7. I'm now getting segfaults in >>> gnutls_x509_privkey_import(). My debugging results are as follows: >>> >> [...] >>> >>> ==3339== 5,886 (168 direct, 5,718 indirect) bytes in 3 blocks are >>> definitely lost in loss record 8 of 9 >>> ==3339== at 0x4A05174: calloc (vg_replace_malloc.c:397) >>> ==3339== by 0x3158C0A211: (within /usr/lib64/libtasn1.so.3.0.14) >>> ==3339== by 0x3158C0A3F2: (within /usr/lib64/libtasn1.so.3.0.14) >>> ==3339== by 0x3158C0A7BD: asn1_create_element (in >>> /usr/lib64/libtasn1.so.3.0.14) >>> ==3339== by 0x4C829B2: _gnutls_asn1_encode_rsa (privkey.c:1075) >>> ==3339== by 0x4C83E0B: gnutls_x509_privkey_export (privkey.c:739) >> >> Hello Sam, >> I've commited fixes for these issues, so that latest code in git should >> not have these issues. All except the last one (quoted). It would be >> very helpful to give me some pointers on how to reproduce it. >> >> As far as I understand it should happening when >> gnutls_rsa_params_export_raw() is called? > > The following minimal program triggers the leak: > > #include > #include > #include > #include > #include > #include > > GCRY_THREAD_OPTION_PTHREAD_IMPL; > > int main() > { > int i; > gnutls_rsa_params_t rsa; > size_t buflen; > > gcry_control(GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); > gcry_control(GCRYCTL_ENABLE_QUICK_RANDOM); > gnutls_global_init(); > > gnutls_rsa_params_init(&rsa); > > printf("vers %s %s\n", LIBGNUTLS_VERSION, gnutls_check_version > (NULL)); > > gnutls_rsa_params_generate2(rsa, 1024); > > gnutls_rsa_params_export_pkcs1(rsa, GNUTLS_X509_FMT_DER, NULL, > &buflen); > > char b[buflen]; > > gnutls_rsa_params_export_pkcs1(rsa, GNUTLS_X509_FMT_DER, b, &buflen); > > gnutls_rsa_params_deinit(rsa); > > return(0); > } > > > The leak gets triggered only when gnutls_rsa_params_export_pkcs1() gets > invoked twice, once with a NULL buffer pointer, to compute the buffer size, > and a second time with the real buffer pointer. Invoking it just once is not > sufficient. > > What looks like is happening is that in gnutls_x509_privkey_export(): > > case GNUTLS_PK_RSA: > ret = _gnutls_asn1_encode_rsa (&key->key, key->params); > > First time through, key->key is NULL, and _gnutls_asn1_encode_rsa() > allocates it using asn1_create_element(). On the second call, key->key holds > the previously allocated buffer, but _gnutls_asn1_encode_rsa() allocates a > new one, without freeing the first one, and leaks it. > > I also see similar logic for the GNUTLS_PK_DSA case, and > _gnutls_asn1_encode_dsa(), so there may also be a similar leak there. > > > From mrsam at courier-mta.com Mon Sep 22 04:17:20 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 21 Sep 2008 22:17:20 -0400 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST References: <87abe75fwk.fsf@mocca.josefsson.org> <87iqsv2fbp.fsf@mocca.josefsson.org> <48D4DA96.5000105@gnutls.org> <48D5F800.9090707@gnutls.org> Message-ID: Nikos Mavrogiannopoulos writes: > Fix commited. Thank you! I ran other parts of my app with valgrind compiled against the 2.5.8 tarball, and I found three more leaks. The first one: ==1980== 264 (72 direct, 192 indirect) bytes in 3 blocks are definitely lost in loss record 5 of 11 ==1980== at 0x4A0739E: malloc (vg_replace_malloc.c:207) ==1980== by 0x31584081D0: do_malloc (global.c:558) ==1980== by 0x31584083D8: _gcry_malloc (global.c:582) ==1980== by 0x31584083FF: _gcry_xmalloc (global.c:717) ==1980== by 0x31584443A9: _gcry_mpi_alloc (mpiutil.c:53) ==1980== by 0x315844138A: _gcry_mpi_scan (mpicoder.c:357) ==1980== by 0x3158409D44: _gcry_sexp_nth_mpi (sexp.c:691) ==1980== by 0x4C7600D: _wrap_gcry_pk_sign (pk-libgcrypt.c:380) ==1980== by 0x4C5E86E: _gnutls_pkcs1_rsa_encrypt (gnutls_pk.c:147) ==1980== by 0x4C68835: _gnutls_sign (gnutls_sig.c:234) ==1980== by 0x4C9F601: pkcs1_rsa_sign (sign.c:160) ==1980== by 0x4C9F86C: _gnutls_x509_sign (sign.c:226) ==1980== by 0x4C9FACA: _gnutls_x509_sign_tbs (sign.c:290) ==1980== by 0x4C9FCD5: _gnutls_x509_pkix_sign (sign.c:348) ==1980== by 0x4CAADC9: gnutls_x509_crt_sign2 (x509_write.c:666) I think the problem here is in _wrap_gcry_pk_sign(). Line 380: res[0] = gcry_sexp_nth_mpi (list, 1, 0); The return value from gcry_sexp_nth_mpi() appears to be the leak, because on a succesful return, this value never gets deallocated. Also, I see that in line 345-367, res[0] and res[1] gets allocated in this fashion, but never get allocated. I see all these cleanup deallocations in the cleanup: block, at the end of the function, and I see that a number of error paths lead there even after the corresponding object is already deallocated. If _gnutls_mpi_release() and gcry_sexp_release() can be safely called on an object that they've already deallocated, it'll probably be easier just to remove the return 0 statement, and let cleanup: handle whatever's not been deallocated already. The second leak: ==1980== 564 bytes in 18 blocks are definitely lost in loss record 7 of 11 ==1980== at 0x4A0739E: malloc (vg_replace_malloc.c:207) ==1980== by 0x4C8B7E4: _gnutls_x509_write_value (common.c:1071) ==1980== by 0x4C925E7: set_extension (extensions.c:305) ==1980== by 0x4C92A71: _gnutls_x509_crt_set_extension (extensions.c:432) This one's easy. _gnutls_x509_write_value(): val.data = gnutls_malloc (asize); // <----- The allocated memory if (val.data == NULL) { gnutls_assert (); result = GNUTLS_E_MEMORY_ERROR; goto cleanup; } if (str) { // Not important } else { val.data = data->data; // <----------- Leaks the malloced pointer val.size = data->size; } The third leak: ==1980== 2,370 (504 direct, 1,866 indirect) bytes in 9 blocks are definitely lost in loss record 10 of 11 ==1980== at 0x4A05174: calloc (vg_replace_malloc.c:397) ==1980== by 0x3158C0A211: (within /usr/lib64/libtasn1.so.3.0.14) ==1980== by 0x3158C0A3F2: (within /usr/lib64/libtasn1.so.3.0.14) ==1980== by 0x3158C0A5C2: (within /usr/lib64/libtasn1.so.3.0.14) ==1980== by 0x3158C0A7E8: asn1_create_element (in /usr/lib64/libtasn1.so.3.0.14) ==1980== by 0x4C88228: _gnutls_x509_encode_and_write_attribute (dn.c:665) ==1980== by 0x4C88D42: _gnutls_x509_set_dn_oid (dn.c:915) ==1980== by 0x4CAA02B: gnutls_x509_crt_set_dn_by_oid (x509_write.c:74) In _gnutls_x509_encode_and_write_attribute(), there appears to be multiple execution paths -- including the successful execution fails, that does not call "asn1_delete_structure (&c2)" in order to release what was allocated on line 665 by calling asn1_create_element(). Looks like asn1_delete_structure(&c2) needs to be shoved right before the comment on line 716, after asn1_write_value() succeeds. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mrsam at courier-mta.com Tue Sep 23 04:56:12 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 22 Sep 2008 22:56:12 -0400 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST References: <87abe75fwk.fsf@mocca.josefsson.org> Message-ID: Got some more leaks. All of these leaks came out when I ran valgrind on some test code that sets up a TLS session, then requests a rehandshake. Setting up a debugging environment, given the nature of the application, was rather difficult, I tried to find the source of the leak by eyeballing the code, I think I can see where the problem is. ==8519== at 0x4A05174: calloc (vg_replace_malloc.c:397) ==8519== by 0x317D24477E: _gnutls_copy_certificate_auth_info (auth_cert.c:81) ==8519== by 0x317D2464E8: _gnutls_proc_x509_server_certificate (auth_cert.c:1022) ==8519== by 0x317D247079: _gnutls_proc_cert_server_certificate (auth_cert.c:1257) ==8519== by 0x317D233DE4: _gnutls_recv_server_certificate (gnutls_kx.c:719) ==8519== by 0x317D22E6AD: _gnutls_handshake_client (gnutls_handshake.c:2359) ==8519== by 0x317D22E268: gnutls_handshake (gnutls_handshake.c:2262) I think this is a leak in _gnutls_copy_certificate_auth_info(): if (ncerts == 0) { info->raw_certificate_list = NULL; info->ncerts = 0; return 0; } info->raw_certificate_list = gnutls_calloc (ncerts, sizeof (gnutls_datum_t)); I think what's happening is that on an initial handshake, the raw_certificate_list was allocated. On the rehandshake, the same code allocated a new list, and overwrote the previously allocated list, leaking it. I think a check is needed here, before the if() statement, to deallocate any previously allocated list, from an earlier handshake. ==8519== at 0x4A0739E: malloc (vg_replace_malloc.c:207) ==8519== by 0x317D23AEA0: _gnutls_set_datum_m (gnutls_datum.c:80) ==8519== by 0x317D242342: _gnutls_set_keys (gnutls_constate.c:130) ==8519== by 0x317D242F90: _gnutls_set_write_keys (gnutls_constate.c:424) ==8519== by 0x317D243AC4: _gnutls_write_connection_state_init (gnutls_constate.c:721) ==8519== by 0x317D22ECF0: _gnutls_send_handshake_final (gnutls_handshake.c:2462) ==8519== by 0x317D22F89C: _gnutls_handshake_common (gnutls_handshake.c:2675) ==8519== by 0x317D22E2B1: gnutls_handshake (gnutls_handshake.c:2279) I see that _gnutls_set_datum_m() allocates memory for the new datum object and doesn't check whether the datum object passed to it already points to a previous memory block that was, presumably, allocated earlier. So, it looks to me like when _gnutls_set_keys(): if (_gnutls_sset_datum (&session->cipher_specs.client_write_mac_secret, &key_block[pos], hash_size) < 0) { gnutls_free (key_block); return GNUTLS_E_MEMORY_ERROR; } So, on a rehandshake, this would leak the memory that client_write_mac_secret points to, that was allocated during the initial handshake. What I do not understand is why there's no corresponding leak for server_write_mac_secret datum object, that's allocated immediately following the above code. ==8519== 1,536 bytes in 6 blocks are definitely lost in loss record 33 of 35 ==8519== at 0x4A0739E: malloc (vg_replace_malloc.c:207) ==8519== by 0x317D23E8D3: _gnutls_mpi_randomize (gnutls_mpi.c:51) ==8519== by 0x317D23258F: gnutls_calc_dh_secret (gnutls_dh.c:65) ==8519== by 0x317D254FB2: _gnutls_dh_common_print_server_kx (auth_dh_common.c:316) ==8519== by 0x317D24A46D: gen_dhe_server_kx (auth_dhe.c:135) ==8519== by 0x317D232F9C: _gnutls_send_server_kx_message (gnutls_kx.c:199) ==8519== by 0x317D22F2EA: _gnutls_handshake_server (gnutls_handshake.c:2593) ==8519== by 0x317D22E276: gnutls_handshake (gnutls_handshake.c:2266) This does not appear to be rehandshake-related. _gnutls_mpi_randomize() mallocs a buffer, but does not appear to free it, on its succesfull execution path, only on its error path. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From n.mavrogiannopoulos at gmail.com Tue Sep 23 10:22:10 2008 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue, 23 Sep 2008 11:22:10 +0300 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST In-Reply-To: References: <87abe75fwk.fsf@mocca.josefsson.org> Message-ID: Thank you. I'll try to apply fixes as soon. regards, Nikos On Tue, Sep 23, 2008 at 5:56 AM, Sam Varshavchik wrote: > Got some more leaks. All of these leaks came out when I ran valgrind on some > test code that sets up a TLS session, then requests a rehandshake. Setting > up a debugging environment, given the nature of the application, was rather > difficult, I tried to find the source of the leak by eyeballing the code, I > think I can see where the problem is. > > ==8519== at 0x4A05174: calloc (vg_replace_malloc.c:397) > ==8519== by 0x317D24477E: _gnutls_copy_certificate_auth_info > (auth_cert.c:81) > ==8519== by 0x317D2464E8: _gnutls_proc_x509_server_certificate > (auth_cert.c:1022) > ==8519== by 0x317D247079: _gnutls_proc_cert_server_certificate > (auth_cert.c:1257) > ==8519== by 0x317D233DE4: _gnutls_recv_server_certificate > (gnutls_kx.c:719) > ==8519== by 0x317D22E6AD: _gnutls_handshake_client > (gnutls_handshake.c:2359) > ==8519== by 0x317D22E268: gnutls_handshake (gnutls_handshake.c:2262) > > I think this is a leak in _gnutls_copy_certificate_auth_info(): > > if (ncerts == 0) > { > info->raw_certificate_list = NULL; > info->ncerts = 0; > return 0; > } > > info->raw_certificate_list = > gnutls_calloc (ncerts, sizeof (gnutls_datum_t)); > > I think what's happening is that on an initial handshake, the > raw_certificate_list was allocated. On the rehandshake, the same code > allocated a new list, and overwrote the previously allocated list, leaking > it. > > I think a check is needed here, before the if() statement, to deallocate any > previously allocated list, from an earlier handshake. > > ==8519== at 0x4A0739E: malloc (vg_replace_malloc.c:207) > ==8519== by 0x317D23AEA0: _gnutls_set_datum_m (gnutls_datum.c:80) > ==8519== by 0x317D242342: _gnutls_set_keys (gnutls_constate.c:130) > ==8519== by 0x317D242F90: _gnutls_set_write_keys (gnutls_constate.c:424) > ==8519== by 0x317D243AC4: _gnutls_write_connection_state_init > (gnutls_constate.c:721) > ==8519== by 0x317D22ECF0: _gnutls_send_handshake_final > (gnutls_handshake.c:2462) > ==8519== by 0x317D22F89C: _gnutls_handshake_common > (gnutls_handshake.c:2675) > ==8519== by 0x317D22E2B1: gnutls_handshake (gnutls_handshake.c:2279) > > I see that _gnutls_set_datum_m() allocates memory for the new datum object > and doesn't check whether the datum object passed to it already points to a > previous memory block that was, presumably, allocated earlier. > > So, it looks to me like when _gnutls_set_keys(): > > if (_gnutls_sset_datum > (&session->cipher_specs.client_write_mac_secret, > &key_block[pos], hash_size) < 0) > { > gnutls_free (key_block); > return GNUTLS_E_MEMORY_ERROR; > } > > So, on a rehandshake, this would leak the memory that > client_write_mac_secret points to, that was allocated during the initial > handshake. > > What I do not understand is why there's no corresponding leak for > server_write_mac_secret datum object, that's allocated immediately following > the above code. > > ==8519== 1,536 bytes in 6 blocks are definitely lost in loss record 33 of 35 > ==8519== at 0x4A0739E: malloc (vg_replace_malloc.c:207) > ==8519== by 0x317D23E8D3: _gnutls_mpi_randomize (gnutls_mpi.c:51) > ==8519== by 0x317D23258F: gnutls_calc_dh_secret (gnutls_dh.c:65) > ==8519== by 0x317D254FB2: _gnutls_dh_common_print_server_kx > (auth_dh_common.c:316) > ==8519== by 0x317D24A46D: gen_dhe_server_kx (auth_dhe.c:135) > ==8519== by 0x317D232F9C: _gnutls_send_server_kx_message > (gnutls_kx.c:199) > ==8519== by 0x317D22F2EA: _gnutls_handshake_server > (gnutls_handshake.c:2593) > ==8519== by 0x317D22E276: gnutls_handshake (gnutls_handshake.c:2266) > > This does not appear to be rehandshake-related. > > _gnutls_mpi_randomize() mallocs a buffer, but does not appear to free it, on > its succesfull execution path, only on its error path. > > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > > From jonathan at dyalog.com Tue Sep 23 13:20:27 2008 From: jonathan at dyalog.com (Jonathan Manktelow) Date: Tue, 23 Sep 2008 12:20:27 +0100 Subject: Bug in gnutls_x509_crt_list_import Message-ID: <000001c91d6e$63059c90$2910d5b0$@com> Hi, There is a buffer overrun bug in gnutls_x509_crt_list_import (from gnutls 4.2.2), if it's given a file containing multiple PEM certificates, each of which is separated by more than one character (such as in a file with windows line endings) In gnutls_x509_crt_list_import When reading the second, and all subsequent, certificates the lines tmp.data = (unsigned char *) ptr; tmp.size = size; setup a temporary buffer for gnutls_x509_crt_import to read from. However the size variable is not set correctly. Changing these lines to tmp.data = (unsigned char *) ptr; size = data->size - (ptr - (char *) data->data); tmp.size = size; fixes it. Please can you confirm if this is a bug, and if so if the fix is correct! Thanks, Jonathan Manktelow From nmav at gnutls.org Tue Sep 23 19:38:01 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 23 Sep 2008 20:38:01 +0300 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST In-Reply-To: References: <87abe75fwk.fsf@mocca.josefsson.org> Message-ID: <48D92979.4020003@gnutls.org> Sam Varshavchik wrote: > Got some more leaks. All of these leaks came out when I ran valgrind on > some test code that sets up a TLS session, then requests a rehandshake. > Setting up a debugging environment, given the nature of the application, > was rather difficult, I tried to find the source of the leak by > eyeballing the code, I think I can see where the problem is. I've commited a fix for all of the issues. I changed also the logic to avoid using malloc in some places (requires C99). Please do not hesitate to contact us if more issues are found. regards, Nikos From nmav at gnutls.org Tue Sep 23 20:04:59 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 23 Sep 2008 21:04:59 +0300 Subject: Bug in gnutls_x509_crt_list_import In-Reply-To: <000001c91d6e$63059c90$2910d5b0$@com> References: <000001c91d6e$63059c90$2910d5b0$@com> Message-ID: <48D92FCB.9000603@gnutls.org> Jonathan Manktelow wrote: > Hi, > There is a buffer overrun bug in gnutls_x509_crt_list_import (from gnutls > 4.2.2), if it's given a file containing multiple PEM certificates, each of > which is separated by more than one character (such as in a file with > windows line endings) > > In gnutls_x509_crt_list_import > When reading the second, and all subsequent, certificates the lines > > tmp.data = (unsigned char *) ptr; > tmp.size = size; > > setup a temporary buffer for gnutls_x509_crt_import to read from. However > the size variable is not set correctly. > Changing these lines to > > tmp.data = (unsigned char *) ptr; > size = data->size - (ptr - (char *) data->data); > tmp.size = size; > > fixes it. > Please can you confirm if this is a bug, and if so if the fix is correct! Your study and patch of the issue looks correct. Patch applied. Thank you! regards, Nikos From simon at josefsson.org Thu Sep 25 10:21:14 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 25 Sep 2008 10:21:14 +0200 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST In-Reply-To: <48D92979.4020003@gnutls.org> (Nikos Mavrogiannopoulos's message of "Tue, 23 Sep 2008 20:38:01 +0300") References: <87abe75fwk.fsf@mocca.josefsson.org> <48D92979.4020003@gnutls.org> Message-ID: <87wsh0ws91.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > I've commited a fix for all of the issues. I changed also the logic to > avoid using malloc in some places (requires C99). I don't think we can use c99 constructs unconditionally, c99 is not sufficiently widely supported yet. I've reverted the gnutls_constate.c patch, and also the gnutls_mpi.c patch but I fixed that memory leak. Possibly _gnutls_set_keys could use a goto to a cleanup section. Ideally the function should be rewritten and be much shorter, but I think we are too close to a stable release to do that now. It can be applied in one week when 2.6.0 has been released. /Simon From nmav at gnutls.org Thu Sep 25 11:35:16 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 25 Sep 2008 12:35:16 +0300 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST In-Reply-To: <87wsh0ws91.fsf@mocca.josefsson.org> References: <87abe75fwk.fsf@mocca.josefsson.org> <48D92979.4020003@gnutls.org> <87wsh0ws91.fsf@mocca.josefsson.org> Message-ID: I don't like mallocs for short sized buffers I think it is better to use a fixed buffer that will have maximum size enough to hold data. On Thu, Sep 25, 2008 at 11:21 AM, Simon Josefsson wrote: > Nikos Mavrogiannopoulos writes: > >> I've commited a fix for all of the issues. I changed also the logic to >> avoid using malloc in some places (requires C99). > > I don't think we can use c99 constructs unconditionally, c99 is not > sufficiently widely supported yet. I've reverted the gnutls_constate.c > patch, and also the gnutls_mpi.c patch but I fixed that memory leak. > > Possibly _gnutls_set_keys could use a goto to a cleanup section. > Ideally the function should be rewritten and be much shorter, but I > think we are too close to a stable release to do that now. It can be > applied in one week when 2.6.0 has been released. > > /Simon > From simon at josefsson.org Thu Sep 25 11:45:13 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 25 Sep 2008 11:45:13 +0200 Subject: 2.5.7 gnutls_x509_privkey_generate() returns GNUTLS_E_INVALID_REQUEST In-Reply-To: (Nikos Mavrogiannopoulos's message of "Thu, 25 Sep 2008 12:35:16 +0300") References: <87abe75fwk.fsf@mocca.josefsson.org> <48D92979.4020003@gnutls.org> <87wsh0ws91.fsf@mocca.josefsson.org> Message-ID: <87iqskwod2.fsf@mocca.josefsson.org> "Nikos Mavrogiannopoulos" writes: > I don't like mallocs for short sized buffers I think it is better to > use a fixed buffer that will have maximum size enough to hold data. I agree. Some of the buffers in gnutls_constate.c and gnutls_mpi.c are arbitrary sized though, but have natural upper limits. Maybe you could re-apply your patch without using C99 but instead using some CPP define that holds the largest possible value? The gnutls_mpi.c code could probably use a cut-off, if users request a random mpi larger than, say, 16k bits, then use gnutls_secure_malloc. Thanks, /Simon From simon at josefsson.org Thu Sep 25 13:39:47 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 25 Sep 2008 13:39:47 +0200 Subject: request for help: freshmeat.net gnutls writer Message-ID: <87abdwtpx8.fsf@mocca.josefsson.org> Hi! Updating freshmeat.net to point to the latest gnutls versions is tiresome, and I haven't had time to do it since the 2.0.0 release. If someone else, or a group of people, wants to help with this, that would be appreciated. You need to read the NEWS file and condense it down to a few sentences for each release. /Simon From n.mavrogiannopoulos at gmail.com Sat Sep 27 20:00:11 2008 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sat, 27 Sep 2008 21:00:11 +0300 Subject: request for help: openpgp under windows doesn't work In-Reply-To: <87prn45nxs.fsf@mocca.josefsson.org> References: <87tzcg5s50.fsf@mocca.josefsson.org> <87prn45nxs.fsf@mocca.josefsson.org> Message-ID: <48DE74AB.8040706@gmail.com> Simon Josefsson wrote: > "Nikos Mavrogiannopoulos" writes: > >> On Tue, Sep 16, 2008 at 12:58 PM, Simon Josefsson wrote: >>> Windows builds of GnuTLS seem to have some problems in the opencdk >>> library, which causes parsing of packets to fail. This can be seen with >>> the 'pgps2kgnu' self-test, which unfortunately results the same error as >>> if the problem it is supposed to test for exists (I've made sure the s2k >>> patch is still working). The problem appears to be in the low-level >>> stream reading code in opencdk. >>> It could be that pgp has never worked under Windows, since the pgp self >>> tests have been disabled because of missing fork(). I'm inclined to >>> disable openpgp authentication under windows for the 2.6.x build, and >>> note in the release notes that it doesn't work currently. >> I had test the openpgp code in windows a while (year) ago and it >> worked. I had some issues though, functions like tmpfile() could only >> be used if run as administrator in windows. Can it be that case? > > I am using wine. I didn't get a hard failure -- instead I got an EOF at > a surprising position (middle of stream). Maybe some fseek problem... > I suspected binary vs text too, but it looks like the files are opened > in binary mode. The idea of using a temporary file seemed somewhat > strange to me, and I'm not familiar with the code so it was hard to > debug. > >>> Help in debugging the problem would be appreciated, it is easy to get a >>> windows build and debug it under debian, see >>> . I tried to do this, but I'm not >>> familiar with opencdk and didn't understand exactly how the code was >>> supposed to work anyway. >> I might be able to check it within this week. > > Great! > > I had to disable the C++ library too, in order to get a Windows build, > because the C++ library depends on having all features present. > Possibly the C++ library could build even if openpgp is missing... > Still, I think we can release 2.6.0 even with this problem. Hello Simon, I cannot compile gnutls4win, I get: err:module:import_dll Library libgpg-error-0.dll (which is needed by L"H:\\cvs\\gnutls4win\\build\\libgpg-error-1.6\\tests\\.libs\\t-strerror.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"H:\\cvs\\gnutls4win\\build\\libgpg-error-1.6\\tests\\.libs\\t-strerror.exe" failed, status c0000135 FAIL: t-strerror.exe err:module:import_dll Library libgpg-error-0.dll (which is needed by L"H:\\cvs\\gnutls4win\\build\\libgpg-error-1.6\\tests\\.libs\\t-syserror.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"H:\\cvs\\gnutls4win\\build\\libgpg-error-1.6\\tests\\.libs\\t-syserror.exe" failed, status c0000135 FAIL: t-syserror.exe ==================================== 2 of 2 tests failed Please report to bug-gnupg at gnupg.org ==================================== If you could commit the latest binaries to cvs or even send them to me would be the best for me. regards, Nikos From mrsam at courier-mta.com Sun Sep 28 00:40:52 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 27 Sep 2008 18:40:52 -0400 Subject: Two memory leak remaining, with fixes Message-ID: Rerunning my valgrind checks against the latest CVS, two memory leaks remain that are triggered by a session rehandshake. First leak: ==6235== 719 bytes in 13 blocks are definitely lost in loss record 3 of 5 ==6235== at 0x4A0739E: malloc (vg_replace_malloc.c:207) ==6235== by 0x4C59EA0: _gnutls_set_datum_m (gnutls_datum.c:80) ==6235== by 0x4C63899: _gnutls_copy_certificate_auth_info (auth_cert.c:98) ==6235== by 0x4C65519: _gnutls_proc_x509_server_certificate (auth_cert.c:1027) ==6235== by 0x4C660AA: _gnutls_proc_cert_server_certificate (auth_cert.c:1262) ==6235== by 0x4C52DE4: _gnutls_recv_server_certificate (gnutls_kx.c:719) ==6235== by 0x4C4D6AD: _gnutls_handshake_client (gnutls_handshake.c:2359) ==6235== by 0x4C4D268: gnutls_handshake (gnutls_handshake.c:2262) Second leak: ==3435== at 0x4A0739E: malloc (vg_replace_malloc.c:207) ==3435== by 0x4C59EA0: _gnutls_set_datum_m (gnutls_datum.c:80) ==3435== by 0x4C61352: _gnutls_set_keys (gnutls_constate.c:130) ==3435== by 0x4C61FA0: _gnutls_set_write_keys (gnutls_constate.c:424) ==3435== by 0x4C62AD4: _gnutls_write_connection_state_init (gnutls_constate.c:721) ==3435== by 0x4C4DCF0: _gnutls_send_handshake_final (gnutls_handshake.c:2462) ==3435== by 0x4C4E89C: _gnutls_handshake_common (gnutls_handshake.c:2675) ==3435== by 0x4C4D2B1: gnutls_handshake (gnutls_handshake.c:2279) Investigating the second leak also found a number of other potential leaks in gnutls_session_int.cipher_specs. It's probably a good idea to audit all other parts of gnutls_session_int that might need explicit cleanup before they are allocated, given that gnutls_handshake() may be called again as a result of a rehandshake. --- lib/auth_cert.c~ 2008-09-23 20:30:32.000000000 -0400 +++ lib/auth_cert.c 2008-09-27 17:55:28.000000000 -0400 @@ -73,6 +73,9 @@ if (info->raw_certificate_list != NULL) { + for (j = 0; j < info->ncerts; j++) + _gnutls_free_datum (&info->raw_certificate_list[j]); + gnutls_free( info->raw_certificate_list); } --- lib/gnutls_constate.c~ 2008-09-25 20:30:41.000000000 -0400 +++ lib/gnutls_constate.c 2008-09-27 18:18:15.000000000 -0400 @@ -124,6 +124,13 @@ _gnutls_bin2hex (key_block, block_size, buf, sizeof (buf))); + _gnutls_free_datum (&session->cipher_specs.server_write_mac_secret); + _gnutls_free_datum (&session->cipher_specs.client_write_mac_secret); + _gnutls_free_datum (&session->cipher_specs.server_write_IV); + _gnutls_free_datum (&session->cipher_specs.client_write_IV); + _gnutls_free_datum (&session->cipher_specs.server_write_key); + _gnutls_free_datum (&session->cipher_specs.client_write_key); + pos = 0; if (hash_size > 0) { From aspecialj at gmail.com Sun Sep 28 01:17:11 2008 From: aspecialj at gmail.com (John Brooks) Date: Sat, 27 Sep 2008 17:17:11 -0600 Subject: request for help: freshmeat.net gnutls writer In-Reply-To: <87abdwtpx8.fsf@mocca.josefsson.org> References: <87abdwtpx8.fsf@mocca.josefsson.org> Message-ID: Since nobody else seems to be willing, I could handle freshmeat updates. I've been reading release announcements for a long time anyway, and update freshmeat for some of my own adventures. Let me know if that sounds good to you. - John Brooks On Thu, Sep 25, 2008 at 5:39 AM, Simon Josefsson wrote: > Hi! Updating freshmeat.net to point to the latest gnutls versions is > tiresome, and I haven't had time to do it since the 2.0.0 release. If > someone else, or a group of people, wants to help with this, that would > be appreciated. You need to read the NEWS file and condense it down to > a few sentences for each release. > > /Simon > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > From n.mavrogiannopoulos at gmail.com Sun Sep 28 02:40:49 2008 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sun, 28 Sep 2008 03:40:49 +0300 Subject: Two memory leak remaining, with fixes In-Reply-To: References: Message-ID: Hello, Thank you, I applied it (the last one with some additional removals). I'm curious though how there could be a leak. Maybe it's too late for me anyway... On Sun, Sep 28, 2008 at 1:40 AM, Sam Varshavchik wrote: > Rerunning my valgrind checks against the latest CVS, two memory leaks remain > that are triggered by a session rehandshake. > > First leak: > > ==6235== 719 bytes in 13 blocks are definitely lost in loss record 3 of 5 > ==6235== at 0x4A0739E: malloc (vg_replace_malloc.c:207) > ==6235== by 0x4C59EA0: _gnutls_set_datum_m (gnutls_datum.c:80) > ==6235== by 0x4C63899: _gnutls_copy_certificate_auth_info > (auth_cert.c:98) > ==6235== by 0x4C65519: _gnutls_proc_x509_server_certificate > (auth_cert.c:1027) > ==6235== by 0x4C660AA: _gnutls_proc_cert_server_certificate > (auth_cert.c:1262) > ==6235== by 0x4C52DE4: _gnutls_recv_server_certificate (gnutls_kx.c:719) > ==6235== by 0x4C4D6AD: _gnutls_handshake_client (gnutls_handshake.c:2359) > ==6235== by 0x4C4D268: gnutls_handshake (gnutls_handshake.c:2262) > > Second leak: > > ==3435== at 0x4A0739E: malloc (vg_replace_malloc.c:207) > ==3435== by 0x4C59EA0: _gnutls_set_datum_m (gnutls_datum.c:80) > ==3435== by 0x4C61352: _gnutls_set_keys (gnutls_constate.c:130) > ==3435== by 0x4C61FA0: _gnutls_set_write_keys (gnutls_constate.c:424) > ==3435== by 0x4C62AD4: _gnutls_write_connection_state_init > (gnutls_constate.c:721) > ==3435== by 0x4C4DCF0: _gnutls_send_handshake_final > (gnutls_handshake.c:2462) > ==3435== by 0x4C4E89C: _gnutls_handshake_common (gnutls_handshake.c:2675) > ==3435== by 0x4C4D2B1: gnutls_handshake (gnutls_handshake.c:2279) > > Investigating the second leak also found a number of other potential leaks > in gnutls_session_int.cipher_specs. It's probably a good idea to audit all > other parts of gnutls_session_int that might need explicit cleanup before > they are allocated, given that gnutls_handshake() may be called again as a > result of a rehandshake. > > > --- lib/auth_cert.c~ 2008-09-23 20:30:32.000000000 -0400 > +++ lib/auth_cert.c 2008-09-27 17:55:28.000000000 -0400 > @@ -73,6 +73,9 @@ > > if (info->raw_certificate_list != NULL) > { > + for (j = 0; j < info->ncerts; j++) > + _gnutls_free_datum (&info->raw_certificate_list[j]); > + > gnutls_free( info->raw_certificate_list); > } > > --- lib/gnutls_constate.c~ 2008-09-25 20:30:41.000000000 -0400 > +++ lib/gnutls_constate.c 2008-09-27 18:18:15.000000000 -0400 > @@ -124,6 +124,13 @@ > _gnutls_bin2hex (key_block, block_size, buf, > sizeof (buf))); > > + _gnutls_free_datum (&session->cipher_specs.server_write_mac_secret); > + _gnutls_free_datum (&session->cipher_specs.client_write_mac_secret); > + _gnutls_free_datum (&session->cipher_specs.server_write_IV); > + _gnutls_free_datum (&session->cipher_specs.client_write_IV); > + _gnutls_free_datum (&session->cipher_specs.server_write_key); > + _gnutls_free_datum (&session->cipher_specs.client_write_key); > + > pos = 0; > if (hash_size > 0) > { > > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > From mrsam at courier-mta.com Sun Sep 28 05:16:13 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sat, 27 Sep 2008 23:16:13 -0400 Subject: Two memory leak remaining, with fixes References: Message-ID: Nikos Mavrogiannopoulos writes: > Hello, > Thank you, I applied it (the last one with some additional removals). > I'm curious though how there could be a leak. Maybe it's too late for > me anyway... Both patches address leaks caused by the same underlying problem. The functions in question allocate some session-specific objects, during a handshake, and save the pointer in the session structure. When a /rehandshake/ occurs, gnutls_handshake() gets called again, a second time. The existing code just allocates new objects and puts them into the gnutls_session_int structure again. Pointers to objects allocated by the first call to gnutls_handshake(), during the first handshake, never get freed. All of these leaks occur when gnutls_handshake() gets called a second time, not the first time. There is no test case for this, but I can confirm that GnuTLS seems to properly implement a rehandshake of an existing GnuTLS session. At least, when the GnuTLS client connects to a GnuTLS server. If the server requests a handshake, the client accepts, gnutls_handshake() -- on both the client and the server -- seems to do the right thing. Except for leaking memory, of course. > > On Sun, Sep 28, 2008 at 1:40 AM, Sam Varshavchik wrote: >> Rerunning my valgrind checks against the latest CVS, two memory leaks remain >> that are triggered by a session rehandshake. >> >> First leak: >> >> ==6235== 719 bytes in 13 blocks are definitely lost in loss record 3 of 5 >> ==6235== at 0x4A0739E: malloc (vg_replace_malloc.c:207) >> ==6235== by 0x4C59EA0: _gnutls_set_datum_m (gnutls_datum.c:80) >> ==6235== by 0x4C63899: _gnutls_copy_certificate_auth_info >> (auth_cert.c:98) >> ==6235== by 0x4C65519: _gnutls_proc_x509_server_certificate >> (auth_cert.c:1027) >> ==6235== by 0x4C660AA: _gnutls_proc_cert_server_certificate >> (auth_cert.c:1262) >> ==6235== by 0x4C52DE4: _gnutls_recv_server_certificate (gnutls_kx.c:719) >> ==6235== by 0x4C4D6AD: _gnutls_handshake_client (gnutls_handshake.c:2359) >> ==6235== by 0x4C4D268: gnutls_handshake (gnutls_handshake.c:2262) >> >> Second leak: >> >> ==3435== at 0x4A0739E: malloc (vg_replace_malloc.c:207) >> ==3435== by 0x4C59EA0: _gnutls_set_datum_m (gnutls_datum.c:80) >> ==3435== by 0x4C61352: _gnutls_set_keys (gnutls_constate.c:130) >> ==3435== by 0x4C61FA0: _gnutls_set_write_keys (gnutls_constate.c:424) >> ==3435== by 0x4C62AD4: _gnutls_write_connection_state_init >> (gnutls_constate.c:721) >> ==3435== by 0x4C4DCF0: _gnutls_send_handshake_final >> (gnutls_handshake.c:2462) >> ==3435== by 0x4C4E89C: _gnutls_handshake_common (gnutls_handshake.c:2675) >> ==3435== by 0x4C4D2B1: gnutls_handshake (gnutls_handshake.c:2279) >> >> Investigating the second leak also found a number of other potential leaks >> in gnutls_session_int.cipher_specs. It's probably a good idea to audit all >> other parts of gnutls_session_int that might need explicit cleanup before >> they are allocated, given that gnutls_handshake() may be called again as a >> result of a rehandshake. >> >> >> --- lib/auth_cert.c~ 2008-09-23 20:30:32.000000000 -0400 >> +++ lib/auth_cert.c 2008-09-27 17:55:28.000000000 -0400 >> @@ -73,6 +73,9 @@ >> >> if (info->raw_certificate_list != NULL) >> { >> + for (j = 0; j < info->ncerts; j++) >> + _gnutls_free_datum (&info->raw_certificate_list[j]); >> + >> gnutls_free( info->raw_certificate_list); >> } >> >> --- lib/gnutls_constate.c~ 2008-09-25 20:30:41.000000000 -0400 >> +++ lib/gnutls_constate.c 2008-09-27 18:18:15.000000000 -0400 >> @@ -124,6 +124,13 @@ >> _gnutls_bin2hex (key_block, block_size, buf, >> sizeof (buf))); >> >> + _gnutls_free_datum (&session->cipher_specs.server_write_mac_secret); >> + _gnutls_free_datum (&session->cipher_specs.client_write_mac_secret); >> + _gnutls_free_datum (&session->cipher_specs.server_write_IV); >> + _gnutls_free_datum (&session->cipher_specs.client_write_IV); >> + _gnutls_free_datum (&session->cipher_specs.server_write_key); >> + _gnutls_free_datum (&session->cipher_specs.client_write_key); >> + >> pos = 0; >> if (hash_size > 0) >> { >> >> >> >> _______________________________________________ >> Gnutls-devel mailing list >> Gnutls-devel at gnu.org >> http://lists.gnu.org/mailman/listinfo/gnutls-devel >> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From simon at josefsson.org Mon Sep 29 11:11:21 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 29 Sep 2008 11:11:21 +0200 Subject: request for help: freshmeat.net gnutls writer In-Reply-To: (John Brooks's message of "Sat, 27 Sep 2008 17:17:11 -0600") References: <87abdwtpx8.fsf@mocca.josefsson.org> Message-ID: <87od272u6e.fsf@mocca.josefsson.org> Thank you John! The most important is to track the stable releases (2.0.x, 2.2.x, 2.4.x, 2.6.x, ...). We are lagging behind seriously now. I think you can click on 'add release' from: http://freshmeat.net/projects/gnutls/ and then write announcement texts for releases. Let me know if you need help with anything. Thanks again, /Simon "John Brooks" writes: > Since nobody else seems to be willing, I could handle freshmeat > updates. I've been reading release announcements for a long time > anyway, and update freshmeat for some of my own adventures. Let me > know if that sounds good to you. > > - John Brooks > > On Thu, Sep 25, 2008 at 5:39 AM, Simon Josefsson wrote: >> Hi! Updating freshmeat.net to point to the latest gnutls versions is >> tiresome, and I haven't had time to do it since the 2.0.0 release. If >> someone else, or a group of people, wants to help with this, that would >> be appreciated. You need to read the NEWS file and condense it down to >> a few sentences for each release. >> >> /Simon >> >> >> _______________________________________________ >> Gnutls-devel mailing list >> Gnutls-devel at gnu.org >> http://lists.gnu.org/mailman/listinfo/gnutls-devel >> From simon at josefsson.org Mon Sep 29 11:14:10 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 29 Sep 2008 11:14:10 +0200 Subject: request for help: openpgp under windows doesn't work In-Reply-To: <48DE74AB.8040706@gmail.com> (Nikos Mavrogiannopoulos's message of "Sat, 27 Sep 2008 21:00:11 +0300") References: <87tzcg5s50.fsf@mocca.josefsson.org> <87prn45nxs.fsf@mocca.josefsson.org> <48DE74AB.8040706@gmail.com> Message-ID: <87k5cv2u1p.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Hello Simon, > I cannot compile gnutls4win, I get: > > err:module:import_dll Library libgpg-error-0.dll (which is needed by > L"H:\\cvs\\gnutls4win\\build\\libgpg-error-1.6\\tests\\.libs\\t-strerror.exe") > not found > err:module:LdrInitializeThunk Main exe initialization for > L"H:\\cvs\\gnutls4win\\build\\libgpg-error-1.6\\tests\\.libs\\t-strerror.exe" > failed, status c0000135 > FAIL: t-strerror.exe > err:module:import_dll Library libgpg-error-0.dll (which is needed by > L"H:\\cvs\\gnutls4win\\build\\libgpg-error-1.6\\tests\\.libs\\t-syserror.exe") > not found > err:module:LdrInitializeThunk Main exe initialization for > L"H:\\cvs\\gnutls4win\\build\\libgpg-error-1.6\\tests\\.libs\\t-syserror.exe" > failed, status c0000135 > FAIL: t-syserror.exe > ==================================== > 2 of 2 tests failed > Please report to bug-gnupg at gnupg.org > ==================================== Hi Nikos, I haven't tracked down why this happens, but there is a workaround for it, you need to create these symlinks to your install tree: jas at mocca:~$ ls -la .wine/drive_c/windows/system32/|grep -- '->' lrwxrwxrwx 1 jas root 46 2008-09-08 15:08 libgcrypt-11.dll -> /home/jas/gnutls4win/inst/bin/libgcrypt-11.dll lrwxrwxrwx 1 jas root 46 2008-09-08 15:07 libgnutls-26.dll -> /home/jas/gnutls4win/inst/bin/libgnutls-26.dll lrwxrwxrwx 1 jas root 52 2008-09-08 15:07 libgnutls-extra-26.dll -> /home/jas/gnutls4win/inst/bin/libgnutls-extra-26.dll lrwxrwxrwx 1 jas root 54 2008-09-08 15:08 libgnutls-openssl-26.dll -> /home/jas/gnutls4win/inst/bin/libgnutls-openssl-26.dll lrwxrwxrwx 1 jas root 48 2008-09-08 15:08 libgpg-error-0.dll -> /home/jas/gnutls4win/inst/bin/libgpg-error-0.dll lrwxrwxrwx 1 jas root 44 2008-09-08 15:08 libtasn1-3.dll -> /home/jas/gnutls4win/inst/bin/libtasn1-3.dll jas at mocca:~$ > If you could commit the latest binaries to cvs or even send them to me > would be the best for me. Just unzip the latest *.zip in the bin/ directory should take care of that. /Simon From simon at josefsson.org Mon Sep 29 14:06:04 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 29 Sep 2008 14:06:04 +0200 Subject: GnuTLS 2.5.9, fifth and final (?) release candidate for 2.6.0 Message-ID: <87tzbz17ir.fsf@mocca.josefsson.org> The GnuTLS 2.5.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. I'll be traveling later this week (speaking at OpenSourceDays in Copenhagen, see and OWASP Sweden see ) so I may have trouble releasing 2.6.0 on Oct 1th, so let's wait until next Monday when I'm back. The intention is to release a new stable branch on October 6th, unless problems are reported. Test this as if it were the new stable release! Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.9.tar.bz2 (4.9MB) ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.9.tar.bz2 Here is the OpenPGP signature: http://alpha.gnu.org/gnu/gnutls/gnutls-2.5.9.tar.bz2.sig ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.5.9.tar.bz2.sig The Windows binary installer and PGP signature: http://josefsson.org/gnutls4win/gnutls-2.5.9.exe (14MB) http://josefsson.org/gnutls4win/gnutls-2.5.9.exe.sig The Windows binaries (DLL, EXE, etc) without the installer: http://josefsson.org/gnutls4win/gnutls-2.5.9.zip (4.9MB) http://josefsson.org/gnutls4win/gnutls-2.5.9.zip.sig Thanks to Enrico Tassi, we also have mingw32 *.deb's available: http://josefsson.org/gnutls4win/mingw32-gnutls_2.5.9-1_all.deb (4.5MB) Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. /Simon * Version 2.5.9 (released 2008-09-29) ** libgnutls: Fix several memory leaks. Reported by Sam Varshavchik . ** libgnutls: Fix buffer overrun in gnutls_x509_crt_list_import. Report and patch by Jonathan Manktelow. ** libgnutls: crypto.h gnutls_pk_params_st changes allocation strategy. The parameters are now allocated in the structure itself. ** doc: Texinfo HTML manual uses a stylesheet to improve readability. ** tests: Scripts now use EXEEXT properly. Modern libtool doesn't create wrapper script, so the self tests need to invoke certtool.exe under MinGW32+Wine. ** Uses autoconf 2.63, automake 1.10.1, libtool 2.2.6a. Automake warnings are now also enabled. ** API and ABI modifications: gnutls_pk_params_st: MODIFIED From simon at josefsson.org Mon Sep 29 22:45:42 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 29 Sep 2008 22:45:42 +0200 Subject: tls 1.2 In-Reply-To: (Nikos Mavrogiannopoulos's message of "Mon, 29 Sep 2008 23:39:24 +0300") References: Message-ID: <87ej32d6kp.fsf@mocca.josefsson.org> "Nikos Mavrogiannopoulos" writes: > Hello Simon, > What is the state of TLS 1.2 support? Is it compatible with the current rfc? Hi! No, they changed the protocol after I implemented and tested it a long time ago. Sigh! Fixing this would be nice for the 2.7.x branch, but I simply have not had any time to work on it. It would be nice to be able to build GnuTLS without any MD5 support. There are several test servers out there with TLS 1.2 support, so should be much simpler to write the support now. /Simon