| 2 Feb 2026 |
 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 |
| raitobezarius | yes there's people working on ZKPing builds | 11:38:52 |
| raitobezarius | i don't disagree that it's easier to rebuild the things but enclaves as an additional thing — if it doesn't cost a lot — doesn't shock me a lot | 11:39:26 |
| raitobezarius | no, lanzaboote works with kernel images, it doesn't touch the config file | 11:41:31 |
| raitobezarius | the only way to add extra entries is to drop more kernel images inside the boot directory | 11:41:41 |
| Sofie 🏳️⚧️ (she/her) | but it disables the systemd thing | 13:39:17 |
| Sofie 🏳️⚧️ (she/her) | like | 13:39:23 |
| Sofie 🏳️⚧️ (she/her) | the option | 13:39:25 |
| Sofie 🏳️⚧️ (she/her) | Redacted or Malformed Event | 13:40:08 |
 K900 | You can just copy the files to /boot/loader | 13:40:22 |
| K900 | You'd still have to sign them separately though | 13:40:43 |
| Sofie 🏳️⚧️ (she/her) | Redacted or Malformed Event | 13:41:46 |
| Sofie 🏳️⚧️ (she/her) | Redacted or Malformed Event | 13:41:57 |
