Tails

#1 Updated by segfault 2019-12-01 20:25:30

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.

#3 Updated by segfault 2019-12-02 08:23:58

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 2019-12-02 08:31:30

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

#6 Updated by segfault 2019-12-02 23:52:20

The branch is based on the one from Bug #17212.

#13 Updated by sajolida 2019-12-18 11:08:57

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.

#16 Updated by segfault 2020-01-22 15:15:56

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 2020-01-25 13:14:15

> 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?

#20 Updated by intrigeri 2020-03-23 06:59:12

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.)

#22 Updated by segfault 2020-03-26 19:40:33

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 2020-03-27 10:38:41

segfault wrote:
> I did not contact the Debian maintainers yet.

Done! (Cc’ing segfault)