🎉 We're happy to announce #KeePassXC version 2.8.0-beta1!
This is the first test release of our next major update, which brings you an upgrade to Qt6, Auto-Type on Wayland, remote sync, ARM64 builds for Windows, and much more.
More info and download links on our blog: https://keepassxc.org/blog/2026-09-23-2.8.0-beta1-released/
@keepassxc Fascinating to see who is auditing or even using KeyPassXC.
Sep 24, 2026, 12:52 PM@taschenorakel is something wrong with @keepassxc?
@ni they added an AI policy that allows LLM assisted contributions in a way that many users, including myself, consider incompatible with security software such as a password manager.
@eltonfc @ni @taschenorakel @keepassxc Well that settles it, it's staying uninstalled. I just tried the version in trixie and it crashed as soon as the lid shut. The errors I got led me to the github issue about autotype/wayland where the dev was very dismissive. A fail on process, stability, attitude, certainly not something I can trust. Why it's in the debian repo I just don't know.
@bbuk Chipass by @whitequark et al. Is a robust non-slop fork of KeepassXC with mature QT6 support. Give it a try!
@eltonfc @whitequark @ni @taschenorakel
You have my attention, though for something so critical I'd really prefer it to be in trixie to make sure updates are applied in a timely manner and integration tested with the relevant versions of the related components.
Any plans to persuade a debian maintainer of the value of this package?
@bbuk @eltonfc @ni @taschenorakel file a debian bug!
@whitequark Thanks, but that doesn't fix the process and attitude of upstream. Switching to bsd instead to address the larger issue here.
@bbuk ? I have no idea what you're saying
@whitequark What started as the mention of a possible bug evolved to a discussion about the trust of the package given the attitude of some dev's github comments and the AI policy of the team, which was more of an issue to me than the posible bug. Switching to bsd is solving the larger (slop) problem for me.
If chipass was in trixie I'd be probably be using it now but instead I'm thankful I became inspired enough to start the bsd journey. Thanks for your hard work and sensible policies!
@bbuk what I mean is that if you file a Debian bug requesting ChiPass to be packaged, it might get picked by a Debian maintainer
@whitequark Ah, gotcha. Thought you meant file a bug against keepassxc. Thinking about it, I suspect debian wouldn't want multiple similar implementations of the same functionality and would defer to keepassxc.
Maybe the solution would be a non-ai suite like we have non-free but that would require too much work since the package/dependency overlap would be hard to administer, and while licenses are clear, ai use is not.
@bbuk I mean, you wouldn't know whether they want it or not until you file a bug...
@bbuk anyway, the upstream builds (we'll publish static Linux x86_64 binaries for the next release) have update checking, so you aren't missing much by not going with a Debian package
@whitequark Thanks but in general, I feel that such out of band update methods broaden the supplier chain attack surface of a system as well as increase the likelihood of issues between dependency versions.
@bbuk I'm a lot more confident in our ability to build a reproducible binary for all of the supported architectures than I am confident in Linux distros' ability to do so (especially now that Debian voted in favor of using LLMs)
@whitequark That's a great point. I've delegated my trust of thousands of packages to debian because it's much easier than making the thousands of trust decisions myself, which would obviously be impossible.
Which OS are you yourself using today to best incorporate the issues in "reflections on trusting trust"? Previously the smaller package numbers in bsd have discouraged me but that seems to be a winning feature now. As soon as I get to a bsd desktop I'll try out chipass!
@bbuk still Debian, but only because like all of my spare cycles are spent on helping other people escape this fresh hell (not just via ChiPass, but also git-pages and FelineBuildServices)
@whitequark When the UK started their "government digital services" approach to move away from being beholden to the likes of fujitsu and hp they chose github. I was disappointed and told them they were doing the same thing but they didn't see it at the time. They remained at the mercy of the whims of the US feds/corps and will presumably get ICC'ed in due course.
@bbuk yeah.
@whitequark I wouldn't want to waste their time considering it for little old me that really doesn't care about passkeys anyway. It has been a while since I built a deb but IIRC the starting point are some config/make files and if upstream maintain those in the source it makes the package maintainer's life much easier and so more likely to be accepted. I could be talking out of my ass though.
@bbuk Debian maintainers start with rm -rf debian/ so no it really doesn't improve things
@bbuk @eltonfc @ni @taschenorakel Which thread is that?
@keepassxc @eltonfc @ni @taschenorakel https://github.com/keepassxreboot/keepassxc/issues/2973
Whether the debug that landed me there was the result of the crash or not I don't know.
All I was after was a dead simple cli passkey manager, the GTK layout was tiny fonts/widgets and too enterprisey. Sadly the cli package doesn't support passkeys for reasons I'm not informed enough to understand. The whole browser integration concerns me though. I think I'm just opposed to the complexity of the architecture of passkeys.
@bbuk @eltonfc @ni @taschenorakel That thread is 8 years old. Back then, Qt had very buggy Wayland support. KeePassXC 2.7.12 and 2.8.0 are much more stable in that regard, as they use Qt 5.15 and Qt6, respectively. You may have come there with the "Wayland does not support QWindow::requestActivate()" message, but that's just a Qt-internal warning, not an error. We don't know of any "lid-close" crashes at the moment, so we'd need more info to help you.
@bbuk @eltonfc @ni @taschenorakel Passkeys are not supported by the CLI, because they require an established browser connection, and thus a permanent background session. Since the CLI doesn't provide that, it cannot support passkeys.
@keepassxc @eltonfc @ni @taschenorakel Well I feel that speaks to the over-complexity of the architecture (of passkeys, not your app). What kind of session, DBUS? ssh-agent seems to play nice with seahorse or whatever the gnome passphrase dialog is, is that kind of capability not usable?
And sorry if I'm over-tagging people, just using the defaults, believe it or not I'm new to mastodon and social media in general.
@bbuk @eltonfc @ni @taschenorakel KeePassXC needs to be running in the background to respond to requests for passkeys. A CLI application doesn't do that, typically. We have an interactive CLI mode, but it doesn't have passkey support at the moment, as that would duplicate a lot of functionality.
Oct 13, 2026, 7:22 PM@keepassxc @bbuk @eltonfc @taschenorakel could you please stop mentioning me, I’m not interested in this debugging. :3
thanks. ^^
@keepassxc @eltonfc @ni @taschenorakel No worries, maybe it got OOMed, maybe I've got bad RAM, thanks for providing a passkey solution anyway. The AI use here is the big no for me though. I'm fine with passwords and 2FA, KISS FTW. And the last comment was 2024, so the issue appeared to me to be still relevant and ongoing for 8 years.
@bbuk @eltonfc @ni @taschenorakel The last comments are only about cosmetic mismatches between a KDE6 desktop and the Qt5 app.
As for AI use, see https://keepassxc.org/blog/2025-11-09-about-keepassxcs-code-quality-control/
@taschenorakel I'm sorry, that statement does nothing to allay my fears. I don't accept that AI for code is inevitable, necessary, stable between releases, deterministic, or particularly useful. I'll prefer code that is developed only by humans even if it takes a little longer. It has worked fine for 70 years. I don't believe you will draw the line correctly, or that that line will stay in place, be honoured by all developers, or that those developers will remain as competent because of it.
Sep 23, 2026, 3:38 PM@keepassxc This is great news!
@keepassxc I was told Auto-Type on #Wayland was just "impossible" to implement, due to Wayland restrictions "for security".
@ciencia It used to be, but with the remote desktop portal, it's possible now. We basically start a local "remote" control session. We still don't get the window names for automatic entry matching, but we can send keystrokes at least. How well it works is still very desktop-dependent, though. Especially if you use an older KDE or Gnome, you might encounter strange bugs.
@keepassxc @ciencia not sure if I can test that beta regarding the wayland change - for Fedora SWAY I downloaded the appimage version, but I can't see the "auto-type" plugin in application settings. Anything to be done in addition here?
@old_school @ciencia Will check.
@old_school @ciencia Auto-Type works out of the box only for mainstream desktop environments like KDE and Gnome and the moment. For an alternative window manager like Sway you need to use Pyrtal to make the remote desktop work: https://github.com/hifi/xdg-desktop-portal-pyrtal
@keepassxc @ciencia thanks following up on my request. I will check out this standalone portal once I have time to analyze all the dependencies of it - for now I'm happy they way I can use the browser integration
@keepassxc @ciencia Will it be extended to other main DE? Not everybody uses GNOME or KDE. And what about use via Browser extension, is that already supported, and if not, are there any plans to implement it? People using Passkeys will find the extension useful.
@Schimmelreiter @ciencia The DE must support the remote desktop portal spec. Not all do.
@keepassxc Looking forward to it :)