First of all sorry for the breakage I caused!

In fact @fpletz and I discussed about this in #58718.

The issue here is that, AFAIUI, cfgc.package will not resolve to the right nativeBuildInput, though I do not understand why exactly.

Same here, we assumed that nativeBuildInputs would solve the problem. I'd like to wait for the suggestions of somebody with more experience in cross-compilation first, but I'm happy to help finding an appropriate solution :)

On a side-note: there are some other modules like services.prometheus which use a similar approach to validate their configs, I guess they need to be fixed as well.

This is not as simple as testing with any other sshd, ideally you want to test with the one that will run the configuration

Naively asked: why? In other words: which sort of issues do you have in mind?

The current validation only ensures the syntactical correctness of the resulting sshd configuration, so we shouldn't experience too much behavioral differences in that case, right?

The current validation only ensures the syntactical correctness of the resulting sshd configuration, so we shouldn't experience too much behavioral differences in that case, right?

I assumed that it would validate that options are set in valid ways, and that options are valid. Meaning that those cases could be problematic:

• testing a configuration with new settings on an old sshd
• new sshd with backwards incompatible options
• sshd fork with misc. incompatible changes

If it only checks syntax it might be less of an issue, assuming at that point that an incompatible syntax using Open SSH sshd fork would likely not the module anyway.

-t Test mode. Only check the validity of the configuration file and sanity of the keys.
This is useful for updating sshd reliably as configuration options may change.

This is not obvious whether it checks validity of options and values or only that it can parse the file.

In native mode, this patch causes:

building '/nix/store/d4mfzz0a60abcw8370fbm80nxmkr7b3r-etc.drv'...
ln: invalid option -- 'N'
Try 'ln --help' for more information.

Looking at it, I'm not sure why.

The splicing that makes nativeBuildInputs do the trick only works with callPackage, so it isn't available here.

I too would just unconditionally do pkgs.buildPackages.openssh----is that that important to customize the build-time dependency? Otherwise one can make a config.programs.ssh-for-build.

Middle ground would be something like:

if stdenv.buildPlatform == stdenv.hostPlatform
  then [ cfgc.package ]
  else [ pkgs.buildPackages.openssh ]

That would address both potential closure size concerns and fix cross-compilation (if only a bit verbose).

Thank you so much for working on this! Tested here too.