Use KeePassXC-Browser AddOn in Firefox-Nightly tarball with KeePassXC flatpak in kdelinux?

My objective, my usecase, is as per the Subject line.

Firefox-Nightly already works fine for me [it’s been my default browser for many years] in kdelinux [i run it from my home partition].

In my ArchLinux Plasma boot the AddOn works nicely with my Nightly & my repo-installed KeePassXC app.

I have read KDE Linux: Browser and KeePassXC doesn´t work as flatpaks together - #17 by Samuele but find it pretty confusing wrt if it actually can be applied to my usecase. I don’t even know if it remains current or might be obsolete.

I assumed the matter was likely hopeless in kdelinux, but then i discovered Use Password Managers with Web Browsers - KDE Linux

The second link there was very uninspiring, as it seems that others have said it sometimes works but then stops working – IMO that makes it unviable.

Otoh the first link seems rather more hopeful, afaict … but i’m really struggling to try to grasp how to adapt it explicitly for my usecase. The writer said:

Configure Firefox

I have firefox running native on my laptop so these shenanigans are not needed.

Well, that’s true also for me, my Nightly is “native” in that it is not a flatpak… but they then only provide native messaging file editing instructions for a flatpak firefox, sigh – what should i do instead for my Nightly? :woman_shrugging:

it uses allowedextensions iso allowedorigin

What does that weird subscript nomenclature mean? It is entirely obscure to me :exploding_head:

Finally they say

give access to the socket file to firefox

$ flatpak override --user --filesystem=xdg-run/app/org.keepassxc.KeePassXC:ro org.mozilla.firefox

…which is a clear instruction i can follow, but for a primary question… they are writing for a dual-flatpak scenario, whereas i only have keepassxc alone as a flatpak, so is that command also applicable to my usecase?

Hoping someone with much better grasp on such intricacies might be able to advise me, pls.

Ah, rats, i just realised there’s another part of those instructions that is incomprehensible to me, & which seems to compound the apparent impossibility of my quest:

keepassxc-proxy

There is a statically compiled rust based socket proxy.

  • rust based keepassxc proxy

    It can be compiled with MUSL for a fully static executable.

    Place it together with the configuration file

:woman_shrugging: :exploding_head:

Not being able to use this in kdelinux is such a shame, given it works so well in my Arch Plasma boot – its productivity enhancement is substantial. Alas.

It means the website author hasn’t paid close attention to formatting and the need to escape their special characters :smiley:

They’ve typed for example org.keepassxc.keepassxc_browser.json, but the _ has been interpreted as subscript formatting instead of a literal underscore.

In fact this should all be easier than the website makes it sound.

Even when using a Flatpak browser and Flatpak KeePassXC you don’t need to mess around compiling your own binary. (The KeePassXC Flatpak now provides and exports a binary that can be called - but I suspect that wasn’t yet the case at the time that web page was written.)

But in your case (non-Flatpak browser with Flatpak KeePassXC), it should be more simple still.

Create this file at ~/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json:

{
    "allowed_extensions": [
        "keepassxc-browser@keepassxc.org"
    ],
    "description": "KeePassXC integration with native messaging support",
    "name": "org.keepassxc.keepassxc_browser",
    "path": "/var/lib/flatpak/exports/bin/org.keepassxc.KeePassXC",
    "type": "stdio"
}

That should be enough to allow the browser to exchange messages with Flatpak KeePassXC.

This definitely works for me on Fedora, where I have non-Flatpak Firefox and Flatpak KeePassXC.

:rofl: :+1:

As it transpired that exact file, exact location, exact contents, already exists.

I agree, & so it has been exasperating for me to keep having it refuse to communicate.

However, at last, this story has a happy ending…

…tonight, at last, in my kdelinux, for the first time, both my Firefox [tarball], & Firefox-Nightly [tarball], are now connected to my KeePassXC [flatpak] :partying_face: :woman_dancing:

I feel stunned, & quite disappointed, that i’d allowed myself to be so distracted by those references [being either obsolete, or inapplicable] i’d mentioned, instead of just doing the obvious thing.

This next, last, part is embarrassing for me to have to admit. For much of my time in kdelinux i have been self-debating whether to adopt a primarily Flatpak or Distrobox paradigm for my non-system apps. As such i have some apps installed both ways for comparison, some only as FPs, some only via DB. In the specific case of KeePassXC, i have been trying it both ways. Here’s the part i had overlooked til tonight, after reading your helpful post. Most of my KP usage in kdelinux has been DB but… sigh… i had confused myself when i created this Issue & thought i was then using the KP FP when it was still the DB. In that version i had diligently ensured i had enabled the Browser Integration in its Settings, but still could not get communication. More recently i reinstalled the FP version… but somehow i had forgotten to also activate this setting in that version :roll_eyes: :woman_facepalming: All this time i thought it was enabled, only to discover after reading your post then rechecking, that it was disabled. So then, after making it so in the FP:

then restarting it, then restarting each browser, success at last.

Thank you so much for your help.

Aha! Maybe it gets created when the “Firefox” box on the Browser Integration screen is checked - so it could already have been there from your previous Distrobox installation of KeePassXC.

Glad to hear it’s working anyway!

Yes i suppose that might be the trigger for it.

One part of this i now find curious in retrospect… that AddOn, or KeePassXC, or… something… still treats the subdirectory ~/.mozilla as the “proper” or “normal” one for Firefox. In fact, earlier this year, Mozilla finally changed their file structure to belatedly follow the XDG convention, hence in my case, for months, i moved all my FF profiles & other files from there, into ~/.config/mozilla. Thus, it seems odd to me that my ~/.mozilla subdirectory is otherwise empty [indeed i had deleted it] except for this ancillary addon file. In my druthers, the KP team would/should fix that, for complete consistency & less possible confusion.

So you managed to make the Flatpak versions of Firefox and KeepassXC work? If so, it sounds like Use Password Managers with Web Browsers - KDE Linux needs to be updated! What specifically did you have to do, from start to finish?

Yes i have been chewing this over since the solution fell into my lap last night, because, tbh Nate, in the end it finally “just worked” for me after several weeks of me going around in circles. During today i shall try to assemble my thoughts & post here a steps summary, but someone else should then independently verify or refute it, in that atm i can’t recollect anything “radical” i did in the end that solved it. TBC…

I think @kdemeoz is using non-Flatpak Firefox with Flatpak KeepassXC?

I have Flatpak Firefox (and indeed Flatpak Floorp, which is a Firefox fork) working with Flatpak KeepassXC. It can be done more simply than either of the links from the documentation webpage make it appear.

Happy to write something up that we could link to from the webpage. I also noticed that Harald wrote up a different approach a while back.

Looks like this first needs a change on the Firefox side - see Use XDG path in Firefox · Issue #12779 · keepassxreboot/keepassxc · GitHub.

(The native-messaging-hosts is one thing that didn’t get moved from ~/.mozilla to ~/.config/mozilla according to https://bugzilla.mozilla.org/show_bug.cgi?id=2005167 .)

Here’s what i did today to double-check & document my steps.

  • created a new qemu/kvm/virtmanager VM, within my real kdelinux system, using kde-linux_202607280254.iso, then…

[A] Failure

  • installed keepassxc flatpak
    • enabled its Firefox Browser Integration [see pics below & above]
    • created dummy new database in it & unlocked it to verify correct operation
    • closed this app for now
  • within the preinstalled Firefox flatpak, i installed the KeePassXC-Browser AddOn
  • used Dolphin to verify that ~/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json exists [contents per following pic, also earlier post above]
  • close Firefox
  • launch KP, unlock database
  • launch FF fp
  • observe its KP icon indicates communication error with KP
  • this is where i gave up… this negative outcome seems consistent with the cautionary tone of Use Password Managers with Web Browsers - KDE Linux – and someone far more knowledgeable than i needs to ascertain if either of the links within are useful

[B] Success

  • this builds on some of the initial steps above
  • download the Firefox tarball from Mozilla, extract its contents
  • create [eg] ~/.var/opt/
  • move that extracted firefox directory into that new subdirectory
  • create a custom launcher for the executable within in the App Menu
  • launch this new FF
  • install the KeePassXC-Browser AddOn
  • close FF
  • launch the KP fp app & unlock its database
  • launch the opt FF
  • observe the KP AO icon is now “happy” [unlike above], then do its directed linking to the KP app
  • dance, jump, whoop & scream happily that now you can use the KP fp app with your FF opt browser [in my real kdelinux, i also did this successfully with FF-Nightly; logically therefore i expect also FF-Beta & FF-DevEd would equally work]
  • see pic below highlighting several of the preceding steps

TL;DR:

  1. I have no idea how to make it work when both apps are flatpaks, but if the browser is via Mozilla tarball, then it seems that making the integration work is really quite easy for anyone who knows how to click on things
  2. I have also failed to get browser integration working when using KP as an exported distrobox app

Please, Others – try to reproduce my steps to find errors or omissions i made, above.

Yeah, this case “just works”.[1] The crux of it is that for the integration to work, the browser needs to be able to run a KeePassXC binary. That’s easy if the browser is non-Flatpak and KeePassXC is a Flatpak - because an unsandboxed host process is allowed to invoke a Flatpak app.

It’s less easy when the browser is a Flatpak, because one Flatpak app can’t simply invoke another. However it can be done more easily than the resources linked from the web page make it sound - I don’t blame you for feeling intimidated by those.

I can write up an easier guide to making this work, but I want to check over my setup and see if it can be simplified further.

That seems like it would be harder to achieve. It might be possible if the container has access to the host’s D-Bus (as in Kapsule) but I haven’t thought about it in any detail.


  1. Although that’s only because by default Flatpak KeePassXC is permissioned to write to ~/.mozilla, which is a bit questionable. In fact by default it’s permissioned with RW access to all system files, which IMO is beyond questionable, but that’s anothe story. ↩︎

Slightly less chaotic pic…

Hello, I would be very interested by an easier setup guide for when both the browser and KeePassXC are flatpaks.

Cheers

Cool, it would be great if you could help test a guide!

Are you primarily interested in Firefox-based or Chrome-based browsers? (I want to do both but Chrome will take a bit more testing than Firefox which I’m more familiar with.)

Sure, I will be glad to test it ! Firefox is my browser of choice
although I also use Vivaldi but rarely.

Thanks

Great. The following steps should work on Firefox.

I’d also like to publish a single script that will automate all these steps, but first let’s set it out step-by-step for transparency and explainability.


Assumptions

  • Firefox is installed as a Flatpak. (But these instructions should also work on other Firefox-based Flatpak browsers [Floorp, Librewolf etc]. For those, wherever org.mozilla.firefox appears, replace it with the app ID of the browser. The native-messaging-hosts directory used in Step 3 may also be in a slightly different location.)
  • The official KeePassXC browser extension is installed.
  • KeePassXC is installed as a Flatpak and has the “Enable browser integration” setting enabled.
  • Both Flatpaks are installed as systemwide installs. (This is the case for the preinstalled Firefox on KDE Linux, and for anything you installed through Discover.)
  • The system uses the x86_64 architecture. (If it’s KDE Linux, this is guaranteed to be true.) There’s no deep requirement for this but it enables us to hardcode some paths.

1. Flatpak permissions for the browser

Normally, Flatpak apps can’t directly interact with each other (sandboxing). Here we’re going to allow Firefox just enough access to KeePassXC to do what it needs to do.

We’ll also set up Firefox so that access to ~/.mozilla in the user’s homedir is redirected to a .mozilla directory inside the user’s Firefox-specific Flatpak data directory. This insulates us from anything that KeePassXC might write to ~/.mozilla (it writes a file there that is correct for non-Flatpak browsers but not for Flatpak browsers).[1]

Action 1: run the following command in a terminal.

flatpak override --user \
    --persist=.mozilla \
    --filesystem=/var/lib/flatpak/app/org.keepassxc.KeePassXC:ro \
    --filesystem=/var/lib/flatpak/runtime/org.kde.Platform:ro \
    --filesystem=xdg-run/app/org.keepassxc.KeePassXC:create \
    org.mozilla.firefox

2. Wrapper script for the browser to invoke the KeePassXC proxy

The KeePassXC Flatpak provides an executable “proxy” which the browser extension should invoke when it needs to communicate with KeePassXC. Because our browser is a Flatpak, we need a wrapper script which locates that proxy and executes it in a sandbox.

Action 2a: create the following script as ~/.var/app/org.mozilla.firefox/data/bin/keepassxc-proxy-wrapper.sh

#!/bin/bash
    
# Adapted from: https://github.com/keepassxreboot/keepassxc-browser/issues/1631#issuecomment-2464608760
# Made lighter by pre-locating relevant directories and injecting them into the script where possible
    
# But we need to locate the runtime dynamically, because the RUNTIME_REF includes the runtime
# version number, which will change over time.
RUNTIME_REF=$(awk -F'=' '$1=="runtime" { print $2 }' < "/var/lib/flatpak/app/org.keepassxc.KeePassXC/x86_64/stable/active/metadata")
RUNTIME_PATH="/var/lib/flatpak/runtime/${RUNTIME_REF}/active"
    
# Execute the proxy provided by the KeePassXC Flatpak
exec flatpak-spawn \
    --env=LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/app/lib:/var/lib/flatpak/app/org.keepassxc.KeePassXC/x86_64/stable/active/files/lib64" \
    --env=PATH="${PATH}" \
    --app-path="/var/lib/flatpak/app/org.keepassxc.KeePassXC/x86_64/stable/active/files" \
    --usr-path="${RUNTIME_PATH}/files" \
    -- keepassxc-proxy "$@"

Action 2b: make the script we just created executable. This can be done either in Dolphin or by running chmod +x ~/.var/app/org.mozilla.firefox/data/bin/keepassxc-proxy-wrapper.sh.


3. Native messaging manifest

We need to create a small file telling Firefox to allow the browser extension to find and use the wrapper script we just created.

Action 3: create the following file at ~/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json. But make sure to edit it to replace the YOURUSERNAME with your own username. (We can’t use ~ as a shortcut here unfortunately, we need the explicit path of the homedir.)

{
    "allowed_extensions": [
        "keepassxc-browser@keepassxc.org"
    ],
    "description": "KeePassXC integration with native messaging support",
    "name": "org.keepassxc.keepassxc_browser",
    "path": "/home/YOURUSERNAME/.var/app/org.mozilla.firefox/data/bin/keepassxc-proxy-wrapper.sh",
    "type": "stdio"
}

Now you should be able to open the browser, click the toolbar button for the KeePassXC browser extension, and successfully connect to your KeePassXC database.


  1. The fact that Mozilla has moved everything other than native messaging manifests out of ~/.mozilla, as mentioned in previous posts, has actually made our life easier here :smiley: ↩︎

Congratulations on this wonderful guide. My Firefox-Nightly and Firefox are from Mozilla tarballs, not Flatpak, but today i installed LibreWolf from Flatpak via Discover, & used it to test your guide [with my existing Flatpak KeePassXC]. Here’s feedback fwiw.

Step 1
Initially i skipped this, because afaict there was/is no corresponding directory to ~/.mozilla, ie, no ~/.librewolf. Therefore i wrongly presumed, initially, that this step was redundant for Flatpak LibreWolf. Later, once i realised my error, i came back, & ran this in Konsole:

flatpak override --user \
    --persist=.librewolf \
    --filesystem=/var/lib/flatpak/app/org.keepassxc.KeePassXC:ro \
    --filesystem=/var/lib/flatpak/runtime/org.kde.Platform:ro \
    --filesystem=xdg-run/app/org.keepassxc.KeePassXC:create \
    io.gitlab.librewolf-community

Step 2
I ran your script, unedited, from /home/kdemeoz/.var/app/io.gitlab.librewolf-community/data/bin/keepassxc-proxy-wrapper.sh

Step 3
I created your file at /home/kdemeoz/.var/app/io.gitlab.librewolf-community/.librewolf/native-messaging-hosts/org.keepassxc.keepassxc_browser.json, including editing it with my name.

Result
Success! :tada::partying_face:

Brilliant work, @pg-tips :trophy:

I’m having a more detailed look at the --persist stuff. It’s necessary for my main browser (Floorp) but I don’t think it is for vanilla Firefox[1] and may not be for other browsers.

However, the --filesystem elements of Step 1 are definitely needed for all browsers, so the browser definitely wouldn’t have been able to talk to KeePassXC without that.

Great! You’re welcome!

I’m doing some more work to try to make an “installer” script that will find the right directories automatically (so that e.g. you wouldn’t have had to dig around to find the ~/.librewolf). The work done on Plasma Browser Integration actually helps us out here for the most common browsers.

Also working on the same thing for Chrome-based browsers. I have it working for Chromium, but again will try to generalise it and make something that automatically figures out directory structure differences across different browsers.


  1. Specifically, the override isn’t necessary for vanilla Firefox, because the app is already configured with a persistent mount to .mozilla ↩︎

Here’s a procedure that should work for Chromium-based browsers.

To avoid duplication I’ll be less verbose in the explanations here - refer back to the post for Firefox-based browsers for a bit more information.

I use Chromium here for the example (org.chromium.Chromium), but for other Chromium-based browsers, you should be able to just replace that with the appropriate app ID.

The KeePassXC extension is available either from the Chrome store or the Edge store - both are supported.


1. Flatpak permissions for the browser

Same as for Firefox, but (as far as I can tell) without complications around persistent mounts.

Action 1: run the following command in a terminal.

flatpak override --user \
    --filesystem=/var/lib/flatpak/app/org.keepassxc.KeePassXC:ro \
    --filesystem=/var/lib/flatpak/runtime/org.kde.Platform:ro \
    --filesystem=xdg-run/app/org.keepassxc.KeePassXC:create \
    org.chromium.Chromium

2. Wrapper script for the browser to invoke the KeePassXC proxy

Same as for Firefox.

Action 2a: create the following script as ~/.var/app/org.chromium.Chromium/data/bin/keepassxc-proxy-wrapper.sh

#!/bin/bash
    
# Adapted from: https://github.com/keepassxreboot/keepassxc-browser/issues/1631#issuecomment-2464608760
# Made lighter by pre-locating relevant directories and injecting them into the script where possible
    
# But we need to locate the runtime dynamically, because the RUNTIME_REF includes the runtime
# version number, which will change over time.
RUNTIME_REF=$(awk -F'=' '$1=="runtime" { print $2 }' < "/var/lib/flatpak/app/org.keepassxc.KeePassXC/x86_64/stable/active/metadata")
RUNTIME_PATH="/var/lib/flatpak/runtime/${RUNTIME_REF}/active"
    
# Execute the proxy provided by the KeePassXC Flatpak
exec flatpak-spawn \
    --env=LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/app/lib:/var/lib/flatpak/app/org.keepassxc.KeePassXC/x86_64/stable/active/files/lib64" \
    --env=PATH="${PATH}" \
    --app-path="/var/lib/flatpak/app/org.keepassxc.KeePassXC/x86_64/stable/active/files" \
    --usr-path="${RUNTIME_PATH}/files" \
    -- keepassxc-proxy "$@"

Action 2b: make the script we just created executable - either in Dolphin or by running chmod +x ~/.var/app/org.chromium.Chromium/data/bin/keepassxc-proxy-wrapper.sh.


3. Native messaging manifest

Same principles as for Firefox, but with slight differences in the file. We allow both the Chrome Store and Edge Store versions of the extension to access KeePassXC, so it shouldn’t matter which you have installed.

The directory where the file should live is different for different browsers. However (unlike Firefox), Chromium-based browsers seem to always create the directory when they first run. So, as long as you have opened your browser at least once, we’ll be able to find the directory.

Action 3a: run the following command to find the right directory:

find ~/.var/app/org.chromium.Chromium -type d -name NativeMessagingHosts

For Chromium, that gives /home/YOURUSERNAME/.var/app/org.chromium.Chromium/config/chromium/NativeMessagingHosts

Action 3b: create the following file inside the directory you found in 3a, with the filename org.keepassxc.keepassxc_browser.json. Make sure to edit it to replace the YOURUSERNAME with your own username (as well as replacing org.chromium.Chromium with the app ID of the browser).

{
    "allowed_origins": [
        "chrome-extension://oboonakemofpalcgghocfoadofidjkkk/",
        "chrome-extension://pdffhmdngciaglkoonimfcmckehcpafo/"
    ],
    "description": "KeePassXC integration with native messaging support",
    "name": "org.keepassxc.keepassxc_browser",
    "path": "/home/YOURUSERNAME/.var/app/org.chromium.Chromium/data/bin/keepassxc-proxy-wrapper.sh",
    "type": "stdio"
}

And hopefully you’ll now have your browser smoothly integrated with KeePassXC!