In this case it was announced on Discourse, but most security vulnerabilities aren’t quite so widespread and severe as to warrant sounding the alarm on that level. You could look at the 1.severity: security label on GitHub, but generally it’s safe to assume that security fixes are happening constantly all the time, and that regularly keeping up‐to‐date on a supported channel is the only reliable way to keep on top of them. It would be nice if we had some kind of security bulletin system so that people could be notified of security issues, but I don’t think the resources are there. Not all upstreams are fantastic at properly acknowledging or surfacing bug fixes that have security impact, so even with more maintainer resources there’s a limit to how much we could do in terms of backporting and notification. In non‐NixOS‐specific terms, the oss-security mailing list is a relatively central place where security vulnerabilities in FOSS software are often announced.
There’s not much we can do against breaking changes in upstream software, but I would say that NixOS stable channel updates and even the rolling‐release unstable channel are pretty good in terms of stability. The nature of configuring things in Nix makes it easier for us to surface breaking changes at the time your system configuration is built, and there is a large suite of automated QA tests exercising a fairly wide range of software that have to pass before the channels will update. For instance, those tests notified us that the functionality for running an OpenSSH server in the stage‐1 boot process was broken by the major version bump that we used to fix the issue in the unstable release, That made sure we fixed it before the update reached the fully‐tested release channels used by most users.
I personally run the unstable channel on all my systems, though it depends on whether you prefer smaller but more evenly‐distributed surprises or a whole bunch of them all at once when a new major release comes out.
I trust automatic upgrades on NixOS more than with most distributions, due to the aforementioned combination of build‐time system configuration checking, automated channel QA tests, and rollback functionality (it’s a lot better than nothing even if it’s not perfect, especially if you can set up things like ensuring your server automatically rolls back if its network configuration breaks).
If it’s viable for you to invest time in writing automated NixOS integration tests for things you care about (here’s a brief introduction), it can greatly increase the confidence you can get in updates without manual labour. Being able to script a virtual network of machines that run the services in your system configuration and check that things seem to be working correctly is a bit of a superpower (although anyone who contributes to NixOS can attest that testing things at that kind of scale does often lead to spending engineering effort on trying to fix flaky tests rather than real failures).
The support period is mentioned in the release notes for each release, but I don’t know if it’s surfaced anywhere more prominently than that. We’re less of a rolling release than Arch is, but we definitely don’t have the paid employees and corporate funding Canonical and Red Hat use to offer very‐long‐term support versions, which involve a lot of engineering effort to identify and manually backport security fixes for a wide range of software. The one month support overlap is definitely a bit of a tight upgrade window for many potential users, but it’s better for us to be realistic about what we can achieve with the resources we have than give people a false sense of security. Bugs are being addressed all the time and in the FOSS world it’s very hard to disentangle general maintenance and feature development work from security fixes.
I don’t have a particularly strong opinion about the availability of releases on the search site, honestly. In this case it seems like the worry about it disappearing led to you learning more about our update and support policies, which seems like a net good thing! But in general it would probably be fine to keep it up a bit longer, and maybe even helpful to users if we could plaster a big security warning on it. It’s partly a matter of consistency and expectations; the search is an example of something that doesn’t really require much maintenance work, but it could potentially lead to people expecting things that do. There’s also a tangible difference between the “deprecated” state where you can still expect security fixes, and the “unsupported” one where you definitely can’t.
No worries, hope you can find a setup that works for you 