aboutsummaryrefslogtreecommitdiff

1. Aims

With this project, I'd aim to work on the following areas:

1.1. As a project, monitoring security issues in GNU Guix

Currently, there's some tooling (guix lint –checker=cve) to look at CVE's relevant to packages, but I'm not aware of any automated way to track and monitor for potential security issues in packages.

I want to build on the existing tooling, making it easy for anyone to see what security issues affect what Guix packages, across various revisions of Guix.

1.2. As a user of GNU Guix, monitoring and checking for security issues

As a user of Guix, there's also a lack of tooling to discover known security issues in the software provided through Guix.

I want to develop the relevant tooling so that users can easily find and monitor for security issues that specifically affect them.

1.3. Improve the patch review process to help guard against malicious code

When contributors are reviewing changes, it could be easier to look at the upstream changes, and perform some checking to guard against malicious code being distributed.

At the moment, there's very little support for doing this when reviewing patches for Guix, this isn't a challenge that needs to be completely solved, but definitely an area where value can be added.

2. Tasks

2.1. Perform initial community inquiry

As a community run free software project, this is especially important. Lots of people are more involved with these areas than me, so it's important to reach out to them and involve them in the work I'm planning.

Milestones:

  • Thread on the guix-devel mailing list about this project
  • Findings from the inquiry posted to the guix-devel mailing list

2.2. Implement initial improvements in and around the Guix Data Service

The Guix Data Service stores data about Guix, but it's not currently aware of grafts, which are an approach often used to provide security fixes to users. For the Guix Data Service to provide accurate data on potential security issues, it needs to be aware of grafts, so that it has accurate data on what packages are present at what verisons in specific revisions.

Additionally, a long planned feature of the Guix Data Service is to be able to subscribe to particular pages/bits of data, and get notifications when they change. This is an important component of using the Guix Data Service to review patches, and I see it playing an important part of responding to security issues as well.

Milestones;

  • The Guix Data Service stores when packages are replaced, including details about the replacement
  • This information is available through the web interface
  • Users can create subscriptions to data in the Guix Data Service (not all data, but at least one bit of data)

2.3. Implement security data support in the Guix Data Service

This is part of getting tooling in place so that security related issues in GNU Guix can be more methodically monitoried.

Milestones:

  • Research data sources
  • Support storing and fetching/receiving this data
  • Add support for considering this data when comparing revisions

2.4. Setup project focused security monitoring and issue tracking

There's currently some tooling for monitoring and tracking security issues, but I think there's lots of room for improvement. Making security issues more visible should mean addressing them is easier and happens faster.

Milestones:

  • Research and plan tooling implementation
  • Implement and document tooling

2.5. Research and implement user security monitoring tooling

As a user of Guix, you might want to be able to check the security status of the software you're using, or get notifications when that changes. This subtask looks at this area.

Milestones:

  • Research done regarding approach and user needs
  • Implement and document tooling

2.6. Prototype adding source diffing to the patch review tooling

Making it easy to review changes to package source materials may help patch submitters and reviewers spot security issues before they get in to Guix.

Milestones:

  • Research approaches
  • Implement prototype
  • Publish results

2.7. Prototype adding automated scanning to the patch review tooling

Reviewing source material changes with software may be a useful approach to highlighing suspicious changes for more manual review, this subtask will look at prototyping this.

Milestones:

  • Research approach and available tooling
  • Implement prototype
  • Publish results

2.8. Prototype adding automated signature checks to patch review tooling

Guix can be seen as a compoent in a software ???supply chain???, and there may be approaches that allow verification or corroberation of the materials coming in on this ???supply chain??? to Guix, which in turn improves the security of Guix for it's users.

Milestones:

  • Research done regarding approach
  • Implement prototype
  • Publish results