From joe at x2a.org Sat Aug 1 18:43:36 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Sat, 01 Aug 2009 12:43:36 -0400 Subject: [PATCH][PULL] Add explicit feature checks Message-ID: <4A7470B8.1090909@x2a.org> As promised, I have added functions for explicit feature checks. I have not changed version == GNUTLS_SSL3 checks since those are version checks and not feature checks. No test-suite detectable regressions were introduced. Thanks for reviewing my patches. The following changes since commit c9f5ec9d1b504e5341b660c5062729325243a633: Simon Josefsson (1): Drop .c and sort. are available in the git repository at: git://x2a.org/gnutls.git version-checks Jonathan Bastien-Filiatrault (9): Add version check functions for selectable PRF and extension handling. Add version check function for explicit IV. Add version check functions for non-minimal padding. Add version check function for selectable signature/hash certificate algorithms. Remove hardcoded version checks in gnutls_handshake.c. Remove hardcoded version checks in gnutls_sig.c. Remove hardcoded version checks in gnutls_cipher.c. Remove hardcoded version check in gnutls_state.c. Remove hardcoded version checks in auth_cert.c. lib/auth_cert.c | 6 +++--- lib/gnutls_algorithms.c | 41 +++++++++++++++++++++++++++++++++++++++++ lib/gnutls_algorithms.h | 7 +++++++ lib/gnutls_cipher.c | 12 ++++++------ lib/gnutls_handshake.c | 12 ++++++------ lib/gnutls_sig.c | 8 ++++---- lib/gnutls_state.c | 2 +- 7 files changed, 68 insertions(+), 20 deletions(-) Regards, Jonathan From simon at josefsson.org Mon Aug 3 15:16:38 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 03 Aug 2009 15:16:38 +0200 Subject: [PATCH][PULL] Add explicit feature checks In-Reply-To: <4A7470B8.1090909@x2a.org> (Jonathan Bastien-Filiatrault's message of "Sat, 01 Aug 2009 12:43:36 -0400") References: <4A7470B8.1090909@x2a.org> Message-ID: <871vntrqa1.fsf@mocca.josefsson.org> Jonathan Bastien-Filiatrault writes: > As promised, I have added functions for explicit feature checks. Thank you. I'll apply as soon as the FSF copyright papers have arrived. I'll review them when my 'git clone' finishes downloading your repository... /Simon From ueno at unixuser.org Mon Aug 3 20:19:21 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Tue, 04 Aug 2009 03:19:21 +0900 Subject: [PATCH] session ticket support In-Reply-To: (Nikos Mavrogiannopoulos's message of "Thu, 30 Jul 2009 23:48:43 +0300") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> Message-ID: <91339156-e2d5-48c3-aa5f-605faff2c047@broken.deisui.org> >>>>> In >>>>> Nikos Mavrogiannopoulos wrote: > > When I changed _gnutls_recv_new_session_ticket to generate new session > > ID, it started to work. ?I attach the new patch, which includes: > I have some questions for you. I was checking the parts that unpack > and pack the session and was wondering whether using the > _gnutls_session_pack() would be possible. In that case both > implementations of the DB and session ticket backends will share > common code. I chose the RFC format just because the patch was initially for experimental purpose. Using _gnutls_session_pack() would be definitely better. I've just tried to make use of the internal format, the code became much simpler (which reduced ~100 lines). Thanks for the suggestion. > Another issue I noticed while checking the code is that if the session > ticket doesn't decrypt well or doesn't verify well, an error is > returned... Wouldn't it be more appropriate to just continue ignoring > the ticket and perform a full handshake? Absolutely. I'll post a new patch shortly, with other polishments (adding interface docs, etc.). Regards, -- Daiki Ueno From simon at josefsson.org Mon Aug 3 23:25:54 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 03 Aug 2009 23:25:54 +0200 Subject: [PATCH] session ticket support In-Reply-To: <91339156-e2d5-48c3-aa5f-605faff2c047@broken.deisui.org> (Daiki Ueno's message of "Tue, 04 Aug 2009 03:19:21 +0900") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <91339156-e2d5-48c3-aa5f-605faff2c047@broken.deisui.org> Message-ID: <87iqh4pp25.fsf@mocca.josefsson.org> Daiki Ueno writes: >>>>>> In >>>>>> Nikos Mavrogiannopoulos wrote: >> > When I changed _gnutls_recv_new_session_ticket to generate new session >> > ID, it started to work. ?I attach the new patch, which includes: > >> I have some questions for you. I was checking the parts that unpack >> and pack the session and was wondering whether using the >> _gnutls_session_pack() would be possible. In that case both >> implementations of the DB and session ticket backends will share >> common code. > > I chose the RFC format just because the patch was initially for > experimental purpose. Using _gnutls_session_pack() would be definitely > better. I'm not sure, couldn't there be situations where applications want to use the RFC ticket format? Maybe the format should be configurable, so the application can decide. Since you have already written support for the RFC ticket format, I think it would be nice to support it somehow. /Simon From simon at josefsson.org Mon Aug 3 23:38:18 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 03 Aug 2009 23:38:18 +0200 Subject: solutions In-Reply-To: <4A43C7FE.9090108@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 25 Jun 2009 21:54:54 +0300") References: <4A43C7FE.9090108@gnutls.org> Message-ID: <87bpmwpohh.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > diff --git a/lib/x509/common.c b/lib/x509/common.c > index 51da7b1..71a4114 100644 > --- a/lib/x509/common.c > +++ b/lib/x509/common.c > @@ -181,7 +181,7 @@ _gnutls_x509_oid_data2string (const char *oid, void *value, > { > char str[MAX_STRING_LEN], tmpname[128]; > const char *ANAME = NULL; > - int CHOICE = -1, len = -1, result; > + int CHOICE = -1, len = -1, result, i; > ASN1_TYPE tmpasn = ASN1_TYPE_EMPTY; > char asn1_err[ASN1_MAX_ERROR_DESCRIPTION_SIZE] = ""; > > @@ -309,6 +309,12 @@ _gnutls_x509_oid_data2string (const char *oid, void *value, > } > } > } > + > + /* Convert null char in the name to '?' > + * to protect applications */ > + for (i=0;i<*res_size;i++) { > + if (res[i] == 0) res[i]='?'; > + } > > return 0; > } Hi Nikos -- this code crashed the self-tests, but I fixed that. However, isn't this the wrong way to address the real problem? It seems callers of the function should be fixed to be careful not to assume decoded data does not contain NULs? /Simon From simon at josefsson.org Tue Aug 4 00:20:48 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 04 Aug 2009 00:20:48 +0200 Subject: solutions In-Reply-To: <87bpmwpohh.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon, 03 Aug 2009 23:38:18 +0200") References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> Message-ID: <87k51ko7y7.fsf@mocca.josefsson.org> Simon Josefsson writes: > Nikos Mavrogiannopoulos writes: > >> diff --git a/lib/x509/common.c b/lib/x509/common.c >> index 51da7b1..71a4114 100644 >> --- a/lib/x509/common.c >> +++ b/lib/x509/common.c >> @@ -181,7 +181,7 @@ _gnutls_x509_oid_data2string (const char *oid, void *value, >> { >> char str[MAX_STRING_LEN], tmpname[128]; >> const char *ANAME = NULL; >> - int CHOICE = -1, len = -1, result; >> + int CHOICE = -1, len = -1, result, i; >> ASN1_TYPE tmpasn = ASN1_TYPE_EMPTY; >> char asn1_err[ASN1_MAX_ERROR_DESCRIPTION_SIZE] = ""; >> >> @@ -309,6 +309,12 @@ _gnutls_x509_oid_data2string (const char *oid, void *value, >> } >> } >> } >> + >> + /* Convert null char in the name to '?' >> + * to protect applications */ >> + for (i=0;i<*res_size;i++) { >> + if (res[i] == 0) res[i]='?'; >> + } >> >> return 0; >> } > > Hi Nikos -- this code crashed the self-tests, but I fixed that. > > However, isn't this the wrong way to address the real problem? It seems > callers of the function should be fixed to be careful not to assume > decoded data does not contain NULs? Indeed the code doesn't seem to be right, since it uses _gnutls_str_cpy which uses strlen earlier to get the length of the string. So instead of truncating on the \0 it will add a ? and truncate after the \0. Fixing the callers should be the right solution. Let's hope our API isn't broken and uses zero terminated strings for these strings... /Simon From nmav at gnutls.org Tue Aug 4 07:23:28 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 04 Aug 2009 08:23:28 +0300 Subject: solutions In-Reply-To: <87bpmwpohh.fsf@mocca.josefsson.org> References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> Message-ID: <4A77C5D0.9060901@gnutls.org> Simon Josefsson wrote: >> return 0; >> } > > Hi Nikos -- this code crashed the self-tests, but I fixed that. > > However, isn't this the wrong way to address the real problem? It seems > callers of the function should be fixed to be careful not to assume > decoded data does not contain NULs? A null byte there is really malicious (why would a string contain a null byte?). Maybe using '?' is not the right solution, though. However I don't think the callers of this function will be safe... even the description of it says that the string will be null terminated :( I'd suggest to use memcpy for the cases of the gnutls_str_cpy to avoid having certificates that return a smaller DN value... From nmav at gnutls.org Tue Aug 4 07:25:06 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 04 Aug 2009 08:25:06 +0300 Subject: [PATCH] session ticket support In-Reply-To: <87iqh4pp25.fsf@mocca.josefsson.org> References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <91339156-e2d5-48c3-aa5f-605faff2c047@broken.deisui.org> <87iqh4pp25.fsf@mocca.josefsson.org> Message-ID: <4A77C632.3050201@gnutls.org> Simon Josefsson wrote: > I'm not sure, couldn't there be situations where applications want to > use the RFC ticket format? Maybe the format should be configurable, so > the application can decide. Since you have already written support for > the RFC ticket format, I think it would be nice to support it somehow. Actually the ticket format is transparent (or better encrypted) to everyone except gnutls. Thus there is very little incentive to keep separate code for something that is useful only to us (if someone can use our ticket, it should be problem in our encryption :). regards, Nikos From wk at gnupg.org Tue Aug 4 10:31:46 2009 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Aug 2009 10:31:46 +0200 Subject: solutions In-Reply-To: <87bpmwpohh.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon, 03 Aug 2009 23:38:18 +0200") References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> Message-ID: <87tz0ornd9.fsf@wheatstone.g10code.de> On Mon, 3 Aug 2009 23:38, simon at josefsson.org said: > However, isn't this the wrong way to address the real problem? It seems > callers of the function should be fixed to be careful not to assume > decoded data does not contain NULs? This is often hard to implement. FWIW, Libksba uses an rfc-2253 representation of DNs in its API, thus there is no problem due to the required quoting. However, for bad (well, unlikely) encodings of URLs, Libksba now uses a made up OID to indicate this error: 1.3.6.1.4.1.11591.2.12242973 (invalid encoded OID). You may want to use a similar hack. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Tue Aug 4 13:53:20 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 04 Aug 2009 13:53:20 +0200 Subject: solutions In-Reply-To: <4A77C5D0.9060901@gnutls.org> (Nikos Mavrogiannopoulos's message of "Tue, 04 Aug 2009 08:23:28 +0300") References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> <4A77C5D0.9060901@gnutls.org> Message-ID: <87ab2flrrj.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: > >>> return 0; >>> } >> >> Hi Nikos -- this code crashed the self-tests, but I fixed that. >> >> However, isn't this the wrong way to address the real problem? It seems >> callers of the function should be fixed to be careful not to assume >> decoded data does not contain NULs? > > A null byte there is really malicious (why would a string contain a null > byte?). The standards permit it... > Maybe using '?' is not the right solution, though. However I don't > think the callers of this function will be safe... even the > description of it says that the string will be null terminated :( I'd > suggest to use memcpy for the cases of the gnutls_str_cpy to avoid > having certificates that return a smaller DN value... The function already escape strings as per RFC 2253 in some cases, so I think it would be fine to escape any NUL byte with \00 which is as per RFC 2253. Then the string will be zero terminated and will look correct. Replacing NUL bytes with ? isn't perfect since it damages information. So to avoid similar issues, we'd also need to replace any \ with \\ or \5C in the string. I'm implementing this now. /Simon From simon at josefsson.org Tue Aug 4 13:56:27 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 04 Aug 2009 13:56:27 +0200 Subject: solutions In-Reply-To: <87tz0ornd9.fsf@wheatstone.g10code.de> (Werner Koch's message of "Tue, 04 Aug 2009 10:31:46 +0200") References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> <87tz0ornd9.fsf@wheatstone.g10code.de> Message-ID: <8763d3lrmc.fsf@mocca.josefsson.org> Werner Koch writes: > On Mon, 3 Aug 2009 23:38, simon at josefsson.org said: > >> However, isn't this the wrong way to address the real problem? It seems >> callers of the function should be fixed to be careful not to assume >> decoded data does not contain NULs? > > This is often hard to implement. > > FWIW, Libksba uses an rfc-2253 representation of DNs in its API, thus > there is no problem due to the required quoting. Right, and this seems to be the right way forward too. GnuTLS uses RFC 2253 format too, but it didn't escape strings properly. :-( > However, for bad (well, unlikely) encodings of URLs, Libksba now uses > a made up OID to indicate this error: 1.3.6.1.4.1.11591.2.12242973 > (invalid encoded OID). You may want to use a similar hack. I don't see how to use this in GnuTLS since there are functions that return data associated with a particular (input variable) OID. If that function is passed the OID for CN, it has to return the information, otherwise you'll get other problems if you return an error saying that there is no CN field. But if we use the RFC 2253 formatting, all things are safe. /Simon From simon at josefsson.org Tue Aug 4 13:59:03 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 04 Aug 2009 13:59:03 +0200 Subject: [PATCH] session ticket support In-Reply-To: <4A77C632.3050201@gnutls.org> (Nikos Mavrogiannopoulos's message of "Tue, 04 Aug 2009 08:25:06 +0300") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <91339156-e2d5-48c3-aa5f-605faff2c047@broken.deisui.org> <87iqh4pp25.fsf@mocca.josefsson.org> <4A77C632.3050201@gnutls.org> Message-ID: <871vnrlri0.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: > >> I'm not sure, couldn't there be situations where applications want to >> use the RFC ticket format? Maybe the format should be configurable, so >> the application can decide. Since you have already written support for >> the RFC ticket format, I think it would be nice to support it somehow. > > Actually the ticket format is transparent (or better encrypted) to > everyone except gnutls. Thus there is very little incentive to keep > separate code for something that is useful only to us (if someone can > use our ticket, it should be problem in our encryption :). If we use our own pack/unpack format, it won't be possible to set up TLS load-balancing between GnuTLS and some other implementation that accepts session tickets on another format. Maybe that is a minor issue, but it could come up. Or is there some other reason why that setup would never work anyway? /Simon From simon at josefsson.org Tue Aug 4 14:15:33 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 04 Aug 2009 14:15:33 +0200 Subject: [PATCH] session ticket support In-Reply-To: (Daiki Ueno's message of "Tue, 28 Jul 2009 10:27:39 +0900") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> Message-ID: <87ws5jkc62.fsf@mocca.josefsson.org> Daiki Ueno writes: > * New interface functions as you suggested. > > int gnutls_session_ticket_allocate_key (gnutls_session_ticket_key_t *); > int gnutls_session_ticket_randomize (gnutls_session_ticket_key_t); > int gnutls_session_ticket_import (gnutls_session_t, void *, size_t); > int gnutls_session_ticket_export (gnutls_session_t, void *, size_t *); I suggest renaming these APIs like this: gnutls_session_ticket_key_allocate gnutls_session_ticket_key_randomize gnutls_session_ticket_key_import gnutls_session_ticket_key_export Also, what do you think about a 'gnutls_session_ticket_key_format_t' parameter? I think some people may want to export the key in text-format rather than raw binary. Also the above API hard-codes the use of AES-128 + HMAC-SHA-256 which won't be good choices forever. How about changing the randomize function into: int gnutls_session_ticket_key_randomize (gnutls_session_ticket_key_t, gnutls_cipher_algorithm_t cipher, gnutls_mac_algorithm_t mac); The docstring should recommend applications to use AES-128 and HMAC-SHA-256. I see that some struct sizes in the RFC (like IV and MAC size) are hard coded, so it may not be worth time to extrapolate that part to support non-AES-128/HMAC-SHA-256 options. So gnutls_session_ticket_key_randomize could return an error if other choices than AES-128/HMAC-SHA-256 are used. This means the API is ready if RFC 5077bis defines support for HMAC-SHA-3 or similar. Thanks, /Simon From nmav at gnutls.org Tue Aug 4 14:38:39 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 4 Aug 2009 15:38:39 +0300 Subject: [PATCH] session ticket support In-Reply-To: <871vnrlri0.fsf@mocca.josefsson.org> References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <91339156-e2d5-48c3-aa5f-605faff2c047@broken.deisui.org> <87iqh4pp25.fsf@mocca.josefsson.org> <4A77C632.3050201@gnutls.org> <871vnrlri0.fsf@mocca.josefsson.org> Message-ID: On Tue, Aug 4, 2009 at 2:59 PM, Simon Josefsson wrote: > If we use our own pack/unpack format, it won't be possible to set up TLS > load-balancing between GnuTLS and some other implementation that accepts > session tickets on another format. ?Maybe that is a minor issue, but it > could come up. ?Or is there some other reason why that setup would never > work anyway? No not really :) Especially since the RFC ticket format is underdefined (several parts are missing). If there will ever be some standard format we can switch our internal format and solve that issue, and in addition our DBs will be readable by others via memcached etc. regards, Nikos From nmav at gnutls.org Tue Aug 4 15:00:35 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 4 Aug 2009 16:00:35 +0300 Subject: [PATCH] session ticket support In-Reply-To: <87ws5jkc62.fsf@mocca.josefsson.org> References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <87ws5jkc62.fsf@mocca.josefsson.org> Message-ID: On Tue, Aug 4, 2009 at 3:15 PM, Simon Josefsson wrote: > Also the above API hard-codes the use of AES-128 + HMAC-SHA-256 which > won't be good choices forever. ?How about changing the randomize > function into: > > ?int gnutls_session_ticket_key_randomize (gnutls_session_ticket_key_t, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?gnutls_cipher_algorithm_t cipher, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?gnutls_mac_algorithm_t mac); Indeed the rename will make things more clear. However this might not be proper place to make the algorithms flexible since the allocation has been done before and had no knowledge of the required key sizes. Those options could have been in the allocation part. > I see that some struct sizes in the RFC (like IV and MAC size) are hard > coded, so it may not be worth time to extrapolate that part to support > non-AES-128/HMAC-SHA-256 options. ?So > gnutls_session_ticket_key_randomize could return an error if other > choices than AES-128/HMAC-SHA-256 are used. ?This means the API is ready > if RFC 5077bis defines support for HMAC-SHA-3 or similar. I am not really sure about the flexibility here. If a new rfc mandates some different algorithms would we expect the application need the change those? I would expect gnutls should have done it implicitely. Anyway I don't think is bad since many people would want to use AES-256 and hmac with 512 etc etc... If we add it we could do it with a different function that accepts additional parameters such as gnutls_session_ticket_key_allocate2(z,x,y ) and leave a simple allocate(x) that will set the defaults? regards, Nikos From simon at josefsson.org Tue Aug 4 15:21:29 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 04 Aug 2009 15:21:29 +0200 Subject: [PATCH] session ticket support In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue, 4 Aug 2009 15:38:39 +0300") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <91339156-e2d5-48c3-aa5f-605faff2c047@broken.deisui.org> <87iqh4pp25.fsf@mocca.josefsson.org> <4A77C632.3050201@gnutls.org> <871vnrlri0.fsf@mocca.josefsson.org> Message-ID: <87fxc7k946.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > On Tue, Aug 4, 2009 at 2:59 PM, Simon Josefsson wrote: > >> If we use our own pack/unpack format, it won't be possible to set up TLS >> load-balancing between GnuTLS and some other implementation that accepts >> session tickets on another format. ?Maybe that is a minor issue, but it >> could come up. ?Or is there some other reason why that setup would never >> work anyway? > > No not really :) Especially since the RFC ticket format is > underdefined (several parts are missing). Yes, and I suspect it is impossible to fully describe a format that covers all TLS extensions. What could be done to improve the current document is to allow type=value extensibility to let implementations store additional parameters. As the spec progress, it can be improved to specify some of the implementation-specific type=value fields. Implementations that doesn't support a particular type=value attribute can ignore it, and there could be better interoperability when using TLS load-balancing. If the document was designed this way, we could change GnuTLS pack/unpack format to use the core format and then add the non-standard parameters as extended type=value fields. > If there will ever be some standard format we can switch our internal > format and solve that issue, and in addition our DBs will be readable > by others via memcached etc. Right. /Simon From simon at josefsson.org Tue Aug 4 15:23:53 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 04 Aug 2009 15:23:53 +0200 Subject: [PATCH] session ticket support In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue, 4 Aug 2009 16:00:35 +0300") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <87ws5jkc62.fsf@mocca.josefsson.org> Message-ID: <87bpmvk906.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > On Tue, Aug 4, 2009 at 3:15 PM, Simon Josefsson wrote: > >> Also the above API hard-codes the use of AES-128 + HMAC-SHA-256 which >> won't be good choices forever. ?How about changing the randomize >> function into: >> >> ?int gnutls_session_ticket_key_randomize (gnutls_session_ticket_key_t, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?gnutls_cipher_algorithm_t cipher, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?gnutls_mac_algorithm_t mac); > > Indeed the rename will make things more clear. However > this might not be proper place to make the algorithms flexible since > the allocation has been done before and had > no knowledge of the required key sizes. Those options could have been > in the allocation part. Good point. Let's ignore my suggestion. We can always add new APIs to generate particular keys later on if there is a need. >> I see that some struct sizes in the RFC (like IV and MAC size) are hard >> coded, so it may not be worth time to extrapolate that part to support >> non-AES-128/HMAC-SHA-256 options. ?So >> gnutls_session_ticket_key_randomize could return an error if other >> choices than AES-128/HMAC-SHA-256 are used. ?This means the API is ready >> if RFC 5077bis defines support for HMAC-SHA-3 or similar. > > I am not really sure about the flexibility here. If a new rfc mandates > some different algorithms would we > expect the application need the change those? I would expect gnutls > should have done it implicitely. Anyway I > don't think is bad since many people would want to use AES-256 and > hmac with 512 etc etc... If we add it we could do > it with a different function that accepts additional parameters such > as gnutls_session_ticket_key_allocate2(z,x,y ) and leave a simple > allocate(x) that will set the defaults? I agree. /Simon From nmav at gnutls.org Tue Aug 4 18:41:51 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 04 Aug 2009 19:41:51 +0300 Subject: solutions In-Reply-To: <87ab2flrrj.fsf@mocca.josefsson.org> References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> <4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org> Message-ID: <4A7864CF.4080702@gnutls.org> Simon Josefsson wrote: >>>> return 0; >>>> } >>> Hi Nikos -- this code crashed the self-tests, but I fixed that. >>> >>> However, isn't this the wrong way to address the real problem? It seems >>> callers of the function should be fixed to be careful not to assume >>> decoded data does not contain NULs? >> A null byte there is really malicious (why would a string contain a null >> byte?). > > The standards permit it... To be precise it is only allowed if a the string is tagged as ia5String. Other types do not allow null. From joe at x2a.org Wed Aug 5 01:06:12 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Tue, 04 Aug 2009 19:06:12 -0400 Subject: [RFC] Suggestion for the improvement of the buffering layer Message-ID: <4A78BEE4.3010802@x2a.org> Here is an implementation suggestion for the improvement of the current buffering code. This would be mostly for enabling easier DTLS integration and better maintainability in the future. Goals: - Preserve read/write boundaries at the transport level. This is mostly important for datagram packing. - Simplify interfaces between layers. - Eliminate the need for peeking (is this possible/desirable ?). - Allow pushing data into GnuTLS when the socket becomes readable and pulling from GnuTLS when the socket becomes writable. This is especially important for event-driven servers. Read and write callbacks could therefore be made optional for such programs. Suggested implementation: A pyramid of FIFO queues (linked lists would do), one queue per direction per layer. On the read() side, data would move upward by forming records from transport buffers. Records would then be demultiplexed and queued into upper layer protocols (handshake, alert, application). For the write() direction this would simply be reversed. This is close to what is done currently except the buffers would be message-based instead of bytestream-based. Advantages: - The separation of "message framing" and message processing. Example: A buffer_process function would form as much records as it can from the available transport buffers then a record_read would simply dequeue the first record from the list and process that record. If there is not enough data, the transport buffers would be refilled by invoking a read() on the socket. This would eliminate logic such as read_headers() then read() from the message processing pipeline and would move that logic inside the "message framing" code. - Better separation of concerns, easier to understand code, better modularity. It can be argued that better understandability, readability and modularity lead to better security (from programming errors). Disadvantages: - Much previously tested/debugged code would be discarded. - Feasibility not clear (to me). - Is it worth it ? Would it really be better ? Thanks for your input, Jonathan From ueno at unixuser.org Wed Aug 5 07:31:06 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Wed, 05 Aug 2009 14:31:06 +0900 Subject: [PATCH] session ticket support In-Reply-To: <87ws5jkc62.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 04 Aug 2009 14:15:33 +0200") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <87ws5jkc62.fsf@mocca.josefsson.org> Message-ID: <87vdl2rfmt.fsf@broken.deisui.org> >>>>> In <87ws5jkc62.fsf at mocca.josefsson.org> >>>>> Simon Josefsson wrote: > I suggest renaming these APIs like this: > gnutls_session_ticket_key_allocate > gnutls_session_ticket_key_randomize > gnutls_session_ticket_key_import > gnutls_session_ticket_key_export Thanks for the suggestion. I'll reflect them in the next patch. > Also, what do you think about a 'gnutls_session_ticket_key_format_t' > parameter? I think some people may want to export the key in > text-format rather than raw binary. As another option, how about making gnutls_session_ticket_key_t a public struct so that people can write custom export function? Regards, -- Daiki Ueno From wk at gnupg.org Wed Aug 5 09:03:27 2009 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Aug 2009 09:03:27 +0200 Subject: solutions In-Reply-To: <8763d3lrmc.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 04 Aug 2009 13:56:27 +0200") References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> <87tz0ornd9.fsf@wheatstone.g10code.de> <8763d3lrmc.fsf@mocca.josefsson.org> Message-ID: <87r5vqrbcw.fsf@wheatstone.g10code.de> On Tue, 4 Aug 2009 13:56, simon at josefsson.org said: > function is passed the OID for CN, it has to return the information, > otherwise you'll get other problems if you return an error saying that > there is no CN field. Better an error than doing something not intended. > But if we use the RFC 2253 formatting, all things are safe. Just make sure that parsing the BER of all arcs is fine and does not overflow. I consider an arc which can't be represented by a 32 bit value as fishy and return an error (i.e. the mentioned special OID). Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Wed Aug 5 10:08:02 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 05 Aug 2009 10:08:02 +0200 Subject: [PATCH] session ticket support In-Reply-To: <87vdl2rfmt.fsf@broken.deisui.org> (Daiki Ueno's message of "Wed, 05 Aug 2009 14:31:06 +0900") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <87ws5jkc62.fsf@mocca.josefsson.org> <87vdl2rfmt.fsf@broken.deisui.org> Message-ID: <87prbahee5.fsf@mocca.josefsson.org> Daiki Ueno writes: >>>>>> In <87ws5jkc62.fsf at mocca.josefsson.org> >>>>>> Simon Josefsson wrote: >> I suggest renaming these APIs like this: > >> gnutls_session_ticket_key_allocate >> gnutls_session_ticket_key_randomize >> gnutls_session_ticket_key_import >> gnutls_session_ticket_key_export > > Thanks for the suggestion. I'll reflect them in the next patch. Great. >> Also, what do you think about a 'gnutls_session_ticket_key_format_t' >> parameter? I think some people may want to export the key in >> text-format rather than raw binary. > > As another option, how about making gnutls_session_ticket_key_t a public > struct so that people can write custom export function? Thinking about that, doesn't a gnutls_datum_t suffice? Then you don't need the import/export functions at all. Possibly the allocate+randomize function could also be merged into one API: int gnutls_session_ticket_key_generate (gnutls_datum_t *key); The function would allocate and randomize key->data and set key->size accordingly. The key->data field needs to be released using gnutls_free as usual. /Simon From simon at josefsson.org Wed Aug 5 13:21:24 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 05 Aug 2009 13:21:24 +0200 Subject: solutions In-Reply-To: <87ab2flrrj.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 04 Aug 2009 13:53:20 +0200") References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> <4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org> Message-ID: <87zlaefqvf.fsf@mocca.josefsson.org> Having had some time to read the code, here are some observations: * The old _gnutls_x509_oid_data2string in lib/x509/common.c is buggy since it truncates the string after a NUL (it copies the string using strcpy instead of memcpy). The RES_SIZE length output variable is correct though, but output data beyond the NUL will be garbage. * I can see a few ways to solve the problem: 1) Make _gnutls_x509_oid_data2string escape NULs as \00 following RFC 2253. 2) Use memcpy instead of strcpy and change the documentation of the function to say that the returned string may contain embedded NULs, and fix the callers of that function. 3) Return a RFC 2253 #-style string for these strings. 4) Return an error when a NUL is encountered. * Solution 1) and 3) appear to break gnutls_x509_crq_get_challenge_password which is used to extract the certificate request challenge password. Password strings are not DNs and should not be escaped as per RFC 2253. If any of the escaped characters in RFC 2253 is used in a password (e.g., plus or comma), and if _gnutls_x509_oid_data2string escapes them, things will break. Further, the gnutls_x509_crq_get_challenge_password API does not use zero-terminated strings, so it can handle embedded NULs in password. The same problem could apply to DN SAN's and CRL distribution points, they are not documented in GnuTLS to be in LDAP escape format (although not documented to be in any other format either). However, if we really want to use 1) or 3) as the solution, the gnutls_x509_crq_get_challenge_password function could be modified to use some other code path to yield correct results. * Solution 2) could work but require that we investigate and possibly fix all callers. The function is used in three places: A) By parse_attribute in lib/x509/crq.c which is used by two other functions: A.1.) gnutls_x509_crq_get_challenge_password which is OK as per above. A.2) gnutls_x509_crq_get_attribute_by_oid. That function calls parse_attribute with RAW=1 which means that _gnutls_x509_oid_data2string is never called. B) By _gnutls_x509_parse_dn in lib/x509/dn.c. That function is documented to return a LDAP string. It performs RFC 2253 escaping by calling str_escape, which doesn't handle embedded NULs. C) By _gnutls_x509_parse_dn_oid in lib/x509/dn.c. That function is also documented to return a LDAP string, but does not perform RFC 2253 escaping so it is arguable broken. Both _gnutls_x509_parse_dn and _gnutls_x509_parse_dn_oid are used in many places in GnuTLS. Most of them are from APIs that actually are documented to return LDAP escaped strings (yay!) so we are relatively safe. However there is one usages that could be problematic: A) _gnutls_parse_general_name uses _gnutls_x509_parse_dn to extract a DirectoryName type of GeneralName. The _gnutls_parse_general_name function is also by gnutls_x509_crt_get_crl_dist_points to get the CRL distribution point. I suspect DN SAN's and use of CRL dist points are quite rare. Anyone with more insight? I believe 2 is actually the right solution but it may not be worth it, especially considering that there are not likely to be any non-malicious uses of NUL in a DNs. So while I prefer 2) since it allows GnuTLS to handle embedded NULs, I suspect 4) will result in more robust overall design. The patch could be as simple as the one below, but I need to do more testing. /Simon --- common.c~ 2009-06-02 20:59:32.000000000 +0200 +++ common.c 2009-08-05 13:18:17.000000000 +0200 @@ -1,5 +1,5 @@ /* - * Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation + * Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation * * Author: Nikos Mavrogiannopoulos * @@ -242,6 +242,9 @@ { str[len] = 0; + if (strlen (str) != len) + return GNUTLS_E_ASN1_DER_ERROR; + if (res) _gnutls_str_cpy (res, *res_size, str); *res_size = len; @@ -296,6 +299,8 @@ if (non_printable == 0) { str[len] = 0; + if (strlen (str) != len) + return GNUTLS_E_ASN1_DER_ERROR; _gnutls_str_cpy (res, *res_size, str); *res_size = len; } From bradh at frogmouth.net Wed Aug 5 14:14:43 2009 From: bradh at frogmouth.net (Brad Hards) Date: Wed, 5 Aug 2009 22:14:43 +1000 Subject: [patch] Request for review - X509 Issuer Altname handling Message-ID: <200908052214.44197.bradh@frogmouth.net> Hi, This patch (which I submit as a request for review / feedback) implements support for getting issuer altname. It is based on the equivalent subject altname code. [I'll submit it again for incorporation after my papers get worked through] Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: x509_issuer_altname-2009-08-05.patch Type: text/x-patch Size: 15121 bytes Desc: not available URL: From nmav at gnutls.org Wed Aug 5 20:25:20 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 05 Aug 2009 21:25:20 +0300 Subject: solutions In-Reply-To: <87zlaefqvf.fsf@mocca.josefsson.org> References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> <4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org> <87zlaefqvf.fsf@mocca.josefsson.org> Message-ID: <4A79CE90.8020706@gnutls.org> Simon Josefsson wrote: > Having had some time to read the code, here are some observations: > > * The old _gnutls_x509_oid_data2string in lib/x509/common.c is buggy > since it truncates the string after a NUL (it copies the string using > strcpy instead of memcpy). The RES_SIZE length output variable is > correct though, but output data beyond the NUL will be garbage. > > * I can see a few ways to solve the problem: > > 1) Make _gnutls_x509_oid_data2string escape NULs as \00 following RFC > 2253. > > 2) Use memcpy instead of strcpy and change the documentation of the > function to say that the returned string may contain embedded NULs, > and fix the callers of that function. > > 3) Return a RFC 2253 #-style string for these strings. > > 4) Return an error when a NUL is encountered. 4 is just ok. One could do 1 if he really bothers, but there is no reason for that. Even though IA5 string allows for null character there is no reason for us to allow it. It is the null terminator for C strings thus allowing it can cause only problems and complicated code. > * Solution 2) could work but require that we investigate and possibly > fix all callers. The function is used in three places: > > A) By parse_attribute in lib/x509/crq.c which is used by two other > functions: > > A.1.) gnutls_x509_crq_get_challenge_password which is OK as per above. > > A.2) gnutls_x509_crq_get_attribute_by_oid. That function calls > parse_attribute with RAW=1 which means that > _gnutls_x509_oid_data2string is never called. > > B) By _gnutls_x509_parse_dn in lib/x509/dn.c. That function is > documented to return a LDAP string. It performs RFC 2253 > escaping by calling str_escape, which doesn't handle embedded > NULs. > > C) By _gnutls_x509_parse_dn_oid in lib/x509/dn.c. That function is > also documented to return a LDAP string, but does not perform RFC > 2253 escaping so it is arguable broken. [...] > I believe 2 is actually the right solution but it may not be worth it, > especially considering that there are not likely to be any non-malicious > uses of NUL in a DNs. It looks a lot of effort to me and I also do not think it can weight the gain. I see no reason to allow nulls in a string that has the purpose to be shown and/or typed. regards, Nikos From nmav at gnutls.org Wed Aug 5 20:48:14 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 05 Aug 2009 21:48:14 +0300 Subject: [RFC] Suggestion for the improvement of the buffering layer In-Reply-To: <4A78BEE4.3010802@x2a.org> References: <4A78BEE4.3010802@x2a.org> Message-ID: <4A79D3EE.80106@gnutls.org> Jonathan Bastien-Filiatrault wrote: > Advantages: > > - The separation of "message framing" and message processing. Example: A > buffer_process function would form as much records as it can from the > available transport buffers then a record_read would simply dequeue the Hi, If I understand well you propose using something similar to skb's in linux? Can you give me an example of your proposal? Say in the TCP case we received a handshake message in 3 different packets and one is not yet received. How the processing will go before the 4th is received and how after that? > - Better separation of concerns, easier to understand code, better > modularity. It can be argued that better understandability, readability > and modularity lead to better security (from programming errors). > Disadvantages: > > - Much previously tested/debugged code would be discarded. Replacing ugly code with simpler one (or more efficient one) does not count as disadvantage to me. > - Is it worth it ? Would it really be better ? I'm curious whether something like that would be more efficient. In theory, if I get your idea correct, it would have less memcopy etc but in practice we are spending more time in decrypting/encrypting and the current code has quite reduced memcpy. However there is still space for improvement. If you are asking a go or not go, I'd say that it's up to you. In any case I am curious of any results and more design information. regards, Nikos From nmav at gnutls.org Wed Aug 5 20:49:45 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 05 Aug 2009 21:49:45 +0300 Subject: [patch] Request for review - X509 Issuer Altname handling In-Reply-To: <200908052214.44197.bradh@frogmouth.net> References: <200908052214.44197.bradh@frogmouth.net> Message-ID: <4A79D449.4070904@gnutls.org> Brad Hards wrote: > Hi, > > This patch (which I submit as a request for review / feedback) implements > support for getting issuer altname. It is based on the equivalent subject > altname code. No comments. Looks nice to me! regards, Nikos From joe at x2a.org Wed Aug 5 21:32:38 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Wed, 05 Aug 2009 15:32:38 -0400 Subject: [RFC] Suggestion for the improvement of the buffering layer In-Reply-To: <4A79D3EE.80106@gnutls.org> References: <4A78BEE4.3010802@x2a.org> <4A79D3EE.80106@gnutls.org> Message-ID: <4A79DE56.9030508@x2a.org> Nikos Mavrogiannopoulos wrote: > Jonathan Bastien-Filiatrault wrote: > >> Advantages: >> >> - The separation of "message framing" and message processing. Example: A >> buffer_process function would form as much records as it can from the >> available transport buffers then a record_read would simply dequeue the > > Hi, > If I understand well you propose using something similar to skb's in > linux? Can you give me an example of your proposal? Say in the TCP case > we received a handshake message in 3 different packets and one is not > yet received. How the processing will go before the 4th is received and > how after that? The handshake framing layer would determine how many more bytes it needs (header present in the first few packets) and compare that with the number of bytes available in the record FIFO. It would return a code such as EAGAIN until it has enough data available. When the last packet is received, it would dequeue the record packets (possibly splitting a partial record packet in two) and memcpy them into a handshake buffer and queue the handshake packet in the handshake FIFO. Just to be clear, there would be a record FIFO for each upper-layer protocol (demultiplex sub-layer). Skb's tend to reduce copying to a minimum. In the implementation I suggest I don't see how I can get away with less that one memcpy per layer transition (unless I implement some zero-copy record-slicing code-fu; something I want to avoid). > >> - Better separation of concerns, easier to understand code, better >> modularity. It can be argued that better understandability, readability >> and modularity lead to better security (from programming errors). >> Disadvantages: >> >> - Much previously tested/debugged code would be discarded. > > Replacing ugly code with simpler one (or more efficient one) does not > count as disadvantage to me. I was hoping someone would say that :P. > >> - Is it worth it ? Would it really be better ? > > I'm curious whether something like that would be more efficient. In > theory, if I get your idea correct, it would have less memcopy etc but > in practice we are spending more time in decrypting/encrypting and the > current code has quite reduced memcpy. However there is still space for > improvement. Right, encryption is a few orders of magnitude more costly than memcpy, in theory I could therefore get away with more memcpy without a significant performance degradation (I won't push this too far, hopefully). > > If you are asking a go or not go, I'd say that it's up to you. In any > case I am curious of any results and more design information. Well, I have basically brain-dumped the design I had in the email you replied to. I want to be sure I have the basics right before building a concrete implementation on top of that. PS: I have just received the FSF papers, I have signed them and I will return them soon. > regards, > Nikos Thanks, Jonathan From ueno at unixuser.org Thu Aug 6 09:12:49 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Thu, 06 Aug 2009 16:12:49 +0900 Subject: [PATCH] session ticket support In-Reply-To: <87prbahee5.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 05 Aug 2009 10:08:02 +0200") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <87ws5jkc62.fsf@mocca.josefsson.org> <87vdl2rfmt.fsf@broken.deisui.org> <87prbahee5.fsf@mocca.josefsson.org> Message-ID: <87k51hxvny.fsf@broken.deisui.org> >>>>> In <87prbahee5.fsf at mocca.josefsson.org> >>>>> Simon Josefsson wrote: > >> Also, what do you think about a 'gnutls_session_ticket_key_format_t' > >> parameter? I think some people may want to export the key in > >> text-format rather than raw binary. > > > > As another option, how about making gnutls_session_ticket_key_t a public > > struct so that people can write custom export function? > Thinking about that, doesn't a gnutls_datum_t suffice? Sorry, perhaps I misunderstood what you meant with "text-format". I had thought that the key is represented as a set of attributes such as cipher/mac keys and used algorithms in human readable form. It is simply an option to select output format in binary or base64, isn't it? Regards, -- Daiki Ueno From bradh at frogmouth.net Thu Aug 6 09:45:37 2009 From: bradh at frogmouth.net (Brad Hards) Date: Thu, 6 Aug 2009 17:45:37 +1000 Subject: [patch] Problems with "make check" Message-ID: <200908061745.38342.bradh@frogmouth.net> Hi, With an up-to-date git, I have problems with "make check" libtool: link: gcc -std=gnu99 -Wall -W -Wformat-security -Winit-self - Wmissing-include-dirs -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wfloat- equal -Wdeclaration-after-statement -Wpointer-arith -Wbad-function-cast - Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes - Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wpacked - Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wlong-long -Wvla - Wvolatile-register-var -Wdisabled-optimization -Wstack-protector -Woverlength- strings -Wbuiltin-macro-redefined -Wmudflap -Wpacked-bitfield-compat -Wsync-nand -Wattributes -Wcoverage-mismatch -Wmultichar -Wunused-macros -Wno-missing- field-initializers -Wno-sign-compare -Wno-pointer-sign -Wno-unused-parameter - Wno-unused-parameter -Wno-stack-protector -fdiagnostics-show-option -Werror -g -O2 -o nul-in-x509-names nul-in-x509-names.o ../lib/.libs/libgnutls.so - ltasn1 -lz ../gl/.libs/libgnu.a ./.libs/libutils.a -lgcrypt -Wl,-rpath - Wl,/home/bradh-dev/gnutls-buildfix/lib/.libs make[3]: *** No rule to make target `rfc2231-escape-test.o', needed by `rfc2231-escape-test'. Stop. I note that the shell script added in a532faf3bd6d95bf41ba75733a72b504090667af is rfc2253-escape-test rather than rfc2231-escape-test. See: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commit;h=a532faf3bd6d95bf41ba75733a72b504090667af I've attached a (trivial) patch to address it. Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-make-check-buildsystem-fix-2009-08-06.patch Type: text/x-patch Size: 974 bytes Desc: not available URL: From simon at josefsson.org Thu Aug 6 17:11:21 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 06 Aug 2009 17:11:21 +0200 Subject: [patch] Problems with "make check" In-Reply-To: <200908061745.38342.bradh@frogmouth.net> (Brad Hards's message of "Thu, 6 Aug 2009 17:45:37 +1000") References: <200908061745.38342.bradh@frogmouth.net> Message-ID: <87iqh1ugdi.fsf@mocca.josefsson.org> Brad Hards writes: > make[3]: *** No rule to make target `rfc2231-escape-test.o', needed by > `rfc2231-escape-test'. Stop. Thank you, should be fixed now. /Simon From simon at josefsson.org Thu Aug 6 17:14:46 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 06 Aug 2009 17:14:46 +0200 Subject: [patch] Request for review - X509 Issuer Altname handling In-Reply-To: <200908052214.44197.bradh@frogmouth.net> (Brad Hards's message of "Wed, 5 Aug 2009 22:14:43 +1000") References: <200908052214.44197.bradh@frogmouth.net> Message-ID: <87eirpug7t.fsf@mocca.josefsson.org> Brad Hards writes: > Hi, > > This patch (which I submit as a request for review / feedback) implements > support for getting issuer altname. It is based on the equivalent subject > altname code. It looks fine to me. I wonder why that have been missing... The self-test x509_altname was missing from your patch though? > [I'll submit it again for incorporation after my papers get worked through] Please do, otherwise I'm likely to forget about it. /Simon From simon at josefsson.org Fri Aug 7 00:22:10 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 07 Aug 2009 00:22:10 +0200 Subject: solutions In-Reply-To: <4A79CE90.8020706@gnutls.org> (Nikos Mavrogiannopoulos's message of "Wed, 05 Aug 2009 21:25:20 +0300") References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> <4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org> <87zlaefqvf.fsf@mocca.josefsson.org> <4A79CE90.8020706@gnutls.org> Message-ID: <87skg4twfh.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: >> Having had some time to read the code, here are some observations: >> >> * The old _gnutls_x509_oid_data2string in lib/x509/common.c is buggy >> since it truncates the string after a NUL (it copies the string using >> strcpy instead of memcpy). The RES_SIZE length output variable is >> correct though, but output data beyond the NUL will be garbage. >> >> * I can see a few ways to solve the problem: >> >> 1) Make _gnutls_x509_oid_data2string escape NULs as \00 following RFC >> 2253. >> >> 2) Use memcpy instead of strcpy and change the documentation of the >> function to say that the returned string may contain embedded NULs, >> and fix the callers of that function. >> >> 3) Return a RFC 2253 #-style string for these strings. >> >> 4) Return an error when a NUL is encountered. > > 4 is just ok. One could do 1 if he really bothers, but there is no > reason for that. Even though IA5 string allows for null character there > is no reason for us to allow it. It is the null terminator for C strings > thus allowing it can cause only problems and complicated code. I agree. I have applied the patch. It is not sufficient alone: NUL in SAN is not covered by that code path, but RedHat supplied a fix for the hostname comparison functions. What remains is to make sure printing a certificate with NUL in SAN comes out OK. /Simon From simon at josefsson.org Fri Aug 7 01:49:01 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 07 Aug 2009 01:49:01 +0200 Subject: please test imminent 2.8.x release In-Reply-To: <87skg4twfh.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 07 Aug 2009 00:22:10 +0200") References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> <4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org> <87zlaefqvf.fsf@mocca.josefsson.org> <4A79CE90.8020706@gnutls.org> <87skg4twfh.fsf@mocca.josefsson.org> Message-ID: <87hbwktseq.fsf_-_@mocca.josefsson.org> Because of the NUL in CN/SAN issue we need to release a stable 2.8.x update quickly. Please test the release candidate: http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20090806.tar.gz This will be identical with the release unless I hear anything negative. You can also help by reviewing the changes since 2.8.1: http://git.savannah.gnu.org/cgit/gnutls.git/log/?h=gnutls_2_8_x I don't have more spare time to produce releases of older versions with the patches (this problem came up at bad timing for me, plenty of paying assignments to work on), but if someone else wants to spend time on 2.6.x or any older release, that would be welcome. Note that in addition to the patches that went into 2.8.x you also need to patch the certificate printing output from gnutls-cli in src/common.c. GnuTLS 2.8.x and later uses libgnutls to print certificate details instead. You can use a self-tests from 2.9.x branch to check if your GnuTLS is vulnerable, see: http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/nul-in-x509-names.c Build and run it like this: wget http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/nul-in-x509-names.c gcc -o nul-in-x509-names nul-in-x509-names.c -lgnutls ./nul-in-x509-names On a broken gnutls it will output: gnutls_x509_crt_check_hostname BROKEN (NUL-IN-CN) gnutls_x509_crt_check_hostname BROKEN (NUL-IN-SAN) On a working gnutls it will output: gnutls_x509_crt_check_hostname OK (NUL-IN-CN) gnutls_x509_crt_check_hostname OK (NUL-IN-SAN) /Simon From simon at josefsson.org Fri Aug 7 01:59:26 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 07 Aug 2009 01:59:26 +0200 Subject: [PATCH] session ticket support In-Reply-To: <87k51hxvny.fsf@broken.deisui.org> (Daiki Ueno's message of "Thu, 06 Aug 2009 16:12:49 +0900") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <87ws5jkc62.fsf@mocca.josefsson.org> <87vdl2rfmt.fsf@broken.deisui.org> <87prbahee5.fsf@mocca.josefsson.org> <87k51hxvny.fsf@broken.deisui.org> Message-ID: <87d478trxd.fsf@mocca.josefsson.org> Daiki Ueno writes: >>>>>> In <87prbahee5.fsf at mocca.josefsson.org> >>>>>> Simon Josefsson wrote: >> >> Also, what do you think about a 'gnutls_session_ticket_key_format_t' >> >> parameter? I think some people may want to export the key in >> >> text-format rather than raw binary. >> > >> > As another option, how about making gnutls_session_ticket_key_t a public >> > struct so that people can write custom export function? > >> Thinking about that, doesn't a gnutls_datum_t suffice? > > Sorry, perhaps I misunderstood what you meant with "text-format". I had > thought that the key is represented as a set of attributes such as > cipher/mac keys and used algorithms in human readable form. > > It is simply an option to select output format in binary or base64, > isn't it? I changed my mind: rather than supporting different formats and crypto agility, the entire API would become: int gnutls_session_ticket_key_generate (gnutls_datum_t *key); The algorithm used are chosen by the library. The app has to write its own import/export stuff. What do you think? /Simon From joe at manyfish.co.uk Fri Aug 7 14:08:19 2009 From: joe at manyfish.co.uk (Joe Orton) Date: Fri, 7 Aug 2009 13:08:19 +0100 Subject: gnutls_certificate_verify_peers2 API Message-ID: <20090807120819.GA16131@manyfish.co.uk> This API is very awkward to use. 1) it is not clear from the API docs whether "failing to verify a cert" would be an error resulting in a non-zero return value, or success. 2) the use of the GNUTLS_CERT_INVALID status bit is unclear and inappropriate. The header file say it means: /* will be set if the certificate was not verified */ the HTML docs say it means: The certificate is not signed by one of the known authorities, or the signature is invalid. which are different things. If the latter is supposed to be true, it is unclear why GNUTLS_CERT_SIGNER_NOT_FOUND exists as well. In practice, all verification failures emitted seem to be ORed with CERT_INVALID, which implies it is redundant. I need to be able to safely map a given verification failure into a API/UI, which allows users to override specific errors. If I get the verification error bits: GNUTLS_CERT_INVALID | GNUTLS_CERT_SIGNER_NOT_FOUND does that mean simply a cert signed by a unknown CA? Or possibly, the cert is signed by an unknown CA *and* there is some other verification error? It's hard to tell. 3) for future-extensibility, it is necessary to be able to map a failure bit (or bitmask) into an error string, so I can present meaningful errors beyond "cert verification failed with GnuTLS failure bit 2^10". Regards, Joe From tim.kosse at filezilla-project.org Fri Aug 7 20:20:45 2009 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Fri, 07 Aug 2009 20:20:45 +0200 Subject: please test imminent 2.8.x release In-Reply-To: <87hbwktseq.fsf_-_@mocca.josefsson.org> References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> <4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org> <87zlaefqvf.fsf@mocca.josefsson.org> <4A79CE90.8020706@gnutls.org> <87skg4twfh.fsf@mocca.josefsson.org> <87hbwktseq.fsf_-_@mocca.josefsson.org> Message-ID: <4A7C707D.8020308@filezilla-project.org> Hi, > Please test the release candidate: > http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20090806.tar.gz works like a charm, I can no longer reproduce the issues I had with 2.8.1 Just one minor detail, the fixes to the EGAIN problems aren't mentioned in the NEWS file. Thanks, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Sat Aug 8 00:42:29 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 8 Aug 2009 01:42:29 +0300 Subject: [RFC] Suggestion for the improvement of the buffering layer In-Reply-To: <4A79DE56.9030508@x2a.org> References: <4A78BEE4.3010802@x2a.org> <4A79D3EE.80106@gnutls.org> <4A79DE56.9030508@x2a.org> Message-ID: On Wed, Aug 5, 2009 at 10:32 PM, Jonathan Bastien-Filiatrault wrote: >> ?If I understand well you propose using something similar to skb's in >> linux? ?Can you give me an example of your proposal? Say in the TCP case >> we received a handshake message in 3 different packets and one is not >> yet received. How the processing will go before the 4th is received and >> how after that? > > The handshake framing layer would determine how many more bytes it needs > (header present in the first few packets) and compare that with the > number of bytes available in the record FIFO. I should add the obvious here that it should check the number of bytes available in the packets of same type (handshake packets). > It would return a code > such as EAGAIN until it has enough data available. When the last packet > is received, it would dequeue the record packets (possibly splitting a > partial record packet in two) and memcpy them into a handshake buffer > and queue the handshake packet in the handshake FIFO. Just to be clear, > there would be a record FIFO for each upper-layer protocol (demultiplex > sub-layer). > Skb's tend to reduce copying to a minimum. In the implementation I > suggest I don't see how I can get away with less that one memcpy per > layer transition (unless I implement some zero-copy record-slicing > code-fu; something I want to avoid). > Right, encryption is a few orders of magnitude more costly than memcpy, > ?in theory I could therefore get away with more memcpy without a > significant performance degradation (I won't push this too far, hopefully). Indeed but don't underestimate memcpy. Both for low latency and high speed links (especially with crypto accelerators) that could be the bottleneck. Keep that in mind in your design. In any case it doesn't look easy task but that's always in the eye of the beholder. regards, Nikos From ametzler at downhill.at.eu.org Sat Aug 8 14:56:46 2009 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 8 Aug 2009 14:56:46 +0200 Subject: gnutls version checking too strict (was: Bug#540449: needs a versioned dependency on libtasn1-3) In-Reply-To: <20090808074058.GA3254@downhill.g.la> References: <20090808024733.GA31539@bongo.bofh.it> <20090808074058.GA3254@downhill.g.la> Message-ID: <20090808125646.GB3254@downhill.g.la> On 2009-08-08 Andreas Metzler wrote: [...] > Upstream seems to have changed the code to require installation of > both gcrypt and tasn versions that greater or equal version gnutls > was built against. > http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=ce23654ab3b8097241c1639ebe3e853c4f67b6d7 > http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=35bd51b3b42dd437a9914a908af45d78fec76856 [...] > (See http://bugs.debian.org/495473 for comparison.) Hello, The gnutls 2.8 series will absolutely fail to work if the currently installed version of libtasn1 or libgcrypt is not greater or equal than the version gnutls was built against. This is much too cautious since the libtasn1 ABI has not changed at all since 1.6. A gnutls binary built against libtasn1 2.3 will work perfectly fiine with e.g. libtasn1 2.0. It also makes our (Debian and probably other distributors) life unnecessary difficult, without any benefit for us, we already track ABI through dependencies. Please undo these changes, proposed patch against GIT HEAD attached. thanks, cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -------------- next part -------------- A non-text attachment was scrubbed... Name: proposed.patch Type: text/x-diff Size: 1816 bytes Desc: not available URL: From joe at x2a.org Sat Aug 8 19:39:29 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Sat, 08 Aug 2009 13:39:29 -0400 Subject: [RFC] Suggestion for the improvement of the buffering layer In-Reply-To: References: <4A78BEE4.3010802@x2a.org> <4A79D3EE.80106@gnutls.org> <4A79DE56.9030508@x2a.org> Message-ID: <4A7DB851.4020600@x2a.org> Nikos Mavrogiannopoulos wrote: > On Wed, Aug 5, 2009 at 10:32 PM, Jonathan > Bastien-Filiatrault wrote: [snip] >> Skb's tend to reduce copying to a minimum. In the implementation I >> suggest I don't see how I can get away with less that one memcpy per >> layer transition (unless I implement some zero-copy record-slicing >> code-fu; something I want to avoid). >> Right, encryption is a few orders of magnitude more costly than memcpy, >> in theory I could therefore get away with more memcpy without a >> significant performance degradation (I won't push this too far, hopefully). > > Indeed but don't underestimate memcpy. Both for low latency and high > speed links (especially with crypto accelerators) that could be the > bottleneck. Keep that in mind in your design. In any case it doesn't > look easy task but that's always in the eye of the beholder. Agreed. You can check http://x2a.org/git/gnutls/?h=buffers-redux for preliminary work. I have squashed _gnutls_io_write_buffered and down to less than a screenful each. The mbuffers code is now handling partial socket writes without problem (and regressions). The code is still missing some comments, but you should find it clear after a little while. The main benefit at this point is that the buffer logic is abstracted away in the mbuffers code and is kept out of the code that uses mbuffers. Your input is very important to me at this point. > > regards, > Nikos Cheers, Jonathan From ueno at unixuser.org Sun Aug 9 08:48:29 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Sun, 09 Aug 2009 15:48:29 +0900 Subject: [PATCH] session ticket support In-Reply-To: <87d478trxd.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 07 Aug 2009 01:59:26 +0200") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <87ws5jkc62.fsf@mocca.josefsson.org> <87vdl2rfmt.fsf@broken.deisui.org> <87prbahee5.fsf@mocca.josefsson.org> <87k51hxvny.fsf@broken.deisui.org> <87d478trxd.fsf@mocca.josefsson.org> Message-ID: <363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org> >>>>> In <87d478trxd.fsf at mocca.josefsson.org> >>>>> Simon Josefsson wrote: > I changed my mind: rather than supporting different formats and crypto > agility, the entire API would become: OK, I see. > int gnutls_session_ticket_key_generate (gnutls_datum_t *key); > The algorithm used are chosen by the library. The app has to write its > own import/export stuff. What do you think? Sounds nice to me. Here is the new patch, with changes from the previous version: * Internal session state format is used instead of the RFC recommendation. * Fallback to full handshake if the decryption of tickets is failed. * The key management interfaces are drawn togeter into a single function `gnutls_session_ticket_key_generate' * tests/session_ticket.c is merged into tests/resume.c. * The doc-comments for the new interface functions are added. -------------- next part -------------- A non-text attachment was scrubbed... Name: session-ticket-2009-08-09.diff.gz Type: application/octet-stream Size: 9907 bytes Desc: not available URL: -------------- next part -------------- Regards, -- Daiki Ueno From nmav at gnutls.org Sun Aug 9 18:21:22 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 09 Aug 2009 19:21:22 +0300 Subject: [RFC] Suggestion for the improvement of the buffering layer In-Reply-To: <4A7DB851.4020600@x2a.org> References: <4A78BEE4.3010802@x2a.org> <4A79D3EE.80106@gnutls.org> <4A79DE56.9030508@x2a.org> <4A7DB851.4020600@x2a.org> Message-ID: <4A7EF782.7070806@gnutls.org> Jonathan Bastien-Filiatrault wrote: >> Indeed but don't underestimate memcpy. Both for low latency and high >> speed links (especially with crypto accelerators) that could be the >> bottleneck. Keep that in mind in your design. In any case it doesn't >> look easy task but that's always in the eye of the beholder. > > Agreed. You can check http://x2a.org/git/gnutls/?h=buffers-redux for > preliminary work. I have squashed _gnutls_io_write_buffered and down to > less than a screenful each. The mbuffers code is now handling partial > socket writes without problem (and regressions). The code is still > missing some comments, but you should find it clear after a little > while. The main benefit at this point is that the buffer logic is > abstracted away in the mbuffers code and is kept out of the code that > uses mbuffers. > > Your input is very important to me at this point. Hello Jonathan, I like the overall change due to simplicity it introduces. Some comments: - You could use const gnutls_datum* to pass datums that will not be changed, just to save few bytes from stack. - I don't like the malloc for each mbuffer_st being added. I'd suggest to be avoided even if it results to some fixed number of mbuffers per session (which seems quite realistic requirement). Further I'd suggest to avoid the _gnutls_mbuffer_enqueue_copy() in io_write_buffered() by passing a datum to the latter as well as flag on whether this datum can be assigned without copy to an mbuffer. Thus in gnutls_record.c you could convert ret = _gnutls_io_write_buffered (session, cipher, cipher_size); gnutls_free (cipher); to something like: gnutls_datum tmp = {cipher, cipher_size}; ret = _gnutls_io_write_buffered (session, &tmp, 1); if (ret < 0) { gnutls_free(cipher); } and will allow the reuse of the already allocated data. regards, Nikos From joe at x2a.org Sun Aug 9 20:23:32 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Sun, 09 Aug 2009 14:23:32 -0400 Subject: [RFC] Suggestion for the improvement of the buffering layer In-Reply-To: <4A7EF782.7070806@gnutls.org> References: <4A78BEE4.3010802@x2a.org> <4A79D3EE.80106@gnutls.org> <4A79DE56.9030508@x2a.org> <4A7DB851.4020600@x2a.org> <4A7EF782.7070806@gnutls.org> Message-ID: <4A7F1424.4090901@x2a.org> Nikos Mavrogiannopoulos wrote: > Jonathan Bastien-Filiatrault wrote: > >>> Indeed but don't underestimate memcpy. Both for low latency and high >>> speed links (especially with crypto accelerators) that could be the >>> bottleneck. Keep that in mind in your design. In any case it doesn't >>> look easy task but that's always in the eye of the beholder. >> Agreed. You can check http://x2a.org/git/gnutls/?h=buffers-redux for >> preliminary work. I have squashed _gnutls_io_write_buffered and down to >> less than a screenful each. The mbuffers code is now handling partial >> socket writes without problem (and regressions). The code is still >> missing some comments, but you should find it clear after a little >> while. The main benefit at this point is that the buffer logic is >> abstracted away in the mbuffers code and is kept out of the code that >> uses mbuffers. >> >> Your input is very important to me at this point. > > Hello Jonathan, > I like the overall change due to simplicity it introduces. Some comments: Thanks ! > > - You could use const gnutls_datum* to pass datums that will not be > changed, just to save few bytes from stack. No problem, I will do this. > > - I don't like the malloc for each mbuffer_st being added. I'd suggest > to be avoided even if it results to some fixed number of mbuffers per > session (which seems quite realistic requirement). So do we just allocate a series of maximum-sized buffers (2^14+2048 for regular TLS and ~2^16 for DTLS) and keep a free list ? Do we keep a free list and realloc if we need more memory ? I do not want to reimplement malloc... Is the added complexity worth it ? In the general case, mbuffer chains should not be very long... > > Further I'd suggest to avoid the _gnutls_mbuffer_enqueue_copy() in > io_write_buffered() by passing a datum to the latter as well as flag on > whether this datum can be assigned without copy to an mbuffer. Thus in > gnutls_record.c you could convert > ret = _gnutls_io_write_buffered (session, cipher, cipher_size); > gnutls_free (cipher); > to something like: > gnutls_datum tmp = {cipher, cipher_size}; > ret = _gnutls_io_write_buffered (session, &tmp, 1); > if (ret < 0) { > gnutls_free(cipher); > } Yes, I agree. I avoided this modification in order to keep the internal API constant for now. I will apply this modification. > > and will allow the reuse of the already allocated data. > > regards, > Nikos Thanks for your input, Jonathan From nmav at gnutls.org Sun Aug 9 21:49:07 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 09 Aug 2009 22:49:07 +0300 Subject: [RFC] Suggestion for the improvement of the buffering layer In-Reply-To: <4A7F1424.4090901@x2a.org> References: <4A78BEE4.3010802@x2a.org> <4A79D3EE.80106@gnutls.org> <4A79DE56.9030508@x2a.org> <4A7DB851.4020600@x2a.org> <4A7EF782.7070806@gnutls.org> <4A7F1424.4090901@x2a.org> Message-ID: <4A7F2833.9050002@gnutls.org> Jonathan Bastien-Filiatrault wrote: >> - I don't like the malloc for each mbuffer_st being added. I'd suggest >> to be avoided even if it results to some fixed number of mbuffers per >> session (which seems quite realistic requirement). > So do we just allocate a series of maximum-sized buffers (2^14+2048 for > regular TLS and ~2^16 for DTLS) and keep a free list ? Do we keep a free > list and realloc if we need more memory ? I do not want to reimplement > malloc... Is the added complexity worth it ? In the general case, > mbuffer chains should not be very long... No actually I was referring to the mbuffer_st structure. As far as I understand this small structure is getting allocated once we are sending a message (at least when io_write_buffered() is called). What I suggest here is that we could avoid that allocation by having some constant number of them for sending data. If you want to keep the allocation for the mbuffer_t which will keep the code simple maybe you can make the callers (now _gnutls_send_int) queue an mbuffer_t directly. Thus the send_int() will allocate data for mbuffer_t and the payload using a function such as(example): mbuffer_st * allocate_with_payload(size_t payload_size) { mbuffer_st * st; st = gnutls_malloc(payload_size+sizeof(mbuffer_st)); //payload points after the mbuffer_st structure st->msg.data = st+sizeof(mbuffer_st); st->msg.size = payload_size; } and will fill in the payload and queue it directly down. Once the node is freed the payload will be freed as well. Maybe I'm insisting too much here, but I think that your current design need not to be worse-performance wise from the current one. Anyway consider my suggestions merely as suggestions. The design looks good already. I'll be unavailable for the next few weeks so all best! Nikos From joe at x2a.org Sun Aug 9 22:30:12 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Sun, 09 Aug 2009 16:30:12 -0400 Subject: [RFC] Suggestion for the improvement of the buffering layer In-Reply-To: <4A7F2833.9050002@gnutls.org> References: <4A78BEE4.3010802@x2a.org> <4A79D3EE.80106@gnutls.org> <4A79DE56.9030508@x2a.org> <4A7DB851.4020600@x2a.org> <4A7EF782.7070806@gnutls.org> <4A7F1424.4090901@x2a.org> <4A7F2833.9050002@gnutls.org> Message-ID: <4A7F31D4.3040309@x2a.org> Nikos Mavrogiannopoulos wrote: > Jonathan Bastien-Filiatrault wrote: > >>> - I don't like the malloc for each mbuffer_st being added. I'd suggest >>> to be avoided even if it results to some fixed number of mbuffers per >>> session (which seems quite realistic requirement). >> So do we just allocate a series of maximum-sized buffers (2^14+2048 for >> regular TLS and ~2^16 for DTLS) and keep a free list ? Do we keep a free >> list and realloc if we need more memory ? I do not want to reimplement >> malloc... Is the added complexity worth it ? In the general case, >> mbuffer chains should not be very long... > > No actually I was referring to the mbuffer_st structure. As far as I > understand this small structure is getting allocated once we are sending > a message (at least when io_write_buffered() is called). What I suggest > here is that we could avoid that allocation by having some constant > number of them for sending data. Oh, right. The chain nodes are a small and constant size and as you say, that overhead could be reduced. > > If you want to keep the allocation for the mbuffer_t which will keep the > code simple maybe you can make the callers (now _gnutls_send_int) queue > an mbuffer_t directly. Thus the send_int() will allocate data for > mbuffer_t and the payload using a function such as(example): > > mbuffer_st * allocate_with_payload(size_t payload_size) > { > mbuffer_st * st; > > st = gnutls_malloc(payload_size+sizeof(mbuffer_st)); > > //payload points after the mbuffer_st structure > st->msg.data = st+sizeof(mbuffer_st); > st->msg.size = payload_size; > } > > and will fill in the payload and queue it directly down. Once the node > is freed the payload will be freed as well. I like this, I will see what I can do... > Maybe I'm insisting too much here, but I think that your current design > need not to be worse-performance wise from the current one. Not problem at all. My current objective is more code simplicity than performance at the moment, but I am doing my best to think about performance at the same time. Hopefully simpler and smaller code will result in less instruction cache misses in the buffer code ;P. > Anyway consider my suggestions merely as suggestions. The design looks > good already. > > I'll be unavailable for the next few weeks so all best! My vacation is ending today... sigh > Nikos Take care, Jonathan From simon at josefsson.org Mon Aug 10 13:30:05 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 10 Aug 2009 13:30:05 +0200 Subject: please test imminent 2.8.x release In-Reply-To: <4A7C707D.8020308@filezilla-project.org> (Tim Kosse's message of "Fri, 07 Aug 2009 20:20:45 +0200") References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> <4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org> <87zlaefqvf.fsf@mocca.josefsson.org> <4A79CE90.8020706@gnutls.org> <87skg4twfh.fsf@mocca.josefsson.org> <87hbwktseq.fsf_-_@mocca.josefsson.org> <4A7C707D.8020308@filezilla-project.org> Message-ID: <874osfhpoi.fsf@mocca.josefsson.org> Tim Kosse writes: > Hi, > >> Please test the release candidate: >> http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20090806.tar.gz > > works like a charm, I can no longer reproduce the issues I had with 2.8.1 Great. > Just one minor detail, the fixes to the EGAIN problems aren't mentioned > in the NEWS file. Oops. I think I made a proposal on what it should say, I'll try to find in some e-mail.. I'll do the release shortly. /Simon From simon at josefsson.org Mon Aug 10 14:33:00 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 10 Aug 2009 14:33:00 +0200 Subject: gnutls version checking too strict In-Reply-To: <20090808125646.GB3254@downhill.g.la> (Andreas Metzler's message of "Sat, 8 Aug 2009 14:56:46 +0200") References: <20090808024733.GA31539@bongo.bofh.it> <20090808074058.GA3254@downhill.g.la> <20090808125646.GB3254@downhill.g.la> Message-ID: <87tz0fg877.fsf@mocca.josefsson.org> Andreas Metzler writes: > On 2009-08-08 Andreas Metzler wrote: > [...] >> Upstream seems to have changed the code to require installation of >> both gcrypt and tasn versions that greater or equal version gnutls >> was built against. > >> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=ce23654ab3b8097241c1639ebe3e853c4f67b6d7 >> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=35bd51b3b42dd437a9914a908af45d78fec76856 > [...] >> (See http://bugs.debian.org/495473 for comparison.) > > Hello, > The gnutls 2.8 series will absolutely fail to work if the currently > installed version of libtasn1 or libgcrypt is not greater or equal > than the version gnutls was built against. This is much too cautious > since the libtasn1 ABI has not changed at all since 1.6. A gnutls > binary built against libtasn1 2.3 will work perfectly fiine with e.g. > libtasn1 2.0. > > It also makes our (Debian and probably other distributors) life > unnecessary difficult, without any benefit for us, we already track > ABI through dependencies. > > Please undo these changes, proposed patch against GIT HEAD attached. > thanks, cu andreas Hi. Just in time for the 2.8.2 release. :-) I applied it somewhat differently, see: http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=860605be8f3b344738548ecfe0f1a6e6cb357c0b Thanks, /Simon From thoger at redhat.com Mon Aug 10 15:02:32 2009 From: thoger at redhat.com (Tomas Hoger) Date: Mon, 10 Aug 2009 13:02:32 +0000 (UTC) Subject: please test imminent 2.8.x release References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> <4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org> <87zlaefqvf.fsf@mocca.josefsson.org> <4A79CE90.8020706@gnutls.org> <87skg4twfh.fsf@mocca.josefsson.org> <87hbwktseq.fsf_-_@mocca.josefsson.org> Message-ID: Hi Simon! Simon Josefsson josefsson.org> writes: > Because of the NUL in CN/SAN issue we need to release a stable 2.8.x > update quickly. > > Please test the release candidate: > > http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20090806.tar.gz > > This will be identical with the release unless I hear anything negative. > > You can also help by reviewing the changes since 2.8.1: > > http://git.savannah.gnu.org/cgit/gnutls.git/log/?h=gnutls_2_8_x Is it intentional that 2.8.2 does contain 21bc1439e5, but does not contain 9b0dc81885 and c9dba57f8d? Moreover, is 21bc1439e5 still needed with 74b6d92f96 applied? It seems that if there is NUL, GNUTLS_E_ASN1_DER_ERROR is returned earlier or res is passed through _gnutls_x509_data2hex() and hence should not contain NULs any more. th. From simon at josefsson.org Mon Aug 10 15:43:44 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 10 Aug 2009 15:43:44 +0200 Subject: GnuTLS 2.8.2 Message-ID: <87k51bg4xb.fsf@mocca.josefsson.org> We are proud to announce a new stable GnuTLS release: Version 2.8.2. GnuTLS is a modern C library that implements the standard network security protocol Transport Layer Security (TLS), for use by network applications. GnuTLS is developed for GNU/Linux, but works on many Unix-like systems and comes with a binary installer for Windows. The GnuTLS library is distributed under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS library (which contains TLS/IA support, LZO compression and Libgcrypt FIPS-mode handler), the OpenSSL compatibility library, the self tests and the command line tools are all distributed under the GNU General Public License version 3.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.3 (or later). The project page of the library is available at: http://www.gnu.org/software/gnutls/ What's New ========== ** libgnutls: Fix problem with NUL bytes in X.509 CN and SAN fields. By using a NUL byte in CN/SAN fields, it was possible to fool GnuTLS into 1) not printing the entire CN/SAN field value when printing a certificate and 2) cause incorrect positive matches when matching a hostname against a certificate. Some CAs apparently have poor checking of CN/SAN values and issue these (arguable invalid) certificates. Combined, this can be used by attackers to become a MITM on server-authenticated TLS sessions. The problem is mitigated since attackers needs to get one certificate per site they want to attack, and the attacker reveals his tracks by applying for a certificate at the CA. It does not apply to client authenticated TLS sessions. Research presented independently by Dan Kaminsky and Moxie Marlinspike at BlackHat09. Thanks to Tomas Hoger for providing one part of the patch. [GNUTLS-SA-2009-4]. ** libgnutls: Fix return value of gnutls_certificate_client_get_request_status. Before it always returned false. Reported by Peter Hendrickson in . ** libgnutls: Fix off-by-one size computation error in unknown DN printing. The error resulted in truncated strings when printing unknown OIDs in X.509 certificate DNs. Reported by Tim Kosse in . ** libgnutls: Return correct bit lengths of some MPIs. gnutls_dh_get_prime_bits, gnutls_rsa_export_get_modulus_bits, and gnutls_dh_get_peers_public_bits. Before the reported value was overestimated. Reported by Peter Hendrickson in . ** libgnutls: Avoid internal error when invoked after GNUTLS_E_AGAIN. Report and patch by Tim Kosse in and . ** libgnutls: Relax checking of required libtasn1/libgcrypt versions. Before we required that the runtime library used the same (or more recent) libgcrypt/libtasn1 as it was compiled with. Now we just check that the runtime usage is above the minimum required. Reported by Marco d'Itri via Andreas Metzler in . ** minitasn1: Internal copy updated to libtasn1 v2.3. ** tests: Fix failure in "chainverify" because a certificate have expired. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the mirror sites or direct from . The list of mirrors can be found at . Here are the BZIP2 compressed sources (6.0MB): ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs. In order to check that the version of GnuTLS which you are going to install is an original and unmodified one, you should verify the OpenPGP signature. You can use the command gpg --verify gnutls-2.8.2.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. The signing key can be identified with the following information: pub 1280R/B565716F 2002-05-05 [expires: 2010-04-21] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2010-04-21] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Alternatively, after successfully verifying the OpenPGP signature of this announcement, you could verify that the files match the following checksum values. The values are for SHA-1 and SHA-224 respectively: eea59fb972e7d566679645a564a56b58aeffe10b gnutls-2.8.2.tar.bz2 048bfb981a4a88d7040c1951614bd9d06cdd787e2242d6243391775a gnutls-2.8.2.tar.bz2 Documentation ============= The manual is available online at: http://www.gnu.org/software/gnutls/documentation.html In particular the following formats are available: HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf For developers there is a GnuTLS API reference manual formatted using the GTK-DOC tools: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html Community ========= If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: http://lists.gnu.org/mailman/listinfo/help-gnutls If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-dev mailing list, see: http://lists.gnu.org/mailman/listinfo/gnutls-devel Windows installer ================= GnuTLS has been ported to the Windows operating system, and a binary installer is available. The installer contains DLLs for application development, manuals, examples, and source code. The installer includes libgpg-error v1.7, libgcrypt v1.4.4, libtasn1 v2.3, and GnuTLS v2.8.2. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ The Windows binary installer and PGP signature: http://josefsson.org/gnutls4win/gnutls-2.8.2.exe (15MB) http://josefsson.org/gnutls4win/gnutls-2.8.2.exe.sig The checksum values for SHA-1 and SHA-224 are: 18fc15825832606123284dd5d7a77d402bf14101 gnutls-2.8.2.exe 9e9b9e5c9c213743fcb070af5c0b9a552ddd3fb3a241f2e0dbb89fa3 gnutls-2.8.2.exe A ZIP archive containing the Windows binaries: http://josefsson.org/gnutls4win/gnutls-2.8.2.zip (5.3MB) http://josefsson.org/gnutls4win/gnutls-2.8.2.zip.sig The checksum values for SHA-1 and SHA-224 are: af492d1c31ef4ecc27724839ce62f5a334731b26 gnutls-2.8.2.zip ca3306416ad63c22b281c30165c83d94d97b0e7a817303f2ca61d00c gnutls-2.8.2.zip A Debian mingw32 package is also available: http://josefsson.org/gnutls4win/mingw32-gnutls_2.8.2-1_all.deb (4.8MB) The checksum values for SHA-1 and SHA-224 are: 4d591773c387be1409fb000ff1a9eae3c3c19756 mingw32-gnutls_2.8.2-1_all.deb fb742033dca3ccca3757d798dfa37fb718c2bac082e557bb7dfbfe57 mingw32-gnutls_2.8.2-1_all.deb Internationalization ==================== The GnuTLS library messages have been translated into Czech, Dutch, French, German, Malay, Polish, Swedish, and Vietnamese. We welcome the addition of more translations. Support ======= Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. The GnuTLS service directory is available at: http://www.gnu.org/software/gnutls/commercial.html Happy Hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Mon Aug 10 15:55:47 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 10 Aug 2009 15:55:47 +0200 Subject: please test imminent 2.8.x release In-Reply-To: (Tomas Hoger's message of "Mon, 10 Aug 2009 13:02:32 +0000 (UTC)") References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> <4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org> <87zlaefqvf.fsf@mocca.josefsson.org> <4A79CE90.8020706@gnutls.org> <87skg4twfh.fsf@mocca.josefsson.org> <87hbwktseq.fsf_-_@mocca.josefsson.org> Message-ID: <87fxbzg4d8.fsf@mocca.josefsson.org> Tomas Hoger writes: > Hi Simon! > > Simon Josefsson josefsson.org> writes: > >> Because of the NUL in CN/SAN issue we need to release a stable 2.8.x >> update quickly. >> >> Please test the release candidate: >> >> http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20090806.tar.gz >> >> This will be identical with the release unless I hear anything negative. >> >> You can also help by reviewing the changes since 2.8.1: >> >> http://git.savannah.gnu.org/cgit/gnutls.git/log/?h=gnutls_2_8_x > > Is it intentional that 2.8.2 does contain 21bc1439e5, but does not > contain 9b0dc81885 and c9dba57f8d? Moreover, is 21bc1439e5 still > needed with 74b6d92f96 applied? It seems that if there is NUL, > GNUTLS_E_ASN1_DER_ERROR is returned earlier or res is passed through > _gnutls_x509_data2hex() and hence should not contain NULs any more. You are right. 21bc1439e5 is no longer needed and should not have been in 2.8.x. I wonder why the self-tests didn't catch that, by reading the code it would seem to trigger an out-of-bounds read in some situations. I'm wondering whether I need to release a 2.8.3 now... or whether the out-of-bounds read never happens in the 2.8.x branch for some other reason. See fixes at: http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=c12e7507562d5f168330acf1dd7db7cc2079cdf0 http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=e52cbea94e67334c2c8e64c4bbb13d84c9d4433a Thanks, /Simon From tmraz at redhat.com Mon Aug 10 16:16:59 2009 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 10 Aug 2009 16:16:59 +0200 Subject: please test imminent 2.8.x release In-Reply-To: <87fxbzg4d8.fsf@mocca.josefsson.org> References: <4A43C7FE.9090108@gnutls.org> <87bpmwpohh.fsf@mocca.josefsson.org> <4A77C5D0.9060901@gnutls.org> <87ab2flrrj.fsf@mocca.josefsson.org> <87zlaefqvf.fsf@mocca.josefsson.org> <4A79CE90.8020706@gnutls.org> <87skg4twfh.fsf@mocca.josefsson.org> <87hbwktseq.fsf_-_@mocca.josefsson.org> <87fxbzg4d8.fsf@mocca.josefsson.org> Message-ID: <1249913819.14237.21.camel@vespa.frost.loc> On Mon, 2009-08-10 at 15:55 +0200, Simon Josefsson wrote: > Tomas Hoger writes: > > > Hi Simon! > > > > Simon Josefsson josefsson.org> writes: > > > >> Because of the NUL in CN/SAN issue we need to release a stable 2.8.x > >> update quickly. > >> > >> Please test the release candidate: > >> > >> http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20090806.tar.gz > >> > >> This will be identical with the release unless I hear anything negative. > >> > >> You can also help by reviewing the changes since 2.8.1: > >> > >> http://git.savannah.gnu.org/cgit/gnutls.git/log/?h=gnutls_2_8_x > > > > Is it intentional that 2.8.2 does contain 21bc1439e5, but does not > > contain 9b0dc81885 and c9dba57f8d? Moreover, is 21bc1439e5 still > > needed with 74b6d92f96 applied? It seems that if there is NUL, > > GNUTLS_E_ASN1_DER_ERROR is returned earlier or res is passed through > > _gnutls_x509_data2hex() and hence should not contain NULs any more. > > You are right. 21bc1439e5 is no longer needed and should not have been > in 2.8.x. I wonder why the self-tests didn't catch that, by reading the > code it would seem to trigger an out-of-bounds read in some situations. > > I'm wondering whether I need to release a 2.8.3 now... or whether the > out-of-bounds read never happens in the 2.8.x branch for some other > reason. > > See fixes at: > http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=c12e7507562d5f168330acf1dd7db7cc2079cdf0 > http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=e52cbea94e67334c2c8e64c4bbb13d84c9d4433a Unfortunately this seems to be exposed through public API so 2.8.3 seems to be necessary. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From ametzler at downhill.at.eu.org Mon Aug 10 19:03:48 2009 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon, 10 Aug 2009 19:03:48 +0200 Subject: gnutls version checking too strict In-Reply-To: <87tz0fg877.fsf@mocca.josefsson.org> References: <20090808024733.GA31539@bongo.bofh.it> <20090808074058.GA3254@downhill.g.la> <20090808125646.GB3254@downhill.g.la> <87tz0fg877.fsf@mocca.josefsson.org> Message-ID: <20090810170348.GA3282@downhill.g.la> On 2009-08-10 Simon Josefsson wrote: > Andreas Metzler writes: [...] > > The gnutls 2.8 series will absolutely fail to work if the currently > > installed version of libtasn1 or libgcrypt is not greater or equal > > than the version gnutls was built against. This is much too cautious [...] > Hi. Just in time for the 2.8.2 release. :-) > I applied it somewhat differently, see: > http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=860605be8f3b344738548ecfe0f1a6e6cb357c0b Thanks for fixing this very quickly. I will try to find time for a (2.8.3, probably ;-) upload tomorrow. 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 simon at josefsson.org Mon Aug 10 21:47:43 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 10 Aug 2009 21:47:43 +0200 Subject: Bug#540449: gnutls version checking too strict In-Reply-To: <20090810170348.GA3282@downhill.g.la> (Andreas Metzler's message of "Mon, 10 Aug 2009 19:03:48 +0200") References: <20090808024733.GA31539@bongo.bofh.it> <20090808074058.GA3254@downhill.g.la> <20090808125646.GB3254@downhill.g.la> <87tz0fg877.fsf@mocca.josefsson.org> <20090810170348.GA3282@downhill.g.la> Message-ID: <87fxbzjvs0.fsf@mocca.josefsson.org> Andreas Metzler writes: > On 2009-08-10 Simon Josefsson wrote: >> Andreas Metzler writes: > [...] >> > The gnutls 2.8 series will absolutely fail to work if the currently >> > installed version of libtasn1 or libgcrypt is not greater or equal >> > than the version gnutls was built against. This is much too cautious > [...] >> Hi. Just in time for the 2.8.2 release. :-) > >> I applied it somewhat differently, see: >> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=860605be8f3b344738548ecfe0f1a6e6cb357c0b > > Thanks for fixing this very quickly. > > I will try to find time for a (2.8.3, probably ;-) upload tomorrow. Right, please wait a day or two for 2.8.3 to avoid the double work. I think lenny (and etch?) needs upgraded packages, though, for the security problem. /Simon From simon at josefsson.org Tue Aug 11 03:14:33 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 11 Aug 2009 03:14:33 +0200 Subject: [PATCH] session ticket support In-Reply-To: <363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org> (Daiki Ueno's message of "Sun, 09 Aug 2009 15:48:29 +0900") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <87ws5jkc62.fsf@mocca.josefsson.org> <87vdl2rfmt.fsf@broken.deisui.org> <87prbahee5.fsf@mocca.josefsson.org> <87k51hxvny.fsf@broken.deisui.org> <87d478trxd.fsf@mocca.josefsson.org> <363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org> Message-ID: <87prb3i22u.fsf@mocca.josefsson.org> Daiki Ueno writes: > Sounds nice to me. Here is the new patch, with changes from the > previous version: Thank you. Once the papers have arrived, I think it is good enough to go in. I'll do a more careful review when I'm pushing it. Meanwhile, it would be nice with some more self-tests. How about also testing: * What happens if the client provides a garbage session ticket? - Does the RFC specify what should happen? I'd assume that the handshake continues as normal, but I'm not sure. * What happens if the client has a session ticket but the server has disabled session ticket support? /Simon From Jeff.Cai at Sun.COM Wed Aug 12 10:43:51 2009 From: Jeff.Cai at Sun.COM (Jeff Cai) Date: Wed, 12 Aug 2009 16:43:51 +0800 Subject: GnuTLS 2.8.2 In-Reply-To: <87k51bg4xb.fsf@mocca.josefsson.org> References: <87k51bg4xb.fsf@mocca.josefsson.org> Message-ID: <1250066631.3868.8.camel@marathon> > What's New > ========== > > ** libgnutls: Fix problem with NUL bytes in X.509 CN and SAN fields. > By using a NUL byte in CN/SAN fields, it was possible to fool GnuTLS > into 1) not printing the entire CN/SAN field value when printing a > certificate and 2) cause incorrect positive matches when matching a > hostname against a certificate. Some CAs apparently have poor > checking of CN/SAN values and issue these (arguable invalid) > certificates. Combined, this can be used by attackers to become a > MITM on server-authenticated TLS sessions. The problem is mitigated > since attackers needs to get one certificate per site they want to > attack, and the attacker reveals his tracks by applying for a > certificate at the CA. It does not apply to client authenticated TLS > sessions. Research presented independently by Dan Kaminsky and Moxie > Marlinspike at BlackHat09. Thanks to Tomas Hoger > for providing one part of the patch. [GNUTLS-SA-2009-4]. How is it affecting old versions of gnutls like 2.6 and 2.4? Do they also need a patch applied if not upgrading them? Jeff > > ** libgnutls: Fix return value of gnutls_certificate_client_get_request_status. > Before it always returned false. Reported by Peter Hendrickson > in > . > > ** libgnutls: Fix off-by-one size computation error in unknown DN printing. > The error resulted in truncated strings when printing unknown OIDs in > X.509 certificate DNs. Reported by Tim Kosse > in > . > > ** libgnutls: Return correct bit lengths of some MPIs. > gnutls_dh_get_prime_bits, gnutls_rsa_export_get_modulus_bits, and > gnutls_dh_get_peers_public_bits. Before the reported value was > overestimated. Reported by Peter Hendrickson in > . > > ** libgnutls: Avoid internal error when invoked after GNUTLS_E_AGAIN. > Report and patch by Tim Kosse in > > and > . > > ** libgnutls: Relax checking of required libtasn1/libgcrypt versions. > Before we required that the runtime library used the same (or more > recent) libgcrypt/libtasn1 as it was compiled with. Now we just check > that the runtime usage is above the minimum required. Reported by > Marco d'Itri via Andreas Metzler > in . > > ** minitasn1: Internal copy updated to libtasn1 v2.3. > > ** tests: Fix failure in "chainverify" because a certificate have expired. > > ** API and ABI modifications: > No changes since last version. > > Getting the Software > ==================== > > GnuTLS may be downloaded from one of the mirror sites or direct from > . The list of mirrors can be found at > . > > Here are the BZIP2 compressed sources (6.0MB): > > ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2 > http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2 > > Here are OpenPGP detached signatures signed using key 0xB565716F: > > ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2.sig > http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2.sig > > Note, that we don't distribute gzip compressed tarballs. > > In order to check that the version of GnuTLS which you are going to > install is an original and unmodified one, you should verify the OpenPGP > signature. You can use the command > > gpg --verify gnutls-2.8.2.tar.bz2.sig > > This checks whether the signature file matches the source file. You > should see a message indicating that the signature is good and made by > that signing key. Make sure that you have the right key, either by > checking the fingerprint of that key with other sources or by checking > that the key has been signed by a trustworthy other key. The signing > key can be identified with the following information: > > pub 1280R/B565716F 2002-05-05 [expires: 2010-04-21] > Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F > uid Simon Josefsson > uid Simon Josefsson > sub 1280R/4D5D40AE 2002-05-05 [expires: 2010-04-21] > > The key is available from: > http://josefsson.org/key.txt > dns:b565716f.josefsson.org?TYPE=CERT > > Alternatively, after successfully verifying the OpenPGP signature of > this announcement, you could verify that the files match the following > checksum values. The values are for SHA-1 and SHA-224 respectively: > > eea59fb972e7d566679645a564a56b58aeffe10b gnutls-2.8.2.tar.bz2 > > 048bfb981a4a88d7040c1951614bd9d06cdd787e2242d6243391775a gnutls-2.8.2.tar.bz2 > > Documentation > ============= > > The manual is available online at: > > http://www.gnu.org/software/gnutls/documentation.html > > In particular the following formats are available: > > HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html > PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf > > For developers there is a GnuTLS API reference manual formatted using > the GTK-DOC tools: > > http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html > > Community > ========= > > If you need help to use GnuTLS, or want to help others, you are invited > to join our help-gnutls mailing list, see: > > http://lists.gnu.org/mailman/listinfo/help-gnutls > > If you wish to participate in the development of GnuTLS, you are invited > to join our gnutls-dev mailing list, see: > > http://lists.gnu.org/mailman/listinfo/gnutls-devel > > Windows installer > ================= > > GnuTLS has been ported to the Windows operating system, and a binary > installer is available. The installer contains DLLs for application > development, manuals, examples, and source code. The installer includes > libgpg-error v1.7, libgcrypt v1.4.4, libtasn1 v2.3, and GnuTLS v2.8.2. > > For more information about GnuTLS for Windows: > http://josefsson.org/gnutls4win/ > > The Windows binary installer and PGP signature: > http://josefsson.org/gnutls4win/gnutls-2.8.2.exe (15MB) > http://josefsson.org/gnutls4win/gnutls-2.8.2.exe.sig > > The checksum values for SHA-1 and SHA-224 are: > > 18fc15825832606123284dd5d7a77d402bf14101 gnutls-2.8.2.exe > 9e9b9e5c9c213743fcb070af5c0b9a552ddd3fb3a241f2e0dbb89fa3 gnutls-2.8.2.exe > > A ZIP archive containing the Windows binaries: > http://josefsson.org/gnutls4win/gnutls-2.8.2.zip (5.3MB) > http://josefsson.org/gnutls4win/gnutls-2.8.2.zip.sig > > The checksum values for SHA-1 and SHA-224 are: > > af492d1c31ef4ecc27724839ce62f5a334731b26 gnutls-2.8.2.zip > ca3306416ad63c22b281c30165c83d94d97b0e7a817303f2ca61d00c gnutls-2.8.2.zip > > A Debian mingw32 package is also available: > http://josefsson.org/gnutls4win/mingw32-gnutls_2.8.2-1_all.deb (4.8MB) > > The checksum values for SHA-1 and SHA-224 are: > > 4d591773c387be1409fb000ff1a9eae3c3c19756 mingw32-gnutls_2.8.2-1_all.deb > fb742033dca3ccca3757d798dfa37fb718c2bac082e557bb7dfbfe57 mingw32-gnutls_2.8.2-1_all.deb > > Internationalization > ==================== > > The GnuTLS library messages have been translated into Czech, Dutch, > French, German, Malay, Polish, Swedish, and Vietnamese. We welcome the > addition of more translations. > > Support > ======= > > Improving GnuTLS is costly, but you can help! We are looking for > organizations that find GnuTLS useful and wish to contribute back. You > can contribute by reporting bugs, improve the software, or donate money > or equipment. > > Commercial support contracts for GnuTLS are available, and they help > finance continued maintenance. Simon Josefsson Datakonsult AB, a > Stockholm based privately held company, is currently funding GnuTLS > maintenance. We are always looking for interesting development > projects. See http://josefsson.org/ for more details. > > The GnuTLS service directory is available at: > > http://www.gnu.org/software/gnutls/commercial.html > > Happy Hacking, > Simon > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel From Jeff.Cai at Sun.COM Thu Aug 13 04:36:39 2009 From: Jeff.Cai at Sun.COM (Jeff Cai) Date: Thu, 13 Aug 2009 10:36:39 +0800 Subject: GnuTLS 2.8.2 In-Reply-To: <1250066631.3868.8.camel@marathon> References: <87k51bg4xb.fsf@mocca.josefsson.org> <1250066631.3868.8.camel@marathon> Message-ID: <1250130999.4606.1.camel@marathon> Simon, Could you provide a patch for 2.6.6 or release 2.6.8 to fix this issue? Thanks Jeff On Wed, 2009-08-12 at 16:43 +0800, Jeff Cai wrote: > > What's New > > ========== > > > > ** libgnutls: Fix problem with NUL bytes in X.509 CN and SAN fields. > > By using a NUL byte in CN/SAN fields, it was possible to fool GnuTLS > > into 1) not printing the entire CN/SAN field value when printing a > > certificate and 2) cause incorrect positive matches when matching a > > hostname against a certificate. Some CAs apparently have poor > > checking of CN/SAN values and issue these (arguable invalid) > > certificates. Combined, this can be used by attackers to become a > > MITM on server-authenticated TLS sessions. The problem is mitigated > > since attackers needs to get one certificate per site they want to > > attack, and the attacker reveals his tracks by applying for a > > certificate at the CA. It does not apply to client authenticated TLS > > sessions. Research presented independently by Dan Kaminsky and Moxie > > Marlinspike at BlackHat09. Thanks to Tomas Hoger > > for providing one part of the patch. [GNUTLS-SA-2009-4]. > > How is it affecting old versions of gnutls like 2.6 and 2.4? Do they > also need a patch applied if not upgrading them? > > Jeff > > > > > ** libgnutls: Fix return value of gnutls_certificate_client_get_request_status. > > Before it always returned false. Reported by Peter Hendrickson > > in > > . > > > > ** libgnutls: Fix off-by-one size computation error in unknown DN printing. > > The error resulted in truncated strings when printing unknown OIDs in > > X.509 certificate DNs. Reported by Tim Kosse > > in > > . > > > > ** libgnutls: Return correct bit lengths of some MPIs. > > gnutls_dh_get_prime_bits, gnutls_rsa_export_get_modulus_bits, and > > gnutls_dh_get_peers_public_bits. Before the reported value was > > overestimated. Reported by Peter Hendrickson in > > . > > > > ** libgnutls: Avoid internal error when invoked after GNUTLS_E_AGAIN. > > Report and patch by Tim Kosse in > > > > and > > . > > > > ** libgnutls: Relax checking of required libtasn1/libgcrypt versions. > > Before we required that the runtime library used the same (or more > > recent) libgcrypt/libtasn1 as it was compiled with. Now we just check > > that the runtime usage is above the minimum required. Reported by > > Marco d'Itri via Andreas Metzler > > in . > > > > ** minitasn1: Internal copy updated to libtasn1 v2.3. > > > > ** tests: Fix failure in "chainverify" because a certificate have expired. > > > > ** API and ABI modifications: > > No changes since last version. > > > > Getting the Software > > ==================== > > > > GnuTLS may be downloaded from one of the mirror sites or direct from > > . The list of mirrors can be found at > > . > > > > Here are the BZIP2 compressed sources (6.0MB): > > > > ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2 > > http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2 > > > > Here are OpenPGP detached signatures signed using key 0xB565716F: > > > > ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2.sig > > http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.2.tar.bz2.sig > > > > Note, that we don't distribute gzip compressed tarballs. > > > > In order to check that the version of GnuTLS which you are going to > > install is an original and unmodified one, you should verify the OpenPGP > > signature. You can use the command > > > > gpg --verify gnutls-2.8.2.tar.bz2.sig > > > > This checks whether the signature file matches the source file. You > > should see a message indicating that the signature is good and made by > > that signing key. Make sure that you have the right key, either by > > checking the fingerprint of that key with other sources or by checking > > that the key has been signed by a trustworthy other key. The signing > > key can be identified with the following information: > > > > pub 1280R/B565716F 2002-05-05 [expires: 2010-04-21] > > Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F > > uid Simon Josefsson > > uid Simon Josefsson > > sub 1280R/4D5D40AE 2002-05-05 [expires: 2010-04-21] > > > > The key is available from: > > http://josefsson.org/key.txt > > dns:b565716f.josefsson.org?TYPE=CERT > > > > Alternatively, after successfully verifying the OpenPGP signature of > > this announcement, you could verify that the files match the following > > checksum values. The values are for SHA-1 and SHA-224 respectively: > > > > eea59fb972e7d566679645a564a56b58aeffe10b gnutls-2.8.2.tar.bz2 > > > > 048bfb981a4a88d7040c1951614bd9d06cdd787e2242d6243391775a gnutls-2.8.2.tar.bz2 > > > > Documentation > > ============= > > > > The manual is available online at: > > > > http://www.gnu.org/software/gnutls/documentation.html > > > > In particular the following formats are available: > > > > HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html > > PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf > > > > For developers there is a GnuTLS API reference manual formatted using > > the GTK-DOC tools: > > > > http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html > > > > Community > > ========= > > > > If you need help to use GnuTLS, or want to help others, you are invited > > to join our help-gnutls mailing list, see: > > > > http://lists.gnu.org/mailman/listinfo/help-gnutls > > > > If you wish to participate in the development of GnuTLS, you are invited > > to join our gnutls-dev mailing list, see: > > > > http://lists.gnu.org/mailman/listinfo/gnutls-devel > > > > Windows installer > > ================= > > > > GnuTLS has been ported to the Windows operating system, and a binary > > installer is available. The installer contains DLLs for application > > development, manuals, examples, and source code. The installer includes > > libgpg-error v1.7, libgcrypt v1.4.4, libtasn1 v2.3, and GnuTLS v2.8.2. > > > > For more information about GnuTLS for Windows: > > http://josefsson.org/gnutls4win/ > > > > The Windows binary installer and PGP signature: > > http://josefsson.org/gnutls4win/gnutls-2.8.2.exe (15MB) > > http://josefsson.org/gnutls4win/gnutls-2.8.2.exe.sig > > > > The checksum values for SHA-1 and SHA-224 are: > > > > 18fc15825832606123284dd5d7a77d402bf14101 gnutls-2.8.2.exe > > 9e9b9e5c9c213743fcb070af5c0b9a552ddd3fb3a241f2e0dbb89fa3 gnutls-2.8.2.exe > > > > A ZIP archive containing the Windows binaries: > > http://josefsson.org/gnutls4win/gnutls-2.8.2.zip (5.3MB) > > http://josefsson.org/gnutls4win/gnutls-2.8.2.zip.sig > > > > The checksum values for SHA-1 and SHA-224 are: > > > > af492d1c31ef4ecc27724839ce62f5a334731b26 gnutls-2.8.2.zip > > ca3306416ad63c22b281c30165c83d94d97b0e7a817303f2ca61d00c gnutls-2.8.2.zip > > > > A Debian mingw32 package is also available: > > http://josefsson.org/gnutls4win/mingw32-gnutls_2.8.2-1_all.deb (4.8MB) > > > > The checksum values for SHA-1 and SHA-224 are: > > > > 4d591773c387be1409fb000ff1a9eae3c3c19756 mingw32-gnutls_2.8.2-1_all.deb > > fb742033dca3ccca3757d798dfa37fb718c2bac082e557bb7dfbfe57 mingw32-gnutls_2.8.2-1_all.deb > > > > Internationalization > > ==================== > > > > The GnuTLS library messages have been translated into Czech, Dutch, > > French, German, Malay, Polish, Swedish, and Vietnamese. We welcome the > > addition of more translations. > > > > Support > > ======= > > > > Improving GnuTLS is costly, but you can help! We are looking for > > organizations that find GnuTLS useful and wish to contribute back. You > > can contribute by reporting bugs, improve the software, or donate money > > or equipment. > > > > Commercial support contracts for GnuTLS are available, and they help > > finance continued maintenance. Simon Josefsson Datakonsult AB, a > > Stockholm based privately held company, is currently funding GnuTLS > > maintenance. We are always looking for interesting development > > projects. See http://josefsson.org/ for more details. > > > > The GnuTLS service directory is available at: > > > > http://www.gnu.org/software/gnutls/commercial.html > > > > Happy Hacking, > > Simon > > _______________________________________________ > > Gnutls-devel mailing list > > Gnutls-devel at gnu.org > > http://lists.gnu.org/mailman/listinfo/gnutls-devel > > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel From simon at josefsson.org Thu Aug 13 12:11:17 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 13 Aug 2009 12:11:17 +0200 Subject: GnuTLS 2.8.2 In-Reply-To: <1250130999.4606.1.camel@marathon> (Jeff Cai's message of "Thu, 13 Aug 2009 10:36:39 +0800") References: <87k51bg4xb.fsf@mocca.josefsson.org> <1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon> Message-ID: <878whodnwa.fsf@mocca.josefsson.org> Jeff Cai writes: > Simon, > > Could you provide a patch for 2.6.6 or release 2.6.8 to fix this issue? I'm releasing an updated 2.8.3 shortly, and will post patches against 2.8.1 to solve the problem -- hopefully they will apply to 2.6.x as well. There is an issue that gnutls-cli before 2.8.x used its own certificate printing functions, but that is only a display problem. /Simon From simon at josefsson.org Thu Aug 13 12:32:01 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 13 Aug 2009 12:32:01 +0200 Subject: GnuTLS 2.8.3 Message-ID: <871vngdmxq.fsf@mocca.josefsson.org> We are proud to announce a new stable GnuTLS release: Version 2.8.3. GnuTLS is a modern C library that implements the standard network security protocol Transport Layer Security (TLS), for use by network applications. GnuTLS is developed for GNU/Linux, but works on many Unix-like systems and comes with a binary installer for Windows. The GnuTLS library is distributed under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS library (which contains TLS/IA support, LZO compression and Libgcrypt FIPS-mode handler), the OpenSSL compatibility library, the self tests and the command line tools are all distributed under the GNU General Public License version 3.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.3 (or later). The project page of the library is available at: http://www.gnu.org/software/gnutls/ What's New ========== ** libgnutls: Fix patch for NUL in CN/SAN in last release. Code intended to be removed would lead to an read-out-bound error in some situations. Reported by Tomas Hoger . A CVE code have been allocated for the vulnerability: [CVE-2009-2730]. ** libgnutls: Fix rare failure in gnutls_x509_crt_import. The function may fail incorrectly when an earlier certificate was imported to the same gnutls_x509_crt_t structure. ** libgnutls-extra, libgnutls-openssl: Fix MinGW cross-compiling build error. ** tests: Made self-test mini-eagain take less time. ** doc: Typo fixes. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the mirror sites or direct from . The list of mirrors can be found at . Here are the BZIP2 compressed sources (6.0MB): ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.3.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.3.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.3.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.3.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs. In order to check that the version of GnuTLS which you are going to install is an original and unmodified one, you should verify the OpenPGP signature. You can use the command gpg --verify gnutls-2.8.3.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. The signing key can be identified with the following information: pub 1280R/B565716F 2002-05-05 [expires: 2010-04-21] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2010-04-21] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Alternatively, after successfully verifying the OpenPGP signature of this announcement, you could verify that the files match the following checksum values. The values are for SHA-1 and SHA-224 respectively: c25fb354258777f9ee34b79b08eb87c024cada75 gnutls-2.8.3.tar.bz2 dff4d774ec9339a1e94711fc9c3762d36df1e77c0b1c1a591ea190aa gnutls-2.8.3.tar.bz2 Documentation ============= The manual is available online at: http://www.gnu.org/software/gnutls/documentation.html In particular the following formats are available: HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf For developers there is a GnuTLS API reference manual formatted using the GTK-DOC tools: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html For developers interested in improving code quality, we publish Cyclomatic code complexity charts that help you find code that may need review and improvements: http://www.gnu.org/software/gnutls/cyclo/ Also useful are code coverage charts which indicate parts of the source code that needs to be tested better by the included self-tests: http://www.gnu.org/software/gnutls/coverage/ Community ========= If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: http://lists.gnu.org/mailman/listinfo/help-gnutls If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-dev mailing list, see: http://lists.gnu.org/mailman/listinfo/gnutls-devel Windows installer ================= GnuTLS has been ported to the Windows operating system, and a binary installer is available. The installer contains DLLs for application development, manuals, examples, and source code. The installer includes libgpg-error v1.7, libgcrypt v1.4.4, libtasn1 v2.3, and GnuTLS v2.8.3. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ The Windows binary installer and PGP signature: http://josefsson.org/gnutls4win/gnutls-2.8.3.exe (15MB) http://josefsson.org/gnutls4win/gnutls-2.8.3.exe.sig The checksum values for SHA-1 and SHA-224 are: 6c6503cbd357d71595a320502ce3e32fe5598d64 gnutls-2.8.3.exe f75988a6efe8306bf4ba4827ff49a2fd39f3f6d9730ddffcca1f3254 gnutls-2.8.3.exe A ZIP archive containing the Windows binaries: http://josefsson.org/gnutls4win/gnutls-2.8.3.zip (5.3MB) http://josefsson.org/gnutls4win/gnutls-2.8.3.zip.sig The checksum values for SHA-1 and SHA-224 are: 4c4829495d7277b3fec69a975084e1144e805e0d gnutls-2.8.3.zip 515dcbe98b739db7419ae25db1a2d59d3cea60683ca1bfd424c348b3 gnutls-2.8.3.zip A Debian mingw32 package is also available: http://josefsson.org/gnutls4win/mingw32-gnutls_2.8.3-1_all.deb (4.8MB) The checksum values for SHA-1 and SHA-224 are: 8cf060268369f1d261b10731840cf0392e625210 mingw32-gnutls_2.8.3-1_all.deb 0f99a5a356cd1a03cc0a3cce9f19b7615772d4486fea0d06e68f3ef6 mingw32-gnutls_2.8.3-1_all.deb Internationalization ==================== The GnuTLS library messages have been translated into Czech, Dutch, French, German, Malay, Polish, Swedish, and Vietnamese. We welcome the addition of more translations. Support ======= Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. The GnuTLS service directory is available at: http://www.gnu.org/software/gnutls/commercial.html Happy Hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Thu Aug 13 12:48:38 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 13 Aug 2009 12:48:38 +0200 Subject: Bug#540449: gnutls version checking too strict In-Reply-To: <87fxbzjvs0.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon, 10 Aug 2009 21:47:43 +0200") References: <20090808024733.GA31539@bongo.bofh.it> <20090808074058.GA3254@downhill.g.la> <20090808125646.GB3254@downhill.g.la> <87tz0fg877.fsf@mocca.josefsson.org> <20090810170348.GA3282@downhill.g.la> <87fxbzjvs0.fsf@mocca.josefsson.org> Message-ID: <87tz0cc7ll.fsf@mocca.josefsson.org> Simon Josefsson writes: > Andreas Metzler writes: > >> On 2009-08-10 Simon Josefsson wrote: >>> Andreas Metzler writes: >> [...] >>> > The gnutls 2.8 series will absolutely fail to work if the currently >>> > installed version of libtasn1 or libgcrypt is not greater or equal >>> > than the version gnutls was built against. This is much too cautious >> [...] >>> Hi. Just in time for the 2.8.2 release. :-) >> >>> I applied it somewhat differently, see: >>> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=860605be8f3b344738548ecfe0f1a6e6cb357c0b >> >> Thanks for fixing this very quickly. >> >> I will try to find time for a (2.8.3, probably ;-) upload tomorrow. > > Right, please wait a day or two for 2.8.3 to avoid the double work. Now released! > I think lenny (and etch?) needs upgraded packages, though, for the > security problem. I'm working on publishing minimal patches for 2.8.x, which hopefully won't be that difficult to back-port to 2.6.x or earlier versions. /Simon From Jeff.Cai at Sun.COM Fri Aug 14 10:11:55 2009 From: Jeff.Cai at Sun.COM (Jeff Cai) Date: Fri, 14 Aug 2009 16:11:55 +0800 Subject: GnuTLS 2.8.2 In-Reply-To: <878whodnwa.fsf@mocca.josefsson.org> References: <87k51bg4xb.fsf@mocca.josefsson.org> <1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon> <878whodnwa.fsf@mocca.josefsson.org> Message-ID: <1250237515.5919.1.camel@marathon> Simon, I didn't find that patch. Could you please tell me where it is? Thanks in advance. :) Then will you release a new package like 2.6.7 to fix this issue? Thanks Jeff On Thu, 2009-08-13 at 12:11 +0200, Simon Josefsson wrote: > Jeff Cai writes: > > > Simon, > > > > Could you provide a patch for 2.6.6 or release 2.6.8 to fix this issue? > > I'm releasing an updated 2.8.3 shortly, and will post patches against > 2.8.1 to solve the problem -- hopefully they will apply to 2.6.x as > well. There is an issue that gnutls-cli before 2.8.x used its own > certificate printing functions, but that is only a display problem. > > /Simon > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel From simon at josefsson.org Fri Aug 14 12:02:27 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 14 Aug 2009 12:02:27 +0200 Subject: NUL bytes in X.509 CN/SAN fields [GNUTLS-SA-2009-4] [CVE-2009-2730] Message-ID: <87ws56pvbg.fsf@mocca.josefsson.org> Research presented independently by Dan Kaminsky and Moxie Marlinspike at BlackHat09 demonstrated a vulnerability related to NUL bytes in X.509 certificate name fields. Attackers needs to go to a CA and acquire a certificate for an invalid name. To attack GnuTLS, the attacker needs to acquire such an invalid certificate for each TLS server to be attacked. The attacker is then able to use the certificate to become a man-in-the-middle on server authenticated channels. The client will receive the attacker's certificate, so the attack leaves traces with the client. The attack does not work for client-authenticated TLS channels. To make client notice the attack and reject it, a few separate aspects needs to be resolved: 1) When displaying a certificate to the user, GnuTLS needs to be fixed so that it does not truncate strings in CN/SAN fields to the first NUL. 2) When comparing the CN/SAN fields to a hostname, it has to make sure it compares the entire string, and not only up until the first NUL. We recommend all users to upgrade to version 2.8.3 which solves these concerns. For people using older releases, or wants to read the minimal patch required to solve the problem, I have prepared patches that applies to version 2.8.1 -- the last stable releases that didn't have this vulnerability. To solve 1) apply PATCH 1 included below. The patches in git corresponding to this patch is (they have to be applied in order): http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=a431be86124f900c4082e82d32917f86fcce461a http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=74b6d92f9675ce4e03642c4d6ced4a3a614b07f6 http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_8_x&id=40081594e3de518b998f3e5177ed5a9f7707f2e8 To solve 2) apply PATCH 2 included below. This patch was supplied by Tomas Hoger . The patches in git corresponding to this patch is (they have to be applied in order): http://git.savannah.gnu.org/cgit/gnutls.git/patch/?id=5a58e9d33448235377afd5fbfcee1683dc70eae3 http://git.savannah.gnu.org/cgit/gnutls.git/patch/?id=1ea190d216767dd4ab93b87361cbcb9d4fb3aafc I have verified that the patches work for v2.6.6 as well if you manually resolve one failed hunk. /Simon PATCH 1 diff -ur gnutls-2.8.1.orig/lib/x509/common.c gnutls-2.8.1/lib/x509/common.c --- gnutls-2.8.1.orig/lib/x509/common.c 2009-06-02 20:59:32.000000000 +0200 +++ gnutls-2.8.1/lib/x509/common.c 2009-08-14 11:56:17.000000000 +0200 @@ -1,5 +1,5 @@ /* - * Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation + * Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation * * Author: Nikos Mavrogiannopoulos * @@ -242,6 +242,10 @@ { str[len] = 0; + /* Refuse to deal with strings containing NULs. */ + if (strlen (str) != len) + return GNUTLS_E_ASN1_DER_ERROR; + if (res) _gnutls_str_cpy (res, *res_size, str); *res_size = len; @@ -291,25 +295,27 @@ non_printable = 0; } - if (res) + if (non_printable == 0) { - if (non_printable == 0) - { - str[len] = 0; - _gnutls_str_cpy (res, *res_size, str); - *res_size = len; - } - else + str[len] = 0; + + /* Refuse to deal with strings containing NULs. */ + if (strlen (str) != len) + return GNUTLS_E_ASN1_DER_ERROR; + + if (res) + _gnutls_str_cpy (res, *res_size, str); + *res_size = len; + } + else + { + result = _gnutls_x509_data2hex (str, len, res, res_size); + if (result < 0) { - result = _gnutls_x509_data2hex (str, len, res, res_size); - if (result < 0) - { - gnutls_assert (); - return result; - } + gnutls_assert (); + return result; } } - } return 0; diff -ur gnutls-2.8.1.orig/lib/x509/output.c gnutls-2.8.1/lib/x509/output.c --- gnutls-2.8.1.orig/lib/x509/output.c 2009-06-02 20:59:32.000000000 +0200 +++ gnutls-2.8.1/lib/x509/output.c 2009-08-14 11:56:17.000000000 +0200 @@ -354,6 +354,17 @@ return; } + if ((err == GNUTLS_SAN_DNSNAME + || err == GNUTLS_SAN_RFC822NAME + || err == GNUTLS_SAN_URI) && + strlen (buffer) != size) + { + adds (str, _("warning: distributionPoint contains an embedded NUL, " + "replacing with '!'\n")); + while (strlen (buffer) < size) + buffer[strlen (buffer)] = '!'; + } + switch (err) { case GNUTLS_SAN_DNSNAME: @@ -552,6 +563,17 @@ return; } + if ((err == GNUTLS_SAN_DNSNAME + || err == GNUTLS_SAN_RFC822NAME + || err == GNUTLS_SAN_URI) && + strlen (buffer) != size) + { + adds (str, _("warning: SAN contains an embedded NUL, " + "replacing with '!'\n")); + while (strlen (buffer) < size) + buffer[strlen (buffer)] = '!'; + } + switch (err) { case GNUTLS_SAN_DNSNAME: @@ -623,8 +645,18 @@ } if (err == GNUTLS_SAN_OTHERNAME_XMPP) - addf (str, _("%s\t\t\tXMPP Address: %.*s\n"), prefix, - (int) size, buffer); + { + if (strlen (buffer) != size) + { + adds (str, _("warning: SAN contains an embedded NUL, " + "replacing with '!'\n")); + while (strlen (buffer) < size) + buffer[strlen (buffer)] = '!'; + } + + addf (str, _("%s\t\t\tXMPP Address: %.*s\n"), prefix, + (int) size, buffer); + } else { addf (str, _("%s\t\t\totherName OID: %.*s\n"), prefix, PATCH 2 diff -ur gnutls-2.8.1.orig/lib/gnutls_str.c gnutls-2.8.1/lib/gnutls_str.c --- gnutls-2.8.1.orig/lib/gnutls_str.c 2009-06-02 20:59:32.000000000 +0200 +++ gnutls-2.8.1/lib/gnutls_str.c 2009-08-14 11:40:45.000000000 +0200 @@ -1,5 +1,5 @@ /* - * Copyright (C) 2002, 2004, 2005, 2007, 2008 Free Software Foundation + * Copyright (C) 2002, 2004, 2005, 2007, 2008, 2009 Free Software Foundation * * Author: Nikos Mavrogiannopoulos * @@ -363,17 +363,22 @@ /* compare hostname against certificate, taking account of wildcards * return 1 on success or 0 on error + * + * note: certnamesize is required as X509 certs can contain embedded NULs in + * the strings such as CN or subjectAltName */ int -_gnutls_hostname_compare (const char *certname, const char *hostname) +_gnutls_hostname_compare (const char *certname, + size_t certnamesize, + const char *hostname) { /* find the first different character */ for (; *certname && *hostname && toupper (*certname) == toupper (*hostname); - certname++, hostname++) + certname++, hostname++, certnamesize--) ; /* the strings are the same */ - if (strlen (certname) == 0 && strlen (hostname) == 0) + if (certnamesize == 0 && *hostname == '\0') return 1; if (*certname == '*') @@ -381,15 +386,16 @@ /* a wildcard certificate */ certname++; + certnamesize--; while (1) { /* Use a recursive call to allow multiple wildcards */ - if (_gnutls_hostname_compare (certname, hostname)) - { - return 1; - } - /* wildcards are only allowed to match a single domain component or component fragment */ + if (_gnutls_hostname_compare (certname, certnamesize, hostname)) + return 1; + + /* wildcards are only allowed to match a single domain + component or component fragment */ if (*hostname == '\0' || *hostname == '.') break; hostname++; diff -ur gnutls-2.8.1.orig/lib/gnutls_str.h gnutls-2.8.1/lib/gnutls_str.h --- gnutls-2.8.1.orig/lib/gnutls_str.h 2009-06-02 20:59:32.000000000 +0200 +++ gnutls-2.8.1/lib/gnutls_str.h 2009-08-14 11:40:45.000000000 +0200 @@ -79,7 +79,7 @@ int _gnutls_hex2bin (const opaque * hex_data, int hex_size, opaque * bin_data, size_t * bin_size); -int _gnutls_hostname_compare (const char *certname, const char *hostname); +int _gnutls_hostname_compare (const char *certname, size_t certnamesize, const char *hostname); #define MAX_CN 256 #endif diff -ur gnutls-2.8.1.orig/lib/openpgp/pgp.c gnutls-2.8.1/lib/openpgp/pgp.c --- gnutls-2.8.1.orig/lib/openpgp/pgp.c 2009-06-02 20:59:32.000000000 +0200 +++ gnutls-2.8.1/lib/openpgp/pgp.c 2009-08-14 11:40:45.000000000 +0200 @@ -570,7 +570,7 @@ if (ret == 0) { - if (_gnutls_hostname_compare (dnsname, hostname)) + if (_gnutls_hostname_compare (dnsname, dnsnamesize, hostname)) return 1; } } diff -ur gnutls-2.8.1.orig/lib/x509/rfc2818_hostname.c gnutls-2.8.1/lib/x509/rfc2818_hostname.c --- gnutls-2.8.1.orig/lib/x509/rfc2818_hostname.c 2009-06-02 20:59:32.000000000 +0200 +++ gnutls-2.8.1/lib/x509/rfc2818_hostname.c 2009-08-14 11:40:45.000000000 +0200 @@ -74,7 +74,7 @@ if (ret == GNUTLS_SAN_DNSNAME) { found_dnsname = 1; - if (_gnutls_hostname_compare (dnsname, hostname)) + if (_gnutls_hostname_compare (dnsname, dnsnamesize, hostname)) { return 1; } @@ -84,7 +84,7 @@ found_dnsname = 1; /* RFC 2818 is unclear whether the CN should be compared for IP addresses too, but we won't do it. */ - if (_gnutls_hostname_compare (dnsname, hostname)) + if (_gnutls_hostname_compare (dnsname, dnsnamesize, hostname)) { return 1; } @@ -104,7 +104,7 @@ return 0; } - if (_gnutls_hostname_compare (dnsname, hostname)) + if (_gnutls_hostname_compare (dnsname, dnsnamesize, hostname)) { return 1; } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Fri Aug 14 12:04:07 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 14 Aug 2009 12:04:07 +0200 Subject: GnuTLS 2.8.2 In-Reply-To: <1250237515.5919.1.camel@marathon> (Jeff Cai's message of "Fri, 14 Aug 2009 16:11:55 +0800") References: <87k51bg4xb.fsf@mocca.josefsson.org> <1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon> <878whodnwa.fsf@mocca.josefsson.org> <1250237515.5919.1.camel@marathon> Message-ID: <87skfupv8o.fsf@mocca.josefsson.org> Jeff Cai writes: > Simon, > > I didn't find that patch. Could you please tell me where it is? Thanks > in advance. :) Just posted. ;) > Then will you release a new package like 2.6.7 to fix this issue? I don't have time/resources to produce releases for older branches. If someone else wants to volunteer to work on fixing older releases, that would be appreciated. /Simon From simon at josefsson.org Fri Aug 14 12:14:21 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 14 Aug 2009 12:14:21 +0200 Subject: How to check if your GnuTLS is vulnerable to NUL-in-CN/SAN issue Message-ID: <87my62purm.fsf@mocca.josefsson.org> Here is how you test if your GnuTLS library is vulnerable to the NUL-in-CN/SAN issue (i.e., [GNUTLS-SA-2009-4] [CVE-2009-2730]). Download and build: http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/nul-in-x509-names.c For example: jas at mocca:~$ wget -q http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/nul-in-x509-names.c jas at mocca:~$ gcc -o nul-in-x509-names nul-in-x509-names.c -lgnutls jas at mocca:~$ ./nul-in-x509-names gnutls_x509_crt_check_hostname OK (NUL-IN-CN) gnutls_x509_crt_check_hostname OK (NUL-IN-SAN) jas at mocca:~$ If your library have not yet been patched, the output will look like: gnutls_x509_crt_check_hostname BROKEN (NUL-IN-CN) gnutls_x509_crt_check_hostname BROKEN (NUL-IN-SAN) If you have a locally installed GnuTLS version and wants to check your system library version, on GNU/Linux system you can use the LD_PRELOAD variable to point at the exact library version to test. For example on my Debian system: jas at mocca:~$ LD_PRELOAD=/usr/lib/libgnutls.so ./nul-in-x509-names gnutls_x509_crt_check_hostname BROKEN (NUL-IN-CN) gnutls_x509_crt_check_hostname BROKEN (NUL-IN-SAN) jas at mocca:~$ To verify that displaying of certificates works correctly, you can use two sample certificates provided by Tomas Hoger . To test whether NUL in CN is handled properly, here is how you do it: jas at mocca:~$ cat>nul-cn.pem -----BEGIN CERTIFICATE----- MIIDjTCCAnWgAwIBAgIBATANBgkqhkiG9w0BAQUFADB0MQswCQYDVQQGEwJHQjES MBAGA1UECBMJQmVya3NoaXJlMRAwDgYDVQQHEwdOZXdidXJ5MRcwFQYDVQQKEw5N eSBDb21wYW55IEx0ZDELMAkGA1UECxMCQ0ExGTAXBgNVBAMTEE5VTEwtZnJpZW5k bHkgQ0EwHhcNMDkwODA0MDczMzQzWhcNMTkwODAyMDczMzQzWjAjMSEwHwYDVQQD Exh3d3cuYmFuay5jb20ALmJhZGd1eS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDNJnCWqaZdPpztDwgVWnwXJWhorxO5rUH6ElTihHJ9WNHiQELB We0FPaoQU3AAiDp3oMBWnqx9ISpxRFEIvBcH2qijdtxRvBuK9gIaVb9GtERrJ16+ 5ReLVrLGgjYRg6i/9y8NF/bNR7VvK6ZBto0zX+rqi7Ea4pk4/1lbCqFxE8o3P7mw HpGayJM1DErgnfTSYcdOW0EKfDFUmdv1Zc6A08ICN2T9VBJ76qyFWVwX4S720Kjy 0C6UWS/Cpl/aB957LhQH7eQnJDedCS6x+VpIuYAkQ+bLx24139VpNP/m1p7odmZu X1kBPJY77HILPB6VD85oE5wi3Ru1RChQSgV/AgMBAAGjezB5MAkGA1UdEwQCMAAw LAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0G A1UdDgQWBBQzFSS+2mY6BovZJzQ6r2JA5JVmXTAfBgNVHSMEGDAWgBQKaTlfnTAE GAguAg7m6p2yJvbiajANBgkqhkiG9w0BAQUFAAOCAQEAMmUjH8jZU4SC0ArrFFEk A7xsGypa/hvw6GkMKxmGz38ydtgr0s+LxNG2W5xgo5kuknIGzt6L0qLSiXwTqQtO vhIJ5dYoOqynJlaUfxPuZH3elGB1wbxVl9SqE44C2LCwcFOuGFPOqrIshT7j8+Em 8/pc7vh7C8Y5tQQzXq64Xg5mzKjAag3sYMHF2TnqvRuPHH0WOLHoyDcBqkuZ3+QP EL5h7prPzScFRgBg2Gp0CDI8i5ABagczDGyQ2+r7ahcadrtzFCfhpH7V3TCxXfIO qtSy1Uz2T5EqB/Q3wc9IGcX+fpKWqN9QajGSo7EU/kHMSWKYTerFugUtScMicu9B CQ== -----END CERTIFICATE----- jas at mocca:~$ certtool -i < nul-cn.pem ... Subject: CN=#13187777772e62616e6b2e636f6d002e6261646775792e636f6d ... Notice how the Subject line is LDAP escaped when it contains a NUL value. Buggy versions would display the cert like this: Subject: CN=www.bank.com To test whether NUL in CN is handled properly, here is how you do it: jas at mocca:~$ cat>nul-san.pem -----BEGIN CERTIFICATE----- MIIDrTCCApWgAwIBAgIBADANBgkqhkiG9w0BAQUFADB0MQswCQYDVQQGEwJHQjES MBAGA1UECBMJQmVya3NoaXJlMRAwDgYDVQQHEwdOZXdidXJ5MRcwFQYDVQQKEw5N eSBDb21wYW55IEx0ZDELMAkGA1UECxMCQ0ExGTAXBgNVBAMTEE5VTEwtZnJpZW5k bHkgQ0EwHhcNMDkwODA0MDY1MzA1WhcNMTkwODAyMDY1MzA1WjAZMRcwFQYDVQQD Ew53d3cuYmFkZ3V5LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AM0mcJappl0+nO0PCBVafBclaGivE7mtQfoSVOKEcn1Y0eJAQsFZ7QU9qhBTcACI OnegwFaerH0hKnFEUQi8FwfaqKN23FG8G4r2AhpVv0a0RGsnXr7lF4tWssaCNhGD qL/3Lw0X9s1HtW8rpkG2jTNf6uqLsRrimTj/WVsKoXETyjc/ubAekZrIkzUMSuCd 9NJhx05bQQp8MVSZ2/VlzoDTwgI3ZP1UEnvqrIVZXBfhLvbQqPLQLpRZL8KmX9oH 3nsuFAft5CckN50JLrH5Wki5gCRD5svHbjXf1Wk0/+bWnuh2Zm5fWQE8ljvscgs8 HpUPzmgTnCLdG7VEKFBKBX8CAwEAAaOBpDCBoTAJBgNVHRMEAjAAMCwGCWCGSAGG +EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU MxUkvtpmOgaL2Sc0Oq9iQOSVZl0wHwYDVR0jBBgwFoAUCmk5X50wBBgILgIO5uqd sib24mowJgYDVR0RBB8wHYIbd3d3LmJhbmsuY29tAHd3dy5iYWRndXkuY29tMA0G CSqGSIb3DQEBBQUAA4IBAQAnbn2zqYZSV2qgxjBsHpQJp2+t/hGfvjKNAXuLlGbX fLaxkPzk9bYyvGxxI7EYiNZHvNoHx15GcTrmQG7Bfx1WlnBl2FGp3J6lBgCY5x4Q vIK6AOVOog8+7Irdb8bJweztbXwxPmaHR6GLFTwhfuwheD0hcHK6cMNk+B1P2dAn PD5+olmuvprTAESncjrjP8ibxY+xlP4AD264FIjxA1CRUa/wHve4WqRXNS3xrciu 3SlhFH3q0TSAXBv960PcIW3GRPk7VHbEkVuspI5y59gk/6dawO8nw9fk+X9VjQ0w 7KLZbch29L6UPRIySpFP28PndgdaEpcYtxUAmFkhiT41 -----END CERTIFICATE----- jas at mocca:~$ certtool -i < nul-san.pem ... Subject Alternative Name (not critical): warning: SAN contains an embedded NUL, replacing with '!' DNSname: www.bank.com!www.badguy.com ... Notice the warning and the full output. Buggy versions would display the cert like this: Subject Alternative Name (not critical): DNSname: www.bank.com I hope this helps you test your system! /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From tgc at jupiterrise.com Fri Aug 14 16:03:34 2009 From: tgc at jupiterrise.com (Tom G. Christensen) Date: Fri, 14 Aug 2009 16:03:34 +0200 Subject: Buildreport for GnuTLS 2.8.3 Message-ID: <20090814140334.GA30319@ares.tgcnet> I grabbed GnuTLS 2.8.3 and tried building it on IRIX 5.3 and 6.2. It builds and passes the testsuite on IRIX 6.2. However I'm still seeing these during the build: In file included from ../gnutls_int.h:29, from opencdk.h:30, from main.c:36: ../config.h:367:1: warning: "SIZE_MAX" redefined In file included from ./../gl/stdlib.h:52, from ./../gl/unistd.h:40, from main.c:30: ./../gl/stdint.h:473:1: warning: this is the location of the previous definition Bruno committed a fix for this to size_max.m4 when it was brought up on bug-gnulib a few months ago but the copies included in gnutls are too old and don't have the fix. It fails to build on IRIX 5.3 due to missing siginterrupt function: ld: ERROR 33: Unresolved text symbol "siginterrupt" -- 1st referenced by tests.o. Since gnulib does not provide a siginterrupt replacement I instead added the replacement used by bash 4.0 to tests.c: static int siginterrupt (sig, flag) int sig, flag; { struct sigaction act; sigaction (sig, (struct sigaction *)NULL, &act); if (flag) act.sa_flags &= ~SA_RESTART; else act.sa_flags |= SA_RESTART; return (sigaction (sig, &act, (struct sigaction *)NULL)); } With that added the build completes and passes the testsuite. -tgc From simon at yubico.com Fri Aug 14 16:03:18 2009 From: simon at yubico.com (Simon Josefsson) Date: Fri, 14 Aug 2009 16:03:18 +0200 Subject: GnuTLS 2.9.2 Message-ID: <87vdkqxzkp.fsf@mocca.josefsson.org> The GnuTLS 2.9.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.9.2.tar.bz2 (5.9MB) ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.9.2.tar.bz2 Here is the OpenPGP signature: http://alpha.gnu.org/gnu/gnutls/gnutls-2.9.2.tar.bz2.sig ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.9.2.tar.bz2.sig Windows build: http://josefsson.org/gnutls4win/gnutls-2.9.2.exe http://josefsson.org/gnutls4win/gnutls-2.9.2.exe.sig http://josefsson.org/gnutls4win/gnutls-2.9.2.zip http://josefsson.org/gnutls4win/gnutls-2.9.2.zip.sig http://josefsson.org/gnutls4win/mingw32-gnutls_2.9.2-1_all.deb Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. /Simon * Version 2.9.2 (released 2009-08-14) ** libgnutls: Fix problem with NUL bytes in X.509 CN and SAN fields. By using a NUL byte in CN/SAN fields, it was possible to fool GnuTLS into 1) not printing the entire CN/SAN field value when printing a certificate and 2) cause incorrect positive matches when matching a hostname against a certificate. Some CAs apparently have poor checking of CN/SAN values and issue these (arguable invalid) certificates. Combined, this can be used by attackers to become a MITM on server-authenticated TLS sessions. The problem is mitigated since attackers needs to get one certificate per site they want to attack, and the attacker reveals his tracks by applying for a certificate at the CA. It does not apply to client authenticated TLS sessions. Research presented independently by Dan Kaminsky and Moxie Marlinspike at BlackHat09. Thanks to Tomas Hoger for providing one part of the patch. [GNUTLS-SA-2009-4] [CVE-2009-2730]. ** libgnutls: Fix rare failure in gnutls_x509_crt_import. The function may fail incorrectly when an earlier certificate was imported to the same gnutls_x509_crt_t structure. ** minitasn1: Internal copy updated to libtasn1 v2.3. ** libgnutls: Fix return value of gnutls_certificate_client_get_request_status. Before it always returned false. Reported by Peter Hendrickson in . ** libgnutls: Fix off-by-one size computation error in unknown DN printing. The error resulted in truncated strings when printing unknown OIDs in X.509 certificate DNs. Reported by Tim Kosse in . ** libgnutls: Fix PKCS#12 decryption from password. The encryption key derived from the password was incorrect for (on average) 1 in every 128 input for random inputs. Reported by "Kukosa, Tomas" in . ** libgnutls: Return correct bit lengths of some MPIs. gnutls_dh_get_prime_bits, gnutls_rsa_export_get_modulus_bits, and gnutls_dh_get_peers_public_bits. Before the reported value was overestimated. Reported by Peter Hendrickson in . ** libgnutls: Avoid internal error when invoked after GNUTLS_E_AGAIN. Report and patch by Tim Kosse in and . ** libgnutls: Relax checking of required libtasn1/libgcrypt versions. Before we required that the runtime library used the same (or more recent) libgcrypt/libtasn1 as it was compiled with. Now we just check that the runtime usage is above the minimum required. Reported by Marco d'Itri via Andreas Metzler in . ** tests: Added new self-test pkcs12_s2k_pem to detect MPI bit length error. ** tests: Improved test vectors in self-test pkcs12_s2k. ** tests: Added new self-test dn2 to detect off-by-one size error. ** tests: Fix failure in "chainverify" because a certificate have expired. ** API and ABI modifications: No changes since last version. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From jamie at canonical.com Fri Aug 14 23:35:38 2009 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 14 Aug 2009 16:35:38 -0500 Subject: GnuTLS CVE-2009-2730 Patches (Was Re: GnuTLS 2.8.2) In-Reply-To: <87skfupv8o.fsf@mocca.josefsson.org> References: <87k51bg4xb.fsf@mocca.josefsson.org> <1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon> <878whodnwa.fsf@mocca.josefsson.org> <1250237515.5919.1.camel@marathon> <87skfupv8o.fsf@mocca.josefsson.org> Message-ID: <20090814213538.GA3469@severus.strandboge.com> On Fri, 14 Aug 2009, Simon Josefsson wrote: > I don't have time/resources to produce releases for older branches. If > someone else wants to volunteer to work on fixing older releases, that > would be appreciated. > Attached are preliminary patches for 2.4.1, 2.0.4 and 1.2.9 backported from the advisory[1]. This is a first pass, have only been very lightly tested and have not been thoroughly looked at (you've been warned). They are not intended for production use yet, but hopefully others will be able to use them and provide feedback. 2.0.4 and 1.2.9 needed an additional patch[2] which adds wide wildcard hostname matching. Ubuntu will likely carry this patch, but it may not be appropriate for everyone. 2.x passes the nul-in-x509-names.c test mentioned in the advisory. 1.2.9 does not pass the CN test yet, though at first glance certtool output looks comparable to the others. These patches are against Ubuntu sources and not clean tarballs. Jamie [1] http://lists.gnu.org/archive/html/help-gnutls/2009-08/msg00011.html [2] http://git.savannah.gnu.org/cgit/gnutls.git/patch/?id=177e7ddb761999cd8b439e14a2bf43590756e230 -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: CVE-2009-2730_2.4.1.patch Type: text/x-diff Size: 8098 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CVE-2009-2730_2.0.4.patch Type: text/x-diff Size: 19482 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CVE-2009-2730_1.2.9.patch Type: text/x-diff Size: 7273 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From simon at josefsson.org Sat Aug 15 10:14:48 2009 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 15 Aug 2009 10:14:48 +0200 Subject: GnuTLS CVE-2009-2730 Patches In-Reply-To: <20090814213538.GA3469@severus.strandboge.com> (Jamie Strandboge's message of "Fri, 14 Aug 2009 16:35:38 -0500") References: <87k51bg4xb.fsf@mocca.josefsson.org> <1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon> <878whodnwa.fsf@mocca.josefsson.org> <1250237515.5919.1.camel@marathon> <87skfupv8o.fsf@mocca.josefsson.org> <20090814213538.GA3469@severus.strandboge.com> Message-ID: <87ws55mr2f.fsf@mocca.josefsson.org> Jamie Strandboge writes: > On Fri, 14 Aug 2009, Simon Josefsson wrote: > >> I don't have time/resources to produce releases for older branches. If >> someone else wants to volunteer to work on fixing older releases, that >> would be appreciated. >> > > Attached are preliminary patches for 2.4.1, 2.0.4 and 1.2.9 backported > from the advisory[1]. Thank you! I have applied the 2.4.x patch on the gnutls_2_4_x branch, so it will be built and tested by the daily autobuilder from now on. I've tested that the nul-in-x509-names self-test works as expected with the 2.4 library. So in theory, it should be easy for me to make a v2.4.4 release from that branch. I wonder if this would helps anyone, though? I'd imagine that most people concerned with older releases are distributions that have to support older GnuTLS releases. And you aren't likely to use a new upstream release anyway, since you just apply the patches to your version. I'm also concerned that there have been plenty of _other_ serious problems in these old GnuTLS releases (check the security vulnerability page), and I haven't back-ported the fixes to those problems to these old branches. So if I make a release on that branch, I'd have to check what other serious problems would needs to be fixed for that branch to be secure -- which sounds like real work (for little gain). For these two reasons, I'd prefer to help you establish trust in the patches you developed rather than make releases on old branches. I also added a link to your post on so others can find it easily. /Simon From simon at josefsson.org Mon Aug 17 15:58:44 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 17 Aug 2009 15:58:44 +0200 Subject: Buildreport for GnuTLS 2.8.3 In-Reply-To: <20090814140334.GA30319@ares.tgcnet> (Tom G. Christensen's message of "Fri, 14 Aug 2009 16:03:34 +0200") References: <20090814140334.GA30319@ares.tgcnet> Message-ID: <87k512k0dn.fsf@mocca.josefsson.org> "Tom G. Christensen" writes: > I grabbed GnuTLS 2.8.3 and tried building it on IRIX 5.3 and 6.2. > > It builds and passes the testsuite on IRIX 6.2. > However I'm still seeing these during the build: > In file included from ../gnutls_int.h:29, > from opencdk.h:30, > from main.c:36: > ../config.h:367:1: warning: "SIZE_MAX" redefined > In file included from ./../gl/stdlib.h:52, > from ./../gl/unistd.h:40, > from main.c:30: > ./../gl/stdint.h:473:1: warning: this is the location of the previous definition > > Bruno committed a fix for this to size_max.m4 when it was brought up on > bug-gnulib a few months ago but the copies included in gnutls are > too old and don't have the fix. I pushed the updated size_max.m4 file from gnulib into the gnutls_2_8_x branch. Please test tomorrow's daily snapshot to make sure it fixes your problem. I assume it is fixed in 2.9.x already. Thanks, /Simon From vivek at collabora.co.uk Mon Aug 17 17:55:17 2009 From: vivek at collabora.co.uk (Vivek Dasmohapatra) Date: Mon, 17 Aug 2009 16:55:17 +0100 (BST) Subject: gnutls_handshake fails after EAGAIN Message-ID: Hi, I've noticed a problem with gnutls_handshake when called with a non-blocking push/pull function pair: It looks to me like a bug in _gnutls_send_finished : full description and a proposed patch here: http://savannah.gnu.org/support/?106979 [ I didn't see this problem in the bug tracker, and the code in 2.8.x is the same as the code in 2.6.x, so I assume it's still iffy in the 2.8.x version ] Any chance this patch [assuming it's the right way to fix things] could be adopted? Apologies if this is a known issue and a fix is already on the way - In either case, what would the approximate timeline or the expected version number of a fixed library be? -- Vivek From tim.kosse at filezilla-project.org Mon Aug 17 18:52:32 2009 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Mon, 17 Aug 2009 18:52:32 +0200 Subject: gnutls_handshake fails after EAGAIN In-Reply-To: References: Message-ID: <4A898AD0.4040001@filezilla-project.org> Hi, Vivek Dasmohapatra wrote: > Hi, I've noticed a problem with gnutls_handshake when called with > a non-blocking push/pull function pair: [...] > http://savannah.gnu.org/support/?106979 this has actually been fixed in 2.8.2 already, I've stumbled upon the same problem recently. Both your patch as well as mine fix the problem, they change functionality the same way. References: http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3670 and http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=28fb34099edaf62e5472cc6e5e2749fed369ea01 Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From vivek at collabora.co.uk Mon Aug 17 19:38:05 2009 From: vivek at collabora.co.uk (Vivek Dasmohapatra) Date: Mon, 17 Aug 2009 18:38:05 +0100 (BST) Subject: gnutls_handshake fails after EAGAIN In-Reply-To: <4A898AD0.4040001@filezilla-project.org> References: <4A898AD0.4040001@filezilla-project.org> Message-ID: Ah, I see, yes, the calling function has been changed rather than the called function - did not spot that. Thanks. From jamie at canonical.com Tue Aug 18 01:29:45 2009 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 17 Aug 2009 18:29:45 -0500 Subject: GnuTLS CVE-2009-2730 Patches (Was Re: GnuTLS 2.8.2) In-Reply-To: <20090814213538.GA3469@severus.strandboge.com> References: <87k51bg4xb.fsf@mocca.josefsson.org> <1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon> <878whodnwa.fsf@mocca.josefsson.org> <1250237515.5919.1.camel@marathon> <87skfupv8o.fsf@mocca.josefsson.org> <20090814213538.GA3469@severus.strandboge.com> Message-ID: <20090817232945.GC6531@severus.strandboge.com> On Fri, 14 Aug 2009, Jamie Strandboge wrote: > 1.2.9 does not pass the CN test yet, though > at first glance certtool output looks comparable to the others. 1.2.9 also needed: http://git.savannah.gnu.org/cgit/gnutls.git/patch/?id=7b80620f99f4d43f5eda692eefc5c969bb4263c0 Attached is an updated patch for 1.2.9 (still only lightly tested, but verified to pass the test program). This and the 2.0.4 patch previously posted now behave the same, but different from 2.4 and higher. Specifically, when using: $ certtool -i --infile /tmp/badguy-nul-cn.crt We have: |<1>| Found OID: '2.5.4.3' with value '13187777772e62616e6b2e636f6d002e6261646775792e636f6d' X.509 Certificate Information: Version: 3 Serial Number (hex): 01 Issuer: C=GB,ST=Berkshire,L=Newbury,O=My Company Ltd,OU=CA,CN=NULL-friendly CA Validity: Not Before: Tue Aug 4 07:33:43 UTC 2009 Not After: Fri Aug 2 07:33:43 UTC 2019 error: get_dn: ASN1 parser: Error in DER parsing. ... This is in contrast to 2.4 and higher which has: X.509 Certificate Information: Version: 3 Serial Number (hex): 01 Issuer: C=GB,ST=Berkshire,L=Newbury,O=My Company Ltd,OU=CA,CN=NULL-friendly CA Validity: Not Before: Tue Aug 04 07:33:43 UTC 2009 Not After: Fri Aug 02 07:33:43 UTC 2019 Subject: CN=#13187777772e62616e6b2e636f6d002e6261646775792e636f6 ... Jamie -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: CVE-2009-2730_1.2.9.patch Type: text/x-diff Size: 7580 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From jamie at canonical.com Tue Aug 18 01:33:53 2009 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 17 Aug 2009 18:33:53 -0500 Subject: GnuTLS CVE-2009-2730 Patches In-Reply-To: <87ws55mr2f.fsf@mocca.josefsson.org> References: <87k51bg4xb.fsf@mocca.josefsson.org> <1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon> <878whodnwa.fsf@mocca.josefsson.org> <1250237515.5919.1.camel@marathon> <87skfupv8o.fsf@mocca.josefsson.org> <20090814213538.GA3469@severus.strandboge.com> <87ws55mr2f.fsf@mocca.josefsson.org> Message-ID: <20090817233353.GD6531@severus.strandboge.com> On Sat, 15 Aug 2009, Simon Josefsson wrote: > Jamie Strandboge writes: > > > On Fri, 14 Aug 2009, Simon Josefsson wrote: > > > > Attached are preliminary patches for 2.4.1, 2.0.4 and 1.2.9 backported > > from the advisory[1]. > > Thank you! > > I have applied the 2.4.x patch on the gnutls_2_4_x branch, so it will be > built and tested by the daily autobuilder from now on. I've tested that > the nul-in-x509-names self-test works as expected with the 2.4 library. > So in theory, it should be easy for me to make a v2.4.4 release from > that branch. I wonder if this would helps anyone, though? I'd imagine > that most people concerned with older releases are distributions that > have to support older GnuTLS releases. And you aren't likely to use a > new upstream release anyway, since you just apply the patches to your > version. > > I'm also concerned that there have been plenty of _other_ serious > problems in these old GnuTLS releases (check the security vulnerability > page), and I haven't back-ported the fixes to those problems to these > old branches. So if I make a release on that branch, I'd have to check > what other serious problems would needs to be fixed for that branch to > be secure -- which sounds like real work (for little gain). > > For these two reasons, I'd prefer to help you establish trust in the > patches you developed rather than make releases on old branches. > I'd agree with this. Vendors have likely backported all those other fixes. However, having a place for people to get patches for older releases would likely be beneficial going forward (like you are doing with this one). This is especially true when considering your aforementioned lack of resources. > I also added a link to your post on > so others can find it > easily. > Thanks! Jamie -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From simon at josefsson.org Tue Aug 18 14:52:48 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 18 Aug 2009 14:52:48 +0200 Subject: gnutls_handshake fails after EAGAIN In-Reply-To: (Vivek Dasmohapatra's message of "Mon, 17 Aug 2009 18:38:05 +0100 (BST)") References: <4A898AD0.4040001@filezilla-project.org> Message-ID: <87fxbpffmn.fsf@mocca.josefsson.org> Vivek Dasmohapatra writes: > Ah, I see, yes, the calling function has been changed rather than the > called function - did not spot that. Thanks. Good to see it solved -- I closed the bug tracker for this. Let me know if you think your patch is better, or if some other code improvement could be made here. /Simon From simon at josefsson.org Tue Aug 18 15:58:03 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 18 Aug 2009 15:58:03 +0200 Subject: GnuTLS CVE-2009-2730 Patches In-Reply-To: <20090817233353.GD6531@severus.strandboge.com> (Jamie Strandboge's message of "Mon, 17 Aug 2009 18:33:53 -0500") References: <87k51bg4xb.fsf@mocca.josefsson.org> <1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon> <878whodnwa.fsf@mocca.josefsson.org> <1250237515.5919.1.camel@marathon> <87skfupv8o.fsf@mocca.josefsson.org> <20090814213538.GA3469@severus.strandboge.com> <87ws55mr2f.fsf@mocca.josefsson.org> <20090817233353.GD6531@severus.strandboge.com> Message-ID: <87y6phdy1g.fsf@mocca.josefsson.org> Jamie Strandboge writes: > On Sat, 15 Aug 2009, Simon Josefsson wrote: > >> Jamie Strandboge writes: >> >> > On Fri, 14 Aug 2009, Simon Josefsson wrote: >> > >> > Attached are preliminary patches for 2.4.1, 2.0.4 and 1.2.9 backported >> > from the advisory[1]. >> >> Thank you! >> >> I have applied the 2.4.x patch on the gnutls_2_4_x branch, so it will be >> built and tested by the daily autobuilder from now on. I've tested that >> the nul-in-x509-names self-test works as expected with the 2.4 library. >> So in theory, it should be easy for me to make a v2.4.4 release from >> that branch. I wonder if this would helps anyone, though? I'd imagine >> that most people concerned with older releases are distributions that >> have to support older GnuTLS releases. And you aren't likely to use a >> new upstream release anyway, since you just apply the patches to your >> version. >> >> I'm also concerned that there have been plenty of _other_ serious >> problems in these old GnuTLS releases (check the security vulnerability >> page), and I haven't back-ported the fixes to those problems to these >> old branches. So if I make a release on that branch, I'd have to check >> what other serious problems would needs to be fixed for that branch to >> be secure -- which sounds like real work (for little gain). >> >> For these two reasons, I'd prefer to help you establish trust in the >> patches you developed rather than make releases on old branches. >> > > I'd agree with this. Vendors have likely backported all those other > fixes. However, having a place for people to get patches for older > releases would likely be beneficial going forward (like you are doing > with this one). This is especially true when considering your > aforementioned lack of resources. Right. If you and others provide patches for older versions, I can apply them on the git branches. Someone could even volunteer to become old-releases-maintainer and do it for me. It would indeed be useful if all vendors could look into the git repository to find the recommended patch for any version, rather than everyone having to spend time on identifying and testing patches by themselves. Alas, I don't have resources to do this, and I believe my time is best spent on maintaining the stable and development branches. /Simon From tgc at jupiterrise.com Tue Aug 18 21:26:23 2009 From: tgc at jupiterrise.com (Tom G. Christensen) Date: Tue, 18 Aug 2009 21:26:23 +0200 Subject: Buildreport for GnuTLS 2.8.3 In-Reply-To: <87k512k0dn.fsf@mocca.josefsson.org> References: <20090814140334.GA30319@ares.tgcnet> <87k512k0dn.fsf@mocca.josefsson.org> Message-ID: <20090818192623.GA5635@ares.tgcnet> On Mon, Aug 17, 2009 at 03:58:44PM +0200, Simon Josefsson wrote: > I pushed the updated size_max.m4 file from gnulib into the gnutls_2_8_x > branch. Please test tomorrow's daily snapshot to make sure it fixes > your problem. I assume it is fixed in 2.9.x already. > I built the daily snapshot but lib/m4/size_max.m4 is still downrev. The log was submitted to autobuild.josefsson.org. -tgc From simon at josefsson.org Tue Aug 18 23:45:47 2009 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 18 Aug 2009 23:45:47 +0200 Subject: [PATCH] session ticket support In-Reply-To: <87prb3i22u.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 11 Aug 2009 03:14:33 +0200") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <87ws5jkc62.fsf@mocca.josefsson.org> <87vdl2rfmt.fsf@broken.deisui.org> <87prbahee5.fsf@mocca.josefsson.org> <87k51hxvny.fsf@broken.deisui.org> <87d478trxd.fsf@mocca.josefsson.org> <363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org> <87prb3i22u.fsf@mocca.josefsson.org> Message-ID: <878whgdcdw.fsf@mocca.josefsson.org> Ueno-san, Your FSF papers have arrived so we should push your patch into the official repository. Do you have an updated patch, or should I use the last one you posted? Having more self-tests would be nice, but not essential. /Simon From simon at josefsson.org Wed Aug 19 00:11:38 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 19 Aug 2009 00:11:38 +0200 Subject: [PATCH][PULL] Add explicit feature checks In-Reply-To: <871vntrqa1.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon, 03 Aug 2009 15:16:38 +0200") References: <4A7470B8.1090909@x2a.org> <871vntrqa1.fsf@mocca.josefsson.org> Message-ID: <87r5v8bwmd.fsf@mocca.josefsson.org> Simon Josefsson writes: > Jonathan Bastien-Filiatrault writes: > >> As promised, I have added functions for explicit feature checks. > > Thank you. I'll apply as soon as the FSF copyright papers have arrived. > I'll review them when my 'git clone' finishes downloading your > repository... Hi! Your papers have arrived, so we should be able to push your patch now. Could you send a patch against master? Thanks, /Simon From joe at x2a.org Wed Aug 19 04:55:30 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Tue, 18 Aug 2009 22:55:30 -0400 Subject: [PATCH] Replace explicit version checks with feature checks Message-ID: <4A8B69A2.9010905@x2a.org> The following changes since commit 47cd212fda611873b72bf70df48b7de3563a3276: Jonathan Bastien-Filiatrault (1): Remove hardcoded version checks in auth_cert.c. are available in the git repository at: git://x2a.org/gnutls.git version-checks Alternatively, you may find the patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: version-checks.patch Type: text/x-diff Size: 9811 bytes Desc: not available URL: From ueno at unixuser.org Wed Aug 19 09:53:07 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Wed, 19 Aug 2009 16:53:07 +0900 Subject: [PATCH] session ticket support In-Reply-To: <878whgdcdw.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 18 Aug 2009 23:45:47 +0200") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <87ws5jkc62.fsf@mocca.josefsson.org> <87vdl2rfmt.fsf@broken.deisui.org> <87prbahee5.fsf@mocca.josefsson.org> <87k51hxvny.fsf@broken.deisui.org> <87d478trxd.fsf@mocca.josefsson.org> <363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org> <87prb3i22u.fsf@mocca.josefsson.org> <878whgdcdw.fsf@mocca.josefsson.org> Message-ID: <6c226b79-bdbf-4277-91c0-ead7ca6e67f2@broken.deisui.org> (Sorry, please ignore the previous incomplete message I've sent by mistake.) >>>>> In <878whgdcdw.fsf at mocca.josefsson.org> >>>>> Simon Josefsson wrote: > Your FSF papers have arrived so we should push your patch into the > official repository. Do you have an updated patch, or should I use the > last one you posted? Having more self-tests would be nice, but not > essential. Yes, please use the attached one. The following changes from the previous patch have been applied: * Support rehandshake when _gnutls_send_new_session_ticket() is interrupted. * Remove a bunch of compiler warnings when configured with --enable-gcc-warnings. * Add one of the self-tests as you suggested: > * What happens if the client has a session ticket but the server has > disabled session ticket support? However, the other one has not yet not implemented since I couldn't find an easy way to send arbitrary extension data from applications: > * What happens if the client provides a garbage session ticket? > > - Does the RFC specify what should happen? I'd assume that the > handshake continues as normal, but I'm not sure. It will be detected during MAC verification and reported as "decryption failed", and then the full-handshake should take place. -------------- next part -------------- A non-text attachment was scrubbed... Name: session-ticket-2009-08-19.diff.gz Type: application/octet-stream Size: 10748 bytes Desc: not available URL: -------------- next part -------------- Regards, -- Daiki Ueno From ueno at unixuser.org Wed Aug 19 09:34:47 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Wed, 19 Aug 2009 16:34:47 +0900 Subject: [PATCH] session ticket support In-Reply-To: <878whgdcdw.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 18 Aug 2009 23:45:47 +0200") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <87ws5jkc62.fsf@mocca.josefsson.org> <87vdl2rfmt.fsf@broken.deisui.org> <87prbahee5.fsf@mocca.josefsson.org> <87k51hxvny.fsf@broken.deisui.org> <87d478trxd.fsf@mocca.josefsson.org> <363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org> <87prb3i22u.fsf@mocca.josefsson.org> <878whgdcdw.fsf@mocca.josefsson.org> Message-ID: >>>>> In <878whgdcdw.fsf at mocca.josefsson.org> >>>>> Simon Josefsson wrote: > Your FSF papers have arrived so we should push your patch into the > official repository. Do you have an updated patch, or should I use the > last one you posted? Having more self-tests would be nice, but not > essential. Yes, please use the attached one. The following changes from the previous patch have been applied: * Support rehandshake when _gnutls_send_new_session_ticket() is interrupted. * Remove a bunch of compiler warnings when configured with --enable-gcc-warnings. * Add more self-tests for -- Daiki Ueno From ueno at unixuser.org Wed Aug 19 13:09:23 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Wed, 19 Aug 2009 20:09:23 +0900 Subject: [PATCH] internals doc update Message-ID: <6622c38a-26f5-4fe0-aaff-111352f98f8f@broken.deisui.org> Hi, When I wrote SessionTicket extension I referred to the manual node "Adding a New TLS Extension", and noticed that it is not up to date. So, here is a patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: internals-doc.diff Type: text/x-diff Size: 1462 bytes Desc: not available URL: -------------- next part -------------- Regards, -- Daiki Ueno From simon at josefsson.org Wed Aug 19 14:35:27 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 19 Aug 2009 14:35:27 +0200 Subject: [PATCH] internals doc update In-Reply-To: <6622c38a-26f5-4fe0-aaff-111352f98f8f@broken.deisui.org> (Daiki Ueno's message of "Wed, 19 Aug 2009 20:09:23 +0900") References: <6622c38a-26f5-4fe0-aaff-111352f98f8f@broken.deisui.org> Message-ID: <87tz047zhs.fsf@mocca.josefsson.org> Daiki Ueno writes: > Hi, > > When I wrote SessionTicket extension I referred to the manual node > "Adding a New TLS Extension", and noticed that it is not up to date. > So, here is a patch. Hi. Thank you, pushed. /Simon From simon at josefsson.org Wed Aug 19 15:13:55 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 19 Aug 2009 15:13:55 +0200 Subject: [PATCH] session ticket support In-Reply-To: <6c226b79-bdbf-4277-91c0-ead7ca6e67f2@broken.deisui.org> (Daiki Ueno's message of "Wed, 19 Aug 2009 16:53:07 +0900") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <87ws5jkc62.fsf@mocca.josefsson.org> <87vdl2rfmt.fsf@broken.deisui.org> <87prbahee5.fsf@mocca.josefsson.org> <87k51hxvny.fsf@broken.deisui.org> <87d478trxd.fsf@mocca.josefsson.org> <363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org> <87prb3i22u.fsf@mocca.josefsson.org> <878whgdcdw.fsf@mocca.josefsson.org> <6c226b79-bdbf-4277-91c0-ead7ca6e67f2@broken.deisui.org> Message-ID: <87pras7xpo.fsf@mocca.josefsson.org> Daiki Ueno writes: > Yes, please use the attached one. Thank you! I fixed a few minor issues and pushed it. /Simon From simon at josefsson.org Wed Aug 19 16:04:48 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 19 Aug 2009 16:04:48 +0200 Subject: [PATCH] Replace explicit version checks with feature checks In-Reply-To: <4A8B69A2.9010905@x2a.org> (Jonathan Bastien-Filiatrault's message of "Tue, 18 Aug 2009 22:55:30 -0400") References: <4A8B69A2.9010905@x2a.org> Message-ID: <8763cj99xb.fsf@mocca.josefsson.org> Hi Jonathan. Thank you, I have pushed the patch. /Simon From joe at x2a.org Wed Aug 19 17:35:36 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Wed, 19 Aug 2009 11:35:36 -0400 Subject: [PATCH] Replace explicit version checks with feature checks In-Reply-To: <8763cj99xb.fsf@mocca.josefsson.org> References: <4A8B69A2.9010905@x2a.org> <8763cj99xb.fsf@mocca.josefsson.org> Message-ID: <4A8C1BC8.6070901@x2a.org> Simon Josefsson wrote: > Hi Jonathan. Thank you, I have pushed the patch. > > /Simon Yay ! Thanks ! Could you please have a look at my buffers-redux branch. So far it seems to suit Nikos. I have taken care of most of the send path, discarding old code with much shorter and simpler new code (and adding a bunch of generic code). The read path is next and I would like to finalize the write side as much as possible. Also, I would like to remove the need to peek data from sockets. This complicates the read side by an order of magnitude. Is this because there is no other way to notify the application to do another read (via select) ? http://x2a.org/git/gnutls/log/?h=buffers-redux git://x2a.org/gnutls.git buffers-redux Thanks ! From vivek at collabora.co.uk Wed Aug 19 18:12:50 2009 From: vivek at collabora.co.uk (Vivek Dasmohapatra) Date: Wed, 19 Aug 2009 17:12:50 +0100 (BST) Subject: gnutls_handshake fails after EAGAIN In-Reply-To: <87fxbpffmn.fsf@mocca.josefsson.org> References: <4A898AD0.4040001@filezilla-project.org> <87fxbpffmn.fsf@mocca.josefsson.org> Message-ID: On Tue, 18 Aug 2009, Simon Josefsson wrote: > Good to see it solved -- I closed the bug tracker for this. Let me know > if you think your patch is better, or if some other code improvement > could be made here. I don't think there's much to choose between them: it's a static function called only from one place, so it doesn't matter much whether the change is made in the caller or the callee. Probably worth checking that other functions with a similar calling convention (once with data, then with NULL for each EAGAIN) are also handled suitably, since it's an easy mistake to make, and won't be picked up if the tests use blocking push-pull functions. From tim.kosse at filezilla-project.org Wed Aug 19 18:40:28 2009 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Wed, 19 Aug 2009 18:40:28 +0200 Subject: gnutls_handshake fails after EAGAIN In-Reply-To: References: <4A898AD0.4040001@filezilla-project.org> <87fxbpffmn.fsf@mocca.josefsson.org> Message-ID: <4A8C2AFC.9020009@filezilla-project.org> Hi, Vivek Dasmohapatra wrote: > Probably worth checking that other functions with a similar calling > convention (once with data, then with NULL for each EAGAIN) are also > handled suitably, since it's an easy mistake to make, and won't be picked > up if the tests use blocking push-pull functions. actually there has been another bug in 2.8.0 and 2.8.1 which was also triggered when the push function returned EAGAIN: http://lists.gnu.org/archive/html/gnutls-devel/2009-06/msg00022.html http://lists.gnu.org/archive/html/gnutls-devel/2009-07/msg00000.html The fix is in http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=c7e003ad9427c655a1b559baff1239a2c1907f32 The GnuTLS developers also added a test case that should hopefully detect future problems like this, see tests/mini-eagain.c Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From simon at josefsson.org Wed Aug 19 22:49:36 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 19 Aug 2009 22:49:36 +0200 Subject: [PATCH] Replace explicit version checks with feature checks In-Reply-To: <4A8C1BC8.6070901@x2a.org> (Jonathan Bastien-Filiatrault's message of "Wed, 19 Aug 2009 11:35:36 -0400") References: <4A8B69A2.9010905@x2a.org> <8763cj99xb.fsf@mocca.josefsson.org> <4A8C1BC8.6070901@x2a.org> Message-ID: <87fxbn5y1r.fsf@mocca.josefsson.org> Jonathan Bastien-Filiatrault writes: > Simon Josefsson wrote: >> Hi Jonathan. Thank you, I have pushed the patch. >> >> /Simon > > Yay ! Thanks ! > > Could you please have a look at my buffers-redux branch. So far it > seems to suit Nikos. I have taken care of most of the send path, > discarding old code with much shorter and simpler new code (and adding > a bunch of generic code). > > The read path is next and I would like to finalize the write side as > much as possible. Also, I would like to remove the need to peek data > from sockets. This complicates the read side by an order of > magnitude. Is this because there is no other way to notify the > application to do another read (via select) ? > > http://x2a.org/git/gnutls/log/?h=buffers-redux > git://x2a.org/gnutls.git buffers-redux How do I create a patch between your branch and master, to review it? I haven't worked with multiple repositories, but willing to learn. /Simon From simon at josefsson.org Wed Aug 19 23:30:40 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 19 Aug 2009 23:30:40 +0200 Subject: GnuTLS 2.9.3 Message-ID: <87tz034hkv.fsf@mocca.josefsson.org> The GnuTLS 2.9.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. Here are the compressed sources (6.0MB): http://alpha.gnu.org/gnu/gnutls/gnutls-2.9.3.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.9.3.tar.bz2 Here is the OpenPGP signature: http://alpha.gnu.org/gnu/gnutls/gnutls-2.9.3.tar.bz2.sig ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.9.3.tar.bz2.sig Windows build: http://josefsson.org/gnutls4win/gnutls-2.9.3.exe http://josefsson.org/gnutls4win/gnutls-2.9.3.exe.sig http://josefsson.org/gnutls4win/gnutls-2.9.3.zip http://josefsson.org/gnutls4win/gnutls-2.9.3.zip.sig http://josefsson.org/gnutls4win/mingw32-gnutls_2.9.3-1_all.deb Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. /Simon * Version 2.9.3 (released 2009-08-19) ** libgnutls: Support for TLS tickets was contributed by Daiki Ueno. The new APIs are gnutls_session_ticket_enable_client, gnutls_session_ticket_enable_server, and gnutls_session_ticket_key_generate. ** gnutls-cli, gnutls-serv: New parameter --noticket to disable TLS tickets. ** API and ABI modifications: gnutls_session_ticket_key_generate: ADDED. gnutls_session_ticket_enable_client: ADDED. gnutls_session_ticket_enable_server: ADDED. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Thu Aug 20 00:07:54 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 20 Aug 2009 00:07:54 +0200 Subject: Buildreport for GnuTLS 2.8.3 In-Reply-To: <20090818192623.GA5635@ares.tgcnet> (Tom G. Christensen's message of "Tue, 18 Aug 2009 21:26:23 +0200") References: <20090814140334.GA30319@ares.tgcnet> <87k512k0dn.fsf@mocca.josefsson.org> <20090818192623.GA5635@ares.tgcnet> Message-ID: <87my5v4fut.fsf@mocca.josefsson.org> "Tom G. Christensen" writes: > On Mon, Aug 17, 2009 at 03:58:44PM +0200, Simon Josefsson wrote: >> I pushed the updated size_max.m4 file from gnulib into the gnutls_2_8_x >> branch. Please test tomorrow's daily snapshot to make sure it fixes >> your problem. I assume it is fixed in 2.9.x already. >> > I built the daily snapshot but lib/m4/size_max.m4 is still downrev. > > The log was submitted to autobuild.josefsson.org. Could you check if the size_max.m4 files in your build have 'serial 9' in the first line? Maybe you tested before the packages was updated. You could test the 2.9.3 release now. It seems that either Bruno's solution didn't work, or something else needs to be back-ported as well, but I'm not sure what. /Simon From ueno at unixuser.org Thu Aug 20 03:33:00 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Thu, 20 Aug 2009 10:33:00 +0900 Subject: GnuTLS 2.9.3 In-Reply-To: <87tz034hkv.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 19 Aug 2009 23:30:40 +0200") References: <87tz034hkv.fsf@mocca.josefsson.org> Message-ID: >>>>> In <87tz034hkv.fsf at mocca.josefsson.org> >>>>> Simon Josefsson wrote: > * Version 2.9.3 (released 2009-08-19) > ** libgnutls: Support for TLS tickets was contributed by Daiki Ueno. Thanks for the new release! Now I run make check and found several memleaks. One is in cdk_keydb_get_pk, and others are in tests (including session ticket test...sorry). Here is a patch to fix them. -------------- next part -------------- A non-text attachment was scrubbed... Name: tests-memleak.diff Type: text/x-diff Size: 2126 bytes Desc: not available URL: -------------- next part -------------- Regards, -- Daiki Ueno From simon at josefsson.org Thu Aug 20 10:05:26 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 20 Aug 2009 10:05:26 +0200 Subject: GnuTLS 2.9.3 In-Reply-To: (Daiki Ueno's message of "Thu, 20 Aug 2009 10:33:00 +0900") References: <87tz034hkv.fsf@mocca.josefsson.org> Message-ID: <87ws4y3o6x.fsf@mocca.josefsson.org> Daiki Ueno writes: >>>>>> In <87tz034hkv.fsf at mocca.josefsson.org> >>>>>> Simon Josefsson wrote: >> * Version 2.9.3 (released 2009-08-19) > >> ** libgnutls: Support for TLS tickets was contributed by Daiki Ueno. > > Thanks for the new release! > > Now I run make check and found several memleaks. One is in > cdk_keydb_get_pk, and others are in tests (including session ticket > test...sorry). > > Here is a patch to fix them. Applied, thank you. /Simon From simon at josefsson.org Thu Aug 20 16:18:46 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 20 Aug 2009 16:18:46 +0200 Subject: GnuTLS CVE-2009-2730 Patches In-Reply-To: <20090820123918.GA6964@severus.strandboge.com> (Jamie Strandboge's message of "Thu, 20 Aug 2009 07:39:18 -0500") References: <87k51bg4xb.fsf@mocca.josefsson.org> <1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon> <878whodnwa.fsf@mocca.josefsson.org> <1250237515.5919.1.camel@marathon> <87skfupv8o.fsf@mocca.josefsson.org> <20090814213538.GA3469@severus.strandboge.com> <87ws55mr2f.fsf@mocca.josefsson.org> <20090817233353.GD6531@severus.strandboge.com> <87y6phdy1g.fsf@mocca.josefsson.org> <20090820123918.GA6964@severus.strandboge.com> Message-ID: <87r5v6y3eh.fsf@mocca.josefsson.org> Btw, I just notice a problem with RedHat's patch, it appears to break OpenPGP connections: gnutls-cli -p 5556 test.gnutls.org --priority NORMAL:+CTYPE-OPENPGP:-CTYPE-X509 I get an error: - The hostname in the certificate does NOT match 'test.gnutls.org' But this is incorrect, the names do match. Please test if that command works on your versions, otherwise you will need this patch too: http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=9eed44b4ef9538117cc134956b32bc8fd39534fd I'll write a self-test to check this regression too. /Simon From simon at josefsson.org Thu Aug 20 19:03:23 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 20 Aug 2009 19:03:23 +0200 Subject: GnuTLS CVE-2009-2730 Patches In-Reply-To: <87r5v6y3eh.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Thu, 20 Aug 2009 16:18:46 +0200") References: <87k51bg4xb.fsf@mocca.josefsson.org> <1250066631.3868.8.camel@marathon> <1250130999.4606.1.camel@marathon> <878whodnwa.fsf@mocca.josefsson.org> <1250237515.5919.1.camel@marathon> <87skfupv8o.fsf@mocca.josefsson.org> <20090814213538.GA3469@severus.strandboge.com> <87ws55mr2f.fsf@mocca.josefsson.org> <20090817233353.GD6531@severus.strandboge.com> <87y6phdy1g.fsf@mocca.josefsson.org> <20090820123918.GA6964@severus.strandboge.com> <87r5v6y3eh.fsf@mocca.josefsson.org> Message-ID: <87r5v6v2n8.fsf@mocca.josefsson.org> Simon Josefsson writes: > Btw, I just notice a problem with RedHat's patch, it appears to break > OpenPGP connections: > > gnutls-cli -p 5556 test.gnutls.org --priority NORMAL:+CTYPE-OPENPGP:-CTYPE-X509 > > I get an error: > > - The hostname in the certificate does NOT match 'test.gnutls.org' > > But this is incorrect, the names do match. > > Please test if that command works on your versions, otherwise you will > need this patch too: > > http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=9eed44b4ef9538117cc134956b32bc8fd39534fd > > I'll write a self-test to check this regression too. Now finished, and here is another way to check if your library is OK or not: wget http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/hostname-check.c wget http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/utils.c wget http://git.savannah.gnu.org/cgit/gnutls.git/plain/tests/utils.h gcc -o hostname-check hostname-check.c utils.c -I. -lgnutls ./hostname-check It should finish with 0 errors. Maybe we'll need a 2.8.4 to fix this... /Simon From joe at x2a.org Fri Aug 21 02:19:08 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Thu, 20 Aug 2009 20:19:08 -0400 Subject: [PATCH] Replace explicit version checks with feature checks In-Reply-To: <87fxbn5y1r.fsf@mocca.josefsson.org> References: <4A8B69A2.9010905@x2a.org> <8763cj99xb.fsf@mocca.josefsson.org> <4A8C1BC8.6070901@x2a.org> <87fxbn5y1r.fsf@mocca.josefsson.org> Message-ID: <4A8DE7FC.5030405@x2a.org> Simon Josefsson wrote: > Jonathan Bastien-Filiatrault writes: > >> Simon Josefsson wrote: > How do I create a patch between your branch and master, to review it? I > haven't worked with multiple repositories, but willing to learn. > > /Simon Alright, here is what you need to do: - Use a somewhat-pristine git repository cloned from savannah or whatever. - Add a remote: git remote add -f jonathan git://x2a.org/gnutls.git ; this adds an entry in the .git/config file and fetches refs and objects from my repository. - Create a local branch tracking my remote repository: git branch --track buffers-redux jonathan/buffers-redux - Now you can git checkout buffers-redux to switch to that branch or do a git diff master..buffers-redux . If you had not created a local branch you could instead do git diff master..jonathan/buffers-redux Hope this helps, Jonathan From simon at josefsson.org Fri Aug 21 10:34:18 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 21 Aug 2009 10:34:18 +0200 Subject: [PATCH] Replace explicit version checks with feature checks In-Reply-To: <4A8DE7FC.5030405@x2a.org> (Jonathan Bastien-Filiatrault's message of "Thu, 20 Aug 2009 20:19:08 -0400") References: <4A8B69A2.9010905@x2a.org> <8763cj99xb.fsf@mocca.josefsson.org> <4A8C1BC8.6070901@x2a.org> <87fxbn5y1r.fsf@mocca.josefsson.org> <4A8DE7FC.5030405@x2a.org> Message-ID: <8763chtvjp.fsf@mocca.josefsson.org> Jonathan Bastien-Filiatrault writes: > Simon Josefsson wrote: >> Jonathan Bastien-Filiatrault writes: >> >>> Simon Josefsson wrote: >> How do I create a patch between your branch and master, to review it? I >> haven't worked with multiple repositories, but willing to learn. >> >> /Simon > > Alright, here is what you need to do: > > - Use a somewhat-pristine git repository cloned from savannah or whatever. > - Add a remote: git remote add -f jonathan git://x2a.org/gnutls.git ; > this adds an entry in the .git/config file and fetches refs and objects > from my repository. > - Create a local branch tracking my remote repository: git branch > --track buffers-redux jonathan/buffers-redux > - Now you can git checkout buffers-redux to switch to that branch or do > a git diff master..buffers-redux . If you had not created a local branch > you could instead do git diff master..jonathan/buffers-redux Excellent, thank you! Quick comments: * Please add a comment describing what dump_bytes does, and preferrably make it use _gnutls_bin2hex for hex encoding. Is there a fixed-size limit of 128 in the function? If so, it would be nice to fix that. * What does the 'bufel' variable name refers to? It looks non-english to me, so I'd prefer using 'buf'. * Some comments at the top of gnutls_mbuffers.? what it does would be good. More later. /Simon From gareuselesinge at libero.it Fri Aug 21 11:55:36 2009 From: gareuselesinge at libero.it (Enrico Tassi) Date: Fri, 21 Aug 2009 11:55:36 +0200 Subject: Help with multithreading Message-ID: <20090821095536.GA6248@birba> I'm facing a problem that seems to be related to the multithreading aspect of gnutls+curl, but digging the mailing list was not enough to find an answer, so I'm posting hoping someone has some hints for me. This is the way I initialize gcrypt/gnutls, and I'm doing it at the very beginning of the main() function: if (!gcry_control (GCRYCTL_ANY_INITIALIZATION_P)) { /* No other library has already initialized libgcrypt. */ if (!gcry_check_version("1.2.2")) { fprintf(stderr, "gcrypt version older than 1.2.2\n"); exit(1); } gcry_control(GCRYCTL_SET_THREAD_CBS,&gcry_threads_pthread); gcry_control (GCRYCTL_DISABLE_SECMEM, 0); gcry_control (GCRYCTL_INITIALIZATION_FINISHED); } According to the mailing list, this should be correct. After that I call the cURL initialization function (that is compiled against gnutls). curl_global_init(CURL_GLOBAL_ALL); Here is the gdb backtrace, that seems to suggest there is something wrong with threads (there were 2 threads, doing exactly the same, i.e. opening an SSL connection). This is the backtrace of the thread that issued the assertion failure: (gdb) core-file core [New Thread 9930] [New Thread 9932] warning: Can't read pathname for load map: Input/output error. Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /usr/lib/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib/libcrypto.so.0.9.8 Reading symbols from /usr/lib/libcurl-gnutls.so.4...Reading symbols from /usr/lib/debug/usr/lib/libcurl-gnutls.so.4.1.1...done. done. Loaded symbols for /usr/lib/libcurl-gnutls.so.4 Reading symbols from /usr/lib/libexpat.so.1...done. Loaded symbols for /usr/lib/libexpat.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/lib/libidn.so.11...done. Loaded symbols for /usr/lib/libidn.so.11 Reading symbols from /usr/lib/liblber-2.4.so.2...done. Loaded symbols for /usr/lib/liblber-2.4.so.2 Reading symbols from /usr/lib/libldap_r-2.4.so.2...done. Loaded symbols for /usr/lib/libldap_r-2.4.so.2 Reading symbols from /lib/librt.so.1...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /usr/lib/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libgnutls.so.26...Reading symbols from /usr/lib/debug/usr/lib/libgnutls.so.26.14.10...done. done. Loaded symbols for /usr/lib/libgnutls.so.26 Reading symbols from /usr/lib/libgcrypt.so.11...Reading symbols from /usr/lib/debug/usr/lib/libgcrypt.so.11.5.2...done. done. Loaded symbols for /usr/lib/libgcrypt.so.11 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /usr/lib/libkrb5.so.3...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /usr/lib/libk5crypto.so.3...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libkrb5support.so.0...done. Loaded symbols for /usr/lib/libkrb5support.so.0 Reading symbols from /lib/libkeyutils.so.1...done. Loaded symbols for /lib/libkeyutils.so.1 Reading symbols from /usr/lib/libtasn1.so.3...done. Loaded symbols for /usr/lib/libtasn1.so.3 Reading symbols from /usr/lib/libgpg-error.so.0...done. Loaded symbols for /usr/lib/libgpg-error.so.0 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_mdns4_minimal.so.2...done. Loaded symbols for /lib/libnss_mdns4_minimal.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 Core was generated by `freepopsd -w'. Program terminated with signal 6, Aborted. #0 0x00007f3864238d25 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00007f3864238d25 in raise () from /lib/libc.so.6 #1 0x00007f386423bde1 in abort () from /lib/libc.so.6 #2 0x00007f3864231f99 in __assert_fail () from /lib/libc.so.6 #3 0x00007f3863024ecb in _gcry_ath_mutex_lock (lock=0x7f3863289390) at ath.c:193 #4 0x00007f38630300af in md_digest_length (algorithm=1) at md.c:1070 #5 0x00007f38632c968f in wrap_gcry_mac_output (src_ctx=0x2787110, digest=0x7f3861cd87f0, digestsize=16) at mac-libgcrypt.c:150 #6 0x00007f38632aeeb9 in _gnutls_hash_deinit (handle=0x26ca, digest=0x26cb) at gnutls_hash_int.c:168 #7 0x00007f38632a6afd in _gnutls_finished (session=0x277f8d0, type=2, ret=0x7f3861cd8860) at gnutls_handshake.c:231 #8 0x00007f38632a90c1 in _gnutls_send_finished (session=0x277f8d0, init=) at gnutls_handshake.c:560 #9 _gnutls_send_handshake_final (session=0x277f8d0, init=) at gnutls_handshake.c:2489 #10 0x00007f38632a9315 in _gnutls_handshake_common (session=0x277f8d0) at gnutls_handshake.c:2693 #11 0x00007f38632aa9f2 in gnutls_handshake (session=0x277f8d0) at gnutls_handshake.c:2297 #12 0x00007f38647b0860 in handshake () from /usr/lib/libcurl-gnutls.so.4 #13 0x00007f38647b0ed6 in Curl_gtls_connect () from /usr/lib/libcurl-gnutls.so.4 #14 0x00007f38647b1e60 in Curl_ssl_connect () from /usr/lib/libcurl-gnutls.so.4 #15 0x00007f3864790e2c in Curl_http_connect () from /usr/lib/libcurl-gnutls.so.4 #16 0x00007f3864797072 in Curl_protocol_connect () from /usr/lib/libcurl-gnutls.so.4 #17 0x00007f3864799e24 in Curl_connect () from /usr/lib/libcurl-gnutls.so.4 #18 0x00007f38647a551b in Curl_perform () from /usr/lib/libcurl-gnutls.so.4 #19 0x000000000040fdc6 in luacurl_easy_perform (L=0x23f6660) at lua-curl.c:509 #20 0x0000000000424296 in luaD_precall (L=0x23f6660, func=0x24e3640, nresults=2) at ldo.c:319 #21 0x000000000042d991 in luaV_execute (L=0x23f6660, nexeccalls=5) at lvm.c:587 ---Type to continue, or q to quit--- #22 0x0000000000424805 in luaD_call (L=0x23f6660, func=0x2430cf0, nResults=1) at ldo.c:377 #23 0x0000000000423ea7 in luaD_rawrunprotected (L=0x23f6660, f=0x4218e0 , ud=0x7f3861cd8f10) at ldo.c:116 #24 0x0000000000423f25 in luaD_pcall (L=0x26ca, func=0x26cb, u=0x6, old_top=-1, ef=41385872) at ldo.c:461 #25 0x0000000000421722 in lua_pcall (L=0x23f6660, nargs=2, nresults=1, errfunc=) at lapi.c:817 #26 0x00000000004205d1 in luay_call (s=0x23f6660, args=0x43acee "ps|d", funcname=0x43ace9 "pass") at luay.c:282 #27 0x000000000040a9e2 in freepops_pass (p=0x23f6490, password=0x7f3861cd98e0 "ndr") at engine.c:259 #28 0x0000000000414026 in pop3_POPSTATE_AUTH (data=) at popserver.c:454 #29 pop3_thread (data=) at popserver.c:785 #30 0x00007f3864d67f9a in start_thread () from /lib/libpthread.so.0 #31 0x00007f38642d356d in clone () from /lib/libc.so.6 #32 0x0000000000000000 in ?? () (gdb) quit While this other thread was (sleeping?) in a poll syscall: #0 0x00007f38642cad36 in poll () from /lib/libc.so.6 #1 0x00007f38647b0286 in Curl_socket_ready () from /usr/lib/libcurl-gnutls.so.4 #2 0x00007f38647b08b6 in handshake () from /usr/lib/libcurl-gnutls.so.4 #3 0x00007f38647b0ed6 in Curl_gtls_connect () from /usr/lib/libcurl-gnutls.so.4 #4 0x00007f38647b1e60 in Curl_ssl_connect () from /usr/lib/libcurl-gnutls.so.4 #5 0x00007f3864790e2c in Curl_http_connect () from /usr/lib/libcurl-gnutls.so.4 #6 0x00007f3864797072 in Curl_protocol_connect () from /usr/lib/libcurl-gnutls.so.4 #7 0x00007f3864799e24 in Curl_connect () from /usr/lib/libcurl-gnutls.so.4 #8 0x00007f38647a551b in Curl_perform () from /usr/lib/libcurl-gnutls.so.4 #9 0x000000000040fdc6 in luacurl_easy_perform (L=0x2444870) at lua-curl.c:509 #10 0x0000000000424296 in luaD_precall (L=0x2444870, func=0x24f0b10, nresults=2) at ldo.c:319 #11 0x000000000042d991 in luaV_execute (L=0x2444870, nexeccalls=5) at lvm.c:587 #12 0x0000000000424805 in luaD_call (L=0x2444870, func=0x247f2b0, nResults=1) at ldo.c:377 #13 0x0000000000423ea7 in luaD_rawrunprotected (L=0x2444870, f=0x4218e0 , ud=0x7f38614d7f10) at ldo.c:116 #14 0x0000000000423f25 in luaD_pcall (L=0x7f38614d78c0, func=0x2, u=0x49282, old_top=-1, ef=0) at ldo.c:461 #15 0x0000000000421722 in lua_pcall (L=0x2444870, nargs=2, nresults=1, errfunc=) at lapi.c:817 #16 0x00000000004205d1 in luay_call (s=0x2444870, args=0x43acee "ps|d", funcname=0x43ace9 "pass") at luay.c:282 #17 0x000000000040a9e2 in freepops_pass (p=0x2444470, password=0x7f38614d88e0 "emc2") at engine.c:259 #18 0x0000000000414026 in pop3_POPSTATE_AUTH (data=) at popserver.c:454 #19 pop3_thread (data=) at popserver.c:785 #20 0x00007f3864d67f9a in start_thread () from /lib/libpthread.so.0 #21 0x00007f38642d356d in clone () from /lib/libc.so.6 Thanks in advance -- Enrico Tassi From xizhi.zhu at gmail.com Thu Aug 20 13:15:31 2009 From: xizhi.zhu at gmail.com (Xizhi Zhu) Date: Thu, 20 Aug 2009 14:15:31 +0300 Subject: Why not SHA256 in cipher suite? Message-ID: <20090820141531.29f9fba5@zhu-laptop> Hi, I found that in GnuTLS, SHA256 is not used in any cipher suites (i.e. not listed in gnutls-cli -l). However, they are defined in RFC 5246, e.g. TLS_RSA_WITH_AES_128_CBC_SHA256 (0x00,0x3C). I wonder why they are not supported in GnuTLS as they can provide a higher security level. Thanks for your answers! Regards, Xizhi From tgc at jupiterrise.com Fri Aug 21 17:55:46 2009 From: tgc at jupiterrise.com (Tom G. Christensen) Date: Fri, 21 Aug 2009 17:55:46 +0200 Subject: Buildreport for GnuTLS 2.8.3 In-Reply-To: <87my5v4fut.fsf@mocca.josefsson.org> References: <20090814140334.GA30319@ares.tgcnet> <87k512k0dn.fsf@mocca.josefsson.org> <20090818192623.GA5635@ares.tgcnet> <87my5v4fut.fsf@mocca.josefsson.org> Message-ID: <20090821155546.GA14150@ares.tgcnet> On Thu, Aug 20, 2009 at 12:07:54AM +0200, Simon Josefsson wrote: > Could you check if the size_max.m4 files in your build have 'serial 9' > in the first line? Maybe you tested before the packages was updated. > You could test the 2.9.3 release now. > I was initially using your daily-build script but then I noticed that the gnutls snapshot has not been updated since Aug 13th. $ sha1sum ../gnutls-2.9.3.tar.bz2 6e7157274df5c95984fd52c4d500a414a67b9d44 ../gnutls-2.9.3.tar.bz2 [gnutls-2.9.3]$ find . -name 'size_max.m4' | xargs head -1 ==> ./gl/m4/size_max.m4 <== # size_max.m4 serial 9 ==> ./lib/m4/size_max.m4 <== # size_max.m4 serial 6 Brunos fix should be fine, I see the toplevel config.h correctly guarding the define with an ifndef SIZE_MAX. -tgc From joe at x2a.org Sat Aug 22 20:31:33 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Sat, 22 Aug 2009 14:31:33 -0400 Subject: [PATCH] Replace explicit version checks with feature checks In-Reply-To: <8763chtvjp.fsf@mocca.josefsson.org> References: <4A8B69A2.9010905@x2a.org> <8763cj99xb.fsf@mocca.josefsson.org> <4A8C1BC8.6070901@x2a.org> <87fxbn5y1r.fsf@mocca.josefsson.org> <4A8DE7FC.5030405@x2a.org> <8763chtvjp.fsf@mocca.josefsson.org> Message-ID: <4A903985.6090807@x2a.org> Simon Josefsson wrote: > Jonathan Bastien-Filiatrault writes: > >> Simon Josefsson wrote: >>> Jonathan Bastien-Filiatrault writes: >>> >>>> Simon Josefsson wrote: >>> How do I create a patch between your branch and master, to review it? I >>> haven't worked with multiple repositories, but willing to learn. >>> >>> /Simon >> Alright, here is what you need to do: >> >> - Use a somewhat-pristine git repository cloned from savannah or whatever. >> - Add a remote: git remote add -f jonathan git://x2a.org/gnutls.git ; >> this adds an entry in the .git/config file and fetches refs and objects >> from my repository. >> - Create a local branch tracking my remote repository: git branch >> --track buffers-redux jonathan/buffers-redux >> - Now you can git checkout buffers-redux to switch to that branch or do >> a git diff master..buffers-redux . If you had not created a local branch >> you could instead do git diff master..jonathan/buffers-redux > > Excellent, thank you! > > Quick comments: > > * Please add a comment describing what dump_bytes does, and preferrably > make it use _gnutls_bin2hex for hex encoding. Is there a fixed-size > limit of 128 in the function? If so, it would be nice to fix that. I was not aware of the existence of the _gnutls_bin2hex function. The fixed buffers in dump_bytes are emptied at the end of each line and their maximum size is bounded by the number of bytes per line (16), so it could in theory print 256^sizeof(size_t) bytes. I will fix gnutls_buffers.c to use _gnutls_bin2hex. > * What does the 'bufel' variable name refers to? It looks non-english > to me, so I'd prefer using 'buf'. A mbuffer is a chain of buffer elements. I use buf to refer to the whole chain of buffers (mbuffer_head_st) and bufel to refer to a buffer element (mbuffer_st). I don't mind changing the variable names if they really bother you. > * Some comments at the top of gnutls_mbuffers.? what it does would be > good. Sure, I can do that. I was planning on adding those comments later on anyway. > More later. I'll be waiting. > > /Simon Thanks ! From nmav at gnutls.org Sun Aug 23 20:28:06 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 23 Aug 2009 21:28:06 +0300 Subject: Help with multithreading In-Reply-To: <20090821095536.GA6248@birba> References: <20090821095536.GA6248@birba> Message-ID: <4A918A36.4090304@gnutls.org> Enrico Tassi wrote: > I'm facing a problem that seems to be related to the multithreading > aspect of gnutls+curl, but digging the mailing list was not enough to > find an answer, so I'm posting hoping someone has some hints for me. > > This is the way I initialize gcrypt/gnutls, and I'm doing it at the very > beginning of the main() function: I'd suggest against doing the full initialization of libgcrypt and allowing gnutls to do it. If you do what the manual says do you have the same issue? http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applications.html#Multi_002dthreaded-applications regards, Nikos From simon at josefsson.org Mon Aug 24 23:06:18 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 24 Aug 2009 23:06:18 +0200 Subject: Buildreport for GnuTLS 2.8.3 In-Reply-To: <20090821155546.GA14150@ares.tgcnet> (Tom G. Christensen's message of "Fri, 21 Aug 2009 17:55:46 +0200") References: <20090814140334.GA30319@ares.tgcnet> <87k512k0dn.fsf@mocca.josefsson.org> <20090818192623.GA5635@ares.tgcnet> <87my5v4fut.fsf@mocca.josefsson.org> <20090821155546.GA14150@ares.tgcnet> Message-ID: <87skfghqgl.fsf@mocca.josefsson.org> "Tom G. Christensen" writes: > On Thu, Aug 20, 2009 at 12:07:54AM +0200, Simon Josefsson wrote: >> Could you check if the size_max.m4 files in your build have 'serial 9' >> in the first line? Maybe you tested before the packages was updated. >> You could test the 2.9.3 release now. >> > I was initially using your daily-build script but then I noticed that > the gnutls snapshot has not been updated since Aug 13th. > > $ sha1sum ../gnutls-2.9.3.tar.bz2 > 6e7157274df5c95984fd52c4d500a414a67b9d44 ../gnutls-2.9.3.tar.bz2 > [gnutls-2.9.3]$ find . -name 'size_max.m4' | xargs head -1 > ==> ./gl/m4/size_max.m4 <== > # size_max.m4 serial 9 > > ==> ./lib/m4/size_max.m4 <== > # size_max.m4 serial 6 Oops, the build robot haven't been able to build it since then, the "resume" test is failing. I suspect it is related to the TLS session ticket support that went in recently. Build log: http://autobuild.josefsson.org/gnutls/log-200908241414540949000.txt I'm working on it. /Simon From simon at josefsson.org Mon Aug 24 23:46:41 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 24 Aug 2009 23:46:41 +0200 Subject: [PATCH] session ticket support In-Reply-To: <87pras7xpo.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 19 Aug 2009 15:13:55 +0200") References: <0c17ce98-f902-4e7e-bc07-a78893f8644e@broken.deisui.org> <4A5F93EA.9050100@gnutls.org> <4A6ACB0A.4030801@gnutls.org> <4A6C5385.9010504@gnutls.org> <87ws5jkc62.fsf@mocca.josefsson.org> <87vdl2rfmt.fsf@broken.deisui.org> <87prbahee5.fsf@mocca.josefsson.org> <87k51hxvny.fsf@broken.deisui.org> <87d478trxd.fsf@mocca.josefsson.org> <363143f7-75d8-49a1-a7d8-ad71bdb2583d@broken.deisui.org> <87prb3i22u.fsf@mocca.josefsson.org> <878whgdcdw.fsf@mocca.josefsson.org> <6c226b79-bdbf-4277-91c0-ead7ca6e67f2@broken.deisui.org> <87pras7xpo.fsf@mocca.josefsson.org> Message-ID: <87ab1ohola.fsf@mocca.josefsson.org> The self-test "resume" crashes, presumably because of the session ticket support or your memory leak fixes. Valgrind complains so it should be easy to debug. Could you please take a look? /Simon jas at mocca:~/src/gnutls/tests master$ valgrind ./resume ==4609== Memcheck, a memory error detector. ==4609== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==4609== Using LibVEX rev 1884, a library for dynamic binary translation. ==4609== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==4609== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation framework. ==4609== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==4609== For more details, rerun with: -v ==4609== try to resume from db server: ready. Listening to port '5556'. Launched, generating DH parameters... server: connection from 127.0.0.1, port 58638 resume db storing... (32-451) server: Handshake was completed client: Handshake was completed server: Peer has closed the GNUTLS connection server: connection from 127.0.0.1, port 58639 resume db fetch... (32) resume db fetch... return info client: Handshake was completed - Previous session was resumed resume db storing... (32-451) server: Handshake was completed server: Peer has closed the GNUTLS connection server: finished global stop ==4612== Invalid free() / delete / delete[] ==4612== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4612== by 0x428F9CB: (within /lib/i686/cmov/libc-2.9.so) ==4612== by 0x428F4A9: (within /lib/i686/cmov/libc-2.9.so) ==4612== by 0x4020402: _vgnU_freeres (vg_preloaded.c:60) ==4612== by 0x42059F3: _Exit (in /lib/i686/cmov/libc-2.9.so) ==4612== by 0x804A4BA: doit (resume.c:463) ==4612== by 0x804A59C: main (utils.c:148) ==4612== Address 0x41662c8 is not stack'd, malloc'd or (recently) free'd ==4612== ==4612== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 21 from 1) ==4612== malloc/free: in use at exit: 2,336 bytes in 38 blocks. ==4612== malloc/free: 2,553 allocs, 2,516 frees, 405,822 bytes allocated. ==4612== For counts of detected errors, rerun with: -v ==4612== searching for pointers to 38 not-freed blocks. ==4612== checked 100,004 bytes. ==4612== ==4612== LEAK SUMMARY: ==4612== definitely lost: 0 bytes in 0 blocks. ==4612== possibly lost: 0 bytes in 0 blocks. ==4612== still reachable: 0 bytes in 0 blocks. ==4612== suppressed: 2,336 bytes in 38 blocks. global stop try to resume from session ticket server: ready. Listening to port '5556'. Launched, generating DH parameters... server: connection from 127.0.0.1, port 58640 server: Handshake was completed client: Handshake was completed server: Peer has closed the GNUTLS connection server: connection from 127.0.0.1, port 58641 client: Handshake was completed - Previous session was resumed server: Handshake was completed server: Peer has closed the GNUTLS connection server: finished global stop ==4622== Invalid free() / delete / delete[] ==4622== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4622== by 0x4054DAF: gnutls_anon_free_server_credentials (gnutls_anon_cred.c:47) ==4622== by 0x8049A5E: global_stop (resume.c:323) ==4622== by 0x804A4AE: doit (resume.c:462) ==4622== by 0x804A59C: main (utils.c:148) ==4622== Address 0x43164e0 is 0 bytes inside a block of size 8 free'd ==4622== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4622== by 0x4054DAF: gnutls_anon_free_server_credentials (gnutls_anon_cred.c:47) ==4622== by 0x8049A5E: global_stop (resume.c:323) ==4622== by 0x804A313: doit (resume.c:457) ==4622== by 0x804A59C: main (utils.c:148) ==4622== ==4622== Invalid read of size 4 ==4622== at 0x404FD3A: _gnutls_mpi_release (gnutls_mpi.c:120) ==4622== by 0x405A7E5: gnutls_dh_params_deinit (gnutls_dh_primes.c:136) ==4622== by 0x8049A6B: global_stop (resume.c:325) ==4622== by 0x804A4AE: doit (resume.c:462) ==4622== by 0x804A59C: main (utils.c:148) ==4622== Address 0x4316518 is 0 bytes inside a block of size 8 free'd ==4622== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4622== by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139) ==4622== by 0x8049A6B: global_stop (resume.c:325) ==4622== by 0x804A313: doit (resume.c:457) ==4622== by 0x804A59C: main (utils.c:148) ==4622== ==4622== Invalid read of size 4 ==4622== at 0x404FD3A: _gnutls_mpi_release (gnutls_mpi.c:120) ==4622== by 0x405A7F0: gnutls_dh_params_deinit (gnutls_dh_primes.c:137) ==4622== by 0x8049A6B: global_stop (resume.c:325) ==4622== by 0x804A4AE: doit (resume.c:462) ==4622== by 0x804A59C: main (utils.c:148) ==4622== Address 0x431651c is 4 bytes inside a block of size 8 free'd ==4622== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4622== by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139) ==4622== by 0x8049A6B: global_stop (resume.c:325) ==4622== by 0x804A313: doit (resume.c:457) ==4622== by 0x804A59C: main (utils.c:148) ==4622== ==4622== Invalid free() / delete / delete[] ==4622== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4622== by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139) ==4622== by 0x8049A6B: global_stop (resume.c:325) ==4622== by 0x804A4AE: doit (resume.c:462) ==4622== by 0x804A59C: main (utils.c:148) ==4622== Address 0x4316518 is 0 bytes inside a block of size 8 free'd ==4622== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4622== by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139) ==4622== by 0x8049A6B: global_stop (resume.c:325) ==4622== by 0x804A313: doit (resume.c:457) ==4622== by 0x804A59C: main (utils.c:148) ==4622== ==4622== Invalid free() / delete / delete[] ==4622== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4622== by 0x428F9CB: (within /lib/i686/cmov/libc-2.9.so) ==4622== by 0x428F4A9: (within /lib/i686/cmov/libc-2.9.so) ==4622== by 0x4020402: _vgnU_freeres (vg_preloaded.c:60) ==4622== by 0x42059F3: _Exit (in /lib/i686/cmov/libc-2.9.so) ==4622== by 0x804A4BA: doit (resume.c:463) ==4622== by 0x804A59C: main (utils.c:148) ==4622== Address 0x41662c8 is not stack'd, malloc'd or (recently) free'd ==4622== ==4622== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 21 from 1) ==4622== malloc/free: in use at exit: 2,336 bytes in 38 blocks. ==4622== malloc/free: 5,078 allocs, 5,043 frees, 847,546 bytes allocated. ==4622== For counts of detected errors, rerun with: -v ==4622== searching for pointers to 38 not-freed blocks. ==4622== checked 100,032 bytes. ==4622== ==4622== LEAK SUMMARY: ==4622== definitely lost: 0 bytes in 0 blocks. ==4622== possibly lost: 0 bytes in 0 blocks. ==4622== still reachable: 0 bytes in 0 blocks. ==4622== suppressed: 2,336 bytes in 38 blocks. global stop try to resume from session ticket (server only) server: ready. Listening to port '5556'. Launched, generating DH parameters... server: connection from 127.0.0.1, port 58642 server: Handshake was completed client: Handshake was completed server: Peer has closed the GNUTLS connection server: connection from 127.0.0.1, port 58643 server: Handshake was completed client: Handshake was completed *** Previous session was NOT resumed server: Peer has closed the GNUTLS connection server: finished global stop ==4625== Invalid free() / delete / delete[] ==4625== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4625== by 0x4054DAF: gnutls_anon_free_server_credentials (gnutls_anon_cred.c:47) ==4625== by 0x8049A5E: global_stop (resume.c:323) ==4625== by 0x804A4AE: doit (resume.c:462) ==4625== by 0x804A59C: main (utils.c:148) ==4625== Address 0x439f610 is 0 bytes inside a block of size 8 free'd ==4625== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4625== by 0x4054DAF: gnutls_anon_free_server_credentials (gnutls_anon_cred.c:47) ==4625== by 0x8049A5E: global_stop (resume.c:323) ==4625== by 0x804A313: doit (resume.c:457) ==4625== by 0x804A59C: main (utils.c:148) ==4625== ==4625== Invalid read of size 4 ==4625== at 0x404FD3A: _gnutls_mpi_release (gnutls_mpi.c:120) ==4625== by 0x405A7E5: gnutls_dh_params_deinit (gnutls_dh_primes.c:136) ==4625== by 0x8049A6B: global_stop (resume.c:325) ==4625== by 0x804A4AE: doit (resume.c:462) ==4625== by 0x804A59C: main (utils.c:148) ==4625== Address 0x439f648 is 0 bytes inside a block of size 8 free'd ==4625== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4625== by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139) ==4625== by 0x8049A6B: global_stop (resume.c:325) ==4625== by 0x804A313: doit (resume.c:457) ==4625== by 0x804A59C: main (utils.c:148) ==4625== ==4625== Invalid read of size 4 ==4625== at 0x404FD3A: _gnutls_mpi_release (gnutls_mpi.c:120) ==4625== by 0x405A7F0: gnutls_dh_params_deinit (gnutls_dh_primes.c:137) ==4625== by 0x8049A6B: global_stop (resume.c:325) ==4625== by 0x804A4AE: doit (resume.c:462) ==4625== by 0x804A59C: main (utils.c:148) ==4625== Address 0x439f64c is 4 bytes inside a block of size 8 free'd ==4625== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4625== by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139) ==4625== by 0x8049A6B: global_stop (resume.c:325) ==4625== by 0x804A313: doit (resume.c:457) ==4625== by 0x804A59C: main (utils.c:148) ==4625== ==4625== Invalid free() / delete / delete[] ==4625== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4625== by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139) ==4625== by 0x8049A6B: global_stop (resume.c:325) ==4625== by 0x804A4AE: doit (resume.c:462) ==4625== by 0x804A59C: main (utils.c:148) ==4625== Address 0x439f648 is 0 bytes inside a block of size 8 free'd ==4625== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4625== by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139) ==4625== by 0x8049A6B: global_stop (resume.c:325) ==4625== by 0x804A313: doit (resume.c:457) ==4625== by 0x804A59C: main (utils.c:148) ==4625== ==4625== Invalid free() / delete / delete[] ==4625== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4625== by 0x428F9CB: (within /lib/i686/cmov/libc-2.9.so) ==4625== by 0x428F4A9: (within /lib/i686/cmov/libc-2.9.so) ==4625== by 0x4020402: _vgnU_freeres (vg_preloaded.c:60) ==4625== by 0x42059F3: _Exit (in /lib/i686/cmov/libc-2.9.so) ==4625== by 0x804A4BA: doit (resume.c:463) ==4625== by 0x804A59C: main (utils.c:148) ==4625== Address 0x41662c8 is not stack'd, malloc'd or (recently) free'd ==4625== ==4625== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 21 from 1) ==4625== malloc/free: in use at exit: 2,336 bytes in 38 blocks. ==4625== malloc/free: 7,713 allocs, 7,678 frees, 1,301,048 bytes allocated. ==4625== For counts of detected errors, rerun with: -v ==4625== searching for pointers to 38 not-freed blocks. ==4625== checked 100,032 bytes. ==4625== ==4625== LEAK SUMMARY: ==4625== definitely lost: 0 bytes in 0 blocks. ==4625== possibly lost: 0 bytes in 0 blocks. ==4625== still reachable: 0 bytes in 0 blocks. ==4625== suppressed: 2,336 bytes in 38 blocks. global stop try to resume from session ticket (client only) server: ready. Listening to port '5556'. Launched, generating DH parameters... server: connection from 127.0.0.1, port 58644 server: Handshake was completed client: Handshake was completed server: Peer has closed the GNUTLS connection server: connection from 127.0.0.1, port 58645 server: Handshake was completed client: Handshake was completed *** Previous session was NOT resumed server: Peer has closed the GNUTLS connection ==4609== Invalid free() / delete / delete[] ==4609== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4609== by 0x804A2F7: doit (resume.c:424) ==4609== by 0x804A59C: main (utils.c:148) ==4609== Address 0x4426510 is 0 bytes inside a block of size 64 free'd ==4609== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4609== by 0x804A2F7: doit (resume.c:424) ==4609== by 0x804A59C: main (utils.c:148) server: finished global stop ==4636== Invalid free() / delete / delete[] ==4636== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4636== by 0x4054DAF: gnutls_anon_free_server_credentials (gnutls_anon_cred.c:47) ==4636== by 0x8049A5E: global_stop (resume.c:323) ==4636== by 0x804A4AE: doit (resume.c:462) ==4636== by 0x804A59C: main (utils.c:148) ==4636== Address 0x4425d60 is 0 bytes inside a block of size 8 free'd ==4636== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4636== by 0x4054DAF: gnutls_anon_free_server_credentials (gnutls_anon_cred.c:47) ==4636== by 0x8049A5E: global_stop (resume.c:323) ==4636== by 0x804A313: doit (resume.c:457) ==4636== by 0x804A59C: main (utils.c:148) ==4636== ==4636== Invalid read of size 4 ==4636== at 0x404FD3A: _gnutls_mpi_release (gnutls_mpi.c:120) ==4636== by 0x405A7E5: gnutls_dh_params_deinit (gnutls_dh_primes.c:136) ==4636== by 0x8049A6B: global_stop (resume.c:325) ==4636== by 0x804A4AE: doit (resume.c:462) ==4636== by 0x804A59C: main (utils.c:148) ==4636== Address 0x4425d98 is 0 bytes inside a block of size 8 free'd ==4636== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4636== by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139) ==4636== by 0x8049A6B: global_stop (resume.c:325) ==4636== by 0x804A313: doit (resume.c:457) ==4636== by 0x804A59C: main (utils.c:148) ==4636== ==4636== Invalid read of size 4 ==4636== at 0x404FD3A: _gnutls_mpi_release (gnutls_mpi.c:120) ==4636== by 0x405A7F0: gnutls_dh_params_deinit (gnutls_dh_primes.c:137) ==4636== by 0x8049A6B: global_stop (resume.c:325) ==4636== by 0x804A4AE: doit (resume.c:462) ==4636== by 0x804A59C: main (utils.c:148) ==4636== Address 0x4425d9c is 4 bytes inside a block of size 8 free'd ==4636== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4636== by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139) ==4636== by 0x8049A6B: global_stop (resume.c:325) ==4636== by 0x804A313: doit (resume.c:457) ==4636== by 0x804A59C: main (utils.c:148) ==4636== ==4636== Invalid free() / delete / delete[] ==4636== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4636== by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139) ==4636== by 0x8049A6B: global_stop (resume.c:325) ==4636== by 0x804A4AE: doit (resume.c:462) ==4636== by 0x804A59C: main (utils.c:148) ==4636== Address 0x4425d98 is 0 bytes inside a block of size 8 free'd ==4636== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4636== by 0x405A7FB: gnutls_dh_params_deinit (gnutls_dh_primes.c:139) ==4636== by 0x8049A6B: global_stop (resume.c:325) ==4636== by 0x804A313: doit (resume.c:457) ==4636== by 0x804A59C: main (utils.c:148) ==4636== ==4636== Invalid free() / delete / delete[] ==4636== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4636== by 0x428F9CB: (within /lib/i686/cmov/libc-2.9.so) ==4636== by 0x428F4A9: (within /lib/i686/cmov/libc-2.9.so) ==4636== by 0x4020402: _vgnU_freeres (vg_preloaded.c:60) ==4636== by 0x42059F3: _Exit (in /lib/i686/cmov/libc-2.9.so) ==4636== by 0x804A4BA: doit (resume.c:463) ==4636== by 0x804A59C: main (utils.c:148) ==4636== Address 0x41662c8 is not stack'd, malloc'd or (recently) free'd ==4636== ==4636== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 21 from 1) ==4636== malloc/free: in use at exit: 2,336 bytes in 38 blocks. ==4636== malloc/free: 10,330 allocs, 10,295 frees, 1,747,306 bytes allocated. ==4636== For counts of detected errors, rerun with: -v ==4636== searching for pointers to 38 not-freed blocks. ==4636== checked 100,032 bytes. ==4636== ==4636== LEAK SUMMARY: ==4636== definitely lost: 0 bytes in 0 blocks. ==4636== possibly lost: 0 bytes in 0 blocks. ==4636== still reachable: 0 bytes in 0 blocks. ==4636== suppressed: 2,336 bytes in 38 blocks. global stop Self test `./resume' finished with 0 errors ==4609== ==4609== Invalid free() / delete / delete[] ==4609== at 0x4024E3A: free (vg_replace_malloc.c:323) ==4609== by 0x428F9CB: (within /lib/i686/cmov/libc-2.9.so) ==4609== by 0x428F4A9: (within /lib/i686/cmov/libc-2.9.so) ==4609== by 0x4020402: _vgnU_freeres (vg_preloaded.c:60) ==4609== by 0x42059F3: _Exit (in /lib/i686/cmov/libc-2.9.so) ==4609== by 0x417D7AC: (below main) (in /lib/i686/cmov/libc-2.9.so) ==4609== Address 0x41662c8 is not stack'd, malloc'd or (recently) free'd ==4609== ==4609== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 21 from 1) ==4609== malloc/free: in use at exit: 2,336 bytes in 38 blocks. ==4609== malloc/free: 10,334 allocs, 10,298 frees, 1,753,420 bytes allocated. ==4609== For counts of detected errors, rerun with: -v ==4609== searching for pointers to 38 not-freed blocks. ==4609== checked 99,916 bytes. ==4609== ==4609== LEAK SUMMARY: ==4609== definitely lost: 0 bytes in 0 blocks. ==4609== possibly lost: 0 bytes in 0 blocks. ==4609== still reachable: 0 bytes in 0 blocks. ==4609== suppressed: 2,336 bytes in 38 blocks. jas at mocca:~/src/gnutls/tests master$ From ueno at unixuser.org Mon Aug 24 23:46:38 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Tue, 25 Aug 2009 06:46:38 +0900 Subject: Buildreport for GnuTLS 2.8.3 In-Reply-To: <87skfghqgl.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon, 24 Aug 2009 23:06:18 +0200") References: <20090814140334.GA30319@ares.tgcnet> <87k512k0dn.fsf@mocca.josefsson.org> <20090818192623.GA5635@ares.tgcnet> <87my5v4fut.fsf@mocca.josefsson.org> <20090821155546.GA14150@ares.tgcnet> <87skfghqgl.fsf@mocca.josefsson.org> Message-ID: >>>>> In <87skfghqgl.fsf at mocca.josefsson.org> >>>>> Simon Josefsson wrote: > Oops, the build robot haven't been able to build it since then, the > "resume" test is failing. I suspect it is related to the TLS session > ticket support that went in recently. Build log: > http://autobuild.josefsson.org/gnutls/log-200908241414540949000.txt > I'm working on it. Oops, it seems that I installed a double-free bug along with memleak fixes... Sorry for taking your time. Here is a patch to fix it: -------------- next part -------------- A non-text attachment was scrubbed... Name: double-free-fix.diff Type: text/x-diff Size: 451 bytes Desc: not available URL: -------------- next part -------------- Regerds, -- Daiki Ueno From simon at josefsson.org Mon Aug 24 23:49:03 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 24 Aug 2009 23:49:03 +0200 Subject: Buildreport for GnuTLS 2.8.3 In-Reply-To: (Daiki Ueno's message of "Tue, 25 Aug 2009 06:46:38 +0900") References: <20090814140334.GA30319@ares.tgcnet> <87k512k0dn.fsf@mocca.josefsson.org> <20090818192623.GA5635@ares.tgcnet> <87my5v4fut.fsf@mocca.josefsson.org> <20090821155546.GA14150@ares.tgcnet> <87skfghqgl.fsf@mocca.josefsson.org> Message-ID: <874orwhohc.fsf@mocca.josefsson.org> Daiki Ueno writes: > Oops, it seems that I installed a double-free bug along with memleak > fixes... Sorry for taking your time. You were too quick! Thanks, confirmed working and pushed. Now let's hope the build robot continues.. /Simon From ueno at unixuser.org Tue Aug 25 14:34:49 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Tue, 25 Aug 2009 21:34:49 +0900 Subject: ECC cipher suites Message-ID: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> Hello, I looked at the feature comparison table of TLS libraries and noticed that GnuTLS still lacks ECC support: http://www.gnu.org/software/gnutls/comparison.html Is anyone working on this? Otherwise, I would like to give it a try[1]. After a quick search on Gmane, the primary (technical) reason seems that there is no way to compute ECDH with libgcrypt. If so, how about simply exporting the EC version of powm and curve selection API[2]? Anyway, would it make sense? Comments are appreciated. Footnotes: [1] I recently got my paperwork done for both GnuTLS/libgcrypt, and I am seeking for next interesting project. [2] I have first considered a generic key-agreement interface in libgcrypt, but I now think that it's too much - currently only DH variants are used in practice. Regards, -- Daiki Ueno From simon at josefsson.org Wed Aug 26 00:24:43 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 26 Aug 2009 00:24:43 +0200 Subject: ECC cipher suites In-Reply-To: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> (Daiki Ueno's message of "Tue, 25 Aug 2009 21:34:49 +0900") References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> Message-ID: <87eiqzedlg.fsf@mocca.josefsson.org> Daiki Ueno writes: > Hello, > > I looked at the feature comparison table of TLS libraries and noticed > that GnuTLS still lacks ECC support: > http://www.gnu.org/software/gnutls/comparison.html > > Is anyone working on this? Otherwise, I would like to give it a try[1]. Nobody is working on it, but there are patent issues with ECC that has to be resolved. To avoid wasting time, we may want to approach the FSF and the SFLC first to get a better understanding of what's involved here (I've been deferring this since nobody has expressed interest in ECC). > [1] I recently got my paperwork done for both GnuTLS/libgcrypt, and I am > seeking for next interesting project. Finishing the TLS 1.2 support and adding the new cipher suites is a high-priority task and it shouldn't be too difficult since there are TLS 1.2 test servers out there to test with. /Simon From roland at digitalvampire.org Thu Aug 27 00:22:14 2009 From: roland at digitalvampire.org (Roland Dreier) Date: Wed, 26 Aug 2009 15:22:14 -0700 Subject: Problem with TLS 1.1 client connecting to TLS 1.0 server Message-ID: <87tyzuw6zt.fsf@shaolin.home.digitalvampire.org> I found what appears to be a small bug in how gnutls handles the case where a TLS 1.1 client connects to a server that only supports TLS 1.0. My particular case is using empathy, an IM client built on telepathy-gabble, which in turn uses libloudmouth and finally uses gnutls to talk to a jabber/XMPP server. This setup defaults to trying TLS 1.1, and in my case I'm using the client to talk to Webex Connect, where there server seems to support only TLS 1.0. So looking at the trace, I see a client hello sent with version 03 02, and the server responds with a hello with version 03 01. gnutls then falls back to TLS 1.0 and future messages have version 03 01, but the handshake fails after gnutls sends the client finished message -- the server responds with a bad record MAC alert. After a bunch of tracing through, I found the code in _gnutls_gen_rsa_client_kx() in auth_rsa.c: ver = _gnutls_get_adv_version (session); if (session->internals.rsa_pms_version[0] == 0) { session->key->key.data[0] = _gnutls_version_get_major (ver); session->key->key.data[1] = _gnutls_version_get_minor (ver); and when a client starts a TLS 1.1 session but falls back to TLS 1.0, _gnutls_get_adv_version() still returns TLS 1.1, so the client uses minor version 2 here, even though it is in the process of negotiating a TLS 1.0 (minor 1) connection. If I add a hack to overwrite session->key->key.data[1] with 1 after the assignment of the minor, then the connection goes through OK. So it seems that _gnutls_gen_rsa_client_kx() should be using the active version here, but I'm not sure what the correct real fix within the gnutls design is. Can someone provide guidance on how to fix this? Thanks, Roland From ueno at unixuser.org Thu Aug 27 13:29:18 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Thu, 27 Aug 2009 20:29:18 +0900 Subject: ECC cipher suites In-Reply-To: <87eiqzedlg.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 26 Aug 2009 00:24:43 +0200") References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> <87eiqzedlg.fsf@mocca.josefsson.org> Message-ID: <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> >>>>> In <87eiqzedlg.fsf at mocca.josefsson.org> >>>>> Simon Josefsson wrote: > > I looked at the feature comparison table of TLS libraries and noticed > > that GnuTLS still lacks ECC support: > > http://www.gnu.org/software/gnutls/comparison.html > > > > Is anyone working on this? Otherwise, I would like to give it a try[1]. > Nobody is working on it, but there are patent issues with ECC that has > to be resolved. To avoid wasting time, we may want to approach the FSF > and the SFLC first to get a better understanding of what's involved here > (I've been deferring this since nobody has expressed interest in ECC). Good to know before stepping into further. I hope that the situation will change in the near future. > Finishing the TLS 1.2 support and adding the new cipher suites is a > high-priority task and it shouldn't be too difficult since there are TLS > 1.2 test servers out there to test with. Thanks for the hint. I'll check which features of TLS 1.2 are not implemented. Adding HMAC-SHA256 cipher suites looks one thing to do. Regards, -- Daiki Ueno From simon at josefsson.org Thu Aug 27 15:12:16 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 27 Aug 2009 15:12:16 +0200 Subject: Poll: What do you want to see implemented in GnuTLS next? In-Reply-To: <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> (Daiki Ueno's message of "Thu, 27 Aug 2009 20:29:18 +0900") References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> <87eiqzedlg.fsf@mocca.josefsson.org> <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> Message-ID: <87fxbdjt8v.fsf_-_@mocca.josefsson.org> Daiki Ueno writes: >> Finishing the TLS 1.2 support and adding the new cipher suites is a >> high-priority task and it shouldn't be too difficult since there are TLS >> 1.2 test servers out there to test with. > > Thanks for the hint. I'll check which features of TLS 1.2 are not > implemented. Adding HMAC-SHA256 cipher suites looks one thing to do. Actually TLS 1.2 is not working in GnuTLS now, the drafts changed how the negotiation worked after I implemented it and I never found time to update it to support the protocol defined by the final RFC. I don't expect finishing this would require major changes, so it would be a great contribution to finish the TLS 1.2 support. Definitely adding SHA256 ciphers would be good. Reading doc/TODO I couldn't find any other easily identifiable task that is more important except possibly DTLS support (but Jonathan is working on that already). Maybe we can turn this into an open poll. What do people want to see happen next? AES-GCM cipher suites would be nice. There is also the OCSP extension, which would be fairly easy to add. /Simon From simon at josefsson.org Thu Aug 27 15:24:49 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 27 Aug 2009 15:24:49 +0200 Subject: Problem with TLS 1.1 client connecting to TLS 1.0 server In-Reply-To: <87tyzuw6zt.fsf@shaolin.home.digitalvampire.org> (Roland Dreier's message of "Wed, 26 Aug 2009 15:22:14 -0700") References: <87tyzuw6zt.fsf@shaolin.home.digitalvampire.org> Message-ID: <87bpm1jsny.fsf@mocca.josefsson.org> Roland Dreier writes: > I found what appears to be a small bug in how gnutls handles the case > where a TLS 1.1 client connects to a server that only supports TLS > 1.0. My particular case is using empathy, an IM client built on > telepathy-gabble, which in turn uses libloudmouth and finally uses > gnutls to talk to a jabber/XMPP server. This setup defaults to trying > TLS 1.1, and in my case I'm using the client to talk to Webex Connect, > where there server seems to support only TLS 1.0. > > So looking at the trace, I see a client hello sent with version 03 02, > and the server responds with a hello with version 03 01. gnutls then > falls back to TLS 1.0 and future messages have version 03 01, but the > handshake fails after gnutls sends the client finished message -- the > server responds with a bad record MAC alert. > > After a bunch of tracing through, I found the code in > _gnutls_gen_rsa_client_kx() in auth_rsa.c: > > ver = _gnutls_get_adv_version (session); > > if (session->internals.rsa_pms_version[0] == 0) > { > session->key->key.data[0] = _gnutls_version_get_major (ver); > session->key->key.data[1] = _gnutls_version_get_minor (ver); > > and when a client starts a TLS 1.1 session but falls back to TLS 1.0, > _gnutls_get_adv_version() still returns TLS 1.1, so the client uses > minor version 2 here, even though it is in the process of negotiating > a TLS 1.0 (minor 1) connection. > > If I add a hack to overwrite session->key->key.data[1] with 1 after > the assignment of the minor, then the connection goes through OK. > > So it seems that _gnutls_gen_rsa_client_kx() should be using the > active version here, but I'm not sure what the correct real fix within > the gnutls design is. Can someone provide guidance on how to fix this? RFC 5246 says the PMS should contain the latest (newest) version supported by the client: client_version The latest (newest) version supported by the client. This is used to detect version rollback attacks. ... Note: The version number in the PreMasterSecret is the version offered by the client in the ClientHello.client_version, not the version negotiated for the connection. This feature is designed to prevent rollback attacks. Unfortunately, some old implementations use the negotiated version instead, and therefore checking the version number may lead to failure to interoperate with such incorrect client implementations. Client implementations MUST always send the correct version number in PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher, server implementations MUST check the version number as described in the note below. If the version number is TLS 1.0 or earlier, server implementations SHOULD check the version number, but MAY have a configuration option to disable the check. Note that if the check fails, the PreMasterSecret SHOULD be randomized as described below. Even RFC 2246, TLS 1.0, is clear on this: client_version The latest (newest) version supported by the client. This is used to detect version roll-back attacks. Upon receiving the premaster secret, the server should check that this value matches the value transmitted by the client in the client hello message. I believe this means your server is broken and doesn't implement TLS 1.0 correctly. Changing how GnuTLS works here by default doesn't work: it would make the default break with working servers, which isn't a good idea. So the next-best solution appears to allow applications say to GnuTLS to work better with this particular server. This is already supported, and you can tell GnuTLS to only attempt to talk TLS 1.0 against the server. This appears to be the simplest solution since your server doesn't support anything more than TLS 1.0 anyway. This should be a knob somewhere in your application, and have to be propagated through the libraries down into GnuTLS. The following disables TLS 1.1: gnutls_priority_set_direct (session, "NORMAL:-VERS-TLS1.1", NULL); There are other alternatives to solving this too (i.e., add a knob to use another client_version value), but I'm not sure it is worth it as it adds other problems and the problem here is really a broken server. /Simon From dkg at fifthhorseman.net Thu Aug 27 22:30:53 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 27 Aug 2009 16:30:53 -0400 Subject: Why not SHA256 in cipher suite? In-Reply-To: <20090820141531.29f9fba5@zhu-laptop> References: <20090820141531.29f9fba5@zhu-laptop> Message-ID: <4A96ECFD.6030907@fifthhorseman.net> On 08/20/2009 07:15 AM, Xizhi Zhu wrote: > I found that in GnuTLS, SHA256 is not used in any cipher suites (i.e. > not listed in gnutls-cli -l). However, they are defined in RFC 5246, > e.g. TLS_RSA_WITH_AES_128_CBC_SHA256 (0x00,0x3C). I wonder why they are > not supported in GnuTLS as they can provide a higher security level. I think there is active development work starting on the SHA256 suites. Please see: http://lists.gnu.org/archive/html/gnutls-devel/2009-08/msg00109.html hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature URL: From roland at digitalvampire.org Thu Aug 27 07:47:34 2009 From: roland at digitalvampire.org (Roland Dreier) Date: Wed, 26 Aug 2009 22:47:34 -0700 Subject: Problem with TLS 1.1 client connecting to TLS 1.0 server In-Reply-To: <87tyzuw6zt.fsf@shaolin.home.digitalvampire.org> (Roland Dreier's message of "Wed, 26 Aug 2009 15:22:14 -0700") References: <87tyzuw6zt.fsf@shaolin.home.digitalvampire.org> Message-ID: <87iqg9x0y1.fsf@shaolin.home.digitalvampire.org> > So it seems that _gnutls_gen_rsa_client_kx() should be using the > active version here, but I'm not sure what the correct real fix within > the gnutls design is. Can someone provide guidance on how to fix this? Never mind ... after reading the TLS spec more closely, I see that the client is correct in using the highest version it offered in the premaster secret. This is a bug (and apparently a common bug -- it appears in the ietf TLS interoperability draft) in the server, and I will report it to the server people. Sorry for the noise. - Roland -- Roland Dreier GPG Key: 1024D/E0EEFAC0 Fingerprint: A89F B5E9 C185 F34D BD50 4009 37E2 25CC E0EE FAC0 Sending >500KB attachments is forbidden by the Geneva Convention. Your country may be at risk if you fail to comply. From dan at coneharvesters.com Fri Aug 28 02:02:17 2009 From: dan at coneharvesters.com (Dan Fandrich) Date: Thu, 27 Aug 2009 17:02:17 -0700 Subject: GnuTLS portability fixes Message-ID: <20090828000216.GA14455@coneharvesters.com> I tripped over a few issues, mainly mismatched types, when compiling GnuTLS 2.8.3 using the OpenWatcom 1.8 compiler on Linux. Attached is a patch to fix those errors. >>> Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-2.8.3.diff Type: text/x-patch Size: 5004 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 288 bytes Desc: not available URL: From simon at josefsson.org Fri Aug 28 15:01:34 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 28 Aug 2009 15:01:34 +0200 Subject: GnuTLS portability fixes In-Reply-To: <20090828000216.GA14455@coneharvesters.com> (Dan Fandrich's message of "Thu, 27 Aug 2009 17:02:17 -0700") References: <20090828000216.GA14455@coneharvesters.com> Message-ID: <87ab1k5byp.fsf@mocca.josefsson.org> Dan Fandrich writes: > I tripped over a few issues, mainly mismatched types, when compiling GnuTLS 2.8.3 > using the OpenWatcom 1.8 compiler on Linux. Attached is a patch to fix > those errors. Thank you, applied. /Simon From tgc at jupiterrise.com Wed Aug 26 18:23:43 2009 From: tgc at jupiterrise.com (Tom G. Christensen) Date: Wed, 26 Aug 2009 18:23:43 +0200 Subject: Buildreport for GnuTLS 2.8.3 In-Reply-To: <874orwhohc.fsf@mocca.josefsson.org> References: <20090814140334.GA30319@ares.tgcnet> <87k512k0dn.fsf@mocca.josefsson.org> <20090818192623.GA5635@ares.tgcnet> <87my5v4fut.fsf@mocca.josefsson.org> <20090821155546.GA14150@ares.tgcnet> <87skfghqgl.fsf@mocca.josefsson.org> <874orwhohc.fsf@mocca.josefsson.org> Message-ID: <20090826162343.GA21539@ares.tgcnet> On Mon, Aug 24, 2009 at 11:49:03PM +0200, Simon Josefsson wrote: > You were too quick! Thanks, confirmed working and pushed. Now let's > hope the build robot continues.. > I see new datestamped tarballs appearing but no gnutls-latest? Also size_max.m4 is still too old: $ sha1sum ../gnutls-20090826.tar.bz2 ecdd0903a92dc2bb9fd77a83c2939a393b293fb4 ../gnutls-20090826.tar.bz2 [gnutls-2.9.4]$ find . -name size_max.m4 | xargs head -1 ==> ./lib/m4/size_max.m4 <== # size_max.m4 serial 6 ==> ./gl/m4/size_max.m4 <== # size_max.m4 serial 9 -tgc From simon at josefsson.org Fri Aug 28 18:32:23 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 28 Aug 2009 18:32:23 +0200 Subject: Buildreport for GnuTLS 2.8.3 In-Reply-To: <20090826162343.GA21539@ares.tgcnet> (Tom G. Christensen's message of "Wed, 26 Aug 2009 18:23:43 +0200") References: <20090814140334.GA30319@ares.tgcnet> <87k512k0dn.fsf@mocca.josefsson.org> <20090818192623.GA5635@ares.tgcnet> <87my5v4fut.fsf@mocca.josefsson.org> <20090821155546.GA14150@ares.tgcnet> <87skfghqgl.fsf@mocca.josefsson.org> <874orwhohc.fsf@mocca.josefsson.org> <20090826162343.GA21539@ares.tgcnet> Message-ID: <874orr527c.fsf@mocca.josefsson.org> "Tom G. Christensen" writes: > On Mon, Aug 24, 2009 at 11:49:03PM +0200, Simon Josefsson wrote: >> You were too quick! Thanks, confirmed working and pushed. Now let's >> hope the build robot continues.. >> > I see new datestamped tarballs appearing but no gnutls-latest? Right, that was because I turned off *.tar.gz, and the script that created the gnutls-latest ssymlink didn't understand *.bz2. Fixed now. > Also size_max.m4 is still too old: > $ sha1sum ../gnutls-20090826.tar.bz2 > ecdd0903a92dc2bb9fd77a83c2939a393b293fb4 ../gnutls-20090826.tar.bz2 > [gnutls-2.9.4]$ find . -name size_max.m4 | xargs head -1 > ==> ./lib/m4/size_max.m4 <== > # size_max.m4 serial 6 > ==> ./gl/m4/size_max.m4 <== > # size_max.m4 serial 9 Ah, lib/m4/size_max.m4 is generated by gettext. I have added an ugly workaround to cfg.mk, please try the most recent snapshot. /Simon From fk at fabiankeil.de Sat Aug 29 13:19:43 2009 From: fk at fabiankeil.de (Fabian Keil) Date: Sat, 29 Aug 2009 13:19:43 +0200 Subject: Minor fixes for gnutls 2.9.4 Message-ID: <20090829131943.17b54e52@r500.local> The attached patches fix a few minor issues in gnutls-20090829.tar.bz2, most of them pointed out by clang. The first three ones fix sanity checks in print_* functions, then there's a patch to improve the code clarity in crypt.c, one that marks what looks like a bug in _gnutls_srp_pwd_read_entry() and finally a couple of patches for write-only variables and dead stores which may or may not be intentional. Patch 0005 removes an apparently unnecessary (and insufficient) NULL pointer check, and while double checking the diff I also noticed the following code: fk at r500 ~/git/gnutls/gnutls-2.9.4 $cat -n lib/opencdk/misc.c | grep 12[34] 123 for (node = root->next; node; node = node->next) 124 return node; and wonder if an if block wouldn't be more suitable here. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-In-print_crl-initialize-aki_idx-and-crl_nr-once-befo.patch Type: text/x-patch Size: 1041 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-In-print_crq-initialize-challenge-and-extensions-onc.patch Type: text/x-patch Size: 905 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-In-print_extensions-initialize-_idx-variables-once-b.patch Type: text/x-patch Size: 1369 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-In-print_extensions-declare-the-_idx-variables-as-in.patch Type: text/x-patch Size: 1148 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-In-cdk_strlist_next-root-is-expected-to-be-non-NULL-.patch Type: text/x-patch Size: 729 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-In-main-rename-salt-to-salt_size-and-don-t-bother-re.patch Type: text/x-patch Size: 1240 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-Mark-what-looks-like-a-bug-in-in-_gnutls_srp_pwd_rea.patch Type: text/x-patch Size: 935 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-Remove-duplicates.-Two-exact-ones-and-a-pretty-close.patch Type: text/x-patch Size: 1771 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-Remove-write-only-variable-tmp_size-in-_pkcs12_decod.patch Type: text/x-patch Size: 1046 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0010-Remove-write-only-variable-sep_ar_idx-in-split_multi.patch Type: text/x-patch Size: 1482 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0011-Remove-write-only-variable-info-in-gen_rsa_export_se.patch Type: text/x-patch Size: 1053 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0012-Remove-write-only-variable-info-in-_gnutls_proc_cert.patch Type: text/x-patch Size: 926 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0013-Remove-dead-store-in-pkcs12_info.patch Type: text/x-patch Size: 638 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0014-Remove-dead-store-in-pwd_put_values.patch Type: text/x-patch Size: 612 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0015-Remove-dead-store-in-gnutls_x509_crt_list_import.patch Type: text/x-patch Size: 663 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0016-Remove-dead-store-in-_gnutls_io_write_buffered.patch Type: text/x-patch Size: 661 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0017-Remove-dead-store-in-listen_socket.patch Type: text/x-patch Size: 638 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From ueno at unixuser.org Mon Aug 31 08:25:19 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Mon, 31 Aug 2009 15:25:19 +0900 Subject: [PATCH] client-side TLS 1.2 support In-Reply-To: <87fxbdjt8v.fsf_-_@mocca.josefsson.org> (Simon Josefsson's message of "Thu, 27 Aug 2009 15:12:16 +0200") References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> <87eiqzedlg.fsf@mocca.josefsson.org> <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> <87fxbdjt8v.fsf_-_@mocca.josefsson.org> Message-ID: <87my5gwldc.fsf_-_@broken.deisui.org> >>>>> In <87fxbdjt8v.fsf_-_ at mocca.josefsson.org> >>>>> Simon Josefsson wrote: > Daiki Ueno writes: > >> Finishing the TLS 1.2 support and adding the new cipher suites is a > >> high-priority task and it shouldn't be too difficult since there are TLS > >> 1.2 test servers out there to test with. > > > > Thanks for the hint. I'll check which features of TLS 1.2 are not > > implemented. Adding HMAC-SHA256 cipher suites looks one thing to do. > Actually TLS 1.2 is not working in GnuTLS now, the drafts changed how > the negotiation worked after I implemented it and I never found time to > update it to support the protocol defined by the final RFC. I just realized it ;-) I'm attaching a set of patches to provide minimal fix for client side TLS 1.2 support. I've confirmed them working against Mike's test server: $ gnutls-cli --debug 10 --protocols TLS1.2 -p 443 www.mikestoolbox.net > I don't expect finishing this would require major changes, so it would > be a great contribution to finish the TLS 1.2 support. While server-side support would require a bit more work, for the moment I would like to ask for comments on my approach. The patches mainly follow the changes regarding SignatureAndHashAlgorithm usage. Here is a summary of each patch: * 0001-Add-functions-for-TLS-signature-algorithm.patch This patch adds helper functions which convert SignatureAndHashAlgorithm value from/to `gnutls_sign_algorithm_t'. * 0002-Respect-TLS-signature-algorithm-in-server-KX.patch The signature of DH params in Server Key Exchange is now a "digitally-signed" struct. This patch makes it read the algorithm IDs at the beginning of the actual signature bytes. * 0003-Use-SHA256-for-PRF-if-TLS-1.2.patch TLS 1.2 mandates that the algorithm for the basis of PRF is SHA256, and the same algorithm is used for the hash over handshake messages (to be used to verify Finished message). This patch makes it use SHA256 in both places. * 0004-Fix-parsing-Certificate-Request-for-TLS-1.2.patch This patch fixes a logic to skip supported_signature_algorithms in Certificate Request, whose type seemes to have changed from the draft. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-functions-for-TLS-signature-algorithm.patch Type: text/x-diff Size: 4756 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Respect-TLS-signature-algorithm-in-server-KX.patch Type: text/x-diff Size: 6862 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Use-SHA256-for-PRF-if-TLS-1.2.patch Type: text/x-diff Size: 2953 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Fix-parsing-Certificate-Request-for-TLS-1.2.patch Type: text/x-diff Size: 885 bytes Desc: not available URL: -------------- next part -------------- Regards, -- Daiki Ueno From simon at josefsson.org Mon Aug 31 13:00:36 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 31 Aug 2009 13:00:36 +0200 Subject: Minor fixes for gnutls 2.9.4 In-Reply-To: <20090829131943.17b54e52@r500.local> (Fabian Keil's message of "Sat, 29 Aug 2009 13:19:43 +0200") References: <20090829131943.17b54e52@r500.local> Message-ID: <87bplwfdt7.fsf@mocca.josefsson.org> Fabian Keil writes: > The attached patches fix a few minor issues in > gnutls-20090829.tar.bz2, most of them pointed out by clang. Thank you, I have applied them all except for 0005 which I decided to solve differently. > fk at r500 ~/git/gnutls/gnutls-2.9.4 $cat -n lib/opencdk/misc.c | grep 12[34] > 123 for (node = root->next; node; node = node->next) > 124 return node; > > and wonder if an if block wouldn't be more suitable here. Or why not just 'return root->next'? The code looks strange to me, but I don't want to change it without a selftest that uses that code. /Simon From simon at josefsson.org Mon Aug 31 13:31:25 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 31 Aug 2009 13:31:25 +0200 Subject: [PATCH] client-side TLS 1.2 support In-Reply-To: <87my5gwldc.fsf_-_@broken.deisui.org> (Daiki Ueno's message of "Mon, 31 Aug 2009 15:25:19 +0900") References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> <87eiqzedlg.fsf@mocca.josefsson.org> <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> <87fxbdjt8v.fsf_-_@mocca.josefsson.org> <87my5gwldc.fsf_-_@broken.deisui.org> Message-ID: <87zl9gdxte.fsf@mocca.josefsson.org> Daiki Ueno writes: > I'm attaching a set of patches to provide minimal fix for client side > TLS 1.2 support. I've confirmed them working against Mike's test > server: > > $ gnutls-cli --debug 10 --protocols TLS1.2 -p 443 www.mikestoolbox.net Great! > static const gnutls_sign_entry sign_algorithms[] = { > {"RSA-SHA", SIG_RSA_SHA1_OID, GNUTLS_SIGN_RSA_SHA1, GNUTLS_PK_RSA, > - GNUTLS_MAC_SHA1}, > + GNUTLS_MAC_SHA1, {2, 1}}, > {"RSA-SHA256", SIG_RSA_SHA256_OID, GNUTLS_SIGN_RSA_SHA256, GNUTLS_PK_RSA, > - GNUTLS_MAC_SHA256}, > + GNUTLS_MAC_SHA256, {4, 1}}, Please define some constants here instead of using hard coded values. Otherwise it looks good, I'll apply and test more carefully once you have fixed the above. /Simon From simon at josefsson.org Mon Aug 31 13:38:50 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 31 Aug 2009 13:38:50 +0200 Subject: [PATCH] Replace explicit version checks with feature checks In-Reply-To: <4A903985.6090807@x2a.org> (Jonathan Bastien-Filiatrault's message of "Sat, 22 Aug 2009 14:31:33 -0400") References: <4A8B69A2.9010905@x2a.org> <8763cj99xb.fsf@mocca.josefsson.org> <4A8C1BC8.6070901@x2a.org> <87fxbn5y1r.fsf@mocca.josefsson.org> <4A8DE7FC.5030405@x2a.org> <8763chtvjp.fsf@mocca.josefsson.org> <4A903985.6090807@x2a.org> Message-ID: <87skf8dxh1.fsf@mocca.josefsson.org> Jonathan Bastien-Filiatrault writes: > Simon Josefsson wrote: >> Jonathan Bastien-Filiatrault writes: >> >>> Simon Josefsson wrote: >>>> Jonathan Bastien-Filiatrault writes: >>>> >>>>> Simon Josefsson wrote: >>>> How do I create a patch between your branch and master, to review it? I >>>> haven't worked with multiple repositories, but willing to learn. >>>> >>>> /Simon >>> Alright, here is what you need to do: >>> >>> - Use a somewhat-pristine git repository cloned from savannah or whatever. >>> - Add a remote: git remote add -f jonathan git://x2a.org/gnutls.git ; >>> this adds an entry in the .git/config file and fetches refs and objects >>> from my repository. >>> - Create a local branch tracking my remote repository: git branch >>> --track buffers-redux jonathan/buffers-redux >>> - Now you can git checkout buffers-redux to switch to that branch or do >>> a git diff master..buffers-redux . If you had not created a local branch >>> you could instead do git diff master..jonathan/buffers-redux >> >> Excellent, thank you! >> >> Quick comments: >> >> * Please add a comment describing what dump_bytes does, and preferrably >> make it use _gnutls_bin2hex for hex encoding. Is there a fixed-size >> limit of 128 in the function? If so, it would be nice to fix that. > > I was not aware of the existence of the _gnutls_bin2hex function. The > fixed buffers in dump_bytes are emptied at the end of each line and > their maximum size is bounded by the number of bytes per line (16), so > it could in theory print 256^sizeof(size_t) bytes. I will fix > gnutls_buffers.c to use _gnutls_bin2hex. Great. >> * What does the 'bufel' variable name refers to? It looks non-english >> to me, so I'd prefer using 'buf'. > > A mbuffer is a chain of buffer elements. I use buf to refer to the whole > chain of buffers (mbuffer_head_st) and bufel to refer to a buffer > element (mbuffer_st). I don't mind changing the variable names if they > really bother you. No, that's fine. I just didn't understand the "buffer element" shortening to bufel. I suggest putting in a short comment at the top of gnutls_mbuffers.c about this in case others wonder. >> * Some comments at the top of gnutls_mbuffers.? what it does would be >> good. > > Sure, I can do that. I was planning on adding those comments later on > anyway. Please add them and post an updated patch. I think it is close to being pushed. Btw, do you expect more changes to the buffer handling for DTLS? I'm thinking that maybe we should release GnuTLS 2.10.0 once the TLS 1.2 support is working, which may happen soon, and I'm not sure how many of these patches makes sense in a GnuTLS 2.10.0 that wouldn't support DTLS. Of course, if you can finish DTLS support, that would be great, but I think complete TLS 1.2 is important enough to warrant a new stable release in the near future. /Simon From ueno at unixuser.org Mon Aug 31 14:14:14 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Mon, 31 Aug 2009 21:14:14 +0900 Subject: [PATCH] client-side TLS 1.2 support In-Reply-To: <87zl9gdxte.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon, 31 Aug 2009 13:31:25 +0200") References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> <87eiqzedlg.fsf@mocca.josefsson.org> <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> <87fxbdjt8v.fsf_-_@mocca.josefsson.org> <87my5gwldc.fsf_-_@broken.deisui.org> <87zl9gdxte.fsf@mocca.josefsson.org> Message-ID: <8763c4npt5.fsf@broken.deisui.org> >>>>> In <87zl9gdxte.fsf at mocca.josefsson.org> >>>>> Simon Josefsson wrote: > > static const gnutls_sign_entry sign_algorithms[] = { > > {"RSA-SHA", SIG_RSA_SHA1_OID, GNUTLS_SIGN_RSA_SHA1, GNUTLS_PK_RSA, > > - GNUTLS_MAC_SHA1}, > > + GNUTLS_MAC_SHA1, {2, 1}}, > > {"RSA-SHA256", SIG_RSA_SHA256_OID, GNUTLS_SIGN_RSA_SHA256, GNUTLS_PK_RSA, > > - GNUTLS_MAC_SHA256}, > > + GNUTLS_MAC_SHA256, {4, 1}}, > Please define some constants here instead of using hard coded values. OK, here it is: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Define-constants-for-known-SignatureAndHashAlgorithm.patch Type: text/x-diff Size: 2332 bytes Desc: not available URL: -------------- next part -------------- Regards, -- Daiki Ueno From simon at josefsson.org Mon Aug 31 14:22:36 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 31 Aug 2009 14:22:36 +0200 Subject: [PATCH] client-side TLS 1.2 support In-Reply-To: <8763c4npt5.fsf@broken.deisui.org> (Daiki Ueno's message of "Mon, 31 Aug 2009 21:14:14 +0900") References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> <87eiqzedlg.fsf@mocca.josefsson.org> <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> <87fxbdjt8v.fsf_-_@mocca.josefsson.org> <87my5gwldc.fsf_-_@broken.deisui.org> <87zl9gdxte.fsf@mocca.josefsson.org> <8763c4npt5.fsf@broken.deisui.org> Message-ID: <87d46cdvg3.fsf@mocca.josefsson.org> Daiki Ueno writes: >>>>>> In <87zl9gdxte.fsf at mocca.josefsson.org> >>>>>> Simon Josefsson wrote: >> > static const gnutls_sign_entry sign_algorithms[] = { >> > {"RSA-SHA", SIG_RSA_SHA1_OID, GNUTLS_SIGN_RSA_SHA1, GNUTLS_PK_RSA, >> > - GNUTLS_MAC_SHA1}, >> > + GNUTLS_MAC_SHA1, {2, 1}}, >> > {"RSA-SHA256", SIG_RSA_SHA256_OID, GNUTLS_SIGN_RSA_SHA256, GNUTLS_PK_RSA, >> > - GNUTLS_MAC_SHA256}, >> > + GNUTLS_MAC_SHA256, {4, 1}}, > >> Please define some constants here instead of using hard coded values. > > OK, here it is: Thanks. > +#define TLS_SIGN_AID_RSA_SHA1 {2, 1} > +#define TLS_SIGN_AID_RSA_SHA256 {4, 1} > +#define TLS_SIGN_AID_RSA_SHA384 {5, 1} > +#define TLS_SIGN_AID_RSA_SHA512 {6, 1} > +#define TLS_SIGN_AID_DSA_SHA1 {2, 2} > +#define TLS_SIGN_AID_RSA_MD5 {1, 2} Where does these "magic" values come from? It was these values that I would prefer to use symbolic names for. /Simon From ueno at unixuser.org Mon Aug 31 14:33:07 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Mon, 31 Aug 2009 21:33:07 +0900 Subject: [PATCH] client-side TLS 1.2 support In-Reply-To: <87d46cdvg3.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon, 31 Aug 2009 14:22:36 +0200") References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> <87eiqzedlg.fsf@mocca.josefsson.org> <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> <87fxbdjt8v.fsf_-_@mocca.josefsson.org> <87my5gwldc.fsf_-_@broken.deisui.org> <87zl9gdxte.fsf@mocca.josefsson.org> <8763c4npt5.fsf@broken.deisui.org> <87d46cdvg3.fsf@mocca.josefsson.org> Message-ID: <871vmsnoxo.fsf@broken.deisui.org> >>>>> In <87d46cdvg3.fsf at mocca.josefsson.org> >>>>> Simon Josefsson wrote: > > +#define TLS_SIGN_AID_RSA_SHA1 {2, 1} > > +#define TLS_SIGN_AID_RSA_SHA256 {4, 1} > > +#define TLS_SIGN_AID_RSA_SHA384 {5, 1} > > +#define TLS_SIGN_AID_RSA_SHA512 {6, 1} > > +#define TLS_SIGN_AID_DSA_SHA1 {2, 2} > > +#define TLS_SIGN_AID_RSA_MD5 {1, 2} > Where does these "magic" values come from? It was these values that I > would prefer to use symbolic names for. RFC5246 7.4.1.4.1. defines those values as: enum { none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } SignatureAlgorithm; I first thought of redefining GNUTLS_SIGN_* with pairs of those values (like cipher suites definitions), but it will break the ABI... Regards, -- Daiki Ueno From ueno at unixuser.org Mon Aug 31 14:45:19 2009 From: ueno at unixuser.org (Daiki Ueno) Date: Mon, 31 Aug 2009 21:45:19 +0900 Subject: [PATCH] client-side TLS 1.2 support In-Reply-To: <871vmsnoxo.fsf@broken.deisui.org> (Daiki Ueno's message of "Mon, 31 Aug 2009 21:33:07 +0900") References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> <87eiqzedlg.fsf@mocca.josefsson.org> <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> <87fxbdjt8v.fsf_-_@mocca.josefsson.org> <87my5gwldc.fsf_-_@broken.deisui.org> <87zl9gdxte.fsf@mocca.josefsson.org> <8763c4npt5.fsf@broken.deisui.org> <87d46cdvg3.fsf@mocca.josefsson.org> <871vmsnoxo.fsf@broken.deisui.org> Message-ID: <87vdk4m9sw.fsf@broken.deisui.org> > > Where does these "magic" values come from? It was these values that I > > would prefer to use symbolic names for. Ah, sorry. Perhaps the attached might be better (it uses separate symbolic names for sign/hash algorithms). -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Define-constants-for-known-SignatureAndHashAlgorithm.patch Type: text/x-diff Size: 2673 bytes Desc: not available URL: -------------- next part -------------- Regards, -- Daiki Ueno From simon at josefsson.org Mon Aug 31 15:04:10 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 31 Aug 2009 15:04:10 +0200 Subject: [PATCH] client-side TLS 1.2 support In-Reply-To: <871vmsnoxo.fsf@broken.deisui.org> (Daiki Ueno's message of "Mon, 31 Aug 2009 21:33:07 +0900") References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> <87eiqzedlg.fsf@mocca.josefsson.org> <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> <87fxbdjt8v.fsf_-_@mocca.josefsson.org> <87my5gwldc.fsf_-_@broken.deisui.org> <87zl9gdxte.fsf@mocca.josefsson.org> <8763c4npt5.fsf@broken.deisui.org> <87d46cdvg3.fsf@mocca.josefsson.org> <871vmsnoxo.fsf@broken.deisui.org> Message-ID: <874orodtit.fsf@mocca.josefsson.org> Daiki Ueno writes: >>>>>> In <87d46cdvg3.fsf at mocca.josefsson.org> >>>>>> Simon Josefsson wrote: >> > +#define TLS_SIGN_AID_RSA_SHA1 {2, 1} >> > +#define TLS_SIGN_AID_RSA_SHA256 {4, 1} >> > +#define TLS_SIGN_AID_RSA_SHA384 {5, 1} >> > +#define TLS_SIGN_AID_RSA_SHA512 {6, 1} >> > +#define TLS_SIGN_AID_DSA_SHA1 {2, 2} >> > +#define TLS_SIGN_AID_RSA_MD5 {1, 2} > >> Where does these "magic" values come from? It was these values that I >> would prefer to use symbolic names for. > > RFC5246 7.4.1.4.1. defines those values as: > > enum { > none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), > sha512(6), (255) > } HashAlgorithm; > > enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } > SignatureAlgorithm; Thanks, I pushed your patches and added a comment explaining this. > I first thought of redefining GNUTLS_SIGN_* with pairs of those values > (like cipher suites definitions), but it will break the ABI... Right, it is not worth it. /Simon From simon at josefsson.org Mon Aug 31 15:10:22 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 31 Aug 2009 15:10:22 +0200 Subject: [PATCH] client-side TLS 1.2 support In-Reply-To: <87my5gwldc.fsf_-_@broken.deisui.org> (Daiki Ueno's message of "Mon, 31 Aug 2009 15:25:19 +0900") References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> <87eiqzedlg.fsf@mocca.josefsson.org> <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> <87fxbdjt8v.fsf_-_@mocca.josefsson.org> <87my5gwldc.fsf_-_@broken.deisui.org> Message-ID: <87zl9gceo1.fsf@mocca.josefsson.org> Some part was missing, for example the definition of the _gnutls_version_has_selectable_sighash function. /Simon From simon at josefsson.org Mon Aug 31 15:11:47 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 31 Aug 2009 15:11:47 +0200 Subject: [PATCH] client-side TLS 1.2 support In-Reply-To: <87zl9gceo1.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon, 31 Aug 2009 15:10:22 +0200") References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> <87eiqzedlg.fsf@mocca.josefsson.org> <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> <87fxbdjt8v.fsf_-_@mocca.josefsson.org> <87my5gwldc.fsf_-_@broken.deisui.org> <87zl9gceo1.fsf@mocca.josefsson.org> Message-ID: <87vdk4celo.fsf@mocca.josefsson.org> Simon Josefsson writes: > Some part was missing, for example the definition of the > _gnutls_version_has_selectable_sighash function. Never mind, I added a '#include ' and it compiled fine. Now testing... /Simon From simon at josefsson.org Mon Aug 31 15:33:54 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 31 Aug 2009 15:33:54 +0200 Subject: [PATCH] client-side TLS 1.2 support In-Reply-To: <87my5gwldc.fsf_-_@broken.deisui.org> (Daiki Ueno's message of "Mon, 31 Aug 2009 15:25:19 +0900") References: <0205bd8a-cd22-4539-8dcd-68e5899d2f64@broken.deisui.org> <87eiqzedlg.fsf@mocca.josefsson.org> <71160cd9-7d90-48d5-9af0-0ee7404f2bc7@broken.deisui.org> <87fxbdjt8v.fsf_-_@mocca.josefsson.org> <87my5gwldc.fsf_-_@broken.deisui.org> Message-ID: <87r5uscdkt.fsf@mocca.josefsson.org> Daiki Ueno writes: >>>>>> In <87fxbdjt8v.fsf_-_ at mocca.josefsson.org> >>>>>> Simon Josefsson wrote: >> Daiki Ueno writes: > >> >> Finishing the TLS 1.2 support and adding the new cipher suites is a >> >> high-priority task and it shouldn't be too difficult since there are TLS >> >> 1.2 test servers out there to test with. >> > >> > Thanks for the hint. I'll check which features of TLS 1.2 are not >> > implemented. Adding HMAC-SHA256 cipher suites looks one thing to do. > >> Actually TLS 1.2 is not working in GnuTLS now, the drafts changed how >> the negotiation worked after I implemented it and I never found time to >> update it to support the protocol defined by the final RFC. > > I just realized it ;-) > > I'm attaching a set of patches to provide minimal fix for client side > TLS 1.2 support. I've confirmed them working against Mike's test > server: > > $ gnutls-cli --debug 10 --protocols TLS1.2 -p 443 www.mikestoolbox.net Confirmed, also working against https://tls.woodgrovebank.com/ Before we enable TLS 1.2 by default, I think what is missing are: * Check server-side TLS 1.2 * Add SHA-2 ciphersuites * Add self-test of TLS 1.2 ciphers/features /Simon From fk at fabiankeil.de Mon Aug 31 20:32:23 2009 From: fk at fabiankeil.de (Fabian Keil) Date: Mon, 31 Aug 2009 20:32:23 +0200 Subject: Minor fixes for gnutls 2.9.4 In-Reply-To: <87bplwfdt7.fsf@mocca.josefsson.org> References: <20090829131943.17b54e52@r500.local> <87bplwfdt7.fsf@mocca.josefsson.org> Message-ID: <20090831203223.7db86265@r500.local> Simon Josefsson wrote: > Fabian Keil writes: > > > The attached patches fix a few minor issues in > > gnutls-20090829.tar.bz2, most of them pointed out by clang. > > Thank you, I have applied them all except for 0005 which I decided to > solve differently. Great. > > fk at r500 ~/git/gnutls/gnutls-2.9.4 $cat -n lib/opencdk/misc.c | grep > > 12[34] 123 for (node = root->next; node; node = node->next) > > 124 return node; > > > > and wonder if an if block wouldn't be more suitable here. > > Or why not just 'return root->next'? Indeed. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From joe at x2a.org Mon Aug 31 20:51:44 2009 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Mon, 31 Aug 2009 14:51:44 -0400 Subject: [PATCH] Replace explicit version checks with feature checks In-Reply-To: <87skf8dxh1.fsf@mocca.josefsson.org> References: <4A8B69A2.9010905@x2a.org> <8763cj99xb.fsf@mocca.josefsson.org> <4A8C1BC8.6070901@x2a.org> <87fxbn5y1r.fsf@mocca.josefsson.org> <4A8DE7FC.5030405@x2a.org> <8763chtvjp.fsf@mocca.josefsson.org> <4A903985.6090807@x2a.org> <87skf8dxh1.fsf@mocca.josefsson.org> Message-ID: <4A9C1BC0.1030407@x2a.org> Simon Josefsson wrote: >>> >>> Quick comments: >>> >>> * Please add a comment describing what dump_bytes does, and preferrably >>> make it use _gnutls_bin2hex for hex encoding. Is there a fixed-size >>> limit of 128 in the function? If so, it would be nice to fix that. >> I was not aware of the existence of the _gnutls_bin2hex function. The >> fixed buffers in dump_bytes are emptied at the end of each line and >> their maximum size is bounded by the number of bytes per line (16), so >> it could in theory print 256^sizeof(size_t) bytes. I will fix >> gnutls_buffers.c to use _gnutls_bin2hex. > > Great. > >>> * What does the 'bufel' variable name refers to? It looks non-english >>> to me, so I'd prefer using 'buf'. >> A mbuffer is a chain of buffer elements. I use buf to refer to the whole >> chain of buffers (mbuffer_head_st) and bufel to refer to a buffer >> element (mbuffer_st). I don't mind changing the variable names if they >> really bother you. > > No, that's fine. I just didn't understand the "buffer element" > shortening to bufel. I suggest putting in a short comment at the top of > gnutls_mbuffers.c about this in case others wonder. > >>> * Some comments at the top of gnutls_mbuffers.? what it does would be >>> good. >> Sure, I can do that. I was planning on adding those comments later on >> anyway. > > Please add them and post an updated patch. I think it is close to being > pushed. Expect something soon on that end. I will notify you when I update my buffers branch with something viable. > Btw, do you expect more changes to the buffer handling for DTLS? I'm > thinking that maybe we should release GnuTLS 2.10.0 once the TLS 1.2 > support is working, which may happen soon, and I'm not sure how many of > these patches makes sense in a GnuTLS 2.10.0 that wouldn't support DTLS. > Of course, if you can finish DTLS support, that would be great, but I > think complete TLS 1.2 is important enough to warrant a new stable > release in the near future. Yes, there are more changes on the way, there is still the read() path that needs a whole lot of cleaning (with industrial grade bleach). The clean buffers interface is much nicer regardless of whether DTLS is there or not. The library user will of course see no change in the API with the brand new buffers. In other words the new buffers and DTLS are pretty much independent and can be merged in two steps with no problem at all. > /Simon Take care, Jonathan