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 #11505 (which puts the dhparams in the Nix
store) would have been merged instead of #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 #39507 and #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
We're going to implement an option which allows us to turn off stateful
handling of Diffie-Hellman parameter files by putting them into the Nix
store.
However, modules now might need a way to reference these files, so we
add a now path option to every param specified, which carries a
read-only value of the path where to find the corresponding DH params
file.
I've also improved the description of security.dhparams.params a bit so
that it uses <warning/> and <note/>.
The NixOS VM test also reflects this change and checks whether the old
way to specify the bit size still works.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Ekleog
We're going to make changes to the dhparams module so we really want to
make sure we don't break it, so having a NixOS VM test is to make sure
we don't blow things up and can iterate on it.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Ekleog
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/smplayer/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/5vy4663v65r0ks1d1jcy0p24m2lk0zmh-smplayer-18.4.0/bin/smplayer -h’ got 0 exit code
- ran ‘/nix/store/5vy4663v65r0ks1d1jcy0p24m2lk0zmh-smplayer-18.4.0/bin/smplayer --help’ got 0 exit code
- found 18.4.0 with grep in /nix/store/5vy4663v65r0ks1d1jcy0p24m2lk0zmh-smplayer-18.4.0
- directory tree listing: https://gist.github.com/25ca7c094ad35c4c5ed4c2c33dfb9be2
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/tini/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/h0h2qyxwrvsjy47m1xyv7sxzd2j0ilsi-tini-0.18.0/bin/tini -h’ got 0 exit code
- ran ‘/nix/store/h0h2qyxwrvsjy47m1xyv7sxzd2j0ilsi-tini-0.18.0/bin/tini --version’ and found version 0.18.0
- found 0.18.0 with grep in /nix/store/h0h2qyxwrvsjy47m1xyv7sxzd2j0ilsi-tini-0.18.0
- directory tree listing: https://gist.github.com/c992fd0a24dfc0365d6b62ac567d395c
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/thefuck/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/p0waa9llvgzfvjv05vgwvsic2xlkm4jr-thefuck-3.26/bin/.thefuck-wrapped -h’ got 0 exit code
- ran ‘/nix/store/p0waa9llvgzfvjv05vgwvsic2xlkm4jr-thefuck-3.26/bin/.thefuck-wrapped --help’ got 0 exit code
- ran ‘/nix/store/p0waa9llvgzfvjv05vgwvsic2xlkm4jr-thefuck-3.26/bin/thefuck -h’ got 0 exit code
- ran ‘/nix/store/p0waa9llvgzfvjv05vgwvsic2xlkm4jr-thefuck-3.26/bin/thefuck --help’ got 0 exit code
- found 3.26 with grep in /nix/store/p0waa9llvgzfvjv05vgwvsic2xlkm4jr-thefuck-3.26
- directory tree listing: https://gist.github.com/7fd81df3f197603f76bdf8c0ae663dcb
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/yubikey-personalization/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykpersonalize -h’ got 0 exit code
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykpersonalize --help’ got 0 exit code
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykpersonalize -V’ and found version 1.19.0
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykchalresp -h’ got 0 exit code
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykchalresp --help’ got 0 exit code
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykchalresp -V’ and found version 1.19.0
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykinfo -h’ got 0 exit code
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykinfo --help’ got 0 exit code
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykinfo help’ got 0 exit code
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykinfo -V’ and found version 1.19.0
- found 1.19.0 with grep in /nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0
- directory tree listing: https://gist.github.com/6592e44c4a66c1b7cf2c9f4c2a75c3ab
Yeah yeah, I want parallel glob expansion but you get what I mean.
These two packages like getting upgraded together so to minimize
incompatibilities I'm upgrading them both in the same commit.
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
(cherry picked from commit ba52ae50488de85a9cf60a3a04f1c9ca7122ec74)
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
