Copy KeePassXC settings to individual db settings

[kalegrill]

Expected Behavior

Feature request to make some settings, e.g. locking db if session locked, configurable at the db level rather than or in addition to KeePassXC installation.

Current Behavior

Currently db settings are limited to crypto and basic metadata and do not include KeePassXC behaviour.

Context

I manage multiple KeepPassXC databases on multiple machines. In that context, the threat model is different for each db and for each machine. Applying the strictest settings, e.g. lock the db if session is locked, makes sense for some db's on some machines and so I have such setting on all KeePassXC installations.

As an example, at work I often need access to several accounts for a short period of time which will then either cease to exist or become inaccessible again. I use these accounts on a machine I trust less than my personal machines but also use for some personal stuff. I thus keep two dbs in this scenario, one for the current job and the other for personal. I lock my screen frequently which thus locks my personal db (great) but also the work db (not so great).

[droidmonkey]

I like this idea, just need to make sure we remain compatible with keepass and others. This will require heavy work on the ui front.

[phoerious]

Those settings could either be saved inside the DB or in the config file. DB ensures that no extra meta data leak and it works across devices, but global config is probably easier and doesn't mess up your DB with automatic config entries.

[ccoenen]

(personally, I would not use it, but I see a few ways to achieve something like this while also maintaining compatibility)

As mentioned above, storing extra settings outside the database might leak metadata. This could be mitigated a little bit perhaps. Instead of storing super-private.kdbx locks with session, one could store salted-peppered-hash-of-something-specific-to-that-file locks with session. I'm not sure if there's something like a database-wide UUID or something, but this would not leak to much information for most use cases IMO.

Or one could create a meta password somewhere in the database where some extra-settings are stored in the notes field or something.

[droidmonkey]

I really like the idea of a meta password to store all the settings using the attributes fields

[kalegrill]

I'm curious of what other uses this may have as well

[piggz]

I have a use case for this ... it a uses sets DB to lock after a period of inactivity, and assumes it so, if anyone (say a family member) can come along and un-check that setting, then the database can be left open unlocked. Not pointing fingers, but im pretty sure my kids have done this get into my microsoft account and alter their screen-time settings!

[droidmonkey]

Man, I used to just use a Red Hat 3 boot disk to get around parental protections!

[piggz]

Theyve also been known to do a password reset ... but I fixed that with 2fa!

[OLLI-S]

I would also like to export all settings of KeePassXC to a external file and also import the settings from this external file.

I have two use-cases for this suggestion:

• I have multiple computers (PC, Laptop, VM, Laptop at work) and with this feature I can have the same settings on all clients
• I have KeePassXC 2.5.4 installed and tested the portable snapshot build. This messed up the settings of KeePassXC (installed) so with this feature I could easily restore my settings with some mouse clicks

This feature would really help me a lot and I really hope it is implemented....

[phoerious]

You find the settings in %LocalAppData%\KeePassXC on Windows, ~/.config/keepassxc on Linux, or ~/Library/Application Support/KeePassXC on macOS.

Starting with 2.6, the Windows settings have migrated to %AppData%\KeePassXC and %LocalAppData% only contains things like the window geometry etc. On Linux, this will be in ~/.cache/KeePassXC, on macOS it's ~/Library/Caches/KeePassXC.

[OLLI-S]

And this is exactly the problem: it is not very user friendly (a bad usability) because the user needs to know where the settings are located on the system.
Two buttons "Export Settings" and "Import Settings" in the settings would be much more user friendly.

[droidmonkey]

If the portable snapshot messed up your installed settings then there is a pre release bug there.

[OLLI-S]

@droidmonkey I created a pre-release bug issue #4751

[ccoenen]

All of these things are not really related to the original issue, though?

[droidmonkey]

Not related at all

[OLLI-S]

@droidmonkey It was my fault when I read the comment #891 (comment).
So can you please take my comment #891 (comment) and all following comments and move them to a new issue?

[chron-isch]

@kalegrill

I'm curious of what other uses this may have as well

My answer may be a few years late, but this is a prerequisite /part of #2224.
If you properly want to use the freedesktop.secrets functionality of keepassxc you need to have your database cotaining the secrets, or a second one, continuously unlocked, otherwise every other program will complain about missing password after a while.

But keepassxc does not allow database specific lock timeouts and it doesn't let you choose which DB to lock either, your only option is to lock all.
So if you actually want to lock a database, while keeping another one open, you have to first lock both, and then unlock the one you want to keep open and repeat that every time...