> could've contributed SLSA attestations support to nix
That sounds like a great idea! However one important consideration is that while an artifact on nixpkgs may aim to replicate the function of the upstream package, it must adhere to and interoperate with the rest of the distribution. Ultimately, its 'ecosystem' is nix. Work that goes into writing and maintaining the nix build does not generally filter back upstream to impact the build integrity of, say, its associated PyPI package. So if users continue to consume from PyPI, improving nix won't serve them.
This is not to say that the long-term source of truth for packaging will remain the language registries. Just that today's reality demands we meet users where they are.
> Would love to see Google contribute to nix in this space :)
> but it could really do with a web UI of some sort!
Couldn't agree more! The terminal UI exists (`./tools/ctl tui`) but is oriented towards developers on the project or to those who wish to run their own instance. Making the system and data more accessible to general users is a big priority.
OSS Rebuild should give that Nebraskan the peace of mind to continue their everyday heroism without being pulled away to set up security configs or debug release CI. The rest of the blocks on top can contribute the support to assure themselves and the community that those critical builds are trustworthy.
Nope! One use for OSS Rebuild would be providing maintainers that have idiosyncratic release processes with an option for providing strong build integrity assurances to their downstream users. This wouldn't force them into any particular workflow, just require their process be reproducible in a container.
> for some projects that I rebuilt myself in docker, I got vastly different sizes of distribution artifacts.
Absolutely. OSS Rebuild can serve to identify cases where there may be discrepancies (e.g. accidentally included test or development files) and publicize that information so end-users can confidently understand, reproduce, and customize their dependencies.
> what about packages in linux distro repositories (debian, etc.)
OSS Rebuild actually does have experimental support for Debian rebuilds, not to mention work towards JVM and Ruby support, although no attestations have been published yet. There is also no practical impediment to supporting additional ecosystems. The existing support is more reflective of the size of the current team rather than the scope of the project.
Both nix and guix are exciting projects with a lot of enviable security properties. Many here can attest that using them feels like, and perhaps is, the future. I see OSS Rebuild as serving more immediate needs.
By rebuilding packages from the registries people already use, we can bring some of those security properties to users without them needing to change the way they get their software.
Nixpkgs pulls source code from places like pypi and crates.io, so verifying the integrity of those packages does help the Nix ecosystem along with everyone else.
> could've contributed SLSA attestations support to nix
That sounds like a great idea! However one important consideration is that while an artifact on nixpkgs may aim to replicate the function of the upstream package, it must adhere to and interoperate with the rest of the distribution. Ultimately, its 'ecosystem' is nix. Work that goes into writing and maintaining the nix build does not generally filter back upstream to impact the build integrity of, say, its associated PyPI package. So if users continue to consume from PyPI, improving nix won't serve them.
This is not to say that the long-term source of truth for packaging will remain the language registries. Just that today's reality demands we meet users where they are.
> Would love to see Google contribute to nix in this space :)
Same :)