[gnutls-devel] GnuTLS | RFC7250 Raw public keys (!650)

Development of GNU's TLS library gnutls-devel at lists.gnutls.org
Mon Nov 26 14:15:38 CET 2018


Nikos Mavrogiannopoulos commented on a discussion on lib/auth/cert.c:

> +	int ret;
> +	gnutls_pcert_st *apr_cert_list;
> +	gnutls_privkey_t apr_pkey;
> +	int apr_cert_list_length;
> +
> +	// Retrieve the appropriate certificate
> +	if((ret = _gnutls_get_selected_cert(session, &apr_cert_list,
> +				       &apr_cert_list_length, &apr_pkey)) < 0)	{
> +			return gnutls_assert_val(ret);
> +	}
> +
> +	/* Since we are transmitting a raw public key with no additional
> +	 * certificate credentials attached to it, it doesn't make sense to
> +	 * have more than one certificate set (i.e. to have a certificate chain).
> +	 */
> +	if (apr_cert_list_length == 1) {

> Isn't that a matter of coding style? I'm used to check for the condition that I need and then act on that. All other scenario's are then falsy. I find it a good approach, especially within the field of security. What's the advantage of checking the inverse condition and directly returning an error? Just to get rid of the else-statement and one level of indentiation?

It is indeed, and it is best to be consistent through the code. Nevertheless we have discussed that in the past, but let me try to demonstrate with an extreme example why eliminating illegal values early makes for more readable code. The first checks for invalid values before and returns early while the other checks for invalid 
```
if (vara == 0 || varb == 1 || varc == 2)
  return -1; /* our error condition */

/* normal code flow */
do_something();
```

The other approach, is checking within the code flow and does not worry about adding indentation for tests.
```
if (vara == 0) {
  return -1;
} else {
  if (varb == 1) {
    return -1;
  } else {
     if (varc == 2)
       return -1;
     else
       do_something();
  }
}
```

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/650#note_120070133
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/20181126/b7df6340/attachment-0001.html>


More information about the Gnutls-devel mailing list