helpGnuTLS - Support: sr #107660, gnutls update to 2.12 branch...


sr #107660: gnutls update to 2.12 branch breaks programs in ARCH and Debian squeeze

Submitted by:  Michael Hellwig <mhellwig>
Submitted on:  Tue Apr 12 12:26:19 2011  
Category: NonePriority: 5 - Normal
Severity: 3 - NormalStatus: Wont Do
Privacy: PublicAssigned to: Nikos Mavrogiannopoulos <nmav>
Open/Closed: ClosedOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

 Spam posted by misi4sty
Tue Aug 30 11:47:19 2011, comment #12:

That is correct.

Tue Aug 30 09:18:48 2011, comment #11:

Hi Nikos,

Thanks for your answer. So, if I understood everything well I need the following to avoid blocking:

when reading from socket, first check if gnutls_record_check_pending() != 0, and if 0, check for select()

when writing, just select()

Is that it ?

Thanks !

Colin Leroy <colinleroy>
Tue Aug 30 07:18:18 2011, comment #10:

Note that select() is used to check for data in the kernel networking buffers. This will not change. What changed (in 3.0.0) is that select() cannot be used any more to check for data in the GnuTLS read buffers.

GnuTLS doesn't hold any write buffers, i.e., every data given to gnutls_record_send() are immediately forwarded to underlying transport layer. Thus, you don't need any equivalent to gnutls_record_check_pending() to know whether writing to the socket would block. It solely depends on the transport layer (i.e. send()).

Nikos Mavrogiannopoulos <nmav>
Project AdministratorIn charge of this item.
Tue Aug 30 06:52:52 2011, comment #9:

If I understand correctly, using select() will be completely impossible with future versions of GnuTLS ?

Is there an equivalent to gnutls_record_check_pending() to know whether writing to the socket would block ?


Colin Leroy <colinleroy>
Mon Apr 25 19:01:16 2011, comment #8:

gnutls_record_check_pending() will return non-zero when there are data that have not been read by the application. It might be less than a complete record (i.e. 1 byte). If it is non-zero any access to gnutls_record_recv() will not involve the network so it will never return GNUTLS_E_AGAIN.

Nikos Mavrogiannopoulos <nmav>
Project AdministratorIn charge of this item.
Mon Apr 25 17:52:07 2011, comment #7:

Is it correct that gnutls_record_check_pending() only returns non-0 when there is a complete TLS record buffered? ie, if gnutls_record_check_pending() returns non-0, is it guaranteed that an immediately following call to gnutls_record_recv() will not return GNUTLS_E_AGAIN?

Dan Winship <danw>
Tue Apr 12 13:49:45 2011, comment #6:

If more information on how to use the gnutls_record_check_pending() is required, here is our modification of gnutls-cli to use it:;a=commitdiff;h=20e0e448a2f3685cc6244f7c052b32f3f0719f73

Nikos Mavrogiannopoulos <nmav>
Project AdministratorIn charge of this item.
Tue Apr 12 13:47:15 2011, comment #5:

Thank you. We could fix it in gnutls 2.12.x and restore the old default, but we'll just postpone the inevitable for the next release that abolishes that functionality.

Nikos Mavrogiannopoulos <nmav>
Project AdministratorIn charge of this item.
Tue Apr 12 13:45:16 2011, comment #4:

ok .. well I'll try and communicate that to the bitlbee people .. as for other projects .. who knows. at least now you'll know what all those bugs will be about ;)

Michael Hellwig <mhellwig>
Tue Apr 12 13:38:53 2011, comment #3:

Unfortunately not :( I just wanted to test what was the issue. gnutls 2.12.0 changed the semantics of gnutls_transport_set_lowat() and the default value is zero.

There are two solutions.
1. Quick fix. Programs that require another value must explicitly call:
gnutls_transport_set_lowat (session, 1);

after (gnutls_init()).

2. Long-term fix. Because later versions of gnutls abolish the functionality of using the system call select() to check for gnutls pending data, the function
has to be used to achieve the same functionality.


Nikos Mavrogiannopoulos <nmav>
Project AdministratorIn charge of this item.
Tue Apr 12 12:58:47 2011, comment #2:

indeed yes, at least for the bitlbee case. the claws-mail case was reported by somebody else, can't test for that.

So hooray, reverting the patch fixes things. Does that mean gnutls has a slight problem that will now be fixed? or that other software does and some workaround broke due to that patch? Or .. other options?


Michael Hellwig <mhellwig>
Tue Apr 12 12:34:37 2011, comment #1:

If you revert the patch in unpatch.txt, do the issues go away?

(file #23212)

Nikos Mavrogiannopoulos <nmav>
Project AdministratorIn charge of this item.
Tue Apr 12 12:26:19 2011, original submission:

I don't really have much more info than "before the update, things worked, now they don't".

bugs at
(note: in that bug somebody mentions that it also breaks claws-mail, not just bitlbee)

at least in the case of bitlbee, I've tested that the problem goes away when I downgrade to gnutls 2.10.5 or link the program against openssl instead. Bitlbee developers also recommend linking against nss but when I do that, I get another problem (although there the connection doesn't hang, it just dies right away).

Michael Hellwig <mhellwig>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #23212:  unpatch.txt added by nmav (820B - text/plain)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by misi4sty (Posted a comment)
  • -unavailable- added by colinleroy (Posted a comment)
  • -unavailable- added by danw (Posted a comment)
  • -unavailable- added by danw
  • -unavailable- added by nmav (Updated the item)
  • -unavailable- added by mhellwig
  • -unavailable- added by mhellwig (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu Feb 6 09:57:36 2014nmavOpen/ClosedOpen=>Closed
    Mon Apr 25 17:52:07 2011danwCarbon-Copy-=>Added danw
    Tue Apr 12 13:38:53 2011nmavStatusNeed Info=>Wont Do
    Tue Apr 12 12:34:37 2011nmavAttached File-=>Added unpatch.txt, #23212
      StatusNone=>Need Info
      Assigned toNone=>nmav
    Tue Apr 12 12:26:22 2011mhellwigCarbon-Copy-=>Added -unavailable-

    Back to the top

    Powered by Savane 3.1-cleanup1