Hi, tl;dr:
Given that crims &co monitor developer discussions to discover unfixed vulnerabilities and clues re exploiting them, what are your ideas to avoid building a tool that can be abused? E.g., How will your tool avoid leaking info during an embargo window while trusted developers are secretly/privately fixing critical vulns? (pls excuse the top-post) -- On +2021-04-17 17:20:13 +0200, Ludovic Courtès wrote: > Hello Chris! > > Christopher Baines <m...@cbaines.net> skribis: > > > In May last year (2020), I submitted an application to NLNet. The work I > > set out wasn't something I was doing at the time, but something I hadn't > > yet found time to work on, tooling specifically around security issues. > > > > The application got a bit lost, probably somewhat down to email issues > > on my end. Anyway, things picked up again in February of this year > > (2021), and this is now something I'm looking to do roughly over the > > next 8 months. > > I’m late to the party, but I think this is excellent news! Well done! > > > 1: https://git.cbaines.net/guix/tooling-to-improve-security-and-trust/about/ > > [...] > > > In terms of looking at security from a project perspective, I'm thinking > > about these kinds of needs/questions: > > > > - What security issues affect this revision of Guix? (latest or otherwise) > > > > - How do Guix contributors find out about new security issues that > > affect Guix revisions they're interested in? > > > > From the user perspective, I want to look at things like: > > > > - How do I find out what (if any) security issues affect the software > > I'm currently running (through Guix)? > > > > - How can I get notified when a new security issue affects the software > > I'm currently running (through Guix)? > > That sounds like a great plan! > > I see several “intermediate” issues that would be super helpful for the > overall project, such as better CPE matching as Léo suggested and/or > providing CPE suggestions: <https://issues.guix.gnu.org/42299>. > > I think the Data Service is in a great position to help out > wrt. monitoring. I think it’d be nice to architect things in a way that > services enhance monitoring, but are not required for get proper > monitoring. For instance, the proposed ‘guix health’¹ can be > implemented without relying on intermediate services at all (it still > needs to rely on the NIST server, of course, but we don’t need extra > services.) > > Anyhow, it’s awesome to see you work in this area. Like Chris Marusich > wrote, Guix is in a good position to address security issues, and you’re > obviously in a very good position to know what and how to improve the > state of things in Guix, so all hail! > > Ludo’. > > ¹ https://issues.guix.gnu.org/31442 > -- Regards, Bengt Richter