From tmraz at redhat.com Tue Mar 2 21:44:07 2010 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 02 Mar 2010 21:44:07 +0100 Subject: Remove artificial constraint in _gnutls_x509_verify_certificate Message-ID: <1267562647.26237.373.camel@vespa.frost.loc> Hi, I was examining the current _gnutls_x509_verify_certificate() code and I found that the code does not allow unconditionally accepting the site certificate if it is on the trust list. I think that this is unnecessary restriction which should be removed. See the attached patch which removes the restriction. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-2.9.10-sitetrusted.patch Type: text/x-patch Size: 1115 bytes Desc: not available URL: From nmav at gnutls.org Tue Mar 2 22:34:24 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 02 Mar 2010 22:34:24 +0100 Subject: Remove artificial constraint in _gnutls_x509_verify_certificate In-Reply-To: <1267562647.26237.373.camel@vespa.frost.loc> References: <1267562647.26237.373.camel@vespa.frost.loc> Message-ID: <4B8D8460.50406@gnutls.org> Tomas Mraz wrote: > Hi, > I was examining the current _gnutls_x509_verify_certificate() code and I > found that the code does not allow unconditionally accepting the site > certificate if it is on the trust list. I think that this is unnecessary > restriction which should be removed. Please elaborate. What is the scenario that wasn't working before and you believe you fixed with this patch? regards, Nikos From nmav at gnutls.org Wed Mar 3 11:52:33 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 03 Mar 2010 11:52:33 +0100 Subject: Another renegotiation patch In-Reply-To: <20100227173024.7f7a0ff3@redhat.com> References: <4B58BC18.7030100@gnutls.org> <873a0zklc5.fsf@mocca.josefsson.org> <20100218125241.0c826a70@redhat.com> <87wryag1wh.fsf@mocca.josefsson.org> <20100218150455.1a4d1195@redhat.com> <20100224170648.11c5c9bb@redhat.com> <4B880BB9.1070300@gnutls.org> <20100227173024.7f7a0ff3@redhat.com> Message-ID: <4B8E3F71.80304@gnutls.org> Tomas Hoger wrote: > Hi Nikos! > > On Fri, 26 Feb 2010 18:58:17 +0100 Nikos Mavrogiannopoulos wrote: > >>> Can you have a look at the attached diff. It moves GNUTLS_CLIENT >>> test, so that the "Allowing/Denying unsafe initial negotiation" >>> message is logged instead of "Allowing/Denying unsafe >>> renegotiation" on initial client connection. >> Hmmm... actually a client cannot tell if it is a renegotiation or an >> initial connection. That's why this message is there. > Client can't tell if server sees that negotiation as initial or > rehandshake, but it's initial negotiation as seen by client. Moving > the entity == client check a bit just changes a gnutls debug message > and causes client not to send no_renegotiation warning. You are right here, on the warning alert. I've committed a fix on that. >>> I'd also consider removing %INITIAL_SAFE_RENEGOTIATION from >>> gnutls-cli.1 (always enforced) and mention client/server defaults in >>> gnutls_priority_init.3. Should I try submitting changes proposal? >> It is now always enforced but will not be the default after the >> renegotiation protection is common practice. > > May I ask why? The current default is to be strict on client side > regardless of the interoprability issues with unupgraded servers. Why > should the default change in the future to the less strict one, even > though fewer servers are expected to require it at that time? I must have been misunderstood. The strict default on the client will stay as is in the future. The server behavior that is permissive to old clients might change in the future. regards, Nikos From tmraz at redhat.com Wed Mar 3 12:31:55 2010 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 03 Mar 2010 12:31:55 +0100 Subject: Remove artificial constraint in _gnutls_x509_verify_certificate In-Reply-To: <4B8D8460.50406@gnutls.org> References: <1267562647.26237.373.camel@vespa.frost.loc> <4B8D8460.50406@gnutls.org> Message-ID: <1267615915.26237.468.camel@vespa.frost.loc> On Tue, 2010-03-02 at 22:34 +0100, Nikos Mavrogiannopoulos wrote: > Tomas Mraz wrote: > > Hi, > > I was examining the current _gnutls_x509_verify_certificate() code and I > > found that the code does not allow unconditionally accepting the site > > certificate if it is on the trust list. I think that this is unnecessary > > restriction which should be removed. > > Please elaborate. What is the scenario that wasn't working before and > you believe you fixed with this patch? For example when the site certificate is expired and/or uses unsafe algorithm for its signature and you put it on the trusted list on client to alleviate the problem. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From thoger at redhat.com Thu Mar 4 14:05:57 2010 From: thoger at redhat.com (Tomas Hoger) Date: Thu, 4 Mar 2010 14:05:57 +0100 Subject: Another renegotiation patch In-Reply-To: <4B8E3F71.80304@gnutls.org> References: <4B58BC18.7030100@gnutls.org> <873a0zklc5.fsf@mocca.josefsson.org> <20100218125241.0c826a70@redhat.com> <87wryag1wh.fsf@mocca.josefsson.org> <20100218150455.1a4d1195@redhat.com> <20100224170648.11c5c9bb@redhat.com> <4B880BB9.1070300@gnutls.org> <20100227173024.7f7a0ff3@redhat.com> <4B8E3F71.80304@gnutls.org> Message-ID: <20100304140557.7890290e@redhat.com> On Wed, 03 Mar 2010 11:52:33 +0100 Nikos Mavrogiannopoulos wrote: > You are right here, on the warning alert. I've committed a fix on > that. Ok, thank you! > > May I ask why? The current default is to be strict on client side > > regardless of the interoprability issues with unupgraded servers. > > Why should the default change in the future to the less strict one, > > even though fewer servers are expected to require it at that time? > > I must have been misunderstood. The strict default on the client will > stay as is in the future. The server behavior that is permissive to > old clients might change in the future. My misunderstanding apparently, sorry. But my previous point should still be valid: as %INITIAL_SAFE_RENEGOTIATION has no impact on client, it probably should/does not be documented in gnutls-cli manpage, or be documented as 'default' that can not be overriden. th. From nmav at gnutls.org Sun Mar 7 09:10:06 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 07 Mar 2010 09:10:06 +0100 Subject: Another renegotiation patch In-Reply-To: <20100304140557.7890290e@redhat.com> References: <4B58BC18.7030100@gnutls.org> <873a0zklc5.fsf@mocca.josefsson.org> <20100218125241.0c826a70@redhat.com> <87wryag1wh.fsf@mocca.josefsson.org> <20100218150455.1a4d1195@redhat.com> <20100224170648.11c5c9bb@redhat.com> <4B880BB9.1070300@gnutls.org> <20100227173024.7f7a0ff3@redhat.com> <4B8E3F71.80304@gnutls.org> <20100304140557.7890290e@redhat.com> Message-ID: <4B935F5E.5040104@gnutls.org> Tomas Hoger wrote: >>> May I ask why? The current default is to be strict on client side >>> regardless of the interoprability issues with unupgraded servers. >>> Why should the default change in the future to the less strict one, >>> even though fewer servers are expected to require it at that time? >> I must have been misunderstood. The strict default on the client will >> stay as is in the future. The server behavior that is permissive to >> old clients might change in the future. > > My misunderstanding apparently, sorry. But my previous point should > still be valid: as %INITIAL_SAFE_RENEGOTIATION has no impact on client, > it probably should/does not be documented in gnutls-cli manpage, or be > documented as 'default' that can not be overriden. Hi, Indeed you're right. Initially it wasn't sure whether this will be the default or not, that's why it wasn't mentioned. I've now added to the description that this enabled by default. regards, Nikos From nmav at gnutls.org Sun Mar 7 10:35:03 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 07 Mar 2010 10:35:03 +0100 Subject: Remove artificial constraint in _gnutls_x509_verify_certificate In-Reply-To: <1267615915.26237.468.camel@vespa.frost.loc> References: <1267562647.26237.373.camel@vespa.frost.loc> <4B8D8460.50406@gnutls.org> <1267615915.26237.468.camel@vespa.frost.loc> Message-ID: <4B937347.70503@gnutls.org> Tomas Mraz wrote: > On Tue, 2010-03-02 at 22:34 +0100, Nikos Mavrogiannopoulos wrote: >> Tomas Mraz wrote: >>> Hi, >>> I was examining the current _gnutls_x509_verify_certificate() code and I >>> found that the code does not allow unconditionally accepting the site >>> certificate if it is on the trust list. I think that this is unnecessary >>> restriction which should be removed. >> Please elaborate. What is the scenario that wasn't working before and >> you believe you fixed with this patch? > > For example when the site certificate is expired and/or uses unsafe > algorithm for its signature and you put it on the trusted list on client > to alleviate the problem. Hi, Sorry for the late reply but needed to find some time to check the verification process carefully. Indeed your suggestion makes sense and doesn't seem to have side-effects. I've commited it. regards, Nikos From mann.patidar at gmail.com Mon Mar 8 18:21:45 2010 From: mann.patidar at gmail.com (Manish Patidar) Date: Mon, 8 Mar 2010 22:51:45 +0530 Subject: GNU TLS 2.9.9 , sign/hash extension support Message-ID: <8062bfc61003080921m7817ec14le719a8a4afe91ae0@mail.gmail.com> Hi , I was going through the GNU TLS 2.9.9 source code that support TLS 1.2. I have following doubts in gnutls that support of TLS 1.2 rfc 1. While selecting server cert and chain, GNUTLS just compare server certificate with client requested sign/hash extension, not the whole chain. if it matched one of the server certificate , it will select the chain. but according to TLS 1.2 , whole chain must matched with one of the sign/hash algo supported by client. Is my understanding is correct ..? If not , how and which part of code GNU TLS compare the sign/hash algo with the whole chain. 2. While selecting client cert list in response of client cert request, GNU TLS doesn't use parsed sign/hash algo supported server. it just use the cert type and dns name for selecting cert chain ,not sign/hash algo but according to TLS 1.2 , client must compare and select cert chain that matches with one of the sign/hash supported by server. Please let me know if am correct or not. Please provide some of your valuable inputs which clarify above point Regards Manish -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Mar 8 18:45:24 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 08 Mar 2010 18:45:24 +0100 Subject: GNU TLS 2.9.9 , sign/hash extension support In-Reply-To: <8062bfc61003080921m7817ec14le719a8a4afe91ae0@mail.gmail.com> References: <8062bfc61003080921m7817ec14le719a8a4afe91ae0@mail.gmail.com> Message-ID: <4B9537B4.8080200@gnutls.org> Manish Patidar wrote: > Hi , > > I was going through the GNU TLS 2.9.9 source code that support TLS 1.2. > I have following doubts in gnutls that support of TLS 1.2 rfc > > 1. While selecting server cert and chain, GNUTLS just compare server > certificate with client requested sign/hash extension, not the whole chain. > > if it matched one of the server certificate , it will select the chain. > but according to TLS 1.2 , whole chain must matched with one of the > sign/hash algo supported by client. > > Is my understanding is correct ..? which part of TLS 1.2 are you referring to? regards, Nikos From tmraz at redhat.com Tue Mar 9 14:14:23 2010 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 09 Mar 2010 14:14:23 +0100 Subject: Safe renegotiation in SSL3 protocol not working Message-ID: <1268140463.6485.15.camel@vespa.frost.loc> The safe renegotiation in SSL3 protocol is failing on client side because during the renegotiation the safe renegotiation extension is not recognized as expected extension. This is caused by missing call to _gnutls_extension_list_add(). The attached patch fixes this. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-reneg-ssl3.patch Type: text/x-patch Size: 452 bytes Desc: not available URL: From ludo at gnu.org Thu Mar 11 12:28:45 2010 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 11 Mar 2010 12:28:45 +0100 Subject: Test failure of =?utf-8?b?4oCYY2hhaW52ZXJpZnnigJk=?= Message-ID: <87pr3b3xn6.fsf@gnu.org> Hello, The ?chainverify? test currently fails with the latest libtasn1 and libgcrypt: --8<---------------cut here---------------start------------->8--- Chain 'verisign.com v1 fail' (1)... Adding certificate 0...done Certificate 0: subject `serialNumber=2497886,1.3.6.1.4.1.311.60.2.1.3=#13025553,1.3.6.1.4.1.311.60.2.1.2=#130844656c6177617265,C=US,2.5.4.17=#14053934303433,ST=California,L=Mountain View,STREET=487 East Middlefield Road,O=VeriSign\, Inc.,OU=Production Security Services,OU=Terms of use at www.verisign.com/rpa (c)06,CN=www.verisign.com', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)06,CN=VeriSign Class 3 Extended Validation SSL SGC CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2007-05-09 00:00:00 UTC', expires `2009-05-08 23:59:59 UTC', SHA-1 fingerprint `c6750e8da95f5a65bb046d6079d4fc87402e0381' Adding certificate 1...done Certificate 1: subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)06,CN=VeriSign Class 3 Extended Validation SSL SGC CA', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-08 00:00:00 UTC', expires `2016-11-07 23:59:59 UTC', SHA-1 fingerprint `4a8a2a0e276ff33b5dd88a362146010f2a8b6aee' Adding certificate 2...done Certificate 2: subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-08 00:00:00 UTC', expires `2021-11-07 23:59:59 UTC', SHA-1 fingerprint `7e7e026f71bfe7bbc7e7e5c591b1915cb6684e6c' Adding certificate 3...done Certificate 3: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2' Adding CA certificate...done CA Certificate: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority|<2>| ASSERT: verify.c:181 |<2>| ASSERT: verify.c:313 |<2>| ASSERT: verify.c:482 |<2>| ASSERT: dn.c:304 |<2>| ASSERT: dn.c:304 |<2>| ASSERT: dn.c:304 |<2>| ASSERT: dn.c:304 |<2>| ASSERT: dn.c:304 |<2>| ASSERT: dn.c:304 |<2>| ASSERT: dn.c:304 |<2>| ASSERT: dn.c:304 |<2>| ASSERT: dn.c:304 |<2>| ASSERT: dn.c:304 |<2>| ASSERT: dn.c:1211 |<2>| ASSERT: dn.c:304 |<2>| ASSERT: dn.c:304 |<2>| ASSERT: dn.c:304 |<2>| ASSERT: dn.c:304 --8<---------------cut here---------------end--------------->8--- (From .) Ideas? Thanks, Ludo?. From nmav at gnutls.org Thu Mar 11 12:42:04 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Mar 2010 12:42:04 +0100 Subject: =?windows-1252?q?Re=3A_Test_failure_of_=91chainverify=92?= In-Reply-To: <87pr3b3xn6.fsf@gnu.org> References: <87pr3b3xn6.fsf@gnu.org> Message-ID: Hi, There has been some change in the verification code and might be related. I'll check it this evening. regards, Nikos On Thu, Mar 11, 2010 at 12:28 PM, Ludovic Court?s wrote: > Hello, > > The ?chainverify? test currently fails with the latest libtasn1 and > libgcrypt: > > --8<---------------cut here---------------start------------->8--- > Chain 'verisign.com v1 fail' (1)... > ? ? ? ?Adding certificate 0...done > ? ? ? ?Certificate 0: subject `serialNumber=2497886,1.3.6.1.4.1.311.60.2.1.3=#13025553,1.3.6.1.4.1.311.60.2.1.2=#130844656c6177617265,C=US,2.5.4.17=#14053934303433,ST=California,L=Mountain View,STREET=487 East Middlefield Road,O=VeriSign\, Inc.,OU=Production Security Services,OU=Terms of use at www.verisign.com/rpa (c)06,CN=www.verisign.com', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)06,CN=VeriSign Class 3 Extended Validation SSL SGC CA', RSA key 1024 bits, signed using RSA-SHA1, activated `2007-05-09 00:00:00 UTC', expires `2009-05-08 23:59:59 UTC', SHA-1 fingerprint `c6750e8da95f5a65bb046d6079d4fc87402e0381' > ? ? ? ?Adding certificate 1...done > ? ? ? ?Certificate 1: subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)06,CN=VeriSign Class 3 Extended Validation SSL SGC CA', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-08 00:00:00 UTC', expires `2016-11-07 23:59:59 UTC', SHA-1 fingerprint `4a8a2a0e276ff33b5dd88a362146010f2a8b6aee' > ? ? ? ?Adding certificate 2...done > ? ? ? ?Certificate 2: subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-08 00:00:00 UTC', expires `2021-11-07 23:59:59 UTC', SHA-1 fingerprint `7e7e026f71bfe7bbc7e7e5c591b1915cb6684e6c' > ? ? ? ?Adding certificate 3...done > ? ? ? ?Certificate 3: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-MD2 (broken!), activated `1996-01-29 00:00:00 UTC', expires `2028-08-01 23:59:59 UTC', SHA-1 fingerprint `742c3192e607e424eb4549542be1bbc53e6174e2' > ? ? ? ?Adding CA certificate...done > ? ? ? ?CA Certificate: subject `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority|<2>| ASSERT: verify.c:181 > |<2>| ASSERT: verify.c:313 > |<2>| ASSERT: verify.c:482 > |<2>| ASSERT: dn.c:304 > |<2>| ASSERT: dn.c:304 > |<2>| ASSERT: dn.c:304 > |<2>| ASSERT: dn.c:304 > |<2>| ASSERT: dn.c:304 > |<2>| ASSERT: dn.c:304 > |<2>| ASSERT: dn.c:304 > |<2>| ASSERT: dn.c:304 > |<2>| ASSERT: dn.c:304 > |<2>| ASSERT: dn.c:304 > |<2>| ASSERT: dn.c:1211 > |<2>| ASSERT: dn.c:304 > |<2>| ASSERT: dn.c:304 > |<2>| ASSERT: dn.c:304 > |<2>| ASSERT: dn.c:304 > --8<---------------cut here---------------end--------------->8--- > > (From .) > > Ideas? > > Thanks, > Ludo?. > > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > From nmav at gnutls.org Thu Mar 11 20:58:34 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Mar 2010 20:58:34 +0100 Subject: Test failure of =?utf-8?b?4oCYY2hhaW52ZXJpZnnigJk=?= In-Reply-To: <87pr3b3xn6.fsf@gnu.org> References: <87pr3b3xn6.fsf@gnu.org> Message-ID: <4B994B6A.80301@gnutls.org> Ludovic Court?s wrote: > Hello, > > The ?chainverify? test currently fails with the latest libtasn1 and > libgcrypt: Ok it seems that the test that verifies an expired trusted certificate fails. That is because the current code considers trusted as ultimately trusted even for the first certificate in the chain (the previous code did that for all except for the first one- end user). This uncovered an issue since there was no consistent treat of the certificates in the trusted list. I believe the current behavior is fine and rational (trust unconditionally anything in the trusted list), but there might be arguments for not allowing weak algorithms and expired certificates in the trusted list (or have additional flag(s) for them). What do you think? regards, Nikos From nmav at gnutls.org Thu Mar 11 21:27:46 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Mar 2010 21:27:46 +0100 Subject: Safe renegotiation in SSL3 protocol not working In-Reply-To: <1268140463.6485.15.camel@vespa.frost.loc> References: <1268140463.6485.15.camel@vespa.frost.loc> Message-ID: <4B995242.7020204@gnutls.org> Tomas Mraz wrote: > The safe renegotiation in SSL3 protocol is failing on client side > because during the renegotiation the safe renegotiation extension is not > recognized as expected extension. This is caused by missing call to > _gnutls_extension_list_add(). The attached patch fixes this. As usual you are correct :) I've fixed it somewhat differently. Thank you for reporting it. best regards, Nikos From ludo at gnu.org Thu Mar 11 21:35:08 2010 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 11 Mar 2010 21:35:08 +0100 Subject: Test failure of =?utf-8?b?4oCYY2hhaW52ZXJpZnnigJk=?= In-Reply-To: <4B994B6A.80301@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 11 Mar 2010 20:58:34 +0100") References: <87pr3b3xn6.fsf@gnu.org> <4B994B6A.80301@gnutls.org> Message-ID: <87tysm1ts3.fsf@gnu.org> Hi Nikos, Nikos Mavrogiannopoulos writes: > Ludovic Court?s wrote: >> Hello, >> >> The ?chainverify? test currently fails with the latest libtasn1 and >> libgcrypt: > > Ok it seems that the test that verifies an expired trusted certificate > fails. That is because the current code considers trusted as ultimately > trusted even for the first certificate in the chain (the previous code > did that for all except for the first one- end user). > > This uncovered an issue since there was no consistent treat of the > certificates in the trusted list. I believe the current behavior is fine > and rational (trust unconditionally anything in the trusted list), but > there might be arguments for not allowing weak algorithms and expired > certificates in the trusted list (or have additional flag(s) for them). > > What do you think? Not much. :-) I?m not an X509 person and definitely not a fan of hierarchical trust models with holly certification authorities. In the context of OpenPGP I?d say that verifying certificates is really user- and/or application-dependent. For instance, some might want to take expiration dates into account while others might not care (after all, a time stamp in an OpenPGP public key doesn?t mean much.) For X509 it may be that the best that can be done is to follow the spirit of the standard, however questionable it may be. My 2?... Thanks, Ludo?. From tmraz at redhat.com Fri Mar 12 09:45:17 2010 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 12 Mar 2010 09:45:17 +0100 Subject: Test failure of =?utf-8?b?4oCYY2hhaW52ZXJpZnnigJk=?= In-Reply-To: <4B994B6A.80301@gnutls.org> References: <87pr3b3xn6.fsf@gnu.org> <4B994B6A.80301@gnutls.org> Message-ID: <1268383517.24408.74.camel@vespa.frost.loc> On Thu, 2010-03-11 at 20:58 +0100, Nikos Mavrogiannopoulos wrote: > Ludovic Court?s wrote: > > Hello, > > > > The ?chainverify? test currently fails with the latest libtasn1 and > > libgcrypt: > > Ok it seems that the test that verifies an expired trusted certificate > fails. That is because the current code considers trusted as ultimately > trusted even for the first certificate in the chain (the previous code > did that for all except for the first one- end user). > > This uncovered an issue since there was no consistent treat of the > certificates in the trusted list. I believe the current behavior is fine > and rational (trust unconditionally anything in the trusted list), but > there might be arguments for not allowing weak algorithms and expired > certificates in the trusted list (or have additional flag(s) for them). > > What do you think? I think you know my opinion, because this was one of my reasons why I've proposed the patch which implements the current behavior. I do not think that certificates which are directly on the trusted list should be rejected if they are expired or signed with a weak algorithm. There might be a slight argument for the expiry check because the expiration might happen behind the notice of the user who put it to the trusted list and arguably the expiration time signals that the private-key/certificate should not be used after the time. However for the weak algorithm check there is no reason at all because the signature of the certificate is not relevant if we trust the public-key of the certificate directly. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From dkg at fifthhorseman.net Fri Mar 12 17:38:41 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 12 Mar 2010 11:38:41 -0500 Subject: Test failure of =?utf-8?b?4oCYY2hhaW52ZXJpZnnigJk=?= In-Reply-To: <1268383517.24408.74.camel@vespa.frost.loc> References: <87pr3b3xn6.fsf@gnu.org> <4B994B6A.80301@gnutls.org> <1268383517.24408.74.camel@vespa.frost.loc> Message-ID: <4B9A6E11.6090702@fifthhorseman.net> On 03/12/2010 03:45 AM, Tomas Mraz wrote: > I do not think > that certificates which are directly on the trusted list should be > rejected if they are expired or signed with a weak algorithm. There > might be a slight argument for the expiry check because the expiration > might happen behind the notice of the user who put it to the trusted > list and arguably the expiration time signals that the > private-key/certificate should not be used after the time. I think that trusting listed certificates after their internally-stated expiry could be a surprising experience for users (in a bad way). Maybe we need a way for a user to communicate to the library that she wants to trust a given certificate beyond its internal expiry? > However for > the weak algorithm check there is no reason at all because the signature > of the certificate is not relevant if we trust the public-key of the > certificate directly. I agree that the type of digest algorithm used in the signature (whether self-signed or not) is irrelevant for certificates in the trusted list. However, ignoring weak digests does not mean we should ignore *all* weak algorithm checks for these certificates. For example, if a 512-bit RSA key would not be acceptable elsewhere in the chain, we should not accept it in the trusted root list. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Sun Mar 14 23:05:23 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 14 Mar 2010 23:05:23 +0100 Subject: Test failure of =?utf-8?b?4oCYY2hhaW52ZXJpZnnigJk=?= In-Reply-To: <4B9A6E11.6090702@fifthhorseman.net> References: <87pr3b3xn6.fsf@gnu.org> <4B994B6A.80301@gnutls.org> <1268383517.24408.74.camel@vespa.frost.loc> <4B9A6E11.6090702@fifthhorseman.net> Message-ID: <4B9D5DA3.2000506@gnutls.org> Daniel Kahn Gillmor wrote: >> I do not think >> that certificates which are directly on the trusted list should be >> rejected if they are expired or signed with a weak algorithm. There >> might be a slight argument for the expiry check because the expiration >> might happen behind the notice of the user who put it to the trusted >> list and arguably the expiration time signals that the >> private-key/certificate should not be used after the time. > > I think that trusting listed certificates after their internally-stated > expiry could be a surprising experience for users (in a bad way). > > Maybe we need a way for a user to communicate to the library that she > wants to trust a given certificate beyond its internal expiry? I've thought of it and the less intruding change that I found, that could solve this issue, is the introduction of a flag to disable time checks for the trusted certificate list. Otherwise always check the trusted list certificates for expiration during verification. I've committed it with 897cbce62c0263a498088ac3e465aa5f05f8719c. I thought it was quite important to be included to the release. > However, ignoring weak digests does not mean we should ignore *all* weak > algorithm checks for these certificates. For example, if a 512-bit RSA > key would not be acceptable elsewhere in the chain, we should not accept > it in the trusted root list. This is a different issue. Current we have no such checking... regards, Nikos From ludo at gnu.org Sun Mar 14 23:16:36 2010 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Sun, 14 Mar 2010 23:16:36 +0100 Subject: Test failure of =?utf-8?b?4oCYY2hhaW52ZXJpZnnigJk=?= In-Reply-To: <4B9D5DA3.2000506@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 14 Mar 2010 23:05:23 +0100") References: <87pr3b3xn6.fsf@gnu.org> <4B994B6A.80301@gnutls.org> <1268383517.24408.74.camel@vespa.frost.loc> <4B9A6E11.6090702@fifthhorseman.net> <4B9D5DA3.2000506@gnutls.org> Message-ID: <87hboia6rf.fsf@gnu.org> Hi Nikos, Nikos Mavrogiannopoulos writes: > I've thought of it and the less intruding change that I found, that > could solve this issue, is the introduction of a flag to disable time > checks for the trusted certificate list. Otherwise always check the > trusted list certificates for expiration during verification. > I've committed it with 897cbce62c0263a498088ac3e465aa5f05f8719c. There?s a remaining issue on Hydra builds with ?testsrn? [0]: the test expects ?localhost? to resolve, which fails in the build chroots (they lack /etc/{hosts,resolv.conf}). Replacing ?localhost? with ?127.0.0.1? will do the trick. Could you do that? Thanks, Ludo?. [0] http://hydra.nixos.org/build/325341 From nmav at gnutls.org Mon Mar 15 00:01:34 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 15 Mar 2010 00:01:34 +0100 Subject: Test failure of =?utf-8?b?4oCYY2hhaW52ZXJpZnnigJk=?= In-Reply-To: <87hboia6rf.fsf@gnu.org> References: <87pr3b3xn6.fsf@gnu.org> <4B994B6A.80301@gnutls.org> <1268383517.24408.74.camel@vespa.frost.loc> <4B9A6E11.6090702@fifthhorseman.net> <4B9D5DA3.2000506@gnutls.org> <87hboia6rf.fsf@gnu.org> Message-ID: <4B9D6ACE.10405@gnutls.org> Ludovic Court?s wrote: > Hi Nikos, > > Nikos Mavrogiannopoulos writes: > >> I've thought of it and the less intruding change that I found, that >> could solve this issue, is the introduction of a flag to disable time >> checks for the trusted certificate list. Otherwise always check the >> trusted list certificates for expiration during verification. >> I've committed it with 897cbce62c0263a498088ac3e465aa5f05f8719c. > > There?s a remaining issue on Hydra builds with ?testsrn? [0]: the test > expects ?localhost? to resolve, which fails in the build chroots (they > lack /etc/{hosts,resolv.conf}). Replacing ?localhost? with ?127.0.0.1? > will do the trick. > > Could you do that? done. From ludo at gnu.org Mon Mar 15 00:34:22 2010 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 15 Mar 2010 00:34:22 +0100 Subject: Test failure of =?utf-8?b?4oCYY2hhaW52ZXJpZnnigJk=?= In-Reply-To: <4B9D6ACE.10405@gnutls.org> (Nikos Mavrogiannopoulos's message of "Mon, 15 Mar 2010 00:01:34 +0100") References: <87pr3b3xn6.fsf@gnu.org> <4B994B6A.80301@gnutls.org> <1268383517.24408.74.camel@vespa.frost.loc> <4B9A6E11.6090702@fifthhorseman.net> <4B9D5DA3.2000506@gnutls.org> <87hboia6rf.fsf@gnu.org> <4B9D6ACE.10405@gnutls.org> Message-ID: <87d3z6a35t.fsf@gnu.org> Works like a charm, thanks! Ludo?. From simon at josefsson.org Mon Mar 15 14:23:00 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 15 Mar 2010 14:23:00 +0100 Subject: GnuTLS 2.8.6 Message-ID: <87fx411zyj.fsf@mocca.josefsson.org> We are proud to announce a new stable GnuTLS release: Version 2.8.6. 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: For CSRs, don't null pad integers for RSA/DSA value. VeriSign rejected CSRs with this padding. Reported by Wilankar Trupti and Boyan Kasarov . Note: As a side effect of this change, the "public key identifier" value computed for a certificate using this version of GnuTLS will be different from values computed using earlier versions of GnuTLS. ** libgnutls: For CSRs on DSA keys, don't add DSA parameters to the ** optional SignatureAlgorithm parameter field. VeriSign rejected these CSRs. They are stricly speaking not needed since you need the signer's certificate to verify the certificate signature anyway. Reported by Wilankar Trupti and Boyan Kasarov . ** libgnutls: When checking openpgp self signature also check the signatures ** of all subkeys. Ilari Liusvaara noticed and reported the issue and provided test vectors as well. ** libgnutls: Cleanups and several bug fixes. Found by Steve Grubb and Tomas Mraz. ** Link libgcrypt explicitly to certtool, gnutls-cli, gnutls-serv. ** Fix --disable-valgrind-tests. Reported by Ingmar Vanhassel in . ** examples: Use the new APIs for printing X.509 certificate information. ** Fix build failures on Solaris. Thanks to Dagobert Michelsen . ** i18n: Updated Czech, Dutch, French, Polish, Swedish and Vietnamese ** translations. Added Simplified Chinese translation. ** 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.2MB): ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.6.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.6.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.6.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.6.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.6.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: 2011-03-30] 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: 2011-03-30] 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: bff911d4fd7389aa6698a644b3748eb2d23715bc gnutls-2.8.6.tar.bz2 a6b36fa1926a7fd3cb68746446c29dc1cbef0cc6bcfd25877fde64ad gnutls-2.8.6.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.5, libtasn1 v2.4, and GnuTLS v2.8.6. 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.6.exe (16MB) http://josefsson.org/gnutls4win/gnutls-2.8.6.exe.sig The checksum values for SHA-1 and SHA-224 are: cbfc717d33edbc1f6eb891e14e5d6935bcfb7dc6 gnutls-2.8.6.exe 42e5bc23dd110de93f36d1e4e13447083d4127e1da18b190f02b4031 gnutls-2.8.6.exe A ZIP archive containing the Windows binaries: http://josefsson.org/gnutls4win/gnutls-2.8.6.zip (5.3MB) http://josefsson.org/gnutls4win/gnutls-2.8.6.zip.sig The checksum values for SHA-1 and SHA-224 are: 5009ea643cad906e86ec85d3d3814ac78a73e66a gnutls-2.8.6.zip 965b5c535956ea8f8b0d93b3badd1ce23d21624a6fa35a05fa20919f gnutls-2.8.6.zip A Debian mingw32 package is also available: http://josefsson.org/gnutls4win/mingw32-gnutls_2.8.6-1_all.deb (4.8MB) The checksum values for SHA-1 and SHA-224 are: 8719083d715ad5f244265bfeebedf491112f6a8a mingw32-gnutls_2.8.6-1_all.deb ef6b6b927968ea393ee3571a649d325232c33ee92335eaf2dc090c55 mingw32-gnutls_2.8.6-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: 420 bytes Desc: not available URL: From simon at josefsson.org Mon Mar 15 14:44:25 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 15 Mar 2010 14:44:25 +0100 Subject: GNU Libtasn1 2.5 Message-ID: <87bpep1yyu.fsf@mocca.josefsson.org> GNU Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding/decoding. GNU Libtasn1 is used by GnuTLS to handle X.509 structures and by GNU Shishi to handle Kerberos V5 structures. * Noteworthy changes in release 2.5 (2010-03-15) [stable] - doc: Improve GTK-DOC comments. - misc: Updated gnulib files. Homepage: http://www.gnu.org/software/libtasn1/ Here are the compressed sources (1.7MB): ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz Here are GPG detached signatures using key 0xB565716F: ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz.sig http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz.sig A ZIP archive containing the Windows binaries (264KB): http://josefsson.org/gnutls4win/libtasn1-2.5.zip http://josefsson.org/gnutls4win/libtasn1-2.5.zip.sig A Debian mingw32 package is also available (240KB): http://josefsson.org/gnutls4win/mingw32-libtasn1_2.5-1_all.deb Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join the help-gnutls mailing list, see: . All manuals are available from: http://www.gnu.org/software/gsasl/manual/ Specifically, the following formats are available. The main manual: HTML: http://www.gnu.org/software/gsasl/manual/gsasl.html PDF: http://www.gnu.org/software/gsasl/manual/gsasl.pdf API Reference manual: http://www.gnu.org/software/gsasl/reference/ - GTK-DOC 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/ The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2011-03-30] 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: 2011-03-30] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: e317282a86702fb57133b50199df47a7fcf681ca libtasn1-2.5.tar.gz 69e53bb61f3512aa8d1eb72640778b4adebf6818a4493548cc7faf2d libtasn1-2.5.tar.gz 784faa0f4aff35aee1ac420013a9e47aa4892d12 libtasn1-2.5.zip 98177b4e5cbc3bae34dd7813940bec99c802275c9dd0cb77f06a1d3d libtasn1-2.5.zip a5427f26d051a3ab30a8f5bea0abcdf6d3d83f0f mingw32-libtasn1_2.5-1_all.deb 6e781ec4652f8d3fd58e3742dd19f69804665356c11c50e179ed1756 mingw32-libtasn1_2.5-1_all.deb Happy hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 420 bytes Desc: not available URL: From ametzler at downhill.at.eu.org Mon Mar 15 18:53:42 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon, 15 Mar 2010 18:53:42 +0100 Subject: wrong gnutls.pc In-Reply-To: <20100228122418.GB3463@downhill.g.la> References: <222ade941002260357p1cede669jf4cf204525460de3@mail.gmail.com> <20100226183026.GA3529@downhill.g.la> <20100228122418.GB3463@downhill.g.la> Message-ID: <20100315175342.GB3278@downhill.g.la> On 2010-02-28 Andreas Metzler wrote: [...] > Patches against git head attached. This should also go to the 2.8.x > series. Saved as http://savannah.gnu.org/support/?107310 cu andreas From simon at josefsson.org Mon Mar 15 19:42:05 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 15 Mar 2010 19:42:05 +0100 Subject: wrong gnutls.pc In-Reply-To: <20100315175342.GB3278@downhill.g.la> (Andreas Metzler's message of "Mon, 15 Mar 2010 18:53:42 +0100") References: <222ade941002260357p1cede669jf4cf204525460de3@mail.gmail.com> <20100226183026.GA3529@downhill.g.la> <20100228122418.GB3463@downhill.g.la> <20100315175342.GB3278@downhill.g.la> Message-ID: <87aau9xw8y.fsf@mocca.josefsson.org> Andreas Metzler writes: > On 2010-02-28 Andreas Metzler wrote: > [...] >> Patches against git head attached. This should also go to the 2.8.x >> series. > > Saved as http://savannah.gnu.org/support/?107310 Oops, I missed that for 2.8.6. Is the patch in savannah still the best version? I think we could apply it easily soon. /Simon From vincent.torri at gmail.com Mon Mar 15 19:54:18 2010 From: vincent.torri at gmail.com (Vincent Torri) Date: Mon, 15 Mar 2010 19:54:18 +0100 Subject: wrong gnutls.pc In-Reply-To: <20100315175342.GB3278@downhill.g.la> References: <222ade941002260357p1cede669jf4cf204525460de3@mail.gmail.com> <20100226183026.GA3529@downhill.g.la> <20100228122418.GB3463@downhill.g.la> <20100315175342.GB3278@downhill.g.la> Message-ID: <222ade941003151154t18060f07o2a933c915f5fa010@mail.gmail.com> On Mon, Mar 15, 2010 at 6:53 PM, Andreas Metzler < ametzler at downhill.at.eu.org> wrote: > On 2010-02-28 Andreas Metzler wrote: > [...] > > Patches against git head attached. This should also go to the 2.8.x > > series. > > Saved as http://savannah.gnu.org/support/?107310 > cu andreas > I don't know if the last version has the patch or if it is only in git, but i'll test gnutls soon on Windows. I'll write a small tuto for the project i'm working on on Windows and which needs gnutls, so, if you want, you can use it. Vincent Torri -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.torri at gmail.com Mon Mar 15 19:56:11 2010 From: vincent.torri at gmail.com (Vincent Torri) Date: Mon, 15 Mar 2010 19:56:11 +0100 Subject: wrong gnutls.pc In-Reply-To: <87aau9xw8y.fsf@mocca.josefsson.org> References: <222ade941002260357p1cede669jf4cf204525460de3@mail.gmail.com> <20100226183026.GA3529@downhill.g.la> <20100228122418.GB3463@downhill.g.la> <20100315175342.GB3278@downhill.g.la> <87aau9xw8y.fsf@mocca.josefsson.org> Message-ID: <222ade941003151156t5d7dde3o50ee2b8951cccd70@mail.gmail.com> On Mon, Mar 15, 2010 at 7:42 PM, Simon Josefsson wrote: > Andreas Metzler writes: > > > On 2010-02-28 Andreas Metzler wrote: > > [...] > >> Patches against git head attached. This should also go to the 2.8.x > >> series. > > > > Saved as http://savannah.gnu.org/support/?107310 > > Oops, I missed that for 2.8.6. Is the patch in savannah still the best > version? I think we could apply it easily soon. > > ok, i'll test the git version, then Btw, if you want, i can provide patches for the autotools stuff. There are things that can be improved, imho. Vincent Torri -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Mar 15 21:46:33 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 15 Mar 2010 21:46:33 +0100 Subject: safe renegotiation in client side Message-ID: <4B9E9CA9.4070901@gnutls.org> As you may have noticed there was a big fuss lately about a bug in the TLS protocol that could cause a client to connect to the wrong server via a renegotiation. There is a fix to the protocol that is unfortunately incompatible with previous versions (if security is required). Thus a gnutls client implementing the fix cannot connect to any non-patched server[0]. To achieve compatibility one has to to explicitly allow unsafe renegotiation with a priority string. This is not always possible since gnutls might be used unintentionally by a program via another library. With some trials in my system I noticed that the current behavior causes denial of service and a simple user might not even have control over the priority string for gnutls. Given your experiences (as system packager, user, implementor or so), what do you think is the adoption of priority strings in programs? Given a program that uses gnutls is it easy to set a string with the algorithms etc. needed for the negotiation? I have been in favor of enabling safe renegotiation for the client before, but seeing how gnutls is being used today, I might have not been correct and enabling it might cause more trouble than the issue it solves. Please let me know of what you think. regards, Nikos [0]. so far the fix adoption wasn't that great. From simon at josefsson.org Mon Mar 15 22:00:59 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 15 Mar 2010 22:00:59 +0100 Subject: safe renegotiation in client side In-Reply-To: <4B9E9CA9.4070901@gnutls.org> (Nikos Mavrogiannopoulos's message of "Mon, 15 Mar 2010 21:46:33 +0100") References: <4B9E9CA9.4070901@gnutls.org> Message-ID: <873a01wb90.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Given your experiences (as system packager, user, implementor or so), > what do you think is the adoption of priority strings in programs? I find it quite rare still, sadly. I don't recall _any_ application that allows users to configure priority strings per-IP address, which would be the optimal approach. I believe it would be painful to release a GnuTLS client that refused to talk to non-patched servers. If I understand correctly, it doesn't improve anything for the client to behave like that, it is only the server that is protected by such a client. Thus, I think we should let servers require patched clients when it makes sense, and otherwise be more lenient on the client side. I wish there was an easy way to warn the user somehow though. Syslog a message with the server hostname? Should we add a function so that applications can find out if a session is potentially insecure due to this threat? Any way to make it less specific to renegotiation issues? We have other areas that users may want to be aware of too -- e.g., if the connection is using a weak cipher, if the connection is not using DHE, etc... OTOH maybe this is overkill. Power-users can use gnutls-cli to find out manually, and other users are probably fine with a lenient default anyway. /Simon From dkg at fifthhorseman.net Mon Mar 15 22:30:29 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 15 Mar 2010 17:30:29 -0400 Subject: safe renegotiation in client side In-Reply-To: <873a01wb90.fsf@mocca.josefsson.org> References: <4B9E9CA9.4070901@gnutls.org> <873a01wb90.fsf@mocca.josefsson.org> Message-ID: <4B9EA6F5.4000805@fifthhorseman.net> On 03/15/2010 05:00 PM, Simon Josefsson wrote: > I believe it would be painful to release a GnuTLS client that refused to > talk to non-patched servers. I agree that it would be painful. > If I understand correctly, it doesn't > improve anything for the client to behave like that, it is only the > server that is protected by such a client. I don't think this is the case. A client connecting to an unpatched server is vulnerable to their connection being used to authenticate another request that they are unaware of. The attack in question is a plaintext prefix injection attack: the attacker starts a session with the server, and then prompts a re-negotiation. It hands off the re-negotiation to the actual client, which might then negotiate to the server thinking that it is the initial connection (not a re-negotiation). If the server then uses the new connections credentials to act on the original (spoofed) part of the session, it is the *client's* credentials which have been mis-applied, not the server's. clients which "fail closed" by rejecting connections to unpatched servers cannot have their credentials mis-applied in this way. (they also won't be able to talk to the majority of the TLS-capable hosts on the 'net today, unfortunately). > Thus, I think we should let > servers require patched clients when it makes sense, and otherwise be > more lenient on the client side. libnss (the mozilla tls implementation) has an interesting phased approach planned to deal with this situation: https://wiki.mozilla.org/Security:Renegotiation i know gnutls doesn't expose as much in the way of a UI as NSS clients like firefox or thunderbird; but if there's some way to adopt a similar approach, i'd like to examine it. Every libgnutls-aware program can see the environment, for example. is using a clearly-scoped environment variable to provide a priority string if none other are supplied out of the question? Or what about ~/.libgnutls/config or something similar? I'm just brainstorming here, feel free to explain why these are horrible proposals. > I wish there was an easy way to warn the user somehow though. Syslog a > message with the server hostname? Should we add a function so that > applications can find out if a session is potentially insecure due to > this threat? Any way to make it less specific to renegotiation issues? > We have other areas that users may want to be aware of too -- e.g., if > the connection is using a weak cipher, if the connection is not using > DHE, etc... OTOH maybe this is overkill. Power-users can use > gnutls-cli to find out manually, and other users are probably fine with > a lenient default anyway. gnutls-cli can find out manually for a different connection -- it won't let you inspect an active connection, will it? i agree that configurable reporting would be useful, though (and i like your assessment of the other concerns we might want to permit but warn about). Seems like a generic interface would be a way for library users register a callback that reports "warnings about your connection", along with an enumerated list (and maybe localized strings describing the problems). I like that idea, but if we can't convince application developers to let end users pass in a priority string, it seems unlikely that we'd get them to register such a callback, let alone report the warnings to their users in a sane way :/ --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From tmraz at redhat.com Mon Mar 15 22:31:30 2010 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 15 Mar 2010 22:31:30 +0100 Subject: safe renegotiation in client side In-Reply-To: <4B9E9CA9.4070901@gnutls.org> References: <4B9E9CA9.4070901@gnutls.org> Message-ID: <1268688690.24408.284.camel@vespa.frost.loc> On Mon, 2010-03-15 at 21:46 +0100, Nikos Mavrogiannopoulos wrote: > As you may have noticed there was a big fuss lately about a bug in the > TLS protocol that could cause a client to connect to the wrong server > via a renegotiation. There is a fix to the protocol that is > unfortunately incompatible with previous versions (if security is > required). Thus a gnutls client implementing the fix cannot connect to > any non-patched server[0]. To achieve compatibility one has to to > explicitly allow unsafe renegotiation with a priority string. This is > not always possible since gnutls might be used unintentionally by a > program via another library. > > With some trials in my system I noticed that the current behavior causes > denial of service and a simple user might not even have control over the > priority string for gnutls. > > Given your experiences (as system packager, user, implementor or so), > what do you think is the adoption of priority strings in programs? Given > a program that uses gnutls is it easy to set a string with the > algorithms etc. needed for the negotiation? The OpenSSL upstream decided to allow the client to talk to the unpatched servers by default. Of course it means that if the client talks to such server it is vulnerable to the attack. They've also added a function call so an application can query whether the connection is protected by the safe renegotiation or not. I, as maintainer of OpenSSL and gnutls packages in Fedora and Red Hat Enterprise Linux, decided when backporting the safe renegotiation patches to the old gnutls packages in released distributions, that the client has to be tolerant to missing safe renegotiation support on connected servers for now and so I have removed the strict client side check from the backported patches. If the adoption of the safe renegotiation extension gets better, we will release updated packages which will contain the strict client side check. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From simon at josefsson.org Mon Mar 15 23:33:20 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 15 Mar 2010 23:33:20 +0100 Subject: safe renegotiation in client side In-Reply-To: <4B9EA6F5.4000805@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 15 Mar 2010 17:30:29 -0400") References: <4B9E9CA9.4070901@gnutls.org> <873a01wb90.fsf@mocca.josefsson.org> <4B9EA6F5.4000805@fifthhorseman.net> Message-ID: <87fx41tdu7.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: >> If I understand correctly, it doesn't >> improve anything for the client to behave like that, it is only the >> server that is protected by such a client. > > I don't think this is the case. A client connecting to an unpatched > server is vulnerable to their connection being used to authenticate > another request that they are unaware of. > > The attack in question is a plaintext prefix injection attack: the > attacker starts a session with the server, and then prompts a > re-negotiation. It hands off the re-negotiation to the actual client, > which might then negotiate to the server thinking that it is the initial > connection (not a re-negotiation). If the server then uses the new > connections credentials to act on the original (spoofed) part of the > session, it is the *client's* credentials which have been mis-applied, > not the server's. Right. But it is the server that makes the mistake of assuming that the newly negotiated client credentials has anything to do with the earlier request, isn't it? To me, the renegotiation protocol flaw means that any server that uses renegotiation MUST require support for safe-renegotiation in the client. This is a critical security issue with the server that needs to be addressed as quickly as possible. I don't see any critical security issue on the client side at all. The only reason clients needs to be upgraded is that without clients, servers will be unable to use renegotiation. > clients which "fail closed" by rejecting connections to unpatched > servers cannot have their credentials mis-applied in this way. (they > also won't be able to talk to the majority of the TLS-capable hosts on > the 'net today, unfortunately). Right, if a client has a policy of not talking to any potentially buggy server, this makes sense. But I'm not sure that is useful -- servers are potentially buggy all the time (many still only supports SSL 3.0), but clients still wants to talk to them. >> Thus, I think we should let >> servers require patched clients when it makes sense, and otherwise be >> more lenient on the client side. > > libnss (the mozilla tls implementation) has an interesting phased > approach planned to deal with this situation: > > https://wiki.mozilla.org/Security:Renegotiation > > i know gnutls doesn't expose as much in the way of a UI as NSS clients > like firefox or thunderbird; but if there's some way to adopt a similar > approach, i'd like to examine it. > > Every libgnutls-aware program can see the environment, for example. is > using a clearly-scoped environment variable to provide a priority string > if none other are supplied out of the question? Or what about > ~/.libgnutls/config or something similar? I'm just brainstorming here, > feel free to explain why these are horrible proposals. Couldn't we be lenient today, and in 2-3 years time start to reject buggy servers by default? >> I wish there was an easy way to warn the user somehow though. Syslog a >> message with the server hostname? Should we add a function so that >> applications can find out if a session is potentially insecure due to >> this threat? Any way to make it less specific to renegotiation issues? >> We have other areas that users may want to be aware of too -- e.g., if >> the connection is using a weak cipher, if the connection is not using >> DHE, etc... OTOH maybe this is overkill. Power-users can use >> gnutls-cli to find out manually, and other users are probably fine with >> a lenient default anyway. > > gnutls-cli can find out manually for a different connection -- it won't > let you inspect an active connection, will it? Right, I'm just thinking of how to identify buggy/working servers. > i agree that configurable reporting would be useful, though (and i like > your assessment of the other concerns we might want to permit but warn > about). Seems like a generic interface would be a way for library users > register a callback that reports "warnings about your connection", along > with an enumerated list (and maybe localized strings describing the > problems). > > I like that idea, but if we can't convince application developers to let > end users pass in a priority string, it seems unlikely that we'd get > them to register such a callback, let alone report the warnings to their > users in a sane way :/ I agree, so it seems like a waste of time right now. :-( /Simon From simon at josefsson.org Mon Mar 15 23:38:05 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 15 Mar 2010 23:38:05 +0100 Subject: safe renegotiation in client side In-Reply-To: <4B9E9CA9.4070901@gnutls.org> (Nikos Mavrogiannopoulos's message of "Mon, 15 Mar 2010 21:46:33 +0100") References: <4B9E9CA9.4070901@gnutls.org> Message-ID: <87bpeptdma.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > I have been in favor of enabling safe renegotiation for the client > before, but seeing how gnutls is being used today, I might have not been > correct and enabling it might cause more trouble than the issue it solves. I just had a thought, it may be wrong due to late at night... Using safe renegotiation is only important if the client provides credentials, right? It sounds as if in your testing, GnuTLS clients were unable to talk to any server, even if the clients didn't provide a client certificate. Is that right? If that is the case, can't we make GnuTLS accept talking to "old" servers by default, but if client certificate authentication is requested by the application, it will tear down the connection if the server doesn't support safe-renegotiation? My impression is that client certificate authentication is still not that widely used by applications. This way, we'll be 100% secure but still work in the majority of cases. People using client certificate authentication will not be able to talk with old servers, but that is what they should get. /Simon From tmraz at redhat.com Mon Mar 15 23:59:55 2010 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 15 Mar 2010 23:59:55 +0100 Subject: safe renegotiation in client side In-Reply-To: <87bpeptdma.fsf@mocca.josefsson.org> References: <4B9E9CA9.4070901@gnutls.org> <87bpeptdma.fsf@mocca.josefsson.org> Message-ID: <1268693995.24408.291.camel@vespa.frost.loc> On Mon, 2010-03-15 at 23:38 +0100, Simon Josefsson wrote: > Nikos Mavrogiannopoulos writes: > > > I have been in favor of enabling safe renegotiation for the client > > before, but seeing how gnutls is being used today, I might have not been > > correct and enabling it might cause more trouble than the issue it solves. > > I just had a thought, it may be wrong due to late at night... > > Using safe renegotiation is only important if the client provides > credentials, right? > > It sounds as if in your testing, GnuTLS clients were unable to talk to > any server, even if the clients didn't provide a client certificate. Is > that right? > > If that is the case, can't we make GnuTLS accept talking to "old" > servers by default, but if client certificate authentication is > requested by the application, it will tear down the connection if the > server doesn't support safe-renegotiation? > > My impression is that client certificate authentication is still not > that widely used by applications. > > This way, we'll be 100% secure but still work in the majority of cases. > People using client certificate authentication will not be able to talk > with old servers, but that is what they should get. Unfortunately the credentials might take even different forms such as the auth user name and password and they might be revealed to the attacker which was demonstrated in the Twitter attack. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From dkg at fifthhorseman.net Tue Mar 16 00:15:35 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 15 Mar 2010 19:15:35 -0400 Subject: safe renegotiation in client side In-Reply-To: <87fx41tdu7.fsf@mocca.josefsson.org> References: <4B9E9CA9.4070901@gnutls.org> <873a01wb90.fsf@mocca.josefsson.org> <4B9EA6F5.4000805@fifthhorseman.net> <87fx41tdu7.fsf@mocca.josefsson.org> Message-ID: <4B9EBF97.5090805@fifthhorseman.net> On 03/15/2010 06:33 PM, Simon Josefsson wrote: > Right. But it is the server that makes the mistake of assuming that the > newly negotiated client credentials has anything to do with the earlier > request, isn't it? yes, that's true, but it's true at the application layer which the TLS implementation (and any client) can't actually know anything about. basically, TLS without safe renegotiation has the property that any single ongoing connection stream may in fact consist of a series of communications with unrelated remote parties. This property was apparently surprising to most application developers, who were relying on the presumed semantics that the remote endpoint in a TLS connection would always be the same entity. "safe renegotiation" enforces this presumed semantics. If you're communicating with an endpoint that does not support safe-reneg, it is unsafe to assume those semantics hold (and so your current connection might be part of a larger aggregated series of connections of which you are unaware, with whatever consequences that might have on the remote peer). > To me, the renegotiation protocol flaw means that any server that uses > renegotiation MUST require support for safe-renegotiation in the client. > This is a critical security issue with the server that needs to be > addressed as quickly as possible. I don't see any critical security > issue on the client side at all. The only reason clients needs to be > upgraded is that without clients, servers will be unable to use > renegotiation. But clients have no way of knowing that their connections won't be seen as part of a larger aggregate connection unless they are confident that the server supports safe-reneg. A client who wants to protect their session from such a situation does need to "fail closed" when talking to an incompatible server. > Right, if a client has a policy of not talking to any potentially buggy > server, this makes sense. But I'm not sure that is useful -- servers > are potentially buggy all the time (many still only supports SSL 3.0), > but clients still wants to talk to them. yup. but if they want to talk to them with any particular security guarantees, they need to fail to connect to peers which cannot negotiate those security guarantees. If you're willing to sacrifice the security guarantees (confidentiality, authenticity, etc) for the same of just connecting, why use TLS in the first place? > Couldn't we be lenient today, and in 2-3 years time start to reject > buggy servers by default? yes, we could (though i hope that it won't be 3 years before that happens). I don't think that would be the worst policy to take. But any popular TLS client implementation also plays a role in spurring adoption of safe-reneg among servers by its choice of enforcement (and warning messages, etc). I'd like to see GnuTLS contribute to the "peer pressure" here in some positive way. i'm not saying that default-fail-closed is necessarily the best way to do that, but an entirely lenient policy is pretty weak on the peer pressure side and doesn't contribute to the overall security of network communications in general. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Mar 16 00:20:06 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 15 Mar 2010 19:20:06 -0400 Subject: safe renegotiation in client side In-Reply-To: <1268693995.24408.291.camel@vespa.frost.loc> References: <4B9E9CA9.4070901@gnutls.org> <87bpeptdma.fsf@mocca.josefsson.org> <1268693995.24408.291.camel@vespa.frost.loc> Message-ID: <4B9EC0A6.6050906@fifthhorseman.net> On 03/15/2010 06:59 PM, Tomas Mraz wrote: > On Mon, 2010-03-15 at 23:38 +0100, Simon Josefsson wrote: >> If that is the case, can't we make GnuTLS accept talking to "old" >> servers by default, but if client certificate authentication is >> requested by the application, it will tear down the connection if the >> server doesn't support safe-renegotiation? > > Unfortunately the credentials might take even different forms such as > the auth user name and password and they might be revealed to the > attacker which was demonstrated in the Twitter attack. I think Tomas is correct here; *any* re-negotiation can be used as a vector for an attack like this, not just renegotiations which request client certificates. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From simon at josefsson.org Tue Mar 16 13:02:48 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Mar 2010 13:02:48 +0100 Subject: safe renegotiation in client side In-Reply-To: <4B9EBF97.5090805@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 15 Mar 2010 19:15:35 -0400") References: <4B9E9CA9.4070901@gnutls.org> <873a01wb90.fsf@mocca.josefsson.org> <4B9EA6F5.4000805@fifthhorseman.net> <87fx41tdu7.fsf@mocca.josefsson.org> <4B9EBF97.5090805@fifthhorseman.net> Message-ID: <87r5nkpj87.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > But any popular TLS client implementation also plays a role in spurring > adoption of safe-reneg among servers by its choice of enforcement (and > warning messages, etc). I'd like to see GnuTLS contribute to the "peer > pressure" here in some positive way. i'm not saying that > default-fail-closed is necessarily the best way to do that, but an > entirely lenient policy is pretty weak on the peer pressure side and > doesn't contribute to the overall security of network communications in > general. I agree. So, we could release an experimental version where clients required safe renegotiation, get it into various distributions, and try applications that use GnuTLS to see if they work or not? The important part is likely how well applications support priority strings for easy user fall backs. How well error reporting works is also important. Maybe our energy is better spent helping application writers here... I'll do some experiments with 2.9.10 on my machine... maybe best to get a release out first though. /Simon From simon at josefsson.org Tue Mar 16 13:14:36 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Mar 2010 13:14:36 +0100 Subject: pkcs1-pad self-check fails? Message-ID: <87k4tcpioj.fsf@mocca.josefsson.org> This self-test appears to fail in master.. Nikos, do you have any idea? /Simon Gnutls 2.9.x: Certificate[0]: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) Issued by: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) Verification output: Verified. Chain verification output: Verified. Certificate[0]: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) Issued by: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) Verification output: Not verified. Chain verification output: Verified. out1 oks 2 fails 0 out2 oks 1 fails 1 expected 2002 PKCS1-PAD2 FAIL FAIL: pkcs1-pad GnuTLS 2.8.6: Certificate[0]: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) Issued by: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) Verification output: Verified. Chain verification output: Verified. Certificate[0]: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) Issued by: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) Verification output: Not verified. Chain verification output: Not verified. out1 oks 2 fails 0 out2 oks 0 fails 2 PKCS1-PAD2 OK From ludo at gnu.org Tue Mar 16 15:28:56 2010 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Tue, 16 Mar 2010 15:28:56 +0100 Subject: Intermittent failures of =?utf-8?b?4oCYdGVzdHNybuKAmQ==?= Message-ID: <87tysgibmf.fsf@gnu.org> Hello, The ?testsrn? test seems to be unreliable. On Hydra it fails once every 3 runs or so (see ): --8<---------------cut here---------------start------------->8--- make[3]: Entering directory `/tmp/nix-build-7w56z0vnh477zm70vcbdszxlbp8maihl-gnutls-2.9.10.drv-0/gnutls-2.9.10/tests/safe-renegotiation' building check-TESTS Checking Safe renegotiation Failure: 0. Renegotiation should have succeeded! Failure: 1. Safe rehandshake should have succeeded! Failure: 4. Unsafe renegotiation should have failed! ./testsrn: line 58: kill: (7871) - No such process Failure: 5. Safe rehandshake should have succeeded! Failure: 6. Unsafe rehandshake should have succeeded! ./testsrn: line 79: kill: (8083) - No such process FAIL: testsrn =================================== 1 of 1 test failed Please report to bug-gnutls at gnu.org =================================== make[3]: *** [check-TESTS] Error 1 --8<---------------cut here---------------end--------------->8--- (From .) It looks like the server died prematurely. Thanks, Ludo?. From nmav at gnutls.org Tue Mar 16 15:37:26 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Mar 2010 15:37:26 +0100 Subject: pkcs1-pad self-check fails? In-Reply-To: <87k4tcpioj.fsf@mocca.josefsson.org> References: <87k4tcpioj.fsf@mocca.josefsson.org> Message-ID: No. When was this started to fail? I'm not home to verify but the last few days, after my last commit, I run make check quite many times without any failure. On Tue, Mar 16, 2010 at 1:14 PM, Simon Josefsson wrote: > This self-test appears to fail in master.. ?Nikos, do you have any idea? > > /Simon > > Gnutls 2.9.x: > > Certificate[0]: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) > ? ? ? ?Issued by: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) > ? ? ? ?Verification output: Verified. > > Chain verification output: Verified. > Certificate[0]: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) > ? ? ? ?Issued by: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) > ? ? ? ?Verification output: Not verified. > > Chain verification output: Verified. > out1 oks 2 fails 0 out2 oks 1 fails 1 > expected 2002 > PKCS1-PAD2 FAIL > FAIL: pkcs1-pad > > GnuTLS 2.8.6: > > Certificate[0]: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) > ? ? ? ?Issued by: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) > ? ? ? ?Verification output: Verified. > > Chain verification output: Verified. > Certificate[0]: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) > ? ? ? ?Issued by: C=AU,ST=Queensland,O=CryptSoft Pty Ltd,CN=Server test cert (512 bit) > ? ? ? ?Verification output: Not verified. > > Chain verification output: Not verified. > out1 oks 2 fails 0 out2 oks 0 fails 2 > PKCS1-PAD2 OK > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > From nmav at gnutls.org Tue Mar 16 15:39:35 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Mar 2010 15:39:35 +0100 Subject: =?windows-1252?q?Re=3A_Intermittent_failures_of_=91testsrn=92?= In-Reply-To: <87tysgibmf.fsf@gnu.org> References: <87tysgibmf.fsf@gnu.org> Message-ID: I noticed that many times a gnutls-serv process wouldn't be killed causing the rest of the gnutls-serv processes to fail to execute. 2010/3/16 Ludovic Court?s : > Hello, > > The ?testsrn? test seems to be unreliable. ?On Hydra it fails once every > 3 runs or so (see ): > > --8<---------------cut here---------------start------------->8--- > make[3]: Entering directory `/tmp/nix-build-7w56z0vnh477zm70vcbdszxlbp8maihl-gnutls-2.9.10.drv-0/gnutls-2.9.10/tests/safe-renegotiation' > building check-TESTS > Checking Safe renegotiation > Failure: 0. Renegotiation should have succeeded! > Failure: 1. Safe rehandshake should have succeeded! > Failure: 4. Unsafe renegotiation should have failed! > ./testsrn: line 58: kill: (7871) - No such process > Failure: 5. Safe rehandshake should have succeeded! > Failure: 6. Unsafe rehandshake should have succeeded! > ./testsrn: line 79: kill: (8083) - No such process > FAIL: testsrn > =================================== > 1 of 1 test failed > Please report to bug-gnutls at gnu.org > =================================== > make[3]: *** [check-TESTS] Error 1 > --8<---------------cut here---------------end--------------->8--- > > (From .) > > It looks like the server died prematurely. > > Thanks, > Ludo?. > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > From ludo at gnu.org Tue Mar 16 15:44:56 2010 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Tue, 16 Mar 2010 15:44:56 +0100 Subject: Intermittent failures of =?utf-8?b?4oCYdGVzdHNybuKAmQ==?= In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue, 16 Mar 2010 15:39:35 +0100") References: <87tysgibmf.fsf@gnu.org> Message-ID: <87mxy8iavr.fsf@gnu.org> Hi, Nikos Mavrogiannopoulos writes: > I noticed that many times a gnutls-serv process wouldn't be killed causing > the rest of the gnutls-serv processes to fail to execute. Or perhaps it?s because it gets EADDRINUSE? If that is the case, one solution would be for each server run to use a different port number. Thanks, Ludo?. From simon at josefsson.org Tue Mar 16 15:45:44 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Mar 2010 15:45:44 +0100 Subject: pkcs1-pad self-check fails? In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue, 16 Mar 2010 15:37:26 +0100") References: <87k4tcpioj.fsf@mocca.josefsson.org> Message-ID: <87634wnx47.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > No. When was this started to fail? I'm not home to verify but the last > few days, > after my last commit, I run make check quite many times without any failure. Maybe you don't have 'datefudge' installed? It is required by this test to avoid date/time checks, and the test is skipped if 'datefudge' is not installed. It looks related to the X.509 chain validation changes to me, but I haven't debugged further. /Simon From nmav at gnutls.org Tue Mar 16 15:48:06 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Mar 2010 15:48:06 +0100 Subject: safe renegotiation in client side In-Reply-To: <87r5nkpj87.fsf@mocca.josefsson.org> References: <4B9E9CA9.4070901@gnutls.org> <873a01wb90.fsf@mocca.josefsson.org> <4B9EA6F5.4000805@fifthhorseman.net> <87fx41tdu7.fsf@mocca.josefsson.org> <4B9EBF97.5090805@fifthhorseman.net> <87r5nkpj87.fsf@mocca.josefsson.org> Message-ID: On Tue, Mar 16, 2010 at 1:02 PM, Simon Josefsson wrote: > I'll do some experiments with 2.9.10 on my machine... maybe best to get > a release out first though. At least in my system I couldn't do basic stuff (use svn over ssl) and couldn't find any fix for those (except changing gnutls). I no longer use openldap to login in my system, but I remember this also doesn't provide access to priority strings, which would also cause a denial of service. I'm also leaning towards having the first releases without enforced safe renegotiation and enforcing it at a later time that does not cause more trouble than it solves. Debug strings warning about that are now being printed via the gnutls logging, but are not visible in most applications (and even if it was might not offer any information to a typical user since it will be issued for almost every server today). What we can do is add a warning on the gnutls-cli if the server does not support safe renegotiation? (gnutls-cli-debug can also detect that). regards, Nikos From nmav at gnutls.org Tue Mar 16 15:52:28 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Mar 2010 15:52:28 +0100 Subject: pkcs1-pad self-check fails? In-Reply-To: <87634wnx47.fsf@mocca.josefsson.org> References: <87k4tcpioj.fsf@mocca.josefsson.org> <87634wnx47.fsf@mocca.josefsson.org> Message-ID: No I don't. I never had. Maybe we should make this test fail when datefudge is not detected? Otherwise we might miss it in the future (as I missed it now). However this error looks like a PKCS padding issue? Don't remember changing anything related lately. Anyway I'll try to check it soon. On Tue, Mar 16, 2010 at 3:45 PM, Simon Josefsson wrote: > Nikos Mavrogiannopoulos writes: > >> No. When was this started to fail? I'm not home to verify but the last >> few days, >> after my last commit, I run make check quite many times without any failure. > > Maybe you don't have 'datefudge' installed? ?It is required by this test > to avoid date/time checks, and the test is skipped if 'datefudge' is not > installed. ?It looks related to the X.509 chain validation changes to > me, but I haven't debugged further. > > /Simon > From simon at josefsson.org Tue Mar 16 15:55:16 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Mar 2010 15:55:16 +0100 Subject: safe renegotiation in client side In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue, 16 Mar 2010 15:48:06 +0100") References: <4B9E9CA9.4070901@gnutls.org> <873a01wb90.fsf@mocca.josefsson.org> <4B9EA6F5.4000805@fifthhorseman.net> <87fx41tdu7.fsf@mocca.josefsson.org> <4B9EBF97.5090805@fifthhorseman.net> <87r5nkpj87.fsf@mocca.josefsson.org> Message-ID: <87vdcwmi3v.fsf@mocca.josefsson.org> Could we syslog() a message with the address of the server that is buggy when a client invokes gnutls_handshake()? We need to extract the server IP address from a socket, though, and will need to be very careful about handling return values from every syscall. (It may not even be a socket, GnuTLS doesn't require that, but then it could just say that the server is buggy with no address..) Even if we don't have the syslog operation in upstream GnuTLS, we could recommend a patch so that RedHat/Debian/Ubuntu/etc can apply it in their builds. This may lead to people upgrading their important servers more quickly. /Simon From simon at josefsson.org Tue Mar 16 15:57:06 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Mar 2010 15:57:06 +0100 Subject: pkcs1-pad self-check fails? In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue, 16 Mar 2010 15:52:28 +0100") References: <87k4tcpioj.fsf@mocca.josefsson.org> <87634wnx47.fsf@mocca.josefsson.org> Message-ID: <87ljdsmi0t.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > No I don't. I never had. Maybe we should make this test fail when > datefudge is not detected? > Otherwise we might miss it in the future (as I missed it now). However > this error looks like a > PKCS padding issue? Don't remember changing anything related lately. > Anyway I'll try to check it soon. Thanks. I think the problem is that the PKIX chain used to be rejected (in 2.8.x) because the signature validation fails, but now the entire chain is accepted. Presumably the particular signature is no longer validated. That could be wrong, or there is a problem in that self test. /Simon From simon at josefsson.org Tue Mar 16 16:02:51 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Mar 2010 16:02:51 +0100 Subject: safe renegotiation in client side In-Reply-To: <4B9EC0A6.6050906@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 15 Mar 2010 19:20:06 -0400") References: <4B9E9CA9.4070901@gnutls.org> <87bpeptdma.fsf@mocca.josefsson.org> <1268693995.24408.291.camel@vespa.frost.loc> <4B9EC0A6.6050906@fifthhorseman.net> Message-ID: <87aau8mhr8.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > On 03/15/2010 06:59 PM, Tomas Mraz wrote: >> On Mon, 2010-03-15 at 23:38 +0100, Simon Josefsson wrote: >>> If that is the case, can't we make GnuTLS accept talking to "old" >>> servers by default, but if client certificate authentication is >>> requested by the application, it will tear down the connection if the >>> server doesn't support safe-renegotiation? >> >> Unfortunately the credentials might take even different forms such as >> the auth user name and password and they might be revealed to the >> attacker which was demonstrated in the Twitter attack. > > I think Tomas is correct here; *any* re-negotiation can be used as a > vector for an attack like this, not just renegotiations which request > client certificates. Yes. Sigh. /Simon From simon at josefsson.org Tue Mar 16 16:04:17 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Mar 2010 16:04:17 +0100 Subject: Intermittent failures of =?utf-8?b?4oCYdGVzdHNybuKAmQ==?= In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue, 16 Mar 2010 15:39:35 +0100") References: <87tysgibmf.fsf@gnu.org> Message-ID: <87634wmhou.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > I noticed that many times a gnutls-serv process wouldn't be killed causing > the rest of the gnutls-serv processes to fail to execute. Maybe we can rewrite these tests based on tests/mini.c or some other approach that doesn't require process management from the shell? The latter is a bit unportable and prone to errors generally. /Simon > 2010/3/16 Ludovic Court?s : >> Hello, >> >> The ?testsrn? test seems to be unreliable. ?On Hydra it fails once every >> 3 runs or so (see ): >> >> --8<---------------cut here---------------start------------->8--- >> make[3]: Entering directory `/tmp/nix-build-7w56z0vnh477zm70vcbdszxlbp8maihl-gnutls-2.9.10.drv-0/gnutls-2.9.10/tests/safe-renegotiation' >> building check-TESTS >> Checking Safe renegotiation >> Failure: 0. Renegotiation should have succeeded! >> Failure: 1. Safe rehandshake should have succeeded! >> Failure: 4. Unsafe renegotiation should have failed! >> ./testsrn: line 58: kill: (7871) - No such process >> Failure: 5. Safe rehandshake should have succeeded! >> Failure: 6. Unsafe rehandshake should have succeeded! >> ./testsrn: line 79: kill: (8083) - No such process >> FAIL: testsrn >> =================================== >> 1 of 1 test failed >> Please report to bug-gnutls at gnu.org >> =================================== >> make[3]: *** [check-TESTS] Error 1 >> --8<---------------cut here---------------end--------------->8--- >> >> (From .) >> >> It looks like the server died prematurely. >> >> Thanks, >> Ludo?. >> >> >> _______________________________________________ >> Gnutls-devel mailing list >> Gnutls-devel at gnu.org >> http://lists.gnu.org/mailman/listinfo/gnutls-devel >> From ametzler at downhill.at.eu.org Tue Mar 16 20:02:46 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Tue, 16 Mar 2010 20:02:46 +0100 Subject: wrong gnutls.pc In-Reply-To: <87aau9xw8y.fsf@mocca.josefsson.org> References: <222ade941002260357p1cede669jf4cf204525460de3@mail.gmail.com> <20100226183026.GA3529@downhill.g.la> <20100228122418.GB3463@downhill.g.la> <20100315175342.GB3278@downhill.g.la> <87aau9xw8y.fsf@mocca.josefsson.org> Message-ID: <20100316190246.GA3816@downhill.g.la> On 2010-03-15 Simon Josefsson wrote: > Andreas Metzler writes: > > On 2010-02-28 Andreas Metzler wrote: > > [...] > >> Patches against git head attached. This should also go to the 2.8.x > >> series. > > Saved as http://savannah.gnu.org/support/?107310 > Oops, I missed that for 2.8.6. Is the patch in savannah still the best > version? I think we could apply it easily soon. [...] Hello, I have not got an update, and there has not been any change in GIT that requires changes to the patches, afaict. The whole "GNUTLS_REQUIRES_PRIVATE" macro is less than elegant, though. ;-) cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Tue Mar 16 22:43:00 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Mar 2010 22:43:00 +0100 Subject: pkcs1-pad self-check fails? In-Reply-To: <87ljdsmi0t.fsf@mocca.josefsson.org> References: <87k4tcpioj.fsf@mocca.josefsson.org> <87634wnx47.fsf@mocca.josefsson.org> <87ljdsmi0t.fsf@mocca.josefsson.org> Message-ID: <4B9FFB64.6040603@gnutls.org> Simon Josefsson wrote: > Thanks. I think the problem is that the PKIX chain used to be rejected > (in 2.8.x) because the signature validation fails, but now the entire > chain is accepted. Presumably the particular signature is no longer > validated. That could be wrong, or there is a problem in that self > test. I cannot understand why this chain shouldn't be validated... What was the reason for the test? It is now accepted because the verification procedure detects the same certificate being verified and trusted and thus considers it ok. As a side-effect I noticed that that gnutls_x509_crt_verify() behaves different than gnutls_x509_crt_list_verify() - i.e. no date checks, which shouldn't occur. regards, Nikos From vincent.torri at gmail.com Tue Mar 16 23:22:16 2010 From: vincent.torri at gmail.com (Vincent Torri) Date: Tue, 16 Mar 2010 23:22:16 +0100 Subject: wrong gnutls.pc In-Reply-To: <20100316190246.GA3816@downhill.g.la> References: <222ade941002260357p1cede669jf4cf204525460de3@mail.gmail.com> <20100226183026.GA3529@downhill.g.la> <20100228122418.GB3463@downhill.g.la> <20100315175342.GB3278@downhill.g.la> <87aau9xw8y.fsf@mocca.josefsson.org> <20100316190246.GA3816@downhill.g.la> Message-ID: <222ade941003161522s69f697bdpf73ac1811eee8b42@mail.gmail.com> On Tue, Mar 16, 2010 at 8:02 PM, Andreas Metzler < ametzler at downhill.at.eu.org> wrote: > Hello, > I have not got an update, and there has not been any change in GIT > that requires changes to the patches, afaict. The whole > "GNUTLS_REQUIRES_PRIVATE" macro is less than elegant, though. ;-) > > Indeed, it can be improved. But imho, configure.ac and m4 macros can be improved and simplified. It's very difficult to understand how detection is done. Vincent Torri -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Tue Mar 16 23:48:48 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Mar 2010 23:48:48 +0100 Subject: pkcs1-pad self-check fails? In-Reply-To: <87ljdsmi0t.fsf@mocca.josefsson.org> References: <87k4tcpioj.fsf@mocca.josefsson.org> <87634wnx47.fsf@mocca.josefsson.org> <87ljdsmi0t.fsf@mocca.josefsson.org> Message-ID: <4BA00AD0.1040900@gnutls.org> Simon Josefsson wrote: > Thanks. I think the problem is that the PKIX chain used to be rejected > (in 2.8.x) because the signature validation fails, but now the entire > chain is accepted. Presumably the particular signature is no longer > validated. That could be wrong, or there is a problem in that self > test. I fixed the chain verification to behave as it used to be. regards, Nikos From simon at josefsson.org Wed Mar 17 10:47:22 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 17 Mar 2010 10:47:22 +0100 Subject: pkcs1-pad self-check fails? In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue, 16 Mar 2010 15:52:28 +0100") References: <87k4tcpioj.fsf@mocca.josefsson.org> <87634wnx47.fsf@mocca.josefsson.org> Message-ID: <87eijjgtzp.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > No I don't. I never had. Maybe we should make this test fail when > datefudge is not detected? > Otherwise we might miss it in the future (as I missed it now). Requiring datefudge will break builds for almost everyone, and the tool doesn't exist on some platforms which makes it impossible to build GnuTLS successfully on those platforms. I reverted this so the test is just skipped if datefudge is not available. /Simon From nmav at gnutls.org Wed Mar 17 11:14:02 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 17 Mar 2010 11:14:02 +0100 Subject: pkcs1-pad self-check fails? In-Reply-To: <87eijjgtzp.fsf@mocca.josefsson.org> References: <87k4tcpioj.fsf@mocca.josefsson.org> <87634wnx47.fsf@mocca.josefsson.org> <87eijjgtzp.fsf@mocca.josefsson.org> Message-ID: <4BA0AB6A.9000006@gnutls.org> Simon Josefsson wrote: > Nikos Mavrogiannopoulos writes: > >> No I don't. I never had. Maybe we should make this test fail when >> datefudge is not detected? >> Otherwise we might miss it in the future (as I missed it now). > > Requiring datefudge will break builds for almost everyone, and the tool > doesn't exist on some platforms which makes it impossible to build > GnuTLS successfully on those platforms. I reverted this so the test is > just skipped if datefudge is not available. But then the test is as good as not being there... Noone will actually run it. I don't find it so bad to require a program for the "make check" to complete. From simon at josefsson.org Wed Mar 17 11:22:33 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 17 Mar 2010 11:22:33 +0100 Subject: pkcs1-pad self-check fails? In-Reply-To: <4BA0AB6A.9000006@gnutls.org> (Nikos Mavrogiannopoulos's message of "Wed, 17 Mar 2010 11:14:02 +0100") References: <87k4tcpioj.fsf@mocca.josefsson.org> <87634wnx47.fsf@mocca.josefsson.org> <87eijjgtzp.fsf@mocca.josefsson.org> <4BA0AB6A.9000006@gnutls.org> Message-ID: <877hpbgsd2.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: >> Nikos Mavrogiannopoulos writes: >> >>> No I don't. I never had. Maybe we should make this test fail when >>> datefudge is not detected? >>> Otherwise we might miss it in the future (as I missed it now). >> >> Requiring datefudge will break builds for almost everyone, and the tool >> doesn't exist on some platforms which makes it impossible to build >> GnuTLS successfully on those platforms. I reverted this so the test is >> just skipped if datefudge is not available. > > But then the test is as good as not being there... Noone will actually > run it. I will. :-) > I don't find it so bad to require a program for the "make check" to > complete. What to do about platforms that doesn't have it, and where it cannot be ported to? The best would to have an API to specify the time you want to use for validation, rather than always using time()... /Simon From nmav at gnutls.org Wed Mar 17 13:52:17 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 17 Mar 2010 13:52:17 +0100 Subject: pkcs1-pad self-check fails? In-Reply-To: <877hpbgsd2.fsf@mocca.josefsson.org> References: <87k4tcpioj.fsf@mocca.josefsson.org> <87634wnx47.fsf@mocca.josefsson.org> <87eijjgtzp.fsf@mocca.josefsson.org> <4BA0AB6A.9000006@gnutls.org> <877hpbgsd2.fsf@mocca.josefsson.org> Message-ID: <4BA0D081.30303@gnutls.org> Simon Josefsson wrote: >> I don't find it so bad to require a program for the "make check" to >> complete. > > What to do about platforms that doesn't have it, and where it cannot be > ported to? This test will just fail with a warning of the missing program. Not a big issue. > The best would to have an API to specify the time you want to use for > validation, rather than always using time()... Indeed. From simon at josefsson.org Wed Mar 17 16:06:18 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 17 Mar 2010 16:06:18 +0100 Subject: pkcs1-pad self-check fails? In-Reply-To: <4BA0D081.30303@gnutls.org> (Nikos Mavrogiannopoulos's message of "Wed, 17 Mar 2010 13:52:17 +0100") References: <87k4tcpioj.fsf@mocca.josefsson.org> <87634wnx47.fsf@mocca.josefsson.org> <87eijjgtzp.fsf@mocca.josefsson.org> <4BA0AB6A.9000006@gnutls.org> <877hpbgsd2.fsf@mocca.josefsson.org> <4BA0D081.30303@gnutls.org> Message-ID: <871vfjdm39.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: > >>> I don't find it so bad to require a program for the "make check" to >>> complete. >> >> What to do about platforms that doesn't have it, and where it cannot be >> ported to? > > This test will just fail with a warning of the missing program. Not a > big issue. I've mentioned datefudge in README-alpha now, so I think interested people will find it now. /Simon From dkg at fifthhorseman.net Wed Mar 17 19:11:09 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 17 Mar 2010 14:11:09 -0400 Subject: datefudge and faketime [was: Re: pkcs1-pad self-check fails?] In-Reply-To: <871vfjdm39.fsf@mocca.josefsson.org> References: <87k4tcpioj.fsf@mocca.josefsson.org> <87634wnx47.fsf@mocca.josefsson.org> <87eijjgtzp.fsf@mocca.josefsson.org> <4BA0AB6A.9000006@gnutls.org> <877hpbgsd2.fsf@mocca.josefsson.org> <4BA0D081.30303@gnutls.org> <871vfjdm39.fsf@mocca.josefsson.org> Message-ID: <4BA11B3D.1040506@fifthhorseman.net> On 03/17/2010 11:06 AM, Simon Josefsson wrote: > I've mentioned datefudge in README-alpha now, so I think interested > people will find it now. i don't know about the portability issues, but there is also faketime[0] which provides similar functionality (i maintain it for debian, fwiw). If it would help the test to reach more architectures or platforms, the test suite could select whichever one is present on the system. Not a big deal, just wanted to throw another option out there. --dkg [0] http://www.code-wizards.com/projects/libfaketime/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From simon at josefsson.org Thu Mar 18 14:43:27 2010 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 18 Mar 2010 14:43:27 +0100 Subject: datefudge and faketime In-Reply-To: <4BA11B3D.1040506@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 17 Mar 2010 14:11:09 -0400") References: <87k4tcpioj.fsf@mocca.josefsson.org> <87634wnx47.fsf@mocca.josefsson.org> <87eijjgtzp.fsf@mocca.josefsson.org> <4BA0AB6A.9000006@gnutls.org> <877hpbgsd2.fsf@mocca.josefsson.org> <4BA0D081.30303@gnutls.org> <871vfjdm39.fsf@mocca.josefsson.org> <4BA11B3D.1040506@fifthhorseman.net> Message-ID: <87ljdp924g.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > On 03/17/2010 11:06 AM, Simon Josefsson wrote: >> I've mentioned datefudge in README-alpha now, so I think interested >> people will find it now. > > i don't know about the portability issues, but there is also > faketime[0] Interesting, it looks almost identical to datefudge... > which provides similar functionality (i maintain it for debian, fwiw). > If it would help the test to reach more architectures or platforms, the > test suite could select whichever one is present on the system. I think there are two orthogonal concerns: 1) These tools only work on a smaller set of platforms (at least compared to all platforms where GnuTLS run on). 2) Most people doesn't have the tool installed even on Debian. For non-essential things, the way we typically handle #2 is to have the dependency be optional (like valgrind is now). If we want to go beyond having it an optional dependency, we need some way to handle the platforms where it doesn't exist. Anyway, I think documenting this requirement in README-alpha is sufficient. /Simon From pavan.konjarla at hp.com Wed Mar 17 16:33:22 2010 From: pavan.konjarla at hp.com (Konjarla, Pavan) Date: Wed, 17 Mar 2010 15:33:22 +0000 Subject: ASN1 structure implementation is missing for OID 2.5.4.17 which is PostalCode, and OID 2.5.4.41 (Name) definition Message-ID: Hello, GnuTLS certtool is unable to display the correct value of Postal Code when the certificate subject contains 'Postal Code' as its one of DN fields. The scenario how to reproduce is as follows, 1. Create a CSR with a DN which contains Postal Code as one of its DN attributes. 2. Send the CSR to any CA for test certificate. 3. After getting the certificate display the certificate using the certtool with ./certtool -i -infile command. 4. Observed that the value for Postal Code is displayed something like PostalCode=#0c06343030303933 instead of a valid decimal value. To fix this problem we should add the definition for Postal Code with the corresponding OID in ASN1 structure. I am attaching the patch file with the feasible fix. Kindly let me know if you need any other information/clarification. Regards, Pavan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch_1.txt URL: From trapni at gentoo.org Tue Mar 16 10:58:51 2010 From: trapni at gentoo.org (Christian Parpart) Date: Tue, 16 Mar 2010 10:58:51 +0100 Subject: handshaking takes too long (although, session resuming *seems* to work) Message-ID: <0d7c54c9105568cca892289052f59624.squirrel@mail.subtrap.net> Hey, i've just implemented SSL in my little web server, however, the handshaking tooks quite long, so I added session resuming to it (based on the example code I found in the sources), and added some debug prints to see whether they're actually invoked. What I now see, is, that on first (client web browser) connect, a record gets stored my cache, and on the second call, I successively return this data back to gnutls, however, the session resuming still takes as much time as on the first request. I've tested it on my netbook (quite thin hardware, though), and there it takes about 2.5 seconds. still too long even without session resuming? Compared to Apache, even the first request responded quite instant. But what could the reasons be? Thanks in advance, Christian Parpart. From ametzler at downhill.at.eu.org Thu Mar 18 18:54:33 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Thu, 18 Mar 2010 18:54:33 +0100 Subject: datefudge and faketime In-Reply-To: <87ljdp924g.fsf@mocca.josefsson.org> References: <87634wnx47.fsf@mocca.josefsson.org> <87eijjgtzp.fsf@mocca.josefsson.org> <4BA0AB6A.9000006@gnutls.org> <877hpbgsd2.fsf@mocca.josefsson.org> <4BA0D081.30303@gnutls.org> <871vfjdm39.fsf@mocca.josefsson.org> <4BA11B3D.1040506@fifthhorseman.net> <87ljdp924g.fsf@mocca.josefsson.org> Message-ID: <20100318175433.GA3762@downhill.g.la> On 2010-03-18 Simon Josefsson wrote: [datefudge] > 2) Most people doesn't have the tool installed even on Debian. [...] FWIW I had made datefudge a build-dependcy in 2.8.5-1, therefore at least the autobuilers install it before running the testsuite. cu andreas From adimcev at carbonwind.net Fri Mar 19 19:02:17 2010 From: adimcev at carbonwind.net (Adrian F. Dimcev) Date: Fri, 19 Mar 2010 20:02:17 +0200 Subject: GnuTLS 2.8.6 vs RFC 4346 stringent EXPORT cipher suites condition Message-ID: <4BA3BC29.7010001@carbonwind.net> http://www3.tools.ietf.org/html/rfc4346 Section A5: A series of cipher suites were designed to operate at reduced key lengths in order to comply with those regulations. Due to advances in computer performance, these algorithms are now unacceptably weak, and export restrictions have since been loosened. TLS 1.1 implementations MUST NOT negotiate these cipher suites in TLS 1.1 mode. However, for backward compatibility they may be offered in the Client Hello for use with TLS 1.0 or SSLv3-only servers. TLS 1.1 clients MUST check that the server did not choose one of these cipher suites during the handshake. These ciphersuites are listed below for informational purposes and to reserve the numbers. CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; ... --- Testing Apache 2.2.15 + mod_gnutls 0.5.5 + GnuTLS 2.8.6 all source builds(on Ubuntu Server 9.1 x64). On the server I have: GnuTLSEnable on GnuTLSPriorities EXPORT DocumentRoot /usr/local/apache2/htdocs GnuTLSCertificateFile /usr/local/apache2/conf/rsa_server.pem GnuTLSKeyFile /usr/local/apache2/conf/rsa_server.key GnuTLSRSAFile /usr/local/apache2/conf/rsa_512bit.key If I want to negotiate and use TLS_RSA_EXPORT_WITH_RC4_40_MD5 under TLS 1.1 it seems I don't have any kind of problems(both client and server use GnuTLS). Also, IMHO, the gnu-cli used as below could have failed with 'no supported cipher suites have been found' or something instead of sending the Client Hello(as I explicitly specified the (only) TLS version to use + the only cipher/key exchange to be used, is not that I also specified RSA and ARCFOUR-128). gnutls-cli 192.168.22.163 --priority NONE:+VERS-TLS1.1:+ARCFOUR-40:+RSA-EXPORT:+MD5:+COMP-NULL --insecure Resolving '192.168.22.163'... Connecting to '192.168.22.163:443'... - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - subject `CN=www.example.net', issuer `CN=Test XCA', RSA key 1024 bits, signed using RSA-SHA, activated `2009-11-13 12:59:50 UTC', expires `2010-11-13 12:59:50 UTC', SHA-1 fingerprint `388492223f7e88e728a4b19ed124a00f0a2c73e2' - The hostname in the certificate does NOT match '192.168.22.163' - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.1 - Key Exchange: RSA-EXPORT - Cipher: ARCFOUR-40 - MAC: MD5 - Compression: NULL - Handshake was completed - Simple Client Mode: ^C From ametzler at downhill.at.eu.org Sat Mar 20 09:34:31 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 20 Mar 2010 09:34:31 +0100 Subject: GnuTLS 2.8.6 In-Reply-To: <87fx411zyj.fsf@mocca.josefsson.org> References: <87fx411zyj.fsf@mocca.josefsson.org> Message-ID: <20100320083431.GB3262@downhill.g.la> On 2010-03-15 Simon Josefsson wrote: > We are proud to announce a new stable GnuTLS release: Version 2.8.6. [...] This release includes this change: -------------------------------------- >From 7e610054fa98f9c0b1e6d722bd6b5dc7dad1a711 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Thu, 05 Nov 2009 13:12:16 +0000 Subject: Make sure libgcrypt's dependency on libgpg-error is known. --- diff --git a/lib/m4/hooks.m4 b/lib/m4/hooks.m4 index 2eb2b2a..dc2904a 100644 --- a/lib/m4/hooks.m4 +++ b/lib/m4/hooks.m4 @@ -34,7 +34,7 @@ AC_DEFUN([LIBGNUTLS_HOOKS], DLL_VERSION=`expr ${LT_CURRENT} - ${LT_AGE}` AC_SUBST(DLL_VERSION) - AC_LIB_HAVE_LINKFLAGS(gcrypt,, [#include ], + AC_LIB_HAVE_LINKFLAGS([gcrypt], [gpg-error], [#include ], [enum gcry_cipher_algos i = GCRY_CIPHER_CAMELLIA128]) if test "$ac_cv_libgcrypt" != yes; then AC_MSG_ERROR([[ -- cgit v0.8.2.1 -------------------------------------- What problem is trying to solve? Gnutls does not uses gpg-error functions, but ends up being linked against gpg-error even on architecures which do not require linkage against indirect dependencies. I thought a major selling point of AC_LIB_HAVE_LINKFLAGS was that it found indirect dependencies if necessary (by relying on libtool la files). thanks, cu andreas From nmav at gnutls.org Sat Mar 20 12:23:25 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 20 Mar 2010 12:23:25 +0100 Subject: GnuTLS 2.8.6 vs RFC 4346 stringent EXPORT cipher suites condition In-Reply-To: <4BA3BC29.7010001@carbonwind.net> References: <4BA3BC29.7010001@carbonwind.net> Message-ID: <4BA4B02D.7040003@gnutls.org> Adrian F. Dimcev wrote: > http://www3.tools.ietf.org/html/rfc4346 > > Section A5: > A series of cipher suites were designed to operate at reduced key > lengths in order to comply with those regulations. Due to advances in > computer performance, these algorithms are now unacceptably weak, and > export restrictions have since been loosened. TLS 1.1 implementations > MUST NOT negotiate these cipher suites in TLS 1.1 mode. However, for > backward compatibility they may be offered in the Client Hello for use > with TLS 1.0 or SSLv3-only servers. TLS 1.1 clients MUST check that the > server did not choose one of these cipher suites during the handshake. > These ciphersuites are listed below for informational purposes and to > reserve the numbers. > CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; Hello and thank you for the report. I have committed a fix in the development version. regards, Nikos From nmav at gnutls.org Sat Mar 20 12:33:21 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 20 Mar 2010 12:33:21 +0100 Subject: ASN1 structure implementation is missing for OID 2.5.4.17 which is PostalCode, and OID 2.5.4.41 (Name) definition In-Reply-To: References: Message-ID: <4BA4B281.5010008@gnutls.org> Konjarla, Pavan wrote: > Hello, > > GnuTLS certtool is unable to display the correct value of Postal Code when the certificate subject contains 'Postal Code' as its one of DN fields. > > The scenario how to reproduce is as follows, > > > 1. Create a CSR with a DN which contains Postal Code as one of its DN attributes. > > 2. Send the CSR to any CA for test certificate. > > 3. After getting the certificate display the certificate using the certtool with ./certtool -i -infile command. > > 4. Observed that the value for Postal Code is displayed something like PostalCode=#0c06343030303933 instead of a valid decimal value. > > > To fix this problem we should add the definition for Postal Code with the corresponding OID in ASN1 structure. > > I am attaching the patch file with the feasible fix. Kindly let me know if you need any other information/clarification. Hello and thank you for the report and fix. I have committed a fix based on your patch. However would it be easy to you a send me a certificate that includes the postalcode and/or name so that I can verify parsing them right? regards, Nikos From simon at josefsson.org Sun Mar 21 20:31:26 2010 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 21 Mar 2010 20:31:26 +0100 Subject: GnuTLS 2.8.6 In-Reply-To: <20100320083431.GB3262@downhill.g.la> (Andreas Metzler's message of "Sat, 20 Mar 2010 09:34:31 +0100") References: <87fx411zyj.fsf@mocca.josefsson.org> <20100320083431.GB3262@downhill.g.la> Message-ID: <87d3yxsc8h.fsf@mocca.josefsson.org> Andreas Metzler writes: > On 2010-03-15 Simon Josefsson wrote: >> We are proud to announce a new stable GnuTLS release: Version 2.8.6. > [...] > > This release includes this change: > > -------------------------------------- > From 7e610054fa98f9c0b1e6d722bd6b5dc7dad1a711 Mon Sep 17 00:00:00 2001 > From: Simon Josefsson > Date: Thu, 05 Nov 2009 13:12:16 +0000 > Subject: Make sure libgcrypt's dependency on libgpg-error is known. > > --- > diff --git a/lib/m4/hooks.m4 b/lib/m4/hooks.m4 > index 2eb2b2a..dc2904a 100644 > --- a/lib/m4/hooks.m4 > +++ b/lib/m4/hooks.m4 > @@ -34,7 +34,7 @@ AC_DEFUN([LIBGNUTLS_HOOKS], > DLL_VERSION=`expr ${LT_CURRENT} - ${LT_AGE}` > AC_SUBST(DLL_VERSION) > > - AC_LIB_HAVE_LINKFLAGS(gcrypt,, [#include ], > + AC_LIB_HAVE_LINKFLAGS([gcrypt], [gpg-error], [#include ], > [enum gcry_cipher_algos i = GCRY_CIPHER_CAMELLIA128]) > if test "$ac_cv_libgcrypt" != yes; then > AC_MSG_ERROR([[ > -- > cgit v0.8.2.1 > -------------------------------------- > > What problem is trying to solve? GnuTLS doesn't build on Solaris without that. > Gnutls does not uses gpg-error functions, but ends up being linked > against gpg-error even on architecures which do not require linkage > against indirect dependencies. Does that cause any problem? > I thought a major selling point of AC_LIB_HAVE_LINKFLAGS was that it > found indirect dependencies if necessary (by relying on libtool la > files). I think lib-link.m4 could be enhanced to test whether dependencies are not needed, and avoid pulling them in if so. It seems to be a wishlist kind of bug though. /Simon From simon at josefsson.org Sun Mar 21 20:32:35 2010 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 21 Mar 2010 20:32:35 +0100 Subject: datefudge and faketime In-Reply-To: <20100318175433.GA3762@downhill.g.la> (Andreas Metzler's message of "Thu, 18 Mar 2010 18:54:33 +0100") References: <87634wnx47.fsf@mocca.josefsson.org> <87eijjgtzp.fsf@mocca.josefsson.org> <4BA0AB6A.9000006@gnutls.org> <877hpbgsd2.fsf@mocca.josefsson.org> <4BA0D081.30303@gnutls.org> <871vfjdm39.fsf@mocca.josefsson.org> <4BA11B3D.1040506@fifthhorseman.net> <87ljdp924g.fsf@mocca.josefsson.org> <20100318175433.GA3762@downhill.g.la> Message-ID: <878w9lsc6k.fsf@mocca.josefsson.org> Andreas Metzler writes: > On 2010-03-18 Simon Josefsson wrote: > [datefudge] >> 2) Most people doesn't have the tool installed even on Debian. > [...] > > FWIW I had made datefudge a build-dependcy in 2.8.5-1, therefore at > least the autobuilers install it before running the testsuite. Great! I think that is sufficient to have confidence that the pkcs1-pad self check will be run on enough hosts to catch any regression. /Simon From pavan.konjarla at hp.com Mon Mar 22 07:00:22 2010 From: pavan.konjarla at hp.com (Konjarla, Pavan) Date: Mon, 22 Mar 2010 06:00:22 +0000 Subject: ASN1 structure implementation is missing for OID 2.5.4.17 which is PostalCode, and OID 2.5.4.41 (Name) definition In-Reply-To: <4BA4B281.5010008@gnutls.org> References: <4BA4B281.5010008@gnutls.org> Message-ID: Hello, Attaching a test certificate with PostalCode attribute. -----BEGIN CERTIFICATE----- MIIDRzCCArACCQDEFjfnIvTaLTANBgkqhkiG9w0BAQQFADCBhjELMAkGA1UEBhMC SU4xFDASBgNVBAgTC01haGFyYXNodHJhMQ8wDQYDVQQHEwZNdW1iYWkxDDAKBgNV BAoTA1RDUzEMMAoGA1UECxMDTkVEMQ4wDAYDVQQDEwVSb2hhbjEkMCIGCSqGSIb3 DQEJARYVcm9oYW4uYW1idXJsZUB0Y3MuY29tMB4XDTA3MDUyODE0MDQxM1oXDTIx MDIwMzE0MDQxM1owggFHMSQwIgYDVQQDFBt3d3cuYWxsX2RuX3dpdGhvdXRfdXRm OC5jb20xDDAKBgNVBAsTA05FRDEMMAoGA1UEChMDVENTMQ4wDAYDVQQpEwVSb2hh bjEPMA0GA1UELBMGTm9JZGVhMQwwCgYDVQQrEwNWRFMxDjAMBgNVBCoTBVZydXNo MQ0wCwYDVQQEEwRTYXNpMQ4wDAYDVQQuEwVNZXRvbzEWMBQGCSqGSIb3DQEJARYH YUBiLmNvbTEPMA0GA1UEERMGNDAwMDkzMRIwEAYDVQQMEwlBbGxETkNlcnQxDjAM BgNVBAUTBVJ1Y2hpMRUwEwYKCZImiZPyLGQBGRYFVnJ1c2gxDTALBgNVBAkTBE1J REMxDzANBgNVBAcTBk11bWJhaTELMAkGA1UEBhMCSU4xFDASBgNVBAgTC01haGFy YXNodHJhMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDO0gVZhKdxqdBMd1sI KdW6TUNB0244zbuIzKltmJlOAnpud/94Irz3fiDpwlnoXEWWP8R11XFZg+IAv4nq Z6YRwQO+lnGPf/IMn/ES1X0xYGSGQsedS2lCGeMZGoES1tJrkbtvJ2v1fyVEp670 8sG4WIu50+wI0eeIdVknN4QaEQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAB1M+C7Q PNRCLM4H36T+7hUXYxvhd3EzLoLe5REorJAemoazB5FGNv7QyhOqKDXUaWp5pcC4 MQrvoWDpfueF+yBgophXy5FxYW0f95mftUnRZFT/ALSAlnpmWnz/Osq6iNssiJjs wRa6CTuDR+WSIQt2pZyxkTf+ILEsoydcudwl -----END CERTIFICATE----- Regards, Pavan -----Original Message----- From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Saturday, March 20, 2010 5:03 PM To: Konjarla, Pavan Cc: bug-gnutls at gnu.org Subject: Re: ASN1 structure implementation is missing for OID 2.5.4.17 which is PostalCode, and OID 2.5.4.41 (Name) definition Konjarla, Pavan wrote: > Hello, > > GnuTLS certtool is unable to display the correct value of Postal Code when the certificate subject contains 'Postal Code' as its one of DN fields. > > The scenario how to reproduce is as follows, > > > 1. Create a CSR with a DN which contains Postal Code as one of its DN attributes. > > 2. Send the CSR to any CA for test certificate. > > 3. After getting the certificate display the certificate using the certtool with ./certtool -i -infile command. > > 4. Observed that the value for Postal Code is displayed something like PostalCode=#0c06343030303933 instead of a valid decimal value. > > > To fix this problem we should add the definition for Postal Code with the corresponding OID in ASN1 structure. > > I am attaching the patch file with the feasible fix. Kindly let me know if you need any other information/clarification. Hello and thank you for the report and fix. I have committed a fix based on your patch. However would it be easy to you a send me a certificate that includes the postalcode and/or name so that I can verify parsing them right? regards, Nikos From ametzler at downhill.at.eu.org Mon Mar 22 19:15:13 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon, 22 Mar 2010 19:15:13 +0100 Subject: GnuTLS 2.8.6 In-Reply-To: <87d3yxsc8h.fsf@mocca.josefsson.org> References: <87fx411zyj.fsf@mocca.josefsson.org> <20100320083431.GB3262@downhill.g.la> <87d3yxsc8h.fsf@mocca.josefsson.org> Message-ID: <20100322181513.GC4468@downhill.g.la> On 2010-03-21 Simon Josefsson wrote: > Andreas Metzler writes: [...] > > - AC_LIB_HAVE_LINKFLAGS(gcrypt,, [#include ], > > + AC_LIB_HAVE_LINKFLAGS([gcrypt], [gpg-error], [#include ], [...] > > What problem is trying to solve? > GnuTLS doesn't build on Solaris without that. I am surprised. Afaiui AC_LIB_HAVE_LINKFLAGS parses the libtool la files and adds any dependency_libs. Is it possible that this only happened on incomplete installations (gcrypt la file not installed)? On Debian we actively work around this "feature" by editing the gcrypt la file and deleting the dependency_libs. > > Gnutls does not uses gpg-error functions, but ends up being linked > > against gpg-error even on architecures which do not require linkage > > against indirect dependencies. > Does that cause any problem? [...] Unnecessary linkage is a problem for distributors of binary packages since it complicates package depencies. This makes the installation program job a lot harder (and more expensive) than necessary. A second negative implication is that transitions caused by soname changes are harder since they involve more packages. (The second one shouldn't be a issue here, since libgpg-error upstream has promised that there won't be a soname bump, ever.) cu andreas From nmav at gnutls.org Tue Mar 23 18:27:21 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 23 Mar 2010 18:27:21 +0100 Subject: ASN1 structure implementation is missing for OID 2.5.4.17 which is PostalCode, and OID 2.5.4.41 (Name) definition In-Reply-To: References: <4BA4B281.5010008@gnutls.org> Message-ID: <4BA8F9F9.2020602@gnutls.org> Konjarla, Pavan wrote: > Hello, > > Attaching a test certificate with PostalCode attribute. Thank you. The current development version correctly parses it. regards, Nikos From simon at josefsson.org Tue Mar 23 19:33:27 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 23 Mar 2010 19:33:27 +0100 Subject: GnuTLS 2.8.6 In-Reply-To: <20100322181513.GC4468@downhill.g.la> (Andreas Metzler's message of "Mon, 22 Mar 2010 19:15:13 +0100") References: <87fx411zyj.fsf@mocca.josefsson.org> <20100320083431.GB3262@downhill.g.la> <87d3yxsc8h.fsf@mocca.josefsson.org> <20100322181513.GC4468@downhill.g.la> Message-ID: <87k4t2sxag.fsf@mocca.josefsson.org> Andreas Metzler writes: > On 2010-03-21 Simon Josefsson wrote: >> Andreas Metzler writes: > [...] >> > - AC_LIB_HAVE_LINKFLAGS(gcrypt,, [#include ], >> > + AC_LIB_HAVE_LINKFLAGS([gcrypt], [gpg-error], [#include ], > [...] >> > What problem is trying to solve? > >> GnuTLS doesn't build on Solaris without that. > > I am surprised. Afaiui AC_LIB_HAVE_LINKFLAGS parses the libtool la files > and adds any dependency_libs. Is it possible that this only happened > on incomplete installations (gcrypt la file not installed)? On Debian > we actively work around this "feature" by editing the gcrypt la file and > deleting the dependency_libs. I saw the problem on at least two Solaris systems, and on one of the systems I built libgpg-error+libgcrypt+gnutls from scratch and didn't remove any *.la files. Generally, I think the change above is actually The Right Thing because libgpg-error IS a dependency of libgcrypt. > >> > Gnutls does not uses gpg-error functions, but ends up being linked >> > against gpg-error even on architecures which do not require linkage >> > against indirect dependencies. > >> Does that cause any problem? > [...] > > Unnecessary linkage is a problem for distributors of binary packages > since it complicates package depencies. This makes the installation > program job a lot harder (and more expensive) than necessary. A second > negative implication is that transitions caused by soname changes are > harder since they involve more packages. (The second one shouldn't be > a issue here, since libgpg-error upstream has promised that there > won't be a soname bump, ever.) I don't know how to resolve that and also making things work on Solaris. As far as I can tell, building on Solaris seems more important than an optimization for one particular distribution. Further, if you don't have the fix above, you may run into problems with binutils-gold which really needs the explicit dependency: . There I solved the same problem by applying a similar patch that was used here, IIRC. /Simon From simon at josefsson.org Thu Mar 25 09:21:27 2010 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 25 Mar 2010 09:21:27 +0100 Subject: Security problem in GnuTLS v1.2.0 and earlier [GNUTLS-SA-2010-1] Message-ID: <87hbo4hkvs.fsf@mocca.josefsson.org> GnuTLS version 1.2.0 and earlier (released on 2005-01-27) on 64-bit platforms are vulnerable to a bug described in: https://bugzilla.redhat.com/show_bug.cgi?id=573028 Please note that the problem was solved for GnuTLS 1.2.1, released on 2005-04-04. Also, 32-bit platforms are not affected. I have added information about this on http://www.gnu.org/software/gnutls/security.html so that it contains the complete list of known security flaws. I'm using the keyword GNUTLS-SA-2010-1 for this. Thanks to Tomas Hoger and the RedHat team for finding and tracking down this problem. I have given this bug a 'Remote Denial of Service' severity, but if anyone has time to look at this bug, justification for any other severity is welcome. /Simon Tomas Hoger 2010-03-12 11:16:28 EST During the testing of GnuTLS updates, a flaw was discovered affecting Red Hat Enterprise Linux 4 GnuTLS packages on s390x platform, causing gnutls-cli to crash while printing server certificate info. This crash was caused by a flaw in gnutls_x509_crt_get_serial(), which calls asn1_read_value() to extract serial number from the x509 certificate. (lib/x509/x509.c) 526 int gnutls_x509_crt_get_serial(gnutls_x509_crt cert, void* result, 527 size_t* result_size) 528 { ... 536 if ((ret = asn1_read_value(cert->cert, "tbsCertificate.serialNumber", result, result_size)) < 0) { asn1_read_value() expects pointer to int (32 bit) as its third argument, but gnutls_x509_crt_get_serial() passed pointer to size_t (64 bit on 64 bit platforms) instead. On 64bit big endian platforms asn1_read_value() got incorrect length value. (lib/minitasn1/element.c) 598 asn1_retCode 599 asn1_read_value(node_asn *root,const char *name,void* ivalue, int *len) On little endian 64 bit platforms, high 32 bits of the *result_size size_t value were lost, but they only contained zeros. On big endian 64 bit platforms, low 32 bits were lost / ignored, causing asn1_read_value() to see length value as 0. This caused asn1_read_value() to return an error, but the length of the value that should have been extracted was saved to *len. gnutls_x509_crt_get_serial() did not correctly check return value of asn1_read_value(), failing to detect an error. After returning, caller could see a high value stored in *result_size (when interpreted as 64 bit value again). print_x509_info() (used by gnutls-cli or gnutls-serv) and print_certificate_info() (used by certtool) relied on the returned size value. Unexpected value caused a stack buffer overflow in those functions. This bug could also cause gnutls_x509_crt_check_revocation() to incorrectly check supplied X509 certificate against the list of revoked certificates, resulting in a bypass or the CRL check. This issue was fixed upstream via following commit: http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=112d537d This fix was first included in upstream version 1.2.1. Therefore, GnuTLS packages in Red Hat Enterprise Linux 5, Fedora, and current upstream GnuTLS versions are not affected by this flaw. Comment 2 Tomas Hoger 2010-03-25 03:57:43 EDT Making bug public. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 420 bytes Desc: not available URL: From simon at josefsson.org Thu Mar 25 09:41:55 2010 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 25 Mar 2010 09:41:55 +0100 Subject: Summer of code projects for GNU Message-ID: <8739zohjxo.fsf@mocca.josefsson.org> GNU is participating in summer of code this year and I may be able to mentor students doing work for any project I maintain. I'm not going to write up project ideas, but leave that to you (although check the project ideas for 2006 and 2007 for some ideas I have written down). For more information see: http://www.gnu.org/software/soc-projects/ideas-2010.html /Simon From ametzler at downhill.at.eu.org Sat Mar 27 16:32:50 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 27 Mar 2010 16:32:50 +0100 Subject: GnuTLS 2.8.6 In-Reply-To: <87k4t2sxag.fsf@mocca.josefsson.org> References: <87fx411zyj.fsf@mocca.josefsson.org> <20100320083431.GB3262@downhill.g.la> <87d3yxsc8h.fsf@mocca.josefsson.org> <20100322181513.GC4468@downhill.g.la> <87k4t2sxag.fsf@mocca.josefsson.org> Message-ID: <20100327153250.GD3294@downhill.g.la> On 2010-03-23 Simon Josefsson wrote: [...] > Further, if you don't have the fix above, you may run into problems with > binutils-gold which really needs the explicit dependency: > . There I > solved the same problem by applying a similar patch that was used here, > IIRC. [...] Afaik the cause of this bug was that shishi was using gpg-error directly (lib/low-crypto.c) without linking against it, for gnutls it is just an indirect dependency. cu andreas From simon at josefsson.org Sun Mar 28 22:02:53 2010 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 28 Mar 2010 22:02:53 +0200 Subject: GnuTLS 2.8.6 In-Reply-To: <20100327153250.GD3294@downhill.g.la> (Andreas Metzler's message of "Sat, 27 Mar 2010 16:32:50 +0100") References: <87fx411zyj.fsf@mocca.josefsson.org> <20100320083431.GB3262@downhill.g.la> <87d3yxsc8h.fsf@mocca.josefsson.org> <20100322181513.GC4468@downhill.g.la> <87k4t2sxag.fsf@mocca.josefsson.org> <20100327153250.GD3294@downhill.g.la> Message-ID: <87bpe86wpe.fsf@mocca.josefsson.org> Andreas Metzler writes: > On 2010-03-23 Simon Josefsson wrote: > [...] >> Further, if you don't have the fix above, you may run into problems with >> binutils-gold which really needs the explicit dependency: >> . There I >> solved the same problem by applying a similar patch that was used here, >> IIRC. > [...] > > Afaik the cause of this bug was that shishi was using gpg-error > directly (lib/low-crypto.c) without linking against it, for gnutls it > is just an indirect dependency. Oops! Indeed, thanks, so the issues are not the same. Still, I don't know a general way to make sure GnuTLS builds on Solaris but not generate this problem on Debian systems. Maybe this could be discussed on the gnulib list, it is a rather general problem, and the lib-*.m4 macros are from gnulib? /Simon From ludo at gnu.org Mon Mar 29 18:16:08 2010 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 29 Mar 2010 18:16:08 +0200 Subject: Tests fail without Valgrind Message-ID: <87634fayt3.fsf@gnu.org> Hello, Commit 57d407ab (which lacks a ChangeLog entry and adds non-GCS-formatted code) breaks ?make check? when run without Valgrind and without ?--disable-valgrind-checks?: --8<---------------cut here---------------start------------->8--- /bin/sh: line 9: -q: command not found FAIL: resume /bin/sh: line 9: -q: command not found FAIL: netconf-psk /bin/sh: line 9: -q: command not found --8<---------------cut here---------------end--------------->8--- (See .) Which leads to another question: do you receive the build notifications from Hydra? If you do receive them but don?t look at them, how do you think they could be improved to be more useful to you? Thanks, Ludo?. From simon at josefsson.org Tue Mar 30 17:41:41 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 30 Mar 2010 17:41:41 +0200 Subject: Missing =?utf-8?b?4oCYc3RydmVyc2NtcOKAmQ==?= Gnulib module In-Reply-To: <87tyrxygzr.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Tue, 30 Mar 2010 17:19:20 +0200") References: <87tyrxygzr.fsf@gnu.org> Message-ID: <87aatpn7ey.fsf@mocca.josefsson.org> ludo at gnu.org (Ludovic Court?s) writes: > Hello, > > (You should really have a ?bug-libtasn1? mailing list. :-)) It is called gnutls-devel at gnu.org. ;) Maybe a bug-libtasn1 (or help-libtasn1) list should be started, although there is some cost to maintain yet another mailing list for me... let's see how heavy the libtasn1-specific traffic will be on gnutls-devel first. > Libtasn1 should use Gnulib?s ?strverscmp? module since that function is > a GNU extension and is lacking on non-GNU platforms (e.g., > ). Libtasn1 already uses that module, but didn't link to it... Fixed as below: http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=ab67c9ada8549b03b3345b912362698355ef5a19 Let me know if you find any other portability issues. /Simon From nmav at gnutls.org Tue Mar 30 18:18:39 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 30 Mar 2010 18:18:39 +0200 Subject: Tests fail without Valgrind In-Reply-To: <87634fayt3.fsf@gnu.org> References: <87634fayt3.fsf@gnu.org> Message-ID: <4BB2245F.9090001@gnutls.org> Ludovic Court?s wrote: > Hello, > > Commit 57d407ab (which lacks a ChangeLog entry and adds > non-GCS-formatted code) breaks ?make check? when run without Valgrind > and without ?--disable-valgrind-checks?: Thanks. Should be fixed now. > another question: do you receive the build notifications > from Hydra? If you do receive them but don?t look at them, how do you > think they could be improved to be more useful to you? I check them but my time is quite limited. I can only work on gnutls certain days per week. My only concern is the failure rate due to tests failing because of a tcp reuse of the port... but this is different issue. regards, Nikos From ludo at gnu.org Tue Mar 30 18:43:37 2010 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Tue, 30 Mar 2010 18:43:37 +0200 Subject: Missing =?utf-8?b?4oCYc3RydmVyc2NtcOKAmQ==?= Gnulib module In-Reply-To: <87aatpn7ey.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 30 Mar 2010 17:41:41 +0200") References: <87tyrxygzr.fsf@gnu.org> <87aatpn7ey.fsf@mocca.josefsson.org> Message-ID: <87r5n1wyiu.fsf@gnu.org> Hi Simon, Simon Josefsson writes: > ludo at gnu.org (Ludovic Court?s) writes: >> (You should really have a ?bug-libtasn1? mailing list. :-)) > > It is called gnutls-devel at gnu.org. ;) Maybe a bug-libtasn1 (or > help-libtasn1) list should be started, although there is some cost to > maintain yet another mailing list for me... let's see how heavy the > libtasn1-specific traffic will be on gnutls-devel first. Or you could ask for an alias bug-libtasn1 at gnu.org -> gnutls-devel at gnu.org, for the sake of consistency with other GNU projects mailing list names. >> Libtasn1 should use Gnulib?s ?strverscmp? module since that function is >> a GNU extension and is lacking on non-GNU platforms (e.g., >> ). > > Libtasn1 already uses that module, but didn't link to it... Fixed as > below: > > http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=ab67c9ada8549b03b3345b912362698355ef5a19 Yeah, it fixes FreeBSD builds! :-) > Let me know if you find any other portability issues. On Darwin: --8<---------------cut here---------------start------------->8--- gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lib -I../gl -I../gl -g -O2 -c Test_errors.c Test_errors.c: In function 'main': Test_errors.c:33: warning: 'libtasn1_strerror' is deprecated (declared at ../lib/libtasn1.h:319) Test_errors.c:34: warning: 'libtasn1_perror' is deprecated (declared at ../lib/libtasn1.h:324) /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -no-install -o Test_errors Test_errors.o ../lib/libtasn1.la libtool: link: warning: `-no-install' is ignored for i386-apple-darwin9.8.0 libtool: link: warning: assuming `-no-fast-install' instead libtool: link: gcc -std=gnu99 -g -O2 -o .libs/Test_errors Test_errors.o ../lib/.libs/libtasn1.dylib Undefined symbols: "_libtasn1_strerror", referenced from: _main in Test_errors.o "_libtasn1_perror", referenced from: _main in Test_errors.o ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [Test_errors] Error 1 --8<---------------cut here---------------end--------------->8--- (From .) I can set up email notification if you want. Thanks, Ludo?. From simon at josefsson.org Tue Mar 30 22:00:54 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 30 Mar 2010 22:00:54 +0200 Subject: Missing =?utf-8?b?4oCYc3RydmVyc2NtcOKAmQ==?= Gnulib module In-Reply-To: <87r5n1wyiu.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Tue, 30 Mar 2010 18:43:37 +0200") References: <87tyrxygzr.fsf@gnu.org> <87aatpn7ey.fsf@mocca.josefsson.org> <87r5n1wyiu.fsf@gnu.org> Message-ID: <87ljd9k2a1.fsf@mocca.josefsson.org> ludo at gnu.org (Ludovic Court?s) writes: > Hi Simon, > > Simon Josefsson writes: > >> ludo at gnu.org (Ludovic Court?s) writes: > >>> (You should really have a ?bug-libtasn1? mailing list. :-)) >> >> It is called gnutls-devel at gnu.org. ;) Maybe a bug-libtasn1 (or >> help-libtasn1) list should be started, although there is some cost to >> maintain yet another mailing list for me... let's see how heavy the >> libtasn1-specific traffic will be on gnutls-devel first. > > Or you could ask for an alias bug-libtasn1 at gnu.org -> > gnutls-devel at gnu.org, for the sake of consistency with other GNU > projects mailing list names. Done, let's see if it works... >>> Libtasn1 should use Gnulib?s ?strverscmp? module since that function is >>> a GNU extension and is lacking on non-GNU platforms (e.g., >>> ). >> >> Libtasn1 already uses that module, but didn't link to it... Fixed as >> below: >> >> http://git.savannah.gnu.org/cgit/libtasn1.git/commit/?id=ab67c9ada8549b03b3345b912362698355ef5a19 > > Yeah, it fixes FreeBSD builds! :-) Great. >> Let me know if you find any other portability issues. > > On Darwin: > > gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lib -I../gl -I../gl -g -O2 -c Test_errors.c > Test_errors.c: In function 'main': > Test_errors.c:33: warning: 'libtasn1_strerror' is deprecated (declared at ../lib/libtasn1.h:319) > Test_errors.c:34: warning: 'libtasn1_perror' is deprecated (declared at ../lib/libtasn1.h:324) > /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -no-install -o Test_errors Test_errors.o ../lib/libtasn1.la > libtool: link: warning: `-no-install' is ignored for i386-apple-darwin9.8.0 > libtool: link: warning: assuming `-no-fast-install' instead > libtool: link: gcc -std=gnu99 -g -O2 -o .libs/Test_errors Test_errors.o ../lib/.libs/libtasn1.dylib > Undefined symbols: > "_libtasn1_strerror", referenced from: > _main in Test_errors.o > "_libtasn1_perror", referenced from: > _main in Test_errors.o > ld: symbol(s) not found > collect2: ld returned 1 exit status > make[2]: *** [Test_errors] Error 1 Should be fixed now too. > I can set up email notification if you want. Yes, please do, send them to libtasn1-commit at gnu.org (which is a list that exists). Thanks, /Simon From simon at josefsson.org Tue Mar 30 22:39:24 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 30 Mar 2010 22:39:24 +0200 Subject: Tests fail without Valgrind In-Reply-To: <87634fayt3.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Mon, 29 Mar 2010 18:16:08 +0200") References: <87634fayt3.fsf@gnu.org> Message-ID: <87hbnxk0hv.fsf@mocca.josefsson.org> ludo at gnu.org (Ludovic Court?s) writes: > Which leads to another question: do you receive the build notifications > from Hydra? If you do receive them but don?t look at them, how do you > think they could be improved to be more useful to you? Can we disable e-mail notifications for coverage failures? Ideally, I would want notification to work something like this: designate one platform as the trigger platform. If building a revision on that platform fails, send ONE notification, and don't bother send any more notifications about any failures (possibly it could complain once per week if the trigger platform is not building for a long time). If a revision has been built on the trigger platform, and fails to build on some other platform, send ONE notification for failures on that platform, and don't bother send any more notifications for that platform until it is working. To be clear, I don't see any point in the FAILED->SUCCEEDED notifications at all, as long as it complains every week if some platform is still broken. Implementation wise, I suspect notification needs to be separated from the build process to implement complex logic above sufficiently well. The build process should happen continuously in the background, but the notification logic runs on the output from that process. Just some ideas... I hope to find more time to help on build robot ideas. /Simon From ludo at gnu.org Wed Mar 31 00:07:10 2010 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Wed, 31 Mar 2010 00:07:10 +0200 Subject: Missing =?utf-8?b?4oCYc3RydmVyc2NtcOKAmQ==?= Gnulib module In-Reply-To: <87ljd9k2a1.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 30 Mar 2010 22:00:54 +0200") References: <87tyrxygzr.fsf@gnu.org> <87aatpn7ey.fsf@mocca.josefsson.org> <87r5n1wyiu.fsf@gnu.org> <87ljd9k2a1.fsf@mocca.josefsson.org> Message-ID: <87y6h9tqep.fsf@gnu.org> Hello! Simon Josefsson writes: >> On Darwin: >> >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../lib -I../gl -I../gl -g -O2 -c Test_errors.c >> Test_errors.c: In function 'main': >> Test_errors.c:33: warning: 'libtasn1_strerror' is deprecated (declared at ../lib/libtasn1.h:319) >> Test_errors.c:34: warning: 'libtasn1_perror' is deprecated (declared at ../lib/libtasn1.h:324) >> /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -no-install -o Test_errors Test_errors.o ../lib/libtasn1.la >> libtool: link: warning: `-no-install' is ignored for i386-apple-darwin9.8.0 >> libtool: link: warning: assuming `-no-fast-install' instead >> libtool: link: gcc -std=gnu99 -g -O2 -o .libs/Test_errors Test_errors.o ../lib/.libs/libtasn1.dylib >> Undefined symbols: >> "_libtasn1_strerror", referenced from: >> _main in Test_errors.o >> "_libtasn1_perror", referenced from: >> _main in Test_errors.o >> ld: symbol(s) not found >> collect2: ld returned 1 exit status >> make[2]: *** [Test_errors] Error 1 > > Should be fixed now too. Indeed, it?s all blue now: . :-) > Yes, please do, send them to libtasn1-commit at gnu.org (which is a list > that exists). Done. Ludo?. From ludo at gnu.org Wed Mar 31 16:28:51 2010 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Wed, 31 Mar 2010 16:28:51 +0200 Subject: Tests fail without Valgrind In-Reply-To: <87hbnxk0hv.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 30 Mar 2010 22:39:24 +0200") References: <87634fayt3.fsf@gnu.org> <87hbnxk0hv.fsf@mocca.josefsson.org> Message-ID: <87pr2kwonw.fsf@gnu.org> Hello! [Cc: hydra-users at gnu.org.] Simon Josefsson writes: > ludo at gnu.org (Ludovic Court?s) writes: > >> Which leads to another question: do you receive the build notifications >> from Hydra? If you do receive them but don?t look at them, how do you >> think they could be improved to be more useful to you? > > Can we disable e-mail notifications for coverage failures? Yes. Done. > Ideally, I would want notification to work something like this: > designate one platform as the trigger platform. If building a revision > on that platform fails, send ONE notification, and don't bother send any > more notifications about any failures (possibly it could complain once > per week if the trigger platform is not building for a long time). If a > revision has been built on the trigger platform, and fails to build on > some other platform, send ONE notification for failures on that > platform, and don't bother send any more notifications for that platform > until it is working. IIUC what you suggest, that?s similar to what has been happening for some time now: notifications are sent when the status of a job?x?platform changes (SUCCEEDED -> FAILED, or FAILED -> SUCCEEDED). So you get one message when the package breaks and you don?t get any new message until it?s fixed. (When we started using Hydra, you would get one message each time a build fails, which quickly led to flooding.) There?s currently no notion of a ?trigger platform?, though, but I don?t understand its role in your suggestion. Can you clarify what you want to achieve and how the trigger platform would help? > To be clear, I don't see any point in the FAILED->SUCCEEDED > notifications at all, OK. I personally find it useful: it gives feedback when I fix something, and I start worrying if I don?t get the message. :-) > as long as it complains every week if some platform is still broken. Don?t forget there?s also a web page. Basically, I see notifications as a way of getting quick feedback so that one can react quickly. In cases where quick response is not needed, it?s probably enough to check the status page (e.g., ) once in a while. > Implementation wise, I suspect notification needs to be separated from > the build process to implement complex logic above sufficiently well. The build process is handled by Nix while Hydra does the checkouts, triggers and schedules builds, and provides the web interface and email notifications. Thanks for your feedback! Please use the new hydra-users at gnu.org mailing list for complaints, feature requests, etc. Ludo?.