[gnutls-devel] gnutls 3.5.6

[Daniel P. Berrange]

On Fri, Nov 11, 2016 at 11:18:35AM +0100, Nikos Mavrogiannopoulos wrote:
> On Fri, Nov 11, 2016 at 11:07 AM, Daniel P. Berrange
> <berrange at redhat.com> wrote:
> > IIUC, this is responsible for a change in behaviour seen by libvirt.
> > Previously the client cert DN would get reported as
> >
> >     C=UK,CN=libvirt
> >
> > and with new version we're getting back
> >
> >     CN=libvirt,C=UK
> >
> > This is causing a regression for libvirt. The libvirt server has ablity
> > to set a whitelist against the DN string, against which we do a regex
> > match.
> >
> > eg the sysadmin may have defined a whitelist of
> >
> >     C=UK,CN=libvirt-client-*
> >
> > to allow all certs issed to libvirt clients.
> > This change in DN ordering by gnutls breaks any existing whitelists
> > our admins have setup, as well as breaking the libvirt test suite
> > which validates this.
> 
> 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.

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 ?

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|