From simon at josefsson.org Fri Mar 2 14:40:20 2012 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 02 Mar 2012 14:40:20 +0100 Subject: valgrind In-Reply-To: (Nikos Mavrogiannopoulos's message of "Wed, 29 Feb 2012 10:05:16 +0100") References: <1330296815.2054.7.camel@vortex> <87hayaxcdg.fsf_-_@latte.josefsson.org> Message-ID: <87obsfp1dn.fsf@latte.josefsson.org> Nikos Mavrogiannopoulos writes: > On Wed, Feb 29, 2012 at 9:38 AM, Simon Josefsson wrote: > >>> Hello, >>> ?It seems that in your system a pkcs11 module is causing a memory leak >>> which prevents the test from succeeding. A work-around would be to >>> run the test by temporarily disabling all pkcs11 modules loaded by p11-kit >>> by removing /etc/pkcs11/modules. In the next release I'll remove the >>> memory leak check completely to avoid such issues. >> It seems clear that running valgrind on all self checks is causing a lot >> of problems, but there are some checks we know should never have memory >> leaks and running valgrind on them would be good. >> One solution is to put these checks in a separate directory, and to only >> enable valgrind in that directory. > > We currently use that (see directory slow), but still we have occasional > unexpected failures in the rest. The current solution is to run valgrind > in the development environment and do not run it on the system to > be installed. > >> Another solution is to use a wrapper script instead of invoking valgrind >> directly, and the wrapper script can have a whitelist of executables to >> run under valgrind, and the rest will run without valgrind. > > The problem is that we have occasional failures that are system dependent > and cannot be predicted, thus such a solution wouldn't add much. I think > the enabling of valgrind in the development environment is the cleanest > solution. Yes, I agree. I thought there were some self checks that had memory leaks that we haven't fixed though, so there would still be two classes: 1) one set of checks with no memory leaks, where we run 'valgrind --error-exitcode=1 --leak-check=full' on, and 2) one set of checks with some known memory leak (potentially due to external libraries) where we want to run valgrind with '--error=exitcode --leak-check=no' on. There are some self-checks that leads to valgrind complaints now, for example 'mini-loss-time' which produces the output below. Why doesn't valgrind exit with error code 1 for it? Maybe it isn't possible to get valgrind to exit with 1 on just memory leaks. The current situation is quite OK, but it is easy for the valgrind output to scroll by and we'd miss it. It would be perfect if 'make check' halted if there is a memory leak in a program, but that may require a two-class approach initially to deal with checks that nobody has fixed all the memory leaks for. /Simon ==31600== 24 bytes in 1 blocks are still reachable in loss record 1 of 17 ==31600== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==31600== by 0x4E5C955: gnutls_credentials_set (gnutls_auth.c:105) ==31600== by 0x4017B7: doit (mini-loss-time.c:150) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 40 bytes in 1 blocks are still reachable in loss record 2 of 17 ==31600== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==31600== by 0x4E67B4A: gnutls_system_mutex_init (system.c:201) ==31600== by 0x4EE53C0: wrap_nettle_rnd_init (rnd.c:414) ==31600== by 0x4E6E61B: _gnutls_rnd_init (random.c:37) ==31600== by 0x4E61E27: gnutls_global_init (gnutls_global.c:251) ==31600== by 0x40175A: doit (mini-loss-time.c:130) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 40 bytes in 1 blocks are still reachable in loss record 3 of 17 ==31600== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==31600== by 0x4E67B4A: gnutls_system_mutex_init (system.c:201) ==31600== by 0x4E61EBF: gnutls_global_init (gnutls_global.c:266) ==31600== by 0x40175A: doit (mini-loss-time.c:130) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 62 bytes in 3 blocks are still reachable in loss record 4 of 17 ==31600== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==31600== by 0x511D4D2: _asn1_set_value (parser_aux.c:222) ==31600== by 0x511F577: asn1_array2tree (structure.c:199) ==31600== by 0x4E61E1C: gnutls_global_init (gnutls_global.c:242) ==31600== by 0x40175A: doit (mini-loss-time.c:130) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 184 bytes in 1 blocks are still reachable in loss record 5 of 17 ==31600== at 0x4C2380C: calloc (vg_replace_malloc.c:467) ==31600== by 0x4EBA4B2: _gnutls_sr_send_params (safe_renegotiation.c:390) ==31600== by 0x4E5C3F5: _gnutls_gen_extensions (gnutls_extensions.c:266) ==31600== by 0x4E53682: _gnutls_send_hello (gnutls_handshake.c:1916) ==31600== by 0x4E5406C: _gnutls_handshake_client (gnutls_handshake.c:2455) ==31600== by 0x4E546FF: gnutls_handshake (gnutls_handshake.c:2368) ==31600== by 0x4017F7: doit (mini-loss-time.c:162) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 312 bytes in 1 blocks are still reachable in loss record 6 of 17 ==31600== at 0x4C2380C: calloc (vg_replace_malloc.c:467) ==31600== by 0x4E6A40F: gnutls_init (gnutls_state.c:335) ==31600== by 0x40177E: doit (mini-loss-time.c:142) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 504 bytes in 1 blocks are still reachable in loss record 7 of 17 ==31600== at 0x4C245E2: realloc (vg_replace_malloc.c:525) ==31600== by 0x4E5C1ED: _gnutls_ext_register (gnutls_extensions.c:364) ==31600== by 0x4E61E36: gnutls_global_init (gnutls_global.c:259) ==31600== by 0x40175A: doit (mini-loss-time.c:130) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 587 bytes in 60 blocks are still reachable in loss record 8 of 17 ==31600== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==31600== by 0x607FA21: strdup (strdup.c:43) ==31600== by 0x511D42F: _asn1_set_name (parser_aux.c:364) ==31600== by 0x511F551: asn1_array2tree (structure.c:197) ==31600== by 0x4E61E1C: gnutls_global_init (gnutls_global.c:242) ==31600== by 0x40175A: doit (mini-loss-time.c:130) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 1,000 bytes in 1 blocks are still reachable in loss record 9 of 17 ==31600== at 0x4C2380C: calloc (vg_replace_malloc.c:467) ==31600== by 0x4E63673: _gnutls_epoch_alloc (gnutls_constate.c:741) ==31600== by 0x4E6A322: gnutls_init (gnutls_state.c:308) ==31600== by 0x40177E: doit (mini-loss-time.c:142) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 1,000 bytes in 1 blocks are still reachable in loss record 10 of 17 ==31600== at 0x4C2380C: calloc (vg_replace_malloc.c:467) ==31600== by 0x4E63673: _gnutls_epoch_alloc (gnutls_constate.c:741) ==31600== by 0x4E547FD: gnutls_handshake (gnutls_handshake.c:2358) ==31600== by 0x4017F7: doit (mini-loss-time.c:162) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 1,603 bytes in 73 blocks are still reachable in loss record 11 of 17 ==31600== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==31600== by 0x511D4D2: _asn1_set_value (parser_aux.c:222) ==31600== by 0x511F577: asn1_array2tree (structure.c:199) ==31600== by 0x4E61DF2: gnutls_global_init (gnutls_global.c:235) ==31600== by 0x40175A: doit (mini-loss-time.c:130) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 2,048 bytes in 1 blocks are still reachable in loss record 12 of 17 ==31600== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==31600== by 0x4C24562: realloc (vg_replace_malloc.c:525) ==31600== by 0x4E6893A: _gnutls_buffer_append_data (gnutls_str.c:152) ==31600== by 0x4E50522: _gnutls_send_handshake (gnutls_handshake.c:1234) ==31600== by 0x4E536C2: _gnutls_send_hello (gnutls_handshake.c:1936) ==31600== by 0x4E5406C: _gnutls_handshake_client (gnutls_handshake.c:2455) ==31600== by 0x4E546FF: gnutls_handshake (gnutls_handshake.c:2368) ==31600== by 0x4017F7: doit (mini-loss-time.c:162) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 4,312 bytes in 1 blocks are still reachable in loss record 13 of 17 ==31600== at 0x4C2380C: calloc (vg_replace_malloc.c:467) ==31600== by 0x4E6A307: gnutls_init (gnutls_state.c:304) ==31600== by 0x40177E: doit (mini-loss-time.c:142) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 4,608 bytes in 64 blocks are still reachable in loss record 14 of 17 ==31600== at 0x4C2380C: calloc (vg_replace_malloc.c:467) ==31600== by 0x511E0EE: _asn1_add_node (parser_aux.c:61) ==31600== by 0x511F53D: asn1_array2tree (structure.c:195) ==31600== by 0x4E61E1C: gnutls_global_init (gnutls_global.c:242) ==31600== by 0x40175A: doit (mini-loss-time.c:130) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 5,223 bytes in 403 blocks are still reachable in loss record 15 of 17 ==31600== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==31600== by 0x607FA21: strdup (strdup.c:43) ==31600== by 0x511D42F: _asn1_set_name (parser_aux.c:364) ==31600== by 0x511F551: asn1_array2tree (structure.c:197) ==31600== by 0x4E61DF2: gnutls_global_init (gnutls_global.c:235) ==31600== by 0x40175A: doit (mini-loss-time.c:130) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 16,464 bytes in 1 blocks are definitely lost in loss record 16 of 17 ==31600== at 0x4C2380C: calloc (vg_replace_malloc.c:467) ==31600== by 0x4E4CD9A: _mbuffer_alloc (gnutls_mbuffers.c:287) ==31600== by 0x4E4EC61: _gnutls_io_read_buffered (gnutls_buffers.c:171) ==31600== by 0x4E49205: _gnutls_recv_in_buffers (gnutls_record.c:866) ==31600== by 0x4E4E482: _gnutls_handshake_io_recv_int (gnutls_buffers.c:1173) ==31600== by 0x4E51D0C: _gnutls_recv_handshake (gnutls_handshake.c:1260) ==31600== by 0x4E558DE: _gnutls_recv_server_kx_message (gnutls_kx.c:470) ==31600== by 0x4E543CF: _gnutls_handshake_client (gnutls_handshake.c:2502) ==31600== by 0x4E546FF: gnutls_handshake (gnutls_handshake.c:2368) ==31600== by 0x4017F7: doit (mini-loss-time.c:162) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31600== 36,576 bytes in 508 blocks are still reachable in loss record 17 of 17 ==31600== at 0x4C2380C: calloc (vg_replace_malloc.c:467) ==31600== by 0x511E0EE: _asn1_add_node (parser_aux.c:61) ==31600== by 0x511F53D: asn1_array2tree (structure.c:195) ==31600== by 0x4E61DF2: gnutls_global_init (gnutls_global.c:235) ==31600== by 0x40175A: doit (mini-loss-time.c:130) ==31600== by 0x4019AC: main (utils.c:155) ==31600== ==31597== 16 bytes in 1 blocks are still reachable in loss record 1 of 1 ==31597== at 0x4C2380C: calloc (vg_replace_malloc.c:467) ==31597== by 0x4E63A96: gnutls_anon_allocate_server_credentials (gnutls_anon_cred.c:62) ==31597== by 0x401637: doit (mini-loss-time.c:222) ==31597== by 0x4019AC: main (utils.c:155) ==31597== PASS: mini-loss-time From latze at angry-red-pla.net Fri Mar 2 16:31:30 2012 From: latze at angry-red-pla.net (Carolin Latze) Date: Fri, 02 Mar 2012 16:31:30 +0100 Subject: patch to documentation on how to add a custom supplemental data message In-Reply-To: <4F48A12A.5010207@gnutls.org> References: <4F47C362.5090603@angry-red-pla.net> <4F48A12A.5010207@gnutls.org> Message-ID: <4F50E7D2.9030405@angry-red-pla.net> Hi Nikos, next try. Is this what you suggested? Carolin On 02/25/2012 09:51 AM, Nikos Mavrogiannopoulos wrote: > On 02/24/2012 06:05 PM, Carolin Latze wrote: > > >> Hi all, >> finally - after 3 years (... :( ) - I wrote this section about how >> to add a custom supplemental data handshake message to GnuTLS. I >> checked the webpage but did not see how add the patch directly, which >> is why I attached it to this mail. Please let me know if this is not >> the correct way to do this >> > > Thank you Carolin. I'd suggest to submit the patch using > git-format-patch, so that your name is included in the commit. (A way to > do it is to commit locally and then use git-format-patch to generate the > patch). > > regards, > Nikos > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-supp-data-doc-added.patch Type: text/x-patch Size: 3287 bytes Desc: not available URL: From nmav at gnutls.org Fri Mar 2 19:22:00 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 02 Mar 2012 19:22:00 +0100 Subject: gnutls 2.12.16 Message-ID: <4F510FC8.6030505@gnutls.org> Hello, I've just released gnutls 2.12.17. It includes several bug fixes. Version 2.12.17 (released 2012-03-02) ** libgnutls: Corrections in record packet parsing. Reported by Matthew Hall. ** libgnutls: Fixes in SRP authentication. ** libgnutls: Added function to force explicit reinitialization of PKCS #11 modules. This is required on the child process after a fork. ** libgnutls: PKCS #11 objects that do not have ID no longer crash listing. Reported by Sven Geggus. ** API and ABI modifications: gnutls_pkcs11_reinit: Added 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.17.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.17.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.17.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.17.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 Fri Mar 2 19:22:25 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 02 Mar 2012 19:22:25 +0100 Subject: patch to documentation on how to add a custom supplemental data message In-Reply-To: <4F50E7D2.9030405@angry-red-pla.net> References: <4F47C362.5090603@angry-red-pla.net> <4F48A12A.5010207@gnutls.org> <4F50E7D2.9030405@angry-red-pla.net> Message-ID: <4F510FE1.9000301@gnutls.org> On 03/02/2012 04:31 PM, Carolin Latze wrote: > Hi Nikos, > > next try. Is this what you suggested? Perfect! Applied. regards, Nikos From nmav at gnutls.org Fri Mar 2 19:42:05 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 02 Mar 2012 19:42:05 +0100 Subject: gnutls 3.0.15 Message-ID: <4F51147D.4090907@gnutls.org> Hello, I've just released gnutls 3.0.15. This is a bug-fix release on the current stable branch. * Version 3.0.15 (released 2012-03-02) ** test suite: Only run under valgrind in the development system (the full git repository) ** command line apps: Link with local libopts if the installed is an old one. ** libgnutls: Eliminate double free during SRP authentication. Reported by Peter Penzov. ** libgnutls: Corrections in record packet parsing. Reported by Matthew Hall. ** libgnutls: Cryptodev updates and fixes. ** libgnutls: Corrected issue with select() that affected FreeBSD. This prevented establishing DTLS sessions. Reported by Andreas Metzler. ** libgnutls: Corrected rehandshake and resumption operations in DTLS. Reported by Sean Buckheister. ** libgnutls: PKCS #11 objects that do not have ID no longer crash listing. Reported by Sven Geggus. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.15.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.15.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.15.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.15.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.15.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.15.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 mabrand at mabrand.nl Fri Mar 2 21:44:58 2012 From: mabrand at mabrand.nl (Mark Brand) Date: Fri, 02 Mar 2012 21:44:58 +0100 Subject: [PATCH] no fchmod() for MinGW32 Message-ID: <4F51314A.6000006@mabrand.nl> Hi, Ran into a little problem building gnutls 3.0.15 using mingw32. This patch works around the problem, but perhaps there's a better way. regards, Mark diff --git a/src/libopts/makeshell.c b/src/libopts/makeshell.c index 1730c81..45d170b 100644 --- a/src/libopts/makeshell.c +++ b/src/libopts/makeshell.c @@ -164,7 +164,9 @@ optionParseShell(tOptions * pOpts) printf(SHOW_PROG_ENV, pOpts->pzPROGNAME); fflush(stdout); +#ifndef __MINGW32__ fchmod(STDOUT_FILENO, 0755); +#endif fclose(stdout); if (ferror(stdout)) { fputs(zOutputFail, stderr); From nmav at gnutls.org Fri Mar 2 22:29:11 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 02 Mar 2012 22:29:11 +0100 Subject: [PATCH] no fchmod() for MinGW32 In-Reply-To: <4F51314A.6000006@mabrand.nl> References: <4F51314A.6000006@mabrand.nl> Message-ID: <4F513BA7.9040408@gnutls.org> On 03/02/2012 09:44 PM, Mark Brand wrote: > Hi, > > Ran into a little problem building gnutls 3.0.15 using mingw32. This > patch works around the problem, but perhaps there's a better way. Thank you. I also noticed few seconds after the release. I remember I had applied a similar patch but must have been lost in the upgrades of autogen. regards, Nikos From INVALID.NOREPLY at gnu.org Sat Mar 3 05:36:22 2012 From: INVALID.NOREPLY at gnu.org (Funda Wang) Date: Sat, 03 Mar 2012 04:36:22 +0000 Subject: [sr #107977] Test failed with building gnutls 3.0.15 Message-ID: <20120303-043621.sv68311.31172@savannah.gnu.org> URL: Summary: Test failed with building gnutls 3.0.15 Project: GnuTLS Submitted by: fundawang Submitted on: Sat 03 Mar 2012 04:36:21 AM GMT Category: Core library Priority: 5 - Normal Severity: 4 - Important Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: When building gnutls 3.0.15 on Mageia Linux Cauldron, make check failed: PASS: pgps2kgnu bind: Address already in use server: bind failed Self test `./x509self' finished with 1 errors FAIL: x509self bind: Address already in use server: bind failed Self test `./x509dn' finished with 1 errors FAIL: x509dn bind: Address already in use server: bind failed Self test `./anonself' finished with 1 errors FAIL: anonself bind: Address already in use server: bind failed Self test `./pskself' finished with 1 errors FAIL: pskself bind: Address already in use server: bind failed Self test `./dhepskself' finished with 1 errors FAIL: dhepskself bind: Address already in use server: bind failed try to resume from db Self test `./resume' finished with 1 errors FAIL: resume PASS: setcredcrash bind: Address already in use server: bind failed Self test `./openpgpself' finished with 1 errors FAIL: openpgpself PASS: rfc2253-escape-test =================================== 7 of 56 tests failed Please report to bug-gnutls at gnu.org The environment would be gcc 4.6.2, glibc 2.14.1. What could be the reason? Thanks. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From branko at majic.rs Sat Mar 3 10:01:27 2012 From: branko at majic.rs (=?UTF-8?B?0JHRgNCw0L3QutC+INCc0LDRmNC40Zs=?=) Date: Sat, 3 Mar 2012 10:01:27 +0100 Subject: [sr #107977] Test failed with building gnutls 3.0.15 In-Reply-To: <20120303-043621.sv68311.31172@savannah.gnu.org> References: <20120303-043621.sv68311.31172@savannah.gnu.org> Message-ID: <20120303100127.737682c7@majic.rs> From what I can tell, the tests are trying to bind to some IP address on a particular port, and that port is already taken (therefore the "bind: Address already in use" error message). You should check what ports are being used by the tests, and make sure they're not occupied by system services etc. At least that's a starting point I'd take :) ???? Sat, 03 Mar 2012 04:36:22 +0000 Funda Wang ??????: > URL: > > > Summary: Test failed with building gnutls 3.0.15 > Project: GnuTLS > Submitted by: fundawang > Submitted on: Sat 03 Mar 2012 04:36:21 AM GMT > Category: Core library > Priority: 5 - Normal > Severity: 4 - Important > Status: None > Privacy: Public > Assigned to: None > Originator Email: > Open/Closed: Open > Discussion Lock: Any > Operating System: GNU/Linux > > _______________________________________________________ > > Details: > > When building gnutls 3.0.15 on Mageia Linux Cauldron, make check > failed: > > > PASS: pgps2kgnu > bind: Address already in use > server: bind failed > Self test `./x509self' finished with 1 errors > FAIL: x509self > bind: Address already in use > server: bind failed > Self test `./x509dn' finished with 1 errors > FAIL: x509dn > bind: Address already in use > server: bind failed > Self test `./anonself' finished with 1 errors > FAIL: anonself > bind: Address already in use > server: bind failed > Self test `./pskself' finished with 1 errors > FAIL: pskself > bind: Address already in use > server: bind failed > Self test `./dhepskself' finished with 1 errors > FAIL: dhepskself > bind: Address already in use > server: bind failed > try to resume from db > Self test `./resume' finished with 1 errors > FAIL: resume > PASS: setcredcrash > bind: Address already in use > server: bind failed > Self test `./openpgpself' finished with 1 errors > FAIL: openpgpself > PASS: rfc2253-escape-test > =================================== > 7 of 56 tests failed > Please report to bug-gnutls at gnu.org > > The environment would be gcc 4.6.2, glibc 2.14.1. What could be the > reason? Thanks. > -- Branko Majic Jabber: branko at majic.rs Please use only Free formats when sending attachments to me. ?????? ????? ?????: branko at majic.rs ????? ??? ?? ??????? ?????? ????????? ? ????????? ?????????. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From novel at FreeBSD.org Sun Mar 4 06:48:27 2012 From: novel at FreeBSD.org (Roman Bogorodskiy) Date: Sun, 4 Mar 2012 09:48:27 +0400 Subject: gnutls 2.12.17 In-Reply-To: <4F510FC8.6030505@gnutls.org> References: <4F510FC8.6030505@gnutls.org> Message-ID: <20120304054826.GA1250@kloomba> Nikos Mavrogiannopoulos wrote: > Hello, > I've just released gnutls 2.12.17. It includes several > bug fixes. > > Version 2.12.17 (released 2012-03-02) > > ** libgnutls: Corrections in record packet parsing. > Reported by Matthew Hall. > > ** libgnutls: Fixes in SRP authentication. > > ** libgnutls: Added function to force explicit reinitialization > of PKCS #11 modules. This is required on the child process after > a fork. > > ** libgnutls: PKCS #11 objects that do not have ID > no longer crash listing. Reported by Sven Geggus. > > ** API and ABI modifications: > gnutls_pkcs11_reinit: Added Was it necessary to bump a major shlib version for the added function? Roman Bogorodskiy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From ametzler at downhill.at.eu.org Sun Mar 4 08:17:59 2012 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 4 Mar 2012 08:17:59 +0100 Subject: gnutls 2.12.17 In-Reply-To: <20120304054826.GA1250@kloomba> References: <4F510FC8.6030505@gnutls.org> <20120304054826.GA1250@kloomba> Message-ID: <20120304071759.GA1998@downhill.g.la> On 2012-03-04 Roman Bogorodskiy wrote: > Nikos Mavrogiannopoulos wrote: [...] > > Version 2.12.17 (released 2012-03-02) [...] > > ** API and ABI modifications: > > gnutls_pkcs11_reinit: Added > Was it necessary to bump a major shlib version for the added function? gnutls uses regular libtool library versioning. --- gnutls-2.12.16/lib/m4/hooks.m4 2012-01-06 20:06:23.000000000 +0100 +++ gnutls-2.12.17/lib/m4/hooks.m4 2012-03-01 17:49:34.000000000 +0100 @@ -26,9 +26,9 @@ AC_DEFUN([LIBGNUTLS_HOOKS], # Interfaces changed/added/removed: CURRENT++ REVISION=0 # Interfaces added: AGE++ # Interfaces removed: AGE=0 - AC_SUBST(LT_CURRENT, 47) - AC_SUBST(LT_REVISION, 9) - AC_SUBST(LT_AGE, 21) + AC_SUBST(LT_CURRENT, 48) + AC_SUBST(LT_REVISION, 0) + AC_SUBST(LT_AGE, 22) ----------------------------------------- And at least on linux this does the correct thing, soname is unchanged (ABI compability has been preserved!) which is the important as it is the used by the dynamic linker. The filename changed from libgnutls.so.26.21.9 to libgnutls.so.26.22.0, which has no effect on any packages using libgnutls (unless they dlopen the full filename). Does FreeBSD behave differently? cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From novel at FreeBSD.org Sun Mar 4 08:41:00 2012 From: novel at FreeBSD.org (Roman Bogorodskiy) Date: Sun, 4 Mar 2012 11:41:00 +0400 Subject: gnutls 2.12.17 In-Reply-To: <20120304071759.GA1998@downhill.g.la> References: <4F510FC8.6030505@gnutls.org> <20120304054826.GA1250@kloomba> <20120304071759.GA1998@downhill.g.la> Message-ID: <20120304074059.GB1250@kloomba> Andreas Metzler wrote: > On 2012-03-04 Roman Bogorodskiy wrote: > > Nikos Mavrogiannopoulos wrote: > [...] > > > Version 2.12.17 (released 2012-03-02) > [...] > > > ** API and ABI modifications: > > > gnutls_pkcs11_reinit: Added > > > Was it necessary to bump a major shlib version for the added function? > > gnutls uses regular libtool library versioning. > > --- gnutls-2.12.16/lib/m4/hooks.m4 2012-01-06 20:06:23.000000000 +0100 > +++ gnutls-2.12.17/lib/m4/hooks.m4 2012-03-01 17:49:34.000000000 +0100 > @@ -26,9 +26,9 @@ AC_DEFUN([LIBGNUTLS_HOOKS], > # Interfaces changed/added/removed: CURRENT++ REVISION=0 > # Interfaces added: AGE++ > # Interfaces removed: AGE=0 > - AC_SUBST(LT_CURRENT, 47) > - AC_SUBST(LT_REVISION, 9) > - AC_SUBST(LT_AGE, 21) > + AC_SUBST(LT_CURRENT, 48) > + AC_SUBST(LT_REVISION, 0) > + AC_SUBST(LT_AGE, 22) > ----------------------------------------- > > And at least on linux this does the correct thing, soname is unchanged > (ABI compability has been preserved!) which is the important as it is > the used by the dynamic linker. The filename changed from > libgnutls.so.26.21.9 to libgnutls.so.26.22.0, which has no effect on > any packages using libgnutls (unless they dlopen the full filename). > > Does FreeBSD behave differently? > cu andreas Yes, FreeBSD has: lib/libgnutls.so lib/libgnutls.so.47 After the update, it will become lib/libgnutls.so lib/libgnutls.so.48 so all the applications that link to libgnutls has to be recompiled, which is unnecessary as far as I understand. However, libtool documentation indeed tells to bump current version: http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html which is quite confusing... Roman Bogorodskiy -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From nmav at gnutls.org Sun Mar 4 10:53:34 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 04 Mar 2012 10:53:34 +0100 Subject: gnutls 2.12.17 In-Reply-To: <20120304074059.GB1250@kloomba> References: <4F510FC8.6030505@gnutls.org> <20120304054826.GA1250@kloomba> <20120304071759.GA1998@downhill.g.la> <20120304074059.GB1250@kloomba> Message-ID: <4F533B9E.5010206@gnutls.org> On 03/04/2012 08:41 AM, Roman Bogorodskiy wrote: >> And at least on linux this does the correct thing, soname is unchanged >> (ABI compability has been preserved!) which is the important as it is >> the used by the dynamic linker. The filename changed from >> libgnutls.so.26.21.9 to libgnutls.so.26.22.0, which has no effect on >> any packages using libgnutls (unless they dlopen the full filename). >> >> Does FreeBSD behave differently? >> cu andreas > > Yes, FreeBSD has: > lib/libgnutls.so > lib/libgnutls.so.47 > > After the update, it will become > lib/libgnutls.so > lib/libgnutls.so.48 > > so all the applications that link to libgnutls has to be recompiled, > which is unnecessary as far as I understand. Indeed it is unnecessary in this case. > However, libtool documentation indeed tells to bump current version: > http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html Could it be a libtool issue in FreeBSD? regards, Nikos From mrsam at courier-mta.com Thu Mar 8 14:21:54 2012 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Thu, 08 Mar 2012 08:21:54 -0500 Subject: Memory leak in 2.xx Message-ID: In 2.12.14 _rsa_generate_params() has a stray "tmp = _gnutls_mpi_alloc_like (resarr[0]);". The malloc-ed memory never gets freed. Looks like this code is gone in 3.x, so only 2.x is impacted. This is called from gnutls_x509_privkey_generate(). A long-running application that keeps creating private keys, for temporary use, and destroying them after use, will end up leaking memory. This is also in the code path for temporary RSA parameter generation when using export-grade RSA keys. This will also leak memory. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From tmraz at redhat.com Thu Mar 8 18:16:07 2012 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 08 Mar 2012 18:16:07 +0100 Subject: Memory leaks in key generation Message-ID: <1331226967.10395.59.camel@vespa.frost.loc> The attached patch fixes a few possible memory leaks in gnutls_x509_privkey_generate() First one happens always when RSA key is generated using the libgcrypt backend. The remaining ones are rather theoretical only when some error paths are taken. The problem was reported to Red Hat Bugzilla by Sam Varshavchik. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-2.12.14-leak.patch Type: text/x-patch Size: 1800 bytes Desc: not available URL: From nmav at gnutls.org Thu Mar 8 23:28:07 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 08 Mar 2012 23:28:07 +0100 Subject: Memory leaks in key generation In-Reply-To: <1331226967.10395.59.camel@vespa.frost.loc> References: <1331226967.10395.59.camel@vespa.frost.loc> Message-ID: <4F593277.6030800@gnutls.org> On 03/08/2012 06:16 PM, Tomas Mraz wrote: > The attached patch fixes a few possible memory leaks in > gnutls_x509_privkey_generate() > > First one happens always when RSA key is generated using the libgcrypt > backend. > The remaining ones are rather theoretical only when some error paths are > taken. Thank you for the patch, applied (with few changes). regards, Nikos From nmav at gnutls.org Thu Mar 8 23:29:17 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 08 Mar 2012 23:29:17 +0100 Subject: Memory leak in 2.xx In-Reply-To: References: Message-ID: <4F5932BD.2090708@gnutls.org> On 03/08/2012 02:21 PM, Sam Varshavchik wrote: > In 2.12.14 _rsa_generate_params() has a stray "tmp = > _gnutls_mpi_alloc_like (resarr[0]);". The malloc-ed memory never gets > freed. > > Looks like this code is gone in 3.x, so only 2.x is impacted. > This is called from gnutls_x509_privkey_generate(). A long-running > application that keeps creating private keys, for temporary use, and > destroying them after use, will end up leaking memory. This is also in > the code path for temporary RSA parameter generation when using > export-grade RSA keys. This will also leak memory. Thank you for reporting it. I've applied the patch by Tomas[0]. Does it fix the issue you see? [0]. http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=ff19ba8b9c5540e46ec876f264ffdbb92cfcf8c9 regards, Nikos From mrsam at courier-mta.com Fri Mar 9 03:23:55 2012 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Thu, 08 Mar 2012 21:23:55 -0500 Subject: Memory leak in 2.xx References: <4F5932BD.2090708@gnutls.org> Message-ID: Nikos Mavrogiannopoulos writes: > On 03/08/2012 02:21 PM, Sam Varshavchik wrote: > > > In 2.12.14 _rsa_generate_params() has a stray "tmp = > > _gnutls_mpi_alloc_like (resarr[0]);". The malloc-ed memory never gets > > freed. > > > > Looks like this code is gone in 3.x, so only 2.x is impacted. > > This is called from gnutls_x509_privkey_generate(). A long-running > > application that keeps creating private keys, for temporary use, and > > destroying them after use, will end up leaking memory. This is also in > > the code path for temporary RSA parameter generation when using > > export-grade RSA keys. This will also leak memory. > > > Thank you for reporting it. I've applied the patch by Tomas[0]. Does > it fix the issue you see? > > [0]. > http://git.savannah.gnu.org/gitweb/? > p=gnutls.git;a=commitdiff;h=ff19ba8b9c5540e46ec876f264ffdbb92cfcf8c9 Indeed, this fix does the trick. From lfinsto at gwdg.de Wed Mar 14 19:21:14 2012 From: lfinsto at gwdg.de (lfinsto at gwdg.de) Date: Wed, 14 Mar 2012 19:21:14 +0100 Subject: Building 3.0.15 (master branch) Message-ID: <11249f10132921a96e3b61f85f4a49c8.squirrel@mailbox.gwdg.de> Hello, I've just updated my PC to SuseLinux 12.1 and thought I would try building and installing GNUTLS from the master branch of the git repository. (For what it's worth, the GNUTLS installed using yast2 is version 3.0.3, so pretty recent.) I succeeded for the most part, but there were a couple of problems and I thought a report might be useful: I have a Dell Precision T3400 uname -a Linux pcfinston 3.1.0-1.2-desktop #1 SMP PREEMPT Thu Nov 3 14:45:45 UTC 2011 (187dde0) x86_64 x86_64 x86_64 GNU/Linux I installed nettle, p11-kit, autoconf, automake, libtool, autogen, etc., using yast2. There were no problems, except for one with autogen (see below). In particular, there were no problems with libhogweed not being created or other problems with dependencies. I didn't have to install any prerequisites by hand. I did actually have a problem with HAVE_LIBNETTLE being undefined, but that was because there was a configure script, config.h.in, config.h, etc., in lib/. Deleting them worked, and I then deleted the whole working copy, cloned the repository again and started again. This error did not occur again and these files don't exist in this directory. I got errors with aclocal && autoconf the first time through, but autoreconf -fvim worked (after touching ChangeLog, as below). I forgot to test this after recloning the repository and just ran autoreconf -fvim immediately. Makefile.am: required file `./ChangeLog' not found autoreconf: automake failed with exit status: 1 touch ChangeLog autoreconf -fvim configure --prefix=/home/lfinsto/gnutls_dev/master_install make File cs.po does not exist. If you are a translator, you can create it through 'msginit'. configure --prefix=/home/lfinsto/gnutls_dev/master_install --disable-nls The first time through, I solved this problem by running `msginit -i *.po.in -o *.po' for the various files, but for a couple it didn't work and I used cs.po.in for the input, e.g., -i cs.po.in -o xx.po (I'm not sure which ones didn't work anymore). I was just guessing that it would work and don't understand this. make certtool-args.c:51:13: error: conflicting types for 'optionAlias' ../src/libopts/autoopts/options.h:1031:12: note: previous declaration of 'optionAlias' was here make[3]: *** [libcmd_certtool_la-certtool-args.lo] Error 1 make[3]: Leaving directory `/home/lfinsto/gnutls_dev/gnutls_master/src' certtool-args.c:51: * DO NOT EDIT THIS FILE (certtool-args.c) * * It has been AutoGen-ed March 14, 2012 at 06:30:08 PM by AutoGen 5.11.8 * From the definitions certtool-args.def * and the template file options libopts/autoopts/options.h * DO NOT EDIT THIS FILE (options.h) * * It has been AutoGen-ed February 26, 2012 at 11:08:44 AM by AutoGen 5.15pre14 * From the definitions funcs.def * and the template file options_h I had a good look around the file system, but I was unable to locate funcs.def or options_h (I didn't look very hard for `options'). The declaration is not in certtool-args.def. I therefore changed extern void optionAlias(tOptions* pOpts, tOptDesc* pOD, unsigned int alias); to extern int optionAlias(tOptions* pOpts, tOptDesc* pOD, unsigned int alias); in certtool-args.c. It worked, but it's obviously not a good solution. make /bin/sh: line 75: /usr/share/autogen/texi2mdoc: Permission denied /bin/sh: line 194: /usr/share/autogen/mdoc2man: Permission denied As root: chmod a+rx /usr/share/autogen/texi2mdoc chmod a+rx /usr/share/autogen/mdoc2man This would seem to be a problem with the autogen installation (I installed it using yast2). make Lots of these warnings: mini-eagain2.c:189:41: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] (it's a 64-bit machine) make install Success! I hope this report is of some use to you. Laurence Finston ------------------------------------------------------------- Laurence Finston Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Am Fassberg 11 37077 Goettingen Telefon: +49 551 201-1882 E-Mail: lfinsto at gwdg.de From INVALID.NOREPLY at gnu.org Thu Mar 15 04:40:48 2012 From: INVALID.NOREPLY at gnu.org (Jack Howarth) Date: Thu, 15 Mar 2012 03:40:48 +0000 Subject: [sr #107983] lib/accelerated/x86/asm files incompatible with i386/x86_64 darwin Message-ID: <20120315-034047.sv75110.75468@savannah.gnu.org> URL: Summary: lib/accelerated/x86/asm files incompatible with i386/x86_64 darwin Project: GnuTLS Submitted by: jhowarth Submitted on: Thu 15 Mar 2012 03:40:46 AM GMT 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: Mac OS _______________________________________________________ Details: The current gnutls 3.0.15 release contains assembly files in lib/accelerated/x86/asm which are incompatible with i386/x86_64 darwin. Minimal changes are required for these to properly compile on darwin... 1) Use the more portable .balign rather than .align (since i386/x86_64 darwin doesn't support .align > 15). 2) Add underscore to global symbols (as well as _aesni_set_encrypt_key and calls to it) using SYM macro. 3) Add TYPEF/TYPEO and SIZE macros to handle .type for @function/@object and .size on darwin as is done in the FSF gcc libitm assembly files. 4) Add and :"#ifdef __linux__" on ".section .note.GNU-stack,"",%progbits" With these change the accelerated assembly code is compiled at i386 and x86_64 on darwin10/11 and the resulting build passes the gnutls test suite. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Thu 15 Mar 2012 03:40:46 AM GMT Name: gnutls_darwin.patch Size: 55kB By: jhowarth darwin lib/accelerated/x86/asm assembly changes _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Mar 15 18:49:01 2012 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 15 Mar 2012 17:49:01 +0000 Subject: [sr #107983] lib/accelerated/x86/asm files incompatible with i386/x86_64 darwin In-Reply-To: <20120315-034047.sv75110.75468@savannah.gnu.org> References: <20120315-034047.sv75110.75468@savannah.gnu.org> Message-ID: <20120315-194901.sv707.64470@savannah.gnu.org> Follow-up Comment #1, sr #107983 (project gnutls): Hi, thank you for reporting the issue and the patch. These assembler files are automatically generated so I avoided any change on them and I generated them for MacOSX. Does the patch below solves the issue for you? (you might need to run autoreconf). http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=080f43e1485e36addcaf4279a39848cf8b66a4df _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From jlloyd at silvertailsystems.com Thu Mar 15 22:41:58 2012 From: jlloyd at silvertailsystems.com (Jim Lloyd) Date: Thu, 15 Mar 2012 14:41:58 -0700 Subject: Why p11-kit-1 instead of p11-kit? Message-ID: Sorry to bug the list with this question, but this seems to be a case where Google does not know all. I'm attempting to build gnutls 2.12.17 on CentOS 6.0 x86-64. I'm doing this specifically for PKCS11 support, which we are adding to an existing product. I have built and installed p11-kit 0.12. But when I configure gnutls I get this error: checking for P11_KIT... configure: error: Package requirements (p11-kit-1 >= 0.11) were not met: No package 'p11-kit-1' found Why p11-kit-1 instead of p11-kit? Does this indicate that I need a forked variant of p11-kit? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Mar 16 08:01:19 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 16 Mar 2012 08:01:19 +0100 Subject: Why p11-kit-1 instead of p11-kit? In-Reply-To: References: Message-ID: <4F62E53F.5050505@gnutls.org> On 03/15/2012 10:41 PM, Jim Lloyd wrote: > Sorry to bug the list with this question, but this seems to be a case where > Google does not know all. > > I'm attempting to build gnutls 2.12.17 on CentOS 6.0 x86-64. I'm doing this > specifically for PKCS11 support, which we are adding to an existing product. > > I have built and installed p11-kit 0.12. But when I configure gnutls I get > this error: > > checking for P11_KIT... configure: error: Package requirements (p11-kit-1 >> = 0.11) were not met: > No package 'p11-kit-1' found > > Why p11-kit-1 instead of p11-kit? Does this indicate that I need a forked > variant of p11-kit? Not really. p11-kit advertises itself as p11-kit-1. You might want to check config.log for the reason of non-detection. regards, Nikos From nmav at gnutls.org Fri Mar 16 18:41:09 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 16 Mar 2012 18:41:09 +0100 Subject: gnutls 2.12.18 Message-ID: <4F637B35.9040402@gnutls.org> Hello, I've just released gnutls 2.12.18. It includes several bug fixes. Version 2.12.18 (released 2012-03-16) ** minitasn1: Upgraded to libtasn1 version 2.12 (pre-release). ** Corrected SRP-RSA ciphersuites when used under TLS 1.2. ** Fixed leaks in key generation. Reported by Sam Varshavchik, patch by Tomas Mraz. ** API and ABI modifications: No changes since last version. 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.18.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.18.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.18.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.18.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 Fri Mar 16 18:46:36 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 16 Mar 2012 18:46:36 +0100 Subject: gnutls 3.0.16 Message-ID: <4F637C7C.2080105@gnutls.org> Hello, I've just released gnutls 3.0.16. This is a bug-fix release on the current stable branch. * Version 3.0.16 (released 2012-03-16) ** minitasn1: Upgraded to libtasn1 version 2.12 (pre-release). ** libgnutls: Corrected SRP-RSA ciphersuites when used under TLS 1.2. ** libgnutls: included assembler files for MacOSX. ** p11tool: Small fixes in handling of the --private command line option. ** certtool: The template option allows for setting the domain component (DC) option of the distinguished name, and the ocsp_uri as well as the ca_issuers_uri options. ** API and ABI modifications: gnutls_x509_crt_set_authority_info_access: Added Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.16.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.16.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.16.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.16.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.16.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.16.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 jlloyd at silvertailsystems.com Fri Mar 16 21:15:01 2012 From: jlloyd at silvertailsystems.com (Jim Lloyd) Date: Fri, 16 Mar 2012 13:15:01 -0700 Subject: Why p11-kit-1 instead of p11-kit? In-Reply-To: <4F62E53F.5050505@gnutls.org> References: <4F62E53F.5050505@gnutls.org> Message-ID: I configure and install p11-kit using the usual incantation: ./configure && make && sudo make install This seems to run without errors. However, 'make check' does report one test failure. I logged that failure: https://bugs.freedesktop.org/show_bug.cgi?id=47374 Anyway, I would expect that the usual incantation should be enough to locate p11-kit when I configure GnuTLS. But it isn't able to find it. I've never needed to use pkg-config before so its still a bit mysterious to me, but I would expect that after installing p11-kit that one of these two commands would output something useful: $ pkg-config --libs p11-kit $ pkg-config --libs p11-kit-1 Both produce an error like this one (for the 2nd command above): Package p11-kit-1 was not found in the pkg-config search path. Perhaps you should add the directory containing `p11-kit-1.pc' to the PKG_CONFIG_PATH environment variable No package 'p11-kit-1' found Is there some reason why I have to do something beyond the usual incantation when installing p11-kit? Thanks, Jim On Fri, Mar 16, 2012 at 12:01 AM, Nikos Mavrogiannopoulos wrote: > On 03/15/2012 10:41 PM, Jim Lloyd wrote: > > > Sorry to bug the list with this question, but this seems to be a case > where > > Google does not know all. > > > > I'm attempting to build gnutls 2.12.17 on CentOS 6.0 x86-64. I'm doing > this > > specifically for PKCS11 support, which we are adding to an existing > product. > > > > I have built and installed p11-kit 0.12. But when I configure gnutls I > get > > this error: > > > > checking for P11_KIT... configure: error: Package requirements (p11-kit-1 > >> = 0.11) were not met: > > No package 'p11-kit-1' found > > > > Why p11-kit-1 instead of p11-kit? Does this indicate that I need a forked > > variant of p11-kit? > > > Not really. p11-kit advertises itself as p11-kit-1. You might want to > check config.log for the reason of non-detection. > > regards, > Nikos > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlloyd at silvertailsystems.com Fri Mar 16 22:30:11 2012 From: jlloyd at silvertailsystems.com (Jim Lloyd) Date: Fri, 16 Mar 2012 14:30:11 -0700 Subject: Why p11-kit-1 instead of p11-kit? In-Reply-To: References: <4F62E53F.5050505@gnutls.org> Message-ID: I added the directory that contains p11-kit-1.pc to PKG_CONFIG_PATH (first time I've ever had to do this) and was able to get ./configure for gnutls-2.12.17 to run without errors. However, make then fails with these errors: make[6]: Entering directory `/home/jim/packages/gnutls-2.12.17/lib/gl' CC c-ctype.lo CC fd-hook.lo CC read-file.lo CC sockets.lo CC asnprintf.lo CC ftell.lo CC ftello.lo ftello.c: In function 'rpl_ftello': ftello.c:45: error: 'fp_' undeclared (first use in this function) ftello.c:45: error: (Each undeclared identifier is reported only once ftello.c:45: error: for each function it appears in.) ftello.c:45: error: '_IOWRT' undeclared (first use in this function) make[6]: *** [ftello.lo] Error 1 This is on CentOS 6.0 using gcc 4.4.4 on x86_64. This system has previously had gnutls 2.8.5 installed via yum. Did anything happen between 2.8.5 and 2.12.17 that I need to account for? Ahh, actually I now notice that since 2.8.5 there is the option to use libnettle instead of libgcrypt. It's quite likely that I should built against libgcrypt. Are there other things like this that I need to be aware of? To recap, I need to add support PKCS11 to an existing application that has to date been built against gnutls 2.8.5. I'd like to figure out the simplest upgrade path with gnutls to obtain PKCS11 support. Thanks, Jim On Fri, Mar 16, 2012 at 1:15 PM, Jim Lloyd wrote: > I configure and install p11-kit using the usual incantation: > > ./configure && make && sudo make install > > This seems to run without errors. However, 'make check' does report one > test failure. I logged that failure: > https://bugs.freedesktop.org/show_bug.cgi?id=47374 > > Anyway, I would expect that the usual incantation should be enough to > locate p11-kit when I configure GnuTLS. But it isn't able to find it. I've > never needed to use pkg-config before so its still a bit mysterious to me, > but I would expect that after installing p11-kit that one of these two > commands would output something useful: > > $ pkg-config --libs p11-kit > $ pkg-config --libs p11-kit-1 > > Both produce an error like this one (for the 2nd command above): > Package p11-kit-1 was not found in the pkg-config search path. > Perhaps you should add the directory containing `p11-kit-1.pc' > to the PKG_CONFIG_PATH environment variable > No package 'p11-kit-1' found > > Is there some reason why I have to do something beyond the usual > incantation when installing p11-kit? > > Thanks, > Jim > > On Fri, Mar 16, 2012 at 12:01 AM, Nikos Mavrogiannopoulos > wrote: > >> On 03/15/2012 10:41 PM, Jim Lloyd wrote: >> >> > Sorry to bug the list with this question, but this seems to be a case >> where >> > Google does not know all. >> > >> > I'm attempting to build gnutls 2.12.17 on CentOS 6.0 x86-64. I'm doing >> this >> > specifically for PKCS11 support, which we are adding to an existing >> product. >> > >> > I have built and installed p11-kit 0.12. But when I configure gnutls I >> get >> > this error: >> > >> > checking for P11_KIT... configure: error: Package requirements >> (p11-kit-1 >> >> = 0.11) were not met: >> > No package 'p11-kit-1' found >> > >> > Why p11-kit-1 instead of p11-kit? Does this indicate that I need a >> forked >> > variant of p11-kit? >> >> >> Not really. p11-kit advertises itself as p11-kit-1. You might want to >> check config.log for the reason of non-detection. >> >> regards, >> Nikos >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlloyd at silvertailsystems.com Fri Mar 16 23:00:14 2012 From: jlloyd at silvertailsystems.com (Jim Lloyd) Date: Fri, 16 Mar 2012 15:00:14 -0700 Subject: Why p11-kit-1 instead of p11-kit? In-Reply-To: References: <4F62E53F.5050505@gnutls.org> Message-ID: Ok, I found the root cause. On this system the shared libraries in /usr/local/lib64 were not being found. This caused some of the checks run by ./configure to fail but configure drew the wrong conclusions about the failure and produced an incorrect configuration. After adding /usr/local/lib64 to LD_LIBRARY_PATH, ./configure is able to produce a correct configuration, and gnutls builds. There is one unusual error now when running make check: Checking DSA-2048 with TLS 1.0 Failure: Succeeded connection to a server with DSA 2048 key and TLS 1.0. Should have failed! FAIL: testdsa I doubt this failure will impact me, but let me know if it is significant. I've cc'ed bug at gnutls@gnu.org. On Fri, Mar 16, 2012 at 2:30 PM, Jim Lloyd wrote: > I added the directory that contains p11-kit-1.pc to PKG_CONFIG_PATH (first > time I've ever had to do this) and was able to get ./configure for > gnutls-2.12.17 to run without errors. However, make then fails with these > errors: > > make[6]: Entering directory `/home/jim/packages/gnutls-2.12.17/lib/gl' > CC c-ctype.lo > CC fd-hook.lo > CC read-file.lo > CC sockets.lo > CC asnprintf.lo > CC ftell.lo > CC ftello.lo > ftello.c: In function 'rpl_ftello': > ftello.c:45: error: 'fp_' undeclared (first use in this function) > ftello.c:45: error: (Each undeclared identifier is reported only once > ftello.c:45: error: for each function it appears in.) > ftello.c:45: error: '_IOWRT' undeclared (first use in this function) > make[6]: *** [ftello.lo] Error 1 > > This is on CentOS 6.0 using gcc 4.4.4 on x86_64. > > This system has previously had gnutls 2.8.5 installed via yum. Did > anything happen between 2.8.5 and 2.12.17 that I need to account for? > > Ahh, actually I now notice that since 2.8.5 there is the option to use > libnettle instead of libgcrypt. It's quite likely that I should built > against libgcrypt. Are there other things like this that I need to be aware > of? > > To recap, I need to add support PKCS11 to an existing application that has > to date been built against gnutls 2.8.5. I'd like to figure out the > simplest upgrade path with gnutls to obtain PKCS11 support. > > Thanks, > Jim > > On Fri, Mar 16, 2012 at 1:15 PM, Jim Lloyd wrote: > >> I configure and install p11-kit using the usual incantation: >> >> ./configure && make && sudo make install >> >> This seems to run without errors. However, 'make check' does report one >> test failure. I logged that failure: >> https://bugs.freedesktop.org/show_bug.cgi?id=47374 >> >> Anyway, I would expect that the usual incantation should be enough to >> locate p11-kit when I configure GnuTLS. But it isn't able to find it. I've >> never needed to use pkg-config before so its still a bit mysterious to me, >> but I would expect that after installing p11-kit that one of these two >> commands would output something useful: >> >> $ pkg-config --libs p11-kit >> $ pkg-config --libs p11-kit-1 >> >> Both produce an error like this one (for the 2nd command above): >> Package p11-kit-1 was not found in the pkg-config search path. >> Perhaps you should add the directory containing `p11-kit-1.pc' >> to the PKG_CONFIG_PATH environment variable >> No package 'p11-kit-1' found >> >> Is there some reason why I have to do something beyond the usual >> incantation when installing p11-kit? >> >> Thanks, >> Jim >> >> On Fri, Mar 16, 2012 at 12:01 AM, Nikos Mavrogiannopoulos < >> nmav at gnutls.org> wrote: >> >>> On 03/15/2012 10:41 PM, Jim Lloyd wrote: >>> >>> > Sorry to bug the list with this question, but this seems to be a case >>> where >>> > Google does not know all. >>> > >>> > I'm attempting to build gnutls 2.12.17 on CentOS 6.0 x86-64. I'm doing >>> this >>> > specifically for PKCS11 support, which we are adding to an existing >>> product. >>> > >>> > I have built and installed p11-kit 0.12. But when I configure gnutls I >>> get >>> > this error: >>> > >>> > checking for P11_KIT... configure: error: Package requirements >>> (p11-kit-1 >>> >> = 0.11) were not met: >>> > No package 'p11-kit-1' found >>> > >>> > Why p11-kit-1 instead of p11-kit? Does this indicate that I need a >>> forked >>> > variant of p11-kit? >>> >>> >>> Not really. p11-kit advertises itself as p11-kit-1. You might want to >>> check config.log for the reason of non-detection. >>> >>> regards, >>> Nikos >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlloyd at silvertailsystems.com Fri Mar 16 23:00:14 2012 From: jlloyd at silvertailsystems.com (Jim Lloyd) Date: Fri, 16 Mar 2012 15:00:14 -0700 Subject: Why p11-kit-1 instead of p11-kit? In-Reply-To: References: <4F62E53F.5050505@gnutls.org> Message-ID: Ok, I found the root cause. On this system the shared libraries in /usr/local/lib64 were not being found. This caused some of the checks run by ./configure to fail but configure drew the wrong conclusions about the failure and produced an incorrect configuration. After adding /usr/local/lib64 to LD_LIBRARY_PATH, ./configure is able to produce a correct configuration, and gnutls builds. There is one unusual error now when running make check: Checking DSA-2048 with TLS 1.0 Failure: Succeeded connection to a server with DSA 2048 key and TLS 1.0. Should have failed! FAIL: testdsa I doubt this failure will impact me, but let me know if it is significant. I've cc'ed bug at gnutls@gnu.org. On Fri, Mar 16, 2012 at 2:30 PM, Jim Lloyd wrote: > I added the directory that contains p11-kit-1.pc to PKG_CONFIG_PATH (first > time I've ever had to do this) and was able to get ./configure for > gnutls-2.12.17 to run without errors. However, make then fails with these > errors: > > make[6]: Entering directory `/home/jim/packages/gnutls-2.12.17/lib/gl' > CC c-ctype.lo > CC fd-hook.lo > CC read-file.lo > CC sockets.lo > CC asnprintf.lo > CC ftell.lo > CC ftello.lo > ftello.c: In function 'rpl_ftello': > ftello.c:45: error: 'fp_' undeclared (first use in this function) > ftello.c:45: error: (Each undeclared identifier is reported only once > ftello.c:45: error: for each function it appears in.) > ftello.c:45: error: '_IOWRT' undeclared (first use in this function) > make[6]: *** [ftello.lo] Error 1 > > This is on CentOS 6.0 using gcc 4.4.4 on x86_64. > > This system has previously had gnutls 2.8.5 installed via yum. Did > anything happen between 2.8.5 and 2.12.17 that I need to account for? > > Ahh, actually I now notice that since 2.8.5 there is the option to use > libnettle instead of libgcrypt. It's quite likely that I should built > against libgcrypt. Are there other things like this that I need to be aware > of? > > To recap, I need to add support PKCS11 to an existing application that has > to date been built against gnutls 2.8.5. I'd like to figure out the > simplest upgrade path with gnutls to obtain PKCS11 support. > > Thanks, > Jim > > On Fri, Mar 16, 2012 at 1:15 PM, Jim Lloyd wrote: > >> I configure and install p11-kit using the usual incantation: >> >> ./configure && make && sudo make install >> >> This seems to run without errors. However, 'make check' does report one >> test failure. I logged that failure: >> https://bugs.freedesktop.org/show_bug.cgi?id=47374 >> >> Anyway, I would expect that the usual incantation should be enough to >> locate p11-kit when I configure GnuTLS. But it isn't able to find it. I've >> never needed to use pkg-config before so its still a bit mysterious to me, >> but I would expect that after installing p11-kit that one of these two >> commands would output something useful: >> >> $ pkg-config --libs p11-kit >> $ pkg-config --libs p11-kit-1 >> >> Both produce an error like this one (for the 2nd command above): >> Package p11-kit-1 was not found in the pkg-config search path. >> Perhaps you should add the directory containing `p11-kit-1.pc' >> to the PKG_CONFIG_PATH environment variable >> No package 'p11-kit-1' found >> >> Is there some reason why I have to do something beyond the usual >> incantation when installing p11-kit? >> >> Thanks, >> Jim >> >> On Fri, Mar 16, 2012 at 12:01 AM, Nikos Mavrogiannopoulos < >> nmav at gnutls.org> wrote: >> >>> On 03/15/2012 10:41 PM, Jim Lloyd wrote: >>> >>> > Sorry to bug the list with this question, but this seems to be a case >>> where >>> > Google does not know all. >>> > >>> > I'm attempting to build gnutls 2.12.17 on CentOS 6.0 x86-64. I'm doing >>> this >>> > specifically for PKCS11 support, which we are adding to an existing >>> product. >>> > >>> > I have built and installed p11-kit 0.12. But when I configure gnutls I >>> get >>> > this error: >>> > >>> > checking for P11_KIT... configure: error: Package requirements >>> (p11-kit-1 >>> >> = 0.11) were not met: >>> > No package 'p11-kit-1' found >>> > >>> > Why p11-kit-1 instead of p11-kit? Does this indicate that I need a >>> forked >>> > variant of p11-kit? >>> >>> >>> Not really. p11-kit advertises itself as p11-kit-1. You might want to >>> check config.log for the reason of non-detection. >>> >>> regards, >>> Nikos >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Mar 16 23:13:33 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 16 Mar 2012 23:13:33 +0100 Subject: Why p11-kit-1 instead of p11-kit? In-Reply-To: References: <4F62E53F.5050505@gnutls.org> Message-ID: <4F63BB0D.9040900@gnutls.org> On 03/16/2012 11:00 PM, Jim Lloyd wrote: > Ok, I found the root cause. On this system the shared libraries in > /usr/local/lib64 were not being found. This caused some of the > checks run by ./configure to fail but configure drew the wrong > conclusions about the failure and produced an incorrect > configuration. After adding /usr/local/lib64 to LD_LIBRARY_PATH, > ./configure is able to produce a correct configuration, and gnutls > builds. Nice. I also tried to build 2.12.18 on centos 6 and I didn't have the issues you mentioned. > There is one unusual error now when running make check: Checking > DSA-2048 with TLS 1.0 Failure: Succeeded connection to a server with > DSA 2048 key and TLS 1.0. Should have failed! FAIL: testdsa This is because the libgcrypt back-end. I should have fixed it but it is low on my priorities because it is not that important (simply ignore it). If you have nettle installed I'd suggest to use that, especially if you care about performance. regards, Nikos From nmav at gnutls.org Fri Mar 16 23:13:33 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 16 Mar 2012 23:13:33 +0100 Subject: Why p11-kit-1 instead of p11-kit? In-Reply-To: References: <4F62E53F.5050505@gnutls.org> Message-ID: <4F63BB0D.9040900@gnutls.org> On 03/16/2012 11:00 PM, Jim Lloyd wrote: > Ok, I found the root cause. On this system the shared libraries in > /usr/local/lib64 were not being found. This caused some of the > checks run by ./configure to fail but configure drew the wrong > conclusions about the failure and produced an incorrect > configuration. After adding /usr/local/lib64 to LD_LIBRARY_PATH, > ./configure is able to produce a correct configuration, and gnutls > builds. Nice. I also tried to build 2.12.18 on centos 6 and I didn't have the issues you mentioned. > There is one unusual error now when running make check: Checking > DSA-2048 with TLS 1.0 Failure: Succeeded connection to a server with > DSA 2048 key and TLS 1.0. Should have failed! FAIL: testdsa This is because the libgcrypt back-end. I should have fixed it but it is low on my priorities because it is not that important (simply ignore it). If you have nettle installed I'd suggest to use that, especially if you care about performance. regards, Nikos From jlloyd at silvertailsystems.com Fri Mar 16 23:21:46 2012 From: jlloyd at silvertailsystems.com (Jim Lloyd) Date: Fri, 16 Mar 2012 15:21:46 -0700 Subject: Why p11-kit-1 instead of p11-kit? In-Reply-To: <4F63BB0D.9040900@gnutls.org> References: <4F62E53F.5050505@gnutls.org> <4F63BB0D.9040900@gnutls.org> Message-ID: On Fri, Mar 16, 2012 at 3:13 PM, Nikos Mavrogiannopoulos wrote: > This is because the libgcrypt back-end. I should have fixed it but it is > low on my priorities because it is not that important (simply ignore > it). If you have nettle installed I'd suggest to use that, especially if > you care about performance. > > This is good to know. But our application also uses libgcrypt directly and I think it is best to change one thing at a time. After we have PKCS11 working we'll investigate making the switch to nettle. Thanks, Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From ktk at enterprise.bidmc.harvard.edu Fri Mar 16 23:25:35 2012 From: ktk at enterprise.bidmc.harvard.edu (Kris Karas) Date: Fri, 16 Mar 2012 18:25:35 -0400 Subject: Gnutls 3.0.16 fails due to autoopts header mismatch Message-ID: <4F63BDDF.9090206@enterprise.bidmc.harvard.edu> Just tried compiling the new gnutls 3.0.16: serv-args.h:62:3: error: #error option template version mismatches autoopts/options.h header serv-args.h:63:3: error: unknown type name 'Choke' serv-args.h:63:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before '.' token Poking around, it seems that the version of GNU autogen used to convert src/serv-args.def into src/serv-args.h has placed #define AO_TEMPLATE_VERSION 147460 into that header, whereas in src/libopts/autoopts/options.h there is #define OPTIONS_STRUCT_VERSION 147459 which is what triggers the version mismatch and error. FWIW, I compiled and installed autogen-5.15 and re-built the src/*.{h,c} from the src/*.def and everything worked OK, a gratuitous install of /usr/lib/libopts.so notwithstanding. Kris Karas -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkorb at gnu.org Fri Mar 16 23:35:27 2012 From: bkorb at gnu.org (Bruce Korb) Date: Fri, 16 Mar 2012 15:35:27 -0700 Subject: Gnutls 3.0.16 fails due to autoopts header mismatch In-Reply-To: <4F63BDDF.9090206@enterprise.bidmc.harvard.edu> References: <4F63BDDF.9090206@enterprise.bidmc.harvard.edu> Message-ID: <4F63C02F.3040300@gnu.org> On 03/16/12 15:25, Kris Karas wrote: > Just tried compiling the new gnutls 3.0.16: > > serv-args.h:62:3: error: #error option template version mismatches autoopts/options.h header > serv-args.h:63:3: error: unknown type name 'Choke' > serv-args.h:63:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before '.' token > > > Poking around, it seems that the version of GNU autogen used to convert src/serv-args.def into src/serv-args.h has placed > > #define AO_TEMPLATE_VERSION 147460 > > into that header, whereas in src/libopts/autoopts/options.h there is > > #define OPTIONS_STRUCT_VERSION 147459 > > which is what triggers the version mismatch and error. gnutls should just always link to the one it is built with and the one it is built with needs to be the same one used to generate the .[ch] files. I've tried to minimize the rough edges.... From bruno at clisp.org Sat Mar 17 01:26:22 2012 From: bruno at clisp.org (Bruno Haible) Date: Sat, 17 Mar 2012 01:26:22 +0100 Subject: failure to build gnutls-3.0.16 Message-ID: <1815728.c1YDrCsP9Y@linuix> Hi, Trying to build gnutls-3.0.16 (from ftp.gnu.org) on MacOS X 10.7, I get this compilation error: Making all in libopts CC libopts_la-libopts.lo CCLD libopts.la libtool: link: warning: `-version-info/-version-number' is ignored for convenience libraries CC libcmd_serv_la-serv-args.lo In file included from serv-args.c:43: serv-args.h:62:3: error: #error option template version mismatches autoopts/options.h header In file included from serv-args.c:43: serv-args.h:63: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Me' serv-args.h:105: warning: data definition has no type or storage class serv-args.h:105: warning: type defaults to 'int' in declaration of 'teOptIndex' serv-args.c:901: error: 'INDEX_OPT_VERSION' undeclared here (not in a function) serv-args.c:915: error: 'INDEX_OPT_HELP' undeclared here (not in a function) serv-args.c:927: error: 'INDEX_OPT_MORE_HELP' undeclared here (not in a function) make[3]: *** [libcmd_serv_la-serv-args.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 And indeed src/serv-args.h contains this code: #define AO_TEMPLATE_VERSION 147460 #if (AO_TEMPLATE_VERSION < OPTIONS_MINIMUM_VERSION) \ || (AO_TEMPLATE_VERSION > OPTIONS_STRUCT_VERSION) # error option template version mismatches autoopts/options.h header Choke Me. #endif whereas src/libopts/autoopts/options.h contains this code: #define OPTIONS_STRUCT_VERSION 147459 #define OPTIONS_VERSION_STRING "36:3:11" #define OPTIONS_MINIMUM_VERSION 102400 #define OPTIONS_MIN_VER_STRING "25:0:0" And yes, 147460 is larger than 147459. Why did I run into this? What's the fix? The previous version, gnutls-3.0.15, works fine. Bruno From quann1 at uci.edu Sat Mar 17 06:18:25 2012 From: quann1 at uci.edu (Quan Nguyen) Date: Fri, 16 Mar 2012 22:18:25 -0700 Subject: Bug in gnutls_pubkey_verify_data() API documentation ? Message-ID: <62f986b009b1fe506eea6c893e1a8580.squirrel@webmail.uci.edu> In the API documentation, it says gnutls_pubkey_verify_data(): "On success, %GNUTLS_E_SUCCESS (0) is returned". However, looking at the source code in gnutls_pubkey.c, we see that this function calls pubkey_verify_data(), which returns 1 on success :"verifies the signature data, and returns GNUTLS_E_PK_SIG_VERIFY_FAILED if not verified, or 1 otherwise." Quan Nguyen From a.radke at arcor.de Sat Mar 17 08:25:54 2012 From: a.radke at arcor.de (Andreas Radke) Date: Sat, 17 Mar 2012 08:25:54 +0100 Subject: failure to build gnutls-3.0.16 In-Reply-To: <1815728.c1YDrCsP9Y@linuix> References: <1815728.c1YDrCsP9Y@linuix> Message-ID: <20120317082554.6a47dc8a@laptop64.home> Am Sat, 17 Mar 2012 01:26:22 +0100 schrieb Bruno Haible : > Why did I run into this? What's the fix? > > The previous version, gnutls-3.0.15, works fine. > > Bruno > Same here building for ArchLinux. -Andy From a.radke at arcor.de Sat Mar 17 08:25:54 2012 From: a.radke at arcor.de (Andreas Radke) Date: Sat, 17 Mar 2012 08:25:54 +0100 Subject: failure to build gnutls-3.0.16 In-Reply-To: <1815728.c1YDrCsP9Y@linuix> References: <1815728.c1YDrCsP9Y@linuix> Message-ID: <20120317082554.6a47dc8a@laptop64.home> Am Sat, 17 Mar 2012 01:26:22 +0100 schrieb Bruno Haible : > Why did I run into this? What's the fix? > > The previous version, gnutls-3.0.15, works fine. > > Bruno > Same here building for ArchLinux. -Andy From nmav at gnutls.org Sat Mar 17 09:13:09 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 17 Mar 2012 09:13:09 +0100 Subject: Gnutls 3.0.16 fails due to autoopts header mismatch In-Reply-To: <4F63BDDF.9090206@enterprise.bidmc.harvard.edu> References: <4F63BDDF.9090206@enterprise.bidmc.harvard.edu> Message-ID: <4F644795.7030101@gnutls.org> On 03/16/2012 11:25 PM, Kris Karas wrote: > Just tried compiling the new gnutls 3.0.16: > > serv-args.h:62:3: error: #error option template version mismatches > autoopts/options.h header > serv-args.h:63:3: error: unknown type name 'Choke' > serv-args.h:63:11: error: expected '=', ',', ';', 'asm' or > '__attribute__' before '.' token > > Poking around, it seems that the version of GNU autogen used to convert > src/serv-args.def into src/serv-args.h has placed > > #define AO_TEMPLATE_VERSION 147460 > into that header, whereas in src/libopts/autoopts/options.h there is > #define OPTIONS_STRUCT_VERSION 147459 Ouch. It seems we'd need a new release with a fixed autogen. Thank you for reporting it. regards, Nikos From nmav at gnutls.org Sat Mar 17 09:25:33 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 17 Mar 2012 09:25:33 +0100 Subject: Bug in gnutls_pubkey_verify_data() API documentation ? In-Reply-To: <62f986b009b1fe506eea6c893e1a8580.squirrel@webmail.uci.edu> References: <62f986b009b1fe506eea6c893e1a8580.squirrel@webmail.uci.edu> Message-ID: <4F644A7D.7070801@gnutls.org> On 03/17/2012 06:18 AM, Quan Nguyen wrote: > > In the API documentation, it says gnutls_pubkey_verify_data(): "On > success, %GNUTLS_E_SUCCESS (0) is returned". However, looking at the > source code in gnutls_pubkey.c, we see that this function calls > pubkey_verify_data(), which returns 1 on success :"verifies the signature > data, and returns GNUTLS_E_PK_SIG_VERIFY_FAILED if not verified, or 1 > otherwise." You're correct. I've replaced it with: Returns: In case of a verification failure %GNUTLS_E_PK_SIG_VERIFY_FAILED is returned, and zero or positive code on success. thank you, Nikos From nmav at gnutls.org Sat Mar 17 10:08:42 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 17 Mar 2012 10:08:42 +0100 Subject: gnutls 3.0.17 Message-ID: <4F64549A.2030201@gnutls.org> Hello, I've just released gnutls 3.0.17, which fixes a build problem in the included programs of 3.0.16. * Version 3.0.17 (released 2012-03-17) ** command line apps: Always link with local libopts. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.17.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.17.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.17.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.17.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.17.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.17.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 rmh at gnu.org Sat Mar 17 11:36:06 2012 From: rmh at gnu.org (Robert Millan) Date: Sat, 17 Mar 2012 11:36:06 +0100 Subject: [PATCH] small fix to avoid integer overflow Message-ID: Hi, Please consider casting the result of get_days() to time_t before converting it to seconds (rather than afterwards). Otherwise it becomes affected by Y2K38 bug unnecessarily. -- Robert Millan -------------- next part -------------- diff --git a/src/certtool.c b/src/certtool.c index df23033..0c4ed9a 100644 --- a/src/certtool.c +++ b/src/certtool.c @@ -417,7 +417,7 @@ generate_certificate (gnutls_privkey_t * ret_key, result = gnutls_x509_crt_set_expiration_time (crt, - time (NULL) + days * 24 * 60 * 60); + time (NULL) + ((time_t) days) * 24 * 60 * 60); if (result < 0) error (EXIT_FAILURE, 0, "set_expiration: %s", gnutls_strerror (result)); @@ -933,7 +933,7 @@ update_signed_certificate (common_info_st * cinfo) days = get_days (); result = - gnutls_x509_crt_set_expiration_time (crt, tim + days * 24 * 60 * 60); + gnutls_x509_crt_set_expiration_time (crt, tim + ((time_t) days) * 24 * 60 * 60); if (result < 0) error (EXIT_FAILURE, 0, "set_expiration: %s", gnutls_strerror (result)); From nmav at gnutls.org Sat Mar 17 13:19:52 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 17 Mar 2012 13:19:52 +0100 Subject: google summer of code Message-ID: <4F648168.4030601@gnutls.org> Hello, I've put some ideas for projects for google summer of code (we'll participate via GNU) at: http://www.gnu.org/software/gnutls/soc.html If you have any other suggestions or willing to participate as a mentor please let me know as soon (we need a backup mentor). regards, Nikos From nmav at gnutls.org Sat Mar 17 13:28:21 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 17 Mar 2012 13:28:21 +0100 Subject: [PATCH] small fix to avoid integer overflow In-Reply-To: References: Message-ID: <4F648365.9030807@gnutls.org> On 03/17/2012 11:36 AM, Robert Millan wrote: > Hi, > > Please consider casting the result of get_days() to time_t before > converting it to seconds (rather than afterwards). Otherwise it > becomes affected by Y2K38 bug unnecessarily. Thank you. Applied. From dkg at fifthhorseman.net Sat Mar 17 17:51:15 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 17 Mar 2012 12:51:15 -0400 Subject: google summer of code In-Reply-To: <4F648168.4030601@gnutls.org> References: <4F648168.4030601@gnutls.org> Message-ID: <4F64C103.2020004@fifthhorseman.net> On 03/17/2012 08:19 AM, Nikos Mavrogiannopoulos wrote: > Hello, > I've put some ideas for projects for google summer of code (we'll > participate via GNU) at: > http://www.gnu.org/software/gnutls/soc.html > > If you have any other suggestions or willing to participate as a mentor > please let me know as soon (we need a backup mentor). I'd be willing to act as a backup mentor, if you think that'd be appropriate. --dkg From nmav at gnutls.org Sat Mar 17 20:56:51 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 17 Mar 2012 20:56:51 +0100 Subject: google summer of code In-Reply-To: <4F64C103.2020004@fifthhorseman.net> References: <4F648168.4030601@gnutls.org> <4F64C103.2020004@fifthhorseman.net> Message-ID: <4F64EC83.709@gnutls.org> On 03/17/2012 05:51 PM, Daniel Kahn Gillmor wrote: >> I've put some ideas for projects for google summer of code (we'll >> participate via GNU) at: >> http://www.gnu.org/software/gnutls/soc.html >> If you have any other suggestions or willing to participate as a mentor >> please let me know as soon (we need a backup mentor). > I'd be willing to act as a backup mentor, if you think that'd be > appropriate. Thank you Daniel. I've added you. From nmav at gnutls.org Sun Mar 18 19:43:35 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 18 Mar 2012 19:43:35 +0100 Subject: google summer of code In-Reply-To: <4F648168.4030601@gnutls.org> References: <4F648168.4030601@gnutls.org> Message-ID: <4F662CD7.20006@gnutls.org> On 03/17/2012 01:19 PM, Nikos Mavrogiannopoulos wrote: > Hello, > I've put some ideas for projects for google summer of code (we'll > participate via GNU) at: > http://www.gnu.org/software/gnutls/soc.html Please feel free to forward our ideas page to interested students! regards, Nikos From nmav at gnutls.org Mon Mar 19 11:18:43 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 19 Mar 2012 11:18:43 +0100 Subject: Fwd: GNU Libtasn1 2.12 released In-Reply-To: <87mx7cgbft.fsf@latte.josefsson.org> References: <87mx7cgbft.fsf@latte.josefsson.org> Message-ID: Note that the bug fixed affects all gnutls versions. ---------- Forwarded message ---------- From: Simon Josefsson Date: Mon, Mar 19, 2012 at 10:57 AM Subject: GNU Libtasn1 2.12 released To: help-libtasn1 at gnu.org, info-gnu at gnu.org GNU Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding/decoding. ?GNU Libtasn1 is used by GnuTLS to handle X.509 structures and by GNU Shishi to handle Kerberos V5 structures. * Noteworthy changes in release 2.12 (2012-03-19) [stable] - Cleanup license headers. - build: Update gnulib files. - Corrected DER decoding issue (reported by Matthew Hall). ?Added self check to detect the problem, see tests/Test_overflow.c. ?This problem can lead to at least remotely triggered crashes, see ?further analysis on the libtasn1 mailing list. Homepage: ?https://www.gnu.org/software/libtasn1/ Here are the compressed sources (1.9MB): ?ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.12.tar.gz ?http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.12.tar.gz Here are GPG detached signatures using key 0xB565716F: ?ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.12.tar.gz.sig ?http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.12.tar.gz.sig We publish Windows binaries for this release (32 and 64 bits): ?ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.12-win32.zip ?http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.12-win32.zip ?ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.12-win64.zip ?http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.12-win64.zip Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. ?Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. ?We are always looking for interesting development projects. ?See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join the help-libtasn1 mailing list, see: ?https://lists.gnu.org/mailman/listinfo/help-libtasn1 All manuals are available from: ?https://www.gnu.org/software/libtasn1/manual/ Direct links to the manual: ?HTML: https://www.gnu.org/software/libtasn1/manual/libtasn1.html ?PDF: https://www.gnu.org/software/libtasn1/manual/libtasn1.pdf Direct links to the API Reference manual: ?HTML: https://www.gnu.org/software/libtasn1/reference/ ?PDF: https://www.gnu.org/software/libtasn1/reference/libtasn1.pdf For developers interested in improving code quality, we publish Cyclomatic code complexity charts that help you find code that may need review and improvements: ?https://www.gnu.org/software/libtasn1/cyclo/ Code coverage charts indicate parts of the source code that needs to be tested better by the included self-tests: ?https://www.gnu.org/software/libtasn1/coverage/ Clang can analyse the source code for common problems, here is its report for libtasn1: ?https://www.gnu.org/software/libtasn1/clang/ The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub ? 1280R/B565716F 2002-05-05 [expires: 2013-05-10] ? ? ?Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 ?F835 EDA2 1E94 B565 716F uid ? ? ? ? ? ? ? ? ?Simon Josefsson uid ? ? ? ? ? ? ? ? ?Simon Josefsson sub ? 1280R/4D5D40AE 2002-05-05 [expires: 2013-05-10] sub ? 2048R/105E722E 2012-03-13 [expires: 2013-07-26] sub ? 2048R/728AB82C 2012-03-13 [expires: 2013-07-26] sub ? 2048R/9394F626 2012-03-13 [expires: 2013-07-26] The key is available from: ?http://josefsson.org/key.txt ?dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: b73539aee5444efb5e606b94bdf3ec5bfedb8620 ?libtasn1-2.12.tar.gz 011e8ab84d57b441f0c1dc18eebdda2ce3960bc9b7fdf8e1d4e35085 ?libtasn1-2.12.tar.gz 919933732983e5075a2df288c1a3eb413e8c86c5 ?libtasn1-2.12-win32.zip 29b40469ae38ba7ff71abde5b806c8d30a222723443386eff4923c57 libtasn1-2.12-win32.zip de3add4d82aef98b7e52fff1ae72c1136781363d ?libtasn1-2.12-win64.zip 6cb1e3171e38e786391cb9dd702e12724f0a19c1cf6c1953a8552e82 libtasn1-2.12-win64.zip Happy hacking, Simon From simon at josefsson.org Mon Mar 19 11:55:26 2012 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 19 Mar 2012 11:55:26 +0100 Subject: Building 3.0.15 (master branch) In-Reply-To: <11249f10132921a96e3b61f85f4a49c8.squirrel@mailbox.gwdg.de> (lfinsto@gwdg.de's message of "Wed, 14 Mar 2012 19:21:14 +0100") References: <11249f10132921a96e3b61f85f4a49c8.squirrel@mailbox.gwdg.de> Message-ID: <878viwdfmp.fsf@latte.josefsson.org> lfinsto at gwdg.de writes: > Hello, > > I've just updated my PC to SuseLinux 12.1 and thought I would try building > and installing GNUTLS from the master branch of the git repository. > (For what it's worth, the GNUTLS installed using yast2 is version 3.0.3, > so pretty recent.) > > I succeeded for the most part, but there were a couple of problems and I > thought a report might be useful: Thank you! > I got errors with aclocal && autoconf the first time through, but > > autoreconf -fvim > > worked (after touching ChangeLog, as below). I forgot to test this after > recloning the repository and just ran autoreconf -fvim immediately. > > Makefile.am: required file `./ChangeLog' not found > autoreconf: automake failed with exit status: 1 > > touch ChangeLog > > autoreconf -fvim > > configure --prefix=/home/lfinsto/gnutls_dev/master_install > > make > > File cs.po does not exist. If you are a translator, you can create it > through 'msginit'. > > configure --prefix=/home/lfinsto/gnutls_dev/master_install --disable-nls > > The first time through, I solved this problem by running `msginit -i > *.po.in -o *.po' for the various files, but for a couple it didn't work > and I used cs.po.in for the input, e.g., -i cs.po.in -o xx.po > (I'm not sure which ones didn't work anymore). I was just guessing that > it would work and don't understand this. That is not the way to bootstrap GnuTLS. See here for how to do it: https://www.gnu.org/software/gnutls/devel.html the commands to bootstrap are run in cfg.mk via GNUmakefile, see the autoreconf rule in cfg.mk. > make > > certtool-args.c:51:13: error: conflicting types for 'optionAlias' > ../src/libopts/autoopts/options.h:1031:12: note: previous declaration > of 'optionAlias' was here > > make[3]: *** [libcmd_certtool_la-certtool-args.lo] Error 1 > make[3]: Leaving directory `/home/lfinsto/gnutls_dev/gnutls_master/src' > > certtool-args.c:51: > > * DO NOT EDIT THIS FILE (certtool-args.c) > * > * It has been AutoGen-ed March 14, 2012 at 06:30:08 PM by AutoGen > 5.11.8 > * From the definitions certtool-args.def > * and the template file options > > > libopts/autoopts/options.h > > * DO NOT EDIT THIS FILE (options.h) > * > * It has been AutoGen-ed February 26, 2012 at 11:08:44 AM by AutoGen > 5.15pre14 > * From the definitions funcs.def > * and the template file options_h > > I had a good look around the file system, but I was unable to locate > funcs.def or options_h (I didn't look very hard for `options'). > The declaration is not in certtool-args.def. > > I therefore changed > > extern void optionAlias(tOptions* pOpts, tOptDesc* pOD, unsigned int alias); > > to > > extern int optionAlias(tOptions* pOpts, tOptDesc* pOD, unsigned int alias); > > in certtool-args.c. > > It worked, but it's obviously not a good solution. Seems like your autogen version is too old. Get 5.15. > make > > /bin/sh: line 75: /usr/share/autogen/texi2mdoc: Permission denied > /bin/sh: line 194: /usr/share/autogen/mdoc2man: Permission denied > > As root: > > chmod a+rx /usr/share/autogen/texi2mdoc > chmod a+rx /usr/share/autogen/mdoc2man > > This would seem to be a problem with the autogen installation (I installed > it using yast2). Yes, you should install autogen 5.15 locally. > make > > Lots of these warnings: > > mini-eagain2.c:189:41: warning: cast to pointer from integer of different > size [-Wint-to-pointer-cast] > > (it's a 64-bit machine) I think these are known issues that nobody has had time to resolve. Help appreciated. /Simon From INVALID.NOREPLY at gnu.org Mon Mar 19 21:53:02 2012 From: INVALID.NOREPLY at gnu.org (Bernhard Rosenkraenzer) Date: Mon, 19 Mar 2012 20:53:02 +0000 Subject: [sr #107987] compat.h includes some non-working defines Message-ID: <20120319-205301.sv1996.8628@savannah.gnu.org> URL: Summary: compat.h includes some non-working defines Project: GnuTLS Submitted by: bero Submitted on: Mon 19 Mar 2012 08:53:01 PM GMT 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: GNU/Linux _______________________________________________________ Details: compat.h in 3.0.17 still does #define TLS_RANDOM_SIZE GNUTLS_RANDOM_SIZE #define TLS_MASTER_SIZE GNUTLS_MASTER_SIZE However, GNUTLS_RANDOM_SIZE and GNUTLS_MASTER_SIZE have been removed a couple of revisions ago. The compat defines requiring them should be removed as well. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Mar 19 22:38:12 2012 From: INVALID.NOREPLY at gnu.org (Simon Josefsson) Date: Mon, 19 Mar 2012 21:38:12 +0000 Subject: [sr #107987] compat.h includes some non-working defines In-Reply-To: <20120319-205301.sv1996.8628@savannah.gnu.org> References: <20120319-205301.sv1996.8628@savannah.gnu.org> Message-ID: <20120319-213812.sv7213.99458@savannah.gnu.org> Update of sr #107987 (project gnutls): Status: None => Done Assigned to: None => jas Open/Closed: Open => Closed _______________________________________________________ Follow-up Comment #1: Thanks, resolved. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From thoger at redhat.com Tue Mar 20 09:20:27 2012 From: thoger at redhat.com (Tomas Hoger) Date: Tue, 20 Mar 2012 08:20:27 +0000 (UTC) Subject: Fwd: GNU Libtasn1 2.12 released References: <87mx7cgbft.fsf@latte.josefsson.org> Message-ID: Nikos Mavrogiannopoulos writes: > Note that the bug fixed affects all gnutls versions. Nikos, should the above be read as "all gnutls versions include libtasn1 versions affected by this problem" or "gnutls uses asn1_get_length_der incorrectly too"? Have you managed to confirm the issue in gnutls and can possibly comment on known possible impacts (e.g. TLS client can trigger this on TLS server by providing a crafted client certificate during handshake)? Thank you! th. From simon at josefsson.org Tue Mar 20 12:43:10 2012 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 20 Mar 2012 12:43:10 +0100 Subject: Fwd: GNU Libtasn1 2.12 released In-Reply-To: (Tomas Hoger's message of "Tue, 20 Mar 2012 08:20:27 +0000 (UTC)") References: <87mx7cgbft.fsf@latte.josefsson.org> Message-ID: <8762dzmrap.fsf@latte.josefsson.org> Tomas Hoger writes: > Nikos Mavrogiannopoulos writes: > >> Note that the bug fixed affects all gnutls versions. > > Nikos, should the above be read as "all gnutls versions include > libtasn1 versions affected by this problem" or "gnutls uses > asn1_get_length_der incorrectly too"? Have you managed to > confirm the issue in gnutls and can possibly comment on known > possible impacts (e.g. TLS client can trigger this on TLS server > by providing a crafted client certificate during handshake)? There is a self-test in GnuTLS about this, see tests/suite/invalid-cert*. It contains a crafted cert which triggers the bug, to cause a crash. /Simon From nmav at gnutls.org Tue Mar 20 18:41:21 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 20 Mar 2012 18:41:21 +0100 Subject: Fwd: GNU Libtasn1 2.12 released In-Reply-To: References: <87mx7cgbft.fsf@latte.josefsson.org> Message-ID: <4F68C141.5080303@gnutls.org> On 03/20/2012 09:20 AM, Tomas Hoger wrote: >> Note that the bug fixed affects all gnutls versions. > Nikos, should the above be read as "all gnutls versions include > libtasn1 versions affected by this problem" or "gnutls uses > asn1_get_length_der incorrectly too"? I don't think gnutls uses asn1_get_length_der(). It is libtasn1 that was using asn1_get_length_der() internally in an incorrect way. Because of that all programs using libtasn1 are vulnerable including gnutls. > Have you managed to > confirm the issue in gnutls and can possibly comment on known > possible impacts (e.g. TLS client can trigger this on TLS server > by providing a crafted client certificate during handshake)? Yes, certificate parsing crashes gnutls with the vulnerable libtasn1. regards, Nikos From security at mudynamics.com Wed Mar 21 00:40:02 2012 From: security at mudynamics.com (Security) Date: Tue, 20 Mar 2012 23:40:02 +0000 Subject: Mu Dynamics, Inc. Security Advisories MU-201202-01 and MU-201202-02 for GnuTLS and Libtasn1 Message-ID: <4A63A26857EBCC41AF96448FAC6FAA6D18E5B600@buddy.musecurity.local> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mu Dynamics, Inc. Security Advisories MU-201202-01 and MU-201202-02 for GnuTLS and Libtasn1 TLS record handling vulnerability in GnuTLS [MU-201202-01] ASN.1 length decoding vulnerability in Libtasn1 [MU-201202-02] 20 March 2012 http://blog.mudynamics.com/2012/03/20/gnutls-and-libtasn1-vulns/ http://labs.mudynamics.com/advisories.html Affected Products/Versions: * libgnutls up to 3.0.16. * libtasn1 up to 2.11. Product Overview: GnuTLS is an open source implementation of SSL, TLS and DTLS, with APIs for encrypted network communications, along with X.509, PKCS #12, OpenPGP, and other security data types. Analysis: Details for TLS record handling vulnerability in GnuTLS [MU-201202-01]: The block cipher decryption logic in GnuTLS assumed that a record containing any data which was a multiple of the block size was valid for further decryption processing, leading to a heap corruption vulnerability. The bug can be reproduced in GnuTLS 3.0.14 by creating a corrupt GenericBlockCipher struct with a valid IV, while everything else is stripped off the end, while the handshake message length retains its original value: struct { opaque IV[SecurityParameters.record_iv_length]; // corrupt: below items not sent /* block-ciphered struct { opaque content[TLSCompressed.length]; opaque MAC[SecurityParameters.mac_length]; uint8 padding[GenericBlockCipher.padding_length]; uint8 padding_length; }; */ } GenericBlockCipher; This will cause a segmentation fault, when the ciphertext_to_compressed function tries to give decrypted data to _gnutls_auth_cipher_add_auth for HMAC verification, even though the data length is invalid, and it should have returned GNUTLS_E_DECRYPTION_FAILED or GNUTLS_E_UNEXPECTED_PACKET_LENGTH instead, before _gnutls_auth_cipher_add_auth was called. Since the error was not returned soon enough, all of the various operations ciphertext_to_compressed performs: i.e. setting the IV, removing the padding, setting the "true" data length with the padding stripped, checking the padding size and padding payload and verifying HMAC could all reference undefined, unallocated, or uninitialized memory. There could be similar ways to reproduce this for AEAD ciphers due to the various flows through this code, but we did not attempt to do this, and see it as a topic for further investigation. Below we trace the execution of the ciphertext_to_compressed function from lib/gnutls_cipher.c. The unsafe operations and missed opportunities to return before the heap corruption happens are marked with "***** ... *****" : 433 static int 434 ciphertext_to_compressed (gnutls_session_t session, 435 gnutls_datum_t *ciphertext, 436 uint8_t * compress_data, 437 int compress_size, 438 uint8_t type, record_parameters_st * params, 439 uint64* sequence) 440 { ... 511 case CIPHER_BLOCK: 512 if (ciphertext->size < MAX(blocksize, tag_size) || (ciphertext->size % blocksize != 0)) ***** UNSAFE ***** 513 return gnutls_assert_val(GNUTLS_E_UNEXPECTED_PACKET_LENGTH); 514 515 /* ignore the IV in TLS 1.1+ 516 */ 517 if (explicit_iv) 518 { 519 _gnutls_auth_cipher_setiv(¶ms->read.cipher_state, 520 ciphertext->data, blocksize); 521 522 ciphertext->size -= blocksize; 523 ciphertext->data += blocksize; 524 525 if (ciphertext->size == 0) ***** UNSAFE ***** 526 { 527 gnutls_assert (); 528 return GNUTLS_E_DECRYPTION_FAILED; 529 } 530 } ... 537 if ((ret = 538 _gnutls_cipher_decrypt (¶ms->read.cipher_state.cipher, 539 ciphertext->data, ciphertext->size)) < 0) 540 return gnutls_assert_val(ret); 541 542 pad = ciphertext->data[ciphertext->size - 1] + 1; /* pad */ 543 544 if ((int) pad > (int) ciphertext->size - tag_size) 545 { 546 gnutls_assert (); 547 _gnutls_record_log 548 ("REC[%p]: Short record length %d > %d - %d (under attack?)\n", 549 session, pad, ciphertext->size, tag_size); ***** Message Appears During The Attack ***** 550 /* We do not fail here. We check below for the 551 * the pad_failed. If zero means success. 552 */ 553 pad_failed = GNUTLS_E_DECRYPTION_FAILED; ***** Execution Continues Anyway ***** 554 pad %= blocksize; 555 } 556 557 length = ciphertext->size - tag_size - pad; 558 559 /* Check the padding bytes (TLS 1.x) */ ... 577 /* Pass the type, version, length and compressed through 578 * MAC. 579 */ 580 preamble_size = 581 make_preamble (UINT64DATA(*sequence), type, 582 length, ver, preamble); 583 ret = _gnutls_auth_cipher_add_auth (¶ms->read.cipher_state, preamble, preamble_size); 584 if (ret < 0) 585 return gnutls_assert_val(ret); 586 587 ret = _gnutls_auth_cipher_add_auth (¶ms->read.cipher_state, ciphertext->data, length); ***** UNSAFE, crashes here ***** 588 if (ret < 0) 589 return gnutls_assert_val(ret); ***** Crashes Before Error Is Returned ***** ... The segmentation fault appears as follows in GDB: Program received signal SIGSEGV, Segmentation fault. 0x003b9946 in _nettle_sha256_compress (state=0x807f128, input=0x808f000
, k=0x3cdb60) at sha256-compress.c:111 111 sha256-compress.c: No such file or directory. in sha256-compress.c (gdb) bt #0 0x003b9946 in _nettle_sha256_compress (state=0x807f128, input=0x808f000
, k=0x3cdb60) at sha256-compress.c:111 #1 0x003b961b in nettle_sha256_update (ctx=0x807f128, length=4294916861, data=0x808effc "") at sha256.c:92 #2 0x003b336d in nettle_hmac_sha256_update (ctx=0x807f050, length=4294967280, data=0x8082b09 '\017' ) at hmac-sha256.c:43 #3 0x0021a749 in wrap_nettle_hmac_update (_ctx=0x807f050, text=0x8082b09, textsize=4294967280) at mac.c:231 #4 0x00158233 in _gnutls_hmac (handle=0x807ef9c, text=0x8082b09, textlen=4294967280) at ./gnutls_hash_int.h:73 #5 0x00158b35 in _gnutls_auth_cipher_add_auth (handle=0x807ef78, text=0x8082b09, textlen=-16) at gnutls_cipher_int.c:190 #6 0x001473de in ciphertext_to_compressed (session=0x807d810, ciphertext=0xbfffe8a4, compress_data=0x8083da4 "", compress_size=16384, type=22 '\026', params=0x807ed48, sequence=0x807efcc) at gnutls_cipher.c:587 #7 0x00145cdc in _gnutls_decrypt (session=0x807d810, ciphertext=0x8082af9 "\252\257C/7\301\362\352h|d\275#\312\027\312", '\017' , ciphertext_size=32, data=0x8083da4 "", max_data_size=16384, type=GNUTLS_HANDSHAKE, params=0x807ed48, sequence=0x807efcc) at gnutls_cipher.c:159 ... (gdb) The segmentation fault appears as follows in Valgrind Memcheck: ==29586== Invalid read of size 1 ==29586== at 0x40274B9: memcpy (mc_replace_strmem.c:497) ==29586== by 0x42BC5A6: nettle_sha256_update (sha256.c:92) ==29586== by 0x42B636C: nettle_hmac_sha256_update (hmac-sha256.c:43) ==29586== by 0x411C748: wrap_nettle_hmac_update (mac.c:231) ==29586== by 0x405A232: _gnutls_hmac (gnutls_hash_int.h:73) ==29586== by 0x405AB34: _gnutls_auth_cipher_add_auth (gnutls_cipher_int.c:190) ==29586== by 0x40493DD: ciphertext_to_compressed (gnutls_cipher.c:587) ==29586== by 0x4047CDB: _gnutls_decrypt (gnutls_cipher.c:159) ... ==29586== Address 0x4464411 is 0 bytes after a block of size 89 alloc'd ==29586== at 0x4024F12: calloc (vg_replace_malloc.c:467) ==29586== by 0x4049AE4: _mbuffer_alloc (gnutls_mbuffers.c:288) ==29586== by 0x4049C49: _mbuffer_linearize (gnutls_mbuffers.c:349) ==29586== by 0x40462FB: _gnutls_recv_in_buffers (gnutls_record.c:996) ==29586== by 0x404D01C: _gnutls_handshake_io_recv_int (gnutls_buffers.c:1174) ==29586== by 0x4050383: _gnutls_recv_handshake (gnutls_handshake.c:1260) ... ==29586== Invalid read of size 1 ... ==29586== Address 0x4464412 is 1 bytes after a block of size 89 alloc'd ... ==29586== Process terminating with default action of signal 11 (SIGSEGV) ==29586== Access not within mapped region at address 0x4779000 ==29586== at 0x42BC946: _nettle_sha256_compress (sha256-compress.c:111) ==29586== by 0x42BC61A: nettle_sha256_update (sha256.c:92) ==29586== by 0x42B636C: nettle_hmac_sha256_update (hmac-sha256.c:43) ==29586== by 0x411C748: wrap_nettle_hmac_update (mac.c:231) ==29586== by 0x405A232: _gnutls_hmac (gnutls_hash_int.h:73) ==29586== by 0x405AB34: _gnutls_auth_cipher_add_auth (gnutls_cipher_int.c:190) ==29586== by 0x40493DD: ciphertext_to_compressed (gnutls_cipher.c:587) ... Segmentation fault Details for ASN.1 length decoding vulnerability in Libtasn1 [MU-201202-02]: Various functions using the ASN.1 length decoding logic in Libtasn1 were incorrectly assuming that the return value from asn1_get_length_der is always less than the length of the enclosing ASN.1 structure, which is only true for valid structures and not for intentionally corrupt or otherwise buggy structures. Here is an example of unsafe asn1_get_length_der usage from lib/minitasn1/decoding.c, in the asn1_der_decoding function: 0812 asn1_retCode 0813 asn1_der_decoding (ASN1_TYPE * element, const void *ider, int len, 0814 char *errorDescription) 0815 { ... 1033 case TYPE_ENUMERATED: 1034 len2 = 1035 asn1_get_length_der (der + counter, len - counter, &len3); 1036 if (len2 < 0) 1037 return ASN1_DER_ERROR; 1038 if (len2 + len3 > len - counter) 1039 return ASN1_DER_ERROR; 1040 _asn1_set_value (p, der + counter, len3 + len2); 1041 counter += len3 + len2; 1042 move = RIGHT; 1043 break; The above call to asn1_get_length_der was returning an impossibly large value of 2GB when the Mu analyzer generated corrupt lengths fields for versions, serial numbers, public key info, and signature structures in X.509 client certificates, but this could happen in any use of Libtasn1 that is relying upon asn1_get_length_der, not just SSL, TLS, or GnuTLS. The asn1_der_decoding function failed to check for cases when asn1_get_length_der returned a length larger than the enclosing structure's (void* ider) own length (int len). When _asn1_set_value was called anyway, it contained a memcpy operation which assumed the arguments are valid, which tried copy 2GB of memory, leading to a heap corruption vulnerability. Simon Josefsson, Libtasn1 maintainer, described the patch as follows: "the real bug was not in asn1_get_length_der() even if that is the function we patch[ed]. The callers of that function that did not check that the return values are sane were buggy. However, instead of fixing all callers, ... we went for the simpler solution to let the function return an error for a situation that is unlikely to occur without malicious interaction or data corruption." The asn1_der_decoding function shown above is now safe, because asn1_get_length_der was updated to "[return] -4 when the decoded length value plus @len would exceed @der_len," so asn1_der_decoding returns ASN1_DER_ERROR before it can call _asn1_set_value to trigger the segmentation fault. Abbreviated GDB Backtrace after the segmentation fault: (gdb) bt #0 __memcpy_ia32 () at ../sysdeps/i386/i686/multiarch/../memcpy.S:75 #1 0x00000001 in ?? () #2 0x0020eadc in _asn1_set_value (node=0x807ff50, value=0x807ed5c, len=2147483652) at parser_aux.c:228 #3 0x0020a646 in asn1_der_decoding (element=0x8078000, ider=0x807ed4e, len=687, errorDescription=0x0) at decoding.c:1036 #4 0x001bc7da in gnutls_x509_crt_import (cert=0x8078000, data=0xbfffeae8, format=GNUTLS_X509_FMT_DER) at x509.c:226 #5 0x00176d16 in gnutls_pcert_import_x509_raw (pcert=0x807d610, cert=0xbfffeae8, format=GNUTLS_X509_FMT_DER, flags=0) at gnutls_pcert.c:201 ... (gdb) Response / Solution: TLS record handling vulnerability in GnuTLS [MU-201202-01] is fixed in GnuTLS 3.0.15. For more details, see http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5912 . ASN.1 length decoding vulnerability in Libtasn1 [MU-201202-02] is fixed in Libtasn1 2.12 and GnuTLS 3.0.16. For more details, see http://lists.gnu.org/archive/html/help-libtasn1/2012-03/msg00000.html and http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5932 . History: Mon, 27 Feb 2012 14:13:45 -0800: TLS Record handling issue reported. Tue, 28 Feb 2012 10:29:46 +0100: TLS Record handling patch created. Fri, 02 Mar 2012 18:42:05 +0000: GnuTLS 3.0.15 release announced. Fri, 02 Mar 2012 14:04:31 -0800: ASN.1 length decoding issue reported. Wed, 14 Mar 2012 01:04:36 +0100: ASN.1 length decoding patch created. Mon, 19 Mar 2012 10:57:42 +0100: Libtasn1 2.12 release announced. Tue, 20 Mar 2012 23:40:00 +0000: Advisory released to the public. See also: http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5912 http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5932 http://lists.gnu.org/archive/html/help-libtasn1/2012-03/msg00000.html http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=b495740f2ff66550ca9395b3fda3ea32c3acb185 http://git.savannah.gnu.org/gitweb/?p=libtasn1.git;a=commitdiff;h=6e534bf4fb3144be51c928ed3efcf9c36055c9c7 Credit: These vulnerabilities were discovered by Matthew Hall , Senior Network Protocol Software Engineer at Mu Dynamics, via code inspection and protocol fuzzing using a Mu 4000 security analyzer. http://blog.mudynamics.com/wp-content/uploads/2012/03/pgpkey.txt Mu Dynamics is the leading provider of solutions ensuring the performance and security of both applications and network infrastructure. The company's innovative solutions enable customers to confidently meet the challenges posed by today's rapidly changing networks. This includes the ever-growing number of applications and devices on the network, and the swift transition to mobile, virtual and cloud environments. Hundreds of service providers, enterprises, application developers and network equipment manufacturers count on its purpose-built solutions, like Mu Studio and Blitz, to ensure their applications and networks are scalable and secure. Mu Dynamics is headquartered in Sunnyvale, California. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJPaRSqAAoJEEzdDa9po1UUuhkP/RnvCMvQwF+9UyZArKkEDVgu Z6NvZPcquXZhQ4MNLuIbfkikQnGg+9e7EnbKUzbxxNp7tsVN/ioVGWFHRZw3diSp Tknw8SZlMghz4Li/nw4ruPQcbT4r6EcDtlkJhTAtI+A2ZAlMkurMUAGIcPhX2CvU cpNHwGdTPqYcT4+07zzhbhf2M2MD5y1268PNEx9EN9VrZEriyDpFRBKlkkOTeti5 LuSkhIUbiH0wChWGheM54rvsoi4LRSO8QEeeUED1kqBzNI5OJD7AB3g1RJ/K8vEB DjSkGmKg2siDHifNQUgwOcnED0qcUnN9LAp/1qV0Wn+DJvG3RC5hleJSHYPAW6sk /fmoOegRN+9TlXVI2ZBzF3ltCaDr8ktbwMUiOU/BZc0MAG2geUvGUyYGkZW0JLZN MZaJRMzqAS2DrKMapwDWUeNXf5rvQHU49eRweBjyE8lUA2cMtMsvgbFtTOtxAFhl JYytEI1e7Sh8Xo12GWUxsc6aMjIngFzs2VgfwQc283fnBjZWHZNsdX8gKcKoUY3f oN6IcQijxfOgCEiWkERsPtcX9GN2+9y2QLs79Z5uDeBJXCOLSzeZg93gWqjEGfcm 64iJwKAWpGcHEr5Po3mxwA+9yREmrth+e6cax9LujiXAn1LrW2SkUXofCafYg8yd ym77p8ibkKLczxASVN2I =aqOg -----END PGP SIGNATURE----- From thoger at redhat.com Wed Mar 21 14:40:49 2012 From: thoger at redhat.com (Tomas Hoger) Date: Wed, 21 Mar 2012 14:40:49 +0100 Subject: Mu Dynamics, Inc. Security Advisories MU-201202-01 and MU-201202-02 for GnuTLS and Libtasn1 In-Reply-To: <4A63A26857EBCC41AF96448FAC6FAA6D18E5B600@buddy.musecurity.local> References: <4A63A26857EBCC41AF96448FAC6FAA6D18E5B600@buddy.musecurity.local> Message-ID: <20120321144049.64f523e8@redhat.com> On Tue, 20 Mar 2012 23:40:02 +0000 Security wrote: > TLS record handling vulnerability in GnuTLS [MU-201202-01] > ASN.1 length decoding vulnerability in Libtasn1 [MU-201202-02] FYI, following CVEs were assigned to these issues: libtasn1 MU-201202-02 CVE-2012-1569 gnutls MU-201202-01 CVE-2012-1573 References: http://thread.gmane.org/gmane.comp.security.oss.general/7231 http://thread.gmane.org/gmane.comp.security.oss.general/7246 -- Tomas Hoger / Red Hat Security Response Team From INVALID.NOREPLY at gnu.org Wed Mar 21 23:06:50 2012 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Wed, 21 Mar 2012 22:06:50 +0000 Subject: [sr #107996] MinGW-W64 enhancements Message-ID: <20120321-220649.sv0.42148@savannah.gnu.org> URL: Summary: MinGW-W64 enhancements Project: GnuTLS Submitted by: None Submitted on: Wed 21 Mar 2012 10:06:49 PM UTC Category: Core library Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: scottm at aero.org Open/Closed: Open Discussion Lock: Any Operating System: Microsoft Windows _______________________________________________________ Details: The following patch enhances support for MinGW-W64, notably that MinGW-W64 (and the Win64 API) assumes a LP64-model environment. Consequently, this patch significantly cuts down the number of int-to-pointer and pointer-to-int warnings that are generated. Also, libopts should not assume that gettext() is declared or even supported by stdio.h. Several platforms, not just MinGW, require libintl.h for the declaration and -lintl for linking, as detected by the HAVE_GETTEXT macro during configure. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Wed 21 Mar 2012 10:06:49 PM UTC Name: gnutls-patch.txt Size: 4kB By: None _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From scottm at aero.org Wed Mar 21 22:46:34 2012 From: scottm at aero.org (B. Scott Michel) Date: Wed, 21 Mar 2012 13:46:34 -0800 Subject: Patch for MinGW-W64 port Message-ID: <584945461bb94a6da16b75e8d13f02aa@mail.face.aero.org> The attached patch enhances support for W64 using the (relatively new) MinGW-W64 environment. MinGW-W64 uses the LP64 model, which explains the changes that eliminate int-to-pointer and pointer-to-int conversion warnings by gcc. The other minor change required is that libopts assumed that gettext() came from stdio.h; I would imagine other platforms actually have to include libintl.h and have an explicit dependency on -lintl during linking. Hope this benefits more than just the MinGW community. -scooter -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gnutls-patch.txt URL: From nmav at gnutls.org Thu Mar 22 19:43:24 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 22 Mar 2012 19:43:24 +0100 Subject: Patch for MinGW-W64 port In-Reply-To: <584945461bb94a6da16b75e8d13f02aa@mail.face.aero.org> References: <584945461bb94a6da16b75e8d13f02aa@mail.face.aero.org> Message-ID: <4F6B72CC.8060305@gnutls.org> On 03/21/2012 10:46 PM, B. Scott Michel wrote: > The attached patch enhances support for W64 using the (relatively new) > MinGW-W64 environment. MinGW-W64 uses the LP64 model, which explains the > changes that eliminate int-to-pointer and pointer-to-int conversion > warnings by gcc. The other minor change required is that libopts assumed > that gettext() came from stdio.h; I would imagine other platforms > actually have to include libintl.h and have an explicit dependency on > -lintl during linking. > > Hope this benefits more than just the MinGW community. Thank you for the patch. > diff -r -u '--exclude-from=/tmp/qpatch4308a' patchTemp/gnutls-3.0.17/doc/examples/ex-serv-anon.c gnutls-3.0.17/doc/examples/ex-serv-anon.c > --- patchTemp/gnutls-3.0.17/doc/examples/ex-serv-anon.c 2012-02-08 08:08:24 -0800 > +++ gnutls-3.0.17/doc/examples/ex-serv-anon.c 2012-03-20 18:12:09 -0700 > @@ -114,7 +114,7 @@ > inet_ntop (AF_INET, &sa_cli.sin_addr, topbuf, > sizeof (topbuf)), ntohs (sa_cli.sin_port)); > > - gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sd); > + gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) ((ptrdiff_t) sd)); What difference do you see with ptrdiff_t comparing to unsigned long? > diff -r -u '--exclude-from=/tmp/qpatch4308a' patchTemp/gnutls-3.0.17/m4/hooks.m4 gnutls-3.0.17/m4/hooks.m4 > --- patchTemp/gnutls-3.0.17/m4/hooks.m4 2012-03-17 01:26:12 -0700 > +++ gnutls-3.0.17/m4/hooks.m4 2012-03-20 18:21:21 -0700 > @@ -221,9 +221,14 @@ > # For storing integers in pointers without warnings > # http://developer.gnome.org/doc/API/2.0/glib/glib-Type-Conversion-Macros.html#desc > AC_CHECK_SIZEOF(void *) > + AC_CHECK_SIZEOF(long long) > AC_CHECK_SIZEOF(long) > AC_CHECK_SIZEOF(int) > case $ac_cv_sizeof_void_p in > + $ac_cv_sizeof_long_long) > + AC_DEFINE([GNUTLS_POINTER_TO_INT_CAST], [(long long)], > + [Additional cast to bring void* to a type castable to int.]) > + ;; Why use long long for pointer to int? Isn't in this platform sizeof(void*)==sizeof(long)? > diff -r -u '--exclude-from=/tmp/qpatch4308a' patchTemp/gnutls-3.0.17/src/libopts/Makefile.am gnutls-3.0.17/src/libopts/Makefile.am > --- patchTemp/gnutls-3.0.17/src/libopts/Makefile.am 2012-02-29 00:26:33 -0800 > +++ gnutls-3.0.17/src/libopts/Makefile.am 2012-03-20 17:37:24 -0700 > @@ -8,6 +8,7 @@ > libopts_la_SOURCES = libopts.c > libopts_la_CPPFLAGS = -I$(top_srcdir) > libopts_la_LDFLAGS = -version-info 36:3:11 > +libopts_la_LIBADD = $(LTLIBINTL) I have to check that when I find some time. Did this cause a problem though? libgnutls is already linked to LTLIBINTL. > #if defined(ENABLE_NLS) > # ifndef _ > -# include > +# if defined(HAVE_GETTEXT) > +# include > +# else > +# include > +# endif I switched it, to gettext.h which we use in the lib/ as well. Let me know if such change works for you. regards, Nikos From nmav at gnutls.org Thu Mar 22 19:54:41 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 22 Mar 2012 19:54:41 +0100 Subject: Patch for MinGW-W64 port In-Reply-To: <584945461bb94a6da16b75e8d13f02aa@mail.face.aero.org> References: <584945461bb94a6da16b75e8d13f02aa@mail.face.aero.org> Message-ID: <4F6B7571.5020200@gnutls.org> On 03/21/2012 10:46 PM, B. Scott Michel wrote: > diff -r -u '--exclude-from=/tmp/qpatch4308a' patchTemp/gnutls-3.0.17/lib/accelerated/x86/aes-x86.h gnutls-3.0.17/lib/accelerated/x86/aes-x86.h > --- patchTemp/gnutls-3.0.17/lib/accelerated/x86/aes-x86.h 2012-02-18 04:51:11 -0800 > +++ gnutls-3.0.17/lib/accelerated/x86/aes-x86.h 2012-03-19 16:23:36 -0700 > @@ -7,7 +7,7 @@ > void register_padlock_crypto(void); > > #define ALIGN16(x) \ > - ((void *)(((unsigned long)(x)+0x0f)&~(0x0f))) > + ((void *)(((ptrdiff_t)(((void *) x)-((void *) 0))+((ptrdiff_t) 0x0f))&~((ptrdiff_t) 0x0f))) > > #define AES_KEY_ALIGN_SIZE 4 > #define AES_MAXNR 14 Btw. This part of the patch doesn't compile as you are using void* in a subtraction. What is the issue you're trying to solve here? regards, Nikos From eliz at gnu.org Thu Mar 22 21:26:43 2012 From: eliz at gnu.org (Eli Zaretskii) Date: Thu, 22 Mar 2012 22:26:43 +0200 Subject: Patch for MinGW-W64 port In-Reply-To: <4F6B72CC.8060305@gnutls.org> References: <584945461bb94a6da16b75e8d13f02aa@mail.face.aero.org> <4F6B72CC.8060305@gnutls.org> Message-ID: <83bonowfek.fsf@gnu.org> > Date: Thu, 22 Mar 2012 19:43:24 +0100 > From: Nikos Mavrogiannopoulos > Cc: gnutls-devel at gnu.org > > > - gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sd); > > + gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) ((ptrdiff_t) sd)); > > > What difference do you see with ptrdiff_t comparing to unsigned long? 64-bit Windows uses the LLP64 model, so `unsigned long' is a 32-bit type. By contrast, ptrdiff_t is a (signed) 64-bit type. > > + $ac_cv_sizeof_long_long) > > + AC_DEFINE([GNUTLS_POINTER_TO_INT_CAST], [(long long)], > > + [Additional cast to bring void* to a type castable to int.]) > > + ;; > > > Why use long long for pointer to int? Isn't in this platform > sizeof(void*)==sizeof(long)? No, see above. On 64-bit Windows, sizeof(void *) == sizeof(long long) From nmav at gnutls.org Thu Mar 22 22:03:43 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 22 Mar 2012 22:03:43 +0100 Subject: Patch for MinGW-W64 port In-Reply-To: <83bonowfek.fsf@gnu.org> References: <584945461bb94a6da16b75e8d13f02aa@mail.face.aero.org> <4F6B72CC.8060305@gnutls.org> <83bonowfek.fsf@gnu.org> Message-ID: <4F6B93AF.4050807@gnutls.org> On 03/22/2012 09:26 PM, Eli Zaretskii wrote: > 64-bit Windows uses the LLP64 model, so `unsigned long' is a 32-bit > type. By contrast, ptrdiff_t is a (signed) 64-bit type. > >>> + $ac_cv_sizeof_long_long) >>> + AC_DEFINE([GNUTLS_POINTER_TO_INT_CAST], [(long long)], >>> + [Additional cast to bring void* to a type castable to int.]) >>> + ;; >> Why use long long for pointer to int? Isn't in this platform >> sizeof(void*)==sizeof(long)? > No, see above. On 64-bit Windows, sizeof(void *) == sizeof(long long) Ah, ok. I've applied a slightly modified version of it. regards, Nikos From scottm at aero.org Fri Mar 23 01:34:43 2012 From: scottm at aero.org (B. Scott Michel) Date: Thu, 22 Mar 2012 16:34:43 -0800 Subject: Patch for MinGW-W64 port In-Reply-To: <83bonowfek.fsf@gnu.org> References: <584945461bb94a6da16b75e8d13f02aa@mail.face.aero.org> <4F6B72CC.8060305@gnutls.org> <83bonowfek.fsf@gnu.org> Message-ID: On 22.03.2012 12:26, Eli Zaretskii wrote: >> Date: Thu, 22 Mar 2012 19:43:24 +0100 From: Nikos Mavrogiannopoulos Cc: gnutls-devel at gnu.org [2] >> >>> - gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sd); + gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) ((ptrdiff_t) sd)); >> What difference do you see with ptrdiff_t comparing to unsigned long? > > 64-bit Windows uses the LLP64 model, so `unsigned long' is a 32-bit > type. By contrast, ptrdiff_t is a (signed) 64-bit type. > >>> + $ac_cv_sizeof_long_long) + AC_DEFINE([GNUTLS_POINTER_TO_INT_CAST], [(long long)], + [Additional cast to bring void* to a type castable to int.]) + ;; >> Why use long long for pointer to int? Isn't in this platform sizeof(void*)==sizeof(long)? > > No, see above. On 64-bit Windows, sizeof(void *) == sizeof(long long) Yes, what Eli said... By definition, ptrdiff_t is the difference between two pointers, which is preferred if one is going to do pointer arithmetic, irrespective of platform word size. Hence, one benefit of the patch is increased portability, if not standards conformance. -scooter Links: ------ [1] mailto:nmav at gnutls.org [2] mailto:gnutls-devel at gnu.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From fitzsim at fitzsim.org Sat Mar 24 22:57:08 2012 From: fitzsim at fitzsim.org (Thomas Fitzsimmons) Date: Sat, 24 Mar 2012 17:57:08 -0400 Subject: gnutls-cli fails to handshake with Exchange server that uses DES-CBC3-SHA cipher Message-ID: Hi, gnutls-cli --verbose --debug 10 --port 993 "" fails to handshake with my Exchange server, whereas openssl s_client -debug -port 993 -host "" succeeds. OpenSSL reports that the server is using the DES-CBC3-SHA cipher. For background on this issue see: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10904#14 Thomas From nmav at gnutls.org Sun Mar 25 10:56:37 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 25 Mar 2012 10:56:37 +0200 Subject: gnutls-cli fails to handshake with Exchange server that uses DES-CBC3-SHA cipher In-Reply-To: References: Message-ID: <4F6EDDC5.60804@gnutls.org> On 03/24/2012 10:57 PM, Thomas Fitzsimmons wrote: > Hi, > gnutls-cli --verbose --debug 10 --port 993 "" > fails to handshake with my Exchange server, whereas > openssl s_client -debug -port 993 -host "" > succeeds. OpenSSL reports that the server is using the DES-CBC3-SHA > cipher. > For background on this issue see: > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10904#14 Hello, The comment below in the thread is very interesting. Could you send me a capture of a failed handshake? > gnutls.c: [1] Received unexpected handshake message 'CERTIFICATE' > (11). Expected 'SERVER HELLO' (2) Do priority strings like the ones below help? http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html regards, Nikos From librarian_rus at yahoo.com Mon Mar 26 01:26:20 2012 From: librarian_rus at yahoo.com (Ilya Tumaykin) Date: Mon, 26 Mar 2012 03:26:20 +0400 Subject: [GSoC 2012] Faster elliptic curve scalar multiplication project. Message-ID: <1492936.rRhKB13goU@photon> Hello everyone. I am a 4th year student of Faculty of Mechanics and Mathematics in Moscow State University and I would like to work on this project during summer. I am studying at department of mathematics and my field of interests is algebraic and number coding theory, so I have a good general theoretical background. However, I am not very familiar with elliptic curves, but I am a devoted person and willing to improve my knowledge about this subject. I have a strong C knowledge and long-time experience with it. Currently, I am working on C(+GMP) implementation of discrete logarithm solver at my university. My part in this project is almost done, thus it won't interfere with my work for GSoC. I am also an experienced Linux user for several years. This includes that working with git is not something fearful. So, I would like to take over this task to improve one of the most widely used libraries and also improve my general knowledge in elliptic curves area. -- Best regards. Ilya Tumaykin. From fitzsim at fitzsim.org Tue Mar 27 00:13:28 2012 From: fitzsim at fitzsim.org (Thomas Fitzsimmons) Date: Mon, 26 Mar 2012 18:13:28 -0400 Subject: gnutls-cli fails to handshake with Exchange server that uses DES-CBC3-SHA cipher In-Reply-To: <4F6EDDC5.60804@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 25 Mar 2012 10:56:37 +0200") References: <4F6EDDC5.60804@gnutls.org> Message-ID: Nikos Mavrogiannopoulos writes: > On 03/24/2012 10:57 PM, Thomas Fitzsimmons wrote: > >> Hi, >> gnutls-cli --verbose --debug 10 --port 993 "" >> fails to handshake with my Exchange server, whereas >> openssl s_client -debug -port 993 -host "" >> succeeds. OpenSSL reports that the server is using the DES-CBC3-SHA >> cipher. >> For background on this issue see: >> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10904#14 > > > Hello, > The comment below in the thread is very interesting. Could you send me > a capture of a failed handshake? > >> gnutls.c: [1] Received unexpected handshake message 'CERTIFICATE' >> (11). Expected 'SERVER HELLO' (2) Yes, attached the redacted output of: ./gnutls-cli --debug 10 --verbose --port 993 from gnutls HEAD. > Do priority strings like the ones below help? > http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html Also attached the redacted output after adding: 1. --priority "NORMAL:%COMPAT" 2. --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-SSL3.0:%COMPAT" 3. --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-SSL3.0:-CIPHER-ALL:+ARCFOUR-128:%COMPAT" The third priority setting works by using ARCFOUR-128. Thomas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: default-options.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: priority-options-1.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: priority-options-2.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: priority-options-3.txt URL: From jlloyd at silvertailsystems.com Tue Mar 27 02:11:35 2012 From: jlloyd at silvertailsystems.com (Jim Lloyd) Date: Mon, 26 Mar 2012 17:11:35 -0700 Subject: Features removed from gnutlsxx Message-ID: Hello, I'm in the process of upgrading an application previously used 2.8.5 to 2.12.x in order to take advantage of PKCS11 support added in gnutls 2.12.0. I notice that sometime between 2.8.5 and 2.12.18 that several previously implemented methods in gnutlsxx now throw unimplemented exceptions. For example: void session::set_cipher_priority (const int *list) { RETWRAP (GNUTLS_E_UNIMPLEMENTED_FEATURE); } which previously was implemented as: void session::set_cipher_priority (const int *list) { RETWRAP( gnutls_cipher_set_priority( s, list)); } Is there any documentation for why support for these features were removed from gnutlsxx? Or perhaps there is a way to enable them via a configuration option? Thanks, Jim Lloyd -------------- next part -------------- An HTML attachment was scrubbed... URL: From librarian_rus at yahoo.com Tue Mar 27 12:07:30 2012 From: librarian_rus at yahoo.com (Ilya Tumaykin) Date: Tue, 27 Mar 2012 14:07:30 +0400 Subject: [GSoC 2012] Faster elliptic curve scalar multiplication project. In-Reply-To: <1492936.rRhKB13goU@photon> References: <1492936.rRhKB13goU@photon> Message-ID: <5629117.yVxUNfCt26@photon> Should I provide any additional info or do some extra actions to make my proposal approved? On Monday 26 March 2012 03:26:20 you wrote: > Hello everyone. > > I am a 4th year student of Faculty of Mechanics and Mathematics in Moscow > State University and I would like to work on this project during summer. I > am studying at department of mathematics and my field of interests is > algebraic and number coding theory, so I have a good general theoretical > background. However, I am not very familiar with elliptic curves, but I am > a devoted person and willing to improve my knowledge about this subject. > > I have a strong C knowledge and long-time experience with it. Currently, I > am working on C(+GMP) implementation of discrete logarithm solver at my > university. My part in this project is almost done, thus it won't interfere > with my work for GSoC. I am also an experienced Linux user for several > years. This includes that working with git is not something fearful. > > So, I would like to take over this task to improve one of the most widely > used libraries and also improve my general knowledge in elliptic curves > area. -- Best regards. Ilya Tumaykin. From nmav at gnutls.org Tue Mar 27 14:10:30 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 27 Mar 2012 14:10:30 +0200 Subject: [GSoC 2012] Faster elliptic curve scalar multiplication project. In-Reply-To: <5629117.yVxUNfCt26@photon> References: <1492936.rRhKB13goU@photon> <5629117.yVxUNfCt26@photon> Message-ID: Hello Ilya, I believe your qualifications are enough to complete this project. However I'd suggest that you see the methods to be implemented (there is a link on the gnutls soc page) and the code to be replaced at [0] and ask any questions you might have. You are more able than me to decide whether this seems doable for you. You also need to apply through the google soc site, and if possible could you send me some code that you've worked on? As for introduction to elliptic curves there are many for non-mathematicians but many things don't make sense if you are one. If you had some course on projective geometry many things will be more clear to you (like points at infinity). Since you are in a mathematics department your library might have some good introductory books. However, you don't really need to understand all details to implement such algorithms, and for the curves used in TLS the wikipedia introduction might be just ok (think of it as curves where you a define a geometric law for addition under which they form a group, and on this group you do Diffie-Hellman). [0]. http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/nettle/ecc_mulmod.c;hb=HEAD regards, Nikos PS. I'm on a place where I don't have good internet connection and I might be unresponsive this week. On Tue, Mar 27, 2012 at 12:07 PM, Ilya Tumaykin wrote: > Should I provide any additional info or do some extra actions to make my > proposal approved? > > On Monday 26 March 2012 03:26:20 you wrote: >> Hello everyone. >> >> I am a 4th year student of Faculty of Mechanics and Mathematics in Moscow >> State University and I would like to work on this project during summer. I >> am studying at department of mathematics and my field of interests is >> algebraic and number coding theory, so I have a good general theoretical >> background. However, I am not very familiar with elliptic curves, but I am >> a devoted person and willing to improve my knowledge about this subject. >> >> I have a strong C knowledge and long-time experience with it. Currently, I >> am working on C(+GMP) implementation of discrete logarithm solver at my >> university. My part in this project is almost done, thus it won't interfere >> with my work for GSoC. I am also an experienced Linux user for several >> years. This includes that working with git is not something fearful. >> >> So, I would like to take over this task to improve one of the most widely >> used libraries and also improve my general knowledge in elliptic curves >> area. > -- > Best regards. > Ilya Tumaykin. From nmav at gnutls.org Tue Mar 27 14:21:58 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 27 Mar 2012 14:21:58 +0200 Subject: Features removed from gnutlsxx In-Reply-To: References: Message-ID: Hello, Unfortunately this was removed because I couldn't mix deprecated attribute with C++. You'd have to either call the deprecate function from your code, or use the gnutls_priority_set_direct(). Unfortunately the C++ interface isn't actively supported and it only supports a very small subset of gnutls' interface. I'm not sure whether shipping it is something useful for c++ projects. regards, Nikos On Tue, Mar 27, 2012 at 2:11 AM, Jim Lloyd wrote: > Hello, > > I'm in the process of upgrading an application previously used 2.8.5 to > 2.12.x in order to take advantage of PKCS11 support added in gnutls 2.12.0. > > I notice that sometime between 2.8.5 and 2.12.18 that several previously > implemented methods in gnutlsxx now throw unimplemented exceptions. For > example: > > ? void session::set_cipher_priority (const int *list) > ? { > ? ? RETWRAP (GNUTLS_E_UNIMPLEMENTED_FEATURE); > ? } > > which previously was implemented as: > > void session::set_cipher_priority (const int *list) > { > ? ? RETWRAP( gnutls_cipher_set_priority( s, list)); > } > > Is there any documentation for why support for these features were removed > from gnutlsxx? Or perhaps there is a way to enable them via a configuration > option? > > Thanks, > Jim Lloyd > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > https://lists.gnu.org/mailman/listinfo/gnutls-devel > From nmav at gnutls.org Tue Mar 27 14:27:16 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 27 Mar 2012 14:27:16 +0200 Subject: gnutls-cli fails to handshake with Exchange server that uses DES-CBC3-SHA cipher In-Reply-To: References: <4F6EDDC5.60804@gnutls.org> Message-ID: Thank you. It seems however that the server you're talking to isn't a valid TLS server. If you check the negotiation in the attached files, gnutls suggests some ciphersuites and the server decides to use one outside the suggested set. Moreover the server decided ciphersuite is an insecure one using DES-56bit. I don't know if it is configuration issue (i.e. somebody configured the server to intentionally negotiate a weak ciphersuite), or bug. In both cases I'd suggest to keep away from this server. If you cannot then just find a priority string that works for this server and use it. It is broken and there is nothing we can do in gnutls to fix it. If openssl negotiates with this server it means that it accepts weak ciphersuites, something that we don't do unless explicitly instructed. regards, Nikos On Tue, Mar 27, 2012 at 12:13 AM, Thomas Fitzsimmons wrote: > Nikos Mavrogiannopoulos writes: > >> On 03/24/2012 10:57 PM, Thomas Fitzsimmons wrote: >> >>> Hi, >>> gnutls-cli --verbose --debug 10 --port 993 "" >>> fails to handshake with my Exchange server, whereas >>> openssl s_client -debug -port 993 -host "" >>> succeeds. ?OpenSSL reports that the server is using the DES-CBC3-SHA >>> cipher. >>> For background on this issue see: >>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10904#14 >> >> >> Hello, >> ?The comment below in the thread is very interesting. Could you send me >> a capture of a failed handshake? >> >>> gnutls.c: [1] Received unexpected handshake message 'CERTIFICATE' >>> (11). Expected 'SERVER HELLO' (2) > > Yes, attached the redacted output of: > > ./gnutls-cli --debug 10 --verbose --port 993 > > from gnutls HEAD. > >> Do priority strings like the ones below help? >> http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html > > Also attached the redacted output after adding: > > 1. --priority "NORMAL:%COMPAT" > 2. --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-SSL3.0:%COMPAT" > 3. --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-SSL3.0:-CIPHER-ALL:+ARCFOUR-128:%COMPAT" > > The third priority setting works by using ARCFOUR-128. > > Thomas From mrsam at courier-mta.com Tue Mar 27 14:37:16 2012 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 27 Mar 2012 08:37:16 -0400 Subject: Features removed from gnutlsxx References: Message-ID: Nikos Mavrogiannopoulos writes: > Hello, > Unfortunately this was removed because I couldn't mix deprecated > attribute with C++. You'd have to either call the deprecate function > from your code, or use the gnutls_priority_set_direct(). Unfortunately > the C++ interface isn't actively supported and it only supports a very > small subset of gnutls' interface. I'm not sure whether shipping it is > something useful for c++ projects. FWIW, I've implemented my own C++ classes for gnutls. The gnutls C API is very accommodating to be turned into an application- specific C++ class hierarchy. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From nmav at gnutls.org Tue Mar 27 15:16:35 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 27 Mar 2012 15:16:35 +0200 Subject: Features removed from gnutlsxx In-Reply-To: References: Message-ID: On Tue, Mar 27, 2012 at 2:37 PM, Sam Varshavchik wrote: >> ?Unfortunately this was removed because I couldn't mix deprecated >> attribute with C++. You'd have to either call the deprecate function >> from your code, or use the gnutls_priority_set_direct(). Unfortunately >> the C++ interface isn't actively supported and it only supports a very >> small subset of gnutls' interface. I'm not sure whether shipping it is >> something useful for c++ projects. > FWIW, I've implemented my own C++ classes for gnutls. Would you be interested in submitting as a replacement of the current c++ api? regards, Nikos From jlloyd at silvertailsystems.com Tue Mar 27 20:01:44 2012 From: jlloyd at silvertailsystems.com (Jim Lloyd) Date: Tue, 27 Mar 2012 11:01:44 -0700 Subject: Features removed from gnutlsxx In-Reply-To: References: Message-ID: Nikos, can you provide a little more background information on these changes? Which interfaces were deprecated? In what release(s) did the deprecations happen? Was there any kind of document(s) produced at the time that described the reason(s) for the deprecations and the recommended approaches for updating applications that relied on the deprecated interfaces? I'm also curious about the differences between the recent versions of 2.x versus 3.x. Normally interface changes would dictate that the major version number be incremented. I assume that 3.x has even more interface changes than the ones I am running into with 2.12. But I wonder if the additional changes are minor enough that perhaps I would be better off making the jump all the way to 3.x? Thanks, Jim Lloyd On Tue, Mar 27, 2012 at 5:21 AM, Nikos Mavrogiannopoulos wrote: > Hello, > Unfortunately this was removed because I couldn't mix deprecated > attribute with C++. You'd have to either call the deprecate function > from your code, or use the gnutls_priority_set_direct(). Unfortunately > the C++ interface isn't actively supported and it only supports a very > small subset of gnutls' interface. I'm not sure whether shipping it is > something useful for c++ projects. > > regards, > Nikos > > On Tue, Mar 27, 2012 at 2:11 AM, Jim Lloyd > wrote: > > Hello, > > > > I'm in the process of upgrading an application previously used 2.8.5 to > > 2.12.x in order to take advantage of PKCS11 support added in gnutls > 2.12.0. > > > > I notice that sometime between 2.8.5 and 2.12.18 that several previously > > implemented methods in gnutlsxx now throw unimplemented exceptions. For > > example: > > > > void session::set_cipher_priority (const int *list) > > { > > RETWRAP (GNUTLS_E_UNIMPLEMENTED_FEATURE); > > } > > > > which previously was implemented as: > > > > void session::set_cipher_priority (const int *list) > > { > > RETWRAP( gnutls_cipher_set_priority( s, list)); > > } > > > > Is there any documentation for why support for these features were > removed > > from gnutlsxx? Or perhaps there is a way to enable them via a > configuration > > option? > > > > Thanks, > > Jim Lloyd > > > > > > _______________________________________________ > > Gnutls-devel mailing list > > Gnutls-devel at gnu.org > > https://lists.gnu.org/mailman/listinfo/gnutls-devel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From INVALID.NOREPLY at gnu.org Tue Mar 27 21:10:57 2012 From: INVALID.NOREPLY at gnu.org (Frederic Bezies) Date: Tue, 27 Mar 2012 19:10:57 +0000 Subject: [sr #108004] Since GnuTLS 3.0.17 upgrade, evolution 3.2.x and newer cannot synchronise with google calendar account Message-ID: <20120327-191056.sv85256.91775@savannah.gnu.org> URL: Summary: Since GnuTLS 3.0.17 upgrade, evolution 3.2.x and newer cannot synchronise with google calendar account Project: GnuTLS Submitted by: fredbezies Submitted on: mar. 27 mars 2012 19:10:56 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: Hello. On my Archlinux, I saw that since GnuTLS was upgraded to version 3.0.17, Evolution is not able to synchronise with my google calendar account. Here is the error message I get : "Unable to open the calendar: The HTTP status code returned (6) is unexpected (Error reading data connector TLS: A TLS packet with incorrect length was received.)" And in terminal, I got this error : "(evolution: 1774): e-data-server-ui-WARNING **: The keyring is unusable: no host name or user" For the first error message, I think a change in GnuTLS broke evolution synchronisation. _______________________________________________________ Reply to this item at: _______________________________________________ Message post? via/par Savannah http://savannah.gnu.org/ From jehiva at gmail.com Tue Mar 27 20:15:02 2012 From: jehiva at gmail.com (Matt Carter) Date: Tue, 27 Mar 2012 14:15:02 -0400 Subject: Error when viewing HTTPS pages with a browser using GnuTLS Message-ID: Hello, I am receiving the following error when viewing some HTTPS pages with a browser that implements GnuTLS (vimprobable2 on Arch Linux GNU/Linux distribution): Error reading data from TLS socket: A TLS packet with unexpected length was received. This error came up originally about 2 months ago, then left after a week or two in a subsequent GnuTLS update. Recently it has re-appeared in version 3.0.17. Thanks, -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrsam at courier-mta.com Tue Mar 27 23:52:24 2012 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Tue, 27 Mar 2012 17:52:24 -0400 Subject: Features removed from gnutlsxx References: Message-ID: Nikos Mavrogiannopoulos writes: > On Tue, Mar 27, 2012 at 2:37 PM, Sam Varshavchik > wrote: > > >> ?Unfortunately this was removed because I couldn't mix deprecated > >> attribute with C++. You'd have to either call the deprecate function > >> from your code, or use the gnutls_priority_set_direct(). Unfortunately > >> the C++ interface isn't actively supported and it only supports a very > >> small subset of gnutls' interface. I'm not sure whether shipping it is > >> something useful for c++ projects. > > FWIW, I've implemented my own C++ classes for gnutls. > > Would you be interested in submitting as a replacement of the current c++ > api? I do intend to release the code at some point later, hopefully this year. but it's a part of a larger collection C++ classes and uses a common foundation, so it'll work better as a standalone library. Also, some classes are Linux-centric, such as the API for the Linux kernel's event file descriptors; also timer and signal file descriptors. It's not something that's amenable to getting carved out; the gnutls classes are not at the bottom of the class hierarchy, but inherit some shared stuff. It's nice and fun writing library code, but writing a usable application or a tool is really the only way to prove that a library is actually practical. So, I need to write something useful, first? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Mar 28 04:25:49 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 27 Mar 2012 22:25:49 -0400 Subject: Error when viewing HTTPS pages with a browser using GnuTLS In-Reply-To: References: Message-ID: <4F7276AD.1070401@fifthhorseman.net> On 03/27/2012 02:15 PM, Matt Carter wrote: > I am receiving the following error when viewing some HTTPS pages with a > browser that implements GnuTLS (vimprobable2 on Arch Linux GNU/Linux > distribution): > > Error reading data from TLS socket: A TLS packet with unexpected length was > received. > > This error came up originally about 2 months ago, then left after a week or > two in a subsequent GnuTLS update. Recently it has re-appeared in version > 3.0.17. Thanks for the report. Are these failures consistent with any particular web servers? If the web server in question that is causing the error is on the public internet, could you identify it specifically? Barring that, could you try running gnutls-cli to get more detailed debugging output? Do you know what priority string vimprobable2 is using with GnuTLS? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Wed Mar 28 09:41:38 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 28 Mar 2012 09:41:38 +0200 Subject: Features removed from gnutlsxx In-Reply-To: References: Message-ID: Hello, The deprecated symbols (for C) were listed in the 2.12.0 announcement [0]. The changes in 3.0.x API aren't much. It mainly removes the deprecated since 2.12.x functions. The main channges are in the manual [1]. [0]. http://permalink.gmane.org/gmane.network.gnutls.general/2286 [1]. http://www.gnu.org/software/gnutls/manual/gnutls.html#Upgrading-from-previous-versions regards, Nikos On Tue, Mar 27, 2012 at 8:01 PM, Jim Lloyd wrote: > Nikos, can you provide a little more background information on these > changes? Which interfaces were deprecated? In what release(s) did the > deprecations happen? Was there any kind of document(s) produced at the time > that described the reason(s) for the deprecations and the recommended > approaches for updating applications that relied on the deprecated > interfaces? > > I'm also curious about the differences between the recent versions of 2.x > versus 3.x. Normally interface changes would dictate that the major version > number be incremented. I assume that 3.x has even more interface changes > than the ones I am running into with 2.12. But I wonder if the additional > changes are minor enough that perhaps I would be better off making the jump > all the way to 3.x? > > Thanks, > Jim Lloyd > > > On Tue, Mar 27, 2012 at 5:21 AM, Nikos Mavrogiannopoulos > wrote: >> >> Hello, >> ?Unfortunately this was removed because I couldn't mix deprecated >> attribute with C++. You'd have to either call the deprecate function >> from your code, or use the gnutls_priority_set_direct(). Unfortunately >> the C++ interface isn't actively supported and it only supports a very >> small subset of gnutls' interface. I'm not sure whether shipping it is >> something useful for c++ projects. >> >> regards, >> Nikos >> >> On Tue, Mar 27, 2012 at 2:11 AM, Jim Lloyd >> wrote: >> > Hello, >> > >> > I'm in the process of upgrading an application previously used 2.8.5 to >> > 2.12.x in order to take advantage of PKCS11 support added in gnutls >> > 2.12.0. >> > >> > I notice that sometime between 2.8.5 and 2.12.18 that several previously >> > implemented methods in gnutlsxx now throw unimplemented exceptions. For >> > example: >> > >> > ? void session::set_cipher_priority (const int *list) >> > ? { >> > ? ? RETWRAP (GNUTLS_E_UNIMPLEMENTED_FEATURE); >> > ? } >> > >> > which previously was implemented as: >> > >> > void session::set_cipher_priority (const int *list) >> > { >> > ? ? RETWRAP( gnutls_cipher_set_priority( s, list)); >> > } >> > >> > Is there any documentation for why support for these features were >> > removed >> > from gnutlsxx? Or perhaps there is a way to enable them via a >> > configuration >> > option? >> > >> > Thanks, >> > Jim Lloyd >> > >> > >> > _______________________________________________ >> > Gnutls-devel mailing list >> > Gnutls-devel at gnu.org >> > https://lists.gnu.org/mailman/listinfo/gnutls-devel >> > > > From nmav at gnutls.org Wed Mar 28 09:44:24 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 28 Mar 2012 09:44:24 +0200 Subject: Features removed from gnutlsxx In-Reply-To: References: Message-ID: On Tue, Mar 27, 2012 at 11:52 PM, Sam Varshavchik wrote: > I do intend to release the code at some point later, hopefully this year. > but it's a part of a larger collection C++ classes and uses a common > foundation, so it'll work better as a standalone library. Also, some classes > are Linux-centric, such as the API for the Linux kernel's event file > descriptors; also timer and signal file descriptors. It's not something > that's amenable to getting carved out; the gnutls classes are not at the > bottom of the class hierarchy, but inherit some shared stuff. Ok maybe we can link to that library then instead of providing one. Please keep me posted. regards, Nikos From INVALID.NOREPLY at gnu.org Wed Mar 28 10:13:23 2012 From: INVALID.NOREPLY at gnu.org (Frederic Bezies) Date: Wed, 28 Mar 2012 08:13:23 +0000 Subject: [sr #108004] Since GnuTLS 3.0.17 upgrade, evolution 3.2.x and newer cannot synchronise with google calendar account In-Reply-To: <20120328-074702.sv0.71531@savannah.gnu.org> References: <20120327-191056.sv85256.91775@savannah.gnu.org> <20120328-074702.sv0.71531@savannah.gnu.org> Message-ID: <20120328-081323.sv85256.47512@savannah.gnu.org> Follow-up Comment #2, sr #108004 (project gnutls): No problem. Just tell me how to make this capture and I will to do asap. I'm not a big friend of wireshark :( _______________________________________________________ Reply to this item at: _______________________________________________ Message post? via/par Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Mar 28 11:07:54 2012 From: INVALID.NOREPLY at gnu.org (Frederic Bezies) Date: Wed, 28 Mar 2012 09:07:54 +0000 Subject: [sr #108004] Since GnuTLS 3.0.17 upgrade, evolution 3.2.x and newer cannot synchronise with google calendar account In-Reply-To: <20120328-082128.sv0.54490@savannah.gnu.org> References: <20120327-191056.sv85256.91775@savannah.gnu.org> <20120328-074702.sv0.71531@savannah.gnu.org> <20120328-081323.sv85256.47512@savannah.gnu.org> <20120328-082128.sv0.54490@savannah.gnu.org> Message-ID: <20120328-090754.sv85256.78849@savannah.gnu.org> Additional Item Attachment, sr #108004 (project gnutls): File name: dump Size:6 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From jehiva at gmail.com Wed Mar 28 15:17:25 2012 From: jehiva at gmail.com (Matthew Carter) Date: Wed, 28 Mar 2012 09:17:25 -0400 Subject: Error when viewing HTTPS pages with a browser using GnuTLS In-Reply-To: <4F7276AD.1070401@fifthhorseman.net> References: <4F7276AD.1070401@fifthhorseman.net> Message-ID: <20120328131723.GA16344@gmail.com> Hi Daniel, Thanks for the reply. You can see an occurrence of the first error at: https://time.techni-serve.com you can also see a similar error ("SSL Handshake Failed") via: https://www.microsoft.com The failure is consistent with both the vimprobable2 browser and using the gnutls-cli to connect (same error message in output in both cases). I would guess it is an IIS issue as both sites are running IIS 6.0. Thanks, -Matt On Tue, Mar 27, 2012 at 10:25:49PM -0400, Daniel Kahn Gillmor wrote: > On 03/27/2012 02:15 PM, Matt Carter wrote: > > I am receiving the following error when viewing some HTTPS pages with a > > browser that implements GnuTLS (vimprobable2 on Arch Linux GNU/Linux > > distribution): > > > > Error reading data from TLS socket: A TLS packet with unexpected length was > > received. > > > > This error came up originally about 2 months ago, then left after a week or > > two in a subsequent GnuTLS update. Recently it has re-appeared in version > > 3.0.17. > > Thanks for the report. Are these failures consistent with any > particular web servers? If the web server in question that is causing > the error is on the public internet, could you identify it specifically? > > Barring that, could you try running gnutls-cli to get more detailed > debugging output? > > Do you know what priority string vimprobable2 is using with GnuTLS? > > --dkg > -- Matthew Carter jehiva at gmail.com From INVALID.NOREPLY at gnu.org Wed Mar 28 17:11:25 2012 From: INVALID.NOREPLY at gnu.org (Dan Winship) Date: Wed, 28 Mar 2012 15:11:25 +0000 Subject: [sr #108004] Since GnuTLS 3.0.17 upgrade, evolution 3.2.x and newer cannot synchronise with google calendar account In-Reply-To: <20120328-090754.sv85256.78849@savannah.gnu.org> References: <20120327-191056.sv85256.91775@savannah.gnu.org> <20120328-074702.sv0.71531@savannah.gnu.org> <20120328-081323.sv85256.47512@savannah.gnu.org> <20120328-082128.sv0.54490@savannah.gnu.org> <20120328-090754.sv85256.78849@savannah.gnu.org> Message-ID: <20120328-151125.sv73763.63696@savannah.gnu.org> Follow-up Comment #4, sr #108004 (project gnutls): What version of glib-networking do you have installed? If it's 2.28 (or rather, less than 2.29.92), then you need to upgrade that. (2.28 was never tested against gnutls 3.0, and so doesn't know about the GNUTLS_E_PREMATURE_TERMINATION error code.) _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Mar 28 17:26:42 2012 From: INVALID.NOREPLY at gnu.org (Frederic Bezies) Date: Wed, 28 Mar 2012 15:26:42 +0000 Subject: [sr #108004] Since GnuTLS 3.0.17 upgrade, evolution 3.2.x and newer cannot synchronise with google calendar account In-Reply-To: <20120328-151125.sv73763.63696@savannah.gnu.org> References: <20120327-191056.sv85256.91775@savannah.gnu.org> <20120328-074702.sv0.71531@savannah.gnu.org> <20120328-081323.sv85256.47512@savannah.gnu.org> <20120328-082128.sv0.54490@savannah.gnu.org> <20120328-090754.sv85256.78849@savannah.gnu.org> <20120328-151125.sv73763.63696@savannah.gnu.org> Message-ID: <20120328-152642.sv85256.5203@savannah.gnu.org> Follow-up Comment #5, sr #108004 (project gnutls): [fred at fredo-arch ~]$ pacman -Qi glib-networking Name : glib-networking Version : 2.30.2-1 Well, glib-networking was last updated in january 2012, gnutls in march 2012. What to do now ? _______________________________________________________ Reply to this item at: _______________________________________________ Message post? via/par Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Mar 28 21:38:27 2012 From: INVALID.NOREPLY at gnu.org (Frederic Bezies) Date: Wed, 28 Mar 2012 19:38:27 +0000 Subject: [sr #108004] Since GnuTLS 3.0.17 upgrade, evolution 3.2.x and newer cannot synchronise with google calendar account In-Reply-To: <20120328-152642.sv85256.5203@savannah.gnu.org> References: <20120327-191056.sv85256.91775@savannah.gnu.org> <20120328-074702.sv0.71531@savannah.gnu.org> <20120328-081323.sv85256.47512@savannah.gnu.org> <20120328-082128.sv0.54490@savannah.gnu.org> <20120328-090754.sv85256.78849@savannah.gnu.org> <20120328-151125.sv73763.63696@savannah.gnu.org> <20120328-152642.sv85256.5203@savannah.gnu.org> Message-ID: <20120328-193827.sv85256.57035@savannah.gnu.org> Follow-up Comment #6, sr #108004 (project gnutls): I made a wireshark dump under virtualbox. Will post a new one with my real computer, upgraded to gnome 3.4. For info, on my real computer : Name : glib-networking Version : 2.31.22-1 _______________________________________________________ Reply to this item at: _______________________________________________ Message post? via/par Savannah http://savannah.gnu.org/ From dkg at fifthhorseman.net Wed Mar 28 22:51:41 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Mar 2012 16:51:41 -0400 Subject: Error when viewing HTTPS pages with a browser using GnuTLS In-Reply-To: <20120328131723.GA16344@gmail.com> References: <4F7276AD.1070401@fifthhorseman.net> <20120328131723.GA16344@gmail.com> Message-ID: <4F7379DD.7020703@fifthhorseman.net> On 03/28/2012 09:17 AM, Matthew Carter wrote: > https://www.microsoft.com fwiw, using openssl s_client from OpenSSL 1.0.1 (the first version that implements TLS versions higher than 1.0) also fails to connect to port 443 on www.microsoft.com unless i provide -no_tls1_1 and -no_tls1_2 --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Mar 28 22:13:35 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Mar 2012 16:13:35 -0400 Subject: Error when viewing HTTPS pages with a browser using GnuTLS In-Reply-To: <20120328131723.GA16344@gmail.com> References: <4F7276AD.1070401@fifthhorseman.net> <20120328131723.GA16344@gmail.com> Message-ID: <4F7370EF.50805@fifthhorseman.net> On 03/28/2012 09:17 AM, Matthew Carter wrote: > You can see an occurrence of the first error at: > > https://time.techni-serve.com > > you can also see a similar error ("SSL Handshake Failed") via: > > https://www.microsoft.com > > The failure is consistent with both the vimprobable2 browser and using > the gnutls-cli to connect (same error message in output in both cases). Thanks! I see the same thing you do with gnutls-cli, so i can confirm this as an issue with their servers. I see those connection failures even with the priority string NORMAL:+%COMPAT :( FWIW, i can get connections to work with both of the above using the following priority string: NORMAL:-VERS-TLS1.1:-VERS-TLS1.2 That is, it looks like these two servers sending fatal alerts to any client that advertises support for TLS1.1 or TLS1.2 :( They both negotiate to TLS1.0, though. > I would guess it is an IIS issue as both sites are running IIS 6.0. https://en.wikipedia.org/wiki/Internet_Information_Services suggests that 6.0 was released with Windows Server 2003, and superceded by IIS 7.0 with the release of Windows Server 2008. I'm a little surprised to see www.microsoft.com running such an old version on their flagship web site. other MS sites (e.g. technet.microsoft.com) are using IIS 7.5 by now. I'm not sure the right way to deal with this from GnuTLS is. Should we be doing anything differently to accommodate these non-compliant servers? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From INVALID.NOREPLY at gnu.org Wed Mar 28 21:46:32 2012 From: INVALID.NOREPLY at gnu.org (Frederic Bezies) Date: Wed, 28 Mar 2012 19:46:32 +0000 Subject: [sr #108004] Since GnuTLS 3.0.17 upgrade, evolution 3.2.x and newer cannot synchronise with google calendar account In-Reply-To: <20120328-193827.sv85256.57035@savannah.gnu.org> References: <20120327-191056.sv85256.91775@savannah.gnu.org> <20120328-074702.sv0.71531@savannah.gnu.org> <20120328-081323.sv85256.47512@savannah.gnu.org> <20120328-082128.sv0.54490@savannah.gnu.org> <20120328-090754.sv85256.78849@savannah.gnu.org> <20120328-151125.sv73763.63696@savannah.gnu.org> <20120328-152642.sv85256.5203@savannah.gnu.org> <20120328-193827.sv85256.57035@savannah.gnu.org> Message-ID: <20120328-194632.sv85256.9286@savannah.gnu.org> Additional Item Attachment, sr #108004 (project gnutls): File name: dump2 Size:20 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message post? via/par Savannah http://savannah.gnu.org/ From jlloyd at silvertailsystems.com Wed Mar 28 22:23:06 2012 From: jlloyd at silvertailsystems.com (Jim Lloyd) Date: Wed, 28 Mar 2012 13:23:06 -0700 Subject: One leading NUL byte in RSA key modulus Message-ID: Hello, I am nearly done porting our application to use gnutls 2.12 instead of 2.8. We have a reasonably decent set of unit tests, nearly all of which pass without requiring any changes. However, there are two failing tests that I find curious. First, we have a function that user gnutls_x509_privkey_export_rsa_raw to return the size in bytes of the modulus of a private key. One specific unit test simply asserts that the size of a given test key is 128 bytes. That test fails because the actual size of the key is now 129 bytes. We have another test that uses gnutls_x509_crt_print to print a human readable description of a certificate. The test simply verifies the output is identical to an expected string. That test fails because the modulus now shows an additional leading 00 byte. For example: Modulus (bits 1024): 00:b5:b8:d2:04:ef:8b:ed:de:91:14:4e:6c:f5:70:da 22:f1:30:ca:48:f9:7f:b2:eb:4f:d5:cc:8d:ac:cc:37 76:ca:21:22:b1:c0:1c:74:c4:39:32:08:18:43:04:cf 92:19:72:9e:fb:a2:65:c3:97:56:81:a3:31:73:33:c9 a3:57:8d:a1:9e:6d:91:97:a9:db:e8:5c:e8:2f:c0:71 db:54:4e:01:79:e8:a7:9b:03:70:8e:db:21:8e:21:9f a9:5b:08:19:40:b2:bb:58:e5:09:94:7e:94:65:33:6d e7:f0:63:db:b2:76:a7:55:8f:2e:28:c6:e6:c6:e9:c5 85 In addition, the Public Key Id output by gnutls_x509_crt_print has changed to be an entirely different hash. If I change the expected results in these two unit tests to reflect these changes, then my all of our unit tests completely pass. Still, it seems odd to me that this behavior has changed. Is the change completely benign? What was the reason for the change? Thanks, Jim Lloyd -------------- next part -------------- An HTML attachment was scrubbed... URL: From INVALID.NOREPLY at gnu.org Thu Mar 29 11:05:48 2012 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Thu, 29 Mar 2012 09:05:48 +0000 Subject: [sr #108004] Since GnuTLS 3.0.17 upgrade, evolution 3.2.x and newer cannot synchronise with google calendar account In-Reply-To: <20120328-194632.sv85256.9286@savannah.gnu.org> References: <20120327-191056.sv85256.91775@savannah.gnu.org> <20120328-074702.sv0.71531@savannah.gnu.org> <20120328-081323.sv85256.47512@savannah.gnu.org> <20120328-082128.sv0.54490@savannah.gnu.org> <20120328-090754.sv85256.78849@savannah.gnu.org> <20120328-151125.sv73763.63696@savannah.gnu.org> <20120328-152642.sv85256.5203@savannah.gnu.org> <20120328-193827.sv85256.57035@savannah.gnu.org> <20120328-194632.sv85256.9286@savannah.gnu.org> Message-ID: <20120329-090548.sv0.97596@savannah.gnu.org> Follow-up Comment #7, sr #108004 (project gnutls): Hello it seems a fix reverted the behavior of sending GNUTLS_E_PREMATURE_TERMINATION to sending GNUTLS_E_UNEXPECTED_PACKET_LENGTH. I'll correct it on the next release and add a test case to prevent this from happening. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Mar 29 11:11:58 2012 From: INVALID.NOREPLY at gnu.org (Frederic Bezies) Date: Thu, 29 Mar 2012 09:11:58 +0000 Subject: [sr #108004] Since GnuTLS 3.0.17 upgrade, evolution 3.2.x and newer cannot synchronise with google calendar account In-Reply-To: <20120329-090548.sv0.97596@savannah.gnu.org> References: <20120327-191056.sv85256.91775@savannah.gnu.org> <20120328-074702.sv0.71531@savannah.gnu.org> <20120328-081323.sv85256.47512@savannah.gnu.org> <20120328-082128.sv0.54490@savannah.gnu.org> <20120328-090754.sv85256.78849@savannah.gnu.org> <20120328-151125.sv73763.63696@savannah.gnu.org> <20120328-152642.sv85256.5203@savannah.gnu.org> <20120328-193827.sv85256.57035@savannah.gnu.org> <20120328-194632.sv85256.9286@savannah.gnu.org> <20120329-090548.sv0.97596@savannah.gnu.org> Message-ID: <20120329-091157.sv85256.65360@savannah.gnu.org> Follow-up Comment #8, sr #108004 (project gnutls): Thanks a lot for the info. Looks like this annoying will be "dead" soon ;) _______________________________________________________ Reply to this item at: _______________________________________________ Message post? via/par Savannah http://savannah.gnu.org/ From nmav at gnutls.org Thu Mar 29 11:29:11 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 29 Mar 2012 11:29:11 +0200 Subject: One leading NUL byte in RSA key modulus In-Reply-To: References: Message-ID: On Wed, Mar 28, 2012 at 10:23 PM, Jim Lloyd wrote: > Hello, > I am nearly done porting our application to use gnutls 2.12 instead of 2.8. > We have a reasonably decent set of unit tests, nearly all of which pass > without requiring any changes. However, there are two failing tests that I > find curious. > First, we have a function that user gnutls_x509_privkey_export_rsa_raw to > return the size in bytes of the modulus of a private key. One specific unit > test simply asserts that the size of a given test key is 128 bytes. That > test fails because the actual size of the key is now 129 bytes. Hello, The null byte ensures that the number isn't treated as negative when imported to a bignum library. Thus it should be expected (at least to numbers with their MSB being 1). > In addition, the Public Key Id output by?gnutls_x509_crt_print has changed > to be an entirely different hash. Could it be the change in 2.8.6? * Version 2.8.6 (released 2010-03-15) ** libgnutls: For CSRs, don't null pad integers for RSA/DSA value. VeriSign rejected CSRs with this padding. Reported by Wilankar Trupti and Boyan Kasarov . Note: As a side effect of this change, the "public key identifier" value computed for a certificate using this version of GnuTLS will be different from values computed using earlier versions of GnuTLS. regards, Nikos From jehiva at gmail.com Thu Mar 29 06:00:28 2012 From: jehiva at gmail.com (Matthew Carter) Date: Thu, 29 Mar 2012 00:00:28 -0400 Subject: Error when viewing HTTPS pages with a browser using GnuTLS In-Reply-To: <4F7370EF.50805@fifthhorseman.net> References: <4F7276AD.1070401@fifthhorseman.net> <20120328131723.GA16344@gmail.com> <4F7370EF.50805@fifthhorseman.net> Message-ID: <20120329040027.GA24319@gmail.com> Hi all, Honestly if a fallback can be implemented in any fashion (if the negotiation hits one of these errors, it is retried with the fallback priority string) that would be best from this user's POV, as it would be a lot more practical to change on this end than getting all the vendors still running IIS 6.0 to upgrade. As it is now, my option is to use another browser to get around this, or tweak the browser's source to try to change the priority string being sent (I may have to dig into webkit/libsoup stuff at that point, since the browser uses those as the backend). Slightly related, but it looks like the Arch Linux evolution/google calendar desync issue is getting the same TLS ended unexpectedly type error; as my issue cropped up at the same time under Arch, it would seem the most recent GnuTLS update re-introduced this (the last version did not have this issue, a few versions ago did). Thanks, -Matt On Wed, Mar 28, 2012 at 04:13:35PM -0400, Daniel Kahn Gillmor wrote: > On 03/28/2012 09:17 AM, Matthew Carter wrote: > > You can see an occurrence of the first error at: > > > > https://time.techni-serve.com > > > > you can also see a similar error ("SSL Handshake Failed") via: > > > > https://www.microsoft.com > > > > The failure is consistent with both the vimprobable2 browser and using > > the gnutls-cli to connect (same error message in output in both cases). > > Thanks! I see the same thing you do with gnutls-cli, so i can confirm > this as an issue with their servers. I see those connection failures > even with the priority string NORMAL:+%COMPAT :( > > FWIW, i can get connections to work with both of the above using the > following priority string: > > NORMAL:-VERS-TLS1.1:-VERS-TLS1.2 > > That is, it looks like these two servers sending fatal alerts to any > client that advertises support for TLS1.1 or TLS1.2 :( > > They both negotiate to TLS1.0, though. > > > I would guess it is an IIS issue as both sites are running IIS 6.0. > > https://en.wikipedia.org/wiki/Internet_Information_Services suggests > that 6.0 was released with Windows Server 2003, and superceded by IIS > 7.0 with the release of Windows Server 2008. I'm a little surprised to > see www.microsoft.com running such an old version on their flagship web > site. other MS sites (e.g. technet.microsoft.com) are using IIS 7.5 by now. > > I'm not sure the right way to deal with this from GnuTLS is. Should we > be doing anything differently to accommodate these non-compliant servers? > > --dkg > -- Matthew Carter jehiva at gmail.com From marcelo.fidel.fernandez at gmail.com Thu Mar 29 06:24:51 2012 From: marcelo.fidel.fernandez at gmail.com (Marcelo Fernandez) Date: Thu, 29 Mar 2012 01:24:51 -0300 Subject: NPN - Next Protocol Negotiation support? Message-ID: Hello, Sorry if it's known to everybody in the list, but I haven't found any information about this. I'd like to know if it's planned to implement NPN - Next Protocol Negotiation Extension [1] in GnuTLS. NPN is still an IETF draft, but OpenSSL just implemented it in the last release [2], and seems to gather relevancy because it brings the possibility to use the SPDY [3][4][5] protocol. [1] http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-02 [2] http://www.openssl.org/news/announce.html [3] http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00 [4] http://en.wikipedia.org/wiki/SPDY [5] http://www.chromium.org/spdy/ Regards -- Marcelo F. Fern?ndez Buenos Aires, Argentina Lic. en Sistemas de Informaci?n E-Mail: marcelo.fidel.fernandez at gmail.com Blog: http://blog.marcelofernandez.info Twitter: http://twitter.com/fidelfernandez From nmav at gnutls.org Thu Mar 29 11:42:55 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 29 Mar 2012 11:42:55 +0200 Subject: Error when viewing HTTPS pages with a browser using GnuTLS In-Reply-To: <4F7370EF.50805@fifthhorseman.net> References: <4F7276AD.1070401@fifthhorseman.net> <20120328131723.GA16344@gmail.com> <4F7370EF.50805@fifthhorseman.net> Message-ID: On Wed, Mar 28, 2012 at 10:13 PM, Daniel Kahn Gillmor wrote: >> https://www.microsoft.com >> The failure is consistent with both the vimprobable2 browser and using >> the gnutls-cli to connect (same error message in output in both cases). > Thanks! ?I see the same thing you do with gnutls-cli, so i can confirm > this as an issue with their servers. ?I see those connection failures > even with the priority string NORMAL:+%COMPAT :( > FWIW, i can get connections to work with both of the above using the > following priority string: > ?NORMAL:-VERS-TLS1.1:-VERS-TLS1.2 Microsoft servers used to drop connections from TLS protocol versions they didn't understand instead of doing a negotiation to the highest common. A solution is, a client, to have a fallback strategy with the priority strings at: http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html > I'm not sure the right way to deal with this from GnuTLS is. ?Should we > be doing anything differently to accommodate these non-compliant servers? This is an old problem and there is not much we can do, except pointing people to compatibility priority strings. Keeping support for TLS 1.2 and 1.1 is important as there are issues in all the previous protocols. regards, Nikos From INVALID.NOREPLY at gnu.org Thu Mar 29 12:15:45 2012 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Thu, 29 Mar 2012 10:15:45 +0000 Subject: [sr #108004] Since GnuTLS 3.0.17 upgrade, evolution 3.2.x and newer cannot synchronise with google calendar account In-Reply-To: <20120329-091157.sv85256.65360@savannah.gnu.org> References: <20120327-191056.sv85256.91775@savannah.gnu.org> <20120328-074702.sv0.71531@savannah.gnu.org> <20120328-081323.sv85256.47512@savannah.gnu.org> <20120328-082128.sv0.54490@savannah.gnu.org> <20120328-090754.sv85256.78849@savannah.gnu.org> <20120328-151125.sv73763.63696@savannah.gnu.org> <20120328-152642.sv85256.5203@savannah.gnu.org> <20120328-193827.sv85256.57035@savannah.gnu.org> <20120328-194632.sv85256.9286@savannah.gnu.org> <20120329-090548.sv0.97596@savannah.gnu.org> <20120329-091157.sv85256.65360@savannah.gnu.org> Message-ID: <20120329-101545.sv0.80853@savannah.gnu.org> Additional Item Attachment, sr #108004 (project gnutls): File name: patch.txt Size:0 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From jlloyd at silvertailsystems.com Thu Mar 29 18:34:09 2012 From: jlloyd at silvertailsystems.com (Jim Lloyd) Date: Thu, 29 Mar 2012 09:34:09 -0700 Subject: One leading NUL byte in RSA key modulus In-Reply-To: References: Message-ID: Thanks Nikos, this all makes complete sense now. On Thu, Mar 29, 2012 at 2:29 AM, Nikos Mavrogiannopoulos wrote: > On Wed, Mar 28, 2012 at 10:23 PM, Jim Lloyd > wrote: > > Hello, > > I am nearly done porting our application to use gnutls 2.12 instead of > 2.8. > > We have a reasonably decent set of unit tests, nearly all of which pass > > without requiring any changes. However, there are two failing tests that > I > > find curious. > > First, we have a function that user gnutls_x509_privkey_export_rsa_raw to > > return the size in bytes of the modulus of a private key. One specific > unit > > test simply asserts that the size of a given test key is 128 bytes. That > > test fails because the actual size of the key is now 129 bytes. > > Hello, > The null byte ensures that the number isn't treated as negative when > imported to a bignum library. Thus it should be expected (at least to > numbers with their MSB being 1). > > > In addition, the Public Key Id output by gnutls_x509_crt_print has > changed > > to be an entirely different hash. > > Could it be the change in 2.8.6? > > * Version 2.8.6 (released 2010-03-15) > > ** libgnutls: For CSRs, don't null pad integers for RSA/DSA value. > VeriSign rejected CSRs with this padding. Reported by Wilankar Trupti > and Boyan Kasarov . > > Note: As a side effect of this change, the "public key identifier" > value computed for a certificate using this version of GnuTLS will be > different from values computed using earlier versions of GnuTLS. > > regards, > Nikos > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fitzsim at fitzsim.org Fri Mar 30 02:22:31 2012 From: fitzsim at fitzsim.org (Thomas Fitzsimmons) Date: Thu, 29 Mar 2012 20:22:31 -0400 Subject: gnutls-cli fails to handshake with Exchange server that uses DES-CBC3-SHA cipher In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue, 27 Mar 2012 14:27:16 +0200") References: <4F6EDDC5.60804@gnutls.org> Message-ID: Hi Nikos, Emacs allows overriding the default GnuTLS priority string using a variable (gnutls-algorithm-priority) so I set it to "performance" to work around this server-side issue. In cases where Emacs would otherwise fail to connect to a server because of a weak ciphersuite maybe the UI should warn the user and ask them whether or not to proceed. Anyway, thanks for analyzing the logs. Thomas Nikos Mavrogiannopoulos writes: > Thank you. It seems however that the server you're talking to isn't a > valid TLS server. If you check the negotiation in the attached files, > gnutls suggests some ciphersuites and the server decides to use one > outside the suggested set. Moreover the server decided ciphersuite is > an insecure one using DES-56bit. I don't know if it is configuration > issue (i.e. somebody configured the server to intentionally negotiate > a weak ciphersuite), or bug. In both cases I'd suggest to keep away > from this server. If you cannot then just find a priority string that > works for this server and use it. It is broken and there is nothing we > can do in gnutls to fix it. > > If openssl negotiates with this server it means that it accepts weak > ciphersuites, something that we don't do unless explicitly instructed. > > regards, > Nikos > > On Tue, Mar 27, 2012 at 12:13 AM, Thomas Fitzsimmons > wrote: >> Nikos Mavrogiannopoulos writes: >> >>> On 03/24/2012 10:57 PM, Thomas Fitzsimmons wrote: >>> >>>> Hi, >>>> gnutls-cli --verbose --debug 10 --port 993 "" >>>> fails to handshake with my Exchange server, whereas >>>> openssl s_client -debug -port 993 -host "" >>>> succeeds. ?OpenSSL reports that the server is using the DES-CBC3-SHA >>>> cipher. >>>> For background on this issue see: >>>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10904#14 >>> >>> >>> Hello, >>> ?The comment below in the thread is very interesting. Could you send me >>> a capture of a failed handshake? >>> >>>> gnutls.c: [1] Received unexpected handshake message 'CERTIFICATE' >>>> (11). Expected 'SERVER HELLO' (2) >> >> Yes, attached the redacted output of: >> >> ./gnutls-cli --debug 10 --verbose --port 993 >> >> from gnutls HEAD. >> >>> Do priority strings like the ones below help? >>> http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html >> >> Also attached the redacted output after adding: >> >> 1. --priority "NORMAL:%COMPAT" >> 2. --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-SSL3.0:%COMPAT" >> 3. --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:+VERS-SSL3.0:-CIPHER-ALL:+ARCFOUR-128:%COMPAT" >> >> The third priority setting works by using ARCFOUR-128. >> >> Thomas From tzz at lifelogs.com Fri Mar 30 14:02:27 2012 From: tzz at lifelogs.com (Ted Zlatanov) Date: Fri, 30 Mar 2012 08:02:27 -0400 Subject: gnutls-cli fails to handshake with Exchange server that uses DES-CBC3-SHA cipher References: <4F6EDDC5.60804@gnutls.org> Message-ID: <87limiwb3g.fsf@lifelogs.com> On Thu, 29 Mar 2012 20:22:31 -0400 Thomas Fitzsimmons wrote: TF> Emacs allows overriding the default GnuTLS priority string using a TF> variable (gnutls-algorithm-priority) so I set it to "performance" to TF> work around this server-side issue. In cases where Emacs would TF> otherwise fail to connect to a server because of a weak ciphersuite TF> maybe the UI should warn the user and ask them whether or not to TF> proceed. Anyway, thanks for analyzing the logs. I don't think currently Emacs can distinguish this case from a normal negotiation failure. The best we can do is to generally suggest a weaker priority string, which seems to be a bad idea. Is there a way to determine that this case has occurred? Ted From zoubeir.elguesmi at gmail.com Fri Mar 30 11:26:33 2012 From: zoubeir.elguesmi at gmail.com (zoubeir elguesmi) Date: Fri, 30 Mar 2012 10:26:33 +0100 Subject: make check report Message-ID: Hello, below the report of make check command in ubuntu 8.04 *FAIL: resume =================================== 8 of 15 tests failed Please report to bug-gnutls at gnu.org =================================== make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/gnutls-2.0.4/tests' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/gnutls-2.0.4/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/gnutls-2.0.4/tests' make: *** [check-recursive] Error 1* regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From insiderboy at gmail.com Sat Mar 31 03:20:14 2012 From: insiderboy at gmail.com (Chatsiri Ratana) Date: Sat, 31 Mar 2012 08:20:14 +0700 Subject: Autoreconf show error when build gnutls-devel by make bootstrap command line. Message-ID: Hello all, I try build source gnutls-devel for libvirt, but it's show error as below : $make bootstrap rm -f m4/codeset.m4 m4/gettext.m4 m4/glibc21.m4 m4/glibc2.m4 m4/iconv.m4 m4/intdiv0.m4 m4/intldir.m4 m4/intl.m4 m4/intlmacosx.m4 m4/intmax.m4 m4/inttypes_h.m4 m4/inttypes-pri.m4 m4/lcmessage.m4 m4/lib-ld.m4 m4/lib-link.m4 m4/lib-prefix.m4 m4/lock.m4 m4/longlong.m4 m4/nls.m4 m4/po.m4 m4/printf-posix.m4 m4/progtest.m4 m4/size_max.m4 m4/stdint_h.m4 m4/uintmax_t.m4 m4/wchar_t.m4 m4/wint_t.m4 m4/visibility.m4 m4/xsize.m4 touch ChangeLog test -f ./configure || AUTOPOINT=true autoreconf --install Usage: autoreconf [-f] [-h] [--help] [-m dir] [--macrodir=dir] [-l dir] [--localdir=dir] [--force] [--verbose] [--version] make: *** [autoreconf] Error 1 I using autoreconf version 2.11 build gnutls. Best Regards, Chatsiri Rattana. -- :-------------------------------------------------------- http://about.me/chatsiri.ratana -------------- next part -------------- An HTML attachment was scrubbed... URL: From ametzler at downhill.at.eu.org Sat Mar 31 16:41:45 2012 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 31 Mar 2012 16:41:45 +0200 Subject: Autoreconf show error when build gnutls-devel by make bootstrap command line. In-Reply-To: References: Message-ID: <20120331144145.GC1919@downhill.g.la> On 2012-03-31 Chatsiri Ratana wrote: [...] > I using autoreconf version 2.11 build gnutls. That is an *ancient* version (1996), isn't it? cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Sat Mar 31 19:32:16 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 31 Mar 2012 19:32:16 +0200 Subject: gnutls-cli fails to handshake with Exchange server that uses DES-CBC3-SHA cipher In-Reply-To: <87limiwb3g.fsf@lifelogs.com> References: <4F6EDDC5.60804@gnutls.org> <87limiwb3g.fsf@lifelogs.com> Message-ID: <4F773FA0.6040703@gnutls.org> On 03/30/2012 02:02 PM, Ted Zlatanov wrote: > On Thu, 29 Mar 2012 20:22:31 -0400 Thomas Fitzsimmons wrote: > > TF> Emacs allows overriding the default GnuTLS priority string using a > TF> variable (gnutls-algorithm-priority) so I set it to "performance" to > TF> work around this server-side issue. In cases where Emacs would > TF> otherwise fail to connect to a server because of a weak ciphersuite > TF> maybe the UI should warn the user and ask them whether or not to > TF> proceed. Anyway, thanks for analyzing the logs. > I don't think currently Emacs can distinguish this case from a normal > negotiation failure. The best we can do is to generally suggest a > weaker priority string, which seems to be a bad idea. Is there a way to > determine that this case has occurred? You cannot in general distinguish a negotiation with a broken server and negotiation failure. What (I think) browsers do is if negotiation fails they fallback to the most compatible mode (SSL 3.0 or so). regards, Nikos From nmav at gnutls.org Sat Mar 31 20:22:04 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 31 Mar 2012 20:22:04 +0200 Subject: make check report In-Reply-To: References: Message-ID: <4F774B4C.9020307@gnutls.org> On 03/30/2012 11:26 AM, zoubeir elguesmi wrote: > Hello, > > below the report of make check command in ubuntu 8.04 > *FAIL: resume > =================================== > 8 of 15 tests failed > Please report to bug-gnutls at gnu.org > =================================== > make[3]: *** [check-TESTS] Error 1 > make[3]: Leaving directory `/gnutls-2.0.4/tests' > make[2]: *** [check-am] Error 2 Hello, GnuTLS 2.0.4 is very old and unsupported. Please use 2.12.x or the latest which is 3.0.x. regards, Nikos From nmav at gnutls.org Sat Mar 31 20:48:50 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 31 Mar 2012 20:48:50 +0200 Subject: NPN - Next Protocol Negotiation support? In-Reply-To: References: Message-ID: <4F775192.2080107@gnutls.org> On 03/29/2012 06:24 AM, Marcelo Fernandez wrote: > Hello, > > Sorry if it's known to everybody in the list, but I haven't found any > information about this. > I'd like to know if it's planned to implement NPN - Next Protocol > Negotiation Extension [1] in GnuTLS. Hello, The draft [1] that you mention isn't complete, it doesn't have any extension numbers assigned by IANA and some fields such as padding aren't defined anywhere. That way it is not possible to implement in an interoperable way. If you depend on this draft I'd suggest to contact the authors to update the current version with a version that can be used to create interoperable implementations. It is not currently in my todo list but looks pretty trivial to implement once a complete version is available. regards, Nikos