From INVALID.NOREPLY at gnu.org Mon Nov 1 13:02:20 2010 From: INVALID.NOREPLY at gnu.org (Tomas Hoger) Date: Mon, 01 Nov 2010 12:02:20 +0000 Subject: [sr #107508] gnutls: commit 41467217 missing in master In-Reply-To: <20101031-210709.sv73003.67650@savannah.gnu.org> References: <20101031-210709.sv73003.67650@savannah.gnu.org> Message-ID: <20101101-120220.sv73003.93937@savannah.gnu.org> Follow-up Comment #1, sr #107508 (project gnutls): Other 2.10.x commits not in 2.11.x/master that I've noticed: - 8a39da8c - internal-only member naming inconsistency issue - 22a2a8b5+5ea6b5a9 - minor doc fixes, now belong to cha-intro-tls.texi _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Nov 1 13:26:57 2010 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 01 Nov 2010 12:26:57 +0000 Subject: [sr #107508] gnutls: commit 41467217 missing in master In-Reply-To: <20101101-120220.sv73003.93937@savannah.gnu.org> References: <20101031-210709.sv73003.67650@savannah.gnu.org> <20101101-120220.sv73003.93937@savannah.gnu.org> Message-ID: <20101101-142657.sv707.97877@savannah.gnu.org> Update of sr #107508 (project gnutls): Status: None => Done Open/Closed: Open => Closed _______________________________________________________ Follow-up Comment #2: Thank you for noticing and notifying us. I've applied a fix. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Nov 1 13:27:17 2010 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 01 Nov 2010 12:27:17 +0000 Subject: [sr #107495] gnutls_bye() blocks on network issues In-Reply-To: <20101015-085126.sv0.70026@savannah.gnu.org> References: <20101015-074016.sv0.24620@savannah.gnu.org> <20101015-075653.sv7213.62214@savannah.gnu.org> <20101015-080735.sv0.85090@savannah.gnu.org> <20101015-081241.sv0.8744@savannah.gnu.org> <20101015-082603.sv0.78492@savannah.gnu.org> <20101015-084637.sv46754.6180@savannah.gnu.org> <20101015-085126.sv0.70026@savannah.gnu.org> Message-ID: <20101101-142717.sv707.38872@savannah.gnu.org> Update of sr #107495 (project gnutls): Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Nov 11 23:01:57 2010 From: INVALID.NOREPLY at gnu.org (Nicolas Kaiser) Date: Thu, 11 Nov 2010 22:01:57 +0000 Subject: [sr #107513] [PATCH] lib/gnutls_x509.c: remove redundant check Message-ID: <20101111-220156.sv40933.98456@savannah.gnu.org> URL: Summary: [PATCH] lib/gnutls_x509.c: remove redundant check Project: GnuTLS Submitted by: nikai Submitted on: Thu 11 Nov 2010 10:01:56 PM GMT Category: None Priority: 5 - Normal Severity: 2 - Minor Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: Hi there! I noticed a stray return value check, left over from git commit f780425c751c6e31d26985e629d1abf3886168d3. Best regards, Nicolas Kaiser --- lib/gnutls_x509.c | 8 -------- 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/lib/gnutls_x509.c b/lib/gnutls_x509.c index 802a81d..1ea19e3 100644 --- a/lib/gnutls_x509.c +++ b/lib/gnutls_x509.c @@ -160,14 +160,6 @@ _gnutls_x509_cert_verify_peers (gnutls_session_t session, return ret; } - - if (ret < 0) - { - gnutls_assert (); - CLEAR_CERTS; - return ret; - } - ret = check_bits (peer_certificate_list[i], cred->verify_bits); if (ret < 0) { -- 1.7.2.2 _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Thu 11 Nov 2010 10:01:56 PM GMT Name: 0001-gnutls_x509.c-remove-redundant-check.patch Size: 794B By: nikai patch _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nephi.allred at gmail.com Thu Nov 11 20:52:46 2010 From: nephi.allred at gmail.com (Nephi Allred) Date: Thu, 11 Nov 2010 12:52:46 -0700 Subject: error in TLS 1.2 implementation Message-ID: I believe that there is an error in gnutls's implementation of TLS 1.2, specifically in the PRF. The spec (RFC 5246) section 5 (page 13) states that all cipher suites in TLS 1.2 use P_SHA256 as the PRF. However, gnutls uses P_hash where hash is the MAC hash algorithm for the cipher suite. So for example when the cipher suite is TLS_RSA_WITH_AES_128_CBC_SHA then gnutls uses P_SHA1 as the PRF. This goes against the spec, or am I missing something? From INVALID.NOREPLY at gnu.org Thu Nov 11 23:58:08 2010 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Nov 2010 22:58:08 +0000 Subject: [sr #107513] [PATCH] lib/gnutls_x509.c: remove redundant check In-Reply-To: <20101111-220156.sv40933.98456@savannah.gnu.org> References: <20101111-220156.sv40933.98456@savannah.gnu.org> Message-ID: <20101112-005808.sv707.91444@savannah.gnu.org> Update of sr #107513 (project gnutls): Status: None => Done Assigned to: None => nmav _______________________________________________________ Follow-up Comment #1: I've just commited a fix. Thanks! _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Fri Nov 12 00:01:23 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 12 Nov 2010 00:01:23 +0100 Subject: error in TLS 1.2 implementation In-Reply-To: References: Message-ID: <4CDC75C3.5050906@gnutls.org> On 11/11/2010 08:52 PM, Nephi Allred wrote: > I believe that there is an error in gnutls's implementation of TLS > 1.2, specifically in the PRF. > The spec (RFC 5246) section 5 (page 13) states that all cipher suites > in TLS 1.2 use P_SHA256 as the PRF. However, gnutls uses P_hash where > hash is the MAC hash algorithm for the cipher suite. So for example > when the cipher suite is TLS_RSA_WITH_AES_128_CBC_SHA then gnutls uses > P_SHA1 as the PRF. This goes against the spec, or am I missing > something? Which version of gnutls do you use? TLS 1.2 is fully supported on 2.10.0 and later versions. What you say shouldn't occur in those versions. regards, Nikos From INVALID.NOREPLY at gnu.org Tue Nov 16 10:12:57 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Tue, 16 Nov 2010 09:12:57 +0000 Subject: [sr #107518] GnuTLS: After DSA Key Generation, 2 Integers were Encoded Incorrectly Message-ID: <20101116-091256.sv80862.53045@savannah.gnu.org> URL: Summary: GnuTLS: After DSA Key Generation, 2 Integers were Encoded Incorrectly Project: GnuTLS Submitted by: noloader Submitted on: Tue 16 Nov 2010 09:12:56 AM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: Seems to be missing a couple of leading 00 octets... =================================================== $ certtool --dsa --generate-privkey --pkcs8 --outder --bits 1024 --outfile dsa-gnutls.der Generating a 1024 bit DSA private key... Enter password: Confirm password: jeffrey at studio:~/Desktop/gnutls$ dumpasn1 dsa-gnutls.der 0 328: SEQUENCE { 4 1: INTEGER 0 7 297: SEQUENCE { 11 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) 20 284: SEQUENCE { 24 128: INTEGER : 9B FE 7E 3B E8 09 8A 09 A4 4A E7 68 6B 88 BC 09 : EC 73 00 2A D8 56 03 B2 3A 1C 2C 04 26 DE 21 5C : 4E D6 A8 3B 3F DE 28 B2 F4 47 2C 7C 50 D2 5F A9 : B6 0E 69 05 48 39 E2 27 F5 9E 32 25 42 1C 99 EC : 18 D6 D0 A3 66 95 18 4B B0 CB 16 69 EE C4 C4 9B : B6 A0 61 02 6A 39 77 BE 77 10 4F FF E9 3F 6D E3 : 5F 6F 66 E9 B4 E2 C2 5E 8B C4 1E 7D 44 08 27 78 : 74 CC A3 93 79 06 27 0D 71 F7 34 A7 58 C2 22 57 : Error: Integer has a negative value. 155 20: INTEGER : E8 93 3C 19 61 B1 38 5B B7 43 0A DE CB 9A F3 3A : 38 AD 46 BD : Error: Integer has a negative value. 177 128: INTEGER : 54 82 BF B9 49 8A B8 77 E2 35 EC BE 7F 8F 3E 4A : AB 21 C0 62 6A A4 C5 8A D8 3B CA 4B 76 BE 50 5D : 13 8A AB 33 3D C5 01 9E 21 A1 FA 75 8F 4A 18 00 : 9B 80 17 35 C0 17 74 BD 2E 2F FC 0A E1 FD AF 44 : 36 84 66 D4 1C 78 C3 C6 08 4A 84 6D 96 CE 77 00 : 66 8A 77 35 DC 30 BA 48 18 48 4C 1A 92 D5 52 F0 : E2 43 7A F5 16 27 77 FF F4 5D F2 17 5F B3 04 D0 : D1 1A 2C E8 36 5D 45 AC A5 68 F7 BB 84 DF 2C 31 : } : } 308 22: OCTET STRING, encapsulates { 310 20: INTEGER : 4F A3 A5 92 92 86 FE 57 6A 73 AE 61 BC 46 0A 86 : BF 0E 14 BE : } : } 0 warnings, 2 errors. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Tue 16 Nov 2010 09:12:56 AM GMT Name: dsa-gnutls.der Size: 332B By: noloader Generated file _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 16 10:15:43 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Tue, 16 Nov 2010 09:15:43 +0000 Subject: [sr #107518] GnuTLS: After DSA Key Generation, 2 Integers were Encoded Incorrectly In-Reply-To: <20101116-091256.sv80862.53045@savannah.gnu.org> References: <20101116-091256.sv80862.53045@savannah.gnu.org> Message-ID: <20101116-091543.sv80862.9275@savannah.gnu.org> Additional Item Attachment, sr #107518 (project gnutls): File name: dsa-gnutls.der Size:0 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 16 12:34:47 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Tue, 16 Nov 2010 11:34:47 +0000 Subject: [sr #107518] GnuTLS: After DSA Key Generation, 2 Integers were Encoded Incorrectly In-Reply-To: <20101116-091543.sv80862.9275@savannah.gnu.org> References: <20101116-091256.sv80862.53045@savannah.gnu.org> <20101116-091543.sv80862.9275@savannah.gnu.org> Message-ID: <20101116-113447.sv80862.68008@savannah.gnu.org> Follow-up Comment #1, sr #107518 (project gnutls): Forgot to mention.... $ uname -a Linux studio 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux $ certtool --version certtool (GnuTLS) 2.8.5 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Nikos Mavrogiannopoulos and Simon Josefsson. $ _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 16 13:39:23 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Tue, 16 Nov 2010 12:39:23 +0000 Subject: [sr #107520] GnuTLS: certtool accepts invalid DSA modulus sizes Message-ID: <20101116-123923.sv80862.29504@savannah.gnu.org> URL: Summary: GnuTLS: certtool accepts invalid DSA modulus sizes Project: GnuTLS Submitted by: noloader Submitted on: Tue 16 Nov 2010 12:39:23 PM 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: None _______________________________________________________ Details: According to FIPS 186 version 1 and 2, a DSA modulus must be between 512 and 1024 in steps of 64 (512, 576, 640, ..., 960, 1024). See section 4, DSA PARAMETERS, of http://csrc.nist.gov/publications/fips/fips1861.pdf and http://csrc.nist.gov/publications/fips/archive/fips186-2/fips186-2.pdf. In addition, at version 2, only moduli of 1024 bits were recommended. At FIPS 186 version 3, moduli of 1024 or higher are required. See http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf. Below, certtool is creating a dsa key with 513 bits without error (not a multiple of 64 bits) nor warning (less than 1024 bits). $ certtool --dsa --generate-privkey --pkcs8 --outder --bits 513 --outfile dsa-gnutls.der Generating a 513 bit DSA private key... Enter password: Confirm password: $ =================== $ uname -a Linux studio 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux $ certtool --version certtool (GnuTLS) 2.8.5 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . ... _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 16 14:26:13 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Tue, 16 Nov 2010 13:26:13 +0000 Subject: [sr #107518] GnuTLS: After DSA Key Generation, 2 Integers were Encoded Incorrectly In-Reply-To: <20101116-113447.sv80862.68008@savannah.gnu.org> References: <20101116-091256.sv80862.53045@savannah.gnu.org> <20101116-091543.sv80862.9275@savannah.gnu.org> <20101116-113447.sv80862.68008@savannah.gnu.org> Message-ID: <20101116-132612.sv80862.12096@savannah.gnu.org> Additional Item Attachment, sr #107518 (project gnutls): File name: dsa-gnutls.der Size:0 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 16 14:29:29 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Tue, 16 Nov 2010 13:29:29 +0000 Subject: [sr #107518] GnuTLS: After DSA Key Generation, 2 Integers were Encoded Incorrectly In-Reply-To: <20101116-132612.sv80862.12096@savannah.gnu.org> References: <20101116-091256.sv80862.53045@savannah.gnu.org> <20101116-091543.sv80862.9275@savannah.gnu.org> <20101116-113447.sv80862.68008@savannah.gnu.org> <20101116-132612.sv80862.12096@savannah.gnu.org> Message-ID: <20101116-132929.sv80862.36266@savannah.gnu.org> Follow-up Comment #2, sr #107518 (project gnutls): After some more testing, all DSA private key integers (p, q, g, and x) have been encoded incorrectly. Interestingly, certtool encodes an RSA private key correctly. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 16 15:47:48 2010 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Nov 2010 14:47:48 +0000 Subject: [sr #107518] GnuTLS: After DSA Key Generation, 2 Integers were Encoded Incorrectly In-Reply-To: <20101116-132929.sv80862.36266@savannah.gnu.org> References: <20101116-091256.sv80862.53045@savannah.gnu.org> <20101116-091543.sv80862.9275@savannah.gnu.org> <20101116-113447.sv80862.68008@savannah.gnu.org> <20101116-132612.sv80862.12096@savannah.gnu.org> <20101116-132929.sv80862.36266@savannah.gnu.org> Message-ID: <20101116-164748.sv707.22406@savannah.gnu.org> Update of sr #107518 (project gnutls): Status: None => Done Assigned to: None => nmav _______________________________________________________ Follow-up Comment #3: Hi, this must have been partially solved in 2.10.x and must have been completely solved at: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=4c96b274661d185b5a6d8197d9ea401772ed87e7 Thanks for bringing this to our attention. Please let me know if any issue remains. regards, Nikos _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 16 15:53:14 2010 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Nov 2010 14:53:14 +0000 Subject: [sr #107520] GnuTLS: certtool accepts invalid DSA modulus sizes In-Reply-To: <20101116-123923.sv80862.29504@savannah.gnu.org> References: <20101116-123923.sv80862.29504@savannah.gnu.org> Message-ID: <20101116-165313.sv707.91010@savannah.gnu.org> Update of sr #107520 (project gnutls): Status: None => In Progress Assigned to: None => nmav _______________________________________________________ Follow-up Comment #1: Is this really a bug? In the new versions of gnutls (2.11) we suggest the --sec-param option instead of bits. The sec-param has as input low|normal|high|ultra and will use bit numbers allowed by FIPS documents. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 16 18:50:50 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Tue, 16 Nov 2010 17:50:50 +0000 Subject: [sr #107521] Lint encountered during compile Message-ID: <20101116-175050.sv80862.34609@savannah.gnu.org> URL: Summary: Lint encountered during compile Project: GnuTLS Submitted by: noloader Submitted on: Tue 16 Nov 2010 05:50:50 PM GMT Category: None Priority: 5 - Normal Severity: 2 - Minor Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: gnutls-make.txt is attached. $ ./configure CFLAGS="-Wall -Wextra -Wno-unused-parameter" $ make &> ./gnutls-make.txt $ cat gnutls-make.txt | grep warning | wc -l 191 $ _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Tue 16 Nov 2010 05:50:50 PM GMT Name: gnutls-make.txt Size: 209kB By: noloader _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 16 22:27:19 2010 From: INVALID.NOREPLY at gnu.org (Simon Josefsson) Date: Tue, 16 Nov 2010 21:27:19 +0000 Subject: [sr #107521] Lint encountered during compile In-Reply-To: <20101116-175050.sv80862.34609@savannah.gnu.org> References: <20101116-175050.sv80862.34609@savannah.gnu.org> Message-ID: <20101116-212719.sv7213.99920@savannah.gnu.org> Follow-up Comment #1, sr #107521 (project gnutls): Fixing these will be a bit of a pain, but we should do it since the code is not clean. The most time consuming part is the pointer signed/unsigned issue. Before someone spends a lot of time on a patch, please tell how you think it should be solved and why. /Simon _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 17 00:30:14 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Tue, 16 Nov 2010 23:30:14 +0000 Subject: [sr #107522] Use of dangerous/banned functions Message-ID: <20101116-233010.sv80862.81354@savannah.gnu.org> URL: Summary: Use of dangerous/banned functions Project: GnuTLS Submitted by: noloader Submitted on: Tue 16 Nov 2010 11:30:10 PM 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: None _______________________________________________________ Details: GnuTLS uses unsafe string handling functions. From Apples Security Guide, Table 1 (p. 35): Table 1: String functions to use and avoid Don't use these functions - Use these instead --------------------------+-------------------------- strcat | strlcat strcpy | strlcpy strncat | strlcat strncpy | strlcpy sprintf | snprintf vsprintf | vsnprint The same theme rings true in the Microsoft world. For example, see Howard and LeBlanc's Writing Secure Code. Use of safe string handling functions is a secure code quality gate. Microsoft software which uses dangerous and banned functions will not pass internal quality checks. == References == Apple Inc., "Secure Coding Guide: Security", String Handling, p.35. Wheeler, "Secure Programming for Linux and Unix HOWTO", Section 6.1 Dangers in C/C++, p 61. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 17 01:09:00 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Wed, 17 Nov 2010 00:09:00 +0000 Subject: [sr #107522] Use of dangerous/banned functions In-Reply-To: <20101116-233010.sv80862.81354@savannah.gnu.org> References: <20101116-233010.sv80862.81354@savannah.gnu.org> Message-ID: <20101117-000900.sv80862.28538@savannah.gnu.org> Follow-up Comment #1, sr #107522 (project gnutls): Forgot to mention.... I cited Apple's security guide because the table is compiled (so it offers copy/paste convenience). Wheeler's security guide says about the same in more words (Wheeler is more in depth because he also discusses other "safe" libraries). And Microsoft has a succinct page: Security Development Lifecycle (SDL) Banned Function Calls, http://msdn.microsoft.com/en-us/library/bb288454.aspx. One fellow on [BuqTraq|FunSec|FullDisclosure] summed it up nicely, "there's no reason to be using strcpy in 2010". (can't find the reference at the moment). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 17 01:49:42 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Wed, 17 Nov 2010 00:49:42 +0000 Subject: [sr #107522] Use of dangerous/banned functions In-Reply-To: <20101117-000900.sv80862.28538@savannah.gnu.org> References: <20101116-233010.sv80862.81354@savannah.gnu.org> <20101117-000900.sv80862.28538@savannah.gnu.org> Message-ID: <20101117-004941.sv80862.38538@savannah.gnu.org> Follow-up Comment #2, sr #107522 (project gnutls): It occurred to me: use of unsafe functions are still at pandemic proportions, yet I don't recall ever seeing a GCC warning. Doing something about it: "Request: Warning for use of unsafe string handling functions", http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513. Mircosoft's tool chain emits warnings on their use, and SAL (/analyze) takes its a step further by offering abuse scenarios (for example, "readable size is 4 bytes, but 16 bytes might be read"). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From steffen.jaeckel at stzedn.de Tue Nov 16 16:11:27 2010 From: steffen.jaeckel at stzedn.de (Steffen Jaeckel) Date: Tue, 16 Nov 2010 16:11:27 +0100 Subject: Build gnutls on Windows Message-ID: <475841956.20101116161127@stzedn.de> Hi, I've tried to build gnutls on windows but I wasn't successful. Exists there any documentation howto do this? Best regards, Steffen From INVALID.NOREPLY at gnu.org Wed Nov 17 04:52:31 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Wed, 17 Nov 2010 03:52:31 +0000 Subject: [sr #107522] Use of dangerous/banned functions In-Reply-To: <20101117-004941.sv80862.38538@savannah.gnu.org> References: <20101116-233010.sv80862.81354@savannah.gnu.org> <20101117-000900.sv80862.28538@savannah.gnu.org> <20101117-004941.sv80862.38538@savannah.gnu.org> Message-ID: <20101117-035230.sv80862.66785@savannah.gnu.org> Follow-up Comment #3, sr #107522 (project gnutls): Attaching "Secure Portability" by Damien Miller. Miller lists systems which include support for safer string handling functions such as strl* and friends. Bounds-checking interfaces are now included in the C1X draft dated 2010-10-04 (previously included via TR 24731-1, which was included in Annex K of an earlier C1X draft). A link to the C1X draft (ISO/IEC 9899:201x) can be found at http://www.open-std.org/Jtc1/sc22/wg14/www/projects. Grab the PDF for N1516. Links to TR 24731-1 (Extensions to the C Library Part I: Bounds-checking interfaces) and TR 24731-2 (Extensions to the C Library - Part II: Dynamic allocation functions) can be found at http://www.open-std.org/Jtc1/sc22/wg14/www/projects. Grab the PDFs for N1225 and N1337. The take away is that strlcpy and friends are almost ubiquitous on *nix, and strcpy_s and friends will be standardized shortly. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 17 08:17:59 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Wed, 17 Nov 2010 07:17:59 +0000 Subject: [sr #107521] Lint encountered during compile In-Reply-To: <20101116-212719.sv7213.99920@savannah.gnu.org> References: <20101116-175050.sv80862.34609@savannah.gnu.org> <20101116-212719.sv7213.99920@savannah.gnu.org> Message-ID: <20101117-071759.sv80862.73064@savannah.gnu.org> Follow-up Comment #2, sr #107521 (project gnutls): Hi Simon, > Fixing these will be a bit of a pain, but we should do it > since the code is not clean. Agreed. -Wall -Wextra is a nice tattle tale. The switches vet issues before they become problems (confer, SR #106551 and SR #106549). > The most time consuming part is the pointer signed/unsigned > issue. Before someone spends a lot of time on a patch, > please tell how you think it should be solved and why. For the signed/unsigned pointers, I would introduce a gnutls byte or octet that was typedf'd as an unsigned char. typedef'ing would step away from signed/unsigned chars, which is conceptually consistent with operating on the data bytes or data octets. With the byte_t or octet_t in place, data which is truly a char* would be operated upon by str* functions, while data which is a byte_t*/octet_t* would manipulated with the mem* functions. Personally, I'm more concerned with "comparison between signed and unsigned integer expressions". A comparison is going to be made, the question is "How?". In this case, the [possible] negative number is most likely promoted to unsigned, which usually results in a *really* big positive value if the original number is negative. Consider: the adversary controls the wire, so he/she is going to feed gnutls bad certs and other miscreant data in an effort to get a toe hold on the system. Adobe is a case study in this sort of vulnerability. Its not the common case, its just something that gnutls should be mindful. Jeff _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 17 08:24:35 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Wed, 17 Nov 2010 07:24:35 +0000 Subject: [sr #107521] Lint encountered during compile In-Reply-To: <20101117-071759.sv80862.73064@savannah.gnu.org> References: <20101116-175050.sv80862.34609@savannah.gnu.org> <20101116-212719.sv7213.99920@savannah.gnu.org> <20101117-071759.sv80862.73064@savannah.gnu.org> Message-ID: <20101117-072435.sv80862.19583@savannah.gnu.org> Follow-up Comment #3, sr #107521 (project gnutls): > For the signed/unsigned pointers, I would introduce a > gnutls byte or octet that was typedf'd as an unsigned > char. typedef'ing would step away from signed/unsigned > chars, which is conceptually consistent with operating > on the data bytes or data octets. > With the byte_t or octet_t in place, data which is truly > a char* would be operated upon by str* functions, while > data which is a byte_t* or octet_t* would manipulated > with the mem* functions. Yikes! I'm slipping in my old age. That should be: "...would be operated upon by SAFE str* functions", Jeff _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 17 08:56:40 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Wed, 17 Nov 2010 07:56:40 +0000 Subject: [sr #107521] Lint encountered during compile In-Reply-To: <20101117-072435.sv80862.19583@savannah.gnu.org> References: <20101116-175050.sv80862.34609@savannah.gnu.org> <20101116-212719.sv7213.99920@savannah.gnu.org> <20101117-071759.sv80862.73064@savannah.gnu.org> <20101117-072435.sv80862.19583@savannah.gnu.org> Message-ID: <20101117-075640.sv80862.14088@savannah.gnu.org> Follow-up Comment #4, sr #107521 (project gnutls): Hi Simon, Forgot to mention.... > Fixing these will be a bit of a pain, but we should do it > since the code is not clean. When -Wall -Wextra is *not* specified, GnuTLS is effectively saying, "we'll let GCC pick and choose what warnings are relevant for the project". GCC does not suffer the project's crashes or vulnerabilities, so GCC should not be making the decisions. GnuTLS *should* specify -Wall -Wextra, so the project can decide what warnings need attention and which can be safely ignored. Jeff _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From noloader at gmail.com Wed Nov 17 10:23:27 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 17 Nov 2010 04:23:27 -0500 Subject: A few beginner questions Message-ID: Hi All, Hold back the laughter........ ===== According to the README, the library is located in \lib. Do libraries have extensions other than *.a or *.so? $ pwd /home/jeffrey/gnutls-2.10.2 $ ./configure CFLAGS="-Wall -Wextra -Wno-unused-param -DDEBUG -O0 -g -ggdb" ... $ make ... $ cd lib $ ls *.a *.so ls: cannot access *.a: No such file or directory ls: cannot access *.so: No such file or directory $ ===== How does one start the self tests? There's nothing in the README. $ pwd /home/jeffrey/gnutls-2.10.2 $ make test make: *** No rule to make target `test'. Stop. $ make tests make: Nothing to be done for `tests'. $ Found . Try 'check': $ make check ... ar: pkix_asn1_tab.o: No such file or directory make[2]: *** [libgnutls.la] Error 1 make[2]: Leaving directory `/home/jeffrey/Desktop/gnutls-2.10.2/lib' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/jeffrey/Desktop/gnutls-2.10.2/lib' make: *** [check-recursive] Error 1 $ find . -name pkix_asn1_tab.* ./lib/.deps/pkix_asn1_tab.Plo ./lib/pkix_asn1_tab.lo ./lib/pkix_asn1_tab.c ./lib/.libs/pkix_asn1_tab.o $ ===== Jeff From noloader at gmail.com Wed Nov 17 10:59:06 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 17 Nov 2010 04:59:06 -0500 Subject: Ubuntu Build: Libnettle 2.1 vs Libnettle 3 Message-ID: Hi All, I'm trying to work from the repo. Any ideas? Jeff $ git clone git://git.savannah.gnu.org/gnutls.git ... $ cd gnutls $ make bootstrap ... checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for shared library run path origin... done checking whether to use nettle... yes checking for libnettle... no configure: error: *** *** Libnettle 2.1 was not found. make: *** [bootstrap] Error 1 $ apt-cache pkgnames | grep nettle libnettle1 libnettle3 nettle-bin nettle-dbg nettle-dev libnettle-dev $ sudo apt-get install libnettle3 Reading package lists... Done Building dependency tree Reading state information... Done libnettle3 is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. $ uname -a Linux studio 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux $ From bradh at frogmouth.net Wed Nov 17 11:03:29 2010 From: bradh at frogmouth.net (Brad Hards) Date: Wed, 17 Nov 2010 21:03:29 +1100 Subject: A few beginner questions In-Reply-To: References: Message-ID: <201011172103.29984.bradh@frogmouth.net> On Wednesday, November 17, 2010 08:23:27 pm Jeffrey Walton wrote: > According to the README, the library is located in \lib. Do libraries > have extensions other than *.a or *.so? http://git.savannah.gnu.org/cgit/gnutls.git/tree/README says "lib/" which means "the directory called lib within this source tree". Unix doesn't use \ as part of a path. > $ pwd > /home/jeffrey/gnutls-2.10.2 > $ ./configure CFLAGS="-Wall -Wextra -Wno-unused-param -DDEBUG -O0 -g -ggdb" > ... > $ make > ... > $ cd lib > $ ls *.a *.so > ls: cannot access *.a: No such file or directory > ls: cannot access *.so: No such file or directory that is the source tree, not the build results. > How does one start the self tests? There's nothing in the README. http://git.savannah.gnu.org/cgit/gnutls.git/tree/README-alpha From bradh at frogmouth.net Wed Nov 17 11:16:49 2010 From: bradh at frogmouth.net (Brad Hards) Date: Wed, 17 Nov 2010 21:16:49 +1100 Subject: Ubuntu Build: Libnettle 2.1 vs Libnettle 3 In-Reply-To: References: Message-ID: <201011172116.50285.bradh@frogmouth.net> On Wednesday, November 17, 2010 08:59:06 pm Jeffrey Walton wrote: > $ apt-cache pkgnames | grep nettle > libnettle1 > libnettle3 > nettle-bin > nettle-dbg > nettle-dev > libnettle-dev > $ sudo apt-get install libnettle3 > Reading package lists... Done > Building dependency tree > Reading state information... Done > libnettle3 is already the newest version. This is nothing to do with gnutls. Debian (and derivatives, such as Ubuntu) name packages according to convention. You can find this convention if you search for it, but the important part here is that if you want to compile something, you want the -dev variant. That is, install libnettle-dev. Brad From INVALID.NOREPLY at gnu.org Wed Nov 17 13:06:38 2010 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Wed, 17 Nov 2010 12:06:38 +0000 Subject: [sr #107521] Lint encountered during compile In-Reply-To: <20101117-075640.sv80862.14088@savannah.gnu.org> References: <20101116-175050.sv80862.34609@savannah.gnu.org> <20101116-212719.sv7213.99920@savannah.gnu.org> <20101117-071759.sv80862.73064@savannah.gnu.org> <20101117-072435.sv80862.19583@savannah.gnu.org> <20101117-075640.sv80862.14088@savannah.gnu.org> Message-ID: <20101117-120638.sv0.32188@savannah.gnu.org> Follow-up Comment #5, sr #107521 (project gnutls): Before adding that all the generated warnings have to be fixed. Something that is not that trivial... --nmav _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From simon at josefsson.org Wed Nov 17 15:25:43 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 17 Nov 2010 15:25:43 +0100 Subject: Ubuntu Build: Libnettle 2.1 vs Libnettle 3 In-Reply-To: <201011172116.50285.bradh@frogmouth.net> (Brad Hards's message of "Wed, 17 Nov 2010 21:16:49 +1100") References: <201011172116.50285.bradh@frogmouth.net> Message-ID: <87tyjgrpqw.fsf@latte.josefsson.org> Brad Hards writes: > On Wednesday, November 17, 2010 08:59:06 pm Jeffrey Walton wrote: >> $ apt-cache pkgnames | grep nettle >> libnettle1 >> libnettle3 >> nettle-bin >> nettle-dbg >> nettle-dev >> libnettle-dev >> $ sudo apt-get install libnettle3 >> Reading package lists... Done >> Building dependency tree >> Reading state information... Done >> libnettle3 is already the newest version. > This is nothing to do with gnutls. Debian (and derivatives, such as Ubuntu) > name packages according to convention. You can find this convention if you > search for it, but the important part here is that if you want to compile > something, you want the -dev variant. > > That is, install libnettle-dev. Note that libnettle3 is version 2.0 on at least debian squeeze: jas at latte:~$ apt-cache show libnettle3|grep Version Version: 2.0-2 jas at latte:~$ The 3 in libnettle3 is the ABI version, not the release version. /Simon From simon at josefsson.org Wed Nov 17 15:28:49 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 17 Nov 2010 15:28:49 +0100 Subject: Build gnutls on Windows In-Reply-To: <475841956.20101116161127@stzedn.de> (Steffen Jaeckel's message of "Tue, 16 Nov 2010 16:11:27 +0100") References: <475841956.20101116161127@stzedn.de> Message-ID: <87pqu4rplq.fsf@latte.josefsson.org> Steffen Jaeckel writes: > Hi, > > I've tried to build gnutls on windows but I wasn't successful. > Exists there any documentation howto do this? If you have a mingw environment, it should just be ./configure && make. I cross-compile from linux using MinGW as well, see: http://josefsson.org/gnutls4win/ http://josefsson.org/gnutls4win/Makefile However I'm currently using MinGW-w64 instead. Maybe I should blog about my setup, it is so easy to do Windows development from linux... /Simon From INVALID.NOREPLY at gnu.org Wed Nov 17 15:34:04 2010 From: INVALID.NOREPLY at gnu.org (Simon Josefsson) Date: Wed, 17 Nov 2010 14:34:04 +0000 Subject: [sr #107522] Use of dangerous/banned functions In-Reply-To: <20101117-035230.sv80862.66785@savannah.gnu.org> References: <20101116-233010.sv80862.81354@savannah.gnu.org> <20101117-000900.sv80862.28538@savannah.gnu.org> <20101117-004941.sv80862.38538@savannah.gnu.org> <20101117-035230.sv80862.66785@savannah.gnu.org> Message-ID: <20101117-143404.sv7213.15048@savannah.gnu.org> Follow-up Comment #4, sr #107522 (project gnutls): Do you have some concrete pointer to broken GnuTLS code? It would help to make this discussion a bit more down to earth. The strlcpy etc are as criticized as the strcpy functions, and I recall decisions within gnulib to not provide portability wrappers for them because it is not a good idea. /Simon _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 17 15:36:07 2010 From: INVALID.NOREPLY at gnu.org (Simon Josefsson) Date: Wed, 17 Nov 2010 14:36:07 +0000 Subject: [sr #107521] Lint encountered during compile In-Reply-To: <20101117-120638.sv0.32188@savannah.gnu.org> References: <20101116-175050.sv80862.34609@savannah.gnu.org> <20101116-212719.sv7213.99920@savannah.gnu.org> <20101117-071759.sv80862.73064@savannah.gnu.org> <20101117-072435.sv80862.19583@savannah.gnu.org> <20101117-075640.sv80862.14088@savannah.gnu.org> <20101117-120638.sv0.32188@savannah.gnu.org> Message-ID: <20101117-143607.sv7213.47574@savannah.gnu.org> Follow-up Comment #6, sr #107521 (project gnutls): Note that some of these problems are because of types used in the public header file. We can't change the public header file without considering backwards compatibility issues. Look at 'gnutls_datum_t' for example, it uses 'unsigned char*' and 'unsigned int'. Changing that to use size_t, for example, will break API/ABI significantly. /Simon _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From noloader at gmail.com Wed Nov 17 21:41:33 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 17 Nov 2010 15:41:33 -0500 Subject: Ubuntu Build: Libnettle 2.1 vs Libnettle 3 In-Reply-To: <87tyjgrpqw.fsf@latte.josefsson.org> References: <201011172116.50285.bradh@frogmouth.net> <87tyjgrpqw.fsf@latte.josefsson.org> Message-ID: On Wed, Nov 17, 2010 at 9:25 AM, Simon Josefsson wrote: > Brad Hards writes: > >> On Wednesday, November 17, 2010 08:59:06 pm Jeffrey Walton wrote: >>> $ apt-cache pkgnames | grep nettle >>> libnettle1 >>> libnettle3 >>> nettle-bin >>> nettle-dbg >>> nettle-dev >>> libnettle-dev >>> $ sudo apt-get install libnettle3 >>> Reading package lists... Done >>> Building dependency tree >>> Reading state information... Done >>> libnettle3 is already the newest version. >> This is nothing to do with gnutls. Debian (and derivatives, such as Ubuntu) >> name packages according to convention. You can find this convention if you >> search for it, but the important part here is that if you want to compile >> something, you want the -dev variant. >> >> That is, install libnettle-dev. > > Note that libnettle3 is version 2.0 on at least debian squeeze: > > jas at latte:~$ apt-cache show libnettle3|grep Version > Version: 2.0-2 > jas at latte:~$ > > The 3 in libnettle3 is the ABI version, not the release version. > Thanks man! Its not the first time I've been mistaken about versions, and I'm sure it won't be the last. I've always had a difficult time with Linux versioning, especially on modules which have been back-patched in piecemeal fashion. An exercise left to the reader: what version of OpenSSL are you *really* running? Jeff From noloader at gmail.com Wed Nov 17 21:42:55 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 17 Nov 2010 15:42:55 -0500 Subject: Ubuntu Build: Libnettle 2.1 vs Libnettle 3 In-Reply-To: <201011172116.50285.bradh@frogmouth.net> References: <201011172116.50285.bradh@frogmouth.net> Message-ID: On Wed, Nov 17, 2010 at 5:16 AM, Brad Hards wrote: > On Wednesday, November 17, 2010 08:59:06 pm Jeffrey Walton wrote: >> $ apt-cache pkgnames | grep nettle >> libnettle1 >> libnettle3 >> nettle-bin >> nettle-dbg >> nettle-dev >> libnettle-dev >> $ sudo apt-get install libnettle3 >> Reading package lists... Done >> Building dependency tree >> Reading state information... Done >> libnettle3 is already the newest version. > This is nothing to do with gnutls. Debian (and derivatives, such as Ubuntu) > name packages according to convention. You can find this convention if you > search for it, but the important part here is that if you want to compile > something, you want the -dev variant. Thanks Brad! Its not the first time I've forgotten to install the -dev variant, and I'm sure it won't be the last. Jeff From INVALID.NOREPLY at gnu.org Thu Nov 18 00:18:51 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Wed, 17 Nov 2010 23:18:51 +0000 Subject: [sr #107522] Use of dangerous/banned functions In-Reply-To: <20101117-143404.sv7213.15048@savannah.gnu.org> References: <20101116-233010.sv80862.81354@savannah.gnu.org> <20101117-000900.sv80862.28538@savannah.gnu.org> <20101117-004941.sv80862.38538@savannah.gnu.org> <20101117-035230.sv80862.66785@savannah.gnu.org> <20101117-143404.sv7213.15048@savannah.gnu.org> Message-ID: <20101117-231851.sv80862.84166@savannah.gnu.org> Follow-up Comment #5, sr #107522 (project gnutls): Hi Simon, I'm going to field things out of order to improve the flow of responses. > The strlcpy etc are as criticized as the strcpy functions... I have also read the counter arguments, which I am going to paraphrase below. The arguments are generic, and not specific to strcpy_s (and friends) or strlcpy (and friends). Please feel free to correct or expand my compilation below. : There are two major issues with using the safer : string functions: : (1) The replacement functions do not completely solve the : "unsafe" handling inherent in the original functions. : (2) The replacement functions are slower than the original : functions under some circumstances and implementations. To re-frame the arguments above, consider: you are a junior programmer making $20 hour (an unsafe function). You want to be a project manager making $60 hour (a safe, efficient, replacement function). Sometime in your career, you are offered a senior programming position at $40 hour (a safer function). But you reject the offer since its not the position of program manager. == Item 1 == Does it make sense to reject the $40 hour position? Does it make sense to reject the safer functions because they were *only* designed to be a [near] drop in replacement to help remediate issues in the existing code base? I believe the syndrome is colloquially referred to as, "throwing the baby out with the bath water". == Item 2 == The B programming language made its debut circa 1969. C followed from B in the 1970s. strcpy and friends made their debut nearly 40 years ago! Unfortunately, it took less than 40 years for the environment, which was originally benign, to turn hostile or toxic. The Dataloss Database (http://datalossdb.org/) is testament to the fact. "They who can give up essential security to obtain a little temporary speed, deserve neither security nor speed." - Benjamin Franklin, circa 1775 == Item 3 == Item 3 did not make the list, but it always plays a role in matters such as these: political feasibility. Microsoft sponsored the initiative at ISO/IEC. The "initiative" was "Extensions to the C Library Part I: Bounds-checking interfaces". This is also known as "safer string handling functions". It is now a normative part of the current C1X draft (latest version dated 2010-10-04). The initiative was accepted and originally presented as a Type 2 Technical Report, which means "there is the future but not immediate possibility of an agreement on an International Standard". The take away: Item 3 is "sour grapes". > ...decisions within gnulib to not provide portability > wrappers for them because it is not a good idea This effect is "no support for safer functions". It is directly attributed to (1) above. In this case, what are the distributions, POSIX, or the Open Standards group, et al offering for the complete resolution of the problems and issues associated with the original [unsafe] functions? That is, what are the "safe" functions (not "safer" functions)? For portability via standardization, I'm willing to use a set of wrappers which [the wrappers] call into safer functions. > Do you have some concrete pointer to broken GnuTLS code? Ah!!! It's not about a single instance of broken code. I don't want to fix 1 stack smash, or 1 buffer overflow for that matter. A particular stack smash or buffer over flow is irrelevant in the big picture. I want policies - which are transformed into procedures - that ensure all stack smashes, buffer overflows, and other miscreants go the way of the dinosaurs. So the policy [which I prefer] is "secure, robust, efficient, and portable code." One of the ways to make it happen is via a policy which requires all project code to call through a wrapper, and then the wrapper calls a safer function. To summarize, it *is* about learning from the past, and moving forward in a safe, robust, and efficient manner. Portability is icing on the cake. Allow of this is technically feasible. Some of it is politically infeasible. Jeff _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Nov 18 04:21:44 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Thu, 18 Nov 2010 03:21:44 +0000 Subject: [sr #107522] Use of dangerous/banned functions In-Reply-To: <20101117-231851.sv80862.84166@savannah.gnu.org> References: <20101116-233010.sv80862.81354@savannah.gnu.org> <20101117-000900.sv80862.28538@savannah.gnu.org> <20101117-004941.sv80862.38538@savannah.gnu.org> <20101117-035230.sv80862.66785@savannah.gnu.org> <20101117-143404.sv7213.15048@savannah.gnu.org> <20101117-231851.sv80862.84166@savannah.gnu.org> Message-ID: <20101118-032144.sv80862.63609@savannah.gnu.org> Follow-up Comment #6, sr #107522 (project gnutls): Hi Simon, This statement needs a little more elaboration: > So the policy [which I prefer] is "secure, robust, efficient, and portable code." == Secure == Here's the signature for a secure strcpy (less restricted pointers). Obviously, the const on the pointers can be dropped but I prefer them until otherwise. Many folks don't care for it (especially if the function asserts), but if fully specifies all parameters. It returns success, bad parameter, or truncation. errno_t safe_str_copy(char* const pDest, size_t nDest, const char* const pSrc, size_t nSrc, size_t nCount); == Robust == For "robust", the project will have to determine what to do. I personally think perror/exit is the least desired combination. But sometimes its all you have. == Efficient == Make one pass, do things in less than (or equal to) O(n), and turn to the native ASM memcpy (which should already be done). == Portable == Use wrappers and (a) strcpy_s or StringCbCopy on Microsoft (b) strlcpy on BSD and Solaris, and (c) memcpy on GNU systems. Jeff _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Nov 18 11:01:09 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Thu, 18 Nov 2010 10:01:09 +0000 Subject: [sr #107524] Test suite: gnutls_global_init/gnutls_global_deinit Message-ID: <20101118-100108.sv80862.92544@savannah.gnu.org> URL: Summary: Test suite: gnutls_global_init/gnutls_global_deinit Project: GnuTLS Submitted by: noloader Submitted on: Thu 18 Nov 2010 10:01:08 AM GMT Category: None Priority: 5 - Normal Severity: 1 - Wish Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: In the test suite, matching calls to gnutls_global_init and gnutls_global_deinit would be a welcome addition. Unmatched calls creates a lot of noise for auditing tools, which makes it somewhat more difficult to trace and audit. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Nov 18 12:57:52 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Thu, 18 Nov 2010 11:57:52 +0000 Subject: [sr #107524] Test suite: gnutls_global_init/gnutls_global_deinit In-Reply-To: <20101118-100108.sv80862.92544@savannah.gnu.org> References: <20101118-100108.sv80862.92544@savannah.gnu.org> Message-ID: <20101118-115752.sv80862.70845@savannah.gnu.org> Follow-up Comment #1, sr #107524 (project gnutls): My bad.... this might actually be an issue. For example, certificate_set_x509_crl calls both gnutls_global_init and gnutls_global_deinit. Since cleanup is being performed, there should probably be nothing reported in Valgrind under "still reachable". See below. Valgrind also claims openpgpself, gnutls_handshake, is definitely leaking. Attached is a jagged test script (enhancements welcomed) and test results. For completeness: $ ./configure CFLAGS=:"-DDEBUG -g3 -ggdb -O0" $ make && make check $ cd tests $ ./valgrind-gnutls.sh # output to valgrind-gnutls.txt $ cat valgrind-gnutls.txt | egrep -c 'definitely lost: [1-9]' 20 **==**==**==**==**==**==**==**==**==**==**==**==**==**== ==20055== Memcheck, a memory error detector ==20055== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==20055== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==20055== Command: ./certificate_set_x509_crl ==20055== ==20055== ==20055== HEAP SUMMARY: ==20055== in use at exit: 3,056 bytes in 38 blocks ==20055== total heap usage: 3,416 allocs, 3,378 frees, 133,604 bytes allocated ==20055== ==20055== 240 bytes in 5 blocks are still reachable in loss record 1 of 5 ==20055== at 0x4C274A8: malloc (vg_replace_malloc.c:236) ==20055== by 0x553D7F0: do_malloc (global.c:737) ==20055== by 0x553D9F8: _gcry_malloc (global.c:759) ==20055== by 0x55425F0: _gcry_module_add (module.c:88) ==20055== by 0x5546D0F: pk_register_default (pubkey.c:216) ==20055== by 0x554716E: _gcry_pk_init (pubkey.c:2598) ==20055== by 0x553DCB4: global_init (global.c:105) ==20055== by 0x553DEF5: _gcry_check_version (global.c:222) ==20055== by 0x4E66662: gnutls_global_init (gnutls_global.c:191) ==20055== by 0x400B26: main (certificate_set_x509_crl.c:59) ==20055== ==20055== 624 bytes in 13 blocks are still reachable in loss record 2 of 5 ==20055== at 0x4C274A8: malloc (vg_replace_malloc.c:236) ==20055== by 0x553D7F0: do_malloc (global.c:737) ==20055== by 0x553D9F8: _gcry_malloc (global.c:759) ==20055== by 0x55425F0: _gcry_module_add (module.c:88) ==20055== by 0x554F5D3: md_register_default (md.c:188) ==20055== by 0x554F7BE: _gcry_md_init (md.c:1291) ==20055== by 0x553DCA8: global_init (global.c:102) ==20055== by 0x553DEF5: _gcry_check_version (global.c:222) ==20055== by 0x4E66662: gnutls_global_init (gnutls_global.c:191) ==20055== by 0x400B26: main (certificate_set_x509_crl.c:59) ==20055== ==20055== 664 bytes in 1 blocks are still reachable in loss record 3 of 5 ==20055== at 0x4C274A8: malloc (vg_replace_malloc.c:236) ==20055== by 0x553D7F0: do_malloc (global.c:737) ==20055== by 0x553D9F8: _gcry_malloc (global.c:759) ==20055== by 0x553DA4E: _gcry_xmalloc (global.c:903) ==20055== by 0x553DA9E: _gcry_xcalloc (global.c:965) ==20055== by 0x557A82E: initialize (random-csprng.c:335) ==20055== by 0x557A8D4: _gcry_rngcsprng_create_nonce (random-csprng.c:1330) ==20055== by 0x4E7FB1C: wrap_gcry_rnd_init (rnd-libgcrypt.c:39) ==20055== by 0x4E7CF09: _gnutls_rnd_init (random.c:39) ==20055== by 0x4E6685A: gnutls_global_init (gnutls_global.c:237) ==20055== by 0x400B26: main (certificate_set_x509_crl.c:59) ==20055== ==20055== 664 bytes in 1 blocks are still reachable in loss record 4 of 5 ==20055== at 0x4C274A8: malloc (vg_replace_malloc.c:236) ==20055== by 0x553D7F0: do_malloc (global.c:737) ==20055== by 0x553D9F8: _gcry_malloc (global.c:759) ==20055== by 0x553DA4E: _gcry_xmalloc (global.c:903) ==20055== by 0x553DA9E: _gcry_xcalloc (global.c:965) ==20055== by 0x557A852: initialize (random-csprng.c:338) ==20055== by 0x557A8D4: _gcry_rngcsprng_create_nonce (random-csprng.c:1330) ==20055== by 0x4E7FB1C: wrap_gcry_rnd_init (rnd-libgcrypt.c:39) ==20055== by 0x4E7CF09: _gnutls_rnd_init (random.c:39) ==20055== by 0x4E6685A: gnutls_global_init (gnutls_global.c:237) ==20055== by 0x400B26: main (certificate_set_x509_crl.c:59) ==20055== ==20055== 864 bytes in 18 blocks are still reachable in loss record 5 of 5 ==20055== at 0x4C274A8: malloc (vg_replace_malloc.c:236) ==20055== by 0x553D7F0: do_malloc (global.c:737) ==20055== by 0x553D9F8: _gcry_malloc (global.c:759) ==20055== by 0x55425F0: _gcry_module_add (module.c:88) ==20055== by 0x55446B1: cipher_register_default (cipher.c:301) ==20055== by 0x55448EE: _gcry_cipher_init (cipher.c:1873) ==20055== by 0x553DC9F: global_init (global.c:99) ==20055== by 0x553DEF5: _gcry_check_version (global.c:222) ==20055== by 0x4E66662: gnutls_global_init (gnutls_global.c:191) ==20055== by 0x400B26: main (certificate_set_x509_crl.c:59) ==20055== ==20055== LEAK SUMMARY: ==20055== definitely lost: 0 bytes in 0 blocks ==20055== indirectly lost: 0 bytes in 0 blocks ==20055== possibly lost: 0 bytes in 0 blocks ==20055== still reachable: 3,056 bytes in 38 blocks ==20055== suppressed: 0 bytes in 0 blocks ==20055== ==20055== For counts of detected and suppressed errors, rerun with: -v ==20055== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) (file #22046, file #22047) _______________________________________________________ Additional Item Attachment: File name: valgrind-gnutls.sh Size:0 KB File name: valgrind-gnutls.txt.tar.gz Size:18 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Nov 18 12:59:55 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Thu, 18 Nov 2010 11:59:55 +0000 Subject: [sr #107524] Test suite: gnutls_global_init/gnutls_global_deinit In-Reply-To: <20101118-115752.sv80862.70845@savannah.gnu.org> References: <20101118-100108.sv80862.92544@savannah.gnu.org> <20101118-115752.sv80862.70845@savannah.gnu.org> Message-ID: <20101118-115955.sv80862.42903@savannah.gnu.org> Follow-up Comment #2, sr #107524 (project gnutls): Second tray at the posting the script..... (file #22048) _______________________________________________________ Additional Item Attachment: File name: valgrind-gnutls.sh.tar.gz Size:0 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 19 01:00:18 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Fri, 19 Nov 2010 00:00:18 +0000 Subject: [sr #107525] Use of dangerous/banned functions (Particular Instances) Message-ID: <20101119-000016.sv80862.1214@savannah.gnu.org> URL: Summary: Use of dangerous/banned functions (Particular Instances) Project: GnuTLS Submitted by: noloader Submitted on: Fri 19 Nov 2010 12:00:16 AM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: GnuTLS is using some functions which cannot indicate error; and other times the project is ignoring return values from known unsafe functions. The attached audit displays usage of strcpy, strncpy, strcat, strncat, sprintf, and vsprintf. In many cases, the function in question does not return a useful return value*, so GnuTLS has no way of detecting abnormalities. It might not be appropriate to assume SUCCESS under all circumstances, especially in a hostile environment Other functions return a value, but the return value is ignored - for example sprintf and snprintf in certtool.c. In the case of security software, it is often prudent to check return values in all cases where a value is available. Attached is the jagged script used to generate the audit (enhancements welcome), and the results of the audit. A sample of the audit follows. ===== certtool.c ===== 124: sprintf (&(buf[i * 3]), "%02X%s", raw[i], ===== cli.c ===== 876: strcpy (b, "\r\n"); ===== common.c ===== 64: sprintf (&(buf[i * 3]), "%02X%s", raw[i], ===== crypt.c ===== 165: strcpy (_salt, salt); 578: strcpy (tmpname, tpasswd); 579: strcat (tmpname, ".tmp"); 131: sprintf (line, "%d:%s:%s\n", index, str_n.data, str_g.data); 511: sprintf (result, "%s:%s", txt_verifier.data, txt_salt.data); .... ========== * For example, strcpy(3) man page states (Ubuntu 10.x): RETURN VALUE: The strcpy() and strncpy() functions return a pointer to the destination string dest. man pages typically under-play the return value. From The Open Group Base Specifications (http://www.opengroup.org/onlinepubs/009695399/functions/strcpy.html): RETURN VALUE: The strcpy() function shall return s1; no return value is reserved to indicate an error. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Fri 19 Nov 2010 12:00:16 AM GMT Name: audit-unsafe-fns.txt Size: 3kB By: noloader ------------------------------------------------------- Date: Fri 19 Nov 2010 12:00:16 AM GMT Name: audit-unsafe.sh Size: 808B By: noloader _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 19 04:03:43 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Fri, 19 Nov 2010 03:03:43 +0000 Subject: [sr #107527] Use of dangerous/banned functions (Analysis) Message-ID: <20101119-030342.sv80862.45182@savannah.gnu.org> URL: Summary: Use of dangerous/banned functions (Analysis) Project: GnuTLS Submitted by: noloader Submitted on: Fri 19 Nov 2010 03:03:42 AM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: SR #107522 flagged the general use of unsafe string handling functions. SR #107525 detailed particular instances of the use of unsafe string handling functions; and highlighted GnuTLS's inability to detect failure. This SR will analyze the code around a cluster of calls to strcpy in serv.c. The lines of interest in peer_print_info (from the SR $107525 audit) are: 451: size_t len = 5 * 1024 + strlen (header); 457: http_buffer = malloc (len); ... 461: strcpy (http_buffer, HTTP_BEGIN); 462: strcpy (&http_buffer[sizeof (HTTP_BEGIN) - 1], DEFAULT_DATA); 463: strcpy (&http_buffer[sizeof (HTTP_BEGIN) + sizeof (DEFAULT_DATA) - 2], HTTP_END); 465: *ret_length = sizeof (DEFAULT_DATA) + sizeof (HTTP_BEGIN) + sizeof (HTTP_END) - 3; ===== header, ehich is subsequently used in a call to strlen, is not checked for validity. In addition, there does not appear to be documentation for peer_print_info, so its unclear if Null/Empty values are acceptable to the function. >From the Open Group Base Specifications for strlen(), it appears no constraints are placed on the string 's' and no errors are defined for the function, which implies all arguments - including NULL - are acceptable. Yet a test program faults on GNU Linux with a NULL argument: Program received signal SIGSEGV, Segmentation fault. __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31 31 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory. in ../sysdeps/x86_64/multiarch/../strlen.S (gdb) bt full #0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31 No locals. #1 0x000000000040066b in peer_print_info_kindof (header=0x0, ret_length=0x7fffffffe2ac) at replace-strcpy.c:43 http_buffer = 0x400755 "H\205\355t\034\061\333\017\037@" len = 140737488348072 #2 0x000000000040062b in main (argc=1, argv=0x7fffffffe398) at replace-strcpy.c:14 written = 0 response = 0x7fffffffe390 "\001" (Sorry for not checking ISO C - I don't have a licensed copy of the standard). ===== The header in line 451 is passed in to peer_print_info. Based on the header length, a buffer is allocated. The 5 * 1024 appears to be a heuristic. ===== At line 457, memory is obtained for a HTTP response. The call to malloc is checked for failure. ===== The strcpy's at lines 461, 462, and 463 assume success since the function cannot convey failures. The assumption is then propagated to the caller via the dereference/assignment at line 465. ===== The dereference at line 465 assumes the pointer is valid. ===== If the invocation of peer_print_info is unsuccessful, ret_length could be in an indeterminate state from the caller's perspective. ===== An improved strategy might include changing calls to strcpy with calls to snprintf since snprintf offers deterministic failure: if(ret_length) *ret_length = -1; size_t len = 5 * 1024 + strlen (header); ... size_t len2 = 0; /* scratch */ int count = 0, written = 0; len2 = strlen(DEFAULT_DATA); if(!(len - written >= len2)) { /*handle failure*/ } count = snprintf(&http_buffer[written], len-written, "%s", DEFAULT_DATA); if(count < 0) { /*handle failure*/ } written += count; ... if(ret_length) *ret_length = written; _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Fri 19 Nov 2010 03:03:42 AM GMT Name: peer_print_info_kindof.c Size: 3kB By: noloader _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 19 07:22:58 2010 From: INVALID.NOREPLY at gnu.org (Simon Josefsson) Date: Fri, 19 Nov 2010 06:22:58 +0000 Subject: [sr #107524] Test suite: gnutls_global_init/gnutls_global_deinit In-Reply-To: <20101118-115955.sv80862.42903@savannah.gnu.org> References: <20101118-100108.sv80862.92544@savannah.gnu.org> <20101118-115752.sv80862.70845@savannah.gnu.org> <20101118-115955.sv80862.42903@savannah.gnu.org> Message-ID: <20101119-062258.sv7213.84357@savannah.gnu.org> Follow-up Comment #3, sr #107524 (project gnutls): These leaks are all in libgcrypt as far as I can tell? Further, they are known (and from what I can tell from Werner, intentional). There is a libgcrypt.supp valgrind file in tests/libgcrypt.supp you could you use. You are better of installing and using nettle instead of libgcrypt, though, since that will be the default crypto library for the next release. It doesn't leak memory by default. /Simon _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 19 07:35:08 2010 From: INVALID.NOREPLY at gnu.org (Simon Josefsson) Date: Fri, 19 Nov 2010 06:35:08 +0000 Subject: [sr #107527] Use of dangerous/banned functions (Analysis) In-Reply-To: <20101119-030342.sv80862.45182@savannah.gnu.org> References: <20101119-030342.sv80862.45182@savannah.gnu.org> Message-ID: <20101119-063507.sv7213.93644@savannah.gnu.org> Follow-up Comment #1, sr #107527 (project gnutls): You make several points in this bug report, and it is difficult to followup on each one -- could you enumerate each problem you have identified? Some of it is discussion, and that is more useful on the list. Also your line numbers are way off, you should use master unless you have found a clear security issue that must be fixed in the stable 2.10.x branch. We don't apply any non-critical fixes on the stable branch. /Simon _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 19 07:35:27 2010 From: INVALID.NOREPLY at gnu.org (Simon Josefsson) Date: Fri, 19 Nov 2010 06:35:27 +0000 Subject: [sr #107513] [PATCH] lib/gnutls_x509.c: remove redundant check In-Reply-To: <20101112-005808.sv707.91444@savannah.gnu.org> References: <20101111-220156.sv40933.98456@savannah.gnu.org> <20101112-005808.sv707.91444@savannah.gnu.org> Message-ID: <20101119-063527.sv7213.54451@savannah.gnu.org> Update of sr #107513 (project gnutls): Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 19 07:26:38 2010 From: INVALID.NOREPLY at gnu.org (Simon Josefsson) Date: Fri, 19 Nov 2010 06:26:38 +0000 Subject: [sr #107525] Use of dangerous/banned functions (Particular Instances) In-Reply-To: <20101119-000016.sv80862.1214@savannah.gnu.org> References: <20101119-000016.sv80862.1214@savannah.gnu.org> Message-ID: <20101119-062638.sv7213.29249@savannah.gnu.org> Follow-up Comment #1, sr #107525 (project gnutls): I think all the places you noted could warrant more careful code reading and potential improvements if there is any chance of errors -- patches welcome. /Simon _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From noloader at gmail.com Fri Nov 19 07:46:40 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 19 Nov 2010 01:46:40 -0500 Subject: [sr #107527] Use of dangerous/banned functions (Analysis) In-Reply-To: <20101119-063507.sv7213.93644@savannah.gnu.org> References: <20101119-030342.sv80862.45182@savannah.gnu.org> <20101119-063507.sv7213.93644@savannah.gnu.org> Message-ID: On Fri, Nov 19, 2010 at 1:35 AM, Simon Josefsson wrote: > > Follow-up Comment #1, sr #107527 (project gnutls): > > You make several points in this bug report, and it is difficult to followup > on each one -- could you enumerate each problem you have identified? ?Some of > it is discussion, and that is more useful on the list. > > Also your line numbers are way off, you should use master unless you have > found a clear security issue that must be fixed in the stable 2.10.x branch. > We don't apply any non-critical fixes on the stable branch. Gotcha. My apologies - path of least resistance. I have not been able to complete a configure/make cycle on the bleeding edge gear, and I like to limit my number of [dumb] questions so the well does not dry up :( Jeff From INVALID.NOREPLY at gnu.org Fri Nov 19 09:50:12 2010 From: INVALID.NOREPLY at gnu.org (Tomas Hoger) Date: Fri, 19 Nov 2010 08:50:12 +0000 Subject: [sr #107527] Use of dangerous/banned functions (Analysis) In-Reply-To: <20101119-063507.sv7213.93644@savannah.gnu.org> References: <20101119-030342.sv80862.45182@savannah.gnu.org> <20101119-063507.sv7213.93644@savannah.gnu.org> Message-ID: <20101119-085011.sv73003.11981@savannah.gnu.org> Follow-up Comment #2, sr #107527 (project gnutls): > This SR will analyze the code around a cluster of calls to > strcpy in serv.c. The lines of interest in peer_print_info > (from the SR $107525 audit) are: > > 451: size_t len = 5 * 1024 + strlen (header); > 457: http_buffer = malloc (len); > ... > > 461: strcpy (http_buffer, HTTP_BEGIN); > 462: strcpy (&http_buffer[sizeof (HTTP_BEGIN) - 1], DEFAULT_DATA); > 463: strcpy (&http_buffer[sizeof (HTTP_BEGIN) + sizeof (DEFAULT_DATA) - 2], HTTP_END); > 465: *ret_length = sizeof (DEFAULT_DATA) + sizeof (HTTP_BEGIN) + sizeof (HTTP_END) - 3; This code block copies 3 hard-coded strings with total length of ~330 characters to buffer that has at least 5*1024 bytes. > From the Open Group Base Specifications for strlen(), it > appears no constraints are placed on the string 's' and no > errors are defined for the function, which implies all > arguments - including NULL - are acceptable. Yet a test > program faults on GNU Linux with a NULL argument: Right, so you can crash your test program by doing strlen(NULL). You can check get_response() to see if peer_print_info() can ever be called with NULL header. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Fri Nov 19 13:55:28 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 19 Nov 2010 13:55:28 +0100 Subject: GnuTLS 2.10.3 released Message-ID: <4CE673C0.2080305@gnutls.org> I've just released gnutls 2.10.3. It is a bugfix release. What's New ========== ** libgnutls: Correctly add leading zero to PKCS #8 encoded DSA key. Reported by Jeffrey Walton. ** libgnutls: Corrected memory leak in extension data calculation. Reported by Mike Blumenkrantz. ** libgnutls: Remove trailing comma in enums in gnutls.h and x509.h. ** 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 BZIP2 compressed sources (7.2MB): ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.2.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.2.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.2.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.2.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 uid Nikos Mavrogiannopoulos 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 Nov 19 14:03:49 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 19 Nov 2010 14:03:49 +0100 Subject: GnuTLS 2.10.3 released In-Reply-To: <4CE673C0.2080305@gnutls.org> References: <4CE673C0.2080305@gnutls.org> Message-ID: <4CE675B5.9080400@gnutls.org> On 11/19/2010 01:55 PM, Nikos Mavrogiannopoulos wrote: And those are the correct links for this release! ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.3.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.3.tar.bz2 ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.3.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.3.tar.bz2.sig From ametzler at downhill.at.eu.org Sat Nov 20 15:53:16 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 20 Nov 2010 15:53:16 +0100 Subject: [SCM] GNU gnutls branch, gnutls_2_10_x, updated. gnutls_2_10_0-9-g301635a In-Reply-To: <4C3CA3C4.3090702@gnutls.org> References: <87zkxv71ac.fsf@mocca.josefsson.org> <4C3CA3C4.3090702@gnutls.org> Message-ID: <20101120145316.GA14854@downhill.g.la> On 2010-07-13 Nikos Mavrogiannopoulos wrote: > Simon Josefsson wrote: >> "Nikos Mavrogiannopoulos" writes: >>> + gnutls_certificate_set_verify_flags(xcred, GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT); >> What was the reason for this change? Do we want to do this >> unconditionally? Maybe we could introduce a --permit-v1-cas flag? I'd >> rather prefer to treat V1 CAs as broken-by-default... > There is no practical problem with having V1 root CAs, the problem is > with the intermediate (untrusted) and this flag allows only root CAs. If > disabled it fails to verify a large fraction of any root CA list. A flag > that would disallow them would offer the functionality you say, but I > don't think it should be the default (not today with this large set of > V1 CAs at least). [...] Hello, I have stumbled upon gnutls-cli's changed behavior today and could not find anything in NEWS or Changelog about a policy change. If this stays in, please document it. (simple patch attached, perhaps the manpage should say so, too.) Also I think different default values in gnutls-the-library and gnutls-cli are confusing. ("My gnutls using app has problem x" - "Please try to reproduce with gnutls-cli" - "Cannot.") Either GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT is a more sensible default value (AFAIK OpenSSL is using it, and about 50% of all TLS certificates are signed by V1 CAs, e.g. Go Daddy.) or not. If GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT is truely evil gnutls-cli should not use it by default. cu andreas From ametzler at downhill.at.eu.org Sat Nov 20 15:55:59 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 20 Nov 2010 15:55:59 +0100 Subject: [SCM] GNU gnutls branch, gnutls_2_10_x, updated. gnutls_2_10_0-9-g301635a In-Reply-To: <20101120145316.GA14854@downhill.g.la> References: <87zkxv71ac.fsf@mocca.josefsson.org> <4C3CA3C4.3090702@gnutls.org> <20101120145316.GA14854@downhill.g.la> Message-ID: <20101120145559.GB14854@downhill.g.la> On 2010-11-20 Andreas Metzler wrote: [...] > simple patch attached, perhaps the manpage > should say so, too.) [...] attaching. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Document-gnutls-cli-V1-CA-policy-change.patch Type: text/x-diff Size: 1429 bytes Desc: not available URL: From simon at josefsson.org Sun Nov 21 13:17:02 2010 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 21 Nov 2010 13:17:02 +0100 Subject: GnuTLS 2.10.3 released In-Reply-To: <4CE673C0.2080305@gnutls.org> (Nikos Mavrogiannopoulos's message of "Fri, 19 Nov 2010 13:55:28 +0100") References: <4CE673C0.2080305@gnutls.org> Message-ID: <871v6ex45d.fsf@latte.josefsson.org> Nikos Mavrogiannopoulos writes: > I've just released gnutls 2.10.3. It is a bugfix release. I can't find any git tag for this release? Also, the NEWS file needs to be updated to include the release date. /Simon From simon at josefsson.org Sun Nov 21 16:38:42 2010 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 21 Nov 2010 16:38:42 +0100 Subject: 64 bit OpenSSL API In-Reply-To: (Jeffrey Walton's message of "Sun, 21 Nov 2010 09:36:39 -0500") References: Message-ID: <87fwuuvg8t.fsf@latte.josefsson.org> Jeffrey Walton writes: > Hey Guys, > > Were you guys aware of "64bit BIOs and support in OpenSSL", > http://marc.info/?l=openssl-users&m=128621823121551? > > It might make a good topic for Compare/Contrast. GnuTLS doesn't have anything directly comparable to BIO, and there shouldn't be any problems with 64-bit streams with GnuTLS. /Simon From simon at josefsson.org Sun Nov 21 16:57:52 2010 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 21 Nov 2010 16:57:52 +0100 Subject: 64 bit OpenSSL API In-Reply-To: (Jeffrey Walton's message of "Sun, 21 Nov 2010 10:48:49 -0500") References: <87fwuuvg8t.fsf@latte.josefsson.org> Message-ID: <87bp5izn27.fsf@latte.josefsson.org> Jeffrey Walton writes: > On Sun, Nov 21, 2010 at 10:38 AM, Simon Josefsson wrote: >> Jeffrey Walton writes: >> >>> Hey Guys, >>> >>> Were you guys aware of "64bit BIOs and support in OpenSSL", >>> http://marc.info/?l=openssl-users&m=128621823121551? >>> >>> It might make a good topic for Compare/Contrast. >> >> GnuTLS doesn't have anything directly comparable to BIO, and there >> shouldn't be any problems with 64-bit streams with GnuTLS. > I've been working through client examples at > http://www.gnu.org/software/gnutls/manual/html_node/Client-examples.html#Client-examples. > I noticed GnuTLS returned ssize_t's, which made me think of OpenSSL's > BIO problems. That is the appropriate type to use for supporting 64-bit (or larger) objects. Btw, please keep cc to the mailing list for GnuTLS discussions. /Simon From noloader at gmail.com Sun Nov 21 17:02:25 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 21 Nov 2010 11:02:25 -0500 Subject: 64 bit OpenSSL API In-Reply-To: <87bp5izn27.fsf@latte.josefsson.org> References: <87fwuuvg8t.fsf@latte.josefsson.org> <87bp5izn27.fsf@latte.josefsson.org> Message-ID: On Sun, Nov 21, 2010 at 10:57 AM, Simon Josefsson wrote: > Jeffrey Walton writes: > >> On Sun, Nov 21, 2010 at 10:38 AM, Simon Josefsson wrote: >>> Jeffrey Walton writes: >>> >>>> Hey Guys, >>>> >>>> Were you guys aware of "64bit BIOs and support in OpenSSL", >>>> http://marc.info/?l=openssl-users&m=128621823121551? >>>> >>>> It might make a good topic for Compare/Contrast. >>> >>> GnuTLS doesn't have anything directly comparable to BIO, and there >>> shouldn't be any problems with 64-bit streams with GnuTLS. >> I've been working through client examples at >> http://www.gnu.org/software/gnutls/manual/html_node/Client-examples.html#Client-examples. >> I noticed GnuTLS returned ssize_t's, which made me think of OpenSSL's >> BIO problems. > > That is the appropriate type to use for supporting 64-bit (or larger) > objects. Agreed. > Btw, please keep cc to the mailing list for GnuTLS discussions. No problem, but it was not meant for general discussion. Jeff From nikias at gmx.li Mon Nov 22 00:17:23 2010 From: nikias at gmx.li (Nikias Bassen) Date: Mon, 22 Nov 2010 00:17:23 +0100 Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice Message-ID: <20101122001723.70acc8e0@i7katze> Hi, I'm a leading developer of libimobiledevice (http://libimobiledevice.org/) and we are facing a GnuTLS issue. The lockdown protocol is initializing an SSLv3 session and since iOS 4.2 the handshake fails when using GnuTLS. Further investigation showed that the error is GNUTLS_E_FATAL_ALERT_RECEIVED -12, Error: Could not negotiate a supported cipher suite. However, I replaced the appropiate ssl code using OpenSSL and got it working. Debugging output showed that the cipher is AES256-SHA, but surprisingly this is the same cipher that we have with pre-4.2 devices using GnuTLS. We have no clue what might be wrong here as it has been working since 4.2b arrived, so I'd like to ask if anyone here might be able to help us investigating this issue? Tell me what info you need and I'll get it for you. The device is the server and libimobiledevice code the client side of the communication. Our code is here: http://cgit.sukimashita.com/libimobiledevice.git/ The SSL code is in src/idevice.c, the handshake is implemented in idevice_connection_enable_ssl(). If you have questions about the code just ask. You can reach us in #libimobiledevice on FreeNode too. Regards, Nikias From graham.gower at gmail.com Mon Nov 22 07:29:56 2010 From: graham.gower at gmail.com (Graham Gower) Date: Mon, 22 Nov 2010 16:59:56 +1030 Subject: parallel build failure(s) Message-ID: <4CEA0DE4.5040304@gmail.com> Hi, I'm using openembedded to cross build gnutls 2.10.2 and have seen a build failure which looks like its caused by missing dependencies in guile/src/Makefile.am. I am building with make -j 12. My failure: http://tinderbox.openembedded.net/public/logs/task/10751151.txt Another, similar failure: http://tinderbox.openembedded.net/public/logs/task/7589267.txt Its clear to me that the failures are due to the header file not being fully created before the guile-snarf process is invoked. I suspect something like the below patch may be the solution, but as I'm unable to easily reproduce the failure, I cannot reliably test it. -Graham diff --git a/guile/src/Makefile.am.orig b/guile/src/Makefile.am index e8e81b1..2ee1297 100644 --- a/guile/src/Makefile.am.orig +++ b/guile/src/Makefile.am @@ -122,7 +122,7 @@ extra-smob-types.i.c: $(srcdir)/make-smob-types.scm snarfcppopts = $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \ $(CFLAGS) $(AM_CFLAGS) $(GUILE_CFLAGS) -.c.x: +.c.x: $(BUILT_SOURCES) $(guile_snarf) -o $@ $< $(snarfcppopts) # Target used by doc/Makefile, to create all built sources necessary From INVALID.NOREPLY at gnu.org Mon Nov 22 09:07:28 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Mon, 22 Nov 2010 08:07:28 +0000 Subject: [sr #107532] gnutls-cli-debug [incorrecttly] reports SRP support for Windows Server 2003/IIS 6.0 Message-ID: <20101122-080727.sv80862.97307@savannah.gnu.org> URL: Summary: gnutls-cli-debug [incorrecttly] reports SRP support for Windows Server 2003/IIS 6.0 Project: GnuTLS Submitted by: noloader Submitted on: Mon 22 Nov 2010 08:07:27 AM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: I believe "Checking for SRP authentication support (TLS extension)... yes' is incorrect. The actual target of the probe was redacted below. $ gnutls-cli-debug -p 443 www.example.com Resolving 'www.example.com'... Connecting to 'www.xxx.yyy.zzz:443'... Checking for TLS 1.1 support... no Checking fallback from TLS 1.1 to... TLS 1.0 Checking for TLS 1.0 support... yes Checking for SSL 3.0 support... yes Checking for HTTPS server name... not checked Checking for version rollback bug in RSA PMS... no Checking for version rollback bug in Client Hello... no Checking whether we need to disable TLS 1.0... N/A Checking whether the server ignores the RSA PMS version... yes Checking whether the server can accept Hello Extensions... yes Checking whether the server can accept cipher suites not in SSL 3.0 spec... yes Checking whether the server can accept a bogus TLS record version in the client hello... yes Checking for certificate information... N/A Checking for trusted CAs... N/A Checking whether the server understands TLS closure alerts... no Checking whether the server supports session resumption... yes Checking for export-grade ciphersuite support... yes Checking RSA-export ciphersuite info... N/A Checking for anonymous authentication support... no Checking anonymous Diffie-Hellman group info... N/A Checking for ephemeral Diffie-Hellman support... no Checking ephemeral Diffie-Hellman group info... N/A Checking for AES cipher support (TLS extension)... no Checking for CAMELLIA cipher support (TLS extension)... no Checking for 3DES cipher support... yes Checking for ARCFOUR 128 cipher support... yes Checking for ARCFOUR 40 cipher support... yes Checking for MD5 MAC support... yes Checking for SHA1 MAC support... yes Checking for LZO compression support (GnuTLS extension)... no Checking for max record size (TLS extension)... no Checking for SRP authentication support (TLS extension)... yes Checking for OpenPGP authentication support (TLS extension)... no _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Nov 22 09:45:42 2010 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 22 Nov 2010 08:45:42 +0000 Subject: [sr #107532] gnutls-cli-debug [incorrecttly] reports SRP support for Windows Server 2003/IIS 6.0 In-Reply-To: <20101122-080727.sv80862.97307@savannah.gnu.org> References: <20101122-080727.sv80862.97307@savannah.gnu.org> Message-ID: <20101122-104542.sv707.20460@savannah.gnu.org> Follow-up Comment #1, sr #107532 (project gnutls): Is this the output of 2.11.x gnutls-cli? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From steffen.jaeckel at stzedn.de Mon Nov 22 09:58:57 2010 From: steffen.jaeckel at stzedn.de (Steffen Jaeckel) Date: Mon, 22 Nov 2010 09:58:57 +0100 Subject: [sr #107532] gnutls-cli-debug [incorrecttly] reports SRP support for Windows Server 2003/IIS 6.0 In-Reply-To: <20101122-080727.sv80862.97307@savannah.gnu.org> References: <20101122-080727.sv80862.97307@savannah.gnu.org> Message-ID: <605929204.20101122095857@stzedn.de> The gnutls-cli-debug should be revised in my opinion. e.g. in testcase "Checking for version rollback bug in RSA PMS..." are also DHE cipher suites set and if the server prefers them, the testcase will fail even if the server hasn't that bug. btw. that's why I wanted to build gnutls on my windows machine, to revise the gnutls-cli-debug, but since it doesn't work for me... :/ -----Original Message----- From: Jeffrey Walton [mailto:INVALID.NOREPLY at gnu.org] Sent: Montag, 22. November 2010 09:07:28 To: noloader at gmail.com Subject: [sr #107532] gnutls-cli-debug [incorrecttly] reports SRP support for Windows Server 2003/IIS 6.0 > URL: > > Summary: gnutls-cli-debug [incorrecttly] reports SRP support > for Windows Server 2003/IIS 6.0 > Project: GnuTLS > Submitted by: noloader > Submitted on: Mon 22 Nov 2010 08:07:27 AM GMT > Category: None > Priority: 5 - Normal > Severity: 3 - Normal > Status: None > Privacy: Public > Assigned to: None > Originator Email: > Open/Closed: Open > Discussion Lock: Any > Operating System: None > _______________________________________________________ > Details: > I believe "Checking for SRP authentication support (TLS extension)... yes' is > incorrect. The actual target of the probe was redacted below. > $ gnutls-cli-debug -p 443 www.example.com > Resolving 'www.example.com'... > Connecting to 'www.xxx.yyy.zzz:443'... > Checking for TLS 1.1 support... no > Checking fallback from TLS 1.1 to... TLS 1.0 > Checking for TLS 1.0 support... yes > Checking for SSL 3.0 support... yes > Checking for HTTPS server name... not checked > Checking for version rollback bug in RSA PMS... no > Checking for version rollback bug in Client Hello... no > Checking whether we need to disable TLS 1.0... N/A > Checking whether the server ignores the RSA PMS version... yes > Checking whether the server can accept Hello Extensions... yes > Checking whether the server can accept cipher suites not in SSL 3.0 spec... > yes > Checking whether the server can accept a bogus TLS record version in the > client hello... yes > Checking for certificate information... N/A > Checking for trusted CAs... N/A > Checking whether the server understands TLS closure alerts... no > Checking whether the server supports session resumption... yes > Checking for export-grade ciphersuite support... yes > Checking RSA-export ciphersuite info... N/A > Checking for anonymous authentication support... no > Checking anonymous Diffie-Hellman group info... N/A > Checking for ephemeral Diffie-Hellman support... no > Checking ephemeral Diffie-Hellman group info... N/A > Checking for AES cipher support (TLS extension)... no > Checking for CAMELLIA cipher support (TLS extension)... no > Checking for 3DES cipher support... yes > Checking for ARCFOUR 128 cipher support... yes > Checking for ARCFOUR 40 cipher support... yes > Checking for MD5 MAC support... yes > Checking for SHA1 MAC support... yes > Checking for LZO compression support (GnuTLS extension)... no > Checking for max record size (TLS extension)... no > Checking for SRP authentication support (TLS extension)... yes > Checking for OpenPGP authentication support (TLS extension)... no > _______________________________________________________ > Reply to this item at: > > _______________________________________________ > Message sent via/by Savannah > http://savannah.gnu.org/ > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel From INVALID.NOREPLY at gnu.org Mon Nov 22 10:30:59 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Mon, 22 Nov 2010 09:30:59 +0000 Subject: [sr #107532] gnutls-cli-debug [incorrecttly] reports SRP support for Windows Server 2003/IIS 6.0 In-Reply-To: <20101122-104542.sv707.20460@savannah.gnu.org> References: <20101122-080727.sv80862.97307@savannah.gnu.org> <20101122-104542.sv707.20460@savannah.gnu.org> Message-ID: <20101122-093059.sv80862.26667@savannah.gnu.org> Follow-up Comment #2, sr #107532 (project gnutls): > Is this the output of 2.11.x gnutls-cli? Good question. I managed to shoot myself out of the water since reporting and your subsequent question. Below are the effects of a 'configure/make/make install' cycle from the bleeding edge gear fetched with git. Jeff $ gnutls-cli-debug --version gnutls-cli-debug: /usr/lib/libgnutls.so.26: version `GNUTLS_2_12' not found (required by gnutls-cli-debug) _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnu.org Mon Nov 22 11:03:15 2010 From: nmav at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 22 Nov 2010 11:03:15 +0100 Subject: [sr #107532] gnutls-cli-debug [incorrecttly] reports SRP support for Windows Server 2003/IIS 6.0 In-Reply-To: <20101122-093059.sv80862.26667@savannah.gnu.org> References: <20101122-080727.sv80862.97307@savannah.gnu.org> <20101122-104542.sv707.20460@savannah.gnu.org> <20101122-093059.sv80862.26667@savannah.gnu.org> Message-ID: Most probably you need to run ldconfig or so. regards, Nikos On Mon, Nov 22, 2010 at 10:30 AM, Jeffrey Walton wrote: > > Follow-up Comment #2, sr #107532 (project gnutls): > >> Is this the output of 2.11.x gnutls-cli? > Good question. I managed to shoot myself out of the water since reporting and > your subsequent question. > > Below are the effects of a 'configure/make/make install' cycle from the > bleeding edge gear fetched with git. > > Jeff > > $ gnutls-cli-debug --version > gnutls-cli-debug: /usr/lib/libgnutls.so.26: version `GNUTLS_2_12' not found > (required by gnutls-cli-debug) > > > ? ?_______________________________________________________ > > Reply to this item at: > > ? > > _______________________________________________ > ?Message sent via/by Savannah > ?http://savannah.gnu.org/ > > > From INVALID.NOREPLY at gnu.org Mon Nov 22 11:53:21 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Mon, 22 Nov 2010 10:53:21 +0000 Subject: [sr #107532] gnutls-cli-debug [incorrecttly] reports SRP support for Windows Server 2003/IIS 6.0 In-Reply-To: <20101122-093059.sv80862.26667@savannah.gnu.org> References: <20101122-080727.sv80862.97307@savannah.gnu.org> <20101122-104542.sv707.20460@savannah.gnu.org> <20101122-093059.sv80862.26667@savannah.gnu.org> Message-ID: <20101122-105321.sv80862.69033@savannah.gnu.org> Follow-up Comment #3, sr #107532 (project gnutls): Hi Nikos, > Is this the output of 2.11.x gnutls-cli? I believe it was a distribution's version (Ubuntu). I suspect it was 2.8.5, but don't know for sure. I performed the process of installing Nettle and GnuTLS a second time. Instead of make bootstrap (per http://git.savannah.gnu.org/cgit/gnutls.git/tree/README-alpha), I used configure this time around. gnutls-cli-debug now runs and claims version 2.11.5. Jeff _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From simon at josefsson.org Mon Nov 22 12:56:11 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 22 Nov 2010 12:56:11 +0100 Subject: README patch In-Reply-To: (Jeffrey Walton's message of "Mon, 22 Nov 2010 06:32:20 -0500") References: Message-ID: <87wro58td0.fsf@latte.josefsson.org> Jeffrey Walton writes: > Hi Guys, > > Here's my first attempt at contributing to the project. Its probably > pretty boring stuff for you guys, but it was a lot of lessons learned > for me. Hopefully it will help others in a similar situation. > > I did not know the best way to submit the patch. A Google search of > 'GnuTLS patch' showed hits from other sites (and not gnu.org), so I'm > guessing patches are emailed. I can't imagine I'm allowed to > check-in, so I did not even bother with looking up the git commands. Thanks -- the best way to submit a patch is to send git-format-patch output, against up-to-date master. There is also the section in the manual about this: http://www.gnu.org/software/gnutls/manual/html_node/Contributing.html It could also use some improvements, specifically mention git. And remove ChangeLog, we generate it from git log. > The paperwork was mailed back to FSF on Saturday. If the paperwork is > not yet on file, then I place the changes included in the patch in > public domain. Having it sent is good enough. Your patch looks good generally, but some specific comments below. Please send an updated patch and we'll install it. > +See the end of this documentfor copying conditions. ^ typo > +COMPILATION > +----------- > + > +A complete list of options available for configure can be found > +by running './configure --help'. Additional options can sometimes > +be found by inspecting configure.ac. Looking at configure.ac should never be needed, and may be confusing since we have multiple configure.ac's. Do you have some example when ./configure --help isn't enough and looking at configure.ac helps? I suggest to drop the last sentence above -- we don't want normal users go looking in configure.ac. > In case you are compiling for > +an embedded system, you should disable unneeded features of GnuTLS. s/should/can/ -- the best is to not disable anything. > +A typical command sequence for building the library is shown below. > + > + cd gnutls-2.10.3 > + ./configure --prefix=/usr > + make > + sudo make install > + > +The commands will build and install both the static archive > +(libnettle.a), the shared object (libnettle.so), and additional > +tools such as certtool and gnutls-cli. That should be libgnutls.a, libgnutls-extra.a instead of libnettle.a, and libgnutls.so, libgnutls-extra.so instead of libnettle.so. > +The librar depends on libgcrypt and/or libnettle. You can find ^ ^^^^ Libgcrypt vs libnettle is OR, never AND. Since libnettle is the default, it should probably be mentioned before libgcrypt. > +libgcrypt at . Note > +that by compiling libgcrypt with CPU optimizations gnutls' speed > +will increase. > + > +Nettle can be found at http://www.lysator.liu.se/~nisse/nettle/. Maybe we should point to http://www.gnu.org/software/nettle/ as that is more likely to be a stable URL. > +To configure libnettle for installation and use by GnuTLS, a typical > +command sequence would be: > + > + cd nettle-2.1 > + ./configure --prefix=/usr --disable-openssl --enable-shared > + make > + sudo make install > + > +Note that --enable-shared will have automake and friends build and > +install both the static archive (libnettle.a) and the shared object > +(libnettle.so). I'm not sure this makes sense in the _GnuTLS_ readme at all. Maybe you could submit this to libnettle? Isn't --enable-shared the default? > +Depending on your installation, additinal libraries may be required. ^ typo, add 'o' > +See README-alpha and http://www.gnu.org/software/gnutls/devel.html > +for additional information. We shouldn't point to these resources here, I think, they are for developers. How about just saying that libtasn1 and zlib are additional, optional, dependencies? > LICENSE ISSUES > -------------- > > -Since the 0.4.2 version the gnutls library is covered under the GNU > -Lesser GPL. Previously released versions were licensed under the GNU > -GPL. > - > -We changed the license for most of GnuTLS because other free libraries > -already exist that do the same jobs and have lax licenses. We want > -GnuTLS to be usable in all the same places as those other libraries. > -We kept some parts of GnuTLS under the GPL because they are unique, > -and with the GPL they provide free software projects (which deserve > -our help) an advantage over non-free projects (which do not deserve > -our help, since they refuse to share with us). For more explanation, > -see http://www.gnu.org/philosophy/why-not-lgpl.html. > +Since version 0.4.2, the GnuTLS library has been released under the GNU > +Lesser General Public License (LGPL). Previous versions were licensed > +under the GNU General Public License (GPL). > + > +We changed the license for most of the GnuTLS components because other > +free libraries exist and offer similar functionality with fewer > +restrcitions. 'fewer restrictions' is a bit biased, some may view other free libraries licenses as problematic -- compare the advertisement clause in the OpenSSL license. I suggest to retain the old wording, and thus do 's/fewer restrictions/lax license/'. > +PATCHES > +------- > +Patches are welcome and encouraged. When submitting patches, please be sure > +to use sources from the Git repositiory. To create a patch for the project, > +please use the following command. > + > + diff --unified FILE-original.c FILE-changed.c > FILE.patch Let's suggest git-format-patch instead, since that retains authorship, date, and includes a commit message too. /Simon From noloader at gmail.com Mon Nov 22 13:01:36 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 22 Nov 2010 07:01:36 -0500 Subject: README patch In-Reply-To: <87wro58td0.fsf@latte.josefsson.org> References: <87wro58td0.fsf@latte.josefsson.org> Message-ID: Hi Simon, Thanks for the feedback. I'll get the issues fixed shortly for the project. > Let's suggest git-format-patch instead, since that retains authorship, > date, and includes a commit message too. Even better. Would you be able to share the command(s)? I'm an SVN guy. So I have not yet suffered the Git learning curve. Sorry about the top post. It was easier to pluck out the one item of interest. Jeff On Mon, Nov 22, 2010 at 6:56 AM, Simon Josefsson wrote: > Jeffrey Walton writes: > >> Hi Guys, >> >> Here's my first attempt at contributing to the project. Its probably >> pretty boring stuff for you guys, but it was a lot of lessons learned >> for me. Hopefully it will help others in a similar situation. >> >> I did not know the best way to submit the patch. ?A Google search of >> 'GnuTLS patch' showed hits from other sites (and not gnu.org), so I'm >> guessing patches are emailed. ?I can't imagine I'm allowed to >> check-in, so I did not even bother with looking up the git commands. > > Thanks -- the best way to submit a patch is to send git-format-patch > output, against up-to-date master. ?There is also the section in the > manual about this: > > http://www.gnu.org/software/gnutls/manual/html_node/Contributing.html > > It could also use some improvements, specifically mention git. ?And > remove ChangeLog, we generate it from git log. > >> The paperwork was mailed back to FSF on Saturday. If the paperwork is >> not yet on file, then I place the changes included in the patch in >> public domain. > > Having it sent is good enough. > > Your patch looks good generally, but some specific comments below. > Please send an updated patch and we'll install it. > >> +See the end of this documentfor copying conditions. > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ > > typo > >> +COMPILATION >> +----------- >> + >> +A complete list of options available for configure can be found >> +by running './configure --help'. ?Additional options can sometimes >> +be found by inspecting configure.ac. > > Looking at configure.ac should never be needed, and may be confusing > since we have multiple configure.ac's. ?Do you have some example when > ./configure --help isn't enough and looking at configure.ac helps? ?I > suggest to drop the last sentence above -- we don't want normal users go > looking in configure.ac. > >> ?In case you are compiling for >> +an embedded system, you should disable unneeded features of GnuTLS. > > s/should/can/ -- the best is to not disable anything. > >> +A typical command sequence for building the library is shown below. >> + >> + ? ?cd gnutls-2.10.3 >> + ? ?./configure --prefix=/usr >> + ? ?make >> + ? ?sudo make install >> + >> +The commands will build and install both the static archive >> +(libnettle.a), the shared object (libnettle.so), and additional >> +tools such as certtool and gnutls-cli. > > That should be libgnutls.a, libgnutls-extra.a instead of libnettle.a, > and libgnutls.so, libgnutls-extra.so instead of libnettle.so. > >> +The librar depends on libgcrypt and/or libnettle. ?You can find > ? ? ? ? ? ? ^ ? ? ? ? ? ? ? ? ? ? ^^^^ > > Libgcrypt vs libnettle is OR, never AND. ?Since libnettle is the > default, it should probably be mentioned before libgcrypt. > >> +libgcrypt at . ?Note >> +that by compiling libgcrypt with CPU optimizations gnutls' speed >> +will increase. >> + >> +Nettle can be found at http://www.lysator.liu.se/~nisse/nettle/. > > Maybe we should point to http://www.gnu.org/software/nettle/ as that is > more likely to be a stable URL. > >> +To configure libnettle for installation and use by GnuTLS, a typical >> +command sequence would be: >> + >> + ? ?cd nettle-2.1 >> + ? ?./configure --prefix=/usr --disable-openssl --enable-shared >> + ? ?make >> + ? ?sudo make install >> + >> +Note that --enable-shared will have automake and friends build and >> +install both the static archive (libnettle.a) and the shared object >> +(libnettle.so). > > I'm not sure this makes sense in the _GnuTLS_ readme at all. ?Maybe you > could submit this to libnettle? > > Isn't --enable-shared the default? > >> +Depending on your installation, additinal libraries may be required. > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^ typo, add 'o' > >> +See README-alpha and http://www.gnu.org/software/gnutls/devel.html >> +for additional information. > > We shouldn't point to these resources here, I think, they are for > developers. ?How about just saying that libtasn1 and zlib are > additional, optional, dependencies? > >> ?LICENSE ISSUES >> ?-------------- >> >> -Since the 0.4.2 version the gnutls library is covered under the GNU >> -Lesser GPL. Previously released versions were licensed under the GNU >> -GPL. >> - >> -We changed the license for most of GnuTLS because other free libraries >> -already exist that do the same jobs and have lax licenses. ?We want >> -GnuTLS to be usable in all the same places as those other libraries. >> -We kept some parts of GnuTLS under the GPL because they are unique, >> -and with the GPL they provide free software projects (which deserve >> -our help) an advantage over non-free projects (which do not deserve >> -our help, since they refuse to share with us). ?For more explanation, >> -see http://www.gnu.org/philosophy/why-not-lgpl.html. >> +Since version 0.4.2, the GnuTLS library has been released under the GNU >> +Lesser General Public License (LGPL). ?Previous versions were licensed >> +under the GNU General Public License (GPL). >> + >> +We changed the license for most of the GnuTLS components because other >> +free libraries exist and offer similar functionality with fewer >> +restrcitions. > > 'fewer restrictions' is a bit biased, some may view other free libraries > licenses as problematic -- compare the advertisement clause in the > OpenSSL license. > > I suggest to retain the old wording, and thus do 's/fewer > restrictions/lax license/'. > >> +PATCHES >> +------- >> +Patches are welcome and encouraged. ?When submitting patches, please be sure >> +to use sources from the Git repositiory. ?To create a patch for the project, >> +please use the following command. >> + >> + ? ?diff --unified FILE-original.c FILE-changed.c > FILE.patch > > Let's suggest git-format-patch instead, since that retains authorship, > date, and includes a commit message too. > > /Simon > From simon at josefsson.org Mon Nov 22 15:08:45 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 22 Nov 2010 15:08:45 +0100 Subject: README patch In-Reply-To: (Jeffrey Walton's message of "Mon, 22 Nov 2010 07:01:36 -0500") References: <87wro58td0.fsf@latte.josefsson.org> Message-ID: <87eiad8n82.fsf@latte.josefsson.org> Jeffrey Walton writes: > Hi Simon, > > Thanks for the feedback. I'll get the issues fixed shortly for the project. > >> Let's suggest git-format-patch instead, since that retains authorship, >> date, and includes a commit message too. > Even better. Would you be able to share the command(s)? I'm an SVN > guy. So I have not yet suffered the Git learning curve. > > Sorry about the top post. It was easier to pluck out the one item of interest. See http://git-scm.com/ for example, the commands you need are on the front page: Cloning and Creating a Patch $ git clone git://github.com/git/hello-world.git $ cd hello-world $ (edit files) $ git add (files) $ git commit -m 'Explain what I changed' $ git format-patch origin/master /Simon From INVALID.NOREPLY at gnu.org Mon Nov 22 15:10:37 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Mon, 22 Nov 2010 14:10:37 +0000 Subject: [sr #107533] Proposed changes to README Message-ID: <20101122-141036.sv80862.86138@savannah.gnu.org> URL: Summary: Proposed changes to README Project: GnuTLS Submitted by: noloader Submitted on: Mon 22 Nov 2010 02:10:36 PM GMT Category: None Priority: 5 - Normal Severity: 2 - Minor Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: Attached is a proposed modification to the README file, including recent comments by Simon. Simon: a couple of sections were added since your last comments. The sections are in the same style as the previous sections. Specifically, SECURITY ADVISORIES and MAILING LISTS. Finally, no changes were made to the developers version of the readme (alpha). Jeff _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Mon 22 Nov 2010 02:10:36 PM GMT Name: README.patch Size: 8kB By: noloader _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Nov 22 15:16:32 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Mon, 22 Nov 2010 14:16:32 +0000 Subject: [sr #107533] Proposed changes to README In-Reply-To: <20101122-141036.sv80862.86138@savannah.gnu.org> References: <20101122-141036.sv80862.86138@savannah.gnu.org> Message-ID: <20101122-141632.sv80862.38089@savannah.gnu.org> Follow-up Comment #1, sr #107533 (project gnutls): >> +To configure libnettle for installation and use by GnuTLS, a typical >> +command sequence would be: >> + >> + cd nettle-2.1 >> + ./configure --prefix=/usr --disable-openssl --enable-shared >> + make >> + sudo make install >> + >> +Note that --enable-shared will have automake and friends build and >> +install both the static archive (libnettle.a) and the shared object >> +(libnettle.so). > > I'm not sure this makes sense in the _GnuTLS_ readme at all. > Maybe you could submit this to libnettle? > > Isn't --enable-shared the default? I don't believe '--enable-shared' is default. After a configure/make/make install, I was missing the shared object. So I had to RTFM ('configure --help'). '--disable-openssl' was spotted after RTFM'ing. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Mon Nov 22 18:04:55 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 22 Nov 2010 18:04:55 +0100 Subject: [SCM] GNU gnutls branch, gnutls_2_10_x, updated. gnutls_2_10_0-9-g301635a In-Reply-To: <20101120145316.GA14854@downhill.g.la> References: <87zkxv71ac.fsf@mocca.josefsson.org> <4C3CA3C4.3090702@gnutls.org> <20101120145316.GA14854@downhill.g.la> Message-ID: <4CEAA2B7.202@gnutls.org> On 11/20/2010 03:53 PM, Andreas Metzler wrote: >> There is no practical problem with having V1 root CAs, the problem is >> with the intermediate (untrusted) and this flag allows only root CAs. If >> disabled it fails to verify a large fraction of any root CA list. A flag >> that would disallow them would offer the functionality you say, but I >> don't think it should be the default (not today with this large set of >> V1 CAs at least). > [...] > > Hello, > I have stumbled upon gnutls-cli's changed behavior today and could not > find anything in NEWS or Changelog about a policy change. If this > stays in, please document it. (simple patch attached, perhaps the manpage > should say so, too.) There is a note at: * Version 2.10.1 (released 2010-07-25) [...] ** gnutls-cli: Allow verification using V1 CAs. > Also I think different default values in gnutls-the-library and > gnutls-cli are confusing. ("My gnutls using app has problem x" - > "Please try to reproduce with gnutls-cli" - "Cannot.") Either > GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT is a more sensible default value > (AFAIK OpenSSL is using it, and about 50% of all TLS certificates are > signed by V1 CAs, e.g. Go Daddy.) or not. If > GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT is truely evil gnutls-cli should > not use it by default. Unfortunately this is the API since quite long to be changed. Applications are to set the required for verification flags. A way to solve this would be to make a higher level verification procedure (functionality). It is not on my immediate plans though. regards, Nikos From ametzler at downhill.at.eu.org Mon Nov 22 18:59:12 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon, 22 Nov 2010 18:59:12 +0100 Subject: [SCM] GNU gnutls branch, gnutls_2_10_x, updated. gnutls_2_10_0-9-g301635a In-Reply-To: <4CEAA2B7.202@gnutls.org> References: <87zkxv71ac.fsf@mocca.josefsson.org> <4C3CA3C4.3090702@gnutls.org> <20101120145316.GA14854@downhill.g.la> <4CEAA2B7.202@gnutls.org> Message-ID: <20101122175912.GA3504@downhill.g.la> On 2010-11-22 Nikos Mavrogiannopoulos wrote: > On 11/20/2010 03:53 PM, Andreas Metzler wrote: > >> There is no practical problem with having V1 root CAs, the problem is > >> with the intermediate (untrusted) and this flag allows only root CAs. If > >> disabled it fails to verify a large fraction of any root CA list. A flag > >> that would disallow them would offer the functionality you say, but I > >> don't think it should be the default (not today with this large set of > >> V1 CAs at least). > > [...] > > > > Hello, > > I have stumbled upon gnutls-cli's changed behavior today and could not > > find anything in NEWS or Changelog about a policy change. If this > > stays in, please document it. (simple patch attached, perhaps the manpage > > should say so, too.) > There is a note at: > * Version 2.10.1 (released 2010-07-25) > [...] > ** gnutls-cli: Allow verification using V1 CAs. Hello, isn't "allow" too weak? Even 2.8.6 can do this with the correct options. (--priority NORMAL:%VERIFY_ALLOW_X509_V1_CA_CRT) > > Also I think different default values in gnutls-the-library and > > gnutls-cli are confusing. ("My gnutls using app has problem x" - > > "Please try to reproduce with gnutls-cli" - "Cannot.") Either > > GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT is a more sensible default value > > (AFAIK OpenSSL is using it, and about 50% of all TLS certificates are > > signed by V1 CAs, e.g. Go Daddy.) or not. If > > GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT is truely evil gnutls-cli should > > not use it by default. > Unfortunately this is the API since quite long to be changed. > Applications are to set the required for verification flags. A way to > solve this would be to make a higher level verification procedure > (functionality). It is not on my immediate plans though. Actually the implemented API has changed in the no too distant past, versions before 2.4.3 accepted V1 CA certs. 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 noloader at gmail.com Mon Nov 22 20:27:22 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 22 Nov 2010 14:27:22 -0500 Subject: Add HTML/ to the git repository? Message-ID: Hi All, Would it be possible to add a html/ directory to gnutls/ to promote updates to the site? The pages of interest are [at least] the top levels at http://www.gnu.org/software/gnutls/. Also, if the pages are available via git, the same processes and procedures can be followed which apply to a source code patch. Jeff From noloader at gmail.com Mon Nov 22 20:47:07 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 22 Nov 2010 14:47:07 -0500 Subject: Test files Message-ID: The GNU style guide (http://www.gnu.org/prep/standards/standards.html) does not appear to offer guidance on test suites or test files. http://www.gnu.org/software/gnutls/coverage/ seems to be one page with project test results but no links to additional information. Is there a one-to-one between source files and test files? For example /src/foo.c and /tests/foo.c? Can test files be added at the function level? For example, suppose foo.c includes two functions, bar and baz. Is it appropriate to have test files /tests/foo-bar.c and /tests/foo-baz.c? Is there any additional reading available? Jeff From nmav at gnutls.org Tue Nov 23 10:08:20 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 23 Nov 2010 10:08:20 +0100 Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice In-Reply-To: <20101122001723.70acc8e0@i7katze> References: <20101122001723.70acc8e0@i7katze> Message-ID: I'd suggest that you use the priority_set_direct() function. Check the examples in the gnutls documentation for details. Does gnutls-cli work on the server you are connecting? What is the output of gnutls-cli-debug? regards, Nikos On Mon, Nov 22, 2010 at 12:17 AM, Nikias Bassen wrote: > Hi, > > I'm a leading developer of libimobiledevice (http://libimobiledevice.org/) and > we are facing a GnuTLS issue. The lockdown protocol is initializing an SSLv3 > session and since iOS 4.2 the handshake fails when using GnuTLS. Further > investigation showed that the error is GNUTLS_E_FATAL_ALERT_RECEIVED -12, > Error: Could not negotiate a supported cipher suite. > However, I replaced the appropiate ssl code using OpenSSL and got it working. > Debugging output showed that the cipher is AES256-SHA, but surprisingly this > is the same cipher that we have with pre-4.2 devices using GnuTLS. > > We have no clue what might be wrong here as it has been working since 4.2b > arrived, so I'd like to ask if anyone here might be able to help us > investigating this issue? Tell me what info you need and I'll get it for you. > > The device is the server and libimobiledevice code the client side of the > communication. > > Our code is here: http://cgit.sukimashita.com/libimobiledevice.git/ > The SSL code is in src/idevice.c, the handshake is implemented in > idevice_connection_enable_ssl(). If you have questions about the code just > ask. You can reach us in #libimobiledevice on FreeNode too. > > Regards, > Nikias > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > From nmav at gnutls.org Tue Nov 23 10:15:33 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 23 Nov 2010 10:15:33 +0100 Subject: Add HTML/ to the git repository? In-Reply-To: References: Message-ID: I think it's already there. Check http://savannah.gnu.org/cvs/?group=gnutls and the webpages repository section. regards, Nikos On Mon, Nov 22, 2010 at 8:27 PM, Jeffrey Walton wrote: > Hi All, > > Would it be possible to add a html/ directory to gnutls/ to promote > updates to the site? The pages of interest are [at least] the top > levels at http://www.gnu.org/software/gnutls/. > > Also, if the pages are available via git, the same processes and > procedures can be followed which apply to a source code patch. > > Jeff > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > From noloader at gmail.com Tue Nov 23 10:29:31 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 23 Nov 2010 04:29:31 -0500 Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice In-Reply-To: References: <20101122001723.70acc8e0@i7katze> Message-ID: On Tue, Nov 23, 2010 at 4:08 AM, Nikos Mavrogiannopoulos wrote: > I'd suggest that you use the priority_set_direct() function. Check the examples > in the gnutls documentation for details. Does gnutls-cli work on the server you > are connecting? What is the output of gnutls-cli-debug? An FYI.... I have not been able to get the examples* to work. I've tried connecting to my Windows 2003/IIS 6 machine, and Simon's host at test.gnutls.org:5556. Usually, gnutls_handshake() fails with one of the following (I do a lot of knob turning on failures). In all cases, gnutls_error_is_fatal() is true. GNUTLS_E_UNEXPECTED_PACKET_LENGTH: -9 GNUTLS_E_INVALID_SESSION: -10 GNUTLS_E_FATAL_ALERT_RECEIVED: -12 In my case, both gnutls-cli and gnutls-cli-debug connect and probe the IIS 6.0 host. I seem to recall problem's with Simon's host, though. When I found problems with both hosts, I stopped using Simon's host. I've tried different 'priority direct' strings: "PERFORMANCE:+ANON-DH:!ARCFOUR-128" (from the example) "PERFORMANCE:+VERS-TLS1.0:+ANON-DH:!ARCFOUR-128" "NORMAL:-VERS-TLS1.2:-VERS-TLS1.1:+VERS-TLS1.0:+RSA:+SHA1" "NORMAL:-VERS-TLS1.2:-VERS-TLS1.1:+VERS-TLS1.0:+RSA:+SHA1:+ANON-DH" I've also tried different protocols in calls to gnutls_protocol_set_priority(). My current array is: static const int protocols[] = { /*GNUTLS_TLS1_2, GNUTLS_TLS1_1,*/ GNUTLS_TLS1_0, GNUTLS_SSL3, 0 }; Jeff * Specifically, the first client example (anonymous auth) at http://www.gnu.org/software/gnutls/manual/html_node/Client-examples.html#Client-examples > On Mon, Nov 22, 2010 at 12:17 AM, Nikias Bassen wrote: >> Hi, >> >> I'm a leading developer of libimobiledevice (http://libimobiledevice.org/) and >> we are facing a GnuTLS issue. The lockdown protocol is initializing an SSLv3 >> session and since iOS 4.2 the handshake fails when using GnuTLS. Further >> investigation showed that the error is GNUTLS_E_FATAL_ALERT_RECEIVED -12, >> Error: Could not negotiate a supported cipher suite. >> However, I replaced the appropiate ssl code using OpenSSL and got it working. >> Debugging output showed that the cipher is AES256-SHA, but surprisingly this >> is the same cipher that we have with pre-4.2 devices using GnuTLS. >> >> We have no clue what might be wrong here as it has been working since 4.2b >> arrived, so I'd like to ask if anyone here might be able to help us >> investigating this issue? Tell me what info you need and I'll get it for you. >> >> The device is the server and libimobiledevice code the client side of the >> communication. >> >> Our code is here: http://cgit.sukimashita.com/libimobiledevice.git/ >> The SSL code is in src/idevice.c, the handshake is implemented in >> idevice_connection_enable_ssl(). If you have questions about the code just >> ask. You can reach us in #libimobiledevice on FreeNode too. >> >> Regards, >> Nikias >> From noloader at gmail.com Tue Nov 23 10:38:06 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 23 Nov 2010 04:38:06 -0500 Subject: Add HTML/ to the git repository? In-Reply-To: References: Message-ID: On Tue, Nov 23, 2010 at 4:15 AM, Nikos Mavrogiannopoulos wrote: > I think it's already there. Check http://savannah.gnu.org/cvs/?group=gnutls > and the webpages repository section. http://cvs.savannah.gnu.org/viewvc/gnutls/?root=gnutls is empty (followed 'Browse Source Reop' -> gnutls -> root). On my local git copy, the only [top level] directories I have are: doc, gl, guile, lib, libextra, m4, src, and tests. Jeff > On Mon, Nov 22, 2010 at 8:27 PM, Jeffrey Walton wrote: >> Hi All, >> >> Would it be possible to add a html/ directory to gnutls/ to promote >> updates to the site? The pages of interest are [at least] the top >> levels at http://www.gnu.org/software/gnutls/. >> >> Also, if the pages are available via git, the same processes and >> procedures can be followed which apply to a source code patch. >> >> Jeff >> >> _______________________________________________ >> Gnutls-devel mailing list >> Gnutls-devel at gnu.org >> http://lists.gnu.org/mailman/listinfo/gnutls-devel >> > From nmav at gnutls.org Tue Nov 23 10:44:23 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 23 Nov 2010 10:44:23 +0100 Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice In-Reply-To: References: <20101122001723.70acc8e0@i7katze> Message-ID: On Tue, Nov 23, 2010 at 10:29 AM, Jeffrey Walton wrote: >> I'd suggest that you use the priority_set_direct() function. Check the examples >> in the gnutls documentation for details. Does gnutls-cli work on the server you >> are connecting? What is the output of gnutls-cli-debug? > An FYI.... I have not been able to get the examples* to work. I've > tried connecting to my Windows 2003/IIS 6 machine, and Simon's host at > test.gnutls.org:5556. > Usually, gnutls_handshake() fails with one of the following (I do a > lot of knob turning on failures). In all cases, > gnutls_error_is_fatal() is true. Which client example did you try? Could it be a windows issue (examples are written for posix)? You can check with wireshark the conversation to check if there is some communication issue. regards, Nikos From INVALID.NOREPLY at gnu.org Tue Nov 23 14:18:02 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Tue, 23 Nov 2010 13:18:02 +0000 Subject: [sr #107535] 'make check' - hang after 'PASS: mini-x509-rehandshake' on x64 Ubuntu Message-ID: <20101123-131802.sv80862.87038@savannah.gnu.org> URL: Summary: 'make check' - hang after 'PASS: mini-x509-rehandshake' on x64 Ubuntu Project: GnuTLS Submitted by: noloader Submitted on: Tue 23 Nov 2010 01:18:02 PM 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: None _______________________________________________________ Details: Performed after a fresh git from the repository. Nettle 2.1 was built from sources with same configure. Nettle self tests OK. Below, the CTRL+C was issued after about 15 minutes. Duplicated 3/3 times. Jeff $ uname -a Linux studio 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux $ ./configure --prefix=/usr --enable-shared CFLAGS="-DDEBUG -g3 -ggdb -O0" ... config.status: config.h is unchanged config.status: executing depfiles commands config.status: executing libtool commands configure: summary of build options: version: 2.11.5 shared 44:3:18 Host type: x86_64-unknown-linux-gnu Install prefix: /usr Compiler: gcc -std=gnu99 Warning flags: errors: warnings: Library types: Shared=yes, Static=yes Valgrind: yes valgrind -q Guile wrappers: yes C++ library: yes OpenSSL library: yes /dev/crypto: no Crypto library: nettle $ make ... $ make check ... PASS: mini-x509 ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E4DBA7: _gnutls_writev (gnutls_buffers.c:404) ==22492== by 0x4E4E54A: _gnutls_io_write_flush (gnutls_buffers.c:708) ==22492== by 0x4E4E8C4: _gnutls_handshake_io_write_flush (gnutls_buffers.c:786) ==22492== by 0x4E55137: _gnutls_send_handshake_final (gnutls_handshake.c:2860) ==22492== by 0x4E55ED1: _gnutls_handshake_common (gnutls_handshake.c:3109) ==22492== by 0x4E54870: gnutls_handshake (gnutls_handshake.c:2690) ==22492== by 0x40143E: main (mini-x509-rehandshake.c:211) ==22492== ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E4E552: _gnutls_io_write_flush (gnutls_buffers.c:709) ==22492== by 0x4E4E8C4: _gnutls_handshake_io_write_flush (gnutls_buffers.c:786) ==22492== by 0x4E55137: _gnutls_send_handshake_final (gnutls_handshake.c:2860) ==22492== by 0x4E55ED1: _gnutls_handshake_common (gnutls_handshake.c:3109) ==22492== by 0x4E54870: gnutls_handshake (gnutls_handshake.c:2690) ==22492== by 0x40143E: main (mini-x509-rehandshake.c:211) ==22492== ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E4CE15: _mbuffer_remove_bytes (gnutls_mbuffers.c:190) ==22492== by 0x4E4E568: _gnutls_io_write_flush (gnutls_buffers.c:711) ==22492== by 0x4E4E8C4: _gnutls_handshake_io_write_flush (gnutls_buffers.c:786) ==22492== by 0x4E55137: _gnutls_send_handshake_final (gnutls_handshake.c:2860) ==22492== by 0x4E55ED1: _gnutls_handshake_common (gnutls_handshake.c:3109) ==22492== by 0x4E54870: gnutls_handshake (gnutls_handshake.c:2690) ==22492== by 0x40143E: main (mini-x509-rehandshake.c:211) ==22492== ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E4E5BD: _gnutls_io_write_flush (gnutls_buffers.c:732) ==22492== by 0x4E4E8C4: _gnutls_handshake_io_write_flush (gnutls_buffers.c:786) ==22492== by 0x4E55137: _gnutls_send_handshake_final (gnutls_handshake.c:2860) ==22492== by 0x4E55ED1: _gnutls_handshake_common (gnutls_handshake.c:3109) ==22492== by 0x4E54870: gnutls_handshake (gnutls_handshake.c:2690) ==22492== by 0x40143E: main (mini-x509-rehandshake.c:211) ==22492== ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E5513F: _gnutls_send_handshake_final (gnutls_handshake.c:2861) ==22492== by 0x4E55ED1: _gnutls_handshake_common (gnutls_handshake.c:3109) ==22492== by 0x4E54870: gnutls_handshake (gnutls_handshake.c:2690) ==22492== by 0x40143E: main (mini-x509-rehandshake.c:211) ==22492== ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E5513F: _gnutls_send_handshake_final (gnutls_handshake.c:2861) ==22492== by 0x4E55ED1: _gnutls_handshake_common (gnutls_handshake.c:3109) ==22492== by 0x4E54870: gnutls_handshake (gnutls_handshake.c:2690) ==22492== by 0x4015AF: main (mini-x509-rehandshake.c:267) ==22492== ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E4DBA7: _gnutls_writev (gnutls_buffers.c:404) ==22492== by 0x4E4E54A: _gnutls_io_write_flush (gnutls_buffers.c:708) ==22492== by 0x4E4845F: gnutls_bye (gnutls_record.c:222) ==22492== by 0x401631: main (mini-x509-rehandshake.c:285) ==22492== ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E4E552: _gnutls_io_write_flush (gnutls_buffers.c:709) ==22492== by 0x4E4845F: gnutls_bye (gnutls_record.c:222) ==22492== by 0x401631: main (mini-x509-rehandshake.c:285) ==22492== ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E4CE15: _mbuffer_remove_bytes (gnutls_mbuffers.c:190) ==22492== by 0x4E4E568: _gnutls_io_write_flush (gnutls_buffers.c:711) ==22492== by 0x4E4845F: gnutls_bye (gnutls_record.c:222) ==22492== by 0x401631: main (mini-x509-rehandshake.c:285) ==22492== ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E4E5BD: _gnutls_io_write_flush (gnutls_buffers.c:732) ==22492== by 0x4E4845F: gnutls_bye (gnutls_record.c:222) ==22492== by 0x401631: main (mini-x509-rehandshake.c:285) ==22492== ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E48475: gnutls_bye (gnutls_record.c:224) ==22492== by 0x401631: main (mini-x509-rehandshake.c:285) ==22492== ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E4DBA7: _gnutls_writev (gnutls_buffers.c:404) ==22492== by 0x4E4E54A: _gnutls_io_write_flush (gnutls_buffers.c:708) ==22492== by 0x4E4845F: gnutls_bye (gnutls_record.c:222) ==22492== by 0x401642: main (mini-x509-rehandshake.c:286) ==22492== ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E4E552: _gnutls_io_write_flush (gnutls_buffers.c:709) ==22492== by 0x4E4845F: gnutls_bye (gnutls_record.c:222) ==22492== by 0x401642: main (mini-x509-rehandshake.c:286) ==22492== ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E4CE15: _mbuffer_remove_bytes (gnutls_mbuffers.c:190) ==22492== by 0x4E4E568: _gnutls_io_write_flush (gnutls_buffers.c:711) ==22492== by 0x4E4845F: gnutls_bye (gnutls_record.c:222) ==22492== by 0x401642: main (mini-x509-rehandshake.c:286) ==22492== ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E4E5BD: _gnutls_io_write_flush (gnutls_buffers.c:732) ==22492== by 0x4E4845F: gnutls_bye (gnutls_record.c:222) ==22492== by 0x401642: main (mini-x509-rehandshake.c:286) ==22492== ==22492== Conditional jump or move depends on uninitialised value(s) ==22492== at 0x4E48475: gnutls_bye (gnutls_record.c:224) ==22492== by 0x401642: main (mini-x509-rehandshake.c:286) ==22492== PASS: mini-x509-rehandshake ^C make[3]: *** [check-TESTS] Interrupt make[2]: *** [check-am] Interrupt make[1]: *** [check-recursive] Interrupt make: *** [check-recursive] Interrupt _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From simon at josefsson.org Tue Nov 23 15:35:52 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 23 Nov 2010 15:35:52 +0100 Subject: Add HTML/ to the git repository? In-Reply-To: (Jeffrey Walton's message of "Tue, 23 Nov 2010 04:38:06 -0500") References: Message-ID: <87sjysxg3b.fsf@latte.josefsson.org> Jeffrey Walton writes: > On Tue, Nov 23, 2010 at 4:15 AM, Nikos Mavrogiannopoulos > wrote: >> I think it's already there. Check http://savannah.gnu.org/cvs/?group=gnutls >> and the webpages repository section. > http://cvs.savannah.gnu.org/viewvc/gnutls/?root=gnutls is empty > (followed 'Browse Source Reop' -> gnutls -> root). > > On my local git copy, the only [top level] directories I have are: > doc, gl, guile, lib, libextra, m4, src, and tests. Read "webpages repository" under Savannah -> GnuTLS -> Source Code -> Use CVS. The direct link is: https://savannah.gnu.org/cvs/?group=gnutls The web pages in CVS can be browsed at: http://web.cvs.savannah.gnu.org/viewvc/gnutls/?root=gnutls /Simon From simon at josefsson.org Tue Nov 23 15:40:02 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 23 Nov 2010 15:40:02 +0100 Subject: parallel build failure(s) In-Reply-To: <4CEA0DE4.5040304@gmail.com> (Graham Gower's message of "Mon, 22 Nov 2010 16:59:56 +1030") References: <4CEA0DE4.5040304@gmail.com> Message-ID: <87oc9gxfwd.fsf@latte.josefsson.org> Graham Gower writes: > Hi, > > I'm using openembedded to cross build gnutls 2.10.2 and have seen a > build failure which looks like its caused by missing dependencies > in guile/src/Makefile.am. I am building with make -j 12. > > My failure: > http://tinderbox.openembedded.net/public/logs/task/10751151.txt > Another, similar failure: > http://tinderbox.openembedded.net/public/logs/task/7589267.txt > > Its clear to me that the failures are due to the header file not > being fully created before the guile-snarf process is invoked. > > I suspect something like the below patch may be the solution, but > as I'm unable to easily reproduce the failure, I cannot reliably > test it. Thanks for report Graham. Ludo, do you think the patch solves the problem? /Simon > -Graham > > diff --git a/guile/src/Makefile.am.orig b/guile/src/Makefile.am > index e8e81b1..2ee1297 100644 > --- a/guile/src/Makefile.am.orig > +++ b/guile/src/Makefile.am > @@ -122,7 +122,7 @@ extra-smob-types.i.c: $(srcdir)/make-smob-types.scm > snarfcppopts = $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \ > $(CFLAGS) $(AM_CFLAGS) $(GUILE_CFLAGS) > > -.c.x: > +.c.x: $(BUILT_SOURCES) > $(guile_snarf) -o $@ $< $(snarfcppopts) > > # Target used by doc/Makefile, to create all built sources necessary From ludo at chbouib.org Tue Nov 23 18:09:56 2010 From: ludo at chbouib.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Tue, 23 Nov 2010 18:09:56 +0100 Subject: parallel build failure(s) In-Reply-To: <87oc9gxfwd.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 23 Nov 2010 15:40:02 +0100") References: <4CEA0DE4.5040304@gmail.com> <87oc9gxfwd.fsf@latte.josefsson.org> Message-ID: <87lj4khspn.fsf@chbouib.org> Hi! Simon Josefsson writes: >> diff --git a/guile/src/Makefile.am.orig b/guile/src/Makefile.am >> index e8e81b1..2ee1297 100644 >> --- a/guile/src/Makefile.am.orig >> +++ b/guile/src/Makefile.am >> @@ -122,7 +122,7 @@ extra-smob-types.i.c: $(srcdir)/make-smob-types.scm >> snarfcppopts = $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \ >> $(CFLAGS) $(AM_CFLAGS) $(GUILE_CFLAGS) >> >> -.c.x: >> +.c.x: $(BUILT_SOURCES) >> $(guile_snarf) -o $@ $< $(snarfcppopts) >> >> # Target used by doc/Makefile, to create all built sources necessary Yes, looks good to me. Please commit. Thanks, Ludo?. From INVALID.NOREPLY at gnu.org Tue Nov 23 18:23:47 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Tue, 23 Nov 2010 17:23:47 +0000 Subject: [sr #107535] 'make check' - hang after 'PASS: mini-x509-rehandshake' on x64 Ubuntu In-Reply-To: <20101123-131802.sv80862.87038@savannah.gnu.org> References: <20101123-131802.sv80862.87038@savannah.gnu.org> Message-ID: <20101123-172347.sv80862.39081@savannah.gnu.org> Follow-up Comment #1, sr #107535 (project gnutls): Please cancel..... The tests were being starved as a background process. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From simon at josefsson.org Tue Nov 23 22:07:30 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 23 Nov 2010 22:07:30 +0100 Subject: parallel build failure(s) In-Reply-To: <4CEA0DE4.5040304@gmail.com> (Graham Gower's message of "Mon, 22 Nov 2010 16:59:56 +1030") References: <4CEA0DE4.5040304@gmail.com> Message-ID: <87y68jvje5.fsf@latte.josefsson.org> Graham Gower writes: > Hi, > > I'm using openembedded to cross build gnutls 2.10.2 and have seen a > build failure which looks like its caused by missing dependencies > in guile/src/Makefile.am. I am building with make -j 12. > > My failure: > http://tinderbox.openembedded.net/public/logs/task/10751151.txt > Another, similar failure: > http://tinderbox.openembedded.net/public/logs/task/7589267.txt > > Its clear to me that the failures are due to the header file not > being fully created before the guile-snarf process is invoked. > > I suspect something like the below patch may be the solution, but > as I'm unable to easily reproduce the failure, I cannot reliably > test it. Thanks, committed! I also pushed it to the 2.10.x branch. /Simon > -Graham > > diff --git a/guile/src/Makefile.am.orig b/guile/src/Makefile.am > index e8e81b1..2ee1297 100644 > --- a/guile/src/Makefile.am.orig > +++ b/guile/src/Makefile.am > @@ -122,7 +122,7 @@ extra-smob-types.i.c: $(srcdir)/make-smob-types.scm > snarfcppopts = $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) \ > $(CFLAGS) $(AM_CFLAGS) $(GUILE_CFLAGS) > > -.c.x: > +.c.x: $(BUILT_SOURCES) > $(guile_snarf) -o $@ $< $(snarfcppopts) > > # Target used by doc/Makefile, to create all built sources necessary From nikias at gmx.li Wed Nov 24 06:25:20 2010 From: nikias at gmx.li (Nikias Bassen) Date: Wed, 24 Nov 2010 06:25:20 +0100 Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice In-Reply-To: References: <20101122001723.70acc8e0@i7katze> Message-ID: <20101124062520.354b4245@i7katze> Hi, we found out that the certificate checking is more strict now as it seems. I have the following question. Using openssl, we do the following: if (SSL_CTX_use_certificate_file(ssl_ctx, "/path/to/certificate.pem", SSL_FILETYPE_PEM) != 1) { debug_info("WARNING: Could not load RootCertificate"); } if (SSL_CTX_use_RSAPrivateKey_file(ssl_ctx, "/path/to/privatekey.pem", SSL_FILETYPE_PEM) != 1) { debug_info("WARNING: Could not load RootPrivateKey"); } What is the equivalent to this when using gnutls? Thanks Nikias On Tue, 23 Nov 2010 10:08:20 +0100 Nikos Mavrogiannopoulos wrote: > I'd suggest that you use the priority_set_direct() function. Check the examples > in the gnutls documentation for details. Does gnutls-cli work on the server you > are connecting? What is the output of gnutls-cli-debug? > > regards, > Nikos > > On Mon, Nov 22, 2010 at 12:17 AM, Nikias Bassen wrote: > > Hi, > > > > I'm a leading developer of libimobiledevice (http://libimobiledevice.org/) and > > we are facing a GnuTLS issue. The lockdown protocol is initializing an SSLv3 > > session and since iOS 4.2 the handshake fails when using GnuTLS. Further > > investigation showed that the error is GNUTLS_E_FATAL_ALERT_RECEIVED -12, > > Error: Could not negotiate a supported cipher suite. > > However, I replaced the appropiate ssl code using OpenSSL and got it working. > > Debugging output showed that the cipher is AES256-SHA, but surprisingly this > > is the same cipher that we have with pre-4.2 devices using GnuTLS. > > > > We have no clue what might be wrong here as it has been working since 4.2b > > arrived, so I'd like to ask if anyone here might be able to help us > > investigating this issue? Tell me what info you need and I'll get it for you. > > > > The device is the server and libimobiledevice code the client side of the > > communication. > > > > Our code is here: http://cgit.sukimashita.com/libimobiledevice.git/ > > The SSL code is in src/idevice.c, the handshake is implemented in > > idevice_connection_enable_ssl(). If you have questions about the code just > > ask. You can reach us in #libimobiledevice on FreeNode too. > > > > Regards, > > Nikias > > > > _______________________________________________ > > Gnutls-devel mailing list > > Gnutls-devel at gnu.org > > http://lists.gnu.org/mailman/listinfo/gnutls-devel > > > From noloader at gmail.com Wed Nov 24 06:50:04 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 24 Nov 2010 00:50:04 -0500 Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice In-Reply-To: References: <20101122001723.70acc8e0@i7katze> Message-ID: On Tue, Nov 23, 2010 at 4:44 AM, Nikos Mavrogiannopoulos wrote: > On Tue, Nov 23, 2010 at 10:29 AM, Jeffrey Walton wrote: > >>> I'd suggest that you use the priority_set_direct() function. Check the examples >>> in the gnutls documentation for details. Does gnutls-cli work on the server you >>> are connecting? What is the output of gnutls-cli-debug? >> An FYI.... I have not been able to get the examples* to work. I've >> tried connecting to my Windows 2003/IIS 6 machine, and Simon's host at >> test.gnutls.org:5556. >> Usually, gnutls_handshake() fails with one of the following (I do a >> lot of knob turning on failures). In all cases, >> gnutls_error_is_fatal() is true. > > Which client example did you try? First example - anonymous client authentication at [1]. I attached my test code for convenience. Here are the results on three different servers: test.gnutls.org: GNUTLS_E_FATAL_ALERT_RECEIVED www,microsoft.com: GNUTLS_E_FATAL_ALERT_RECEIVED my tests server (Windows 2003/IIS 6): GNUTLS_E_UNEXPECTED_PACKET_LENGTH I suspect www.microsoft.com is Server 2008 (nmap -O -v www.microsoft.com returns "No OS matches for host"). > Could it be a windows issue (examples are written for posix)? Working on Ubuntu. > You can check with wireshark the conversation to check if > there is some communication issue. OK. I'll get it fired up soon. Jeff [1] http://www.gnu.org/software/gnutls/manual/html_node/Simple-client-example-with-anonymous-authentication.html#Simple-client-example-with-anonymous-authentication -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-test.c Type: text/x-csrc Size: 6453 bytes Desc: not available URL: From noloader at gmail.com Wed Nov 24 07:07:46 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 24 Nov 2010 01:07:46 -0500 Subject: Question on Test Cases Message-ID: Hi All, According to Contributing [1]: Return errors. No reason whatsoever should abort the execution of the library. Even memory allocation errors, e.g. when malloc return NULL, should work although result in an error code. Are negative test cases accepted and welcomed? Or should the test cases only be positive? Jeff [1] http://www.gnu.org/software/gnutls/manual/html_node/Contributing.html From nmav at gnutls.org Wed Nov 24 09:23:53 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 24 Nov 2010 09:23:53 +0100 Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice In-Reply-To: References: <20101122001723.70acc8e0@i7katze> Message-ID: <4CECCB99.3040005@gnutls.org> On 11/24/2010 06:50 AM, Jeffrey Walton wrote: > On Tue, Nov 23, 2010 at 4:44 AM, Nikos Mavrogiannopoulos > wrote: >> On Tue, Nov 23, 2010 at 10:29 AM, Jeffrey Walton wrote: >> >>>> I'd suggest that you use the priority_set_direct() function. Check the examples >>>> in the gnutls documentation for details. Does gnutls-cli work on the server you >>>> are connecting? What is the output of gnutls-cli-debug? >>> An FYI.... I have not been able to get the examples* to work. I've >>> tried connecting to my Windows 2003/IIS 6 machine, and Simon's host at >>> test.gnutls.org:5556. >>> Usually, gnutls_handshake() fails with one of the following (I do a >>> lot of knob turning on failures). In all cases, >>> gnutls_error_is_fatal() is true. >> >> Which client example did you try? > First example - anonymous client authentication at [1]. I attached my > test code for convenience. Web servers do not support anonymous authentication, thus receiving an alert that might indicate that would be the expected behavior (use the gnutls_alert_* functions to read the actual alert). regards, Nikos From nmav at gnutls.org Wed Nov 24 09:29:29 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 24 Nov 2010 09:29:29 +0100 Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice In-Reply-To: <20101124062520.354b4245@i7katze> References: <20101122001723.70acc8e0@i7katze> <20101124062520.354b4245@i7katze> Message-ID: <4CECCCE9.2010004@gnutls.org> On 11/24/2010 06:25 AM, Nikias Bassen wrote: > Hi, > > we found out that the certificate checking is more strict now as it seems. I > have the following question. Using openssl, we do the following: > > if (SSL_CTX_use_certificate_file(ssl_ctx, > "/path/to/certificate.pem", > SSL_FILETYPE_PEM) != 1) { > debug_info("WARNING: Could not load RootCertificate"); > } > if (SSL_CTX_use_RSAPrivateKey_file(ssl_ctx, > "/path/to/privatekey.pem", > SSL_FILETYPE_PEM) != 1) { > debug_info("WARNING: Could not load RootPrivateKey"); > } > > What is the equivalent to this when using gnutls? Check gnutls_certificate_set_x509_key_file() and the examples in the gnutls manual. regards, Nikos From noloader at gmail.com Wed Nov 24 11:04:49 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 24 Nov 2010 05:04:49 -0500 Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice In-Reply-To: <4CECCB99.3040005@gnutls.org> References: <20101122001723.70acc8e0@i7katze> <4CECCB99.3040005@gnutls.org> Message-ID: On Wed, Nov 24, 2010 at 3:23 AM, Nikos Mavrogiannopoulos wrote: > On 11/24/2010 06:50 AM, Jeffrey Walton wrote: >> On Tue, Nov 23, 2010 at 4:44 AM, Nikos Mavrogiannopoulos >> wrote: >>> On Tue, Nov 23, 2010 at 10:29 AM, Jeffrey Walton wrote: >>> >>>>> I'd suggest that you use the priority_set_direct() function. Check the examples >>>>> in the gnutls documentation for details. Does gnutls-cli work on the server you >>>>> are connecting? What is the output of gnutls-cli-debug? >>>> An FYI.... I have not been able to get the examples* to work. I've >>>> tried connecting to my Windows 2003/IIS 6 machine, and Simon's host at >>>> test.gnutls.org:5556. >>>> Usually, gnutls_handshake() fails with one of the following (I do a >>>> lot of knob turning on failures). In all cases, >>>> gnutls_error_is_fatal() is true. >>> >>> Which client example did you try? >> First example - anonymous client authentication at [1]. I attached my >> test code for convenience. > > Web servers do not support anonymous authentication, thus receiving an > alert that might indicate that would be the expected behavior. Ah. I see - we're not on the same page. I'm not using the correct terms. My apologies. That would explain why I thought "anonymous authentication" [1, 2] meant "no client credentials" or similar. What term should I use to mean "no client credentials"? The best I can explain "no client credentials" is how a standard web server operates; and the inverse of "client authentication" introduced in SSL 3.0. The take away: how do I set up a secure channel, which requires server authentication, but not [necessarily] client authentication? > (use the gnutls_alert_* functions to read the actual alert). The error code and gnutls_alert_get()/gnutls_alert_get_name() were not very useful. Confer: {GNUTLS_E_UNEXPECTED_PACKET_LENGTH, "Close notify"} and {GNUTLS_E_FATAL_ALERT_RECEIVED, "Error in protocol version"} Googling for the error defines and alert strings usually state something like, "let's get the GnuTLS guys involved with this" and "GnuTLS is broken, use {OpenSSL|NSS}". Jeff [1] IIS Authentication, "Anonymous authentication gives users access to the public areas of your Web site without prompting them for a user name or password. Although listed as an authentication scheme, it is not technically performing any client authentication because the client is not required to supply any credentials." http://msdn.microsoft.com/en-us/library/aa292114%28VS.71%29.aspx [2] Apache 2 with SSL/TLS, "It is also recommended to disable all cipher suites that support anonymous authentication (aNULL)." http://www.symantec.com/connect/articles/apache-2-ssltls-step-step-part-2 From nikias at gmx.li Wed Nov 24 11:05:47 2010 From: nikias at gmx.li (Nikias Bassen) Date: Wed, 24 Nov 2010 11:05:47 +0100 Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice In-Reply-To: <4CECCCE9.2010004@gnutls.org> References: <20101122001723.70acc8e0@i7katze> <20101124062520.354b4245@i7katze> <4CECCCE9.2010004@gnutls.org> Message-ID: <20101124110547.0382c934@i7katze> Hi, On Wed, 24 Nov 2010 09:29:29 +0100 Nikos Mavrogiannopoulos wrote: > On 11/24/2010 06:25 AM, Nikias Bassen wrote: > > Hi, > > > > we found out that the certificate checking is more strict now as it seems. I > > have the following question. Using openssl, we do the following: > > > > if (SSL_CTX_use_certificate_file(ssl_ctx, > > "/path/to/certificate.pem", > > SSL_FILETYPE_PEM) != 1) { > > debug_info("WARNING: Could not load RootCertificate"); > > } > > if (SSL_CTX_use_RSAPrivateKey_file(ssl_ctx, > > "/path/to/privatekey.pem", > > SSL_FILETYPE_PEM) != 1) { > > debug_info("WARNING: Could not load RootPrivateKey"); > > } > > > > What is the equivalent to this when using gnutls? > > Check gnutls_certificate_set_x509_key_file() and the examples in the > gnutls manual. These functions are intended for the server, right? Remember we are on the client side. Does that make any difference? Regards Nikias From nmav at gnutls.org Wed Nov 24 12:17:49 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 24 Nov 2010 12:17:49 +0100 Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice In-Reply-To: <20101124110547.0382c934@i7katze> References: <20101122001723.70acc8e0@i7katze> <20101124062520.354b4245@i7katze> <4CECCCE9.2010004@gnutls.org> <20101124110547.0382c934@i7katze> Message-ID: On Wed, Nov 24, 2010 at 11:05 AM, Nikias Bassen wrote: >> > if (SSL_CTX_use_certificate_file(ssl_ctx, >> > ? "/path/to/certificate.pem", >> > ? SSL_FILETYPE_PEM) != 1) { >> > ? ? debug_info("WARNING: Could not load RootCertificate"); >> > } >> > if (SSL_CTX_use_RSAPrivateKey_file(ssl_ctx, >> > ? "/path/to/privatekey.pem", >> > ? SSL_FILETYPE_PEM) != 1) { >> > ? ? debug_info("WARNING: Could not load RootPrivateKey"); >> > } >> > What is the equivalent to this when using gnutls? >> Check gnutls_certificate_set_x509_key_file() and the examples in the >> gnutls manual. > These functions are intended for the server, right? Remember we are on the > client side. Does that make any difference? No. They are functions for the one that wants to use certificate (it can be either server or client). The only distinction between server and client in gnutls is being done in gnutls_init(). Most of the other functions are applicable to both unless they mention otherwise in the description. regards, Nikos From nmav at gnutls.org Wed Nov 24 12:24:59 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 24 Nov 2010 12:24:59 +0100 Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice In-Reply-To: References: <20101122001723.70acc8e0@i7katze> <4CECCB99.3040005@gnutls.org> Message-ID: On Wed, Nov 24, 2010 at 11:04 AM, Jeffrey Walton wrote: >> Web servers do not support anonymous authentication, thus receiving an >> alert that might indicate that would be the expected behavior. > Ah. I see - we're not on the same page. I'm not using the correct > terms. My apologies. That would explain why I thought "anonymous > authentication" [1, 2] meant "no client credentials" or similar. > What term should I use to mean "no client credentials"? The best I can > explain "no client credentials" is how a standard web server operates; > and the inverse of "client authentication" introduced in SSL 3.0. The authentication in TLS most commonly used is certificate authentication. This can be server-side only (only server is authenticated) or client and server authentication (where both are authenticated to each other). A client thus such as the client in 7.3.2 that does not set a certificate would work for you. >> (use the gnutls_alert_* functions to read the actual alert). > The error code and gnutls_alert_get()/gnutls_alert_get_name() were not > very useful. Confer: {GNUTLS_E_UNEXPECTED_PACKET_LENGTH, "Close > notify"} and {GNUTLS_E_FATAL_ALERT_RECEIVED, "Error in protocol > version"} In what sense? Did you use something like: http://www.gnu.org/software/gnutls/manual/html_node/Checking-for-an-alert.html#Checking-for-an-alert ? > Googling for the error defines and alert strings usually state > something like, "let's get the GnuTLS guys involved with this" and > "GnuTLS is broken, use {OpenSSL|NSS}". Sometimes error alerts from TLS can be quite cryptic. Maybe we can improve the documentation for the common cases. > [1] IIS Authentication, "Anonymous authentication gives users access > to the public areas of your Web site without prompting them for a user > name or password. Although listed as an authentication scheme, it is > not technically performing any client authentication because the > client is not required to supply any credentials." > http://msdn.microsoft.com/en-us/library/aa292114%28VS.71%29.aspx Ouch. Here they abuse the terminology of TLS. Anonymous authentication is authentication where neither the client nor the server are authenticated to each other. > [2] Apache 2 with SSL/TLS, "It is also recommended to disable all > cipher suites that support anonymous authentication (aNULL)." > http://www.symantec.com/connect/articles/apache-2-ssltls-step-step-part-2 Here is correct usage of anonymous authentication. regards, Nikos From simon at josefsson.org Wed Nov 24 15:25:01 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 24 Nov 2010 15:25:01 +0100 Subject: Question on Test Cases In-Reply-To: (Jeffrey Walton's message of "Wed, 24 Nov 2010 01:07:46 -0500") References: Message-ID: <87aaky2402.fsf@latte.josefsson.org> Jeffrey Walton writes: > Hi All, > > According to Contributing [1]: > > Return errors. No reason whatsoever should abort the execution > of the library. Even memory allocation errors, e.g. when malloc > return NULL, should work although result in an error code. > > Are negative test cases accepted and welcomed? Or should the test > cases only be positive? All self tests are welcome! /Simon From INVALID.NOREPLY at gnu.org Wed Nov 24 17:37:56 2010 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Wed, 24 Nov 2010 16:37:56 +0000 Subject: [sr #107533] Proposed changes to README In-Reply-To: <20101122-141632.sv80862.38089@savannah.gnu.org> References: <20101122-141036.sv80862.86138@savannah.gnu.org> <20101122-141632.sv80862.38089@savannah.gnu.org> Message-ID: <20101124-183756.sv707.32921@savannah.gnu.org> Update of sr #107533 (project gnutls): Status: None => Done Assigned to: None => nmav Open/Closed: Open => Closed _______________________________________________________ Follow-up Comment #2: Commited. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 24 19:14:40 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Wed, 24 Nov 2010 18:14:40 +0000 Subject: [sr #107538] Patch: "warning: cast to pointer from integer of different size" Message-ID: <20101124-181439.sv80862.53976@savannah.gnu.org> URL: Summary: Patch: "warning: cast to pointer from integer of different size" Project: GnuTLS Submitted by: noloader Submitted on: Wed 24 Nov 2010 06:14:39 PM GMT Category: None Priority: 5 - Normal Severity: 2 - Minor Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: >From the low hanging fruit department..... This clears about 50 instances (give or take) of "warning: cast to pointer from integer of different size". I believe the warning only showed up on x64 systems. gnutls_transport_ptr_t is typedef'd as a void*, while a file descriptor is a [fixed sized] int. OK on x86, warning on x64. Previous: gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sd); Proposed: gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) (ssize_t)sd); _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Wed 24 Nov 2010 06:14:39 PM GMT Name: pointer-from-integer.patch Size: 19kB By: noloader _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 24 19:37:47 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Wed, 24 Nov 2010 18:37:47 +0000 Subject: [sr #107538] Patch: "warning: cast to pointer from integer of different size" In-Reply-To: <20101124-181439.sv80862.53976@savannah.gnu.org> References: <20101124-181439.sv80862.53976@savannah.gnu.org> Message-ID: <20101124-183747.sv80862.90432@savannah.gnu.org> Follow-up Comment #1, sr #107538 (project gnutls): gnutls_handshake.patch turns off (ie, comments out) an assert I was using that might be included in the warnings patch. (file #22099) _______________________________________________________ Additional Item Attachment: File name: gnutls_handshake.patch Size:1 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 24 22:24:56 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Wed, 24 Nov 2010 21:24:56 +0000 Subject: [sr #107539] Patch: crl.c: pointer targets differ in signedness Message-ID: <20101124-212455.sv80862.25249@savannah.gnu.org> URL: Summary: Patch: crl.c: pointer targets differ in signedness Project: GnuTLS Submitted by: noloader Submitted on: Wed 24 Nov 2010 09:24:55 PM GMT Category: None Priority: 5 - Normal Severity: 2 - Minor Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: Cleared warnings in crl.c. Hardened crl.c so in preparations for upcoming negative tests on the source file. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Wed 24 Nov 2010 09:24:55 PM GMT Name: crl.patch Size: 10kB By: noloader _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From noloader at gmail.com Thu Nov 25 08:35:41 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 25 Nov 2010 02:35:41 -0500 Subject: VALIDATE_PARAMETERS macro Message-ID: Hi All, I'd like to introduce a VALIDATE_PARAMETERS macro. The macro would guard full parameter validation in library functions. I think full parameter validation would greatly enhance the robustness of the library by hardening the library from user land errors and mis-use. For those who are interested in performance ("the user needs to RTFM" philosophy), the macro can remain undefined to retain existing behavior. In addition, the asserts (or gnutls_assert) will aide in finding the point of first failure quickly, which frees developers up to do other things. (VALIDATE_PARAMETERS and asserts are tightly coupled in well-instrumented code). A proper assert strategy would include: Release, off; Debug, on; and Test, off. Below is a sample of existing and augmented code. Could anyone help with comments? Jeff ========== int gnutls_dh_params_import_raw (gnutls_dh_params_t dh_params, const gnutls_datum_t * prime, const gnutls_datum_t * generator) { bigint_t tmp_prime, tmp_g; size_t size; size = prime->size; if (_gnutls_mpi_scan_nz (&tmp_prime, prime->data, size)) { gnutls_assert (); return GNUTLS_E_MPI_SCAN_FAILED; } size = generator->size; if (_gnutls_mpi_scan_nz (&tmp_g, generator->data, size)) { _gnutls_mpi_release (&tmp_prime); gnutls_assert (); return GNUTLS_E_MPI_SCAN_FAILED; } /* store the generated values */ dh_params->params[0] = tmp_prime; dh_params->params[1] = tmp_g; return 0; } ========== int gnutls_dh_params_import_raw (gnutls_dh_params_t dh_params, const gnutls_datum_t * prime, const gnutls_datum_t * generator) { bigint_t tmp_prime, tmp_g; size_t size; #if defined VALIDATE_PARAMETERS if (dh_params == NULL || dh_params->params[0] == NULL || dh_params->params[1] == NULL) { gnutls_assert (); return GNUTLS_E_INVALID_REQUEST; } if (prime == NULL || generator == NULL) { gnutls_assert (); return GNUTLS_E_INVALID_REQUEST; } if (prime->data == NULL || prime->size < 6 || generator->data == NULL || generator->size < 6) { gnutls_assert (); return GNUTLS_E_INVALID_REQUEST; } #endif /* VALIDATE_PARAMETERS */ size = prime->size; if (_gnutls_mpi_scan_nz (&tmp_prime, prime->data, size)) { gnutls_assert (); return GNUTLS_E_MPI_SCAN_FAILED; } size = generator->size; if (_gnutls_mpi_scan_nz (&tmp_g, generator->data, size)) { _gnutls_mpi_release (&tmp_prime); gnutls_assert (); return GNUTLS_E_MPI_SCAN_FAILED; } /* store the generated values */ dh_params->params[0] = tmp_prime; dh_params->params[1] = tmp_g; return 0; } From INVALID.NOREPLY at gnu.org Thu Nov 25 10:13:16 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Thu, 25 Nov 2010 09:13:16 +0000 Subject: [sr #107540] Patch: terminal feedback for gendh.c Message-ID: <20101125-091315.sv80862.24816@savannah.gnu.org> URL: Summary: Patch: terminal feedback for gendh.c Project: GnuTLS Submitted by: noloader Submitted on: Thu 25 Nov 2010 09:13:15 AM GMT Category: None Priority: 5 - Normal Severity: 2 - Minor Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: * Cleared warnings * Provided feedback for calls into gnutls_dh_params_init and dnutls_dh_params_generate2 _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Thu 25 Nov 2010 09:13:15 AM GMT Name: gendh.patch Size: 716B By: noloader _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Nov 25 13:07:15 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Thu, 25 Nov 2010 12:07:15 +0000 Subject: [sr #107541] Patch: crq.c warnings Message-ID: <20101125-120714.sv80862.63783@savannah.gnu.org> URL: Summary: Patch: crq.c warnings Project: GnuTLS Submitted by: noloader Submitted on: Thu 25 Nov 2010 12:07:14 PM GMT Category: None Priority: 5 - Normal Severity: 2 - Minor Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: * cleared warnings _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Thu 25 Nov 2010 12:07:14 PM GMT Name: crq.patch Size: 11kB By: noloader _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From almog at mce-sys.com Wed Nov 24 20:59:56 2010 From: almog at mce-sys.com (almogbh) Date: Wed, 24 Nov 2010 11:59:56 -0800 (PST) Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice In-Reply-To: <20101122001723.70acc8e0@i7katze> References: <20101122001723.70acc8e0@i7katze> Message-ID: <30298914.post@talk.nabble.com> Hi, any news/estimations for resolving this issue? libimobiledevice is the coolest project ever, but i cant conenct my 4.2 device!! thanks! Nikias Bassen wrote: > > Hi, > > I'm a leading developer of libimobiledevice (http://libimobiledevice.org/) > and > we are facing a GnuTLS issue. The lockdown protocol is initializing an > SSLv3 > session and since iOS 4.2 the handshake fails when using GnuTLS. Further > investigation showed that the error is GNUTLS_E_FATAL_ALERT_RECEIVED -12, > Error: Could not negotiate a supported cipher suite. > However, I replaced the appropiate ssl code using OpenSSL and got it > working. > Debugging output showed that the cipher is AES256-SHA, but surprisingly > this > is the same cipher that we have with pre-4.2 devices using GnuTLS. > > We have no clue what might be wrong here as it has been working since 4.2b > arrived, so I'd like to ask if anyone here might be able to help us > investigating this issue? Tell me what info you need and I'll get it for > you. > > The device is the server and libimobiledevice code the client side of the > communication. > > Our code is here: http://cgit.sukimashita.com/libimobiledevice.git/ > The SSL code is in src/idevice.c, the handshake is implemented in > idevice_connection_enable_ssl(). If you have questions about the code just > ask. You can reach us in #libimobiledevice on FreeNode too. > > Regards, > Nikias > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > > -- View this message in context: http://old.nabble.com/iDevice-GnuTLS-issue-with-iOS-4.2---libimobiledevice-tp30274681p30298914.html Sent from the GnuPG - Gnutls - Dev mailing list archive at Nabble.com. From INVALID.NOREPLY at gnu.org Thu Nov 25 14:06:26 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Thu, 25 Nov 2010 13:06:26 +0000 Subject: [sr #107542] Patch: dn.c warnings Message-ID: <20101125-130626.sv80862.60484@savannah.gnu.org> URL: Summary: Patch: dn.c warnings Project: GnuTLS Submitted by: noloader Submitted on: Thu 25 Nov 2010 01:06:26 PM GMT Category: None Priority: 5 - Normal Severity: 2 - Minor Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: * cleared warnings * indent -gnu _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Thu 25 Nov 2010 01:06:26 PM GMT Name: dn.patch Size: 7kB By: noloader _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From simon at josefsson.org Thu Nov 25 18:32:28 2010 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 25 Nov 2010 18:32:28 +0100 Subject: README patch In-Reply-To: <87eiad8n82.fsf@latte.josefsson.org> (Simon Josefsson's message of "Mon, 22 Nov 2010 15:08:45 +0100") References: <87wro58td0.fsf@latte.josefsson.org> <87eiad8n82.fsf@latte.josefsson.org> Message-ID: <87aakxjolv.fsf@latte.josefsson.org> I modified the new README to recommend git format-patch rather than git diff, since that makes things easier for us. /Simon From simon at josefsson.org Thu Nov 25 18:39:37 2010 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 25 Nov 2010 18:39:37 +0100 Subject: VALIDATE_PARAMETERS macro In-Reply-To: (Jeffrey Walton's message of "Thu, 25 Nov 2010 02:35:41 -0500") References: Message-ID: <8762vljo9y.fsf@latte.josefsson.org> Jeffrey Walton writes: > Hi All, > > I'd like to introduce a VALIDATE_PARAMETERS macro. The macro would > guard full parameter validation in library functions. > > I think full parameter validation would greatly enhance the robustness > of the library by hardening the library from user land errors and > mis-use. For those who are interested in performance ("the user needs > to RTFM" philosophy), the macro can remain undefined to retain > existing behavior. > > In addition, the asserts (or gnutls_assert) will aide in finding the > point of first failure quickly, which frees developers up to do other > things. (VALIDATE_PARAMETERS and asserts are tightly coupled in > well-instrumented code). A proper assert strategy would include: > Release, off; Debug, on; and Test, off. > > Below is a sample of existing and augmented code. > > Could anyone help with comments? I don't think a VALIDATE_PARAMETERS symbol is necessary (actually I consider any CPP #if's a nuisance from a code quality point of view: it makes it difficult to test all code paths). Instead, just add the NULL checks in the code directly. This is done in many places already. > int > gnutls_dh_params_import_raw (gnutls_dh_params_t dh_params, > const gnutls_datum_t * prime, > const gnutls_datum_t * generator) > { > bigint_t tmp_prime, tmp_g; > size_t size; > > #if defined VALIDATE_PARAMETERS > if (dh_params == NULL || dh_params->params[0] == NULL > || dh_params->params[1] == NULL) > { > gnutls_assert (); > return GNUTLS_E_INVALID_REQUEST; > } ... I'm not certain this is a good example: _gnutls_mpi_scan_nz appears to check whether input variables are NULL or not. So these additional checks are redundant. /Simon From INVALID.NOREPLY at gnu.org Thu Nov 25 18:55:09 2010 From: INVALID.NOREPLY at gnu.org (Simon Josefsson) Date: Thu, 25 Nov 2010 17:55:09 +0000 Subject: [sr #107538] Patch: "warning: cast to pointer from integer of different size" In-Reply-To: <20101124-183747.sv80862.90432@savannah.gnu.org> References: <20101124-181439.sv80862.53976@savannah.gnu.org> <20101124-183747.sv80862.90432@savannah.gnu.org> Message-ID: <20101125-175509.sv7213.20099@savannah.gnu.org> Follow-up Comment #2, sr #107538 (project gnutls): Re pointer-from-integer: why ssize_t? Wouldn't 'unsigned long' be better? Otherwise I agree with this patch. Re gnutls_handshake.patch: this looks wrong for two reasons, first we don't use assert () because it would crash an application (instead we should return errors), and secondly, I don't think there is an error to end up in the default case. So there is no reason for even gnutls_assert there, is there? /Simon _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Nov 25 18:46:40 2010 From: INVALID.NOREPLY at gnu.org (Simon Josefsson) Date: Thu, 25 Nov 2010 17:46:40 +0000 Subject: [sr #107540] Patch: terminal feedback for gendh.c In-Reply-To: <20101125-091315.sv80862.24816@savannah.gnu.org> References: <20101125-091315.sv80862.24816@savannah.gnu.org> Message-ID: <20101125-174640.sv7213.57159@savannah.gnu.org> Update of sr #107540 (project gnutls): Status: None => Done Assigned to: None => jas _______________________________________________________ Follow-up Comment #1: I don't see what this patch really does? It just prints some statements, which does not influence the self test outcome. /Simon _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Nov 25 19:00:48 2010 From: INVALID.NOREPLY at gnu.org (Simon Josefsson) Date: Thu, 25 Nov 2010 18:00:48 +0000 Subject: [sr #107539] Patch: crl.c: pointer targets differ in signedness In-Reply-To: <20101124-212455.sv80862.25249@savannah.gnu.org> References: <20101124-212455.sv80862.25249@savannah.gnu.org> Message-ID: <20101125-180048.sv7213.47042@savannah.gnu.org> Follow-up Comment #1, sr #107539 (project gnutls): Re this code: + if (crl == NULL) + { + gnutls_assert (); + /* Need a GNUTLS_E_INVALID_PARAMETER */ + return GNUTLS_E_SHORT_MEMORY_BUFFER; + } The error typically used is GNUTLS_E_INVALID_REQUEST. + opaque *out = NULL; What's the reason for this? It is initialized later on. + if (buf == NULL || sizeof_buf == NULL) + { + gnutls_assert (); + return GNUTLS_E_INVALID_REQUEST; + } This is quite wrong: read the documentation for the function, buf can be NULL. The same applies to a couple of more instance, and I stopped reading. Some of the stuff is good, so please rework the patch and I'll review again. /Simon _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Nov 25 19:02:41 2010 From: INVALID.NOREPLY at gnu.org (Simon Josefsson) Date: Thu, 25 Nov 2010 18:02:41 +0000 Subject: [sr #107542] Patch: dn.c warnings In-Reply-To: <20101125-130626.sv80862.60484@savannah.gnu.org> References: <20101125-130626.sv80862.60484@savannah.gnu.org> Message-ID: <20101125-180240.sv7213.72706@savannah.gnu.org> Follow-up Comment #1, sr #107542 (project gnutls): There is no need to post patches for indentation changes, in fact it just makes it harder to read. Just post a patch to clear the warnings, and we can run 'make indent' and commit the result to fix the indentation. /Simon _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Nov 25 18:48:48 2010 From: INVALID.NOREPLY at gnu.org (Simon Josefsson) Date: Thu, 25 Nov 2010 17:48:48 +0000 Subject: [sr #107541] Patch: crq.c warnings In-Reply-To: <20101125-120714.sv80862.63783@savannah.gnu.org> References: <20101125-120714.sv80862.63783@savannah.gnu.org> Message-ID: <20101125-174848.sv7213.9723@savannah.gnu.org> Follow-up Comment #1, sr #107541 (project gnutls): Is there anything except indentation checks in this patch? Code indentation is performed by 'make indent'. We run it manually sometimes and commit the result. /Simon _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From noloader at gmail.com Thu Nov 25 23:43:47 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 25 Nov 2010 17:43:47 -0500 Subject: README patch In-Reply-To: <87aakxjolv.fsf@latte.josefsson.org> References: <87wro58td0.fsf@latte.josefsson.org> <87eiad8n82.fsf@latte.josefsson.org> <87aakxjolv.fsf@latte.josefsson.org> Message-ID: Hi Simon, On Thu, Nov 25, 2010 at 12:32 PM, Simon Josefsson wrote: > I modified the new README to recommend git format-patch rather than git > diff, since that makes things easier for us. NP. I expect my work to be edited mercilessly until I learn the ways. Jeff From INVALID.NOREPLY at gnu.org Fri Nov 26 02:37:34 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Fri, 26 Nov 2010 01:37:34 +0000 Subject: [sr #107542] Patch: dn.c warnings In-Reply-To: <20101125-180240.sv7213.72706@savannah.gnu.org> References: <20101125-130626.sv80862.60484@savannah.gnu.org> <20101125-180240.sv7213.72706@savannah.gnu.org> Message-ID: <20101126-013734.sv80862.81806@savannah.gnu.org> Follow-up Comment #2, sr #107542 (project gnutls): > we can run 'make indent' and commit the result to fix the indentation. Very cool. I was not aware it was a target. (And sorry about running it on the other patches - the noise is probably maddening). Jeff _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 26 02:55:24 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Fri, 26 Nov 2010 01:55:24 +0000 Subject: [sr #107538] Patch: "warning: cast to pointer from integer of different size" In-Reply-To: <20101125-175509.sv7213.20099@savannah.gnu.org> References: <20101124-181439.sv80862.53976@savannah.gnu.org> <20101124-183747.sv80862.90432@savannah.gnu.org> <20101125-175509.sv7213.20099@savannah.gnu.org> Message-ID: <20101126-015523.sv80862.75700@savannah.gnu.org> Follow-up Comment #3, sr #107538 (project gnutls): > Re pointer-from-integer: why ssize_t? Wouldn't 'unsigned long' > be better? Otherwise I agree with this patch. size_t/ssize_t seemed like the most direct path to a machine's word size. > ... because [an assert] would crash an application (instead we should return errors) I'll get a separate thread started on mail dev. But I agree about crash versus failure. > I don't think there is an error to end up in the default case. OK. I take interest in "empty" default cases, and like to know when they are encountered. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 26 03:34:57 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Fri, 26 Nov 2010 02:34:57 +0000 Subject: [sr #107540] Patch: terminal feedback for gendh.c In-Reply-To: <20101125-174640.sv7213.57159@savannah.gnu.org> References: <20101125-091315.sv80862.24816@savannah.gnu.org> <20101125-174640.sv7213.57159@savannah.gnu.org> Message-ID: <20101126-023457.sv80862.74697@savannah.gnu.org> Follow-up Comment #2, sr #107540 (project gnutls): > I don't see what this patch really does? It just prints some > statements, which does not influence the self test outcome. Correct, confer SR # 107535. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 26 05:37:53 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Fri, 26 Nov 2010 04:37:53 +0000 Subject: [sr #107541] Patch: crq.c warnings In-Reply-To: <20101125-174848.sv7213.9723@savannah.gnu.org> References: <20101125-120714.sv80862.63783@savannah.gnu.org> <20101125-174848.sv7213.9723@savannah.gnu.org> Message-ID: <20101126-043752.sv80862.98272@savannah.gnu.org> Follow-up Comment #2, sr #107541 (project gnutls): crq.c: In function 'gnutls_x509_crq_get_extension_by_oid': crq.c:1810: warning: pointer targets in passing argument 5 of 'gnutls_x509_crq_get_extension_info' differ in signedness crq.c:1289: note: expected 'int *' but argument is of type 'unsigned int *' crq.c: In function 'gnutls_x509_crq_get_key_id': crq.c:2460: warning: pointer targets in passing argument 4 of 'asn1_der_coding' differ in signedness /usr/include/libtasn1.h:206: note: expected 'int *' but argument is of type 'unsigned int *' crq.c:2476: warning: pointer targets in passing argument 4 of 'asn1_der_coding' differ in signedness /usr/include/libtasn1.h:206: note: expected 'int *' but argument is of type 'unsigned int *' _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From noloader at gmail.com Fri Nov 26 06:49:56 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 26 Nov 2010 00:49:56 -0500 Subject: [sr #107539] Patch: crl.c: pointer targets differ in signedness In-Reply-To: <20101125-180048.sv7213.47042@savannah.gnu.org> References: <20101124-212455.sv80862.25249@savannah.gnu.org> <20101125-180048.sv7213.47042@savannah.gnu.org> Message-ID: On Thu, Nov 25, 2010 at 1:00 PM, Simon Josefsson wrote: > > Follow-up Comment #1, sr #107539 (project gnutls): > > Re this code: > > + ?if (crl == NULL) > + ? ?{ > + ? ? ?gnutls_assert (); > + ? ? ?/* Need a GNUTLS_E_INVALID_PARAMETER */ > + ? ? ?return GNUTLS_E_SHORT_MEMORY_BUFFER; > + ? ?} > > The error typically used is GNUTLS_E_INVALID_REQUEST. OK. Got it. > > + ? ? ?opaque *out = NULL; > > What's the reason for this? ?It is initialized later on. Under the debugger, its hard to tell what is valid (appears to be garbage) and what is uninitialized (is really garbage). If the initialization is not needed, the optimizer will drop it. > + ?if (buf == NULL || sizeof_buf == NULL) > + ? ?{ > + ? ? ?gnutls_assert (); > + ? ? ?return GNUTLS_E_INVALID_REQUEST; > + ? ?} > > This is quite wrong: read the documentation for the function, buf can be > NULL. ?The same applies to a couple of more instance, and I stopped reading. OK. I caught that after submission :/ > Some of the stuff is good, so please rework the patch and I'll review again. OK. Thanks. Jeff From noloader at gmail.com Fri Nov 26 06:57:44 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 26 Nov 2010 00:57:44 -0500 Subject: libtasn1, asn1_read_value, and truncation Message-ID: Hi All, How does one detect if/when libtasn1 truncates the value during asn1_read_value. It is not clear to me from the online documentation (http://www.gnu.org/software/libtasn1/manual/libtasn1.html). Should GnuTLS infer truncation *if* the reported length of the value (from asn1_read_value) is the same as the size of the buffer? (The strategy is similar to interpreting return values from snprintf). Jeff From INVALID.NOREPLY at gnu.org Fri Nov 26 08:26:22 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Fri, 26 Nov 2010 07:26:22 +0000 Subject: [sr #107544] Patch: common.c Message-ID: <20101126-072621.sv80862.13909@savannah.gnu.org> URL: Summary: Patch: common.c Project: GnuTLS Submitted by: noloader Submitted on: Fri 26 Nov 2010 07:26:20 AM GMT Category: None Priority: 5 - Normal Severity: 2 - Minor Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: Hi Simon/Nikos, Attached is a patch for common.c. * str -> val and tmpname -> val_name to improve readability. * Added test for oid == NULL (_gnutls_x509_oid_data_printable passes its arg directly to strcmp without validation). * Added additional guards on asn1_read_value() due to libtasn1's API (length is an integer rather than unsigned or size_t). Failure results in GNUTLS_A_DECODE_ERROR. * Proper casts to clear signed/unsigned warnings. * Proper casts from char* to opaque* to clear warnings. * Changed test to 'if (data_size > (MAX_STRING_LEN - 1) / 2)' in case of overflow using multiplication. I believe a [likely] stack smash was cleared in _gnutls_x509_oid_data2string at the call to _gnutls_str_cpy. Jeff Sorry about not using git-commit, git-format and friends per the README. The error message is not very useful to a git-layman (speaking from experience). $ cd gnutls $ git commit ./lib/x509/common.c $ git format-patch $ git send-email ./git/EDITMSG fatal: ambiguous argument './git/EDITMSG': unknown revision or path not in the working tree. Use '--' to separate paths from revisions format-patch -o /tmp/bg6BvZnp_r ./git/EDITMSG: command returned error: 128 $ git push fatal: The remote end hung up unexpectedly _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Fri 26 Nov 2010 07:26:20 AM GMT Name: common.patch Size: 9kB By: noloader _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 26 10:28:56 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Fri, 26 Nov 2010 09:28:56 +0000 Subject: [sr #107545] Patch: output.c Message-ID: <20101126-092855.sv80862.71660@savannah.gnu.org> URL: Summary: Patch: output.c Project: GnuTLS Submitted by: noloader Submitted on: Fri 26 Nov 2010 09:28:55 AM GMT Category: None Priority: 5 - Normal Severity: 2 - Minor Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: * cleared 16 warnings _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Fri 26 Nov 2010 09:28:55 AM GMT Name: output.patch Size: 7kB By: noloader _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 26 11:39:11 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Fri, 26 Nov 2010 10:39:11 +0000 Subject: [sr #107546] Incorrect use of snprintf Message-ID: <20101126-103910.sv80862.31800@savannah.gnu.org> URL: Summary: Incorrect use of snprintf Project: GnuTLS Submitted by: noloader Submitted on: Fri 26 Nov 2010 10:39:10 AM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: The following list calls to snprintf which do not check for a return value. On failure, snprintf returns -1. On truncation, the return value is >= destination buffer size (the return value does not include the NULL). Perhaps something similar to: int written = snprintf(buffer, size, ....); if(written == -1) { /* handle error */ } if(written >= size) { /* handle truncation */ } ... ===== lib/opencdk/keydb.c ===== 59: if (snprintf (fname, len, fmt, file) <= 0) ===== lib/pakchois/pakchois.c ===== 208: snprintf (path, sizeof path, "%s/%s%s%s", dir, 509: snprintf (buf, sizeof buf, 527: snprintf (buf, sizeof buf, ===== lib/pkcs11.c ===== 1351: snprintf (obj->info.manufacturer, sizeof (obj->info.manufacturer), 1353: snprintf (obj->info.token, sizeof (obj->info.token), "%s", tinfo->label); 1354: snprintf (obj->info.model, sizeof (obj->info.model), "%s", tinfo->model); 1355: snprintf (obj->info.serial, sizeof (obj->info.serial), "%s", 1358: snprintf (obj->info.lib_manufacturer, sizeof (obj->info.lib_manufacturer), 1360: snprintf (obj->info.lib_desc, sizeof (obj->info.lib_desc), "%s", 1362: snprintf (obj->info.lib_version, sizeof (obj->info.lib_version), "%u.%u", 1863: snprintf (find_data->info.lib_version, 2927: snprintf (version, sizeof (version), "%u.%u", ===== lib/x509/crq.c ===== 306: snprintf (tmpbuffer1, sizeof (tmpbuffer1), "%s.?%u", attr_name, k1); 308: snprintf (tmpbuffer1, sizeof (tmpbuffer1), "?%u", k1); 350: snprintf (tmpbuffer3, sizeof (tmpbuffer3), "%s.values.?%u", 450: snprintf (name, sizeof (name), "%s", root); 461: snprintf (name, sizeof (name), "%s.?LAST.type", root); 470: snprintf (name, sizeof (name), "%s.?LAST.values", root); 479: snprintf (name, sizeof (name), "%s.?LAST.values.?LAST", root); 501: snprintf (name, sizeof (name), "%s.?%u", root, indx); 533: snprintf (name, sizeof (name), "%s.?%u", root, k); 1190: snprintf (name, sizeof (name), 1245: snprintf (name, sizeof (name), 1347: snprintf (name, sizeof (name), "?%u.extnID", indx + 1); 1367: snprintf (name, sizeof (name), "?%u.critical", indx + 1); 1478: snprintf (name, sizeof (name), "?%u.extnValue", indx + 1); 2129: snprintf (tmpstr, sizeof (tmpstr), "?%u", indx); ===== lib/x509/extensions.c ===== 59: snprintf (name, sizeof (name), "%s.?%u", root, k); 210: snprintf (name, sizeof (name), "%s.?%u", root, k); 314: snprintf (name, sizeof (name), "%s", root); 326: snprintf (name, sizeof (name), "%s.?LAST.extnID", root); 328: snprintf (name, sizeof (name), "?LAST.extnID"); 343: snprintf (name, sizeof (name), "%s.?LAST.critical", root); 345: snprintf (name, sizeof (name), "?LAST.critical"); 355: snprintf (name, sizeof (name), "%s.?LAST.extnValue", root); 357: snprintf (name, sizeof (name), "?LAST.extnValue"); 381: snprintf (name, sizeof (name), "%s.?%u", root, indx); 383: snprintf (name, sizeof (name), "?%u", indx); 431: snprintf (name, sizeof (name), "%s.?%u", root, k); 433: snprintf (name, sizeof (name), "?%u", k); ===== lib/x509/pkcs7.c ===== 307: snprintf (root2, sizeof (root2), "certificates.?%u", indx + 1); 695: snprintf (root2, sizeof (root2), "certificates.?%u", indx + 1); 768: snprintf (root2, sizeof (root2), "crls.?%u", indx + 1); 1005: snprintf (root2, sizeof (root2), "crls.?%u", indx + 1); ===== lib/x509/dn.c ===== 128: snprintf (tmpbuffer1, sizeof (tmpbuffer1), "%s.?%u", asn1_rdn_name, 131: snprintf (tmpbuffer1, sizeof (tmpbuffer1), "?%u", k1); 156: snprintf (tmpbuffer2, sizeof (tmpbuffer2), "%s.?%u", tmpbuffer1, 159: snprintf (tmpbuffer2, sizeof (tmpbuffer2), "?%u", k2); 371: snprintf (tmpbuffer1, sizeof (tmpbuffer1), "%s.?%u", asn1_rdn_name, 374: snprintf (tmpbuffer1, sizeof (tmpbuffer1), "?%u", k1); 400: snprintf (tmpbuffer2, sizeof (tmpbuffer2), "%s.?%u", tmpbuffer1, 403: snprintf (tmpbuffer2, sizeof (tmpbuffer2), "?%u", k2); 540: snprintf (tmpbuffer1, sizeof (tmpbuffer1), "%s.?%u", asn1_rdn_name, 543: snprintf (tmpbuffer1, sizeof (tmpbuffer1), "?%u", k1); 569: snprintf (tmpbuffer2, sizeof (tmpbuffer2), "%s.?%u", tmpbuffer1, 572: snprintf (tmpbuffer2, sizeof (tmpbuffer2), "?%u", k2); ===== lib/x509/pkcs12.c ===== 395: snprintf (root, sizeof (root), "?%u.bagId", i + 1); 419: snprintf (root, sizeof (root), "?%u.bagValue", i + 1); 446: snprintf (root, sizeof (root), "?%u.bagAttributes", i + 1); 463: snprintf (root, sizeof (root), "?%u.bagAttributes.?%u", i + 1, 615: snprintf (root2, sizeof (root2), "?%u.contentType", indx + 1); 636: snprintf (root2, sizeof (root2), "?%u.content", indx + 1); ===== lib/x509/crl.c ===== 510: snprintf (serial_name, sizeof (serial_name), 512: snprintf (date_name, sizeof (date_name), 936: snprintf (name, sizeof (name), "tbsCertList.crlExtensions.?%u.extnID", 951: snprintf (name, sizeof (name), "tbsCertList.crlExtensions.?%u.critical", 1009: snprintf (name, sizeof (name), "tbsCertList.crlExtensions.?%u.extnValue", ===== lib/x509/x509.c ===== 928: snprintf (nptr, sizeof (nptr), "%s.?%u", src_name, seq); 930: snprintf (nptr, sizeof (nptr), "?%u", seq); 987: snprintf (nptr, sizeof (nptr), "%s.?%u.otherName.type-id", 990: snprintf (nptr, sizeof (nptr), "?%u.otherName.type-id", seq); 1763: snprintf (name, sizeof (name), "tbsCertificate.extensions.?%u.extnID", 1778: snprintf (name, sizeof (name), "tbsCertificate.extensions.?%u.critical", 1834: snprintf (name, sizeof (name), "tbsCertificate.extensions.?%u.extnValue", 2026: snprintf (rbuf, sizeof (rbuf), "rdnSequence.?%d.?%d", irdn, iava); 2034: snprintf (rbuf, sizeof (rbuf), "?%d.type", iava); 2045: snprintf (rbuf, sizeof (rbuf), "?%d.value", iava); 2872: snprintf (tmpstr, sizeof (tmpstr), "?%u", indx); _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Fri Nov 26 14:01:59 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 26 Nov 2010 14:01:59 +0100 Subject: [SCM] GNU gnutls branch, gnutls_2_10_x, updated. gnutls_2_10_0-9-g301635a In-Reply-To: <20101122175912.GA3504@downhill.g.la> References: <87zkxv71ac.fsf@mocca.josefsson.org> <4C3CA3C4.3090702@gnutls.org> <20101120145316.GA14854@downhill.g.la> <4CEAA2B7.202@gnutls.org> <20101122175912.GA3504@downhill.g.la> Message-ID: <4CEFAFC7.3090005@gnutls.org> On 11/22/2010 06:59 PM, Andreas Metzler wrote: >> Unfortunately this is the API since quite long to be changed. >> Applications are to set the required for verification flags. A way to >> solve this would be to make a higher level verification procedure >> (functionality). It is not on my immediate plans though. > Actually the implemented API has changed in the no too distant past, > versions before 2.4.3 accepted V1 CA certs. I've reverted this behavior then: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=60ee8a0eb9975d123002b1cffbefd60a8cd5fae6 regards, Nikos From noloader at gmail.com Fri Nov 26 16:08:11 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 26 Nov 2010 10:08:11 -0500 Subject: GNUTLS_ASSERT macro Message-ID: Hi All, A properly asserted program expedites finding the point of first failure in a program or library. I believe the current GnuTLS assert could be improved. In fact, it appears others would find asserts and "self debugging code" useful: "main: TLS init def ctx failed: -1", http://www.mail-archive.com/help-gnutls at gnu.org/msg01999.html. Fredrik's comment: I guess my only option now is to instrument that part with debug information to see what return -1 triggers the error. .... Or can I turn on some gnutls flag that prints debug information ? Frederik is asking for an assert to find the point of first failure so he does not have to waste time under the debugger. ===== The use of gnutls_assert() is somewhat unconventional. Typically one asserts as follows: ret = some_function(...); assert(ret == 0); if(ret != 0) .... But the project is using its assert as follows: ret = some_function(...); if(ret != 0) { gnutls_assert(ret == 0); .... } Trying to use gnutls_assert conventionally results in a compile error. ===== Typically, and application or library is built with either a "debug" configuration, or a "release" configuration. The current assert is gnutls_assert(), which does nothing when DEBUG is defined. Inspecting gnutls_errors.h reveals a very unconventional definition: #ifdef __FILE__ # ifdef __LINE__ # define gnutls_assert() _gnutls_debug_log( "ASSERT: %s:%d\n", __FILE__,__LINE__); # else # define gnutls_assert() # endif #else /* __FILE__ not defined */ # define gnutls_assert() #endif GnuTLS should probably honor the intent of standard assert() and provide equivalent behavior: if NDEBUG is defined, asserts are not compiled into the program code. Otherwise, asserts are compiled into the program code [1]. ===== According to the Open Group Base Specifications [1], "assert() shall write information about the particular call that failed on stderr and shall call abort()." I've never liked the behavior, so I install my own SIG_TRAP handler. It works great on Linux (Debian, Fedora, Ubuntu), Mac OS X, and iPhone. If a debugger is attached, the debugger snaps. If no debugger is attached, the program continues normally after writing a message to stderr. The project is welcome to the code if interested. I'll place it in public domain, so there will be absolutely no licensing issues. ===== The 'make check' target should be assert agnostic. I've already experienced some automake awkwardness because the tests take the same settings as the libraries. My experience has been that building both libraries and tests with asserts spuriously pops asserts on negative tests. The spurious asserts are a total distraction. What I really wanted was a way to build one particular test, so I could get the one test under gdb. But automake and friends has a penchant for building a group of applications, and then running the group, and then building another group, etc. Missing the ability to build one test with desired settings, I've found a desire to disgorge the libraries' CFLAGS from the tests' CFLAGS. As far as I can tell, thats not possible either. Jeff [1] http://www.opengroup.org/onlinepubs/009695399/functions/assert.html From nmav at gnutls.org Fri Nov 26 18:19:16 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 26 Nov 2010 18:19:16 +0100 Subject: GNUTLS_ASSERT macro In-Reply-To: References: Message-ID: On Fri, Nov 26, 2010 at 4:08 PM, Jeffrey Walton wrote: > Hi All, > A properly asserted program expedites finding the point of first > failure in a program or library. I believe the current GnuTLS assert > could be improved. gnutls_assert() is not related to the use of assert(). The name might be confusing, but it's already there. We use gnutls_assert() to get an easy backtrace of a program that fails without going through the debugger. There is run-time functionality to enable assertions and print information on them. > Typically, and application or library is built with either a "debug" > configuration, or a "release" configuration. The current assert is > gnutls_assert(), which does nothing when DEBUG is defined. It's not related to how assert() works. > GnuTLS should probably honor the intent of standard assert() and > provide equivalent behavior: if NDEBUG is defined, asserts are not > compiled into the program code. Otherwise, asserts are compiled into > the program code [1]. No. The original assert() is very dangerous, and pretty useless to me. Projects that need assertions why wouldn't they use them in production code? The cost of the instructions of the "if" is pretty low to even consider it. regards, Nikos From noloader at gmail.com Fri Nov 26 18:25:48 2010 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 26 Nov 2010 12:25:48 -0500 Subject: GNUTLS_ASSERT macro In-Reply-To: References: Message-ID: On Fri, Nov 26, 2010 at 12:19 PM, Nikos Mavrogiannopoulos wrote: > On Fri, Nov 26, 2010 at 4:08 PM, Jeffrey Walton wrote: >> Hi All, >> A properly asserted program expedites finding the point of first >> failure in a program or library. I believe the current GnuTLS assert >> could be improved. > > gnutls_assert() is not related to the use of assert(). The name might > be confusing, but it's already there. We use gnutls_assert() to get an > easy backtrace of a program that fails without going through the debugger. > > There is run-time functionality to enable assertions and print information > on them. > >> Typically, and application or library is built with either a "debug" >> configuration, or a "release" configuration. The current assert is >> gnutls_assert(), which does nothing when DEBUG is defined. > > It's not related to how assert() works. > >> GnuTLS should probably honor the intent of standard assert() and >> provide equivalent behavior: if NDEBUG is defined, asserts are not >> compiled into the program code. Otherwise, asserts are compiled into >> the program code [1]. > > No. The original assert() is very dangerous, How so? > ... and pretty useless to me. OK. To each their own. > Projects that need assertions why wouldn't they use them > in production code? Asserts are a development tool. Hence the reason the standard states "[defining NDEBUG] shall stop assertions from being compiled into the program." > The cost of the instructions of the "if" is pretty low to even > consider it. Agreed. I don't worry about 3 cycles, and with modern branch prediction algorithms, the hit rate is well over 90%. Jeff From nikias at gmx.li Fri Nov 26 21:39:29 2010 From: nikias at gmx.li (Nikias Bassen) Date: Fri, 26 Nov 2010 21:39:29 +0100 Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice In-Reply-To: References: <20101122001723.70acc8e0@i7katze> <20101124062520.354b4245@i7katze> <4CECCCE9.2010004@gnutls.org> <20101124110547.0382c934@i7katze> Message-ID: <20101126213929.2dd4b474@i7katze> Hi, On Wed, 24 Nov 2010 12:17:49 +0100 Nikos Mavrogiannopoulos wrote: > On Wed, Nov 24, 2010 at 11:05 AM, Nikias Bassen wrote: > >> > if (SSL_CTX_use_certificate_file(ssl_ctx, > >> > ? "/path/to/certificate.pem", > >> > ? SSL_FILETYPE_PEM) != 1) { > >> > ? ? debug_info("WARNING: Could not load RootCertificate"); > >> > } > >> > if (SSL_CTX_use_RSAPrivateKey_file(ssl_ctx, > >> > ? "/path/to/privatekey.pem", > >> > ? SSL_FILETYPE_PEM) != 1) { > >> > ? ? debug_info("WARNING: Could not load RootPrivateKey"); > >> > } > >> > What is the equivalent to this when using gnutls? > >> Check gnutls_certificate_set_x509_key_file() and the examples in the > >> gnutls manual. > > These functions are intended for the server, right? Remember we are on the > > client side. Does that make any difference? > > No. They are functions for the one that wants to use certificate (it can be > either server or client). The only distinction between server and > client in gnutls > is being done in gnutls_init(). Most of the other functions are applicable to > both unless they mention otherwise in the description. I made dumps with OpenSSL (succeeding) and GnuTLS (failing) and found out that the GnuTLS code fails because it can't find a certificate. It sends the following packet to the device, instead of the certificate (like openssl does) ssl_write(7) { 15 -- Alert 03 00 -- SSL3.0 00 02 -- Length 01 -- Warning 29 -- No Certificate } And this is why it fails, since the device wants to verify the peer (this is new in iOS 4.2). However, I set the certficate (and private key) with gnutls_certificate_set_x509_key_file() with GNUTLS_X509_FMT_PEM: [...] char *rootcert = g_build_path(G_DIR_SEPARATOR_S, g_get_user_config_dir(), "libimobiledevice", "RootCertificate.pem", NULL); char *rootpkey = g_build_path(G_DIR_SEPARATOR_S, g_get_user_config_dir(), "libimobiledevice", "RootPrivateKey.pem", NULL); // the paths are ok, double checked it. And OpenSSL is happy with them too. [...] gnutls_global_init(); gnutls_certificate_allocate_credentials(&ssl_data_loc->certificate); int res = gnutls_certificate_set_x509_key_file(ssl_data_loc->certificate, rootcert, rootpkey, GNUTLS_X509_FMT_PEM); printf("res=%d\n",res); // <-- returns 0 gnutls_init(&ssl_data_loc->session, GNUTLS_CLIENT); { int protocol_priority[16] = { GNUTLS_SSL3, 0 }; int kx_priority[16] = { GNUTLS_KX_ANON_DH, GNUTLS_KX_RSA, 0 }; int cipher_priority[16] = { GNUTLS_CIPHER_AES_256_CBC, 0 }; int mac_priority[16] = { GNUTLS_MAC_SHA1, GNUTLS_MAC_MD5, 0 }; int comp_priority[16] = { GNUTLS_COMP_NULL, 0 }; gnutls_cipher_set_priority(ssl_data_loc->session, cipher_priority); gnutls_compression_set_priority(ssl_data_loc->session, comp_priority); gnutls_kx_set_priority(ssl_data_loc->session, kx_priority); gnutls_protocol_set_priority(ssl_data_loc->session, protocol_priority); gnutls_mac_set_priority(ssl_data_loc->session, mac_priority); } gnutls_credentials_set(ssl_data_loc->session, GNUTLS_CRD_CERTIFICATE, ssl_data_loc->certificate); [...] Both files are in .pem format. Is this correct, and if so, is there any way to debug this issue? Greetings Nikias From INVALID.NOREPLY at gnu.org Sat Nov 27 04:59:28 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Sat, 27 Nov 2010 03:59:28 +0000 Subject: [sr #107547] DH Parameter Generation Message-ID: <20101127-035927.sv80862.9940@savannah.gnu.org> URL: Summary: DH Parameter Generation Project: GnuTLS Submitted by: noloader Submitted on: Sat 27 Nov 2010 03:59:27 AM GMT Category: None Priority: 5 - Normal Severity: 1 - Wish Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: Hi All, While tracing group parameter generation code in wrap_nettle_generate_group, I came across a comment regarding the perceived slowness of the algorithm. I also thought the 'gendh; test program hung during testing (confer: SR #107535, "'make check' - hang after 'PASS: mini-x509-rehandshake'", https://savannah.gnu.org/support/?107535). Attached is a paper by Joye1, Paillier1, and Vaudenay that describes an efficient method for safe primes. See section 7.2 Generation of Safe Primes. Jeff _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Sat 27 Nov 2010 03:59:27 AM GMT Name: Efficient Generation of Prime Numbers.pdf Size: 191kB By: noloader _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sat Nov 27 06:03:34 2010 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sat, 27 Nov 2010 05:03:34 +0000 Subject: [sr #107547] DH Parameter Generation In-Reply-To: <20101127-035927.sv80862.9940@savannah.gnu.org> References: <20101127-035927.sv80862.9940@savannah.gnu.org> Message-ID: <20101127-070334.sv707.97022@savannah.gnu.org> Update of sr #107547 (project gnutls): Status: None => Confirmed _______________________________________________________ Follow-up Comment #1: There quite some many efficient methods, and the libgcrypt method (Lim-Lee?) is also pretty fast. The one I implemented with nettle is the easiest one to implement. If you can submit a patch a with another faster method would be nice. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Sat Nov 27 06:07:07 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 27 Nov 2010 06:07:07 +0100 Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice In-Reply-To: <20101126213929.2dd4b474@i7katze> References: <20101122001723.70acc8e0@i7katze> <20101124062520.354b4245@i7katze> <4CECCCE9.2010004@gnutls.org> <20101124110547.0382c934@i7katze> <20101126213929.2dd4b474@i7katze> Message-ID: <4CF091FB.6070303@gnutls.org> On 11/26/2010 09:39 PM, Nikias Bassen wrote: >> No. They are functions for the one that wants to use certificate (it can be >> either server or client). The only distinction between server and >> client in gnutls >> is being done in gnutls_init(). Most of the other functions are applicable to >> both unless they mention otherwise in the description. > I made dumps with OpenSSL (succeeding) and GnuTLS (failing) and found out that > the GnuTLS code fails because it can't find a certificate. It sends the > following packet to the device, instead of the certificate (like openssl does) If you use gnutls_certificate_set_x509_key_file() then it will send a certificate to the server if the server requests a CA that matches the one in the certificate (you can check which one the server requested by viewing the transaction in wireshark). An alternative way, which you can force to send a certificate even if the server didn't request one, is by using the certificate callback function. See example in: http://www.gnu.org/software/gnutls/manual/html_node/Using-a-callback-to-select-the-certificate-to-use.html#Using-a-callback-to-select-the-certificate-to-use regards, Nikos From INVALID.NOREPLY at gnu.org Sat Nov 27 08:13:19 2010 From: INVALID.NOREPLY at gnu.org (Jeffrey Walton) Date: Sat, 27 Nov 2010 07:13:19 +0000 Subject: [sr #107547] DH Parameter Generation In-Reply-To: <20101127-070334.sv707.97022@savannah.gnu.org> References: <20101127-035927.sv80862.9940@savannah.gnu.org> <20101127-070334.sv707.97022@savannah.gnu.org> Message-ID: <20101127-071319.sv80862.28101@savannah.gnu.org> Follow-up Comment #2, sr #107547 (project gnutls): Added Lim and Lee paper _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nikias at gmx.li Sat Nov 27 15:20:28 2010 From: nikias at gmx.li (Nikias Bassen) Date: Sat, 27 Nov 2010 15:20:28 +0100 Subject: iDevice GnuTLS issue with iOS 4.2 - libimobiledevice In-Reply-To: <4CF091FB.6070303@gnutls.org> References: <20101122001723.70acc8e0@i7katze> <20101124062520.354b4245@i7katze> <4CECCCE9.2010004@gnutls.org> <20101124110547.0382c934@i7katze> <20101126213929.2dd4b474@i7katze> <4CF091FB.6070303@gnutls.org> Message-ID: <20101127152028.20afc45d@i7katze> Hi, that did the trick. The fix for libimobiledevice is in git master now. Regards, Nikias On Sat, 27 Nov 2010 06:07:07 +0100 Nikos Mavrogiannopoulos wrote: > On 11/26/2010 09:39 PM, Nikias Bassen wrote: > > >> No. They are functions for the one that wants to use certificate (it can be > >> either server or client). The only distinction between server and > >> client in gnutls > >> is being done in gnutls_init(). Most of the other functions are applicable to > >> both unless they mention otherwise in the description. > > I made dumps with OpenSSL (succeeding) and GnuTLS (failing) and found out that > > the GnuTLS code fails because it can't find a certificate. It sends the > > following packet to the device, instead of the certificate (like openssl does) > > If you use gnutls_certificate_set_x509_key_file() then it will send a > certificate to the server if the server requests a CA that matches the > one in the certificate (you can check which one the server requested by > viewing the transaction in wireshark). > > An alternative way, which you can force to send a certificate even if > the server didn't request one, is by using the certificate callback > function. See example in: > http://www.gnu.org/software/gnutls/manual/html_node/Using-a-callback-to-select-the-certificate-to-use.html#Using-a-callback-to-select-the-certificate-to-use > > > regards, > Nikos > From nmav at gnutls.org Sat Nov 27 19:51:19 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 27 Nov 2010 19:51:19 +0100 Subject: libtasn1, asn1_read_value, and truncation In-Reply-To: References: Message-ID: <4CF15327.8080608@gnutls.org> On 11/26/2010 06:57 AM, Jeffrey Walton wrote: > Hi All, > > How does one detect if/when libtasn1 truncates the value during > asn1_read_value. It is not clear to me from the online documentation > (http://www.gnu.org/software/libtasn1/manual/libtasn1.html). > > Should GnuTLS infer truncation *if* the reported length of the value > (from asn1_read_value) is the same as the size of the buffer? (The > strategy is similar to interpreting return values from snprintf). It would return an error that the provided buffer is not long enough. regards, Nikos From INVALID.NOREPLY at gnu.org Sat Nov 27 19:53:49 2010 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sat, 27 Nov 2010 18:53:49 +0000 Subject: [sr #107546] Incorrect use of snprintf In-Reply-To: <20101126-103910.sv80862.31800@savannah.gnu.org> References: <20101126-103910.sv80862.31800@savannah.gnu.org> Message-ID: <20101127-205349.sv707.73675@savannah.gnu.org> Follow-up Comment #1, sr #107546 (project gnutls): The use cases we have shouldn't trigger an error in snprintf and truncation isn't an issue. If you think there are cases where ignoring the error could cause problems, we can add a fix for that case. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Sat Nov 27 19:55:00 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 27 Nov 2010 19:55:00 +0100 Subject: GNUTLS_ASSERT macro In-Reply-To: References: Message-ID: <4CF15404.6050803@gnutls.org> On 11/26/2010 06:25 PM, Jeffrey Walton wrote: >>> GnuTLS should probably honor the intent of standard assert() and >>> provide equivalent behavior: if NDEBUG is defined, asserts are not >>> compiled into the program code. Otherwise, asserts are compiled into >>> the program code [1]. >> No. The original assert() is very dangerous, > How so? Production code is less safe than testing code. regards, Nikos