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

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

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

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
$