[gnutls-devel] [PATCH] gnutls_priority_init: multiple @KEYWORD lookups with fallback

[Nikos Mavrogiannopoulos]

On Fri, 2016-06-03 at 16:57 +0100, Daniel P. Berrange wrote:
> The support for using "@KEYWORD" as a priority string is very
> useful to separate selection of priorities from application
> specific code or config files. It is, however, not general
> enough to fully serve all reasonable use cases.
> 
> For example, consider an application sets
> 
>   gnutls_priority_set_direct(session, "@SYSTEM", NULL);
> 
> The system administrator can modify the global priorities
> file to change what "@SYSTEM" resolves to for all apps using
> GNUTLS. As soon as one application wishes to have a slightly
> different configuration from others on the host, you have to
> go back and start modifying application specific configuration
> files once more. This is bad for the system administrator as
> it means there's no longer one single place where they can
> see the priority configuration for all apps.
> 
> They may try to get around this problem by configuring the
> app to use a different keyword, instead of a full priority
> string, eg "@LIBVIRT". So the global priorities file can
> now define entries for both "SYSTEM" and "LIBVIRT". This
> has still placed a burden on the administrator change the
> config in two places - both libvirt config files and the
> global priorities file.
> 
> What is more desirable is if applications were able to provide
> a list of keywords that would be tried in order, picking the
> first that existed. For example, libvirt could be written to
> request the following by default
> 
>   gnutls_priority_set_direct(session, "@LIBVIRT,SYSTEM", NULL);
> 
> With this, gnutls would first try to find the "LIBVIRT" keyword
> in the global configuration file, and if that is not present,
> then it would fallback to trying to find the "SYSTEM" keyword.
> 
> This provides nice "out of the box" behaviour for system
> administrators, whereby the app would be using "SYSTEM" initially
> and if the admin wishes to give the app a custom configuration,
> they can simply modify the global priorities file to add in the
> application specific keyword "LIBVIRT". There is never a need
> for the sysadmin to modify any application specific configuration
> files any more. It is exclusively controlled in one place via the
> global priorities file.

The keyword fallback could also be useful in applications which are
intended to run on different systems with different system-wide
keywords. I think it makes sense to add it.

This patch currently breaks tests/system-prio-file.c. Irrespective of
that it would be very good to have some test cases there for the
fallback option too.

> + * a default fallback. e.g., "@LIBVIRT, at SYSTEM:!-VERS-SSL3.0" will

There seems to be a typo here. Shouldn't that be @LIBVIRT,SYSTEM?


regards,
Nikos