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


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

Submitter:  Michael Hellwig <mhellwig>
Submitted:  Tue 12 Apr 2011 12:26:19 PM UTC
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Wont Do
Privacy:  Public Assigned to:  nmav
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

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

That is correct.

Tue 30 Aug 2011 09:18:48 AM UTC, 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 30 Aug 2011 07:18:18 AM UTC, 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>
Group administrator
Tue 30 Aug 2011 06:52:52 AM UTC, 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 25 Apr 2011 07:01:16 PM UTC, 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>
Group administrator
Mon 25 Apr 2011 05:52:07 PM UTC, 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 12 Apr 2011 01:49:45 PM UTC, 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>
Group administrator
Tue 12 Apr 2011 01:47:15 PM UTC, 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>
Group administrator
Tue 12 Apr 2011 01:45:16 PM UTC, 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 12 Apr 2011 01:38:53 PM UTC, 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>
Group administrator
Tue 12 Apr 2011 12:58:47 PM UTC, 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 12 Apr 2011 12:34:37 PM UTC, comment #1: 

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

(file #23212)

Nikos Mavrogiannopoulos <nmav>
Group administrator
Tue 12 Apr 2011 12:26:19 PM UTC, 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 Files:

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
  • -email is unavailable- added by misi4sty (Posted a comment)
  • -email is unavailable- added by colinleroy (Posted a comment)
  • -email is unavailable- added by danw (Posted a comment)
  • -email is unavailable- added by danw
  • -email is unavailable- added by nmav (Updated the item)
  • -email is unavailable- added by mhellwig
  • -email is unavailable- added by mhellwig (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-02-06 nmav Open/ClosedOpen Closed
    2011-04-25 danw Carbon-Copy- Added danw
    2011-04-12 nmav StatusNeed Info Wont Do
    2011-04-12 nmav Attached File- Added unpatch.txt, #23212
        StatusNone Need Info
        Assigned toNone nmav
    2011-04-12 mhellwig Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code