From simon at josefsson.org  Sun Feb  1 11:02:37 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 01 Feb 2009 11:02:37 +0100
Subject: Gaim is now Pidgin
In-Reply-To: <1233085986.9353.8.camel@T60> ("Sven =?iso-8859-1?Q?M=FCller?=
	=?iso-8859-1?Q?=22's?= message of "Tue,
	27 Jan 2009 20:53:06 +0100")
References: <1233085986.9353.8.camel@T60>
Message-ID: <87iqnumq4i.fsf@mocca.josefsson.org>

Sven M?ller <sven.mueller at enfos.de> writes:

> Dear gnutls staff,
>
> in the program list appears Gaim, which was renamed - due to brand
> violation charges by aol - to Pidgin.

I updated the web page, thanks.

/Simon




From simon at josefsson.org  Sun Feb  1 11:07:31 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 01 Feb 2009 11:07:31 +0100
Subject: client certificate authentication
In-Reply-To: <497C8588.3000904@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sun, 25 Jan 2009 17:30:16 +0200")
References: <1231356138.7163.7.camel@nimitz.example.org>
	<4974DD81.4020400@gnutls.org>
	<1232484433.7434.31.camel@nimitz.example.org>
	<1232883443.19927.20.camel@nimitz.example.org>
	<497C8588.3000904@gnutls.org>
Message-ID: <87eiyimpwc.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> The attached patch tries stay on the safe side and don't try to upgrade
> the TLS version on a rehandshake. I'm not sure whether this is the right
> thing to do, although performing a rehandshake to upgrade the TLS
> version seems quite unlikely.

I suspect it will become more likely given TLS 1.1 and TLS 1.2: you may
want to try TLS 1.0 on initial handshake, and then want to attempt more
recent TLS versions to get more advanced features from the other end --
however I think we use the patch for now and revisit this if someone
runs into this limit in the future.

This seems like a protocol issue, so we could ask on the IETF list
too...

/Simon




From simon at josefsson.org  Mon Feb  2 13:40:15 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 02 Feb 2009 13:40:15 +0100
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <496E1B02.7010507@anl.gov> (Douglas E. Engert's message of "Wed, 
	14 Jan 2009 11:04:02 -0600")
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org> <49677E15.6030702@anl.gov>
	<87wsd4774d.fsf@mocca.josefsson.org> <49679093.3070509@anl.gov>
	<87tz87gydq.fsf@mocca.josefsson.org> <496B63A6.4090804@anl.gov>
	<871vv8mslq.fsf@mocca.josefsson.org> <496E1B02.7010507@anl.gov>
Message-ID: <87vdrtj9lc.fsf@mocca.josefsson.org>

"Douglas E. Engert" <deengert at anl.gov> writes:

> Simon Josefsson wrote:
>>
>> If the patch is over 10 lines long we will need a copyright assignment
>> before we can apply it though.  If you want to speed up the process, you
>> could fill out the form below now.
>>
>
> I sent in the form to assign at gnu.org. They are sending a paper copy
> which must be signed and mailed back. This may be a problem, as I will
> have to get it OK'ed, which might take weeks.
>
> So here is the short version of a "shorten the cert chain" patch that
> is only 10 lines long. Do with it what you want. As this fixes
> our problem, I consider it a bug fix.
>
> But you will need to add a check_if_same_cert routine, which can be
> taken from the first half of the check_if_ca routine. The line numbers
> may be off, but in the 2.6.3 version, it would be inserted at line 394.
>
> This will also solve our problem, as V1 cert will not get used at all
> ans the intermediate cert is trusted and is V3.

Thanks for the patch.  I started looking at this now, and there is a
small problem: the code removes certificates from the certificate chain
before the CRL code has had a chance to check whether certificates in
the chain are revoked.  I think the best is to move the CRL checking
code up a bit.

I'll try to get a new 2.6.x and 2.4.x release out, and then look further
at getting your patch into the 2.7.x branch.  I'm rather busy this week
though, so may not have time until next week.

/Simon




From simon at josefsson.org  Mon Feb  2 17:35:07 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 02 Feb 2009 17:35:07 +0100
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <496E1B02.7010507@anl.gov> (Douglas E. Engert's message of "Wed, 
	14 Jan 2009 11:04:02 -0600")
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org> <49677E15.6030702@anl.gov>
	<87wsd4774d.fsf@mocca.josefsson.org> <49679093.3070509@anl.gov>
	<87tz87gydq.fsf@mocca.josefsson.org> <496B63A6.4090804@anl.gov>
	<871vv8mslq.fsf@mocca.josefsson.org> <496E1B02.7010507@anl.gov>
Message-ID: <874ozckdac.fsf@mocca.josefsson.org>

I reconsidered, and think we should push this patch into 2.6.x since it
helps users deal with RSA-MD5 chains.  The only recommendation we have
right now is to patch applications to provide an option to accept
RSA-MD5.  That is still insecure.  With your patch, users will have a
another transition strategy while they are moving end-entity
certificates from RSA-MD5 chains to a RSA-SHA1 chain: explicitly trust
the intermediary RSA-MD5 cert.  Users can make some additional steps to
mitigate the hazards with RSA-MD5 certs (like comparing it with several
year old intermediary RSA-MD5 certs before the RSA-MD5 vulnerability
were common knowledge).

I used your small patch and pushed the following:

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=0ca6c0eeb67e3be4f6d79d775f23c3fccba97444

I'll be backporting this to the 2.6.x and 2.4.x branches and make some
pre-releases.

Thanks,
/Simon




From deengert at anl.gov  Mon Feb  2 17:40:58 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 02 Feb 2009 10:40:58 -0600
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <87vdrtj9lc.fsf@mocca.josefsson.org>
References: <49654581.3020505@anl.gov>
	<87sknu2ozf.fsf@mocca.josefsson.org>	<49663944.6030708@anl.gov>
	<87k594g5uv.fsf@mocca.josefsson.org>	<87bpugg4xg.fsf@mocca.josefsson.org>
	<49677E15.6030702@anl.gov>	<87wsd4774d.fsf@mocca.josefsson.org>
	<49679093.3070509@anl.gov>	<87tz87gydq.fsf@mocca.josefsson.org>
	<496B63A6.4090804@anl.gov>	<871vv8mslq.fsf@mocca.josefsson.org>
	<496E1B02.7010507@anl.gov> <87vdrtj9lc.fsf@mocca.josefsson.org>
Message-ID: <4987221A.1000405@anl.gov>



Simon Josefsson wrote:
> "Douglas E. Engert" <deengert at anl.gov> writes:
> 
>> Simon Josefsson wrote:
>>> If the patch is over 10 lines long we will need a copyright assignment
>>> before we can apply it though.  If you want to speed up the process, you
>>> could fill out the form below now.
>>>
>> I sent in the form to assign at gnu.org. They are sending a paper copy
>> which must be signed and mailed back. This may be a problem, as I will
>> have to get it OK'ed, which might take weeks.
>>
>> So here is the short version of a "shorten the cert chain" patch that
>> is only 10 lines long. Do with it what you want. As this fixes
>> our problem, I consider it a bug fix.
>>
>> But you will need to add a check_if_same_cert routine, which can be
>> taken from the first half of the check_if_ca routine. The line numbers
>> may be off, but in the 2.6.3 version, it would be inserted at line 394.
>>
>> This will also solve our problem, as V1 cert will not get used at all
>> ans the intermediate cert is trusted and is V3.
> 
> Thanks for the patch.  I started looking at this now, and there is a
> small problem: the code removes certificates from the certificate chain
> before the CRL code has had a chance to check whether certificates in
> the chain are revoked.  I think the best is to move the CRL checking
> code up a bit.

But the certs it removes are ones that you have in your trusted list.
Are you saying that you don't check CRLs for the trusted certs? Should
you? Without the mod, is there a security concern if an attacker sends
in a short list, in effect duplicating what the mod does?

> 
> I'll try to get a new 2.6.x and 2.4.x release out, and then look further
> at getting your patch into the 2.7.x branch.  I'm rather busy this week
> though, so may not have time until next week.
> 

I am at the ISOC NDSS meeting next week, so am busy too.


> /Simon
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444




From deengert at anl.gov  Mon Feb  2 17:48:53 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 02 Feb 2009 10:48:53 -0600
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <874ozckdac.fsf@mocca.josefsson.org>
References: <49654581.3020505@anl.gov>
	<87sknu2ozf.fsf@mocca.josefsson.org>	<49663944.6030708@anl.gov>
	<87k594g5uv.fsf@mocca.josefsson.org>	<87bpugg4xg.fsf@mocca.josefsson.org>
	<49677E15.6030702@anl.gov>	<87wsd4774d.fsf@mocca.josefsson.org>
	<49679093.3070509@anl.gov>	<87tz87gydq.fsf@mocca.josefsson.org>
	<496B63A6.4090804@anl.gov>	<871vv8mslq.fsf@mocca.josefsson.org>
	<496E1B02.7010507@anl.gov> <874ozckdac.fsf@mocca.josefsson.org>
Message-ID: <498723F5.2090007@anl.gov>



Simon Josefsson wrote:
> I reconsidered, and think we should push this patch into 2.6.x since it
> helps users deal with RSA-MD5 chains.  The only recommendation we have
> right now is to patch applications to provide an option to accept
> RSA-MD5.  That is still insecure.  With your patch, users will have a
> another transition strategy while they are moving end-entity
> certificates from RSA-MD5 chains to a RSA-SHA1 chain: explicitly trust
> the intermediary RSA-MD5 cert.  Users can make some additional steps to
> mitigate the hazards with RSA-MD5 certs (like comparing it with several
> year old intermediary RSA-MD5 certs before the RSA-MD5 vulnerability
> were common knowledge).
> 
> I used your small patch and pushed the following:
> 
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=0ca6c0eeb67e3be4f6d79d775f23c3fccba97444
> 
> I'll be backporting this to the 2.6.x and 2.4.x branches and make some
> pre-releases.

Looks good.

> 
> Thanks,
> /Simon
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444




From simon at josefsson.org  Mon Feb  2 17:58:05 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 02 Feb 2009 17:58:05 +0100
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <4987221A.1000405@anl.gov> (Douglas E. Engert's message of "Mon, 
	02 Feb 2009 10:40:58 -0600")
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org> <49677E15.6030702@anl.gov>
	<87wsd4774d.fsf@mocca.josefsson.org> <49679093.3070509@anl.gov>
	<87tz87gydq.fsf@mocca.josefsson.org> <496B63A6.4090804@anl.gov>
	<871vv8mslq.fsf@mocca.josefsson.org> <496E1B02.7010507@anl.gov>
	<87vdrtj9lc.fsf@mocca.josefsson.org> <4987221A.1000405@anl.gov>
Message-ID: <87y6woixnm.fsf@mocca.josefsson.org>

"Douglas E. Engert" <deengert at anl.gov> writes:

> Simon Josefsson wrote:
>> "Douglas E. Engert" <deengert at anl.gov> writes:
>>
>>> Simon Josefsson wrote:
>>>> If the patch is over 10 lines long we will need a copyright assignment
>>>> before we can apply it though.  If you want to speed up the process, you
>>>> could fill out the form below now.
>>>>
>>> I sent in the form to assign at gnu.org. They are sending a paper copy
>>> which must be signed and mailed back. This may be a problem, as I will
>>> have to get it OK'ed, which might take weeks.
>>>
>>> So here is the short version of a "shorten the cert chain" patch that
>>> is only 10 lines long. Do with it what you want. As this fixes
>>> our problem, I consider it a bug fix.
>>>
>>> But you will need to add a check_if_same_cert routine, which can be
>>> taken from the first half of the check_if_ca routine. The line numbers
>>> may be off, but in the 2.6.3 version, it would be inserted at line 394.
>>>
>>> This will also solve our problem, as V1 cert will not get used at all
>>> ans the intermediate cert is trusted and is V3.
>>
>> Thanks for the patch.  I started looking at this now, and there is a
>> small problem: the code removes certificates from the certificate chain
>> before the CRL code has had a chance to check whether certificates in
>> the chain are revoked.  I think the best is to move the CRL checking
>> code up a bit.
>
> But the certs it removes are ones that you have in your trusted list.

I think it can remove more, consider this:

Root-CA -> Intermediary-CA-1 -> Intermediary-CA-2 -> End-Entity Cert

Let's consider if you put I-CA-2 in your trusted cert list.  Your code
will shorten the cert list into I-CA-2 -> E-E Cert, thereby removing
I-CA-1.  However, it seems like I-CA-1 could be revoked by a CRL.
Before, the code would detect this and reject the chain.

I'm not sure what should happen here though... if you have a CRL that
revokes I-CA-1 but also explicitly trust I-CA-2, should validation
succeed or not?

> Are you saying that you don't check CRLs for the trusted certs? Should
> you?

The code reads:

  for (i = 0; i < clist_size; i++)
    {
      ret = gnutls_x509_crt_check_revocation (certificate_list[i],
					      CRLs, crls_size);
...

Thus, it only checks revocation for the earliest entries of clist_size.
Thus, it seems the CRL check should come early, before GnuTLS trims off
entries from clist_size.

I've moved the CRL check first in the function in the patch I have
installed.

I'm not sure how many are using CRLs though.

> Without the mod, is there a security concern if an attacker sends in a
> short list, in effect duplicating what the mod does?

I don't follow the attack?  If it is a short list, the chain won't
validate because GnuTLS will not be able to find intermediary certs.
GnuTLS will only use the trusted cert list to trim off certs from the
list, and to validate the last cert in the list.  Otherwise, the chain
needs to be complete (and in order) as provided from the server.

/Simon




From deengert at anl.gov  Mon Feb  2 18:18:05 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Mon, 02 Feb 2009 11:18:05 -0600
Subject: gnutls fails to use Verisign CA cert without a Basic Constraint
In-Reply-To: <87y6woixnm.fsf@mocca.josefsson.org>
References: <49654581.3020505@anl.gov>
	<87sknu2ozf.fsf@mocca.josefsson.org>	<49663944.6030708@anl.gov>
	<87k594g5uv.fsf@mocca.josefsson.org>	<87bpugg4xg.fsf@mocca.josefsson.org>
	<49677E15.6030702@anl.gov>	<87wsd4774d.fsf@mocca.josefsson.org>
	<49679093.3070509@anl.gov>	<87tz87gydq.fsf@mocca.josefsson.org>
	<496B63A6.4090804@anl.gov>	<871vv8mslq.fsf@mocca.josefsson.org>
	<496E1B02.7010507@anl.gov>	<87vdrtj9lc.fsf@mocca.josefsson.org>
	<4987221A.1000405@anl.gov> <87y6woixnm.fsf@mocca.josefsson.org>
Message-ID: <49872ACD.8040606@anl.gov>



Simon Josefsson wrote:
> "Douglas E. Engert" <deengert at anl.gov> writes:
> 
>> Simon Josefsson wrote:
>>> "Douglas E. Engert" <deengert at anl.gov> writes:
>>>
>>>> Simon Josefsson wrote:
>>>>> If the patch is over 10 lines long we will need a copyright assignment
>>>>> before we can apply it though.  If you want to speed up the process, you
>>>>> could fill out the form below now.
>>>>>
>>>> I sent in the form to assign at gnu.org. They are sending a paper copy
>>>> which must be signed and mailed back. This may be a problem, as I will
>>>> have to get it OK'ed, which might take weeks.
>>>>
>>>> So here is the short version of a "shorten the cert chain" patch that
>>>> is only 10 lines long. Do with it what you want. As this fixes
>>>> our problem, I consider it a bug fix.
>>>>
>>>> But you will need to add a check_if_same_cert routine, which can be
>>>> taken from the first half of the check_if_ca routine. The line numbers
>>>> may be off, but in the 2.6.3 version, it would be inserted at line 394.
>>>>
>>>> This will also solve our problem, as V1 cert will not get used at all
>>>> ans the intermediate cert is trusted and is V3.
>>> Thanks for the patch.  I started looking at this now, and there is a
>>> small problem: the code removes certificates from the certificate chain
>>> before the CRL code has had a chance to check whether certificates in
>>> the chain are revoked.  I think the best is to move the CRL checking
>>> code up a bit.
>> But the certs it removes are ones that you have in your trusted list.
> 
> I think it can remove more, consider this:
> 
> Root-CA -> Intermediary-CA-1 -> Intermediary-CA-2 -> End-Entity Cert
> 
> Let's consider if you put I-CA-2 in your trusted cert list.  Your code
> will shorten the cert list into I-CA-2 -> E-E Cert, thereby removing
> I-CA-1.  However, it seems like I-CA-1 could be revoked by a CRL.
> Before, the code would detect this and reject the chain.
> 
> I'm not sure what should happen here though... if you have a CRL that
> revokes I-CA-1 but also explicitly trust I-CA-2, should validation
> succeed or not?

Good question. I am am correct, some other versions of path validation, have
both trusted cert and intermediate cert stores: OpenSSL, NSS, and Windows.
GnuTLS appears to only have one trusted cert store.  In the the vendor's code
one could put I-CA-1 into the trusted cert store, and I-CA-2 in to the
intermediate store. I believe in this case the CRLs for I-CA-2 will be checked,
but not for I-CA-1.

> 
>> Are you saying that you don't check CRLs for the trusted certs? Should
>> you?
> 
> The code reads:
> 
>   for (i = 0; i < clist_size; i++)
>     {
>       ret = gnutls_x509_crt_check_revocation (certificate_list[i],
> 					      CRLs, crls_size);
> ...
> 
> Thus, it only checks revocation for the earliest entries of clist_size.
> Thus, it seems the CRL check should come early, before GnuTLS trims off
> entries from clist_size.
> 
> I've moved the CRL check first in the function in the patch I have
> installed.
> 
> I'm not sure how many are using CRLs though.
> 

Maybe not today, but people should...

>> Without the mod, is there a security concern if an attacker sends in a
>> short list, in effect duplicating what the mod does?
> 

I may not have understood your original concern.

> I don't follow the attack?  If it is a short list, the chain won't
> validate because GnuTLS will not be able to find intermediary certs.
> GnuTLS will only use the trusted cert list to trim off certs from the
> list, and to validate the last cert in the list.  Otherwise, the chain
> needs to be complete (and in order) as provided from the server.

My question may have come from the fact that GnuTLS has only one
cert store, rather then two, and tries to verify the cert chain all the
way to a self signed root cert, rather then saying it's OK to stop
at a trusted cert.

Our concern is to not have to put a Versign V1 self sign cert in the
cert store, but to trust the intermediate cert which they publish
on their web site.

> 
> /Simon
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444




From simon at josefsson.org  Mon Feb  2 18:22:37 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 02 Feb 2009 18:22:37 +0100
Subject: Release candidates of GnuTLS 2.4.3 and 2.6.4
In-Reply-To: <874ozckdac.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 02 Feb 2009 17:35:07 +0100")
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org> <49677E15.6030702@anl.gov>
	<87wsd4774d.fsf@mocca.josefsson.org> <49679093.3070509@anl.gov>
	<87tz87gydq.fsf@mocca.josefsson.org> <496B63A6.4090804@anl.gov>
	<871vv8mslq.fsf@mocca.josefsson.org> <496E1B02.7010507@anl.gov>
	<874ozckdac.fsf@mocca.josefsson.org>
Message-ID: <87tz7ciwiq.fsf_-_@mocca.josefsson.org>

I have prepared new daily builds containing state-of-the-art fixes for
GnuTLS branches 2.4.x, 2.6.x, and 2.7.x:

http://daily.josefsson.org/gnutls-2.4/gnutls-2.4-20090202.tar.gz
http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20090202.tar.gz
http://daily.josefsson.org/gnutls/gnutls-20090202.tar.gz

I'd appreciate if people could test these, and/or compare the source to
what's in various distribution to see if some patch has been missed.

If you know any other concern for v2.6.x, now is a good time to bring it
up!  Nothing will change if you don't speak up.

/Simon




From deengert at anl.gov  Tue Feb  3 21:43:19 2009
From: deengert at anl.gov (Douglas E. Engert)
Date: Tue, 03 Feb 2009 14:43:19 -0600
Subject: Release candidates of GnuTLS 2.4.3 and 2.6.4
In-Reply-To: <87tz7ciwiq.fsf_-_@mocca.josefsson.org>
References: <49654581.3020505@anl.gov>
	<87sknu2ozf.fsf@mocca.josefsson.org>	<49663944.6030708@anl.gov>
	<87k594g5uv.fsf@mocca.josefsson.org>	<87bpugg4xg.fsf@mocca.josefsson.org>
	<49677E15.6030702@anl.gov>	<87wsd4774d.fsf@mocca.josefsson.org>
	<49679093.3070509@anl.gov>	<87tz87gydq.fsf@mocca.josefsson.org>
	<496B63A6.4090804@anl.gov>	<871vv8mslq.fsf@mocca.josefsson.org>
	<496E1B02.7010507@anl.gov>	<874ozckdac.fsf@mocca.josefsson.org>
	<87tz7ciwiq.fsf_-_@mocca.josefsson.org>
Message-ID: <4988AC67.2010501@anl.gov>



Simon Josefsson wrote:
> I have prepared new daily builds containing state-of-the-art fixes for
> GnuTLS branches 2.4.x, 2.6.x, and 2.7.x:
> 
> http://daily.josefsson.org/gnutls-2.4/gnutls-2.4-20090202.tar.gz
> http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20090202.tar.gz
> http://daily.josefsson.org/gnutls/gnutls-20090202.tar.gz
> 

Tried compile of 2.6-20090202. What version of libgcrypt11 is required?
Compile failed to find GCRY_MD_SHA224. I was using libgcrypt11-1.2.4-2Ubuntu-7
which does not have appear to have SHA224.


> I'd appreciate if people could test these, and/or compare the source to
> what's in various distribution to see if some patch has been missed.
> 
> If you know any other concern for v2.6.x, now is a good time to bring it
> up!  Nothing will change if you don't speak up.
> 
> /Simon
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444




From simon at josefsson.org  Wed Feb  4 07:35:41 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 04 Feb 2009 07:35:41 +0100
Subject: Release candidates of GnuTLS 2.4.3 and 2.6.4
In-Reply-To: <4988AC67.2010501@anl.gov> (Douglas E. Engert's message of "Tue, 
	03 Feb 2009 14:43:19 -0600")
References: <49654581.3020505@anl.gov> <87sknu2ozf.fsf@mocca.josefsson.org>
	<49663944.6030708@anl.gov> <87k594g5uv.fsf@mocca.josefsson.org>
	<87bpugg4xg.fsf@mocca.josefsson.org> <49677E15.6030702@anl.gov>
	<87wsd4774d.fsf@mocca.josefsson.org> <49679093.3070509@anl.gov>
	<87tz87gydq.fsf@mocca.josefsson.org> <496B63A6.4090804@anl.gov>
	<871vv8mslq.fsf@mocca.josefsson.org> <496E1B02.7010507@anl.gov>
	<874ozckdac.fsf@mocca.josefsson.org>
	<87tz7ciwiq.fsf_-_@mocca.josefsson.org> <4988AC67.2010501@anl.gov>
Message-ID: <87iqnq1zgi.fsf@mocca.josefsson.org>

"Douglas E. Engert" <deengert at anl.gov> writes:

> Simon Josefsson wrote:
>> I have prepared new daily builds containing state-of-the-art fixes for
>> GnuTLS branches 2.4.x, 2.6.x, and 2.7.x:
>>
>> http://daily.josefsson.org/gnutls-2.4/gnutls-2.4-20090202.tar.gz
>> http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20090202.tar.gz
>> http://daily.josefsson.org/gnutls/gnutls-20090202.tar.gz
>>
>
> Tried compile of 2.6-20090202. What version of libgcrypt11 is required?
> Compile failed to find GCRY_MD_SHA224. I was using libgcrypt11-1.2.4-2Ubuntu-7
> which does not have appear to have SHA224.

Libgcrypt v1.3.0 or later is required, this is the same as for the
entire 2.6.x branch.  If your platform uses the gnutls 2.4.x branch, it
might be better to test it instead.

The dependency on libgcrypt v1.3.0+ isn't critical, but we have to
disable the SHA-2 and Camellia in GnuTLS if libgcrypt < 1.3.0 is used.
This could be done, I think.

/Simon




From simon at josefsson.org  Fri Feb  6 21:02:37 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 06 Feb 2009 21:02:37 +0100
Subject: Some compile issues of gnutls 2.6.3 on Solaris
In-Reply-To: <0860A8D9-BFA3-40A0-9BD6-2F44E0F1D855@opencsw.org> (Dagobert
	Michelsen's message of "Thu, 22 Jan 2009 17:48:57 +0100")
References: <C31B13FF-0A76-4A38-A475-D9C817954F43@opencsw.org>
	<878wp45p0t.fsf@mocca.josefsson.org>
	<0860A8D9-BFA3-40A0-9BD6-2F44E0F1D855@opencsw.org>
Message-ID: <87vdrn72qq.fsf@mocca.josefsson.org>

Dagobert Michelsen <dam at opencsw.org> writes:

> Hi Simon,
>
> Am 21.01.2009 um 22:26 schrieb Simon Josefsson:
>> This was new, thank you.  Should be fixed on trunk.  Please test
>> updated
>> daily build of the 2.6.x trunk (soon to be released):
>>
>> http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20090121.tar.gz
>
> Compilation and testing works fine now. However, on installation I get
>
> libtool: install: warning: relinking `libgnutlsxx.la'
> libtool: install: (cd /home/dam/mgar/pkg/gnutls/trunk/work/build-isa-
> sparcv8/gnutls-2.6.4/lib; /bin/bash /home/dam/mgar/pkg/gnutls/trunk/
> work/build-isa-sparcv8/gnutls-2.6.4/libtool  --tag CXX --mode=relink /
> opt/studio/SOS11/SUNWspro/bin/CC -I../includes/ -xO3 -xarch=v8 -I/opt/
> csw/include -no-undefined -version-info 37:5:11 -xarch=v8 -L/opt/csw/
> lib -R/opt/csw/lib/\\\$ISALIST -R/opt/csw/lib -o libgnutlsxx.la -
> rpath /opt/csw/lib libgnutlsxx_la-gnutlsxx.lo libgnutls.la -lnsl -
> lsocket -inst-prefix-dir /home/dam/mgar/pkg/gnutls/trunk/work/install-
> isa-sparcv8)
> libtool: relink: /opt/studio/SOS11/SUNWspro/bin/CC -G -zdefs -
> hlibgnutlsxx.so.26 -o .libs/libgnutlsxx.so.26.11.5   .libs/
> libgnutlsxx_la-gnutlsxx.o   -R/opt/csw/lib -R/opt/csw/lib/\$ISALIST
> -L/
> opt/csw/lib
> -L/home/dam/mgar/pkg/gnutls/trunk/work/install-isa-sparcv8/
> opt/csw/lib -lgnutls -ltasn1 -lz -lgcrypt -lgpg-error -lintl -lnsl -
> lsocket -library=Cstd -library=Crun -lc   -xarch=v8 -xarch=v8
> Undefined                       first referenced
>  symbol                             in file
> gnutls_priority_set                 .libs/libgnutlsxx_la-gnutlsxx.o
> gnutls_priority_set_direct          .libs/libgnutlsxx_la-gnutlsxx.o
> gnutls_openpgp_send_cert            .libs/libgnutlsxx_la-gnutlsxx.o
> ld: fatal: Symbol referencing errors. No output written to .libs/
> libgnutlsxx.so.26.11.5
> libtool: install: error: relink `libgnutlsxx.la' with the above
> command before installing it
> gmake[5]: *** [install-libLTLIBRARIES] Error 1
>
> Please be advised that I don't install .la-files for shared libraries
> (like libassuan etc.)

It looks like -lgnutls is linking to an old version of gnutls that is
installed somewhere else.  Also, the \$ISALIST stuff looks weird, should
it be a complete expanded path?

Perhaps libtool relinking requires the *.la files to be properly
installed.  Try to install them too...  alternatively, make sure the
relink command doesn't link to the old copy of gnutls.so.

/Simon




From simon at josefsson.org  Fri Feb  6 21:53:48 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 06 Feb 2009 21:53:48 +0100
Subject: GnuTLS 2.6.4 and 2.4.3
Message-ID: <878woj70df.fsf@mocca.josefsson.org>

We are proud to announce two new stable GnuTLS releases: Version 2.6.4
and 2.4.3.

Normally we only make stable releases on the latest stable branch, i.e.,
currently 2.6.x.  Many users appears to still be using the 2.4.x branch.
To make it easier for these users to upgrade to a secure version, we
have back-ported all of the X.509 chain verification fixes from the
2.6.x branch to the 2.4.x branch.  These two releases should solve the
[CVE-2008-4989] security problem and fix the problems with incorrectly
rejected chains that were reported for earlier 2.6.x releases.

GnuTLS is a modern C library that implement 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.gnutls.org/
  http://www.gnu.org/software/gnutls/

What's New
==========

Version 2.6.4 is a maintenance release on our stable branch.

** libgnutls: Accept chains where intermediary certs are trusted.
Before GnuTLS needed to validate the entire chain back to a
self-signed certificate.  GnuTLS will now stop looking when it has
found an intermediary trusted certificate.  The new behaviour is
useful when chains, for example, contains a top-level CA, an
intermediary CA signed using RSA-MD5, and an end-entity certificate.
To avoid chain validation errors due to the RSA-MD5 cert, you can
explicitly add the intermediary RSA-MD5 cert to your trusted certs.
The signature on trusted certificates are not checked, so the chain
has a chance to validate correctly.  Reported by "Douglas E. Engert"
<deengert at anl.gov> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3351>.

** libgnutls: result_size in gnutls_hex_encode now holds
the size of the result. Report by John Brooks <special at dereferenced.net>.

** libgnutls: gnutls_handshake when sending client hello during a
rehandshake, will not offer a version number larger than the current.
Reported by Tristan Hill <stan at saticed.me.uk>.

** libgnutls: Permit V1 Certificate Authorities properly.
Before they were mistakenly rejected even though
GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT and/or
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT were supplied.  Reported by
"Douglas E. Engert" <deengert at anl.gov> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3351>.

** libgnutls: deprecate X.509 validation chains using MD5 and MD2 signatures.
This is a bugfix -- the previous attempt to do this from internal x509
certificate verification procedures did not return the correct value
for certificates using a weak hash.  Reported by Daniel Kahn Gillmor
<dkg at fifthhorseman.net> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3332>,
debugged and patch by Tomas Mraz <tmraz at redhat.com> and Daniel Kahn
Gillmor <dkg at fifthhorseman.net>.

** libgnutls: Fix compile error with Sun CC.
Reported by Jeff Cai <jeff.cai at sun.com> in
<https://savannah.gnu.org/support/?106549>.

** 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
<ftp://ftp.gnu.org/gnu/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources (4.9MB):

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.4.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.4.tar.bz2

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.4.3.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.4.3.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.4.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.4.tar.bz2.sig

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.4.3.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.4.3.tar.bz2.sig

Note, that we don't distribute gzip compressed tarballs.

In order to check that the version of GnuTLS which you are going to
install is an original and unmodified one, you should verify the OpenPGP
signature.  You can use the command

     gpg --verify gnutls-2.6.4.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: 2009-04-21]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2009-04-21]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Alternatively, after successfully verifying the OpenPGP signature of
this announcement, you could verify that the files match the following
checksum values.  The values are for SHA-1 and SHA-224 respectively:

11dd1e11599906a32b3ff92308f4c4dbaadbad58  gnutls-2.6.4.tar.bz2

83289283739e168f346427784cc9a58c248c3363d1dc346674a54b15  gnutls-2.6.4.tar.bz2

0f4e6ed9ae5939bb9a63bb95722a25e2f6e32fae  gnutls-2.4.3.tar.bz2

b8daacc55a67048c241686d2567eb9797af486c6920bd5c59774c981  gnutls-2.4.3.tar.bz2

Documentation
=============

The manual is available online at:

  http://www.gnu.org/software/gnutls/documentation.html

In particular the following formats are available:

 HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html
 PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf

For developers there is a GnuTLS API reference manual formatted using
the GTK-DOC tools:

  http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html

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 uses
libgpg-error v1.7, libgcrypt v1.4.4, libtasn1 v1.8, and GnuTLS v2.6.4.

For more information about GnuTLS for Windows:
  http://josefsson.org/gnutls4win/

The Windows binary installer and PGP signature:
  http://josefsson.org/gnutls4win/gnutls-2.6.4.exe (14MB)
  http://josefsson.org/gnutls4win/gnutls-2.6.4.exe.sig

The checksum values for SHA-1 and SHA-224 are:

25975ee8ff0dea1acfb75d5c0bf12ffe7453136d  gnutls-2.6.4.exe

83da845fa1436dc6efc78f39c10bea9a6831191720ad10743ec30915  gnutls-2.6.4.exe

Thanks to Enrico Tassi, we also have mingw32 *.deb's available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.6.4-1_all.deb

The checksum values for SHA-1 and SHA-224 are:

310b4a0f8953927517d7ce600ff24b88c1deada5  mingw32-gnutls_2.6.4-1_all.deb

b251518c49d0ab04246b726a4171796d602b5cbbd8a7dd12f58c584b  mingw32-gnutls_2.6.4-1_all.deb

Internationalization
====================

GnuTLS messages have been translated into Dutch, French, German,
Malay, Polish, Swedish, and Vietnamese.  We welcome the addition of
more translations.

Support
=======

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.
You can contribute by reporting bugs, improve the software, or donate
money or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult AB, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

The GnuTLS service directory is available at:

  http://www.gnu.org/software/gnutls/commercial.html

Happy Hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20090206/276181d8/attachment.pgp>

From simon at josefsson.org  Fri Feb  6 22:23:28 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 06 Feb 2009 22:23:28 +0100
Subject: GnuTLS 2.6.4 and 2.4.3
In-Reply-To: <878woj70df.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Fri, 06 Feb 2009 21:53:48 +0100")
References: <878woj70df.fsf@mocca.josefsson.org>
Message-ID: <87r62b5kfj.fsf@mocca.josefsson.org>

Note that the release use a slightly different patch compared to the
release candidate.  The difference is at what point the CRL checking is
done.  I decided that without more thinking, we should better leave the
code as is, so I reverted the move of this code that I made before the
release candidate.

There is a slight semantic difference between the two approaches: will a
CRL containing a trusted intermediary cert lead to rejection or
acception when validating said trusted intermediary cert as part of a
chain?  I do not know what the proper answer should be.  Since it is
easier to modify the trust settings in deployment than to modify CRLs
(they are signed..), so the current approach is to let the trust store
setting have preference.

Please throw your X.509 chains at the 2.6.4 release and let me know
whether it behaves.  While the many changes in this area have been
unfortunate, at least we have built up a good self-test based on the
many chains submitted.  That will help catch regressions in this area in
the future...

/Simon




From simon at josefsson.org  Fri Feb  6 22:39:58 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 06 Feb 2009 22:39:58 +0100
Subject: Some compile issues of gnutls 2.6.3 on Solaris
In-Reply-To: <498CACF1.8000409@bredband.net> (Mats Rojestal's message of "Fri, 
	06 Feb 2009 22:34:41 +0100")
References: <C31B13FF-0A76-4A38-A475-D9C817954F43@opencsw.org>
	<878wp45p0t.fsf@mocca.josefsson.org>
	<0860A8D9-BFA3-40A0-9BD6-2F44E0F1D855@opencsw.org>
	<87vdrn72qq.fsf@mocca.josefsson.org> <498CACF1.8000409@bredband.net>
Message-ID: <87hc375jo1.fsf@mocca.josefsson.org>

Mats Rojestal <mats.rojestal at bredband.net> writes:

> Hi,
>
> gnutls 2.6.4 (and also 2.4.3) compiles cleanly on Solaris and also
> passes all tests.
> Compiler is gcc.

Great, thanks for testing.

/Simon

> bash-3.00$ gcc -v
> Using built-in specs.
> Target: i386-pc-solaris2.10
> Configured with: ../configure --prefix=/usr/gnu
> --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/local/bin/gld
> --enable-shared --with-gnu-ld --enable-languages=c,c++ --disable-nls
> Thread model: posix
> gcc version 4.3.0 (GCC)
>
> Regards Mats R?jest?l
>
> Simon Josefsson skrev:
>> Dagobert Michelsen <dam at opencsw.org> writes:
>>
>>> Hi Simon,
>>>
>>> Am 21.01.2009 um 22:26 schrieb Simon Josefsson:
>>>> This was new, thank you.  Should be fixed on trunk.  Please test
>>>> updated
>>>> daily build of the 2.6.x trunk (soon to be released):
>>>>
>>>> http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20090121.tar.gz
>>> Compilation and testing works fine now. However, on installation I get
>>>
>>> libtool: install: warning: relinking `libgnutlsxx.la'
>>> libtool: install: (cd /home/dam/mgar/pkg/gnutls/trunk/work/build-isa-
>>> sparcv8/gnutls-2.6.4/lib; /bin/bash /home/dam/mgar/pkg/gnutls/trunk/
>>> work/build-isa-sparcv8/gnutls-2.6.4/libtool  --tag CXX --mode=relink /
>>> opt/studio/SOS11/SUNWspro/bin/CC -I../includes/ -xO3 -xarch=v8 -I/opt/
>>> csw/include -no-undefined -version-info 37:5:11 -xarch=v8 -L/opt/csw/
>>> lib -R/opt/csw/lib/\\\$ISALIST -R/opt/csw/lib -o libgnutlsxx.la -
>>> rpath /opt/csw/lib libgnutlsxx_la-gnutlsxx.lo libgnutls.la -lnsl -
>>> lsocket -inst-prefix-dir /home/dam/mgar/pkg/gnutls/trunk/work/install-
>>> isa-sparcv8)
>>> libtool: relink: /opt/studio/SOS11/SUNWspro/bin/CC -G -zdefs -
>>> hlibgnutlsxx.so.26 -o .libs/libgnutlsxx.so.26.11.5   .libs/
>>> libgnutlsxx_la-gnutlsxx.o   -R/opt/csw/lib -R/opt/csw/lib/\$ISALIST
>>> -L/
>>> opt/csw/lib
>>> -L/home/dam/mgar/pkg/gnutls/trunk/work/install-isa-sparcv8/
>>> opt/csw/lib -lgnutls -ltasn1 -lz -lgcrypt -lgpg-error -lintl -lnsl -
>>> lsocket -library=Cstd -library=Crun -lc   -xarch=v8 -xarch=v8
>>> Undefined                       first referenced
>>>  symbol                             in file
>>> gnutls_priority_set                 .libs/libgnutlsxx_la-gnutlsxx.o
>>> gnutls_priority_set_direct          .libs/libgnutlsxx_la-gnutlsxx.o
>>> gnutls_openpgp_send_cert            .libs/libgnutlsxx_la-gnutlsxx.o
>>> ld: fatal: Symbol referencing errors. No output written to .libs/
>>> libgnutlsxx.so.26.11.5
>>> libtool: install: error: relink `libgnutlsxx.la' with the above
>>> command before installing it
>>> gmake[5]: *** [install-libLTLIBRARIES] Error 1
>>>
>>> Please be advised that I don't install .la-files for shared libraries
>>> (like libassuan etc.)
>>
>> It looks like -lgnutls is linking to an old version of gnutls that is
>> installed somewhere else.  Also, the \$ISALIST stuff looks weird, should
>> it be a complete expanded path?
>>
>> Perhaps libtool relinking requires the *.la files to be properly
>> installed.  Try to install them too...  alternatively, make sure the
>> relink command doesn't link to the old copy of gnutls.so.
>>
>> /Simon
>>
>>
>> _______________________________________________
>> Gnutls-devel mailing list
>> Gnutls-devel at gnu.org
>> http://lists.gnu.org/mailman/listinfo/gnutls-devel
>>




From simon at josefsson.org  Fri Feb  6 23:07:16 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 06 Feb 2009 23:07:16 +0100
Subject: GnuTLS 2.7.5
Message-ID: <87ab8z5iej.fsf@mocca.josefsson.org>

The GnuTLS 2.7.x branch is NOT what you want for your stable system.  It
is intended for developers and experienced users.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.7.5.tar.bz2 (5.8MB)
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.7.5.tar.bz2

Here is the OpenPGP signature:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.7.5.tar.bz2.sig
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.7.5.tar.bz2.sig

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult AB, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

/Simon

* Version 2.7.5 (released 2009-02-06)

** libgnutls: Accept chains where intermediary certs are trusted.
Before GnuTLS needed to validate the entire chain back to a
self-signed certificate.  GnuTLS will now stop looking when it has
found an intermediary trusted certificate.  The new behaviour is
useful when chains, for example, contains a top-level CA, an
intermediary CA signed using RSA-MD5, and an end-entity certificate.
To avoid chain validation errors due to the RSA-MD5 cert, you can
explicitly add the intermediary RSA-MD5 cert to your trusted certs.
The signature on trusted certificates are not checked, so the chain
has a chance to validate correctly.  Reported by "Douglas E. Engert"
<deengert at anl.gov> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3351>.

** libgnutls: result_size in gnutls_hex_encode now holds
the size of the result. Report by John Brooks <special at dereferenced.net>.

** libgnutls: gnutls_handshake when sending client hello during a
rehandshake, will not offer a version number larger than the current.
Reported by Tristan Hill <stan at saticed.me.uk>.

** libgnutls: Permit V1 Certificate Authorities properly.
Before they were mistakenly rejected even though
GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT and/or
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT were supplied.  Reported by
"Douglas E. Engert" <deengert at anl.gov> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3351>.

** API and ABI modifications:
No changes since last version.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20090206/fee89cb1/attachment.pgp>

From simon at josefsson.org  Fri Feb 13 13:11:23 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 13 Feb 2009 13:11:23 +0100
Subject: FOSDEM GnuTLS lightning talk
Message-ID: <873aeiiljo.fsf@mocca.josefsson.org>

I forgot to announce this before the event, but I made a brief talk
about GnuTLS at FOSDEM.  The presentation is here:

http://josefsson.org/talks/fosdem2009-gnutls.pdf

I won't dig up a URL to the video recoding to reduce my embarrassment of
poor english and poor presentation skillz.. ;)

If someone has suggestion on the presentation, we could improve it.
Perhaps it can serve as a quick introduction to GnuTLS and be placed on
the GnuTLS web page.

/Simon




From nmav at gnutls.org  Mon Feb 16 02:18:35 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 16 Feb 2009 03:18:35 +0200
Subject: [Help-gnutls] Default record version
In-Reply-To: <49986DCC.3030102@gmx.net>
References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org>
	<49986DCC.3030102@gmx.net>
Message-ID: <4998BEEB.1060004@gnutls.org>

Martin von Gagern wrote:

>>> It seems that _gnutls_record_set_default_version would provide a way to
>>> get the intended behaviour of an older record version but a recent
>>> client hello version. That function doesn't seem to be intended as part
>>> of the public interface of GnuTLS, though [3]. Why is that?
>> It was meant as a hack to test for buggy servers that I mentioned above.
>> I don't think it should be normally used. A better solution would be to
>> have a priority string %RFC4346 that would enforce that behavior. What
>> do you think on that?
> 
> The reference to RFC 4346 in your sentence confuses me, especially as I
> see no reference to a "priority string" in that RFC. The only possible
> interpretation of your suggestion would be to use a call to
> gnutls_protocol_set_priority in order to disable TLS 1.1, thus enforcing
> a TLS 1.0 record header and client hello.

Hello,
 What I meant is to have this %RFC4346 option in the priority string in
order to specify that the way the client hello and first record version
will be according to appendix E as you quoted before (lowest supported
record version -SSL 3.0 and highest supported client hello version
-TLS1.1). The priority string is gnutls specific and means the string
you specify in the set_priority functions.


regards,
Nikos




From simon at josefsson.org  Mon Feb 16 09:42:48 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Feb 2009 09:42:48 +0100
Subject: Default record version
In-Reply-To: <4998BEEB.1060004@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Mon, 16 Feb 2009 03:18:35 +0200")
References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org>
	<49986DCC.3030102@gmx.net> <4998BEEB.1060004@gnutls.org>
Message-ID: <87ab8m93hz.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Martin von Gagern wrote:
>
>>>> It seems that _gnutls_record_set_default_version would provide a way to
>>>> get the intended behaviour of an older record version but a recent
>>>> client hello version. That function doesn't seem to be intended as part
>>>> of the public interface of GnuTLS, though [3]. Why is that?
>>> It was meant as a hack to test for buggy servers that I mentioned above.
>>> I don't think it should be normally used. A better solution would be to
>>> have a priority string %RFC4346 that would enforce that behavior. What
>>> do you think on that?
>> 
>> The reference to RFC 4346 in your sentence confuses me, especially as I
>> see no reference to a "priority string" in that RFC. The only possible
>> interpretation of your suggestion would be to use a call to
>> gnutls_protocol_set_priority in order to disable TLS 1.1, thus enforcing
>> a TLS 1.0 record header and client hello.
>
> Hello,
>  What I meant is to have this %RFC4346 option in the priority string in
> order to specify that the way the client hello and first record version
> will be according to appendix E as you quoted before (lowest supported
> record version -SSL 3.0 and highest supported client hello version
> -TLS1.1). The priority string is gnutls specific and means the string
> you specify in the set_priority functions.

I think a priority string to configure this seems like a good idea,
however, please use a more descriptive name than %RFC4346 (which has
already been obsoleted by RFC 5246).  How about
%USE-TLS1.0-RECORD-VERSION?  And %USE-SSL3-RECORD-VERSION if we need to
be able to set both SSL 3.0 and TLS 1.0 record versions.

/Simon




From nmav at gnutls.org  Sat Feb 21 12:25:21 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 21 Feb 2009 13:25:21 +0200
Subject: [Help-gnutls] Default record version
In-Reply-To: <49986DCC.3030102@gmx.net>
References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org>
	<49986DCC.3030102@gmx.net>
Message-ID: <499FE4A1.3000805@gnutls.org>

Martin von Gagern wrote:
> Hi Nikos, thanks for your reply!
> 
> Nikos Mavrogiannopoulos wrote:
>>> My first question is this: is there a good reason that GnuTLS doesn't
>>> indicate an older record version in accordance with appendix E by default?
>> This is tricky. There are other servers that do not operate well if the
>> client hello version does not match record version. This is the reason
>> why gnutls has this behavior. Of course this was noticed many years ago.
>> I don't know how many servers now have this problem.
> 
> I see, and in that light it might make sense to not have the Appendix E
> behaviour by default. In my opinion, it would be desirable if you could
> at least configure GnuTLS to use that approach, though.

The commit below[0] adds a priority string called SSL3_RECORD_VERSION
that forces a compatibility mode where an SSL 3.0 record version is set
on the client hello. I have backported it to 2.6 branch as well.

[0].
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=27a05b85c390f3192fcf0c55c1b5c0196e33c727


regards,
Nikos




From Martin.vGagern at gmx.net  Sat Feb 21 13:31:13 2009
From: Martin.vGagern at gmx.net (Martin von Gagern)
Date: Sat, 21 Feb 2009 13:31:13 +0100
Subject: [Help-gnutls] Default record version
In-Reply-To: <499FE4A1.3000805@gnutls.org>
References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org>
	<49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org>
Message-ID: <499FF411.40009@gmx.net>

Nikos Mavrogiannopoulos wrote:
> The commit below adds a priority string called SSL3_RECORD_VERSION
> that forces a compatibility mode where an SSL 3.0 record version is set
> on the client hello. I have backported it to 2.6 branch as well.

Thanks a lot! I'll test that, and get back to you if anything doesn't
work as expected. Otherwise that seems like a suitable solution.

Greetings,
 Martin von Gagern

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090221/1b6220ba/attachment.pgp>

From Martin.vGagern at gmx.net  Sat Feb 21 14:57:42 2009
From: Martin.vGagern at gmx.net (Martin von Gagern)
Date: Sat, 21 Feb 2009 14:57:42 +0100
Subject: [Help-gnutls] Default record version
In-Reply-To: <499FF411.40009@gmx.net>
References: <4997EB28.8090100@gmx.net>
	<49985133.4010508@gnutls.org>	<49986DCC.3030102@gmx.net>
	<499FE4A1.3000805@gnutls.org> <499FF411.40009@gmx.net>
Message-ID: <49A00856.1040707@gmx.net>

Martin von Gagern wrote:
> Nikos Mavrogiannopoulos wrote:
>> The commit below adds a priority string called SSL3_RECORD_VERSION
>> that forces a compatibility mode where an SSL 3.0 record version is set
>> on the client hello. I have backported it to 2.6 branch as well.
> 
> Thanks a lot! I'll test that, and get back to you if anything doesn't
> work as expected. Otherwise that seems like a suitable solution.

The implementation itself seems to work well enough, thanks for that!

You might want to check the generated documentation, though. Looking at
the man page of gnutls_priority_init(3), it looks like gdoc was eating
the percent signs, while nroff eats lines starting with an apostrophe.

It would also be nice to have a test in gnutls-cli-debug, to see whether
a connection can be established with SSL3 record version but TLS1.1
client hello version, and if so, what version was actually negotiated.

Greetings,
 Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090221/aac93238/attachment.pgp>

From nmav at gnutls.org  Sat Feb 21 16:23:21 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 21 Feb 2009 17:23:21 +0200
Subject: [Help-gnutls] Default record version
In-Reply-To: <49A00856.1040707@gmx.net>
References: <4997EB28.8090100@gmx.net>
	<49985133.4010508@gnutls.org>	<49986DCC.3030102@gmx.net>
	<499FE4A1.3000805@gnutls.org> <499FF411.40009@gmx.net>
	<49A00856.1040707@gmx.net>
Message-ID: <49A01C69.2000708@gnutls.org>

Martin von Gagern wrote:

> You might want to check the generated documentation, though. Looking at
> the man page of gnutls_priority_init(3), it looks like gdoc was eating
> the percent signs, while nroff eats lines starting with an apostrophe.

Corrected. Thank you.


regards,
Nikos




From Martin.vGagern at gmx.net  Sat Feb 21 17:17:54 2009
From: Martin.vGagern at gmx.net (Martin von Gagern)
Date: Sat, 21 Feb 2009 17:17:54 +0100
Subject: [Help-gnutls] Default record version
In-Reply-To: <49A01C69.2000708@gnutls.org>
References: <4997EB28.8090100@gmx.net>
	<49985133.4010508@gnutls.org>	<49986DCC.3030102@gmx.net>
	<499FE4A1.3000805@gnutls.org> <499FF411.40009@gmx.net>
	<49A00856.1040707@gmx.net> <49A01C69.2000708@gnutls.org>
Message-ID: <49A02932.6060306@gmx.net>

Nikos Mavrogiannopoulos wrote:
> Corrected. Thank you.

No, that's not the one I'm talking about. I wrote about
gnutls_priority_init(3) while you fixed gnutls-cli(1). The attached
patch fixes gnutls_priority_init(3), but in a very hackish way, treating
a percent sign as indicating a constant only if it is not immediately
preceded by a double quote.

I guess it would be nice to have some kind of generic escaping mechanism
in order to include verbatim % and @ characters. Up to you to decide how
you would like to encode this. The current hack works for current
gnutls, as the gnutls_priority_init contains the only occurrences of
``"%'' inside a documentation comment, and none of them is a constant.

Greetings,
 Martin
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: percent-hack.patch
URL: </pipermail/attachments/20090221/167a3e55/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090221/167a3e55/attachment.pgp>

From nmav at gnutls.org  Sun Feb 22 10:10:04 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 22 Feb 2009 11:10:04 +0200
Subject: [Help-gnutls] Default record version
In-Reply-To: <49A02932.6060306@gmx.net>
References: <4997EB28.8090100@gmx.net>
	<49985133.4010508@gnutls.org>	<49986DCC.3030102@gmx.net>
	<499FE4A1.3000805@gnutls.org> <499FF411.40009@gmx.net>
	<49A00856.1040707@gmx.net> <49A01C69.2000708@gnutls.org>
	<49A02932.6060306@gmx.net>
Message-ID: <49A1166C.6000703@gnutls.org>

Martin von Gagern wrote:
> Nikos Mavrogiannopoulos wrote:
>> Corrected. Thank you.
> 
> No, that's not the one I'm talking about. I wrote about
> gnutls_priority_init(3) while you fixed gnutls-cli(1). The attached
> patch fixes gnutls_priority_init(3), but in a very hackish way, treating
> a percent sign as indicating a constant only if it is not immediately
> preceded by a double quote.

Applied as is. Thank you!

regards,
Nikos






From Martin.vGagern at gmx.net  Sun Feb 22 10:19:50 2009
From: Martin.vGagern at gmx.net (Martin von Gagern)
Date: Sun, 22 Feb 2009 10:19:50 +0100
Subject: [Help-gnutls] Default record version
In-Reply-To: <499FE4A1.3000805@gnutls.org>
References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org>
	<49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org>
Message-ID: <49A118B6.8020102@gmx.net>

Nikos Mavrogiannopoulos wrote:
> The commit below adds a priority string called SSL3_RECORD_VERSION
> that forces a compatibility mode where an SSL 3.0 record version is set
> on the client hello. I have backported it to 2.6 branch as well.

Pidgin is now using %SSL3_RECORD_VERSION, so I'm looking forward to the
next releases to actually contain this feature. When will they happen?

Thanks and greetings,
 Martin

http://developer.pidgin.im/viewmtn/revision/info/c84a41f40179331c218ac05005ce7805129049e5

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090222/831ac5d7/attachment.pgp>

From simon at josefsson.org  Sun Feb 22 12:39:55 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 22 Feb 2009 12:39:55 +0100
Subject: Default record version
In-Reply-To: <49A118B6.8020102@gmx.net> (Martin von Gagern's message of "Sun, 
	22 Feb 2009 10:19:50 +0100")
References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org>
	<49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org>
	<49A118B6.8020102@gmx.net>
Message-ID: <87ljrybsz8.fsf@mocca.josefsson.org>

Martin von Gagern <Martin.vGagern at gmx.net> writes:

> Nikos Mavrogiannopoulos wrote:
>> The commit below adds a priority string called SSL3_RECORD_VERSION
>> that forces a compatibility mode where an SSL 3.0 record version is set
>> on the client hello. I have backported it to 2.6 branch as well.
>
> Pidgin is now using %SSL3_RECORD_VERSION, so I'm looking forward to the
> next releases to actually contain this feature. When will they happen?

The gnutls 2.7.x branch is in a pretty good state.  The only thing I'm
aware of is that we should finish the TLS 1.2 implementation.
Alternatively, we could also disable the TLS 1.2 support until we have
finished the implementation.

(The current TLS 1.2 support is for an old TLS 1.2 draft which doesn't
interoperate with the final TLS 1.2...)

I don't think I will have time to look into this in the next few weeks
though.

Also, this isn't a regression over GnuTLS 2.6.x which has the same
partial TLS 1.2 implementation.  So we could also just document this
fact, and release now.

/Simon




From nmav at gnutls.org  Sun Feb 22 17:14:28 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 22 Feb 2009 18:14:28 +0200
Subject: Default record version
In-Reply-To: <87ljrybsz8.fsf@mocca.josefsson.org>
References: <4997EB28.8090100@gmx.net>
	<49985133.4010508@gnutls.org>	<49986DCC.3030102@gmx.net>
	<499FE4A1.3000805@gnutls.org>	<49A118B6.8020102@gmx.net>
	<87ljrybsz8.fsf@mocca.josefsson.org>
Message-ID: <49A179E4.7050004@gnutls.org>

Simon Josefsson wrote:

> I don't think I will have time to look into this in the next few weeks
> though.
> 
> Also, this isn't a regression over GnuTLS 2.6.x which has the same
> partial TLS 1.2 implementation.  So we could also just document this
> fact, and release now.

I have backported the fix to 2.6 release as well so it doesn't have to
be 2.7 only for that.

regards,
Nikos




From simon at josefsson.org  Mon Feb 23 17:50:42 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 23 Feb 2009 17:50:42 +0100
Subject: Default record version
In-Reply-To: <49A1166C.6000703@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sun, 22 Feb 2009 11:10:04 +0200")
References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org>
	<49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org>
	<499FF411.40009@gmx.net> <49A00856.1040707@gmx.net>
	<49A01C69.2000708@gnutls.org> <49A02932.6060306@gmx.net>
	<49A1166C.6000703@gnutls.org>
Message-ID: <87wsbh2j31.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Martin von Gagern wrote:
>> Nikos Mavrogiannopoulos wrote:
>>> Corrected. Thank you.
>> 
>> No, that's not the one I'm talking about. I wrote about
>> gnutls_priority_init(3) while you fixed gnutls-cli(1). The attached
>> patch fixes gnutls_priority_init(3), but in a very hackish way, treating
>> a percent sign as indicating a constant only if it is not immediately
>> preceded by a double quote.
>
> Applied as is. Thank you!

This seems to break texinfo building:

http://autobuild.josefsson.org/gnutls/log-200902222047566880000.txt

/Simon




From Martin.vGagern at gmx.net  Mon Feb 23 23:33:26 2009
From: Martin.vGagern at gmx.net (Martin von Gagern)
Date: Mon, 23 Feb 2009 23:33:26 +0100
Subject: Default record version
In-Reply-To: <87wsbh2j31.fsf@mocca.josefsson.org>
References: <4997EB28.8090100@gmx.net>
	<49985133.4010508@gnutls.org>	<49986DCC.3030102@gmx.net>
	<499FE4A1.3000805@gnutls.org>	<499FF411.40009@gmx.net>
	<49A00856.1040707@gmx.net>	<49A01C69.2000708@gnutls.org>
	<49A02932.6060306@gmx.net>	<49A1166C.6000703@gnutls.org>
	<87wsbh2j31.fsf@mocca.josefsson.org>
Message-ID: <49A32436.60503@gmx.net>

Simon Josefsson schrieb:
> This seems to break texinfo building:
> 
> http://autobuild.josefsson.org/gnutls/log-200902222047566880000.txt
> 
> /Simon

Probably because percent signs introduce a comment in texinfo, as they
do in tex. The attached patch might fix that. Haven't tested it myself,
as I only have remote access over a slow link to my build environment
right now.

I have to admit that things become even more hackish with this patch in
place, as there are now even more places where the sequence "% receives
special treatment. The main reason for this is that the replacements are
stored in hashes, not lists, so I can't rely on the order of
substitutions, therefore I can't first replace the constants and then
replace all remaining percent signs.

Maybe the replacement of % were better done somewhere in the
corresponding output function, along with sepcial treatment for any
other kind of special characters for the corresponding output language.
Maybe those highlighting substitutions were better saved as arrays.
Maybe those arrays should employ qr/.../ and '...' to avoid half of the
backslashes and make things more readable.

As you can see, there is a lot which could be improved about that
script. And most improvements are not obvious, but require some kind of
design decision, like what characters are special, how to escape them,
where to handle what special cases, what other documentation syntax to
emulate, stuff like that.

If I don't forget it, maybe I can write a major patch for some of this
some time next week. Before I start that, I would like to hear that you
are interested in such a general improvement. You should also voice any
thoughts you have as to what direction such improvements should take.

Of course, I'd be more than happy if you fix this yourself. I'm not that
eager to read and understand someone else's Perl code, even if that
script seems to be a fairly tame specimen.

Greetings,
 Martin
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: percent-hack2.patch
URL: </pipermail/attachments/20090223/6533a072/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090223/6533a072/attachment.pgp>

From jean.robertson at mcgill.ca  Wed Feb 25 20:34:25 2009
From: jean.robertson at mcgill.ca (Jean Robertson)
Date: Wed, 25 Feb 2009 14:34:25 -0500
Subject: make check fails on AIX 5.3
Message-ID: <200902251434.25182.jean.robertson@mcgill.ca>

Hello,

I am trying to compile and test gnutls and am getting the following:

make[3]: Entering directory 
`/opt/src/rpms/build/gnutls-2.6.4/tests/rsa-md5-collision'
./rsa-md5-collision[28]: 397372 Memory fault(coredump)
FAIL: rsa-md5-collision
===================================
1 of 1 tests failed
Please report to bug-gnutls at gnu.org
===================================
make[3]: *** [check-TESTS] Error 1


Following is the environment:

O/S:	AIX 5.3
GCC:	4.2.0
gcrypt:	1.4.4
autoconf: 2.63

Please let me know how I can help.
Specifically, I do not know how much more info you would like.

Jean

-- 
Jean Robertson, McGill University (514) 398-8117





From simon at josefsson.org  Thu Feb 26 11:46:35 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 26 Feb 2009 11:46:35 +0100
Subject: make check fails on AIX 5.3
In-Reply-To: <200902251434.25182.jean.robertson@mcgill.ca> (Jean Robertson's
	message of "Wed, 25 Feb 2009 14:34:25 -0500")
References: <200902251434.25182.jean.robertson@mcgill.ca>
Message-ID: <87r61lwk50.fsf@mocca.josefsson.org>

Jean Robertson <jean.robertson at mcgill.ca> writes:

> Hello,
>
> I am trying to compile and test gnutls and am getting the following:
>
> make[3]: Entering directory 
> `/opt/src/rpms/build/gnutls-2.6.4/tests/rsa-md5-collision'
> ./rsa-md5-collision[28]: 397372 Memory fault(coredump)
> FAIL: rsa-md5-collision
> ===================================
> 1 of 1 tests failed
> Please report to bug-gnutls at gnu.org
> ===================================
> make[3]: *** [check-TESTS] Error 1
>
>
> Following is the environment:
>
> O/S:	AIX 5.3
> GCC:	4.2.0
> gcrypt:	1.4.4
> autoconf: 2.63
>
> Please let me know how I can help.
> Specifically, I do not know how much more info you would like.

Strange, rsa-md5-collision is a shell script.  Presumably it isn't the
script itself that crashes, but something it does.

Can you show the output of this command:

jas at mocca:~/src/gnutls/src master$ ./certtool --inder -i --infile ../tests/rsa-md5-collision/MD5CollisionCA.cer 

/Simon




From simon at josefsson.org  Thu Feb 26 12:13:38 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 26 Feb 2009 12:13:38 +0100
Subject: GnuTLS 2.6.5 release candidate
In-Reply-To: <49A179E4.7050004@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sun, 22 Feb 2009 18:14:28 +0200")
References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org>
	<49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org>
	<49A118B6.8020102@gmx.net> <87ljrybsz8.fsf@mocca.josefsson.org>
	<49A179E4.7050004@gnutls.org>
Message-ID: <87iqmxwivx.fsf_-_@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> I have backported the fix to 2.6 release as well so it doesn't have to
> be 2.7 only for that.

I have prepared a 2.6.5 release candidate, please test it:

http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20090226.tar.gz

Right now it only contains this change:

  ** libgnutls: Added %SSL3_RECORD_VERSION priority string that allows to
  specify the client hello message record version. Used to overcome buggy
  TLS servers. Report by Martin von Gagern.

Which really is a new feature rather than a fix, so I'd like to defer
making the release until we have some more critical problems to fix, or
when 6 weeks have passed, whichever comes first.

Please test it as if it were a proper release, and let us know about any
problems.

/Simon




From simon at josefsson.org  Fri Feb 27 09:32:58 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 27 Feb 2009 09:32:58 +0100
Subject: Default record version
In-Reply-To: <49A32436.60503@gmx.net> (Martin von Gagern's message of "Mon, 23
	Feb 2009 23:33:26 +0100")
References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org>
	<49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org>
	<499FF411.40009@gmx.net> <49A00856.1040707@gmx.net>
	<49A01C69.2000708@gnutls.org> <49A02932.6060306@gmx.net>
	<49A1166C.6000703@gnutls.org> <87wsbh2j31.fsf@mocca.josefsson.org>
	<49A32436.60503@gmx.net>
Message-ID: <87k57c8ekl.fsf@mocca.josefsson.org>

Martin von Gagern <Martin.vGagern at gmx.net> writes:

> Simon Josefsson schrieb:
>> This seems to break texinfo building:
>> 
>> http://autobuild.josefsson.org/gnutls/log-200902222047566880000.txt
>> 
>> /Simon
>
> Probably because percent signs introduce a comment in texinfo, as they
> do in tex. The attached patch might fix that. Haven't tested it myself,
> as I only have remote access over a slow link to my build environment
> right now.

Hi Martin.  Thanks.  I have reverted the earlier patch to be able to
make a release, but we should definitely try to fix this.  I'll try your
patch later too -- it helps to compare the output with an old release to
catch regressions here, so making a release first seemed better from
this point of view as well.

> I have to admit that things become even more hackish with this patch in
> place, as there are now even more places where the sequence "% receives
> special treatment. The main reason for this is that the replacements are
> stored in hashes, not lists, so I can't rely on the order of
> substitutions, therefore I can't first replace the constants and then
> replace all remaining percent signs.
>
> Maybe the replacement of % were better done somewhere in the
> corresponding output function, along with sepcial treatment for any
> other kind of special characters for the corresponding output language.
> Maybe those highlighting substitutions were better saved as arrays.
> Maybe those arrays should employ qr/.../ and '...' to avoid half of the
> backslashes and make things more readable.
>
> As you can see, there is a lot which could be improved about that
> script. And most improvements are not obvious, but require some kind of
> design decision, like what characters are special, how to escape them,
> where to handle what special cases, what other documentation syntax to
> emulate, stuff like that.
>
> If I don't forget it, maybe I can write a major patch for some of this
> some time next week. Before I start that, I would like to hear that you
> are interested in such a general improvement. You should also voice any
> thoughts you have as to what direction such improvements should take.

I am a bit reluctant to do major work on the current gdoc -- if major
work is going to be done (which would be great!), what I would prefer
would be a clean re-implementation of it, that would be copyrighted by
the FSF, and thus could be added to gnulib.  This would make it easier
to re-use it between projects; I'm already using variously patched
versions of gdoc in several of my projects.  This could be written with
some design documentation, that discuss how to deal with problems like
you have discovered.

Meanwhile, we should be open to consider hacks that work around the
larger problem.  If all else fails, we could post-process this
particular man page to make it render properly.

/Simon




From simon at josefsson.org  Fri Feb 27 16:57:51 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 27 Feb 2009 16:57:51 +0100
Subject: GnuTLS 2.7.6
Message-ID: <87hc2fzxc0.fsf@mocca.josefsson.org>

The GnuTLS 2.7.x branch is NOT what you want for your stable system.  It
is intended for developers and experienced users.

Here are the compressed sources:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.7.6.tar.bz2 (5.8MB)
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.7.6.tar.bz2

Here is the OpenPGP signature:
  http://alpha.gnu.org/gnu/gnutls/gnutls-2.7.6.tar.bz2.sig
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.7.6.tar.bz2.sig

Known open issues holding back the next stable release:

 * Make gnutls-cli/gnutls-serv work under Windows again
 * Resolve how to treat the partial TLS 1.2 implementation
 * Fix the API man page for priority strings

The plan is to resolve these issues and post release candidates during
March and release on April 1th.  If you want to see anything else in the
next stable release, now is the time to speak!

Improving GnuTLS is costly, but you can help!  We are looking for
organizations that find GnuTLS useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or donate money
or equipment.

Commercial support contracts for GnuTLS are available, and they help
finance continued maintenance.  Simon Josefsson Datakonsult AB, a
Stockholm based privately held company, is currently funding GnuTLS
maintenance.  We are always looking for interesting development
projects.  See http://josefsson.org/ for more details.

/Simon

* Version 2.7.6 (released 2009-02-27)

** certtool: Query for multiple dnsName subjectAltName in interactive mode.
This applies both to generating certificates and certificate requests.

** pkix.asn: Removed unneeded definitions to reduce memory usage.

** gnutls-cli: No longer accepts V1 CAs by default during X.509 chain verify.
Use --priority NORMAL:%VERIFY_ALLOW_X509_V1_CA_CRT to permit V1 CAs to
be used for chain verification.

** gnutls-serv: No longer disable MAC padding by default.
Use --priority NORMAL:%COMPAT to disable MAC padding again.

** gnutls-cli: Certificate information output format changed.
The tool now uses libgnutls' functions to print certificate
information.  This avoids code duplication.

** libgnutls: New priority strings %VERIFY_ALLOW_SIGN_RSA_MD5
** and %VERIFY_ALLOW_X509_V1_CA_CRT.
They can be used to override the default certificate chain validation
behaviour.

** libgnutls: Added %SSL3_RECORD_VERSION priority string that allows to 
specify the client hello message record version. Used to overcome buggy 
TLS servers. Report by Martin von Gagern.

** libgnutls: gnutls_x509_crt_print prints signature algorithm in oneline mode.

** libgnutls: gnutls_openpgp_crt_print supports oneline mode.

** doc: Update gnutls-cli and gnutls-serv --help output descriptions.

** API and ABI modifications:
No changes since last version.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20090227/2c02cf3e/attachment.pgp>

From Martin.vGagern at gmx.net  Fri Feb 27 23:17:33 2009
From: Martin.vGagern at gmx.net (Martin von Gagern)
Date: Fri, 27 Feb 2009 23:17:33 +0100
Subject: gdoc replacement (was: Re: Default record version)
In-Reply-To: <87k57c8ekl.fsf@mocca.josefsson.org>
References: <4997EB28.8090100@gmx.net>
	<49985133.4010508@gnutls.org>	<49986DCC.3030102@gmx.net>
	<499FE4A1.3000805@gnutls.org>	<499FF411.40009@gmx.net>
	<49A00856.1040707@gmx.net>	<49A01C69.2000708@gnutls.org>
	<49A02932.6060306@gmx.net>	<49A1166C.6000703@gnutls.org>
	<87wsbh2j31.fsf@mocca.josefsson.org>	<49A32436.60503@gmx.net>
	<87k57c8ekl.fsf@mocca.josefsson.org>
Message-ID: <49A8667D.6000608@gmx.net>

Simon Josefsson schrieb:
> I am a bit reluctant to do major work on the current gdoc -- if major
> work is going to be done (which would be great!), what I would prefer
> would be a clean re-implementation of it, that would be copyrighted by
> the FSF, and thus could be added to gnulib.

Sounds reasonable, even though I havent dealt with gnulib before. In my
opinion, a formal description of the grammar used in comments should be
the first step along that road, and the basis for discussion. Shouldn't
be too complicated, but it might help get some things straight.

Once you have that in place, using common lexer and/or parser generators
should be enough to do most of the work on the input side. Of course,
this approach is more easily turned into a C program than a Perl script,
but I assume this might even be a plus in terms of portability, as long
as you get it compiled as part of your build process or depend on it
being installed in its binary form on the build system.

> This would make it easier
> to re-use it between projects; I'm already using variously patched
> versions of gdoc in several of my projects.  This could be written with
> some design documentation, that discuss how to deal with problems like
> you have discovered.

It is my opinion that such problems should not even happen in the first
place. This means that
a) special syntax should be clearly and unabiguously recognizable as
such. E.g. in TeX, a command is introduced by \ (disregarding any other
special chars TeX uses besides \), in Javadoc by @, and so on. This way,
users know when what they type will be treated as a command, and are not
likely to involuntarily use obscure markup they never thought about.
b) All non-special syntax should be escaped wherever the output medium
requires it, avoiding issues like those special meanings for ' and %.

Of course, all of this would probably imply a change of syntax, e.g.
from %CONSTANT to {@const CONSTANT} or stuff like that. Would that be
acceptable? If you decide that a change of syntax is acceptable, it
might make sense to emulate the syntax of some other projects. The one
that comes to my mind is Doxygen, mostly because it's the only one I've
worked with before, besides Javadoc. Such a step might mean translating
fragments from some (maybe well defined) subset of HTML to other
languages. The smaller the subset, the easier this process. This would
also allow for HTML entities as a powerful means to escape special
characters.

> Meanwhile, we should be open to consider hacks that work around the
> larger problem.

Doable, given the right amount of hacking.

> If all else fails, we could post-process this
> particular man page to make it render properly.

I assume it should be possible to avoid that, at least as long as you
don't mind accumulating deviations and hackish code in gdoc.

> /Simon

Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090227/d67019ff/attachment.pgp>