keepassxreboot/keepassxc

KeepassXC (a must-have application and dealbreaker) is still broken on Wayland. The recommended "solution" is to edit the .desktop file to resemble the following: QT_QPA_PLATFORM=wayland ECORE_EVAS_ENGINE=wayland_egl ELM_ENGINE=wayland_egl SDL_VIDEODRIVER=wayland _JAVA_AWT_WM_NONREPARENTING=1 keepassxc https://github.com/keepassxreboot/keepassxc/issues/2973

KeepassXC at least allows you to export your passkeys should you choose. The people behind passkeys do not like this. https://github.com/keepassxreboot/keepassxc/issues/10407

If you want to see an example of pro-user behavior, read the github thread where a FIDO developer asked keepassxc to disallow exports of passkeys[1] or to reprompt for the db password if the website requests it[2]. The conversation was roughly: > keepassxc: no > FIDO devs: but the spec > keepassxc: that part of the spec is anti-user > FIDO devs: do it or we might blacklist your app > keepassxc: can't we just impersonate another password manager? also isn't bitwarden already doing this? > FIDO devs: "Someone else is doing bad things too" isn't the greatest argument... > FIDO devs: maybe we could hop on a phone call? [1] https://github.com/keepassxreboot/keepassxc/issues/10407 [2] https://g…

…fication" (the software must force user interaction) and not allowing the user to access the plaintext keys. It appears that the spec authors do not consider the keys to be owned by the user at all. KeepassXC implements passkey support, but they do not implement these anti-user features. As a result, they are being threatened with being banned via attestation: https://github.com/keepassxreboot/keepassxc/issues/10406 https://github.com/keepassxreboot/keepassxc/issues/10407 Screw these "You'll own nothing and be happy" people. I'll own all my keys no matter what. The software I run on my device should never betray me to signal things like "this passkey is allowed to be backed up!".

…e lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations)." "This implementation is not spec compliant and has the potential to be blocked by relying parties." Proponents keep trying to hand wave away the attestation lock-in problem as some vague faraway threat that we may never encounter. It isn't. It's the actual plan.

This is a violation of the spec you cited above and criticized by FIDO devs here: https://github.com/keepassxreboot/keepassxc/issues/10407#issuecomment-1994923493

This is a pretty unconvincing argument. It's just one guy saying "trust me, no one will abuse this." It's especially unconvincing when you've got this other Passkey dev directly contradicting it: > To be very honest here, you risk having KeePassXC blocked by relying parties. ... I've already heard rumblings that KeepassXC is likely to be featured in a few industry presentations that highlight security challenges with passkey providers, the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations). htt…

Yeah they're really trying to solve problems that should be solved at a technical level with soft solutions in porcelain. See also this issue asking keepassxc to disable plaintext exports, which is completely technically feasible https://github.com/keepassxreboot/keepassxc/issues/10407

KeePassXC is not for a "normal" user. It really needs to get default entry tempates [1] out the door. [1] https://github.com/keepassxreboot/keepassxc/issues/8228