The guix-security mailing list is meant to be a private messaging system for embargoed (i.e. secret) security reports. Everything else should be handled in public.
Leo On Fri, Apr 4, 2025, at 12:21, John Kehayias 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). > > 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
