From nadhemj at yahoo.com  Sun Aug  7 11:59:34 2011
From: nadhemj at yahoo.com (N. J.)
Date: Sun, 7 Aug 2011 02:59:34 -0700 (PDT)
Subject: Qs on _gnutls_record_log
Message-ID: <1312711174.65301.YahooMailNeo@web161004.mail.bf1.yahoo.com>

Hello,

I was able to install gnuTLS 3.0?successfully and?I am looking now on how to deal with messages generated by the code.
One of the functions I see in the code is "?_gnutls_record_log". I see this for example in gnutls_record.c, gnutls_alert.c and gnutls_ciphers.c.
My Qs are the following:
1. What does this function do exactly do?
2. Where does it output the error messages specified? And will I be able to see it if I use gnutls_serv?
3. Do I need to do anything to enable logging to the screen/file?
4. What is the difference between it and?_gnutls_audit_log?

Thanks in advance,
Nadhem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110807/a0467f8e/attachment.htm>

From nmav at gnutls.org  Mon Aug  8 23:27:35 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 08 Aug 2011 23:27:35 +0200
Subject: gnutls 2.12.8
Message-ID: <4E4054C7.5000700@gnutls.org>

Hello,
 I've just released gnutls 2.12.8. This release adds
new functionality to 2.12.x and fixes all the known
bugs.

* Version 2.12.8 (released 2011-08-08)

** libgnutls: PKCS #11 back-end was replaced by p11-kit
http://p11-glue.freedesktop.org/p11-kit.html. This backports
the 3.0.0 PKCS #11 back-end. Rewrite by Stef Walter.

** libgnutls: gcrypt: replaced occurences of gcry_sexp_nth_mpi (..., 0)
with gcry_sexp_nth_mpi (..., GCRYMPI_FMT_USG) to fix errors with 1.5.0.
Patch by Andreas Metzler.

** libgnutls: Verify that a certificate liste specified
using gnutls_certificate_set_x509_key*(), is sorted
according to TLS specification (from subject to issuer).

** libgnutls: Added GNUTLS_X509_CRT_LIST_FAIL_IF_UNSORTED flag for
gnutls_x509_crt_list_import. It checks whether the list to be
imported is properly sorted.

** libgnutls: writev_emu: stop on the first incomplete write. Patch by
Sjoerd Simons.

** libgnutls: Fix zlib handling in gnutls.pc. Patch by Andreas
Metzler.

** certtool: bug fixes in certificate request generation. Patch
by Petr P?sa?.

** API and ABI modifications:
GNUTLS_X509_CRT_LIST_FAIL_IF_UNSORTED: New element in
gnutls_certificate_import_flags



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

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.8.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.8.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 nmav at gnutls.org  Mon Aug  8 23:50:11 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 08 Aug 2011 23:50:11 +0200
Subject: Qs on _gnutls_record_log
In-Reply-To: <1312711174.65301.YahooMailNeo@web161004.mail.bf1.yahoo.com>
References: <1312711174.65301.YahooMailNeo@web161004.mail.bf1.yahoo.com>
Message-ID: <4E405A13.3010901@gnutls.org>

On 08/07/2011 11:59 AM, N. J. wrote:
> Hello,
> 
> I was able to install gnuTLS 3.0 successfully and I am looking now on how to deal with messages generated by the code.
> One of the functions I see in the code is " _gnutls_record_log". I see this for example in gnutls_record.c, gnutls_alert.c and gnutls_ciphers.c.
> My Qs are the following:
> 1. What does this function do exactly do?
> 2. Where does it output the error messages specified? And will I be able to see it if I use gnutls_serv?
> 3. Do I need to do anything to enable logging to the screen/file?
> 4. What is the difference between it and _gnutls_audit_log?

You might want to check the manual at:
http://www.gnu.org/software/gnutls/manual/html_node/Debugging-and-auditing.html#Debugging-and-auditing


regards,
Nikos



From nadhemj at yahoo.com  Tue Aug  9 12:11:53 2011
From: nadhemj at yahoo.com (N. J.)
Date: Tue, 9 Aug 2011 03:11:53 -0700 (PDT)
Subject: Qs on _gnutls_record_log
In-Reply-To: <4E405A13.3010901@gnutls.org>
References: <1312711174.65301.YahooMailNeo@web161004.mail.bf1.yahoo.com>
	<4E405A13.3010901@gnutls.org>
Message-ID: <1312884713.78773.YahooMailNeo@web161007.mail.bf1.yahoo.com>

Thanks Nikos for the response. I was able to figure it out.

Cheers,



________________________________
From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
To: N. J. <nadhemj at yahoo.com>
Cc: "help-gnutls at gnu.org" <help-gnutls at gnu.org>
Sent: Tuesday, August 9, 2011 12:50 AM
Subject: Re: Qs on _gnutls_record_log

On 08/07/2011 11:59 AM, N. J. wrote:
> Hello,
> 
> I was able to install gnuTLS 3.0 successfully and I am looking now on how to deal with messages generated by the code.
> One of the functions I see in the code is " _gnutls_record_log". I see this for example in gnutls_record.c, gnutls_alert.c and gnutls_ciphers.c.
> My Qs are the following:
> 1. What does this function do exactly do?
> 2. Where does it output the error messages specified? And will I be able to see it if I use gnutls_serv?
> 3. Do I need to do anything to enable logging to the screen/file?
> 4. What is the difference between it and _gnutls_audit_log?

You might want to check the manual at:
http://www.gnu.org/software/gnutls/manual/html_node/Debugging-and-auditing.html#Debugging-and-auditing


regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110809/acbc96be/attachment.htm>

From dinh at flic.net  Mon Aug 15 22:15:52 2011
From: dinh at flic.net (Dinh Le)
Date: Mon, 15 Aug 2011 13:15:52 -0700 (PDT)
Subject: gnutls_record_recv() hangs
Message-ID: <alpine.LFD.1.00.1108151314340.31054@flic.net>

Hi,

Please straighten out my understanding of the gnutls_record_recv()
related functions.  Listed below is a portion of my code for connecting
to an imap server, login, and list all the mail boxes.

The "Connect" and "Login" responses from the server are less than 1024
bytes while the 'list "" "*"' response is almost 4000 bytes in my case.
Since I don't know how to check if there's data available to be received,
I wrote a loop that continuously calls gnutls_record_recv() if the
previous message received is 1024 bytes in length.  This is a bad hack,
but I just wanted to see the code works before reading the manual more
carefully.

But this hack does not work since the previously received message may
be less than 1024 bytes long but there are still more data available
for receiving.  Worse yet, gnutls_record_recv() would hang indefinitely
if there's no data available to be received.

I am using gnutls version 2.6 on Ubuntu 10.04 (with the latest official
updates).

Please help.

Thank you,

Dinh

------------------------------------------------------------------------

void
send_request(char *msg)
{
   gnutls_record_send(session, msg, strlen(msg));
}

int
recv_response()
{
   int ret, ii;

   do {
     ret = gnutls_record_recv (session, buffer, MAX_BUF);
     if (ret == 0)
       {
         success ("client: Peer has closed the TLS connection\n");
         close_and_cleanup();
         return 0;
       }
     else if (ret < 0)
       {
         fail ("client: Error: %s\n", gnutls_strerror (ret));
         close_and_cleanup();
         return -1;
       }

     // printf ("- Received %d bytes: ", ret);
     for (ii = 0; ii < ret; ii++)
       {
         fputc (buffer[ii], stdout);
       }
   } while (ret == 1024);

   return 1;
}

void
doit (void)
{
   connect_to_imap_server();
   recv_response();			// receive connected response
   send_request(". login dinh xxx\r\n");	// request log in as dinh
   recv_response();			// receive login OK
   send_request(". list \"\" \"*\"\r\n");// request list "" "*"
   recv_response();			// receive long list of mail boxes
   recv_response();
   send_request(". select inbox\r\n");
   recv_response();
   close_and_cleanup();
}



From mike at cchtml.com  Mon Aug 15 23:54:49 2011
From: mike at cchtml.com (Michael Cronenworth)
Date: Mon, 15 Aug 2011 16:54:49 -0500
Subject: gnutls_record_recv() hangs
In-Reply-To: <alpine.LFD.1.00.1108151314340.31054@flic.net>
References: <alpine.LFD.1.00.1108151314340.31054@flic.net>
Message-ID: <4E4995A9.2000704@cchtml.com>

Dinh Le wrote:
> But this hack does not work since the previously received message may
> be less than 1024 bytes long but there are still more data available
> for receiving.  Worse yet, gnutls_record_recv() would hang indefinitely
> if there's no data available to be received.

You will need to use non-blocking I/O if you want to do multiple reads 
without hanging.

You have two options:
1. Add large static buffers and do one read.
2. Use non-blocking I/O and do multiple reads in blocks (the size can be 
up to you) and dynamically allocate memory to receive an unknown size 
data packet.



From mrsam at courier-mta.com  Tue Aug 16 01:45:20 2011
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Mon, 15 Aug 2011 19:45:20 -0400
Subject: =?UTF-8?Q?gnutls=5Frecord=5Frecv()?= hangs
References: <alpine.LFD.1.00.1108151314340.31054@flic.net>
Message-ID: <cone.1313451920.781485.31105.500@monster.email-scan.com>

Dinh Le writes:

> Hi,
>
> Please straighten out my understanding of the gnutls_record_recv()
> related functions.  Listed below is a portion of my code for connecting
> to an imap server, login, and list all the mail boxes.
>
> The "Connect" and "Login" responses from the server are less than 1024
> bytes while the 'list "" "*"' response is almost 4000 bytes in my case.
> Since I don't know how to check if there's data available to be received,

Right, you don't, and you do not need to know that. You do not need to check  
how much data is available to receive.

Having implemented both an IMAP server and an IMAP client myself, I can  
authoritatively tell you that by parsing the IMAP protocol properly, the  
client or the server always knows when it receives a complete IMAP message  
from its peer. Once you begin receiving an IMAP message from your peer, it  
is the content of the message, and not any byte count that you get from a  
single read attempt (gnutls_record_recv() with GnuTLS, a plain read() for  
unencrypted IMAP), that determines where the message ends, and the next one  
begins. You may very well find that some arbitrary gnutls_record_recv()  
gives you back the end of the current IMAP message you're reading, and the  
start of the next IMAP message from the peer.

> I wrote a loop that continuously calls gnutls_record_recv() if the
> previous message received is 1024 bytes in length.  This is a bad hack,
> but I just wanted to see the code works before reading the manual more
> carefully.
>
> But this hack does not work since the previously received message may
> be less than 1024 bytes long but there are still more data available
> for receiving.  Worse yet, gnutls_record_recv() would hang indefinitely
> if there's no data available to be received.

This approach has several logical flaws. There's nothing that requires an  
IMAP server to always write full records. An IMAP server may decide, for  
example, to flush its output buffer every ten folders when it's producing  
the response to your LIST request, for example. This results in records 
that are less than the full size.

Or, for example, the IMAP server you're talking to might have a disjoint  
TLS/SSL proxy wrapper running on top of it; that is, the server just talks  
non-encrypted IMAP, and a separate TLS/SSL wrapper reads and writes to the  
server, encrypting and decrypting its input and output streams on the fly.  
Perfectly valid approach, and I can tell you that this is exactly how some  
IMAP servers work. Then, if the server is busy for some reason, and pauses  
for a few milliseconds, and the TLS/SSL proxy wrapper sees that the server  
stops sending --the TLS/SSL wrapper is just a dumb wrapper with no explicit  
domain knowledge of IMAP -- it just takes whatever it collected in its  
buffer so far, and sends you a partial record. When the actual IMAP server  
gets more CPU and begins producing more output, the TLS/SSL proxy resumes  
sending you more records. Perfectly valid, nothing wrong with that, and your  
IMAP client code must be prepared to handle this eventuality too. In either  
case, you simply cannot use the raw byte count from gnutls_record_recv() to  
tell you anything at all, especially when you received a well-formed IMAP  
message. This will never work reliably.

Taking it a step further, I do believe that each call to  
gnutls_record_recv() right now gets cut off at the end of the current record  
GnuTLS has read from the server. That if you ask for 10,000 bytes, but the  
current record that the GnuTLS library has read has only 1,000 bytes left,  
GnuTLS will give you just the 1,000 bytes even though there might be unread  
data on the underlying transport, that GnuTLS could read for the next data  
record, and give you more data in response to your request.

I believe that's the way the library works now, but it's certainly within  
the realm of possibility for some future version to try to be smart and  
attempt to automatically coalesce multiple records together, so if you asked  
for more bytes than what's available, some future version of GnuTLS might  
attempt to read ahead and see if it gets another complete record that can be  
processed to produce additional data to satisfy the gnutls_record_recv()  
request. So, even if your IMAP server remains the same, a future version of  
GnuTLS might break for you.

The bottom line is that the byte count from gnutls_record_recv() says  
absolutely nothing whatsoever regarding the current IMAP message being read.  
IMAP, or any other structured protocol, does not work this way. This has  
nothing to do with GnuTLS. The same applies to non-encrypted IMAP, just  
substitute read() in place of gnutls_record_recv(), and the same principle  
applies. Trying to parse IMAP (or any other structured protocol) using  
counts of bytes individually read, is a failing proposition. You might be  
able to find a way to get your approach working with the specific behavior  
of the IMAP server you are testing again, and the individual manner it reads  
and writes. But as soon as your IMAP server is updated to a newer version,  
or even switched for a different IMAP server, or even if the version of  
GnuTLS gets switched out for you, be prepared to fix your logic, again.

You should treat the input you're getting from gnutls_record_recv() as an  
unstructured byte stream. How many bytes you're getting from a single  
individual gnutls_record_recv() is absolutely and completely irrelevant. You  
must read the data that gnutls_record_recv() gives you, irrespective of how  
many bytes you get each time, and parse the ongoing byte stream into  
discrete IMAP messages, one following each other, then act upon each message  
as you deem necessary. You may very well find that your last call to  
gnutls_record_recv() not only gave you the tail end of the current IMAP  
message you are parsing, but a partial beginning of the next IMAP message  
from the server! IMAP permits the server to send certain kinds of  
asynchronous messages, at any time. Even though you are using only 1024-byte  
reads, some IMAP messages are quite small; and it's perfectly feasible to  
get a single 1024-byte read containing two or small IMAP messages, one after  
the other.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: </pipermail/attachments/20110815/8621383c/attachment.pgp>

From dinh at flic.net  Tue Aug 16 06:09:28 2011
From: dinh at flic.net (Dinh Le)
Date: Mon, 15 Aug 2011 21:09:28 -0700 (PDT)
Subject: gnutls_record_recv() hangs
In-Reply-To: <cone.1313451920.781485.31105.500@monster.email-scan.com>
References: <alpine.LFD.1.00.1108151314340.31054@flic.net>
	<cone.1313451920.781485.31105.500@monster.email-scan.com>
Message-ID: <alpine.LFD.1.00.1108152029170.32473@flic.net>

Thank you Sam for the insightful reply.  Now I understand why the imap 
protocol wants all requests to begin with some symbol (name-value) that 
can be incremented so that the responses can be paired easier with the
corresponding requests on the client side.

Using select() seems to make the solution much more complicated than it 
should.  Some web servers simply fork(), read, buffer, process, write, and 
repeat.  Wow, this method is cleaner but can be much more expensive.

OK, I will have to experiment and read further.

Thank you all.

Dinh




From nmav at gnutls.org  Sun Aug 21 00:06:27 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 21 Aug 2011 00:06:27 +0200
Subject: gnutls 3.0.1
Message-ID: <4E502FE3.4050802@gnutls.org>

Hello,
 I've just released gnutls 3.0.1 It includes bug fixes and few feature
additions.

* Version 3.0.1 (released 2011-08-20)

** libgnutls: gnutls_certificate_set_x509_key_file() and
friends support server name indication. If multiple
certificates are set using these functions the proper one
will be selected during a handshake.

** libgnutls: Added AES-256-GCM which was left out from
the previous release. Reported by Benjamin Hof.

** libgnutls: When asking for a PKCS# 11 PIN multiple
times, the flags in the callback were not being updated
to reflect for PIN low count or final try.

** libgnutls: Do not allow second instances of PKCS #11
modules.

** libgnutls: fixed alignment issue in AES-NI code.

** libgnutls: The config file at gnutls_pkcs11_init()
is being read if provided.

** libgnutls: Ensure that a certificate list specified
using gnutls_certificate_set_x509_key() and friends, is
sorted according to TLS specification (from subject to issuer).

** libgnutls: Added GNUTLS_X509_CRT_LIST_FAIL_IF_UNSORTED flag for
gnutls_x509_crt_list_import. It checks whether the list to be
imported is properly sorted.

** crywrap: Added to the distribution. It is an application
that proxies TLS session to a port using a plaintext service.

** doc: Many GTK-DOC improvements.

** i18n: Translations were updated.

** API and ABI modifications:
GNUTLS_X509_CRT_LIST_FAIL_IF_UNSORTED: New element in
gnutls_certificate_import_flags
GNUTLS_PKCS11_PIN_WRONG: New flag for PIN callback


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-3.0.1.tar.xz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.1.tar.xz
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.1.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.1.tar.xz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.1.tar.xz.sig
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.1.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 nmav at gnutls.org  Sun Aug 21 00:38:24 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 21 Aug 2011 00:38:24 +0200
Subject: gnutls 2.12.9
Message-ID: <4E503760.7030601@gnutls.org>

Hello,
 I've just released gnutls 2.12.9. This release
fixes an issue in PKCS #11 PIN handling that could
lead to a card lock if wrong PIN was being supplied
to p11tool.


* Version 2.12.9 (released 2011-08-21)

** libgnutls-extra: Replaced enumeration with unsigned
int, in openssl.h to make it identical to the 3.0.0 version.
This shouldn't introduce binary incompatibility.

** libgnutls: When asking for a PIN multiple times, the
flags in the callback were not being updated to reflect
for PIN low count or final try.

** API and ABI modifications:
GNUTLS_PKCS11_PIN_WRONG: New flag for PIN callback



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

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.9.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.9.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 brukhanov.a.e at amakan.ru  Mon Aug 22 12:33:53 2011
From: brukhanov.a.e at amakan.ru (Alexander Brukhanov)
Date: Mon, 22 Aug 2011 19:33:53 +0900
Subject: GNU TLS Hang after error
Message-ID: <1314009233.13333.10.camel@greed.ispsystem.net>

I'm using gnutls 2.12.8 with poll and pthreads on FreeBSD and Linux
systems. Some times (when I have a long time between requests) I have
gnutls hanged. Here is my backtrace:

(gdb) info threads
  4 Thread 0xb6fc4b70 (LWP 11499)  0xb751d29c in *__GI___poll
(fds=0xb759fff4, nfds=1, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:87
  3 Thread 0xb5ec4b70 (LWP 11952)  __lll_lock_wait ()
at ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S:144
  2 Thread 0xb3affb70 (LWP 11973)  __lll_lock_wait ()
at ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S:144
* 1 Thread 0xb6fc5aa0 (LWP 11498)  0xb74f5e4c in nanosleep ()
at ../sysdeps/unix/syscall-template.S:82
(gdb) thread 3
[Switching to thread 3 (Thread 0xb5ec4b70 (LWP 11952))]#0
__lll_lock_wait ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S:144
144	../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S: ??? ??????
????? ??? ????????.
	in ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S
(gdb) bt
#0  __lll_lock_wait ()
at ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S:144
#1  0xb75abe5d in _L_lock_748 () from /lib/libpthread.so.0
#2  0xb75abc81 in __pthread_mutex_lock (mutex=0x88897f8) at
pthread_mutex_lock.c:61
#3  0x080da773 in gnutls_system_mutex_lock (priv=0x81b0ca0) at
system.c:197
#4  0x08125554 in wrap_nettle_rnd (_ctx=0x0, level=0, data=0x88ab0de,
datasize=32) at rnd.c:449
#5  0x080d9c68 in gnutls_rnd (level=GNUTLS_RND_NONCE, data=0x88ab0de,
len=143169528) at random.c:78
#6  0x080b4f77 in _gnutls_generate_session_id (session_id=0x88ab0de "",
len=0x88ab0fe " ") at gnutls_handshake.c:3157
#7  0x080b60be in _gnutls_read_client_hello (session=0x88ab058, 
    data=0x888b748 "\003\001NR\004\f\256\214\200\376=\200\274\fF\320\341
\275\341 Z\024H\250?A\257\360\336\027?\177 \340\317\327\024\034\236\070
\245;\v|\177R\a\360\023\233\034\332\373\374\254\003\246W\001\036\360uXp
\204", datalen=186)
    at gnutls_handshake.c:500
#8  _gnutls_recv_hello (session=0x88ab058, 
    data=0x888b748 "\003\001NR\004\f\256\214\200\376=\200\274\fF\320\341
\275\341 Z\024H\250?A\257\360\336\027?\177 \340\317\327\024\034\236\070
\245;\v|\177R\a\360\023\233\034\332\373\374\254\003\246W\001\036\360uXp
\204", datalen=186)
    at gnutls_handshake.c:2355
#9  0x080b7138 in _gnutls_recv_handshake (session=0x88ab058, data=0x0,
datalen=0x0, 
    type=GNUTLS_HANDSHAKE_CLIENT_HELLO, optional=MANDATORY_PACKET) at
gnutls_handshake.c:1526
#10 0x080b8fa0 in _gnutls_handshake_server (session=0x88ab058) at
gnutls_handshake.c:2987
#11 0x080ba0c7 in gnutls_handshake (session=0x88ab058) at
gnutls_handshake.c:2677
#12 0x0805eeee in MHD_tls_connection_handle_read (connection=0x888b868)
at connection_https.c:62
#13 0x0805e099 in MHD_handle_connection (data=0x888b868) at daemon.c:657
#14 0xb75a97b0 in start_thread (arg=0xb5ec4b70) at pthread_create.c:300
#15 0xb752a8fe in clone ()
at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) thread 2
[Switching to thread 2 (Thread 0xb3affb70 (LWP 11973))]#0
__lll_lock_wait ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S:144
144	in ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S
(gdb) bt
#0  __lll_lock_wait ()
at ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S:144
#1  0xb75abe5d in _L_lock_748 () from /lib/libpthread.so.0
#2  0xb75abc81 in __pthread_mutex_lock (mutex=0x88897f8) at
pthread_mutex_lock.c:61
#3  0x080da773 in gnutls_system_mutex_lock (priv=0x81b0ca0) at
system.c:197
#4  0x08125554 in wrap_nettle_rnd (_ctx=0x0, level=0, data=0xb3aff027,
datasize=28) at rnd.c:449
#5  0x080d9c68 in gnutls_rnd (level=GNUTLS_RND_NONCE, data=0xb3aff027,
len=143169528) at random.c:78
#6  0x080b5b6e in _gnutls_tls_create_random (dst=0xb3aff023 "NR\006\037
\bh\360\257\263@\026\r\b<?\bH?\b\272")
    at gnutls_handshake.c:330
#7  0x080b5c71 in _gnutls_read_client_hello (session=0x88ab928, 
    data=0x888c948 "\003\001NR\006\037M-\341V\227!\273\002\334y\256
\232aTM\277\016LAc\020D?\233\343/\020 \340\317\327\024\034\236\070\245;
\v|\177R\a\360\023\233\034\332\373\374\254\003\246W\001\036\360uXp\204",
datalen=186)
    at gnutls_handshake.c:443
#8  _gnutls_recv_hello (session=0x88ab928, 
    data=0x888c948 "\003\001NR\006\037M-\341V\227!\273\002\334y\256
\232aTM\277\016LAc\020D?\233\343/\020 \340\317\327\024\034\236\070\245;
\v|\177R\a\360\023\233\034\332\373\374\254\003\246W\001\036\360uXp\204",
datalen=186)
    at gnutls_handshake.c:2355
#9  0x080b7138 in _gnutls_recv_handshake (session=0x88ab928, data=0x0,
datalen=0x0, 
    type=GNUTLS_HANDSHAKE_CLIENT_HELLO, optional=MANDATORY_PACKET) at
gnutls_handshake.c:1526
#10 0x080b8fa0 in _gnutls_handshake_server (session=0x88ab928) at
gnutls_handshake.c:2987
#11 0x080ba0c7 in gnutls_handshake (session=0x88ab928) at
gnutls_handshake.c:2677
#12 0x0805eeee in MHD_tls_connection_handle_read (connection=0x88aaf90)
at connection_https.c:62
#13 0x0805e099 in MHD_handle_connection (data=0x88aaf90) at daemon.c:657
#14 0xb75a97b0 in start_thread (arg=0xb3affb70) at pthread_create.c:300
#15 0xb752a8fe in clone ()
at ../sysdeps/unix/sysv/linux/i386/clone.S:130

As I understand it happens because wrap_nettle_rnd exits with error. You
do not do RND_UNLOCK in case of error. But I have tried to unlock it. It
cause libmicrohttpd to drop all incoming connections.

static int
wrap_nettle_rnd (void *_ctx, int level, void *data, size_t datasize)
{
  int ret;

  RND_LOCK;

  ret = do_trivia_source (0);
  if (ret < 0)
    {
      gnutls_assert ();
      return ret;
    }

  ret = do_device_source (0);
  if (ret < 0)
    {
      gnutls_assert ();
      return ret;
    }

  yarrow256_random (&yctx, datasize, data);
  RND_UNLOCK;
  return 0;
}

Please, I need a advice what to do ?




From nmav at gnutls.org  Mon Aug 22 13:37:33 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 22 Aug 2011 13:37:33 +0200
Subject: GNU TLS Hang after error
In-Reply-To: <1314009233.13333.10.camel@greed.ispsystem.net>
References: <1314009233.13333.10.camel@greed.ispsystem.net>
Message-ID: <4E523F7D.6070505@gnutls.org>

On 08/22/2011 12:33 PM, Alexander Brukhanov wrote:
> I'm using gnutls 2.12.8 with poll and pthreads on FreeBSD and Linux
> systems. Some times (when I have a long time between requests) I have
> gnutls hanged. Here is my backtrace:
[...]

Indeed it shouldn't hang there, but it shouldn't arrive there as well.
I suppose that do_device_source_urandom() failed in your system. This
is very strange. Could you pinpoint what exactly failed?

> As I understand it happens because wrap_nettle_rnd exits with error. You
> do not do RND_UNLOCK in case of error. But I have tried to unlock it. It
> cause libmicrohttpd to drop all incoming connections.

If the random generator fails, gnutls cannot operate. This is expected.
What wasn't expected is the failure you see.

regards,
Nikos