Hi folks,
I’m excited to finally share something that I’ve wanted to see in the Nix ecosystem for years: a Nixpkgs that you can confidently hand over to your security and compliance folks. It’s basically an answer to the zillion consulting customers I had when they were worried their security team would object.
We’re promising with a contractual SLA for patching vulnerabilities. We’re publishing SBOMs and (soon) tooling. It comes with a FIPS variant ready and pre-built.
Let me know if you have questions! 
Will there be some backport to nixpkgs for CVE patches?
Definitely. We don’t want to maintain a fat stack of patches if we don’t have to. One of the important aspects about Determinate Secure Packages is we’re able to ship the patches to users in a matter of hours. Once they’re shipping from upstream, we’ll drop them.
I assume that this is backed by some fork of the Nixpkgs git repo (with hand-picked packages)? But I could not find the git repo in the announcement.
Also if you are rebuilding a smaller & safer Nixpkgs, could you try again for full source bootstrap? 
I think the relevant effort has stalled in Nixpkgs (it is quite difficult to achieve this and not break things in such a large package set) (not true, see below), but maybe it is possible if you are building something new and secure from the ground up.
@bryango we’re only a merge and a staging cycle away from a full-source bootstrap in nixpkgs for x86_64-linux: minimal-bootstrap: Hook up with stdenv by Gskartwii · Pull Request #479322 · NixOS/nixpkgs · GitHub
Other architectures will take some more work still, AFAIUI.
Wow, that’s amazing! I was following the old work of @emilytrau and didn’t notice the recent updates… That’s some heroic work! So exciting! Thank you!
It’s actually not a fork of Nixpkgs. We pull the upstream Nixpkgs flake, apply a set of patches, and do a variety of things with the result, such as run security scans and generate SBOMs. And we manage all of this with a dedicated tool that we developed internally. That’s a very rough overview but gives some sense of our approach.
That… sounds like a fork
We take Nixpkgs and we patch it and do other stuff with it. We didn’t press the fork button on GitHub and we don’t use Git to handle per-release state changes. If the “fork” terminology works for you, great, but we respectfully disagree.
I’m not sure why you’d make this argument when even Wikipedia disagrees with your premise:
In software development, a fork is a codebase that is created by duplicating an existing codebase and, generally, is subsequently modified independently of the original.
Let’s call this what it is, please: a soft fork of Nixpkgs. Not that there’s anything wrong with that — quite the opposite, I think, and even better if you’d upstream your patches to package definitions if you happen to be first to write one for a given CVE — but I’m not sure what you gain here by dancing around the terminology.
It’s the same silly argument they make for their nix fork not being a fork. (Even though in that case they clearly did click the fork button on gh.) And they can’t press the fork button here because they already have a fork-button fork at GitHub - DeterminateSystems/nixpkgs: A local fork of the Nixpkgs repository, for sending contributions upstream. Not actively monitored. (in fact I’m not even sure this “secure packages” repo is on github, or public, or even open-source.)
But also, it’s a waste of time to debate “fork or not” or even that they’re busy spreading FUD about nix and nixpkgs itself, when, yknow.
I think the caution comes from the situation around nix/lix/dix. Wanting to dodge that association is understandable (though I prefer calling a fish a fish).
There is indeed nothing wrong with a soft fork of nixpkgs intended to provide better support for compliance-focused businesses. I don’t even think there’s anything wrong with putting it behind a paywall (though as far as I can tell this isn’t?), either, given licensing, as long as the sources are still distributed to customers (which they kinda have to be, given nix). I can actually see myself depending on this at $dayjob.
I’d be more concerned about a hard fork, but that’s definitely not what this is. A hard fork doesn’t really seem feasible anyway.
This blog post in particular doesn’t seem to discredit the community much either. It’s concise and to the point, and just says that there’s a nice way to get SBOMs and security scanning, and a contract for response times. It’d be nice if the jab at self-merges was removed, we all know the stats on FOSS vs commercial security, but eh, I’ll take the lack of outright lies.
I think commercial support for precisely what this offers is really beneficial to the ecosystem. Having this available will make nix look (and possibly be) much more mature and healthy, ultimately aiding adoption and consequently bringing in more resources for everyone.
Awesome project, I hope it’s successful!
I’m not sure there’s really much at stake in the fork vs not-fork-but-rather-something-else terminology. If it’s meaningful to you to call it a fork, please do so.
It is a paid product, yeah. And sources do get distributed to customers indeed :).
Thank you!
Got it; the article isn’t very explicit about it, though I suppose it’s implied by the offer of extending the SLA to packages not currently covered.
Would you be willing to elaborate on what exactly the SBOM covers?
From my perspective the most attractive thing would be an SBOM for the set of build tools used in a specific build, as well as the final set of dependencies in an image or package produced by nix.
I’m not sure an SBOM covering the entirety of nixpkgs (or whatever subset is covered by your SLA) is particularly useful for that; Or do you intend to curate metadata such that something like sbomnix is clean and useful for the subset you support?
That’s kind of funny. We link to the “schedule a call” page but never specifically say it’s paid. I’ll raise that 
.
We publish an SBOM now that covers the contents of the package set. It’s gigantic and unwieldy, but is useful in our internal processing and tooling. More interestingly, the SBOM generation tooling we’ve built is (going to be) available to customers (at the end of January) to cover their closures too. We’ve taken some interesting bets / approaches here around integrating directly with the Nix evaluator to make it more precise.
We do have a long-standing project internally to improve Nixpkgs’ metadata coverage to make the SBOMs cleaner for everybody, yeah :).