This option allows us to turn off stateful generation of Diffie-Hellman
parameters, which in some way is still stateful as the generated DH
params file is non-deterministic.

However what we can avoid with this is to have an increased surface for
failures during system startup, because generation of the parameters is
done during build-time.

Another advantage of this is that we no longer need to take care of
cleaning up the files that are no longer used and in my humble opinion I
would have preferred that NixOS#11505 (which puts the dhparams in the Nix
store) would have been merged instead of NixOS#22634 (which we have now).

Luckily we can still change that and this change gives the user the
option to put the dhparams into the Nix store.

Beside of the more obvious advantages pointed out here, this also
effects test runtime if more services are starting to use this (for
example see NixOS#39507 and NixOS#39288), because generating DH params could take
a long time depending on the bit size which adds up to test runtime.

If we generate the DH params in a separate derivation, subsequent test
runs won't need to wait for DH params generation during bootup.

Of course, tests could still mock this by force-disabling the service
and adding a service or activation script that places pre-generated DH
params in /var/lib/dhparams but this would make tests less readable and
the workaround would have to be made for each test affected.

Note that the 'stateful' option is still true by default so that we are
backwards-compatible with existing systems.

Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Ekleog, @abbradar, @fpletz

This introduces an option that allows us to turn off stateful generation
of Diffie-Hellman parameters, which in some way is still "stateful" as
the generated DH params file is non-deterministic.

However what we can avoid with this is to have an increased surface for
failures during system startup, because generation of the parameters is
done during build-time.

Aside from adding a NixOS VM test it also restructures the type of the
security.dhparams.params option, so that it's a submodule.

A new defaultBitSize option is also there to allow users to set a
system-wide default.

I added a release notes entry that described what has changed and also
included a few notes for module developers using this module, as the
first usage already popped up in #39507.

Thanks to @Ekleog and @abbradar for reviewing.

The pull request that added dhparams (#39507) was made at the time where
the dhparams module overhaul (#39526) wasn't done yet, so it's still
using the old mechanics of the module.

As stated in the release notes:

  Module implementers should not set a specific bit size in order to let
  users configure it by themselves if they want to have a different bit
  size than the default (2048).

  An example usage of this would be:

    { config, ... }:

    {
      security.dhparams.params.myservice = {};
      environment.etc."myservice.conf".text = ''
        dhparams = ${config.security.dhparams.params.myservice.path}
      '';
    }

Signed-off-by: aszlig <aszlig@nix.build>
Cc: @qknight, @abbradar, @hrdinka, @leenaars

The pull request that added dhparams (NixOS#39507) was made at the time where
the dhparams module overhaul (NixOS#39526) wasn't done yet, so it's still
using the old mechanics of the module.

As stated in the release notes:

  Module implementers should not set a specific bit size in order to let
  users configure it by themselves if they want to have a different bit
  size than the default (2048).

  An example usage of this would be:

    { config, ... }:

    {
      security.dhparams.params.myservice = {};
      environment.etc."myservice.conf".text = ''
        dhparams = ${config.security.dhparams.params.myservice.path}
      '';
    }

Signed-off-by: aszlig <aszlig@nix.build>
Cc: @qknight, @abbradar, @hrdinka, @leenaars
(cherry picked from commit 67a8c66)

This option allows us to turn off stateful generation of Diffie-Hellman
parameters, which in some way is still stateful as the generated DH
params file is non-deterministic.

However what we can avoid with this is to have an increased surface for
failures during system startup, because generation of the parameters is
done during build-time.

Another advantage of this is that we no longer need to take care of
cleaning up the files that are no longer used and in my humble opinion I
would have preferred that NixOS#11505 (which puts the dhparams in the Nix
store) would have been merged instead of NixOS#22634 (which we have now).

Luckily we can still change that and this change gives the user the
option to put the dhparams into the Nix store.

Beside of the more obvious advantages pointed out here, this also
effects test runtime if more services are starting to use this (for
example see NixOS#39507 and NixOS#39288), because generating DH params could take
a long time depending on the bit size which adds up to test runtime.

If we generate the DH params in a separate derivation, subsequent test
runs won't need to wait for DH params generation during bootup.

Of course, tests could still mock this by force-disabling the service
and adding a service or activation script that places pre-generated DH
params in /var/lib/dhparams but this would make tests less readable and
the workaround would have to be made for each test affected.

Note that the 'stateful' option is still true by default so that we are
backwards-compatible with existing systems.

Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Ekleog, @abbradar, @fpletz
(cherry picked from commit 3e11ff6)