From simon at josefsson.org  Tue Jun  1 09:08:45 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 01 Jun 2010 09:08:45 +0200
Subject: safe renegotiation bug?
In-Reply-To: <4C041CE2.3060006@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Mon, 31 May 2010 22:32:34 +0200")
References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org>
	<874ohzeko1.fsf@mocca.josefsson.org> <4BF85B33.5040203@gnutls.org>
	<87typs7bcp.fsf@mocca.josefsson.org> <4BFF7154.3060700@gnutls.org>
	<87typs5uwg.fsf@mocca.josefsson.org> <4C005B4C.7030606@gnutls.org>
	<874ohoj6sf.fsf@mocca.josefsson.org> <4C040283.8040603@gnutls.org>
	<87sk57g981.fsf@mocca.josefsson.org> <4C041CE2.3060006@gnutls.org>
Message-ID: <87y6ezcjr6.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Simon Josefsson wrote:
>
>> Then there is no way to make clients allow initial handshakes but
>> disallow renegotiations.  That goes against a RECOMMENDED in RFC 5746:
>> 
>> 4.2.  Client Behavior: Legacy (Insecure) Renegotiation
>> 
>>    This text applies if the connection's "secure_renegotiation" flag is
>>    set to FALSE.
>> 
>>    It is possible that un-upgraded servers will request that the client
>>    renegotiate.  It is RECOMMENDED that clients refuse this
>>    renegotiation request.  Clients that do so MUST respond to such
>>    requests with a "no_renegotiation" alert (RFC 5246 requires this
>>    alert to be at the "warning" level).  It is possible that the
>>    apparently un-upgraded server is in fact an attacker who is then
>>    allowing the client to renegotiate with a different, legitimate,
>>    upgraded server.  If clients nevertheless choose to renegotiate, they
>>    MUST behave as described below.
>> 
>> I would prefer a good reason to do something like that.
>> 
>> I don't understand your "because it allows clients to have a maximum
>> compatibility when %UNSAFE_RENEGOTIATION is specified".  Changing the
>> _default_ behaviour to follow the RFCs recommendation would not change
>> what happens when %UNSAFE_RENEGOTIATION is specified.  And indeed, with
>> %UNSAFE_RENEGOTIATION clients do have maximum compatibility already.
>> Could you clarify what you meant here?
>
> I mean that the default now for the client is %UNSAFE_RENEGOTIATION. As
> far as I understand what you propose is to add an extra level for the
> client that allows initial negotiation but not subsequent ones. Am I right?

Almost -- I want the default to disallow unsafe re-handshakes both in
client and server.  That would not be equal to %UNSAFE_RENEGOTIATION
(which is more relaxed) or %SAFE_RENEGOTIATION (which is more
conservative).  If we need a priority string for this middle road, we
can call it %PARTIAL_RENEGOTIATION.

> To be honest I'd prefer to modify unsafe renegotiation to do what you
> propose rather than adding an extra level. The code getting more and
> more complicated as well as the behavior. It might be better to have few
> easily explained states, rather than a bunch. With this change clients
> using gnutls would need to specify %DISABLE_SAFE_RENEGOTIATION to have
> the compatibility behavior (which is not so good but one has to draw a
> line somewhere between keeping things simple and supporting everything).
>
> So which solution do you prefer?

I'm not sure that is a good idea -- then there is no way to configure
mod_gnutls to talk to anyone.  People would need to use an older GnuTLS,
or install mod_ssl or mod_nss instead to get that behaviour.

However, we already have %INITIAL_SAFE_RENEGOTIATION so we already have
four different priority strings.  I think we could be feature complete
with four different priority strings if we redesign things slightly:

%DISABLE_SAFE_RENEGOTIATION: Disable the extension, permits unsafe
 (re-)handshakes.

%SAFE_RENEGOTIATION: Enable extension and require it for all handshakes.

%PARTIAL_RENEGOTIATION: Enable extension and require it on all
 re-handshakes but permit initial handshakes without it.

%UNSAFE_RENEGOTIATION: Enable extension and permit all (re-)handshakes
 without extension.

The default for both clients and servers would be
%PARTIAL_RENEGOTIATION.  We'll change the defaults to
%SAFE_RENEGOTIATION in two years or so.

What do you think about this approach?

/Simon



From nmav at gnutls.org  Tue Jun  1 09:48:48 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 01 Jun 2010 09:48:48 +0200
Subject: safe renegotiation bug?
In-Reply-To: <87y6ezcjr6.fsf@mocca.josefsson.org>
References: <87hblzdfmx.fsf@mocca.josefsson.org>
	<4BF8345A.2020009@gnutls.org>	<874ohzeko1.fsf@mocca.josefsson.org>
	<4BF85B33.5040203@gnutls.org>	<87typs7bcp.fsf@mocca.josefsson.org>
	<4BFF7154.3060700@gnutls.org>	<87typs5uwg.fsf@mocca.josefsson.org>
	<4C005B4C.7030606@gnutls.org>	<874ohoj6sf.fsf@mocca.josefsson.org>
	<4C040283.8040603@gnutls.org>	<87sk57g981.fsf@mocca.josefsson.org>
	<4C041CE2.3060006@gnutls.org> <87y6ezcjr6.fsf@mocca.josefsson.org>
Message-ID: <4C04BB60.3010603@gnutls.org>

Simon Josefsson wrote:

>> So which solution do you prefer?
> 
> I'm not sure that is a good idea -- then there is no way to configure
> mod_gnutls to talk to anyone.  People would need to use an older GnuTLS,
> or install mod_ssl or mod_nss instead to get that behaviour.
> 
> However, we already have %INITIAL_SAFE_RENEGOTIATION so we already have
> four different priority strings.  I think we could be feature complete
> with four different priority strings if we redesign things slightly:
> 
> %DISABLE_SAFE_RENEGOTIATION: Disable the extension, permits unsafe
>  (re-)handshakes.
> 
> %SAFE_RENEGOTIATION: Enable extension and require it for all handshakes.
> 
> %PARTIAL_RENEGOTIATION: Enable extension and require it on all
>  re-handshakes but permit initial handshakes without it.
> 
> %UNSAFE_RENEGOTIATION: Enable extension and permit all (re-)handshakes
>  without extension.
> 
> The default for both clients and servers would be
> %PARTIAL_RENEGOTIATION.  We'll change the defaults to
> %SAFE_RENEGOTIATION in two years or so.
> 
> What do you think about this approach?

As a concept I agree... The only problem might be that
%PARTIAL_RENEGOTIATION might be misleading in client side because it
doesn't really protect from the https renegotiation attack, but this can
be made clear in the documentation. I'll try to check it today.

regards,
Nikos





From simon at josefsson.org  Tue Jun  1 11:10:48 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 01 Jun 2010 11:10:48 +0200
Subject: safe renegotiation bug?
In-Reply-To: <4C04BB60.3010603@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Tue, 01 Jun 2010 09:48:48 +0200")
References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org>
	<874ohzeko1.fsf@mocca.josefsson.org> <4BF85B33.5040203@gnutls.org>
	<87typs7bcp.fsf@mocca.josefsson.org> <4BFF7154.3060700@gnutls.org>
	<87typs5uwg.fsf@mocca.josefsson.org> <4C005B4C.7030606@gnutls.org>
	<874ohoj6sf.fsf@mocca.josefsson.org> <4C040283.8040603@gnutls.org>
	<87sk57g981.fsf@mocca.josefsson.org> <4C041CE2.3060006@gnutls.org>
	<87y6ezcjr6.fsf@mocca.josefsson.org> <4C04BB60.3010603@gnutls.org>
Message-ID: <87iq639kyv.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Simon Josefsson wrote:
>
>>> So which solution do you prefer?
>> 
>> I'm not sure that is a good idea -- then there is no way to configure
>> mod_gnutls to talk to anyone.  People would need to use an older GnuTLS,
>> or install mod_ssl or mod_nss instead to get that behaviour.
>> 
>> However, we already have %INITIAL_SAFE_RENEGOTIATION so we already have
>> four different priority strings.  I think we could be feature complete
>> with four different priority strings if we redesign things slightly:
>> 
>> %DISABLE_SAFE_RENEGOTIATION: Disable the extension, permits unsafe
>>  (re-)handshakes.
>> 
>> %SAFE_RENEGOTIATION: Enable extension and require it for all handshakes.
>> 
>> %PARTIAL_RENEGOTIATION: Enable extension and require it on all
>>  re-handshakes but permit initial handshakes without it.
>> 
>> %UNSAFE_RENEGOTIATION: Enable extension and permit all (re-)handshakes
>>  without extension.
>> 
>> The default for both clients and servers would be
>> %PARTIAL_RENEGOTIATION.  We'll change the defaults to
>> %SAFE_RENEGOTIATION in two years or so.
>> 
>> What do you think about this approach?
>
> As a concept I agree... The only problem might be that
> %PARTIAL_RENEGOTIATION might be misleading in client side because it
> doesn't really protect from the https renegotiation attack, but this can
> be made clear in the documentation. I'll try to check it today.

Right, PARTIAL_RENEGOTIATION is the trade-off approach that is
vulnerable to some attacks but at least allows interop to happen.  I
think we have some good warning material in the manual already for this.

It would be great if you could make modifications to make this happen.
I can update the self tests to make sure it is working as we want it to.
Alas I'll be travelling in the next few days, but I'll have some
connectivity and can do a 2.9.11 release.

/Simon



From nmav at gnutls.org  Tue Jun  1 11:40:10 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 1 Jun 2010 11:40:10 +0200
Subject: safe renegotiation bug?
In-Reply-To: <87iq639kyv.fsf@mocca.josefsson.org>
References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org>
	<874ohzeko1.fsf@mocca.josefsson.org> <4BF85B33.5040203@gnutls.org>
	<87typs7bcp.fsf@mocca.josefsson.org> <4BFF7154.3060700@gnutls.org>
	<87typs5uwg.fsf@mocca.josefsson.org> <4C005B4C.7030606@gnutls.org>
	<874ohoj6sf.fsf@mocca.josefsson.org> <4C040283.8040603@gnutls.org>
	<87sk57g981.fsf@mocca.josefsson.org> <4C041CE2.3060006@gnutls.org>
	<87y6ezcjr6.fsf@mocca.josefsson.org> <4C04BB60.3010603@gnutls.org>
	<87iq639kyv.fsf@mocca.josefsson.org>
Message-ID: <AANLkTimKMO-Oa0pB4YYxi1z7iPZXFe5iY8tIEGK4-k_N@mail.gmail.com>

On Tue, Jun 1, 2010 at 11:10 AM, Simon Josefsson <simon at josefsson.org> wrote:

>>>> So which solution do you prefer?
>>>
>>> I'm not sure that is a good idea -- then there is no way to configure
>>> mod_gnutls to talk to anyone. ?People would need to use an older GnuTLS,
>>> or install mod_ssl or mod_nss instead to get that behaviour.
>>>
>>> However, we already have %INITIAL_SAFE_RENEGOTIATION so we already have
>>> four different priority strings. ?I think we could be feature complete
>>> with four different priority strings if we redesign things slightly:
>>>
>>> %DISABLE_SAFE_RENEGOTIATION: Disable the extension, permits unsafe
>>> ?(re-)handshakes.
>>>
>>> %SAFE_RENEGOTIATION: Enable extension and require it for all handshakes.
>>>
>>> %PARTIAL_RENEGOTIATION: Enable extension and require it on all
>>> ?re-handshakes but permit initial handshakes without it.
>>>
>>> %UNSAFE_RENEGOTIATION: Enable extension and permit all (re-)handshakes
>>> ?without extension.
>>>
>>> The default for both clients and servers would be
>>> %PARTIAL_RENEGOTIATION. ?We'll change the defaults to
>>> %SAFE_RENEGOTIATION in two years or so.
>>>
>>> What do you think about this approach?
>>
>> As a concept I agree... The only problem might be that
>> %PARTIAL_RENEGOTIATION might be misleading in client side because it
>> doesn't really protect from the https renegotiation attack, but this can
>> be made clear in the documentation. I'll try to check it today.
>
> Right, PARTIAL_RENEGOTIATION is the trade-off approach that is
> vulnerable to some attacks but at least allows interop to happen. ?I
> think we have some good warning material in the manual already for this.
> It would be great if you could make modifications to make this happen.
> I can update the self tests to make sure it is working as we want it to.

That would be great.

> Alas I'll be travelling in the next few days, but I'll have some
> connectivity and can do a 2.9.11 release

I'll try to have the code ready by tonight. Do the renegotiation self
tests cover all cases of the previously tests in bash?

regards,
Nikos



From nmav at gnutls.org  Tue Jun  1 16:17:50 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 01 Jun 2010 16:17:50 +0200
Subject: safe renegotiation bug?
In-Reply-To: <87iq639kyv.fsf@mocca.josefsson.org>
References: <87hblzdfmx.fsf@mocca.josefsson.org>
	<4BF8345A.2020009@gnutls.org>	<874ohzeko1.fsf@mocca.josefsson.org>
	<4BF85B33.5040203@gnutls.org>	<87typs7bcp.fsf@mocca.josefsson.org>
	<4BFF7154.3060700@gnutls.org>	<87typs5uwg.fsf@mocca.josefsson.org>
	<4C005B4C.7030606@gnutls.org>	<874ohoj6sf.fsf@mocca.josefsson.org>
	<4C040283.8040603@gnutls.org>	<87sk57g981.fsf@mocca.josefsson.org>
	<4C041CE2.3060006@gnutls.org>	<87y6ezcjr6.fsf@mocca.josefsson.org>
	<4C04BB60.3010603@gnutls.org> <87iq639kyv.fsf@mocca.josefsson.org>
Message-ID: <4C05168E.6060302@gnutls.org>

Simon Josefsson wrote:

>>> What do you think about this approach?
>> As a concept I agree... The only problem might be that
>> %PARTIAL_RENEGOTIATION might be misleading in client side because it
>> doesn't really protect from the https renegotiation attack, but this can
>> be made clear in the documentation. I'll try to check it today.
> 
> Right, PARTIAL_RENEGOTIATION is the trade-off approach that is
> vulnerable to some attacks but at least allows interop to happen.  I
> think we have some good warning material in the manual already for this.
> 
> It would be great if you could make modifications to make this happen.
> I can update the self tests to make sure it is working as we want it to.
> Alas I'll be travelling in the next few days, but I'll have some
> connectivity and can do a 2.9.11 release.

Should be ok now. I needed to make some changes in srn5 in order to
work. Please check them because I might have not understand what it
does. It might be better to have a small text that documents what each
srn?.c is testing for. Otherwise if it fails it is difficult to
understand why and what went wrong.


regards,
Nikos



From simon at josefsson.org  Tue Jun  1 16:25:48 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 01 Jun 2010 16:25:48 +0200
Subject: safe renegotiation bug?
In-Reply-To: <4C05168E.6060302@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Tue, 01 Jun 2010 16:17:50 +0200")
References: <87hblzdfmx.fsf@mocca.josefsson.org> <4BF8345A.2020009@gnutls.org>
	<874ohzeko1.fsf@mocca.josefsson.org> <4BF85B33.5040203@gnutls.org>
	<87typs7bcp.fsf@mocca.josefsson.org> <4BFF7154.3060700@gnutls.org>
	<87typs5uwg.fsf@mocca.josefsson.org> <4C005B4C.7030606@gnutls.org>
	<874ohoj6sf.fsf@mocca.josefsson.org> <4C040283.8040603@gnutls.org>
	<87sk57g981.fsf@mocca.josefsson.org> <4C041CE2.3060006@gnutls.org>
	<87y6ezcjr6.fsf@mocca.josefsson.org> <4C04BB60.3010603@gnutls.org>
	<87iq639kyv.fsf@mocca.josefsson.org> <4C05168E.6060302@gnutls.org>
Message-ID: <87pr0a96dv.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Simon Josefsson wrote:
>
>>>> What do you think about this approach?
>>> As a concept I agree... The only problem might be that
>>> %PARTIAL_RENEGOTIATION might be misleading in client side because it
>>> doesn't really protect from the https renegotiation attack, but this can
>>> be made clear in the documentation. I'll try to check it today.
>> 
>> Right, PARTIAL_RENEGOTIATION is the trade-off approach that is
>> vulnerable to some attacks but at least allows interop to happen.  I
>> think we have some good warning material in the manual already for this.
>> 
>> It would be great if you could make modifications to make this happen.
>> I can update the self tests to make sure it is working as we want it to.
>> Alas I'll be travelling in the next few days, but I'll have some
>> connectivity and can do a 2.9.11 release.
>
> Should be ok now. I needed to make some changes in srn5 in order to
> work. Please check them because I might have not understand what it
> does. It might be better to have a small text that documents what each
> srn?.c is testing for. Otherwise if it fails it is difficult to
> understand why and what went wrong.

Thanks!  I'll take a look later this week -- there is
tests/safe-rengotiation/README which attempts to describe the tests, but
it may not be completely updated.

It may be that some of the srn?.c tests are not relevant any more.

/Simon



From fidlersean at gmail.com  Sun Jun  6 01:01:34 2010
From: fidlersean at gmail.com (Sean Fidler)
Date: Sat, 5 Jun 2010 19:01:34 -0400
Subject: libgcrypt not found OS X 10.6.3
Message-ID: <AANLkTinBWvNTMewwuFxWjo5vIcR5MsEG1Soz_TrPPNQ4@mail.gmail.com>

Hi,

I'm trying to install gnutls and I'm receiving the error

checking for libgcrypt... no
configure: error:
***
*** libgcrypt was not found. You may want to get it from
*** ftp://ftp.gnupg.org/gcrypt/libgcrypt/
***

I have libgcrypt installed and I've used --with-libgcrypt-prefix with no luck.

I've searched on Google and found nothing about, which makes me
believe it's a bug. Of course, I could be missing something.

Thanks,
Sean



From nmav at gnutls.org  Sun Jun  6 20:31:16 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 06 Jun 2010 20:31:16 +0200
Subject: libgcrypt not found OS X 10.6.3
In-Reply-To: <AANLkTinBWvNTMewwuFxWjo5vIcR5MsEG1Soz_TrPPNQ4@mail.gmail.com>
References: <AANLkTinBWvNTMewwuFxWjo5vIcR5MsEG1Soz_TrPPNQ4@mail.gmail.com>
Message-ID: <4C0BE974.9080008@gnutls.org>

Sean Fidler wrote:
> Hi,
> 
> I'm trying to install gnutls and I'm receiving the error
> 
> checking for libgcrypt... no
> configure: error:
> ***
> *** libgcrypt was not found. You may want to get it from
> *** ftp://ftp.gnupg.org/gcrypt/libgcrypt/
> ***
> 
> I have libgcrypt installed and I've used --with-libgcrypt-prefix with no luck.
> 
> I've searched on Google and found nothing about, which makes me
> believe it's a bug. Of course, I could be missing something.

Check config.log for the reason.

regards,
Nikos



From simon at josefsson.org  Mon Jun  7 15:15:57 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 07 Jun 2010 15:15:57 +0200
Subject: safe renegotiation self checks
Message-ID: <87typf56gi.fsf@mocca.josefsson.org>

On the gnutls_2_10_x branch I have fixed so that we have the self-tests
for safe renegotiation described below.  Are there more cases that we
want to test?  Review welcome, it is easy to go code blind with this
complexity.  Code is available from:

http://git.savannah.gnu.org/cgit/gnutls.git/tree/tests/safe-renegotiation?h=gnutls_2_10_x

/Simon

Testing safe renegotiation is relatively complex, here is a summary of
what we test and what how we believe it should work.

	Client setting
			Server setting
					Initial handshake outcome
							Rehandshake outcome
srn0.c

 This tests that the safe renegotiation extension is negotiated
 properly by default on initial connections and on rehandshaked
 connections.  Consequently, it also verifies that rehandshaked
 connections work with the extension enabled.

	NORMAL
			NORMAL
					OK
							OK

srn1.c

 This tests that clients without support for safe renegotiation is
 able to handshake against servers with support, but not able to
 rehandshake (server will refuse rehandshake).

	NORMAL:%DISABLE_SAFE_RENEGOTIATION
			NORMAL
					OK
							Server refuses

srn2.c

 This tests that clients with support for safe renegotiation is able
 to handshake against servers without support, but not able to
 rehandshake (client will refuse rehandshake).

	NORMAL
			NORMAL:%DISABLE_SAFE_RENEGOTIATION
					OK
							Client refuses

srn3.c

 This tests that a %SAFE_RENEGOTIATION client will reject handshakes
 against servers that do not support the extension (server uses
 %DISABLE_SAFE_RENEGOTIATION).

	NORMAL:%SAFE_RENEGOTIATION
			NORMAL:%DISABLE_SAFE_RENEGOTIATION
					Client refuses
							N/A

srn4.c

 This tests that a %SAFE_RENEGOTIATION server will reject handshakes
 against clients that do not support the extension.

	NORMAL:%DISABLE_SAFE_RENEGOTIATION
			NORMAL:%SAFE_RENEGOTIATION
					Server refuses
							N/A

srn5.c

 This tests that a client with a permissive policy
 (%UNSAFE_RENEGOTIATION) is able to handshake and rehandshake with a
 server with no support for the extension.

	NORMAL:%DISABLE_SAFE_RENEGOTIATION
			NORMAL:%UNSAFE_RENEGOTIATION
					OK
							OK

srn6.c

 This tests that a server with a permissive policy
 (%UNSAFE_RENEGOTIATION) is able to handshake and rehandshake with a
 client with no support for the extension.

	NORMAL:%UNSAFE_RENEGOTIATION
			NORMAL:%DISABLE_SAFE_RENEGOTIATION
					OK
							OK

srn7.c

 This tests that clients and servers in %SAFE_RENEGOTIATION mode are
 able to handshake and rehandshake.

	NORMAL:%SAFE_RENEGOTIATION
			NORMAL:%SAFE_RENEGOTIATION
					OK
							OK



From simon at josefsson.org  Mon Jun  7 17:47:13 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 07 Jun 2010 17:47:13 +0200
Subject: GnuTLS 2.9.11 - second release candidate for 2.10.0
Message-ID: <87eigi26bi.fsf@mocca.josefsson.org>

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

Things on my radar before we can release 2.10.0:
- Someone please build and report about Solaris and Mac OS X status
- Sanity check by installing it as the system GnuTLS on a GNU/Linux
  system and make sure normal things still appear to work

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

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

Windows build:
  http://josefsson.org/gnutls4win/gnutls-2.9.11.exe
  http://josefsson.org/gnutls4win/gnutls-2.9.11.exe.sig
  http://josefsson.org/gnutls4win/gnutls-2.9.11.zip
  http://josefsson.org/gnutls4win/gnutls-2.9.11.zip.sig
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.9.11-1_all.deb

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

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

/Simon

* Version 2.9.11 (released 2010-06-07)

** libgnutls: Removed two APIs related to safe renegotiation.
Use priority strings instead.  The APIs were
gnutls_safe_negotiation_set_initial and gnutls_safe_renegotiation_set.
(Remember that we don't promise ABI stability during development
series, so this doesn't cause an shared library ABI increment.)

** tests: More self testing of safe renegotiation extension.
See tests/safe-renegotiation/README for more information.

** doc: a PDF version of the API reference manual (GTK-DOC) is now built.

** doc: Terms 'GNUTLS' and 'GNU TLS' were changed to 'GnuTLS' for consistency.

** API and ABI modifications:
gnutls_safe_negotiation_set_initial: REMOVED.
gnutls_safe_renegotiation_set: REMOVED.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 420 bytes
Desc: not available
URL: </pipermail/attachments/20100607/77024285/attachment.pgp>

From simon at josefsson.org  Mon Jun  7 17:49:41 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 07 Jun 2010 17:49:41 +0200
Subject: Updated draft release notes for 2.10.0
Message-ID: <87aar6267e.fsf@mocca.josefsson.org>

I've updated the release notes, see below for current draft.  Note in
particular the rewritten section 'TLS Renegotiation Attack' and the new
section 'Call to application authors'.

Let's put 2.9.11 to the test, and hopefully we can release 2.10.0 within
a week or two!

/Simon

To: help-gnutls at gnu.org, gnutls-devel at gnu.org, info-gnu at gnu.org
Subject: GnuTLS 2.10.0 released

We are proud to announce a new stable GnuTLS release: Version 2.10.0.

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
==========

Version 2.10.0 is the first stable release on the 2.10.x branch and is
the result of over 12 months of work on the experimental 2.9.x branch.
The GnuTLS 2.10.x branch replaces the GnuTLS 2.8.x branch as the
supported stable branch, although we will continue to support GnuTLS
2.8.x for some time.

** libgnutls: Added Steve Dispensa's patch for safe renegotiation (RFC 5746)
Solves the issue discussed in:
<http://www.ietf.org/mail-archive/web/tls/current/msg03928.html> and
<http://www.ietf.org/mail-archive/web/tls/current/msg03948.html>.
Note that to allow connecting to unpatched servers the full protection
is only enabled if the priority string %SAFE_RENEGOTIATION is
specified. You can check whether protection is in place by querying
gnutls_safe_renegotiation_status().  New error codes
GNUTLS_E_SAFE_RENEGOTIATION_FAILED and
GNUTLS_E_UNSAFE_RENEGOTIATION_DENIED added.

** libgnutls: Time verification extended to trusted certificate list.
Unless new constant GNUTLS_VERIFY_DISABLE_TRUSTED_TIME_CHECKS flag is
specified.

** certtool: Display postalCode and Name X.509 DN attributes correctly.
Based on patch by Pavan Konjarla.  Adds new constant
GNUTLS_OID_X520_POSTALCODE and GNUTLS_OID_X520_NAME.

** 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: Added cryptodev support (/dev/crypto).
Tested with http://home.gna.org/cryptodev-linux/.  Added
benchmark utility for AES.  Adds new error codes
GNUTLS_E_CRYPTODEV_IOCTL_ERROR and GNUTLS_E_CRYPTODEV_DEVICE_ERROR.

** libgnutls: Exported API to access encryption and hash algorithms.
The new API functions are gnutls_cipher_decrypt, gnutls_cipher_deinit,
gnutls_cipher_encrypt, gnutls_cipher_get_block_size,
gnutls_cipher_init, gnutls_hash, gnutls_hash_deinit, gnutls_hash_fast,
gnutls_hash_get_len, gnutls_hash_init, gnutls_hash_output,
gnutls_hmac, gnutls_hmac_deinit, gnutls_hmac_fast,
gnutls_hmac_get_len, gnutls_hmac_init, gnutls_hmac_output.  New API
constants are GNUTLS_MAC_SHA224 and GNUTLS_DIG_SHA224.

** libgnutls: Added gnutls_certificate_set_verify_function() to allow
verification of certificate upon receipt rather than waiting until the
end of the handshake.

** libgnutls: Don't send alerts during handshake.
Instead new error code GNUTLS_E_UNKNOWN_SRP_USERNAME is added.

** certtool: Corrected two issues that affected certificate request generation.
(1) Null padding is added on integers (found thanks to Wilankar Trupti),
(2) In optional SignatureAlgorithm parameters field for DSA keys the DSA
parameters were added. Those were rejected by Verisign. Gnutls no longer adds 
those parameters there since other implementations don't do either and having 
them does not seem to offer anything (anyway you need the signer's certificate
to verify thus public key will be available). Found thanks to Boyan Kasarov.
This however has the side-effect that public key IDs shown by certtool are
now different than previous gnutls releases.
(3) the option --pgp-certificate-info will verify self signatures

** certtool: Allow exporting of Certificate requests on DER format.

** certtool: New option --no-crq-extensions to avoid extensions in CSRs.

** gnutls-cli: Handle reading binary data from server.
Reported by and tiny patch from Vitaly Mayatskikh
<v.mayatskih at gmail.com> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/4096>.

** minitasn1: Upgraded to libtasn1 version 2.6.

** doc: The GTK-DOC manual is significantly improved.

** doc: a PDF version of the API reference manual (GTK-DOC) is now built.

** doc: Terms 'GNUTLS' and 'GNU TLS' were changed to 'GnuTLS' for consistency.

** 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
<https://savannah.gnu.org/support/?107029>.

** libgnutls: Fix for memory leaks on interrupted handshake.
Reported by Tang Tong.

** libgnutls: Addition of support for TLS 1.2 signature algorithms
** extension and certificate verify field.
This requires changes for TLS 1.2 servers and clients that use
callbacks for certificate retrieval.  They are now required to check
with gnutls_sign_algorithm_get_requested() whether the certificate
they send complies with the peer's preferences in signature
algorithms.

** libgnutls: In server side when resuming a session do not overwrite the 
** initial session data with the resumed session data.

** libgnutls: Added support for AES-128, AES-192 and AES-256 in PKCS #8
** encryption.
This affects also PKCS #12 encoded files.  This adds the following new
enums: GNUTLS_CIPHER_AES_192_CBC, GNUTLS_PKCS_USE_PBES2_AES_128,
GNUTLS_PKCS_USE_PBES2_AES_192, GNUTLS_PKCS_USE_PBES2_AES_256.

** libgnutls: Fix PKCS#12 encoding.
The error you would get was "The OID is not supported.".  Problem
introduced for the v2.8.x branch in 2.7.6.

** certtool: Added the --pkcs-cipher option.
To explicitely specify the encryption algorithm to use.

** tests: Added "pkcs12_encode" self-test to check PKCS#12 functions.

** tests: Fix time bomb in chainverify self-test.
Reported by Andreas Metzler <ametzler at downhill.at.eu.org> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3925>.

** tests: Fix expired cert in chainverify self-test.

** libgnutls: TLS 1.2 server mode fixes.
Now interoperates against Opera.  Contributed by Daiki Ueno.

** libgnutlsxx: Fix link problems.
Tiny patch from Boyan Kasarov <bkasarov at gmail.com>.

** guile: Compatibility with guile 2.x.
By Ludovic Courtes <ludovic.courtes at laas.fr>.

** libgnutls: Enable Camellia ciphers by default.

** libgnutls: Add new functions to extract X.509 Issuer Alternative Names.
The new functions are gnutls_x509_crt_get_issuer_alt_name2,
gnutls_x509_crt_get_issuer_alt_name, and
gnutls_x509_crt_get_issuer_alt_othername_oid.  Contributed by Brad
Hards <bradh at frogmouth.net>.

** libgnutls: Client-side TLS 1.2 and SHA-256 ciphersuites now works.
The new supported ciphersuites are AES-128/256 in CBC mode with
ANON-DH/RSA/DHE-DSS/DHE-RSA.  Contributed by Daiki Ueno.  Further,
SHA-256 is now the preferred default MAC (however it is only used with
TLS 1.2).

** libgnutls: Make OpenPGP hostname checking work again.
The patch to resolve the X.509 CN/SAN issue accidentally broken
OpenPGP hostname comparison.

** libgnutls: When printing X.509 certificates, handle XMPP SANs better.
Reported by Howard Chu <hyc at symas.com> in
<https://savannah.gnu.org/support/?106975>.

** Fix use of deprecated types internally.
Use of deprecated types in GnuTLS from now on will lead to a compile
error, to prevent this from happening again.

** libgnutls: Support for TLS tickets was contributed by Daiki Ueno.
The new APIs are gnutls_session_ticket_enable_client,
gnutls_session_ticket_enable_server, and
gnutls_session_ticket_key_generate.

** gnutls-cli, gnutls-serv: New parameter --noticket to disable TLS tickets.

** libgnutls: Fix problem with NUL bytes in X.509 CN and SAN fields.
By using a NUL byte in CN/SAN fields, it was possible to fool GnuTLS
into 1) not printing the entire CN/SAN field value when printing a
certificate and 2) cause incorrect positive matches when matching a
hostname against a certificate.  Some CAs apparently have poor
checking of CN/SAN values and issue these (arguable invalid)
certificates.  Combined, this can be used by attackers to become a
MITM on server-authenticated TLS sessions.  The problem is mitigated
since attackers needs to get one certificate per site they want to
attack, and the attacker reveals his tracks by applying for a
certificate at the CA.  It does not apply to client authenticated TLS
sessions.  Research presented independently by Dan Kaminsky and Moxie
Marlinspike at BlackHat09.  Thanks to Tomas Hoger <thoger at redhat.com>
for providing one part of the patch.  [GNUTLS-SA-2009-4] [CVE-2009-2730].

** libgnutls: Fix rare failure in gnutls_x509_crt_import.
The function may fail incorrectly when an earlier certificate was
imported to the same gnutls_x509_crt_t structure.

** libgnutls: Fix return value of gnutls_certificate_client_get_request_status.
Before it always returned false.  Reported by Peter Hendrickson
<pdh at wiredyne.com> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3668>.

** libgnutls: Fix off-by-one size computation error in unknown DN printing.
The error resulted in truncated strings when printing unknown OIDs in
X.509 certificate DNs.  Reported by Tim Kosse
<tim.kosse at filezilla-project.org> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3651>.

** libgnutls: Fix PKCS#12 decryption from password.
The encryption key derived from the password was incorrect for (on
average) 1 in every 128 input for random inputs.  Reported by "Kukosa,
Tomas" <tomas.kukosa at siemens-enterprise.com> in
<http://permalink.gmane.org/gmane.network.gnutls.general/1663>.

** libgnutls: Return correct bit lengths of some MPIs.
gnutls_dh_get_prime_bits, gnutls_rsa_export_get_modulus_bits, and
gnutls_dh_get_peers_public_bits.  Before the reported value was
overestimated.  Reported by Peter Hendrickson <pdh at wiredyne.com> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3607>.

** libgnutls: Avoid internal error when invoked after GNUTLS_E_AGAIN.
Report and patch by Tim Kosse <tim.kosse at filezilla-project.org> in
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3671>
and
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3670>.

** libgnutls: Relax checking of required libtasn1/libgcrypt versions.
Before we required that the runtime library used the same (or more
recent) libgcrypt/libtasn1 as it was compiled with.  Now we just check
that the runtime usage is above the minimum required.  Reported by
Marco d'Itri <md at linux.it> via Andreas Metzler
<ametzler at downhill.at.eu.org> in <http://bugs.debian.org/540449>.

** tests: Added new self-test pkcs12_s2k_pem to detect MPI bit length error.

** tests: Improved test vectors in self-test pkcs12_s2k.

** tests: Added new self-test dn2 to detect off-by-one size error.

** tests: Fix failure in "chainverify" because a certificate have expired.

** libgnutls: Fix crash in gnutls_global_init after earlier init/deinit cycle.
Forwarded by Martin von Gagern <Martin.vGagern at gmx.net> from
<http://bugs.gentoo.org/272388>.

** Reduce stack usage for some CRQ functions.

** Doc fixes for CRQ functions.

TLS Renegotiation Attack
========================

Some application protocols and implementations uses the TLS
renegotiation feature in a manner that enables attackers to insert
content of his choice in the beginning of a TLS session.

One easy to understand vulnerability is HTTPS when servers request
client certificates optionally for certain parts of a web site.  The
attack works by having the attacker simulate a client and connect to a
server, with server-only authentication, and send some data intended to
cause harm.  When the proper client attempts to contact the server, the
attacker hijacks that connection and uses the TLS renegotiation feature
with the server and splices in the client connection to the already
established connection between the attacker and server.  The attacker
will not be able to read the data exchanged between the client and the
server.  However, the server will (incorrectly) assume that the data
sent by the attacker was sent by the now authenticated client.  The
result is a prefix plain-text injection attack.

The above is just one example.  Other vulnerabilities exists that do
not rely on the TLS renegotiation to change the client's authenticated
status (either TLS or application layer).

While fixing these application protocols and implementations would be
one natural reaction, an extension to TLS has been designed that
cryptographically binds together any renegotiated handshakes with the
initial negotiation.  When the extension is used, the attack is
detected and the session can be terminated.  The extension is specified
in RFC5746.

GnuTLS supports the safe renegotiation extension.  The default behavior
is as follows.  Clients will attempt to negotiate the safe
renegotiation extension when talking to servers.  Servers will accept
the extension when presented by clients.  Clients and servers will
permit an initial handshake to complete even when the other side does
not support the safe renegotiation extension.  Clients and servers will
refuse renegotiation attempts when the extension has not been
negotiated.

Note that permitting clients to connect to servers even when the safe
renegotiation extension is not negotiated open up for some attacks.
Changing this default behaviour would prevent interoperability against
the majority of deployed servers out there.  We will reconsider this
default behaviour in the future when more servers have been upgraded.
Note that it is easy to configure clients to always require the safe
renegotiation extension from servers (see below on the
`%SAFE_RENEGOTIATION' priority string).

To modify the default behaviour, we have introduced some new priority
strings.  The priority strings can be used by applications (see
gnutls_priority_set) and end users (e.g., `--priority' parameter to
`gnutls-cli' and `gnutls-serv').

The `%UNSAFE_RENEGOTIATION' priority string permits (re-)handshakes
even when the safe renegotiation extension was not negotiated.  The
default behavior is `%PARTIAL_RENEGOTIATION' that will prevent
renegotiation with clients and servers not supporting the extension.
This is secure for servers but leaves clients vulnerable to some
attacks, but this is a tradeoff between security and compatibility with
old servers.  The `%SAFE_RENEGOTIATION' priority string makes clients
and servers require the extension for every handshake.  The latter is
the most secure option for clients, at the cost of not being able to
connect to legacy servers.  Servers will also deny clients that do not
support the extension from connecting.

It is possible to disable use of the extension completely, in both
clients and servers, by using the `%DISABLE_SAFE_RENEGOTIATION'
priority string however we strongly recommend you to only do this for
debugging and test purposes.

The default values if the flags above are not specified are:
`Server:'
     %PARTIAL_RENEGOTIATION

`Client:'
     %PARTIAL_RENEGOTIATION

For applications we have introduced a new API related to safe
renegotiation.  The gnutls_safe_renegotiation_status function is used
to check if the extension has been negotiated on a session, and can be
used both by clients and servers.

Call to application authors
===========================

Please use the priority string interface, and make it possible for
users to supply a priority string!

Several parts of GnuTLS, including the new safe renegotiation
behaviour, can be configured through priority strings.  However, if
the application do not publish this interface to users, it will not be
possible to configure GnuTLS the way a user wants.

The new defaults for GnuTLS with regard to the safe renegotiation bug
is to be insecure by default.  This is something we reluctantly and
after carefuly consideration decided to do, for interoperability
reasons.  We'd like to close this security gap as soon as possible,
hopefully even for the GnuTLS 2.12.x branch.

For this transition to be as smooth as possible, users of GnuTLS
applications needs to be able to provide a priority string when a TLS
session is initialized.  Preferrably it should be possible to do on a
domain name or IP basis, to only modify the defaults for a particular
server and not generally.

Once the GnuTLS defaults have changed to be secure by default, users
may want to be able to provide a %PARTIAL_RENEGOTIATION or even an
%UNSAFE_RENEGOTIATION priority string, to be able to talk with certain
clients or servers.  This will not be possible unless you, as
application author, export this ability to your users.

Technically, you would replace a call like this:

   gnutls_set_default_priority (session)

with a call like this:

   gnutls_priority_set_direct (session, string, NULL);

where 'string' is a character string read from your configuration
files, and the default should be 'NORMAL'.  It is fine for string to
be NULL if you didn't read any configuration from the user, then
'NORMAL' will be used.

For more information see:

http://www.gnu.org/software/gnutls/manual/html_node/Core-functions.html#gnutls_005fpriority_005finit

API/ABI changes in GnuTLS 2.10
==============================

No offically supported interfaces have been modified or removed.  The
library should be completely backwards compatible on both the source
and binary level.

The following symbols have been added to the library:

gnutls_certificate_set_verify_function: ADDED.
gnutls_cipher_decrypt: ADDED.
gnutls_cipher_deinit: ADDED.
gnutls_cipher_encrypt: ADDED.
gnutls_cipher_get_block_size: ADDED.
gnutls_cipher_init: ADDED.
gnutls_hash: ADDED.
gnutls_hash_deinit: ADDED.
gnutls_hash_fast: ADDED.
gnutls_hash_get_len: ADDED.
gnutls_hash_init: ADDED.
gnutls_hash_output: ADDED.
gnutls_hmac: ADDED.
gnutls_hmac_deinit: ADDED.
gnutls_hmac_fast: ADDED.
gnutls_hmac_get_len: ADDED.
gnutls_hmac_init: ADDED.
gnutls_hmac_output: ADDED.
gnutls_safe_renegotiation_status: ADDED.
gnutls_sign_algorithm_get_requested: ADDED.

gnutls_x509_crt_get_issuer_alt_name2: ADDED.
gnutls_x509_crt_get_issuer_alt_name: ADDED.
gnutls_x509_crt_get_issuer_alt_othername_oid: ADDED.

gnutls_session_ticket_key_generate: ADDED.
gnutls_session_ticket_enable_client: ADDED.
gnutls_session_ticket_enable_server: ADDED.

In addition to the functions above, the following non-function
definitions have been added to the header files:

GNUTLS_DIG_SHA224: ADDED.
GNUTLS_E_CRYPTODEV_DEVICE_ERROR: ADDED.
GNUTLS_E_CRYPTODEV_IOCTL_ERROR: ADDED.
GNUTLS_E_SAFE_RENEGOTIATION_FAILED: ADDED.
GNUTLS_E_UNKNOWN_SRP_USERNAME: ADDED.
GNUTLS_E_UNSAFE_RENEGOTIATION_DENIED: ADDED.
GNUTLS_MAC_SHA224: ADDED.
GNUTLS_OID_X520_NAME: ADDED.
GNUTLS_OID_X520_POSTALCODE: ADDED.
GNUTLS_VERIFY_DISABLE_TRUSTED_TIME_CHECKS: ADDED.
GNUTLS_VERSION_MAX: ADDED.

GNUTLS_CIPHER_AES_192_CBC: ADDED to gnutls/gnutls.h.
GNUTLS_PKCS_USE_PBES2_AES_128: ADDED to gnutls/x509.h.
GNUTLS_PKCS_USE_PBES2_AES_192: ADDED to gnutls/x509.h.
GNUTLS_PKCS_USE_PBES2_AES_256: ADDED to gnutls/x509.h.
GNUTLS_BAG_SECRET: ADDED to gnutls/pkcs12.h.
GNUTLS_DIG_UNKNOWN: ADDED to gnutls/gnutls.h.

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 (6.0MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.0.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.0.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.10.0.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 <jas at extundo.com>
uid                  Simon Josefsson <simon at josefsson.org>
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:

7c102253bb4e817f393b9979a62c647010312eac  gnutls-2.10.0.tar.bz2

57ee306f261ed331b8386baf854f737fbf24da7b3bcc32331d34176b  gnutls-2.10.0.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.5, libtasn1 v2.6, and GnuTLS
v2.10.0.

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

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

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

8a7965168c542edec3259469b6c0e87a9a2b4626  gnutls-2.10.0.exe

5f76c907eac768b714dc7187a17f87c0393439cf1ef44ab145aab6e3  gnutls-2.10.0.exe

A ZIP archive containing the Windows binaries:
  http://josefsson.org/gnutls4win/gnutls-2.10.0.zip (5.3MB)
  http://josefsson.org/gnutls4win/gnutls-2.10.0.zip.sig

A Debian mingw32 package is also available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.7.10-1_all.deb (4.8MB)

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

aca9f9f1adba09b952e095039595d4c5d9e67d46  mingw32-gnutls_2.10.0-1_all.deb

269020738a9f36135e3f231a94cdb2cabc0edd3658092d76b87c27dc  mingw32-gnutls_2.10.0-1_all.deb

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

The GnuTLS library messages have been translated into Czech, Dutch,
French, German, Italian, Malay, Polish, Simplified Chinese, 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



From ametzler at downhill.at.eu.org  Tue Jun  8 19:59:52 2010
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Tue, 8 Jun 2010 19:59:52 +0200
Subject: GnuTLS versions 2.9.7 and later breaks libsoup (epiphany)
Message-ID: <20100608175952.GB4525@downhill.g.la>

Hello,

this is http://bugs.debian.org/576339

With GnuTLS versions 2.9.7 and later epiphany is unable to load https
sites. Reproducing this is very easy on Debian/unstable
(+experimental)

sudo apt-get install epiphany-browser
sudo apt-get install libgnutls26=2.9.11-1
epiphany-browser https://db.debian.org/

epiphany simply gets stuck, resending the same request again and
again. GnuTLS 2.9.6 and earlier (including 2.8.x) are fine.

cu andreas



From nmav at gnutls.org  Tue Jun  8 23:41:35 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 08 Jun 2010 23:41:35 +0200
Subject: GnuTLS versions 2.9.7 and later breaks libsoup (epiphany)
In-Reply-To: <20100608175952.GB4525@downhill.g.la>
References: <20100608175952.GB4525@downhill.g.la>
Message-ID: <4C0EB90F.2080000@gnutls.org>

Andreas Metzler wrote:
> Hello,
> this is http://bugs.debian.org/576339
> 
> With GnuTLS versions 2.9.7 and later epiphany is unable to load https
> sites. Reproducing this is very easy on Debian/unstable
> (+experimental)
> 
> sudo apt-get install epiphany-browser
> sudo apt-get install libgnutls26=2.9.11-1
> epiphany-browser https://db.debian.org/
> 
> epiphany simply gets stuck, resending the same request again and
> again. GnuTLS 2.9.6 and earlier (including 2.8.x) are fine.

Hi,
 The problem seems to be the support for TLS 1.2. It seems that epiphany
sets a priority string of "NORMAL:!VERS-TLS1.1:!VERS-TLS1.0". Thus the
allowed versions are now TLS 1.2 and SSL 3.0. The servers do not support
TLS 1.2 thus falling back to TLS 1.0 which is not supported. A quick fix
would be to add !VERS-TLS1.2 to epiphany (I have no idea where it is).


regards,
Nikos



From nmav at gnutls.org  Wed Jun  9 13:47:25 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 9 Jun 2010 13:47:25 +0200
Subject: request for comments: PKCS #11
Message-ID: <AANLkTim2l9sGjV7VtMzVlL6kd_zuTWOW2SLz2RivHrgt@mail.gmail.com>

Hello,
 I sent this to you because you have previously expressed your
interest on PKCS #11 support in gnutls or you have already implement
it (in that case I have taken ideas already from you), or I'd be
interested in your comments.  I have added PKCS #11 support in gnutls
and I would like your comments and ideas. The basic functionality
supported is reading public and private keys (as well as
certificates), using private keys for operations and storing private
keys and certificates to tokens (smart cards etc). To reference any
objects I used PKCS #11 URLs as specified in
http://tools.ietf.org/html/draft-pechanec-pkcs11uri-01.  This has the
advantage that all existing applications that use the gnutls functions
to load keys/certificates will be able to use pkcs11 urls
transparently. For example I can use gnutls-cli with a certificate and
private key residing in my smart card, and use the trusted certificate
list in gnome-keyring for verification.

The current API can be found at:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/includes/gnutls/pkcs11.h;h=22850d09788913f121145fd38404fd69cd8a37ce;hb=HEAD

API for abstract data types that handle private and public keys either
in PCKS #11 or in gnutls_x509_* format.
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/includes/gnutls/abstract.h;h=77e7994a5e87c4d1d2e95b0d8dfac4c8e9d223b5;hb=HEAD

And some text describing it is at (sorry it is raw .texi for now):
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=doc/cha-cert-auth.texi;h=68999e1d80efc47ba12a490510a708b7cc0fee88;hb=HEAD#l322
as well as an image on how I think it will be used:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=doc/pkcs11-vision.png;h=15c14f4e39ff6acb0a46124e626a356ef2f1a0fa;hb=HEAD

regards,
Nikos



From simon at josefsson.org  Wed Jun  9 14:52:21 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 09 Jun 2010 14:52:21 +0200
Subject: GnuTLS versions 2.9.7 and later breaks libsoup (epiphany)
In-Reply-To: <4C0EB90F.2080000@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Tue, 08 Jun 2010 23:41:35 +0200")
References: <20100608175952.GB4525@downhill.g.la> <4C0EB90F.2080000@gnutls.org>
Message-ID: <878w6owepm.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Andreas Metzler wrote:
>> Hello,
>> this is http://bugs.debian.org/576339
>> 
>> With GnuTLS versions 2.9.7 and later epiphany is unable to load https
>> sites. Reproducing this is very easy on Debian/unstable
>> (+experimental)
>> 
>> sudo apt-get install epiphany-browser
>> sudo apt-get install libgnutls26=2.9.11-1
>> epiphany-browser https://db.debian.org/
>> 
>> epiphany simply gets stuck, resending the same request again and
>> again. GnuTLS 2.9.6 and earlier (including 2.8.x) are fine.
>
> Hi,
>  The problem seems to be the support for TLS 1.2. It seems that epiphany
> sets a priority string of "NORMAL:!VERS-TLS1.1:!VERS-TLS1.0". Thus the
> allowed versions are now TLS 1.2 and SSL 3.0. The servers do not support
> TLS 1.2 thus falling back to TLS 1.0 which is not supported. A quick fix
> would be to add !VERS-TLS1.2 to epiphany (I have no idea where it is).

Why aren't they simply using 'NORMAL'?  I think any deviation from
NORMAL need some good justification, and ultimately configured by the
user.  Not supporting TLS 1.0 seems quite bad...

/Simon



From nmav at gnutls.org  Wed Jun  9 15:09:04 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 9 Jun 2010 15:09:04 +0200
Subject: GnuTLS versions 2.9.7 and later breaks libsoup (epiphany)
In-Reply-To: <878w6owepm.fsf@mocca.josefsson.org>
References: <20100608175952.GB4525@downhill.g.la> <4C0EB90F.2080000@gnutls.org>
	<878w6owepm.fsf@mocca.josefsson.org>
Message-ID: <AANLkTim3YpACeiN_A1b-fDC9VmNtJhjeZYwVejM0rffV@mail.gmail.com>

On Wed, Jun 9, 2010 at 2:52 PM, Simon Josefsson <simon at josefsson.org> wrote:

>> ?The problem seems to be the support for TLS 1.2. It seems that epiphany
>> sets a priority string of "NORMAL:!VERS-TLS1.1:!VERS-TLS1.0". Thus the
>> allowed versions are now TLS 1.2 and SSL 3.0. The servers do not support
>> TLS 1.2 thus falling back to TLS 1.0 which is not supported. A quick fix
>> would be to add !VERS-TLS1.2 to epiphany (I have no idea where it is).
>
> Why aren't they simply using 'NORMAL'? ?I think any deviation from
> NORMAL need some good justification, and ultimately configured by the
> user. ?Not supporting TLS 1.0 seems quite bad...

I only speculate here, but I think it is probably for interoperability
reasons. I've seen some servers rejecting client hellos containing TLS
1.1 and/or TLS 1.2. I don't think TLS 1.0 is a problem though.
Sometime ago, I was thinking disabling 1.1 and 1.2 if the %COMPAT flag
is specified, but never did it due to lack of complaints :)

regards,
Nikos



From ametzler at downhill.at.eu.org  Wed Jun  9 19:41:18 2010
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Wed, 9 Jun 2010 19:41:18 +0200
Subject: GnuTLS versions 2.9.7 and later breaks libsoup (epiphany)
In-Reply-To: <4C0EB90F.2080000@gnutls.org>
References: <20100608175952.GB4525@downhill.g.la> <4C0EB90F.2080000@gnutls.org>
Message-ID: <20100609174118.GB3862@downhill.g.la>

On 2010-06-08 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> Andreas Metzler wrote:
> > Hello,
> > this is http://bugs.debian.org/576339
>
> > With GnuTLS versions 2.9.7 and later epiphany is unable to load https
> > sites. Reproducing this is very easy on Debian/unstable
> > (+experimental)

> > sudo apt-get install epiphany-browser
> > sudo apt-get install libgnutls26=2.9.11-1
> > epiphany-browser https://db.debian.org/
 
> > epiphany simply gets stuck, resending the same request again and
> > again. GnuTLS 2.9.6 and earlier (including 2.8.x) are fine.

> Hi,
>  The problem seems to be the support for TLS 1.2. It seems that epiphany
> sets a priority string of "NORMAL:!VERS-TLS1.1:!VERS-TLS1.0". Thus the
> allowed versions are now TLS 1.2 and SSL 3.0. The servers do not support
> TLS 1.2 thus falling back to TLS 1.0 which is not supported.

Shouldn't GnuTLS fall back to the supported protocol (SSL 3.0) in that
case instead of getting stuck?

> A quick fix
> would be to add !VERS-TLS1.2 to epiphany (I have no idea where it is).

The respective code seems to be in libsoup
libsoup2.4-2.30.1/libsoup/soup-gnutls.c
and the explaining comment points to 
http://bugzilla.gnome.org/show_bug.cgi?id=581342 as reason. Apparently
epiphany experienced breakage with SSL 3.0 only servers
(www.paypal.com).

While changing the respective initialisation from

gnutls_priority_set_direct (session, "NORMAL:!VERS-TLS1.1:!VERS-TLS1.0", NULL)
to
gnutls_priority_set_direct (session, "NORMAL", NULL)

makes https://db.debian.org/ accessible again with GnuTLS 2.9.7,
it also breaks connecting to https://www.paypal.com/. Not really a
solution.

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  Wed Jun  9 20:11:36 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 09 Jun 2010 20:11:36 +0200
Subject: GnuTLS versions 2.9.7 and later breaks libsoup (epiphany)
In-Reply-To: <20100609174118.GB3862@downhill.g.la>
References: <20100608175952.GB4525@downhill.g.la> <4C0EB90F.2080000@gnutls.org>
	<20100609174118.GB3862@downhill.g.la>
Message-ID: <4C0FD958.9060105@gnutls.org>

Andreas Metzler wrote:

>> Hi,
>>  The problem seems to be the support for TLS 1.2. It seems that epiphany
>> sets a priority string of "NORMAL:!VERS-TLS1.1:!VERS-TLS1.0". Thus the
>> allowed versions are now TLS 1.2 and SSL 3.0. The servers do not support
>> TLS 1.2 thus falling back to TLS 1.0 which is not supported.
> 
> Shouldn't GnuTLS fall back to the supported protocol (SSL 3.0) in that
> case instead of getting stuck?

It cannot. The server decides the fallback.

>> A quick fix
>> would be to add !VERS-TLS1.2 to epiphany (I have no idea where it is).
> 
> The respective code seems to be in libsoup
> libsoup2.4-2.30.1/libsoup/soup-gnutls.c
> and the explaining comment points to 
> http://bugzilla.gnome.org/show_bug.cgi?id=581342 as reason. Apparently
> epiphany experienced breakage with SSL 3.0 only servers
> (www.paypal.com).
> 
> While changing the respective initialisation from
> 
> gnutls_priority_set_direct (session, "NORMAL:!VERS-TLS1.1:!VERS-TLS1.0", NULL)
> to
> gnutls_priority_set_direct (session, "NORMAL", NULL)

Then the solution should be:
NORMAL:!VERS-TLS1.1:!VERS-TLS1.2:!VERS-TLS1.0

regards,
Nikos



From stef-list at memberwebs.com  Thu Jun 10 05:49:51 2010
From: stef-list at memberwebs.com (Stef Walter)
Date: Wed, 09 Jun 2010 22:49:51 -0500
Subject: request for comments: PKCS #11
In-Reply-To: <AANLkTim2l9sGjV7VtMzVlL6kd_zuTWOW2SLz2RivHrgt@mail.gmail.com>
References: <AANLkTim2l9sGjV7VtMzVlL6kd_zuTWOW2SLz2RivHrgt@mail.gmail.com>
Message-ID: <4C1060DF.7080703@memberwebs.com>

On 2010-06-09 06:47, Nikos Mavrogiannopoulos wrote:
> Hello,
>  I sent this to you because you have previously expressed your
> interest on PKCS #11 support in gnutls or you have already implement
> it (in that case I have taken ideas already from you), or I'd be
> interested in your comments.  I have added PKCS #11 support in gnutls
> and I would like your comments and ideas. 

This is awesome progress. I'm excited because I'm going to be giving a
talk at GUADEC conference (in the Netherlands) about uniting GNOME's
(and in the future the Linux Desktop's) crypto storage around PKCS#11.

http://www.guadec.org/index.php/guadec/2010/paper/view/15

One question though, are you importing private keys from the PKCS#11
token, or using the crypto operations. Forgive me if I've overlooked
something but in this example looked like the keys were being imported:

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=doc/cha-cert-auth.texi;h=68999e1d80efc47ba12a490510a708b7cc0fee88;hb=HEAD#l532

The basic functionality
> supported is reading public and private keys (as well as
> certificates), using private keys for operations and storing private
> keys and certificates to tokens (smart cards etc). To reference any
> objects I used PKCS #11 URLs as specified in
> http://tools.ietf.org/html/draft-pechanec-pkcs11uri-01.  

Interesting spec. I hadn't seen it before.

Day Dreaming: It's too bad there isn't a way to have a unique URL per
PKCS#11 object. However, this spec is still better than nothing and I
can see how it would be useful for loading objects.

One thing that I'm interested in is the use of a pkcs11 config file
system. I was thinking of a scaled down PAM style concept, where one can
configure in a standard way which pkcs11 modules to load. In other
words, which host processes should load which modules. I noticed you
have a config file specific to gnutls there. Do you know of any work
being done on something more global?

Anyway, all that to say, I love seeing progress in this area, and would
like to stay in touch.

Cheers,

Stef



From simon at josefsson.org  Thu Jun 10 09:08:23 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 10 Jun 2010 09:08:23 +0200
Subject: GnuTLS versions 2.9.7 and later breaks libsoup (epiphany)
In-Reply-To: <20100609174118.GB3862@downhill.g.la> (Andreas Metzler's message
	of "Wed, 9 Jun 2010 19:41:18 +0200")
References: <20100608175952.GB4525@downhill.g.la>
	<4C0EB90F.2080000@gnutls.org> <20100609174118.GB3862@downhill.g.la>
Message-ID: <87bpbjs6u0.fsf@mocca.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> On 2010-06-08 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>> Andreas Metzler wrote:
>> > Hello,
>> > this is http://bugs.debian.org/576339
>>
>> > With GnuTLS versions 2.9.7 and later epiphany is unable to load https
>> > sites. Reproducing this is very easy on Debian/unstable
>> > (+experimental)
>
>> > sudo apt-get install epiphany-browser
>> > sudo apt-get install libgnutls26=2.9.11-1
>> > epiphany-browser https://db.debian.org/
>  
>> > epiphany simply gets stuck, resending the same request again and
>> > again. GnuTLS 2.9.6 and earlier (including 2.8.x) are fine.
>
>> Hi,
>>  The problem seems to be the support for TLS 1.2. It seems that epiphany
>> sets a priority string of "NORMAL:!VERS-TLS1.1:!VERS-TLS1.0". Thus the
>> allowed versions are now TLS 1.2 and SSL 3.0. The servers do not support
>> TLS 1.2 thus falling back to TLS 1.0 which is not supported.
>
> Shouldn't GnuTLS fall back to the supported protocol (SSL 3.0) in that
> case instead of getting stuck?

I think there is a bug in epiphany (or libsoup) here that cause it to
send the same request over and over again -- either the request should
succeed or it should fail.  I don't see why it is trying the same
request over and over again.

What it could do is to try the request with default settings (i.e.,
NORMAL, which makes it support latest protocol improvements) but if that
fails with an error message that indicate that re-trying without TLS 1.x
will help, it should re-try with lower TLS protocol versions.  It won't
help to re-try the exact same handshake.

>> A quick fix
>> would be to add !VERS-TLS1.2 to epiphany (I have no idea where it is).
>
> The respective code seems to be in libsoup
> libsoup2.4-2.30.1/libsoup/soup-gnutls.c
> and the explaining comment points to 
> http://bugzilla.gnome.org/show_bug.cgi?id=581342 as reason. Apparently
> epiphany experienced breakage with SSL 3.0 only servers
> (www.paypal.com).
>
> While changing the respective initialisation from
>
> gnutls_priority_set_direct (session, "NORMAL:!VERS-TLS1.1:!VERS-TLS1.0", NULL)
> to
> gnutls_priority_set_direct (session, "NORMAL", NULL)
>
> makes https://db.debian.org/ accessible again with GnuTLS 2.9.7,
> it also breaks connecting to https://www.paypal.com/. Not really a
> solution.

A better solution is to attempt the NORMAL setting first, and if it
fails, also attempt to negotiate using SSL3+TLS1 only.  If that fails,
stop retrying.

/Simon



From nmav at gnutls.org  Thu Jun 10 10:27:13 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 10 Jun 2010 10:27:13 +0200
Subject: request for comments: PKCS #11
In-Reply-To: <4C1060DF.7080703@memberwebs.com>
References: <AANLkTim2l9sGjV7VtMzVlL6kd_zuTWOW2SLz2RivHrgt@mail.gmail.com>
	<4C1060DF.7080703@memberwebs.com>
Message-ID: <AANLkTimUXTyEydb127ePsYd3HXVWKBKXPGp4UpbFEZpi@mail.gmail.com>

On Thu, Jun 10, 2010 at 5:49 AM, Stef Walter <stef-list at memberwebs.com> wrote:
>> Hello,
>> ?I sent this to you because you have previously expressed your
>> interest on PKCS #11 support in gnutls or you have already implement
>> it (in that case I have taken ideas already from you), or I'd be
>> interested in your comments. ?I have added PKCS #11 support in gnutls
>> and I would like your comments and ideas.
>
> This is awesome progress. I'm excited because I'm going to be giving a
> talk at GUADEC conference (in the Netherlands) about uniting GNOME's
> (and in the future the Linux Desktop's) crypto storage around PKCS#11.
> http://www.guadec.org/index.php/guadec/2010/paper/view/15

That's cool. I believe on the same thing. PKCS #11 can be used as glue
to connect all the now separated pieces. The advantage of it is that
one can have a central storage that all libraries can access, thus
allowing the existing diversity and offering usability at the same
time.

> One question though, are you importing private keys from the PKCS#11
> token, or using the crypto operations. Forgive me if I've overlooked
> something but in this example looked like the keys were being imported:
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=doc/cha-cert-auth.texi;h=68999e1d80efc47ba12a490510a708b7cc0fee88;hb=HEAD#l532

The system call for privkeys is called "import" but it actually
associates the URL object with the pkcs11 structure. It does not try
to import it.

> Day Dreaming: It's too bad there isn't a way to have a unique URL per
> PKCS#11 object. However, this spec is still better than nothing and I
> can see how it would be useful for loading objects.

I believe this is possible if all the components of the URL are specified.

> One thing that I'm interested in is the use of a pkcs11 config file
> system. I was thinking of a scaled down PAM style concept, where one can
> configure in a standard way which pkcs11 modules to load. In other
> words, which host processes should load which modules. I noticed you
> have a config file specific to gnutls there. Do you know of any work
> being done on something more global?

No I'm not aware of something like that, but I would also be
interested in anything related.


regards,
Nikos



From nmav at gnutls.org  Thu Jun 10 10:43:05 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 10 Jun 2010 10:43:05 +0200
Subject: GnuTLS versions 2.9.7 and later breaks libsoup (epiphany)
In-Reply-To: <87bpbjs6u0.fsf@mocca.josefsson.org>
References: <20100608175952.GB4525@downhill.g.la> <4C0EB90F.2080000@gnutls.org>
	<20100609174118.GB3862@downhill.g.la>
	<87bpbjs6u0.fsf@mocca.josefsson.org>
Message-ID: <AANLkTimy_mnW-wSPcxKmCc0GP_G0_p-kxl3erSPGh752@mail.gmail.com>

On Thu, Jun 10, 2010 at 9:08 AM, Simon Josefsson <simon at josefsson.org> wrote:
>> makes https://db.debian.org/ accessible again with GnuTLS 2.9.7,
>> it also breaks connecting to https://www.paypal.com/. Not really a
>> solution.
>
> A better solution is to attempt the NORMAL setting first, and if it
> fails, also attempt to negotiate using SSL3+TLS1 only. ?If that fails,
> stop retrying.

For some reason the paypal site fails even with TLS1.0! It cannot
gracefully fallback to SSL 3.0, and it works only if it is asked for
SSL3.0 alone. I couldn't figure out which server they have.

regards,
Nikos



From simon at josefsson.org  Thu Jun 17 17:24:33 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 17 Jun 2010 17:24:33 +0200
Subject: GnuTLS 2.9.12 - third and final (?) release candidate for 2.10.0
Message-ID: <87aaqtbs26.fsf@mocca.josefsson.org>

I plan to release our new stable branch 2.10.0 next week, unless we get
reports about things not working.  NOW is the time to test.

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

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

Windows build:
  http://josefsson.org/gnutls4win/gnutls-2.9.12.exe
  http://josefsson.org/gnutls4win/gnutls-2.9.12.exe.sig
  http://josefsson.org/gnutls4win/gnutls-2.9.12.zip
  http://josefsson.org/gnutls4win/gnutls-2.9.12.zip.sig
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.9.12-1_all.deb

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

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

/Simon

* Version 2.9.12 (released 2010-06-17)

** gnutls-cli: Make --starttls work again.
Problem introduced in patch to use read() instead of fgets() committed
on 2010-01-27.

** 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: 420 bytes
Desc: not available
URL: </pipermail/attachments/20100617/e425fe4e/attachment.pgp>

From ametzler at downhill.at.eu.org  Thu Jun 17 20:04:55 2010
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Thu, 17 Jun 2010 20:04:55 +0200
Subject: GnuTLS 2.9.12 - third and final (?) release candidate for 2.10.0
In-Reply-To: <87aaqtbs26.fsf@mocca.josefsson.org>
References: <87aaqtbs26.fsf@mocca.josefsson.org>
Message-ID: <20100617180455.GC3510@downhill.g.la>

On 2010-06-17 Simon Josefsson <simon at josefsson.org> wrote:
> I plan to release our new stable branch 2.10.0 next week, unless we get
> reports about things not working.  NOW is the time to test.
[...]

Hello,

a workaround for http://bugs.debian.org/519006 would be nice, 2.9.x
does not build on mips(el). (See e.g.
http://bugs.debian.org/585476)

I could understand if you needed to priotitize and spend your efforts
on something else.

cu andreas



From nmav at gnutls.org  Thu Jun 17 20:23:24 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 17 Jun 2010 20:23:24 +0200
Subject: GnuTLS 2.9.12 - third and final (?) release candidate for 2.10.0
In-Reply-To: <20100617180455.GC3510@downhill.g.la>
References: <87aaqtbs26.fsf@mocca.josefsson.org>
	<20100617180455.GC3510@downhill.g.la>
Message-ID: <4C1A681C.1010502@gnutls.org>

Andreas Metzler wrote:
> On 2010-06-17 Simon Josefsson <simon at josefsson.org> wrote:
>> I plan to release our new stable branch 2.10.0 next week, unless we get
>> reports about things not working.  NOW is the time to test.
> [...]
> 
> Hello,
> 
> a workaround for http://bugs.debian.org/519006 would be nice, 2.9.x
> does not build on mips(el). (See e.g.
> http://bugs.debian.org/585476)
> 
> I could understand if you needed to priotitize and spend your efforts
> on something else.

I didn't really understand what the problem is, but I got the impression
that is a toolchain issue, rather than something that can be fixed by
gnutls.

regards,
Nikos



From simon at josefsson.org  Fri Jun 18 15:14:04 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 18 Jun 2010 15:14:04 +0200
Subject: GnuTLS 2.9.12 - third and final (?) release candidate for 2.10.0
In-Reply-To: <20100617180455.GC3510@downhill.g.la> (Andreas Metzler's message
	of "Thu, 17 Jun 2010 20:04:55 +0200")
References: <87aaqtbs26.fsf@mocca.josefsson.org>
	<20100617180455.GC3510@downhill.g.la>
Message-ID: <87typ04h5v.fsf@mocca.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> On 2010-06-17 Simon Josefsson <simon at josefsson.org> wrote:
>> I plan to release our new stable branch 2.10.0 next week, unless we get
>> reports about things not working.  NOW is the time to test.
> [...]
>
> Hello,
>
> a workaround for http://bugs.debian.org/519006 would be nice, 2.9.x
> does not build on mips(el). (See e.g.
> http://bugs.debian.org/585476)

That is a toolchain bug on mips(el), and we don't know how to work
around it in GnuTLS.

I'm not sure I see why we should work around it either, the bug affects
so many debian packages now (coreutils, m4, unistring, libidn, ...) so
the proper fix is to fix the bug in binutils.

For some debian packages, I have just disabled running self-checks on
mips, since the bug is only triggered for self-tests, and nobody have
suggested a better fix.

I don't think there is anything wrong with the generated libraries.

/Simon



From ametzler at downhill.at.eu.org  Sat Jun 19 15:14:45 2010
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 19 Jun 2010 15:14:45 +0200
Subject: [trivial patch] /usefull/useful/
Message-ID: <20100619131445.GB3337@downhill.g.la>

Hej,

-----------------------------
2010-06-19  Andreas Metzler <ametzler at downhill.at.eu.org>
        * doc/cha-auth.texi, lib/ext_signature.c: Typo fix "usefull".
-----------------------------
thanks, cu andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usefull.diff
Type: text/x-diff
Size: 1086 bytes
Desc: not available
URL: </pipermail/attachments/20100619/1eed066b/attachment.diff>

From nmav at gnutls.org  Sat Jun 19 15:40:16 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 19 Jun 2010 15:40:16 +0200
Subject: [trivial patch] /usefull/useful/
In-Reply-To: <20100619131445.GB3337@downhill.g.la>
References: <20100619131445.GB3337@downhill.g.la>
Message-ID: <4C1CC8C0.2030506@gnutls.org>

Andreas Metzler wrote:
> Hej,

Applied thanks.


regards,
Nikos



From ametzler at downhill.at.eu.org  Sun Jun 20 08:47:06 2010
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 20 Jun 2010 08:47:06 +0200
Subject: GnuTLS 2.9.12 - third and final (?) release candidate for 2.10.0
In-Reply-To: <87typ04h5v.fsf@mocca.josefsson.org>
References: <87aaqtbs26.fsf@mocca.josefsson.org>
	<20100617180455.GC3510@downhill.g.la>
	<87typ04h5v.fsf@mocca.josefsson.org>
Message-ID: <20100620064706.GA3261@downhill.g.la>

On 2010-06-18 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
[...]
>> a workaround for http://bugs.debian.org/519006 would be nice, 2.9.x
>> does not build on mips(el). (See e.g.
>> http://bugs.debian.org/585476)

> That is a toolchain bug on mips(el), and we don't know how to work
> around it in GnuTLS.

> I'm not sure I see why we should work around it either, the bug affects
> so many debian packages now (coreutils, m4, unistring, libidn, ...) so

Fair enough. I have worked around the issue now by building without -g
on mips(el), which seems to have been a success:
https://buildd.debian.org/build.php?pkg=gnutls26&arch=mips&ver=2.9.12-2

> the proper fix is to fix the bug in binutils.

Afaiu the bug is actually in gcc-4.4 (4.5 is supposed to be ok).
cu andreas



From kalee at monitorapp.com  Mon Jun 21 06:23:49 2010
From: kalee at monitorapp.com (Kyung a Lee)
Date: Mon, 21 Jun 2010 13:23:49 +0900
Subject: Help
Message-ID: <004901cb10f9$8c687c30$a5397490$@com>

Hello, I have some questions about libgcrypt - gcry_pk_decrypt func.

If I call this function many times, then the useage of cpu is increased.

If call 3000 times,  it takes around 30 seconds, I wonder this func has
bugs..

(or it actually takes time when decrypt key)

I think it affacts the performance of my program, Plz help me.

Thanks?

 

******************************************

?? ? ? 

??????? / ?????                   

 

?????????

?????? ??? ?? 3? 197-17

????????? 1? 306?, 152-766

?Tel : 02-749-0799

?Fax : 02-749-0798

?Mobile : 010-2078-8137

?E-mail : kalee at monitorapp.com

******************************************

 

 

 

 

******************************************

?? ? ? 

??????? / ?????                   

 

?????????

?????? ??? ?? 3? 197-17

????????? 1? 306?, 152-766

?Tel : 02-749-0799

?Fax : 02-749-0798

?Mobile : 010-2078-8137

?E-mail : kalee at monitorapp.com

******************************************

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20100621/e65e7297/attachment.htm>

From simon at josefsson.org  Mon Jun 21 09:55:02 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 21 Jun 2010 09:55:02 +0200
Subject: GnuTLS 2.9.12 - third and final (?) release candidate for 2.10.0
In-Reply-To: <20100620064706.GA3261@downhill.g.la> (Andreas Metzler's message
	of "Sun, 20 Jun 2010 08:47:06 +0200")
References: <87aaqtbs26.fsf@mocca.josefsson.org>
	<20100617180455.GC3510@downhill.g.la>
	<87typ04h5v.fsf@mocca.josefsson.org>
	<20100620064706.GA3261@downhill.g.la>
Message-ID: <87tyowzup5.fsf@mocca.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> On 2010-06-18 Simon Josefsson <simon at josefsson.org> wrote:
>> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
> [...]
>>> a workaround for http://bugs.debian.org/519006 would be nice, 2.9.x
>>> does not build on mips(el). (See e.g.
>>> http://bugs.debian.org/585476)
>
>> That is a toolchain bug on mips(el), and we don't know how to work
>> around it in GnuTLS.
>
>> I'm not sure I see why we should work around it either, the bug affects
>> so many debian packages now (coreutils, m4, unistring, libidn, ...) so
>
> Fair enough. I have worked around the issue now by building without -g
> on mips(el), which seems to have been a success:
> https://buildd.debian.org/build.php?pkg=gnutls26&arch=mips&ver=2.9.12-2

That makes the libgnutls26-dbg package useless, which it doesn't have to
be if instead self checks are disabled.  But this only affects mips(el)
users so I don't care strongly...

>> the proper fix is to fix the bug in binutils.
>
> Afaiu the bug is actually in gcc-4.4 (4.5 is supposed to be ok).

The patch says the problem also affects x86_64, but I haven't seen any
evidence of this.  So I wonder what makes this bug only appear on
mips(el)...

/Simon



From simon at josefsson.org  Mon Jun 21 09:56:41 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 21 Jun 2010 09:56:41 +0200
Subject: Help
In-Reply-To: <004901cb10f9$8c687c30$a5397490$@com> (Kyung a. Lee's message of
	"Mon, 21 Jun 2010 13:23:49 +0900")
References: <004901cb10f9$8c687c30$a5397490$@com>
Message-ID: <87pqzkzume.fsf@mocca.josefsson.org>

"Kyung a Lee" <kalee at monitorapp.com> writes:

> Hello, I have some questions about libgcrypt - gcry_pk_decrypt func.
>
> If I call this function many times, then the useage of cpu is increased.
>
> If call 3000 times,  it takes around 30 seconds, I wonder this func has
> bugs..
>
> (or it actually takes time when decrypt key)

This isn't the libgcrypt mailing list, but the GnuTLS mailing list, but
I'll try to answer anyway: yes, public-key decryption is slow.  Run the
libgcrypt's tests/benchmark to see what kind of speed you should expect.

/Simon



From vincent.torri at gmail.com  Thu Jun 24 06:48:50 2010
From: vincent.torri at gmail.com (Vincent Torri)
Date: Thu, 24 Jun 2010 06:48:50 +0200
Subject: about documentation on the site
Message-ID: <AANLkTikDvn7k4NwXxFcexa3PqktPHgkJg-ZV9F-7u_oY@mail.gmail.com>

Hey,

In http://www.gnu.org/software/gnutls/devel.html one can see, in the
building steps, twice 'make'. Imho, 2 things are missing: the generation of
the configure script (autoreconf ?) and the launch of the configure script
itself

regards

Vincent Torri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20100624/50acd7bd/attachment.htm>

From vincent.torri at gmail.com  Thu Jun 24 06:53:50 2010
From: vincent.torri at gmail.com (Vincent Torri)
Date: Thu, 24 Jun 2010 06:53:50 +0200
Subject: slight improvement of the output during building
Message-ID: <AANLkTimF0HQyXT634CldbHo2G1HqEoKeVQI0TtC5T6Wo@mail.gmail.com>

Hey,

since automake 1.11, one can make the output less verbose. It is described
in the automake manual as 'silent rule'.

For that, simply add in configure.ac, just after AM_INIT_AUTOMAKE :

m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])

To have the original output : make V=1

regards

Vincent Torri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20100624/3cd15cd6/attachment.htm>

From vincent.torri at gmail.com  Thu Jun 24 06:55:06 2010
From: vincent.torri at gmail.com (Vincent Torri)
Date: Thu, 24 Jun 2010 06:55:06 +0200
Subject: disabling the build of tests
Message-ID: <AANLkTin8KYuo24M6jQIPh_mfJaftCctXOfyxNJEBYX78@mail.gmail.com>

Hey,

would it be possible to add an option to disable the build of the tests. I
can provide a patch if the idea is accepted

regards

Vincent Torri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20100624/5baf075a/attachment.htm>

From simon at josefsson.org  Thu Jun 24 09:25:18 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 24 Jun 2010 09:25:18 +0200
Subject: disabling the build of tests
In-Reply-To: <AANLkTin8KYuo24M6jQIPh_mfJaftCctXOfyxNJEBYX78@mail.gmail.com>
	(Vincent Torri's message of "Thu, 24 Jun 2010 06:55:06 +0200")
References: <AANLkTin8KYuo24M6jQIPh_mfJaftCctXOfyxNJEBYX78@mail.gmail.com>
Message-ID: <87eifwdh9d.fsf@mocca.josefsson.org>

Vincent Torri <vincent.torri at gmail.com> writes:

> Hey,
>
> would it be possible to add an option to disable the build of the tests. I
> can provide a patch if the idea is accepted

The tests aren't built if you don't run 'make check', are they?

/Simon



From simon at josefsson.org  Thu Jun 24 09:26:18 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 24 Jun 2010 09:26:18 +0200
Subject: about documentation on the site
In-Reply-To: <AANLkTikDvn7k4NwXxFcexa3PqktPHgkJg-ZV9F-7u_oY@mail.gmail.com>
	(Vincent Torri's message of "Thu, 24 Jun 2010 06:48:50 +0200")
References: <AANLkTikDvn7k4NwXxFcexa3PqktPHgkJg-ZV9F-7u_oY@mail.gmail.com>
Message-ID: <87aaqkdh7p.fsf@mocca.josefsson.org>

Vincent Torri <vincent.torri at gmail.com> writes:

> Hey,
>
> In http://www.gnu.org/software/gnutls/devel.html one can see, in the
> building steps, twice 'make'. Imho, 2 things are missing: the generation of
> the configure script (autoreconf ?) and the launch of the configure script
> itself

The configure script is generated, and launched, by the first call to
'make'.  Try the commands and you will see..

/Simon



From simon at josefsson.org  Thu Jun 24 09:29:06 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 24 Jun 2010 09:29:06 +0200
Subject: slight improvement of the output during building
In-Reply-To: <AANLkTimF0HQyXT634CldbHo2G1HqEoKeVQI0TtC5T6Wo@mail.gmail.com>
	(Vincent Torri's message of "Thu, 24 Jun 2010 06:53:50 +0200")
References: <AANLkTimF0HQyXT634CldbHo2G1HqEoKeVQI0TtC5T6Wo@mail.gmail.com>
Message-ID: <876318dh31.fsf@mocca.josefsson.org>

Vincent Torri <vincent.torri at gmail.com> writes:

> Hey,
>
> since automake 1.11, one can make the output less verbose. It is described
> in the automake manual as 'silent rule'.
>
> For that, simply add in configure.ac, just after AM_INIT_AUTOMAKE :
>
> m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
>
> To have the original output : make V=1

Thanks, I've applied this change on git master.

/Simon



From vincent.torri at gmail.com  Thu Jun 24 09:40:50 2010
From: vincent.torri at gmail.com (Vincent Torri)
Date: Thu, 24 Jun 2010 09:40:50 +0200
Subject: about documentation on the site
In-Reply-To: <87aaqkdh7p.fsf@mocca.josefsson.org>
References: <AANLkTikDvn7k4NwXxFcexa3PqktPHgkJg-ZV9F-7u_oY@mail.gmail.com>
	<87aaqkdh7p.fsf@mocca.josefsson.org>
Message-ID: <AANLkTilVCpnolSmy5McAPgp60WKG2h3mcNGKC6mXPXEb@mail.gmail.com>

On Thu, Jun 24, 2010 at 9:26 AM, Simon Josefsson <simon at josefsson.org>wrote:

> Vincent Torri <vincent.torri at gmail.com> writes:
>
> > Hey,
> >
> > In http://www.gnu.org/software/gnutls/devel.html one can see, in the
> > building steps, twice 'make'. Imho, 2 things are missing: the generation
> of
> > the configure script (autoreconf ?) and the launch of the configure
> script
> > itself
>
> The configure script is generated, and launched, by the first call to
> 'make'.  Try the commands and you will see..


i haven't tried, actually. There is no Makefile. Does it mean that
GNUMakefile is used by default, as well as Makefile (if GNU make is used).
If so, it means that it is not portable.

Vincent Torri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20100624/1d1e1ee9/attachment.htm>

From simon at josefsson.org  Thu Jun 24 09:51:36 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 24 Jun 2010 09:51:36 +0200
Subject: about documentation on the site
In-Reply-To: <AANLkTilVCpnolSmy5McAPgp60WKG2h3mcNGKC6mXPXEb@mail.gmail.com>
	(Vincent Torri's message of "Thu, 24 Jun 2010 09:40:50 +0200")
References: <AANLkTikDvn7k4NwXxFcexa3PqktPHgkJg-ZV9F-7u_oY@mail.gmail.com>
	<87aaqkdh7p.fsf@mocca.josefsson.org>
	<AANLkTilVCpnolSmy5McAPgp60WKG2h3mcNGKC6mXPXEb@mail.gmail.com>
Message-ID: <87fx0cc1h3.fsf@mocca.josefsson.org>

Vincent Torri <vincent.torri at gmail.com> writes:

> On Thu, Jun 24, 2010 at 9:26 AM, Simon Josefsson <simon at josefsson.org>wrote:
>
>> Vincent Torri <vincent.torri at gmail.com> writes:
>>
>> > Hey,
>> >
>> > In http://www.gnu.org/software/gnutls/devel.html one can see, in the
>> > building steps, twice 'make'. Imho, 2 things are missing: the generation
>> of
>> > the configure script (autoreconf ?) and the launch of the configure
>> script
>> > itself
>>
>> The configure script is generated, and launched, by the first call to
>> 'make'.  Try the commands and you will see..
>
>
> i haven't tried, actually. There is no Makefile. Does it mean that
> GNUMakefile is used by default, as well as Makefile (if GNU make is used).
> If so, it means that it is not portable.

Yes, a GNUmakefile is used.  And yes, we require that people building
GnuTLS from git sources uses GNU make.  The list of required tools for
developers are explained in README-alpha, see below.

Note that users building from *.tar.bz2 do not need to have all these
tools installed, and do not need GNU make.  So I'd claim that GnuTLS is
portable.

- Make <http://www.gnu.org/software/make/>
- Automake <http://www.gnu.org/software/automake/>
- Autoconf <http://www.gnu.org/software/autoconf/>
- Libtool <http://www.gnu.org/software/libtool/>
- Gettext <http://www.gnu.org/software/gettext/>
- Texinfo <http://www.gnu.org/software/texinfo/>
- help2man <http://www.gnu.org/software/help2man/>
- Tar <http://www.gnu.org/software/tar/>
- Gzip <http://www.gnu.org/software/gzip/>
- Texlive & epsf <http://www.tug.org/texlive/> (for PDF manual)
- CVS <http://www.gnu.org/software/cvs/> (for gettext autopoint)
- GTK-DOC <http://www.gtk.org/gtk-doc/> (for API manual)
- Git <http://git.or.cz/>
- Perl <http://www.cpan.org/>
- Valgrind <http://valgrind.org/> (optional)
- libgcrypt <http://www.gnupg.org/>
- Guile <http://www.gnu.org/software/guile/>
- Gaa <http://gaa.sf.net> (optional)
- libtasn1 <http://josefsson.org/libtasn1/> (optional)
- datefudge <packages.debian.org/datefudge> (optional)

/Simon



From vincent.torri at gmail.com  Thu Jun 24 11:38:31 2010
From: vincent.torri at gmail.com (Vincent Torri)
Date: Thu, 24 Jun 2010 11:38:31 +0200
Subject: disabling the build of tests
In-Reply-To: <87eifwdh9d.fsf@mocca.josefsson.org>
References: <AANLkTin8KYuo24M6jQIPh_mfJaftCctXOfyxNJEBYX78@mail.gmail.com>
	<87eifwdh9d.fsf@mocca.josefsson.org>
Message-ID: <AANLkTilnnFXfgGgaPhqn3GxB6CzpMHP3C_CtmLzWWdF4@mail.gmail.com>

On Thu, Jun 24, 2010 at 9:25 AM, Simon Josefsson <simon at josefsson.org>wrote:

> Vincent Torri <vincent.torri at gmail.com> writes:
>
> > Hey,
> >
> > would it be possible to add an option to disable the build of the tests.
> I
> > can provide a patch if the idea is accepted
>
> The tests aren't built if you don't run 'make check', are they?
>

I 'll verify that this evening

Vincent Torri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20100624/72312cae/attachment.htm>

From vincent.torri at gmail.com  Thu Jun 24 19:39:48 2010
From: vincent.torri at gmail.com (Vincent Torri)
Date: Thu, 24 Jun 2010 19:39:48 +0200
Subject: about documentation on the site
In-Reply-To: <87fx0cc1h3.fsf@mocca.josefsson.org>
References: <AANLkTikDvn7k4NwXxFcexa3PqktPHgkJg-ZV9F-7u_oY@mail.gmail.com>
	<87aaqkdh7p.fsf@mocca.josefsson.org>
	<AANLkTilVCpnolSmy5McAPgp60WKG2h3mcNGKC6mXPXEb@mail.gmail.com>
	<87fx0cc1h3.fsf@mocca.josefsson.org>
Message-ID: <AANLkTin8HToMeG7L17h7NP-BB0G17tsIhu8jAgyasJ1S@mail.gmail.com>

On Thu, Jun 24, 2010 at 9:51 AM, Simon Josefsson <simon at josefsson.org>wrote:

> Vincent Torri <vincent.torri at gmail.com> writes:
>
> > On Thu, Jun 24, 2010 at 9:26 AM, Simon Josefsson <simon at josefsson.org
> >wrote:
> >
> >> Vincent Torri <vincent.torri at gmail.com> writes:
> >>
> >> > Hey,
> >> >
> >> > In http://www.gnu.org/software/gnutls/devel.html one can see, in the
> >> > building steps, twice 'make'. Imho, 2 things are missing: the
> generation
> >> of
> >> > the configure script (autoreconf ?) and the launch of the configure
> >> script
> >> > itself
> >>
> >> The configure script is generated, and launched, by the first call to
> >> 'make'.  Try the commands and you will see..
> >
> >
> > i haven't tried, actually. There is no Makefile. Does it mean that
> > GNUMakefile is used by default, as well as Makefile (if GNU make is
> used).
> > If so, it means that it is not portable.
>
> Yes, a GNUmakefile is used.  And yes, we require that people building
> GnuTLS from git sources uses GNU make.  The list of required tools for
> developers are explained in README-alpha, see below.
>
> Note that users building from *.tar.bz2 do not need to have all these
> tools installed, and do not need GNU make.  So I'd claim that GnuTLS is
> portable.
>
> - Make <http://www.gnu.org/software/make/>
> - Automake <http://www.gnu.org/software/automake/>
> - Autoconf <http://www.gnu.org/software/autoconf/>
> - Libtool <http://www.gnu.org/software/libtool/>
> - Gettext <http://www.gnu.org/software/gettext/>
> - Texinfo <http://www.gnu.org/software/texinfo/>
> - help2man <http://www.gnu.org/software/help2man/>
> - Tar <http://www.gnu.org/software/tar/>
> - Gzip <http://www.gnu.org/software/gzip/>
> - Texlive & epsf <http://www.tug.org/texlive/> (for PDF manual)
> - CVS <http://www.gnu.org/software/cvs/> (for gettext autopoint)
> - GTK-DOC <http://www.gtk.org/gtk-doc/> (for API manual)
> - Git <http://git.or.cz/>
> - Perl <http://www.cpan.org/>
> - Valgrind <http://valgrind.org/> (optional)
> - libgcrypt <http://www.gnupg.org/>
> - Guile <http://www.gnu.org/software/guile/>
> - Gaa <http://gaa.sf.net> (optional)
> - libtasn1 <http://josefsson.org/libtasn1/> (optional)
> - datefudge <packages.debian.org/datefudge> (optional)
>

ok. Thank you

Vincent Torri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20100624/d7cb32cc/attachment.htm>

From simon at josefsson.org  Fri Jun 25 09:57:04 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 25 Jun 2010 09:57:04 +0200
Subject: GnuTLS 2.10.0 released
Message-ID: <8763171r5b.fsf@mocca.josefsson.org>

We are proud to announce a new stable GnuTLS release: Version 2.10.0.

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
==========

Version 2.10.0 is the first stable release on the 2.10.x branch and is
the result of over 12 months of work on the experimental 2.9.x branch.
The GnuTLS 2.10.x branch replaces the GnuTLS 2.8.x branch as the
supported stable branch, although we will continue to support GnuTLS
2.8.x for some time.

** libgnutls: Added Steve Dispensa's patch for safe renegotiation (RFC 5746)
Solves the issue discussed in:
<http://www.ietf.org/mail-archive/web/tls/current/msg03928.html> and
<http://www.ietf.org/mail-archive/web/tls/current/msg03948.html>.
Note that to allow connecting to unpatched servers the full protection
is only enabled if the priority string %SAFE_RENEGOTIATION is
specified. You can check whether protection is in place by querying
gnutls_safe_renegotiation_status().  New error codes
GNUTLS_E_SAFE_RENEGOTIATION_FAILED and
GNUTLS_E_UNSAFE_RENEGOTIATION_DENIED added.

** libgnutls: Time verification extended to trusted certificate list.
Unless new constant GNUTLS_VERIFY_DISABLE_TRUSTED_TIME_CHECKS flag is
specified.

** certtool: Display postalCode and Name X.509 DN attributes correctly.
Based on patch by Pavan Konjarla.  Adds new constant
GNUTLS_OID_X520_POSTALCODE and GNUTLS_OID_X520_NAME.

** 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: Added cryptodev support (/dev/crypto).
Tested with http://home.gna.org/cryptodev-linux/.  Added
benchmark utility for AES.  Adds new error codes
GNUTLS_E_CRYPTODEV_IOCTL_ERROR and GNUTLS_E_CRYPTODEV_DEVICE_ERROR.

** libgnutls: Exported API to access encryption and hash algorithms.
The new API functions are gnutls_cipher_decrypt, gnutls_cipher_deinit,
gnutls_cipher_encrypt, gnutls_cipher_get_block_size,
gnutls_cipher_init, gnutls_hash, gnutls_hash_deinit, gnutls_hash_fast,
gnutls_hash_get_len, gnutls_hash_init, gnutls_hash_output,
gnutls_hmac, gnutls_hmac_deinit, gnutls_hmac_fast,
gnutls_hmac_get_len, gnutls_hmac_init, gnutls_hmac_output.  New API
constants are GNUTLS_MAC_SHA224 and GNUTLS_DIG_SHA224.

** libgnutls: Added gnutls_certificate_set_verify_function() to allow
verification of certificate upon receipt rather than waiting until the
end of the handshake.

** libgnutls: Don't send alerts during handshake.
Instead new error code GNUTLS_E_UNKNOWN_SRP_USERNAME is added.

** certtool: Corrected two issues that affected certificate request generation.
(1) Null padding is added on integers (found thanks to Wilankar Trupti),
(2) In optional SignatureAlgorithm parameters field for DSA keys the DSA
parameters were added. Those were rejected by Verisign. Gnutls no longer adds 
those parameters there since other implementations don't do either and having 
them does not seem to offer anything (anyway you need the signer's certificate
to verify thus public key will be available). Found thanks to Boyan Kasarov.
This however has the side-effect that public key IDs shown by certtool are
now different than previous gnutls releases.
(3) the option --pgp-certificate-info will verify self signatures

** certtool: Allow exporting of Certificate requests on DER format.

** certtool: New option --no-crq-extensions to avoid extensions in CSRs.

** gnutls-cli: Handle reading binary data from server.
Reported by and tiny patch from Vitaly Mayatskikh
<v.mayatskih at gmail.com> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/4096>.

** minitasn1: Upgraded to libtasn1 version 2.6.

** doc: The GTK-DOC manual is significantly improved.

** doc: a PDF version of the API reference manual (GTK-DOC) is now built.

** doc: Terms 'GNUTLS' and 'GNU TLS' were changed to 'GnuTLS' for consistency.

** 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
<https://savannah.gnu.org/support/?107029>.

** libgnutls: Fix for memory leaks on interrupted handshake.
Reported by Tang Tong.

** libgnutls: Addition of support for TLS 1.2 signature algorithms
** extension and certificate verify field.
This requires changes for TLS 1.2 servers and clients that use
callbacks for certificate retrieval.  They are now required to check
with gnutls_sign_algorithm_get_requested() whether the certificate
they send complies with the peer's preferences in signature
algorithms.

** libgnutls: In server side when resuming a session do not overwrite the 
** initial session data with the resumed session data.

** libgnutls: Added support for AES-128, AES-192 and AES-256 in PKCS #8
** encryption.
This affects also PKCS #12 encoded files.  This adds the following new
enums: GNUTLS_CIPHER_AES_192_CBC, GNUTLS_PKCS_USE_PBES2_AES_128,
GNUTLS_PKCS_USE_PBES2_AES_192, GNUTLS_PKCS_USE_PBES2_AES_256.

** libgnutls: Fix PKCS#12 encoding.
The error you would get was "The OID is not supported.".  Problem
introduced for the v2.8.x branch in 2.7.6.

** certtool: Added the --pkcs-cipher option.
To explicitely specify the encryption algorithm to use.

** tests: Added "pkcs12_encode" self-test to check PKCS#12 functions.

** tests: Fix time bomb in chainverify self-test.
Reported by Andreas Metzler <ametzler at downhill.at.eu.org> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3925>.

** tests: Fix expired cert in chainverify self-test.

** libgnutls: TLS 1.2 server mode fixes.
Now interoperates against Opera.  Contributed by Daiki Ueno.

** libgnutlsxx: Fix link problems.
Tiny patch from Boyan Kasarov <bkasarov at gmail.com>.

** guile: Compatibility with guile 2.x.
By Ludovic Courtes <ludovic.courtes at laas.fr>.

** libgnutls: Enable Camellia ciphers by default.

** libgnutls: Add new functions to extract X.509 Issuer Alternative Names.
The new functions are gnutls_x509_crt_get_issuer_alt_name2,
gnutls_x509_crt_get_issuer_alt_name, and
gnutls_x509_crt_get_issuer_alt_othername_oid.  Contributed by Brad
Hards <bradh at frogmouth.net>.

** libgnutls: Client-side TLS 1.2 and SHA-256 ciphersuites now works.
The new supported ciphersuites are AES-128/256 in CBC mode with
ANON-DH/RSA/DHE-DSS/DHE-RSA.  Contributed by Daiki Ueno.  Further,
SHA-256 is now the preferred default MAC (however it is only used with
TLS 1.2).

** libgnutls: Make OpenPGP hostname checking work again.
The patch to resolve the X.509 CN/SAN issue accidentally broken
OpenPGP hostname comparison.

** libgnutls: When printing X.509 certificates, handle XMPP SANs better.
Reported by Howard Chu <hyc at symas.com> in
<https://savannah.gnu.org/support/?106975>.

** Fix use of deprecated types internally.
Use of deprecated types in GnuTLS from now on will lead to a compile
error, to prevent this from happening again.

** libgnutls: Support for TLS tickets was contributed by Daiki Ueno.
The new APIs are gnutls_session_ticket_enable_client,
gnutls_session_ticket_enable_server, and
gnutls_session_ticket_key_generate.

** gnutls-cli, gnutls-serv: New parameter --noticket to disable TLS tickets.

** libgnutls: Fix problem with NUL bytes in X.509 CN and SAN fields.
By using a NUL byte in CN/SAN fields, it was possible to fool GnuTLS
into 1) not printing the entire CN/SAN field value when printing a
certificate and 2) cause incorrect positive matches when matching a
hostname against a certificate.  Some CAs apparently have poor
checking of CN/SAN values and issue these (arguable invalid)
certificates.  Combined, this can be used by attackers to become a
MITM on server-authenticated TLS sessions.  The problem is mitigated
since attackers needs to get one certificate per site they want to
attack, and the attacker reveals his tracks by applying for a
certificate at the CA.  It does not apply to client authenticated TLS
sessions.  Research presented independently by Dan Kaminsky and Moxie
Marlinspike at BlackHat09.  Thanks to Tomas Hoger <thoger at redhat.com>
for providing one part of the patch.  [GNUTLS-SA-2009-4] [CVE-2009-2730].

** libgnutls: Fix rare failure in gnutls_x509_crt_import.
The function may fail incorrectly when an earlier certificate was
imported to the same gnutls_x509_crt_t structure.

** libgnutls: Fix return value of gnutls_certificate_client_get_request_status.
Before it always returned false.  Reported by Peter Hendrickson
<pdh at wiredyne.com> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3668>.

** libgnutls: Fix off-by-one size computation error in unknown DN printing.
The error resulted in truncated strings when printing unknown OIDs in
X.509 certificate DNs.  Reported by Tim Kosse
<tim.kosse at filezilla-project.org> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3651>.

** libgnutls: Fix PKCS#12 decryption from password.
The encryption key derived from the password was incorrect for (on
average) 1 in every 128 input for random inputs.  Reported by "Kukosa,
Tomas" <tomas.kukosa at siemens-enterprise.com> in
<http://permalink.gmane.org/gmane.network.gnutls.general/1663>.

** libgnutls: Return correct bit lengths of some MPIs.
gnutls_dh_get_prime_bits, gnutls_rsa_export_get_modulus_bits, and
gnutls_dh_get_peers_public_bits.  Before the reported value was
overestimated.  Reported by Peter Hendrickson <pdh at wiredyne.com> in
<http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3607>.

** libgnutls: Avoid internal error when invoked after GNUTLS_E_AGAIN.
Report and patch by Tim Kosse <tim.kosse at filezilla-project.org> in
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3671>
and
<http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3670>.

** libgnutls: Relax checking of required libtasn1/libgcrypt versions.
Before we required that the runtime library used the same (or more
recent) libgcrypt/libtasn1 as it was compiled with.  Now we just check
that the runtime usage is above the minimum required.  Reported by
Marco d'Itri <md at linux.it> via Andreas Metzler
<ametzler at downhill.at.eu.org> in <http://bugs.debian.org/540449>.

** tests: Added new self-test pkcs12_s2k_pem to detect MPI bit length error.

** tests: Improved test vectors in self-test pkcs12_s2k.

** tests: Added new self-test dn2 to detect off-by-one size error.

** tests: Fix failure in "chainverify" because a certificate have expired.

** libgnutls: Fix crash in gnutls_global_init after earlier init/deinit cycle.
Forwarded by Martin von Gagern <Martin.vGagern at gmx.net> from
<http://bugs.gentoo.org/272388>.

** Reduce stack usage for some CRQ functions.

** Doc fixes for CRQ functions.

TLS Renegotiation Attack
========================

Some application protocols and implementations uses the TLS
renegotiation feature in a manner that enables attackers to insert
content of his choice in the beginning of a TLS session.

One easy to understand vulnerability is HTTPS when servers request
client certificates optionally for certain parts of a web site.  The
attack works by having the attacker simulate a client and connect to a
server, with server-only authentication, and send some data intended to
cause harm.  When the proper client attempts to contact the server, the
attacker hijacks that connection and uses the TLS renegotiation feature
with the server and splices in the client connection to the already
established connection between the attacker and server.  The attacker
will not be able to read the data exchanged between the client and the
server.  However, the server will (incorrectly) assume that the data
sent by the attacker was sent by the now authenticated client.  The
result is a prefix plain-text injection attack.

The above is just one example.  Other vulnerabilities exists that do
not rely on the TLS renegotiation to change the client's authenticated
status (either TLS or application layer).

While fixing these application protocols and implementations would be
one natural reaction, an extension to TLS has been designed that
cryptographically binds together any renegotiated handshakes with the
initial negotiation.  When the extension is used, the attack is
detected and the session can be terminated.  The extension is specified
in RFC5746.

GnuTLS supports the safe renegotiation extension.  The default behavior
is as follows.  Clients will attempt to negotiate the safe
renegotiation extension when talking to servers.  Servers will accept
the extension when presented by clients.  Clients and servers will
permit an initial handshake to complete even when the other side does
not support the safe renegotiation extension.  Clients and servers will
refuse renegotiation attempts when the extension has not been
negotiated.

Note that permitting clients to connect to servers even when the safe
renegotiation extension is not negotiated open up for some attacks.
Changing this default behaviour would prevent interoperability against
the majority of deployed servers out there.  We will reconsider this
default behaviour in the future when more servers have been upgraded.
Note that it is easy to configure clients to always require the safe
renegotiation extension from servers (see below on the
`%SAFE_RENEGOTIATION' priority string).

To modify the default behaviour, we have introduced some new priority
strings.  The priority strings can be used by applications (see
gnutls_priority_set) and end users (e.g., `--priority' parameter to
`gnutls-cli' and `gnutls-serv').

The `%UNSAFE_RENEGOTIATION' priority string permits (re-)handshakes
even when the safe renegotiation extension was not negotiated.  The
default behavior is `%PARTIAL_RENEGOTIATION' that will prevent
renegotiation with clients and servers not supporting the extension.
This is secure for servers but leaves clients vulnerable to some
attacks, but this is a tradeoff between security and compatibility with
old servers.  The `%SAFE_RENEGOTIATION' priority string makes clients
and servers require the extension for every handshake.  The latter is
the most secure option for clients, at the cost of not being able to
connect to legacy servers.  Servers will also deny clients that do not
support the extension from connecting.

It is possible to disable use of the extension completely, in both
clients and servers, by using the `%DISABLE_SAFE_RENEGOTIATION'
priority string however we strongly recommend you to only do this for
debugging and test purposes.

The default values if the flags above are not specified are:
`Server:'
     %PARTIAL_RENEGOTIATION

`Client:'
     %PARTIAL_RENEGOTIATION

For applications we have introduced a new API related to safe
renegotiation.  The gnutls_safe_renegotiation_status function is used
to check if the extension has been negotiated on a session, and can be
used both by clients and servers.

Call to application authors
===========================

Please use the priority string interface, and make it possible for
users to supply a priority string!

Several parts of GnuTLS, including the new safe renegotiation
behaviour, can be configured through priority strings.  However, if
the application do not publish this interface to users, it will not be
possible to configure GnuTLS the way a user wants.

The new defaults for GnuTLS with regard to the safe renegotiation bug
is to be insecure by default.  This is something we reluctantly and
after carefuly consideration decided to do, for interoperability
reasons.  We'd like to close this security gap as soon as possible,
hopefully even for the GnuTLS 2.12.x branch.

For this transition to be as smooth as possible, users of GnuTLS
applications needs to be able to provide a priority string when a TLS
session is initialized.  Preferrably it should be possible to do on a
domain name or IP basis, to only modify the defaults for a particular
server and not generally.

Once the GnuTLS defaults have changed to be secure by default, users
may want to be able to provide a %PARTIAL_RENEGOTIATION or even an
%UNSAFE_RENEGOTIATION priority string, to be able to talk with certain
clients or servers.  This will not be possible unless you, as
application author, export this ability to your users.

Technically, you would replace a call like this:

   gnutls_set_default_priority (session)

with a call like this:

   gnutls_priority_set_direct (session, string, NULL);

where 'string' is a character string read from your configuration
files, and the default should be 'NORMAL'.  It is fine for string to
be NULL if you didn't read any configuration from the user, then
'NORMAL' will be used.

For more information see:

http://www.gnu.org/software/gnutls/manual/html_node/Core-functions.html#gnutls_005fpriority_005finit

API/ABI changes in GnuTLS 2.10
==============================

No offically supported interfaces have been modified or removed.  The
library should be completely backwards compatible on both the source
and binary level.

The following symbols have been added to the library:

gnutls_certificate_set_verify_function: ADDED.
gnutls_cipher_decrypt: ADDED.
gnutls_cipher_deinit: ADDED.
gnutls_cipher_encrypt: ADDED.
gnutls_cipher_get_block_size: ADDED.
gnutls_cipher_init: ADDED.
gnutls_hash: ADDED.
gnutls_hash_deinit: ADDED.
gnutls_hash_fast: ADDED.
gnutls_hash_get_len: ADDED.
gnutls_hash_init: ADDED.
gnutls_hash_output: ADDED.
gnutls_hmac: ADDED.
gnutls_hmac_deinit: ADDED.
gnutls_hmac_fast: ADDED.
gnutls_hmac_get_len: ADDED.
gnutls_hmac_init: ADDED.
gnutls_hmac_output: ADDED.
gnutls_safe_renegotiation_status: ADDED.
gnutls_sign_algorithm_get_requested: ADDED.

gnutls_x509_crt_get_issuer_alt_name2: ADDED.
gnutls_x509_crt_get_issuer_alt_name: ADDED.
gnutls_x509_crt_get_issuer_alt_othername_oid: ADDED.

gnutls_session_ticket_key_generate: ADDED.
gnutls_session_ticket_enable_client: ADDED.
gnutls_session_ticket_enable_server: ADDED.

In addition to the functions above, the following non-function
definitions have been added to the header files:

GNUTLS_DIG_SHA224: ADDED.
GNUTLS_E_CRYPTODEV_DEVICE_ERROR: ADDED.
GNUTLS_E_CRYPTODEV_IOCTL_ERROR: ADDED.
GNUTLS_E_SAFE_RENEGOTIATION_FAILED: ADDED.
GNUTLS_E_UNKNOWN_SRP_USERNAME: ADDED.
GNUTLS_E_UNSAFE_RENEGOTIATION_DENIED: ADDED.
GNUTLS_MAC_SHA224: ADDED.
GNUTLS_OID_X520_NAME: ADDED.
GNUTLS_OID_X520_POSTALCODE: ADDED.
GNUTLS_VERIFY_DISABLE_TRUSTED_TIME_CHECKS: ADDED.
GNUTLS_VERSION_MAX: ADDED.

GNUTLS_CIPHER_AES_192_CBC: ADDED to gnutls/gnutls.h.
GNUTLS_PKCS_USE_PBES2_AES_128: ADDED to gnutls/x509.h.
GNUTLS_PKCS_USE_PBES2_AES_192: ADDED to gnutls/x509.h.
GNUTLS_PKCS_USE_PBES2_AES_256: ADDED to gnutls/x509.h.
GNUTLS_BAG_SECRET: ADDED to gnutls/pkcs12.h.
GNUTLS_DIG_UNKNOWN: ADDED to gnutls/gnutls.h.

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 (7.2MB):

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

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.10.0.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.10.0.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.10.0.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 <jas at extundo.com>
uid                  Simon Josefsson <simon at josefsson.org>
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:

16c94a1262f8ea3c4dd34eec495bd57203bbcd3a  gnutls-2.10.0.tar.bz2

f97d09916dc87315a245991ce005f658915ca3770f4c48006d28c358  gnutls-2.10.0.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:

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

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
contains libgpg-error v1.8, libgcrypt v1.4.5, libtasn1 v2.7, and
GnuTLS v2.10.0.

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

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

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

5fb951d9819f45fc53ff368c87aea61391c782f1  gnutls-2.10.0.exe

ad39fdbdff193c622e72eaf837443d882f7b3876a7c1a911123339cb  gnutls-2.10.0.exe

A ZIP archive containing the Windows binaries:
  http://josefsson.org/gnutls4win/gnutls-2.10.0.zip (5.5MB)
  http://josefsson.org/gnutls4win/gnutls-2.10.0.zip.sig

A Debian mingw32 package is also available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.7.10-1_all.deb (5.0MB)

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

7ffabf34274cfc73c84550aae7efe650df10f77e  gnutls-2.10.0.zip

a657b3c5a07964a46f214bed5d72f731d85ef5829072d15e3c817fca  gnutls-2.10.0.zip

6fd7c6264237f76ba31304d16d2d72a428126267  mingw32-gnutls_2.10.0-1_all.deb

944f8fa4db48efdffd0e03630c86ca275925d5f295fd99614f58ddfd  mingw32-gnutls_2.10.0-1_all.deb

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

The GnuTLS library messages have been translated into Czech, Dutch,
French, German, Italian, Malay, Polish, Simplified Chinese, 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

Glad midsommar,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 420 bytes
Desc: not available
URL: </pipermail/attachments/20100625/89736b47/attachment.pgp>

From nmav at gnutls.org  Sat Jun 26 10:04:02 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 26 Jun 2010 10:04:02 +0200
Subject: making gnutls depended to pthread
Message-ID: <4C25B472.5010509@gnutls.org>

Hello,
 I've been thinking it for quite some time but given the bug report:
https://savannah.gnu.org/support/?107409 , I think it might be relevant.
GnuTLS due to its use of random numbers will always need a global pool
to be accessed, and thus locking is mandatory. How about making a new
gnutls_global_init2() that accept flags such as USE_SYSTEM_LOCKS (that
would be pthread for linux), by default? This way gnutls will initialize
all libraries that it is depended on using the default threads for each
system.

regards,
Nikos



From vincent.torri at gmail.com  Sat Jun 26 10:36:29 2010
From: vincent.torri at gmail.com (Vincent Torri)
Date: Sat, 26 Jun 2010 10:36:29 +0200
Subject: make compilation faster on Windows
Message-ID: <AANLkTinj3OjrylO7iCSheZoG8NUHJ1QWqQ92fbAJuHqL@mail.gmail.com>

Hey,

by default, the header file windows.h includes a *lot* os other header
files, which are almost always useless, except in some cases of course. It
improves the compilation speed, especially with MSYS/MinGW.

There is a way to reduce the number of header files included by windows.h:

#define WIN32_LEAN_AND_MEAN
# include <windows.h>
#undef WIN32_LEAN_AND_MEAN

You can look at windows.h to see what the macro WIN32_LEAN_AND_MEAN disable.

As far as I can see, 2 files are using windows.h in gnutls/src: crypt.c and
psk.c

Maybe it is worth adding this macro in those files

regards

Vincent Torri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20100626/9c1ed7d4/attachment.htm>

From danw at gnome.org  Sun Jun 27 16:41:16 2010
From: danw at gnome.org (Dan Winship)
Date: Sun, 27 Jun 2010 10:41:16 -0400
Subject: GnuTLS versions 2.9.7 and later breaks libsoup (epiphany)
In-Reply-To: <87bpbjs6u0.fsf@mocca.josefsson.org>
References: <20100608175952.GB4525@downhill.g.la>	<4C0EB90F.2080000@gnutls.org>
	<20100609174118.GB3862@downhill.g.la>
	<87bpbjs6u0.fsf@mocca.josefsson.org>
Message-ID: <4C27630C.5020401@gnome.org>

On 01/-10/-28163 02:59 PM, Simon Josefsson wrote:
>> Shouldn't GnuTLS fall back to the supported protocol (SSL 3.0) in that
>> case instead of getting stuck?
> 
> I think there is a bug in epiphany (or libsoup) here that cause it to
> send the same request over and over again

Yes, that was already fixed in libsoup; Debian must not have the latest
version.

> What it could do is to try the request with default settings (i.e.,
> NORMAL, which makes it support latest protocol improvements) but if that
> fails with an error message that indicate that re-trying without TLS 1.x
> will help, it should re-try with lower TLS protocol versions.

That's the eventual plan, but it's complicated, since the retrying has
to happen at a higher level of the stack, since there may be non-TLS
stuff that has to happen before you get to the new handshake. (Eg, if
you're connecting to the bad site via a proxy, you need to send at least
a CONNECT first.)

> A better solution is to attempt the NORMAL setting first, and if it
> fails, also attempt to negotiate using SSL3+TLS1 only.  If that fails,
> stop retrying.

As someone else noted, PayPal's server is too broken for that. My plan
was to try NORMAL first, and then fall back to SSL3-only; otherwise
there are too many variables for different ways servers could be broken
(maybe they support TLS 1.0 without extensions, but fail if you try to
use the server name extension, etc).

-- Dan



From ametzler at downhill.at.eu.org  Sun Jun 27 17:59:25 2010
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 27 Jun 2010 17:59:25 +0200
Subject: GnuTLS versions 2.9.7 and later breaks libsoup (epiphany)
In-Reply-To: <4C0FD958.9060105@gnutls.org>
References: <20100608175952.GB4525@downhill.g.la> <4C0EB90F.2080000@gnutls.org>
	<20100609174118.GB3862@downhill.g.la> <4C0FD958.9060105@gnutls.org>
Message-ID: <20100627155925.GA3328@downhill.g.la>

On 2010-06-09 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> Andreas Metzler wrote:
[...]
> > The respective code seems to be in libsoup
> > libsoup2.4-2.30.1/libsoup/soup-gnutls.c
> > and the explaining comment points to 
> > http://bugzilla.gnome.org/show_bug.cgi?id=581342 as reason. Apparently
> > epiphany experienced breakage with SSL 3.0 only servers
> > (www.paypal.com).
> > 
> > While changing the respective initialisation from
> > 
> > gnutls_priority_set_direct (session, "NORMAL:!VERS-TLS1.1:!VERS-TLS1.0", NULL)
> > to
> > gnutls_priority_set_direct (session, "NORMAL", NULL)

> Then the solution should be:
> NORMAL:!VERS-TLS1.1:!VERS-TLS1.2:!VERS-TLS1.0
[...]

I somehow failed to read this message successfully tried
NORMAL:!VERS-TLS1.1:!VERS-TLS1.0:!VERS-TLS1.2. - I guess the ordering
does not make difference.
cu andreas



From nmav at gnutls.org  Sun Jun 27 18:03:35 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 27 Jun 2010 18:03:35 +0200
Subject: GnuTLS versions 2.9.7 and later breaks libsoup (epiphany)
In-Reply-To: <4C27630C.5020401@gnome.org>
References: <20100608175952.GB4525@downhill.g.la>	<4C0EB90F.2080000@gnutls.org>	<20100609174118.GB3862@downhill.g.la>	<87bpbjs6u0.fsf@mocca.josefsson.org>
	<4C27630C.5020401@gnome.org>
Message-ID: <4C277657.8050005@gnutls.org>

Dan Winship wrote:

>> A better solution is to attempt the NORMAL setting first, and if it
>> fails, also attempt to negotiate using SSL3+TLS1 only.  If that fails,
>> stop retrying.
> 
> As someone else noted, PayPal's server is too broken for that. My plan
> was to try NORMAL first, and then fall back to SSL3-only; otherwise
> there are too many variables for different ways servers could be broken
> (maybe they support TLS 1.0 without extensions, but fail if you try to
> use the server name extension, etc).

At least for paypal using the %COMPAT flag does the job.

regards,
Nikos



From ametzler at downhill.at.eu.org  Sun Jun 27 18:02:01 2010
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 27 Jun 2010 18:02:01 +0200
Subject: GnuTLS versions 2.9.7 and later breaks libsoup (epiphany)
In-Reply-To: <4C27630C.5020401@gnome.org>
References: <20100608175952.GB4525@downhill.g.la> <4C0EB90F.2080000@gnutls.org>
	<20100609174118.GB3862@downhill.g.la>
	<87bpbjs6u0.fsf@mocca.josefsson.org> <4C27630C.5020401@gnome.org>
Message-ID: <20100627160201.GB3328@downhill.g.la>

On 2010-06-27 Dan Winship <danw at gnome.org> wrote:
> On 01/-10/-28163 02:59 PM, Simon Josefsson wrote:
> >> Shouldn't GnuTLS fall back to the supported protocol (SSL 3.0) in that
> >> case instead of getting stuck?
> > 
> > I think there is a bug in epiphany (or libsoup) here that cause it to
> > send the same request over and over again

> Yes, that was already fixed in libsoup; Debian must not have the latest
> version.
[...]

Debian has 2.30.1 in unstable and 2.31.2 in experimental. 2.31.2 indeed
does not send endless request but simply says

----------------------
Unable to load page

Problem occurred while loading the URL https://db.debian.org/

SSL handshake failed: A record packet with illegal version was
received.

[Try again]
----------------------

cu andreas



From simon at josefsson.org  Tue Jun 29 10:52:32 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 29 Jun 2010 10:52:32 +0200
Subject: help wanted: freshmeat announcements
Message-ID: <87eifqrzjj.fsf@mocca.josefsson.org>

Do you want to help us make a freshmeat.net announcement of GnuTLS
2.10.0 in particular, and also in general for future releases?  If so,
please say so publicly and submit an release update request to the
freshmeat.net team.  Inspiration for what to publish could be my
savannah news update:

https://savannah.gnu.org/forum/forum.php?forum_id=6406

/Simon



From simon at josefsson.org  Tue Jun 29 10:58:49 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 29 Jun 2010 10:58:49 +0200
Subject: make compilation faster on Windows
In-Reply-To: <AANLkTinj3OjrylO7iCSheZoG8NUHJ1QWqQ92fbAJuHqL@mail.gmail.com>
	(Vincent Torri's message of "Sat, 26 Jun 2010 10:36:29 +0200")
References: <AANLkTinj3OjrylO7iCSheZoG8NUHJ1QWqQ92fbAJuHqL@mail.gmail.com>
Message-ID: <87aaqerz92.fsf@mocca.josefsson.org>

Vincent Torri <vincent.torri at gmail.com> writes:

> Hey,
>
> by default, the header file windows.h includes a *lot* os other header
> files, which are almost always useless, except in some cases of course. It
> improves the compilation speed, especially with MSYS/MinGW.
>
> There is a way to reduce the number of header files included by windows.h:
>
> #define WIN32_LEAN_AND_MEAN
> # include <windows.h>
> #undef WIN32_LEAN_AND_MEAN
>
> You can look at windows.h to see what the macro WIN32_LEAN_AND_MEAN disable.
>
> As far as I can see, 2 files are using windows.h in gnutls/src: crypt.c and
> psk.c

I suspect a better fix is to just remove the '#include <windows.h>', as
we use gnulib modules for Windows portability.  I'll try a Windows build
to see if this works...

/Simon



From simon at josefsson.org  Tue Jun 29 11:36:16 2010
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 29 Jun 2010 11:36:16 +0200
Subject: making gnutls depended to pthread
In-Reply-To: <4C25B472.5010509@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sat, 26 Jun 2010 10:04:02 +0200")
References: <4C25B472.5010509@gnutls.org>
Message-ID: <87fx06qiy7.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Hello,
>  I've been thinking it for quite some time but given the bug report:
> https://savannah.gnu.org/support/?107409 , I think it might be relevant.
> GnuTLS due to its use of random numbers will always need a global pool
> to be accessed, and thus locking is mandatory. How about making a new
> gnutls_global_init2() that accept flags such as USE_SYSTEM_LOCKS (that
> would be pthread for linux), by default? This way gnutls will initialize
> all libraries that it is depended on using the default threads for each
> system.

I don't want to see GnuTLS require pthreads, as pthreads doesn't exist
on several platforms (e.g., Windows).

Even on GNU/Linux I'm not sure pthreads is universal, I think both GNU
Pth and NPTL is still in wide use.

So I think a flag USE_SYSTEM_LOCKS flag would be confusing, as it isn't
clear what the application is getting -- one library may be using the
system's NPTL library and another library may be using the system
-lpthread and a third library may use GNU Pth, and if the all are linked
into one application, things will break badly.

Doesn't a gnutls_global_set_mutex-approach where the caller provides the
mutex functions solve this problem?

/Simon



From nmav at gnutls.org  Tue Jun 29 12:52:28 2010
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 29 Jun 2010 12:52:28 +0200
Subject: making gnutls depended to pthread
In-Reply-To: <87fx06qiy7.fsf@mocca.josefsson.org>
References: <4C25B472.5010509@gnutls.org> <87fx06qiy7.fsf@mocca.josefsson.org>
Message-ID: <AANLkTimYaV_TfZ37ED8D15UQoArIOYb3ycJPBsDojIVW@mail.gmail.com>

>> Hello,
>> ?I've been thinking it for quite some time but given the bug report:
>> https://savannah.gnu.org/support/?107409 , I think it might be relevant.
>> GnuTLS due to its use of random numbers will always need a global pool
>> to be accessed, and thus locking is mandatory. How about making a new
>> gnutls_global_init2() that accept flags such as USE_SYSTEM_LOCKS (that
>> would be pthread for linux), by default? This way gnutls will initialize
>> all libraries that it is depended on using the default threads for each
>> system.
> I don't want to see GnuTLS require pthreads, as pthreads doesn't exist
> on several platforms (e.g., Windows).

This is why I proposed using the native system thread system. Windows
will have their own locks.

> Even on GNU/Linux I'm not sure pthreads is universal, I think both GNU
> Pth and NPTL is still in wide use.

Isn't NPTL the actual pthreads in linux? GNU Pth is a userspace
implementation of threads, a practice used in the late 80's and 90's
but I doubt today anyone is using it.

> So I think a flag USE_SYSTEM_LOCKS flag would be confusing, as it isn't
> clear what the application is getting -- one library may be using the
> system's NPTL library and another library may be using the system
> -lpthread and a third library may use GNU Pth, and if the all are linked
> into one application, things will break badly.

Things break badly with the current API as well with the scenario you
describe. I don't think there a practical way even to mix this kind of
libraries. 99% multithreaded of the applications in linux use
pthreads, thus it is safe to assume a default for them, and allow the
1% that does use something different to use their own hooks. Currently
every application that uses threads has to register locks with the
same code as if it was exceptional use. Moreover the issue described
in the savanah bug report occurs even if libraries and applications
use pthreads only.

> Doesn't a gnutls_global_set_mutex-approach where the caller provides the
> mutex functions solve this problem?

I update my point. To have such a function but provide defaults if it
is not called. My idea is for systems with pthreads to provide
pthreads as default and for windows to provide the critical section
locking code as defaults. Applications using exotic thread
implementations can still use gnutls if the use the function you
describe. This should solve the issue at
https://savannah.gnu.org/support/?107409

regards,
Nikos