home-manager: create a prototype module for user secret decryption

[RaitoBezarius]

This is a prototype module for user decryption with home-manager.

Some stuff might not be absolutely in line with the quality standards of the project, e.g.

• directories creation might be a bit broken ;
• sshKeyPaths stuff should handled better (accept [] and let rage find out the proper key?)
• reuse of passphrase is not implemented (are SSH agents working? it seems like not)
• cleanup of rootSecret code? does root secrets still make sense in a user context?

cc #50

I can confirm this code provides me with HM-integration of agenix, as seen on https://github.com/RaitoBezarius/nixos-home

[ryantm]

reuse of passphrase is not implemented (are SSH agents working? it seems like not)

This is also a problem with the existing agenix bash script for managing secrets.

[RaitoBezarius]

reuse of passphrase is not implemented (are SSH agents working? it seems like not)

This is also a problem with the existing agenix bash script for managing secrets.

Indeed, maybe, the solution could be shared and provide a flag to help reuse passwords if this is wanted at all.

[ambroisie]

Is there any use-case for changing the owner of a file to someone other than $USER in a home-manager context?

At the very least, I do not see any point in separating the secrets according to which is root-owned or not. This is only relevant in the NixOS case where one needs users to actually exist on the system before trying to chown files to their ownership.

[RaitoBezarius]

Is there any use-case for changing the owner of a file to someone other than $USER in a home-manager context?

Really, I don't know, but I know I do not have this usecase indeed.

At the very least, I do not see any point in separating the secrets according to which is root-owned or not. This is only relevant in the NixOS case where one needs users to actually exist on the system before trying to chown files to their ownership.

+1

[ambroisie]

@ryantm @RaitoBezarius what is needed to merge this PR?

I assume we need to address:

• rootSecret special handling: this is probably unnecessary.
• owner/group handling in general: I don't think it is necessary for the kind of configuration that one does using home-manager. If it is deemed useful by some users it can be added back in.
• sshKeyPaths automatic discovery: this is a feature that would be useful for both NixOS and home-manager, and would probably be more fit for another feature branch.
• testing directory creation: in general, we should probably add a NixOS test to ensure that functionality is not broken.

[RaitoBezarius]

@ryantm @RaitoBezarius what is needed to merge this PR?

I assume we need to address:

• rootSecret special handling: this is probably unnecessary.
• owner/group handling in general: I don't think it is necessary for the kind of configuration that one does using home-manager. If it is deemed useful by some users it can be added back in.

I can do those in the next minutes easily. (EDIT: done.)

• sshKeyPaths automatic discovery: this is a feature that would be useful for both NixOS and home-manager, and would probably be more fit for another feature branch.

I would prefer to let someone else do it, and I do not think this is a critical feature for this PR.

• testing directory creation: in general, we should probably add a NixOS test to ensure that functionality is not broken.

Indeed.

What is left is:

• ensure this work across reboots — once you reboot, there is no mechanism to restore the secrets AFAIK. (critical)
• reuse of passphrases or passphrase caching, otherwise, rebuilding will become annoyingly painful. (important)

For now, I have moved to a system home-manager, so I disabled my version of this module, I will get back to it soon to rework it a bit, notably to address the last two points.

[ambroisie]

reuse of passphrases or passphrase caching, otherwise, rebuilding will become annoyingly painful. (important)

This is also a problem for the NixOS module, I think it is out of scope for this PR

[RaitoBezarius]

reuse of passphrases or passphrase caching, otherwise, rebuilding will become annoyingly painful. (important)

This is also a problem for the NixOS module, I think it is out of scope for this PR

Sure.

[Gerschtli]

Hey, quick question: What is the state of this PR? I'd love to see support for home-manager for agenix. :)

[RaitoBezarius]

Hey, quick question: What is the state of this PR? I'd love to see support for home-manager for agenix. :)

That's a prototype which worked more or less fine for me, except the painful process where you retype all your passwords when you're iterating on your own configuration, quite quickly. So I'd be looking for something that's able to reuse passwords, for this, I'd look for the plugin API of (r)age to add some kernel keyring support and reuse it here.

[ambroisie]

Is it possible to get this merged, and improve it later @RaitoBezarius @ryantm? I feel like the password-reuse issue is cross-cutting (it's useful for re-keying secrets, etc...) but not quite solvable at the moment. However having this module merged avoids having to copy-paste it and keep up with potential updates in the future.

[ratsclub]

@ambroisie Ryan tagged it as a merge conflict so I assume that we are only a rebase away from this to get merged 😄

[ryantm]

@ratsclub 😄, probably not! I looked into the whole home-manager situation with @Kranzes kind of recently and it seems like some home-manager work needs to happen. One problem I remember is that home-manager doesn't run its activation scripts when a user logs in, so I'm pretty sure the way this PR defaults to decrypting the secrets to a temp directory (/run) isn't going to be very user friendly.

[Kranzes]

From my testing it does run activation script on login, the issue is that /run/users/$UID does not yet get created by the time it needs to to decrypt the keys there.

[ambroisie]

Can we just mkdir -p or use a systemd files directive for this issue?

[ryantm]

From my testing it does run activation script on login

I use home-manager standalone (not incorporated as a NixOS module) and I added

{
  home.activation.test = lib.hm.dag.entryAfter ["writeBoundary"] ''
    $DRY_RUN_CMD touch ~/test-home-manager.txt
  '';
}

which created the file when I ran home-manager switch. Then I deleted that file and restarted my computer. When I logged back in the file was still gone.

[Kranzes]

Hmm so I guess it only works as a nixos module. Maybe there's a way to add that functionality to standalone home-manager. We will have to ask @rycee for that.

[ambroisie]

Instead of using home.activation, we could define a systemd service which gets started when the user logs in (so wanted by default.target I think?).

It still wouldn't work on MacOS, but at least it would work on stand-alone home-manager on Linux.

[RaitoBezarius]

FWIW, I put the PR into a draft as it has too much diverged from a WIP which could be used, feel free to close it / re-open a new one on the top of it (or if anyone wants commit bits, no problem) :).

To be honest, user secret decryption is useful for me only if we do solve the issue of multiple passphrases, as I have a lot of synchronized machines and typing 5+ passphrases is annoying to rebuild. So I will only revisit this once (r)age gets agent support which I'm looking in.