2024-05-04 Meeting notes
Start: 17:00 (UTC+1)
Attendees:
- minion (Skyler Grey)
- jakehamilton (Jake Hamilton)
- nat-418
- dfh (Olly)
- c8h4 (Christoph Heiss)
Agenda
- Introduction round
- Vision
- [nat] GUIX has a better security story
- [dfh] Gentoo has security much more available, directly integrated into the standard utils that manage the system
- How can we know what CVEs apply to us?
- [jakehamilton] GitHub - nix-community/vulnix: Vulnerability (CVE) scanner for Nix/NixOS. provides some way to check for CVEs in our store
- [nat] what about having an ‘aux audit’ command
- [dfh] Can we check for vulnerable packages in our CI?
- [dfh] I’m inspired by the Debian and Gentoo teams, I think they do a really great job at security. I would like to build something with similar quality
- [nat] Aux should have a “blessed” way
- Flakes/non-flakes is a split, and I can’t help across the divide
- Aux should have like “aux secrets manager” [rather than sops-nix, age-nix, etc.]
- [dfh] The term “blueprints” comes to mind … I want to bounce that a little towards the documentation team
- I like the idea of security templates
- It seems somewhat like the “module contracts” idea descriped at NixCon NA
- [jakehamilton] That reminds me of how some k8s APIs are set up, for example you can have an “ingress provider” but it can be handled by different providers and it works the same
- This would let us be a lot more nimble, as things tend to get tied in to a specific implementations
- [minion] I’ve faced this with caddy/nginx in nixpkgs before
- This would let us be a lot more nimble, as things tend to get tied in to a specific implementations
- [jakehamilton] That reminds me of how some k8s APIs are set up, for example you can have an “ingress provider” but it can be handled by different providers and it works the same
- How is best to start?
- [dfh] Jake Hamilton, how is it best to start off a security SIG?
- [jakehamilton] I wonder if this should be a committee instead, as it’s more of an orgwide thing. Most of the SIG/Committee divide comes from k8s
- A committee is handling more meta-tasks, not actual projects. Security committee could take care of the ongoing security tasks and form/ call on SIGs for (groups of?) projects (such as a “Secrets Management SIG” or “SELinux SIG” or “Secure Boot SIG”)
- The committee would/ could set (technical) standards
- [jakehamilton] One thing that’s come up a lot is “How do we drive things”
- In the nix world, everything is third-party
- They’re far more important than that, we need them to be 3rd-party, integrated and cohesive!
- e.g. secrets management should be just a part of the project
- [dfh] “Becoming coordinated with a security approach” is hard, and normally starts with a lot of thinking… you don’t necessarily want to maximize security. Maybe we should start by writing out a security story and getting people, SIGs, etc. on the same page
- [dfh] How do we get a committe started
- [jakehamilton]
- Just do, messy (good enough) is OK for now.
- Committees/ SIGs/ working group established with a charter and a formal process [k8s-community]
- [jakehamilton]
Decisions
- SIGSEC will become a committee
- Overseeing the “security story” for Aux
- Easier to spin off specialized SIGs
- TODOS
- Rename forum categories
- Rename github teams
- (skyler+dfh) Writing a “security story” partly fictional, partly technical
- Community structure similar to kubernetes structure [k8s-community]
- (dfh) Add a when2meet link up for the next conversation
Reflections
- [jakehamilton] This idea feels
- [dfh] This call felt really nice
lot of good idea
