[gnutls-devel] gnutls 3.5.6

[Nikos Mavrogiannopoulos]

On Fri, Nov 11, 2016 at 11:30 AM, Daniel P. Berrange
<berrange at redhat.com> wrote:
>> Any suggestions on how to mitigate that? Would a global flag to revert
>> the library behavior and generate compatibility DNs be sufficient?
> A global flag feels rather dirty for something that's in a library, as
> an app linking to 2 libraries both in turn using gnutls, may have
> conflicting desires for the state of the global flag.
> I'm guessing just reverting to the old behaviour unconditionally is out
> of the question ? Personally I would have added a new API to request the
> changed behaviour, so apps wanting new behaviour can know for sure that
> they're getting it rather than silently getting different behaviour
> based on the version of gnutls they link to.

Maybe that makes sense. Maybe I should introduce new functions which
obtain the textual DN which accept a flag to switch behavior (compat
or default), and the old functions stay as wrappers to the new with
the compat flag set. That will address both the need for the standard
compliant version, and breaking the existing behavior. I'll try to
schedule that for the next 3.5.x release.

> If you don't want to change gnutls, then is it safe for libvirt to
> simply split the string on ',' and reverse the pieces to reassemble
> the original ordering ?

Could also be, but in addition to not being simple (due to escaping
etc), if you used the string that way, other applications may have
done too, thus it would affect more than just libvirt. Addressing it
in gnutls makes sense.

regards,
Nikos