| 2 Feb 2026 |
 raitobezarius | is this how we make UEFI test keys go in production builds? | 22:19:41 |
 WeetHet | Oh, I see, thanks | 22:54:36 |
 Jules Lamur | oh that's right, I did not think of that 👍️ | 22:54:47 |
| Jules Lamur | Not addressing your point directly, but even if the invocation passes secrets' "references" (ie. files in my previous examples), that does not prevent the actual secrets store from having authorization. For files it's the kernel doing its things, but you could imagine having secrets references with other "fetchers" for example nix-build --secret sec1 bao:foo/bar/baz or something like that, and openbao does it's job checking that the user running the command has access to the secret. | 23:00:27 |
| Jules Lamur | If the user is compromised and can run arbitrary commands it's already game over, even if they can't map secrets to derivations? | 23:01:59 |
| Jules Lamur | Also, would it be a problem that, by design, these derivations cannot be reproducible? A lot of the nixpkgs ones are not so I guess that would be only a "philosophical problem"? | 23:10:27 |
| Jules Lamur | (Reproducible / determinist in the sense that even with the same signature key, the signed binary differs) | 23:14:23 |
| raitobezarius | the reproducible problem can be fixed by extending the Nix model | 23:14:31 |
| raitobezarius | for example, there could be some sort of special input-addressed derivations which are deterministic modulo verification of the artifacts with a certain public key that needs to be declared | 23:15:04 |
| raitobezarius | * for example, there could be some sort of special input-addressed derivations which are deterministic modulo verification of the artifacts with a certain public key that needs to be declared in the drv | 23:15:07 |
| raitobezarius | so the outputs is IA + mod public key verification | 23:15:17 |
| Jules Lamur | that would be nice | 23:15:34 |
| raitobezarius | the problem is that we are having the discussion over an vague/abstract infrastructure that does this signing thing | 23:17:29 |
| raitobezarius | sure, there might not be arb exec primitive in the real world, but if you have arb foobar injection and arb drv eval and arb […], maybe you have something equivalent | 23:18:01 |
| raitobezarius | additionally, Lix is pretty explicit | 23:18:11 |
| raitobezarius | its sandbox is not a security boundary | 23:18:16 |
| raitobezarius | https://docs.lix.systems/manual/lix/stable/installation/nix-security.html | 23:19:03 |
| raitobezarius |
Nevertheless, the Lix team does not consider multi-user mode a strong security boundary, and does not recommend running untrusted user-supplied Nix language code on privileged machines, even if it is secure to the best of our knowledge at any moment in time.
| 23:19:06 |
| raitobezarius | i think zooming out, some things are important:
- being able to verify inputs provenance via signatures (addresses the source code / .drv recipes trust)
- being able to identify a derivation cryptographically as a function of its inputs which are themselves trusted, etc.
- being able to trust that the code that should be executed is executed (i know some people are playing around with Nitro Enclave derivation builders with attestations)
if you can relate these pieces and the final output (i.e. something proof shaped), that's pretty strong evidence that you are not going to sign any random bytes that someone manipulated through all the pipeline layers? | 23:26:03 |
| raitobezarius | where you do tradeoffs is usecase dependent | 23:26:08 |
| raitobezarius | and some transparency layer for good measure ofc | 23:27:33 |
| 3 Feb 2026 |
| Jules Lamur | Isn't that more or less equivalent to having the full nix evaluated source code (first two points) + a tpm attestation of some sort done (3rd point)? And if I follow where you are going all of that should be sent to the secrets manager that could in turn make its decision to sign or not? The logic behind a secret manager that can take a decision based on that is probably not impossible but I fail to imagine it. It might be too late for me to connect all the pieces together now :) | 00:06:38 |
| raitobezarius | more complicated than tpm but yes | 00:09:04 |
| raitobezarius | the secrets manager needs to be able to verify a proof that the outputs is the result of the execution code with some inputs with known hashes and trust the execution code, some inputs with known hashes needs to be verified to be the outputs of some evaluation code with some new inputs with new known hashes, up to the srcs and that the roots are all trusted (bootstrap tarball, source tarballs signed by an authority, etc.), it's just a long policy check via a DFS where you have to come up with a way to establish trust of a certain output assuming that the inputs are trusted and then you recurse to prove that the inputs are themselves trustables assuming their own inputs are trustables; at some point, you will find yourself in the roots of the "eval-build graph", that way, maybe you can push the risk into having people to compromise your sources' signature hygiene at this point | 00:14:03 |
| raitobezarius | but this is mostly theoretical or abstract again | 00:14:09 |
| raitobezarius | no one is properly doing source tarball signing among a non trivial dependency graph | 00:14:21 |
| raitobezarius | so assuming such a scheme could be devised, it could only work on a custom userspace with very well chosen components, that's super unrealistic | 00:14:53 |
| raitobezarius | * no one is properly doing source tarball signing, esp. with a non trivial dependency graph | 00:15:11 |
 0x4fbb09 it/its ⛯✇ΘΔ | i've seen some zero knowledge proof type stuff to allow fast verification that a given output was an execution of a given program
but as-is, it's so incredibly slow to compile that it's not worth it for just reproducible build verification, you're better off just asking people to rebuild the binaries themselves
more trustworthy than "just trust that attacks on enclaves aren't a thing(they are)" | 09:00:44 |
 Sofie 🏳️⚧️ (she/her) | Is there a way to add extrafiles for systemd boot and extraEntries in Lanzaboote? | 09:54:23 |
