gopass
gopass copied to clipboard
gopasspw
Setting config options for substores not working
Summary
The gopass config --store <store> key value command sets the config option globally and not on the mount.
And why is the autosync option not available anymore? How can I disable the automatic sync?
Environment
- OS: Arch
- gopass Version: 1.10.1
- Installation method: repo
Having individual settings for different mounts was deprecated in 1.10 actually. I don't remember the exact rational, but the goal is to simplify the codebase and to have as little settings as possible.
Autosync should become the default I think, but @dominikschulz is the one who knowns the details.
Setting config options per mount has been removed. It complicated implementation and UX for little benefit. AutoSync is now enabled by default. If you don't want sync remove the remotes.
The --store option should be removed from the help page if the feature has been removed.
However, this feature is important for me, because not all users of a substore are using gopass. And one substore I use, stores the public keys in a different location than gopass would with the exportkeys function. So I would like to disable exportkeys for this substore but let it enabled for the others.
And I want to disable autosync because it slows down my workflow as the syncing is done synchronously. I replaced the autosync by a systemd timer that runs every 30 minutes. If it is done directly, creating and editing passwords takes too long, especially when using a YubiKey, which slows down the crypto operations.
So I will have to go back to 1.9.x
@dominikschulz I can see how having mount-specific config options can be useful. Should we have a user-story with this ^ usecase and include it back?
I don't know how much complexity to the config handling it added? Most of the code is still able to handle it I'd guess.
For the autosync, if we don't want to have a config option we could maybe have a environment variable to disable it?
Meanwhile if you don't want to have the exportkey stuff messing with your substore, you could add the exportkey .public-keys folder to your .gitignore I guess?
(BTW, exportkey is not well documented, we might want to document what triggers it and how it behaves. Possibly add a way to specify a different location for its exportation?)
We certainly want to slow down our main use cases too much. Maybe having an option for autosync might be useful, but it should default to on. Environment variables are also OK. I'd prefer that for rarely used features.
The .gitignore workaround for exportkeys sounds good to me. Not sure if it's worth reintorducing the sub-store config compliexity (which was very annoying) just for that.
The problem is that the workaround is not working.
Gopass creates the commits despite the folder being listed in the .gitignore file.
If it's already track by git you might need to remove it first. Then it shuoldn't show up on the remotes anymore. But of course the folder will still be created locally.
It's not tracked by git, but the commits are created nevertheless. And my .gitignore file is correct.
Ha, yes. You are right. Sorry.
To work around some strange failure modes of git, we have added --force to git add.
Of course this will then ignore your .gitignore.
Seems like we need to find another way.
Actually I was considering to drop this feature, but I'm not entirely sure. In certain settings it can help a lot.
Maybe we should have it enabled by default but provide some escape hatch, like checking if a special file in that mount exists and skipping key exports if we find it or so. But I'd really like to avoid reintroducing this cumbersome per-mount config options.
So, currently is autosync removed completely? I want to sync my stores, but not on every command I use. If I want to set autosync to false globally I get:
> gopass config autosync false
Error: Error setting config value
It's still mentioned in the docs.
this cumbersome per-mount config options.
@dominikschulz I wonder why that's cumbersome. It looks to me that's a common case from end users perspective, just like git config, where it has both the global config and per-repo config (optional), and the per-repo one can overwrite the global one.
The way we did config and per-store config previously was cumbersome. But IMO we could probably come up with a better scheme.
For example, for the "per-repo" config: what if someone set just one option in a given repo? Should we copy the entire current config to that repo and change just that value? Or should we make sure that we supprot "partial" config, where if a repo override just one option, the others are taken from the global config and if the global config isn't specifying everything we use the default value?
IMO I'd say the second way is "best", but it would currently require a complete re-write of the config handling.
I like the idea of "partial" config, as it appears that where there's a change at global level, it doesn't have to copy over all the stuff to all config files at the child level.