GnuTLS 3.0.0 Warning

[Dash Shendy]

While compiling the latest version of GnuTLS, I get the following warning:

cc1: warnings being treated as errors
cert.c: In function âcall_get_cert_callbackâ:
cert.c:581:3: error: enumeration value âGNUTLS_PRIVKEY_PKCS11â not handled in switch [-Wswitch]
make[3]: *** [cert.lo] Error 1

I know that some warnings are ok to ignore, is this one of them, or should I be worried?

The Library was conf'ed using the following options:
./configure --prefix=/usr --enable-cryptodev --enable-ld-version-script --enable-valgrind-tests --enable-gcc-warnings --enable-shared=all --enable-guile --with-libnettle-prefix --with-included-libtasn1 --with-libiconv-prefix=/usr --with-libpthread-prefix=/usr --with-libintl-prefix=/usr --with-libz-prefix=/usr --with-libnettle-prefix=/usr --with-included-libcfg --with-packager=/usr/bin/pkg-config --with-gnu-ld --without-p11-kit

I'll just ignore the warning for now, but ideally would prefer a clean compilation;)

Regards,

Dash Shendy
Coder/Pentester/Security-Analyst
http://dash.za.net/?smtpsig
gtalk: address@hidden
skype: dashula2006
mopho: (+27) 72 23 75 199

On 8/3/2011 6:00 PM, address@hidden wrote:

Send Gnutls-devel mailing list submissions to
	address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.gnu.org/mailman/listinfo/gnutls-devel
or, via email, send a message with subject or body 'help' to
	address@hidden

You can reach the person managing the list at
	address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gnutls-devel digest..."


Today's Topics:

   1. [sr #107763] Running GnuTLS in non-blocking mode.
      (Bj?rn Christensen)


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

Message: 1
Date: Wed, 03 Aug 2011 07:01:37 +0000
From: Bj?rn Christensen <address@hidden>
To: Bj?rn Christensen <address@hidden>, address@hidden
Subject: [sr #107763] Running GnuTLS in non-blocking mode.
Message-ID: <address@hidden>
Content-Type: text/plain;charset=UTF-8

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

                 Summary: Running GnuTLS in non-blocking mode.
                 Project: GnuTLS
            Submitted by: cybear
            Submitted on: Wed Aug  3 07:01:37 2011
                Category: Core library
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: Microsoft Windows

    _______________________________________________________

Details:

I think this is a variant of #107660.


I have just updated from version 2.10.1 to 2.12.7 and my application has
stopped working.

I am running one thread to handle all the socket communication both secure
through GnuTLS and unsecure on sockets.

All sockets have been set into non-blocking mode. 


The main loop in the work thread defines which sockets  to check for ready for
read and write and then suspends on the select() call.

When returned from the select() call I will read from the socket which has
data to read.

This strategy worked fine with version 2.10.1 but is broken in version
2.12.7.

Because: (as far as I can debug)

I sent from the client 231 bytes of data 115 bytes of header and 116 bytes of
data (my protocol)

I call gnutls_record_recv and ask for 115 bytes, because I want to read my 
header and determine what to do after that. 
Then I again mark the socket so select() will check it for new data (ready for
read on the raw socket) waiting for my 116 byte of data. And the work thread
suspends on the select() call.


But in version 2.12.7 no new data arrives on the socket because it was read
and buffered on the first call to gnutls_record_recv. SO my work thread grinds
to a halt on the socket gnutls buffers data.

Yes I can see there is a call to the gnutls_record_check_pending() but this
will cause that the way of reading will be different between secure and
unsecure communication.

And the comments in the code on gnutls_record_recv clearly indicates that the
intention is for the function to work like recv().







 








    _______________________________________________________

Reply to this item at:

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

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




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

_______________________________________________
Gnutls-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnutls-devel


End of Gnutls-devel Digest, Vol 45, Issue 3
*******************************************

0x1F109B38.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature