[gnutls-help] "built-in" gnutls config, with optional-only config file on disk

Dimitri John Ledkov xnox at ubuntu.com
Tue Dec 31 16:48:13 CET 2019

On Mon, 16 Dec 2019 at 20:23, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Mon, Dec 16, 2019 at 4:17 AM Dimitri John Ledkov <xnox at ubuntu.com> wrote:
> >
> > In Ubuntu, gnutls default priority is set to "NORMAL", however, I kind
> > of like how on Fedora it is set to "@SYSTEM" and then a system config
> > file defines what that actually means. Allowing users to override that
> > system-wide.
> >
> > However, there are a few issues with that. It creates a hard
> > dependency between libgnutls and config file on disk, and said config
> > file must always specify [priorities] SYSTEM=, as otherwise setting
> > default priorities fails. (and apparmor profile must allow reading
> > said config, etc.)
> > Prime example, gnutls testuite fails, as it uses a custom
> > tests/system.prio without SYSTEM= specified. And for example, one can
> > see in Fedora spec file that 'echo SYSTEM=NORMAL >> tests/system.prio'
> > is done to unbreak the testsuite.
> >
> > It also means, that if one copies all the library dependencies of an
> > app, without the config file into chroot/initrd/container/etc one may
> > get non-working gnutls, or the one that behaves differently.
> >
> > Is there a way to provide built-in compiled defaults that operate with
> > or without a config file on disk? I.e. something like use @SYSTEM if
> > exists, otherwise fallback to "NORMAL"? That way, with or without
> > config, default behaviour is the same, setting default-priority always
> > works and users can still override it.
> I believe you can do what you describe by specifying a priority string
> to applications as "@SYSTEM,NORMAL". With that, the fallback policy
> will be the default NORMAL. However that has the drawback that you
> cannot know which profile each application will be using. It would be
> quite difficult to tell the system state and the expected outcome of a
> connection.

Just that works, but it's not that useful. What I reallly wanted was
something like:


But that fails....
|<2>| cfg: system priority /etc/gnutls/config has not changed
|<2>| resolved 'SYSTEM' to '', next 'NORMAL%PROFILE_MEDIUM'
|<2>| cfg: system priority /etc/gnutls/config has not changed
|<2>| resolved 'NORMAL%PROFILE_MEDIUM' to '', next ''
|<2>| unable to resolve @SYSTEM,NORMAL%PROFILE_MEDIUM

I can do @SYSTEM,NORMAL:%PROFILE_MEDIUM but that is not quite the
same, as it resolves to NORMAL:%PROFILE_MEDIUM or
SYSTEM:%PROFILE_MEDIUM. I.e. people will not be able to negate

I.e. users can only prepend, but not append things.

I kind of wish for


But that too fails to parse with:
Syntax error at: @SYSTEM,NONE

> > What about for the other overrides? I.e. can one somehow compile-in
> > default [overrides] that is used, unless system config specifies one?
> > I.e. built-in config specifying [overrides] disabled-versions=tls1.0,
> > with users able to turn it back on by creating the config and
> > specifying like empty [overrides] paragraph, or like using
> > reenable-versions=tls1.0.
> >
> > Maybe I am overthinking all of this, and what I really want is simply
> > support for
> >     [overrides]
> >     default-priority-string = NORMAL
> > Whilst the library itself is compiled with something stronger, i.e.
> > --with-default-priority-string='NORMAL:-VERS-TLS1.0'.
> That sounds like something reasonable. There is an ongoing coversation
> on how to handle national standards like GOST with a similar mechanism
> at:
> https://gitlab.com/gnutls/gnutls/merge_requests/1119
> Would you like to move that discussion there so that we combine the
> requirements?

Possibly. At the moment I do not see any better way than to introduce
[overrides]default-priority-string in the config file. As I want
NORMAL:-VERS-TLS1.0:-VERS-TLS1.1:%PROFILE_MEDIUM as the compiled-in
default but a way for users to override this behaviour in a config
file, which I don't see a way to do at the moment.

Also there isn't a compiled-in default for the [overrides]
verify-profile key, nor for the compiled-in [overrides]
disabled-version key, nor a way to reenable compiled-in

Imho, any library should have sensible compiled-in defaults, which can
be overridden with config files, such that one can have "available,
but disabled by default" algos / protocol version / profile levels /
etc, which users can opt-into anyway. This is separete to choosing to
not even compile unwanted protocol versions (i.e. just disable tls1.3
at build time, and not include that functionality in the library at

I wonder if as a distribution, I should be changing what "NORMAL"
means. And compile gnutls with @SYSTEM,NORMAL, and change such that
NORMAL means TLS1.2+ %PROFILE_MEDIUM with a distro patch.



More information about the Gnutls-help mailing list