Security related tooling project

Security related tooling project

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

Hey,

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've been working on stuff in and around Guix for I think around 5 years
now, and in that time I have attempted some big projects, particularly
things like the Guix Data Service and Guix Build Coordinator. I've fit
all of that around a regular non-Guix related work. The support of NLNet
means I'm able to set aside more time for Guix and this work, exactly
how much more time I can dedicate is something I'm still working on.

There's a more complete description of the aims and tasks here [1], this
email is effectively the start of the work. I want to get lots of input
and feedback on the plans I've set out, as well as checking if there's
any related or overlapping work going on.

1: https://git.cbaines.net/guix/tooling-to-improve-security-and-trust/about/

I'm particularly excited by some of the initial work. I'm hoping getting
some initial version of Guix Data Service subscriptions in place will
open up loads of opportunities, and getting data about package
replacements (grafts) in to the Guix Data Service will be generally
helpful as well.

Once that's in place, I want to tackle 3 areas: security issues from a
project perspective, security issues from a individual user perspective
and prototype some enhancements to the patch review process,
specifically around security.

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)?

Please let me know if you have any comments or questions!

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Security related tooling project OFF TOPIC PRAISE

[Joshua Branson]

Christopher Baines <mail@cbaines.net> writes:

> Hey,
>
> 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.

Sweet action bro!  Way to land a guix related job for the next 8 months!
That's awesome!

>
> I've been working on stuff in and around Guix for I think around 5 years
> now, and in that time I have attempted some big projects, particularly
> things like the Guix Data Service and Guix Build Coordinator. I've fit
> all of that around a regular non-Guix related work. The support of NLNet
> means I'm able to set aside more time for Guix and this work, exactly
> how much more time I can dedicate is something I'm still working on.

I'm looking forward to the tooling that you'll develop!  I've heard cool
things about the Guix Data Service and the Build Coordinator.  I've no
doubt that your security related tooling will be just as fantastic!

>
> There's a more complete description of the aims and tasks here [1], this
> email is effectively the start of the work. I want to get lots of input
> and feedback on the plans I've set out, as well as checking if there's
> any related or overlapping work going on.
>
> 1: https://git.cbaines.net/guix/tooling-to-improve-security-and-trust/about/

Are you using guix system to serve the above link?  I didn't realize
that gitolite could render a README document so well!

>
> Please let me know if you have any comments or questions!
>
> Thanks,
>
> Chris

It'll be interesting when people stop saying that "OpenBSD" has fixed
that security issue, and instead they say guix system fixed that
security flaw.  :)

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Re: Security related tooling project

[Léo Le Bouter]

[-- Attachment #1: Type: text/plain, Size: 3242 bytes --]

On Sat, 2021-04-03 at 11:41 +0100, Christopher Baines wrote:
> Hey,
> 
> 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've been working on stuff in and around Guix for I think around 5
> years
> now, and in that time I have attempted some big projects,
> particularly
> things like the Guix Data Service and Guix Build Coordinator. I've
> fit
> all of that around a regular non-Guix related work. The support of
> NLNet
> means I'm able to set aside more time for Guix and this work, exactly
> how much more time I can dedicate is something I'm still working on.
> 
> There's a more complete description of the aims and tasks here [1],
> this
> email is effectively the start of the work. I want to get lots of
> input
> and feedback on the plans I've set out, as well as checking if
> there's
> any related or overlapping work going on.
> 
> 1: 
> https://git.cbaines.net/guix/tooling-to-improve-security-and-trust/about/
> 
> I'm particularly excited by some of the initial work. I'm hoping
> getting
> some initial version of Guix Data Service subscriptions in place will
> open up loads of opportunities, and getting data about package
> replacements (grafts) in to the Guix Data Service will be generally
> helpful as well.
> 
> Once that's in place, I want to tackle 3 areas: security issues from
> a
> project perspective, security issues from a individual user
> perspective
> and prototype some enhancements to the patch review process,
> specifically around security.
> 
> 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)?
> 
> Please let me know if you have any comments or questions!
> 
> Thanks,
> 
> Chris

That's really really awesome Chris! I especially like that also users
are invited to particpate in the process and the information is shared
there as well!

If I have a comment about the CVE mechanism is that it seems CPE
vendor/name labeling isnt done well or not fast enough in practice,
most flaws I fix they do not have CPE name and vendor specified. So I
wonder how to automate recognition of them here. I believe some could
try and parse the summary with natural language analysis but that also
seems quite imprecise.

Léo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Security related tooling project

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

Christopher Baines <mail@cbaines.net> writes:

> 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)?
>
> Please let me know if you have any comments or questions!

I think this is a great plan! The last two points in particular are
particularly useful, I think.

Everyone needs security.  I think Guix is in a unique position where it
is so easy to modify packages that (in theory, at least) anyone who
cares can figure out how to submit a change to upgrade and fix security
vulnerabilities.

People and companies are more likely to go out of their way to fix
packages they care about.  Therefore, making it easy to identify
vulnerabilities in specifically the packages they care about, and making
it easier to get involved in the community to fix them, are important
goals.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: Security related tooling project OFF TOPIC PRAISE

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 2499 bytes --]


Joshua Branson <jbranso@dismail.de> writes:

> Christopher Baines <mail@cbaines.net> writes:
>
>> Hey,
>>
>> 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.
>
> Sweet action bro!  Way to land a guix related job for the next 8 months!
> That's awesome!

Well, not quite a job, but some financial support specifically to work
on Guix, which is still good!

>> I've been working on stuff in and around Guix for I think around 5 years
>> now, and in that time I have attempted some big projects, particularly
>> things like the Guix Data Service and Guix Build Coordinator. I've fit
>> all of that around a regular non-Guix related work. The support of NLNet
>> means I'm able to set aside more time for Guix and this work, exactly
>> how much more time I can dedicate is something I'm still working on.
>
> I'm looking forward to the tooling that you'll develop!  I've heard cool
> things about the Guix Data Service and the Build Coordinator.  I've no
> doubt that your security related tooling will be just as fantastic!

Thanks!

>> There's a more complete description of the aims and tasks here [1], this
>> email is effectively the start of the work. I want to get lots of input
>> and feedback on the plans I've set out, as well as checking if there's
>> any related or overlapping work going on.
>>
>> 1: https://git.cbaines.net/guix/tooling-to-improve-security-and-trust/about/
>
> Are you using guix system to serve the above link?  I didn't realize
> that gitolite could render a README document so well!

I am, it's cgit which is doing the web stuff, and it can process the
about content through a script, which is what I'm doing [1]. I'm using a
script which either passes it through Emacs if it's an org file, and
otherwise uses the about-formatting.sh script included in cgit.

1: https://paste.debian.net/plain/1192275

>> Please let me know if you have any comments or questions!
>>
>> Thanks,
>>
>> Chris
>
> It'll be interesting when people stop saying that "OpenBSD" has fixed
> that security issue, and instead they say guix system fixed that
> security flaw.  :)

:)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Security related tooling project

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]


Léo Le Bouter <lle-bout@zaclys.net> writes:

> On Sat, 2021-04-03 at 11:41 +0100, Christopher Baines wrote:
>> Please let me know if you have any comments or questions!
>
> That's really really awesome Chris! I especially like that also users
> are invited to particpate in the process and the information is shared
> there as well!

Cool, and yeah, I think users of Guix do have some needs around security
and how they use Guix, but I don't yet have a clear picture of them. I
want to try and work on figuring this out though!

> If I have a comment about the CVE mechanism is that it seems CPE
> vendor/name labeling isnt done well or not fast enough in practice,
> most flaws I fix they do not have CPE name and vendor specified. So I
> wonder how to automate recognition of them here. I believe some could
> try and parse the summary with natural language analysis but that also
> seems quite imprecise.

Right, that definitely seems like something to work on.

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Security related tooling project

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]


Chris Marusich <cmmarusich@gmail.com> writes:

> Christopher Baines <mail@cbaines.net> writes:
>
>> 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)?
>>
>> Please let me know if you have any comments or questions!
>
> I think this is a great plan! The last two points in particular are
> particularly useful, I think.
>
> Everyone needs security.  I think Guix is in a unique position where it
> is so easy to modify packages that (in theory, at least) anyone who
> cares can figure out how to submit a change to upgrade and fix security
> vulnerabilities.
>
> People and companies are more likely to go out of their way to fix
> packages they care about.  Therefore, making it easy to identify
> vulnerabilities in specifically the packages they care about, and making
> it easier to get involved in the community to fix them, are important
> goals.

Cool :) While it's not directly security related, I really want the
subscriptions functionality I'm planning to work on to be done so that
people can subscribe to things related to the packages they use, like
new versions becoming available, or the build breaking for example, as
that might help people stay involved.

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Security related tooling project

[Xinglu Chen]

On Sun, Apr 04 2021, Christopher Baines wrote:

> Cool :) While it's not directly security related, I really want the
> subscriptions functionality I'm planning to work on to be done so that
> people can subscribe to things related to the packages they use, like
> new versions becoming available, or the build breaking for example, as
> that might help people stay involved.

A bit off-topic, but I think it would be nice if the Emails/RSS feeds
would contain more information.  Right now it just says that PACKAGE on
ARCHITECTURE is fixed/broken, and gives a URL pointing to the build job.
I think it would be useful to also show the commit (the revision and
the commit summary for some context) that caused the fix/failure, and
maybe also the time it took to build the package, plus a link to the raw
build log.

All of this sounds very exciting.  Keep up the great work!

Re: Security related tooling project OFF TOPIC PRAISE

[Joshua Branson]

Christopher Baines <mail@cbaines.net> writes:

> Joshua Branson <jbranso@dismail.de> writes:
>
>> Christopher Baines <mail@cbaines.net> writes:
>>
>>> 1: https://git.cbaines.net/guix/tooling-to-improve-security-and-trust/about/
>>
>> Are you using guix system to serve the above link?  I didn't realize
>> that gitolite could render a README document so well!
>
> I am, it's cgit which is doing the web stuff, and it can process the
> about content through a script, which is what I'm doing [1]. I'm using a
> script which either passes it through Emacs if it's an org file, and
> otherwise uses the about-formatting.sh script included in cgit.
>
> 1: https://paste.debian.net/plain/1192275

That is probably the most beautiful thing I've seen so far today!  That
is soo cool!

--
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar

Re: Security related tooling project

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 3636 bytes --]

Christopher Baines <mail@cbaines.net> writes:

> Chris Marusich <cmmarusich@gmail.com> writes:
>
>> Christopher Baines <mail@cbaines.net> writes:
>>
>>> 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)?
>>>
>>> Please let me know if you have any comments or questions!
>>
>> I think this is a great plan! The last two points in particular are
>> particularly useful, I think.
>>
>> Everyone needs security.  I think Guix is in a unique position where it
>> is so easy to modify packages that (in theory, at least) anyone who
>> cares can figure out how to submit a change to upgrade and fix security
>> vulnerabilities.
>>
>> People and companies are more likely to go out of their way to fix
>> packages they care about.  Therefore, making it easy to identify
>> vulnerabilities in specifically the packages they care about, and making
>> it easier to get involved in the community to fix them, are important
>> goals.
>
> Cool :) While it's not directly security related, I really want the
> subscriptions functionality I'm planning to work on to be done so that
> people can subscribe to things related to the packages they use, like
> new versions becoming available, or the build breaking for example, as
> that might help people stay involved.

Yes, that would be cool.  I can imagine various ways that a user could
get information like this.  For instance, just as how the news entries
tell you what's new when you "guix pull," perhaps we could add something
similar (optional?) for when you install packages, like: "Hey, I see
you're using packages Foo and Bar.  New versions are available!  They
are affected by these CVEs!  Run "guix refresh" from a checkout to try
upgrading them!" and so on.

Another option could be to add some sort of functionality to Cuirass
(does it already exist?) or the Guix Data Service which allows one to
create a custom RSS feed or atom feed or similar.  Imagine crafting a
URL that says "This is my search query - spit out an RSS feed showing me
what's going on recently with these packages".  I know some wiki-style
software features something like this, where you can encode a search
query into a URL, and it will spit out a dynamically created RSS feed.

Another idea is: just as "guix lint" can report CVEs, perhaps the code
could be adapted to enable a command that lets you lint an
already-installed profile to inform you about what CVEs or updates are
available for that specific collection of installed software.  This
could be used as a "security scanner", where you can "scan" some
installed profiles to see what's vulnerable on a system.  Simply keeping
the package definitions up to date is half the battle; actually
upgrading them on systems you care about is the other half...

Just some ideas.  Perhaps one resonates with you; if not, that's fine
too!  Maybe the UI is the easier part, and the mechanism of reliably
determining what has changed, what security updates are available, etc.,
is harder.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: Security related tooling project

[Ludovic Courtès]

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

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

Re: Security related tooling project

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 2433 bytes --]


Ludovic Courtès <ludo@gnu.org> writes:

> 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/
>
> [...]
n>
>> 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!

That's good to hear!

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Security related tooling project

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]


Bengt Richter <bokr@bokr.com> writes:

> 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?

That's a point to consider I think. Most of what I'm thinking about is
for published vulnerabilities in software packaged for Guix, but you
raise a valid point, so thanks for bringing it up.

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]