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

[Dimitri John Ledkov]

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:

@ SYSTEM,NORMAL%PROFILE_MEDIUM

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
%PROFILE_MEDIUM.

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

I kind of wish for

--priority='NORMAL:%PROFILE_MEDIUM:@SYSTEM,NONE'

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
disabled-versions.

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
all).

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.

-- 
Regards,

Dimitri.