I’d like to collect some topics, questions and related projects, info about which people are working on specific topics, from the community here, and factor them into my preparation for the panel. So if you have any input like that, please post about it in this topic!
We also have panelists already, but if you’d interested in being on the panel or moderating, please PM me here or on Matrix, since I don’t want to adjudicate participation in public.
To give a bit of a (non-exaustive) starting point, here are some of the areas that I’d like to touch on, there is for sure a lot I am still missing though:
I’m not very familiar with cryptography and modern supply chain security practices, so maybe these don’t make sense, but I have a few questions bouncing around in my head about Laut:
How does it fit in with existing tools such as SigStore?
How does it handle threshold signing such as what is in FREON?
Can developers sign artifacts or is it only for package maintainers?
How might a package maintainer integrate a developer’s non-nix signed release? (I.e. they sign a source code bundle for a particular release, or a compiled artifact)
I can also help with GUAC, SLSA and Sigstore, as a maintainer of GUAC and currently working on Sigstore for ML (though I won’t be at NixCon either,sadly)
We made the decision to not go too far out into the weeds on the technical topics, but I did the prep to answer your questions, so I will post my replies to your questions in this thread.
A transparency log like SigStore, can sit conceptually below laut, as a sort of foundation. It’s just for practical reasons that we are defining it as a signature format first. Using a transparency log instead is a matter of putting the same basic data into SigStore instead. @arianvp did some work to put the relevant data in SigStore in his project https://github.com/arianvp/nix-attest, but that’s not the same data format laut uses, yet. Where transparency logs can do more than signatures is if you want to make sure some specific evil build did not run ahead of yours, but there are some issues with that approach, and I think there are better alternatives.
The idea of having a fixed quorum of producers and building that into the cryptography fits well with a producer-centric perspective on supply chains. Laut tries to put consumers of software in control of what they trust instead, so you would not want a quorum like that or really any consensus-mechanism built into the cryptography, to give consumers the flexibility to freely pick their own quorum as part of the validation logic. I think this consumer-centric perspective also fits well with Nix conceptually. Nix also makes it easy for consumers to modify software after all.
There is some way in which you end up with a git repo full of nix code that defines what you are building. There are supply chain security questions about how to secure the contribution process to that repo, and the repo itself, but laut does not handle any of that in its scope, not even the maintainer aspects.
Laut only secures the technical systems that turn a tree of derivations into the final build output.
A lot of old school open source people prefer trusting people over trusting systems, but I think it makes sense to solve trust in people and systems differently or on different levels.
We can make the dependency tree in Nix express and perform these kinds of people-related signature checks, meaning laut doesn’t deliberately deal with that, but you can do it in Nix on top of laut (also see next answer).
Solving issues around how signatures interact with reproducibility in nix was one of the starting points for the work that turned into laut. Laut is designed to be strong enough that you can do serious testing an verification that depends on bitwise identity, like verifying signatures, as part of Nix’s dependency tree, which works well conceptually. Making your dependency tree express those signature checks is one option. The way I did this on top of IA derivations back in 2022 was very brittle and dark-magic-y, but we can make that more user friendly on top of laut and / or CA derivations.
