This module was deprecated in 26.05 and is being removed in 26.11.
Generating your own dhparams has been obsoleted by RFC 7919 (2016).
DHE itself has been obsoleted by ECHDE (RFC8422, 2018) and Hybrid PQ
(draft-ietf-tls-ecdhe-mlkem, 2026) key exchanges.
TLS 1.3 (RFC8446, 2018) stopped defining any DHE cipher suites and lists
this as a major difference from TLS 1.2.
`pkgs.glibcLocales` is null for musl systems, so
`options.i18n.glibcLocales` needs to also be nullable.
otherwise, the `.override` and subsequence path interpolations
fail for non-gnu systems.
Generating your own dhparams has been obsoleted by RFC 7919 (2016).
DHE itself has been obsoleted by ECHDE (RFC8422, 2018) and Hybrid PQ
(draft-ietf-tls-ecdhe-mlkem, 2026) key exchanges.
TLS 1.3 (RFC8446, 2018) stopped defining any DHE cipher suites and lists
this as a major difference from TLS 1.2.
Per https://github.com/NixOS/nixpkgs/issues/96006, this does not work as
expected.
The warning trace will be emitted regardless of whether the option is
set, rendering it pointless. It does not work at the top-level either
(i.e. as `"security" "acme" "defaults" "credentialsFile"`), As such,
remove it entirely.
Situations where systemd-tmpfiles rules aren't applied but
acme-$name.service is rerun are quite unlikely, so it should be fine to
remove the mkdir completely.
Up to now, the webroot mechanism wasn't usable without extra steps
when the certificate was not intended for the web server. In my case,
I wanted to obtain a certificate for use in other services from a
private CA, but validate via a webroot served by nginx. The (sensibly!)
restrictive umask of acme-$name.service led to the webroot being created
with o-rx permissions, which meant that nginx could not serve the
webroot and the certificate could not be obtained.
This retains the mkdir invocation as a best-effort attempt to create the
webroot if for example the state has been cleared since systemd-tmpfiles
setup, but relies primarily on systemd-tmpfiles to create the webroots
with appropriate permissions.
Several modules define whole PAM service rule stacks by overwriting the
default value of the 'text' option. Instead, we disable useDefaultRules
for these services and declare a new set of rules using the 'rules'
option. This option is considered experimental and hidden from users,
but it is supported for use within nixpkgs.
This function is used to convert an ordered list of rules into an
attrset of rules with reasonable 'order' values. This reduces
boilerplate to define 'order' and makes it simple to switch how ordering
is managed in the future.
This option is enabled by default to preserve the current behavior when
a new service is declared. Users may disable this option to more easily
create a service without any rules. In nixpkgs, we can use this option
to eliminate usage of the 'text' option where the entire service rule
stack is replaced.
PAM rules with non-absolute module paths are rejected when apparmor is
used. In general, it helps (aside from readability) for all the module
paths to be absolute, especially when the user overrides the PAM
package.
polkit 127 switched to socket activation with a systemd unit for
polkit-agent-helper that uses PrivateDevices=yes and ProtectHome=yes.
This breaks pam_u2f (and potentially other PAM modules that interact
with hardware), because:
- PrivateDevices=yes creates a private /dev without hidraw devices,
so FIDO tokens are inaccessible
- ProtectHome=yes blocks reading ~/.config/Yubico/u2f_keys
- StandardError=inherit causes polkit agents to misinterpret PAM
diagnostic output as protocol errors, resulting in tight
re-execution loops
Fix by overriding these properties in the polkit module:
- StandardError=journal unconditionally (benefits all PAM modules)
- PrivateDevices/DeviceAllow/ProtectHome when pam_u2f is enabled
Co-authored-by: Victor Luft <victor@luft.io>
With Lego since 4.25.0 instead of --days we can pass --dynamic to pick
the renewal date based on a fraction of its total validity duration.
This provides a reasonable default that accomodates varying certificate
validy durations we're going to be seeing through the profile option and
LE's plans to reduce the default validity duration in multiple steps down
to 45 days in 2028.
This changes changes the default valid duration to null to enable dynamic
renewal calculation. To that end the expiration skip function gained the
ability to calculate the total and remaining duration and to apply the
correct remainder based on the certificates total duration.