Submitting this as a draft to gather feedback first

It looks like the schema check fails with this, as unset value are exported asnull or[] in the json. I am not sure if we can let the module system omit unset values (it wouldn't work if the options didn't have default values)

there is some niche pain points in this strategy I'd like to address.

Some pain points

• Lists are collected into a single collection by the module system. So given this case where we have a default value, but wish to not use it;lib.mkForce must be used.

EDIT:

• The list collection problem maybe a bit more untamed than first thought of.lib.mkForce may not be suitable, as deploy-rs does the merging of values.
  Perhaps an additional argument to the binary (deploy-rs/cli.rs) can override this behavior--no-merge

deploy={sshOpts=["-t"];nodes.test-vm.sshOpts=lib.mkForce["-T"];};

• enforcing specific ordering that contradicts thedeploy.sshOpts overdeploy.nodes.*.sshOpts may also need to utilizelib.mkForce,lib.mkAfter,lib.mkBefore.

• deploy.nodes.*.profilePath == null set will cause errors such as "profilePath used but not declared."

• Possible malicious usage.deploy.sshOpts is forced onto the flake from another flake-parts module. most likely man-in-the-middle attack. High impact. (perhaps an extra security measure, such as checksum could suffice)

• There is also some module "hula-hoops" you should also consider. To avoid infinite recursion, nixos modules use a descendant set of options underconfig.build. This is used for automatic code-generation, afaik flake-parts doesn't provide an equivalent. If you'd like to reference the module-options, and then build new values based off of those options, its expected you do a similar thing underconfig.deploy.build (which shouldn't be carried intoflake.deploy).

Some upsides

• Having it defined in flake-parts is fairly ergonomic, the ability to spread it across different files is a big plus.
• It is now possible to build utilities off ofdeploy options, and then share them with others.
  • One idea might be generating DNS names for each host based offdeploy.nodes.*.hostname then dropping that data into a nixos-module that can then be consumed by a nixosConfiguration.

My conclusion to the idea is that -- I generally like it, and think the benefits outweigh the problems.

The primary problem in the implementation of this is how we choose to communicate with our users. It is not entirely clear to beginners what a flake-module is, and the possible reasons for their usage, above the pre-existing. In some sense, we have a chicken-egg problem. If there were a large ecosystem of flake-modules, then it'd be self-explanatory, but the current state of affairs is that they're quite rare.

I would encourage the author to consider this, and help build the bridge of reason to use the ecosystem by outlining clear benefits.

I hope this helps, I'll be watching the thread as its getting worked on. I might be able to invest sometime into it, but I have a full time job, so its only about 0.01% time that I can donate.

• The list collection problem maybe a bit more untamed than first thought of.lib.mkForce may not be suitable, as deploy-rs does the merging of values.
  Perhaps an additional argument to the binary (deploy-rs/cli.rs) can override this behavior--no-merge

Some after thoughts on this portion. This problem can be solved in the module system, but with some constraints.

Instead of directly passingdeploy top's level (deploy.*), each node would be declared individually indeploy.nodes, which is only shown todeploy-rs.

The remaining top level options should be used in conjunction withdeploy.nodes.*

In respect todeploy-rs/cli.rs, it should only see{ deploy.nodes = { .. }; }. This way we do not need to make any modifications to the client to conform to this.

Possible malicious usage. deploy.sshOpts is forced onto the flake from another flake-parts module. most likely man-in-the-middle attack. High impact. (perhaps an extra security measure, such as checksum could suffice)

There is likely some unsaid primitive in nix for checksums. Imagine a case like a derivation.

{sshOpts=["-t"];# sha2(stringConcatSep " " sshOpts)sshOptsHash="b64f681b76d9dc31203b50b41af60f449ed8c657";}

There maybe some use in not using lists, and rather strings directly, so that the type system can be used to say this can only be defined once, but we still have cases oflib.mkForce.

These ideas are more mitigations for a bigger problem, but it is good to have a focus on high impact causalities from possible supply-chain attacks. In this case, a malicious flake-input.

Some other ideas might include wrapping deploy-rs to ensure that it can only read a subset of public keys, and any nefarious writes to known_hosts/ssh-key exchange is behind bubblewrap, and won't be applied to the running session. This may be the best option, so far I've thought of.

EDIT:

Too understand the possible risk of command injection better, I've gone ahead and built a POC against thecwe-78.

Fish: fish, version 3.7.0
Nixpkgs: f480f9d09e4b4cf87ee6151eba068197125714de

sshOpts = ["eval (touch '/tmp/foo')"]

I think this isn't limited to deploy-rs. If you import a malicious flake module, it could modify your devShell to add some malicious commands to the shell hook, or just replace thedeploy binary with a malicious version. I am not sure if there is a perfect way to fix this. I think this also applies just as well to any other module-based configuration system, like NixOS