[-- 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 --]
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
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
[-- 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 --]
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!
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
[-- 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 --]
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
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
[-- 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 --]
[-- 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 --]