[ Not relevant at this stage/phase, so this is rather that it isn’t forgotten somewhere along the line in the future. ]
tl;dr: security (updates) were always a bit of a … let’s say, rather poor-cared for thing in nixpkgs.
E.g. delroth did quite a lot on this topic and also held a talk about Remediating thousands of untracked security vulnerabilities in nixpkgs at FOSDEM this year, just to give one good example.
This is certainly something that can be improved upon.
So a SIG for anything-security is very much needed I think, just like for any (bigger) project and especially for a distribution. The exact scope of its responsibilities need to be laid out detailed IMHO, which can and need to be adaptable as the project grows.
Some key responsibilities probably should be something like:
Monitoring/be part of the oss-security mailing list and eventually also its distros list, if possible?
Quick responses for vulnerable packages, providing timely updates. Most critical ones are core packages and complex applications like web browsers.
As a practical example: I maintain a Firefox fork in nixpkgs and there are quite some (unwritten) rules about them, one being e.g. that updates must be within seven days of them becoming available, to address any (potential) vulnerabilities.
Although CVEs are quite over-reaching these days, real ones need to be addressed as well. Long-term; own CNA? (see e.g. why curl became its own CNA)
Separate security contact for responsible disclosure from third-parties?
These are just some points to get started, but having a dedicated team handling this matter is important in some way or another.
Taking a look at Security Team | Nix & NixOS reinforces my feeling that NixOS security is somehow “different” - not in a way I personally prefer.
IMO a first good step could be to establish a single point of contact (especially for external communication) pattern like Debian does: Teams/Security - Debian Wiki
While their security page (Debian -- Security Information) looks minimal it IMO contains the most relevant information to get started.
I’d be happy to if and when we come to leader elections. But that is on hold for now anyway until that position gets better defined, so that’s fine for now, thanks!
Yep, I would have taken the Debian security as an example/base for us too, since their process is pretty well defined and works, as they really take that seriously.
As soon as the source for aux.computer comes available, I can draft up a first security contact page + extras as needed.
Agreed. Also the Gentoo Sec Team came to my mind after writing my previous post. Generally speaking I do prefer leaning on established practices.
Yeah great idea! Wanna do this together? From your profile I assume you’re living in Europe? I’m on Portugal (UTC+1) time and in the afternoons until late evenings.
