Project

General

Profile

Bug #17286

Make KeePassXC save database in a persistent dir by default

Added by segfault 4 months ago. Updated 5 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
bugfix/17286-keepassxc-persistent
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Password Manager

Description

As described in #17212#note-1, KeePassXC currently proposes to save the database in /home/amnesia/Passwords.kdbx, while in 3.x it was stored in /home/amnesia/Persistent/keepassx.kdbx.

Since the new path is not persisted, users who store their database there will lose the passwords they generate before restarting. This is a regression and we should try to fix this.


Related issues

Related to Tails - Bug #17212: KeePassXC dialog lists a default DB which does not exist Resolved
Duplicated by Tails - Bug #17421: Consider setting KeypassXC default folder to ~/Persistent/ Duplicate
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

Associated revisions

Revision e874c94f (diff)
Added by segfault 4 months ago

Make KeePassXC propose to store new databases in ~/Persistent (refs: #17286)

Revision 38436f6e (diff)
Added by segfault 4 months ago

Display warning when starting KeePassXC without persistence (refs: #17286)

History

#1 Updated by segfault 4 months ago

I took a look at the KeePassXC code, the proposed path is hardcoded as QDir::homePath() + "/" + tr("Passwords").append(".kdbx").

So a way to fix this would be to create a wrapper script which calls keepassxc with a modified HOME env var:

#!/bin/sh
HOME=/home/amnesia/Persistent /usr/bin/keepassxc $@

I still have to check in which other places in the KeePassXC code the home dir is used.

#2 Updated by segfault 4 months ago

  • Assignee set to segfault

#3 Updated by segfault 4 months ago

segfault wrote:

I still have to check in which other places in the KeePassXC code the home dir is used.

It's being used:

  • As the default directory when saving and opening databases. This is where we explicitly want to use ~/Persistent.
  • In code used only for the browser extension, where it is used to find the config directory of the supported browser. Since Tor Browser is not supported anyway, we don't break anything here.
  • To locate the keepassxc.ini config file, except if XDG_CONFIG_HOME is set to an absolute path. So to keep using ~/.config/keepassxc.ini, we should also set @XDG_CONFIG_HOME=/home/amnesia/.config" in the wrapper script.

#4 Updated by segfault 4 months ago

As the long-term solution, I think we could ask the KeePassXC maintainers to read the default database path from an environment variable.

#5 Updated by segfault 4 months ago

  • Status changed from Confirmed to In Progress

#6 Updated by segfault 4 months ago

The branch is based on the one from #17212.

#7 Updated by segfault 4 months ago

  • Status changed from In Progress to Needs Validation
  • Assignee deleted (segfault)

#8 Updated by segfault 4 months ago

  • Feature Branch set to bugfix/17286-keepassxc-persistent

#9 Updated by segfault 4 months ago

  • Related to Bug #17212: KeePassXC dialog lists a default DB which does not exist added

#10 Updated by intrigeri 4 months ago

#11 Updated by intrigeri 4 months ago

  • Assignee set to intrigeri

segfault wrote:

The branch is based on the one from #17212.

⇒ I'll review both at once!

#12 Updated by intrigeri 4 months ago

  • Status changed from Needs Validation to In Progress
  • Assignee changed from intrigeri to segfault

Hi,

First, I'd like to assess the severity.

I agree this is a regression.
It would obviously be better if the default directory was a persistent one.
We knew about it and workaround'ed it by documentation, but it's barely good enough and the risk you're describing does exist.

This being said, given we have no explicit persistence setting about KeePassXC data, arguably a user would not expect that it'll persist if they save it to /home/amnesia, just like they would not expect a picture saved from GIMP, or a spreadsheet saved from LibreOffice, to persist if they save it there. So personally I'm classifying this problem as rather minor. If we can fix it cheaply and safely enough, great, let's do it. If we can't, I'm fine with living with status quo. I'd love to hear your thoughts and sajolida's about it :)

segfault wrote:

segfault wrote:

I still have to check in which other places in the KeePassXC code the home dir is used.

It's being used:

  • As the default directory when saving and opening databases. This is where we explicitly want to use ~/Persistent.
  • In code used only for the browser extension, where it is used to find the config directory of the supported browser. Since Tor Browser is not supported anyway, we don't break anything here.
  • To locate the keepassxc.ini config file, except if XDG_CONFIG_HOME is set to an absolute path. So to keep using ~/.config/keepassxc.ini, we should also set @XDG_CONFIG_HOME=/home/amnesia/.config" in the wrapper script.

I'm a bit worried by the consequences of setting a custom $HOME.
I'm glad you checked where it is used in the KeePassXC codebase and that you've set $XDG_CONFIG_HOME: it alleviates my concern a bit.
Thankfully lots of IPC on modern GNU/Linux systems happens in ways that are not affected by $HOME (so for example, I'm confident that this won't break accessibility; this should be checked though IMO).

But on my sid system, the keepassxc binary is dynamically linked to no less than 52 libraries. Each of them can potentially use $HOME currently or start using it in the future. We've got a lot of potential breakage here. For example, I could imagine that Qt5 uses $HOME and not only $XDG_CONFIG_HOME.

I'm open to concluding that fixing this problem is worth the risk but I'm not exactly there yet. I'm not sure where to go from here.

One thing that could help convince me this change is safe enough is to trace the process (and all its threads, if relevant) with HOME=/home/amnesia and check what it tries to access in there.

What do you think?

#13 Updated by sajolida 3 months ago

Taking a step back:

I think that when we decide to store the KeePassX database in
Persistence by default, we make the assumption that KeePassX is only
useful in Tails if you have Persistence. In other words, why would
someone create a KeePassX database if it was not to reuse it in future
working sessions?

Though it's in essence slightly inconsistent with our policy of being
amnesic by default. We've been working with this assumption until now,
some people probably got used to it, and it otherwise didn't seem to
create a lot of noise on our help desk.

I don't know how worse it would be to not save to Persistence by default
and how much extra development work it might be worth to change this.

Another option I could think of would be to have a dedicated KeePassX
Persistence feature, to go back to a more consistent behavior. But then
I'm not sure how it should work either. Using a link trick to persist
~/keepassx.kdbx might look inconsistent as well and user might ask "Why
is this file persistent if it's not in ~/Persistent?"

All-in-all, I'm fine with forgetting about this ticket for now if the
$HOME trick might get us into more troubles.

#14 Updated by intrigeri 3 months ago

  • Target version changed from Tails_4.2 to Tails_4.3

#15 Updated by intrigeri 3 months ago

  • Duplicated by Bug #17421: Consider setting KeypassXC default folder to ~/Persistent/ added

#16 Updated by segfault 2 months ago

segfault wrote:

As the long-term solution, I think we could ask the KeePassXC maintainers to read the default database path from an environment variable.

I was just about to write a patch for that, but it turns out KeePassXC already supports configuring the default database directory via its config file since 2.4.0. Bullseye and sid both have 2.4.3, so it should be enough to install the package from one of those suites. @intrigeri, what do you think? Should I prepare a commit?

#17 Updated by intrigeri 2 months ago

I was just about to write a patch for that, but it turns out KeePassXC already supports configuring the default database directory via its config file since 2.4.0.

Great news!

Bullseye and sid both have 2.4.3, so it should be enough to install the package from one of those suites. intrigeri, what do you think?

At first glance (without testing), 2.4.3+dfsg.1-1+b1 won't be installable on Buster because of Depends: libc6 (>= 2.29). Given the list of {build,runtime}-dependencies, I expect future library ABI breaks and the corresponding transitions and binNMUs will introduce more similar uninstallability problems in the future.

So I'm afraid we need:

  • either an official backport for Buster; if the maintainers don't want to handle it themselves, then we have to do it, and commit to maintain the backport until mid-2022 in Debian
  • or a Tails-specific backport that we maintain (including a process to keep it up-to-date) in our custom APT repo
  • or we wait for Tails 5.0 to fix this problem
  • another option?

#18 Updated by anonym about 2 months ago

  • Target version changed from Tails_4.3 to Tails_4.4

#19 Updated by CyrilBrulebois 20 days ago

  • Target version changed from Tails_4.4 to Tails_4.5

#20 Updated by intrigeri 9 days ago

To move things forward a little, I volunteer to ask the maintainers of KeePassXC in Debian whether they would be ready to maintain it in buster-backports. I don't count on a positive answer, but asking won't hurt :) Makes sense?

(I don't want to walk on segfault's toes nor to ask them this question if segfault already did, hence this coordination step.)

#21 Updated by intrigeri 6 days ago

  • Target version changed from Tails_4.5 to Tails_4.6

(I doubt this would qualify for a 4.5 freeze exception.)

#22 Updated by segfault 5 days ago

intrigeri wrote:

To move things forward a little, I volunteer to ask the maintainers of KeePassXC in Debian whether they would be ready to maintain it in buster-backports. I don't count on a positive answer, but asking won't hurt :) Makes sense?

(I don't want to walk on segfault's toes nor to ask them this question if segfault already did, hence this coordination step.)

I did not contact the Debian maintainers yet. Thanks for taking the initiative!

#23 Updated by intrigeri 5 days ago

segfault wrote:

I did not contact the Debian maintainers yet.

Done! (Cc'ing segfault)

Also available in: Atom PDF