search

keepassxreboot / keepassxc

KeePassXC is a cross-platform community-driven port of the Windows application “Keepass Password Safe”.
https://keepassxc.org/
Other
20.75k stars 1.44k forks source link

Cannot open URL's from AppImage #8721

Closed plegrand1 closed 4 months ago

plegrand1 commented 1 year ago

Hello, since last update (2.7.4), opening url from KeePassXC does not works anymore. I use Appimage KeePassXC

Debian SID Firefox 106 KeePassXC-Browser : 1.8.3.1

I made some tests : Opening URLs does not work with 2.7.3 and 2.7.4 appimage version It works fine with the 2.7.1 appimage version

Debug Info KeePassXC - Version 2.7.4 Révision : 63b2394 Distribution : AppImage

Qt 5.15.2 Le mode débogage est désactivé.

Système d’exploitation : Debian GNU/Linux bookworm/sid Architecture de l’unité centrale : x86_64 Noyau : linux 6.0.0-2-amd64

Extensions activées :

Bibliothèques cryptographiques :

Thanks for your help

droidmonkey commented 1 year ago

How are you attempting to open the url? Click the link in the preview panel? Double click url in entry view? Ctrl + Shift + U keyboard shortcut?

Does this happen for all urls or just ones that are special like cmd:// ?

plegrand1 commented 1 year ago

it seems to happen on all url

Right click on entry and open url or link in the preview panel or shift control U

Le 31/10/2022 à 13:28, Jonathan White a écrit :

How are you attempting to open the url? Click the link in the preview panel? Double click url in entry view? Ctrl + Shift + U keyboard shortcut?

Does this happen for all urls or just ones that are special like cmd:// ?

— Reply to this email directly, view it on GitHub https://github.com/keepassxreboot/keepassxc/issues/8721#issuecomment-1297014939, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBFWRCAG67JF3UA5FPH2VLWF63PVANCNFSM6AAAAAARTAGMYI. You are receiving this because you authored the thread.Message ID: @.***>

Leepic commented 1 year ago

Hi,

I have the same issue after upgrading from 2.7.1 to 2.7.4 (Linux Mint 20.3). Nothing below works:

cmd:// and URL HTTP/HTTPS are concerned.

When running AppImage in my terminal I've this error:

Traceback (most recent call last):
  File "/usr/bin/gnome-terminal", line 9, in <module>
    from gi.repository import GLib, Gio
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 42, in <module>
    from . import _gi
ImportError: /lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined symbol: g_atomic_ref_count_inc
XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
/lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined symbol: g_atomic_ref_count_inc
Couldn't load XPCOM.
XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
/lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined symbol: g_atomic_ref_count_inc
Couldn't load XPCOM.
XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
/lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined symbol: g_atomic_ref_count_inc
Couldn't load XPCOM.
XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
/lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined symbol: g_atomic_ref_count_inc
Couldn't load XPCOM.
/usr/bin/xdg-open: 869: iceweasel: not found
/usr/bin/xdg-open: 869: seamonkey: not found
/usr/bin/xdg-open: 869: mozilla: not found
/usr/bin/xdg-open: 869: epiphany: not found
/usr/bin/xdg-open: 869: konqueror: not found
/usr/lib/chromium/chromium: symbol lookup error: /lib/x86_64-linux-gnu/libgio-2.0.so.0: undefined symbol: g_atomic_ref_count_inc
/usr/bin/xdg-open: 869: chromium-browser: not found
/usr/bin/xdg-open: 869: google-chrome: not found
/usr/bin/xdg-open: 869: www-browser: not found
/usr/bin/xdg-open: 869: links2: not found
/usr/bin/xdg-open: 869: elinks: not found
/usr/bin/xdg-open: 869: links: not found
/usr/bin/xdg-open: 869: lynx: not found
/usr/bin/xdg-open: 869: w3m: not found
xdg-open: no method available for opening 'https://github.com'

Workaround

  1. Extract the AppImage
cd /tmp
wget https://github.com/keepassxreboot/keepassxc/releases/download/2.7.4/KeePassXC-2.7.4-x86_64.AppImage
chmod u+x KeePassXC-2.7.4-x86_64.AppImage
./KeePassXC-2.7.4-x86_64.AppImage --appimage-extract

  1. Remove libglibc in AppImage rm -f squashfs-root/usr/lib/libglib-2.0.so.0

  2. Test ./squashfs-root/AppRun

then exit KeepassXC.

  1. Fix wrong XML parsing before creating a fixed AppImage

wget https://github.com/AppImage/AppImageKit/releases/download/13/appimagetool-x86_64.AppImage chmod u+x appimagetool-x86_64.AppImage ./appimagetool-x86_64.AppImage squashfs-root KeepassXC-2.7.4-fixed.AppImage

appimagetool, continuous build (commit 8bbf694), build <local dev build> built on 2020-12-31 11:48:33 UTC
/tmp/squashfs-root/org.keepassxc.KeePassXC.desktop: hint: value item "Security" in key "Categories" in group "Desktop Entry" can be extended with another category among the following categories: Settings, or System
Using architecture x86_64
/tmp/squashfs-root should be packaged as KeepassXC-2.7.4-fixed.AppImage
AppStream upstream metadata found in usr/share/metainfo/org.keepassxc.KeePassXC.appdata.xml
Trying to validate AppStream information with the appstreamcli tool
In case of issues, please refer to https://github.com/ximion/appstream
org.keepassxc.KeePassXC.appdata.xml
  E: ~:~: xml-markup-invalid Could not parse XML data: Entity: line 77: parser error : expected '>'
        <release version="2.7.3" date="2022-10-23">
        ^
Entity: line 1031: parser error : Opening and ending tag mismatch: release line 63 and releases
    </releases>
               ^
Entity: line 1033: parser error : Opening and ending tag mismatch: releases line 63 and component
</component>
            ^
Entity: line 1034: parser error : EndTag: '</' not found

^

Validation échouée : erreurs : 1
run_external: subprocess exited with status 3Failed to validate AppStream information with appstreamcli

nano +76 ./squashfs-root/usr/share/metainfo/org.keepassxc.KeePassXC.appdata.xml

--    </description
++    </description>
++    </release>

Fix warnings:

org.keepassxc.KeePassXC.appdata.xml
  W: org.keepassxc.KeePassXC.desktop:35: url-invalid-type vcs-browser
  W: org.keepassxc.KeePassXC.desktop:36: url-invalid-type contribute

nano +35 ./squashfs-root/usr/share/metainfo/org.keepassxc.KeePassXC.appdata.xml

Remove this lines:

--    <url type="vcs-browser">https://github.com/keepassxreboot/keepassxc</url>
--    <url type="contribute">https://keepassxc.org/docs#contribute</url>

4.1 Create a fixed AppImage

./appimagetool-x86_64.AppImage squashfs-root KeepassXC-2.7.4-fixed.AppImage

appimagetool, continuous build (commit 8bbf694), build <local dev build> built on 2020-12-31 11:48:33 UTC
/tmp/squashfs-root/org.keepassxc.KeePassXC.desktop: hint: value item "Security" in key "Categories" in group "Desktop Entry" can be extended with another category among the following categories: Settings, or System
Using architecture x86_64
/tmp/squashfs-root should be packaged as KeepassXC-2.7.4-fixed.AppImage
AppStream upstream metadata found in usr/share/metainfo/org.keepassxc.KeePassXC.appdata.xml
Trying to validate AppStream information with the appstreamcli tool
In case of issues, please refer to https://github.com/ximion/appstream
La validation a réussi.
Generating squashfs...
Parallel mksquashfs: Using 4 processors
Creating 4.0 filesystem on KeepassXC-2.7.4-fixed.AppImage, block size 131072.
[========================================================================================================================================================-] 990/990 100%

Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
    compressed data, compressed metadata, compressed fragments,
    compressed xattrs, compressed ids
    duplicates are removed
Filesystem size 39343.84 Kbytes (38.42 Mbytes)
    37.31% of uncompressed filesystem size (105443.58 Kbytes)
Inode table size 5638 bytes (5.51 Kbytes)
    39.13% of uncompressed inode table size (14409 bytes)
Directory table size 3280 bytes (3.20 Kbytes)
    39.77% of uncompressed directory table size (8247 bytes)
Number of duplicate files found 39
Number of inodes 340
Number of files 240
Number of fragments 34
Number of symbolic links  3
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 97
Number of ids (unique uids + gids) 1
Number of uids 1
    root (0)
Number of gids 1
    root (0)
Embedding ELF...
Marking the AppImage as executable...
Embedding MD5 digest
Success

Please consider submitting your AppImage to AppImageHub, the crowd-sourced
central directory of available AppImages, by opening a pull request
at https://github.com/AppImage/appimage.github.io
  1. Enjoy Your working AppImage is at /tmp/KeepassXC-2.7.4-fixed.AppImage.
phoerious commented 1 year ago

The URL opening issue is some sort of incompatible MIME type handling between Qt and your system. It's reproducible, but I don't think we can fix that.

There is a workaround, but not a nice one. See here: https://github.com/keepassxreboot/keepassxc/issues/8669#issuecomment-1294593961

plegrand1 commented 1 year ago

Does that meas there is no solution ?

plegrand1 commented 1 year ago

I admit that I have a little difficulty in understanding since version 2.7.1 works correctly. I would think that the problem comes from the appimage, no?

clunst commented 1 year ago

I think I am affected by the same problem. Main system is a debian bullseye and I have run several tests on different live environments (xfce, KDE, i3wm, cinnamon / wayland, X) and in none of the environments I was able to open a URL. All tests by clicking the Help->Getting Started button. Something seems to be wrong with v2.7.4.

debian bullseye:

~$ Downloads/KeePassXC-2.7.4-x86_64.AppImage 
xdg-mime: mimetype argument missing
Try 'xdg-mime --help' for more information.
/opt/brave.com/brave/brave: symbol lookup error: /lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_uri_ref

KDE neon live cd:

 ./KeePassXC-2.7.4-x86_64.AppImage 
kde-open5: symbol lookup error: /lib/x86_64-linux-gnu/libQt5WaylandClient.so.5: undefined symbol: _ZTI27QPlatformServiceColorPicker, version Qt_5_PRIVATE_API

endeavour OS live cd:

$ ./KeePassXC-2.7.4-x86_64.AppImage 
xdg-mime: no method available for querying MIME type of '/tmp/.mount_KeePascbt5Vf/usr/share/keepassxc/docs/KeePassXC_GettingStarted.html'
xdg-mime: mimetype argument missing
Try 'xdg-mime --help' for more information.
XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
/usr/lib/libgobject-2.0.so.0: undefined symbol: g_atomic_rc_box_release_full
Couldn't load XPCOM.
XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
/usr/lib/libgobject-2.0.so.0: undefined symbol: g_atomic_rc_box_release_full
Couldn't load XPCOM.
xdg-open: no method available for opening 'file:////tmp/.mount_KeePascbt5Vf/usr/share/keepassxc/docs/KeePassXC_GettingStarted.html'

Fedora live cd:

$ ./KeePassXC-2.7.4-x86_64.AppImage 
XPCOMGlueLoad error for file /usr/lib64/firefox/libmozgtk.so:
/lib64/libgobject-2.0.so.0: undefined symbol: g_uri_ref
Couldn't load XPCOM.
/usr/bin/xdg-open: line 881: x-www-browser: command not found
XPCOMGlueLoad error for file /usr/lib64/firefox/libmozgtk.so:
/lib64/libgobject-2.0.so.0: undefined symbol: g_uri_ref
Couldn't load XPCOM.
/usr/bin/xdg-open: line 881: iceweasel: command not found
/usr/bin/xdg-open: line 881: seamonkey: command not found
/usr/bin/xdg-open: line 881: mozilla: command not found
/usr/bin/xdg-open: line 881: epiphany: command not found
/usr/bin/xdg-open: line 881: konqueror: command not found
/usr/bin/xdg-open: line 881: chromium: command not found
/usr/bin/xdg-open: line 881: chromium-browser: command not found
/usr/bin/xdg-open: line 881: google-chrome: command not found
/usr/bin/xdg-open: line 881: www-browser: command not found
/usr/bin/xdg-open: line 881: links2: command not found
/usr/bin/xdg-open: line 881: elinks: command not found
/usr/bin/xdg-open: line 881: links: command not found
/usr/bin/xdg-open: line 881: lynx: command not found
/usr/bin/xdg-open: line 881: w3m: command not found
xdg-open: no method available for opening 'file:////tmp/.mount_KeePasM58WNJ/usr/share/keepassxc/docs/KeePassXC_GettingStarted.html'

garuda live cd:

Downloads/KeePassXC-2.7.4-x86_64.AppImage 
xdg-mime: no method available for querying MIME type of '/tmp/.mount_KeePas9rXuig/usr/share/keepassxc/docs/KeePassXC_GettingStarted.html'
xdg-mime: mimetype argument missing
Try 'xdg-mime --help' for more information.
Opening "//tmp/.mount_KeePas9rXuig/usr/share/keepassxc/docs/KeePassXC_GettingStarted.html" with FireDragon  (text/html)
XPCOMGlueLoad error for file /usr/lib/firedragon/libmozgtk.so:
/usr/lib/libgobject-2.0.so.0: undefined symbol: g_atomic_rc_box_release_full
Couldn't load XPCOM.
XPCOMGlueLoad error for file /usr/lib/firedragon/libmozgtk.so:
/usr/lib/libgobject-2.0.so.0: undefined symbol: g_atomic_rc_box_release_full
Couldn't load XPCOM.
XPCOMGlueLoad error for file /usr/lib/firedragon/libmozgtk.so:
/usr/lib/libgobject-2.0.so.0: undefined symbol: g_atomic_rc_box_release_full
Couldn't load XPCOM.
xdg-open: no method available for opening 'file:////tmp/.mount_KeePas9rXuig/usr/share/keepassxc/docs/KeePassXC_GettingStarted.html'
phoerious commented 1 year ago

The problem is this here: https://github.com/keepassxreboot/keepassxc/issues/8737#issuecomment-1300549695

plegrand1 commented 1 year ago

But how to explain then the solution proposed by Leepic ?

droidmonkey commented 1 year ago

Remove libglibc in AppImage rm -f squashfs-root/usr/lib/libglib-2.0.so.0

By doing this you force the appimage to use your system library. Might as well just use the ppa at that point.

priv commented 1 year ago

@plegrand1

I don't think it's same problem as #8737, more likely a glib incompatible problem. KeePassXC invokes other Applications, but the other Applications have problems with libglib-2.0.so.0 included in the AppImage.

Reproduced on Ubuntu 22.10

alvin@alvin-WS-E500:~/Applications$ ./KeePassXC-2.7.4-x86_64.AppImage 
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
QObject::startTimer: Timers cannot have negative intervals
qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_base_id
qt.network.ssl: QSslSocket: cannot resolve SSL_get_peer_certificate
qt.network.ssl: QSslSocket: cannot call unresolved function SSL_get_peer_certificate
/usr/bin/google-chrome-stable: symbol lookup error: /lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_uri_ref
plegrand1 commented 1 year ago

Then, is there a solution for this problem ? Do i have to do something to make it works ? Thanks

priv commented 1 year ago

Then, is there a solution for this problem ? Do i have to do something to make it works ? Thanks

Two ways:

  1. KeePassXC don't pack glib in it. (It's not there in 2.7.1) I think this is most viable because I don't think any popular distributions work without glib.
  2. KeePassXC packs all glib series libraries in it so there will not be version mismatch problems. But this is not reasonable since KeePassXC does not use them.

Or, KeePassXC can discard bundle library information when it calls external application, but I wonder if there's simple way to do it.

plegrand1 commented 1 year ago

Hello, so will the next versions of KeepassXC take this problem into account?

NoahDar commented 1 year ago

I too am having this issue with Debian 11 KDE. I'm wondering at this point just compile from source and be done with it? I really like the AppImage as it's nice and self-contained.

droidmonkey commented 1 year ago

Use the flatpak..

plegrand1 commented 1 year ago

Does this mean that the AppImage version will eventually disappear? I have never used an application in FlatPack version and I admit I don't know much about it, is it as reliable? Where is the application installed?

Thank you in advance for your answers

droidmonkey commented 1 year ago

@phoerious unfortunately this is still a problem

phoerious commented 1 year ago

This is nothing we can fix, really. It's a bug that depends on the host's and the AppImage's Ubuntu Version.

vphantom commented 1 year ago

Is there any reason you started including part of the glib libraries in the AppImage builds after 2.7.1 which prevents you from reverting to the way it was built up to 2.7.1?

NoahDar commented 1 year ago

AppImage 2.7.1 still works fine in Debian 11 with KDE. With 2.7.4 I've formed a habit of just copying the URL and pasting it into Chrome.

priv commented 1 year ago

Hi,

I have the same issue after upgrading from 2.7.1 to 2.7.4 (Linux Mint 20.3). Nothing below works:

It seems that the steps needs some revision for 2.7.5: 2.7.5 has some problems with the old appimagetool

alvin@alvin-WS-E500:~/Applications$ ./appimagetool-x86_64.AppImage squashfs-root/ KeePassXC-2.7.5-fixed.AppImage
appimagetool, continuous build (commit 8bbf694), build <local dev build> built on 2020-12-31 11:48:33 UTC
/home/alvin/Applications/squashfs-root/org.keepassxc.KeePassXC.desktop: error: value "1.5" for key "Version" in group "Desktop Entry" is not a known version
/home/alvin/Applications/squashfs-root/org.keepassxc.KeePassXC.desktop: hint: value item "Security" in key "Categories" in group "Desktop Entry" can be extended with another category among the following categories: Settings, or System
/home/alvin/Applications/squashfs-root/org.keepassxc.KeePassXC.desktop: error: file contains key "SingleMainWindow" in group "Desktop Entry", but keys extending the format should start with "X-"
ERROR: Desktop file contains errors. Please fix them. Please see
       https://standards.freedesktop.org/desktop-entry-spec/1.0/n       for more information.

If using newer appimage tool from the continuous build, some other xml contents will fail:

alvin@alvin-WS-E500:~/Applications$ ./appimagetool-x86_64.AppImage squashfs-root/ KeePassXC-2.7.5-fixed.AppImage
appimagetool, continuous build (commit 5735cc5), build <local dev build> built on 2023-03-08 22:52:04 UTC
/home/alvin/Applications/squashfs-root/org.keepassxc.KeePassXC.desktop: hint: value item "Security" in key "Categories" in group "Desktop Entry" can be extended with another category among the following categories: Settings, or System
Using architecture x86_64
/home/alvin/Applications/squashfs-root should be packaged as KeePassXC-2.7.5-fixed.AppImage
AppStream upstream metadata found in usr/share/metainfo/org.keepassxc.KeePassXC.appdata.xml
Trying to validate AppStream information with the appstreamcli tool
In case of issues, please refer to https://github.com/ximion/appstream
org.keepassxc.KeePassXC.appdata.xml
  W: org.keepassxc.KeePassXC.desktop:8: mimetypes-tag-deprecated
  W: org.keepassxc.KeePassXC.desktop:40: screenshot-image-not-found
       https://keepassxc.org/images/screenshots/thumbs/welcome_screen.png - URL was not
       found on the server.
  W: org.keepassxc.KeePassXC.desktop:44: screenshot-image-not-found
       https://keepassxc.org/images/screenshots/thumbs/database_view.png - URL was not found
       on the server.
  W: org.keepassxc.KeePassXC.desktop:48: screenshot-image-not-found
       https://keepassxc.org/images/screenshots/thumbs/edit_entry.png - URL was not found on
       the server.
  W: org.keepassxc.KeePassXC.desktop:52: screenshot-image-not-found
       https://keepassxc.org/images/screenshots/thumbs/edit_entry_icons.png - URL was not
       found on the server.
  W: org.keepassxc.KeePassXC.desktop:56: screenshot-image-not-found
       https://keepassxc.org/images/screenshots/thumbs/password_generator_advanced.png - URL
gbrauen commented 1 year ago

@phoerious Do you know if this is a problem with 2.7.2 - 2.7.5 on Debian 12 (bookworm)? Currently, this has a 2.8.0 milestone but your comment above is "This is nothing we can fix, really." Is the real solution to wait for AppImages on bullseye to go away?

I'm running a patched version of 2.7.4 AppImage (thanks to @Leepic!) on Debian 11 and nothing in the list of changes for 2.7.5 seems to warrant an update with bookworm's release imminent, if the libglib-2.0.so.0 problem will be gone after that upgrade.

droidmonkey commented 1 year ago

The fix is beyond easy, switch to Flatpak

https://flathub.org/apps/org.keepassxc.KeePassXC

vphantom commented 1 year ago

I'm confused though; isn't the whole point of AppImage to produce a stand-alone executable which can run anywhere? I could understand it needing a minimum version of glibc but how come there's a mismatch beyond that? I can only assume that some dependencies are still left for the host O/S to supply, which is a neat feature of AppImage to keep the distributed size down but defeats the purpose of portability. 🤔 Presumably, the AppImage could be made self-sufficient to work around the version mismatch we experience here, bloated as it might become. (I wonder by how much it would grow.)

Going one step further: since this is a C++ project, what was the motivation to choose AppImage and Flatpak instead of building statically? Sure static linking with glibc throws some compile-time warnings but most I encountered in my experiments in other projects could be ignored.

gbrauen commented 1 year ago

@droidmonkey Are you suggesting that this is still a problem with AppImage on bookworm?

I have used both Snap and Flatpak with Keepassxc and browser integration is a mess in both cases. You can make it work but the finicky setup is not worthwhile.

droidmonkey commented 1 year ago

Browser integration works perfectly fine with both. Not sure what you are referring to.

jbrzozoski commented 1 year ago

The fix is beyond easy, switch to Flatpak

I know most users may not be using YubiKeys, but getting the YubiKey HMAC to work consistently with Flatpak was not "beyond easy". I went through a few of the guides and was able to get the YubiKey to be seen for a while, but it would inevitably break within a few hours and require I stop and restart KeePassXC to get it working again. I'm sure there's some tweak to the permissions that could've solved this, but I couldn't figure it out with couple hours of searching and experimenting.

bkauler commented 1 year ago

I installed 2.7.4 appimage. When tried to open a url in chromium, the xdg-open script gave "permission denied" errors on lines like this:

grep -q "^${WHOIAM}=true" /root/.clients-status

/root and clients-status have permissions 755, so should be readable. Also got the permission denied in another part of the script that tried to read under /root

I then installed 2.7.1 appimage, and it worked, some error messages to the commandline, but the url opened in chromium.

Note, I'm running EasyOS 5.4.1, which has a custom /usr/bin/xdg-open script that is different from other distros.

bkauler commented 1 year ago

I commented above that got some errors, though chromium launched ok. One of those errors:

dbus-launch: /tmp/.mount_keepasmg9KjO/usr/lib/libdbus-1.so.3: version 'LIBDBUS_PRIVATE_1.14.6' not found (required by dbus-launch)

Have just now installed 2.7.5, don't get that permission denied, but the browser fails to launch, get this error:

/usr/bin/chromium.bin0: symbol lookup error: /usr/lib/libgobject-2.0.so.0: undefined symbol: g_uri_ref

Note, /usr/bin/chromium.bin0 is a startup script for chromium.

And 2.7.5 still gives that error:

dbus-launch: /tmp/.mount_keepasNv7mvT/usr/lib/libdbus-1.so.3: version 'LIBDBUS_PRIVATE_1.14.6' not found (required by dbus-launch)

einfinder commented 1 year ago

Same here (libgobject-2.0.so.0: undefined symbol: g_uri_ref) with the 2.7.5 AppImage on Debian Bullseye. Did a local build and install. Issue is gone (as expected).

I found another reference to this issue where the maintainer claimed it disappeared without change in a new build...

bkauler commented 1 year ago

Yes, I have also done a local compile in EasyOS, and released Easy 5.4.3 with KeepassXC builtin, and it works great. Got it to automatically start in the tray, also great: https://bkhome.org/news/202306/keepassxc-now-builtin-to-easyos.html

I have made a few posts to my blog how flakey appimages are, for example: https://bkhome.org/news/202303/wrapping-up-appimage-installer.html

Whereas all the flatpaks tried so far have worked.

gbrauen commented 1 year ago

Can now confirm this is still a problem with 2.7.5 AppImage on debian bookworm. When attempting to open a URL from KeePassXC, I see the following in syslog indicating a mismatch between system libgobject and libglib bundled in the AppImage: /lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_uri_ref

Both libgobject-2.0.so.0 and libglib-2.0.so.0 are installed as part of the debian package libglib2.0-0:amd64 in bookworm.

The workaround by @Leepic still works. Remove libglib-2.0.so.0 from the AppImage bundle. Basic steps are correct except two files in the AppImage need to be edited to fix the errors shown here and allow the command ./appimagetool-x86_64.AppImage squashfs-root KeepassXC-2.7.5-fixed.AppImage to work :

  1. Edit (from /tmp) ./squashfs-root/usr/share/applications/org.keepassxc.KeePassXC.desktop (changes) 
    45c45
< Version=1.5
---
> #Version=1.5
48c48
< SingleMainWindow=true
---
> #SingleMainWindow=true
  2. Edit (from /tmp) ./squashfs-root/usr/share/metainfo/org.keepassxc.KeePassXC.appdata.xml (changes) 
    8c8
<     <mimetypes>
---
>     <!--mimetypes>
10c10
<     </mimetypes>
---
>     </mimetypes-->
40c40
<             <image>https://keepassxc.org/images/screenshots/thumbs/welcome_screen.png</image>
---
>             <image>https://keepassxc.org/assets/img/screenshots/thumbs/welcome_screen.png</image>
44c44
<             <image>https://keepassxc.org/images/screenshots/thumbs/database_view.png</image>
---
>             <image>https://keepassxc.org/assets/img/screenshots/thumbs/database_view.png</image>
48c48
<             <image>https://keepassxc.org/images/screenshots/thumbs/edit_entry.png</image>
---
>             <image>https://keepassxc.org/assets/img/screenshots/thumbs/edit_entry.png</image>
52c52
<             <image>https://keepassxc.org/images/screenshots/thumbs/edit_entry_icons.png</image>
---
>             <image>https://keepassxc.org/assets/img/screenshots/thumbs/edit_entry_icons.png</image>
56c56
<             <image>https://keepassxc.org/images/screenshots/thumbs/password_generator_advanced.png</image>
---
>             <image>https://keepassxc.org/assets/img/screenshots/thumbs/password_generator_advanced.png</image>
droidmonkey commented 1 year ago

https://github.com/OpenChemistry/avogadroapp/pull/318/files

This was fixed by someone else by directly calling xdg-open instead of the qt call

plegrand1 commented 1 year ago

Does this mean that the next update will take this information into account?

Auronius commented 4 months ago

Hello! I still have this problem in KeePassXC 2.7.7. I am using Linux Mint 20.2 Uma. A Year and five months have passed, but this bug still has not been fixed. Why?

NoahDar commented 4 months ago

Hello! I still have this problem in KeePassXC 2.7.7. I am using Linux Mint 20.2 Uma. A Year and five months have passed, but this bug still has not been fixed. Why?

I've been wondering about that too. I am using plain vanilla Debian 12 with KDE.

Kernel: 6.1.0-20-amd64 Operating System: Debian GNU/Linux 12 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.0-20-amd64 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor Memory: 125.7 GiB of RAM Graphics Processor: AMD Radeon RX 6900 XT

From what I understand the issue revolves around Qt.

I've made it as a habit to copy and paste the URL into my browser. Long as the browser plugin works it's not too big of a deal for me.

plegrand1 commented 3 months ago

Hello, I've just tried the new version of KeePassXC in Appimage (2.7.8) on Debian SID. The problem still seems to be there. When I click on a url, the application freezes and I can't do anything. I then have to “kill” it. In the logs, I get these messages:

mai 16 18:41:20 zenbook KeePassXC.AppImage[44007]: XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
mai 16 18:41:20 zenbook KeePassXC.AppImage[44007]: /lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_uri_ref
mai 16 18:41:20 zenbook KeePassXC.AppImage[44007]: Couldn't load XPCOM.
mai 16 18:41:20 zenbook KeePassXC.AppImage[44012]: XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
mai 16 18:41:20 zenbook KeePassXC.AppImage[44012]: /lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_uri_ref
mai 16 18:41:20 zenbook KeePassXC.AppImage[44012]: Couldn't load XPCOM.
mai 16 18:41:20 zenbook KeePassXC.AppImage[43938]: /usr/bin/xdg-open: 882: iceweasel: not found
mai 16 18:41:20 zenbook KeePassXC.AppImage[43938]: /usr/bin/xdg-open: 882: seamonkey: not found
mai 16 18:41:20 zenbook KeePassXC.AppImage[43938]: /usr/bin/xdg-open: 882: mozilla: not found
mai 16 18:41:20 zenbook KeePassXC.AppImage[43938]: /usr/bin/xdg-open: 882: epiphany: not found
mai 16 18:41:20 zenbook KeePassXC.AppImage[43938]: /usr/bin/xdg-open: 882: konqueror: not found
mai 16 18:41:20 zenbook KeePassXC.AppImage[43938]: /usr/bin/xdg-open: 882: chromium: not found
mai 16 18:41:20 zenbook KeePassXC.AppImage[43938]: /usr/bin/xdg-open: 882: chromium-browser: not found
mai 16 18:41:20 zenbook KeePassXC.AppImage[43938]: /usr/bin/xdg-open: 882: google-chrome: not found
michaelk83 commented 3 months ago

@plegrand1 At this point, this looks like a configuration issue on your system. Does the browser open when you run xdg-open "<the url>" from a shell? If not, then see https://unix.stackexchange.com/q/251054/455274 (you can also define a default browser in system settings in some DEs).

I'm not sure whether anything can be added to the AppImage to make this work by default, as the specific browser association would be up to each user's system.

plegrand1 commented 3 months ago

I just made a test with xdg-open http://www.google.fr from a shell and it works fine.

droidmonkey commented 3 months ago

The error message you show indicates appimage cannot see your configuration file that defines the default browser. It isn't a keepassxc specific issue.

michaelk83 commented 3 months ago

appimage cannot see your configuration

https://github.com/AppImage/AppImageKit/issues/124#issuecomment-205486221 might be relevant?

droidmonkey commented 3 months ago

Yup precisely that!

plegrand1 commented 3 months ago

Should the unset command be run once and for all or on each reboot? In this case i should have to modify the desktop file to launch the appimage?

plegrand1 commented 3 months ago

Then i made the test unset XDG_DATA_DIRS Then i launch KeePassXC AppImage, no more freeze but impossible to open url's. When i click on the url, nothing happens Logs: mai 17 16:23:41 zenbook KeePassXC.AppImage[55038]: XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so: mai 17 16:23:41 zenbook KeePassXC.AppImage[55038]: /lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_uri_ref mai 17 16:23:41 zenbook KeePassXC.AppImage[55038]: Couldn't load XPCOM.

From my point of view and my limited knowledge, this is very similar to the original problem.

gbrauen commented 3 months ago

With 2.7.8 appimage on Debian Bookworm (12), I still get the same error as reported by @clunst here. 

XPCOMGlueLoad error for file /usr/share/librewolf/libmozgtk.so:
/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_uri_ref
Couldn't load XPCOM.

Undefined symbol is still fixed by removing the mismatched libglib-2.0.so.0 from the appimage and repacking it.

This should still be open. Is it tracked elsewhere?

droidmonkey commented 3 months ago

Appimage is a failed standard. Use flatpak

plegrand1 commented 3 months ago

Hello, That's not really an answer. On the KeePassXC site, the Appimage version is highlighted, so it's natural to choose this one. It seems that the initial bug present on the Appimage version is still present on the latest version. Will the Appimage version no longer be offered, or will this bug be corrected? Sincerely Pascal

droidmonkey commented 3 months ago

It is an answer, maybe not the one you wanted to read. How can we keep fixing problems in appimage that crop up on all these disparate systems? It's a failed solution to the problem of portability, clearly.

vphantom commented 3 months ago

FlatPak uses a huge amount of space compared to AppImage and introduces unpleasant issues being more isolated (i.e. cannot access host's fonts, GTK config), which is why I use AppImages when available. It used to work well for KeePassXC too until 1-2 years ago. With that said, if you no longer support AppImages, why release them at all? It creates an expectation that we should report bugs as they are found. That's overhead for you and frustration for us. 😉

Instead, why not work on a static build process (perhaps with musl libc)? I'm not sure if that's easy with C++ but it's quite common with Rust and Go projects for example. Heck I'd contribute to a bounty for that, as it would be cleaner than AppImage (or FlatPak).

Edit: It doesn't help that the big green button on https://keepassxc.org/download/#linux links to the AppImage, which tells users that it's the main officially-supported Linux download.