Hello, (CCing some more security people)
On Fri, Apr 04, 2025 at 05:51 PM, Simon Josefsson via \"Development of GNU Guix and the GNU System distribution.\" wrote: > Nicolas Graves <ngra...@ngraves.fr> writes: > >> Hi Guix! >> >> I think one of the things where Guix could be better is security / >> ensuring CVEs are fixed quickly. >> >> In 76819 I developped some missing functionality in the CVE linter, so >> that it will be easier to get proper missing libraries. >> >> A few ideas/questions to advance on that : >> - there are still a lot of linted CVEs for toolchains (former go >> versions etc) that users should in principle not be exposed to. >> Should we handle or ignore those? I think we should definitely handle all CVEs, as best we can. Toolchain updates will be slower unfortunately, but we have grafts we can do of course (already too many). >> - Maybe having a team or a responsible person for this is a good >> idea. Do you mean for package-level CVEs and the like? We do have a security-team: <https://guix.gnu.org/en/security/> (linked from the About menu on the Guix homepage). Admittedly, we could use more people and rotate out, with some set terms. It has been mentioned before but not done. I'm on the team and we could do better. Some things take a while (though I think we have been pretty good about Guix-specific issues in the recent past), though generally it is quite low traffic. Prioritizing package updates to do CVEs can and should be done by us all though. >> - A good practice could be to setup a daily job to get notified of all >> CVEs, so that we can quickly handle them. > That does sound helpful, though also running `guix lint` on any submission or review of a patch should catch CVEs as well. A set job/notification sounds helpful. Perhaps you also meant a public security list for things like speedier review of patches with "security-updates" or CVEs listed? I'm not sure if we want that together or not with a private list for undisclosed vulnerabilities, but for sure a way to ping some extra people for such (public) security updates would be great. Presumably we can leverage what is done for CCing teams to look for those keywords and CC security? I try to keep an eye open when I can but that is no substitute. > Yes, most distributions have a special security point of contact that is > not publicly archived, to discuss ways to resolve responsible disclosure > vulnerabilities for example. Seeing some progress on this has been one > blocker for me to increase dependence on Guix for production systems. > The process doesn't have to work perfect (I don't think anyone would > suggest Debian/Fedora/Ubuntu/RHEL/etc handle security bugs perfect > either), but one important step is for the process to exist. > > /Simon Simon, do you mean there has or has not been progress? As I noted above, we do have a private security list for such things though the vast majority of CVEs tend to be for older packages we have that need to be updated. Issues specific to Guix do get emailed out and posted on the website when they are fixed/disclosed. Oh, while I'm here: we need to ungraft! I would like some sort of cadence for this, perhaps: 1. Any graft immediately has an ungraft patch applied to, say, "ungrafting-branch" or some branch focused on that. 2. This is built and merged every month (?) or once a certain number of ungrafts/package rebuilds are needed (insert favorite arbitrary number), whichever comes first. Maybe this needs a proper GCD? I think we could just try something as this is more basic build management than a change to the project, because right now we keep falling behind and easily spend more time grafting than building on user systems. John
