New recipient syncing removes all other public keys

[LeadingMoominExpert]

Summary

I added myself as a new recipient to a store on a new machine. After running gopass clone and sync I'm able to see the stored secrets, but syncing removed all other public keys from the store. Syncing shows the following output

$ gopass sync --store tuomas
❌ Failed to initialize mount 3 (/home/tuomas/.local/share/gopass/stores/3). Ignoring: failed to init sub store "3" at "/home/tuomas/.local/share/gopass/stores/3": password store 3 is not initialized. Try gopass init --store 3 --path /home/tuomas/.local/share/gopass/stores/3
🚥 Syncing with all remotes ...
[tuomas] 
   gitfs pull and push ... OK (no changes)❌ Failed to decode public key 0x011B48107A2944E1: public key "0x011B48107A2944E1" not found❌ failed to export public key for "0x011B48107A2944E1": failed to export public key: key not found❌ Failed to export missing public keys for "tuomas": some keys failed✅ All done

Steps To Reproduce

Sync an existing store using a new recipient.

Expected behavior

Syncing would import the existing public keys to the new recipients machine instead of removing them from the store.

Environment

• OS: Ubuntu 22.04.2 LTS
• OS version: Linux mylly 5.17.0-1034-oem # 35-Ubuntu SMP PREEMPT Wed Jun 21 14:47:15 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
• gopass Version: gopass 1.15.5 go1.20.2 linux amd64
• Installation method: downloaded from gopass repo releases

[AnomalRoil]

How did you install that store?

I think you might need to import the old public keys first using:

gpg --import /path/to/your/store/.public-keys/*

[LeadingMoominExpert]

I used gopass clone to initiate the new store from git. Having done that the public keys located in /path/to/your/store/.public-keys/* are just my own keys, not the ones already set in the git repository, so importing them really doesn't do anything.

[AnomalRoil]

That's surprising.
sync should detect the missing keys and import them.

I could reproduce locally, adding a substore using:

gopass setup --remote git@git.github.com:example/example.git --alias example

seems to work fine, but doing the same thing using gopass clone doesn't:

$ gopass setup --remote git@git.github.com:example/example.git --alias example
🌟 Configuring your password store ...
✅ Configuration written
[example]Configuring git remote ...
[example]Cloning from the git remote ...
[example]✅ Done. Joined Team "example"
[example]⚠ You still need to request access to decrypt secrets!

$ gopass clone git@git.github.com:example/example.git second
[...]
Your password store is ready to use! Have a look around: `gopass list second`

❌ Failed to git commit: exit status 128: error: gpg failed to sign the data
fatal: failed to write commit object
⚠ Please ask the owner of the password store to add one of your keys: 0x1...
⚠ The missing keys were exported to the password store. Run `gopass sync` to push them.

$ gopass sync
🚥 Syncing with all remotes ...
[<root>]
   gitfs pull and push ... Skipped (no remote)
[example]
   gitfs pull and push ... OK (no changes)Do you want to import the public key "0x..." (Names: [...]) into your keyring? [y/N/q]: y
Imported public key for 0x... into Keyring
[second]
   gitfs pull and push ... OK (no changes)❌ Failed to decode public key 0x...

[uschtwill]

Trying to introduce gopass in my team, and we've run into this repeatedly, specifically gopass clone not using the keys that are there.

[uschtwill]

And now we had the same thing happen as OP. Upon their first sync, a colleague's gopass removed all public keys but their own and immediately pushed that change to the remote. 😔

[dominikschulz]

Sorry for that. I hope that I can take a look at this soon.

[dominikschulz]

Can anyone that is affected re-run the steps to reproduce with GOPASS_DEBUG_LOG=/tmp/gopass.log and provide (possibly truncated) logs?

I think there might be a mismatch between how recipients are specified in the .gpg-id file and their filenames.

[jonmz]

We observed this problem as well, but only with our newest team member. The only difference we came across was that she was the only team member initializing the password store with gopass clone straight from our git repo, while all the other team members had used the original pass earlier and later switched to gopass, resulting in the following difference:

• the new team member has its root store in ~/.local/share/gopass/stores/root
• the other team members have their root store in ~/.password-store

We tried simulating this for her by moving her root store into the legacy location and removing all other stuff created by gopass clone:

$ mv ~/.local/share/gopass/stores/root ~/.password-store
$ rm -rf ~/.local/share/gopass ~/.config/gopass

When we tried again, gopass sync worked like a charm and happily imported all team member's public keys into her local keyring.

[dominikschulz]

Thank you @jonmz . This is useful feedback. I will try to reproduce this as well.