noXLibs is an advanced option for advanced users which know how to recognize and debug build failures which might be caused by the added overlays.
The minimal profile should be minimal but also save to use for many people and not cause build failures in packages it really shouldn't.
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.)
Untrimmed mbrola-voices is leaking into the installer images again.
Instead of trying to manually squash every path it could possibly
leak through, use a very big hammer.
This reduces the size of mbrola-voices by 387M (647M -> 260M) for all
installers that ship with speechd, to make sure that they fit the output
limits of hydra while not compromising too much on accessbility.
Co-authored-by: Martin Weinelt <hexa@darmstadt.ccc.de>
and turn it in to a list.
The current setting of system.forbiddenDependenciesRegex is a string, meaning only one such regex as any additional setting would result in conflicts.
As maintainers have already started using this setting eg. in profiles, it would be good if this setting would accept a list of regex to allow the end
user to make use of it in addition to package maintainers.
these changes were generated with nixq 0.0.2, by running
nixq ">> lib.mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> Inherit >> mdDoc[remove]" --batchmode nixos/**.nix
two mentions of the mdDoc function remain in nixos/, both of which
are inside of comments.
Since lib.mdDoc is already defined as just id, this commit is a no-op as
far as Nix (and the built manual) is concerned.
For example, if the user decided to ctrl-c upon getting the sudo
password prompt, the script previously continued on to start the VM, but
that should not be the case.
Borrowing from here to match hardened profile with more recent kernels:
* https://madaidans-insecurities.github.io/guides/linux-hardening.html?#boot-parameters
* https://github.com/a13xp0p0v/kernel-hardening-checker/
Removed "slub_debug" as that option disables kernel memory address
hashing. You also see a big warning about this in the dmesg:
"This system shows unhashed kernel memory addresses via the console, logs, and other interfaces."
"init_on_alloc=1" and "init_on_free=1" zeroes all SLAB and SLUB allocations. Introduced in 6471384af2a6530696fc0203bafe4de41a23c9ef. Also the default for the Android Google kernel btw. It is on by default through the KConfig.
"slab_nomerge" prevents the merging of slab/slub caches. These are
effectively slab/slub pools.
"LEGACY_VSYSCALL_NONE" disables the older vsyscall mechanic that relies on
static address. It got superseeded by vdsos a decade ago. Read some
LWN.net to learn more ;)
"debugfs=off" I'm sure there are some few userspace programs that rely on
debugfs, but they shouldn't.
Most other things mentioned on the blog where already the default on a
running machine or may not be applicable.
Most other Kconfigs changes come from the kernel hardening checker and
were added, when they were not applied to the kernel already.
Unsure about CONFIG_STATIC_USERMODEHELPER. Would need testing.
Polkit enables running 'reboot' and 'poweroff' in the installer without
being root, and non-root is the default login for a few NixOS releases
now.
There's no size increase in the minimal ISO:
$ git checkout nixpkgs-unstable
$ nix-build -A config.system.build.isoImage -I nixos-config=nixos/modules/installer/cd-dvd/installation-cd-minimal.nix nixos/default.nix && du -sc ./result/iso/*.iso
/nix/store/bfvbvrrqjmnqqhyqyxc0w32gagdz2rya-nixos-24.05.git.1149dab64e7-x86_64-linux.iso
998404 ./result/iso/nixos-24.05.git.1149dab64e7-x86_64-linux.iso
998404 total
$ git checkout THIS_COMMIT
$ nix-build -A config.system.build.isoImage -I nixos-config=nixos/modules/installer/cd-dvd/installation-cd-minimal.nix nixos/default.nix && du -sc ./result/iso/*.iso
/nix/store/l9x9rwlvfddnri70h1ifx865q0cvka5l-nixos-24.05.git.1149dab64e7-x86_64-linux.iso
998404 ./result/iso/nixos-24.05.git.1149dab64e7-x86_64-linux.iso
998404 total
A remote builder does not need to evaluate anything, so let's trim
it down to (eventually) save some space, and make the purpose of
the builder clear.
Users should evaluate on the host instead.
Yama is a LSM which restricts debugging. This prevents processes from
snooping on another. It can be easily disabled with sysctl.
This was initially included in #14392 and disabled by default by
86721a5f78.
This has been part of the hardened configuration, but many other distros
ship this for quite some time (Ubuntu for about ten years), so I'd say
it might make sense to enable this per default.
I chose not to do nixos.{config, options} because that would make it
look too much like a configuration object, which it is not.
A configuration object I would define as for example the result of
calling NixOS, an attrset with `_type = "configuration";`.
Recreating a configuration object without evalModules is quite
feasible but not guaranteed to be correct, and not maintainable.
For non-interactive installation it's quite handy to be able to nix copy additional dependencies to the system.
While this is possible for the root user, we cannot easily ssh into it, as we don't allow root login with a password.
By making nixos a trusted user, we can do "passwd && sudo systemctl start sshd" and than run nixos-anywhere
