[gnutls-devel] GnuTLS | update tlsfuzzer scripts to latest version (!774)

[Development of GNU's TLS library]

Nikos Mavrogiannopoulos commented on a discussion on lib/handshake.c:

> +		/* TLS1.2 or earlier, kx is associated with ciphersuite */
> +		kx = session->security_parameters.cs->kx_algorithm;
>  	}
>  
>  	if (kx) {
>  		session->security_parameters.server_auth_type = _gnutls_map_kx_get_cred(kx, 1);
>  		session->security_parameters.client_auth_type = _gnutls_map_kx_get_cred(kx, 0);
> -	} else if (session->internals.resumed == RESUME_FALSE) {
> -		return gnutls_assert_val(GNUTLS_E_INTERNAL_ERROR);
> +	} else if (unlikely(session->internals.resumed == RESUME_FALSE)) {
> +		/* Here we can only arrive if something we received
> +		 * prevented the session from completing. */
> +		return gnutls_assert_val(GNUTLS_E_ILLEGAL_PARAMETER);
>  	}
>  
>  	return 0;

We should try to be consistent on way or another, but I find returning zero much simpler (less typing), and makes error checking more natural (checking `< 0` for error feels more natural when you return zero on success). `GNUTLS_E_SUCCESS` was introduced for users of the library to use it when they like it (e.g., because it may look cleaner as you mention). However, that proved to be an issue because then some applications were checking for error as `if (ret != GNUTLS_E_SUCCESS)` instead of `if (ret < 0)`.applications were checking for error as `if (ret != GNUTLS_E_SUCCESS)` instead of `if (ret < 0)`. I may be wrong but I feel that the use of a definition for zero prompted a different use than the originally intended, and caused problem when enhancing APIs to return more specific info (e.g., how many certs were loaded), on newer revisions of gnutls. That prompted the introduction of the ugly `GNUTLS_CERTIFICATE_API_V2` flag. So if I would change something would be to mark the use of `GNUTLS_E_SUCCESS` as deprecated :) Nevertheless, lets discuss this on a separate bug or cleanup MR.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/774#note_110177092
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20181019/93a00354/attachment.html>