ReiserFS has not been actively maintained for many years. It has been
marked as obsolete since Linux 6.6, and is scheduled for removal
in 2025. A warning is logged informing users of this every time a
ReiserFS file system is mounted. It suffers from unfixable issues
like the year 2038 problem.
JFS is a slightly more ambiguous case. It also has not been actively
maintained for years; even in 2008 questions were being raised
about its maintenance state and IBM’s commitment to it, and some
enterprise distributions were opting not to ship support for it as
a result. It will [indefinitely postpone journal writes], leading
to data loss over potentially arbitrary amounts of time. Kernel
developers [considered marking it as deprecated] last year, but
no concrete decision was made. There have been [occasional fixes]
to the code since then, but even the developer of much of those was
not opposed to deprecating it.
[considered marking it as deprecated]: https://lore.kernel.org/lkml/Y8DvK281ii6yPRcW@infradead.org/
[indefinitely postpone journal writes]: https://www.usenix.org/legacy/events/usenix05/tech/general/full_papers/prabhakaran/prabhakaran.pdf
[occasional fixes]: https://www.phoronix.com/news/JFS-Linux-6.7-Improvements
Regardless of whether JFS should be removed from the kernel, with all
the implications for existing installations that entails, I think
it’s safe to say that no new Linux installation should be using
either of these file systems, and that it’s a waste of space and
potential footgun to be shipping support for them on our standard
installation media. We’re lagging behind other distributions on
this decision; neither is supported by Fedora’s installation media.
(It also just so happens that `jfsutils` is the one remaining package
in the minimal installer ISO that has reproducibility issues, due to
some cursed toolchain bug, but I’m not trying to Goodhart’s law
this or anything. I just think we shouldn’t be shipping it anyway.)
Exposes all currently available command-line arguments that were
missing, including some that were impossible to use with the catch-all
option `extraArgs` alone, requiring changes to other parts of the
system.
Those are now all self-contained in the module.
The service now uses systemd's `DynamicUsers`.
With mautrix-signal v0.7.0 the bridge is built upon the bridgev2
architecture. With this, the configuration file was slightly rearranged.
Options like login_shared_secret_map and double_puppet_server_map were
dropped.
2.3.0 is the final release, the repo is now archived.
Also I don't use it anymore for quite a while, so it didn't have a real
nixpkgs maintainer either.
Closes#338712
For a long time now, the SDK and minimum target version for
`x86_64-darwin` has been stuck on macOS 10.12. In the past, the minimum
SDK was updated quite regularly; at first, the current situation was
just because updating the SDKs was excessively burdensome and nobody
was up for doing the work, but the introduction of `aarch64-darwin`
with its macOS 11 default SDK has resulted in a long‐term fracture
of the two platforms.
Per <https://endoflife.date/macos>, macOS 10.12 has not received
an update since 2017 and went out of security support 5 years
ago. Trying to support it in Nixpkgs has been a large burden on the
Darwin maintainers, resulting in workarounds, porting work, and even
patching functionality out of applications. The existence of Nix
users using a macOS version this old is, to my knowledge, entirely
theoretical, and we pay in both maintenance costs and functionality:
for instance, applications built for `x86_64-darwin` do not support
automatic dark mode switching by default.
This situation has always been suboptimal, but it is
now becoming untenable. Python, a critical component
of the Nixpkgs standard environment for builds, is
dropping support for versions older than 10.13 in 3.13:
<https://www.python.org/downloads/release/python-3130rc1/>. Qt 6 only
supports macOS 11 and newer. libuv only supports the versions Apple
does, and is a ticking time bomb due to its use in the standard
environment. QEMU only supports the last two macOS releases, and
won’t build with an SDK older than macOS 12; we previously vendored
a set of backporting changes and functionality‐removing reverts
to keep it building for 10.12, but this also became overly onerous,
and we gave up in <https://github.com/NixOS/nixpkgs/pull/338598>.
`x86_64-darwin` is a platform with a limited upstream future. Apple no
longer sells any hardware that runs it natively, and it is unclear how
much longer they will support it in the operating system. There are
still many users of the platform, myself included, so we shouldn’t
drop support for it prematurely, but it’s unreasonable to try and
patch the entire world to keep it supporting insecure versions of
the OS that only run on hardware that is no longer sold.
Therefore, this adds a release note to warn users ahead of time that
25.05 will only support macOS 11 and newer, as suggested by the 24.05
release team when the possibility of bumping the required version
was raised.
Why target Big Sur, rather than any other version? The
reason is simple: it’s the same SDK and deployment target as
`aarch64-darwin`. There are many packages that work on `aarch64-darwin`
but not `x86_64-darwin`, and Darwin maintainers frequently need to be
called in to fix things that work fine on the newer platform but not
the older one. This change will increase the health of `x86_64-darwin`
by aligning the SDK versions and support between the two platforms;
the vast majority of packages that work on one will Just Work on the
other. macOS 11 is almost four years old and has itself been out of
security support for a year now, but as the first version to support
Apple Silicon, it’s a far more compatible base for us to build our
Darwin packages for. Any future change in supported versions should
be synchronized between the two Darwin architectures.
When 25.05 is released, users on old, unsupported versions of macOS
will have the following options:
* Update to a new macOS version. For users that are on hardware
that Apple has dropped support for, OpenCore Legacy Patcher
(<https://dortania.github.io/OpenCore-Legacy-Patcher/>) can enable
the use of newer macOS versions on hardware even older than 10.12
supports.
* Install NixOS. That obviously precludes the use of macOS software
(though most of that software has already dropped support for 10.12),
but will give users a secure, supported operating system that we
can actually own the support for going forward.
* Keep using 24.11 forever. Since they’re not getting updates
to their OS and core applications anyway, this is likely to be
acceptable to many users.
* Switch to MacPorts. They support all the way back to 10.6 for
`x86_64-darwin` by building packages separately for every OS release,
though not every package is available for every version.
* Send patches. We *may* accept non‐invasive patches to keep
certain critical packages (such as the core `stdenv` packages)
building for old OS versions, on a case‐by‐case basis, but we
can’t guarantee it. This will ultimately have to be a decision
made by package maintainers and personally I doubt this will be a
viable path to sustainably support older versions.
The current kubernetes module only allows you to set a single DNS
resolver for the kubelet. Historically, this has not mattered as the
value was passed to a cli argument as a string and as per the kubelet's
configuration parsing mechanism, multiple values could be passed as a
comma-delimited string. However, recently, the module was refactored to
make configure kubernetes components via configuration files rather than
the deprecated command-line arguments. These files more strongly-typed
than CLI arguments and to pass multiple values, one must define a list
in the file. When this change was made, an incorrect assumption was made
that only a single DNS server could be specified and forced a
single-item list into this configuration file. We need to introduce a
breaking change to the module in order to allow the user to supply their
own list with however many dns resolvers they wish to use.
Every now and then, kubernetes adds new configuration parameters to the
kubelet configuration. Since this is defined using a nix attrset which
is then converted to json/yaml, it would be nice to have an escape hatch
similar to the extraOpts one that exists for additional CLI arguments.
The typical use case would be to configure new settings before they are
officially supported in the nixos module.
Strongly inspired by the forgejo counterpart[1], for the following
reasons:
* The feature is broken with the current module and crashes on
authentication with the following stacktrace (with a PAM service
`gitea` added):
server # Stack trace of thread 1008:
server # #0 0x00007f3116917dfb __nptl_setxid (libc.so.6 + 0x8ddfb)
server # #1 0x00007f3116980ae6 setuid (libc.so.6 + 0xf6ae6)
server # #2 0x00007f30cc80f420 _unix_run_helper_binary (pam_unix.so + 0x5420)
server # #3 0x00007f30cc8108c9 _unix_verify_password (pam_unix.so + 0x68c9)
server # #4 0x00007f30cc80e1b5 pam_sm_authenticate (pam_unix.so + 0x41b5)
server # #5 0x00007f3116a84e5b _pam_dispatch (libpam.so.0 + 0x3e5b)
server # #6 0x00007f3116a846a3 pam_authenticate (libpam.so.0 + 0x36a3)
server # #7 0x00000000029b1e7a n/a (.gitea-wrapped + 0x25b1e7a)
server # #8 0x000000000047c7e4 n/a (.gitea-wrapped + 0x7c7e4)
server # ELF object binary architecture: AMD x86-64
server #
server # [ 42.420827] gitea[897]: pam_unix(gitea:auth): unix_chkpwd abnormal exit: 159
server # [ 42.423142] gitea[897]: pam_unix(gitea:auth): authentication failure; logname= uid=998 euid=998 tty= ruser= rhost= user=snenskek
It only worked after turning off multiple sandbox settings and adding
`shadow` as supplementary group to `gitea.service`.
I'm not willing to maintain additional multiple sandbox settings for
different features, especially given that it was probably not used for
quite a long time:
* There was no PR or bugreport about sandboxing issues related to
PAM.
* Ever since the module exists, it used the user `gitea`, i.e. it had
never read-access to `/etc/shadow`.
* Upstream has it disabled by default[2].
If somebody really needs it, it can still be brought back by an overlay
updating `tags` accordingly and modifying the systemd service config.
[1] 07641a91c9
[2] https://docs.gitea.com/usage/authentication#pam-pluggable-authentication-module
This splits a dev output to make the default output not depend on any
build dependencies anymore. This also avoids removing references from
pgxs' Makefile this way, which should, at least theoretically, be good
to build extensions via pgxs, making sure they use the same tooling.
ecpg is the "embedded SQL C preprocessor", which is certainly a dev
tool.
Most important, for closure size anyway, is to move pg_config to the dev
output, since it retains paths to all the other outputs.
The only thing with references to the dev output remaining is then the
postgres binary itself. It contains all the output paths, because it
shows those in the pg_config system view. There is no other way than
to nuke those references to avoid circular dependencies between outputs
- and blowing up closure size again.
[UWSM](https://github.com/Vladimir-csp/uwsm) is a session manager that wraps a wayland
window compositor with useful systemd units like `graphical-session-pre.target`,
`graphical-session.target`, `xdg-desktop-autostart.target`.
This is useful for Wayland Compositors that do not start
these units on these own.
Example for Hyprland:
```nix
programs.hyprland.enable = true;
programs.uwsm.enable = true;
programs.uwsm.waylandCompositors = {
hyprland = {
compositorPrettyName = "Hyprland";
compositorComment = "Hyprland compositor managed by UWSM";
compositorBinPath = "/run/current-system/sw/bin/Hyprland";
};
};
```
Co-authored-by: Kai Norman Clasen <k.clasen@protonmail.com>
This splits the 3rdparty drivers into seperate
packages as recommended by upstream. This also
allows to build a indi-full equivalent with only
the needed drivers. Also add indi-full-nonfree
with all the nonfree drivers. And remove them
from indi-full.
https://forgejo.org/docs/latest/user/authentication/#pam-pluggable-authentication-module
PAM support has to be enabled at compile time and upstream considers it
opt-in.
Official upstream binaries have it disabled.
We enabled it by default because we simply inherited most of it from
Gitea when the split in nixpkgs happened.
Reasons why it had been enabled in nixpkgs for Gitea are unknown.
See 9406f240a7.
There is reason to believe not a single Forgejo instance running on
NixOS uses this feature because it literally segfaults due to our
sandboxing.
Fix overriding of vendorHash and various attributes via the fixed point
attribute support of stdenv.mkDerivation.
Pass as derivation attributes
goModules, modRoot, vendorHash, deleteVendor, and proxyVendor.
Move goModules and vendorHash out of passthru.
Co-authored-by: Doron Behar <doron.behar@gmail.com>
Deprecate singularity-tools.mkLayer and singularity-tools.shellScript,
for they are no longer related to image building.
Use writers.writeBash instead of singularity-tools.shellScript.
This change adds services.pgbouncer.settings option as per [RFC 0042]
and deprecates other options that were previously used to generate
configuration file.
In addition to that, we also place the configuration file under
environment.etc to allow reloading configuration without service
restart.
[RFC 0042]: https://github.com/NixOS/rfcs/blob/master/rfcs/0042-config-option.md
msmtpq patches had to be recreated:
- removal of the executable check and addition of systemd logging were
kept and split into two patches.
- renaming of queue and log files was removed as the upstream script had
renamed these to add the `MSMTPQ_` prefix (noted as a backwards
incompatible change).
*compressDrv* compresses files in a given derivation.
*compressDrvWeb* compresses a derivation for a loosely-defined
pre-compressed "web server" usage.
This intends to replace the `passthru.data-compressed` derivations that
have accumulated in nixpkgs with something more reusable.
* buildkite-agent: 3.59.0 -> 3.76.1
* nixos/buildkite-agent: put each agent in its own private /tmp
Workaround for https://github.com/buildkite/agent/issues/2916, but
probably still a good idea.
This is a breaking change, requiring users of `featureGates` to change
from a `listOf str` to `attrsOf bool`.
Before:
```nix
featureGates = [ "EphemeralContainers" ];
extraOpts = pkgs.lib.concatStringsSep " " (
[
"--container-runtime=remote"
''--feature-gates="CSIMigration=false"''
});
```
After:
```nix
featureGates = {EphemeralContainers = true; CSIMigration=false;};
```
This is much nicer, and sets us up for later work of migrating to
configuration files for other services, like e.g. has been happening
with kubelet (see: #290119).
Signed-off-by: Christina Sørensen <christina@cafkafk.com>
This adds migration instructions for the removed global shared instance
configuration of fcgiwrap.
Adding those explicit messages to the previous options requires moving
the newly defined options from `services.fcgiwrap.*` to
`services.fcgiwrap.instances.*` due to an option namespace clash.
`mkRenamedOptionModule` was not used because the previous options do
not directly map to the new ones. In particular, `user` and `group`
were described as setting the socket's permission, but were actually
setting the process' running user.
Co-authored-by: Minijackson <minijackson@riseup.net>
Adds a module for rathole package. The package itself
and this module is very similar to frp, so the options
and tests are not very far off from those for frp.
Otherwise, the empty path in `nix.conf` takes precedence over `NIX_PATH`,
and by extension the `nix.nixPath` configuration option.
Introduced in 61afc4d166.
Upgrade default postgresql for stateVersion >=24.11.
This also rebuilds all packages linking against `libpq.so` to use
postgresql 16.
After re-reading https://www.postgresql.org/docs/16/release-16.html
I don't see any major risks about doing that.
This is a full rewrite independent of the previously removed cryptpad
module, managing cryptpad's config in RFC0042 along with a shiny test.
Upstream cryptpad provides two nginx configs, with many optimizations
and complex settings; this uses the easier variant for now but
improvements (e.g. serving blocks and js files directly through nginx)
should be possible with a bit of work and care about http headers.
the /checkup page of cryptpad passes all tests except HSTS, we don't
seem to have any nginx config with HSTS enabled in nixpkgs so leave this
as is for now.
Co-authored-by: Pol Dellaiera <pol.dellaiera@protonmail.com>
Co-authored-by: Michael Smith <shmitty@protonmail.com>
`SECURITY_DMESG_RESTRICT` is enabled by default by a lot of
other distributions for a quite a while now, NixOS is a bit of an outlier.
The main justification to enable it is that kernel log might leak kernel
pointers which can then be used by exploits to defeat KASLR (NixOS also
enables `kernel.kptr_restrict` by default since 2013).
