| 14 Oct 2021 |
 Alyssa Ross | j-k: do you have a link to the discourse discussion? | 09:19:32 |
| Alyssa Ross | sad that I've missed this | 09:19:37 |
 j-k | https://discourse.nixos.org/t/generating-software-bill-of-materials-from-derivation/14089 | 09:19:54 |
| j-k | It's also been posted about in the matrix twice | 09:20:17 |
| Alyssa Ross | hmm, that seems to be about one very specific aspect of it | 09:21:41 |
| Alyssa Ross | and I think it's one Nix is not particularly well-suited for, because it's too dynamic | 09:27:04 |
| j-k | what is one? SBOM? | 09:27:49 |
| Alyssa Ross | yeah | 09:28:00 |
| j-k | An SBOM (in it's current incarnation) should be a reproducible bill of materials that covers direct dependencies and transitive dependencies. Some also collect the hashes for every file (but I find the benefit of this dubious, just review your git repo).
As I see it SBOM is generally an inferior .drv (especially if you're using something like go2nix which brings all your deps into the nix ecosystem
I have little value for an SBOM for a project alone, I will also want the SBOM of the tooling (e.g. go) and the SBOM for whatever built that etc etc etc turtles all the way down. I'd also want some guarentees the SBOM I have for a go build is the exact one for that actual go build etc
In my estimation nix drvs solve this | 09:33:52 |
| j-k | There's some complexity using something that bundles dependencies such as buildGoModule but you could either generate an SBOM as part of that output or just migrate to a full nix system like gomod2nix | 09:35:02 |
| Alyssa Ross | hmm, right, in that case perhaps I was misunderstanding what it is | 09:35:41 |
| Alyssa Ross | so if I made a list of all the sources required to build my application, including all transitive build and runtime dependencies, that would be an SBoM? | 09:36:34 |
| j-k | yep, the analogy that's common is a list of ingredients on a food packet | 09:37:21 |
| j-k | I've put some initial thoughs in the nix-slsa channel but I'm hoping to do a full review of different SLSA requirements and covering where nix solves them, where nix invalidates the need for them, or where nix might need some extra help | 09:37:50 |
| Alyssa Ross | right, yeah, that sounds like something Nix would be extremely good at | 09:38:11 |
| Alyssa Ross | I'm not sure if you know this, but this sort of stuff is extremely relevant to my work | 09:40:21 |
| Alyssa Ross | https://spectrum-os.org/ | 09:40:34 |
| j-k | IIRC you're working on Spectrum | 09:40:36 |
| j-k | yeah | 09:40:37 |
| Alyssa Ross | one goal is to minimize the amount of code running on the host system | 09:41:05 |
| Alyssa Ross | obviously that makes it easier to audit and stuff | 09:41:10 |
| Alyssa Ross | and SBoM stuff as you've described it here sounds like it would be very useful at identifying what needs to be audited | 09:41:32 |
| Alyssa Ross | unfortunately, I'm swamped until the end of the year trying to satisfy existing funding goals before they expire, but one thing I might be able do would be to get in touch with people who're coming to Nix from the SCS side of things, introduce myself and what I'm trying to do, and reassure them that we are interested in this and that I'd be interested in looking for opportunites to collaborate starting next year. | 09:45:11 |
| Alyssa Ross | because you're right that it'd a real shame if Nix was passed over for all this stuff. | 09:45:23 |
| j-k | Exactly. Every time I look at the work done on nix and how long ago this all was started my mind is blown. I'd hate for industry to pop up, recreate everything from scratch, and introduce fatal flaws that nix has already solved | 09:46:49 |
| Alyssa Ross | The reason I said I didn't think Nix was well suited before, btw, is that with Nix it's basically impossible to figure out which code is actually being used at runtime. Of course that doesn't really matter, when any build dependency could have compromised that code, but my experience before has been that people don't care about build deps. Glad to hear that's not the case here. | 09:47:09 |
| j-k | In the interest of seeing this move ahead and not get missed in the torrent of messages I'll try summarise some of this in a discorse post | 09:47:52 |
| Alyssa Ross | Yeah, please. | 09:48:00 |
| Alyssa Ross | And we can discuss further in the SLSA channel, which I've now joined. | 09:48:31 |
| j-k | In reply to @qyliss:fairydust.space
The reason I said I didn't think Nix was well suited before, btw, is that with Nix it's basically impossible to figure out which code is actually being used at runtime. Of course that doesn't really matter, when any build dependency could have compromised that code, but my experience before has been that people don't care about build deps. Glad to hear that's not the case here. Yeah I've not looked too much into the runtime aspect. I've had my colleagues complain they can't use nix on fedora with SELinux on 🙃 Your insight around that would be amazing
There is some work around keylime and validating SBOMs/Provenance at the kernel level before code runs so that might also help 🤷
| 09:49:36 |
