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 12 Apr 2011 12:26:19 PM UTC  
 
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)

(Why is this post is considered to be spam? Users may have reported it to be spam or, if it has been recently posted, it may just be waiting for spamchecks to be run.)
Spam content:

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. http://www.misiasty.pl http://www.e-zawady.pl http://www.e-zwd.pl
-Deleted Account- <misi4sty>
Tue 30 Aug 2011 11:47:19 AM UTC, comment #12:

That is correct.

Anonymous
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>
Project AdministratorIn charge of this item.
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 ?

Thanks.

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>
Project AdministratorIn charge of this item.
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:

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=20e0e448a2f3685cc6244f7c052b32f3f0719f73

Nikos Mavrogiannopoulos <nmav>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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
gnutls_record_check_pending()
has to be used to achieve the same functionality.

regards,
Nikos

Nikos Mavrogiannopoulos <nmav>
Project AdministratorIn charge of this item.
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?

thanks!

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

Hello,
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 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
https://bugs.archlinux.org/task/23678
(note: in that bug somebody mentions that it also breaks claws-mail, not just bitlbee)
http://bugs.bitlbee.org/bitlbee/ticket/779

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):
   
   
Comment:
   

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 06 Feb 2014 09:57:36 AM UTCnmavOpen/ClosedOpen=>Closed
    Mon 25 Apr 2011 05:52:07 PM UTCdanwCarbon-Copy-=>Added danw
    Tue 12 Apr 2011 01:38:53 PM UTCnmavStatusNeed Info=>Wont Do
    Tue 12 Apr 2011 12:34:37 PM UTCnmavAttached File-=>Added unpatch.txt, #23212
      StatusNone=>Need Info
      Assigned toNone=>nmav
    Tue 12 Apr 2011 12:26:22 PM UTCmhellwigCarbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup