I found myself more confident having my flakes given another input of nixpkgs-small besides the nixpkgs.
So I am now pulling my kernel build from -small and want to do that with as much packages as possible, especially those that are a security concern as my browser is.
So there would be at least two questions I got to think about:
is there an easy way to list packages that are provided in the build cache of the -small branch?
can I default all packages in my flake to be pulled from -small and fallback to nixpkgs if they’re not cached there? Looks kinda proxy’ish
If your threat model is this severe, you might as well pull from master and build everything yourself. -small is not useful for a desktop system, and more importantly, none of the tests get built, so you might end up with a broken system (same issue as with master).
The installer boot is part of it, which is probably the most important test, as well as apparently emacs. The small channel package choices are a little arbitrary.
Assuming you’re on stable (and therefore updates here are compatible), I actually think grabbing specifically the kernel from the small channel seems perfectly fine given this, especially since the kernel won’t come with a big closure (though you are paying that extra 500MB for another nixpkgs checkout, likely several times over). With pretty much any other package you get the huge added closure for no practical gain, even if it is tested.
And yeah, forget about browsers in the small channel, not having to waste time building browsers is kind of the point of the small channel, those are the largest builds in pretty much any distro. This is not intended for desktop use cases, no realistic desktop threat model is going to avoid zero days anyway.
IMHO openssh would be another candidate to have updated ASAP if it’s facing public internet?
For what reason would you think its going to pull a huge closure? To me it looks like another exception about closure sizes.
BTW: this request is purely academic and not for any real threat related reasons.
Because alongside anything that requires libc at runtime you’re pulling an extra stdenv.
opensslis part of the installer image so it’s available, but it depends on the stdenv so you’re pulling in a second stdenv. The kernel, on account of being the kernel, does not require a stdenv.
But you’re taking away the wrong point, I’m just saying that the small channels are more usable than claimed, not that actually doing so isn’t niche or makes sense from what we assume your threat model to be.
Personally, I would only temporarily switch to the small channels when a high-profile vulnerability pops up (anything relevant will be publicly posted to social media and amplified by your favorite LLM-based security firm’s marketing team), only for servers, and only if there really is no better workaround.
The small channel only gives you about a few hours to a day of extra patch speed anyway, by then you’ve either applied the workaround or you’re not actually worried about being pwned in the first place. This also only really helps with fully automated updates, which you’re realistically not going to apply to the kernel because that takes a reboot.
For all the recent kernel vulnerabilities for example just disabling module loads at runtime is both faster, easier and more generic, so you don’t have to even wait for patches unless it affects a module you actually use.
That’s not to say I think the small channels are useless, if you have spare build capacity and an instance where getting patches quickly matters, use them. If you’re thinking about browsers, however, you’re barking up the wrong tree.
“This also only really helps with fully automated updates, which you’re realistically not going to apply to the kernel because that takes a reboot.”
→ well… I guess a reboot is less of a concern to me than being nagged around with workarounds. Even with services I host. But thats something that everybody values differently depending on their business.
I had a looong story about my update philosophy here but decided to cut for brevity.
In the end the whole ecosystem is way more agile compared to microsofts patchday once a month.
About this request:
My desktop got the kernel from -small → it works, I monitor and refrain from using -small for anything else.
Yeah, this is more of a problem for servers, where the frequent downtime - and potential risk, often when nobody is even awake to fix it - of automated reboots with sufficient frequency to get any benefit from the small channel is usually unacceptable.
Assuming you don’t have load balancing and failovers, alongside complex update scheduling to ensure redundancy, of course, which is expensive and difficult for the bare-metal use cases where NixOS makes sense, but yeah, as I said, I don’t think the small channels are useless, they’re just niche.
