[gnutls-devel] gnutls 3.5.5

[Nikos Mavrogiannopoulos]

On Fri, 2016-10-21 at 20:08 +0200, Stefan Bühler wrote:

> I'd like to point out that gnutls_certificate_set_key* had an API
> incompatible change: they now might return integers > 0 when
> successful,
> which breaks previously documented behaviour of always returning
> GNUTLS_E_SUCCESS (i.e. 0).
> 
> I already pointed this out when reviewing the change, see:
> 
>     https://gitlab.com/gnutls/gnutls/merge_requests/65#note_15134877
> 
> Nikos, how do you want to handle this in the future? Should I always
> check for `>= GNUTLS_E_SUCCESS` in my code when testing for success?
> 
> If so this should be properly reflected throughout the documentation.

Hi Stefan,
 Thanks for bringing that up. I went through the documentation and the
related changes, and they are indeed not sufficient for the
documentation of such a change. I've tried to improve it at:
https://gitlab.com/gnutls/gnutls/merge_requests/123
(comments welcome)

My suggestion as you will see above in the merge request is for
applications to use if (retval < 0) to check for errors rather than
check for a specific success code. That cannot of course change past
applications.

My expectation was that few software will check for equality with zero,
mainly due to the examples which use the <0 pattern, and that even if
they did, the fact that the first certificate index would be zero, will
mitigate any issue (most applications load a single certificate).

Do you think this is going to cause issues? Most likely we can still
revert the change by introducing a flag in
gnutls_certificate_set_flags() which can enable the behavior of
returning indexes, instead of returning them by default.

regards,
Nikos