Flatpak version not recognised by official KeePassXC-Browser

[diogogomes]

Version: 2.3.0
**OS:**Xubuntu 16.04

Error: Timeout or not connected to KeePassXC

Description:
KeePassXC is dropping support to KeePassHTTP-Connector and implementing KeePassXC-Browser.

KeePassHTTP-Connector worked like expected on flatpak version but KeePassXC-Browser do not recognise that flatpak version is open.

(Sorry create this issue here but I think that is related with flatpak container permissions. Tell me if I should open an issue on KeePassXC-Browser browser. Thanks)

[AsavarTzeth]

Thank you for reporting this, I suspect you are correct about permissions and did the right thing informing me here.

KeePassXC 2.3 brought a lot of changes to the optional features in the application. Unfortunately, due to a lack of time, I could not test them all at the time. I will look closer into this, and see if it is possible to get it to work.

[diogogomes]

Thanks for your answer @AsavarTzeth.

I'll use deb version until there.

Unfortunately, due to a lack of time, I could not test them all at the time.

Please mention @diogogomes if you need any help to test on xubuntu 16.04, it will be my pleasure.

Thanks

[diogogomes]

I tried the command that @Alexander-Wilms suggested and I got multiple errors.

Do you need the entire log or only the errors?

I also got Cannot encrypt message or public key not found. Is native messaging or support for your browser enabled in KeePassXC? on browser plugin and I don't know if is related.

[AsavarTzeth]

qdbus org.keepassxc.MainWindow /keepassxc org.keepassxc.MainWindow.lockAllDatabases
Service 'org.keepassxc.MainWindow' does not exist.

This seems to be an unrelated bug that needs to be patched. The application id is org.keepassxc.KeePassXC and based on my understanding they need to use the full id as a prefix, everywhere.

Edit: I tried using the correct id and it works. The wiki is simply not updated. Since the wiki is not accessible to the public I will file an issue.

[AsavarTzeth]

So after a lot of research, trial and error I have managed to get this working, with some manual workarounds. Unfortunately I cannot make this work automatically out of the box, but I can patch things so some of these steps are not necessary.

1. Once a browser extension is launched it attempts to connect via the Native Messaging API. It essentially means that using the command line, the browser executes the native application and it communicates via stdio (stdin/stdout).

2. This causes problems if, for example, KeePassXC is already open. To prevent potentially losing unsaved changes to a database, a proxy (keepassxc-proxy) is used.

   • Communication with the browser extension uses, the Native Messaging API (stdio)
   • Communication with KeePassXC itself uses a unix socket. This socket is provided when keepassxc is launched.

   The first thing I had to patch is where the UNIX socket is located. By default it will listen on:
   $XDG_RUNTIME_DIR/kpxc_server
   and fallback to:
   /tmp/kpxc_server
   To make it work with Flatpak it needs to listen on:
   $XDG_RUNTIME_DIR/app/org.keepassxc.KeePassXC/kpxc_server.
   As usual this is meant to ensure there are no conflicts with other applications. This is easily fixed with a patch. No --filesystem=xdg-run/app/org.keepassxc.KeePassXC is required.

3. There are still some issues though. KeePassXC will inform the browser extension that the proxy is available at /app/bin/keepassxc-proxy. This is false, since that is only available inside the KeePassXC sandbox.

   You can work around this in KeePassXC by navigating to Tools > Settings and configuring a custom proxy location. This brings us to the last issue.

4. As of Export binary wrappers for easier CLI use flatpak/flatpak#1254 (see related issue Improve cli application experience flatpak/flatpak#1188) it is possible to use a single command as a wrapper for flatpak run. However, this only works for the main command, not a second one, i.e. keepassxc-proxy.

   The way I worked around this was by manually creating my own wrapper which I called org.keepassxc.KeePassXC.Proxy and making it available to $PATH.

   Substitute --branch=master and --arch=x86_64 as necessary.

   #!/bin/sh
   exec /usr/bin/flatpak run --command=keepassxc-proxy --branch=master --arch=x86_64 org.keepassxc.KeePassXC "$@"
   

Unless I have missed something, the only way I could even possibly make this work out of the box is by shipping keepassxc-proxy as its own application. That and maybe finding some way to patch KeePassXC so that informs the browser about the wrapper instead of /app/bin/keepassxc-proxy. Although that would not work if the browser is sandboxed as well.

At this time what I can do is push a patch that fixes the UNIX socket location, but that is about it.

[shieling]

I have also come across this problem and have searched for a solution. When I could find no solution I found this forum - thanks for clarifying the issue. As a hobbyist I am not sure I fully understand your workaround but will look forward to any progress made on this issue. Thanks.

[AsavarTzeth]

Well this isn't meant to be a self-help guide for anyone inexperienced with flatpak. It´s mainly meant for myself and other flatpak maintainers. I simply meant to document the issue in more detail.

If you are familiar with building and maintaining a flatpak, is there any section in particular you found unclear? Perhaps I could improve it?

[shieling]

Thank you for the quick response. I am not familiar with maintaining a flatpak, but was pleased that the problem I encountered has been recognized and thought about. In the meantime, like diogogomes , I will stick with the deb version - just a shame that the deb install is only at version 2.3.0 and not 2.3.1.

[diogogomes]

@AsavarTzeth Thank you for your effort trying to solve this problem.

I've found that most of the issues can be related to the extension because I'm having the same problem with the Deb package.

You can close it if you want and I open another one if this problem persists after Deb package is fixed.

[AsavarTzeth]

That is strange, most if not all, issues listed here actually are specific to a sandboxed environment. It should not occur with a regular debian package. In any case, I would like this issue to remain open.

Feel free to inform me if they make any greater or fundamental redesigns of the extension.

[diogogomes]

@AsavarTzeth I use containerised tabs on Firefox (I forgot to mention). Maybe that it's the reason for my issues with the extension.

I'll provide more updates about this issue. Thank you

[diogogomes]

Just to leave here the issue of KeePassXC that may be related to this:

Unable to connect to KeePassXC-Browser

[diogogomes]

@AsavarTzeth, after last updates on deb version and Firefox plugin, the integration started worked without any issues but this situation persists on the Flatpak version.

[AsavarTzeth]

Fixed in 934f25a.

Things should just work most of the time. However there are some conditions (see commit message).

By default Flatpak uses the system-wide install (--system). In that case things should just work.

If one installs the app with --user (user specific installation) then you will have to enter a custom proxy path within the application, ex. in this case /home/<your_user_name>/.local/share/flatpak/exports/bin/org.keepassxc.KeePassXC.

Let me know if you have any issues.

[varjolintu]

By default Firefox will start KeePassXC which is not the correct behaviour.
To fix this and use keepassxc-properly, please see keepassxreboot/keepassxc-browser#297 (comment).

The solution is basically the same one at step 4 #13 (comment).

[rugk]

FYI, for everyone following: I have found a working around involving some manual steps you need to do though for KeePassXC<->Firefox communication, if Firefox is flatpaked/sandboxed (works if KeePassXC is sandboxed or not). Read the full write-up/tutorial here.