Store recipients file alongside passwords?

[fredrikfoss]

Hi,

What's the rationale for storing the recipients file in the base directory
($PA_DIR) ~/.local/share/pa/ rather than alongside the passwords in
~/.local/share/pa/passwords/, like pass/passage/gopass?

It would make it easier to identify what private key to use for decryption, as
you can convert an identity file to a recipient file and compare. This would
also make it easier to deal with multiple identities/recipients, as the
recipients to be encrypted for will be synced with the repository, rather than
having to send a copy of the new recipients file through other means every time
it is changed. A disadvantage is of course that anyone with access to the
password repo could overwrite any secret, but at this point you should be using
another solution aimed at multiuser usage anyway, no?

[biox]

do they do this sort of thing per-password? like:

$ ls passwords/
mypass.enc
mypass.recipient

or is there basically a single pubkey stored in the passwords dir, and it's always used for encryption?

i'm curious about how this works specifically. i have no problem with making the recipients files part of the passwords/ dir by default, but i figured since it wasn't a password, it didn't really belong in the dir, haha.

[fredrikfoss]

There is usually a single top-level recipient file used for all passwords, yes.
Something like

$ ls passwords/
.recipients
mypass.enc

where .recipients contains one pubkey per line. But I think at least gopass
supported having multiple recipient files in nesten directories inside the
password store, which would supersede earlier recipient files.

$ ls passwords/
.recipients
mypass.enc
site.com/.recipients
site.com/privatepass.enc

Not sure how much code this would require though. But about the file not being a
password, true but so is the case with .gitattributes and also .git/. I think it
looks pretty clean including the recipient file as a hidden file in the password
dir as well :)

[biox]

the question, really, is does this benefit pa's users? the current setup is similar to the way ssh, or tls certs work - the public thing is right next to the private thing. i can see your side though, and i'm going to let this percolate in my head a lil bit before making any decisions. curious to hear opinions from other folks too.

[fredrikfoss]

Sure! I do see your point though. I'll ponder a bit more on it as well while
waiting.

[arcxio]

my concern would be that in case remote is compromised, you can be fed the attacker's key in a recipient file, meaning you'll be unknowingly encrypting your passwords for the adversary recipient. it's good to require extra care for syncing the recipients.

[fredrikfoss]

Yeah, that is a good point. Just thinking aloud: i don't want to assume others' workflow, but how often do you pull your vault? Doing a quick pa g log -p after each pull should be doable, and probably habit anyway.

Say you have five systems where you share your passwords, each with different privkeys. When you want to add your passwords to a 6th, you'll have to transfer your pubkeys over to all five machines in some way. If you're unlucky and forget one of them, then pull, add/edit/re-key, then push; your new system would no longer be able to decrypt whatever passwords you changed or added. But with /passwords/.recipients:

# pc 6
pa g clone git@mypws # (this doesnt actually work though, clones to /passords/mypws/)
age-keygen -o identities
age-keygen -y identities >>passwords/.recipients
pa g add commit push

# pc 5
pa g pull
pa g log -p
pa-rekey
pa g push

# pc 6
pa g pull

# all other pcs
pa g pull

Though you probably have to copy over your ssh keys anyway. Having recipients separate from the repo also gives each instance more control over which other instances can decrypt their stuff (but why..). And then there's the compromised remote concern. Possible workflow:

# pc 6
age-keygen -o identities
age-keygen -y identities >>recipients
somehow-transer-recipients-to-pc-5

# pc 5
recieve-recipients-from-pc-6
cat pc-6-recipients >>recipients
pa-rekey
pa g pull

# pc 6
pa g clone git@mypws # (again doesn't work)
pa g pull

# all other pcs
somehow-get-new-recipients-file-tranfered-over
mv new-recipients recipients
pa g pull

I think both have some drawbacks, but personally I think I'm leaning a bit more towards an .identities in passwords/. Want to sync your password? Just git pull, no need to stress checking for new recipients and manually transfer files.

[arcxio]

i don't want to assume others' workflow

me neither, which is why it's a problem. you don't even have to use git to sync passwords, if someone does that through some shady cloud, it's still secure now, and not so much if we'll have a recipients file there.

I think both have some drawbacks, but personally I think I'm leaning a bit more towards an .identities in passwords/. Want to sync your password? Just git pull, no need to stress checking for new recipients and manually transfer files.

identities definitely don't belong in the password store and there are no differences between your last two examples, I assume these are typos.

there's a middle-ground option that came to mind: you'll have two recipients files, the real one (in $PA_DIR), and the synced one (in $PA_DIR/passwords), whenever the latter is changed, pa can show some kind of confirmation with a diff to replace the former with it.

to be clear, nothing currently prevents you from doing it manually. you can store the recipients file in the password store (as well as anywhere else) and link $PA_DIR/recipients to it, and it should work as you expect. so this issue is more on the UX side rather than technical.

[fredrikfoss]

you can store the recipients file in the password store (as well as anywhere else) and link $PA_DIR/recipients to it

Ah of course, don't know how I didn't think about that. Such an easy solution.

you'll have two recipients files, the real one (in $PA_DIR), and the synced one (in $PA_DIR/passwords), whenever the latter is changed, pa can show some kind of confirmation with a diff to replace the former with it.

That sounds like it could solve all issues really wow, interesting. It doesn't sound too complicated to implement either. Yet another feature to your simple manager though. I wonder if gopass and co. does this.

[arcxio]

@biox do you think we need this sort of thing? if you like my suggestion I'll make it into a PR

[biox]

by default, would any identities show up in the password store? i feel that there should really only be 1 set of identities, otherwise the interaction between them will be unclear.

i think that as long as it's optional (since this is an advanced feature), i'm fine with it - but if there are 2 identities files by default, i think i lean against it.

[arcxio]

by default, would any identities show up in the password store?

identities won't change. there would be an additional file in the password store with recipients. on every run pa would check if the two recipients files are equal. if there are new recipients in the local file, they should be added to the one in the password store. then if there are new recipients in the file that's in the password store, pa should show something like this:

age1vwrcxwy8y40xmrua45z8p6sveakj4ld3nx2r2nvyvcufk57h9y0sk5900r
age13z6jhd9kj5hf9n6ettszcwyxrdmhwqv97xyvjnn28fav6rx2jqpqfpmvdy
do you accept these new recipients from the synced storage? [y/N]

if user agrees, then these should be added to the local file. otherwise, they should be removed from the file in the password store.

I can't come up with a simpler way to do it properly. the way it can be optional is that pa would not create this new recipients file in the password store by itself, it would be this weird implicit behavior in case the file already exists, and it would require the user to copy the recipients file to the password store manually to enable this thing. we're trying to move away from manual synchronization of recipients here and make multi-device setup more convenient - preferably without losing security, in that context I'd rather have it work automagically, so by default. if it's not utilized, the user will just have two files that are the same. it would be nice to have but I'm afraid to overcomplicate stuff as well so you're free to veto this

[biox]

i like it, except that removing the entries from the password store recipients file would mess with the git state - would that change be auto-handled as part of the git workflow? i could see that getting messy

[arcxio]

would that change be auto-handled as part of the git workflow?

I actually think if recipients are removed the git repo should be nuked.

if recipients are removed because they are not used or in the worst case scenario the identities for them are leaked or at risk of being leaked, then it's not a good idea to store passwords encrypted for those outdated recipients in the git repo.

and if they are removed because I have no idea who those recipients are, then the remote is untrusted and must be reconfigured anyway.

[arcxio]

while sketching this out, I've had a realization - if pa would track recipients changes, it could also trigger rekey right then by itself, instead of expecting user to manually run a contrib script separately. this would be an additional improvement in multi-recipient UX: just add a recipient and the passwords become ready for it with no additional steps.

it does of course bring notable complexity - my draft with two recipients files had ~200 loc initially, and 224 loc now after trying to integrate rekey.