News on the security team

Announcements
1

Hi everyone,

We’ve had a bit of discussion how the security team will be organized in the future. @globin is currently laying out a RFC with a detailed description on how it’s gonna be.

But I’d like to draw attention right now. The security team will be reviewing and coordinating security fixes, but we are too few people to fix everything ourselves. So we’re asking each package maintainer and any other person willing to contribute to help out.

What can you do?

  1. Have a look at the security relevant issues at Github: Issues · NixOS/nixpkgs · GitHub

  2. Pick some issue you feel comfortable with.

  3. Do some research: is there a newer version available? Has a patch been published? Is the problem relevant for NixOS at all?

  4. Fix the package and submit a pull request -or- comment on the issue that nothing is to be done.

We are currently working on a dashboard-like thingy which will provide a more structured overview. But let’s not wait and start working on security issues right now!

Cheers

Christian

9 Likes
2

Forgot to mention: When in doubt or in need of advice, ask on #nixos-security @ freenode. Friendly members of the security team will usually hang around there.

2 Likes
3

Thank you a lot, @ckauhaus! I think the progress you all made today was excellent, I look forward to seeing more!

I think it would be good for us to schedule a video call in a few weeks (I’m not home / available for 3 or so …) between people who are interested. How does that sound?

4

Hi guys,

Thanks so much for all of the continued work on this! I’m wondering, is
there any way financial support could be helpful, whether on an
individual or corporate level? Personally I don’t have capacity to work
on these things directly, but I’d be more than happy to help fund these
efforts (assuming it’s being used effectively, of course) and would try
to convince my employer to do the same. I wonder how many others are in
a similar position?

Thanks,
Shea

Christian Kauhaus nixos1@discoursemail.com writes:

5

@ckauhaus I would be glad to join and help with my capacity during business hours. I regularly have benefited from seeing a CVE published and been astonished that this is already merged in our PR. Thus, i am glad to give back the help i got so far and in extent support my company is using secure software.

6

Hi Shea,

good to hear that. Currently, I don’t see any specific need for funding. In the long term however, it would be worthwhile to think about funding at least a part-time worker hacking NixOS. There are things that nobody is really inclined to work on but that must be done for NixOS being successful.

Christian

7

@periklis Yes, you are very welcome to help out. :slight_smile: Have a glance at the issues listed above or just ask on #nixos-security on IRC.

8

Contributing manpower is probably the best way, but that could theoretically be arranged in indirect ways, due to most companies only wanting to afford a small fraction of a full-time job, e.g.:

  • go through an entity such as the foundation, i.e. companies donating to some fund and foundation paying the manpower from it; or
  • https://www.bountysource.com/ or similar – suitable e.g. for those who want to stress some CVEs in particular.
9

https://opencollective.com/ also seems quite interesting

1 Like
10

@ckauhaus I see multiple “vulnerability roundup” issues, However for some CVEs we still do not have patches. How about putting each CVE as an issue in a github project board?

2 Likes
11

@periklis This is a good question. We had this partially done by simply not ticking off checkboxes in the roundups and revisiting them later. But why not try to set up a board? Let’s give it a try and see how that is working (or not). Would you be willing to do that?

12

@ckauhaus Sure i can do this with the appropriate rights on GH. Imho ic two approaches of structuring the issues on a GH board:

  • Split roundup tickets in an issue per package version listing all CVEs and amending that issue or reopen when new CVEs arrive. Through that we could assign different labels for: affected channels, needs backport, rebuild impact:
Title: libarchive-3.2.2 - Vulnerability roundup
Content:
search, files
- [ ] CVE-2017-14501
- [ ] CVE-2017-14503
  • Split roundup tickets in an issue per CVE which would be more of a copy of the official databases amended by our labels.

In addition i see the following columns:

  • Open: All new issues land here
  • In Progess: Issues that people are investigating for a patch and/or impact analysis on NixOS
  • PR submitted: Issues with mentioned patches for CVEs.
  • Pending Patches: All issues that still miss patches for open CVEs or patches are not available yet
  • Unknown: State of CVE is quetionable or further impact vector analysis is needed.
  • Closed: All issues that are fixed

WDYT?

13

I like your issue per ticket approach. Combine that with labels and I think that would be a big improvement. Work the current roundups sometimes I’m not sure if someone is actually working on something or not so I don’t want to touch it and duplicate effort.

14

I’ll try to structure the upcoming Vulnerability roundup into separate tickets. Let’s see if that makes it easier to structure work.

Unfortunately, I lack permission to create/modify project boards on GH, too. There is a Security board which has not been used for more than a year. Can perhaps someone with appropriate permissions restructure that board according to the outline given by @periklis?

15

I’m afraid I fail to see how splitting helps that point, but I don’t mind the splitting at all.

16

If there is 1 issue per vulnerability easier to keep track of someone saying they are working on it, or you can assign the issue to someone.

1 Like
17

Let’s continue the discussion here: Vulnerability roundup 51: experiments on ticket formatting - “Announcements” should be for announcements

1 Like