From INVALID.NOREPLY at gnu.org  Tue Mar  1 22:58:41 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Tue, 01 Mar 2011 21:58:41 +0000
Subject: [sr #107608] duplicate entries in symbol script
In-Reply-To: <20110228-200723.sv20807.51809@savannah.gnu.org>
References: <20110228-200723.sv20807.51809@savannah.gnu.org>
Message-ID: <20110301-235841.sv707.18245@savannah.gnu.org>

Update of sr #107608 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

Applied... thank you!

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107608>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From ludo at gnu.org  Wed Mar  2 00:02:48 2011
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 02 Mar 2011 00:02:48 +0100
Subject: Priority strings
References: <87tyfp9ud7.fsf@gnu.org> <4D6AD735.9070500@gnutls.org>
Message-ID: <87wrki5trb.fsf@gnu.org>

Hi Nikos,

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> You could use something like that:
> NONE:+VERS-TLS-ALL:+CIPHER-ALL:+MAC-ALL:+SIGN-ALL:+COMP-ALL:+ANON-DH

OK, thanks!

>> Besides, while the old method was more verbose, it allowed 
>> programming errors to be spotted more easily (in the Guile bindings, 
>> you would get a type error if trying to use a MAC name when setting 
>> the cipher priority, for instance.)  Could it coexist alongside 
>> priority strings?
>
> No the old priority functions will be marked as deprecated and may be
> removed. I cannot understand though how the error you describe apply
> to that interface.

This is what I had in mind:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (define session (make-session connection-end/client))
scheme@(guile-user)> (set-session-mac-priority! session (list cipher/aes-128-cbc))
ERROR: In procedure set-session-mac-priority!:
ERROR: In procedure set-session-mac-priority!: Wrong type argument in position 2: #<gnutls-cipher-enum AES-128-CBC>
--8<---------------cut here---------------end--------------->8---

Priority strings are handy, but they are less expressive and make it
harder to diagnose programming errors, IMO.

Thanks,
Ludo?.




From home_pw at msn.com  Mon Mar  7 19:30:43 2011
From: home_pw at msn.com (peter williams)
Date: Mon, 7 Mar 2011 10:30:43 -0800
Subject: validating SAN URIs in gntls (FW: [foaf-protocols] Fwd:
	[Freedombox-discuss] WebID)
Message-ID: <SNT143-ds11E54A31A8F4647C513D3A92C70@phx.gbl>

The following may be a little hard to follow, lacking much context here.
But, its essentially saying that a TLS server might validate a client cert
using document retrieved from its SAN URI field (much as the GNUTLS
implementation already validates the DNS SAN URI field by talking to
DNS...).

One might want to think about enabling GNUTLS server's to easily add a
validation callback *mechanism* for the case that SAN URI(s) (possibly
plural) are received in client certs.

I did change certtool(1) src to generate SAN URIs as discussed here once
before, but did it in a way that was reprehensible (and quick). It's not
code I could release... since I just modified the existing code for
populating SAN RFC822 names to make them generate SAN URIs names instead,
destroying the support for RFC822 names. Whoever programmed certtool(1)
initially could probably add SAN URI support properly, in 15-30 minutes.



-----Original Message-----
From: foaf-protocols-bounces at lists.foaf-project.org
[mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of Melvin
Carvalho
Sent: Sunday, March 06, 2011 10:56 AM
To: foaf-protocols at lists.foaf-project.org; WebID XG; Inkster Toby
Subject: [foaf-protocols] Fwd: [Freedombox-discuss] WebID

FYI

WebID + perl implementation in debian

---------- Forwarded message ----------
From: Jonas Smedegaard <dr at jones.dk>
Date: 6 March 2011 19:27
Subject: [Freedombox-discuss] WebID
To: freedombox-discuss at lists.alioth.debian.org


On Tue, Mar 01, 2011 at 07:51:07PM +0100, Melvin Carvalho wrote:
>
> On 1 March 2011 19:34, Jonas Smedegaard <dr at jones.dk> wrote:
>>
>> On Tue, Mar 01, 2011 at 07:04:53PM +0100, Melvin Carvalho wrote:
>>>
>>> On 1 March 2011 18:44, Daniel Kahn Gillmor <dkg at fifthhorseman.net>
wrote:
>>>>
>>>> On 03/01/2011 12:33 PM, Melvin Carvalho wrote:
>>>>>
>>>>> But actually there is a way in the case of the Freedom Box, because
you have the advantage of controlling your own server.
>>>>>
>>>>> Since you are already running a webserver and (hopefully) have control
of your DNS.
>>>>>
>>>>> You can provide a two-way verification chain.
>>>>>
>>>>> 1. Your Person Profile publishes your public key. ?(this is a few 
>>>>> lines of html5, should be easy) 2. Point your self-signed X.509 to
your Freedom Box profile. ?This can be done by putting an entry in the
SubjectAltName field of the cert, a common technique.
>>>>>
>>>>> This provides strong verification for all the X.509 tool chain and
means you can talk security to any server using SSL/TLS which is most of
them, providing strong authentication as a side product.
>>>>
>>>> This doesn't provide an adequate means of revocation, though. ?If an
attacker gets control over your key, and is able to repoint DNS, then you
cannot publish any revocation statement about this key through this channel.
>>>
>>> If an attacker does gain these two points of control, and they knew what
they were doing, you could have an issue yes.
>>>
>>> We need to scope out a revocation model, but I dont think it's that
hard. ?May already be something existing, I'll have a check.
>>
>> Without plauing with it yet myself, I blindly assumed Monkeysphere was
usable for exactly this: use GPG web of trust to assure certificates.
>>
>>
>>>> These two points are what i meant when i said that this model has "no
way of verifying/revoking these keys".
>>>>
>>>> I'm sure you could graft something like this onto <X.509+your scheme
above>; but OpenPGP already exists and handles these cases pretty well. ?Why
reinvent the wheel?
>>>
>>> Because X.509 is quite webby, and the web is the dominant ecosystem on
the internet.
>>
>> more specifically: TLS allows for RESTful secure identity handling -
which helps save bandwidth as is is friendly to proxies and other caching.
>>
>> http://www.w3.org/wiki/WebID
>
> Yes, exactly.
>
> There's a group that has now moved this a step closer to standardization
with the a W3C Web Consortium Incubator Group.
>
> http://www.w3.org/2005/Incubator/webid/charter
>
> I know revocation has been raised as a topic. ?I normally listen in on the
telecons, so I can report back on this topic, and any others people with to
raise.

Awesome!


On a related note, I now (after fighting intensely with it for 3 days,
producing the needed 27 Debian packages) I have now packaged
libcgi-auth-foaf-ssl-perl which is a Perl implementation of WebID.

The work is now pending approval into Debian, and is also available using
the following APT line:

?deb http://debian.jones.dk/ sid freedombox

I would appreciate any and all comments on these packages (and also do tell
me if you are interested in the field of RDF using Perl and need other
libraries packaged!).


- Jonas

--
?* Jonas Smedegaard - idealist & Internet-arkitekt
?* Tlf.: +45 40843136 ?Website: http://dr.jones.dk/

?[x] quote me freely ?[ ] ask before reusing ?[ ] keep private

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCgAGBQJNc9H+AAoJECx8MUbBoAEhcNcP/3ywfLzHBUxbMM2B5gJCKl84
4iXuO1CmunC/cJzFUiF8B7uB1ZL0xQjTjYX1V78QF0ae+hpLKKnFCaF/mXypmXey
IUtYTawQ84xAl7aH1V//z7fNJ7810lcj5JTvcyoNlB6lEnydmZpZ1Yhe+D2SM03J
46i8Xux3DS6XaIq7KBCUgmGXkhqAG1ArT4DrflEbkILY757cGn753U0O0puoqRkE
2YG8FKeYV149meKWlRcaJ9RcPaAWLXlr1YlKqkyM/J3OV2IBFBAW4zNl2Z766uZa
1Qmnc7wVRccdqYQEUMs8XUWYQh6sEjU4LjWDXHiTx0bgl33ikXGCttiWntx6gNBa
au2pfgNGeXzIh6vRbxMLOUYJ76xM4UZ9moKV/dah1PIBkuaP82nruV9ChSaiXrJL
pgzDVZ1WvrwPcOlekLyVWZjfKJY47aRpmSl7/lRBgCWc7/jcjOz9IuLCxs7Gzq5j
nPhLC03nGdbZJzyJneVkyJHbIEzgRiatgCBVXAQJKBybKfO9Mm0uqkes2w3MyBd9
p0F7Kuc0zEoUn520hExscuMxoFAadGYiZt6oAdETCeMiZuIAxuUSHz5GedRWAWRf
0juQYBdAzxim0DpLCZikijbD+5N6W7V4bRoaTWd7FKUrgmxyIhuE3ooYlBV1FNXw
ArPmQbjaPRkgLA/C8Tkf
=SDSs
-----END PGP SIGNATURE-----

_______________________________________________
Freedombox-discuss mailing list
Freedombox-discuss at lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: </pipermail/attachments/20110307/22ae7165/attachment.pgp>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Untitled attachment 00340.txt
URL: </pipermail/attachments/20110307/22ae7165/attachment.txt>

From dkg at fifthhorseman.net  Mon Mar  7 20:19:56 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 07 Mar 2011 14:19:56 -0500
Subject: certificate validation callbacks [was: Re: validating SAN URIs in
 gntls]
In-Reply-To: <SNT143-ds11E54A31A8F4647C513D3A92C70@phx.gbl>
References: <SNT143-ds11E54A31A8F4647C513D3A92C70@phx.gbl>
Message-ID: <4D752FDC.1090102@fifthhorseman.net>

On 03/07/2011 01:30 PM, peter williams wrote:
> One might want to think about enabling GNUTLS server's to easily add a
> validation callback *mechanism* for the case that SAN URI(s) (possibly
> plural) are received in client certs.

certificate validation callbacks would be a very nice thing to have,
particularly if they include information about which particular session
is triggering the verification.

That is, an application knows how it is using a given TLS connection --
it might be using it to connect to a mailserver or a web server or a
database or some other peer with a protocol that GnuTLS doesn't even
know about.

The application might have several TLS sessions running at once (e.g. an
MUA fetching IMAP messages and pulling RSS feeds via HTTPS
concurrently).  So the callback would need to allow the application to
distinguish which TLS session the certificate is for, and accept the
application's approval/rejection of the certificate for that purpose.
This is a different problem than asking an application to approve or
reject a certificate in its own right.  For example, a "valid"
certificate for an HTTPS web server might be considered invalid when
used as client-side auth for an LDAP session.  More prosaically, an
certificate that is valid for a web server at https://example.net/ might
not be acceptable for a web server at https://example.com/

The callback will probably also need to also include the entire
certificate chain, not just the end-entity certificate.

Since the application's particular use of any given TLS session can be
tightly-bound to the qualifications of a given certificate, i think this
kind of callback would be an important thing to have.

There's no reason that GnuTLS should need to know (or be told) about all
the different ways that an application might make use of TLS or decide
to validate certificates, so exposing those configuration choices to the
application is a responsible (and simplifying) approach.

	--dkg

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

From home_pw at msn.com  Mon Mar  7 21:51:13 2011
From: home_pw at msn.com (peter williams)
Date: Mon, 7 Mar 2011 12:51:13 -0800
Subject: certificate validation callbacks [was: Re: validating SAN URIs
	in gntls]
In-Reply-To: <4D752FDC.1090102@fifthhorseman.net>
References: <SNT143-ds11E54A31A8F4647C513D3A92C70@phx.gbl>
	<4D752FDC.1090102@fifthhorseman.net>
Message-ID: <SNT143-ds1991A2939B495C1C36A64192C70@phx.gbl>


Consider how it was done in windows NT 4 (a wee while ago).

A [client] certificate is presented for evaluation.

A factory for trust models fires, looking at the cert for help for which trust model dll to load. In windows, this is called the wintrust framework. One modern way to know which trust model dll the factory should load is to consider the ApplicationPolicies extension in the cert. There are lots of legacy kludge ways, that are just too embarrassing to discuss.

The trust model is always responsible for 2 processes: discovery of chains, validation of chains. Discovery may be nothing more than consult the chain of authority certs presented alongside the client EE cert, originating from the record layer. Validation may consume services, including OCSP, CRLs, or webid protocol... for one or more of those authority + EE certs. It's also responsible for enforcing X.509 chaining semantics (if the chain requires them).

Presumbaly, given a self-signed client cert, GNUTLS _today_ already validates the self-signed signature? (I ask, as I noted that the close protocol was only recently confirmed to be implemented, correctly.)

Obviously, there is then a discovery factory and a validation factory, which knows to load the discovery dll and validation dll. Modern ways to choose them include consulting cert fields, such as AIA (which points at the OCSP server) or the CRLDP (which points at CRL documents). Metadata from those resources can drive the factory to make a provider.

What GNUTLS needs at this point is, probably, just the framework itself. The first providers need be nothing more than discovery = use cert chain given by SSL, and validation = check signatures in a chain of certs. The second provider should be able to punt, up to the likes of the perl libraries mentioned.

What would be nice, for use in the webid world (which is just self-signed client cert with an URI name within) is to be able to easily control which CA's are sought by the GNUTLS server, during client authn. Ideally, it would be trivial to select a null list of CAs, per full handshake.


-----Original Message-----
From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] 
Sent: Monday, March 07, 2011 11:20 AM
To: peter williams
Cc: gnutls-devel at gnu.org
Subject: certificate validation callbacks [was: Re: validating SAN URIs in gntls]

On 03/07/2011 01:30 PM, peter williams wrote:
> One might want to think about enabling GNUTLS server's to easily add a 
> validation callback *mechanism* for the case that SAN URI(s) (possibly
> plural) are received in client certs.

certificate validation callbacks would be a very nice thing to have, particularly if they include information about which particular session is triggering the verification.

That is, an application knows how it is using a given TLS connection -- it might be using it to connect to a mailserver or a web server or a database or some other peer with a protocol that GnuTLS doesn't even know about.

The application might have several TLS sessions running at once (e.g. an MUA fetching IMAP messages and pulling RSS feeds via HTTPS concurrently).  So the callback would need to allow the application to distinguish which TLS session the certificate is for, and accept the application's approval/rejection of the certificate for that purpose.
This is a different problem than asking an application to approve or reject a certificate in its own right.  For example, a "valid"
certificate for an HTTPS web server might be considered invalid when used as client-side auth for an LDAP session.  More prosaically, an certificate that is valid for a web server at https://example.net/ might not be acceptable for a web server at https://example.com/

The callback will probably also need to also include the entire certificate chain, not just the end-entity certificate.

Since the application's particular use of any given TLS session can be tightly-bound to the qualifications of a given certificate, i think this kind of callback would be an important thing to have.

There's no reason that GnuTLS should need to know (or be told) about all the different ways that an application might make use of TLS or decide to validate certificates, so exposing those configuration choices to the application is a responsible (and simplifying) approach.

	--dkg





From dkg at fifthhorseman.net  Tue Mar  8 05:17:05 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 07 Mar 2011 23:17:05 -0500
Subject: certificate validation callbacks [was: Re: validating SAN URIs
 in gntls]
In-Reply-To: <SNT143-ds1991A2939B495C1C36A64192C70@phx.gbl>
References: <SNT143-ds11E54A31A8F4647C513D3A92C70@phx.gbl>	<4D752FDC.1090102@fifthhorseman.net>
	<SNT143-ds1991A2939B495C1C36A64192C70@phx.gbl>
Message-ID: <4D75ADC1.10905@fifthhorseman.net>

On 03/07/2011 03:51 PM, peter williams wrote:
> Presumbaly, given a self-signed client cert, GNUTLS _today_ already
> validates the self-signed signature? (I ask, as I noted that the
> close protocol was only recently confirmed to be implemented, correctly.)

Why would it matter to validate the self-signature?  If we've
established that the peer is in control of the secret key that is
contained within the certificate, why do we care that the certificate is
properly self-signed?  Couldn't a peer in control of its own key craft
any arbitrary self-signed certificate they wanted?

Is there a risk that an attacker could somehow inject a bad cert (albeit
one that contains the same key) without it becoming apparent to both
parties in the negotiation?

> What GNUTLS needs at this point is, probably, just the framework itself.
> The first providers need be nothing more than discovery = use cert chain
> given by SSL, and validation = check signatures in a chain of certs. The
> second provider should be able to punt, up to the likes of the perl
libraries
> mentioned.

Why so complicated?  Why not just a callback to the application with the
following arguments:

 0) some way the caller can identify the particular TLS session

 1) the certificate list offered by the peer (including the EE cert)

> What would be nice, for use in the webid world (which is just self-signed
> client cert with an URI name within) is to be able to easily control which
> CA's are sought by the GNUTLS server, during client authn. Ideally, it
> would be trivial to select a null list of CAs, per full handshake.

GnuTLS is a library, not a server.  What do you mean here?  I'm
proposing that GnuTLS itself makes it easy for the library to punt
entirely on the validation process by handing the relevant information
back to the application for verification.

	--dkg

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

From home_pw at msn.com  Tue Mar  8 05:37:05 2011
From: home_pw at msn.com (peter williams)
Date: Mon, 7 Mar 2011 20:37:05 -0800
Subject: certificate validation callbacks [was: Re: validating SAN URIs
	in gntls]
In-Reply-To: <4D75ADC1.10905@fifthhorseman.net>
References: <SNT143-ds11E54A31A8F4647C513D3A92C70@phx.gbl>	<4D752FDC.1090102@fifthhorseman.net>
	<SNT143-ds1991A2939B495C1C36A64192C70@phx.gbl>
	<4D75ADC1.10905@fifthhorseman.net>
Message-ID: <SNT143-ds17C34C6C85D001D990D9E92C60@phx.gbl>

In the webid protocol, folks have taken a slice out of the original openid protocol proposal: test that a user has write permissions at a server to store a [client] cert/pubkey in an XML document reference by a URI located to that server. Then, rely upon SSL's RSA signature for client authn to prove the user has control over the private key, presenting the cert with associated pubkey in support. To complete the loop (ie. validate the cert's bindings now), from cert retrieve name, which points to server resource, which shall be tested for presence of cert/pubkey under the assumption that only the user has write permissions.

What one needs is the cert is self-signed (or the client cert is trusted by the verifier due to a cert chain, alternatively, that speaks for that URI namespace). Only the user controlling the private key - tied to pubkey - can thus bind pubkey to SAN URI, using that private key.  An https MITM proxy cannot manufacture a false pubkey/URI binding for a self-asserted cert - but it HAS to be self-signed, and be confirmed as such during SSL server procedures.

-----Original Message-----
From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] 
Sent: Monday, March 07, 2011 8:17 PM
To: peter williams
Cc: gnutls-devel at gnu.org
Subject: Re: certificate validation callbacks [was: Re: validating SAN URIs in gntls]

On 03/07/2011 03:51 PM, peter williams wrote:
> Presumbaly, given a self-signed client cert, GNUTLS _today_ already 
> validates the self-signed signature? (I ask, as I noted that the close 
> protocol was only recently confirmed to be implemented, correctly.)

Why would it matter to validate the self-signature?  If we've established that the peer is in control of the secret key that is contained within the certificate, why do we care that the certificate is properly self-signed?  Couldn't a peer in control of its own key craft any arbitrary self-signed certificate they wanted?

Is there a risk that an attacker could somehow inject a bad cert (albeit one that contains the same key) without it becoming apparent to both parties in the negotiation?

> What GNUTLS needs at this point is, probably, just the framework itself.
> The first providers need be nothing more than discovery = use cert 
> chain given by SSL, and validation = check signatures in a chain of 
> certs. The second provider should be able to punt, up to the likes of 
> the perl
libraries
> mentioned.

Why so complicated?  Why not just a callback to the application with the following arguments:

 0) some way the caller can identify the particular TLS session

 1) the certificate list offered by the peer (including the EE cert)

> What would be nice, for use in the webid world (which is just 
> self-signed client cert with an URI name within) is to be able to 
> easily control which CA's are sought by the GNUTLS server, during 
> client authn. Ideally, it would be trivial to select a null list of CAs, per full handshake.

GnuTLS is a library, not a server.  What do you mean here?  I'm proposing that GnuTLS itself makes it easy for the library to punt entirely on the validation process by handing the relevant information back to the application for verification.

	--dkg





From dkg at fifthhorseman.net  Tue Mar  8 07:45:34 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 08 Mar 2011 01:45:34 -0500
Subject: certificate validation callbacks [was: Re: validating SAN URIs
 in gntls]
In-Reply-To: <SNT143-ds17C34C6C85D001D990D9E92C60@phx.gbl>
References: <SNT143-ds11E54A31A8F4647C513D3A92C70@phx.gbl>	<4D752FDC.1090102@fifthhorseman.net>	<SNT143-ds1991A2939B495C1C36A64192C70@phx.gbl>	<4D75ADC1.10905@fifthhorseman.net>
	<SNT143-ds17C34C6C85D001D990D9E92C60@phx.gbl>
Message-ID: <4D75D08E.8020007@fifthhorseman.net>

On 03/07/2011 11:37 PM, peter williams wrote:

> but it HAS to be self-signed, and be confirmed as such during SSL server procedures.

I'm afraid i'm still not following this argument.  We're talking about
client-side authentication, and the cert in question belongs to the
client in the TLS session?

I think the entire TLS handshake (up through and including the
client-side cert) get certified by the client's secret key in the
"certificate verify" message [0].  So the client is cryptographically
demonstrating:

 (a) control over the public key, and
 (b) a certification that covers the client certificate.

I imagine two types of threat we're concerned about:

 0) a network-based attacker who wants to use their own key in place of
the client's key, and

 1) a network-based attacker who just wants to swap out the client's
certificate with a different certificate (the replacement cert contains
the client's own key).

In scenario 0, the attacker presents the server with a certificate
derived from her own key -- since she controls the key, she can
certainly make the certificate self-signed.  The validity of the
self-sig on the certificate doesn't provide us with a way to distinguish
the attacker from the client in this situation.

In scenario 1, the attacker is maybe trying to convince the server that
the client is presenting different data from the data in the client's
actual certificate.  The server could distinguish the two cases based on
whether the certificate is properly self-signed (the attacker's bogus
cert could not be self-signed because the client's secret key is
unavailable to the attacker).  But since the client doesn't see the
replacement certificate, its computed "certificate verify" message will
not verify anyway.  So again, i don't think the validity of the self-sig
on the certificate buys us anything in this situation.

Another way of looking at it: doesn't the "certificate verify" message
offer an assertion that the client is vouching for the data in their
certificate?  What additional benefits do we get from validating the
self-sig on the cert anyway?

Can you help me understand *why* either party would care that either
cert be self-signed if the session initiation has already established
that both parties saw the same certs and are in control of their
respective secret keys?

It's certainly possible that i'm misunderstanding something about how
TLS works -- feel free to point it out to me, even if the flaw in my
reasoning is glaringly obvious.  I can take it :)

Trying to understand,

	--dkg

[0] https://tools.ietf.org/html/rfc2246#section-7.4.8 (there are
comparable sections in TLS 1.1 and 1.2)

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

From nmav at gnutls.org  Tue Mar  8 09:27:52 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 8 Mar 2011 09:27:52 +0100
Subject: certificate validation callbacks [was: Re: validating SAN URIs
	in gntls]
In-Reply-To: <4D752FDC.1090102@fifthhorseman.net>
References: <SNT143-ds11E54A31A8F4647C513D3A92C70@phx.gbl>
	<4D752FDC.1090102@fifthhorseman.net>
Message-ID: <AANLkTim__MYB0jW4LMAYhGKLZR-r-aCMUogxVeVWBNOD@mail.gmail.com>

On Mon, Mar 7, 2011 at 8:19 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> On 03/07/2011 01:30 PM, peter williams wrote:
>> One might want to think about enabling GNUTLS server's to easily add a
>> validation callback *mechanism* for the case that SAN URI(s) (possibly
>> plural) are received in client certs.
> certificate validation callbacks would be a very nice thing to have,
> particularly if they include information about which particular session
> is triggering the verification.

I don't really understand about what kind of callbacks is the discussion about.
Isn't the callback set by gnutls_certificate_set_verify_function() sufficient?

regards,
Nikos



From INVALID.NOREPLY at gnu.org  Tue Mar  8 13:23:24 2011
From: INVALID.NOREPLY at gnu.org (Sebastien Helleu)
Date: Tue, 08 Mar 2011 12:23:24 +0000
Subject: [sr #107619] Check hostname of certificate failed with two
	subdomains in hostname
Message-ID: <20110308-132323.sv8049.92493@savannah.gnu.org>

URL:
  <http://savannah.gnu.org/support/?107619>

                 Summary: Check hostname of certificate failed with two
subdomains in hostname
                 Project: GnuTLS
            Submitted by: flashcode
            Submitted on: Tue 08 Mar 2011 01:23:23 PM CET
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

Hi,
I'm WeeChat developer, an irc client, which uses gnutls to connect to irc
servers.
When I connect to freenode using SSL, I receive this certificate:


subject `OU=Domain Control Validated,OU=Gandi Standard Wildcard
SSL,CN=*.freenode.net', issuer `C=FR,O=GANDI SAS,CN=Gandi Standard SSL CA',
RSA key ...


I call function "gnutls_x509_crt_check_hostname (cert, hostname)" to check
hostname with certificate.

If I connect to chat.freenode.net, the hostname check is ok (*.freenode.net
matches chat.freenode.net).
But if I connect to ipv6.chat.freenode.net, the hostname check failed because
*.freenode.net does NOT match ipv6.chat.freenode.net (according to RFC2818 you
are using in your function).

My question are:
* is it a problem in freenode certificate? 
* is it ok to use rfc2818 in gnutls to check certificate hostname? shouldn't
*.freenode.net match ipv6.chat.freenode.net ?

Last info, I'm using gnutls 2.10.5 (under debian sid).

Thank you for your help.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107619>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Tue Mar  8 13:50:48 2011
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Tue, 08 Mar 2011 12:50:48 +0000
Subject: [sr #107619] Check hostname of certificate failed with two
	subdomains in hostname
In-Reply-To: <20110308-132323.sv8049.92493@savannah.gnu.org>
References: <20110308-132323.sv8049.92493@savannah.gnu.org>
Message-ID: <20110308-125048.sv0.6315@savannah.gnu.org>

Follow-up Comment #1, sr #107619 (project gnutls):

RFC2818 defines what certificates should contain for HTTPS servers. Unless
there is a similar document for IRC servers, I'd consider that applicable and
see it as problem in the freenode certificate. 

RFC2818 is pretty explicit on that:
Names may contain the wildcard character * which is considered to match any
single domain name component or component fragment. E.g., *.a.com matches
foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com.


You could however use your custom matching function.

regards,
--nmav

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107619>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From dkg at fifthhorseman.net  Tue Mar  8 15:05:06 2011
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 08 Mar 2011 09:05:06 -0500
Subject: certificate validation callbacks [was: Re: validating SAN URIs
 in gntls]
In-Reply-To: <AANLkTim__MYB0jW4LMAYhGKLZR-r-aCMUogxVeVWBNOD@mail.gmail.com>
References: <SNT143-ds11E54A31A8F4647C513D3A92C70@phx.gbl>	<4D752FDC.1090102@fifthhorseman.net>
	<AANLkTim__MYB0jW4LMAYhGKLZR-r-aCMUogxVeVWBNOD@mail.gmail.com>
Message-ID: <4D763792.9010303@fifthhorseman.net>

On 03/08/2011 03:27 AM, Nikos Mavrogiannopoulos wrote:
> I don't really understand about what kind of callbacks is the discussion about.
> Isn't the callback set by gnutls_certificate_set_verify_function() sufficient?

Whoops!  I didn't realize this had been added to 2.10.0.  Yes, it looks
like that will do exactly what i was thinking.  Thanks for anticipating
this, Nikos!  I'm assuming this callback triggers on both the server and
client sides?

Out of curiosity, when gnutls_certificate_set_verify_function() gets
called, do we have evidence that the peer is actually in control of the
secret key corresponding to the public key in the certificate?  Or do we
only get that evidence after the handshake has completed?  (maybe the
answer is different for the case where we are the client vs. the case
where we are the server?)

The docs [0] say:

>> This function sets a callback to be called when peer's certificate has
>> been received in order to verify it on receipt rather than doing after
>> the handshake is completed. 

Is the idea that users of older versions of gnutls would have used
something like gnutls_handshake_set_post_client_hello_function() if they
are the server?  or just that they would have to manually invoke
gnutls_handshake(), then check the certificate, and alert/fail the
connection at that point?

	--dkg

 [0]
http://www.gnu.org/software/gnutls/manual/html_node/Core-functions.html#gnutls_005fcertificate_005fset_005fverify_005ffunction


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

From nmav at gnutls.org  Tue Mar  8 15:20:08 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 8 Mar 2011 15:20:08 +0100
Subject: certificate validation callbacks [was: Re: validating SAN URIs
	in gntls]
In-Reply-To: <4D763792.9010303@fifthhorseman.net>
References: <SNT143-ds11E54A31A8F4647C513D3A92C70@phx.gbl>
	<4D752FDC.1090102@fifthhorseman.net>
	<AANLkTim__MYB0jW4LMAYhGKLZR-r-aCMUogxVeVWBNOD@mail.gmail.com>
	<4D763792.9010303@fifthhorseman.net>
Message-ID: <AANLkTinJn3D=BE_U1+98eeB=SG2VUKWChKev7wnEZs0E@mail.gmail.com>

On Tue, Mar 8, 2011 at 3:05 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> On 03/08/2011 03:27 AM, Nikos Mavrogiannopoulos wrote:
>> I don't really understand about what kind of callbacks is the discussion about.
>> Isn't the callback set by gnutls_certificate_set_verify_function() sufficient?
> Whoops! ?I didn't realize this had been added to 2.10.0. ?Yes, it looks
> like that will do exactly what i was thinking. ?Thanks for anticipating
> this, Nikos! ?I'm assuming this callback triggers on both the server and
> client sides?

Indeed.

> Out of curiosity, when gnutls_certificate_set_verify_function() gets
> called, do we have evidence that the peer is actually in control of the
> secret key corresponding to the public key in the certificate? ?Or do we
> only get that evidence after the handshake has completed? ?(maybe the
> answer is different for the case where we are the client vs. the case
> where we are the server?)

No at this point only the certificate has been received. The protocol has
not been completed. It is only after the completion of the handshake (and
the verification of certificates), that you are sure about peer's
identity/certificate
claims.

> Is the idea that users of older versions of gnutls would have used
> something like gnutls_handshake_set_post_client_hello_function() if they
> are the server? ?or just that they would have to manually invoke
> gnutls_handshake(), then check the certificate, and alert/fail the
> connection at that point?

The post_client_hello_function() is used by web servers that want to
access the extensions such as server_name indication asap. The
"new" callback is to allow having the verification as part of the handshake
and thus having a setup where a successful handshake also indicates
verification of the peer.

regards,
Nikos



From home_pw at msn.com  Tue Mar  8 15:46:39 2011
From: home_pw at msn.com (peter williams)
Date: Tue, 8 Mar 2011 06:46:39 -0800
Subject: certificate validation callbacks [was: Re: validating SAN URIs
	in gntls]
In-Reply-To: <4D75D08E.8020007@fifthhorseman.net>
References: <SNT143-ds11E54A31A8F4647C513D3A92C70@phx.gbl>	<4D752FDC.1090102@fifthhorseman.net>	<SNT143-ds1991A2939B495C1C36A64192C70@phx.gbl>	<4D75ADC1.10905@fifthhorseman.net>
	<SNT143-ds17C34C6C85D001D990D9E92C60@phx.gbl>
	<4D75D08E.8020007@fifthhorseman.net>
Message-ID: <SNT143-ds19B6D346C63A616F9E9FCC92C60@phx.gbl>

SSL was designed according to the doctrine of mutual suspicion (each party assume the other is an active attacker). In the web, active attackers abound: they are called corporate firewalls :-). They take the SSL handshake including the self-signed cert from the browser's client authn, and spoof the browser endpoint to the intended site; presenting perhaps their own self-signed cert (since they cannot sign for the user) pointing in the SAN_URI to their own document.

Its true that the SSL patent (and all the various Netscape/IETF specs) distinguish between TLS protocols and [asymmetric] key management, with the latter being a matter for the application (GNUTLS library consumer). Lets distinguish correctly between the server, and the TLS lib/state. GNUTEST test server is the first such "server", supported by the latest GNUTLS lib.

Thus, it?s the GNUTLS test server (not the library) that is responsible for assuring the [asymmetric] key management - checking the self-signed cert, in this case.  If the server had a "wintrust type interaction" with the library, then server code might go further and do the full webid validation agent steps (or do PKIK PKI, or Netscape cert extensions, or...). As folks state properly, this validation will in the general case need the full ssl state for the connection ( => session) for each sessionid; and the server app needs to be able in any case to order a close, or an alert, or a new full handshake, or a resume.... etc, per sessionid as part of responding to what it determines, during validation of the [asymm] keys.

In the case of webid, that server code (implementing a particular validation model, somehow selected from n of them) has to not only check the self-signed cert, not only confirm pubkey exists in stored remote file, but confirm that the URI is part of an out of bound trust mesh (to address the corporate proxy simply swapping out one self-signed cert pointing to a document, for another).

So, I think I'm in agreement on all points.

1. its server's who do self-signed cert checking (and GNUTLS test server is probably one that should, or else just warn that it hasn?t)

2. its library/server API design that allows server to drive a validation process, for some asymmetric key management design (e.g. PKIX, webid protocol, .next)

3. the SSL state is what the server needs. Arguably, it needs a chain of states, those to which it has access rights because n connections (and their sessions) are all being bound to the very same server (vs TLS) endpoint, in the stack of the entity playing the SSL server-role.


-----Original Message-----
From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] 
Sent: Monday, March 07, 2011 10:46 PM
To: peter williams
Cc: gnutls-devel at gnu.org
Subject: Re: certificate validation callbacks [was: Re: validating SAN URIs in gntls]

On 03/07/2011 11:37 PM, peter williams wrote:

> but it HAS to be self-signed, and be confirmed as such during SSL server procedures.

I'm afraid i'm still not following this argument.  We're talking about client-side authentication, and the cert in question belongs to the client in the TLS session?

I think the entire TLS handshake (up through and including the client-side cert) get certified by the client's secret key in the "certificate verify" message [0].  So the client is cryptographically
demonstrating:

 (a) control over the public key, and
 (b) a certification that covers the client certificate.

I imagine two types of threat we're concerned about:

 0) a network-based attacker who wants to use their own key in place of the client's key, and

 1) a network-based attacker who just wants to swap out the client's certificate with a different certificate (the replacement cert contains the client's own key).

In scenario 0, the attacker presents the server with a certificate derived from her own key -- since she controls the key, she can certainly make the certificate self-signed.  The validity of the self-sig on the certificate doesn't provide us with a way to distinguish the attacker from the client in this situation.

In scenario 1, the attacker is maybe trying to convince the server that the client is presenting different data from the data in the client's actual certificate.  The server could distinguish the two cases based on whether the certificate is properly self-signed (the attacker's bogus cert could not be self-signed because the client's secret key is unavailable to the attacker).  But since the client doesn't see the replacement certificate, its computed "certificate verify" message will not verify anyway.  So again, i don't think the validity of the self-sig on the certificate buys us anything in this situation.

Another way of looking at it: doesn't the "certificate verify" message offer an assertion that the client is vouching for the data in their certificate?  What additional benefits do we get from validating the self-sig on the cert anyway?

Can you help me understand *why* either party would care that either cert be self-signed if the session initiation has already established that both parties saw the same certs and are in control of their respective secret keys?

It's certainly possible that i'm misunderstanding something about how TLS works -- feel free to point it out to me, even if the flaw in my reasoning is glaringly obvious.  I can take it :)

Trying to understand,

	--dkg

[0] https://tools.ietf.org/html/rfc2246#section-7.4.8 (there are comparable sections in TLS 1.1 and 1.2)





From home_pw at msn.com  Tue Mar  8 19:12:38 2011
From: home_pw at msn.com (peter williams)
Date: Tue, 8 Mar 2011 10:12:38 -0800
Subject: certificate validation callbacks [was: Re: validating SAN URIs
	in gntls]
In-Reply-To: <AANLkTim__MYB0jW4LMAYhGKLZR-r-aCMUogxVeVWBNOD@mail.gmail.com>
References: <SNT143-ds11E54A31A8F4647C513D3A92C70@phx.gbl>	<4D752FDC.1090102@fifthhorseman.net>
	<AANLkTim__MYB0jW4LMAYhGKLZR-r-aCMUogxVeVWBNOD@mail.gmail.com>
Message-ID: <SNT143-ds208D04A12558F75BB5A46F92C60@phx.gbl>

Perhaps, yes.

Does the GNUTLS *test* server use it to set a callback, that then verifies cert chains (such as self-signed client authn cert is indeed self-signed)?

Ive been pointing folks at the GNUTLS test server, showing how it prints out the value of the client cert, showing its SAN_URI content in particular. The question I had in my mind, originally, was: was the signature on the cert even verified (by the lib, OR by the test server callback code)?

I can presume (I hope) that mere delivery of the client cert to the server by the library means that the SSL (RSA) ciphersuite was properly enforced  by the library, ensuring that the RSA signature due to the clientauthn procedure of SSL matched the pubkey in the cert.

SSL doesn?t require that last condition; which motivates my question. A library might use a cache of "trusted pubkeys" to validate the RSA signature due to client authn, totally ignoring the client certs also received on the wire. Nothing requires that client authn enforcement and signature checking (for RSA) use the pubkeys from certs in the inbound certificate message (though this is  commonly done)

At some point, I suppose I'll just have to read all the code, to see what it all does.



-----Original Message-----
From: n.mavrogiannopoulos at gmail.com [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos
Sent: Tuesday, March 08, 2011 12:28 AM
To: gnutls-devel at gnu.org
Cc: Daniel Kahn Gillmor; peter williams
Subject: Re: certificate validation callbacks [was: Re: validating SAN URIs in gntls]

On Mon, Mar 7, 2011 at 8:19 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> On 03/07/2011 01:30 PM, peter williams wrote:
>> One might want to think about enabling GNUTLS server's to easily add 
>> a validation callback *mechanism* for the case that SAN URI(s) 
>> (possibly
>> plural) are received in client certs.
> certificate validation callbacks would be a very nice thing to have, 
> particularly if they include information about which particular 
> session is triggering the verification.

I don't really understand about what kind of callbacks is the discussion about.
Isn't the callback set by gnutls_certificate_set_verify_function() sufficient?

regards,
Nikos




From nmav at gnutls.org  Wed Mar  9 20:57:02 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 09 Mar 2011 20:57:02 +0100
Subject: gnutls 2.11.7
Message-ID: <4D77DB8E.6020703@gnutls.org>

Hello,

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

This is major update release that includes features such as PKCS #11
support for cryptographic objects, a PKCS #11 token manipulation tool
(p11tool), support for local system thread locks, new message buffering
layer, support for nettle library and more.

Consider that a release candidate for 2.12.0.

A draft of the complete changes since 2.10.x can be found at:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=doc/announce.txt;h=5a881d80620beb7b870d4195f0a0e446e1c632ff;hb=gnutls_2_12_x

Here are the compressed sources:
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.11.7.tar.bz2
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-2.11.7.tar.bz2

Here is the OpenPGP signature:
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.11.7.tar.bz2.sig
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-2.11.7.tar.bz2.sig

regards,
Nikos




From ametzler at downhill.at.eu.org  Thu Mar 10 10:34:39 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Thu, 10 Mar 2011 10:34:39 +0100
Subject: gnutls 2.11.7
In-Reply-To: <4D77DB8E.6020703@gnutls.org>
References: <4D77DB8E.6020703@gnutls.org>
Message-ID: <20110310093439.GA2027@downhill.g.la>

On 2011-03-09 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> This is major update release that includes features such as PKCS #11
> support for cryptographic objects, a PKCS #11 token manipulation tool
> (p11tool), support for local system thread locks, new message buffering
> layer, support for nettle library and more.

Hello,

I have loooked over the headers (mainly compared to .6).

openssl.h: typedef struct SSL_METHOD has changed (size and members).

Isn't this a problem? (ABI break)

There is also couple of API changes that are not correctly documented,
afaict this is just a minor documentation problem, none of the functions
were part of a stable release.

NEWS says gnutls_transport_set_push_function2: ADDED
However the function was present in .6 and removed in .7.

gnutls_openpgp_privkey_decrypt_data was present in .6 openpgp.h and is
missing now.

gnutls_x509_privkey_sign_data2 was removed but is not listed in NEWS.

gnutls_pkcs11_privkey_sign_hash is listed twice as REMOVED in NEWS.

cu andreas



From ametzler at downhill.at.eu.org  Thu Mar 10 12:06:50 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Thu, 10 Mar 2011 12:06:50 +0100
Subject: gnutls 2.11.7
In-Reply-To: <4D77DB8E.6020703@gnutls.org>
References: <4D77DB8E.6020703@gnutls.org>
Message-ID: <20110310110650.GB2027@downhill.g.la>

On 2011-03-09 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
[...]
> Consider that a release candidate for 2.12.0.
[...]

Hello,
Using the gcrypt backend ex-client2 fails to build with binutils-gold
since libgnutls-extra is not linked correctly. It uses
gcry_check_version but is not linked against libgcrypt.

Patch attached.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proper-patch.diff
Type: text/x-diff
Size: 462 bytes
Desc: not available
URL: </pipermail/attachments/20110310/a924309c/attachment.diff>

From nmav at gnutls.org  Thu Mar 10 17:07:48 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 10 Mar 2011 17:07:48 +0100
Subject: gnutls 2.11.7
In-Reply-To: <20110310093439.GA2027@downhill.g.la>
References: <4D77DB8E.6020703@gnutls.org> <20110310093439.GA2027@downhill.g.la>
Message-ID: <4D78F754.1040907@gnutls.org>

On 03/10/2011 10:34 AM, Andreas Metzler wrote:
> On 2011-03-09 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>> This is major update release that includes features such as PKCS #11
>> support for cryptographic objects, a PKCS #11 token manipulation tool
>> (p11tool), support for local system thread locks, new message buffering
>> layer, support for nettle library and more.
> 
> Hello,
> 
> I have loooked over the headers (mainly compared to .6).
> 
> openssl.h: typedef struct SSL_METHOD has changed (size and members).
> Isn't this a problem? (ABI break)

Indeed but only for libgnutls-openssl. Btw,  Does it make sense to
remove it from main gnutls and distribute it separately?
(not for 2.12.x, but for the next major release).

> There is also couple of API changes that are not correctly documented,
> afaict this is just a minor documentation problem, none of the functions
> were part of a stable release.
> NEWS says gnutls_transport_set_push_function2: ADDED
> However the function was present in .6 and removed in .7.

It was renamed to gnutls_transport_set_vec_push_function(). I forgot
to replace that part. I've fixed it.

> gnutls_openpgp_privkey_decrypt_data was present in .6 openpgp.h and is
> missing now.
> gnutls_x509_privkey_sign_data2 was removed but is not listed in NEWS.
> gnutls_pkcs11_privkey_sign_hash is listed twice as REMOVED in NEWS.

Corrected.

Thank you for checking that.

regards,
Nikos




From nmav at gnutls.org  Thu Mar 10 17:16:26 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 10 Mar 2011 17:16:26 +0100
Subject: gnutls 2.11.7
In-Reply-To: <20110310110650.GB2027@downhill.g.la>
References: <4D77DB8E.6020703@gnutls.org> <20110310110650.GB2027@downhill.g.la>
Message-ID: <4D78F95A.3040505@gnutls.org>

On 03/10/2011 12:06 PM, Andreas Metzler wrote:
> On 2011-03-09 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> [...]
>> Consider that a release candidate for 2.12.0.
> [...]
> Hello,
> Using the gcrypt backend ex-client2 fails to build with binutils-gold
> since libgnutls-extra is not linked correctly. It uses
> gcry_check_version but is not linked against libgcrypt.

Applied. Thank you.

regards,
Nikos



From ametzler at downhill.at.eu.org  Fri Mar 11 17:55:20 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Fri, 11 Mar 2011 17:55:20 +0100
Subject: gnutls 2.11.7
In-Reply-To: <4D78F754.1040907@gnutls.org>
References: <4D77DB8E.6020703@gnutls.org> <20110310093439.GA2027@downhill.g.la>
	<4D78F754.1040907@gnutls.org>
Message-ID: <20110311165520.GA3535@downhill.g.la>

On 2011-03-10 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On 03/10/2011 10:34 AM, Andreas Metzler wrote:
[...]
>> openssl.h: typedef struct SSL_METHOD has changed (size and members).
>> Isn't this a problem? (ABI break)

> Indeed but only for libgnutls-openssl.

Hello,

I see that you have already bumped the soname in GIT gnutls_2_12_x.

> Btw,  Does it make sense to
> remove it from main gnutls and distribute it separately?
> (not for 2.12.x, but for the next major release).
[snip]

Splitting upstream sources imho does not make sense, I do not see the
gain but obviously more work for you (duplicate release process,
e.g.) However I will split off libgnutls-openssl in a
separate Debian binary package.

thanks, cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



From nmav at gnutls.org  Fri Mar 11 20:59:55 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 11 Mar 2011 20:59:55 +0100
Subject: DTLS in gnutls
Message-ID: <4D7A7F3B.2070305@gnutls.org>

Hello,
 It seems that gnutls in master repository includes a fully
functional DTLS 1.0 (rfc4347) implementation. Kudos to Jonathan
for creating the initial functional implementation the current
implementation was built on.

Due to DTLS' requirements for handshake, several parts of
gnutls' handshake subsystem were rewritten to allow maximum
re-use between the two protocols (TLS and DTLS). DTLS'
handshake is asynchronous meaning that it might operate
even after gnutls_handshake() is terminated (e.g. retransmit
handshake packets lost by the peer) and this requires
substantial changes to how gnutls' functions can be
called in DTLS. Now I emulate the synchronous behavior
of gnutls_handshake() by waiting for few seconds for
possible retransmissions by peer, and this has the
disadvantage of gnutls_handshake() taking a fixed amount
of seconds irrespective of calculations, but requires
no semantic changes in the rest of the functions
(such as gnutls_record_recv()).

Another solution is to require a DTLS server/client to
call gnutls_record_recv() on every received record, even
if he wasn't expecting one for his application protocol
and reserve a special error code to indicate no data for
application...


I don't like the latter change of semantics, but I cannot
see any obvious way of avoiding it... If you have suggestions
or ideas please let me know.

best regards,
Nikos



From INVALID.NOREPLY at gnu.org  Sun Mar 13 05:01:28 2011
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Sun, 13 Mar 2011 04:01:28 +0000
Subject: [sr #107622] SIGN-RSA224, SIGN-DSA-224,
	and SIGN-DSA-256 not supported in priority string
Message-ID: <20110313-040127.sv0.38955@savannah.gnu.org>

URL:
  <http://savannah.gnu.org/support/?107622>

                 Summary: SIGN-RSA224, SIGN-DSA-224, and SIGN-DSA-256 not
supported in priority string
                 Project: GnuTLS
            Submitted by: None
            Submitted on: s?n 13 mar 2011 04.01.27
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: teddy at fukt.bsnet.se
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

It is not possible to specify SIGN-RSA224, SIGN-DSA-224, or SIGN-DSA-256 in a
priority string.  Suggested patch:

--- lib/gnutls_algorithms.c.~1~ 2011-03-02 18:39:13.000000000 +0100
+++ lib/gnutls_algorithms.c     2011-03-13 04:11:44.000000000 +0100
@@ -1958,11 +1958,14 @@
 /* Keep the contents of this struct the same as the previous one. */
 static const gnutls_sign_algorithm_t supported_sign[] = {
   GNUTLS_SIGN_RSA_SHA1,
+  GNUTLS_SIGN_RSA_SHA224,
   GNUTLS_SIGN_RSA_SHA256,
   GNUTLS_SIGN_RSA_SHA384,
   GNUTLS_SIGN_RSA_SHA512,
   GNUTLS_SIGN_RSA_RMD160,
   GNUTLS_SIGN_DSA_SHA1,
+  GNUTLS_SIGN_DSA_SHA224,
+  GNUTLS_SIGN_DSA_SHA256,
   GNUTLS_SIGN_RSA_MD5,
   GNUTLS_SIGN_RSA_MD2,
   0

/Teddy Hogeborn





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107622>

_______________________________________________
  Meddelandet skickades via/av Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Mar 13 07:01:45 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 13 Mar 2011 06:01:45 +0000
Subject: [sr #107622] SIGN-RSA224, SIGN-DSA-224,
	and SIGN-DSA-256 not supported in priority string
In-Reply-To: <20110313-040127.sv0.38955@savannah.gnu.org>
References: <20110313-040127.sv0.38955@savannah.gnu.org>
Message-ID: <20110313-080145.sv707.47897@savannah.gnu.org>

Update of sr #107622 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

thank you for reporting and the patch. I've committed the fix.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107622>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Mar 13 15:53:22 2011
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Sun, 13 Mar 2011 14:53:22 +0000
Subject: [sr #107623] Priority string "SECURITY256" seemingly no longer
	supports DSA keys
Message-ID: <20110313-145321.sv0.73086@savannah.gnu.org>

URL:
  <http://savannah.gnu.org/support/?107623>

                 Summary: Priority string "SECURITY256" seemingly no longer
supports DSA keys
                 Project: GnuTLS
            Submitted by: None
            Submitted on: s?n 13 mar 2011 14.53.21
                Category: None
                Priority: 5 - Normal
                Severity: 4 - Important
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: teddy at fukt.bsnet.se
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

If DSA keys are used, the priority string "SECURE256" no longer yields a
successful handshake.  Steps to reproduce:

########
mkdir /tmp/keydir

cat > /tmp/keydir/batch <<EOF
Key-Type: DSA
Key-Length: 2048
Subkey-Type: ELG-E
Subkey-Length: 2048
Name-Real: localhost
Expire-Date: 0
%commit
EOF

gpg --quiet --batch --no-tty --no-options --enable-dsa2 --homedir /tmp/keydir
--trust-model always --gen-key /tmp/keydir/batch

gpg --quiet --batch --no-tty --no-options --enable-dsa2 --homedir /tmp/keydir
--armor --export-options export-minimal --comment "Test key for GnuTLS"
--output /tmp/keydir/seckey.txt --export-secret-keys
gpg --quiet --batch --no-tty --no-options --enable-dsa2 --homedir /tmp/keydir
--armor --export-options export-minimal --comment "Test key for GnuTLS"
--output /tmp/keydir/pubkey.txt --export

gnutls-serv --priority 'SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP' --pgpkeyfile
/tmp/keydir/seckey.txt --pgpcertfile /tmp/keydir/pubkey.txt --port 5556

# Now, in another terminal, run this:

gnutls-cli --insecure --priority 'SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP'
--port 5556 localhost
########

The server produces these error messages:
Error in handshake
Error: An unknown public key algorithm was encountered.

This used to work in GnuTLS 2.8.6.  If I change the SECURE256 to SECURE128 (on
both server and client) it works, and also if I add ":!VERS-TLS1.2".  However
both of those "solutions" feel suboptimal.

/Teddy Hogeborn





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107623>

_______________________________________________
  Meddelandet skickades via/av Savannah
  http://savannah.gnu.org/




From fweimer at bfk.de  Mon Mar 14 12:34:01 2011
From: fweimer at bfk.de (Florian Weimer)
Date: Mon, 14 Mar 2011 11:34:01 +0000
Subject: Missing interface documentation for push/pull functions
Message-ID: <82pqpurl5i.fsf@mid.bfk.de>

The documentation should mention that the functions must return -1
(and not any other negative value, especially not GNUTLS error codes)
on error, and set errno to a suitable error code.  The calling
functions do not handle other negative return values very well.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99



From nmav at gnutls.org  Mon Mar 14 12:38:52 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 14 Mar 2011 12:38:52 +0100
Subject: Missing interface documentation for push/pull functions
In-Reply-To: <82pqpurl5i.fsf@mid.bfk.de>
References: <82pqpurl5i.fsf@mid.bfk.de>
Message-ID: <AANLkTikuq=spinSxY+KgVTs_oJtGzHiD76y3=yU+BbL4@mail.gmail.com>

On Mon, Mar 14, 2011 at 12:34 PM, Florian Weimer <fweimer at bfk.de> wrote:
> The documentation should mention that the functions must return -1
> (and not any other negative value, especially not GNUTLS error codes)
> on error, and set errno to a suitable error code. ?The calling
> functions do not handle other negative return values very well.

Which part of the documentation are you referring to?
I can see that:
http://www.gnu.org/software/gnutls/manual/html_node/The-transport-layer.html#The-transport-layer
is pretty clear about that.

regards,
Nikos



From fweimer at bfk.de  Mon Mar 14 12:45:17 2011
From: fweimer at bfk.de (Florian Weimer)
Date: Mon, 14 Mar 2011 11:45:17 +0000
Subject: Missing interface documentation for push/pull functions
In-Reply-To: <AANLkTikuq=spinSxY+KgVTs_oJtGzHiD76y3=yU+BbL4@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Mon\,
	14 Mar 2011 12\:38\:52 +0100")
References: <82pqpurl5i.fsf@mid.bfk.de>
	<AANLkTikuq=spinSxY+KgVTs_oJtGzHiD76y3=yU+BbL4@mail.gmail.com>
Message-ID: <82ipvmrkmq.fsf@mid.bfk.de>

* Nikos Mavrogiannopoulos:

> On Mon, Mar 14, 2011 at 12:34 PM, Florian Weimer <fweimer at bfk.de> wrote:
>> The documentation should mention that the functions must return -1
>> (and not any other negative value, especially not GNUTLS error codes)
>> on error, and set errno to a suitable error code. ?The calling
>> functions do not handle other negative return values very well.
>
> Which part of the documentation are you referring to?
> I can see that:
> http://www.gnu.org/software/gnutls/manual/html_node/The-transport-layer.html#The-transport-layer
> is pretty clear about that.

The documentation for gnutls_transport_set_push_function and
gnutls_transport_set_pull_function.  I think I'd reported this before,
but I fell into the same trap again. 8-(

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99



From ametzler at downhill.at.eu.org  Mon Mar 14 17:50:55 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 14 Mar 2011 17:50:55 +0100
Subject: gnutls 2.11.7
In-Reply-To: <20110311165520.GA3535@downhill.g.la>
References: <4D77DB8E.6020703@gnutls.org> <20110310093439.GA2027@downhill.g.la>
	<4D78F754.1040907@gnutls.org> <20110311165520.GA3535@downhill.g.la>
Message-ID: <20110314165055.GC2045@downhill.g.la>

On 2011-03-11 Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
> On 2011-03-10 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
[...]
> > Btw,  Does it make sense to
> > remove it from main gnutls and distribute it separately?
> > (not for 2.12.x, but for the next major release).
> [snip]

> Splitting upstream sources imho does not make sense, I do not see the
> gain but obviously more work for you (duplicate release process,
> e.g.) However I will split off libgnutls-openssl in a
> separate Debian binary package.

[x] Done.
http://packages.qa.debian.org/g/gnutls26/news/20110314T153227Z.html



From joe at x2a.org  Mon Mar 14 22:44:06 2011
From: joe at x2a.org (Jonathan Bastien-Filiatrault)
Date: Mon, 14 Mar 2011 17:44:06 -0400
Subject: DTLS in gnutls
In-Reply-To: <4D7A7F3B.2070305@gnutls.org>
References: <4D7A7F3B.2070305@gnutls.org>
Message-ID: <4D7E8C26.2070607@x2a.org>

On 2011-03-11 14:59, Nikos Mavrogiannopoulos wrote:
> Hello,
>  It seems that gnutls in master repository includes a fully
> functional DTLS 1.0 (rfc4347) implementation. Kudos to Jonathan
> for creating the initial functional implementation the current
> implementation was built on.

Great ! Thanks for putting it together and getting that last 10-20% done !

> Due to DTLS' requirements for handshake, several parts of
> gnutls' handshake subsystem were rewritten to allow maximum
> re-use between the two protocols (TLS and DTLS). DTLS'
> handshake is asynchronous meaning that it might operate
> even after gnutls_handshake() is terminated (e.g. retransmit
> handshake packets lost by the peer) and this requires
> substantial changes to how gnutls' functions can be
> called in DTLS. Now I emulate the synchronous behavior
> of gnutls_handshake() by waiting for few seconds for
> possible retransmissions by peer, and this has the
> disadvantage of gnutls_handshake() taking a fixed amount
> of seconds irrespective of calculations, but requires
> no semantic changes in the rest of the functions
> (such as gnutls_record_recv()).

This is a good starting point. However, as you must be aware, this adds
latency for the blocking case and is a Really Bad Idea in the async case.

The absolute worst case is a blocking, send-only application (think
CHARGEN).

The asynchronous case can be solved simply: require applications to
monitor the receive side even if they don't read after
gnutls_handshake() and call gnutls_record_recv() when this happens. This
assumes that you keep the last flight buffered neatly somewhere, ready
to send, for a while after gnutls_handshake().

Example sequence of events:

- Bunch of writes
- Event dispatch
- Bunch of writes
- Event dispatch
- Retransmit receive
- Socket readable event
- Event dispatch
- gnutls_record_read(). Here we read the socket, process and retransmit
if required. If we have no application data, we can (ab)use GNUTLS_E_AGAIN.
- Bunch of writes
- Event dispatch
- ...

Since this only adds a requirement and does not change existing ones
much, I think this is desirable.

For the blocking case, someone needs to monitor the receive side of the
socket. gnutls_record_send could set the socket to non-blocking mode,
call gnutls_record_recv, set it back to blocking mode and do the write.
This induces dependencies on some syscalls/application function pointers.

Giving a look at YaSSL and OpenSSL might give us a clue. The
responsibilities between application and library are still fuzzy for me
in that case. Handling os-specific timers and timeouts was also a big
part of my indecision in the handshake layer.

> Another solution is to require a DTLS server/client to
> call gnutls_record_recv() on every received record, even
> if he wasn't expecting one for his application protocol
> and reserve a special error code to indicate no data for
> application...

Is this the case I elaborated above ?
> 
> 
> I don't like the latter change of semantics, but I cannot
> see any obvious way of avoiding it... If you have suggestions
> or ideas please let me know.
> 
> best regards,
> Nikos
> 

All the best,
Jonathan

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

From nmav at gnutls.org  Tue Mar 15 15:24:13 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 15 Mar 2011 15:24:13 +0100
Subject: DTLS in gnutls
In-Reply-To: <4D7E8C26.2070607@x2a.org>
References: <4D7A7F3B.2070305@gnutls.org>
	<4D7E8C26.2070607@x2a.org>
Message-ID: <AANLkTikDEv0CO7ZmhNmQvD_eav8NjKFm4MxBESf=QUe8@mail.gmail.com>

On Mon, Mar 14, 2011 at 10:44 PM, Jonathan Bastien-Filiatrault
<joe at x2a.org> wrote:

>> called in DTLS. Now I emulate the synchronous behavior
>> of gnutls_handshake() by waiting for few seconds for
>> possible retransmissions by peer, and this has the
>> disadvantage of gnutls_handshake() taking a fixed amount
>> of seconds irrespective of calculations, but requires
>> no semantic changes in the rest of the functions
>> (such as gnutls_record_recv()).
>
> This is a good starting point. However, as you must be aware, this adds
> latency for the blocking case and is a Really Bad Idea in the async case.

Indeed.

> The asynchronous case can be solved simply: require applications to
> monitor the receive side even if they don't read after
> gnutls_handshake() and call gnutls_record_recv() when this happens. This
> assumes that you keep the last flight buffered neatly somewhere, ready
> to send, for a while after gnutls_handshake().
> Example sequence of events:
> - Bunch of writes
> - Event dispatch
> - Bunch of writes
> - Event dispatch
> - Retransmit receive
> - Socket readable event
> - Event dispatch
> - gnutls_record_read(). Here we read the socket, process and retransmit
> if required. If we have no application data, we can (ab)use GNUTLS_E_AGAIN.

It seems to be the only sensible solution so far. It doesn't require
much code, but needs quite some documentation :) I was thinking into
adding another non-fatal error code such as GNUTLS_E_NO_DATA
to avoid overloading of E_AGAIN... but I'll think about it again.

regards,
Nikos



From INVALID.NOREPLY at gnu.org  Tue Mar 15 23:59:04 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Tue, 15 Mar 2011 22:59:04 +0000
Subject: [sr #107623] Priority string "SECURITY256" seemingly no longer
	supports DSA keys
In-Reply-To: <20110313-145321.sv0.73086@savannah.gnu.org>
References: <20110313-145321.sv0.73086@savannah.gnu.org>
Message-ID: <20110316-005904.sv707.1820@savannah.gnu.org>

Update of sr #107623 (project gnutls):

                  Status:                    None => In Progress            
             Assigned to:                    None => nmav                   

    _______________________________________________________

Follow-up Comment #1:

Hello,
 I've committed a fix that might solve your issue. The commit is at:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git
Patches:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=c5f804fa369d493d9587a51b7a262ced7b378811
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=67cc6539269fe8dbe6b0c436dcbc4033c92fa0dd
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=946ad46eb1ed66e5c48b881e20fd2464af7e81f8

However some notes. Gnutls prefers openpgp keys to have a DSA or RSA subkey
(ELG is not supported by TLS and using the master key is not wise). Moreover
DSA keys of more than 1024 bits are not very well defined in the TLS protocol.
The missing parts are filled in by gnutls and thus might not interoperate
correctly with other implementations. If you want to be on the safe side
either use DSA-1024 or RSA of any size.

Please let me know if the patches solve your issue.



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107623>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Tue Mar 22 17:51:34 2011
From: INVALID.NOREPLY at gnu.org (Steven Hudson)
Date: Tue, 22 Mar 2011 16:51:34 +0000
Subject: [sr #107634] Change to nettle breaks compatibility (2.11.7)
Message-ID: <20110322-165133.sv82170.13113@savannah.gnu.org>

URL:
  <http://savannah.gnu.org/support/?107634>

                 Summary: Change to nettle breaks compatibility (2.11.7)
                 Project: GnuTLS
            Submitted by: randomproof
            Submitted on: Tue 22 Mar 2011 04:51:33 PM GMT
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

The removal of gcrypt breaks lib compatibility with old apps that used
gcry_control to setup gcrypt prior to gnutls init.  While trying out gnutls
2.11.7 other apps load the new lib instead of the old one (even if the new lib
is installed into /usr/local/).  I think they are loading libgnutls.so.26
which is normally linked to libgnutls.so.26.16.14 but gets relinked to
libgnutls.so.26.18.7 when  gnutls 2.11.7 is installed.  I noticed that
libgnutlsxx.26 becomes libgnutlsxx.so.27 in 2.11.7 so why not libgnutls.so.27
?




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107634>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Tue Mar 22 18:54:25 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Tue, 22 Mar 2011 17:54:25 +0000
Subject: [sr #107634] Change to nettle breaks compatibility (2.11.7)
In-Reply-To: <20110322-165133.sv82170.13113@savannah.gnu.org>
References: <20110322-165133.sv82170.13113@savannah.gnu.org>
Message-ID: <20110322-195425.sv707.22504@savannah.gnu.org>

Update of sr #107634 (project gnutls):

                Severity:              3 - Normal => 1 - Wish               
             Assigned to:                    None => nmav                   

    _______________________________________________________

Follow-up Comment #1:

About issue (1), there is not much we can do. Applications that used
gcry_control() should be linked against libgcrypt...

About the change in libgnutlsxx sonumber, is because the ABI compatibility
broke for that library. The libgnutls library is binary compatible, thus does
not require change to .27.



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107634>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From nmav at gnutls.org  Thu Mar 24 19:40:50 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 24 Mar 2011 19:40:50 +0100
Subject: gnutls 2.12.0
Message-ID: <4D8B9032.4020003@gnutls.org>

We are proud to announce a new stable GnuTLS release: Version 2.12.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.12.0 is the first stable release on the 2.12.x branch and is
the result of 12 months of work on the experimental 2.11.x branch.  The
GnuTLS 2.12.x branch replaces the GnuTLS 2.10.x branch as the supported
stable branch, although we will continue to support GnuTLS 2.10.x for
some time.

** libgnutls: Nettle is the default crypto back end. Use
--with-libgcrypt to use the libgcrypt back end.

** libgnutls: Added PKCS #11 support and an API to access objects in
gnutls/pkcs11.h. Certificates and public keys can be
imported from tokens, and operations can be performed on private keys.

** p11tool: Introduced. It allows manipulating pkcs 11 tokens.

** libgnutls: Added an abstract interface to access public keys
and private keys in gnutls/abstract.h. It allows easy handling
of private keys and public keys of all subsystems such as pkcs11, openpgp
and x509.

** libgnutls: Added functions to ease selection of bit length in public
key algorithm key generation. Those are
gnutls_sec_param_to_pk_bits(), gnutls_pk_bits_to_sec_param(),
and gnutls_sec_param_get_name().

** libgnutls: Add new API gnutls_session_channel_binding.
The function is used to get the channel binding data.  Currently only
the "tls-unique" (RFC 5929) channel binding type is supported, through
the GNUTLS_CB_TLS_UNIQUE type.  See new section "Channel Bindings" in
the manual.

** libgnutls: Removed support for opaque PRF (it was disabled by
default in previous gnutls versions)

** libgnutls: Added gnutls_global_set_mutex() to allow setting
alternative locking procedures. By default the system available
locking is used. In *NIX pthreads are used and in windows the
critical section API. This follows a different approach than the
previous versions that depended on libgcrypt initialization. The
locks are now set by default in systems that support it. Programs
that used gcry_control() to set thread locks should insert it into
a block of
#if GNUTLS_VERSION_NUMBER <= 0x020b00
	gcry_control(...)
#endif

** libgnutls: Added support for reading DN from EV-certificates.
New DN values:
jurisdictionOfIncorporationLocalityName,
jurisdictionOfIncorporationStateOrProvinceName,
jurisdictionOfIncorporationCountryName

** gnutls-cli, gnutls-serv: Print 'tls-unique' Channel Bindings.

** libgnutls: Added RSA_NULL_SHA1 and SHA256 ciphersuites.

** libgnutls: Is now more liberal in the PEM decoding. That is spaces
and tabs are being skipped.

** libgnutls: The %COMPAT flag now allows larger records that violate
the TLS spec.

** libgnutls: Corrected signature generation and verification
in the Certificate Verify message when in TLS 1.2. Reported
by Todd A. Ouska.

** libgnutls: gnutls_x509_privkey_import() will fallback to
gnutls_x509_privkey_import_pkcs8() without a password, if it
is unable to decode the key.

** libgnutls: HMAC-MD5 no longer used by default.

** libgnutls: Corrected issue in DHE-PSK ciphersuites that ignored
the PSK callback.

** libgnutls: SRP and PSK are no longer set on the default priorities.
They have to be explicitly set.

** libgnutls: During TLS 1.2 handshake message verification using DSS
use the hash algorithm required by it. In TLS 1.0, 1.1 and SSL 3.0
SHA-1 is used always.

** libgnutls: gnutls_x509_privkey_sign_hash() is deprecated.
Use gnutls_privkey_sign_hash() instead.

** libgnutls: gnutls_pubkey_verify_data, gnutls_pubkey_verify_hash,
gnutls_x509_privkey_verify_data, gnutls_x509_crt_verify_data,
gnutls_x509_crt_verify_hash return the negative error code
GNUTLS_E_PK_SIG_VERIFY_FAILED if verification fails to simplify error
checking.

** libgnutls: Added helper functions for signature verification:
gnutls_pubkey_verify_data() and gnutls_pubkey_import_privkey().

** gnutls_x509_crl_privkey_sign2(), gnutls_x509_crq_sign2()
gnutls_x509_privkey_sign_hash(), gnutls_x509_privkey_sign_data(),
gnutls_x509_crt_verify_hash(), gnutls_x509_crt_verify_data(), were
deprecated for gnutls_x509_crl_privkey_sign(),
gnutls_x509_crq_privkey_sign(), gnutls_privkey_sign_hash(),
gnutls_privkey_sign_data(), gnutls_pubkey_verify_hash()
gnutls_pubkey_verify_data() respectively.

** libgnutls: gnutls_*_export_raw() functions now add leading zero in
integers.

** libgnutls: Added gnutls_transport_set_vec_push_function() that
can be used to specify a writev() like function. Using that gnutls
can provide more efficient writes to network layer in systems that
support it.

** libgnutls: Record version of Client Hellos is now set by default to
SSL 3.0. To restore the previous default behavior use
%LATEST_RECORD_VERSION priority string.

** libgnutls: Use ASN1_NULL when writing parameters for RSA signatures.
This makes us comply with RFC3279. Reported by Michael Rommel.

** gnutls-serv: Corrected a buffer overflow. Reported and patch by Tomas
Mraz.

** libgnutls: Reverted default behavior for verification and
introduced GNUTLS_VERIFY_DO_NOT_ALLOW_X509_V1_CA_CRT. Thus by default
V1 trusted CAs are allowed, unless the new flag is specified.

** libgnutls: Correctly add leading zero to PKCS #8 encoded DSA key.
Reported by Jeffrey Walton.

** libgnutls: Added SIGN-ALL, CTYPE-ALL, COMP-ALL, and VERS-TLS-ALL
as priority strings. Those allow to set all the supported algorithms
at once.

** libgnutls: Added support for DSA signing/verifying with bit
length over 1024.

** libgnutls-extra: When in FIPS mode gnutls_global_init_extra()
has to be called to register any required md5 handlers.



API/ABI changes in GnuTLS 2.12
==============================

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_transport_set_vec_push_function: ADDED
gnutls_x509_crl_get_raw_issuer_dn: ADDED
gnutls_session_channel_binding: New function.
gnutls_channel_binding_t: New enumeration.
gnutls_pkcs11_token_init: New function
gnutls_pkcs11_token_set_pin: New function
gnutls_x509_crt_get_subject_unique_id: ADDED.
gnutls_x509_crt_get_issuer_unique_id: ADDED.
gnutls_x509_crt_get_preferred_hash_algorithm: ADDED
gnutls_x509_privkey_export_rsa_raw2: ADDED
gnutls_openpgp_privkey_sec_param: ADDED
gnutls_x509_privkey_sec_param: ADDED
gnutls_global_set_mutex: ADDED
gnutls_rnd: ADDED
gnutls_sec_param_to_pk_bits: ADDED
gnutls_pk_bits_to_sec_param: ADDED
gnutls_sec_param_get_name: ADDED
gnutls_certificate_set_retrieve_function: ADDED
gnutls_pkcs11_type_get_name: ADDED
gnutls_pkcs11_init: ADDED
gnutls_pkcs11_deinit: ADDED
gnutls_pkcs11_set_pin_function: ADDED
gnutls_pkcs11_set_token_function: ADDED
gnutls_pkcs11_add_provider: ADDED
gnutls_pkcs11_obj_init: ADDED
gnutls_pkcs11_obj_import_url: ADDED
gnutls_pkcs11_obj_export_url: ADDED
gnutls_pkcs11_obj_deinit: ADDED
gnutls_pkcs11_obj_export: ADDED
gnutls_pkcs11_obj_list_import_url: ADDED
gnutls_pkcs11_obj_export: ADDED
gnutls_pkcs11_obj_get_type: ADDED
gnutls_pkcs11_obj_get_info: ADDED
gnutls_pkcs11_token_get_info: ADDED
gnutls_pkcs11_token_get_url: ADDED
gnutls_pkcs11_privkey_init: ADDED
gnutls_pkcs11_privkey_deinit: ADDED
gnutls_pkcs11_privkey_get_pk_algorithm: ADDED
gnutls_pkcs11_privkey_get_info: ADDED
gnutls_pkcs11_privkey_import_url: ADDED
gnutls_pkcs11_privkey_sign_data: ADDED
gnutls_pkcs11_privkey_sign_hash: ADDED
gnutls_pkcs11_privkey_decrypt_data: ADDED
gnutls_x509_crt_import_pkcs11: ADDED
gnutls_x509_crt_list_import_pkcs11: ADDED
gnutls_x509_crt_import_pkcs11_url: ADDED
gnutls_privkey_init: ADDED
gnutls_privkey_sign_hash: ADDED
gnutls_privkey_sign_data: ADDED
gnutls_privkey_deinit: ADDED
gnutls_privkey_get_pk_algorithm: ADDED
gnutls_privkey_get_type: ADDED
gnutls_privkey_import_pkcs11: ADDED
gnutls_privkey_import_x509: ADDED
gnutls_privkey_import_openpgp: ADDED
gnutls_privkey_sign_data: ADDED
gnutls_privkey_sign_hash: ADDED
gnutls_privkey_decrypt_data: ADDED
gnutls_pkcs11_privkey_export_url: ADDED
gnutls_x509_crq_privkey_sign: ADDED
gnutls_x509_crl_privkey_sign: ADDED
gnutls_x509_crt_privkey_sign: ADDED
gnutls_pubkey_init: ADDED
gnutls_pubkey_import_privkey: ADDED
gnutls_pubkey_verify_data: ADDED
gnutls_pubkey_get_preferred_hash_algorithm: ADDED
gnutls_pubkey_deinit: ADDED
gnutls_pubkey_get_pk_algorithm: ADDED
gnutls_pubkey_import_x509: ADDED
gnutls_pubkey_import_openpgp: ADDED
gnutls_pubkey_get_pk_rsa_raw: ADDED
gnutls_pubkey_get_pk_dsa_raw: ADDED
gnutls_pubkey_export: ADDED
gnutls_pubkey_get_key_id: ADDED
gnutls_pubkey_get_key_usage: ADDED
gnutls_pubkey_verify_hash: ADDED
gnutls_pubkey_get_verify_algorithm: ADDED
gnutls_pkcs11_type_get_name: ADDED
gnutls_pubkey_import_pkcs11_url: ADDED
gnutls_pubkey_import: ADDED
gnutls_pubkey_import_pkcs11: ADDED
gnutls_pubkey_import_dsa_raw: ADDED
gnutls_pubkey_import_rsa_raw: ADDED
gnutls_x509_crt_set_pubkey: ADDED
gnutls_x509_crq_set_pubkey: ADDED
gnutls_pkcs11_copy_x509_crt: ADDED
gnutls_pkcs11_copy_x509_privkey: ADDED
gnutls_pkcs11_delete_url: ADDED

The following symbols were deprecated because have been replaced
by newer functions:
gnutls_cipher_set_priority: DEPRECATED (use: gnutls_priority_set_direct)
gnutls_mac_set_priority: DEPRECATED (use: gnutls_priority_set_direct)
gnutls_compression_set_priority: DEPRECATED (use:
gnutls_priority_set_direct)
gnutls_kx_set_priority: DEPRECATED (use: gnutls_priority_set_direct)
gnutls_protocol_set_priority: DEPRECATED (use: gnutls_priority_set_direct)
gnutls_certificate_type_set_priority: DEPRECATED (use:
gnutls_priority_set_direct)
gnutls_certificate_client_retrieve_function: DEPRECATED (use:
gnutls_certificate_set_retrieve_function)
gnutls_certificate_server_retrieve_function: DEPRECATED (use:
gnutls_certificate_set_retrieve_function)
gnutls_certificate_verify_peers: DEPRECATED (use:
gnutls_certificate_verify_peers2)
gnutls_x509_crl_sign: DEPRECATED (use: gnutls_x509_crl_privkey_sign)
gnutls_x509_crl_sign2: DEPRECATED (use: gnutls_x509_crl_privkey_sign)
gnutls_x509_privkey_sign_data: DEPRECATED (use: gnutls_privkey_sign_data)
gnutls_x509_privkey_verify_data: DEPRECATED (use: gnutls_pubkey_verify_data)
gnutls_x509_crt_verify_data: DEPRECATED (use: gnutls_pubkey_verify_data)
gnutls_x509_crt_verify_hash: DEPRECATED (use: gnutls_pubkey_verify_hash)
gnutls_x509_crt_get_verify_algorithm: DEPRECATED (use:
gnutls_pubkey_get_verify_algorithm)
gnutls_x509_privkey_sign_hash: DEPRECATED (use: gnutls_privkey_sign_hash)
gnutls_x509_crq_sign2: DEPRECATED (use: gnutls_x509_crq_privkey_sign)
gnutls_x509_crq_sign: DEPRECATED (use: gnutls_x509_crq_privkey_sign)
gnutls_openpgp_privkey_sign_hash: DEPRECATED (use: gnutls_privkey_sign_hash)

Symbols deprecated because they exported internal structures, making
modification of gnutls' inner workings hard:
gnutls_session_get_server_random: DEPRECATED
gnutls_session_get_client_random: DEPRECATED
gnutls_session_get_master_secret: DEPRECATED
gnutls_session_set_finished_function: DEPRECATED
gnutls_certificate_get_x509_cas: DEPRECATED
gnutls_certificate_get_x509_crls: DEPRECATED
gnutls_certificate_get_openpgp_keyring: DEPRECATED

Deprecated symbols because functionality will not be supported in the
future:
gnutls_session_set_finished_function: DEPRECATED
gnutls_transport_set_lowat: DEPRECATED
gnutls_psk_netconf_derive_key: DEPRECATED

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

GNUTLS_CB_TLS_UNIQUE: New gnutls_channel_binding_t enum member.
GNUTLS_E_CHANNEL_BINDING_NOT_AVAILABLE: New error code.
GNUTLS_E_OPENPGP_PREFERRED_KEY_ERROR: New error code.
GNUTLS_E_INCOMPAT_DSA_KEY_WITH_TLS_PROTOCOL: New error code.
GNUTLS_E_PKCS11_ERROR: New error code.
GNUTLS_E_PKCS11_LOAD_ERROR: New error code.
GNUTLS_E_PARSING_ERROR: New error code.
GNUTLS_E_PKCS11_PIN_ERROR: New error code.
GNUTLS_E_PKCS11_SLOT_ERROR: New error code.
GNUTLS_E_LOCKING_ERROR: New error code.
GNUTLS_E_PKCS11_ATTRIBUTE_ERROR: New error code.
GNUTLS_E_PKCS11_DEVICE_ERROR: New error code.
GNUTLS_E_PKCS11_DATA_ERROR: New error code.
GNUTLS_E_PKCS11_UNSUPPORTED_FEATURE_ERROR: New error code.
GNUTLS_E_PKCS11_KEY_ERROR: New error code.
GNUTLS_E_PKCS11_PIN_EXPIRED: New error code.
GNUTLS_E_PKCS11_PIN_LOCKED: New error code.
GNUTLS_E_PKCS11_SESSION_ERROR: New error code.
GNUTLS_E_PKCS11_SIGNATURE_ERROR: New error code.
GNUTLS_E_PKCS11_TOKEN_ERROR: New error code.
GNUTLS_E_PKCS11_USER_ERROR: New error code.
GNUTLS_E_CRYPTO_INIT_FAILED: New error code.

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.12.0.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.0.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.0.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.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.12.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   3104R/96865171 2008-05-04 [expires: 2028-04-29]
      Key fingerprint = 1F42 4189 05D8 206A A754  CCDC 29EE 58B9 9686 5171
uid                  Nikos Mavrogiannopoulos <nmav at gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

The key is available from:
  http://members.hellug.gr/nmav/pgpkeys.asc

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

48f27df66c7a721c5ce2b690ab936a3c9162c40a  gnutls-2.12.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


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.


regards,
Nikos




From nmav at gnutls.org  Thu Mar 24 19:57:56 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 24 Mar 2011 19:57:56 +0100
Subject: PKCS #11 + gnutls
Message-ID: <4D8B9434.1030606@gnutls.org>

Hello,

The just-released gnutls 2.12.0 includes support for security
modules such as smart-cards via the PKCS #11 API. More
details are available at:
http://www.gnu.org/software/gnutls/manual/html_node/PKCS-_002311-tokens.html#PKCS-_002311-tokens

It should be noted however that PKCS #11 is an old
API with few problems. If you expect the PKCS #11 modules
to be used by multiple crypto libraries, we suggest that you
use the intermediate module p11-kit. It is available at:
http://p11-glue.freedesktop.org/


regards,
Nikos

PS. The 2.12.0 release contains the wrong (or better no) version
number in the NEWS file. It is a minor issue thus no release is
scheduled for that.



From hilberg at kernelconcepts.de  Fri Mar 25 10:34:49 2011
From: hilberg at kernelconcepts.de (Christian Hilberg)
Date: Fri, 25 Mar 2011 10:34:49 +0100
Subject: PKCS #11 + gnutls
In-Reply-To: <4D8B9434.1030606@gnutls.org>
References: <4D8B9434.1030606@gnutls.org>
Message-ID: <201103251035.00876.hilberg@kernelconcepts.de>

On Thu 24 March 2011, Nikos Mavrogiannopoulos wrote:
> Hello,
> 
> The just-released gnutls 2.12.0 includes support for security
> modules such as smart-cards via the PKCS #11 API. More
> details are available at:
> http://www.gnu.org/software/gnutls/manual/html_node/PKCS-_002311-tokens.htm
> l#PKCS-_002311-tokens
> 
> It should be noted however that PKCS #11 is an old
> API with few problems. If you expect the PKCS #11 modules
> to be used by multiple crypto libraries, we suggest that you
> use the intermediate module p11-kit. It is available at:
> http://p11-glue.freedesktop.org/

Aside from p11-kit, has GnuTLS PKCS #11 been tried with the OpenCryptoki [1] / 
Trousers [2] stack (or glue, whichever wording is more appropriate)? I'm 
asking just out of curiosity as we're using OpenCryptoki/Trousers and NSS 
presently, since there had not been PKCS #11 support in GnuTLS when we started 
out with our project [3], which could also profit from the now-available PKCS 
#11 support in GnuTLS.

Kind regards,

	Christian


[1] http://sourceforge.net/projects/opencryptoki/
[2] http://trousers.sourceforge.net/
[3] https://sourceforge.net/projects/evolution-kolab/

-- 
kernel concepts GbR        Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20110325/8bb05b05/attachment.pgp>

From nmav at gnutls.org  Fri Mar 25 11:34:03 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 25 Mar 2011 11:34:03 +0100
Subject: PKCS #11 + gnutls
In-Reply-To: <201103251035.00876.hilberg@kernelconcepts.de>
References: <4D8B9434.1030606@gnutls.org>
	<201103251035.00876.hilberg@kernelconcepts.de>
Message-ID: <4D8C6F9B.503@gnutls.org>

On 03/25/2011 10:34 AM, Christian Hilberg wrote:

>> It should be noted however that PKCS #11 is an old API with few
>> problems. If you expect the PKCS #11 modules to be used by multiple
>> crypto libraries, we suggest that you use the intermediate module
>> p11-kit. It is available at: http://p11-glue.freedesktop.org/
> Aside from p11-kit, has GnuTLS PKCS #11 been tried with the
> OpenCryptoki [1] / Trousers [2] stack (or glue, whichever wording is
> more appropriate)? I'm asking just out of curiosity as we're using
> OpenCryptoki/Trousers and NSS presently, since there had not been
> PKCS #11 support in GnuTLS when we started out with our project [3],
> which could also profit from the now-available PKCS #11 support in
> GnuTLS.

GnuTLS has been tried with opensc PKCS #11 module and smart-cards.
Since a very basic subset of the PKCS #11 API is used I don't expect
to be incompatibilities with the modules you mention, but if they are
please let me know.

regards,
Nikos



From hilberg at kernelconcepts.de  Fri Mar 25 14:25:49 2011
From: hilberg at kernelconcepts.de (Christian Hilberg)
Date: Fri, 25 Mar 2011 14:25:49 +0100
Subject: PKCS #11 + gnutls
In-Reply-To: <4D8C6F9B.503@gnutls.org>
References: <4D8B9434.1030606@gnutls.org>
	<201103251035.00876.hilberg@kernelconcepts.de>
	<4D8C6F9B.503@gnutls.org>
Message-ID: <201103251426.03398.hilberg@kernelconcepts.de>

Hi there,

On Fri 25 March 2011 Nikos Mavrogiannopoulos wrote:
> On 03/25/2011 10:34 AM, Christian Hilberg wrote:
> >> It should be noted however that PKCS #11 is an old API with few
> >> problems. If you expect the PKCS #11 modules to be used by multiple
> >> crypto libraries, we suggest that you use the intermediate module
> >> p11-kit. It is available at: http://p11-glue.freedesktop.org/
> > 
> > Aside from p11-kit, has GnuTLS PKCS #11 been tried with the
> > OpenCryptoki [1] / Trousers [2] stack (or glue, whichever wording is
> > more appropriate)? I'm asking just out of curiosity as we're using
> > OpenCryptoki/Trousers and NSS presently, since there had not been
> > PKCS #11 support in GnuTLS when we started out with our project [3],
> > which could also profit from the now-available PKCS #11 support in
> > GnuTLS.
> 
> GnuTLS has been tried with opensc PKCS #11 module and smart-cards.
> Since a very basic subset of the PKCS #11 API is used I don't expect
> to be incompatibilities with the modules you mention, but if they are
> please let me know.

Thanks. Sadly, we lack the time to try this right now. We'll keep an eye on 
the GIO security modules development, however, and I'd expect the topic to 
come up there sooner or later (or not, if things will settle on one or the 
other solution, but then, no need for further investigation :-).

Kind regards,

	Christian

-- 
kernel concepts GbR        Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20110325/a3148315/attachment.pgp>

From INVALID.NOREPLY at gnu.org  Fri Mar 25 17:43:01 2011
From: INVALID.NOREPLY at gnu.org (Marius Schamschula)
Date: Fri, 25 Mar 2011 16:43:01 +0000
Subject: [sr #107636] gnutls 2.12.0 Fails to build
Message-ID: <20110325-164300.sv63226.38600@savannah.gnu.org>

URL:
  <http://savannah.gnu.org/support/?107636>

                 Summary: gnutls 2.12.0 Fails to build
                 Project: GnuTLS
            Submitted by: mschamschula
            Submitted on: Fri 25 Mar 2011 04:43:00 PM GMT
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: Mac OS

    _______________________________________________________

Details:

While building gnutls 2.12.0 under Mac OS X 10.6.7 I get the following error:

make[4]: Entering directory `/private/tmp/gnutls-2.12.0/libextra'
  CCLD   libgnutls-extra.la
/usr/bin/nm: no name list
ld: duplicate symbol _ext_mod_ia in .libs/ext_inner_application.o and
.libs/gnutls_extra.o
collect2: ld returned 1 exit status
make[4]: *** [libgnutls-extra.la] Error 1
make[4]: Leaving directory `/private/tmp/gnutls-2.12.0/libextra'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/private/tmp/gnutls-2.12.0/libextra'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/private/tmp/gnutls-2.12.0/libextra'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/private/tmp/gnutls-2.12.0'
make: *** [all] Error 2





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107636>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From ametzler at downhill.at.eu.org  Fri Mar 25 19:19:21 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Fri, 25 Mar 2011 19:19:21 +0100
Subject: gnutls 2.12.0
In-Reply-To: <4D8B9032.4020003@gnutls.org>
References: <4D8B9032.4020003@gnutls.org>
Message-ID: <20110325181921.GA2562@downhill.g.la>

On 2011-03-24 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> We are proud to announce a new stable GnuTLS release: Version 2.12.0.
[...]

Hello,
I get a testsuite failure in openpgp-auth:

--------------
Self test `./openssl' finished with 0 errors
PASS: openssl
server openpgp keys The request is invalid.
client openpgp keys The request is invalid.
server handshake Could not negotiate a supported cipher suite. (-21)
--------------

At this point the test suite hangs and needs to be interrupted with
ctrl-C.

Failing output of ./openpgp-auth -v attached.

cu andreas

PS: Completely unrelated, there is a compiler warning:
gnutls_sig.c: In function '_gnutls_handshake_sign_cert_vrfy12':
gnutls_sig.c:599:17: warning: comparison between 'gnutls_digest_algorithm_t' and 'gnutls_mac_algorithm_t'
gnutls_sig.c:601:22: warning: comparison between 'gnutls_digest_algorithm_t' and 'gnutls_mac_algorithm_t'

-------------- next part --------------
A non-text attachment was scrubbed...
Name: testsuite-error-verbose.gz
Type: application/octet-stream
Size: 8067 bytes
Desc: not available
URL: </pipermail/attachments/20110325/b801f576/attachment.obj>

From nmav at gnutls.org  Fri Mar 25 20:17:31 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 25 Mar 2011 20:17:31 +0100
Subject: gnutls 2.12.0
In-Reply-To: <20110325181921.GA2562@downhill.g.la>
References: <4D8B9032.4020003@gnutls.org> <20110325181921.GA2562@downhill.g.la>
Message-ID: <4D8CEA4B.30606@gnutls.org>

On 03/25/2011 07:19 PM, Andreas Metzler wrote:
> On 2011-03-24 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>> We are proud to announce a new stable GnuTLS release: Version 2.12.0.
> [...]
> 
> Hello,
> I get a testsuite failure in openpgp-auth:
> --------------
> Self test `./openssl' finished with 0 errors
> PASS: openssl
> server openpgp keys The request is invalid.
> client openpgp keys The request is invalid.
> server handshake Could not negotiate a supported cipher suite. (-21)

Ouch, it seems the new test cases uncovered a very old issue. It isn't
2.12.0-related. Is this a 32-bit system? Does the attached patch
fix the issue? Thanks for reporting that.

regards,
Nikos
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: </pipermail/attachments/20110325/cffa2c0a/attachment.txt>

From INVALID.NOREPLY at gnu.org  Fri Mar 25 20:30:37 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Fri, 25 Mar 2011 19:30:37 +0000
Subject: [sr #107636] gnutls 2.12.0 Fails to build
In-Reply-To: <20110325-164300.sv63226.38600@savannah.gnu.org>
References: <20110325-164300.sv63226.38600@savannah.gnu.org>
Message-ID: <20110325-213037.sv707.11786@savannah.gnu.org>

Update of sr #107636 (project gnutls):

                  Status:                    None => In Progress            
             Assigned to:                    None => nmav                   

    _______________________________________________________

Follow-up Comment #1:

Thank you for reporting that. Does the attached patch fix the issue for you?

(file #23013)
    _______________________________________________________

Additional Item Attachment:

File name: patch.txt                      Size:0 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107636>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Fri Mar 25 20:31:07 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Fri, 25 Mar 2011 19:31:07 +0000
Subject: [sr #107619] Check hostname of certificate failed with two
	subdomains in hostname
In-Reply-To: <20110308-125048.sv0.6315@savannah.gnu.org>
References: <20110308-132323.sv8049.92493@savannah.gnu.org>
	<20110308-125048.sv0.6315@savannah.gnu.org>
Message-ID: <20110325-213107.sv707.46479@savannah.gnu.org>

Update of sr #107619 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107619>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Fri Mar 25 20:37:25 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Fri, 25 Mar 2011 19:37:25 +0000
Subject: [sr #107605] Uninitialized variable "md" use in
	file_verify_clearsign()
In-Reply-To: <20110226-024147.sv81876.49001@savannah.gnu.org>
References: <20110226-024147.sv81876.49001@savannah.gnu.org>
Message-ID: <20110325-213725.sv707.86817@savannah.gnu.org>

Update of sr #107605 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   

    _______________________________________________________

Follow-up Comment #1:

Nice catch. I've commited a fix (for some reason I didn't receive this report
on time, thus it will be included in the first 2.12.x bugfix release).

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107605>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Fri Mar 25 20:50:36 2011
From: INVALID.NOREPLY at gnu.org (Vitaly Kruglikov)
Date: Fri, 25 Mar 2011 19:50:36 +0000
Subject: [sr #107605] Uninitialized variable "md" use in
	file_verify_clearsign()
In-Reply-To: <20110325-213725.sv707.86817@savannah.gnu.org>
References: <20110226-024147.sv81876.49001@savannah.gnu.org>
	<20110325-213725.sv707.86817@savannah.gnu.org>
Message-ID: <20110325-195035.sv81876.96911@savannah.gnu.org>

Follow-up Comment #2, sr #107605 (project gnutls):

Actually -- Coverity flagged this and many other potential issues in gnutls
library and utilities.  I filed a few of them on this site, but there are too
many for me alone to investigate and file.  If someone on the gnutls team has
access to Coverity, I would highly recommend running it.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107605>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From mabrand at mabrand.nl  Fri Mar 25 22:05:08 2011
From: mabrand at mabrand.nl (mabrand at mabrand.nl)
Date: Fri, 25 Mar 2011 22:05:08 +0100
Subject: [PATCH] C++ compatibility fix
Message-ID: <1301087108-2334-1-git-send-email-mabrand@mabrand.nl>

From: Mark Brand <mabrand at mabrand.nl>

---
 lib/includes/gnutls/compat.h |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/lib/includes/gnutls/compat.h b/lib/includes/gnutls/compat.h
index af02d92..6f200db 100644
--- a/lib/includes/gnutls/compat.h
+++ b/lib/includes/gnutls/compat.h
@@ -114,6 +114,10 @@
 #define LIBGNUTLS_VERSION_NUMBER GNUTLS_VERSION_NUMBER
 #define LIBGNUTLS_EXTRA_VERSION GNUTLS_VERSION
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
 /* The gnutls_retr_st was deprecated by gnutls_certificate_retrieve_function()
  * and gnutls_retr2_st.
  */
@@ -345,4 +349,7 @@ gnutls_sign_callback_get (gnutls_session_t session, void **userdata)
 
   void gnutls_transport_set_lowat (gnutls_session_t session, int num) _GNUTLS_GCC_ATTR_DEPRECATED;
 
+#ifdef  __cplusplus
+}
+#endif
 #endif /* _GNUTLS_COMPAT_H */
-- 
1.7.4.1




From mabrand at mabrand.nl  Fri Mar 25 22:05:32 2011
From: mabrand at mabrand.nl (mabrand at mabrand.nl)
Date: Fri, 25 Mar 2011 22:05:32 +0100
Subject: [PATCH] add parameter vaiable to avoid gcc error
Message-ID: <1301087132-2370-1-git-send-email-mabrand@mabrand.nl>

From: Mark Brand <mabrand at mabrand.nl>

---
 lib/system.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/system.c b/lib/system.c
index f3bed5f..b795fca 100644
--- a/lib/system.c
+++ b/lib/system.c
@@ -50,7 +50,7 @@
 #ifdef _WIN32
 
 int
-system_errno (gnutls_transport_ptr)
+system_errno (gnutls_transport_ptr p)
 {
   int tmperr = WSAGetLastError ();
   int ret = 0;
-- 
1.7.4.1




From nmav at gnutls.org  Sat Mar 26 00:52:36 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 26 Mar 2011 00:52:36 +0100
Subject: [PATCH] C++ compatibility fix
In-Reply-To: <1301087108-2334-1-git-send-email-mabrand@mabrand.nl>
References: <1301087108-2334-1-git-send-email-mabrand@mabrand.nl>
Message-ID: <4D8D2AC4.4070008@gnutls.org>

On 03/25/2011 10:05 PM, mabrand at mabrand.nl wrote:
> From: Mark Brand <mabrand at mabrand.nl>
> +#ifdef __cplusplus
> +extern "C" {
> +#endif

Applied. Thank you!

regards,
Nikos



From INVALID.NOREPLY at gnu.org  Sat Mar 26 01:10:55 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sat, 26 Mar 2011 00:10:55 +0000
Subject: [sr #107604] use-after-free in cdk_stream_read()
In-Reply-To: <20110226-022459.sv81876.31391@savannah.gnu.org>
References: <20110226-022459.sv81876.31391@savannah.gnu.org>
Message-ID: <20110326-021055.sv707.73639@savannah.gnu.org>

Update of sr #107604 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

A fix has been commited.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107604>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sat Mar 26 01:11:12 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sat, 26 Mar 2011 00:11:12 +0000
Subject: [sr #107623] Priority string "SECURITY256" seemingly no longer
	supports DSA keys
In-Reply-To: <20110316-005904.sv707.1820@savannah.gnu.org>
References: <20110313-145321.sv0.73086@savannah.gnu.org>
	<20110316-005904.sv707.1820@savannah.gnu.org>
Message-ID: <20110326-021112.sv707.62518@savannah.gnu.org>

Update of sr #107623 (project gnutls):

                  Status:             In Progress => Done                   
             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107623>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sat Mar 26 01:58:14 2011
From: INVALID.NOREPLY at gnu.org (Marius Schamschula)
Date: Sat, 26 Mar 2011 00:58:14 +0000
Subject: [sr #107636] gnutls 2.12.0 Fails to build
In-Reply-To: <20110325-213037.sv707.11786@savannah.gnu.org>
References: <20110325-164300.sv63226.38600@savannah.gnu.org>
	<20110325-213037.sv707.11786@savannah.gnu.org>
Message-ID: <20110326-005814.sv63226.35924@savannah.gnu.org>

Follow-up Comment #2, sr #107636 (project gnutls):

I just tried rebuilding with the patch: Unfortunately, I get the same result.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107636>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sat Mar 26 08:19:49 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sat, 26 Mar 2011 07:19:49 +0000
Subject: [sr #107636] gnutls 2.12.0 Fails to build
In-Reply-To: <20110326-005814.sv63226.35924@savannah.gnu.org>
References: <20110325-164300.sv63226.38600@savannah.gnu.org>
	<20110325-213037.sv707.11786@savannah.gnu.org>
	<20110326-005814.sv63226.35924@savannah.gnu.org>
Message-ID: <20110326-091949.sv707.99180@savannah.gnu.org>

Follow-up Comment #3, sr #107636 (project gnutls):

Could you try a "make clean" and rebuild after the patch is applied?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107636>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sat Mar 26 11:29:22 2011
From: INVALID.NOREPLY at gnu.org (Marius Schamschula)
Date: Sat, 26 Mar 2011 10:29:22 +0000
Subject: [sr #107636] gnutls 2.12.0 Fails to build
In-Reply-To: <20110326-091949.sv707.99180@savannah.gnu.org>
References: <20110325-164300.sv63226.38600@savannah.gnu.org>
	<20110325-213037.sv707.11786@savannah.gnu.org>
	<20110326-005814.sv63226.35924@savannah.gnu.org>
	<20110326-091949.sv707.99180@savannah.gnu.org>
Message-ID: <20110326-102922.sv63226.72171@savannah.gnu.org>

Follow-up Comment #4, sr #107636 (project gnutls):

The rebuild was clean, i.e. extract from source, configure, patch and make,

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107636>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sat Mar 26 11:33:31 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sat, 26 Mar 2011 10:33:31 +0000
Subject: [sr #107636] gnutls 2.12.0 Fails to build
In-Reply-To: <20110326-102922.sv63226.72171@savannah.gnu.org>
References: <20110325-164300.sv63226.38600@savannah.gnu.org>
	<20110325-213037.sv707.11786@savannah.gnu.org>
	<20110326-005814.sv63226.35924@savannah.gnu.org>
	<20110326-091949.sv707.99180@savannah.gnu.org>
	<20110326-102922.sv63226.72171@savannah.gnu.org>
Message-ID: <20110326-123331.sv707.71043@savannah.gnu.org>

Update of sr #107636 (project gnutls):

                  Status:             In Progress => Done                   
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #5:

Ok I found the reason. A proper fix is commited and will be included in the
next release. Thank you for the report.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107636>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From arbogast.cedric at gmail.com  Sat Mar 26 15:57:18 2011
From: arbogast.cedric at gmail.com (gmail)
Date: Sat, 26 Mar 2011 15:57:18 +0100
Subject: Probable bug in openpgp
Message-ID: <4D8DFECE.7030604@gmail.com>


Hi all,

This is my first contact and mail with gnutls mailing list, to summarize 
i'm a coder maintening a personnal home server using several GNU tools 
since the late 90's.


I build GNUTLS-2.12.0 in a chroot jail (gcc 4.5.2/libc 2.13/binutils 
2.21/make 3.82) with an athlon architecture on ext3 FS and, as root,  
and notice tests/openpgp-auth freeze after few error messages :

     [root at pompomgalli] mkdir gnutls-2.12.0_build && cd gnutls-2.12.0_build

     [root at pompomgalli] ../gnutls-2.12.0/configure && make

     ...

     [root at pompomgalli] make check

     ...

     PASS: mini-x509
     PASS: mini-x509-rehandshake
     Self test `./rng-fork' finished with 0 errors
     successSelf test `./rng-fork' finished with 0 errors
     PASS: rng-fork
     Self test `./openssl' finished with 0 errors
     PASS: openssl
     server openpgp keys The request is invalid.
     client openpgp keys The request is invalid.
     server handshake Could not negotiate a supported cipher suite. (-21)

<[CTRL][C]>

     [root at pompomgalli]





I investigate by put on debugging in tests/openpgp-auth and add strace 
support relating to openpgp-auth in tests Makefile :




--- gnutls-2.12.0_build/tests/Makefile.orig     2011-03-26 
13:23:14.000000000 +0100
+++ gnutls-2.12.0_build/tests/Makefile  2011-03-26 09:52:44.000000000 +0100
@@ -1670,6 +1670,7 @@
             if test -f ./$$tst; then dir=./; \
             elif test -f $$tst; then dir=; \
             else dir="$(srcdir)/"; fi; \
+           if [ "$$tst" = "openpgp-auth" ] ; then tst="strace -o 
pgp.txt -ff $$tst" ; fi; \
             if $(TESTS_ENVIRONMENT) $${dir}$$tst; then \
               all=`expr $$all + 1`; \
               case " $(XFAIL_TESTS) " in \


--- gnutls-2.12.0/tests/openpgp-auth.c.orig     2011-03-16 
22:40:25.000000000 +0100
+++ gnutls-2.12.0/tests/openpgp-auth.c  2011-03-26 12:05:10.000000000 +0100
@@ -60,6 +60,7 @@
    const char *srcdir;
    char *pub_key_path, *priv_key_path;
    pid_t child;
+  debug=1;

    gnutls_global_init ();





And relaunch tests suite :




     [root at pompomgalli] make check

     ...

     [ 5569| 7] RB: Have 5 bytes into buffer. Adding 112 bytes.
     [ 5569| 7] RB: Requested 117 bytes
     [ 5569| 4] REC[0x8055e80]: Decrypted Packet[1] Alert(21) with length: 2
     [ 5569| 4] REC[0x8055e80]: Alert[1|0] - Close notify - was received
     Process 5777 attached
     [ 5569| 4] REC[0x8064250]: Allocating epoch #0
     [ 5569| 7] new stream `[temp]'
     [ 5569| 7] new stream fd=10
     [ 5569| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/armor.c:327
     [ 5569| 6] armor filter: decode
     [ 5569| 7] filter [temp] [read]: type=1 rc=0
     [ 5569| 7] replace stream fd=10 with fd=11
     [ 5569| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/misc.c:325
     [ 5569| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/misc.c:325
     [ 5569| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/stream.c:1002
     [ 5569| 7] close stream ref=0 `[temp]'
     [ 5569| 7] close stream fd=11
     [ 5777| 4] REC[0x8064250]: Allocating epoch #0
     [ 5569| 6] free armor filter
     [ 5569| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/stream.c:515
     [ 5569| 7] new stream `[temp]'
     [ 5569| 7] new stream fd=10
     [ 5569| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/armor.c:327
     [ 5777| 7] new stream `[temp]'
     [ 5777| 7] new stream fd=10
     [ 5777| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/armor.c:327
     [ 5777| 6] armor filter: decode
     [ 5777| 7] filter [temp] [read]: type=1 rc=0
     [ 5777| 7] replace stream fd=10 with fd=11
     [ 5777| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/misc.c:325
     [ 5777| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/misc.c:325
     [ 5777| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/stream.c:1002
     [ 5777| 7] close stream ref=0 `[temp]'
     [ 5777| 7] close stream fd=11
     [ 5777| 6] free armor filter
     [ 5777| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/stream.c:515
     [ 5777| 7] new stream `[temp]'
     [ 5777| 7] new stream fd=10
     [ 5777| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/armor.c:327
     [ 5777| 6] armor filter: decode
     [ 5777| 7] filter [temp] [read]: type=1 rc=0
     [ 5777| 7] replace stream fd=10 with fd=11
     [ 5777| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/stream.c:1002
     [ 5777| 7] close stream ref=0 `[temp]'
     [ 5777| 7] close stream fd=11
     [ 5777| 6] free armor filter
     [ 5777| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/stream.c:515
     [ 5777| 2] ASSERT: ../../gnutls-2.12.0/lib/gnutls_str.c:496
     [ 5777| 2] Error converting hex string: f30fd423c143e7ba.
     [ 5777| 2] ASSERT: 
../../../gnutls-2.12.0/lib/openpgp/gnutls_openpgp.c:414
     [ 5777| 2] ASSERT: 
../../../gnutls-2.12.0/lib/openpgp/gnutls_openpgp.c:425
     [ 5777| 2] ASSERT: 
../../../gnutls-2.12.0/lib/openpgp/gnutls_openpgp.c:509
     client openpgp keys The request is invalid.
     [ 5777| 2] ASSERT: ../../gnutls-2.12.0/lib/gnutls_constate.c:695

     ...

<[CTRL][C]>

     [root at pompomgalli]



I notice then something is probably wrong with the key id :    "[ 5777| 
2] Error converting hex string: f30fd423c143e7ba." triggered by the 
gnutls_str.c assert at line 496 which then trigger the three following 
asserts.
I have then checked the gnutls_openpgp.c method at the origin of the 
line 414 assert :


         @321 "gnutls-2.12.0/lib/openpgp/gnutls_openpgp.c"

         static int
         get_keyid (gnutls_openpgp_keyid_t keyid, const char *str)
         {
           size_t keyid_size = sizeof (keyid);

           if (strlen (str) != 16)
             {
               _gnutls_debug_log
                 ("The OpenPGP subkey ID has to be 16 hexadecimal 
characters.\n");
               return GNUTLS_E_INVALID_REQUEST;
             }

           if (_gnutls_hex2bin (str, strlen (str), keyid, &keyid_size) < 0)
             {
               _gnutls_debug_log ("Error converting hex string: %s.\n", 
str);
               return GNUTLS_E_INVALID_REQUEST;
             }

           return 0;
         }


And the _gnutls_hex2bin method that triggers the converting error message :


           @476 "gnutls-2.12.0/lib/gnutls_str.c"
           int
           _gnutls_hex2bin (const opaque * hex_data, int hex_size, 
opaque * bin_data,
                            size_t * bin_size)
           {
             int i, j;
             opaque hex2_data[3];
             unsigned long val;

             hex2_data[2] = 0;

             for (i = j = 0; i < hex_size;)
               {
                 if (!isxdigit (hex_data[i]))      /* skip non-hex such 
as the ':' in 00:FF */
                   {
                     i++;
                     continue;
                   }

                 if (j > *bin_size)
                   {
                     gnutls_assert ();
                     return GNUTLS_E_SHORT_MEMORY_BUFFER;
                   }

                 hex2_data[0] = hex_data[i];
                 hex2_data[1] = hex_data[i + 1];
                 i += 2;

                 val = strtoul ((char *) hex2_data, NULL, 16);
                 if (val == ULONG_MAX)
                   {
                     gnutls_assert ();
                     return GNUTLS_E_PARSING_ERROR;
                   }
                 bin_data[j] = val;
                 j++;
               }
             *bin_size = j;

             return 0;
           }

The line 496 assert (if (j > *bin_size)  { gnutls_assert (); return 
GNUTLS_E_SHORT_MEMORY_BUFFER;  }) is normaly triggered by an unexpected 
numbers of digits in keyid requiring too many bytes in the target binary 
buffer.
I guess then there is something wrrong with the keyid str string or the 
keyid_size. The keyid str in the log above seems correct, with 16 digits 
forming a correct hexadecimal string.
I decide to check the keyid_size :



--- gnutls-2.12.0/lib/openpgp/gnutls_openpgp.c.orig     2011-03-16 
20:53:46.000000000 +0100
+++ gnutls-2.12.0/lib/openpgp/gnutls_openpgp.c  2011-03-26 
13:18:35.000000000 +0100
@@ -332,7 +332,7 @@

    if (_gnutls_hex2bin (str, strlen (str), keyid, &keyid_size) < 0)
      {
-      _gnutls_debug_log ("Error converting hex string: %s.\n", str);
+      _gnutls_debug_log ("Error converting hex string: %s.[%d]\n", 
str,keyid_size);
        return GNUTLS_E_INVALID_REQUEST;
      }





And relaunch tests suite :





     [root at pompomgalli] make check

     ...

     [13182| 7] RB: Requested 181 bytes
     [13182| 4] REC[0x8055e80]: Decrypted Packet[2] Alert(21) with length: 2
     [13182| 4] REC[0x8055e80]: Alert[1|0] - Close notify - was received
     Process 13182 suspended
     [13184| 6] armor filter: decode
     [13184| 7] filter [temp] [read]: type=1 rc=0
     [13184| 7] replace stream fd=10 with fd=11
     [13184| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/misc.c:325
     [13184| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/misc.c:325
     [13184| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/stream.c:1002
     [13184| 7] close stream ref=0 `[temp]'
     [13184| 7] close stream fd=11
     [13184| 6] free armor filter
     [13184| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/stream.c:515
     [13184| 7] new stream `[temp]'
     [13184| 7] new stream fd=10
     [13184| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/armor.c:327
     [13184| 6] armor filter: decode
     [13184| 7] filter [temp] [read]: type=1 rc=0
     [13184| 7] replace stream fd=10 with fd=11
     [13184| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/stream.c:1002
     [13184| 7] close stream ref=0 `[temp]'
     [13184| 7] close stream fd=11
     [13184| 6] free armor filter
     [13184| 2] ASSERT: ../../../gnutls-2.12.0/lib/opencdk/stream.c:515
     [13184| 2] ASSERT: ../../gnutls-2.12.0/lib/gnutls_str.c:496
     [13184| 2] Error converting hex string: f30fd423c143e7ba.[4]
     [13184| 2] ASSERT: 
../../../gnutls-2.12.0/lib/openpgp/gnutls_openpgp.c:414
     [13184| 2] ASSERT: 
../../../gnutls-2.12.0/lib/openpgp/gnutls_openpgp.c:425
     [13184| 2] ASSERT: 
../../../gnutls-2.12.0/lib/openpgp/gnutls_openpgp.c:509
     client openpgp keys The request is invalid.
     [13184| 2] ASSERT: ../../gnutls-2.12.0/lib/gnutls_constate.c:695
     [13184| 4] REC[0x8064250]: Allocating epoch #1
     [13184| 3] HSK[0x8064250]: Keeping ciphersuite: 
DHE_DSS_AES_128_CBC_SHA1
     [13184| 3] HSK[0x8064250]: Keeping ciphersuite: 
DHE_DSS_CAMELLIA_128_CBC_SHA1
     [13184| 3] HSK[0x8064250]: Keeping ciphersuite: 
DHE_DSS_AES_256_CBC_SHA1
     [13184| 3] HSK[0x8064250]: Keeping ciphersuite: 
DHE_DSS_CAMELLIA_256_CBC_SHA1
     [13184| 3] HSK[0x8064250]: Keeping ciphersuite: 
DHE_DSS_3DES_EDE_CBC_SHA1
     [13184| 3] HSK[0x8064250]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
     [13184| 3] HSK[0x8064250]: Keeping ciphersuite: 
DHE_RSA_AES_128_CBC_SHA1
     [13184| 3] HSK[0x8064250]: Keeping ciphersuite: 
DHE_RSA_CAMELLIA_128_CBC_SHA1
     [13184| 3] HSK[0x8064250]: Keeping ciphersuite: 
DHE_RSA_AES_256_CBC_SHA1
     [13184| 3] HSK[0x8064250]: Keeping ciphersuite: 
DHE_RSA_CAMELLIA_256_CBC_SHA1


<[CTRL][C]>

     [root at pompomgalli]



The ligne  "[13184| 2] Error converting hex string: 
f30fd423c143e7ba.[4]" is self explaining, hard to store 16 digits 
hexadecimal string in 4 bytes.
The gnutls_openpgp_keyid_t type is now my main suspect and i then check 
his definition  and stuff relating to it  :

         @56 "gnutls-2.12.0/lib/includes/gnutls/openpgp.h"
           typedef unsigned char gnutls_openpgp_keyid_t[8];


         @2874 "gnutls-2.12.0/NEWS"
         gnutls_openpgp_keyid_t: ADDED, instead of hard-coded 'unsigned 
char[8]'.

         (in Version 2.3.1, released 2008-02-21 )


Bingo !

      sizeof(unsigned char[8]) return 8

  but

     sizeof(*) return ...
             4 on a 32 bits architecture
             8 on a 64 bits architecture


The issue appears at the third pass of the openpgp-auth which provides 
directly a keyid, which drives openpgp to parse the keyid.
On a 64 bits architecture, the pointer size matchs the keyid buffer size 
and then get_keyid works without any troubles.
On a 32 bits architecture, it fails as show the openpgp-auth test.

The problem is that keyid_size in the get_keyid method has to  get the 
keyid BUFFER size and not the keyid POINTER size.

A way to correct that could be to alter openpgp.h to have sizeof(keyid) 
returning BUFFER size without broke ABI compatibility :

       typedef struct { unsigned char __gnutls_openpgp_keyid_t[8]; } 
gnutls_openpgp_keyid_t;

But everything in gnutls deal with gnutls_openpgp_keyid_t  as a pointer, 
so it's seems better to directly alter "size_t keyid_size = sizeof 
(keyid); " in
gnutls_openpgp.c to "size_t keyid_size = sizeof (unsigned char[8]);" and 
doing it properly with a constant.

Here is three suggested patchs for this bug :

Patch 1 :

--- gnutls-2.12.0/lib/includes/gnutls/gnutls.h.in.orig  2011-03-23 
19:53:44.000000000 +0100
+++ gnutls-2.12.0/lib/includes/gnutls/gnutls.h.in       2011-03-26 
14:11:46.000000000 +0100
@@ -1571,6 +1571,11 @@
  #define GNUTLS_KEY_CRL_SIGN            2
  #define GNUTLS_KEY_ENCIPHER_ONLY       1
  #define GNUTLS_KEY_DECIPHER_ONLY       32768
+
+  /* specifics contants relating to keys and subkeys :
+   */
+#define GNUTLS_KEY_ID_SIZE_IN_BYTES     8
+

    void
      gnutls_certificate_set_params_function 
(gnutls_certificate_credentials_t



Patch 2 :


--- gnutls-2.12.0/lib/includes/gnutls/openpgp.h.orig    2011-02-28 
17:12:24.000000000 +0100
+++ gnutls-2.12.0/lib/includes/gnutls/openpgp.h 2011-03-26 
14:13:53.000000000 +0100
@@ -53,7 +53,7 @@
      GNUTLS_OPENPGP_FMT_BASE64
    } gnutls_openpgp_crt_fmt_t;

-  typedef unsigned char gnutls_openpgp_keyid_t[8];
+  typedef unsigned char 
gnutls_openpgp_keyid_t[GNUTLS_KEY_ID_SIZE_IN_BYTES];

  /* gnutls_openpgp_cert_t should be defined in gnutls.h
   */



Patch 3 :


--- gnutls-2.12.0/lib/openpgp/gnutls_openpgp.c.orig     2011-03-16 
20:53:46.000000000 +0100
+++ gnutls-2.12.0/lib/openpgp/gnutls_openpgp.c  2011-03-26 
14:16:04.000000000 +0100
@@ -321,7 +321,11 @@
  static int
  get_keyid (gnutls_openpgp_keyid_t keyid, const char *str)
  {
-  size_t keyid_size = sizeof (keyid);
+  /* keyid_size should get keyid buffer size,
+   * since 2008-02-21 keyid has become a pointer so
+   * sizeof(keyid) become wrong and
+   * keyid_size must be explicity given */
+  size_t keyid_size = sizeof (unsigned char[GNUTLS_KEY_ID_SIZE_IN_BYTES]);

    if (strlen (str) != 16)
      {
@@ -329,7 +333,6 @@
          ("The OpenPGP subkey ID has to be 16 hexadecimal characters.\n");
        return GNUTLS_E_INVALID_REQUEST;
      }
-
    if (_gnutls_hex2bin (str, strlen (str), keyid, &keyid_size) < 0)
      {
        _gnutls_debug_log ("Error converting hex string: %s.\n", str);



I have applied  this three patchs on my build and the openpgp-auth is 
now succesfull :


     [root at pompomgalli] make check

     ...

     PASS: mini-x509
     PASS: mini-x509-rehandshake
     Self test `./rng-fork' finished with 0 errors
     successSelf test `./rng-fork' finished with 0 errors
     PASS: rng-fork
     Self test `./openssl' finished with 0 errors
     PASS: openssl
     Self test `./openpgp-auth' finished with 0 errors
     Self test `./openpgp-auth' finished with 0 errors
     Self test `./openpgp-auth' finished with 0 errors
     Self test `./openpgp-auth' finished with 0 errors
     Self test `./openpgp-auth' finished with 0 errors
     Self test `./openpgp-auth' finished with 0 errors
     Self test `./openpgp-auth' finished with 0 errors
     Self test `./openpgp-auth' finished with 0 errors
     PASS: openpgp-auth
     Self test `./openpgp-keyring' finished with 0 errors
     PASS: openpgp-keyring
     PASS: pgps2kgnu
     Self test `./x509self' finished with 0 errors
     Self test `./x509self' finished with 0 errors

     ...


Hope this will help, i'm available for tests/infos if needed.


Regards, Cedric.




From a.radke at arcor.de  Sat Mar 26 18:19:48 2011
From: a.radke at arcor.de (Andreas Radke)
Date: Sat, 26 Mar 2011 18:19:48 +0100
Subject: gnutls 2.12.0
In-Reply-To: <4D8CEA4B.30606@gnutls.org>
References: <4D8B9032.4020003@gnutls.org> <20110325181921.GA2562@downhill.g.la>
	<4D8CEA4B.30606@gnutls.org>
Message-ID: <20110326181948.7250acc8@laptop64.home>

Am Fri, 25 Mar 2011 20:17:31 +0100
schrieb Nikos Mavrogiannopoulos <nmav at gnutls.org>:

> Ouch, it seems the new test cases uncovered a very old issue. It isn't
> 2.12.0-related. Is this a 32-bit system? Does the attached patch
> fix the issue? Thanks for reporting that.
> 
> regards,
> Nikos

Yes, this fixes the test hanging. Thanks.

-Andy



From nmav at gnutls.org  Sun Mar 27 09:27:17 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 27 Mar 2011 09:27:17 +0200
Subject: Probable bug in openpgp
In-Reply-To: <4D8DFECE.7030604@gmail.com>
References: <4D8DFECE.7030604@gmail.com>
Message-ID: <4D8EE6D5.1000107@gnutls.org>

On 03/26/2011 03:57 PM, gmail wrote:
> 
> Hi all,
> 
> This is my first contact and mail with gnutls mailing list, to summarize
> i'm a coder maintening a personnal home server using several GNU tools
> since the late 90's.

Hello, thank you for the bug report and for the fix. It seems we've
fixed it the same way. A committed fix you can try is at:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=93dee00c4ece2ff287ef6c6e60d8a8d8c057dfbf
A new version will be released next week or so.

best regards,
Nikos



From arbogast.cedric at gmail.com  Sun Mar 27 19:13:50 2011
From: arbogast.cedric at gmail.com (gmail)
Date: Sun, 27 Mar 2011 19:13:50 +0200
Subject: Not sure if it could be considered as a bug, concern the tests suite,
 let you see
Message-ID: <4D8F704E.3040204@gmail.com>

Hello,

I have build gnutls-2.12.0 in a chroot jail (gcc 4.5.2/libc 
2.13/binutils 2.21/make 3.82) on an athlon architecture as root and got 
the following trouble whi dsatest :

     [root at pompomgalli] ../gnutls-2.12.0/configure && make

     ...

     [root at pompomgalli] make check

     ...

     make[3]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     make[2]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     Making check in dsa
     make[2]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  testdsa
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[3]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[3]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Checking server DSA-1024 with client DSA-1024 and TLS 1.0
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.0
     Checking server DSA-1024 with client DSA-3072 and TLS 1.0
     ../../../gnutls-2.12.0/tests/dsa/testdsa: line 83: kill: `%1': not 
a pid or valid job spec

<[CTRL][C]>

   ^CFAIL: testdsa
     ===================================
     1 of 1 test failed
     Please report to bug-gnutls at gnu.org
     ===================================
     ...

     [root at pompomgalli]



I choose to ignore the kill notice and focus on the freeze of the test 
(a bad idea, as i will see later...),
i relaunch a second time the tests suite to check if it could be repeated :



     [root at pompomgalli] make check

     ...

     make[3]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     make[2]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     Making check in dsa
     make[2]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  testdsa
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[3]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[3]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Checking server DSA-1024 with client DSA-1024 and TLS 1.0
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.0
     Checking server DSA-1024 with client DSA-3072 and TLS 1.0
     ../../../gnutls-2.12.0/tests/dsa/testdsa: line 67: kill: `%1': not 
a pid or valid job spec
     Checking DSA-1024 with TLS 1.2
     Checking server DSA-1024 with client DSA-1024 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     *** Fatal error: The given DSA key is incompatible with the 
selected TLS protocol.
     *** Handshake has failed
     GnuTLS error: The given DSA key is incompatible with the selected 
TLS protocol.
     Failure: Failed connection to a server with a client DSA 2048 key 
and TLS 1.2!
     FAIL: testdsa
     ===================================
     1 of 1 test failed
     Please report to bug-gnutls at gnu.org
     ===================================
     ...

     [root at pompomgalli]



Apparently, something was wrong with TLS 1.2, so i turn on debugging in 
testdsa :



--- gnutls-2.12.0/tests/dsa/testdsa.orig        2011-03-23 
19:46:59.000000000 +0100
+++ gnutls-2.12.0/tests/dsa/testdsa    2011-03-27 14:01:10.000000000 +0200
@@ -24,7 +24,7 @@
  SERV="${SERV:-../../src/gnutls-serv} -q"
  CLI="${CLI:-../../src/gnutls-cli}"
  PORT="${PORT:-5559}"
-DEBUG=""
+DEBUG="-d 9"
  unset RETCODE

  fail() {



and relaunch a third time the tests suite :



     [root at pompomgalli] make check

     ...

     Checking server DSA-1024 with client DSA-2048 and TLS 1.2
     Processed 1 client certificates...
     |<2>| ASSERT: ../../gnutls-2.12.0/lib/x509_b64.c:453
     |<2>| Could not find '-----BEGIN RSA PRIVATE KEY'
     Processed 1 client X.509 certificates...
     |<4>| REC[0x8062b20]: Allocating epoch #0
     |<2>| ASSERT: ../../gnutls-2.12.0/lib/gnutls_constate.c:695
     |<4>| REC[0x8062b20]: Allocating epoch #1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: 
DHE_RSA_CAMELLIA_128_CBC_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: 
DHE_RSA_CAMELLIA_256_CBC_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA256
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: 
DHE_DSS_CAMELLIA_128_CBC_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: 
DHE_DSS_CAMELLIA_256_CBC_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
     |<3>| HSK[0x8062b20]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
     |<2>| EXT[0x8062b20]: Sending extension CERT TYPE (3 bytes)
     |<2>| EXT[0x8062b20]: Sending extension SERVER NAME (14 bytes)
     |<2>| EXT[0x8062b20]: Sending extension SAFE RENEGOTIATION (1 bytes)
     |<2>| EXT[0x8062b20]: Sending extension SESSION TICKET (0 bytes)
     |<2>| EXT[SIGA]: sent signature algo (4.2) DSA-SHA256
     |<2>| EXT[SIGA]: sent signature algo (4.1) RSA-SHA256
     |<2>| EXT[SIGA]: sent signature algo (2.1) RSA-SHA1
     |<2>| EXT[SIGA]: sent signature algo (2.2) DSA-SHA1
     |<2>| EXT[0x8062b20]: Sending extension SIGNATURE ALGORITHMS (10 bytes)
     |<3>| HSK[0x8062b20]: CLIENT HELLO was sent [139 bytes]
     |<4>| REC[0x8062b20]: Sending Packet[0] Handshake(22) with length: 139
     |<4>| REC[0x8062b20]: Sent Packet[1] Handshake(22) with length: 144
     |<4>| REC[0x8062b20]: Expected Packet[0] Handshake(22) with length: 1
     |<4>| REC[0x8062b20]: Received Packet[0] Handshake(22) with length: 85
     |<4>| REC[0x8062b20]: Decrypted Packet[0] Handshake(22) with length: 85
     |<3>| HSK[0x8062b20]: SERVER HELLO was received [85 bytes]
     |<3>| HSK[0x8062b20]: Server's version: 3.1
     |<3>| HSK[0x8062b20]: SessionID length: 32
     |<3>| HSK[0x8062b20]: SessionID: 
42fdb8a2c661db286038ab89073cbb496eace1fa7f43a23b4e5b23a91e09924a
     |<3>| HSK[0x8062b20]: Selected cipher suite: DHE_DSS_AES_128_CBC_SHA1
     |<2>| EXT[0x8062b20]: Parsing extension 'SAFE RENEGOTIATION/65281' 
(1 bytes)
     |<2>| EXT[0x8062b20]: Parsing extension 'SESSION TICKET/35' (0 bytes)
     |<3>| HSK[0x8062b20]: Safe renegotiation succeeded
     |<4>| REC[0x8062b20]: Expected Packet[1] Handshake(22) with length: 1
     |<4>| REC[0x8062b20]: Received Packet[1] Handshake(22) with length: 863
     |<4>| REC[0x8062b20]: Decrypted Packet[1] Handshake(22) with 
length: 863
     |<3>| HSK[0x8062b20]: CERTIFICATE was received [863 bytes]
     |<2>| ASSERT: ../../gnutls-2.12.0/lib/ext_signature.c:386
     |<4>| REC[0x8062b20]: Expected Packet[2] Handshake(22) with length: 1
     |<4>| REC[0x8062b20]: Received Packet[2] Handshake(22) with length: 315
     |<4>| REC[0x8062b20]: Decrypted Packet[2] Handshake(22) with 
length: 315
     |<3>| HSK[0x8062b20]: SERVER KEY EXCHANGE was received [315 bytes]
     |<4>| REC[0x8062b20]: Expected Packet[3] Handshake(22) with length: 1
     |<4>| REC[0x8062b20]: Received Packet[3] Handshake(22) with length: 9
     |<4>| REC[0x8062b20]: Decrypted Packet[3] Handshake(22) with length: 9
     |<3>| HSK[0x8062b20]: CERTIFICATE REQUEST was received [9 bytes]
     |<2>| ASSERT: ../../gnutls-2.12.0/lib/ext_signature.c:499
     |<4>| REC[0x8062b20]: Expected Packet[4] Handshake(22) with length: 1
     |<4>| REC[0x8062b20]: Received Packet[4] Handshake(22) with length: 4
     |<4>| REC[0x8062b20]: Decrypted Packet[4] Handshake(22) with length: 4
     |<3>| HSK[0x8062b20]: SERVER HELLO DONE was received [4 bytes]
     |<3>| HSK[0x8062b20]: CERTIFICATE was sent [1293 bytes]
     |<3>| HSK[0x8062b20]: CLIENT KEY EXCHANGE was sent [134 bytes]
     |<2>| ASSERT: ../../gnutls-2.12.0/lib/gnutls_sig.c:716
     |<2>| ASSERT: ../../gnutls-2.12.0/lib/auth_cert.c:1559
     |<2>| ASSERT: ../../gnutls-2.12.0/lib/gnutls_kx.c:336
     |<2>| ASSERT: ../../gnutls-2.12.0/lib/gnutls_handshake.c:2832
     *** Fatal error: The given DSA key is incompatible with the 
selected TLS protocol.
     |<4>| REC: Sending Alert[2|40] - Handshake failed
     |<4>| REC[0x8062b20]: Sending Packet[1] Alert(21) with length: 2
     |<4>| REC[0x8062b20]: Sent Packet[2] Alert(21) with length: 7
     *** Handshake has failed
     GnuTLS error: The given DSA key is incompatible with the selected 
TLS protocol.
     |<4>| REC[0x8062b20]: Epoch #0 freed
     |<4>| REC[0x8062b20]: Epoch #1 freed
     Failure: Failed connection to a server with a client DSA 2048 key 
and TLS 1.2!
     FAIL: testdsa
     ===================================
     1 of 1 test failed
     Please report to bug-gnutls at gnu.org
     ===================================
     ...

     [root at pompomgalli]


After having check the assert at line 716 in 
gnutls-2.12.0/lib/gnutls_sig.c and seen nothing wrong,
i modify it to get details on what the client get from the server :

--- gnutls-2.12.0/lib/gnutls_sig.c.orig 2011-03-23 19:46:37.000000000 +0100
+++ gnutls-2.12.0/lib/gnutls_sig.c      2011-03-27 14:47:22.000000000 +0200
@@ -712,8 +712,10 @@
      case GNUTLS_PK_DSA:
        /* ensure 1024 bit DSA keys are used */
        hash_algo = _gnutls_dsa_q_to_hash (cert->params[1]);
-      if (!_gnutls_version_has_selectable_sighash (ver) && hash_algo != 
GNUTLS_DIG_SHA1)
+      if (!_gnutls_version_has_selectable_sighash (ver) && hash_algo != 
GNUTLS_DIG_SHA1) {
+        _gnutls_debug_log ("DEBUGLOG: %d, %d, %s\n", ver, hash_algo, 
gnutls_mac_get_name (hash_algo));
          return 
gnutls_assert_val(GNUTLS_E_INCOMPAT_DSA_KEY_WITH_TLS_PROTOCOL);
+      }

        dconcat.data = &concat[16];
        dconcat.size = 20;




And relaunch, fourth time, the tests suite :


     [root at pompomgalli] make check

     ...

     |<3>| HSK[0x8062b20]: CERTIFICATE REQUEST was received [9 bytes]
     |<2>| ASSERT: ../../gnutls-2.12.0/lib/ext_signature.c:499
     |<4>| REC[0x8062b20]: Expected Packet[4] Handshake(22) with length: 1
     |<4>| REC[0x8062b20]: Received Packet[4] Handshake(22) with length: 4
     |<4>| REC[0x8062b20]: Decrypted Packet[4] Handshake(22) with length: 4
     |<3>| HSK[0x8062b20]: SERVER HELLO DONE was received [4 bytes]
     |<3>| HSK[0x8062b20]: CERTIFICATE was sent [1293 bytes]
     |<3>| HSK[0x8062b20]: CLIENT KEY EXCHANGE was sent [134 bytes]
     |<2>| DEBUGLOG: 2, 6, SHA256
     |<2>| ASSERT: ../../gnutls-2.12.0/lib/gnutls_sig.c:717
     |<2>| ASSERT: ../../gnutls-2.12.0/lib/auth_cert.c:1559
     |<2>| ASSERT: ../../gnutls-2.12.0/lib/gnutls_kx.c:336
     |<2>| ASSERT: ../../gnutls-2.12.0/lib/gnutls_handshake.c:2832
     *** Fatal error: The given DSA key is incompatible with the 
selected TLS protocol.
     |<4>| REC: Sending Alert[2|40] - Handshake failed
     |<4>| REC[0x8062b20]: Sending Packet[1] Alert(21) with length: 2
     |<4>| REC[0x8062b20]: Sent Packet[2] Alert(21) with length: 7
     *** Handshake has failed
     GnuTLS error: The given DSA key is incompatible with the selected 
TLS protocol.
     |<4>| REC[0x8062b20]: Epoch #0 freed
     |<4>| REC[0x8062b20]: Epoch #1 freed
     Failure: Failed connection to a server with a client DSA 2048 key 
and TLS 1.2!
     FAIL: testdsa
     ===================================
     1 of 1 test failed
     Please report to bug-gnutls at gnu.org
     ===================================

     ...

     [root at pompomgalli]


The value 2 in (|<2>| DEBUGLOG: 2, 6, SHA256) mean TLS 1.0, but the test 
was supposed to deal with a TLS 1.2 server at this step...
I then remember, with a shiver in the back,  the kill notice... :

     [root at pompomgalli]  ps -efa | grep tls

     root      2329 26908  0 15:01 pts/10   00:00:00 vi 
gnutls-2.12.0/tests/dsa/testd
     root      2361  7462  0 15:07 pts/2    00:00:00 grep tls
     root      5752     1  0 Mar26 pts/2    00:00:00 
/usr/src/gnutls-2.12.0_build/src

     [root at pompomgalli]  cat /proc/5752/cmdline

     
/usr/src/gnutls-2.12.0_build/src/.libs/lt-gnutls-serv-q-p5559--priorityNORMAL:-VERS-TLS-ALL:+VERS-TLS1.0--x509certfile../../../gnutls-2.12.0/tests/dsa/cert.dsa.1024.pem--x509keyfile../../../gnutls-2.12.0/tests/dsa/dsa.1024.pem

     [root at pompomgalli]


Well... The client was still discussing with the TLS 1.0 server launched 
a the first tests suite run, which was never killed...
I then modify gnutls-2.12.0/tests/dsa/testdsa to signal the fact there 
was a problem with server's launch (full patch at the end of the mail), 
remove debug mode and launch the tests suite :



     [root at pompomgalli] make check

     ...

     make[3]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     make[2]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     Making check in dsa
     make[2]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  testdsa
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[3]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[3]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Failure: Unable to launch server DSA-1024 with TLS 1.0 !
     FAIL: testdsa
     ===================================
     1 of 1 test failed
     Please report to bug-gnutls at gnu.org
     ===================================

     ...

     [root at pompomgalli]


Ok, this time the testdsa script warn about some trouble with the server 
launch from the first server launch.
It's the expected behavior, considering there is still a running server 
on the 5559 tcp port.
I finally focus on the kill notice and do some basics checks :


     [root at pompomgalli]  read &

     [1] 12466

     [root at pompomgalli]  /bin/kill %1

     kill: can't find process "%1"

     [1]+  Stopped                 read

     [root at pompomgalli]  /bin/kill --version

     kill from util-linux 2.19

     [root at pompomgalli] kill %1

     [1]+  Stopped                 read

     [root at pompomgalli]



The testdsa shell does not use shell builtin kill command and builtin 
kill command is mandatory for job control monitoring.
I then modfy the testdsa in this way :


--- gnutls-2.12.0/tests/dsa/testdsa.orig        2011-03-23 
19:46:59.000000000 +0100
+++ gnutls-2.12.0/tests/dsa/testdsa     2011-03-27 17:37:04.000000000 +0200
@@ -32,6 +32,26 @@
     exit 1
  }

+enable_bash_job_monitoring() {
+       set -m
+       enable jobs
+       enable kill
+}
+
+# Check for ps or /proc availability
+if test "$(ps 2>&1 > /dev/null; echo $?)" != "0" ; then
+        # Check for porc filesusyem
+        if test -d /proc -a -d /proc/$$ ; then
+                CHECKPS="test -d /proc/\${PROCESS}"
+        fi
+else
+        CHECKPS="test \"\$(ps -p \${PROCESS} 2>&1 > /dev/null; echo 
\$?)\" = \"0\""
+fi
+
+# Required for bash allowing job montioring bultins
+enable_bash_job_monitoring 2>&1 > /dev/null
+
+
  echo "Checking various DSA key sizes"

  # DSA 1024 + TLS 1.0
@@ -39,127 +59,166 @@
  echo "Checking DSA-1024 with TLS 1.0"

  $SERV $DEBUG -p $PORT --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0" 
--x509certfile $srcdir/cert.dsa.1024.pem --x509keyfile 
$srcdir/dsa.1024.pem >/dev/null 2>&1 &
+PROCESS=$!

  # give the server a chance to initialize
  sleep 2

-$CLI $DEBUG -p $PORT 127.0.0.1 --insecure </dev/null >/dev/null || \
-  fail "Failed connection to a server with DSA 1024 key and TLS 1.0!"
+if eval ${CHECKPS} ; then
+
+       $CLI $DEBUG -p $PORT 127.0.0.1 --insecure </dev/null >/dev/null || \
+         fail "Failed connection to a server with DSA 1024 key and TLS 
1.0!"

-echo "Checking server DSA-1024 with client DSA-1024 and TLS 1.0"
+       echo "Checking server DSA-1024 with client DSA-1024 and TLS 1.0"

-#try with client key of 1024 bits (should succeed)
-$CLI $DEBUG -p $PORT 127.0.0.1 --insecure --x509certfile 
$srcdir/cert.dsa.1024.pem --x509keyfile $srcdir/dsa.1024.pem </dev/null 
 >/dev/null || \
-  fail "Failed connection to a server with DSA 1024 key and TLS 1.0!"
+       #try with client key of 1024 bits (should succeed)
+       $CLI $DEBUG -p $PORT 127.0.0.1 --insecure --x509certfile 
$srcdir/cert.dsa.1024.pem --x509keyfile $srcdir/dsa.1024.pem </dev/null 
 >/dev/null || \
+         fail "Failed connection to a server with DSA 1024 key and TLS 
1.0!"

-echo "Checking server DSA-1024 with client DSA-2048 and TLS 1.0"
+       echo "Checking server DSA-1024 with client DSA-2048 and TLS 1.0"

-#try with client key of 2048 bits (should fail)
-$CLI $DEBUG -p $PORT 127.0.0.1 --insecure --x509certfile 
$srcdir/cert.dsa.2048.pem --x509keyfile $srcdir/dsa.2048.pem </dev/null 
 >/dev/null 2>&1 && \
-  fail "Succeeded connection to a server with a client DSA 2048 key and 
TLS 1.0!"
+       #try with client key of 2048 bits (should fail)
+       $CLI $DEBUG -p $PORT 127.0.0.1 --insecure --x509certfile 
$srcdir/cert.dsa.2048.pem --x509keyfile $srcdir/dsa.2048.pem </dev/null 
 >/dev/null 2>&1 && \
+         fail "Succeeded connection to a server with a client DSA 2048 
key and TLS 1.0!"


-echo "Checking server DSA-1024 with client DSA-3072 and TLS 1.0"
+       echo "Checking server DSA-1024 with client DSA-3072 and TLS 1.0"

-#try with client key of 3072 bits (should fail)
-$CLI $DEBUG -p $PORT 127.0.0.1 --insecure --x509certfile 
$srcdir/cert.dsa.3072.pem --x509keyfile $srcdir/dsa.3072.pem </dev/null 
 >/dev/null 2>&1 && \
-  fail "Succeeded connection to a server with a client DSA 3072 key and 
TLS 1.0!"
+       #try with client key of 3072 bits (should fail)
+       $CLI $DEBUG -p $PORT 127.0.0.1 --insecure --x509certfile 
$srcdir/cert.dsa.3072.pem --x509keyfile $srcdir/dsa.3072.pem </dev/null 
 >/dev/null 2>&1 && \
+         fail "Succeeded connection to a server with a client DSA 3072 
key and TLS 1.0!"

-kill %1
-wait
+       jobs >&2
+       kill %1
+       wait
+else
+       fail "Unable to launch server DSA-1024 with TLS 1.0 !"
+fi

  # DSA 1024 + TLS 1.2

  echo "Checking DSA-1024 with TLS 1.2"

  $SERV $DEBUG -p $PORT --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2" 
--x509certfile $srcdir/cert.dsa.1024.pem --x509keyfile 
$srcdir/dsa.1024.pem >/dev/null 2>&1 &
+PROCESS=$!

  # give the server a chance to initialize
  sleep 2

-$CLI $DEBUG -p $PORT 127.0.0.1 --insecure </dev/null >/dev/null || \
-  fail "Failed connection to a server with DSA 1024 key and TLS 1.2!"
+if eval ${CHECKPS} ; then
+
+       $CLI $DEBUG -p $PORT 127.0.0.1 --insecure </dev/null >/dev/null || \
+         fail "Failed connection to a server with DSA 1024 key and TLS 
1.2!"

-echo "Checking server DSA-1024 with client DSA-1024 and TLS 1.2"
+       echo "Checking server DSA-1024 with client DSA-1024 and TLS 1.2"

-#try with client key of 1024 bits (should succeed)
-$CLI $DEBUG -p $PORT 127.0.0.1 --insecure --x509certfile 
$srcdir/cert.dsa.1024.pem --x509keyfile $srcdir/dsa.1024.pem </dev/null 
 >/dev/null || \
-  fail "Failed connection to a server with DSA 1024 key and TLS 1.2!"
+       #try with client key of 1024 bits (should succeed)
+       $CLI $DEBUG -p $PORT 127.0.0.1 --insecure --x509certfile 
$srcdir/cert.dsa.1024.pem --x509keyfile $srcdir/dsa.1024.pem </dev/null 
 >/dev/null || \
+         fail "Failed connection to a server with DSA 1024 key and TLS 
1.2!"

-echo "Checking server DSA-1024 with client DSA-2048 and TLS 1.2"
+       echo "Checking server DSA-1024 with client DSA-2048 and TLS 1.2"

-#try with client key of 2048 bits (should succeed)
-$CLI $DEBUG -p $PORT 127.0.0.1 --insecure --x509certfile 
$srcdir/cert.dsa.2048.pem --x509keyfile $srcdir/dsa.2048.pem </dev/null 
 >/dev/null || \
-  fail "Failed connection to a server with a client DSA 2048 key and 
TLS 1.2!"
+       #try with client key of 2048 bits (should succeed)
+       $CLI $DEBUG -p $PORT 127.0.0.1 --insecure --x509certfile 
$srcdir/cert.dsa.2048.pem --x509keyfile $srcdir/dsa.2048.pem </dev/null 
 >/dev/null || \
+         fail "Failed connection to a server with a client DSA 2048 key 
and TLS 1.2!"

-echo "Checking server DSA-1024 with client DSA-3072 and TLS 1.2"
+       echo "Checking server DSA-1024 with client DSA-3072 and TLS 1.2"

-#try with client key of 3072 bits (should succeed)
-$CLI $DEBUG -p $PORT 127.0.0.1 --insecure --x509certfile 
$srcdir/cert.dsa.3072.pem --x509keyfile $srcdir/dsa.3072.pem </dev/null 
 >/dev/null || \
-  fail "Failed connection to a server with a client DSA 3072 key and 
TLS 1.2!"
+       #try with client key of 3072 bits (should succeed)
+       $CLI $DEBUG -p $PORT 127.0.0.1 --insecure --x509certfile 
$srcdir/cert.dsa.3072.pem --x509keyfile $srcdir/dsa.3072.pem </dev/null 
 >/dev/null || \
+         fail "Failed connection to a server with a client DSA 3072 key 
and TLS 1.2!"


-kill %1
-wait
+       kill %1
+       wait
+else
+       fail "Unable to launch server DSA-1024 with TLS 1.2 !"
+fi

  # DSA 2048 + TLS 1.0

  echo "Checking DSA-2048 with TLS 1.0"

  $SERV $DEBUG -p $PORT --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0" 
--x509certfile $srcdir/cert.dsa.2048.pem --x509keyfile 
$srcdir/dsa.2048.pem >/dev/null 2>&1 &
+PROCESS=$!

  # give the server a chance to initialize
  sleep 2

-$CLI $DEBUG -p $PORT 127.0.0.1 --insecure </dev/null >/dev/null 2>&1 && \
-  fail "Succeeded connection to a server with DSA 2048 key and TLS 1.0. 
Should have failed!"
+if eval ${CHECKPS} ; then

-kill %1
-wait
+       $CLI $DEBUG -p $PORT 127.0.0.1 --insecure </dev/null >/dev/null 
2>&1 && \
+         fail "Succeeded connection to a server with DSA 2048 key and 
TLS 1.0. Should have failed!"
+
+       kill %1
+       wait
+else
+       fail "Unable to launch server DSA-2048 with TLS 1.0 !"
+fi

  # DSA 2048 + TLS 1.2

  echo "Checking DSA-2048 with TLS 1.2"

  $SERV $DEBUG -p $PORT --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2" 
--x509certfile $srcdir/cert.dsa.2048.pem --x509keyfile 
$srcdir/dsa.2048.pem >/dev/null 2>&1 &
+PROCESS=$!

  # give the server a chance to initialize
  sleep 2

-$CLI $DEBUG -p $PORT 127.0.0.1 --insecure </dev/null >/dev/null || \
-  fail "Failed connection to a server with DSA 2048 key and TLS 1.2!"
+if eval ${CHECKPS} ; then
+
+       $CLI $DEBUG -p $PORT 127.0.0.1 --insecure </dev/null >/dev/null || \
+         fail "Failed connection to a server with DSA 2048 key and TLS 
1.2!"

-kill %1
-wait
+       kill %1
+       wait
+else
+       fail "Unable to launch server DSA-2048 with TLS 1.2 !"
+fi

  # DSA 3072 + TLS 1.0

  echo "Checking DSA-3072 with TLS 1.0"

  $SERV $DEBUG -p $PORT --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0" 
--x509certfile $srcdir/cert.dsa.3072.pem --x509keyfile 
$srcdir/dsa.3072.pem >/dev/null 2>&1 &
+PROCESS=$!

  # give the server a chance to initialize
  sleep 2

-$CLI $DEBUG -p $PORT 127.0.0.1 --insecure </dev/null >/dev/null 2>&1 && \
-  fail "Succeeded connection to a server with DSA 2048 key and TLS 1.0. 
Should have failed!"
+if eval ${CHECKPS} ; then
+
+       $CLI $DEBUG -p $PORT 127.0.0.1 --insecure </dev/null >/dev/null 
2>&1 && \
+         fail "Succeeded connection to a server with DSA 2048 key and 
TLS 1.0. Should have failed!"
+
+       kill %1
+       wait
+else
+       fail "Unable to launch server DSA-3072 with TLS 1.0 !"
+fi

-kill %1
-wait

  # DSA 3072 + TLS 1.2

  echo "Checking DSA-3072 with TLS 1.2"

  $SERV $DEBUG -p $PORT --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2" 
--x509certfile $srcdir/cert.dsa.3072.pem --x509keyfile 
$srcdir/dsa.3072.pem >/dev/null 2>&1 &
+PROCESS=$!

  # give the server a chance to initialize
  sleep 2

-$CLI $DEBUG -p $PORT 127.0.0.1 --insecure </dev/null >/dev/null || \
-  fail "Failed connection to a server with DSA 3072 key and TLS 1.2!"
+if eval ${CHECKPS} ; then
+
+       $CLI $DEBUG -p $PORT 127.0.0.1 --insecure </dev/null >/dev/null || \
+         fail "Failed connection to a server with DSA 3072 key and TLS 
1.2!"
+
+       kill %1
+       wait
+else
+       fail "Unable to launch server DSA-3072 with TLS 1.2 !"
+fi

-kill %1
-wait

  exit 0




And then kill the still running TLS server and relaunch the tests suite :



     [root at pompomgalli] kill 5752

     [root at pompomgalli] make check

     ...

     make[3]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     make[2]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     Making check in dsa
     make[2]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  testdsa
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[3]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[3]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Checking server DSA-1024 with client DSA-1024 and TLS 1.0
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.0
     Checking server DSA-1024 with client DSA-3072 and TLS 1.0
     [1]+  Running                 $SERV $DEBUG -p $PORT --priority 
"NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0" --x509certfile 
$srcdir/cert.dsa.1024.pem --x509keyfile $srcdir/dsa.1024.pem >/dev/null 
2>&1 &
     Checking DSA-1024 with TLS 1.2
     Checking server DSA-1024 with client DSA-1024 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-3072 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking DSA-2048 with TLS 1.0
     Checking DSA-2048 with TLS 1.2
     Checking DSA-3072 with TLS 1.0
     Checking DSA-3072 with TLS 1.2
     PASS: testdsa
     =============
     1 test passed
     =============

     ...


Finally it's successfull...

And this time, i have checked the gnutls commit's page before sending 
this report :-)

Hope this will help, best regards, Cedric.





From nmav at gnutls.org  Mon Mar 28 21:36:04 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 28 Mar 2011 21:36:04 +0200
Subject: Not sure if it could be considered as a bug, concern the tests
 suite, let you see
In-Reply-To: <4D8F704E.3040204@gmail.com>
References: <4D8F704E.3040204@gmail.com>
Message-ID: <4D90E324.3060002@gnutls.org>

On 03/27/2011 07:13 PM, gmail wrote:
> Hello,
> 
> I have build gnutls-2.12.0 in a chroot jail (gcc 4.5.2/libc
> 2.13/binutils 2.21/make 3.82) on an athlon architecture as root and got
> the following trouble whi dsatest :

Hello thank you for reporting and investigating that. I've fixed it
similarly to your proposal, but in a different way. I've committed
the fix at:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=2df3b9d72f283d6a52b1625465a9d1b07cd8d0c3
that should make the whole test bourne compatible. I hope
this will result to more systems being able to run those
tests with less issues.


best regards,
Nikos



From arbogast.cedric at gmail.com  Tue Mar 29 01:02:04 2011
From: arbogast.cedric at gmail.com (gmail)
Date: Tue, 29 Mar 2011 01:02:04 +0200
Subject: Not sure if it could be considered as a bug, concern the tests
 suite, let you see
In-Reply-To: <4D90E324.3060002@gnutls.org>
References: <4D8F704E.3040204@gmail.com> <4D90E324.3060002@gnutls.org>
Message-ID: <4D91136C.5050603@gmail.com>

Hello,

I have  applied the "bourne shell compatible" patch and launch the test 
suite, it's successfull on my build :

     [root at pompomgalli] make check

     ...
     make[3]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     make[2]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     Making check in dsa
     make[2]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  testdsa
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[3]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[3]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Checking server DSA-1024 with client DSA-1024 and TLS 1.0
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.0
     Checking server DSA-1024 with client DSA-3072 and TLS 1.0
     Checking DSA-1024 with TLS 1.2
     Checking server DSA-1024 with client DSA-1024 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-3072 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking DSA-2048 with TLS 1.0
     Checking DSA-2048 with TLS 1.2
     Checking DSA-3072 with TLS 1.0
     Checking DSA-3072 with TLS 1.2
     PASS: testdsa
     =============
     1 test passed
     =============


I then launch a daemon on port 5559 with the goal to prevent tls server 
launch and check how the test deal with potential launch failure :

     [root at pompomgalli] sshd -p 5559

     [root at pompomgalli] netstat -pan | grep 5559
      tcp        0      0 0.0.0.0:5559            
0.0.0.0:*               LISTEN      5348/sshd

     [root at pompomgalli] make check

     ...
     make[3]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     make[2]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     Making check in dsa
     make[2]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  testdsa
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[3]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[3]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     *** Fatal error: An unexpected TLS packet was received.
     *** Handshake has failed
     GnuTLS error: An unexpected TLS packet was received.
     Failure: Failed connection to a server with DSA 1024 key and TLS 1.0!
     FAIL: testdsa
     ===================================
     1 of 1 test failed
     Please report to bug-gnutls at gnu.org
     ===================================


The test correctly fail, but without mention tls_server launch has failed.
To show how this could be confusing, checking again with a forced TLS 
server 1.0 :


     [root at pompomgalli] kill 5438

     [root at pompomgalli] src/gnutls-serv -d 9 -p 5559 --priority 
"NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0" --x509certfile 
../gnutls-2.12.0/tests/dsa/cert.dsa.1024.pem --x509keyfile 
../gnutls-2.12.0/tests/dsa/dsa.1024.pem >/dev/null 2>&1 &

     [1] 7091

     [root at pompomgalli] netstat -pan | grep 5559
     tcp        0      0 0.0.0.0:5559            0.0.0.0:*               
LISTEN      7091/lt-gnutls-serv

     [root at pompomgalli] make check

     ...
     make[3]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     make[2]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     Making check in dsa
     make[2]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  testdsa
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[3]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[3]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Checking server DSA-1024 with client DSA-1024 and TLS 1.0
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.0
     Checking server DSA-1024 with client DSA-3072 and TLS 1.0
     ../../../gnutls-2.12.0/tests/dsa/testdsa: line 68: kill: (8793) - 
No such process
     Checking DSA-1024 with TLS 1.2
     Checking server DSA-1024 with client DSA-1024 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     *** Fatal error: The given DSA key is incompatible with the 
selected TLS protocol.
     *** Handshake has failed
     GnuTLS error: The given DSA key is incompatible with the selected 
TLS protocol.
     Failure: Failed connection to a server with a client DSA 2048 key 
and TLS 1.2!
     FAIL: testdsa
     ===================================
     1 of 1 test failed
     Please report to bug-gnutls at gnu.org
     ===================================



The test correclty fail,  the "./../../gnutls-2.12.0/tests/dsa/testdsa: 
line 68: kill: (8793) - No such process" gives some tips about the real 
issue but the "incompatible DSA key" messages could lead to misundertood it.

Perhaps this does not worth any efforts, but what did you think about 
this (normaly bourne compatible) patch :



--- tests/dsa/testdsa.man       2011-03-29 00:33:24.000000000 +0200
+++ tests/dsa/testdsa.cea       2011-03-29 00:27:21.000000000 +0200
@@ -32,13 +32,31 @@
     exit 1
  }

+
+launch_server() {
+       PARENT=$1;
+       shift;
+       $SERV $DEBUG -p $PORT $* >/dev/null 2>&1 &
+       LOCALPID="$!";
+       trap "[ ! -z \"${LOCALPID}\" ] && kill ${LOCALPID};" 15
+       wait "${LOCALPID}"
+       LOCALRET="$?"
+       if [ "${LOCALRET}" != "0" -a "${LOCALRET}" != "143" ] ; then
+               # Houston, we'v got a problem...
+               echo "Failed to launch a gnutls-serv server !"
+               kill -10 ${PARENT}
+       fi
+}
+
+trap "fail \"Failed to launch a gnutls-serv server, aborting dsatest... 
\"" 10
+
  echo "Checking various DSA key sizes"

  # DSA 1024 + TLS 1.0

  echo "Checking DSA-1024 with TLS 1.0"

-$SERV $DEBUG -p $PORT --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0" 
--x509certfile $srcdir/cert.dsa.1024.pem --x509keyfile 
$srcdir/dsa.1024.pem >/dev/null 2>&1 & PID=$!
+launch_server $$  --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0" 
--x509certfile $srcdir/cert.dsa.1024.pem --x509keyfile 
$srcdir/dsa.1024.pem & PID=$!
  trap "kill $PID" 1 15 2

  # give the server a chance to initialize
@@ -72,7 +90,7 @@

  echo "Checking DSA-1024 with TLS 1.2"

-$SERV $DEBUG -p $PORT --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2" 
--x509certfile $srcdir/cert.dsa.1024.pem --x509keyfile 
$srcdir/dsa.1024.pem >/dev/null 2>&1 & PID=$!
+launch_server $$  --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2" 
--x509certfile $srcdir/cert.dsa.1024.pem --x509keyfile 
$srcdir/dsa.1024.pem & PID=$!
  trap "kill $PID" 1 15 2

  # give the server a chance to initialize
@@ -107,7 +125,7 @@

  echo "Checking DSA-2048 with TLS 1.0"

-$SERV $DEBUG -p $PORT --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0" 
--x509certfile $srcdir/cert.dsa.2048.pem --x509keyfile 
$srcdir/dsa.2048.pem >/dev/null 2>&1 & PID=$!
+launch_server $$  --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0" 
--x509certfile $srcdir/cert.dsa.2048.pem --x509keyfile 
$srcdir/dsa.2048.pem & PID=$!
  trap "kill $PID" 1 15 2

  # give the server a chance to initialize
@@ -123,7 +141,7 @@

  echo "Checking DSA-2048 with TLS 1.2"

-$SERV $DEBUG -p $PORT --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2" 
--x509certfile $srcdir/cert.dsa.2048.pem --x509keyfile 
$srcdir/dsa.2048.pem >/dev/null 2>&1 & PID=$!
+launch_server $$  --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2" 
--x509certfile $srcdir/cert.dsa.2048.pem --x509keyfile 
$srcdir/dsa.2048.pem & PID=$!
  trap "kill $PID" 1 15 2

  # give the server a chance to initialize
@@ -139,7 +157,7 @@

  echo "Checking DSA-3072 with TLS 1.0"

-$SERV $DEBUG -p $PORT --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0" 
--x509certfile $srcdir/cert.dsa.3072.pem --x509keyfile 
$srcdir/dsa.3072.pem >/dev/null 2>&1 & PID=$!
+launch_server $$  --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0" 
--x509certfile $srcdir/cert.dsa.3072.pem --x509keyfile 
$srcdir/dsa.3072.pem & PID=$!
  trap "kill $PID" 1 15 2

  # give the server a chance to initialize
@@ -155,7 +173,7 @@

  echo "Checking DSA-3072 with TLS 1.2"

-$SERV $DEBUG -p $PORT --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2" 
--x509certfile $srcdir/cert.dsa.3072.pem --x509keyfile 
$srcdir/dsa.3072.pem >/dev/null 2>&1 & PID=$!
+launch_server $$  --priority "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.2" 
--x509certfile $srcdir/cert.dsa.3072.pem --x509keyfile 
$srcdir/dsa.3072.pem & PID=$!
  trap "kill $PID" 1 15 2

  # give the server a chance to initialize





The testdsa script abort properly with a gnutls server TLS 1.0 occupying 
port 5559 :

     [root at pompomgalli] netstat -pan | grep 5559
     tcp        0      0 0.0.0.0:5559            0.0.0.0:*               
LISTEN      7091/lt-gnutls-serv

     [root at pompomgalli] make check

     ...
     make[3]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     make[2]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     Making check in dsa
     make[2]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  testdsa
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[3]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[3]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Failed to launch a gnutls-serv server !
     Failure: Failed to launch a gnutls-serv server, aborting dsatest...
     FAIL: testdsa
     ===================================
     1 of 1 test failed
     Please report to bug-gnutls at gnu.org
     ===================================


It abort properly too with something on port 5559 or if the tls server 
can't start for any reason :

     [root at pompomgalli] kill 7091

     [root at pompomgalli] sshd -p 5559

     [root at pompomgalli] netstat -pan | grep 5559
     tcp        0      0 0.0.0.0:5559            0.0.0.0:*               
LISTEN      25080/sshd

     [root at pompomgalli] make check

     ...

     make[3]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     make[2]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     Making check in dsa
     make[2]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  testdsa
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[3]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[3]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Failed to launch a gnutls-serv server !
     Failure: Failed to launch a gnutls-serv server, aborting dsatest...
     FAIL: testdsa
     ===================================
     1 of 1 test failed
     Please report to bug-gnutls at gnu.org
     ===================================

     [root at pompomgalli] kill 25080

     [root at pompomgalli] netstat -pan | grep 5559

     [root at pompomgalli] echo "exit 1;" > src/gnutls-serv

     [root at pompomgalli] make check

     ...

     make[3]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     make[2]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     Making check in dsa
     make[2]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  testdsa
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[3]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[3]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Failed to launch a gnutls-serv server !
     Failure: Failed to launch a gnutls-serv server, aborting dsatest...
     FAIL: testdsa
     ===================================
     1 of 1 test failed
     Please report to bug-gnutls at gnu.org
     ===================================


And if all is ok, testdsa is successfull :

     [root at pompomgalli] rm src/gnutls-serv

     [root at pompomgalli] make check

     ...

     make[3]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     make[2]: Leaving directory 
`/usr/src/gnutls-2.12.0_build/tests/safe-renegotiation'
     Making check in dsa
     make[2]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  testdsa
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[3]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[3]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Checking server DSA-1024 with client DSA-1024 and TLS 1.0
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.0
     Checking server DSA-1024 with client DSA-3072 and TLS 1.0
     Checking DSA-1024 with TLS 1.2
     Checking server DSA-1024 with client DSA-1024 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-3072 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking DSA-2048 with TLS 1.0
     Checking DSA-2048 with TLS 1.2
     Checking DSA-3072 with TLS 1.0
     Checking DSA-3072 with TLS 1.2
     PASS: testdsa
     =============
     1 test passed
     =============


If you think it 's worth the effort, i can launch the test suite with a 
"pure" bourne shell.


Best regard, C?dric.


Le 28/03/2011 21:36, Nikos Mavrogiannopoulos a ?crit :
> On 03/27/2011 07:13 PM, gmail wrote:
>> Hello,
>>
>> I have build gnutls-2.12.0 in a chroot jail (gcc 4.5.2/libc
>> 2.13/binutils 2.21/make 3.82) on an athlon architecture as root and got
>> the following trouble whi dsatest :
> Hello thank you for reporting and investigating that. I've fixed it
> similarly to your proposal, but in a different way. I've committed
> the fix at:
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=2df3b9d72f283d6a52b1625465a9d1b07cd8d0c3
> that should make the whole test bourne compatible. I hope
> this will result to more systems being able to run those
> tests with less issues.
>
>
> best regards,
> Nikos




From nmav at gnutls.org  Tue Mar 29 10:21:23 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 29 Mar 2011 10:21:23 +0200
Subject: Not sure if it could be considered as a bug, concern the tests
 suite, let you see
In-Reply-To: <4D91136C.5050603@gmail.com>
References: <4D8F704E.3040204@gmail.com> <4D90E324.3060002@gnutls.org>
	<4D91136C.5050603@gmail.com>
Message-ID: <4D919683.4060504@gnutls.org>

On 03/29/2011 01:02 AM, gmail wrote:
> Hello,

> I then launch a daemon on port 5559 with the goal to prevent tls server
> launch and check how the test deal with potential launch failure :
[...]
> The test correctly fail, but without mention tls_server launch has failed.
> To show how this could be confusing, checking again with a forced TLS
> server 1.0 :
[...]
> The test correclty fail,  the "./../../gnutls-2.12.0/tests/dsa/testdsa:
> line 68: kill: (8793) - No such process" gives some tips about the real
> issue but the "incompatible DSA key" messages could lead to misundertood
> it.
> Perhaps this does not worth any efforts, but what did you think about
> this (normaly bourne compatible) patch :

Actually it is pretty interesting (maybe not for this release but
in general), because I would like to have more test cases as bourne
shell scripts, and having such a library would help a lot. Thanks for
the ideas and patches. I'll include it in master.

regards,
Nikos



From arbogast.cedric at gmail.com  Wed Mar 30 01:47:33 2011
From: arbogast.cedric at gmail.com (gmail)
Date: Wed, 30 Mar 2011 01:47:33 +0200
Subject: Not sure if it could be considered as a bug, concern the tests
 suite, let you see
In-Reply-To: <4D919683.4060504@gnutls.org>
References: <4D8F704E.3040204@gmail.com> <4D90E324.3060002@gnutls.org>
	<4D91136C.5050603@gmail.com> <4D919683.4060504@gnutls.org>
Message-ID: <4D926F95.6010304@gmail.com>

Hello,

I check the dsatest with a pure bourne shell (SVR4/SVID3 level), the 
heirloom Bourne Shell (http://heirloom.sourceforge.net/sh.html) , the 
test works correctly :

     [root at pompomgalli] # cd gnutls-2.12.0_build/tests/dsa

     [root at pompomgalli] # rm /bin/sh

     [root at pompomgalli] # ln -s /5bin/sh /bin/sh

     [root at pompomgalli] # make check

     make  testdsa
     make[1]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[1]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[1]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[1]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Checking server DSA-1024 with client DSA-1024 and TLS 1.0
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.0
     Checking server DSA-1024 with client DSA-3072 and TLS 1.0
     Checking DSA-1024 with TLS 1.2
     Checking server DSA-1024 with client DSA-1024 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-3072 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking DSA-2048 with TLS 1.0
     Checking DSA-2048 with TLS 1.2
     Checking DSA-3072 with TLS 1.0
     Checking DSA-3072 with TLS 1.2
     PASS: testdsa
     =============
     1 test passed
     =============
     make[1]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'

     [root at pompomgalli] # /5bin/sh --version

     [\u@\h \W]\$ <[CTRL] [D]>

     [root at pompomgalli] # /5bin/sh --v

     [\u@\h \W]\$ <[CTRL] [D]>

     [root at pompomgalli] # /5bin/sh -v

     [\u@\h \W]\$ <[CTRL] [D]>


And to be sure ...


     [root at zeus dsa] # sh

     [\u@\h \W]\$ make check

     make  testdsa
     make[1]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[1]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[1]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[1]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Checking server DSA-1024 with client DSA-1024 and TLS 1.0
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.0
     Checking server DSA-1024 with client DSA-3072 and TLS 1.0
     Checking DSA-1024 with TLS 1.2
     Checking server DSA-1024 with client DSA-1024 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-3072 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking DSA-2048 with TLS 1.0
     Checking DSA-2048 with TLS 1.2
     Checking DSA-3072 with TLS 1.0
     Checking DSA-3072 with TLS 1.2
     PASS: testdsa
     =============
     1 test passed
     =============
     make[1]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'

     [\u@\h \W]\$

     [\u@\h \W]\$ sshd -p 5559

     [\u@\h \W]\$ make check

     make  testdsa
     make[1]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[1]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[1]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[1]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Failed to launch a gnutls-serv server !
     Failure: Failed to launch a gnutls-serv server, aborting dsatest...
     FAIL: testdsa
     ===================================
     1 of 1 test failed
     Please report to bug-gnutls at gnu.org
     ===================================
     make[1]: *** [check-TESTS] Error 1
     make[1]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make: *** [check-am] Error 2

     [\u@\h \W]\$ netstat -pan | grep 5559

     tcp        0      0 0.0.0.0:5559            0.0.0.0:*               
LISTEN      11884/sshd

     [\u@\h \W]\$ kill 11884

     [\u@\h \W]\$ make check

     make  testdsa
     make[1]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[1]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[1]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[1]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Checking server DSA-1024 with client DSA-1024 and TLS 1.0
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.0
     Checking server DSA-1024 with client DSA-3072 and TLS 1.0
     Checking DSA-1024 with TLS 1.2
     Checking server DSA-1024 with client DSA-1024 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-3072 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking DSA-2048 with TLS 1.0
     Checking DSA-2048 with TLS 1.2
     Checking DSA-3072 with TLS 1.0
     Checking DSA-3072 with TLS 1.2
     PASS: testdsa
     =============
     1 test passed
     =============
     make[1]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'

     [\u@\h \W]\$ ../../src/gnutls-serv -d 9 -p 5559 --priority 
"NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0" --x509certfile 
../../../gnutls-2.12.0/tests/dsa/cert.dsa.1024.pem --x509keyfile 
../../../gnutls-2.12.0/tests/dsa/dsa.1024.pem >/dev/null 2>&1 &

     12721

     [\u@\h \W]\$ make check

     make  testdsa
     make[1]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[1]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[1]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[1]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Failed to launch a gnutls-serv server !
     Failure: Failed to launch a gnutls-serv server, aborting dsatest...
     FAIL: testdsa
     ===================================
     1 of 1 test failed
     Please report to bug-gnutls at gnu.org
     ===================================
     make[1]: *** [check-TESTS] Error 1
     make[1]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make: *** [check-am] Error 2

     [\u@\h \W]\$ kill 12721

     [\u@\h \W]\$ make check

     make  testdsa
     make[1]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make[1]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[1]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     make  check-TESTS
     make[1]: Entering directory `/usr/src/gnutls-2.12.0_build/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Checking server DSA-1024 with client DSA-1024 and TLS 1.0
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.0
     Checking server DSA-1024 with client DSA-3072 and TLS 1.0
     Checking DSA-1024 with TLS 1.2
     Checking server DSA-1024 with client DSA-1024 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-3072 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking DSA-2048 with TLS 1.0
     Checking DSA-2048 with TLS 1.2
     Checking DSA-3072 with TLS 1.0
     Checking DSA-3072 with TLS 1.2
     PASS: testdsa
     =============
     1 test passed
     =============
     make[1]: Leaving directory `/usr/src/gnutls-2.12.0_build/tests/dsa'

     [\u@\h \W]\$


    Therefore, the testdsa script seems to be fully bourne shell 
original compliant.

     (Finding sources tarball of a "pure" bourne shell was the most 
difficult part...)



     Actually, the gnutls-2.12.0_build/lib/libtool script does not work 
with the bourne shell due to syntax forms like the one used in this 
function :

               func_arith ()
               {
                 func_arith_result=$(( $* ))
               }

     Then i can't launch directly all the tests suite. I can however 
test each script one by one. Do you think it's better to adapt the tools 
scripts first or to check the test scripts first ?

     Regards, C?dric.


Le 29/03/2011 10:21, Nikos Mavrogiannopoulos a ?crit :
> On 03/29/2011 01:02 AM, gmail wrote:
>> Hello,
>> I then launch a daemon on port 5559 with the goal to prevent tls server
>> launch and check how the test deal with potential launch failure :
> [...]
>> The test correctly fail, but without mention tls_server launch has failed.
>> To show how this could be confusing, checking again with a forced TLS
>> server 1.0 :
> [...]
>> The test correclty fail,  the "./../../gnutls-2.12.0/tests/dsa/testdsa:
>> line 68: kill: (8793) - No such process" gives some tips about the real
>> issue but the "incompatible DSA key" messages could lead to misundertood
>> it.
>> Perhaps this does not worth any efforts, but what did you think about
>> this (normaly bourne compatible) patch :
> Actually it is pretty interesting (maybe not for this release but
> in general), because I would like to have more test cases as bourne
> shell scripts, and having such a library would help a lot. Thanks for
> the ideas and patches. I'll include it in master.
>
> regards,
> Nikos




From nmav at gnutls.org  Wed Mar 30 15:52:21 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 30 Mar 2011 15:52:21 +0200
Subject: Not sure if it could be considered as a bug, concern the tests
 suite, let you see
In-Reply-To: <4D926F95.6010304@gmail.com>
References: <4D8F704E.3040204@gmail.com> <4D90E324.3060002@gnutls.org>
	<4D91136C.5050603@gmail.com> <4D919683.4060504@gnutls.org>
	<4D926F95.6010304@gmail.com>
Message-ID: <4D933595.8080201@gnutls.org>

On 03/30/2011 01:47 AM, gmail wrote:

>     Actually, the gnutls-2.12.0_build/lib/libtool script does not work
> with the bourne shell due to syntax forms like the one used in this
> function :
> 
>               func_arith ()
>               {
>                 func_arith_result=$(( $* ))
>               }
> 
>     Then i can't launch directly all the tests suite. I can however test
> each script one by one. Do you think it's better to adapt the tools
> scripts first or to check the test scripts first ?

You might want to report to the libtool people
(at http://www.gnu.org/software/libtool/) about the libtool. Even if
we fix it in gnutls, it will be undone once we upgrade to the next
libtool.

regards,
Nikos



From arbogast.cedric at gmail.com  Wed Mar 30 21:39:22 2011
From: arbogast.cedric at gmail.com (gmail)
Date: Wed, 30 Mar 2011 21:39:22 +0200
Subject: Not sure if it could be considered as a bug, concern the tests
 suite, let you see
In-Reply-To: <4D933595.8080201@gnutls.org>
References: <4D8F704E.3040204@gmail.com> <4D90E324.3060002@gnutls.org>
	<4D91136C.5050603@gmail.com> <4D919683.4060504@gnutls.org>
	<4D926F95.6010304@gmail.com> <4D933595.8080201@gnutls.org>
Message-ID: <4D9386EA.8030702@gmail.com>

Hello,

I was a little tired yesterday and launch the tests suite from the wrong 
build directory, the one which was configured with bash initialy and not 
the new configured with sh...

Therefore, the makefile was running bash configured libtool with bourne 
shell original, which explain the unexpected results.



I  then relaunch the tests suite in the good build directory with sh and 
all the tests (and libtool) work correctly :


     [root at pompomgalli] # cd gnutls-2.12.0_build2

     [root at pompomgalli] # rm /bin/sh

     [root at pompomgalli] # ln -s /5bin/sh /bin/sh

     [root at pompomgalli] # mv /bin/bash /root/borg

     [root at pompomgalli] # mv /bin/ksh /root/borg2

     [root at pompomgalli] # sh

     [\u@\h \W]\$ ../gnutls-2.12.0/configure

    ...

     [\u@\h \W]\$ make

     ...

     [\u@\h \W]\$ make check

     make[3]: Leaving directory 
`/usr/src/gnutls-2.12.0_build2/tests/safe-renegotiation'
     make[2]: Leaving directory 
`/usr/src/gnutls-2.12.0_build2/tests/safe-renegotiation'
     Making check in dsa
     make[2]: Entering directory `/usr/src/gnutls-2.12.0_build2/tests/dsa'
     make  testdsa
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build2/tests/dsa'
     make[3]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/dsa/testdsa'.
     make[3]: Leaving directory `/usr/src/gnutls-2.12.0_build2/tests/dsa'
     make  check-TESTS
     make[3]: Entering directory `/usr/src/gnutls-2.12.0_build2/tests/dsa'
     Checking various DSA key sizes
     Checking DSA-1024 with TLS 1.0
     Checking server DSA-1024 with client DSA-1024 and TLS 1.0
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.0
     Checking server DSA-1024 with client DSA-3072 and TLS 1.0
     Checking DSA-1024 with TLS 1.2
     Checking server DSA-1024 with client DSA-1024 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-2048 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking server DSA-1024 with client DSA-3072 and TLS 1.2
     Processed 1 client certificates...
     Processed 1 client X.509 certificates...
     Checking DSA-2048 with TLS 1.0
     Checking DSA-2048 with TLS 1.2
     Checking DSA-3072 with TLS 1.0
     Checking DSA-3072 with TLS 1.2
     PASS: testdsa
     =============
     1 test passed
     =============
     make[3]: Leaving directory `/usr/src/gnutls-2.12.0_build2/tests/dsa'
     make[2]: Leaving directory `/usr/src/gnutls-2.12.0_build2/tests/dsa'
     Making check in openpgp-certs
     make[2]: Entering directory 
`/usr/src/gnutls-2.12.0_build2/tests/openpgp-certs'
     make  testselfsigs testcerts
     make[3]: Entering directory 
`/usr/src/gnutls-2.12.0_build2/tests/openpgp-certs'
     make[3]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/openpgp-certs/testselfsigs'.
     make[3]: Nothing to be done for 
`../../../gnutls-2.12.0/tests/openpgp-certs/testcerts'.
     make[3]: Leaving directory 
`/usr/src/gnutls-2.12.0_build2/tests/openpgp-certs'
     make  check-TESTS
     make[3]: Entering directory 
`/usr/src/gnutls-2.12.0_build2/tests/openpgp-certs'
     Checking OpenPGP certificate self verification
     PASS: testselfsigs
     =============
     1 test passed
     =============
     make[3]: Leaving directory 
`/usr/src/gnutls-2.12.0_build2/tests/openpgp-certs'
     make[2]: Leaving directory 
`/usr/src/gnutls-2.12.0_build2/tests/openpgp-certs'
     make[1]: Leaving directory `/usr/src/gnutls-2.12.0_build2/tests'
     make[1]: Entering directory `/usr/src/gnutls-2.12.0_build2'
     make[1]: Nothing to be done for `check-am'.
     make[1]: Leaving directory `/usr/src/gnutls-2.12.0_build2'
       GEN    public-submodule-commit

     [\u@\h \W]\$


Then it seems almost all even if all the tests are bourne shell original 
compliant, and there's no trouble with libtool.

Regards, Cedric.

Le 30/03/2011 15:52, Nikos Mavrogiannopoulos a ?crit :
> On 03/30/2011 01:47 AM, gmail wrote:
>
>>      Actually, the gnutls-2.12.0_build/lib/libtool script does not work
>> with the bourne shell due to syntax forms like the one used in this
>> function :
>>
>>                func_arith ()
>>                {
>>                  func_arith_result=$(( $* ))
>>                }
>>
>>      Then i can't launch directly all the tests suite. I can however test
>> each script one by one. Do you think it's better to adapt the tools
>> scripts first or to check the test scripts first ?
> You might want to report to the libtool people
> (at http://www.gnu.org/software/libtool/) about the libtool. Even if
> we fix it in gnutls, it will be undone once we upgrade to the next
> libtool.
>
> regards,
> Nikos




From bjg at gnu.org  Thu Mar 31 00:48:51 2011
From: bjg at gnu.org (Brian Gough)
Date: Wed, 30 Mar 2011 23:48:51 +0100
Subject: different lib directories for gnutls and nettle
Message-ID: <437hbgql64.wl%bjg@gnu.org>

Hi, now that GNU TLS is using nettle I notice there is a difference
between the --libdir for the two packages on 64 bit.

Nettle installs to $prefix/lib64/ and GNU TLS looks for it in
$prefix/lib/ -- so it fails and the standard configure/install to a
prefix doesn't work.

  (cd nettle-2.1 ; ./configure --prefix=/foo ; make ; make install)
  (cd gnutls-2.12.0 ; ./configure --prefix=/foo ; make ; make install)

  checking whether to use nettle... yes
  checking for libnettle... no
  configure: error: 
    ***
    *** Libnettle 2.1 was not found.

  make: *** [configure-work/gnutls-2.12.0/configure] Error 1

See http://chapters.gnu.org/~bjg/gsrc/logs/gnutls.txt for a complete
example.