Possibility of implementing sops sidecar files for secrets as well

[sylvorg]

Hello!

Terribly sorry for being your first issue, but I don't suppose it would be possible to add sops support for secret files as well? I've created a NixOS module for passage, but the agenix module seems to have a few bugs with the paths that I can't figure out, so I'm using sops-nix as well.

I've forked the original passage repo and implemented sops sidecar files, but since I don't know rust, I won't be able to do that here as easily, if at all. Therefore, I was wondering if it would be particularly difficult to add sops sidecar files to this project as well.

Thank you kindly for the help, and sorry for the rambling nature of this issue; if you need any clarification, just let me know!

[sebhoss]

hey :) it's awesome that someone created a first issue here - thank you!

I read your commit and my understanding is that you want to save an additional file per secret encrypted with sops, right? So far, pasejo uses a single file to encrypt an entire store, however I once started with a one-file-per-secret layout that passage is using. I changed this to the current system so that secret names would not be exposed, but thought about making this configurable for those who prefer the passage way of storing secrets. With such a switch in place, I think it should be possible to support a sops-flavor storage layout as well.

Just checked and I think we can use rops to integrate sops support into pasejo. However, I'm not sure how strictly they follow the behavior from the original sops. Can you tell me a little more about your use case and how you are using your forked passage version? Why do you need both the .age and .sops files? Are you strictly calling passage to retrieve the secrets or do you use the sops CLI as well?

[sylvorg]

Hah! I forgot I pushed it already! 😹 But yes, that's about what I want. For some reason, the agenix module is having some trouble with secret paths in the NixOS home-manager module, if I recall correctly, so I'm trying to supplement it with sops-nix.

However, I don't want to switch away from passage, which uses age files for it's secrets, so I just implemented sops sidecar files instead, based on the code I saw in the passage script, since I'm not particularly good at bash either.

Unfortunately, I've since forgotten the context of the original issue, so I'm not sure I can expound much more upon what I've already written.

[sebhoss]

ok ok ... so right now, there might already be an option here: You can use hooks to do something with your store after editing it (that's the push hook because it's original intention was to push changes to a remote repository). I'm thinking that a workflow could look like this:

1. Create/edit a secret with pasejo
2. pasejo calls your push hook which is set to some sops invocation
3. Your sops invocation calls pasejo store decrypt to get the unencrypted data
4. sops can now do whatever it wants with the data

Would that work for you?

[sylvorg]

So the hook would run any time a secret changes, then sops creates a sidecar from the decrypted data beside the age file? If so, it would work for creating and editing the secrets, but what about deletion? Does that count as writing something to the store?

Additionally, I'm assuming verifying the secret and the sidecar are the same could be done with a pull hook, correct?

[sebhoss]

Yeah deletion does count as a modification to the store as well (code). You can run basically any program during those hooks, so running some sort of verification before reading/opening a store can be done with the pull hook. However, as I mentioned before, pasejo does use a single file per store right now and that might have to change in order to better support your use case?

[sylvorg]

pasejo does use a single file per store

Hmm... Could you expand on this? I'm not quite sure I understand it...

[sebhoss]

Forgot to mention that pull hooks have a configurable interval. The idea is that the pull hook is only called after the interval has ended, which is 24 hours by default. You can change this with pasejo config set pull-interval-seconds 0 so that the hook is called every time, but I'm thinking that we might be better off by introducing dedicated before-edit and after-edit hooks that run always?

[sebhoss]

pasejo does use a single file per store

Hmm... Could you expand on this? I'm not quite sure I understand it...

Yeah so the original pass and passage projects all use a one file per secret layout. For example if you have two secrets called a and b, you end up with two files called a.age and b.age. In pasejo, I started with the same layout but then switched to a single file layout which uses a single file per store (which is a collection of secrets). Therefore, no matter how many secrets you have in a store, you always have something like store.age in pasejo. https://rot256.dev/post/pass/ explains the possible attacks I wanted to avoid with this change.

[sylvorg]

introducing dedicated before-edit and after-edit hooks that run always

Yeah, that sounds great! So they don't get in the way of push and pull hooks that need more time.

And got it. So would my solution technically be a two file per secret layout?

I'll take a look at the post.

[sebhoss]

yeah it would be two files per secret, however I don't have any real experience with nix or sops-nix, so I can't tell what's the best way to support your use case. Would adding those hooks be enough for you or do you need another changes as well?

[sylvorg]

I can't tell what's the best way to support your use case

Not much is required, actually, just the sops sidecars would be enough. But in the meantime, if you think a two files per secret might be insecure to implement (understandable; more attack vectors), then the proposed hooks should work just fine!

If there's anything specific or more secure I think I'll need, I'll create another issue! ... Though hopefully not your second issue. That'll feel terrible. 😹

[sebhoss]

nah it's fine - open another one ^^

I should be able to implement those hooks really easy in the next couple of days.

[sylvorg]

Take your time, take your time! Still have to figure out how to implement this in nix, if it's at all possible with their rust packaging system! 😅