Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KeePassXC-browser native messaging does not work with flatpak #92

Closed
oidualc opened this issue Aug 24, 2018 · 14 comments
Closed

KeePassXC-browser native messaging does not work with flatpak #92

oidualc opened this issue Aug 24, 2018 · 14 comments

Comments

@oidualc
Copy link

oidualc commented Aug 24, 2018

Subject of the issue

KeePassXC-Browser is unable to connect to KeePassXC, likely a problem with Native Messaging.
Probably relevant, the needed file org.keepassxc.keepassxc_browser.json is available in ~/.mozilla/native-messaging-hosts, but not in ~/.var/app/org.mozilla.FirefoxNightly/.mozilla. In fact the directory native-messaging-hosts is missing.

Environment

  • Arch Linux
  • Firefox Nightly (flatpak)
  • KeePassXC (flatpak, from dl.flathub.org)

Steps to reproduce

Assuming the availability of a working instance of KeePassXC, install the KeePassXC-Browser addon and try to connect.

Expected behaviour

After having verified that on Firefox Nightly (non-flatpak) the extension works correctly, try to connect using Firefox Nightly (flatpak) and expect it working the same way.

Actual behaviour

On Firefox Nightly (non-flatpak) the extension works as intended, on Firefox Nigthly (flatpak) the error message is "Timeout or not connected to KeePassXC".

@wvengen
Copy link

wvengen commented Sep 10, 2018

You may be able to expose native-messaging-hosts e.g. by hardlinking the file to the ~/.var/... path:

ln ~/.mozilla/native-messaging-hosts ~/.var/app/org.mozilla.FirefoxNightly/.mozilla/native-messaging-hosts

Or perhaps use the --persist option to flatpak run to expose this file.

Perhaps the cleanest way would be to be able to pass some kind of --socket=keepassxc option to flatpak run, and let flatpak understand that option to expose the socket. I'd try my luck with the other options first.

@oidualc
Copy link
Author

oidualc commented Sep 10, 2018

Hi @wvengen, unfortunately I cannot hardlink native-messaging-hosts because it's actually a directory, not a file. The closest thing I can think is:

mkdir ~/.var/app/org.mozilla.FirefoxNightly/.mozilla/native-messaging-hosts
ln ~/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json ~/.var/app/org.mozilla.FirefoxNightly/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json

but even like this it doesn't work.

With regard to the --persist and --socket=keepassxc options I don't know enough about flatpak to understand what I could try.

@kaymio
Copy link

kaymio commented Feb 1, 2019

Hi @oidualc @wvengen ,

has someone achieved any progress on this front. My setup is very similar.

Arch + flat FF DevEdition + flat KeePassXC
I know that my KPXC instance is working correctly because my natively installed FF works just fine with the flatKPXC.

@rugk
Copy link

rugk commented Feb 1, 2019

@oidualc Can we maybe change the title of this issue to something like "KeePasssXC-browser' native messaging does not work with flatpak", which is more specific than the current one?

@oidualc oidualc changed the title Unable to get KeePassXC-browser addon working, likely a Native Messaging issue. KeePassXC-browser native messaging does not work with flatpak Feb 1, 2019
@rugk
Copy link

rugk commented Apr 13, 2019

BTW a workaround has been provided in this issue (or here) that works if KeePassXC is also installed as a flatpak.
(Edit: Or possibly it does not… Only works if flatpak is installed on the host… 🤔)
Edit2: Or no, you can get it to work securely. See flathub/org.keepassxc.KeePassXC#13 (comment). The issue is fixed, so it should work. 😃 (with the only adjustment already linked - the wrapper script)

@kaymio
Copy link

kaymio commented Apr 15, 2019

Thank you @rugk for your effort to solve this issue.

With the wrapper script my native FF doesn't start KeePassXC in parallel, as intended.

The flatpaked version of FF (this repo) still doesn't connect to the flatpaked KeePassXC.

@rugk
Copy link

rugk commented Apr 15, 2019

Okay, hmm. Note I have also been advised that DBUS could be used to spawn another process, but AFAIK this is a thing that would have to be baked in, into this browser flatpak. (@xhorak, are you listening?)

@kaymio If you want to try it, you can create the following wrapper script as a workaround somewhere accessible to the Firefox flatpak (and keepassxc too, AFAIK, so in the worst case use /opt or maybe better your home dir?):

#!/bin/sh
flatpak-spawn --host keepassxc-proxy "$@"

I've based this loosely on my other scripts here.

Then flatpak override this.app.ID --talk-name=org.freedesktop.Flatpak (Attention: this allows this flatpak to start any commands on the host!) and then point keepassxc-browser to start this script instead of keepassxc-proxy.

This should allow Firefox to spawn a keepassxc-proxy on the host, so if keepassxc runs on the host, it works.

So now, you may want both (also KeePassXC) as flatpaks. So we also need to do step 4 here, which may end up in a script like this:

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

I am just not sure whether the whole thing with unix sockets and so on still works. In any case, take these as ideas, I guess it won't work exactly like this and there may still be bugs.

@kaymio
Copy link

kaymio commented Apr 16, 2019

Unfortunately my skill level is not high enough to meddle that deeply with the system. Especially if it goes that deep:

(Attention: this allows this flatpak to start any commands on the host!)

Nonetheless, thx!

PS: There was some movement during the flatpak update today. Although it finished with an error.
Error: Message recipient disconnected from message bus without replying.
Also the build still relies on Gnome 3.24 which is deprecated as of 11th January. Don't know whether I should file a bug report.

@rugk
Copy link

rugk commented Apr 16, 2019

Don't know whether I should file a bug report.

Unless it is fixed in the next second, yes. 😄 (also noticed that issue already)

@Ramblurr
Copy link

@rugk your solution works for a flatpaked-firefox and a host-keepassxc, but it allows firefox to run arbitrary commands on the host, which severely reduces the benefit of running FF in a flatpak. :/ any idea how to restrict it further?

@rugk
Copy link

rugk commented Dec 13, 2019

Well… unfortunately I do not have any better idea. Because you need to grant Firefox host execution permissions or it just does not work, as it needs to spawn a command. 🤔

@rugk
Copy link

rugk commented Dec 13, 2019

Okay maybe another idea I am not quite sure whether it works: AFAIK KeePassXC also supports some kind of "reverse connection", where KeePassXC actually spawns the proxy. This way KeePassXC could possibly spawn it inside of the Firefox flatopak. (via flatpak enter)
But whether that works is another question. 🤔

@rugk
Copy link

rugk commented May 5, 2020

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.

@erAck
Copy link
Collaborator

erAck commented Jun 24, 2020

This can not be soved in flatpackaging. There's upstream issue https://bugzilla.mozilla.org/show_bug.cgi?id=1621763 for native messaging in flatpak.
Use rugk's workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants