Confusing --disk-encryption-keys semantics

[felixdorn]

I'd be happy to submit a PR to improve this but I'd like to have some approval (or refusal) first.

Why it's confusing

1. --disk-encryption-keys has nothing to do with disko but it is so specific that it's difficult not to think that it messes with settings.keyFile, settings.passwordFile, or additionalKeyFiles
2. --disk-encryption-keys` has little to do with keys in its implementation, i.e., any other secret would work fine too
3. The syntax is <dest> <source> instead of <source> <dest>, which seems like a footgun, it's not what cp, install or a myriad of other copy utilities use.

How we could improve it

1. Depreciate --disk-encryption-keys in favor of a less-suggestive --copy-secret
2. Swap the argument order (source, then destination)

[bebehei]

I'm having issues with --disk-encryption-keys too. The argument seems to be ignored for me and I get asked always for a password.

While thinking about it: Why is it important that the remote path is fixed, too? Wouldn't a sensible implementation make the remote filepath a superfluous setting at all? As a user, I'm controlling the input (the local key), but the remote key location is processed by the program itself.

[sedlund]

@bebehei

but the remote key location is processed by the program itself.

the remote key path is specified in your disko config so it depends where its put:
https://github.com/nix-community/disko/blob/84a5b93637cc16cbfcc61b6e1684d626df61eb21/example/luks-interactive-login.nix#L26

@felixdorn
i think it makes sense to add a new --pre-disko-files (in relation to the phases) and then use the same tar method as --extra-files

1. this is more descriptive about when the files are copied
2. the destination need not be specified

add a deprecation notice for v2.0 🥳

EDIT: although i dont speak for the maintainers!

[bebehei]

the remote key path is specified in your disko config so it depends where its put:
https://github.com/nix-community/disko/blob/84a5b93637cc16cbfcc61b6e1684d626df61eb21/example/luks-interactive-login.nix#L26

Thanks for the explanation. This makes a bit sense then. I have dismissed the disko parameter, as I thought this is used for a static setup where a secret inside disk1 can be used to unlock disk2.

Is this documented anywhere? I only find docs/howtos/secrets.md. But there is nothing mentioned about disko's passwordFile and --disk-encryption-keys.

Did I miss some docs or do I need to update them?

---

Sorry for hijacking this thread.

[felixdorn]

EDIT: although i dont speak for the maintainers!

I talked to someone from Numtide at Nixcon about this and I remember them having mixed feeling. It's fuzzy, but I think they convinced me that it wasn't too bad, although I don't remember why and how.

i think it makes sense to add a new --pre-disko-files (in relation to the phases) and then use the same tar method as --extra-files

I think we might not want to generalize too much (--pre-disko-files), but just enough (--copy-secret) to avoid the confusion. The only use case of this argument is to copy disk secrets after all.

[sedlund]

@bebehei

Is this documented anywhere?

I dont see anything specific in nixos-anyhere that ties it all together. Seems to be in disko's examples directory for luks setup which one would have to familiarize with to make disko work. adding more to that section in the secrets.md would be good.