From ametzler at downhill.at.eu.org  Sat Oct  1 14:31:35 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 1 Oct 2011 14:31:35 +0200
Subject: 2.12.11 includes parts of different gnulib versions
Message-ID: <20111001123135.GA2098@downhill.g.la>

Hello,

looks like some gnulib update was incomlete in 2.12.11:

(SID)gnutls-2.12.11$ head -n1 ./lib/gl/m4/float_h.m4 ./gl/m4/float_h.m4
==> ./lib/gl/m4/float_h.m4 <==
# float_h.m4 serial 7

==> ./gl/m4/float_h.m4 <==
# float_h.m4 serial 5

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 ametzler at downhill.at.eu.org  Sun Oct  2 16:08:19 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 2 Oct 2011 16:08:19 +0200
Subject: Please update gnulib (PowerPC build fix)
Message-ID: <20111002140819.GA2055@downhill.g.la>

Hello,

please update gnulib to at least
c65d65a81e9d66960ae7ce5abe5069d5b7338ed2. The version currently used
(for 2.12.x) has a testsuite error on powerpc.
http://mid.gmane.org/201109300359.31777.bruno%40clisp.org

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 ametzler at downhill.at.eu.org  Sun Oct  2 16:26:04 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 2 Oct 2011 16:26:04 +0200
Subject: 2.12.11 includes parts of different gnulib versions
In-Reply-To: <20111001123135.GA2098@downhill.g.la>
References: <20111001123135.GA2098@downhill.g.la>
Message-ID: <20111002142604.GC2055@downhill.g.la>

On 2011-10-01 Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
> Hello,

> looks like some gnulib update was incomlete in 2.12.11:

> (SID)gnutls-2.12.11$ head -n1 ./lib/gl/m4/float_h.m4 ./gl/m4/float_h.m4
> ==> ./lib/gl/m4/float_h.m4 <==
> # float_h.m4 serial 7

> ==> ./gl/m4/float_h.m4 <==
> # float_h.m4 serial 5

Hello,
looks like 1f2742f85da1aa1f4c73c44d7fdf1a8f41c82c7d is the cause,
since then only lib/gl/ has been updated, gl/ and libextra/gl/ seem to
be stale.

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  Mon Oct  3 10:15:20 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 3 Oct 2011 10:15:20 +0200
Subject: Please update gnulib (PowerPC build fix)
In-Reply-To: <20111002140819.GA2055@downhill.g.la>
References: <20111002140819.GA2055@downhill.g.la>
Message-ID: <CAJU7zaK8F-tCxSU0fJFTqNSiEF6XDXoAijC80hSq3YvRRAJ-jw@mail.gmail.com>

Noted. Will be updated in the next release.

regards,
Nikos

On Sun, Oct 2, 2011 at 4:08 PM, Andreas Metzler
<ametzler at downhill.at.eu.org> wrote:
> Hello,
>
> please update gnulib to at least
> c65d65a81e9d66960ae7ce5abe5069d5b7338ed2. The version currently used
> (for 2.12.x) has a testsuite error on powerpc.
> http://mid.gmane.org/201109300359.31777.bruno%40clisp.org
>
> 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'
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> https://lists.gnu.org/mailman/listinfo/gnutls-devel
>



From INVALID.NOREPLY at gnu.org  Mon Oct  3 11:08:50 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Mon, 03 Oct 2011 09:08:50 +0000
Subject: [sr #107822] Testing 3.0.2 on AIX
In-Reply-To: <20110930-170011.sv707.80734@savannah.gnu.org>
References: <20110928-125430.sv79827.62919@savannah.gnu.org>
	<20110928-132311.sv0.16882@savannah.gnu.org>
	<20110928-135723.sv79827.24851@savannah.gnu.org>
	<20110928-140451.sv0.84588@savannah.gnu.org>
	<20110928-162408.sv79827.98884@savannah.gnu.org>
	<20110928-165745.sv79827.49308@savannah.gnu.org>
	<20110928-232900.sv707.53794@savannah.gnu.org>
	<20110929-075006.sv79827.50491@savannah.gnu.org>
	<20110929-104705.sv79827.7753@savannah.gnu.org>
	<20110929-135104.sv79827.16087@savannah.gnu.org>
	<20110929-192206.sv707.39913@savannah.gnu.org>
	<20110930-075623.sv79827.28701@savannah.gnu.org>
	<20110930-082023.sv0.57421@savannah.gnu.org>
	<20110930-101556.sv79827.50138@savannah.gnu.org>
	<20110930-124921.sv79827.49719@savannah.gnu.org>
	<20110930-170011.sv707.80734@savannah.gnu.org>
Message-ID: <20111003-090850.sv79827.43226@savannah.gnu.org>

Follow-up Comment #16, sr #107822 (project gnutls):

gnutls_global_init have been called.

I can decode and use certs on the platfrom through the gnutls API. (what part
of certtool needs to work?)



In the function decode_ber_digest_info, it looks to me like gnutls are trying
to decode the info as and ASN1 string but at that point info holds 20 bytes
which is the SHA1 hash. 

What is info expected to hold?


in 2.10.1 all the data send forth and back were logged, is that possible with
3.0.2?
 

call stack:
	decode_ber_digest_info : gnutls_sig.o	line 780
	_pkcs1_rsa_verify_sig : gnutls_pubkey.o	
	pubkey_verify_hashed_data : gnutls_pubkey.o	
	gnutls_pubkey_verify_hash : gnutls_pubkey.o	
	verify_tls_hash : gnutls_sig.o	
	_gnutls_handshake_verify_cert_vrfy12 : gnutls_sig.o	
	_gnutls_handshake_verify_cert_vrfy : gnutls_sig.o	
	_gnutls_proc_cert_client_cert_vrfy : cert.o	
	_gnutls_recv_client_certificate_verify_message : gnutls_kx.o	
	_gnutls_handshake_server : gnutls_handshake.o	
	gnutls_handshake : gnutls_handshake.o	

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 11:23:32 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Mon, 03 Oct 2011 09:23:32 +0000
Subject: [sr #107822] Testing 3.0.2 on AIX
In-Reply-To: <20111003-090850.sv79827.43226@savannah.gnu.org>
References: <20110928-125430.sv79827.62919@savannah.gnu.org>
	<20110928-132311.sv0.16882@savannah.gnu.org>
	<20110928-135723.sv79827.24851@savannah.gnu.org>
	<20110928-140451.sv0.84588@savannah.gnu.org>
	<20110928-162408.sv79827.98884@savannah.gnu.org>
	<20110928-165745.sv79827.49308@savannah.gnu.org>
	<20110928-232900.sv707.53794@savannah.gnu.org>
	<20110929-075006.sv79827.50491@savannah.gnu.org>
	<20110929-104705.sv79827.7753@savannah.gnu.org>
	<20110929-135104.sv79827.16087@savannah.gnu.org>
	<20110929-192206.sv707.39913@savannah.gnu.org>
	<20110930-075623.sv79827.28701@savannah.gnu.org>
	<20110930-082023.sv0.57421@savannah.gnu.org>
	<20110930-101556.sv79827.50138@savannah.gnu.org>
	<20110930-124921.sv79827.49719@savannah.gnu.org>
	<20110930-170011.sv707.80734@savannah.gnu.org>
	<20111003-090850.sv79827.43226@savannah.gnu.org>
Message-ID: <20111003-092331.sv79827.91634@savannah.gnu.org>

Follow-up Comment #17, sr #107822 (project gnutls):

If I disable TLS1.2 it works!






but if I give the priority string

NORMAL:!CTYPE-OPENPGP:!VERS-TLS1.2:!ECDHE-RSA

where I try to disable  eliptic curves I get an Error when TLS1.2 is
disabled.

/bhc

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 12:44:37 2011
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Mon, 03 Oct 2011 10:44:37 +0000
Subject: [sr #107822] Testing 3.0.2 on AIX
In-Reply-To: <20111003-092331.sv79827.91634@savannah.gnu.org>
References: <20110928-125430.sv79827.62919@savannah.gnu.org>
	<20110928-132311.sv0.16882@savannah.gnu.org>
	<20110928-135723.sv79827.24851@savannah.gnu.org>
	<20110928-140451.sv0.84588@savannah.gnu.org>
	<20110928-162408.sv79827.98884@savannah.gnu.org>
	<20110928-165745.sv79827.49308@savannah.gnu.org>
	<20110928-232900.sv707.53794@savannah.gnu.org>
	<20110929-075006.sv79827.50491@savannah.gnu.org>
	<20110929-104705.sv79827.7753@savannah.gnu.org>
	<20110929-135104.sv79827.16087@savannah.gnu.org>
	<20110929-192206.sv707.39913@savannah.gnu.org>
	<20110930-075623.sv79827.28701@savannah.gnu.org>
	<20110930-082023.sv0.57421@savannah.gnu.org>
	<20110930-101556.sv79827.50138@savannah.gnu.org>
	<20110930-124921.sv79827.49719@savannah.gnu.org>
	<20110930-170011.sv707.80734@savannah.gnu.org>
	<20111003-090850.sv79827.43226@savannah.gnu.org>
	<20111003-092331.sv79827.91634@savannah.gnu.org>
Message-ID: <20111003-104437.sv0.99636@savannah.gnu.org>

Follow-up Comment #18, sr #107822 (project gnutls):

What is the type of the remote server? Could it be a server with incomplete
TLS 1.2 support (gnutls 2.8.x had one, but it was disabled by default). About
the error with the priority string what error is it? Is it reproducible with
gnutls-cli?


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 12:49:48 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Mon, 03 Oct 2011 10:49:48 +0000
Subject: [sr #107822] Testing 3.0.2 on AIX
In-Reply-To: <20111003-104437.sv0.99636@savannah.gnu.org>
References: <20110928-125430.sv79827.62919@savannah.gnu.org>
	<20110928-132311.sv0.16882@savannah.gnu.org>
	<20110928-135723.sv79827.24851@savannah.gnu.org>
	<20110928-140451.sv0.84588@savannah.gnu.org>
	<20110928-162408.sv79827.98884@savannah.gnu.org>
	<20110928-165745.sv79827.49308@savannah.gnu.org>
	<20110928-232900.sv707.53794@savannah.gnu.org>
	<20110929-075006.sv79827.50491@savannah.gnu.org>
	<20110929-104705.sv79827.7753@savannah.gnu.org>
	<20110929-135104.sv79827.16087@savannah.gnu.org>
	<20110929-192206.sv707.39913@savannah.gnu.org>
	<20110930-075623.sv79827.28701@savannah.gnu.org>
	<20110930-082023.sv0.57421@savannah.gnu.org>
	<20110930-101556.sv79827.50138@savannah.gnu.org>
	<20110930-124921.sv79827.49719@savannah.gnu.org>
	<20110930-170011.sv707.80734@savannah.gnu.org>
	<20111003-090850.sv79827.43226@savannah.gnu.org>
	<20111003-092331.sv79827.91634@savannah.gnu.org>
	<20111003-104437.sv0.99636@savannah.gnu.org>
Message-ID: <20111003-104948.sv79827.51464@savannah.gnu.org>

Follow-up Comment #19, sr #107822 (project gnutls):

The server is 3.0.2  and should support TLS-1.2 the client I used was 2.10.1 

I have not tested with gnutls-cli. I can try again and capture the stack.

/bhc

    _______________________________________________________

Reply to this item at:

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

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




From derleader at abv.bg  Mon Oct  3 12:49:44 2011
From: derleader at abv.bg (derleader mail)
Date: Mon, 3 Oct 2011 13:49:44 +0300 (EEST)
Subject: set sockets to nonblocking in GnuTLS 3.0.3
Message-ID: <132712425.54952.1317638984641.JavaMail.apache@mail23.abv.bg>

 
Hi,



 I'm interested how I can set sockets to nonblocking in GnuTLS 3.0.3.

Regards


-----------------------------------------------------------------
100 ?? ?????. ???-?????? ???????????. Tempobet.com
http://bg.tempobet.com/affiliates/3208311
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20111003/2b535090/attachment.htm>

From derleader at abv.bg  Mon Oct  3 13:02:54 2011
From: derleader at abv.bg (derleader mail)
Date: Mon, 3 Oct 2011 14:02:54 +0300 (EEST)
Subject: epoll with GnuTLS
Message-ID: <1965651241.55772.1317639774015.JavaMail.apache@mail23.abv.bg>

 
Hi,


 Is it possible to use epoll with GnuTLS for very hight loaded servers.

Regards


-----------------------------------------------------------------
100 ?? ?????. ???-?????? ???????????. Tempobet.com
http://bg.tempobet.com/affiliates/3208311
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20111003/0bd22bda/attachment.htm>

From INVALID.NOREPLY at gnu.org  Mon Oct  3 13:52:13 2011
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Mon, 03 Oct 2011 11:52:13 +0000
Subject: [sr #107822] Testing 3.0.2 on AIX
In-Reply-To: <20111003-104948.sv79827.51464@savannah.gnu.org>
References: <20110928-125430.sv79827.62919@savannah.gnu.org>
	<20110928-132311.sv0.16882@savannah.gnu.org>
	<20110928-135723.sv79827.24851@savannah.gnu.org>
	<20110928-140451.sv0.84588@savannah.gnu.org>
	<20110928-162408.sv79827.98884@savannah.gnu.org>
	<20110928-165745.sv79827.49308@savannah.gnu.org>
	<20110928-232900.sv707.53794@savannah.gnu.org>
	<20110929-075006.sv79827.50491@savannah.gnu.org>
	<20110929-104705.sv79827.7753@savannah.gnu.org>
	<20110929-135104.sv79827.16087@savannah.gnu.org>
	<20110929-192206.sv707.39913@savannah.gnu.org>
	<20110930-075623.sv79827.28701@savannah.gnu.org>
	<20110930-082023.sv0.57421@savannah.gnu.org>
	<20110930-101556.sv79827.50138@savannah.gnu.org>
	<20110930-124921.sv79827.49719@savannah.gnu.org>
	<20110930-170011.sv707.80734@savannah.gnu.org>
	<20111003-090850.sv79827.43226@savannah.gnu.org>
	<20111003-092331.sv79827.91634@savannah.gnu.org>
	<20111003-104437.sv0.99636@savannah.gnu.org>
	<20111003-104948.sv79827.51464@savannah.gnu.org>
Message-ID: <20111003-115212.sv0.24145@savannah.gnu.org>

Follow-up Comment #20, sr #107822 (project gnutls):

gnutls 2.10.x is unsupported. 2.10.1 had a bug in client certificates and TLS
1.2 which was fixed in 2.10.5 (the latest release from this branch).
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=NEWS;h=e84a83d4b072f91010c7b1cb7dff262e36e06cc7;hb=gnutls_2_10_x

I'd suggest using gnutls 2.12.x which is binary compatible with 2.10.x.


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 14:06:35 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Mon, 03 Oct 2011 12:06:35 +0000
Subject: [sr #107822] Testing 3.0.2 on AIX
In-Reply-To: <20111003-115212.sv0.24145@savannah.gnu.org>
References: <20110928-125430.sv79827.62919@savannah.gnu.org>
	<20110928-132311.sv0.16882@savannah.gnu.org>
	<20110928-135723.sv79827.24851@savannah.gnu.org>
	<20110928-140451.sv0.84588@savannah.gnu.org>
	<20110928-162408.sv79827.98884@savannah.gnu.org>
	<20110928-165745.sv79827.49308@savannah.gnu.org>
	<20110928-232900.sv707.53794@savannah.gnu.org>
	<20110929-075006.sv79827.50491@savannah.gnu.org>
	<20110929-104705.sv79827.7753@savannah.gnu.org>
	<20110929-135104.sv79827.16087@savannah.gnu.org>
	<20110929-192206.sv707.39913@savannah.gnu.org>
	<20110930-075623.sv79827.28701@savannah.gnu.org>
	<20110930-082023.sv0.57421@savannah.gnu.org>
	<20110930-101556.sv79827.50138@savannah.gnu.org>
	<20110930-124921.sv79827.49719@savannah.gnu.org>
	<20110930-170011.sv707.80734@savannah.gnu.org>
	<20111003-090850.sv79827.43226@savannah.gnu.org>
	<20111003-092331.sv79827.91634@savannah.gnu.org>
	<20111003-104437.sv0.99636@savannah.gnu.org>
	<20111003-104948.sv79827.51464@savannah.gnu.org>
	<20111003-115212.sv0.24145@savannah.gnu.org>
Message-ID: <20111003-120634.sv79827.43722@savannah.gnu.org>

Follow-up Comment #21, sr #107822 (project gnutls):

I am moving from 2.10.1 to 3.0.2, I tested the server build on 3.0.2 with the
client build on 2.10.1 to limit the range of errors. I believed the 2.10.1 to
work.

The problem on the 3.0.2 server is still that decode_ber_digest_info expect
the hash to be wrapped in ASN1.





    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 14:10:43 2011
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Mon, 03 Oct 2011 12:10:43 +0000
Subject: [sr #107822] Testing 3.0.2 on AIX
In-Reply-To: <20111003-120634.sv79827.43722@savannah.gnu.org>
References: <20110928-125430.sv79827.62919@savannah.gnu.org>
	<20110928-132311.sv0.16882@savannah.gnu.org>
	<20110928-135723.sv79827.24851@savannah.gnu.org>
	<20110928-140451.sv0.84588@savannah.gnu.org>
	<20110928-162408.sv79827.98884@savannah.gnu.org>
	<20110928-165745.sv79827.49308@savannah.gnu.org>
	<20110928-232900.sv707.53794@savannah.gnu.org>
	<20110929-075006.sv79827.50491@savannah.gnu.org>
	<20110929-104705.sv79827.7753@savannah.gnu.org>
	<20110929-135104.sv79827.16087@savannah.gnu.org>
	<20110929-192206.sv707.39913@savannah.gnu.org>
	<20110930-075623.sv79827.28701@savannah.gnu.org>
	<20110930-082023.sv0.57421@savannah.gnu.org>
	<20110930-101556.sv79827.50138@savannah.gnu.org>
	<20110930-124921.sv79827.49719@savannah.gnu.org>
	<20110930-170011.sv707.80734@savannah.gnu.org>
	<20111003-090850.sv79827.43226@savannah.gnu.org>
	<20111003-092331.sv79827.91634@savannah.gnu.org>
	<20111003-104437.sv0.99636@savannah.gnu.org>
	<20111003-104948.sv79827.51464@savannah.gnu.org>
	<20111003-115212.sv0.24145@savannah.gnu.org>
	<20111003-120634.sv79827.43722@savannah.gnu.org>
Message-ID: <20111003-121043.sv0.962@savannah.gnu.org>

Follow-up Comment #22, sr #107822 (project gnutls):

If you are using client certificates you might be seeing the bug in 2.10.1 I
mentioned about. 2.10.1 was not correctly packing data for client certificate
RSA signatures. If you want them to interoperate upgrade to 2.10.5 or 2.12.x.

3.0.x is expecting the data to be properly packed.


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 14:34:20 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Mon, 03 Oct 2011 12:34:20 +0000
Subject: [sr #107822] Testing 3.0.2 on AIX
In-Reply-To: <20111003-121043.sv0.962@savannah.gnu.org>
References: <20110928-125430.sv79827.62919@savannah.gnu.org>
	<20110928-132311.sv0.16882@savannah.gnu.org>
	<20110928-135723.sv79827.24851@savannah.gnu.org>
	<20110928-140451.sv0.84588@savannah.gnu.org>
	<20110928-162408.sv79827.98884@savannah.gnu.org>
	<20110928-165745.sv79827.49308@savannah.gnu.org>
	<20110928-232900.sv707.53794@savannah.gnu.org>
	<20110929-075006.sv79827.50491@savannah.gnu.org>
	<20110929-104705.sv79827.7753@savannah.gnu.org>
	<20110929-135104.sv79827.16087@savannah.gnu.org>
	<20110929-192206.sv707.39913@savannah.gnu.org>
	<20110930-075623.sv79827.28701@savannah.gnu.org>
	<20110930-082023.sv0.57421@savannah.gnu.org>
	<20110930-101556.sv79827.50138@savannah.gnu.org>
	<20110930-124921.sv79827.49719@savannah.gnu.org>
	<20110930-170011.sv707.80734@savannah.gnu.org>
	<20111003-090850.sv79827.43226@savannah.gnu.org>
	<20111003-092331.sv79827.91634@savannah.gnu.org>
	<20111003-104437.sv0.99636@savannah.gnu.org>
	<20111003-104948.sv79827.51464@savannah.gnu.org>
	<20111003-115212.sv0.24145@savannah.gnu.org>
	<20111003-120634.sv79827.43722@savannah.gnu.org>
	<20111003-121043.sv0.962@savannah.gnu.org>
Message-ID: <20111003-123420.sv79827.95960@savannah.gnu.org>

Follow-up Comment #23, sr #107822 (project gnutls):

Hangon a bit!

does the means that 2.10.5, 2.12.x and 3.0.x all wraps the hash in ASN1, when
they are using TLS-1.2? 

see #107785

/bhc

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 14:35:25 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Mon, 03 Oct 2011 12:35:25 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
Message-ID: <20111003-123524.sv79827.16222@savannah.gnu.org>

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

                 Summary: Build GnuTLS 3.0.2 for windows!
                 Project: GnuTLS
            Submitted by: cybear
            Submitted on: Mon Oct  3 12:35:24 2011
                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: None

    _______________________________________________________

Details:






    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 14:38:02 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Mon, 03 Oct 2011 12:38:02 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111003-123524.sv79827.16222@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
Message-ID: <20111003-123802.sv79827.15794@savannah.gnu.org>

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

That was a little to short!

I can not compile nettle/rnd.c
I think it is needed to include <windows.h> and <wincrypt.h> to have
HCRYPTPROV defined.


egd.c also have a problem it includes <sys/un.h> which does not exist on
windows. 

Please Advise


/bhc



    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 15:00:14 2011
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Mon, 03 Oct 2011 13:00:14 +0000
Subject: [sr #107822] Testing 3.0.2 on AIX
In-Reply-To: <20111003-123420.sv79827.95960@savannah.gnu.org>
References: <20110928-125430.sv79827.62919@savannah.gnu.org>
	<20110928-132311.sv0.16882@savannah.gnu.org>
	<20110928-135723.sv79827.24851@savannah.gnu.org>
	<20110928-140451.sv0.84588@savannah.gnu.org>
	<20110928-162408.sv79827.98884@savannah.gnu.org>
	<20110928-165745.sv79827.49308@savannah.gnu.org>
	<20110928-232900.sv707.53794@savannah.gnu.org>
	<20110929-075006.sv79827.50491@savannah.gnu.org>
	<20110929-104705.sv79827.7753@savannah.gnu.org>
	<20110929-135104.sv79827.16087@savannah.gnu.org>
	<20110929-192206.sv707.39913@savannah.gnu.org>
	<20110930-075623.sv79827.28701@savannah.gnu.org>
	<20110930-082023.sv0.57421@savannah.gnu.org>
	<20110930-101556.sv79827.50138@savannah.gnu.org>
	<20110930-124921.sv79827.49719@savannah.gnu.org>
	<20110930-170011.sv707.80734@savannah.gnu.org>
	<20111003-090850.sv79827.43226@savannah.gnu.org>
	<20111003-092331.sv79827.91634@savannah.gnu.org>
	<20111003-104437.sv0.99636@savannah.gnu.org>
	<20111003-104948.sv79827.51464@savannah.gnu.org>
	<20111003-115212.sv0.24145@savannah.gnu.org>
	<20111003-120634.sv79827.43722@savannah.gnu.org>
	<20111003-121043.sv0.962@savannah.gnu.org>
	<20111003-123420.sv79827.95960@savannah.gnu.org>
Message-ID: <20111003-130013.sv0.371@savannah.gnu.org>

Follow-up Comment #24, sr #107822 (project gnutls):

Indeed. Check http://tools.ietf.org/html/rfc5246#section-4.7 for the details.
This is a good argument for me to disable TLS 1.2 silently if sign_callback is
set.

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 15:03:28 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Mon, 03 Oct 2011 13:03:28 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111003-123802.sv79827.15794@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
Message-ID: <20111003-130328.sv79827.54599@savannah.gnu.org>

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

Is it correct that egd.c is not used when _WIN32 is defined.


_rndegd_connect_socket is only called from the POSIX section of rnd.c


can all of egd.c be removed for windows?


/bhc


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 15:04:06 2011
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Mon, 03 Oct 2011 13:04:06 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111003-130328.sv79827.54599@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
	<20111003-130328.sv79827.54599@savannah.gnu.org>
Message-ID: <20111003-130406.sv0.78656@savannah.gnu.org>

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

So does including wincrypt.h fixes the issue in nettle/rnd.c?
For egd.c you don't need it. Add an #ifndef _WIN32 after include config.h.


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 15:11:52 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Mon, 03 Oct 2011 13:11:52 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111003-130406.sv0.78656@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
	<20111003-130328.sv79827.54599@savannah.gnu.org>
	<20111003-130406.sv0.78656@savannah.gnu.org>
Message-ID: <20111003-131152.sv79827.45963@savannah.gnu.org>

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

Including wincrypt.h makes the rnd.c compile with warnings.

But I suspect that the warnings are because I have an old version of the cross
compiler HCRYPTPROV is define as ULONG where real windows declares it as ULONG
*.

I cannot cover all of egd.c with #ifndef _WIN32 unless I also do it for the
headerfile.

Or leave some empty function for the defined function in the header file. 

What do you normally do?
 

    _______________________________________________________

Reply to this item at:

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

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




From nmav at gnutls.org  Mon Oct  3 15:17:23 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 3 Oct 2011 15:17:23 +0200
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111003-131152.sv79827.45963@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
	<20111003-130328.sv79827.54599@savannah.gnu.org>
	<20111003-130406.sv0.78656@savannah.gnu.org>
	<20111003-131152.sv79827.45963@savannah.gnu.org>
Message-ID: <CAJU7zaLRYfSYriKWaWih2+Yj+3t=DMSpCBw5f1G_KieOQ5c4=w@mail.gmail.com>

2011/10/3 Bj?rn Christensen <INVALID.NOREPLY at gnu.org>:
> I cannot cover all of egd.c with #ifndef _WIN32 unless I also do it for the
> headerfile.
> Or leave some empty function for the defined function in the header file.

Do you mean that a patch like the attached issues an error?
-------------- next part --------------
diff --git a/lib/nettle/egd.c b/lib/nettle/egd.c
index f472aed..7defc18 100644
--- a/lib/nettle/egd.c
+++ b/lib/nettle/egd.c
@@ -19,6 +19,9 @@
  */
 
 #include <config.h>
+
+#ifndef _WIN32
+
 #include <stdio.h>
 #include <stdlib.h>
 #include <errno.h>
@@ -268,3 +271,5 @@ restart:
 
   return _length;               /* success */
 }
+
+#endif /* _WIN32 */

From bhc at insight.dk  Mon Oct  3 15:19:30 2011
From: bhc at insight.dk (=?utf-8?B?QmrDuHJuIENocmlzdGVuc2Vu?=)
Date: Mon, 3 Oct 2011 15:19:30 +0200
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
Message-ID: <83D596805E41464EB382DFEEB6232D5487E3A5@shelob.Insight.local>

Sorry 

You are right the patch solved the problem, I made a typo.


/bhc

-----Original Message-----
From: n.mavrogiannopoulos at gmail.com [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos
Sent: 3. oktober 2011 15:17
To: Bj?rn Christensen; gnutls-devel at gnu.org
Subject: Re: [sr #107827] Build GnuTLS 3.0.2 for windows!

2011/10/3 Bj?rn Christensen <INVALID.NOREPLY at gnu.org>:
> I cannot cover all of egd.c with #ifndef _WIN32 unless I also do it 
> for the headerfile.
> Or leave some empty function for the defined function in the header file.

Do you mean that a patch like the attached issues an error?

From INVALID.NOREPLY at gnu.org  Mon Oct  3 16:05:39 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Mon, 03 Oct 2011 14:05:39 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111003-131152.sv79827.45963@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
	<20111003-130328.sv79827.54599@savannah.gnu.org>
	<20111003-130406.sv0.78656@savannah.gnu.org>
	<20111003-131152.sv79827.45963@savannah.gnu.org>
Message-ID: <20111003-140539.sv79827.5756@savannah.gnu.org>

Follow-up Comment #5, sr #107827 (project gnutls):

gnutls_dtls.c line 48 uint  ==> unsigned int

uint is not declared.

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 17:26:48 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Mon, 03 Oct 2011 15:26:48 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111003-140539.sv79827.5756@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
	<20111003-130328.sv79827.54599@savannah.gnu.org>
	<20111003-130406.sv0.78656@savannah.gnu.org>
	<20111003-131152.sv79827.45963@savannah.gnu.org>
	<20111003-140539.sv79827.5756@savannah.gnu.org>
Message-ID: <20111003-152648.sv79827.32280@savannah.gnu.org>

Follow-up Comment #6, sr #107827 (project gnutls):

I have this from the log file when building:

I am not sure what is wrong here! I have included <vector> in my sourcefiles
with out problems. 


  CC     crypto-backend.lo
  CC     gnutls_srp.lo
  CC     gnutls_psk.lo
  CCLD   libgnutls.la
copying selected object files to avoid basename conflicts...
  CXX    libgnutlsxx_la-gnutlsxx.lo
In file included from
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/cwchar:52,
                 from
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/bits/postypes.h:46,
                 from
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/iosfwd:49,
                 from
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/bits/stl_algobase.h:70,
                 from
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/vector:66,
                 from ./includes/gnutls/gnutlsxx.h:27,
                 from gnutlsxx.cpp:5:
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/ctime:76: error:
'::gmtime' has not been declared
/usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/include/c++/ctime:77: error:
'::localtime' has not been declared
make[3]: *** [libgnutlsxx_la-gnutlsxx.lo] Error 1
make[3]: Leaving directory
`/devt/users/bhc/build/congassl/win/congassl32/gnutls-3.0.2/lib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/devt/users/bhc/build/congassl/win/congassl32/gnutls-3.0.2/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/devt/users/bhc/build/congassl/win/congassl32/gnutls-3.0.2'
make: *** [all] Error 2

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 17:38:46 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Mon, 03 Oct 2011 15:38:46 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111003-152648.sv79827.32280@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
	<20111003-130328.sv79827.54599@savannah.gnu.org>
	<20111003-130406.sv0.78656@savannah.gnu.org>
	<20111003-131152.sv79827.45963@savannah.gnu.org>
	<20111003-140539.sv79827.5756@savannah.gnu.org>
	<20111003-152648.sv79827.32280@savannah.gnu.org>
Message-ID: <20111003-183846.sv707.91169@savannah.gnu.org>

Follow-up Comment #7, sr #107827 (project gnutls):

If you don't use the c++ gnutls library ignore this issue. It looks like a
header problem to me.

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 18:03:59 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Mon, 03 Oct 2011 16:03:59 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111003-183846.sv707.91169@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
	<20111003-130328.sv79827.54599@savannah.gnu.org>
	<20111003-130406.sv0.78656@savannah.gnu.org>
	<20111003-131152.sv79827.45963@savannah.gnu.org>
	<20111003-140539.sv79827.5756@savannah.gnu.org>
	<20111003-152648.sv79827.32280@savannah.gnu.org>
	<20111003-183846.sv707.91169@savannah.gnu.org>
Message-ID: <20111003-160359.sv79827.65375@savannah.gnu.org>

Follow-up Comment #8, sr #107827 (project gnutls):

I would but the make file ends without producing a libgnutls.a

/bhc

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 18:22:21 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Mon, 03 Oct 2011 16:22:21 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111003-160359.sv79827.65375@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
	<20111003-130328.sv79827.54599@savannah.gnu.org>
	<20111003-130406.sv0.78656@savannah.gnu.org>
	<20111003-131152.sv79827.45963@savannah.gnu.org>
	<20111003-140539.sv79827.5756@savannah.gnu.org>
	<20111003-152648.sv79827.32280@savannah.gnu.org>
	<20111003-183846.sv707.91169@savannah.gnu.org>
	<20111003-160359.sv79827.65375@savannah.gnu.org>
Message-ID: <20111003-192221.sv707.98243@savannah.gnu.org>

Follow-up Comment #9, sr #107827 (project gnutls):

Even if you use make -i in lib/?

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 21:05:17 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Mon, 03 Oct 2011 19:05:17 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111003-192221.sv707.98243@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
	<20111003-130328.sv79827.54599@savannah.gnu.org>
	<20111003-130406.sv0.78656@savannah.gnu.org>
	<20111003-131152.sv79827.45963@savannah.gnu.org>
	<20111003-140539.sv79827.5756@savannah.gnu.org>
	<20111003-152648.sv79827.32280@savannah.gnu.org>
	<20111003-183846.sv707.91169@savannah.gnu.org>
	<20111003-160359.sv79827.65375@savannah.gnu.org>
	<20111003-192221.sv707.98243@savannah.gnu.org>
Message-ID: <20111003-190517.sv79827.74921@savannah.gnu.org>

Follow-up Comment #10, sr #107827 (project gnutls):

make -i in lib/ works, then I get the libgnutls.a

Can I skip building the libgnutlsxx.a lib? running make with -i could bring me
into problem later.

/bhc

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 22:15:21 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Mon, 03 Oct 2011 20:15:21 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111003-190517.sv79827.74921@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
	<20111003-130328.sv79827.54599@savannah.gnu.org>
	<20111003-130406.sv0.78656@savannah.gnu.org>
	<20111003-131152.sv79827.45963@savannah.gnu.org>
	<20111003-140539.sv79827.5756@savannah.gnu.org>
	<20111003-152648.sv79827.32280@savannah.gnu.org>
	<20111003-183846.sv707.91169@savannah.gnu.org>
	<20111003-160359.sv79827.65375@savannah.gnu.org>
	<20111003-192221.sv707.98243@savannah.gnu.org>
	<20111003-190517.sv79827.74921@savannah.gnu.org>
Message-ID: <20111003-201521.sv79827.7196@savannah.gnu.org>

Follow-up Comment #11, sr #107827 (project gnutls):

make -i build libgnutls.a but when I link with the application I get an
error:

/devt/users/bhc/build/congassl/win/congassl32/libs/libgnutls.a(system.o):system.c:(.text+0x172):
undefined reference to `_select_used_without_including_sys_select_h'

and a warning from compiling lib/system.c

system.c: In function 'system_recv_timeout':
system.c:132: warning: implicit declaration of function
'select_used_without_including_sys_select_h'

I have tried to include <winsock2.h> after <windows.h> but that did not help.


I looks to me like a it would like to have sys/select.h included.

/bhc

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct  3 23:18:40 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Mon, 03 Oct 2011 21:18:40 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111003-201521.sv79827.7196@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
	<20111003-130328.sv79827.54599@savannah.gnu.org>
	<20111003-130406.sv0.78656@savannah.gnu.org>
	<20111003-131152.sv79827.45963@savannah.gnu.org>
	<20111003-140539.sv79827.5756@savannah.gnu.org>
	<20111003-152648.sv79827.32280@savannah.gnu.org>
	<20111003-183846.sv707.91169@savannah.gnu.org>
	<20111003-160359.sv79827.65375@savannah.gnu.org>
	<20111003-192221.sv707.98243@savannah.gnu.org>
	<20111003-190517.sv79827.74921@savannah.gnu.org>
	<20111003-201521.sv79827.7196@savannah.gnu.org>
Message-ID: <20111004-001840.sv707.27571@savannah.gnu.org>

Follow-up Comment #12, sr #107827 (project gnutls):

You can use ./configure --disable-cxx
to disable the C++ library.

About the select issue, if you add an include <sys/select.h> does it work?


    _______________________________________________________

Reply to this item at:

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

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




From bhc at insight.dk  Tue Oct  4 09:56:08 2011
From: bhc at insight.dk (=?UTF-8?B?QmrDuHJuIENocmlzdGVuc2Vu?=)
Date: Tue, 4 Oct 2011 09:56:08 +0200
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
Message-ID: <83D596805E41464EB382DFEEB6232D5487E3A7@shelob.Insight.local>

<sys/select.h> is not available under windows, it tried with <winsock2.h> where select in define for windows but it did not help. 

If I add <sys/select.h> I get file not found.



I can see that the old gcrypt.h had a forward declarations for select, but now where we have moved to nettle gcrypt.h is not included any more.

I am sure that the declaration of select is in the winsock2.h

The declaration of select is cover by a:
#if ! (defined (__INSIDE_CYGWIN__) || defined (__INSIDE_MSYS__)) 


Which is not is not the case. I do not know what that means. 


I can solve the problem by in the #ifdef _WIN32 section of system.c  include the winsock2.h and add a forward declaration for select. (stolen from gcrypt.h)

#ifdef _WIN32
#include <windows.h>

#include <winsock2.h>
ssize_t (*select) (int nfd, void *rset, void *wset, void *eset, struct timeval *timeout);

#else

That is not a nice solution but it works.

Better suggestions are appreciated


/bhc


PS: --disable-cxx worked.

Thanks!



-----Original Message-----
From: Nikos Mavrogiannopoulos [mailto:INVALID.NOREPLY at gnu.org] 
Sent: 3. oktober 2011 23:19
To: Nikos Mavrogiannopoulos; Bj?rn Christensen; gnutls-devel at gnu.org
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!

Follow-up Comment #12, sr #107827 (project gnutls):

You can use ./configure --disable-cxx
to disable the C++ library.

About the select issue, if you add an include <sys/select.h> does it work?


    _______________________________________________________

Reply to this item at:

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

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


From INVALID.NOREPLY at gnu.org  Tue Oct  4 10:10:36 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Tue, 04 Oct 2011 08:10:36 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111004-001840.sv707.27571@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
	<20111003-130328.sv79827.54599@savannah.gnu.org>
	<20111003-130406.sv0.78656@savannah.gnu.org>
	<20111003-131152.sv79827.45963@savannah.gnu.org>
	<20111003-140539.sv79827.5756@savannah.gnu.org>
	<20111003-152648.sv79827.32280@savannah.gnu.org>
	<20111003-183846.sv707.91169@savannah.gnu.org>
	<20111003-160359.sv79827.65375@savannah.gnu.org>
	<20111003-192221.sv707.98243@savannah.gnu.org>
	<20111003-190517.sv79827.74921@savannah.gnu.org>
	<20111003-201521.sv79827.7196@savannah.gnu.org>
	<20111004-001840.sv707.27571@savannah.gnu.org>
Message-ID: <20111004-081036.sv79827.10689@savannah.gnu.org>

Follow-up Comment #13, sr #107827 (project gnutls):

<sys/select.h> is not available under windows, it tried with <winsock2.h>
where select in define for windows but it did not help. 

If I add <sys/select.h> I get file not found.



I can see that the old gcrypt.h had a forward declarations for select, but now
where we have moved to nettle gcrypt.h is not included any more.

I am sure that the declaration of select is in the winsock2.h

The declaration of select is cover by a:
#if ! (defined (__INSIDE_CYGWIN__) || defined (__INSIDE_MSYS__)) 


Which is not is not the case. I do not know what that means. 


I can solve the problem by in the #ifdef _WIN32 section of system.c  include
the winsock2.h and add a forward declaration for select. (stolen from
gcrypt.h)

#ifdef _WIN32
#include <windows.h>

#include <winsock2.h>
ssize_t (*select) (int nfd, void *rset, void *wset, void *eset, struct timeval
*timeout);

#else

That is not a nice solution but it works.

Better suggestions are appreciated


/bhc

PS: --disable-cxx worked.

Thanks!




    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Tue Oct  4 11:29:51 2011
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Tue, 04 Oct 2011 09:29:51 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111004-081036.sv79827.10689@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
	<20111003-130328.sv79827.54599@savannah.gnu.org>
	<20111003-130406.sv0.78656@savannah.gnu.org>
	<20111003-131152.sv79827.45963@savannah.gnu.org>
	<20111003-140539.sv79827.5756@savannah.gnu.org>
	<20111003-152648.sv79827.32280@savannah.gnu.org>
	<20111003-183846.sv707.91169@savannah.gnu.org>
	<20111003-160359.sv79827.65375@savannah.gnu.org>
	<20111003-192221.sv707.98243@savannah.gnu.org>
	<20111003-190517.sv79827.74921@savannah.gnu.org>
	<20111003-201521.sv79827.7196@savannah.gnu.org>
	<20111004-001840.sv707.27571@savannah.gnu.org>
	<20111004-081036.sv79827.10689@savannah.gnu.org>
Message-ID: <20111004-092951.sv0.30997@savannah.gnu.org>

Follow-up Comment #14, sr #107827 (project gnutls):

Could you add an #undef select, under the #undef recv?

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Tue Oct  4 11:49:28 2011
From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen)
Date: Tue, 04 Oct 2011 09:49:28 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111004-092951.sv0.30997@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
	<20111003-130328.sv79827.54599@savannah.gnu.org>
	<20111003-130406.sv0.78656@savannah.gnu.org>
	<20111003-131152.sv79827.45963@savannah.gnu.org>
	<20111003-140539.sv79827.5756@savannah.gnu.org>
	<20111003-152648.sv79827.32280@savannah.gnu.org>
	<20111003-183846.sv707.91169@savannah.gnu.org>
	<20111003-160359.sv79827.65375@savannah.gnu.org>
	<20111003-192221.sv707.98243@savannah.gnu.org>
	<20111003-190517.sv79827.74921@savannah.gnu.org>
	<20111003-201521.sv79827.7196@savannah.gnu.org>
	<20111004-001840.sv707.27571@savannah.gnu.org>
	<20111004-081036.sv79827.10689@savannah.gnu.org>
	<20111004-092951.sv0.30997@savannah.gnu.org>
Message-ID: <20111004-094928.sv79827.7974@savannah.gnu.org>

Follow-up Comment #15, sr #107827 (project gnutls):

The #undef select worked, thank you!


I have made some more changes to avoid warnings:

in nettle/rnd.c line 32 

I have add #include <locks.h>  to avoid warnings on gnutls_mutex* undeclared.

and in gnutls_str_array.h I have added 
#include <gnutls_error.h> 

just after the #include <gnutls_int.h>

/bhc

    _______________________________________________________

Reply to this item at:

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

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




From vincent.torri at gmail.com  Tue Oct  4 14:23:18 2011
From: vincent.torri at gmail.com (Vincent Torri)
Date: Tue, 4 Oct 2011 14:23:18 +0200
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <83D596805E41464EB382DFEEB6232D5487E3A7@shelob.Insight.local>
References: <83D596805E41464EB382DFEEB6232D5487E3A7@shelob.Insight.local>
Message-ID: <CAMq1adr2VKo8bp5bSFNbUr0w94LJA4jY9=jq5fxAGKHzozgbdA@mail.gmail.com>

2011/10/4 Bj?rn Christensen <bhc at insight.dk>

> <sys/select.h> is not available under windows, it tried with <winsock2.h>
> where select in define for windows but it did not help.
>

use MSDN:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141%28v=vs.85%29.aspx

select() is declared when winsock2.h is included.

header : winsock2.h
lib : libws2_32

I don't understand why there are problems. I use select() for a project I'm
working on without any issue. I just include winsock2.h on Windows:

#ifdef _WIN32
# include <winsock2.h>
#endif

and that's all (or add a check in configure.ac and guard it with
HAVE_WINSOCK2_H)


> If I add <sys/select.h> I get file not found.
>

this file does not exist on Windows.

Vincent Torri


>
>
> I can see that the old gcrypt.h had a forward declarations for select, but
> now where we have moved to nettle gcrypt.h is not included any more.
>
> I am sure that the declaration of select is in the winsock2.h
>
> The declaration of select is cover by a:
> #if ! (defined (__INSIDE_CYGWIN__) || defined (__INSIDE_MSYS__))
>
>
> Which is not is not the case. I do not know what that means.
>
>
> I can solve the problem by in the #ifdef _WIN32 section of system.c
>  include the winsock2.h and add a forward declaration for select. (stolen
> from gcrypt.h)
>
> #ifdef _WIN32
> #include <windows.h>
>
> #include <winsock2.h>
> ssize_t (*select) (int nfd, void *rset, void *wset, void *eset, struct
> timeval *timeout);
>
> #else
>
> That is not a nice solution but it works.
>
> Better suggestions are appreciated
>
>
> /bhc
>
>
> PS: --disable-cxx worked.
>
> Thanks!
>
>
>
> -----Original Message-----
> From: Nikos Mavrogiannopoulos [mailto:INVALID.NOREPLY at gnu.org]
> Sent: 3. oktober 2011 23:19
> To: Nikos Mavrogiannopoulos; Bj?rn Christensen; gnutls-devel at gnu.org
> Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
>
> Follow-up Comment #12, sr #107827 (project gnutls):
>
> You can use ./configure --disable-cxx
> to disable the C++ library.
>
> About the select issue, if you add an include <sys/select.h> does it work?
>
>
>    _______________________________________________________
>
> Reply to this item at:
>
>  <http://savannah.gnu.org/support/?107827>
>
> _______________________________________________
>  Message sent via/by Savannah
>  http://savannah.gnu.org/
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> https://lists.gnu.org/mailman/listinfo/gnutls-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20111004/0a80c424/attachment.htm>

From bhc at insight.dk  Tue Oct  4 14:31:17 2011
From: bhc at insight.dk (=?iso-8859-1?Q?Bj=F8rn_Christensen?=)
Date: Tue, 4 Oct 2011 14:31:17 +0200
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
Message-ID: <83D596805E41464EB382DFEEB6232D5487E3AB@shelob.Insight.local>

The problem was solve by adding an #undef select ,  to  let system.c actually find the definition from winsock2.h.

 

There must be a #define somewhere to set select to 'select_used_without_including_sys_select_h' to warn that it have not been define probably,

 

 

/bhc

 

 

 

From: Vincent Torri [mailto:vincent.torri at gmail.com] 
Sent: 4. oktober 2011 14:23
To: Bj?rn Christensen
Cc: Nikos Mavrogiannopoulos; Nikos Mavrogiannopoulos; gnutls-devel at gnu.org
Subject: Re: [sr #107827] Build GnuTLS 3.0.2 for windows!

 

 

2011/10/4 Bj?rn Christensen <bhc at insight.dk>

<sys/select.h> is not available under windows, it tried with <winsock2.h> where select in define for windows but it did not help.


use MSDN:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141%28v=vs.85%29.aspx

select() is declared when winsock2.h is included.

header : winsock2.h
lib : libws2_32
 
I don't understand why there are problems. I use select() for a project I'm working on without any issue. I just include winsock2.h on Windows:

#ifdef _WIN32
# include <winsock2.h>
#endif

and that's all (or add a check in configure.ac and guard it with HAVE_WINSOCK2_H)

	
	If I add <sys/select.h> I get file not found.


this file does not exist on Windows.
 
Vincent Torri

	
	
	
	I can see that the old gcrypt.h had a forward declarations for select, but now where we have moved to nettle gcrypt.h is not included any more.
	
	I am sure that the declaration of select is in the winsock2.h
	
	The declaration of select is cover by a:
	#if ! (defined (__INSIDE_CYGWIN__) || defined (__INSIDE_MSYS__))
	
	
	Which is not is not the case. I do not know what that means.
	
	
	I can solve the problem by in the #ifdef _WIN32 section of system.c  include the winsock2.h and add a forward declaration for select. (stolen from gcrypt.h)
	
	#ifdef _WIN32
	#include <windows.h>
	
	#include <winsock2.h>
	ssize_t (*select) (int nfd, void *rset, void *wset, void *eset, struct timeval *timeout);
	
	#else
	
	That is not a nice solution but it works.
	
	Better suggestions are appreciated
	
	
	/bhc
	
	
	PS: --disable-cxx worked.
	
	Thanks!
	
	
	
	-----Original Message-----
	From: Nikos Mavrogiannopoulos [mailto:INVALID.NOREPLY at gnu.org]
	Sent: 3. oktober 2011 23:19
	To: Nikos Mavrogiannopoulos; Bj?rn Christensen; gnutls-devel at gnu.org
	Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
	
	Follow-up Comment #12, sr #107827 (project gnutls):
	
	You can use ./configure --disable-cxx
	to disable the C++ library.
	
	About the select issue, if you add an include <sys/select.h> does it work?
	
	
	   _______________________________________________________
	
	Reply to this item at:
	
	 <http://savannah.gnu.org/support/?107827>
	
	_______________________________________________
	 Message sent via/by Savannah
	 http://savannah.gnu.org/
	
	_______________________________________________
	Gnutls-devel mailing list
	Gnutls-devel at gnu.org
	https://lists.gnu.org/mailman/listinfo/gnutls-devel

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20111004/40bd7fc3/attachment.htm>

From nmav at gnu.org  Tue Oct  4 15:22:26 2011
From: nmav at gnu.org (Nikos Mavrogiannopoulos)
Date: Tue, 4 Oct 2011 15:22:26 +0200
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <CAMq1adr2VKo8bp5bSFNbUr0w94LJA4jY9=jq5fxAGKHzozgbdA@mail.gmail.com>
References: <83D596805E41464EB382DFEEB6232D5487E3A7@shelob.Insight.local>
	<CAMq1adr2VKo8bp5bSFNbUr0w94LJA4jY9=jq5fxAGKHzozgbdA@mail.gmail.com>
Message-ID: <CAJU7zaL3cLgHC67GiJYxnGux83ajvK2dJ5++Gq4O4pBk1YfLpA@mail.gmail.com>

2011/10/4 Vincent Torri <vincent.torri at gmail.com>:

>> <sys/select.h> is not available under windows, it tried with <winsock2.h>
>> where select in define for windows but it did not help.
> use MSDN:
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141%28v=vs.85%29.aspx
> select() is declared when winsock2.h is included.
[...]
> I don't understand why there are problems. I use select() for a project I'm
> working on without any issue. I just include winsock2.h on Windows:

It was gnulib that caused that. It seems it is defining select to an
unknown symbol unless a "proper" header is included.

regards,
Nikos



From vincent.torri at gmail.com  Tue Oct  4 16:50:46 2011
From: vincent.torri at gmail.com (Vincent Torri)
Date: Tue, 4 Oct 2011 16:50:46 +0200
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <CAJU7zaL3cLgHC67GiJYxnGux83ajvK2dJ5++Gq4O4pBk1YfLpA@mail.gmail.com>
References: <83D596805E41464EB382DFEEB6232D5487E3A7@shelob.Insight.local>
	<CAMq1adr2VKo8bp5bSFNbUr0w94LJA4jY9=jq5fxAGKHzozgbdA@mail.gmail.com>
	<CAJU7zaL3cLgHC67GiJYxnGux83ajvK2dJ5++Gq4O4pBk1YfLpA@mail.gmail.com>
Message-ID: <CAMq1adpsX+ZS3pe4_g8JBG7-yV7VXGvNcX=b0Oju4zFYWOBesg@mail.gmail.com>

On Tue, Oct 4, 2011 at 3:22 PM, Nikos Mavrogiannopoulos <nmav at gnu.org>wrote:

> 2011/10/4 Vincent Torri <vincent.torri at gmail.com>:
>
> >> <sys/select.h> is not available under windows, it tried with
> <winsock2.h>
> >> where select in define for windows but it did not help.
> > use MSDN:
> >
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141%28v=vs.85%29.aspx
> > select() is declared when winsock2.h is included.
> [...]
> > I don't understand why there are problems. I use select() for a project
> I'm
> > working on without any issue. I just include winsock2.h on Windows:
>
> It was gnulib that caused that. It seems it is defining select to an
> unknown symbol unless a "proper" header is included.
>

Ok. In case it might interest you, for that kind of error, clang is very
good. I had similar problems and clang reported in the error message where
the other declaration was done.

Vincent Torri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20111004/92af810f/attachment.htm>

From nmav at gnutls.org  Wed Oct  5 20:33:31 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 05 Oct 2011 20:33:31 +0200
Subject: gnutls on via nano
Message-ID: <4E8CA2FB.7030100@gnutls.org>

Hello,
  Thanks to Andy Polyakov and VIA I had access to a via nano to finish 
the VIA padlock support in GnuTLS. The results in nano are quite 
impressive. The values of the accelerated gnutls are:

Checking AES-128-CBC with SHA1 (16kb payload)... 0.29 GB/sec
Checking AES-128-CBC with SHA256 (16kb payload)... 0.24 GB/sec
Checking AES-128-GCM (16kb payload)... 73.70 MB/sec
Checking SHA1 (16kb payload)... 0.52 GB/sec
Checking SHA256 (16kb payload)... 0.45 GB/sec
Checking SHA512 (16kb payload)... 0.44 GB/sec
Checking AES-128-CBC (16kb payload)... 1.01 GB/sec
Checking ARCFOUR-128 (16kb payload)... 192.43 MB/sec

and the software only version:
Checking AES-128-CBC with SHA1 (16kb payload)... 48.10 MB/sec
Checking AES-128-CBC with SHA256 (16kb payload)... 32.82 MB/sec
Checking AES-128-GCM (16kb payload)... 47.15 MB/sec
Checking SHA1 (16kb payload)... 161.58 MB/sec
Checking SHA256 (16kb payload)... 61.77 MB/sec
Checking SHA512 (16kb payload)... 92.81 MB/sec
Checking AES-128-CBC (16kb payload)... 67.71 MB/sec
Checking ARCFOUR-128 (16kb payload)... 192.43 MB/sec

This is 15x speedup in AES-CBC and a 7x speedup in SHA-256. Note that 
this CPU has instructions for the SHA algorithms as well. It is quite a 
CPU for cryptographic operations.

regards,
Nikos



From INVALID.NOREPLY at gnu.org  Wed Oct  5 20:45:12 2011
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Wed, 05 Oct 2011 18:45:12 +0000
Subject: [sr #107831] local 'len' in gnutls_x509_crt_get_key_id not
	initialized, causing segmentation fault
Message-ID: <20111005-184511.sv0.14983@savannah.gnu.org>

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

                 Summary: local 'len' in gnutls_x509_crt_get_key_id not
initialized, causing segmentation fault
                 Project: GnuTLS
            Submitted by: None
            Submitted on: Wed 05 Oct 2011 06:45:11 PM UTC
                Category: Core library
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: Erik.Jensen at pnnl.gov
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None

    _______________________________________________________

Details:

With gnutls 3.0.3, certtool segfaults when I try to generate a self-signed
certificate. The problem is that 

asn1_der_coding (crt->cert, "tbsCertificate.subjectPublicKeyInfo", NULL, &len,
NULL);

is called with len unitialized. Since len contains garbage, asn1_der_coding
thinks it is okay to write to the output buffer, which is NULL. The following
patch fixes the problem for me.


--- gnutls-3.0.3/lib/x509/x509.c.orig	2011-10-05 17:25:53.025852307 +0000
+++ gnutls-3.0.3/lib/x509/x509.c	2011-10-05 17:26:04.232713442 +0000
@@ -2283,7 +2283,7 @@
                             unsigned char *output_data,
                             size_t * output_data_size)
 {
-  int pk, result = 0, len;
+  int pk, result = 0, len = 0;
   gnutls_datum_t pubkey;
 
   if (crt == NULL)






    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Wed Oct  5 21:12:43 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Wed, 05 Oct 2011 19:12:43 +0000
Subject: [sr #107831] local 'len' in gnutls_x509_crt_get_key_id not
	initialized, causing segmentation fault
In-Reply-To: <20111005-184511.sv0.14983@savannah.gnu.org>
References: <20111005-184511.sv0.14983@savannah.gnu.org>
Message-ID: <20111005-221243.sv707.38273@savannah.gnu.org>

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

Thanks. It will be fixed in the next release. Was it an ECDSA key you were
generating?

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Wed Oct  5 21:16:53 2011
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Wed, 05 Oct 2011 19:16:53 +0000
Subject: [sr #107831] local 'len' in gnutls_x509_crt_get_key_id not
	initialized, causing segmentation fault
In-Reply-To: <20111005-221243.sv707.38273@savannah.gnu.org>
References: <20111005-184511.sv0.14983@savannah.gnu.org>
	<20111005-221243.sv707.38273@savannah.gnu.org>
Message-ID: <20111005-191650.sv0.96069@savannah.gnu.org>

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

It was, yes.

    _______________________________________________________

Reply to this item at:

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

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




From vincent.torri at gmail.com  Thu Oct  6 19:05:49 2011
From: vincent.torri at gmail.com (Vincent Torri)
Date: Thu, 6 Oct 2011 19:05:49 +0200
Subject: about PKCS11
Message-ID: <CAMq1adrNEwYCCRHwMCBK++2zALX3AcZ-YrLLwXPpn_hENXjTBg@mail.gmail.com>

Hey,

I recently tried to use nettle instead of libgcrypt. Now, the configure
script asks for another dependency : p11-kit. Note also that I don't know
much about cryptography.

I'm building packages for Windows, using mingw-w64 and p11-kit needs another
dependency : pthread. I know that pthread-win32 exists for x86 but not for
x86_64. In addition, according to wikipedia, PKCS11 API on Windows exists:
http://en.wikipedia.org/wiki/Cryptographic_Application_Programming_Interface
.

if that Windows API is not used in gnutls (I don't see anything about it in
configure options), I would like to know which problems i could encounter if
I disable p11-kit support for gnutls

thank you

Vincent Torri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20111006/5026875d/attachment.htm>

From nmav at gnutls.org  Thu Oct  6 21:45:33 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 06 Oct 2011 21:45:33 +0200
Subject: about PKCS11
In-Reply-To: <CAMq1adrNEwYCCRHwMCBK++2zALX3AcZ-YrLLwXPpn_hENXjTBg@mail.gmail.com>
References: <CAMq1adrNEwYCCRHwMCBK++2zALX3AcZ-YrLLwXPpn_hENXjTBg@mail.gmail.com>
Message-ID: <4E8E055D.2080900@gnutls.org>

On 10/06/2011 07:05 PM, Vincent Torri wrote:

> Hey,
> I recently tried to use nettle instead of libgcrypt. Now, the configure
> script asks for another dependency : p11-kit. Note also that I don't know
> much about cryptography.
>
> I'm building packages for Windows, using mingw-w64 and p11-kit needs another
> dependency : pthread. I know that pthread-win32 exists for x86 but not for
> x86_64. In addition, according to wikipedia, PKCS11 API on Windows exists:
> http://en.wikipedia.org/wiki/Cryptographic_Application_Programming_Interface.
> if that Windows API is not used in gnutls (I don't see anything about it in
> configure options), I would like to know which problems i could encounter if
> I disable p11-kit support for gnutls

Hello,
  Do you need smart card support? If not just use the --without-p11-kit 
configure flag. If you need smart-card support in gnutls, then I don't 
know whether p11-kit is could run on windows. Stef would have more 
insight on that.

regards,
Nikos



From stefw at collabora.co.uk  Sat Oct  8 08:10:14 2011
From: stefw at collabora.co.uk (Stef Walter)
Date: Sat, 08 Oct 2011 08:10:14 +0200
Subject: about PKCS11
In-Reply-To: <4E8E055D.2080900@gnutls.org>
References: <CAMq1adrNEwYCCRHwMCBK++2zALX3AcZ-YrLLwXPpn_hENXjTBg@mail.gmail.com>
	<4E8E055D.2080900@gnutls.org>
Message-ID: <4E8FE946.1000502@collabora.co.uk>

On 2011-10-06 21:45, Nikos Mavrogiannopoulos wrote:
> Hello,
>  Do you need smart card support? If not just use the --without-p11-kit
> configure flag. If you need smart-card support in gnutls, then I don't
> know whether p11-kit is could run on windows. Stef would have more
> insight on that.

Yes, win32 support needs to be done. I don't see any major obstacles,
but I just need to get a win32 VM setup and actually work on it. I
imagine I'll need to do an MSVC and a GCC mingw build. I'm not looking
forward to releasing binaries, but at least I'll get it building.

Cheers,

Stef



From stefw at collabora.co.uk  Sat Oct  8 08:19:49 2011
From: stefw at collabora.co.uk (Stef Walter)
Date: Sat, 08 Oct 2011 08:19:49 +0200
Subject: Problems with automatic pkcs11 reinit on fork
Message-ID: <4E8FEB85.90503@collabora.co.uk>

In p11-kit we've copied the pakchois behavior of automatically
reinitializing when a fork happens. In PKCS#11 an application using
PKCS#11 modules has to call C_Initialize after a fork to reinitialize
the smart card driver.

The automatic reinitialization behavior of p11-kit is sort of nice from
the perspective of the consumers of the library, however it causes
performance problems when it's automatic.

For example if a process that's using p11-kit forks/execs another
executable, then all the PKCS#11 providers are reinitialized after the
fork and before the exec.

Perhaps we should change p11-kit so that it's fork aware, and zeros its
initialization ref counts, but expects the user of the library to
actually reinitialize after a fork.

For example, in the case of gnutls, on the next use of PKCS#11 after a
fork gnutls would need to call p11_kit_initialize_registered() again.

How does that sound? Alon, I hope it's okay that I've CC'd you. You
have extensive experience with how applications deal with this issue, so
I figured you may have valuable advice.

Cheers,

Stef



From n.mavrogiannopoulos at gmail.com  Sat Oct  8 12:22:45 2011
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sat, 08 Oct 2011 12:22:45 +0200
Subject: Problems with automatic pkcs11 reinit on fork
In-Reply-To: <4E8FEB85.90503@collabora.co.uk>
References: <4E8FEB85.90503@collabora.co.uk>
Message-ID: <4E902475.90506@gmail.com>

On 10/08/2011 08:19 AM, Stef Walter wrote:
> In p11-kit we've copied the pakchois behavior of automatically
> reinitializing when a fork happens. In PKCS#11 an application using
> PKCS#11 modules has to call C_Initialize after a fork to reinitialize
> the smart card driver.
>
> The automatic reinitialization behavior of p11-kit is sort of nice from
> the perspective of the consumers of the library, however it causes
> performance problems when it's automatic.
[...]
> For example if a process that's using p11-kit forks/execs another
> executable, then all the PKCS#11 providers are reinitialized after the
> fork and before the exec.
> Perhaps we should change p11-kit so that it's fork aware, and zeros its
> initialization ref counts, but expects the user of the library to
> actually reinitialize after a fork.
> For example, in the case of gnutls, on the next use of PKCS#11 after a
> fork gnutls would need to call p11_kit_initialize_registered() again.

Actually that would have to be gnutls' applications that I don't expect 
them to do it. gnutls itself it does know of fork, unless we call 
getpid() on every pkcs11 call to detect forks.

Couldn't this be handled entirely within p11-kit? I.e. at fork instead 
of initializing everything, mark as everything being uninitialized. Then
(a) either reinitialize everything on the first pkcs11 call, or (b) 
provide a call like p11_kit_reinitialize_if_needed() or so.

On the (b) case the user of p11-kit would have to call 
p11_kit_reinitialize_if_needed() before every pkcs11 call. This is very 
ugly, but better than nothing. I'd prefer (a).

regards,
Nikos



From vincent.torri at gmail.com  Sat Oct  8 12:22:32 2011
From: vincent.torri at gmail.com (Vincent Torri)
Date: Sat, 8 Oct 2011 12:22:32 +0200
Subject: compilation error with gnutls 2.12.10 a,d mingw-w64
Message-ID: <CAMq1adr6rCUCexR0d4QHah5yK+1Dfx_Om+gRwZBFZeaRmwZ4Bg@mail.gmail.com>

Hey,

I cross compile on linux to Windows using mingw-w64. uint8_t is used in
cli.c but it's not defined. I don't understand why unsigned char is not
used.

Vincent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20111008/1bb5eb98/attachment.htm>

From vincent.torri at gmail.com  Sat Oct  8 12:37:15 2011
From: vincent.torri at gmail.com (Vincent Torri)
Date: Sat, 8 Oct 2011 12:37:15 +0200
Subject: gaa : about use of ftell/fseek
Message-ID: <CAMq1ado28_0eum6MP=Rn6mZw0-5Y6CkEXwwjA0x-3949vqoFYA@mail.gmail.com>

Hey

maybe ftello / fseeko should be used instead of fseek / ftell (if
available). There is an autoconf macro to check their availability :
AC_FUNC_FSEEKO. On Windows, the functions to use are _ftelli64 and _fseeki64
:

http://msdn.microsoft.com/fr-fr/library/0ys3hc0b%28VS.80%29.aspx

regards

Vincent Torri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20111008/60ca376f/attachment.htm>

From nmav at gnutls.org  Sat Oct  8 12:49:49 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 08 Oct 2011 12:49:49 +0200
Subject: compilation error with gnutls 2.12.10 a,d mingw-w64
In-Reply-To: <CAMq1adr6rCUCexR0d4QHah5yK+1Dfx_Om+gRwZBFZeaRmwZ4Bg@mail.gmail.com>
References: <CAMq1adr6rCUCexR0d4QHah5yK+1Dfx_Om+gRwZBFZeaRmwZ4Bg@mail.gmail.com>
Message-ID: <4E902ACD.7040708@gnutls.org>

On 10/08/2011 12:22 PM, Vincent Torri wrote:

> I cross compile on linux to Windows using mingw-w64. uint8_t is used in
> cli.c but it's not defined. I don't understand why unsigned char is not
> used.

Hi,
  uint8_t is a C99 type defined in stdint.h. I've reverted it to 
unsigned char, because gnutls is supposed to compile with C89 compilers 
as well (I don't know whether this is really true today).

regards,
Nikos



From nmav at gnutls.org  Sat Oct  8 12:53:35 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 08 Oct 2011 12:53:35 +0200
Subject: gaa : about use of ftell/fseek
In-Reply-To: <CAMq1ado28_0eum6MP=Rn6mZw0-5Y6CkEXwwjA0x-3949vqoFYA@mail.gmail.com>
References: <CAMq1ado28_0eum6MP=Rn6mZw0-5Y6CkEXwwjA0x-3949vqoFYA@mail.gmail.com>
Message-ID: <4E902BAF.9090704@gnutls.org>

On 10/08/2011 12:37 PM, Vincent Torri wrote:
> Hey
>
> maybe ftello / fseeko should be used instead of fseek / ftell (if
> available). There is an autoconf macro to check their availability :
> AC_FUNC_FSEEKO. On Windows, the functions to use are _ftelli64 and _fseeki64

Hello,
  Why? The included programs don't really care about large files. They 
might accept a configuration file or a file holding certificates. Those 
are rarely over 2^31 bytes.

regards,
Nikos



From vincent.torri at gmail.com  Sat Oct  8 12:55:38 2011
From: vincent.torri at gmail.com (Vincent Torri)
Date: Sat, 8 Oct 2011 12:55:38 +0200
Subject: compilation error of errcodes
Message-ID: <CAMq1adq+L6u6_J4n66KXe4gR=bp3UsEMLCXaFRb4ahTfKu5o8g@mail.gmail.com>

hey,

always compiling with mingw-w64 : errcodes can not be compiled as gnutls.h
is not found : 'make ./errcodes' so it  seems that AM_CPPFLAGS is not taken
into account (i've not searched in the automake manual if it's the reason or
not.

Anyway, adding

errcodes_CPPFLAGS = -I$(top_srcdir)/lib/includes
-I$(top_builddir)/lib/includes

in doc/Makefile.am fixes my problem.

Vincent Torri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20111008/9287f1d4/attachment.htm>

From nmav at gnutls.org  Sat Oct  8 13:10:55 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 08 Oct 2011 13:10:55 +0200
Subject: compilation error of errcodes
In-Reply-To: <CAMq1adq+L6u6_J4n66KXe4gR=bp3UsEMLCXaFRb4ahTfKu5o8g@mail.gmail.com>
References: <CAMq1adq+L6u6_J4n66KXe4gR=bp3UsEMLCXaFRb4ahTfKu5o8g@mail.gmail.com>
Message-ID: <4E902FBF.1010606@gnutls.org>

On 10/08/2011 12:55 PM, Vincent Torri wrote:
> hey, always compiling with mingw-w64 : errcodes can not be compiled
> as gnutls.h is not found : 'make ./errcodes' so it  seems that
> AM_CPPFLAGS is not taken into account (i've not searched in the
> automake manual if it's the reason or not.

It looks like a bug in the automake used. Did you run automake before
compiling? In my system that change is not required.

regards,
Nikos



From stefw at collabora.co.uk  Sat Oct  8 17:39:20 2011
From: stefw at collabora.co.uk (Stef Walter)
Date: Sat, 08 Oct 2011 17:39:20 +0200
Subject: Problems with automatic pkcs11 reinit on fork
In-Reply-To: <4E902475.90506@gmail.com>
References: <4E8FEB85.90503@collabora.co.uk> <4E902475.90506@gmail.com>
Message-ID: <4E906EA8.5040601@collabora.co.uk>

On 2011-10-08 12:22, Nikos Mavrogiannopoulos wrote:
> Actually that would have to be gnutls' applications that I don't expect
> them to do it. gnutls itself it does know of fork, unless we call
> getpid() on every pkcs11 call to detect forks.

Right, that makes sense.

Essentially though, the core issue is that a library like gnutls cannot
use pkcs11 blindly across forks. In particular all sessions, object
handles and everything else related to PKCS#11 becomes invalid after a fork.

When it comes to PKCS#11, we cannot make forking transparent for gnutls
or any other library or application.

> Couldn't this be handled entirely within p11-kit? I.e. at fork instead
> of initializing everything, mark as everything being uninitialized. Then
> (a) either reinitialize everything on the first pkcs11 call, 

We don't wrap every pkcs11 call, so sadly this wouldn't work, see the
problem with transparency above.

or (b)
> provide a call like p11_kit_reinitialize_if_needed() or so.

I guess we can do this or something like it. We could have a macro that
checks a global variable to make this a very fast check.

But would it make more sense for gnutls to listen to pthread_atfork()
and clear out its pkcs#11 state?

> On the (b) case the user of p11-kit would have to call
> p11_kit_reinitialize_if_needed() before every pkcs11 call. This is very
> ugly, but better than nothing. I'd prefer (a).

Me too. I wish there was a nice clean solution. Essentially we have (a)
right now, by initializing right as the fork occurs. Sadly this has
performance problems when fork/exec is encountered.

But there's another problem with the current solution (reinitializing
right as the fork occurs using pthread_atfork), and that is that PKCS#11
implementations often also use pthread_atfork to detect and emulate the
correct behavior. Pakchois also has this problem. We cannot guarantee
that pthread_atfork callback that p11-kit installs happens after the
pthread_atfork callback that a pkcs11 library is using.

Cheers,

Stef



From n.mavrogiannopoulos at gmail.com  Sun Oct  9 23:13:41 2011
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sun, 09 Oct 2011 23:13:41 +0200
Subject: Problems with automatic pkcs11 reinit on fork
In-Reply-To: <4E906EA8.5040601@collabora.co.uk>
References: <4E8FEB85.90503@collabora.co.uk> <4E902475.90506@gmail.com>
	<4E906EA8.5040601@collabora.co.uk>
Message-ID: <4E920E85.6020204@gmail.com>

On 10/08/2011 05:39 PM, Stef Walter wrote:

> When it comes to PKCS#11, we cannot make forking transparent for gnutls
> or any other library or application.
>> Couldn't this be handled entirely within p11-kit? I.e. at fork instead
>> of initializing everything, mark as everything being uninitialized. Then
>> (a) either reinitialize everything on the first pkcs11 call,
>
> We don't wrap every pkcs11 call, so sadly this wouldn't work, see the
> problem with transparency above.

What if you wrap every call just like pakchois did. Then it would be 
possible.

> or (b)
>> provide a call like p11_kit_reinitialize_if_needed() or so.
> I guess we can do this or something like it. We could have a macro that
> checks a global variable to make this a very fast check.

This would be problematic when you could also have multiple threads 
(e.g. the way apache works). In most of the cases where multiple 
initialization doesn't really matter it wouldn't be a problem, but here 
multiple initialization might have unexpected outcome. Thus some kind of 
locks would also be required.

> But would it make more sense for gnutls to listen to pthread_atfork()
> and clear out its pkcs#11 state?

Then I'd have exactly the same problem that you have. Performance issues 
:) It might be better for this issue to be solved once and for all users 
of p11-kit.


regards,
Nikos



From simon at josefsson.org  Mon Oct 10 11:25:15 2011
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Oct 2011 11:25:15 +0200
Subject: compilation error with gnutls 2.12.10 a,d mingw-w64
In-Reply-To: <4E902ACD.7040708@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sat, 08 Oct 2011 12:49:49 +0200")
References: <CAMq1adr6rCUCexR0d4QHah5yK+1Dfx_Om+gRwZBFZeaRmwZ4Bg@mail.gmail.com>
	<4E902ACD.7040708@gnutls.org>
Message-ID: <87r52lxkp0.fsf@latte.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On 10/08/2011 12:22 PM, Vincent Torri wrote:
>
>> I cross compile on linux to Windows using mingw-w64. uint8_t is used in
>> cli.c but it's not defined. I don't understand why unsigned char is not
>> used.
>
> Hi,
>  uint8_t is a C99 type defined in stdint.h. I've reverted it to
> unsigned char, because gnutls is supposed to compile with C89
> compilers as well (I don't know whether this is really true today).

Gnulib provides the C99 stdint types even for C89 compilers.  I think we
should feel free to use uint*_t everywhere.

src/cli.c does not include stdint.h though.  Could it be that simple?
I've pushed a patch.  Vincent, please try adding '#include <stdint.h>'
at the top of src/cli.c after the '#include <config.h>' line.

/Simon



From simon at josefsson.org  Mon Oct 10 11:27:48 2011
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Oct 2011 11:27:48 +0200
Subject: compilation error of errcodes
In-Reply-To: <4E902FBF.1010606@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sat, 08 Oct 2011 13:10:55 +0200")
References: <CAMq1adq+L6u6_J4n66KXe4gR=bp3UsEMLCXaFRb4ahTfKu5o8g@mail.gmail.com>
	<4E902FBF.1010606@gnutls.org>
Message-ID: <87mxd9xkkr.fsf@latte.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On 10/08/2011 12:55 PM, Vincent Torri wrote:
>> hey, always compiling with mingw-w64 : errcodes can not be compiled
>> as gnutls.h is not found : 'make ./errcodes' so it  seems that
>> AM_CPPFLAGS is not taken into account (i've not searched in the
>> automake manual if it's the reason or not.
>
> It looks like a bug in the automake used. Did you run automake before
> compiling? In my system that change is not required.

Perhaps the patch below solves this.  Vincent, can you try running 'make
./errcodes.exe' to see if it uses the correct cflags?  If so, this patch
is the right thing.

/Simon

diff --git a/doc/Makefile.am b/doc/Makefile.am
index 8f4d121..2824461 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -156,8 +156,8 @@ alert_printlist_SOURCES = alert-printlist.c
 alert_printlist_LDADD = ../lib/libgnutls.la ../gl/libgnu.la
 
 error_codes.texi: $(top_srcdir)/lib/gnutls_errors.c $(srcdir)/errcodes.c
-	make $(builddir)/errcodes
-	$(builddir)/errcodes > $@-tmp
+	make $(builddir)/errcodes$(EXEEXT)
+	$(builddir)/errcodes$(EXEEXT) > $@-tmp
 	mv -f $@-tmp $@
 
 algorithms.texi: printlist
 



From nmav at gnutls.org  Mon Oct 10 11:49:13 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 10 Oct 2011 11:49:13 +0200
Subject: compilation error with gnutls 2.12.10 a,d mingw-w64
In-Reply-To: <87r52lxkp0.fsf@latte.josefsson.org>
References: <CAMq1adr6rCUCexR0d4QHah5yK+1Dfx_Om+gRwZBFZeaRmwZ4Bg@mail.gmail.com>
	<4E902ACD.7040708@gnutls.org> <87r52lxkp0.fsf@latte.josefsson.org>
Message-ID: <CAJU7za+njHuMKtRYz82UuyCz1Cww3=ycHnS5W5hcRO1EaeRisQ@mail.gmail.com>

On Mon, Oct 10, 2011 at 11:25 AM, Simon Josefsson <simon at josefsson.org> wrote:

> src/cli.c does not include stdint.h though. ?Could it be that simple?
> I've pushed a patch. ?Vincent, please try adding '#include <stdint.h>'
> at the top of src/cli.c after the '#include <config.h>' line.

Indeed, but I saw no point to include it for only one occurrence.
Using the uint*_t types is better though.

regards,
Nikos



From alon.barlev at gmail.com  Sat Oct  8 19:16:36 2011
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sat, 8 Oct 2011 19:16:36 +0200
Subject: Problems with automatic pkcs11 reinit on fork
In-Reply-To: <4E8FEB85.90503@collabora.co.uk>
References: <4E8FEB85.90503@collabora.co.uk>
Message-ID: <CAOazyz2p4qRttVHnfWqmVGKLB9SzdhuVzjYnnuL4zdn8o-Lxpw@mail.gmail.com>

Hi,

Some thoughts....

1. I always assued that p11-kit was a transparent PKCS#11 provider
that does extra functionality on behalf proxied providers. Maybe I am
wrong.

2. If (1) is correct, requesting application to do some extra logic if
the specific p11-kit is loaded is something that should be avoided.,

3. If (1) is correct, and application is already using PKCS#11, it
should follow the spec and do <something> special when fork()ing, and
nothing is needed.

4. Most provides miss this requirement, and even after
re-initialization do not work properly. This is *THE* bug of providers
when vendors port their provider into *POSIX, and won't be fixed
anyway.

5. Doing that transparent requires:

a. Make sure application is designed properly to re-initialize any
handle that is invalidate.

b. Record pid of initialized process, and monitor all C_ functions for
uninitialized process.

c. Keep refcount for each C_ method, and wait for refcount=0 before
fork(), this should be done at all process threads! (Most common,
thread that polls for slot status).

d. Free locks of all threads other than fork() thread before fork().

e. Reinitialize after fork().

Regards,
Alon.


On Sat, Oct 8, 2011 at 8:19 AM, Stef Walter <stefw at collabora.co.uk> wrote:
>
> In p11-kit we've copied the pakchois behavior of automatically
> reinitializing when a fork happens. In PKCS#11 an application using
> PKCS#11 modules has to call C_Initialize after a fork to reinitialize
> the smart card driver.
>
> The automatic reinitialization behavior of p11-kit is sort of nice from
> the perspective of the consumers of the library, however it causes
> performance problems when it's automatic.
>
> For example if a process that's using p11-kit forks/execs another
> executable, then all the PKCS#11 providers are reinitialized after the
> fork and before the exec.
>
> Perhaps we should change p11-kit so that it's fork aware, and zeros its
> initialization ref counts, but expects the user of the library to
> actually reinitialize after a fork.
>
> For example, in the case of gnutls, on the next use of PKCS#11 after a
> fork gnutls would need to call p11_kit_initialize_registered() again.
>
> How does that sound? Alon, I hope it's okay that I've CC'd you. You
> have extensive experience with how applications deal with this issue, so
> I figured you may have valuable advice.
>
> Cheers,
>
> Stef



From simon at josefsson.org  Mon Oct 10 14:21:34 2011
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Oct 2011 14:21:34 +0200
Subject: compilation error with gnutls 2.12.10 a,d mingw-w64
In-Reply-To: <CAJU7za+njHuMKtRYz82UuyCz1Cww3=ycHnS5W5hcRO1EaeRisQ@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Mon, 10 Oct 2011 11:49:13
	+0200")
References: <CAMq1adr6rCUCexR0d4QHah5yK+1Dfx_Om+gRwZBFZeaRmwZ4Bg@mail.gmail.com>
	<4E902ACD.7040708@gnutls.org> <87r52lxkp0.fsf@latte.josefsson.org>
	<CAJU7za+njHuMKtRYz82UuyCz1Cww3=ycHnS5W5hcRO1EaeRisQ@mail.gmail.com>
Message-ID: <87ehylxcj5.fsf@latte.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On Mon, Oct 10, 2011 at 11:25 AM, Simon Josefsson <simon at josefsson.org> wrote:
>
>> src/cli.c does not include stdint.h though. ?Could it be that simple?
>> I've pushed a patch. ?Vincent, please try adding '#include <stdint.h>'
>> at the top of src/cli.c after the '#include <config.h>' line.
>
> Indeed, but I saw no point to include it for only one occurrence.
> Using the uint*_t types is better though.

Looking more closely at this code made me change my mind though.  The
declaration is:

  uint8_t keyid[GNUTLS_OPENPGP_KEYID_SIZE];

and the variable is used like this:

      get_keyid (keyid, info.pgp_subkey);
...
        gnutls_pcert_import_openpgp_raw (&pgp_crt, &data, GNUTLS_OPENPGP_FMT_BASE64, info.pgp_subkey!=NULL?keyid:NULL, 0);
...
           gnutls_openpgp_privkey_set_preferred_key_id (tmp_pgp_key, keyid)

Those functions has prototypes like this:

int get_keyid (gnutls_openpgp_keyid_t keyid, const char *str)

int gnutls_pcert_import_openpgp_raw (gnutls_pcert_st *pcert,
	const gnutls_datum_t* cert, 
	gnutls_openpgp_crt_fmt_t format, 
	gnutls_openpgp_keyid_t keyid,
	unsigned int flags)

int
gnutls_openpgp_privkey_set_preferred_key_id (gnutls_openpgp_privkey_t key,
                                             const gnutls_openpgp_keyid_t
                                             keyid)

So the proper type to use seems to be gnutls_openpgp_keyid_t instead of
uint8_t/unsigned char.  It is declared like this:

#define GNUTLS_OPENPGP_KEYID_SIZE 8
  typedef unsigned char gnutls_openpgp_keyid_t[GNUTLS_OPENPGP_KEYID_SIZE];

I've made this change now...  (keeping stdint.h, it doesn't hurt that
much I think)

/Simon



From nmav at gnutls.org  Mon Oct 10 14:29:39 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 10 Oct 2011 14:29:39 +0200
Subject: compilation error with gnutls 2.12.10 a,d mingw-w64
In-Reply-To: <87ehylxcj5.fsf@latte.josefsson.org>
References: <CAMq1adr6rCUCexR0d4QHah5yK+1Dfx_Om+gRwZBFZeaRmwZ4Bg@mail.gmail.com>
	<4E902ACD.7040708@gnutls.org> <87r52lxkp0.fsf@latte.josefsson.org>
	<CAJU7za+njHuMKtRYz82UuyCz1Cww3=ycHnS5W5hcRO1EaeRisQ@mail.gmail.com>
	<87ehylxcj5.fsf@latte.josefsson.org>
Message-ID: <CAJU7za+EVQG89A86GUujgEcwr3pJGBoM-p_YRR3_BfUx05ELEg@mail.gmail.com>

On Mon, Oct 10, 2011 at 2:21 PM, Simon Josefsson <simon at josefsson.org> wrote:

> So the proper type to use seems to be gnutls_openpgp_keyid_t instead of
> uint8_t/unsigned char. ?It is declared like this:
> #define GNUTLS_OPENPGP_KEYID_SIZE 8
> ?typedef unsigned char gnutls_openpgp_keyid_t[GNUTLS_OPENPGP_KEYID_SIZE];

This is wrong! gnutls_openpgp_keyid_t with the above typedef is just a
pointer type meaning it has 4 bytes in 32-bit systems. I made the
definition like that to make clear to the caller that 8-bytes should
be allocated, but it seems this obscure typedef is confusing. It might
be better to be replaced with a simple pointer type.

regards,
Nikos



From simon at josefsson.org  Mon Oct 10 15:14:44 2011
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 10 Oct 2011 15:14:44 +0200
Subject: compilation error with gnutls 2.12.10 a,d mingw-w64
In-Reply-To: <CAJU7za+EVQG89A86GUujgEcwr3pJGBoM-p_YRR3_BfUx05ELEg@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Mon, 10 Oct 2011 14:29:39
	+0200")
References: <CAMq1adr6rCUCexR0d4QHah5yK+1Dfx_Om+gRwZBFZeaRmwZ4Bg@mail.gmail.com>
	<4E902ACD.7040708@gnutls.org> <87r52lxkp0.fsf@latte.josefsson.org>
	<CAJU7za+njHuMKtRYz82UuyCz1Cww3=ycHnS5W5hcRO1EaeRisQ@mail.gmail.com>
	<87ehylxcj5.fsf@latte.josefsson.org>
	<CAJU7za+EVQG89A86GUujgEcwr3pJGBoM-p_YRR3_BfUx05ELEg@mail.gmail.com>
Message-ID: <87aa99xa2j.fsf@latte.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On Mon, Oct 10, 2011 at 2:21 PM, Simon Josefsson <simon at josefsson.org> wrote:
>
>> So the proper type to use seems to be gnutls_openpgp_keyid_t instead of
>> uint8_t/unsigned char. ?It is declared like this:
>> #define GNUTLS_OPENPGP_KEYID_SIZE 8
>> ?typedef unsigned char gnutls_openpgp_keyid_t[GNUTLS_OPENPGP_KEYID_SIZE];
>
> This is wrong! gnutls_openpgp_keyid_t with the above typedef is just a
> pointer type meaning it has 4 bytes in 32-bit systems. I made the
> definition like that to make clear to the caller that 8-bytes should
> be allocated, but it seems this obscure typedef is confusing. It might
> be better to be replaced with a simple pointer type.

Heh, good point.  Lack of coffee.  So I think the proper solution then
really is to duplicate the typedef'ed definition like this:

  unsigned char keyid[GNUTLS_OPENPGP_KEYID_SIZE];

With the rationale that if the library doesn't use uint8_t for this
type, the tool shouldn't either...

Pushed.

/Simon



From stefw at collabora.co.uk  Mon Oct 10 18:10:32 2011
From: stefw at collabora.co.uk (Stef Walter)
Date: Mon, 10 Oct 2011 18:10:32 +0200
Subject: Problems with automatic pkcs11 reinit on fork
In-Reply-To: <CAOazyz2p4qRttVHnfWqmVGKLB9SzdhuVzjYnnuL4zdn8o-Lxpw@mail.gmail.com>
References: <4E8FEB85.90503@collabora.co.uk>
	<CAOazyz2p4qRttVHnfWqmVGKLB9SzdhuVzjYnnuL4zdn8o-Lxpw@mail.gmail.com>
Message-ID: <4E9318F8.6080001@collabora.co.uk>

Thanks Alon, very helpful.

On 10/08/2011 07:16 PM, Alon Bar-Lev wrote:
> 1. I always assued that p11-kit was a transparent PKCS#11 provider
> that does extra functionality on behalf proxied providers. Maybe I am
> wrong.

Yes, that's one way to use p11-kit for applications that are not aware 
of p11-kit. However in the case of gnutls and other applications aware 
of p11-kit the applications are invoked directly.

However p11-kit does not aspire to be a wrapper library for PKCS#11. At 
least not yet ... there was some talk of merging pakchois into p11-kit, 
but it hasn't been p11-kit's core focus to try and abstract away PKCS#11.

> 3. If (1) is correct, and application is already using PKCS#11, it
> should follow the spec and do<something>  special when fork()ing, and
> nothing is needed.

Good point. Right, that makes sense. Handling forking correctly is an 
integral part of using PKCS#11. It may be that a wrapper library can 
hide this away, but it would be an extremely leaky abstraction.

> 4. Most provides miss this requirement, and even after
> re-initialization do not work properly. This is *THE* bug of providers
> when vendors port their provider into *POSIX, and won't be fixed
> anyway.

I see :/

> 5. Doing that transparent requires:
>
> a. Make sure application is designed properly to re-initialize any
> handle that is invalidate.
>
> b. Record pid of initialized process, and monitor all C_ functions for
> uninitialized process.
>
> c. Keep refcount for each C_ method, and wait for refcount=0 before
> fork(), this should be done at all process threads! (Most common,
> thread that polls for slot status).
>
> d. Free locks of all threads other than fork() thread before fork().
>
> e. Reinitialize after fork().

Right, that's a tough set of requirements. I might add that for 
requirement 'e', one cannot simply reinitialize inside a callback called 
from pthread_atfork() or similar. NSS and some other PKCS#11 modules use 
pthread_atfork() to watch for forks and set their internal state to 
uninitialized, so there's an inherent race condition here.

Cheers,

Stef



From stefw at collabora.co.uk  Mon Oct 10 18:17:29 2011
From: stefw at collabora.co.uk (Stef Walter)
Date: Mon, 10 Oct 2011 18:17:29 +0200
Subject: Problems with automatic pkcs11 reinit on fork
In-Reply-To: <4E920E85.6020204@gmail.com>
References: <4E8FEB85.90503@collabora.co.uk> <4E902475.90506@gmail.com>
	<4E906EA8.5040601@collabora.co.uk> <4E920E85.6020204@gmail.com>
Message-ID: <4E931A99.10907@collabora.co.uk>

On 10/09/2011 11:13 PM, Nikos Mavrogiannopoulos wrote:
> On 10/08/2011 05:39 PM, Stef Walter wrote:
>
>> When it comes to PKCS#11, we cannot make forking transparent for gnutls
>> or any other library or application.
>>> Couldn't this be handled entirely within p11-kit? I.e. at fork instead
>>> of initializing everything, mark as everything being uninitialized. Then
>>> (a) either reinitialize everything on the first pkcs11 call,
>>
>> We don't wrap every pkcs11 call, so sadly this wouldn't work, see the
>> problem with transparency above.
>
> What if you wrap every call just like pakchois did. Then it would be
> possible.

There was some talk of merging pakchois into p11-kit. It hasn't been the 
focus of p11-kit to be a wrapper library abstracting all of PKCS#11, 
although it does abstract the loading and initializing.

>> or (b)
>>> provide a call like p11_kit_reinitialize_if_needed() or so.
>> I guess we can do this or something like it. We could have a macro that
>> checks a global variable to make this a very fast check.
>
> This would be problematic when you could also have multiple threads
> (e.g. the way apache works). In most of the cases where multiple
> initialization doesn't really matter it wouldn't be a problem, but here
> multiple initialization might have unexpected outcome. Thus some kind of
> locks would also be required.

You're right. I ran into this problem the other day independently of 
this issue.

In particular, some PKCS#11 modules do not do locking inside their 
C_Initialize or C_Finalize. They expect that those methods are called 
from a single thread and not concurrently. NSS's libsoftkn3 is a module 
like this.

So I've committed fixes to p11-kit just this morning, which prevent 
concurrent initialization, and handle this case correctly within the 
refcounting framework of p11-kit.

>> But would it make more sense for gnutls to listen to pthread_atfork()
>> and clear out its pkcs#11 state?
>
> Then I'd have exactly the same problem that you have. Performance issues
> :) It might be better for this issue to be solved once and for all users
> of p11-kit.

It's pretty hard to do this correctly at the p11-kit layer. We cannot 
transparently hide the fact that all of a sudden all slots, token info, 
sessions, objects, and other handles have been invalidated. Therefore 
any structures that gnutls is holding must also be cleared on fork.

Forgive me if I'm missing something, but the only way I see to solve 
this part of the problem is for p11-kit to notify gnutls that any and 
all PKCS#11 state is invalid. gnutls would then start from a clean 
pkcs#11 state. I'll work on some patches for gnutls.

Cheers,

Stef



From n.mavrogiannopoulos at gmail.com  Mon Oct 10 23:40:33 2011
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 10 Oct 2011 23:40:33 +0200
Subject: Problems with automatic pkcs11 reinit on fork
In-Reply-To: <4E931A99.10907@collabora.co.uk>
References: <4E8FEB85.90503@collabora.co.uk> <4E902475.90506@gmail.com>
	<4E906EA8.5040601@collabora.co.uk> <4E920E85.6020204@gmail.com>
	<4E931A99.10907@collabora.co.uk>
Message-ID: <4E936651.3010301@gmail.com>

On 10/10/2011 06:17 PM, Stef Walter wrote:

>> Then I'd have exactly the same problem that you have. Performance
>> issues :) It might be better for this issue to be solved once and
>> for all users of p11-kit.
> It's pretty hard to do this correctly at the p11-kit layer. We cannot
>  transparently hide the fact that all of a sudden all slots, token
> info, sessions, objects, and other handles have been invalidated.
> Therefore any structures that gnutls is holding must also be cleared
> on fork. Forgive me if I'm missing something, but the only way I see
> to solve this part of the problem is for p11-kit to notify gnutls
> that any and all PKCS#11 state is invalid. gnutls would then start
> from a clean pkcs#11 state. I'll work on some patches for gnutls.

I wouldn't think gnutls as a special case, but rather as just another
user of the p11-kit framework (glue). Having an API that says please
during fork do that, but if you do fork very often then wait until the
next pkcs11 operation and then do it, or you become slow... sounds
really ugly. Of course there could be a fix for gnutls because the API
is limiting pkcs11 operations, but other users of p11-kit would have
exactly the same problem and a fix might not be so straightforward.

A viable solution I see is wrapping pkcs11 calls. I see how you did that
in gnutls so it looks pretty straightforward that could be added and
exported from p11-kit. But anyway it is your call.

regards,
Nikos



From stefw at collabora.co.uk  Tue Oct 11 09:34:43 2011
From: stefw at collabora.co.uk (Stef Walter)
Date: Tue, 11 Oct 2011 09:34:43 +0200
Subject: Problems with automatic pkcs11 reinit on fork
In-Reply-To: <4E936651.3010301@gmail.com>
References: <4E8FEB85.90503@collabora.co.uk> <4E902475.90506@gmail.com>
	<4E906EA8.5040601@collabora.co.uk> <4E920E85.6020204@gmail.com>
	<4E931A99.10907@collabora.co.uk> <4E936651.3010301@gmail.com>
Message-ID: <4E93F193.50001@collabora.co.uk>

On 10/10/2011 11:40 PM, Nikos Mavrogiannopoulos wrote:
> On 10/10/2011 06:17 PM, Stef Walter wrote:
>
>>> Then I'd have exactly the same problem that you have. Performance
>>> issues :) It might be better for this issue to be solved once and
>>> for all users of p11-kit.
>> It's pretty hard to do this correctly at the p11-kit layer. We cannot
>> transparently hide the fact that all of a sudden all slots, token
>> info, sessions, objects, and other handles have been invalidated.
>> Therefore any structures that gnutls is holding must also be cleared
>> on fork. Forgive me if I'm missing something, but the only way I see
>> to solve this part of the problem is for p11-kit to notify gnutls
>> that any and all PKCS#11 state is invalid. gnutls would then start
>> from a clean pkcs#11 state. I'll work on some patches for gnutls.
>
> I wouldn't think gnutls as a special case, but rather as just another
> user of the p11-kit framework (glue). Having an API that says please
> during fork do that, but if you do fork very often then wait until the
> next pkcs11 operation and then do it, or you become slow... sounds
> really ugly. Of course there could be a fix for gnutls because the API
> is limiting pkcs11 operations, but other users of p11-kit would have
> exactly the same problem and a fix might not be so straightforward.
>
> A viable solution I see is wrapping pkcs11 calls. I see how you did that
> in gnutls so it looks pretty straightforward that could be added and
> exported from p11-kit.

Yes, that's true. I agree, it seems like that's the cleanest way to 
accomplish reinitializing after a fork.

As discussed previously, the caller of p11-kit (like gnutls) would also 
need to be made aware of the reinitialization, via a callback perhaps, 
so that it can clear out its cached information about the state of the 
PKCS#11 modules. These two aspects are obviously not mutually exclusive.

Cheers,

Stef



From simon at josefsson.org  Wed Oct 12 10:51:59 2011
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 12 Oct 2011 10:51:59 +0200
Subject: 2.12.11 includes parts of different gnulib versions
In-Reply-To: <20111002142604.GC2055@downhill.g.la> (Andreas Metzler's message
	of "Sun, 2 Oct 2011 16:26:04 +0200")
References: <20111001123135.GA2098@downhill.g.la>
	<20111002142604.GC2055@downhill.g.la>
Message-ID: <87ty7e1tjk.fsf@latte.josefsson.org>

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

> On 2011-10-01 Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
>> Hello,
>
>> looks like some gnulib update was incomlete in 2.12.11:
>
>> (SID)gnutls-2.12.11$ head -n1 ./lib/gl/m4/float_h.m4 ./gl/m4/float_h.m4
>> ==> ./lib/gl/m4/float_h.m4 <==
>> # float_h.m4 serial 7
>
>> ==> ./gl/m4/float_h.m4 <==
>> # float_h.m4 serial 5
>
> Hello,
> looks like 1f2742f85da1aa1f4c73c44d7fdf1a8f41c82c7d is the cause,
> since then only lib/gl/ has been updated, gl/ and libextra/gl/ seem to
> be stale.

This has been fixed, right?  I just ran 'make glimport' in the 2.12
branch, and there were only minor diffs.

/Simon



From nmav at gnutls.org  Wed Oct 12 19:13:32 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 12 Oct 2011 19:13:32 +0200
Subject: 2.12.11 includes parts of different gnulib versions
In-Reply-To: <87ty7e1tjk.fsf@latte.josefsson.org>
References: <20111001123135.GA2098@downhill.g.la>	<20111002142604.GC2055@downhill.g.la>
	<87ty7e1tjk.fsf@latte.josefsson.org>
Message-ID: <4E95CABC.4060407@gnutls.org>

On 10/12/2011 10:51 AM, Simon Josefsson wrote:
> Andreas Metzler<ametzler at downhill.at.eu.org>  writes:
>
>> On 2011-10-01 Andreas Metzler<ametzler at downhill.at.eu.org>  wrote:
>>> Hello,
>>
>>> looks like some gnulib update was incomlete in 2.12.11:
>>
>>> (SID)gnutls-2.12.11$ head -n1 ./lib/gl/m4/float_h.m4 ./gl/m4/float_h.m4
>>> ==>  ./lib/gl/m4/float_h.m4<==
>>> # float_h.m4 serial 7
>>
>>> ==>  ./gl/m4/float_h.m4<==
>>> # float_h.m4 serial 5
>>
>> Hello,
>> looks like 1f2742f85da1aa1f4c73c44d7fdf1a8f41c82c7d is the cause,
>> since then only lib/gl/ has been updated, gl/ and libextra/gl/ seem to
>> be stale.
>
> This has been fixed, right?  I just ran 'make glimport' in the 2.12
> branch, and there were only minor diffs.

I have imported the new gnulib since then, but there hasn't been any 
release.

regards,
Nikos




From nmav at gnutls.org  Sat Oct 15 01:49:54 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 15 Oct 2011 01:49:54 +0200
Subject: gnutls 3.0.4
Message-ID: <4E98CAA2.8010908@gnutls.org>

Hello,
  I've just released gnutls 3.0.4. It includes several bug fixes
and adds new features to the latest stable branch. Moreover since this
version the printed manual (see
http://www.gnu.org/software/gnutls/documentation.html ) is no longer
used as a donation method, and is available at the printing cost.

The changelog since 3.0.3 follows.

* Version 3.0.4 (released 2011-10-15)

** gnutls-cli-debug: Added more tests including AES-GCM,
SHA256 and elliptic curves.

** gnutls-cli: Added --benchmark-soft-ciphers to benchmark
the software version of the ciphers instead of hw accelerated
(where available)

** libgnutls: Public key ID calculation is consistent among
all structures. It uses a SHA-1 hash of the subjectPublicKeyInfo.

** libgnutls: gnutls_privkey_t allows setting external callback
to perform signing or decryption. Can be set using
gnutls_privkey_import_ext()

** libgnutls: A certificate credentials structure can be
used with a gnutls_privkey_t and a gnutls_pcert_st
structure using gnutls_certificate_set_key().

** libgnutls: Fixes to enable external signing callback to
operate with TLS 1.2.

** libgnutls: Fixed crash when printing ECDSA certificate key
ID. Reported by Erik Jensen.

** libgnutls: Corrected VIA padlock code for C3. In C3 benchmarks
show a 2x increase in AES speed and a 14x increase in VIA nano. Added
support for hashes and HMACs.

** libgnutls: Compilation fixed when p11-kit is not detected.

** libgnutls: Fixed the deflate compression code.

** libgnutls: Added gnutls_x509_crt_get_authority_info_access.
Used to get the PKIX Authority Information Access (AIA) field.

** libgnutls: gnutls_x509_crt_print supports printing AIA fields.

** libgnutls: Added ability to gnutls_privkey_t to operate with
signing callback function.

** API and ABI modifications:
gnutls_x509_crt_get_authority_info_access (x509.h): Added function.
gnutls_privkey_import_ext: Added function.
gnutls_certificate_set_key: Added function.
gnutls_info_access_what_t (x509.h): Added enum.
GNUTLS_OID_AIA (x509.h): Added symbol.
GNUTLS_OID_AD_OCSP (x509.h): Added symbol.
GNUTLS_OID_AD_CAISSUERS (x509.h): Added symbol.


Getting the Software
====================

GnuTLS may be downloaded from one of the GNU mirror sites or directly
 From <ftp://ftp.gnu.org/gnu/gnutls/?.  The list of GNU mirrors can be
found at <http://www.gnu.org/prep/ftp.html> and a list of GnuTLS mirrors
can be found at <http://www.gnu.org/software/gnutls/download.html>.

Here are the XZ compressed sources:

   ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.4.tar.xz
   http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.4.tar.xz
   ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.4.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

   ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.4.tar.xz.sig
   http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.4.tar.xz.sig
   ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.4.tar.xz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
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]

regards,
Nikos



From ametzler at downhill.at.eu.org  Sat Oct 15 10:02:44 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 15 Oct 2011 10:02:44 +0200
Subject: gnutls 3.0.4
In-Reply-To: <4E98CAA2.8010908@gnutls.org>
References: <4E98CAA2.8010908@gnutls.org>
Message-ID: <20111015080244.GB1999@downhill.g.la>

On 2011-10-15 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
>  I've just released gnutls 3.0.4. 
[...]

Hello,
The newly added padlock-common.s is missing a GNU-stack note,
therefore the resulting library comes with an executable stack. Find
attached a trivial patch (copy and paste from your fix for the same
problem in 3.0.1).

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 ametzler at downhill.at.eu.org  Sat Oct 15 10:21:23 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 15 Oct 2011 10:21:23 +0200
Subject: gnutls 3.0.4
In-Reply-To: <20111015080244.GB1999@downhill.g.la>
References: <4E98CAA2.8010908@gnutls.org> <20111015080244.GB1999@downhill.g.la>
Message-ID: <20111015082123.GC1999@downhill.g.la>

On 2011-10-15 Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
[...] 
> Find attached
[...]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: addGNU-stack.diff
Type: text/x-diff
Size: 409 bytes
Desc: not available
URL: </pipermail/attachments/20111015/565b4aa5/attachment.diff>

From ametzler at downhill.at.eu.org  Sat Oct 15 10:56:58 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 15 Oct 2011 10:56:58 +0200
Subject: [3.0.4] gnutls_register_md5_handler defined in gnutls/extra.h but
	not present in gnutls-extra
Message-ID: <20111015085658.GD1999@downhill.g.la>

Hello,

3.0.4 drops gnutls_register_md5_handler from libgnutls-extra.so, it is
still present in the header file and .map.

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 ametzler at downhill.at.eu.org  Sat Oct 15 13:47:53 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 15 Oct 2011 13:47:53 +0200
Subject: [3.0.4] gnutls_register_md5_handler defined in gnutls/extra.h
	but not present in gnutls-extra
In-Reply-To: <20111015085658.GD1999@downhill.g.la>
References: <20111015085658.GD1999@downhill.g.la>
Message-ID: <20111015114753.GF1999@downhill.g.la>

On 2011-10-15 Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
> 3.0.4 drops gnutls_register_md5_handler from libgnutls-extra.so, it is
> still present in the header file and .map.

FWIW I have decided to stop shipping libgnutls-extra 3.0 in Debian,
there really is no point as long it is an empty shell. (Once it
provides functionality again it will be added back of course)

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  Sat Oct 15 19:50:26 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 15 Oct 2011 19:50:26 +0200
Subject: gnutls 3.0.4
In-Reply-To: <20111015082123.GC1999@downhill.g.la>
References: <4E98CAA2.8010908@gnutls.org> <20111015080244.GB1999@downhill.g.la>
	<20111015082123.GC1999@downhill.g.la>
Message-ID: <4E99C7E2.40207@gnutls.org>

On 10/15/2011 10:21 AM, Andreas Metzler wrote:
> On 2011-10-15 Andreas Metzler<ametzler at downhill.at.eu.org>  wrote:
> [...]
>> Find attached
> [...]

Thanks. Applied.

regards,
Nikos



From nmav at gnutls.org  Sat Oct 15 20:03:16 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 15 Oct 2011 20:03:16 +0200
Subject: [3.0.4] gnutls_register_md5_handler defined in gnutls/extra.h
	but not present in gnutls-extra
In-Reply-To: <20111015114753.GF1999@downhill.g.la>
References: <20111015085658.GD1999@downhill.g.la>
	<20111015114753.GF1999@downhill.g.la>
Message-ID: <4E99CAE4.4070104@gnutls.org>

On 10/15/2011 01:47 PM, Andreas Metzler wrote:
> On 2011-10-15 Andreas Metzler<ametzler at downhill.at.eu.org>  wrote:
>> 3.0.4 drops gnutls_register_md5_handler from libgnutls-extra.so, it is

I removed it because the function would serve no purpose under nettle. I 
forgot about bumping the gnutls-extra version though. This might require 
a bug-fix release, but I doubt if it is of any use.

>> still present in the header file and .map.
> FWIW I have decided to stop shipping libgnutls-extra 3.0 in Debian,
> there really is no point as long it is an empty shell. (Once it
> provides functionality again it will be added back of course)

I think gnutls-extra has served its purpose and it is no longer useful. 
I have no plans to revive it with new features, so if Simon also agrees 
it might as well be dropped from gnutls.

regards,
Nikos



From ametzler at downhill.at.eu.org  Sun Oct 16 18:09:05 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 16 Oct 2011 18:09:05 +0200
Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and mipsel
Message-ID: <20111016160905.GA1921@downhill.g.la>

Hello,

starting with version 3.0.1 (3.0.0 is ok) three guile tests segfault
on armel and mipsel:

-----------8X-------------------------------------------------------------
--- buildlog.gnutls28.3.0.0.armel       2011-10-16 17:48:04.000000000 +0200
+++ buildlog.gnutls28.3.0.1.armel       2011-10-16 17:48:07.000000000 +0200
[...]
@@ -4896,1204 +5697,30 @@ make[3]: Entering directory `/build-gnut
 /usr/bin/make  check-TESTS
 make[4]: Entering directory `/build-gnutls/guile/tests'
 PASS: anonymous-auth.scm
-
-Some deprecated features have been used.  Set the environment
-variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
-program to get more information.  Set it to "no" to suppress
-this message.
-
-Some deprecated features have been used.  Set the environment
-variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
-program to get more information.  Set it to "no" to suppress
-this message.
-PASS: session-record-port.scm
+/bin/bash: line 5: 10178 Segmentation fault      GUILE_AUTO_COMPILE=0 ../../guile/pre-inst-guile -L . ${dir}$tst
+FAIL: session-record-port.scm
 PASS: pkcs-import-export.scm
 PASS: errors.scm
 PASS: x509-certificates.scm
-
-Some deprecated features have been used.  Set the environment
-variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
-program to get more information.  Set it to "no" to suppress
-this message.
-
-Some deprecated features have been used.  Set the environment
-variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
-program to get more information.  Set it to "no" to suppress
-this message.
-PASS: x509-auth.scm
+/bin/bash: line 5: 10228 Segmentation fault      GUILE_AUTO_COMPILE=0 ../../guile/pre-inst-guile -L . ${dir}$tst
+FAIL: x509-auth.scm
 PASS: priorities.scm
 PASS: openpgp-keys.scm
 PASS: openpgp-keyring.scm
-PASS: openpgp-auth.scm
+/bin/bash: line 5: 10279 Segmentation fault      GUILE_AUTO_COMPILE=0 ../../guile/pre-inst-guile -L . ${dir}$tst
+FAIL: openpgp-auth.scm
 PASS: srp-base64.scm
-===================
-All 11 tests passed
-===================
+===================================
+3 of 11 tests failed
+Please report to bug-gnutls at gnu.org
+===================================
+make[4]: *** [check-TESTS] Error 1
 make[4]: Leaving directory `/build-gnutls/guile/tests'
-----------8X-------------------------------------------------------------

gdb does not look very helpful:

-----------8X-------------------------------------------------------------
(sid)ametzler at abel:~/GNUTLS/gnutls28-3.0.1/guile/tests$ env LD_PRELOAD=/lib/arm-linux-gnueabi/libpthread.so.0 LD_LIBRARY_PATH=/home/ametzler/GNUTLS/gnutls28-3.0.1/guile/src/.libs:/home/ametzler/GNUTLS/gnutls28-3.0.1/lib/.libs  GUILE_LOAD_PATH="/home/ametzler/GNUTLS/gnutls28-3.0.1/guile/modules" GUILE_AUTO_COMPILE=0 ~/x/usr/bin/guile -L . session-record-port.scm
Segmentation fault
(sid)ametzler at abel:~/GNUTLS/gnutls28-3.0.1/guile/tests$ env LD_PRELOAD=/lib/arm-linux-gnueabi/libpthread.so.0 LD_LIBRARY_PATH=/home/ametzler/GNUTLS/gnutls28-3.0.1/guile/src/.libs:/home/ametzler/GNUTLS/gnutls28-3.0.1/lib/.libs  GUILE_LOAD_PATH="/home/ametzler/GNUTLS/gnutls28-3.0.1/guile/modules" GUILE_AUTO_COMPILE=0 gdb --args ~/x/usr/bin/guile -L . session-record-port.scm
GNU gdb (GDB) 7.3-debian
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/ametzler/x/usr/bin/guile...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/ametzler/x/usr/bin/guile -L . session-record-port.scm
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
*__GI___libc_free (mem=0x1) at malloc.c:3709
3709    malloc.c: No such file or directory.
        in malloc.c
(gdb) bt
#0  *__GI___libc_free (mem=0x1) at malloc.c:3709
#1  0x400b59cc in scm_gc_free () from /usr/lib/libguile.so.17
#2  0x400d79cc in scm_remove_from_port_table () from /usr/lib/libguile.so.17
#3  0x400b5f28 in scm_i_sweep_card () from /usr/lib/libguile.so.17
#4  0x404248f0 in ?? ()
Cannot access memory at address 0x34
#5  0x404248f0 in ?? ()
Cannot access memory at address 0x34
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)
-----------8X-------------------------------------------------------------

(I have built both 3.0.0 and 3.0.1 with the same development
environment.)

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  Mon Oct 17 10:11:50 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 17 Oct 2011 10:11:50 +0200
Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and
	mipsel
In-Reply-To: <20111016160905.GA1921@downhill.g.la>
References: <20111016160905.GA1921@downhill.g.la>
Message-ID: <CAJU7zaKegN64-28UF+QHBpO+JjgTaRs9VCFg9npVvJdC=WPh5A@mail.gmail.com>

Hi Ludovic, any ideas?

On Sun, Oct 16, 2011 at 6:09 PM, Andreas Metzler
<ametzler at downhill.at.eu.org> wrote:
> Hello,
>
> starting with version 3.0.1 (3.0.0 is ok) three guile tests segfault
> on armel and mipsel:
>
> -----------8X-------------------------------------------------------------
> --- buildlog.gnutls28.3.0.0.armel ? ? ? 2011-10-16 17:48:04.000000000 +0200
> +++ buildlog.gnutls28.3.0.1.armel ? ? ? 2011-10-16 17:48:07.000000000 +0200
> [...]
> @@ -4896,1204 +5697,30 @@ make[3]: Entering directory `/build-gnut
> ?/usr/bin/make ?check-TESTS
> ?make[4]: Entering directory `/build-gnutls/guile/tests'
> ?PASS: anonymous-auth.scm
> -
> -Some deprecated features have been used. ?Set the environment
> -variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
> -program to get more information. ?Set it to "no" to suppress
> -this message.
> -
> -Some deprecated features have been used. ?Set the environment
> -variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
> -program to get more information. ?Set it to "no" to suppress
> -this message.
> -PASS: session-record-port.scm
> +/bin/bash: line 5: 10178 Segmentation fault ? ? ?GUILE_AUTO_COMPILE=0 ../../guile/pre-inst-guile -L . ${dir}$tst
> +FAIL: session-record-port.scm
> ?PASS: pkcs-import-export.scm
> ?PASS: errors.scm
> ?PASS: x509-certificates.scm
> -
> -Some deprecated features have been used. ?Set the environment
> -variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
> -program to get more information. ?Set it to "no" to suppress
> -this message.
> -
> -Some deprecated features have been used. ?Set the environment
> -variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
> -program to get more information. ?Set it to "no" to suppress
> -this message.
> -PASS: x509-auth.scm
> +/bin/bash: line 5: 10228 Segmentation fault ? ? ?GUILE_AUTO_COMPILE=0 ../../guile/pre-inst-guile -L . ${dir}$tst
> +FAIL: x509-auth.scm
> ?PASS: priorities.scm
> ?PASS: openpgp-keys.scm
> ?PASS: openpgp-keyring.scm
> -PASS: openpgp-auth.scm
> +/bin/bash: line 5: 10279 Segmentation fault ? ? ?GUILE_AUTO_COMPILE=0 ../../guile/pre-inst-guile -L . ${dir}$tst
> +FAIL: openpgp-auth.scm
> ?PASS: srp-base64.scm
> -===================
> -All 11 tests passed
> -===================
> +===================================
> +3 of 11 tests failed
> +Please report to bug-gnutls at gnu.org
> +===================================
> +make[4]: *** [check-TESTS] Error 1
> ?make[4]: Leaving directory `/build-gnutls/guile/tests'
> -----------8X-------------------------------------------------------------
>
> gdb does not look very helpful:
>
> -----------8X-------------------------------------------------------------
> (sid)ametzler at abel:~/GNUTLS/gnutls28-3.0.1/guile/tests$ env LD_PRELOAD=/lib/arm-linux-gnueabi/libpthread.so.0 LD_LIBRARY_PATH=/home/ametzler/GNUTLS/gnutls28-3.0.1/guile/src/.libs:/home/ametzler/GNUTLS/gnutls28-3.0.1/lib/.libs ?GUILE_LOAD_PATH="/home/ametzler/GNUTLS/gnutls28-3.0.1/guile/modules" GUILE_AUTO_COMPILE=0 ~/x/usr/bin/guile -L . session-record-port.scm
> Segmentation fault
> (sid)ametzler at abel:~/GNUTLS/gnutls28-3.0.1/guile/tests$ env LD_PRELOAD=/lib/arm-linux-gnueabi/libpthread.so.0 LD_LIBRARY_PATH=/home/ametzler/GNUTLS/gnutls28-3.0.1/guile/src/.libs:/home/ametzler/GNUTLS/gnutls28-3.0.1/lib/.libs ?GUILE_LOAD_PATH="/home/ametzler/GNUTLS/gnutls28-3.0.1/guile/modules" GUILE_AUTO_COMPILE=0 gdb --args ~/x/usr/bin/guile -L . session-record-port.scm
> GNU gdb (GDB) 7.3-debian
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. ?Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "arm-linux-gnueabi".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /home/ametzler/x/usr/bin/guile...(no debugging symbols found)...done.
> (gdb) run
> Starting program: /home/ametzler/x/usr/bin/guile -L . session-record-port.scm
> [Thread debugging using libthread_db enabled]
>
> Program received signal SIGSEGV, Segmentation fault.
> *__GI___libc_free (mem=0x1) at malloc.c:3709
> 3709 ? ?malloc.c: No such file or directory.
> ? ? ? ?in malloc.c
> (gdb) bt
> #0 ?*__GI___libc_free (mem=0x1) at malloc.c:3709
> #1 ?0x400b59cc in scm_gc_free () from /usr/lib/libguile.so.17
> #2 ?0x400d79cc in scm_remove_from_port_table () from /usr/lib/libguile.so.17
> #3 ?0x400b5f28 in scm_i_sweep_card () from /usr/lib/libguile.so.17
> #4 ?0x404248f0 in ?? ()
> Cannot access memory at address 0x34
> #5 ?0x404248f0 in ?? ()
> Cannot access memory at address 0x34
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
> -----------8X-------------------------------------------------------------
>
> (I have built both 3.0.0 and 3.0.1 with the same development
> environment.)
>
> 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'
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> https://lists.gnu.org/mailman/listinfo/gnutls-devel
>



From vuntz at gnome.org  Mon Oct 17 15:19:37 2011
From: vuntz at gnome.org (Vincent Untz)
Date: Mon, 17 Oct 2011 15:19:37 +0200
Subject: [patch] Fix a crash when getting dn of a certificate
Message-ID: <20111017131937.GS32466@vuntz.net>

Hi,

Somebody stumbled upon this gnutls crash in openSUSE:

*** glibc detected *** /usr/lib/telepathy-haze: free(): invalid pointer: 0x0000000000a5d900 ***

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff66e9f10 in malloc_consolidate () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff66e9f10 in malloc_consolidate () from /lib64/libc.so.6
#1  0x00007ffff66eb0d3 in _int_malloc () from /lib64/libc.so.6
#2  0x00007ffff66ec1d2 in malloc_check () from /lib64/libc.so.6
#3  0x00007ffff66ef11d in calloc () from /lib64/libc.so.6
#4  0x00007ffff7de69ce in _dl_new_object () from /lib64/ld-linux-x86-64.so.2
#5  0x00007ffff7de2196 in _dl_map_object_from_fd () from /lib64/ld-linux-x86-64.so.2
#6  0x00007ffff7de3f97 in _dl_map_object () from /lib64/ld-linux-x86-64.so.2
#7  0x00007ffff7dedc2b in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#8  0x00007ffff7de9bd6 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#9  0x00007ffff7ded7ca in _dl_open () from /lib64/ld-linux-x86-64.so.2
#10 0x00007ffff6785440 in do_dlopen () from /lib64/libc.so.6
#11 0x00007ffff7de9bd6 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#12 0x00007ffff67854df in dlerror_run () from /lib64/libc.so.6
#13 0x00007ffff6785547 in __libc_dlopen_mode () from /lib64/libc.so.6
#14 0x00007ffff67609d5 in init () from /lib64/libc.so.6
#15 0x00007ffff6a103d3 in pthread_once () from /lib64/libpthread.so.0
#16 0x00007ffff6760af4 in backtrace () from /lib64/libc.so.6
#17 0x00007ffff66e3e8f in __libc_message () from /lib64/libc.so.6
#18 0x00007ffff66e9bb6 in malloc_printerr () from /lib64/libc.so.6
#19 0x00007fffece76eb4 in _gnutls_x509_parse_dn (asn1_struct=0x9cbc40, asn1_rdn_name=
    0x7fffeced0d68 "tbsCertificate.subject.rdnSequence", buf=0x0, sizeof_buf=0x7fffffffd338) at dn.c:287

(from https://bugzilla.novell.com/show_bug.cgi?id=724421)

Here's a patch to fix it.

Cheers,

Vincent

-- 
Les gens heureux ne sont pas press?s.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Correctly-terminate-a-string-with-0-before-concatena.patch
Type: text/x-diff
Size: 728 bytes
Desc: not available
URL: </pipermail/attachments/20111017/b53f43f7/attachment.patch>

From stef-list at thewalter.net  Mon Oct 17 15:36:26 2011
From: stef-list at thewalter.net (Stef Walter)
Date: Mon, 17 Oct 2011 15:36:26 +0200
Subject: about PKCS11
In-Reply-To: <4E8FE946.1000502@collabora.co.uk>
References: <CAMq1adrNEwYCCRHwMCBK++2zALX3AcZ-YrLLwXPpn_hENXjTBg@mail.gmail.com>
	<4E8E055D.2080900@gnutls.org> <4E8FE946.1000502@collabora.co.uk>
Message-ID: <4E9C2F5A.2080706@thewalter.net>

On 10/08/2011 08:10 AM, Stef Walter wrote:
> On 2011-10-06 21:45, Nikos Mavrogiannopoulos wrote:
>> Hello,
>>  Do you need smart card support? If not just use the --without-p11-kit
>> configure flag. If you need smart-card support in gnutls, then I don't
>> know whether p11-kit is could run on windows. Stef would have more
>> insight on that.
> 
> Yes, win32 support needs to be done. I don't see any major obstacles,
> but I just need to get a win32 VM setup and actually work on it. I
> imagine I'll need to do an MSVC and a GCC mingw build. I'm not looking
> forward to releasing binaries, but at least I'll get it building.

Completed the initial port of p11-kit to win32. It's at p11-kit git master.

The build works, and the tools run. I built with:

$ ./autogen.sh --host=i586-mingw32msvc --enable-strict ...

The tests don't all pass on wine yet. In particular the test-init
recursion test fails. But I'm not sure if this is a wine bug or a
problem in the p11-kit windows stuff.

The win32 port needs more attention, but at least this is a start.

Thanks Vincent for your help.

Cheers,

Stef



From ludo at gnu.org  Tue Oct 18 22:06:27 2011
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 18 Oct 2011 22:06:27 +0200
Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and
	mipsel
In-Reply-To: <CAJU7zaKegN64-28UF+QHBpO+JjgTaRs9VCFg9npVvJdC=WPh5A@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Mon, 17 Oct 2011 10:11:50
	+0200")
References: <20111016160905.GA1921@downhill.g.la>
	<CAJU7zaKegN64-28UF+QHBpO+JjgTaRs9VCFg9npVvJdC=WPh5A@mail.gmail.com>
Message-ID: <87mxcyqd30.fsf@gnu.org>

Hi,

Nikos Mavrogiannopoulos <nmav at gnutls.org> skribis:

> Hi Ludovic, any ideas?

I?ll check on my ARM-based plug, but in the meantime, what Guile version
is it (apparently 1.8.x)?

Andreas: Could you bisect it yourself, between 3.0.0 and 3.0.1?

(I would recommend switching to 2.0.x.)

Thanks,
Ludo?.



From ametzler at downhill.at.eu.org  Wed Oct 19 19:08:34 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Wed, 19 Oct 2011 19:08:34 +0200
Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and
	mipsel
In-Reply-To: <87mxcyqd30.fsf@gnu.org>
References: <20111016160905.GA1921@downhill.g.la>
	<CAJU7zaKegN64-28UF+QHBpO+JjgTaRs9VCFg9npVvJdC=WPh5A@mail.gmail.com>
	<87mxcyqd30.fsf@gnu.org>
Message-ID: <20111019170834.GA2086@downhill.g.la>

On 2011-10-18 Ludovic Court?s <ludo at gnu.org> wrote:
> Nikos Mavrogiannopoulos <nmav at gnutls.org> skribis:

> > Hi Ludovic, any ideas?

> I?ll check on my ARM-based plug, but in the meantime, what Guile version
> is it (apparently 1.8.x)?

Debian 1.8.8+1-6.1

> Andreas: Could you bisect it yourself, between 3.0.0 and 3.0.1?

I probably won't have time before the weekend, but I will try then if
the issue is still open.

> (I would recommend switching to 2.0.x.)

It is not yet in Debian but I will keep this in mind.
cu andreas



From ludo at gnu.org  Wed Oct 19 23:49:33 2011
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 19 Oct 2011 23:49:33 +0200
Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and
	mipsel
In-Reply-To: <CAJU7zaKegN64-28UF+QHBpO+JjgTaRs9VCFg9npVvJdC=WPh5A@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Mon, 17 Oct 2011 10:11:50
	+0200")
References: <20111016160905.GA1921@downhill.g.la>
	<CAJU7zaKegN64-28UF+QHBpO+JjgTaRs9VCFg9npVvJdC=WPh5A@mail.gmail.com>
Message-ID: <87hb34mz2q.fsf@gnu.org>

Hello,

Nikos Mavrogiannopoulos <nmav at gnutls.org> skribis:

> On Sun, Oct 16, 2011 at 6:09 PM, Andreas Metzler
> <ametzler at downhill.at.eu.org> wrote:

[...]

>> (gdb) bt
>> #0 ?*__GI___libc_free (mem=0x1) at malloc.c:3709
>> #1 ?0x400b59cc in scm_gc_free () from /usr/lib/libguile.so.17
>> #2 ?0x400d79cc in scm_remove_from_port_table () from /usr/lib/libguile.so.17
>> #3 ?0x400b5f28 in scm_i_sweep_card () from /usr/lib/libguile.so.17
>> #4 ?0x404248f0 in ?? ()

I?ve reproduced it on armv5tel-unknown-linux-gnueabi, with Guile 1.8.8,
GCC 4.5.1, and glibc 2.12.

The 0x1 above seems to be the value of some port?s ?putback_buf? field.
Normally it should be either NULL or a valid pointer.

Adding ?c_port->putback_buf = NULL? in
$GNUTLS/guile/src/core.c:make_session_record_port, which is supposed to
be a non-functional change, leads to a malloc inconsistency much more
quickly (setting $MALLOC_CHECK_=2 helps catch it.)

So I?m starting to wonder if libguile and GnuTLS somehow have a
different vision of the layout of ?scm_t_port?, which would explain
these inconsistencies.

To be continued...

Ludo?.



From nmav at gnutls.org  Thu Oct 20 21:18:57 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 20 Oct 2011 21:18:57 +0200
Subject: gnutls 2.12.12
Message-ID: <4EA07421.9060003@gnutls.org>

Hello,
  I've just released gnutls 2.12.12. This is a bugfix
release on the 2.12.x branch.

Version 2.12.12 (released 2011-10-20)

** gnulib: updated

** libgnutls: Fixes to enable external signing callback to
operate with TLS 1.2.

** API and ABI modifications:
No changes since last version.



Getting the Software
====================

GnuTLS may be downloaded from one of the GNU mirror sites or directly
 From <ftp://ftp.gnu.org/gnu/gnutls/?.  The list of GNU mirrors can be
found at <http://www.gnu.org/prep/ftp.html> and a list of GnuTLS mirrors
can be found at <http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources:

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

Here are OpenPGP detached signatures signed using key 0x96865171:

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

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
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]

regards,
Nikos



From hoyt6 at llnl.gov  Thu Oct 20 23:26:46 2011
From: hoyt6 at llnl.gov (Hoyt, David)
Date: Thu, 20 Oct 2011 14:26:46 -0700
Subject: gnutls 3.0.4 and mingw-w64 build issues
Message-ID: <B288BDCCFC5B874BBC7D22117EDFB6F9010B335C76B4@NSPEXMBX-C.the-lab.llnl.gov>

When building 3.0.4 with mingw-w64 (gcc 4.5.2) on a windows 7 machine, I get the following error:


In file included from gnutls-3.0.4/lib/x509/common.c:24:0:
gnutls-3.0.4/lib/x509/../gnutls_int.h:46:24: fatal error: sys/socket.h: No such file or directory
compilation terminated. 


I double checked and I do not have sys/socket.h. What's the correct fix for gnutls_int.h? Removing the include altogether allowed compilation to proceed further (so perhaps the include could be guarded if needed elsewhere), but then I got:


In file included from gnutls-3.0.4/lib/accelerated/x86/sha-padlock.c:24:0:
gnutls-3.0.4/lib/accelerated/x86/../../gnutls_int.h:65:27: fatal error: gnutls/gnutls.h: No such file or directory
compilation terminated.
make[4]: *** [sha-padlock.lo] Error 1


Not exactly sure what's the best way to fix that.

Thanks,
- David Hoyt



From ametzler at downhill.at.eu.org  Sat Oct 22 13:51:15 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 22 Oct 2011 13:51:15 +0200
Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and
	mipsel
In-Reply-To: <20111019170834.GA2086@downhill.g.la>
References: <20111016160905.GA1921@downhill.g.la>
	<CAJU7zaKegN64-28UF+QHBpO+JjgTaRs9VCFg9npVvJdC=WPh5A@mail.gmail.com>
	<87mxcyqd30.fsf@gnu.org> <20111019170834.GA2086@downhill.g.la>
Message-ID: <20111022115115.GA2707@downhill.g.la>

On 2011-10-19 Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
> On 2011-10-18 Ludovic Court?s <ludo at gnu.org> wrote:
[...]
> > Andreas: Could you bisect it yourself, between 3.0.0 and 3.0.1?

> I probably won't have time before the weekend, but I will try then if
> the issue is still open.
[...]

The commit which triggers the bug is this one:
|-----------------------------
| From 2385c7f999c12802b11859a34b89ff7662b1f4af Mon Sep 17 00:00:00 2001
| From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
| Date: Sat, 13 Aug 2011 14:10:55 +0200
| Subject: [PATCH] Added crywrap to the distributed programs.
|-----------------------------

Apart from adding crywrap it adds a lot of new gnulib modules, I guess 
one of these causes the problem.

cu andreas



From INVALID.NOREPLY at gnu.org  Sun Oct 23 13:46:13 2011
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Sun, 23 Oct 2011 11:46:13 +0000
Subject: [sr #107850] gnutls 3.0.4 fails to compile on VIA C7 unless
	--disable-hardware-acceleration is provided
Message-ID: <20111023-114612.sv0.97001@savannah.gnu.org>

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

                 Summary: gnutls 3.0.4 fails to compile on VIA C7 unless
--disable-hardware-acceleration is provided
                 Project: GnuTLS
            Submitted by: None
            Submitted on: Sun 23 Oct 2011 11:46:12 AM UTC
                Category: Core library
                Priority: 5 - Normal
                Severity: 4 - Important
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: fijam at archlinux.us
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

I cannot compile gnutls 3.0.4 on a system with the following processor (VIA
C7):

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 10
model name      : VIA Esther processor  800MHz
stepping        : 9
[...]
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge cmov pat
clflush acpi mmx fxsr sse sse2 tm nx up pni est tm2 rng rng_en ace ace_en ace2
ace2_en phe phe_en pmm pmm_en

using the following configure switches:
 ./configure --prefix=/usr \
        --with-zlib \
        --disable-static \
        --disable-guile \
        --disable-valgrind-tests

The compilation fails at:

make[3]: Entering directory `/var/abs/extra/gnutls/src/gnutls-3.0.4/tests'
/bin/sh: line 5:  8042 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: mini-deflate
PASS: simple
/bin/sh: line 5:  8050 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: gc
/bin/sh: line 5:  8055 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: set_pkcs12_cred
/bin/sh: line 5:  8060 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: certder
/bin/sh: line 5:  8065 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: certuniqueid
/bin/sh: line 5:  8070 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: mpi
/bin/sh: line 5:  8075 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: certificate_set_x509_crl
/bin/sh: line 5:  8080 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: dn
/bin/sh: line 5:  8085 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: parse_ca
/bin/sh: line 5:  8090 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: moredn
/bin/sh: line 5:  8095 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: mini
/bin/sh: line 5:  8100 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: hostname-check
/bin/sh: line 5:  8105 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: cve-2008-4989
/bin/sh: line 5:  8110 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: pkcs12_s2k
/bin/sh: line 5:  8115 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: chainverify
/bin/sh: line 5:  8120 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: crq_key_id
/bin/sh: line 5:  8125 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: x509sign-verify
/bin/sh: line 5:  8130 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: cve-2009-1415
/bin/sh: line 5:  8135 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: cve-2009-1416
/bin/sh: line 5:  8140 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: crq_apis
/bin/sh: line 5:  8145 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: init_roundtrip
/bin/sh: line 5:  8150 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: pkcs12_s2k_pem
/bin/sh: line 5:  8155 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: dn2
/bin/sh: line 5:  8160 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: mini-eagain
/bin/sh: line 5:  8165 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: nul-in-x509-names
/bin/sh: line 5:  8170 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: x509_altname
/bin/sh: line 5:  8175 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: pkcs12_encode
/bin/sh: line 5:  8180 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: mini-x509
/bin/sh: line 5:  8185 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: mini-x509-rehandshake
/bin/sh: line 5:  8190 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: rng-fork
/bin/sh: line 5:  8195 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: mini-eagain-dtls
/bin/sh: line 5:  8200 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: cipher-test
/bin/sh: line 5:  8205 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: x509cert
/bin/sh: line 5:  8210 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: x509cert-tl
/bin/sh: line 5:  8215 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: infoaccess
/bin/sh: line 5:  8220 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: openssl
/bin/sh: line 5:  8225 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: openpgp-auth
/bin/sh: line 5:  8230 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: openpgp-auth2
/bin/sh: line 5:  8235 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: openpgp-keyring
/bin/sh: line 5:  8240 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: pgps2kgnu
/bin/sh: line 5:  8245 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: x509self
/bin/sh: line 5:  8251 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: x509dn
/bin/sh: line 5:  8257 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: anonself
/bin/sh: line 5:  8263 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: pskself
/bin/sh: line 5:  8269 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: dhepskself
try to resume from db
/bin/sh: line 5:  8275 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: resume
/bin/sh: line 5:  8281 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: setcredcrash
/bin/sh: line 5:  8286 Segmentation fault     
PKCS12FILE=./pkcs12-decode/client.p12 PKCS12PASSWORD=foobar
PKCS12FILE_2=./pkcs12-decode/pkcs12_2certs.p12 PKCS12PASSWORD_2="" EXEEXT=
srcdir="." ${dir}$tst
FAIL: openpgpself
RFC 2253 escaping not working?
FAIL: rfc2253-escape-test
===================================
49 of 50 tests failed

I have tried the following (infoaccess chosen at random, I tried a handful of
executables from /tests and they all fail in the same fashion):

$ gdb tests/infoaccess
[...]
(gdb) run
Starting program: /var/abs/extra/gnutls/src/gnutls-3.0.4/tests/infoaccess
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0xb7f77484 in register_padlock_crypto ()
   from /var/abs/extra/gnutls/src/gnutls-3.0.4/lib/.libs/libgnutls.so.28

(gdb) bt
#0  0xb7f77484 in register_padlock_crypto ()
   from /var/abs/extra/gnutls/src/gnutls-3.0.4/lib/.libs/libgnutls.so.28
#1  0xb7f76b65 in _gnutls_register_accel_crypto ()
   from /var/abs/extra/gnutls/src/gnutls-3.0.4/lib/.libs/libgnutls.so.28
#2  0xb7f1d103 in gnutls_global_init ()
   from /var/abs/extra/gnutls/src/gnutls-3.0.4/lib/.libs/libgnutls.so.28
#3  0x08048a9a in doit ()
#4  0x08048975 in main ()


Please let me know what other information do you need. Alternatively, I can
hook you up with SSH access to the affected machine.

Compiling with --disable-hardware-acceleration works just fine.




    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Oct 23 14:16:17 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 23 Oct 2011 12:16:17 +0000
Subject: [sr #107850] gnutls 3.0.4 fails to compile on VIA C7 unless
	--disable-hardware-acceleration is provided
In-Reply-To: <20111023-114612.sv0.97001@savannah.gnu.org>
References: <20111023-114612.sv0.97001@savannah.gnu.org>
Message-ID: <20111023-151617.sv707.70116@savannah.gnu.org>

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

Hi,
 Did you compile without debugging symbols? If yes could you add "-g" to the
cflags? I'd like to see the line in aes-padlock.c or at least the instruction
that failed. It could be that C7 has differences with nano in the instruction
set (e.g. sse3 or so). 

If you could provide ssh access would be best. In the case contact me at
nmav at gnutls.org



    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Oct 23 14:16:36 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 23 Oct 2011 12:16:36 +0000
Subject: [sr #107831] local 'len' in gnutls_x509_crt_get_key_id not
	initialized, causing segmentation fault
In-Reply-To: <20111005-191650.sv0.96069@savannah.gnu.org>
References: <20111005-184511.sv0.14983@savannah.gnu.org>
	<20111005-221243.sv707.38273@savannah.gnu.org>
	<20111005-191650.sv0.96069@savannah.gnu.org>
Message-ID: <20111023-151635.sv707.89702@savannah.gnu.org>

Update of sr #107831 (project gnutls):

                  Status:                    None => Done                   
             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Oct 23 14:16:56 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 23 Oct 2011 12:16:56 +0000
Subject: [sr #107827] Build GnuTLS 3.0.2 for windows!
In-Reply-To: <20111004-094928.sv79827.7974@savannah.gnu.org>
References: <20111003-123524.sv79827.16222@savannah.gnu.org>
	<20111003-123802.sv79827.15794@savannah.gnu.org>
	<20111003-130328.sv79827.54599@savannah.gnu.org>
	<20111003-130406.sv0.78656@savannah.gnu.org>
	<20111003-131152.sv79827.45963@savannah.gnu.org>
	<20111003-140539.sv79827.5756@savannah.gnu.org>
	<20111003-152648.sv79827.32280@savannah.gnu.org>
	<20111003-183846.sv707.91169@savannah.gnu.org>
	<20111003-160359.sv79827.65375@savannah.gnu.org>
	<20111003-192221.sv707.98243@savannah.gnu.org>
	<20111003-190517.sv79827.74921@savannah.gnu.org>
	<20111003-201521.sv79827.7196@savannah.gnu.org>
	<20111004-001840.sv707.27571@savannah.gnu.org>
	<20111004-081036.sv79827.10689@savannah.gnu.org>
	<20111004-092951.sv0.30997@savannah.gnu.org>
	<20111004-094928.sv79827.7974@savannah.gnu.org>
Message-ID: <20111023-151655.sv707.51284@savannah.gnu.org>

Update of sr #107827 (project gnutls):

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


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Oct 23 14:17:19 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 23 Oct 2011 12:17:19 +0000
Subject: [sr #107822] Testing 3.0.2 on AIX
In-Reply-To: <20111003-130013.sv0.371@savannah.gnu.org>
References: <20110928-125430.sv79827.62919@savannah.gnu.org>
	<20110928-132311.sv0.16882@savannah.gnu.org>
	<20110928-135723.sv79827.24851@savannah.gnu.org>
	<20110928-140451.sv0.84588@savannah.gnu.org>
	<20110928-162408.sv79827.98884@savannah.gnu.org>
	<20110928-165745.sv79827.49308@savannah.gnu.org>
	<20110928-232900.sv707.53794@savannah.gnu.org>
	<20110929-075006.sv79827.50491@savannah.gnu.org>
	<20110929-104705.sv79827.7753@savannah.gnu.org>
	<20110929-135104.sv79827.16087@savannah.gnu.org>
	<20110929-192206.sv707.39913@savannah.gnu.org>
	<20110930-075623.sv79827.28701@savannah.gnu.org>
	<20110930-082023.sv0.57421@savannah.gnu.org>
	<20110930-101556.sv79827.50138@savannah.gnu.org>
	<20110930-124921.sv79827.49719@savannah.gnu.org>
	<20110930-170011.sv707.80734@savannah.gnu.org>
	<20111003-090850.sv79827.43226@savannah.gnu.org>
	<20111003-092331.sv79827.91634@savannah.gnu.org>
	<20111003-104437.sv0.99636@savannah.gnu.org>
	<20111003-104948.sv79827.51464@savannah.gnu.org>
	<20111003-115212.sv0.24145@savannah.gnu.org>
	<20111003-120634.sv79827.43722@savannah.gnu.org>
	<20111003-121043.sv0.962@savannah.gnu.org>
	<20111003-123420.sv79827.95960@savannah.gnu.org>
	<20111003-130013.sv0.371@savannah.gnu.org>
Message-ID: <20111023-151719.sv707.37620@savannah.gnu.org>

Update of sr #107822 (project gnutls):

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


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Sun Oct 23 14:17:32 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 23 Oct 2011 12:17:32 +0000
Subject: [sr #107785] gnutls_sign_func called with hash size of 20 bytes
In-Reply-To: <20110923-151828.sv707.37037@savannah.gnu.org>
References: <20110829-133316.sv79827.56778@savannah.gnu.org>
	<20110829-134109.sv79827.17998@savannah.gnu.org>
	<20110829-142440.sv0.60552@savannah.gnu.org>
	<20110829-185359.sv79827.62866@savannah.gnu.org>
	<20110829-232625.sv707.44182@savannah.gnu.org>
	<20110829-233143.sv707.76764@savannah.gnu.org>
	<20110923-121314.sv79827.86415@savannah.gnu.org>
	<20110923-151828.sv707.37037@savannah.gnu.org>
Message-ID: <20111023-151732.sv707.72982@savannah.gnu.org>

Update of sr #107785 (project gnutls):

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


    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Mon Oct 24 00:36:05 2011
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Sun, 23 Oct 2011 22:36:05 +0000
Subject: [sr #107850] gnutls 3.0.4 fails to compile on VIA C7 unless
	--disable-hardware-acceleration is provided
In-Reply-To: <20111023-151617.sv707.70116@savannah.gnu.org>
References: <20111023-114612.sv0.97001@savannah.gnu.org>
	<20111023-151617.sv707.70116@savannah.gnu.org>
Message-ID: <20111023-223605.sv0.78012@savannah.gnu.org>

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

This is now fixed in git.

    _______________________________________________________

Reply to this item at:

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

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




From simon at josefsson.org  Mon Oct 24 15:02:11 2011
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 24 Oct 2011 15:02:11 +0200
Subject: [3.0.4] gnutls_register_md5_handler defined in gnutls/extra.h but
	not present in gnutls-extra
In-Reply-To: <4E99CAE4.4070104@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sat, 15 Oct 2011 20:03:16 +0200")
References: <20111015085658.GD1999@downhill.g.la>
	<20111015114753.GF1999@downhill.g.la> <4E99CAE4.4070104@gnutls.org>
Message-ID: <87hb2yv8z0.fsf@latte.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On 10/15/2011 01:47 PM, Andreas Metzler wrote:
>> On 2011-10-15 Andreas Metzler<ametzler at downhill.at.eu.org>  wrote:
>>> 3.0.4 drops gnutls_register_md5_handler from libgnutls-extra.so, it is
>
> I removed it because the function would serve no purpose under
> nettle. I forgot about bumping the gnutls-extra version though. This
> might require a bug-fix release, but I doubt if it is of any use.
>
>>> still present in the header file and .map.
>> FWIW I have decided to stop shipping libgnutls-extra 3.0 in Debian,
>> there really is no point as long it is an empty shell. (Once it
>> provides functionality again it will be added back of course)
>
> I think gnutls-extra has served its purpose and it is no longer
> useful. I have no plans to revive it with new features, so if Simon
> also agrees it might as well be dropped from gnutls.

No problem, libgnutls-extra mostly causes build problems and nothing
else.

/Simon



From simon at josefsson.org  Mon Oct 24 15:04:03 2011
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 24 Oct 2011 15:04:03 +0200
Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and
	mipsel
In-Reply-To: <20111022115115.GA2707@downhill.g.la> (Andreas Metzler's message
	of "Sat, 22 Oct 2011 13:51:15 +0200")
References: <20111016160905.GA1921@downhill.g.la>
	<CAJU7zaKegN64-28UF+QHBpO+JjgTaRs9VCFg9npVvJdC=WPh5A@mail.gmail.com>
	<87mxcyqd30.fsf@gnu.org> <20111019170834.GA2086@downhill.g.la>
	<20111022115115.GA2707@downhill.g.la>
Message-ID: <87d3dmv8vw.fsf@latte.josefsson.org>

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

> On 2011-10-19 Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
>> On 2011-10-18 Ludovic Court?s <ludo at gnu.org> wrote:
> [...]
>> > Andreas: Could you bisect it yourself, between 3.0.0 and 3.0.1?
>
>> I probably won't have time before the weekend, but I will try then if
>> the issue is still open.
> [...]
>
> The commit which triggers the bug is this one:
> |-----------------------------
> | From 2385c7f999c12802b11859a34b89ff7662b1f4af Mon Sep 17 00:00:00 2001
> | From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
> | Date: Sat, 13 Aug 2011 14:10:55 +0200
> | Subject: [PATCH] Added crywrap to the distributed programs.
> |-----------------------------
>
> Apart from adding crywrap it adds a lot of new gnulib modules, I guess 
> one of these causes the problem.

Which gnulib modules?  Some modules don't work well with shared
libraries, and must be in a separate gnulib directory only linked to by
the applications (and not the library).

/Simon



From nmav at gnutls.org  Mon Oct 24 15:58:23 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 24 Oct 2011 15:58:23 +0200
Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and
	mipsel
In-Reply-To: <87d3dmv8vw.fsf@latte.josefsson.org>
References: <20111016160905.GA1921@downhill.g.la>	<CAJU7zaKegN64-28UF+QHBpO+JjgTaRs9VCFg9npVvJdC=WPh5A@mail.gmail.com>	<87mxcyqd30.fsf@gnu.org>
	<20111019170834.GA2086@downhill.g.la>	<20111022115115.GA2707@downhill.g.la>
	<87d3dmv8vw.fsf@latte.josefsson.org>
Message-ID: <4EA56EFF.9080208@gnutls.org>

On 10/24/2011 03:04 PM, Simon Josefsson wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
> 
>> On 2011-10-19 Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
>>> On 2011-10-18 Ludovic Court?s <ludo at gnu.org> wrote:
>> [...]
>>>> Andreas: Could you bisect it yourself, between 3.0.0 and 3.0.1?
>>
>>> I probably won't have time before the weekend, but I will try then if
>>> the issue is still open.
>> [...]
>>
>> The commit which triggers the bug is this one:
>> |-----------------------------
>> | From 2385c7f999c12802b11859a34b89ff7662b1f4af Mon Sep 17 00:00:00 2001
>> | From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
>> | Date: Sat, 13 Aug 2011 14:10:55 +0200
>> | Subject: [PATCH] Added crywrap to the distributed programs.
>> |-----------------------------
>>
>> Apart from adding crywrap it adds a lot of new gnulib modules, I guess 
>> one of these causes the problem.
> Which gnulib modules?  Some modules don't work well with shared
> libraries, and must be in a separate gnulib directory only linked to by
> the applications (and not the library).

Modules like argp,dirname,dirent etc. They are visible at:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=2385c7f999c12802b11859a34b89ff7662b1f4af

if you check the additions in gl/Makefile.am. However they aren't used
by gnutls.

regards,
Nikos



From simon at josefsson.org  Tue Oct 25 13:11:38 2011
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 25 Oct 2011 13:11:38 +0200
Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel and
	mipsel
In-Reply-To: <4EA56EFF.9080208@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Mon, 24 Oct 2011 15:58:23 +0200")
References: <20111016160905.GA1921@downhill.g.la>
	<CAJU7zaKegN64-28UF+QHBpO+JjgTaRs9VCFg9npVvJdC=WPh5A@mail.gmail.com>
	<87mxcyqd30.fsf@gnu.org> <20111019170834.GA2086@downhill.g.la>
	<20111022115115.GA2707@downhill.g.la>
	<87d3dmv8vw.fsf@latte.josefsson.org> <4EA56EFF.9080208@gnutls.org>
Message-ID: <87pqhlqqad.fsf@latte.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On 10/24/2011 03:04 PM, Simon Josefsson wrote:
>> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
>> 
>>> On 2011-10-19 Andreas Metzler <ametzler at downhill.at.eu.org> wrote:
>>>> On 2011-10-18 Ludovic Court?s <ludo at gnu.org> wrote:
>>> [...]
>>>>> Andreas: Could you bisect it yourself, between 3.0.0 and 3.0.1?
>>>
>>>> I probably won't have time before the weekend, but I will try then if
>>>> the issue is still open.
>>> [...]
>>>
>>> The commit which triggers the bug is this one:
>>> |-----------------------------
>>> | From 2385c7f999c12802b11859a34b89ff7662b1f4af Mon Sep 17 00:00:00 2001
>>> | From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
>>> | Date: Sat, 13 Aug 2011 14:10:55 +0200
>>> | Subject: [PATCH] Added crywrap to the distributed programs.
>>> |-----------------------------
>>>
>>> Apart from adding crywrap it adds a lot of new gnulib modules, I guess 
>>> one of these causes the problem.
>> Which gnulib modules?  Some modules don't work well with shared
>> libraries, and must be in a separate gnulib directory only linked to by
>> the applications (and not the library).
>
> Modules like argp,dirname,dirent etc. They are visible at:
> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=2385c7f999c12802b11859a34b89ff7662b1f4af
>
> if you check the additions in gl/Makefile.am. However they aren't used
> by gnutls.

None of the added modules looks suspicious, however maybe one of them
depends on some lower level header file that causes the issue.  However,
the problem Ludo' diagnosed does not seem related to any system header
file to me -- instead it seems much more related to guile system library
confusion (e.g., having multiple guile libraries installed).

Andreas, how did you identify that the patch above is responsible?  Were
you able to reproduce this on a x86/amd64 system?

/Simon



From dam at opencsw.org  Wed Oct 26 04:36:39 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 26 Oct 2011 04:36:39 +0200
Subject: Problem compiling gnutls 2.12.12 on Solaris 9 Sparc
Message-ID: <27693E51-3A65-4D44-8515-543812F2044C@opencsw.org>

Hi,

I have a problem compiling gnutls 2.12.12 on Solaris 9 Sparc with Sun Studio 12:

- The definition of _FILE_OFFSET_BITS probably in config.h is too late.
  I have seen and reported this earlier for Wireshark as described in this thread:
    http://www.wireshark.org/lists/wireshark-bugs/201106/msg00239.html

>   CC     dummy.lo
> "../config.h", line 1094: warning: macro redefined: _FILE_OFFSET_BITS
> "/opt/csw/include/zlib.h", line 1583: identifier redeclared: gzseek64
>         current : function(pointer to void, long, int) returning long
>         previous: function(pointer to void, long long, int) returning long long : "/opt/csw/include/zlib.h", line 1567
> "/opt/csw/include/zlib.h", line 1584: identifier redeclared: gztell64
>         current : function(pointer to void) returning long
>         previous: function(pointer to void) returning long long : "/opt/csw/include/zlib.h", line 1568
> "/opt/csw/include/zlib.h", line 1585: identifier redeclared: gzoffset64
>         current : function(pointer to void) returning long
>         previous: function(pointer to void) returning long long : "/opt/csw/include/zlib.h", line 1569
> "/opt/csw/include/zlib.h", line 1586: identifier redeclared: adler32_combine64
>         current : function(unsigned long, unsigned long, long) returning unsigned long
>         previous: function(unsigned long, unsigned long, long long) returning unsigned long : "/opt/csw/include/zlib.h", line 1570
> "/opt/csw/include/zlib.h", line 1587: identifier redeclared: crc32_combine64
>         current : function(unsigned long, unsigned long, long) returning unsigned long
>         previous: function(unsigned long, unsigned long, long long) returning unsigned long : "/opt/csw/include/zlib.h", line 1571
> cc: acomp failed for dummy.c
> gmake[4]: *** [dummy.lo] Error 1



- There are duplicate definitions from gnulib in libnettle 2.4, the issue is probably
  related to the previous one:

> Making all in nettle
> gmake[4]: Entering directory `/home/dam/mgar/pkg/gnutls/trunk/work/solaris9-sparc/build-isa-sparcv8/gnutls-2.12.12/lib/nettle'
>   CC     pk.lo
> "/opt/csw/include/nettle/nettle-stdint.h", line 237: identifier redeclared: gl_int_fast8_t
>         current : signed char
>         previous: long : "./../gl/stdint.h", line 241
> "/opt/csw/include/nettle/nettle-stdint.h", line 238: warning: modification of typedef with "int" ignored
> "/opt/csw/include/nettle/nettle-stdint.h", line 238: identifier redeclared: gl_int_fast16_t
>         current : int
>         previous: long : "./../gl/stdint.h", line 243
> "/opt/csw/include/nettle/nettle-stdint.h", line 239: warning: modification of typedef with "int" ignored
> "/opt/csw/include/nettle/nettle-stdint.h", line 239: identifier redeclared: gl_int_fast32_t
>         current : int
>         previous: long : "./../gl/stdint.h", line 245
> "/opt/csw/include/nettle/nettle-stdint.h", line 241: warning: typedef redeclared: int64_t
> "/opt/csw/include/nettle/nettle-stdint.h", line 244: identifier redeclared: gl_uint_fast8_t
>         current : unsigned char
>         previous: unsigned long : "./../gl/stdint.h", line 242
> "/opt/csw/include/nettle/nettle-stdint.h", line 245: identifier redeclared: gl_uint_fast16_t
>         current : unsigned int
>         previous: unsigned long : "./../gl/stdint.h", line 244
> "/opt/csw/include/nettle/nettle-stdint.h", line 246: identifier redeclared: gl_uint_fast32_t
>         current : unsigned int
>         previous: unsigned long : "./../gl/stdint.h", line 246
> "/opt/csw/include/nettle/nettle-stdint.h", line 248: warning: typedef redeclared: uint64_t
> cc: acomp failed for pk.c
> gmake[4]: *** [pk.lo] Error 1
> gmake[4]: Leaving directory `/home/dam/mgar/pkg/gnutls/trunk/work/solaris9-sparc/build-isa-sparcv8/gnutls-2.12.12/lib/nettle'


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896




From ametzler at downhill.at.eu.org  Wed Oct 26 10:37:04 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Wed, 26 Oct 2011 08:37:04 +0000 (UTC)
Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel
	=?utf-8?b?YW5kCW1pcHNlbA==?=
References: <20111016160905.GA1921@downhill.g.la>
	<CAJU7zaKegN64-28UF+QHBpO+JjgTaRs9VCFg9npVvJdC=WPh5A@mail.gmail.com>
	<87mxcyqd30.fsf@gnu.org> <20111019170834.GA2086@downhill.g.la>
	<20111022115115.GA2707@downhill.g.la>
	<87d3dmv8vw.fsf@latte.josefsson.org> <4EA56EFF.9080208@gnutls.org>
	<87pqhlqqad.fsf@latte.josefsson.org>
Message-ID: <loom.20111026T103351-568@post.gmane.org>

Simon Josefsson <simon <at> josefsson.org> writes:
> Nikos Mavrogiannopoulos <nmav <at> gnutls.org> writes:
> > On 10/24/2011 03:04 PM, Simon Josefsson wrote:
> >> Andreas Metzler <ametzler <at> downhill.at.eu.org> writes:
> >>> On 2011-10-19 Andreas Metzler <ametzler <at> downhill.at.eu.org> wrote:
> >>>> On 2011-10-18 Ludovic Court?s <ludo <at> gnu.org> wrote:
> >>> [...]
> >>>>> Andreas: Could you bisect it yourself, between 3.0.0 and 3.0.1?
> >>>
> >>>> I probably won't have time before the weekend, but I will try then if
> >>>> the issue is still open.
> >>> [...]
[...]
> Andreas, how did you identify that the patch above is responsible?

standard bisect. starting with this commit I got the segfault.

> Were you able to reproduce this on a x86/amd64 system?

Nope, this was on armel (abel.debian.org)

cu andreas







From nmav at gnutls.org  Wed Oct 26 17:53:29 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 26 Oct 2011 17:53:29 +0200
Subject: Problem compiling gnutls 2.12.12 on Solaris 9 Sparc
In-Reply-To: <27693E51-3A65-4D44-8515-543812F2044C@opencsw.org>
References: <27693E51-3A65-4D44-8515-543812F2044C@opencsw.org>
Message-ID: <4EA82CF9.1080102@gnutls.org>

On 10/26/2011 04:36 AM, Dagobert Michelsen wrote:
> Hi,
> 
> I have a problem compiling gnutls 2.12.12 on Solaris 9 Sparc with Sun Studio 12:
> 
> - The definition of _FILE_OFFSET_BITS probably in config.h is too late.
>   I have seen and reported this earlier for Wireshark as described in this thread:
>     http://www.wireshark.org/lists/wireshark-bugs/201106/msg00239.html
[...]

>>         current : function(unsigned long, unsigned long, long) returning unsigned long
>>         previous: function(unsigned long, unsigned long, long long) returning unsigned long : "/opt/csw/include/zlib.h", line 1571
>> cc: acomp failed for dummy.c
>> gmake[4]: *** [dummy.lo] Error 1

This looks like a zlib error in your platform. Try running configure
with the "--without-zlib"  option.

> - There are duplicate definitions from gnulib in libnettle 2.4, the issue is probably
>   related to the previous one:
>> Making all in nettle
>> gmake[4]: Entering directory `/home/dam/mgar/pkg/gnutls/trunk/work/solaris9-sparc/build-isa-sparcv8/gnutls-2.12.12/lib/nettle'
>>   CC     pk.lo
>> "/opt/csw/include/nettle/nettle-stdint.h", line 237: identifier redeclared: gl_int_fast8_t
>>         current : signed char
>>         previous: long : "./../gl/stdint.h", line 241
>> "/opt/csw/include/nettle/nettle-stdint.h", line 238: warning: modification of typedef with "int" ignored
>> "/opt/csw/include/nettle/nettle-stdint.h", line 238: identifier redeclared: gl_int_fast16_t

This might be a nettle bug. Could you reply to Niels (nettle's author),
on his questions on the mail at:
http://permalink.gmane.org/gmane.comp.encryption.nettle.bugs/154

regards,
Nikos



From dam at opencsw.org  Wed Oct 26 22:25:46 2011
From: dam at opencsw.org (Dagobert Michelsen)
Date: Wed, 26 Oct 2011 22:25:46 +0200
Subject: Problem compiling gnutls 2.12.12 on Solaris 9 Sparc
In-Reply-To: <4EA82CF9.1080102@gnutls.org>
References: <27693E51-3A65-4D44-8515-543812F2044C@opencsw.org>
	<4EA82CF9.1080102@gnutls.org>
Message-ID: <F0BE1B41-52FD-46D6-A909-08098E05E7D5@opencsw.org>

Hi Nikos,

Am 26.10.2011 um 17:53 schrieb Nikos Mavrogiannopoulos:
> On 10/26/2011 04:36 AM, Dagobert Michelsen wrote:
>> I have a problem compiling gnutls 2.12.12 on Solaris 9 Sparc with Sun Studio 12:
>> 
>> - The definition of _FILE_OFFSET_BITS probably in config.h is too late.
>>  I have seen and reported this earlier for Wireshark as described in this thread:
>>    http://www.wireshark.org/lists/wireshark-bugs/201106/msg00239.html
> [...]
> 
>>>        current : function(unsigned long, unsigned long, long) returning unsigned long
>>>        previous: function(unsigned long, unsigned long, long long) returning unsigned long : "/opt/csw/include/zlib.h", line 1571
>>> cc: acomp failed for dummy.c
>>> gmake[4]: *** [dummy.lo] Error 1
> 
> This looks like a zlib error in your platform. Try running configure
> with the "--without-zlib"  option.

Using --without-zlib the error vanishes, however, I still believe that at some point
zlib.h is included twice: once before the definition of _FILE_OFFSET_BITS and once
afterwards.

>> - There are duplicate definitions from gnulib in libnettle 2.4, the issue is probably
>>  related to the previous one:
>>> Making all in nettle
>>> gmake[4]: Entering directory `/home/dam/mgar/pkg/gnutls/trunk/work/solaris9-sparc/build-isa-sparcv8/gnutls-2.12.12/lib/nettle'
>>>  CC     pk.lo
>>> "/opt/csw/include/nettle/nettle-stdint.h", line 237: identifier redeclared: gl_int_fast8_t
>>>        current : signed char
>>>        previous: long : "./../gl/stdint.h", line 241
>>> "/opt/csw/include/nettle/nettle-stdint.h", line 238: warning: modification of typedef with "int" ignored
>>> "/opt/csw/include/nettle/nettle-stdint.h", line 238: identifier redeclared: gl_int_fast16_t
> 
> This might be a nettle bug. Could you reply to Niels (nettle's author),
> on his questions on the mail at:
> http://permalink.gmane.org/gmane.comp.encryption.nettle.bugs/154

I couldn't post using the web interface so I mailed him privately offering access
to the OpenCSW buildfarm:
  http://www.opencsw.org/extend-it/signup/to-upstream-maintainers/

Simon already has an account there, if you want one too I can easily set this up.


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896




From ml at smtp.fakessh.eu  Thu Oct 27 14:41:27 2011
From: ml at smtp.fakessh.eu (fakessh @)
Date: Thu, 27 Oct 2011 14:41:27 +0200
Subject: gnutls and mod_gnutls is it vulnerable to the flaw last to openssl is
	called renegotiation
Message-ID: <201110271441.37071.ml@smtp.fakessh.eu>

hi guru
hi list

gnutls is it vulnerable to the flaw last to openssl is called renegotiation

all testimonials are welcome
-- 
?http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7
?gpg --keyserver pgp.mit.edu --recv-key 092164A7

?http://urlshort.eu fakessh @
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </pipermail/attachments/20111027/3f4ca8a5/attachment.pgp>

From nmav at gnutls.org  Thu Oct 27 20:48:17 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 27 Oct 2011 20:48:17 +0200
Subject: gnutls 3.0.5
Message-ID: <4EA9A771.7060203@gnutls.org>

Hello,
 I've just released gnutls 3.0.5. It is a bug-fix release on the current
stable branch.

The changelog since 3.0.4 follows.

* Version 3.0.5 (released 2011-10-27)

** libgnutls-extra: is no more

** libgnutls: Corrections in order to compile with mingw32.

** libgnutls: Corrections in VIA padlock code for VIA C5 processor
and new detection of PHE with support for partial hashing.

** libgnutls: Corrected bug in gnutls_x509_data2hex. Report and fix
by Vincent Untz.

** minitasn1: Upgraded to libtasn1 version 2.10.

** API and ABI modifications:
No changes since last version.


Getting the Software
====================

GnuTLS may be downloaded from one of the GNU mirror sites or directly
>From <ftp://ftp.gnu.org/gnu/gnutls/?.  The list of GNU mirrors can be
found at <http://www.gnu.org/prep/ftp.html> and a list of GnuTLS mirrors
can be found at <http://www.gnu.org/software/gnutls/download.html>.

Here are the XZ compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.5.tar.xz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.5.tar.xz
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.5.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.5.tar.xz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.5.tar.xz.sig
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.5.tar.xz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
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]

regards,
Nikos



From simon at josefsson.org  Fri Oct 28 11:06:23 2011
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 28 Oct 2011 11:06:23 +0200
Subject: Compile fix for gnutls-3.0.5
In-Reply-To: <4EA9BA9A.5070107@rcn.com> (Kris Karas's message of "Thu, 27 Oct
	2011 16:10:02 -0400")
References: <4EA9BA9A.5070107@rcn.com>
Message-ID: <87y5w5eb8w.fsf@latte.josefsson.org>

Kris Karas <ktk2008 at rcn.com> writes:

> Greetings,
>
> I just went to compile the new GnuTLS 3.0.5, which fails with:
>
> 	make[4]: Entering directory `/var/tmp/slackbuild/gnutls/gnutls-3.0.5/guile/src'
> 	  CC     libguile_gnutls_v_1_la-core.lo
> 	In file included from core.c:40:0:
> 	enum-map.i.c: In function 'scm_gnutls_define_enums':
> 	enum-map.i.c:1484:3: error: 'GNUTLS_E_INIT_LIBEXTRA' undeclared (first use in this function)
>
>
> A patch to fix the bug is attached for your convenience...

Thanks for the report.  The fix is the wrong one, libgnutls-extra has
been removed but the guile part is still there -- Nikos, have you tried
building the latest branch with guile?

/Simon

> Best regards,
> Kris
> --- lib/includes/gnutls/gnutls.h.in.orig	2011-10-27 16:04:25.321139578 -0400
> +++ lib/includes/gnutls/gnutls.h.in	2011-10-27 16:05:12.433855297 -0400
> @@ -1680,6 +1680,8 @@
>  #define GNUTLS_E_TOO_MANY_EMPTY_PACKETS -78
>  #define GNUTLS_E_UNKNOWN_PK_ALGORITHM -80
>  #define GNUTLS_E_TOO_MANY_HANDSHAKE_PACKETS -81
> +#define GNUTLS_E_INIT_LIBEXTRA -82
> +#define GNUTLS_E_LIBRARY_VERSION_MISMATCH -83
>  
>    /* returned if you need to generate temporary RSA
>     * parameters. These are needed for export cipher suites.



From simon at josefsson.org  Fri Oct 28 11:08:00 2011
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 28 Oct 2011 11:08:00 +0200
Subject: Compile fix for gnutls-3.0.5
In-Reply-To: <87y5w5eb8w.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Fri, 28 Oct 2011 11:06:23 +0200")
References: <4EA9BA9A.5070107@rcn.com> <87y5w5eb8w.fsf@latte.josefsson.org>
Message-ID: <87ty6teb67.fsf@latte.josefsson.org>

Trying to build trunk, I also noticed that libgnutls-extra is still
referenced by the GTK-DOC manual...

gtk-doc: Building HTML
warning: failed to load external entity "../xml/extra.xml"
../gnutls-docs.sgml:25: element include: XInclude error : could not load ../xml/extra.xml, and no fallback was found
warning: failed to load external entity "../xml/openssl.xml"
../gnutls-docs.sgml:32: element include: XInclude error : could not load ../xml/openssl.xml, and no fallback was found
Computing chunks...

/Simon



From simon at josefsson.org  Fri Oct 28 11:12:14 2011
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 28 Oct 2011 11:12:14 +0200
Subject: guile testsuite failure (gnutls 3.0.1 and later) and armel
	and	mipsel
In-Reply-To: <loom.20111026T103351-568@post.gmane.org> (Andreas Metzler's
	message of "Wed, 26 Oct 2011 08:37:04 +0000 (UTC)")
References: <20111016160905.GA1921@downhill.g.la>
	<CAJU7zaKegN64-28UF+QHBpO+JjgTaRs9VCFg9npVvJdC=WPh5A@mail.gmail.com>
	<87mxcyqd30.fsf@gnu.org> <20111019170834.GA2086@downhill.g.la>
	<20111022115115.GA2707@downhill.g.la>
	<87d3dmv8vw.fsf@latte.josefsson.org> <4EA56EFF.9080208@gnutls.org>
	<87pqhlqqad.fsf@latte.josefsson.org>
	<loom.20111026T103351-568@post.gmane.org>
Message-ID: <87pqhheaz5.fsf@latte.josefsson.org>

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

> Simon Josefsson <simon <at> josefsson.org> writes:
>> Nikos Mavrogiannopoulos <nmav <at> gnutls.org> writes:
>> > On 10/24/2011 03:04 PM, Simon Josefsson wrote:
>> >> Andreas Metzler <ametzler <at> downhill.at.eu.org> writes:
>> >>> On 2011-10-19 Andreas Metzler <ametzler <at> downhill.at.eu.org> wrote:
>> >>>> On 2011-10-18 Ludovic Court?s <ludo <at> gnu.org> wrote:
>> >>> [...]
>> >>>>> Andreas: Could you bisect it yourself, between 3.0.0 and 3.0.1?
>> >>>
>> >>>> I probably won't have time before the weekend, but I will try then if
>> >>>> the issue is still open.
>> >>> [...]
> [...]
>> Andreas, how did you identify that the patch above is responsible?
>
> standard bisect. starting with this commit I got the segfault.
>
>> Were you able to reproduce this on a x86/amd64 system?
>
> Nope, this was on armel (abel.debian.org)

Darn, I don't have access to it, and the gcc compile farm doesn't seem
to have any online arm systems either...

/Simon



From nmav at gnutls.org  Fri Oct 28 11:27:51 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 28 Oct 2011 11:27:51 +0200
Subject: Compile fix for gnutls-3.0.5
In-Reply-To: <87y5w5eb8w.fsf@latte.josefsson.org>
References: <4EA9BA9A.5070107@rcn.com>
	<87y5w5eb8w.fsf@latte.josefsson.org>
Message-ID: <CAJU7zaJM9PF=nhyCBJq-uvKEyhT879Cw8K89TrmT0H_nPeVQgA@mail.gmail.com>

On Fri, Oct 28, 2011 at 11:06 AM, Simon Josefsson <simon at josefsson.org> wrote:

>> I just went to compile the new GnuTLS 3.0.5, which fails with:
>>
>> ? ? ? make[4]: Entering directory `/var/tmp/slackbuild/gnutls/gnutls-3.0.5/guile/src'
>> ? ? ? ? CC ? ? libguile_gnutls_v_1_la-core.lo
>> ? ? ? In file included from core.c:40:0:
>> ? ? ? enum-map.i.c: In function 'scm_gnutls_define_enums':
>> ? ? ? enum-map.i.c:1484:3: error: 'GNUTLS_E_INIT_LIBEXTRA' undeclared (first use in this function)
>> A patch to fix the bug is attached for your convenience...
> Thanks for the report. ?The fix is the wrong one, libgnutls-extra has
> been removed but the guile part is still there -- Nikos, have you tried
> building the latest branch with guile?

No, I don't use guile.



From simon at josefsson.org  Fri Oct 28 12:16:20 2011
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 28 Oct 2011 12:16:20 +0200
Subject: OCSP support
Message-ID: <87hb2tbevf.fsf@latte.josefsson.org>

All,

I'm implementing Online Certificate Status Protocol (OCSP) support in
GnuTLS, sponsored by Smoothwall.  I've pushed an initial branch that has
client-side functionality.  The branch is called 'ocsp' and you may
browse it here:

http://git.savannah.gnu.org/cgit/gnutls.git/log/?h=ocsp

The majority of the work available so far is in this commit:

http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=ocsp&id=5f1c585d7f25c9cdec4f64c9b56a65516fd8d0e5

There is no documentation yet, but there is a command line tool
'ocsptool' that can be used to view requests/responses and generate
requests and verify responses.

My plan is to improve the code further, add more documentation and
self-tests and then merge this onto the GnuTLS master branch.  Feedback
on the API and code in general at this point is appreciated.  See it as
a good opportunity to help influence the API design now, since you will
have a much harder time changing the API later on. :-)

If you are a potential user of a GnuTLS OCSP interface, please take some
time to review the API documented here:

http://josefsson.org/gnutls-ocsp/gtk-doc-api-manual/gnutls-ocsp.html

I'm including the header file below for easy quoting.

/Simon

#ifndef GNUTLS_OCSP_H
#define GNUTLS_OCSP_H

#include <gnutls/gnutls.h>
#include <gnutls/x509.h>

#ifdef __cplusplus
extern "C"
{
#endif

#define GNUTLS_OCSP_NONCE "1.3.6.1.5.5.7.48.1.2"

  /**
   * gnutls_ocsp_print_formats_t:
   * @GNUTLS_OCSP_PRINT_FULL: Full information about OCSP request/response.
   *
   * Enumeration of different OCSP printing variants.
   */
  typedef enum gnutls_ocsp_print_formats_t
    {
      GNUTLS_OCSP_PRINT_FULL = 0,
    } gnutls_ocsp_print_formats_t;

  /**
   * gnutls_ocsp_resp_status_t:
   * @GNUTLS_OCSP_RESP_SUCCESSFUL: Response has valid confirmations.
   * @GNUTLS_OCSP_RESP_MALFORMEDREQUEST: Illegal confirmation request
   * @GNUTLS_OCSP_RESP_INTERNALERROR: Internal error in issuer
   * @GNUTLS_OCSP_RESP_TRYLATER: Try again later
   * @GNUTLS_OCSP_RESP_SIGREQUIRED: Must sign the request
   * @GNUTLS_OCSP_RESP_UNAUTHORIZED: Request unauthorized
   *
   * Enumeration of different OCSP response status codes.
   */
  typedef enum gnutls_ocsp_resp_status_t
    {
      GNUTLS_OCSP_RESP_SUCCESSFUL = 0,
      GNUTLS_OCSP_RESP_MALFORMEDREQUEST = 1,
      GNUTLS_OCSP_RESP_INTERNALERROR = 2,
      GNUTLS_OCSP_RESP_TRYLATER = 3,
      GNUTLS_OCSP_RESP_SIGREQUIRED = 5,
      GNUTLS_OCSP_RESP_UNAUTHORIZED = 6
    } gnutls_ocsp_resp_status_t;

  /**
   * gnutls_ocsp_cert_status_t:
   * @GNUTLS_OCSP_CERT_GOOD: Positive response to status inquiry.
   * @GNUTLS_OCSP_CERT_REVOKED: Certificate has been revoked.
   * @GNUTLS_OCSP_CERT_UNKNOWN: The responder doesn't know about the
   *   certificate.
   *
   * Enumeration of different OCSP response status codes.
   */
  typedef enum gnutls_ocsp_cert_status_t
    {
      GNUTLS_OCSP_CERT_GOOD = 0,
      GNUTLS_OCSP_CERT_REVOKED = 1,
      GNUTLS_OCSP_CERT_UNKNOWN = 2
    } gnutls_ocsp_cert_status_t;

  /**
   * gnutls_x509_crl_reason_t:
   * @GNUTLS_X509_CRLREASON_UNSPECIFIED: Unspecified reason.
   * @GNUTLS_X509_CRLREASON_KEYCOMPROMISE: Private key compromised.
   * @GNUTLS_X509_CRLREASON_CACOMPROMISE: CA compromised.
   * @GNUTLS_X509_CRLREASON_AFFILIATIONCHANGED: Affiliation has changed.
   * @GNUTLS_X509_CRLREASON_SUPERSEDED: Certificate superseded.
   * @GNUTLS_X509_CRLREASON_CESSATIONOFOPERATION: Operation has ceased.
   * @GNUTLS_X509_CRLREASON_CERTIFICATEHOLD: Certificate is on hold.
   * @GNUTLS_X509_CRLREASON_REMOVEFROMCRL: Will be removed from delta CRL.
   * @GNUTLS_X509_CRLREASON_PRIVILEGEWITHDRAWN: Privilege withdrawn.
   * @GNUTLS_X509_CRLREASON_AACOMPROMISE: AA compromised.
   *
   * Enumeration of different reason codes.  Note that this
   * corresponds to the CRLReason ASN.1 enumeration type, and not the
   * ReasonFlags ASN.1 bit string.
   */
  typedef enum gnutls_x509_crl_reason_t
    {
      GNUTLS_X509_CRLREASON_UNSPECIFIED = 0,
      GNUTLS_X509_CRLREASON_KEYCOMPROMISE = 1,
      GNUTLS_X509_CRLREASON_CACOMPROMISE = 2,
      GNUTLS_X509_CRLREASON_AFFILIATIONCHANGED = 3,
      GNUTLS_X509_CRLREASON_SUPERSEDED = 4,
      GNUTLS_X509_CRLREASON_CESSATIONOFOPERATION = 5,
      GNUTLS_X509_CRLREASON_CERTIFICATEHOLD = 6,
      /* -- value 7 is not used */
      GNUTLS_X509_CRLREASON_REMOVEFROMCRL = 8,
      GNUTLS_X509_CRLREASON_PRIVILEGEWITHDRAWN = 9,
      GNUTLS_X509_CRLREASON_AACOMPROMISE = 10
    } gnutls_x509_crl_reason_t;

   /* Enumeration of OCSP verify status codes. */
#define GNUTLS_OCSP_VERIFY_SIGNER_NOT_FOUND 1
#define GNUTLS_OCSP_VERIFY_SIGNER_KEYUSAGE_ERROR 2
#define GNUTLS_OCSP_VERIFY_UNTRUSTED_SIGNER 4
#define GNUTLS_OCSP_VERIFY_INSECURE_ALGORITHM 8
#define GNUTLS_OCSP_VERIFY_SIGNATURE_FAILURE 16
#define GNUTLS_OCSP_VERIFY_CERT_NOT_ACTIVATED 32
#define GNUTLS_OCSP_VERIFY_CERT_EXPIRED 64

  struct gnutls_ocsp_req_int;
  typedef struct gnutls_ocsp_req_int *gnutls_ocsp_req_t;

  int gnutls_ocsp_req_init (gnutls_ocsp_req_t * req);
  void gnutls_ocsp_req_deinit (gnutls_ocsp_req_t req);

  int gnutls_ocsp_req_import (gnutls_ocsp_req_t req,
			      const gnutls_datum_t * data);
  int gnutls_ocsp_req_export (gnutls_ocsp_req_t req, gnutls_datum_t * data);
  int gnutls_ocsp_req_print (gnutls_ocsp_req_t req,
			     gnutls_ocsp_print_formats_t format,
			     gnutls_datum_t * out);

  int gnutls_ocsp_req_get_version (gnutls_ocsp_req_t req);
  int gnutls_ocsp_req_get_certid (gnutls_ocsp_req_t req,
				  unsigned indx,
				  gnutls_digest_algorithm_t *digest,
				  gnutls_datum_t *issuer_name_hash,
				  gnutls_datum_t *issuer_key_hash,
				  gnutls_datum_t *serial_number);
  int gnutls_ocsp_req_add_certid (gnutls_ocsp_req_t req,
				  gnutls_digest_algorithm_t digest,
				  const gnutls_datum_t *issuer_name_hash,
				  const gnutls_datum_t *issuer_key_hash,
				  const gnutls_datum_t *serial_number);
  int gnutls_ocsp_req_add_cert (gnutls_ocsp_req_t req,
				gnutls_digest_algorithm_t digest,
				gnutls_x509_crt_t issuer,
				gnutls_x509_crt_t cert);

  int gnutls_ocsp_req_get_extension (gnutls_ocsp_req_t req,
				     unsigned indx,
				     gnutls_datum_t *oid,
				     unsigned int *critical,
				     gnutls_datum_t *data);
  int gnutls_ocsp_req_get_nonce (gnutls_ocsp_req_t req,
				 unsigned int *critical,
				 gnutls_datum_t *nonce);

  int gnutls_ocsp_req_set_extension (gnutls_ocsp_req_t req,
				     const char *oid,
				     unsigned int critical,
				     const gnutls_datum_t *data);
  int gnutls_ocsp_req_set_nonce (gnutls_ocsp_req_t req,
				 unsigned int critical,
				 const gnutls_datum_t *nonce);

  struct gnutls_ocsp_resp_int;
  typedef struct gnutls_ocsp_resp_int *gnutls_ocsp_resp_t;

  int gnutls_ocsp_resp_init (gnutls_ocsp_resp_t * resp);
  void gnutls_ocsp_resp_deinit (gnutls_ocsp_resp_t resp);

  int gnutls_ocsp_resp_import (gnutls_ocsp_resp_t resp,
			       const gnutls_datum_t * data);
  int gnutls_ocsp_resp_export (gnutls_ocsp_resp_t resp,
			       gnutls_datum_t * data);
  int gnutls_ocsp_resp_print (gnutls_ocsp_resp_t resp,
			      gnutls_ocsp_print_formats_t format,
			      gnutls_datum_t * out);

  int gnutls_ocsp_resp_get_status (gnutls_ocsp_resp_t resp);
  int gnutls_ocsp_resp_get_response (gnutls_ocsp_resp_t resp,
				     gnutls_datum_t *response_type_oid,
				     gnutls_datum_t *response);

  int gnutls_ocsp_resp_get_version (gnutls_ocsp_resp_t resp);
  int gnutls_ocsp_resp_get_responderid_dn (gnutls_ocsp_resp_t resp,
					   gnutls_datum_t *dn);
  time_t gnutls_ocsp_resp_get_produceat (gnutls_ocsp_resp_t resp);
  int gnutls_ocsp_resp_get_singleresponse (gnutls_ocsp_resp_t resp,
					   unsigned indx,
					   gnutls_digest_algorithm_t *digest,
					   gnutls_datum_t *issuer_name_hash,
					   gnutls_datum_t *issuer_key_hash,
					   gnutls_datum_t *serial_number,
					   int *cert_status,
					   time_t *this_update,
					   time_t *next_update,
					   time_t *revocation_time,
					   int *revocation_reason);
  int gnutls_ocsp_resp_get_extension (gnutls_ocsp_resp_t resp,
				      unsigned indx,
				      gnutls_datum_t *oid,
				      unsigned int *critical,
				      gnutls_datum_t *data);
  int gnutls_ocsp_resp_get_nonce (gnutls_ocsp_resp_t resp,
				  unsigned int *critical,
				  gnutls_datum_t *nonce);
  int gnutls_ocsp_resp_get_signature_algorithm (gnutls_ocsp_resp_t resp);
  int gnutls_ocsp_resp_get_signature (gnutls_ocsp_resp_t resp,
				      gnutls_datum_t *sig);
  int gnutls_ocsp_resp_get_certs (gnutls_ocsp_resp_t resp,
				  gnutls_x509_crt_t ** certs,
				  size_t *ncerts);

  int gnutls_ocsp_resp_verify (gnutls_ocsp_resp_t resp,
			       gnutls_x509_trust_list_t trustlist,
			       gnutls_x509_crt_t signercert,
			       unsigned *verify,
			       int flags);

#ifdef __cplusplus
}
#endif

#endif /* GNUTLS_OCSP_H */



From nmav at gnutls.org  Fri Oct 28 14:08:26 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 28 Oct 2011 14:08:26 +0200
Subject: Compile fix for gnutls-3.0.5
In-Reply-To: <87ty6teb67.fsf@latte.josefsson.org>
References: <4EA9BA9A.5070107@rcn.com> <87y5w5eb8w.fsf@latte.josefsson.org>
	<87ty6teb67.fsf@latte.josefsson.org>
Message-ID: <CAJU7zaLEis0siW6ipu7QpLQxPO+Z3vwWGTv1pFKzV4sryJUVuw@mail.gmail.com>

Please check into it. I have no idea on the gtk-doc manual generation.

regards,
Nikos

On Fri, Oct 28, 2011 at 11:08 AM, Simon Josefsson <simon at josefsson.org> wrote:
> Trying to build trunk, I also noticed that libgnutls-extra is still
> referenced by the GTK-DOC manual...
>
> gtk-doc: Building HTML
> warning: failed to load external entity "../xml/extra.xml"
> ../gnutls-docs.sgml:25: element include: XInclude error : could not load ../xml/extra.xml, and no fallback was found
> warning: failed to load external entity "../xml/openssl.xml"
> ../gnutls-docs.sgml:32: element include: XInclude error : could not load ../xml/openssl.xml, and no fallback was found
> Computing chunks...
>
> /Simon
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> https://lists.gnu.org/mailman/listinfo/gnutls-devel
>



From nmav at gnutls.org  Fri Oct 28 18:18:09 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 28 Oct 2011 18:18:09 +0200
Subject: gnutls and mod_gnutls is it vulnerable to the flaw last to openssl
	is called renegotiation
In-Reply-To: <201110271441.37071.ml@smtp.fakessh.eu>
References: <201110271441.37071.ml@smtp.fakessh.eu>
Message-ID: <4EAAD5C1.8090202@gnutls.org>

On 10/27/2011 02:41 PM, fakessh @ wrote:

> gnutls is it vulnerable to the flaw last to openssl is called renegotiation

If you are asking on the safe renegotiation vulnerability it has been
countered since 2.10.x. You can check the security advisories for more
information at:
http://www.gnu.org/software/gnutls/security.html

regards,
Nikos



From jesse at eloquentpeasant.net  Thu Oct 27 19:37:17 2011
From: jesse at eloquentpeasant.net (Jesse Ruffin)
Date: Thu, 27 Oct 2011 13:37:17 -0400
Subject: [modgnutls-support] gnutls and mod_gnutls is it vulnerable to
	the flaw last to openssl is called renegotiation
In-Reply-To: <201110271441.37071.ml@smtp.fakessh.eu>
References: <201110271441.37071.ml@smtp.fakessh.eu>
Message-ID: <4EA996CD.3040801@eloquentpeasant.net>

You want to read this thread.

http://lists.gnu.org/archive/html/gnutls-devel/2011-09/msg00064.html

It's a protocol problem, but there are workarounds.

On 10/27/2011 08:41, fakessh @ wrote:
> hi guru
> hi list
> 
> gnutls is it vulnerable to the flaw last to openssl is called renegotiation
> 
> all testimonials are welcome
> 
> 
> 
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning at Cisco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-dev2dev
> 
> 
> 
> _______________________________________________
> modgnutls-support mailing list
> modgnutls-support at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/modgnutls-support



From joe at t67.eu  Thu Oct 27 15:22:35 2011
From: joe at t67.eu (Joseph Graham)
Date: Thu, 27 Oct 2011 14:22:35 +0100
Subject: chainverify test failed
Message-ID: <20111027132235.GA6162@t67.eu>

Am trying to update gnutls for the Parabola MIPS port. One test failed.

chain[ecc cert ok]: verify_status: 2 expected: 0
FAIL: chainverify

Version is 3.0.4



From nmav at gnutls.org  Fri Oct 28 18:28:05 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 28 Oct 2011 18:28:05 +0200
Subject: chainverify test failed
In-Reply-To: <20111027132235.GA6162@t67.eu>
References: <20111027132235.GA6162@t67.eu>
Message-ID: <4EAAD815.7030808@gnutls.org>

On 10/27/2011 03:22 PM, Joseph Graham wrote:
> Am trying to update gnutls for the Parabola MIPS port. One test failed.
> 
> chain[ecc cert ok]: verify_status: 2 expected: 0
> FAIL: chainverify
> Version is 3.0.4

 Hi,
Does the same error occur in 3.0.5? If yes could you send me the output
of chainverify -v?

regards,
Nikos



From nmav at gnutls.org  Sat Oct 29 01:42:30 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 29 Oct 2011 01:42:30 +0200
Subject: gnutls 3.0.5
In-Reply-To: <87r51wx4ci.fsf@lifelogs.com>
References: <4EA9A771.7060203@gnutls.org>
	<87r51wx4ci.fsf@lifelogs.com>
Message-ID: <CAJU7za+iEdJfcUkArpt+ChPnSzK5oKq45jOpE1DWePjtPi=8Ow@mail.gmail.com>

2011/10/28 Ted Zlatanov <tzz at lifelogs.com>:

> NM> ?I've just released gnutls 3.0.5. It is a bug-fix release on the current
> NM> stable branch.
> Thanks, Nikos. ?Simon Josefsson's Windows DLL builds haven't been
> updated since 2.10.x (July 2010). ?Can the GnuTLS project provide these
> builds for 3.x or will Simon remain their provider?

I cannot provide win32 builds. If however there is someone who can
provide win32 builds for the releases, he's welcome to join us.

regards,
Nikos



From ktk2008 at rcn.com  Fri Oct 28 19:13:10 2011
From: ktk2008 at rcn.com (Kris Karas)
Date: Fri, 28 Oct 2011 13:13:10 -0400
Subject: Compile fix for gnutls-3.0.5
In-Reply-To: <87y5w5eb8w.fsf@latte.josefsson.org>
References: <4EA9BA9A.5070107@rcn.com> <87y5w5eb8w.fsf@latte.josefsson.org>
Message-ID: <4EAAE2A6.1030104@rcn.com>

Simon Josefsson wrote:
> Kris Karas<ktk2008 at rcn.com>  writes:
>
>> enum-map.i.c:1484:3: error: 'GNUTLS_E_INIT_LIBEXTRA' undeclared (first use in this function)
> Thanks for the report.  The fix is the wrong one

Sorry for the wrong (dumb) patch.  I neglected to consider that code was 
being removed instead of added.  :-)

The platform triggering this error is basically slackware-13.37 (which 
has guile 1.8.8) except that yours truly has a mechanism that 
automatically downloads/package-builds/installs anything network-facing 
or in support thereof (gnutls, openssl, nettle, p11-kit, apache, 
dovecot, etc etc...) hence its automatic try at gnutls-3.0.5.  The guile 
inclusion appears auto-detected by "configure" as there are no 
--with/--enable keywords for it on the command line.  (I don't knowingly 
use the guile portion of gnutls myself, either.)

Kris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20111028/0a8a77e8/attachment.htm>

From n.mavrogiannopoulos at gmail.com  Sat Oct 29 14:23:37 2011
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sat, 29 Oct 2011 14:23:37 +0200
Subject: Problems with automatic pkcs11 reinit on fork
In-Reply-To: <4E931A99.10907@collabora.co.uk>
References: <4E8FEB85.90503@collabora.co.uk> <4E902475.90506@gmail.com>
	<4E906EA8.5040601@collabora.co.uk> <4E920E85.6020204@gmail.com>
	<4E931A99.10907@collabora.co.uk>
Message-ID: <4EABF049.1000203@gmail.com>

On 10/10/2011 06:17 PM, Stef Walter wrote:

>> Then I'd have exactly the same problem that you have. Performance issues
>> :) It might be better for this issue to be solved once and for all users
>> of p11-kit.
> 
> It's pretty hard to do this correctly at the p11-kit layer. We cannot
> transparently hide the fact that all of a sudden all slots, token info,
> sessions, objects, and other handles have been invalidated. Therefore
> any structures that gnutls is holding must also be cleared on fork.
> 
> Forgive me if I'm missing something, but the only way I see to solve
> this part of the problem is for p11-kit to notify gnutls that any and
> all PKCS#11 state is invalid. gnutls would then start from a clean
> pkcs#11 state. I'll work on some patches for gnutls.

Hi any update on that (on the p11-kit part). Would p11-kit provide a
callback when reinitialization occurs, or should gnutls use pthread_atfork?

regards,
Nikos



From stefw at collabora.co.uk  Sun Oct 30 18:38:53 2011
From: stefw at collabora.co.uk (Stef Walter)
Date: Sun, 30 Oct 2011 18:38:53 +0100
Subject: Problems with automatic pkcs11 reinit on fork
In-Reply-To: <4EABF049.1000203@gmail.com>
References: <4E8FEB85.90503@collabora.co.uk> <4E902475.90506@gmail.com>
	<4E906EA8.5040601@collabora.co.uk> <4E920E85.6020204@gmail.com>
	<4E931A99.10907@collabora.co.uk> <4EABF049.1000203@gmail.com>
Message-ID: <4EAD8BAD.2000600@collabora.co.uk>

On 2011-10-29 14:23, Nikos Mavrogiannopoulos wrote:
> On 10/10/2011 06:17 PM, Stef Walter wrote:
> 
>>> Then I'd have exactly the same problem that you have. Performance issues
>>> :) It might be better for this issue to be solved once and for all users
>>> of p11-kit.
>>
>> It's pretty hard to do this correctly at the p11-kit layer. We cannot
>> transparently hide the fact that all of a sudden all slots, token info,
>> sessions, objects, and other handles have been invalidated. Therefore
>> any structures that gnutls is holding must also be cleared on fork.
>>
>> Forgive me if I'm missing something, but the only way I see to solve
>> this part of the problem is for p11-kit to notify gnutls that any and
>> all PKCS#11 state is invalid. gnutls would then start from a clean
>> pkcs#11 state. I'll work on some patches for gnutls.
> 
> Hi any update on that (on the p11-kit part). Would p11-kit provide a
> callback when reinitialization occurs, or should gnutls use pthread_atfork?

It turns out that pthread_atfork() callbacks is really only supposed to
call async-signal-safe functions. This is specified in some versions of
the POSIX documentation, and aluded to in others. It *seems* that on
Linux the 'child' handler can get away with doing more, but that is non
portable :(

I haven't removed the behavior from p11-kit which auto-reinitializes,
even though this is broken considering the above limitation.

So what I've been meaning to do is one or both of the following:

 * Provide a function/macro which callers p11-kit can use to check if a
   fork has occurred.

 * Merge in something like the pakchois API, so that we can do the
   reinitialization checks.

Cheers,

Stef



From INVALID.NOREPLY at gnu.org  Mon Oct 31 16:24:39 2011
From: INVALID.NOREPLY at gnu.org (Martin =?UTF-8?B?U3RvcnNqw7Y=?=)
Date: Mon, 31 Oct 2011 15:24:39 +0000
Subject: [sr #107860] The read_file function is too generic,
	clashes with similarly named functions in user applications
Message-ID: <20111031-152438.sv85909.76320@savannah.gnu.org>

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

                 Summary: The read_file function is too generic, clashes with
similarly named functions in user applications
                 Project: GnuTLS
            Submitted by: mstorsjo
            Submitted on: Mon 31 Oct 2011 03:24:38 PM GMT
                Category: Core library
                Priority: 5 - Normal
                Severity: 2 - Minor
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

The read_file function is a very generic name, which can cause clashes with
functions named similarly in calling applications, if linking gnutls
statically. (One concrete case was in the ffmpeg/avconv applications, where
the function has been renamed as a preparation for adding gnutls support:
http://git.libav.org/?p=libav.git;a=commitdiff;h=02170990fdb2a05c6eaf5fd449f440ec51c0f822)

The attached patch renames this function and the other ones in gl/read-file.h,
by adding a leading underscore. Any other prefix that would be internal to
gnutls would work just as well.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Mon 31 Oct 2011 03:24:38 PM GMT  Name:
0001-Rename-the-read_file-function-family.patch  Size: 11kB   By: mstorsjo

<http://savannah.gnu.org/support/download.php?file_id=24255>

    _______________________________________________________

Reply to this item at:

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

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