Allow embedding pasta binary #996

New issue

Open

opened 2025-09-19 09:55:56 +00:00 by yu-re-ka · 3 comments

yu-re-ka commented

2025-09-19 09:55:56 +00:00

Member

When using Lix where it is infeasible to deploy it to /nix/store/ (because Lix is used for system recovery, or because the user does not have permissions to create /nix/store/), this is possible using the pkgsStatic.lix package. rsync-ing ${pkgsStatic.lix}/bin to the target host and adding it to the PATH has worked previously to use Lix with an external store or for recovery purposes.
Since pasta was added, now the Lix binary from pkgsStatic.lix depends on the pasta binary being present on the target system, and it defaults to the default pasta_path in the Nix store. This creates a regression with the aforementioned use cases.

Describe the solution you'd like

Similar to the sandbox shell is embeded into the Lix binary for pkgsStatic builds, I would like the pasta binary to be embeddable too, so that the pkgsStatic Lix binary has as little external dependencies as possible.

While the sandbox shell binary is extracted in the sandbox, the pasta binary simply needs to be executed out of the Lix binary's memory space.

Describe alternatives you've considered

I can copy the pasta binary to the target host separately and set pasta_path in the Nix config, but this involves extra steps which have already been removed for the sandbox shell binary.

Additional context

Discussed on Lix Development Matrix on 2025-09-19

## Is your feature request related to a problem? Please describe. When using Lix where it is infeasible to deploy it to /nix/store/ (because Lix is used for system recovery, or because the user does not have permissions to create /nix/store/), this is possible using the pkgsStatic.lix package. rsync-ing ${pkgsStatic.lix}/bin to the target host and adding it to the PATH has worked previously to use Lix with an external store or for recovery purposes. Since pasta was added, now the Lix binary from pkgsStatic.lix depends on the pasta binary being present on the target system, and it defaults to the default pasta_path in the Nix store. This creates a regression with the aforementioned use cases. ## Describe the solution you'd like Similar to the sandbox shell is embeded into the Lix binary for pkgsStatic builds, I would like the pasta binary to be embeddable too, so that the pkgsStatic Lix binary has as little external dependencies as possible. While the sandbox shell binary is extracted in the sandbox, the pasta binary simply needs to be executed out of the Lix binary's memory space. ## Describe alternatives you've considered I can copy the pasta binary to the target host separately and set pasta_path in the Nix config, but this involves extra steps which have already been removed for the sandbox shell binary. ## Additional context Discussed on Lix Development Matrix on 2025-09-19

yu-re-ka self-assigned this

2025-09-19 09:56:08 +00:00

pennae commented

2025-09-19 11:40:59 +00:00

Owner

the static build could also override pasta = null to drop the dependency altogether? if the primary purpose of the static builds is to have a self-contained recovery mechanism then pasta won't even be necessary (it being just an additional security measure that won't prevent much you're not going to erase anyway when booting a live so or something)

the static build could also override `pasta = null` to drop the dependency altogether? if the primary purpose of the static builds is to have a self-contained recovery mechanism then pasta won't even be necessary (it being just an additional security measure that won't prevent much you're not going to erase anyway when booting a live so or something)

yu-re-ka commented

2025-10-05 11:29:58 +00:00

Author

Member

@pennae I regularly use a non-NixOS host, on which I use the static Lix binary for enabling remote builds, so not just recovery purposes. I would rather have the additional hardening there as well.
Is there any reason not to match the sandbox shell logic for pasta?

@pennae I regularly use a non-NixOS host, on which I use the static Lix binary for enabling remote builds, so not just recovery purposes. I would rather have the additional hardening there as well. Is there any reason not to match the sandbox shell logic for pasta?

pennae commented

2025-10-05 11:32:47 +00:00

Owner

pasta would have to be fully static for that to be viable, but if we can do that there's in principle nothing keeping us from extracting it at runtime and running it from that location. we probably shouldn't mirror the sandbox situation exactly since having the binary visible in the sandbox isn't all that desirable, but in principle the only hurdle would be static linking of pasta as part of our build process

👍 1