Tails

#2 Updated by intrigeri 2018-02-10 06:31:52

KeePassX 2.1 will support Qt5 but that’s been in upstream Git for 2.5 years and not released yet. So:

• if KeePassX 2.1 is in Buster: we’ll need to decide purely based on other factors, e.g. UX and cost/benefit of the migration (doc update, possibly migrating data & persistence config, changing users’ habits), integration with the rest of the system and so on
• if KeePassX in Buster does not support Qt5: we’ll need to decide based on the aforementioned factors + the benefits of dropping Qt4 from the ISO + the advantages of shipping a Qt5 password manager (e.g. better accessibility IIRC but I didn’t try recently)

#4 Updated by jvoisin 2018-02-27 21:35:36

We might want to wait a bit for its codebase to stabilize a bit before considering a move, to avoid issues like bringing down the WiFi or corrupting password databases .

#5 Updated by intrigeri 2018-02-28 08:47:50

> bringing down the WiFi

FTR this one is caused by a Qt bug and only affects OS X. But regardless, we’ll want to disable favicon fetching if we switch to KeePassXC. And even disallow network access to KeePassXC once AppArmor supports this in Linux mainline.

> or corrupting password databases .

That one is caused by a bug in a beta version of Qt so IMO it is no indication of KeePassXC’s codebase maturity.

#6 Updated by sajolida 2018-03-14 15:36:50

I talked to several people at IFF who were really enthusiastic about KeePassXC as a new active replacement of KeePassX. Two cool features were mentioned to me: diceware passphrase (original code by @micahflee) and two-factor authentication seeding.

#8 Updated by micahflee 2018-07-27 10:12:07

I would love for Tails to switch from KeePassX to KeePassXC. The main reason is KeePassX is a completely abandoned project now, and KeePassXC includes all the same features as well as several new genuinely useful features.

One of these is a Diceware passphrase generator instead of just a random character password generator. (I actually developed the Diceware generator for KeePassX and made a pull request, but because KeePassX is a dead project it got ignored. The KeePassXC project ultimately merged my feature into their project and have since improved the usability.) Another awesome feature is supporting requiring a Yubikey for challenge/response to unlock your passwords.

Also, both of the cited KeePassXC issues above are now closed, btw.

#9 Updated by intrigeri 2018-07-28 03:32:49

Any suggestion wrt. how to handle a pre-existing persistent KeePassX database? More specifically:

• does KeePassXC use the same directory to store its data?
• does KeePassXC automatically import (and if needed, convert) data from KeePassX? if not, is there a way for users to do this manually via a GUI?

#10 Updated by micahflee 2018-07-28 08:17:05

KeePassX and KeePassXC both have (I believe) config files in separate folders. But they deal with the .kdbx password databases in the same way, and they use the exact same format. So it should be simple, you can just load your old KeePassX database in KeePassXC and it will “just work”.

#11 Updated by intrigeri 2018-07-28 09:34:10

> KeePassX and KeePassXC both have (I believe) config files in separate folders. But they deal with the .kdbx password databases in the same way, and they use the exact same format. So it should be simple, you can just load your old KeePassX database in KeePassXC and it will “just work”.

OK. It would be sweet if someone particularly interested in this proposal figured out a nice way to handle this automatically on upgrades. Starting points:

• The Git history of config/chroot_local-includes/usr/local/sbin/live-persist has examples of how to migrate persistence settings (to deal with the new directory name).
• config/chroot_local-includes/usr/local/bin/keepassx is a wrapper that handled KeePassX 1.x → 2.x migration.
• We need a KeePassXC config file that achieves the same as config/chroot_local-includes/etc/skel/.config/keepassx/keepassx2.ini wrt. making data loss hard and initial config easy, i.e. when saving the DB for the first time, a standard filename in the standard persistent directory is pre-selected.

#15 Updated by hefee 2019-01-04 11:01:50

A good starting point:
https://tails.boum.org/doc/encryption_and_privacy/manage_passwords/index.en.html

and this would be needs to updated if switching to KeePassXC.

#16 Updated by hefee 2019-01-04 11:08:37

intrigeri wrote:
> * The Git history of config/chroot_local-includes/usr/local/sbin/live-persist has examples of how to migrate persistence settings (to deal with the new directory name).
> * config/chroot_local-includes/usr/local/bin/keepassx is a wrapper that handled KeePassX 1.x → 2.x migration.

so far the fileformat hasn’t changed so we don’t have to update the files itself. I see no need to rename the file to keepassxc.kdbx. Maybe do a backup before starting keepassxc the first time, just in case?

> * We need a KeePassXC config file that achieves the same as config/chroot_local-includes/etc/skel/.config/keepassx/keepassx2.ini wrt. making data loss hard and initial config easy, i.e. when saving the DB for the first time, a standard filename in the standard persistent directory is pre-selected.

the config file is now keepassxc and we can archive the same:
q
config/chroot_local-includes/etc/skel/.config/keepassxc/keepassxc.ini

#17 Updated by hefee 2019-01-04 11:33:01

There is a new kdbx 4:

https://keepass.info/help/kb/kdbx_4.html

KeePassX and KeePAssXC supports both kdbx 3.1

You need to update to this format by hand by switching Encryption Algorithm to “ChaCha20”, and the Key Derivation Function to “Argon2”:

https://keepassxc.org/docs/#faq-security-kdbx4
https://theorangeone.net/posts/keepassxc-2.3-migration/#kdbx4

#18 Updated by intrigeri 2019-01-04 13:50:36

> so far the fileformat hasn’t changed so we don’t have to update the files itself.

Great!

> I see no need to rename the file to keepassxc.kdbx. Maybe do a backup before starting keepassxc the first time, just in case?

Good idea. And drop the migration code we had for Tails 2.x → 3.x.

>> * We need a KeePassXC config file that achieves the same as config/chroot_local-includes/etc/skel/.config/keepassx/keepassx2.ini wrt. making data loss hard and initial config easy, i.e. when saving the DB for the first time, a standard filename in the standard persistent directory is pre-selected.

> the config file is now keepassxc and we can archive the same:
> config/chroot_local-includes/etc/skel/.config/keepassxc/keepassxc.ini

Looks like we don’t suggest making that file persistent so perhaps there’s nothing more to do :)