helpGnuTLS - Support: sr #107521, Lint encountered during compile

 
 

sr #107521: Lint encountered during compile

Submitted by:  Jeffrey Walton <noloader>
Submitted on:  Tue 16 Nov 2010 05:50:50 PM UTC
 
Category:  None Priority:  5 - Normal
Severity:  2 - Minor Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Wed 17 Nov 2010 02:36:07 PM UTC, comment #6: 

Note that some of these problems are because of types used in the public header file.  We can't change the public header file without considering backwards compatibility issues.

Look at 'gnutls_datum_t' for example, it uses 'unsigned char*' and 'unsigned int'.  Changing that to use size_t, for example, will break API/ABI significantly.

/Simon

Simon Josefsson <jas>
Project Administrator
Wed 17 Nov 2010 12:06:38 PM UTC, comment #5: 

Before adding that all the generated warnings have to be fixed. Something that is not that trivial...

--nmav

Anonymous
Wed 17 Nov 2010 07:56:40 AM UTC, comment #4: 

Hi Simon,

Forgot to mention....

> Fixing these will be a bit of a pain, but we should do it
> since the code is not clean.

When -Wall -Wextra is not specified, GnuTLS is effectively saying, "we'll let GCC pick and choose what warnings are relevant for the project".

GCC does not suffer the project's crashes or vulnerabilities, so GCC should not be making the decisions.

GnuTLS should specify -Wall -Wextra, so the project can decide what warnings need attention and which can be safely ignored.

Jeff

Jeffrey Walton <noloader>
Wed 17 Nov 2010 07:24:35 AM UTC, comment #3: 

> For the signed/unsigned pointers, I would introduce a
> gnutls byte or octet that was typedf'd as an unsigned
> char. typedef'ing would step away from signed/unsigned
> chars, which is conceptually consistent with operating
> on the data bytes or data octets.


> With the byte_t or octet_t in place, data which is truly
> a char* would be operated upon by str* functions, while
> data which is a byte_t* or octet_t* would manipulated
> with the mem* functions.

Yikes! I'm slipping in my old age. That should be: "...would be operated upon by SAFE str* functions",

Jeff

Jeffrey Walton <noloader>
Wed 17 Nov 2010 07:17:59 AM UTC, comment #2: 

Hi Simon,

> Fixing these will be a bit of a pain, but we should do it
> since the code is not clean.

Agreed. -Wall -Wextra is a nice tattle tale. The switches vet issues before they become problems (confer, SR #106551 and SR #106549).

> The most time consuming part is the pointer signed/unsigned
> issue. Before someone spends a lot of time on a patch,
> please tell how you think it should be solved and why.

For the signed/unsigned pointers, I would introduce a gnutls byte or octet that was typedf'd as an unsigned char. typedef'ing would step away from signed/unsigned chars, which is conceptually consistent with operating on the data bytes or data octets.

With the byte_t or octet_t in place, data which is truly a char* would be operated upon by str* functions, while data which is a byte_t*/octet_t* would manipulated with the mem* functions.

Personally, I'm more concerned with "comparison between signed and unsigned integer expressions". A comparison is going to be made, the question is "How?". In this case, the [possible] negative number is most likely promoted to unsigned, which usually results in a really big positive value if the original number is negative.

Consider: the adversary controls the wire, so he/she is going to feed gnutls bad certs and other miscreant data in an effort to get a toe hold on the system. Adobe is a case study in this sort of vulnerability. Its not the common case, its just something that gnutls should be mindful.

Jeff

Jeffrey Walton <noloader>
Tue 16 Nov 2010 09:27:19 PM UTC, comment #1: 

Fixing these will be a bit of a pain, but we should do it since the code is not clean.  The most time consuming part is the pointer signed/unsigned issue.  Before someone spends a lot of time on a patch, please tell how you think it should be solved and why.

/Simon

Simon Josefsson <jas>
Project Administrator
Tue 16 Nov 2010 05:50:50 PM UTC, original submission:  

gnutls-make.txt is attached.

$ ./configure CFLAGS="-Wall -Wextra -Wno-unused-parameter"
$ make &> ./gnutls-make.txt
$ cat gnutls-make.txt | grep warning | wc -l
191
$

Jeffrey Walton <noloader>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #22035:  gnutls-make.txt added by noloader (209KiB - 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 nmav (Updated the item)
  • -email is unavailable- added by jas (Posted a comment)
  • -email is unavailable- added by noloader (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-04-10 nmav Open/ClosedOpen => Closed
    2010-11-16 noloader Attached File- => Added gnutls-make.txt, #22035

    Back to the top


    Powered by Savane 3.9