RFC: Simplify config handling

[dominikschulz]

The current config implementation is pretty strict so it can provide proper backwards compatibility.

However this makes it harder to edit the configuration manually since we don't allow extra fields and don't support comments, cf. #1654

Should we change the config format to a simple key-value format (ini-style, no YAML) that supports comments?

It's not trivial since then programmatic changes, e.g. through gopass config foo bar become more difficult and we'd need to figure out backwards compatibility. But I wonder if there is any need for that at all.

[AnomalRoil]

We might also want to discuss #1567 since we're discussing config handling :)

In my opinion:

• We should support a config file per store, that's stored at the root of the said store and fallback to the "main" config file if the store doesn't have a specific config. (This can be annoying in teams, since the config file per store might be shared? Maybe have a setting in the main one to disable secondary config files?) Ideally the logic to handle it should be the same, it would just be its location that would influence which file is used.

• Partial config files should be interpreted and non-specified fields should default to Gopass' default values. I believe this should actually already work with the mostRecent config we've got, but maybe we're missing some default values?

  gopass/internal/config/io.go

  Lines 106 to 109 in e54b2a5

  	mostRecent := &Config{
  	ExportKeys: true,
  	Parsing: true,
  	}

  
  Seems we are missing autoimport, cliptimeout and notifications default values.
  In any case we should make sure to honor the $PASSWORD_STORE_DIR value in case the path is the default one, no?
  I guess the issue in Setting mime:false in config blanks out path, ignores $PASSWORD_STORE_DIR, changes other defaults #1654 is probably that we do not correctly handle an empty path in the config.

• We should support comments
  Actually I'm surprised that we do not already support comments since it seems we are using a YAML parser, so it should work with the comments as per YAML format, no?

[morningspace]

Just a couple of comments re: the comments idea.

When we say support comments, it looks the implication is that we encourage user to modify the configuration somewhere in a file, so that they can make comments alongside a certain config item. It's intuitive to modify a YAML file and add comments to it.

On the other side, the current gopass config is more like a way that encourage people to change the configuration from the command line which does not need to touch the YAML file directly. If we do not have too many configurable items and people have already been familiar the way as such, I don't see benefits to add the comment support at least for now.

P.S.

Maybe we can take git config as reference, which has both the command and the config file w/ ini-like format. YAML parser should have comment supported. So, if we did not expose the config file format to the end user, this seems to be a nice way that aligns w/ how git user uses git config. To me, it's just not a must have for now.

[dominikschulz]

The git config format is a great idea, but that would be a big change.

[morningspace]

Understood. It may need some sort of tradeoff here. Also, it looks to me the current configurable items for gopass is pretty simple, mostly a small set of flattened key-value pairs, while the YAML format is essentially capable of supporting more complex scenario, including nested structures. This seem to be a bit overkilled.

[dominikschulz]

Yes, it is overkill and I am strongly considering the git config idea.

We have the YAML format because the config used to be more complex (but not complex enough to justify YAML).

[Techassi]

Just chiming in on this. TOML might be a good config format. The git config format looks to be very close to the TOML format, but it seems like a custom one: Refercence

I would also be open to tackle this migration / change with a PR.