From stefw at collabora.co.uk Mon Aug 1 11:53:58 2011 From: stefw at collabora.co.uk (Stef Walter) Date: Mon, 01 Aug 2011 11:53:58 +0200 Subject: More PKCS#11 fixes for gnutls master Message-ID: <4E3677B6.6090109@collabora.co.uk> Attached are three more fixes to gnutls master for bugs and documentation. Do these changes look okay? Would it be better to deprecate or change the gnutls_pkcs11_init() function, rather than just marking the argument as unused? Stef commit 938f959a23b05ea2407bef067d54ce8b1e3cb6ec Author: Stef Walter Date: Mon Aug 1 11:12:57 2011 +0200 Don't try to do PKCS#11 login if session is already logged in. * It is possible for new PKCS#11 sessions to be logged in if another logged in session already exists. * In these cases, don't log in, but detect the condition and return success. commit d5c239f7542916b4fd50386476256c89d8cef58b Author: Stef Walter Date: Mon Aug 1 11:11:01 2011 +0200 When finding private keys fail, return error code. * Previously this would result in an endless loop. commit c68258d60c35426a89081705874b6d2acbba0ed9 Author: Stef Walter Date: Mon Aug 1 09:45:44 2011 +0200 Mark the config argument of gnutls_pkcs11_init() as unused * Since its no longer used. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Mark-the-config-argument-of-gnutls_pkcs11_init-as-un.patch Type: text/x-patch Size: 2030 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-When-finding-private-keys-fail-return-error-code.patch Type: text/x-patch Size: 849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Don-t-try-to-do-PKCS-11-login-if-session-is-already-.patch Type: text/x-patch Size: 1584 bytes Desc: not available URL: From nmav at gnutls.org Mon Aug 1 18:00:48 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 01 Aug 2011 18:00:48 +0200 Subject: More PKCS#11 fixes for gnutls master In-Reply-To: <4E3677B6.6090109@collabora.co.uk> References: <4E3677B6.6090109@collabora.co.uk> Message-ID: <4E36CDB0.1090601@gnutls.org> On 08/01/2011 11:53 AM, Stef Walter wrote: > Attached are three more fixes to gnutls master for bugs and documentation. Applied. > Do these changes look okay? Would it be better to deprecate or change > the gnutls_pkcs11_init() function, rather than just marking the argument > as unused? No reason to deprecate it. The argument was there for extensibility (due to pakchois operation). > commit d5c239f7542916b4fd50386476256c89d8cef58b > Author: Stef Walter > Date: Mon Aug 1 11:11:01 2011 +0200 > > When finding private keys fail, return error code. > > * Previously this would result in an endless loop. I don't remember why I had that loop on errors. thanks, Nikos From INVALID.NOREPLY at gnu.org Wed Aug 3 09:01:37 2011 From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen) Date: Wed, 03 Aug 2011 07:01:37 +0000 Subject: [sr #107763] Running GnuTLS in non-blocking mode. Message-ID: <20110803-070137.sv79827.32337@savannah.gnu.org> URL: Summary: Running GnuTLS in non-blocking mode. Project: GnuTLS Submitted by: cybear Submitted on: Wed Aug 3 07:01:37 2011 Category: Core library Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: Microsoft Windows _______________________________________________________ Details: I think this is a variant of #107660. I have just updated from version 2.10.1 to 2.12.7 and my application has stopped working. I am running one thread to handle all the socket communication both secure through GnuTLS and unsecure on sockets. All sockets have been set into non-blocking mode. The main loop in the work thread defines which sockets to check for ready for read and write and then suspends on the select() call. When returned from the select() call I will read from the socket which has data to read. This strategy worked fine with version 2.10.1 but is broken in version 2.12.7. Because: (as far as I can debug) I sent from the client 231 bytes of data 115 bytes of header and 116 bytes of data (my protocol) I call gnutls_record_recv and ask for 115 bytes, because I want to read my header and determine what to do after that. Then I again mark the socket so select() will check it for new data (ready for read on the raw socket) waiting for my 116 byte of data. And the work thread suspends on the select() call. But in version 2.12.7 no new data arrives on the socket because it was read and buffered on the first call to gnutls_record_recv. SO my work thread grinds to a halt on the socket gnutls buffers data. Yes I can see there is a call to the gnutls_record_check_pending() but this will cause that the way of reading will be different between secure and unsecure communication. And the comments in the code on gnutls_record_recv clearly indicates that the intention is for the function to work like recv(). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Aug 3 19:00:02 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Wed, 03 Aug 2011 17:00:02 +0000 Subject: [sr #107763] Running GnuTLS in non-blocking mode. In-Reply-To: <20110803-070137.sv79827.32337@savannah.gnu.org> References: <20110803-070137.sv79827.32337@savannah.gnu.org> Message-ID: <20110803-200002.sv707.32162@savannah.gnu.org> Update of sr #107763 (project gnutls): Status: None => Duplicate Assigned to: None => nmav _______________________________________________________ Follow-up Comment #1: Unfortunately there is not much we can do. This is indeed a duplicate of #107660. The solutions discussed in: https://savannah.gnu.org/support/?107660#comment3 should be applicable to your case. Note however that the quick fix (1) using gnutls_transport_set_lowat(), is not applicable in gnutls 3.0.0 that doesn't have this function. Because operating system sockets and gnutls sessions operate on different context the convenient usage of select was mostly a hack that became expensive to maintain. A solution is to wrap select with a function that will also poll gnutls_record_check_pending(). If the interface of the latter function is not sufficient feel free to send suggestions and/or improvements. regards, Nikos _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From neuromancer at dash.za.net Thu Aug 4 01:20:18 2011 From: neuromancer at dash.za.net (Dash Shendy) Date: Thu, 04 Aug 2011 01:20:18 +0200 Subject: GnuTLS 3.0.0 Warning In-Reply-To: References: Message-ID: <4E39D7B2.7050609@dash.za.net> While compiling the latest version of GnuTLS, I get the following warning: cc1: warnings being treated as errors cert.c: In function ?call_get_cert_callback?: cert.c:581:3: error: enumeration value ?GNUTLS_PRIVKEY_PKCS11? not handled in switch [-Wswitch] make[3]: *** [cert.lo] Error 1 I know that some warnings are ok to ignore, is this one of them, or should I be worried? The Library was conf'ed using the following options: ./configure --prefix=/usr --enable-cryptodev --enable-ld-version-script --enable-valgrind-tests --enable-gcc-warnings --enable-shared=all --enable-guile --with-libnettle-prefix --with-included-libtasn1 --with-libiconv-prefix=/usr --with-libpthread-prefix=/usr --with-libintl-prefix=/usr --with-libz-prefix=/usr --with-libnettle-prefix=/usr --with-included-libcfg --with-packager=/usr/bin/pkg-config --with-gnu-ld --without-p11-kit I'll just ignore the warning for now, but ideally would prefer a clean compilation;) Regards, *Dash Shendy* Coder/Pentester/Security-Analyst http://dash.za.net/?smtpsig gtalk: dash.za.net at gmail.com skype: dashula2006 mopho: (+27) 72 23 75 199 On 8/3/2011 6:00 PM, gnutls-devel-request at gnu.org wrote: > Send Gnutls-devel mailing list submissions to > gnutls-devel at gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/gnutls-devel > or, via email, send a message with subject or body 'help' to > gnutls-devel-request at gnu.org > > You can reach the person managing the list at > gnutls-devel-owner at gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gnutls-devel digest..." > > > Today's Topics: > > 1. [sr #107763] Running GnuTLS in non-blocking mode. > (Bj?rn Christensen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 03 Aug 2011 07:01:37 +0000 > From: Bj?rn Christensen > To: Bj?rn Christensen , gnutls-devel at gnu.org > Subject: [sr #107763] Running GnuTLS in non-blocking mode. > Message-ID: <20110803-070137.sv79827.32337 at savannah.gnu.org> > Content-Type: text/plain;charset=UTF-8 > > URL: > > > Summary: Running GnuTLS in non-blocking mode. > Project: GnuTLS > Submitted by: cybear > Submitted on: Wed Aug 3 07:01:37 2011 > Category: Core library > Priority: 5 - Normal > Severity: 3 - Normal > Status: None > Privacy: Public > Assigned to: None > Originator Email: > Open/Closed: Open > Discussion Lock: Any > Operating System: Microsoft Windows > > _______________________________________________________ > > Details: > > I think this is a variant of #107660. > > > I have just updated from version 2.10.1 to 2.12.7 and my application has > stopped working. > > I am running one thread to handle all the socket communication both secure > through GnuTLS and unsecure on sockets. > > All sockets have been set into non-blocking mode. > > > The main loop in the work thread defines which sockets to check for ready for > read and write and then suspends on the select() call. > > When returned from the select() call I will read from the socket which has > data to read. > > This strategy worked fine with version 2.10.1 but is broken in version > 2.12.7. > > Because: (as far as I can debug) > > I sent from the client 231 bytes of data 115 bytes of header and 116 bytes of > data (my protocol) > > I call gnutls_record_recv and ask for 115 bytes, because I want to read my > header and determine what to do after that. > Then I again mark the socket so select() will check it for new data (ready for > read on the raw socket) waiting for my 116 byte of data. And the work thread > suspends on the select() call. > > > But in version 2.12.7 no new data arrives on the socket because it was read > and buffered on the first call to gnutls_record_recv. SO my work thread grinds > to a halt on the socket gnutls buffers data. > > Yes I can see there is a call to the gnutls_record_check_pending() but this > will cause that the way of reading will be different between secure and > unsecure communication. > > And the comments in the code on gnutls_record_recv clearly indicates that the > intention is for the function to work like recv(). > > > > > > > > > > > > > > > > > _______________________________________________________ > > Reply to this item at: > > > > _______________________________________________ > Message sent via/by Savannah > http://savannah.gnu.org/ > > > > > ------------------------------ > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > https://lists.gnu.org/mailman/listinfo/gnutls-devel > > > End of Gnutls-devel Digest, Vol 45, Issue 3 > ******************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x1F109B38.asc Type: application/pgp-keys Size: 1887 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From a.radke at arcor.de Sun Aug 7 21:12:32 2011 From: a.radke at arcor.de (Andreas Radke) Date: Sun, 7 Aug 2011 21:12:32 +0200 Subject: gnutls 3.0.0 test segfault Message-ID: <20110807211232.01ffa6dc@laptop64.home> Building the ArchLinux package x86_64 version works well but in our i686 chroot the test suite segfaults: Self test `./moredn' finished with 0 errors PASS: moredn /bin/sh: line 5: 11462 Segmentation fault PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT= srcdir="." ${dir}$tst FAIL: mini Self test `./hostname-check' finished with 0 errors any idea? I build with --without-p11-kit -Andy From nmav at gnutls.org Mon Aug 8 11:46:52 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 8 Aug 2011 11:46:52 +0200 Subject: gnutls 3.0.0 test segfault In-Reply-To: <20110807211232.01ffa6dc@laptop64.home> References: <20110807211232.01ffa6dc@laptop64.home> Message-ID: On Sun, Aug 7, 2011 at 9:12 PM, Andreas Radke wrote: > Building the ArchLinux package x86_64 version works well but in our > i686 chroot the test suite segfaults: Could you use gdb or valgrind to find the segmentation fault point? Another options would be to try: --disable-hardware-acceleration and see if it fixes the issue. If yes, could you provide more information about the i686 variant? regards, Nikos From ametzler at downhill.at.eu.org Mon Aug 8 19:52:50 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon, 8 Aug 2011 19:52:50 +0200 Subject: 3.0.0 executable stack in libgnutls Message-ID: <20110808175250.GA10461@downhill.g.la> Hello, with 3.0.0 libgnutls' stack is marked executable: ---------------- ametzler at argenau:~/SVN/gnutls28/trunk$ readelf -l /usr/lib/libgnutls.so.26.14.12 | grep -E 'Type |GNU_STACK ' Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4 ametzler at argenau:~/SVN/gnutls28/trunk$ readelf -l /tmp/GNUTLS/gnutls-3.0.0/debian/tmp/usr/lib/i386-linux-gnu/libgnutls.so.28.0.0 | grep -E 'Type |GNU_STACK ' Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 ---------------- Note the "E" in RWE. Afaict this is caused by ./lib/accelerated/intel/appro-aes-x86.o missing a GNU-stack section. (SID)ametzler at argenau:/tmp/GNUTLS/gnutls-3.0.0$ readelf -S \ ./lib/accelerated/intel/appro-aes-x86.o | grep -i stack (SID)ametzler at argenau:/tmp/GNUTLS/gnutls-3.0.0$ readelf -S \ ./lib/accelerated/intel/aes-x86.o | grep -i stack [21] .note.GNU-stack PROGBITS 00000000 001f19 000000 00 0 0 1 The source assembly files in /tmp/GNUTLS/gnutls-3.0.0/lib/accelerated/intel/asm/ all seem to be missing the GNU-stack note. cu andreas http://www.gentoo.org/proj/en/hardened/gnu-stack.xml From nmav at gnutls.org Mon Aug 8 20:10:06 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 08 Aug 2011 20:10:06 +0200 Subject: 3.0.0 executable stack in libgnutls In-Reply-To: <20110808175250.GA10461@downhill.g.la> References: <20110808175250.GA10461@downhill.g.la> Message-ID: <4E40267E.7000200@gnutls.org> On 08/08/2011 07:52 PM, Andreas Metzler wrote: > Hello, > > with 3.0.0 libgnutls' stack is marked executable: > ---------------- > ametzler at argenau:~/SVN/gnutls28/trunk$ readelf -l /usr/lib/libgnutls.so.26.14.12 | grep -E 'Type |GNU_STACK ' > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4 > ametzler at argenau:~/SVN/gnutls28/trunk$ readelf -l /tmp/GNUTLS/gnutls-3.0.0/debian/tmp/usr/lib/i386-linux-gnu/libgnutls.so.28.0.0 | grep -E 'Type |GNU_STACK ' > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 > ---------------- > Note the "E" in RWE. Afaict this is caused by > ./lib/accelerated/intel/appro-aes-x86.o missing a GNU-stack section. > (SID)ametzler at argenau:/tmp/GNUTLS/gnutls-3.0.0$ readelf -S \ > ./lib/accelerated/intel/appro-aes-x86.o | grep -i stack > (SID)ametzler at argenau:/tmp/GNUTLS/gnutls-3.0.0$ readelf -S \ > ./lib/accelerated/intel/aes-x86.o | grep -i stack > [21] .note.GNU-stack PROGBITS 00000000 001f19 000000 00 0 0 1 Nice catch. Does the attached patch solve the issue? regards, Nikos -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From INVALID.NOREPLY at gnu.org Mon Aug 8 21:54:09 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 08 Aug 2011 19:54:09 +0000 Subject: [sr #107763] Running GnuTLS in non-blocking mode. In-Reply-To: <20110803-200002.sv707.32162@savannah.gnu.org> References: <20110803-070137.sv79827.32337@savannah.gnu.org> <20110803-200002.sv707.32162@savannah.gnu.org> Message-ID: <20110808-225409.sv707.75252@savannah.gnu.org> Update of sr #107763 (project gnutls): Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Aug 8 21:54:38 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 08 Aug 2011 19:54:38 +0000 Subject: [sr #107696] GnuTLS 2.10 client cannot negotiate TLS 1.2 to GnuTLS 2.8 server In-Reply-To: <20110524-154908.sv82895.15836@savannah.gnu.org> References: <20110524-150255.sv82895.67461@savannah.gnu.org> <20110524-183825.sv707.62403@savannah.gnu.org> <20110524-183846.sv707.60748@savannah.gnu.org> <20110524-154908.sv82895.15836@savannah.gnu.org> Message-ID: <20110808-225438.sv707.62105@savannah.gnu.org> Update of sr #107696 (project gnutls): Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Mon Aug 8 23:27:35 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 08 Aug 2011 23:27:35 +0200 Subject: gnutls 2.12.8 Message-ID: <4E4054C7.5000700@gnutls.org> Hello, I've just released gnutls 2.12.8. This release adds new functionality to 2.12.x and fixes all the known bugs. * Version 2.12.8 (released 2011-08-08) ** libgnutls: PKCS #11 back-end was replaced by p11-kit http://p11-glue.freedesktop.org/p11-kit.html. This backports the 3.0.0 PKCS #11 back-end. Rewrite by Stef Walter. ** libgnutls: gcrypt: replaced occurences of gcry_sexp_nth_mpi (..., 0) with gcry_sexp_nth_mpi (..., GCRYMPI_FMT_USG) to fix errors with 1.5.0. Patch by Andreas Metzler. ** libgnutls: Verify that a certificate liste specified using gnutls_certificate_set_x509_key*(), is sorted according to TLS specification (from subject to issuer). ** libgnutls: Added GNUTLS_X509_CRT_LIST_FAIL_IF_UNSORTED flag for gnutls_x509_crt_list_import. It checks whether the list to be imported is properly sorted. ** libgnutls: writev_emu: stop on the first incomplete write. Patch by Sjoerd Simons. ** libgnutls: Fix zlib handling in gnutls.pc. Patch by Andreas Metzler. ** certtool: bug fixes in certificate request generation. Patch by Petr P?sa?. ** API and ABI modifications: GNUTLS_X509_CRT_LIST_FAIL_IF_UNSORTED: New element in gnutls_certificate_import_flags Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.8.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.8.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.8.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.8.tar.bz2.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From INVALID.NOREPLY at gnu.org Tue Aug 9 09:53:54 2011 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Tue, 09 Aug 2011 07:53:54 +0000 Subject: [sr #107769] GnuTLS 2.12.7 problems on AIX Message-ID: <20110809-075353.sv0.48851@savannah.gnu.org> URL: Summary: GnuTLS 2.12.7 problems on AIX Project: GnuTLS Submitted by: None Submitted on: Tue 09 Aug 2011 07:53:53 UTC Category: Core library Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: cybear Open/Closed: Open Discussion Lock: Any Operating System: *BSD _______________________________________________________ Details: I have build my application on linux and a crosscompiled version for windows and they are working but on AIX I can not connection client to server. Somthing goes wrong during negotiation. I am running the sockets in non-blocking mode, and that causes some problems, I have made a hack for that in version 2.10.1 and added the hack to 2.12.7. AIX read returns -1 but no error code and in that case I return GNUTLS_E_AGAIN from _gnutls_read. That worked in 2.10.1 and brings me further in version 2.12.7. The next problem occures in line 410 of gnutls_record.c if (sizeofdata > MAX_RECORD_SEND_SIZE) where MAX_RECORD_SEND_SIZE point to a member of the session structure and have the value 0. (see behaviour in attached log file serverbeforefix.log) I have fixed the line to : if (sizeofdata > MAX_RECORD_SEND_SIZE && MAX_RECORD_SEND_SIZE>0) Which is definently not correct but brings me forward. It seems like the whole session have been cleaned up. I have attached logfile from the client and server with the output from the negotiations, and the gnutls_buffers.c and gnutls_record.c that I have used to create these log files. Changed lines are marked by "bhc" On the client AIX OS also issues a warning to the console Warning: using insecure memory!" I have build my gnutls library on gnutls 2.12.7 with the included libtans1 and libgcrypt 1.4.6 and libgpg-error 1.8. Any suggestion on where and what to look for? _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Tue 09 Aug 2011 07:53:53 UTC Name: serverbeforefix.log Size: 24kB By: None ------------------------------------------------------- Date: Tue 09 Aug 2011 07:53:53 UTC Name: client.log Size: 45kB By: None ------------------------------------------------------- Date: Tue 09 Aug 2011 07:53:53 UTC Name: Server.log Size: 20kB By: None ------------------------------------------------------- Date: Tue 09 Aug 2011 07:53:53 UTC Name: gnutls_buffers-2.12.7.c Size: 29kB By: None _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Aug 9 09:54:23 2011 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Tue, 09 Aug 2011 07:54:23 +0000 Subject: [sr #107769] GnuTLS 2.12.7 problems on AIX In-Reply-To: <20110809-075353.sv0.48851@savannah.gnu.org> References: <20110809-075353.sv0.48851@savannah.gnu.org> Message-ID: <20110809-075423.sv0.44506@savannah.gnu.org> Additional Item Attachment, sr #107769 (project gnutls): File name: gnutls_record-2.12.7.c Size:35 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ametzler at downhill.at.eu.org Tue Aug 9 19:00:29 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Tue, 9 Aug 2011 19:00:29 +0200 Subject: 3.0.0 executable stack in libgnutls In-Reply-To: <4E40267E.7000200@gnutls.org> References: <20110808175250.GA10461@downhill.g.la> <4E40267E.7000200@gnutls.org> Message-ID: <20110809170029.GA10243@downhill.g.la> On 2011-08-08 Nikos Mavrogiannopoulos wrote: > On 08/08/2011 07:52 PM, Andreas Metzler wrote: > > with 3.0.0 libgnutls' stack is marked executable: [...] > Nice catch. Thanks to lintian. > Does the attached patch solve the issue? Splendid, works for me. thanks, cu andreas From ametzler at downhill.at.eu.org Tue Aug 9 19:32:59 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Tue, 9 Aug 2011 19:32:59 +0200 Subject: leftover reference to pakchois Message-ID: <20110809173259.GC10243@downhill.g.la> Hello, there are some tiny leftovers from pakchois: gnutls_3_0_x and master: lib/README still refers to pakchois gnutls_2_12_x: lib/configure.ac: dnl for pakchois AC_LIB_HAVE_LINKFLAGS(dl,, [#include ], [dlclose (0);]) cu andreas From INVALID.NOREPLY at gnu.org Tue Aug 9 22:13:13 2011 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Tue, 09 Aug 2011 20:13:13 +0000 Subject: [sr #107771] gnutls uses port 5556 which is reserved for freeciv Message-ID: <20110809-201312.sv0.67159@savannah.gnu.org> URL: Summary: gnutls uses port 5556 which is reserved for freeciv Project: GnuTLS Submitted by: None Submitted on: Tue 09 Aug 2011 08:13:12 PM UTC Category: Included programs Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: woutershep at gmail.com Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: gnutls-serv and gnutls examples seem to extensively use port 5556 which is allocated to freeciv according to IANA: http://www.iana.org/assignments/port-numbers freeciv 5556/tcp Freeciv gameplay freeciv 5556/udp Freeciv gameplay # Reinier Post, Paul Zastoupil January 2006 This causes the automated unit-tests to fail when one is running a freeciv server for example. At first glance the affected files are: doc/cha-programs.texi doc/examples/ex-serv-anon.c doc/examples/ex-serv-pgp.c doc/examples/ex-serv-psk.c doc/examples/ex-serv-srp.c doc/examples/ex-serv1.c doc/examples/tcp.c doc/gnutls.html doc/gnutls.ps src/common.h src/serv-gaa.c src/serv.gaa tests/anonself.c tests/dhepskself.c tests/openpgpself.c tests/pskself.c tests/resume.c tests/x509dn.c tests/x509self.c (On a side note, it might also be nice to include the (new) default port in the gnutls-{serv,cli,cli-debug} manpages) _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Tue Aug 9 22:22:38 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 09 Aug 2011 22:22:38 +0200 Subject: leftover reference to pakchois In-Reply-To: <20110809173259.GC10243@downhill.g.la> References: <20110809173259.GC10243@downhill.g.la> Message-ID: <4E41970E.6090008@gnutls.org> On 08/09/2011 07:32 PM, Andreas Metzler wrote: > Hello, > > there are some tiny leftovers from pakchois: > > gnutls_3_0_x and master: lib/README still refers to pakchois > > gnutls_2_12_x: lib/configure.ac: > dnl for pakchois > AC_LIB_HAVE_LINKFLAGS(dl,, [#include ], [dlclose (0);]) Fixes applied. Thanks! From INVALID.NOREPLY at gnu.org Thu Aug 11 22:54:04 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Aug 2011 20:54:04 +0000 Subject: [sr #107769] GnuTLS 2.12.7 problems on AIX In-Reply-To: <20110809-075423.sv0.44506@savannah.gnu.org> References: <20110809-075353.sv0.48851@savannah.gnu.org> <20110809-075423.sv0.44506@savannah.gnu.org> Message-ID: <20110811-235404.sv707.83260@savannah.gnu.org> Update of sr #107769 (project gnutls): Status: None => Need Info Assigned to: None => nmav _______________________________________________________ Follow-up Comment #1: I can understand the first issue (the AIX bug), but how can MAX_RECORD_SEND_SIZE be zero in this system? If you have an AIX fix (i.e., with ifdefs) for the first issue I'd be interested incorporating it to gnutls. For the second issue (max_record_size being zero) it looks strange. Could you debug this and find out how it becomes zero? Normally this should have the default size of 16k which is set by gnutls_init(). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Aug 11 22:59:47 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Aug 2011 20:59:47 +0000 Subject: [sr #107771] gnutls uses port 5556 which is reserved for freeciv In-Reply-To: <20110809-201312.sv0.67159@savannah.gnu.org> References: <20110809-201312.sv0.67159@savannah.gnu.org> Message-ID: <20110811-235946.sv707.28066@savannah.gnu.org> Update of sr #107771 (project gnutls): Status: None => Confirmed Assigned to: None => nmav _______________________________________________________ Follow-up Comment #1: I confirm that, but since they are used only for testing I don't consider that a major issue. If anyone offers a patch though I'll consider applying it. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Aug 15 05:26:27 2011 From: INVALID.NOREPLY at gnu.org (Jan Steffens) Date: Mon, 15 Aug 2011 03:26:27 +0000 Subject: [sr #107775] GnuTLS 3.0.0 causes segfault Message-ID: <20110815-032626.sv84482.99672@savannah.gnu.org> URL: Summary: GnuTLS 3.0.0 causes segfault Project: GnuTLS Submitted by: heftig Submitted on: Mon 15 Aug 2011 03:26:26 AM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: telepathy-gabble segfaults when used with GnuTLS 3.0.0. Backtrace: #0 0x00007ffff56dc7f0 in ?? () from /lib/libc.so.6 #1 0x00007ffff56d6735 in memmove () from /lib/libc.so.6 #2 0x00007ffff5a17999 in g_memdup () from /usr/lib/libglib-2.0.so.0 #3 0x00000000004e3899 in wocky_tls_session_push_func (user_data=0x7e01a0, buffer=0x8921b0, count=4294967269) at wocky-tls.c:1192 #4 0x00007ffff6e800c5 in _gnutls_writev_emu (session=0x88f9d0, fd=0x7e01a0, giovec=0x7fffffffd710, giovec_cnt=3) at gnutls_buffers.c:322 #5 0x00007ffff6e8016e in _gnutls_writev (session=0x88f9d0, giovec=0x7fffffffd710, giovec_cnt=3) at gnutls_buffers.c:349 #6 0x00007ffff6e808de in _gnutls_io_write_flush (session=0x88f9d0) at gnutls_buffers.c:564 #7 0x00007ffff6e80e02 in _gnutls_handshake_io_write_flush (session=0x88f9d0) at gnutls_buffers.c:679 #8 0x00007ffff6e85947 in _gnutls_send_handshake (session=0x88f9d0, bufel=0xb40440, type=GNUTLS_HANDSHAKE_FINISHED) at gnutls_handshake.c:1133 #9 0x00007ffff6e84916 in _gnutls_send_finished (session=0x88f9d0, again=0) at gnutls_handshake.c:667 #10 0x00007ffff6e8925b in _gnutls_send_handshake_final (session=0x88f9d0, init=1) at gnutls_handshake.c:2600 #11 0x00007ffff6e89f02 in _gnutls_handshake_common (session=0x88f9d0) at gnutls_handshake.c:2822 #12 0x00007ffff6e885e4 in gnutls_handshake (session=0x88f9d0) at gnutls_handshake.c:2342 #13 0x00000000004e1a3e in wocky_tls_session_try_operation (session=0x7e01a0, operation=WOCKY_TLS_OP_READ) at wocky-tls.c:386 #14 0x00000000004e35a9 in wocky_tls_session_read_ready (object=0x818c90, result=0x85c920, user_data=0x7e01a0) at wocky-tls.c:1111 #15 0x00007ffff6578929 in ?? () from /usr/lib/libgio-2.0.so.0 #16 0x00007ffff659010c in ?? () from /usr/lib/libgio-2.0.so.0 #17 0x00007ffff59fa29d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #18 0x00007ffff59faa78 in ?? () from /usr/lib/libglib-2.0.so.0 #19 0x00007ffff59fb0ba in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #20 0x00007ffff6bbe04f in tp_run_connection_manager () from /usr/lib/libtelepathy-glib.so.0 #21 0x0000000000431e81 in gabble_main (argc=1, argv=0x7fffffffdea8) at gabble.c:177 #22 0x0000000000431b09 in main (argc=1, argv=0x7fffffffdea8) at main.c:28 Look at that count=4294967269 buffer length (#3), that can't be right. Of the three giovecs used, the first two have 4294967269 length, the third one has a more sane 53. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Aug 15 08:31:49 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 15 Aug 2011 06:31:49 +0000 Subject: [sr #107775] GnuTLS 3.0.0 causes segfault In-Reply-To: <20110815-032626.sv84482.99672@savannah.gnu.org> References: <20110815-032626.sv84482.99672@savannah.gnu.org> Message-ID: <20110815-093149.sv707.10582@savannah.gnu.org> Update of sr #107775 (project gnutls): Status: None => Need Info Assigned to: None => nmav _______________________________________________________ Follow-up Comment #1: Is there a way to reproduce this issue? It might be memory corruption, have you tried valgrind? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ametzler at downhill.at.eu.org Mon Aug 15 19:08:45 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon, 15 Aug 2011 19:08:45 +0200 Subject: GnuTLS 3.0.0 released In-Reply-To: <4E331923.1030503@gnutls.org> References: <4E331923.1030503@gnutls.org> Message-ID: <20110815170845.GA2114@downhill.g.la> On 2011-07-29 Nikos Mavrogiannopoulos wrote: [...] > ** libgnutls: license upgraded to LGPLv3 Hello, The guile-wrapper is still LGPLv2.1+ / GPLv2+, was this intended? [...] > ** > libgnutls-openssl: modified to use modern gnutls' functions. > This introduces an ABI incompatibility with previous versions. This is compared to 2.10, not 2.12, isn't it? Both 2.12.7 and 3.0.0 use the same soname for the ssl wrapper and at a quick glance this seems to be the only interesting change: --- gnutls-2.12.7/libextra/includes/gnutls/openssl.h 2011-04-08 02:30:45.000000000 +0200 +++ gnutls-3.0.0/libextra/includes/gnutls/openssl.h 2011-05-07 23:32:29.000000000 +0200 @@ -100,7 +100,7 @@ extern "C" typedef struct { char priority_string[256]; - gnutls_connection_end_t connend; + unsigned int connend; } SSL_METHOD; gnutls_connection_end_t was a enum in 2.12.7, does this change the size of the struct? [...] > ** libgnutls-extra: Inner application extension was removed. > It was never standardized nor published as an RFC. [...] So extra is an empty shell now, isn't it? Sholulds the gcrypt related code be reomved from gnutls_extra.c? cu andreas From benjamin.hof at stusta.net Mon Aug 15 11:21:00 2011 From: benjamin.hof at stusta.net (Benjamin Hof) Date: Mon, 15 Aug 2011 11:21:00 +0200 Subject: AES 256 GCM mode not working Message-ID: <20110815092100.GA6247@kenobi.orange.stusta.mhn.de> Hello, Apparently AES256 in GCM mode is not enabled in current GnuTLS. It seems to be implemented and documented, though. Is there a reason for this? The issue applies to the current git HEAD as well as version 3.0.0. A patch is attached, showing what I would assume gnutls_cipher_entry algorithms[] could look like. Kind regards, Benjamin -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls_cipher_entry_aes_256_gcm.patch Type: text/x-diff Size: 793 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From INVALID.NOREPLY at gnu.org Mon Aug 15 21:54:01 2011 From: INVALID.NOREPLY at gnu.org (Jan Steffens) Date: Mon, 15 Aug 2011 19:54:01 +0000 Subject: [sr #107775] GnuTLS 3.0.0 causes segfault In-Reply-To: <20110815-093149.sv707.10582@savannah.gnu.org> References: <20110815-032626.sv84482.99672@savannah.gnu.org> <20110815-093149.sv707.10582@savannah.gnu.org> Message-ID: <20110815-195401.sv84482.82513@savannah.gnu.org> Follow-up Comment #2, sr #107775 (project gnutls): Seems to occur on most attempts to connect. Here's a valgrind log. I killed it because it seriously thrashed my laptop, but it did get to a warning about the crashing g_memdup. (file #23811) _______________________________________________________ Additional Item Attachment: File name: valgrind.log Size:75 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Mon Aug 15 22:14:22 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 15 Aug 2011 22:14:22 +0200 Subject: AES 256 GCM mode not working In-Reply-To: <20110815092100.GA6247@kenobi.orange.stusta.mhn.de> References: <20110815092100.GA6247@kenobi.orange.stusta.mhn.de> Message-ID: <4E497E1E.1070408@gnutls.org> On 08/15/2011 11:21 AM, Benjamin Hof wrote: > Hello, > > Apparently AES256 in GCM mode is not enabled in current GnuTLS. It > seems to be implemented and documented, though. Is there a reason for > this? The issue applies to the current git HEAD as well as version > 3.0.0. A patch is attached, showing what I would assume > gnutls_cipher_entry algorithms[] could look like. It seems it was left out unintentionally. Thank you for pointing that out, it will be included in the next release. regards, Nikos From INVALID.NOREPLY at gnu.org Mon Aug 15 22:23:39 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 15 Aug 2011 20:23:39 +0000 Subject: [sr #107775] GnuTLS 3.0.0 causes segfault In-Reply-To: <20110815-195401.sv84482.82513@savannah.gnu.org> References: <20110815-032626.sv84482.99672@savannah.gnu.org> <20110815-093149.sv707.10582@savannah.gnu.org> <20110815-195401.sv84482.82513@savannah.gnu.org> Message-ID: <20110815-232339.sv707.32450@savannah.gnu.org> Follow-up Comment #3, sr #107775 (project gnutls): It doesn't on my system, thus I need more information to reproduce it. The attached log shows there is a problem in the application in whole. Why do you get the Source and destination overlap in memcpy()? At least in the GnuTLS case, when this message is printed memmove() was being called indicating that something is not right. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Mon Aug 15 22:37:56 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 15 Aug 2011 22:37:56 +0200 Subject: GnuTLS 3.0.0 released In-Reply-To: <20110815170845.GA2114@downhill.g.la> References: <4E331923.1030503@gnutls.org> <20110815170845.GA2114@downhill.g.la> Message-ID: <4E4983A4.8090501@gnutls.org> On 08/15/2011 07:08 PM, Andreas Metzler wrote: > On 2011-07-29 Nikos Mavrogiannopoulos wrote: > [...] >> ** libgnutls: license upgraded to LGPLv3 > > Hello, > The guile-wrapper is still LGPLv2.1+ / GPLv2+, was this intended? Hello Andreas, They should have been updated in head to the LGPLv3 as well. > [...] > This is compared to 2.10, not 2.12, isn't it? Both 2.12.7 and 3.0.0 > use the same soname for the ssl wrapper and at a quick glance this > seems to be the only interesting change: > --- gnutls-2.12.7/libextra/includes/gnutls/openssl.h 2011-04-08 02:30:45.000000000 +0200 > +++ gnutls-3.0.0/libextra/includes/gnutls/openssl.h 2011-05-07 23:32:29.000000000 +0200 > @@ -100,7 +100,7 @@ extern "C" > typedef struct > { > char priority_string[256]; > - gnutls_connection_end_t connend; > + unsigned int connend; > } SSL_METHOD; > gnutls_connection_end_t was a enum in 2.12.7, does this change the > size of the struct? Interesting. I don't remember why this wasn't included in the 0.12.x version. Although it is not a strict C requirement, enumerations have the same size as integers in most compilers (including gcc) and thus they are binary compatible. > [...] >> ** libgnutls-extra: Inner application extension was removed. >> It was never standardized nor published as an RFC. > [...] > So extra is an empty shell now, isn't it? Indeed. > Sholulds the gcrypt related code be reomved from gnutls_extra.c? I'll keep it for a while just in case someone volunteers to update the gcrypt code (currently it is impossible since gcrypt doesn't have GCM that is now required but it might be available later). best regards, Nikos From INVALID.NOREPLY at gnu.org Tue Aug 16 20:53:37 2011 From: INVALID.NOREPLY at gnu.org (Jan Steffens) Date: Tue, 16 Aug 2011 18:53:37 +0000 Subject: [sr #107775] GnuTLS 3.0.0 causes segfault In-Reply-To: <20110815-232339.sv707.32450@savannah.gnu.org> References: <20110815-032626.sv84482.99672@savannah.gnu.org> <20110815-093149.sv707.10582@savannah.gnu.org> <20110815-195401.sv84482.82513@savannah.gnu.org> <20110815-232339.sv707.32450@savannah.gnu.org> Message-ID: <20110816-185337.sv84482.71177@savannah.gnu.org> Follow-up Comment #4, sr #107775 (project gnutls): I don't know why, sorry. This system runs Arch Linux x86_64. I did recompile gnutls and telepathy-gabble using "-O0 -g2" to help debug this. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Aug 16 23:06:47 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Aug 2011 21:06:47 +0000 Subject: [sr #107775] GnuTLS 3.0.0 causes segfault In-Reply-To: <20110816-185337.sv84482.71177@savannah.gnu.org> References: <20110815-032626.sv84482.99672@savannah.gnu.org> <20110815-093149.sv707.10582@savannah.gnu.org> <20110815-195401.sv84482.82513@savannah.gnu.org> <20110815-232339.sv707.32450@savannah.gnu.org> <20110816-185337.sv84482.71177@savannah.gnu.org> Message-ID: <20110817-000646.sv707.69169@savannah.gnu.org> Follow-up Comment #5, sr #107775 (project gnutls): Than I don't know how I can help you, unless you can provide a minimal program that reproduces the issue you see. Try also executing gnutls-cli and gnutls-serv. If they have no issues in your system then it is likely that there is a memory corruption in your application. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Aug 17 08:46:53 2011 From: INVALID.NOREPLY at gnu.org (Andreas Metzler) Date: Wed, 17 Aug 2011 06:46:53 +0000 Subject: [sr #107775] GnuTLS 3.0.0 causes segfault In-Reply-To: <20110817-000646.sv707.69169@savannah.gnu.org> References: <20110815-032626.sv84482.99672@savannah.gnu.org> <20110815-093149.sv707.10582@savannah.gnu.org> <20110815-195401.sv84482.82513@savannah.gnu.org> <20110815-232339.sv707.32450@savannah.gnu.org> <20110816-185337.sv84482.71177@savannah.gnu.org> <20110817-000646.sv707.69169@savannah.gnu.org> Message-ID: <20110817-084652.sv20807.15870@savannah.gnu.org> Follow-up Comment #6, sr #107775 (project gnutls): Nikos Mavrogiannopoulos wrote: > The attached log shows there is a problem in the application in > whole. Why do you get the Source and destination overlap in > memcpy()? At least in the GnuTLS case, when this message is printed > memmove() was being called indicating that something is not right. Hello, This reminds me of a glibc header bug triggered by gcc-4.6. cu andreas _______________________________________________________ Reply to this item at: _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Aug 18 13:30:37 2011 From: INVALID.NOREPLY at gnu.org (Axilleas P) Date: Thu, 18 Aug 2011 11:30:37 +0000 Subject: [sr #107777] filezilla fails to start with gnutls 3.0.0 Message-ID: <20110818-113036.sv84572.8590@savannah.gnu.org> URL: Summary: filezilla fails to start with gnutls 3.0.0 Project: GnuTLS Submitted by: axil Submitted on: Thu 18 Aug 2011 11:30:36 AM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: I get the following error when running filezilla. filezilla: error while loading shared libraries: libgnutls.so.26: cannot open shared object file: No such file or directory Reverting back to 2.12.7 solves the issue. OS: Archlinux x86_64 kernel: 3.0.3 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Aug 18 14:01:46 2011 From: INVALID.NOREPLY at gnu.org (Andreas Metzler) Date: Thu, 18 Aug 2011 12:01:46 +0000 Subject: [sr #107777] filezilla fails to start with gnutls 3.0.0 In-Reply-To: <20110818-113036.sv84572.8590@savannah.gnu.org> References: <20110818-113036.sv84572.8590@savannah.gnu.org> Message-ID: <20110818-140145.sv20807.79840@savannah.gnu.org> Follow-up Comment #1, sr #107777 (project gnutls): Hello, This is not a bug in gnutls. GnuTLS 3.0.0 includes some ABI/APOI changes and has therefore changed the soname to libgnutls.so.28. Any depending packages need to be rebuilt against the new version of gnutls. cu andreas _______________________________________________________ Reply to this item at: _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ From ametzler at downhill.at.eu.org Fri Aug 19 19:41:10 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Fri, 19 Aug 2011 19:41:10 +0200 Subject: GnuTLS 3.0.0 a first look at reverse dependencies Message-ID: <20110819174110.GA2105@downhill.g.la> Hello, yesterday I have tried building all packages in Debian/unstable the build-depend on libgnutls-dev. Out of 129 source packages 47 failed. 28 of these were triggered by failing to find gcrypt (#include or -lgcrypt). Because GnuTLS 3.0.0 does not use gcrypt as backend, libgnutls-dev does not depend on libgcrypt11-dev anymore and was therefore not automatically installed. The 19 errors which are not gcrypt related seem to be not too hard: 2 break because GNUTLS_COMP_LZO was dropped (easily fixed, bugreport will follow) 3 stumble upon missing gnutls_certificate_verify_peers (easily fixed, bugreports were submitted some weeks ago.) at least 1 will need to replace gnutls_certificate_get_x509_cas with gnutls_certificate_get_issuer() Most of the of the other build failures are not necessarily gnutls-related, the packages either already have non build errors or the build-dependencies are not installable currently. ------------------------------ The gcrypt related errors seem to more difficult: Only 5 of these 28 are fixed trivially (bugs already submitted), they link/include gcrypt without any need. 14 use some multithread related code (GCRY_THREAD_OPTION_*)[1]. A surprising number of packages seem (my grep pattern might be off) to really use gcrypt directly[2] cu andreas [1] claws-mail-3.7.9 eet-1.4.0 glib-networking-2.28.7 gtk-vnc-0.4.3 libprelude-1.0.0 nufw-2.4.3 nzbget-0.7.0 postal-0.70 rsyslog-5.8.3 ucommon-5.0.5 vlc-1.1.11 vpnc-0.5.3r449 wzdftpd-0.8.3 xfce4-mailwatch-plugin-1.1.0 [2] eet-1.4.0 gtk-vnc-0.4.3 ircd-ratbox-3.0.6.dfsg jd-2.8.2-110808 libggz-0.0.14.1 libprelude-1.0.0 network-manager-0.8.4.0 nufw-2.4.3 nzbget-0.7.0 openvas-libraries-2.0.4 rtmpdump-2.3 ucommon-5.0.5 vlc-1.1.11 vpnc-0.5.3r449 wireshark-1.6.1 xfce4-mailwatch-plugin-1.1.0 xmlsec1-1.2.14 -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Fri Aug 19 21:23:29 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 19 Aug 2011 21:23:29 +0200 Subject: GnuTLS 3.0.0 a first look at reverse dependencies In-Reply-To: <20110819174110.GA2105@downhill.g.la> References: <20110819174110.GA2105@downhill.g.la> Message-ID: <4E4EB831.70305@gnutls.org> On 08/19/2011 07:41 PM, Andreas Metzler wrote: > Hello, yesterday I have tried building all packages in > Debian/unstable the build-depend on libgnutls-dev. Hello Andreas, Thanks. If help is needed on the conversion of any of those don't hesitate to ask. > Most of the of the other build failures are not necessarily > gnutls-related, the packages either already have non build errors or > the build-dependencies are not installable currently. > ------------------------------ The gcrypt related errors seem to > more difficult: [...] > 14 use some multithread related code (GCRY_THREAD_OPTION_*)[1]. A If their only call of gcrypt is that, it could be put in an if-clause like below (both the call and the header). #if GNUTLS_VERSION_NUMBER <= 0x020b00 gcry_control() #endif > surprising number of packages seem (my grep pattern might be off) to > really use gcrypt directly[2] Those need to be linked with gcrypt as well and there is not much it can be done. If their usage of gcrypt is simple (e.g. for a hash or a cipher) they could use gnutls/crypto.h API instead. This is not really required though, unless they don't want the direct gcrypt dependency. regards, Nikos From INVALID.NOREPLY at gnu.org Sat Aug 20 10:42:52 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sat, 20 Aug 2011 08:42:52 +0000 Subject: [sr #107777] filezilla fails to start with gnutls 3.0.0 In-Reply-To: <20110818-140145.sv20807.79840@savannah.gnu.org> References: <20110818-113036.sv84572.8590@savannah.gnu.org> <20110818-140145.sv20807.79840@savannah.gnu.org> Message-ID: <20110820-114252.sv707.74745@savannah.gnu.org> Update of sr #107777 (project gnutls): Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Sun Aug 21 00:06:27 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 21 Aug 2011 00:06:27 +0200 Subject: gnutls 3.0.1 Message-ID: <4E502FE3.4050802@gnutls.org> Hello, I've just released gnutls 3.0.1 It includes bug fixes and few feature additions. * Version 3.0.1 (released 2011-08-20) ** libgnutls: gnutls_certificate_set_x509_key_file() and friends support server name indication. If multiple certificates are set using these functions the proper one will be selected during a handshake. ** libgnutls: Added AES-256-GCM which was left out from the previous release. Reported by Benjamin Hof. ** libgnutls: When asking for a PKCS# 11 PIN multiple times, the flags in the callback were not being updated to reflect for PIN low count or final try. ** libgnutls: Do not allow second instances of PKCS #11 modules. ** libgnutls: fixed alignment issue in AES-NI code. ** libgnutls: The config file at gnutls_pkcs11_init() is being read if provided. ** libgnutls: Ensure that a certificate list specified using gnutls_certificate_set_x509_key() and friends, is sorted according to TLS specification (from subject to issuer). ** libgnutls: Added GNUTLS_X509_CRT_LIST_FAIL_IF_UNSORTED flag for gnutls_x509_crt_list_import. It checks whether the list to be imported is properly sorted. ** crywrap: Added to the distribution. It is an application that proxies TLS session to a port using a plaintext service. ** doc: Many GTK-DOC improvements. ** i18n: Translations were updated. ** API and ABI modifications: GNUTLS_X509_CRT_LIST_FAIL_IF_UNSORTED: New element in gnutls_certificate_import_flags GNUTLS_PKCS11_PIN_WRONG: New flag for PIN callback Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.1.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.1.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.1.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.1.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.1.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.1.tar.xz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Sun Aug 21 00:38:24 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 21 Aug 2011 00:38:24 +0200 Subject: gnutls 2.12.9 Message-ID: <4E503760.7030601@gnutls.org> Hello, I've just released gnutls 2.12.9. This release fixes an issue in PKCS #11 PIN handling that could lead to a card lock if wrong PIN was being supplied to p11tool. * Version 2.12.9 (released 2011-08-21) ** libgnutls-extra: Replaced enumeration with unsigned int, in openssl.h to make it identical to the 3.0.0 version. This shouldn't introduce binary incompatibility. ** libgnutls: When asking for a PIN multiple times, the flags in the callback were not being updated to reflect for PIN low count or final try. ** API and ABI modifications: GNUTLS_PKCS11_PIN_WRONG: New flag for PIN callback Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.9.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.9.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.9.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.9.tar.bz2.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Sun Aug 21 10:29:10 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 21 Aug 2011 10:29:10 +0200 Subject: gnutls 3.0.1 In-Reply-To: <20110821095851.1a6c5f72@workstation64.home> References: <4E502FE3.4050802@gnutls.org> <20110821095851.1a6c5f72@workstation64.home> Message-ID: <4E50C1D6.2060209@gnutls.org> On 08/21/2011 09:58 AM, Andreas Radke wrote: > Am Sun, 21 Aug 2011 00:06:27 +0200 > schrieb Nikos Mavrogiannopoulos : > >> Hello, >> I've just released gnutls 3.0.1 It includes bug fixes and few feature >> additions. > > I've just built the ArchLinux packages. All usual tests get passed this > time for me. For the first time I've tried to add the valgrind tests and > this brings some errors. Maybe you can have a look if they should be > fixed or are harmless. > full build log: http://pastebin.com/ygD2Vzb6 They are not. I must be the glibc headers issue mentioned in https://savannah.gnu.org/support/?107775 by Andreas. It has nothing to do with gnutls. regards, Nikos From ametzler at downhill.at.eu.org Sun Aug 21 14:37:10 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 21 Aug 2011 14:37:10 +0200 Subject: gnutls 3.0.1 In-Reply-To: <4E502FE3.4050802@gnutls.org> References: <4E502FE3.4050802@gnutls.org> Message-ID: <20110821123710.GA2188@downhill.g.la> On 2011-08-21 Nikos Mavrogiannopoulos wrote: [...] > ** crywrap: Added to the distribution. It is an application > that proxies TLS session to a port using a plaintext service. [...] Hello, According to the headers the application itself is not Copyright Free Software Foundation, Inc." but | Copyright (C) 2003 Gergely Nagy | Copyright (C) 2011 Nikos Mavrogiannopoulos The manpage has a non-standard[1] license: .\" Copyright (C) 2003 Gergely Nagy .\" .\" Permission is granted to make and distribute verbatim copies of this .\" manual provided the copyright notice and this permission notice are .\" preserved on all copies. .\" .\" Permission is granted to copy and distribute modified versions of this .\" manual under the conditions for verbatim copying, provided that the .\" entire resulting derived work is distributed under the terms of a .\" permission notice identical to this one. .\" .\" Permission is granted to copy and distribute translations of this .\" manual into another language, under the above conditions for modified .\" versions, except that this permission notice may be stated in a .\" translation approved by the Author. I am really just wondering whether this is correct (perhaps a copyright tassignment to FDL happened), there is absolutely no problem with these license/copyright staements. cu andreas [1] The other monapages do not a copyright/license statement, I have always assumed they were GPLv3+ or FDLv3+) From nmav at gnutls.org Sun Aug 21 14:52:32 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 21 Aug 2011 14:52:32 +0200 Subject: gnutls 3.0.1 In-Reply-To: <20110821123710.GA2188@downhill.g.la> References: <4E502FE3.4050802@gnutls.org> <20110821123710.GA2188@downhill.g.la> Message-ID: <4E50FF90.20106@gnutls.org> On 08/21/2011 02:37 PM, Andreas Metzler wrote: > Hello, > According to the headers the application itself is not Copyright > Free Software Foundation, Inc." but > | Copyright (C) 2003 Gergely Nagy > | Copyright (C) 2011 Nikos Mavrogiannopoulos It is not. This application is not part of gnutls. It is only distributed with it. > The manpage has a non-standard[1] license: > .\" Copyright (C) 2003 Gergely Nagy [...] I hadn't notice that. I'll make a release with this manpage removed from gnutls' distribution. > [1] The other monapages do not a copyright/license statement, I have > always assumed they were GPLv3+ or FDLv3+) They are part of GnuTLS documentation that is FDL. regards, Nikos From snackypants at gmail.com Mon Aug 22 03:01:04 2011 From: snackypants at gmail.com (Chris Palmer) Date: Sun, 21 Aug 2011 18:01:04 -0700 Subject: How does GnuTLS handle the known-bad Debian keys? Message-ID: <01170D32-AF7B-4376-BD8B-F25760CFA0CC@gmail.com> I can't seem to find any key-blacklist-checking code in GnuTLS. Perhaps I'm not looking in the right places; I am very new to this codebase. GnuTLS should use such a blacklist, either built-in or in an external package, because the fundamental guarantee of the library is to help applications establish secure connections. Connections authenticated with the weak Debian keys simply cannot provide that guarantee. This is one of those (hopefully rare) cases in which policy concerns impinge on what should be a pure mechanism. From a utilitarian or pragmatic viewpoint, adding blacklist support in the library will help the most people with the least effort, as compared to e.g. having each individual application handle blacklisting known-bad keys. In fact, the latter is just not going to happen, and isn't happening now. I have a trivial bit of portable C code that searches a blacklist of known-bad key fingerprints. I'll send it along if you want it, but first I thought I'd gauge people's interest. Or maybe you'll point me to where the code already does handle this. :) I've CC'd my colleague Dan Auerbach of EFF, who has been working with me to audit the security of prominent open source applications. From andyrtr at googlemail.com Sun Aug 21 09:58:51 2011 From: andyrtr at googlemail.com (Andreas Radke) Date: Sun, 21 Aug 2011 09:58:51 +0200 Subject: gnutls 3.0.1 In-Reply-To: <4E502FE3.4050802@gnutls.org> References: <4E502FE3.4050802@gnutls.org> Message-ID: <20110821095851.1a6c5f72@workstation64.home> Am Sun, 21 Aug 2011 00:06:27 +0200 schrieb Nikos Mavrogiannopoulos : > Hello, > I've just released gnutls 3.0.1 It includes bug fixes and few feature > additions. I've just built the ArchLinux packages. All usual tests get passed this time for me. For the first time I've tried to add the valgrind tests and this brings some errors. Maybe you can have a look if they should be fixed or are harmless. full build log: http://pastebin.com/ygD2Vzb6 regards. -Andy From INVALID.NOREPLY at gnu.org Mon Aug 22 09:56:44 2011 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Mon, 22 Aug 2011 07:56:44 +0000 Subject: [sr #107775] GnuTLS 3.0.0 causes segfault In-Reply-To: <20110817-084652.sv20807.15870@savannah.gnu.org> References: <20110815-032626.sv84482.99672@savannah.gnu.org> <20110815-093149.sv707.10582@savannah.gnu.org> <20110815-195401.sv84482.82513@savannah.gnu.org> <20110815-232339.sv707.32450@savannah.gnu.org> <20110816-185337.sv84482.71177@savannah.gnu.org> <20110817-000646.sv707.69169@savannah.gnu.org> <20110817-084652.sv20807.15870@savannah.gnu.org> Message-ID: <20110822-075644.sv0.20175@savannah.gnu.org> Follow-up Comment #7, sr #107775 (project gnutls): Hi, I can reproduce this problem with mcabber. strace says: connect(3, {sa_family=AF_INET, sin_port=htons(5223), sin_addr=inet_addr("217.10.10.194")}, 16) = -1 EINPROGRESS (Operation now in progress) [...] poll([{fd=3, events=POLLOUT}, {fd=0, events=POLLIN|POLLPRI}], 2, -1) = 1 ([{fd=3, revents=POLLOUT}]) open("/etc/ssl/certs/ca-certificates.crt", O_RDONLY) = 5 [...] writev(3, [{"263 2761 27233NQ373C370+25361334F 321y!6#5|1}34"..., 195}], 1) = 195 recv(3, "2631 001", 5, 0) = 5 recv(3, "2 -31NQ373C374211v347276y(r30222236v244K23321730535;372252264"..., 49, 0) = 49 recv(3, "263123b", 5, 0) = 5 recv(3, "v 23^ 23[ 6 0502026 0102023351240321223 2673610r6t"..., 4962, 0) = 1389 recv(3, "16214376217<|303}+W'1320A332256)241315h2325726031250|305366212365203352"..., 3573, 0) = 1448 recv(3, "X>351224+221P20733326^3262143143671720fRN32026a345345nl27727307rF"..., 2125, 0) = 1448 recv(3, "crl046t`206H1206370B1104'26%http://www.c"..., 677, 0) = 677 recv(3, "2631 4", 5, 0) = 5 recv(3, "16 ", 4, 0) = 4 [...] writev(3, [{"", 4294967269}, {"", 4294967269}, {"2631 360sI-31533262$5343222402345201332306210?303224215266252`|36R"..., 245}], 3) = -1 EINVAL (Invalid argument) shutdown(3, SHUT_RDWR) = 0 close(3) = 0 The length argument to writev() is (unsigned int)-26. Valgrind only has complaints about libidn (read of size 4 with offset 4 in an allocation of size 7). This can't cause any corruption. Then comes the writev(): ==17779== Syscall param writev(vector[...]) points to unaddressable byte(s) ==17779== at 0x43C1ADE: writev (in /lib/libc-2.14.so) ==17779== Address 0x6dd6e67 is 0 bytes after a block of size 2,895 alloc'd ==17779== at 0x4026416: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==17779== by 0x44F271F: ??? (in /usr/lib/libgnutls.so.28.0.1) ==17779== by 0x44EE7CA: _gnutls_send_int (in /usr/lib/libgnutls.so.28.0.1) ==17779== by 0x44F47E6: ??? (in /usr/lib/libgnutls.so.28.0.1) ==17779== by 0x44F668C: ??? (in /usr/lib/libgnutls.so.28.0.1) ==17779== by 0x44F6B2C: ??? (in /usr/lib/libgnutls.so.28.0.1) ==17779== by 0x44F8C4F: ??? (in /usr/lib/libgnutls.so.28.0.1) ==17779== by 0x44FA558: gnutls_handshake (in /usr/lib/libgnutls.so.28.0.1) ==17779== by 0x4055427: ??? (in /usr/lib/libloudmouth-1.so.0.1.0) ==17779== by 0x4056F70: ??? (in /usr/lib/libloudmouth-1.so.0.1.0) ==17779== by 0x40576F8: ??? (in /usr/lib/libloudmouth-1.so.0.1.0) ==17779== by 0x40580D7: ??? (in /usr/lib/libloudmouth-1.so.0.1.0) All the packages used are archlinux x86 stock ones. I'd be happy about any hints on how I can debug this further. P.S.: How do I attach files? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Aug 22 13:41:43 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 22 Aug 2011 11:41:43 +0000 Subject: [sr #107775] GnuTLS 3.0.0 causes segfault In-Reply-To: <20110822-075644.sv0.20175@savannah.gnu.org> References: <20110815-032626.sv84482.99672@savannah.gnu.org> <20110815-093149.sv707.10582@savannah.gnu.org> <20110815-195401.sv84482.82513@savannah.gnu.org> <20110815-232339.sv707.32450@savannah.gnu.org> <20110816-185337.sv84482.71177@savannah.gnu.org> <20110817-000646.sv707.69169@savannah.gnu.org> <20110817-084652.sv20807.15870@savannah.gnu.org> <20110822-075644.sv0.20175@savannah.gnu.org> Message-ID: <20110822-144143.sv707.3951@savannah.gnu.org> Follow-up Comment #8, sr #107775 (project gnutls): To attach a file check below the discussion. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ametzler at downhill.at.eu.org Mon Aug 22 19:33:29 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon, 22 Aug 2011 19:33:29 +0200 Subject: gnutls 2.12.x does not export gnutls_openpgp_privkey_sign_hash Message-ID: <20110822173328.GD2192@downhill.g.la> Hello, gnutls 2.12.x is lacking gnutls_openpgp_privkey_sign_hash. The symbol was *intentionally* reintroduced in the headers to prevent an ABI break baut re-adding it to lib/libgnutls.map somhow slipped the net. This was diagnosed by Jakub Wilk. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -------------- next part -------------- A non-text attachment was scrubbed... Name: 22_export_gnutls_openpgp_privkey_sign_hash.diff Type: text/x-diff Size: 528 bytes Desc: not available URL: From nmav at gnutls.org Mon Aug 22 20:48:49 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 22 Aug 2011 20:48:49 +0200 Subject: gnutls 2.12.x does not export gnutls_openpgp_privkey_sign_hash In-Reply-To: <20110822173328.GD2192@downhill.g.la> References: <20110822173328.GD2192@downhill.g.la> Message-ID: <4E52A491.80301@gnutls.org> On 08/22/2011 07:33 PM, Andreas Metzler wrote: > Hello, > > gnutls 2.12.x is lacking gnutls_openpgp_privkey_sign_hash. The symbol > was *intentionally* reintroduced in the headers to prevent an ABI > break baut re-adding it to lib/libgnutls.map somhow slipped the net. > This was diagnosed by Jakub Wilk. Applied, thanks! From nmav at gnutls.org Mon Aug 22 20:52:05 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 22 Aug 2011 20:52:05 +0200 Subject: How does GnuTLS handle the known-bad Debian keys? In-Reply-To: <01170D32-AF7B-4376-BD8B-F25760CFA0CC@gmail.com> References: <01170D32-AF7B-4376-BD8B-F25760CFA0CC@gmail.com> Message-ID: <4E52A555.6080802@gnutls.org> On 08/22/2011 03:01 AM, Chris Palmer wrote: > I can't seem to find any key-blacklist-checking code in GnuTLS. > Perhaps I'm not looking in the right places; I am very new to this > codebase. > GnuTLS should use such a blacklist, either built-in or in an external > package, because the fundamental guarantee of the library is to help > applications establish secure connections. Connections authenticated > with the weak Debian keys simply cannot provide that guarantee. This > is one of those (hopefully rare) cases in which policy concerns > impinge on what should be a pure mechanism. > From a utilitarian or pragmatic viewpoint, adding blacklist support > in the library will help the most people with the least effort, as > compared to e.g. having each individual application handle > blacklisting known-bad keys. In fact, the latter is just not going to > happen, and isn't happening now. > I have a trivial bit of portable C code that searches a blacklist of > known-bad key fingerprints. I'll send it along if you want it, but > first I thought I'd gauge people's interest. Or maybe you'll point me > to where the code already does handle this. :) We do not check for the debian keys. If a patch is provided we can consider for inclusion. regards, Nikos From valery.meleshko at ximxim.com Fri Aug 26 11:15:42 2011 From: valery.meleshko at ximxim.com (Meleshko Valera) Date: Fri, 26 Aug 2011 12:15:42 +0300 Subject: bug? Message-ID: <4E57643E.2040301@ximxim.com> Making all in libextra make all-recursive Making all in gl make all-am CC hmac-md5.lo CC md5.lo CC memxor.lo CCLD libxgnu.la Making all in includes CC gnutls_extra.lo CC fipsmd5.lo CC ext_inner_application.lo CC gnutls_ia.lo CC gnutls_openssl.lo CC openssl_compat.lo CCLD libgnutls-extra.la CCLD libgnutls-openssl.la Making all in gl make all-recursive Making all in tests make all-recursive Making all in . CC c-ctype.lo CC close-hook.lo In file included from ./sys/select.h:52, from /usr/include/sys/types.h:299, from /usr/include/unistd.h:41, from ./unistd.h:44, from close-hook.c:24: ./sys/time.h:395: error: conflicting types for 'gettimeofday' /usr/include/sys/time.h:308: error: previous declaration of 'gettimeofday' was here ./sys/time.h:395: error: conflicting types for 'gettimeofday' /usr/include/sys/time.h:308: error: previous declaration of 'gettimeofday' was here *** Error code 1 1 error *** Error code 1 1 error *** Error code 2 1 error *** Error code 1 1 error *** Error code 2 1 error *** Error code 1 Stop in /usr/ports/security/gnutls. # CC --version CC (GCC) 3.4.6 [FreeBSD] 20060305 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # uname -a FreeBSD viking.it.local 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 UTC 2007 -- Valery Meleshko From ametzler at downhill.at.eu.org Sat Aug 27 14:53:40 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 27 Aug 2011 14:53:40 +0200 Subject: Bug#638595: WWWOFFLE HTTPS now unusable In-Reply-To: References: <20110820105830.GA2096@msgid.wurtel.net> <87hb5cfh72.fsf@jidanni.org> <20110822185437.GH2192@downhill.g.la> Message-ID: <20110827125340.GA2023@downhill.g.la> On 2011-08-25 "Andrew M. Bishop" wrote: [...] > A better test is to do the following against your running WWWOFFLE > server (you don't need to be online): > lynx -dump https://localhost:8443/ ok. That makes it reproducible. gnutls-cli or openssl s_client -connect 127.0.0.1:8443 also does the trick. [...] > I can run WWWOFFLE under gdb to demonstrate the crash like this (while > wwwoffled is running I run the lynx command above): > # gdb /home/amb/wwwoffle-2.9g/src/wwwoffled [...] Throwing in a slightly better readable backtrace (against gnutls 2.12.7): ---------------------------------- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf7d036c0 (LWP 24626)] _gcry_mpi_normalize (a=0x0) at mpi-bit.c:60 60 mpi-bit.c: No such file or directory. in mpi-bit.c (gdb) bt #0 _gcry_mpi_normalize (a=0x0) at mpi-bit.c:60 #1 0xf7d87e7a in _gcry_mpi_get_nbits (a=0x0) at mpi-bit.c:78 #2 0xf7d3c93b in gcry_mpi_get_nbits (a=0x0) at visibility.c:421 #3 0xf7f9d4eb in wrap_gcry_mpi_get_nbits (a=0x0) at mpi.c:131 #4 0xf7f2888a in _gnutls_pkcs1_rsa_decrypt (plaintext=0xffffd2b0, ciphertext=0xffffd2b8, params=0x810fb10, params_len=0, btype=2) at gnutls_pk.c:223 #5 0xf7f4000b in gnutls_privkey_decrypt_data (key=0x8111ed0, flags=0, ciphertext=0xffffd2b8, plaintext=0xffffd2b0) at gnutls_privkey.c:614 #6 0xf7f2481e in proc_rsa_client_kx (session=0x8110490, data=0x810fbb8 "", _data_size=66) at auth_rsa.c:180 #7 0xf7f1d1f1 in _gnutls_recv_client_kx_message (session=0x8110490) at gnutls_kx.c:456 #8 0xf7f19076 in _gnutls_handshake_server (session=0x8110490) at gnutls_handshake.c:3059 #9 0xf7f1995f in gnutls_handshake (session=0x8110490) at gnutls_handshake.c:2677 #10 0x080875e3 in io_init_gnutls (fd=0, host=0x80fc580 "localhost", type=1) at iognutls.c:160 #11 0x080853ab in configure_io_gnutls (fd=0, host=0x80fc580 "localhost", type=1) at io.c:376 #12 0x0804e863 in wwwoffles (online=0, fetching=0, client=0) at wwwoffles.c:174 #13 0x080641ad in ForkServer (fd=0) at connect.c:501 #14 0x0804ca55 in main (argc=5, argv=0xffffd884) at wwwoffled.c:649 ---------------------------------- downgrading libgnutls26 to 2.10.5 fixes the issue. I have trying to bisect this, but neither Gnutls master nor gnutls_2_12_x are bisectable, the tree does not build for a a long time, from August 2009 to May 2010. (after 9c8631c68a728584b46b7d2ceff2e872ae8a59dd and before 743dedcddb41d9a29a0e92fa85a24a5c270d5f01). Making wwwoffle generate/use v3 certs or using Gnutls 3.0 does not improve things. cu andreas [ Full quote, since I am Cc-ing bug-gnutls at gnu.org] > This is with a vanilla wwwoffle 2.9g - unmodified since released. > If you look at the WWWOFFLE code you will see that I am paranoid about > a problem with gnutls and I check the return value from every gnutls > function that is called before trying the handshake. > Another way to view the problem is to look at the libgnutls functions > that WWWOFFLE calls: > # ltrace -l /usr/lib/i386-linux-gnu/libgnutls.so \ > /home/amb/wwwoffle-2.9g/src/wwwoffled -c /etc/wwwoffle/wwwoffle.conf -f > gnutls_global_init(0x810cf18, 0x80f01a4, 0x80f030e, 0xbf9e56c8, 88) = 0 > gnutls_x509_privkey_init(0xbf9e568c, 0xbf9e5284, 1024, 0xb78b0840, 0xb77bc28c) = 0 > gnutls_x509_privkey_import(0x8113830, 0xbf9e5684, 1, 0xb78b0840, 0xb77bc28c) = 0 > gnutls_x509_crt_list_import(0x80fbf60, 0xbf9e565c, 0xbf9e5654, 1, 1) = 1 > gnutls_x509_crt_get_activation_time(0x81039f0, 0x80d9150, 0xbf9e56b8, 0xbf9e56c8, 88) = 0x4abe3b3f > gnutls_x509_crt_get_expiration_time(0x81039f0, 0x80d9150, 0xbf9e56b8, 0xbf9e56c8, 88) = 0x5061d5bf > gnutls_dh_params_init(0x80fbf54, 0x80d9150, 0xbf9e56b8, 0xbf9e56c8, 88) = 0 > gnutls_dh_params_generate2(0x80feaa8, 1024, 0xbf9e56b8, 0xbf9e56c8, 88) = 0 > ... > gnutls_init(0x82af284, 1, 10, 0x80f9104, 0xbf808cf8) = 0 > gnutls_set_default_priority(0x8195178, 1, 10, 0x80f9104, 0xbf808cf8) = 0 > gnutls_x509_privkey_init(0xbf808bec, 0xbf8087e4, 1024, 0x80fc480, 0xbf808822) = 0 > gnutls_x509_privkey_import(0x818dd18, 0xbf808be4, 1, 0x80fc480, 0xbf808822) = 0 > gnutls_x509_crt_list_import(0x80fbf60, 0xbf808bbc, 0xbf808bb4, 1, 1) = 1 > gnutls_x509_crt_get_activation_time(0x8159d50, 0x82b1c28, 0xbf808c4c, 0x80fc480, 1) = 0x4e4fff40 > gnutls_x509_crt_get_expiration_time(0x8159d50, 0x82b1c28, 0xbf808c4c, 0x80fc480, 1) = 0x53f399c0 > gnutls_x509_crt_verify(0x8159d50, 0x80fbf50, 1, 0, 0xbf808cac) = 0 > gnutls_certificate_allocate_credentials(0xbf808ca4, 0x80fbf50, 1, 0, 0xbf808cac) = 0 > gnutls_certificate_set_x509_key(0x818ff70, 0xbf808ca8, 1, 0x818dd18, 0xbf808cac) = 0 > gnutls_certificate_set_dh_params(0x818ff70, 0x80feaa8, 1, 0x818dd18, 0xbf808cac) = 0x818ff70 > gnutls_x509_crt_deinit(0x8159d50, 0x80feaa8, 1, 0x818dd18, 0xbf808cac) = 0xb77063c0 > gnutls_x509_privkey_deinit(0x818dd18, 0x80feaa8, 1, 0x818dd18, 0xbf808cac) = 161 > gnutls_credentials_set(0x8195178, 1, 0x818ff70, 0x80f9104, 0xbf808cf8) = 0 > gnutls_transport_set_ptr(0x8195178, 0, 0x818ff70, 0x80f9104, 0xbf808cf8) = 0x8195178 > gnutls_handshake(0x8195178, 0, 0x818ff70, 0x80f9104, 0xbf808cf8 > Looking at the list of functions I can see that there are two > gnutls_x509_*_deinit() functions called before the handshake. > Calling the first one, gnutls_x509_crt_deinit(), is OK, but calling > the second one, gnutls_x509_privkey_deinit(), before the handshake > will cause it to crash. > The documentation for these functions don't say that you can't call > the 'deinit' function until after the handshake. The libgnutls NEWS > file doesn't say that there is an ABI change in this area either. It > certainly used to work that you could do this. From ametzler at downhill.at.eu.org Sat Aug 27 18:58:35 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 27 Aug 2011 18:58:35 +0200 Subject: Bug#638595: WWWOFFLE HTTPS now unusable In-Reply-To: <20110827125340.GA2023@downhill.g.la> References: <20110820105830.GA2096@msgid.wurtel.net> <87hb5cfh72.fsf@jidanni.org> <20110822185437.GH2192@downhill.g.la> <20110827125340.GA2023@downhill.g.la> Message-ID: <20110827165835.GB2023@downhill.g.la> On 2011-08-27 Andreas Metzler wrote: > On 2011-08-25 "Andrew M. Bishop" wrote: [...] >> Another way to view the problem is to look at the libgnutls functions >> that WWWOFFLE calls: >> # ltrace -l /usr/lib/i386-linux-gnu/libgnutls.so \ >> /home/amb/wwwoffle-2.9g/src/wwwoffled -c /etc/wwwoffle/wwwoffle.conf -f [...] >> gnutls_x509_privkey_init(0xbf808bec, 0xbf8087e4, 1024, 0x80fc480, 0xbf808822) = 0 >> gnutls_x509_privkey_import(0x818dd18, 0xbf808be4, 1, 0x80fc480, 0xbf808822) = 0 [...] >> gnutls_certificate_set_x509_key(0x818ff70, 0xbf808ca8, 1, 0x818dd18, 0xbf808cac) = 0 [...] >> gnutls_x509_privkey_deinit(0x818dd18, 0x80feaa8, 1, 0x818dd18, 0xbf808cac) = 161 >> gnutls_credentials_set(0x8195178, 1, 0x818ff70, 0x80f9104, 0xbf808cf8) = 0 >> gnutls_transport_set_ptr(0x8195178, 0, 0x818ff70, 0x80f9104, 0xbf808cf8) = 0x8195178 >> gnutls_handshake(0x8195178, 0, 0x818ff70, 0x80f9104, 0xbf808cf8 [...] >> The documentation for these functions don't say that you can't call >> the 'deinit' function until after the handshake. The libgnutls NEWS >> file doesn't say that there is an ABI change in this area either. It >> certainly used to work that you could do this. Hello, I would not be surprised if upstream's response was "don't do this, this was never supposed to work" but at a quick look I could not find respective reference in the docs either. cu andreas From INVALID.NOREPLY at gnu.org Sat Aug 27 19:27:53 2011 From: INVALID.NOREPLY at gnu.org (Andreas Metzler) Date: Sat, 27 Aug 2011 17:27:53 +0000 Subject: [sr #107784] fails to find second dns entry of a cert - error: get_subject/issuer_alt_name2: ASN1 parser: Element was not found Message-ID: <20110827-192752.sv20807.20609@savannah.gnu.org> URL: Summary: fails to find second dns entry of a cert - error: get_subject/issuer_alt_name2: ASN1 parser: Element was not found Project: GnuTLS Submitted by: ametzler Submitted on: Sa 27 Aug 2011 19:27:52 CEST Category: Included programs Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: Hello, this is http://bugs.debian.org/638586 reported by Sebastian Reichel. certtool Gnutls 2.12.7 and later (including 3.0.1) cannot parse the certificate http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=gnutls-broken-cert;att=1;bug=638586 anymore. Where certtool -i on earlier versions (e.g. 2.10.5) said Subject Alternative Name (not critical): DNSname: ring0.de XMPP Address: ring0.de DNSname: *.ring0.de XMPP Address: *.ring0.de later versions show this instead: Subject Alternative Name (not critical): DNSname: ring0.de error: get_subject/issuer_alt_name2: ASN1 parser: Element was not found. Signature Algorithm: RSA-SHA1 _______________________________________________________ Reply to this item at: _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ From nmav at gnutls.org Sat Aug 27 20:42:46 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 27 Aug 2011 20:42:46 +0200 Subject: Bug#638595: WWWOFFLE HTTPS now unusable In-Reply-To: <20110827165835.GB2023@downhill.g.la> References: <20110820105830.GA2096@msgid.wurtel.net> <87hb5cfh72.fsf@jidanni.org> <20110822185437.GH2192@downhill.g.la> <20110827125340.GA2023@downhill.g.la> <20110827165835.GB2023@downhill.g.la> Message-ID: <4E593AA6.7040205@gnutls.org> On 08/27/2011 06:58 PM, Andreas Metzler wrote: > Hello, > I would not be surprised if upstream's response was "don't do this, this > was never supposed to work" but at a quick look I could not find > respective reference in the docs either. It is a bug introduced in 2.12.x. Does the attached patch fix the issue? regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-gnutls_certificate_set_x509_key-and-gnutls_certifica.patch Type: text/x-patch Size: 8155 bytes Desc: not available URL: From INVALID.NOREPLY at gnu.org Sat Aug 27 20:53:20 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sat, 27 Aug 2011 18:53:20 +0000 Subject: [sr #107784] fails to find second dns entry of a cert - error: get_subject/issuer_alt_name2: ASN1 parser: Element was not found In-Reply-To: <20110827-192752.sv20807.20609@savannah.gnu.org> References: <20110827-192752.sv20807.20609@savannah.gnu.org> Message-ID: <20110827-215319.sv707.8096@savannah.gnu.org> Update of sr #107784 (project gnutls): Status: None => Ready For Test Assigned to: None => nmav _______________________________________________________ Follow-up Comment #1: Does the attached patch fix the issue? (file #23887) _______________________________________________________ Additional Item Attachment: File name: 0001-XmppAddr-UTF8String.patch Size:0 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Sat Aug 27 20:55:25 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 27 Aug 2011 20:55:25 +0200 Subject: bug? In-Reply-To: <4E57643E.2040301@ximxim.com> References: <4E57643E.2040301@ximxim.com> Message-ID: <4E593D9D.6030608@gnutls.org> On 08/26/2011 11:15 AM, Meleshko Valera wrote: > In file included from ./sys/select.h:52, > from /usr/include/sys/types.h:299, > from /usr/include/unistd.h:41, > from ./unistd.h:44, > from close-hook.c:24: > ./sys/time.h:395: error: conflicting types for 'gettimeofday' > /usr/include/sys/time.h:308: error: previous declaration of > 'gettimeofday' was here > ./sys/time.h:395: error: conflicting types for 'gettimeofday' > /usr/include/sys/time.h:308: error: previous declaration of > 'gettimeofday' was here > *** Error code 1 > 1 error > *** Error code 1 > 1 error > *** Error code 2 > 1 error > *** Error code 1 > 1 error > *** Error code 2 > 1 error > *** Error code 1 > Stop in /usr/ports/security/gnutls. Hello, Thanks for the report. It looks like a bug in the included gnulib. Is this the latest version of gnutls? regards, Nikos From INVALID.NOREPLY at gnu.org Sun Aug 28 09:00:33 2011 From: INVALID.NOREPLY at gnu.org (Andreas Metzler) Date: Sun, 28 Aug 2011 07:00:33 +0000 Subject: [sr #107784] fails to find second dns entry of a cert - error: get_subject/issuer_alt_name2: ASN1 parser: Element was not found In-Reply-To: <20110827-215319.sv707.8096@savannah.gnu.org> References: <20110827-192752.sv20807.20609@savannah.gnu.org> <20110827-215319.sv707.8096@savannah.gnu.org> Message-ID: <20110828-090033.sv20807.17824@savannah.gnu.org> Follow-up Comment #2, sr #107784 (project gnutls): > Does the attached patch fix the issue? Works for me. Thank you very much for the quick fix. _______________________________________________________ Reply to this item at: _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ From ametzler at downhill.at.eu.org Sun Aug 28 09:07:16 2011 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 28 Aug 2011 09:07:16 +0200 Subject: Bug#638595: WWWOFFLE HTTPS now unusable In-Reply-To: <4E593AA6.7040205@gnutls.org> References: <20110820105830.GA2096@msgid.wurtel.net> <87hb5cfh72.fsf@jidanni.org> <20110822185437.GH2192@downhill.g.la> <20110827125340.GA2023@downhill.g.la> <20110827165835.GB2023@downhill.g.la> <4E593AA6.7040205@gnutls.org> Message-ID: <20110828070716.GA2119@downhill.g.la> On 2011-08-27 Nikos Mavrogiannopoulos wrote: [...] > It is a bug introduced in 2.12.x. Does the attached patch > fix the issue? [...] Hello, it seems to fix the issue for me, the minimal testcase (lynx -dump https://localhost:8443/) now works. thanks, cu andreas From INVALID.NOREPLY at gnu.org Mon Aug 29 15:33:22 2011 From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen) Date: Mon, 29 Aug 2011 13:33:22 +0000 Subject: [sr #107785] gnutls_sign_func called with hash size of 20 bytes Message-ID: <20110829-133316.sv79827.56778@savannah.gnu.org> URL: Summary: gnutls_sign_func called with hash size of 20 bytes Project: GnuTLS Submitted by: cybear Submitted on: Mon Aug 29 13:33:16 2011 Category: Core library Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: Microsoft Windows _______________________________________________________ Details: I have used gnutls_sign_callback_set to set a sign function, and my function get called during the signing process, but the hash have a size of 20 bytes. I expect the hash to be 36 bytes accoring to the definition in SSL/TLS the hash to be signed by the client is by definition a concatenation of a SHA1 (20 bytes) and an MD5 (16 bytes) I am using GNUTLS 2.10.1. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Aug 29 15:41:09 2011 From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen) Date: Mon, 29 Aug 2011 13:41:09 +0000 Subject: [sr #107785] gnutls_sign_func called with hash size of 20 bytes In-Reply-To: <20110829-133316.sv79827.56778@savannah.gnu.org> References: <20110829-133316.sv79827.56778@savannah.gnu.org> Message-ID: <20110829-134109.sv79827.17998@savannah.gnu.org> Follow-up Comment #1, sr #107785 (project gnutls): I will attach logfile from server and client. (file #23892, file #23893) _______________________________________________________ Additional Item Attachment: File name: client2.log Size:63 KB File name: server2.log Size:61 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Aug 29 16:24:40 2011 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Mon, 29 Aug 2011 14:24:40 +0000 Subject: [sr #107785] gnutls_sign_func called with hash size of 20 bytes In-Reply-To: <20110829-134109.sv79827.17998@savannah.gnu.org> References: <20110829-133316.sv79827.56778@savannah.gnu.org> <20110829-134109.sv79827.17998@savannah.gnu.org> Message-ID: <20110829-142440.sv0.60552@savannah.gnu.org> Follow-up Comment #2, sr #107785 (project gnutls): TLS 1.0 with RSA signatures uses 36 bytes. Other protocol version (TLS 1.2 for example) might use different sizes. If possible we suggest against using the sign_callback but use the gnutls pkcs11 API instead. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From jidanni at jidanni.org Mon Aug 29 12:00:36 2011 From: jidanni at jidanni.org (jidanni at jidanni.org) Date: Mon, 29 Aug 2011 18:00:36 +0800 Subject: Bug#638595: WWWOFFLE HTTPS now unusable References: <20110828070716.GA2119@downhill.g.la> Message-ID: <8739gkh70b.fsf@jidanni.org> reopen 638595 thanks >>>>> "AM" == Andreas Metzler writes: AM> it seems to fix the issue for me, the minimal testcase (lynx -dump AM> https://localhost:8443/) now works. Did you try the test cases I listed? No. From jidanni at jidanni.org Mon Aug 29 18:11:00 2011 From: jidanni at jidanni.org (jidanni at jidanni.org) Date: Tue, 30 Aug 2011 00:11:00 +0800 Subject: Bug#638595: WWWOFFLE HTTPS now unusable References: Message-ID: <87aaasw63v.fsf@jidanni.org> # OK, so the gnutls upgrade fixed the segfaults, and the rest is a WWWOFFLE bug. reassign 638595 wwwoffle 2.9f-2.2 From amb at gedanken.demon.co.uk Mon Aug 29 17:48:38 2011 From: amb at gedanken.demon.co.uk (Andrew M. Bishop) Date: Mon, 29 Aug 2011 16:48:38 +0100 Subject: Bug#638595: WWWOFFLE HTTPS now unusable In-Reply-To: <8739gkh70b.fsf@jidanni.org> (jidanni@jidanni.org's message of "Mon, 29 Aug 2011 18:00:36 +0800") References: <20110828070716.GA2119@downhill.g.la> <8739gkh70b.fsf@jidanni.org> Message-ID: jidanni at jidanni.org writes: > reopen 638595 > thanks >>>>>> "AM" == Andreas Metzler writes: > AM> it seems to fix the issue for me, the minimal testcase (lynx -dump > AM> https://localhost:8443/) now works. > Did you try the test cases I listed? > No. I don't know why the problem occurs now and not before but I don't think that this part of it is a gnutls bug (although it may be a change in gnutls behaviour that WWWOFFLE doesn't handle well). The problem that you are having seems to be that one chunk of data from gnutls_record_recv() uncompresses into much more data than the output buffer can hold. This means that there is still lots of uncompressed raw data from the socket left over. This patch for WWWOFFLE tries to empty the existing socket buffer before requesting more (otherwise you end up requesting data after the last packet and gnutls gives an error). -------------- next part -------------- A non-text attachment was scrubbed... Name: io.c.diff Type: text/x-diff Size: 4103 bytes Desc: not available URL: -------------- next part -------------- As a side-note to the gnutls thing I found that this change in WWWOFFLE worked around the problem that we had instead of changing libgnutls. I can't be sure that it does the same thing though because my test showed that calling gnutls_x509_crt_deinit() was safe so it might be that we don't now free the crt when we finish. -------------------- certificates.c.diff -------------------- --- certificates.c (revision 2160) +++ certificates.c (revision 2161) @@ -559,6 +559,8 @@ if(!initialised) return; + gnutls_certificate_free_keys(cred); + gnutls_certificate_free_credentials(cred); } @@ -918,12 +920,6 @@ free(keyfilename); free(crtfilename); - if(crt) - gnutls_x509_crt_deinit(crt); - - if(privkey) - gnutls_x509_privkey_deinit(privkey); - return(cred); } -------------------- certificates.c.diff -------------------- -- Andrew. ---------------------------------------------------------------------- Andrew M. Bishop amb at gedanken.demon.co.uk http://www.gedanken.demon.co.uk/ WWWOFFLE users page: http://www.gedanken.demon.co.uk/wwwoffle/version-2.9/user.html From INVALID.NOREPLY at gnu.org Mon Aug 29 20:53:59 2011 From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen) Date: Mon, 29 Aug 2011 18:53:59 +0000 Subject: [sr #107785] gnutls_sign_func called with hash size of 20 bytes In-Reply-To: <20110829-142440.sv0.60552@savannah.gnu.org> References: <20110829-133316.sv79827.56778@savannah.gnu.org> <20110829-134109.sv79827.17998@savannah.gnu.org> <20110829-142440.sv0.60552@savannah.gnu.org> Message-ID: <20110829-185359.sv79827.62866@savannah.gnu.org> Follow-up Comment #3, sr #107785 (project gnutls): I can see from http://www.ietf.org/rfc/rfc5246.txt that it have changed, now I have two questions: 1) how do I determin which hash are being used? from the hash size? or is there a call to give me the hash algorithm. 2) you say that the gnutls_sign_callback_set is depreciated, but how do I use the PKCS 11 interface, I am right now using gnutls on windows and the reason I use the gnutls_sign_callback_set is to be able to also use certificates from the Microsoft Certificate Store. I can not see how the PKCS 11 interface would help me there. Do you have any samples show how that would work? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ml at smtp.fakessh.eu Mon Aug 29 22:01:26 2011 From: ml at smtp.fakessh.eu (ml at smtp.fakessh.eu) Date: Mon, 29 Aug 2011 22:01:26 +0200 Subject: problem to build an rpm Message-ID: hello folks I have problems to build an rpm to the last release of gnutls But I use a. spec everything is more common the error is Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 V?rification des fichiers non empaquet?s: /usr/lib/rpm/check-files /var/tmp/gnutls-2.12.9-1.el5-root-root erreur: Fichier(s) install?(s) (mais non empaquet?s): /usr/share/info/pkcs11-vision.png.gz Erreur de construction de RPM: Fichier(s) install?(s) (mais non empaquet?s): /usr/share/info/pkcs11-vision.png.gz the fichier pkcs11-vision.png and although present in the tarball but not built well all testimonials are welcome -- ?http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7 ?gpg --keyserver pgp.mit.edu --recv-key 092164A7 From ml at smtp.fakessh.eu Mon Aug 29 22:09:10 2011 From: ml at smtp.fakessh.eu (ml at smtp.fakessh.eu) Date: Mon, 29 Aug 2011 22:09:10 +0200 Subject: problem to build an rpm In-Reply-To: References: Message-ID: On 29.08.2011 22:01, ml at smtp.fakessh.eu wrote: > hello folks > > > I have problems to build an rpm to the last release of gnutls > But I use a. spec everything is more common > > the error is > Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > V?rification des fichiers non empaquet?s: /usr/lib/rpm/check-files > /var/tmp/gnutls-2.12.9-1.el5-root-root > erreur: Fichier(s) install?(s) (mais non empaquet?s): > /usr/share/info/pkcs11-vision.png.gz > > > Erreur de construction de RPM: > Fichier(s) install?(s) (mais non empaquet?s): > /usr/share/info/pkcs11-vision.png.gz > > > the fichier pkcs11-vision.png and although present in the tarball but > not built well > > > all testimonials are welcome forgiveness for the wrong message encodes -- ?http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7 ?gpg --keyserver pgp.mit.edu --recv-key 092164A7 From INVALID.NOREPLY at gnu.org Mon Aug 29 22:26:26 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 29 Aug 2011 20:26:26 +0000 Subject: [sr #107785] gnutls_sign_func called with hash size of 20 bytes In-Reply-To: <20110829-185359.sv79827.62866@savannah.gnu.org> References: <20110829-133316.sv79827.56778@savannah.gnu.org> <20110829-134109.sv79827.17998@savannah.gnu.org> <20110829-142440.sv0.60552@savannah.gnu.org> <20110829-185359.sv79827.62866@savannah.gnu.org> Message-ID: <20110829-232625.sv707.44182@savannah.gnu.org> Update of sr #107785 (project gnutls): Status: None => Confirmed _______________________________________________________ Follow-up Comment #4: 1. Unfortunately the sign callback doesn't pass the hash algorithm and seems to be relied on, only if you fix your protocol to be SSL 3.0 or TLS 1.0 (maybe TLS 1.1 too, but I don't remember). 2. You would need a PKCS #11 front-end to the microsoft certificate store. I don't know if such thing exists. PKCS #11 is an API to access cryptographic keys without exposing them. I suppose the MCS does the same thing. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Aug 29 22:31:43 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 29 Aug 2011 20:31:43 +0000 Subject: [sr #107785] gnutls_sign_func called with hash size of 20 bytes In-Reply-To: <20110829-232625.sv707.44182@savannah.gnu.org> References: <20110829-133316.sv79827.56778@savannah.gnu.org> <20110829-134109.sv79827.17998@savannah.gnu.org> <20110829-142440.sv0.60552@savannah.gnu.org> <20110829-185359.sv79827.62866@savannah.gnu.org> <20110829-232625.sv707.44182@savannah.gnu.org> Message-ID: <20110829-233143.sv707.76764@savannah.gnu.org> Follow-up Comment #5, sr #107785 (project gnutls): For information on PKCS #11 with GnuTLS check the example of a TLS client using the PKCS #11 API, http://www.gnu.org/software/gnutls/manual/html_node/Client-using-a-PKCS-11-token-with-TLS.html#ex%3apkcs11-client and more elaborate discussion at http://www.gnu.org/software/gnutls/manual/html_node/Hardware-tokens.html#Hardware-tokens I don't know about your requirements, but sticking on TLS 1.0 might be the easier solution to do. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Aug 29 22:32:00 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 29 Aug 2011 20:32:00 +0000 Subject: [sr #107784] fails to find second dns entry of a cert - error: get_subject/issuer_alt_name2: ASN1 parser: Element was not found In-Reply-To: <20110828-090033.sv20807.17824@savannah.gnu.org> References: <20110827-192752.sv20807.20609@savannah.gnu.org> <20110827-215319.sv707.8096@savannah.gnu.org> <20110828-090033.sv20807.17824@savannah.gnu.org> Message-ID: <20110829-233200.sv707.64059@savannah.gnu.org> Update of sr #107784 (project gnutls): Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ml at smtp.fakessh.eu Tue Aug 30 00:18:48 2011 From: ml at smtp.fakessh.eu (ml at smtp.fakessh.eu) Date: Tue, 30 Aug 2011 00:18:48 +0200 Subject: problem to build an rpm In-Reply-To: References: Message-ID: <8ae64a2e589740d0cbe474b179211606@roundcube.fakessh.eu> On 29.08.2011 22:09, ml at smtp.fakessh.eu wrote: > On 29.08.2011 22:01, ml at smtp.fakessh.eu wrote: >> hello folks >> >> >> I have problems to build an rpm to the last release of gnutls >> But I use a. spec everything is more common >> >> the error is >> Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 >> rpmlib(PayloadFilesHavePrefix) <= 4.0-1 >> V?rification des fichiers non empaquet?s: /usr/lib/rpm/check-files >> /var/tmp/gnutls-2.12.9-1.el5-root-root >> erreur: Fichier(s) install?(s) (mais non empaquet?s): >> /usr/share/info/pkcs11-vision.png.gz >> >> >> Erreur de construction de RPM: >> Fichier(s) install?(s) (mais non empaquet?s): >> /usr/share/info/pkcs11-vision.png.gz >> >> >> the fichier pkcs11-vision.png and although present in the tarball >> but >> not built well >> >> >> all testimonials are welcome > > forgiveness for the wrong message encodes errors from the file .spec I realize the build the rpm -- ?http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7 ?gpg --keyserver pgp.mit.edu --recv-key 092164A7 From INVALID.NOREPLY at gnu.org Tue Aug 30 08:52:52 2011 From: INVALID.NOREPLY at gnu.org (Colin Leroy) Date: Tue, 30 Aug 2011 06:52:52 +0000 Subject: [sr #107660] gnutls update to 2.12 branch breaks programs in ARCH and Debian squeeze In-Reply-To: <20110425-220116.sv707.16419@savannah.gnu.org> References: <20110412-122623.sv82434.96453@savannah.gnu.org> <20110412-153438.sv707.56854@savannah.gnu.org> <20110412-125848.sv82434.87468@savannah.gnu.org> <20110412-163853.sv707.39141@savannah.gnu.org> <20110412-134516.sv82434.5097@savannah.gnu.org> <20110412-164715.sv707.89667@savannah.gnu.org> <20110412-164945.sv707.39713@savannah.gnu.org> <20110425-175208.sv73763.11918@savannah.gnu.org> <20110425-220116.sv707.16419@savannah.gnu.org> Message-ID: <20110830-085252.sv13613.55462@savannah.gnu.org> Follow-up Comment #9, sr #107660 (project gnutls): If I understand correctly, using select() will be completely impossible with future versions of GnuTLS ? Is there an equivalent to gnutls_record_check_pending() to know whether writing to the socket would block ? Thanks. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Aug 30 09:18:18 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Tue, 30 Aug 2011 07:18:18 +0000 Subject: [sr #107660] gnutls update to 2.12 branch breaks programs in ARCH and Debian squeeze In-Reply-To: <20110830-085252.sv13613.55462@savannah.gnu.org> References: <20110412-122623.sv82434.96453@savannah.gnu.org> <20110412-153438.sv707.56854@savannah.gnu.org> <20110412-125848.sv82434.87468@savannah.gnu.org> <20110412-163853.sv707.39141@savannah.gnu.org> <20110412-134516.sv82434.5097@savannah.gnu.org> <20110412-164715.sv707.89667@savannah.gnu.org> <20110412-164945.sv707.39713@savannah.gnu.org> <20110425-175208.sv73763.11918@savannah.gnu.org> <20110425-220116.sv707.16419@savannah.gnu.org> <20110830-085252.sv13613.55462@savannah.gnu.org> Message-ID: <20110830-101818.sv707.37555@savannah.gnu.org> Follow-up Comment #10, sr #107660 (project gnutls): Note that select() is used to check for data in the kernel networking buffers. This will not change. What changed (in 3.0.0) is that select() cannot be used any more to check for data in the GnuTLS read buffers. GnuTLS doesn't hold any write buffers, i.e., every data given to gnutls_record_send() are immediately forwarded to underlying transport layer. Thus, you don't need any equivalent to gnutls_record_check_pending() to know whether writing to the socket would block. It solely depends on the transport layer (i.e. send()). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Aug 30 11:18:49 2011 From: INVALID.NOREPLY at gnu.org (Colin Leroy) Date: Tue, 30 Aug 2011 09:18:49 +0000 Subject: [sr #107660] gnutls update to 2.12 branch breaks programs in ARCH and Debian squeeze In-Reply-To: <20110830-101818.sv707.37555@savannah.gnu.org> References: <20110412-122623.sv82434.96453@savannah.gnu.org> <20110412-153438.sv707.56854@savannah.gnu.org> <20110412-125848.sv82434.87468@savannah.gnu.org> <20110412-163853.sv707.39141@savannah.gnu.org> <20110412-134516.sv82434.5097@savannah.gnu.org> <20110412-164715.sv707.89667@savannah.gnu.org> <20110412-164945.sv707.39713@savannah.gnu.org> <20110425-175208.sv73763.11918@savannah.gnu.org> <20110425-220116.sv707.16419@savannah.gnu.org> <20110830-085252.sv13613.55462@savannah.gnu.org> <20110830-101818.sv707.37555@savannah.gnu.org> Message-ID: <20110830-111849.sv13613.84838@savannah.gnu.org> Follow-up Comment #11, sr #107660 (project gnutls): Hi Nikos, Thanks for your answer. So, if I understood everything well I need the following to avoid blocking: when reading from socket, first check if gnutls_record_check_pending() != 0, and if 0, check for select() when writing, just select() Is that it ? Thanks ! _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Aug 30 13:47:19 2011 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Tue, 30 Aug 2011 11:47:19 +0000 Subject: [sr #107660] gnutls update to 2.12 branch breaks programs in ARCH and Debian squeeze In-Reply-To: <20110830-111849.sv13613.84838@savannah.gnu.org> References: <20110412-122623.sv82434.96453@savannah.gnu.org> <20110412-153438.sv707.56854@savannah.gnu.org> <20110412-125848.sv82434.87468@savannah.gnu.org> <20110412-163853.sv707.39141@savannah.gnu.org> <20110412-134516.sv82434.5097@savannah.gnu.org> <20110412-164715.sv707.89667@savannah.gnu.org> <20110412-164945.sv707.39713@savannah.gnu.org> <20110425-175208.sv73763.11918@savannah.gnu.org> <20110425-220116.sv707.16419@savannah.gnu.org> <20110830-085252.sv13613.55462@savannah.gnu.org> <20110830-101818.sv707.37555@savannah.gnu.org> <20110830-111849.sv13613.84838@savannah.gnu.org> Message-ID: <20110830-114719.sv0.59352@savannah.gnu.org> Follow-up Comment #12, sr #107660 (project gnutls): That is correct. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Aug 30 13:59:41 2011 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Tue, 30 Aug 2011 11:59:41 +0000 Subject: [sr #107775] GnuTLS 3.0.0 causes segfault In-Reply-To: <20110822-144143.sv707.3951@savannah.gnu.org> References: <20110815-032626.sv84482.99672@savannah.gnu.org> <20110815-093149.sv707.10582@savannah.gnu.org> <20110815-195401.sv84482.82513@savannah.gnu.org> <20110815-232339.sv707.32450@savannah.gnu.org> <20110816-185337.sv84482.71177@savannah.gnu.org> <20110817-000646.sv707.69169@savannah.gnu.org> <20110817-084652.sv20807.15870@savannah.gnu.org> <20110822-075644.sv0.20175@savannah.gnu.org> <20110822-144143.sv707.3951@savannah.gnu.org> Message-ID: <20110830-115940.sv0.36111@savannah.gnu.org> Follow-up Comment #9, sr #107775 (project gnutls): I figured out where those wrong values come from (well, kinda). In _gnutls_send_int, cipher_size is a size_t. It is assigned the result from _gnutls_encrypt() in line 437. However, this function returns an int where negative values are used for errors. Line 440 then indeed checks if (cipher_size <= 0), however, since size_t is unsigned, this would only be true if cipher_size == 0. This code then goes on and tries to send garbage. Patch for this hopefully is attached, however I'm not sure if the size_t type is required for other places in this code. Someone with a clue should check carefully and perhaps split cipher_size up into two different variables. It might also make sense to use int instead of ssize_t. Dunno. Now, I only have to figure out why I get GNUTLS_E_COMPRESSION_FAILED (-27) immediately after the handshake... (file #23906) _______________________________________________________ Additional Item Attachment: File name: patch Size:0 KB _______________________________________________________ Reply to this item at: _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Aug 30 15:51:45 2011 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Tue, 30 Aug 2011 13:51:45 +0000 Subject: [sr #107775] GnuTLS 3.0.0 causes segfault In-Reply-To: <20110830-115940.sv0.36111@savannah.gnu.org> References: <20110815-032626.sv84482.99672@savannah.gnu.org> <20110815-093149.sv707.10582@savannah.gnu.org> <20110815-195401.sv84482.82513@savannah.gnu.org> <20110815-232339.sv707.32450@savannah.gnu.org> <20110816-185337.sv84482.71177@savannah.gnu.org> <20110817-000646.sv707.69169@savannah.gnu.org> <20110817-084652.sv20807.15870@savannah.gnu.org> <20110822-075644.sv0.20175@savannah.gnu.org> <20110822-144143.sv707.3951@savannah.gnu.org> <20110830-115940.sv0.36111@savannah.gnu.org> Message-ID: <20110830-165145.sv707.88428@savannah.gnu.org> Update of sr #107775 (project gnutls): Status: Need Info => In Progress _______________________________________________________ Follow-up Comment #10: Thank you for finding it out. I've committed a fix in master. The compression failed is pretty awkward. Does zlib return an error? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/