EDIT: Lol, it doesn’t actually work +___+ It is enabled in KeepassXC but it just doesn’t do anything. Welp.
Here’s a neat trick I just found out (with a hint from here):
In Wayland you can’t use KeepassXC’s very cool Auto-Type feature (it’s somehow Qt’s fault?) but if you installed it as a Flatpak you can go into KDE Settings, search for “Flatpak Permission Settings” and in the settings for KeepassXC under “Advanced” you can disable “Wayland Windowing System” to make it work. Nice!
Using the environment variable QT_QPA_PLATFORM=xcb should do the same thing, but it likely won’t fix your problem. These two methods allow KeepassXC to run on X11, which lets it access other X11 apps (running on XWayland), meaning native Wayland apps still won’t be able to use auto-complete.
There’s probably no way around this for now, as this is due to Wayland’s design, which has stricter keyboard access safety, as opposed to X11 which just let all apps read/use the keyboard all the time.
Yeah, I read the QT_QPA_PLATFORM=xcb as well but never saw where and how I do that, do you know?
It has to be added to the command when you want to launch it, or added to the .desktop file so it does so automatically. On KDE, it should be as easy as right clicking it on the start menu and clicking “edit application” on the second tab there should be a command field, where you can add the variable at the beginning.
In case this doesn’t fix it, your alternatives are copying and pasting passwords or, if your main use for it is in a browser, using the official extension.
Cool, thanks, I’ll try that out! Could not get browser integtstion to work, the Firefox-addon didn’t see the database (maybe another security/sandbox thing?)
Browser integration works on my machine, which also uses Wayland, so unless you’re, say, running Firefox from a flatpak or something, I don’t see why it shouldn’t work.
This is because Wayland doesn’t allow it to read window titles. Keepass and KeepassXC uses the window title to identify which entry to use. If you have no title, you can’t find the entry. That’s why it will not work with Wayland and never will work, until Wayland allows it to read window titles.
XWayland, which is forced with your workaround, is not Wayland.
That’s at least for me, the main reason not to switch to Wayland. I have no idea why Wayland doesn’t allow reading window titles. There is absolutely no security or performance benefit of this behavior. For me it’s either a bug or a design failure. Or simply bad behavior.
With how easy it is to change window titles, I’m surprised this feature ever made it into Keepass in the first place. Surely it also tries to do some kind of executable matching, right?
With the lack of proper window security and the ability for applications to snoop on each other’s messages, I have strong doubts about the security of such a mechanism.
As for why Wayland disallows reading other windows’ anything: Wayland was designed so that the window manager manages the windows, and to no longer provide one big common pool of windows and controls that can all muck about with each other. Other operating systems have used variants of this mechanism for years for security reasons (for example, Windows keyloggers can’t capture the password you type into the UAC prompt like the more naive X prompts will let you, and low integrity processes like the stuff launched from an exploited browser don’t get access to high integrity processes like control panel).
I understand why you may disagree with this design, and I’m sure X11 will stick around for the coming few years despite most X developers now working on Wayland and X being put in maintenance mode.
Perhaps it’s interesting to note that there is a relatively easy way to query open windows in Gnome through the DBUS API, by running a piece of extension script. I suppose someone could write a KDE plugin that exposes an API for applications as well. Don’t count on any of this making it into a stable API, though.
That window titles can be easily changed is quite true, so all applications I know monitor such changes and abort the autotype on request when a change is made. But as already said, this is not a security feature, at least not a useful one.
Monitoring the application itself makes no sense for a password manager. As you write yourself, it’s easy to customize the title. All applications make use of this. It is already changed when the tab in the browser changes, a new page is loaded or similar. The same is true for non-browser applications. Windows also allows read access to window titles.
What the Wayland developers do is, in my opinion, gross mischief or ignorance regarding window titles. The password manager needs a simple way to assign a window to an entry, which should be the same for all applications. This should be the same for all DE’s, window managers and OS. The simplest is the window title. The status bar makes no sense and an API would have to be the same or at least similar across all DE’s, window managers and OS. Such a thing does not exist. To implement something like that only for KDE is too niche. This would have to be implemented and established, if already for the broad mass. So also for Gnome, Mate, Cinnamon and all the others. Not to forget, this must also work for Windows and MacOS in a similar way.
I disagree, I have full trust in the intentions and design capabilities of the Wayland developers. The core of them also developed X.org, after all.
I do agree that there should be some standard way applications should be able to provide accelerators to specific application, but copying things like window titles and X specific APIs is the wrong approach.
Wayland has the Foreign toplevel list protocol to get application IDs for every top level window. I think that API should provide ample capabilities to a password autofill service. It even provides window titles (not useful for matching applications, but very useful for picking default names for newly created entries and audit logs). It doesn’t provide access to windows in the background, but that sounds like a good design decision to me; I can’t think of a reason to password fill a background window.
I absolutely never trust blindly in such things. I have never seen a plausible explanation why this is a security feature.
When there are dev’s from X11 involved, this is fine and it seems that this leads to decisions which prevent from current X11 issues. But it absolutely is no guarantee that everything is trustable. I’m not that expert, but your mentioned link points in the right direction. But as long this isn’t supported in the wide mass, it’s only a wish…
I ran in to this problem in the past when I was testing Wayland out. Here is the solution that worked for me:
- Append
-platform xcbto the end of your keepassxc autostart entry, or start keepassxc with this tagged on the end from a terminal and it should work.
This was months ago now though and I don’t use Wayland regularly.
- Append
Disable wayland means it runs through XWayland. I guess autotype will then also only work in other XWayland apps. Which means that isolation between all these apps is gone.
The old security vs ease-of-use problem. It’s kinda a hassle to copy-paste all this logins and passwords (haven’t done it in a long time). Switched to Wayland now because gaming seems to be better (had some nasty screen-tearing on Xorg and possible borked my monitor setup while trying to fix it).
It will get better, but controlled. Through portals, with permissions and all.
Not having autotype is for me the reason not to switch to Wayland, too. I don’t only have passwords for websites stored in KeepassXC - otherwise it wouldn’t be a problem with the Firefox addon. Copy & paste of passwords into e.g. the console can’t be better security. I wouldn’t mind if autotype would work in general and one has to choose the corresponding entry manually without automatic matching to the current window. But even autotype into the last active window doesn’t work.
