Re: Security related tooling project

[Bengt Richter]

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 <mail@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