On 2025-04-04 16:21, John Kehayias via "Development of GNU Guix and the GNU System distribution." wrote:
> 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). Yes, I meant package-level CVEs. I'm not qualified enough to help on Guix internal CVEs. > 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. Yes, but a CVE can happen for a package after submission or review, that's why I think such a job could be helpful in the middle term. I think we can start by focussing first on fixing existing CVEs. WDYT about : 1) Reviewing / merging 76819 (adding package properties to better match CVEs to packages in Guix) 2) Run a system-level guix lint -c cve to list/prioritize/organize the work on existing CVEs. 3) After most existing CVEs are fixed, then try to implement our daily automatic script/webhook/whatever to get notified when a CVE is spotted among guix packages. This way even when it's a "false alarm" (bad cpe-name etc), we can simply edit package-properties to get gradually better matches on what is relevant and what is not. Hopefully in the long term, we can achieve some workflow like CVE found with fix -> guix security team notified -> quickfix with graft if necessary -> CVE fixed ! within a few days It's trickier when the CVE is released with no known patch, but at least there Guix would not lag behind any other distribution on security. > 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. I think team-like cc is a good idea. > 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. I also agree on the ungrafting part, I like the idea! -- Best regards, Nicolas Graves
