https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
> To be very honest here, you risk having KeePassXC blocked by relying parties
This threat, because someone dared to give users control, is completely unacceptable to me.
In Passkeys are not a trapkeepassxreboot
keepassxc
C++2017–2026
keepassxreboot / keepassxc
keepassxc
KeePassXC is a cross-platform community-driven port of the Windows application “KeePass Password Safe”.
147Distinct people
211Mentions
2Explicit recommenders
30KGitHub stars
What to know before exploring
What it is
KeePassXC is a cross-platform community-driven port of the Windows application “KeePass Password Safe”.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I love that the "big guys" get to support syncing passkeys between devices... but others don't (wasn't it KeePas who had issues where they were threatened by being blocked from…
FireBeyond used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- keepassx/keepassx · linked in 2 of the same discussions
- kunzisoft/keepassdx · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year211 dated mentions
Observed mentions: 2017-01-19 23:33:12 UTC to 2026-10-14 23:38:36 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 19 | 1 | 18 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 24 | 2 | 22 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 47 | 3 | 44 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 45 | 0 | 45 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 37 | 0 | 37 |
From the project README
An excerpt from the repository, fetched Nov 12, 2026.
Read the project’s introduction
KeePassXC
KeePassXC is a modern, secure, and open-source password manager that stores and manages your most sensitive information. You can run KeePassXC on Windows, macOS, and Linux systems. KeePassXC is for people with extremely high demands of secure personal data management. It saves many different types of information, such as usernames, passwords, URLs, attachments, and notes in an offline, encrypted file that can be stored in any location, including private and public cloud solutions. For easy identification and management, user-defined titles and icons can be specified for entries. In addition, entries are sorted into customizable groups. An integrated search function allows you to use advanced patterns to easily find any entry in your database. A customizable, fast, and easy-to-use password generator utility allows you to create passwords with any combination of characters or easy to remember passphrases.
Quick Start
The QuickStart Guide gets you started using KeePassXC on your Windows, macOS, or Linux computer using pre-compiled binaries from the downloads page. Additionally, individual Linux distributions may ship their own versions, so please check your distribution's package list to see if KeePassXC is available. Detailed documentation is available in the User Guide.
Features List
KeePassXC has numerous features for novice and power users alike. Our goal is to create an application that can be used by anyone while still offering advanced features to those that need them.
Core Features
Create, open, and save databases in the KDBX format (KeePass-compatible with KDBX4 and KDBX3)
All information is encrypted at rest and never exposed outside the program
Store sensitive information in entries that are organized by groups
Password generator
Search for entries
TOTP storage and generation
YubiKey/OnlyKey challenge-response support
Auto-Type passwords into applications
Browser integration with Google Chrome, Mozilla Firefox, Microsoft Edge, Chromium, Vivaldi, Brave, and Tor-Browser
Support for passkeys using the browser integration
Entry icon download
Import databases from CSV, 1Password, Bitwarden, Proton Pass, and KeePass1 formats
Advanced
Database reports (password health, HIBP, and statistics)
Database export to CSV, XML, and HTML formats
TOTP storage and generation
Field references between entries
File attachments and custom attributes
Entry history and data restoration
Command line interface (keepassxc-cli)
SSH Agent integration
FreeDesktop.org Secret Service (replace Gnome keyring, etc.)
Additional encryption choices: Twofish and ChaCha20
For a full list of changes, read the CHANGELOG document.
For a full list of keyboard shortcuts, see KeyboardShortcuts.adoc
Building KeePassXC
Detailed instructions are available in the Build and Install page and in the Wiki.
Contributing
We are always looking for suggestions on how to improve KeePassXC. If you find any bugs or have an idea for a new feature, please let us know by opening a report in the issue tracker on GitHub, or join us on Matrix community channel or Matrix development channel, or on IRC in Libera.Chat channels #keepassxc and #keepassxc-dev.
You may directly contribute your own code by submitting a pull request. Please read the CONTRIBUTING document for further information.
Contributors are required to adhere to the project's Code of Conduct.
Generative AI
Generative AI is fast becoming a first-party feature in most development environments, including GitHub itself. If the majority of a code submission is made using Generative AI (e.g., agent-based or vibe coding) then we will document that in the pull request. All code submissions go through a rigorous review process regardless of the development workflow or submitter.
License
KeePassXC code is licensed under GPL-2 or GPL-3. Additional licensing for third-party files is detailed in COPYING.
Read the full README on GitHubWhat Hacker News says
211 sourcesMuch like you could use any AOSP fork to run banking applications... until you couldn't. But hey, at least there's an explainer website[0] that completely glosses over this detail.
[0]: One great bit of environmental storytelling is the "Made with <3 by the passkey community" in the footer. "Passkey community" of course means timcappalli with minor contributions from two others. You might remember him from https://github.com/keepassxreboot/keepassxc/issues/10407#iss....
In Passkeys are not a trap> sharply restricting -if not preventing- freedom to sync the attested credential
They already did that! That was the first round! It is only through community outcry that "Credential Exchange Format (CXF)" came to existence.
https://github.com/keepassxreboot/keepassxc/issues/10407
This one is specifically about 1Password: https://news.ycombinator.com/item?id=37836783
There was a similar thing about what Google did with Android (basically making only the built-in manager viable, for a while), but I can't find a good link.
In Passkeys are a trapI was expecting the author to at least address the thinly veiled threat to blacklist KeePassXC at [0] (via the very same mechanism they claim is harmless), but of course it's not even mentioned.
I'm sorry, but if your system allows someone to make a credible threat like this, you should make sure to redesign your protocol so that kind of abuse is not possible BEFORE advocating for it. I'm so incredibly sick of people repeating history, only to disappear once we're all roped into yet another anti-user scheme.
And yes, passkeys absolutely ARE a trap.
[0]: https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
In Passkeys are not a trapThe cauldron is already warm. I encourage people to read these issue trackers.
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
https://github.com/keepassxreboot/keepassxc/issues/10406
"The unfortunate piece is that your product choices can have both positive and negative impacts on the ecosystem as a whole. 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)."
"This implementation is not spec compliant and has the potential to be blocked by relying parties."
Proponent
Read the rest
s 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.
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
In Passkeys are not a trapThis is a violation of the spec you cited above and criticized by FIDO devs here:
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
In Passkeys are a trap> for both a format and secure protocol
No, there is a working draft of a protocol. The "format" is only for use in the protocol, not a separate thing. Thus, giving the user a file is disallowed under the spec as per §5.1.1.1 which reads
> Explicitly state that the orchestrating party only transmits the credential exchange data between the exporting provider and importing provider.
And, in accordance with the spec, 1Password refuses to export passkeys directly to users for manual import on another platform or app. FIDO developers have complained about Keepassxc violating the spec and threatened to blacklist them as a result[1].
Furthermore, 1Password (who is apparently leading the way on the FIDO exchange protocol design) has not implemented _any_ passkey export on _any_ desktop platform.
It is interesting that you listed Bitwarden, si
Read the rest
nce I believe that FIDO developers have specifically disavowed Bitwarden's behavior of allowing users to access their passkeys.
[1] https://github.com/keepassxreboot/keepassxc/issues/10407
[2] https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
That's not a fair reading of that comment, in my view (assuming you mean https://github.com/keepassxreboot/keepassxc/issues/10407#iss...).
I read it as "your actions might push relying parties to use attestation to be able to block you", not as "we, the FIDO consortium will block you". (How could they? There's no signer identity to block without attestation!)
That said I don't agree with the substance of the comment; it's effectively an appeal to security by obscurity/unavailability of user-friendly insecure export methods.
In Ricky Mondello responds to "Passkeys are a trap. Do not use them.">if they didn't remove sharing/export functionality that Google, Apple and others had at the same time.
This is factually incorrect — no one supported exporting passkeys at the time and I believe the only ones who supported passkey sharing of any kind was Apple: https://support.apple.com/guide/iphone/share-passwords-iphe6...
What that Keepass X GitHub PR comment section was discussing was giving users a way to export their passkeys to an unencrypted file on disk, which would have allowed for attackers to convince non-technical users to export all their passkeys and then send them to an attacker.
I believe person who commented on that GitHub PR was trying to explain that instead of implementing export to plaintext file on disk, it would be a better idea to implement the Credential Exchange Protocol, which was almost finished at the time.
h
Read the rest
ttps://fidoalliance.org/specs/cx/cxp-v1.0-wd-20240522.html
Fast forward to today... and it looks like there's movement towards doing exactly that:
https://github.com/keepassxreboot/keepassxc/pull/13343
--
Edit: Indeed if you scroll down to the last comment on that infamous PR (https://github.com/keepassxreboot/keepassxc/issues/10407#iss...), you'll see they closed it in favor of implementing the Credentials Exchange standard.
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://github.com/keepassxreboot/keepassxc/issues/10406
In Passkeys are a trapThis 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).
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
They need to remove attestation from the spec. Instead of promising no one will ever use
Read the rest
it, just get rid of it and solve the problem.
This is where the attestation feature comes in, there's a reason it was part of the initial spec and key transfer was a "we'll get to it later". They will use it as a weapon to blacklist providers that don't play by their rules.
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
https://github.com/keepassxreboot/keepassxc/issues/10406
In Passkeys are a trapThis is only true until the vise closes all the way, they likely implemented it that way because they will eventually HAVE to:
"Once certification and attestation goes live, there will be a minimum functional and security bar for providers."
https://github.com/keepassxreboot/keepassxc/issues/10406
In Passkeys are a trapShowing the 15 most recent of 211 sources. Enable JavaScript to search and browse every indexed mention.