[gnutls-devel] gnutls 3.5.5

[Nikos Mavrogiannopoulos]

On Sat, 2016-10-22 at 11:30 +0200, Thomas Klute wrote:
> 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.
> > It did cause issues with lighttpd2; as there is no release and I
> > fixed
> > it in git HEAD I don't see any remaining issues in this case.
> > 
> > I can't speak for other applications :)
> It is definitely a problem for mod_gnutls, which has a lot of
> "(==|!=)
> GNUTLS_E_SUCCESS" status checks. The one function affected by this
> API
> change should be easy enough to change, but I don't want to do a
> pattern
> change over the whole code base. The risk of unintended side effects
> seems low, but I wouldn't want to take the chance.
> 
> Generally I think this change violates the principle of least
> surprise:
> If the API documentation says "returns GNUTLS_E_SUCCESS or an error
> code", checking for equality is the obviously safe thing to do. Of
> course if GnuTLS explicitly guarantees that error codes will always
> be
> negative that's no less safe, but not something I would've expected
> based on the old API doc.
> 
> If there are similar changes in the future, all functions should be
> listed under "API and ABI modifications" to make it as easy as
> possible
> to find affected code. Without a complete list I'm still worried I
> might
> have missed something broken by the change in 3.5.5.

The intention is to make 3.5.x once stabilized API compatible with the
3.x series and ABI compatible with the 3.4 branch. Thus it may make
sense to revert that patch and require the application to perform an
extra step to obtain these indexes.

btw. In any case that API should be useful to mod_gnutls as well, since
it will provide a way to associate local OCSP responses with
certificates, something that is not possible today (with versions prior
to 3.5.5 at least).

regards,
Nikos