(~10 years NixOS user, and committer.)
It depends.
Mostly on how much rebuilding it needs (e.g. if it's a "leaf" package, or one many packages depend on).
The merging of security fixes is usually very good, also because it is so easy for anyone to just make a PR.
The security team also seems pretty competent and fast.
As a sibling commenter says, it is also extremely easy to just apply patches to your own system in general, usually with a few line of easy code max. So you can fix systems without dependence on distro maintainers.
In contrast to e.g. patching a `.deb`, you can declare the code such that the patch will still be used even if the distro releases a new package; you can carry the patch forward, and don't need to choose between {not having the patch because the distro lacks it} and {not having future security fixes because you pinned your custom .deb version}. NixOS will rebuild any future update, applying your patch to it. That's a big benefit, because it makes "out-of-tree" custom patches very maintainable.
Due to declarativeness, you can easily roll out your fix on lots of machines.
Also, the "SBOM" (software bill of materials) part is quite good in NixOS. It's very easy to determine which package uses what dependencies.
The only real drawback is CI build time when a high-dependency package needs fixing.
Due to the way Nix works with its immutable hash DAG of package dependencies, a package change will trigger a full rebuild of all packages that recursively depend on it.
For example, if you change 1 line in glibc, or libpng, or curl, or (recently) brotli, the entire distro needs to be recompiled from source ("rebuild the world"). Some of the packages, such as Chromium, can take many hours to rebuild individually. Rebuilding all-of-NixOS can take days.
In distros that can mutate packages without triggering dependency rebuilds, updating 1 line in e.g. glibc, will only rebuild that package, allowing to theoretically distribute such security updates within minutes (if done, see Ubuntu counter-example).
The mass-rebuilding is done by NixOS's binary-cache build farm. A new NixOS update is generally only released once the build farm has fully built all dependents.
(One can also opt into a "small" channel that releases as soon as only a few core packages are built, which gives you security updates faster for those. But if you do that, your computer will next start compile all huge packages such as Chromium, in parallel to the NixOS build farm already doing that. So usually people don't.)
For the recent brotli CVE-2026-111497, the timline was:
2026-10-21 node.js releases its fix for node2shell (caused by brotli)
2026-10-21 19:27 https://github.com/google/brotli/releases#release-v1.2.1
2026-10-22 brotli CVE-2026-111497 gets published
2026-10-22 06:51 PR "brotli 1.2.1" https://github.com/NixOS/nixpkgs/pull/577208
2026-10-22 08:25 PR merged to "staging" that will become rolling "nixos-unstable" in the future
2026-10-23 created https://tracker.security.nixos.org/suggestions/by-id/60353
2026-10-23 created https://github.com/nixos/nixpkgs/issues/577796
2026-10-28 CI has built a nixos-26.05 update that includes it:
https://hydra.nixos.org/build/351243680
This is the point where users can install it.
2026-11-02 CI for rolling-release nixos-unstable is still not built, 2 weeks later:
https://github.com/NixOS/nixpkgs/pull/577208#issuecomment-6573335016
So in summary:
The PR got made within 7 h
Review and merge happened within 2 h
CI took additional 6 days for stable NixOS 26.05
CI for rolling nixos-unstable is still not finished after 10 days post-merge
For our startup, I rebuilt the slice of the world we use on a 16-core CPU within a day or so, without waiting on the NixOS build farm to build all of NixOS, so we got the update significantly faster.
Also note that just patching a library in your distro is often not enough. For brotli, lots of upstream package vendor brotli's code. NixOS contributors seem to be quite good at looking at underlying issues, e.g. there's this issue "Tracking vendored Brotli decoders" (nixpkgs#578375) to track that. I am not aware of other distros making such efforts.
Thus:
In NixOS, security updates are great and fast for leaf packages such as the kernel, but can be slow for many-dependents packages. Much of that can be mitigated by building things yourself, which is easy.
Hope this helps.
SC member allow for a platform for the Nix community to state their thoughts about reinstating @domenkozar commit bit, and sin conjuring is exactly what they are doing.
Almost every person speaking out has said similarly inflammatory statements.
nixpkgs-committers#162
13 likes · 483 views
Just another day of the "anti-fasch" mentally-ill trying to remove previous pillars of the Nix community. Naming this the "Great woke replacement".
nixpkgs-committers#162
25 likes · 656 views
Feedback requested on nixpkgs PR #581542 ("CONTRIBUTING: ban most LLM prose")
I have made a proposal that would ban LLM output from prose in PRs and commit messages (subject to some exceptions).
Posting here for increased visibility; please leave all comments/feedback/suggestions on the PR itself:
nixpkgs#581542
18 likes
:obsidian: #Obsidian PSA:
If anyone is getting a blank screen on obsidian startup on linux, the fix is to clear obsidian's cache: nixpkgs#578970
2 likes · 2 reposts
finally, I will be able to compile things without incurring a huge performance penalty during the linking stage when using a nix flake
nixpkgs#579802
6 likes · 1 repost
This post is a reaction to the 3rd person asking me for patterns on _how_ to use Nixtamal with NixOS configurations—specifically those coming from flakes looking to adopt system.nix + overlays. The cookbook is for patterns with the input pinner.
1. Yep, I have as well… but I have seen many places that if you are using a configuration.nix file, it’s you can’t put it it version control (which is almost certainly why the Nixmap project shows as much)
2. Yes. there are several input pinners—I made a comparison table to the best of by knowledge of the common ones. None check all boxes.
3. Flakes aren’t stable. The API has drifted, the manifest has no version, & there are 3 different flake implementations now (NixCpp, Lix, Determinate Nix). Folks are free to try them out, but a) they shouldn’t act like it’s stable b) without much effort you can get backwards compatibility without adding dependencies if using the patterns here. I was wanting to get a piece out that showed these patterns on how a stable Nix system would be consuming projects to help both system.nix adopters & upstream project think about compatibility (slapping flake-compat isn’t the right solution).
The goal isn’t to consume or generate manifest files from Nix so probably not a huge issue, but there is a KDL feature request & a pull request. KDL is used in Zellij, Niri, Miso, & even the System76 scheduler to name a few.
> I'm happy to switch off flakes if I'm offered something better.
That would be the goal, but Nixtamal only handles inputs. You’d need another project such as Nilla (not affiliated, not an endorsement) if you want the schema side. The problem is baking this buggy kitchen sink into the binary means its a) hard to iterate & b) hard for competition when folks say an experimental feature they can flip on. There are some neat ideas out there—& the ones that aren’t flakes all tend to be pluggable, but flakes owning a project in the way folks use it it practice, make it very difficult or impossible or expensive to get what could/should otherwise be classic Nix expressions. This ends up leading to tight coupling that’s hard to use at scale which leaves a sour taste in folks’ mouth about Nix. A lot of $BIG_TECH, even when using flakes set flake = false; on all inputs to get back control & lower complexity which also requires stable-friendly code.
(I’m also proud of handcoding up all the stuff to get Asciinema + Webm (AV1) video + GIF fallbacks for <noscript>… it was a lot of things to learn & plumb)
4 points
purefetch: Nix profile package counts and a configurable terminal banner
Processing img i1d2kma3meyh1...
I maintain purefetch, a system information tool for Linux and macOS written in Rust without crate dependencies. I use it as a configurable terminal banner on NixOS.
Its Nix package count covers versioned runtime outputs in active system, default and user profile closures, including dependencies. It excludes documentation and development outputs and avoids counting profiles twice when they resolve to the same store path.
The module list and ordering are configurable; you can supply your own logo or add rows from commands. ZFS roots report whole-pool usage. External probes, including Nix queries, have a two-second deadline.
You can try the tagged release with:
nix run github:ooonea/purefetch/v0.2.7
The flake exports packages and an overlay for x86_64-linux, aarch64-linux, aarch64-darwin and x86_64-darwin. The nixpkgs addition is still an open PR: nixpkgs#545037
Source and configuration: ooonea/purefetch
The program is MIT OR Apache-2.0, with separate terms for bundled artwork. The project was developed with substantial Claude Code and OpenAI Codex assistance under my direction; this post was also drafted with AI assistance.
Tested successfully on a physical Apple M1 Mac running Fedora Asahi Remix 44 with purefetch 0.2.7, including correct automatic selection of the Asahi logo.
3 points
For uv in particular: nixpkgs#579622 is currently making its way to 26.05 (and in fact, is already in 26.05-small).
The updates couldn't be backported because of backcompat concerns (and if the above PR weren't merged instead, I imagine/hope we would have just written our own patch to bump the roots).
5 points
> Oh, you have a detailed package inventory or, dare I say it, SBOMs? That's really nice. Do show me where that lists the various vendored or hard-coded CA trust bundles. Yeah, I didn't think so.3
Interesting the Author linked to nixos issue here, if you follow that link you end up at nix-cacert-scan, a tool that scans your system nix closure for packages that contain TLS certs, and from there you can find out why any package includes it and add overlays to patch any such packages, even add automation to your pipeline to detect compromised certs throughout your whole system.
I think this is one of the strengths of nixos, it is a pity it isn't more focused on security, missing things like signed commits on nixpkgs, built-in kernel hardening, musl builds. nixpkgs is also so huge and interweaved, it would be nice if a secure core was separated out (before someone commercial does it.)
28 points
Mentions
(~10 years NixOS user, and committer.) It depends. Mostly on how much rebuilding it needs (e.g. if it's a "leaf" package, or one many packages depend on). The merging of security fixes is usually very good, also because it is so easy for anyone to just make a PR. The security team also seems pretty competent and fast. As a sibling commenter says, it is also extremely easy to just apply patches to your own system in general, usually with a few line of easy code max. So you can fix systems without dependence on distro maintainers. In contrast to e.g. patching a `.deb`, you can declare the code such that the patch will still be used even if the distro releases a new package; you can carry the patch forward, and don't need to choose between {not having the patch because the distro lacks it} and {not having future security fixes because you pinned your custom .deb version}. NixOS will rebuild any future update, applying your patch to it. That's a big benefit, because it makes "out-of-tree" custom patches very maintainable. Due to declarativeness, you can easily roll out your fix on lots of machines. Also, the "SBOM" (software bill of materials) part is quite good in NixOS. It's very easy to determine which package uses what dependencies. The only real drawback is CI build time when a high-dependency package needs fixing. Due to the way Nix works with its immutable hash DAG of package dependencies, a package change will trigger a full rebuild of all packages that recursively depend on it. For example, if you change 1 line in glibc, or libpng, or curl, or (recently) brotli, the entire distro needs to be recompiled from source ("rebuild the world"). Some of the packages, such as Chromium, can take many hours to rebuild individually. Rebuilding all-of-NixOS can take days. In distros that can mutate packages without triggering dependency rebuilds, updating 1 line in e.g. glibc, will only rebuild that package, allowing to theoretically distribute such security updates within minutes (if done, see Ubuntu counter-example). The mass-rebuilding is done by NixOS's binary-cache build farm. A new NixOS update is generally only released once the build farm has fully built all dependents. (One can also opt into a "small" channel that releases as soon as only a few core packages are built, which gives you security updates faster for those. But if you do that, your computer will next start compile all huge packages such as Chromium, in parallel to the NixOS build farm already doing that. So usually people don't.) For the recent brotli CVE-2026-111497, the timline was: 2026-10-21 node.js releases its fix for node2shell (caused by brotli) 2026-10-21 19:27 https://github.com/google/brotli/releases#release-v1.2.1 2026-10-22 brotli CVE-2026-111497 gets published 2026-10-22 06:51 PR "brotli 1.2.1" https://github.com/NixOS/nixpkgs/pull/577208 2026-10-22 08:25 PR merged to "staging" that will become rolling "nixos-unstable" in the future 2026-10-23 created https://tracker.security.nixos.org/suggestions/by-id/60353 2026-10-23 created https://github.com/nixos/nixpkgs/issues/577796 2026-10-28 CI has built a nixos-26.05 update that includes it: https://hydra.nixos.org/build/351243680 This is the point where users can install it. 2026-11-02 CI for rolling-release nixos-unstable is still not built, 2 weeks later: https://github.com/NixOS/nixpkgs/pull/577208#issuecomment-6573335016 So in summary: The PR got made within 7 h Review and merge happened within 2 h CI took additional 6 days for stable NixOS 26.05 CI for rolling nixos-unstable is still not finished after 10 days post-merge For our startup, I rebuilt the slice of the world we use on a 16-core CPU within a day or so, without waiting on the NixOS build farm to build all of NixOS, so we got the update significantly faster. Also note that just patching a library in your distro is often not enough. For brotli, lots of upstream package vendor brotli's code. NixOS contributors seem to be quite good at looking at underlying issues, e.g. there's this issue "Tracking vendored Brotli decoders" (nixpkgs#578375) to track that. I am not aware of other distros making such efforts. Thus: In NixOS, security updates are great and fast for leaf packages such as the kernel, but can be slow for many-dependents packages. Much of that can be mitigated by building things yourself, which is easy. Hope this helps.
SC member allow for a platform for the Nix community to state their thoughts about reinstating @domenkozar commit bit, and sin conjuring is exactly what they are doing. Almost every person speaking out has said similarly inflammatory statements. nixpkgs-committers#162
Just another day of the "anti-fasch" mentally-ill trying to remove previous pillars of the Nix community. Naming this the "Great woke replacement". nixpkgs-committers#162
Feedback requested on nixpkgs PR #581542 ("CONTRIBUTING: ban most LLM prose") I have made a proposal that would ban LLM output from prose in PRs and commit messages (subject to some exceptions). Posting here for increased visibility; please leave all comments/feedback/suggestions on the PR itself: nixpkgs#581542
:obsidian: #Obsidian PSA: If anyone is getting a blank screen on obsidian startup on linux, the fix is to clear obsidian's cache: nixpkgs#578970
finally, I will be able to compile things without incurring a huge performance penalty during the linking stage when using a nix flake nixpkgs#579802
This post is a reaction to the 3rd person asking me for patterns on _how_ to use Nixtamal with NixOS configurations—specifically those coming from flakes looking to adopt system.nix + overlays. The cookbook is for patterns with the input pinner. 1. Yep, I have as well… but I have seen many places that if you are using a configuration.nix file, it’s you can’t put it it version control (which is almost certainly why the Nixmap project shows as much) 2. Yes. there are several input pinners—I made a comparison table to the best of by knowledge of the common ones. None check all boxes. 3. Flakes aren’t stable. The API has drifted, the manifest has no version, & there are 3 different flake implementations now (NixCpp, Lix, Determinate Nix). Folks are free to try them out, but a) they shouldn’t act like it’s stable b) without much effort you can get backwards compatibility without adding dependencies if using the patterns here. I was wanting to get a piece out that showed these patterns on how a stable Nix system would be consuming projects to help both system.nix adopters & upstream project think about compatibility (slapping flake-compat isn’t the right solution). The goal isn’t to consume or generate manifest files from Nix so probably not a huge issue, but there is a KDL feature request & a pull request. KDL is used in Zellij, Niri, Miso, & even the System76 scheduler to name a few. > I'm happy to switch off flakes if I'm offered something better. That would be the goal, but Nixtamal only handles inputs. You’d need another project such as Nilla (not affiliated, not an endorsement) if you want the schema side. The problem is baking this buggy kitchen sink into the binary means its a) hard to iterate & b) hard for competition when folks say an experimental feature they can flip on. There are some neat ideas out there—& the ones that aren’t flakes all tend to be pluggable, but flakes owning a project in the way folks use it it practice, make it very difficult or impossible or expensive to get what could/should otherwise be classic Nix expressions. This ends up leading to tight coupling that’s hard to use at scale which leaves a sour taste in folks’ mouth about Nix. A lot of $BIG_TECH, even when using flakes set flake = false; on all inputs to get back control & lower complexity which also requires stable-friendly code. (I’m also proud of handcoding up all the stuff to get Asciinema + Webm (AV1) video + GIF fallbacks for <noscript>… it was a lot of things to learn & plumb)
purefetch: Nix profile package counts and a configurable terminal banner Processing img i1d2kma3meyh1... I maintain purefetch, a system information tool for Linux and macOS written in Rust without crate dependencies. I use it as a configurable terminal banner on NixOS. Its Nix package count covers versioned runtime outputs in active system, default and user profile closures, including dependencies. It excludes documentation and development outputs and avoids counting profiles twice when they resolve to the same store path. The module list and ordering are configurable; you can supply your own logo or add rows from commands. ZFS roots report whole-pool usage. External probes, including Nix queries, have a two-second deadline. You can try the tagged release with: nix run github:ooonea/purefetch/v0.2.7 The flake exports packages and an overlay for x86_64-linux, aarch64-linux, aarch64-darwin and x86_64-darwin. The nixpkgs addition is still an open PR: nixpkgs#545037 Source and configuration: ooonea/purefetch The program is MIT OR Apache-2.0, with separate terms for bundled artwork. The project was developed with substantial Claude Code and OpenAI Codex assistance under my direction; this post was also drafted with AI assistance. Tested successfully on a physical Apple M1 Mac running Fedora Asahi Remix 44 with purefetch 0.2.7, including correct automatic selection of the Asahi logo.
For uv in particular: nixpkgs#579622 is currently making its way to 26.05 (and in fact, is already in 26.05-small). The updates couldn't be backported because of backcompat concerns (and if the above PR weren't merged instead, I imagine/hope we would have just written our own patch to bump the roots).
> Oh, you have a detailed package inventory or, dare I say it, SBOMs? That's really nice. Do show me where that lists the various vendored or hard-coded CA trust bundles. Yeah, I didn't think so.3 Interesting the Author linked to nixos issue here, if you follow that link you end up at nix-cacert-scan, a tool that scans your system nix closure for packages that contain TLS certs, and from there you can find out why any package includes it and add overlays to patch any such packages, even add automation to your pipeline to detect compromised certs throughout your whole system. I think this is one of the strengths of nixos, it is a pity it isn't more focused on security, missing things like signed commits on nixpkgs, built-in kernel hardening, musl builds. nixpkgs is also so huge and interweaved, it would be nice if a secure core was separated out (before someone commercial does it.)