KeePassXC in repos only partly works.

Hi

I’ve checked this in TW on my two physical computers, in a couple of TW VMs in one of those computers, & in a Leap 42.3 VM also… all behave the same as follows. I have the latest package version now in TW via a recent TW zypper dup, but also the previous version [2.1.4, as still used in Leap] manifested the same behaviour. The current installed version is:


gooeygirl@linux-Tower:~> zypper info keepassxc
Loading repository data...
Reading installed packages...




Information for package keepassxc:
----------------------------------
Repository     : Main Repository (OSS)     
Name           : keepassxc                 
Version        : 2.2.0-1.1                 
Arch           : x86_64                    
Vendor         : openSUSE                  
Installed Size : 6.8 MiB                   
Installed      : Yes                       
Status         : up-to-date                
Source package : keepassxc-2.2.0-1.1.src   
Summary        : Qt5-based Password Manager
Description    :                           
    A password manager or safe which manages your passwords. Databases
    are locked with a master key/password or a key disk. The databases
    are encrypted using AES and Twofish.


gooeygirl@linux-Tower:~> 

These repos versions launch fine, & in almost all aspects initially seem to run perfectly. However i discovered there is one specific core activity that does not work in these repos versions. These two pics illustrate:

https://paste.opensuse.org/images/17954638.png

https://paste.opensuse.org/images/26023575.png

No manually-added attribute will copy to the clipboard, with these repos versions [the manual items are those that show up [i]below the line in that second pic, above].

I know for a fact that this is not a basic coding error in the actual package Dev’s work, because performing this identical test in a non-openSUSE distro [eg, Maui Linux] works perfectly. Furthermore, in my oS TW, i did the following additional tests.

Firstly i downloaded the KeePassXC AppImage from here [the Dev’s website] https://keepassxc.org/download . I discovered that this works perfectly, regarding copying all the manually-added attributes to clipboard.

Secondly i installed the KeePassXC Snap package, using the method i described here https://forums.opensuse.org/showthread.php/523333-anyone-successfully-installed-snapd?p=2836827#post2836827 . This also works perfectly, regarding copying all the manually-added attributes to clipboard.

You might think that all i need to do is to not use the repos version, & keep using the AppImage or Snap package. The difficulty with that is that for optimised security & privacy i prefer running lots of my programs, especially including sensitive ones like KeePassXC, inside the Firejail sandbox, isolated from the internet. Whereas the repos KPXC version runs very nicely in FJ, both the AppImage & Snap versions do not.

Ideally i’d like whatever is wrong with the repos versions to be fixed so that full-functionality is available, but i don’t know how to achieve that. Ideas please?

Hi
Step 1: Does it duplicate for a test user if yes;
Step 2: A bug report is probably the best course…
openSUSE:Submitting bug reports - openSUSE

Thanks.

Step 1: Does it duplicate for a test user if yes;

Yes.

Looks like it’s time then for Step 2.

I have not raised a bug report, as i’m apprehensive about the loss of privacy that seems to be associated with doing that.

However, fortuitously today i read a brilliant solution on the Mint forum, enabling use of the full-function KeePassXC AppImage, with FireJail. I have tried it, & it works perfectly. Woohoo.

Update.

  1. The v2.2.0 AppImage continues to go well, but i have realised there’s an annoying issue/bug, as i posted here https://forums.opensuse.org/showthread.php/527661-AppImages-cause-Loop-Device-mounting-can-this-be-a-cumulative-problem … each launch of the AI mounts a new Loop Device, & none of the previous instances automatically “goes away” [unmount, i assume].
  2. The new v2.2.1 AppImage continues to have the full functionality
    too, but also the same Loop Device problem. 1. The TW repos’ newly upgraded v2.2.1, just like v2.2.0, still fails to copy any manually-added attribute to the clipboard
    . 1. Today [with help; https://forums.opensuse.org/showthread.php/527662-Dependency-issues-when-trying-to-build-KeePassXC-from-Source?p=2842056#post2842056 ] i managed to build my own flavour of v2.2.1 from the source-code. To my shock & displeasure, it also fails to copy any manually-added attribute to the clipboard
    . 1. Whilst i am now happy & willing to open a Bug Report, i am no longer sure that there’s any justification for it, ie, without in any way at all meaning to impugn DimStar’s
    work https://build.opensuse.org/package/show/openSUSE:Factory/keepassxc by even suggesting a Bug Report, i cannot see how logically there could be any fault in the Repos versions, given that my own independent build-from-source has the same problem.

I keep thinking about the fact that the “missing” functionality in TW & Leap’s repos’ versions, compared to the AppImage’s full functionality in TW, AND compared to the repos’ installations of KeePassXC in non-openSUSE distros also having full functionality, somehow seems to imply that in oS the clipboard is not being allowed to completely communicate with this package. However i am too technically weak to know if that is even possible, & if it is, how i could fix it.

Hi
Bug report would be the best way to figure things out…

The package is developed here (follow the link in top right back);
https://build.opensuse.org/package/show/security/keepassxc

In my initial post in this thread i stated this:

I know for a fact that this is not a basic coding error in the actual package Dev’s work, because performing this identical test in a non-openSUSE distro [eg, Maui Linux] works perfectly.

Based on extensive further testing, that original statement is partly WRONG.

Today i have performed much additional testing:

  1. i installed KeePassXC 2.2.1 in my Fedora 26 KDE VM [from the Fedora repo]. –> INCOMPLETE functionality.

  2. In another VM i have KaOS, in which i already had KeePassXC v2.2.0, but which all attempts today to upgrade it to 2.2.1 failed… hence my tests occurred on its 2.2.0. –> INCOMPLETE functionality.

  3. In my Maui VM, in my original testing i made a silly error; whereas i had thought i was using the “real” pgm, i accidentally instead had launched the Snap package. Hence my original Maui VM testing is now invalid. Instead, today i ensured i am using the “real” pgm… it is not in their repos, so i downloaded it from Releases · magkopian/keepassxc-debian · GitHub , as directed by Download – KeePassXC for Debian and Ubuntu. –> INCOMPLETE functionality.

4, i installed the same KeePassXC 2.2.1 pgm from GitHub in my KDE Neon VM. –> INCOMPLETE functionality.

  1. i installed the same KeePassXC 2.2.1 pgm from GitHub in my Mint 18.2 KDE VM. –> INCOMPLETE functionality.

  2. i installed the same KeePassXC 2.2.1 pgm from GitHub in my Linux Lite [Xfce] 3.6 VM. –> FULL functionality.

  3. i installed the same KeePassXC 2.2.1 pgm from GitHub in my Ubuntu MATE 16.04 VM. –> FULL functionality.

  4. i installed the same KeePassXC 2.2.1 pgm from GitHub in my Mint 18.2 Cinnamon VM. –> FULL functionality.

  5. i installed the same KeePassXC 2.2.1 pgm from GitHub in my Mint 18 MATE VM. –> FULL functionality.

  6. i installed the same KeePassXC 2.2.1 pgm from GitHub in my Mint 18 Xfce VM. –> FULL functionality.

I identified a pattern from reviewing all the above results: FULL functionality for all non-Plasma5 DEs, but **INCOMPLETE functionality for ALL Plasma5 DEs **[ie, no manually-added attribute will copy to the clipboard (the manual items are those that show up below the line in that second pic, above)] … how freaky is this???

One of my Tumbleweed VMs has multiple DEs installed; Plasma5, Gnome, Xfce, MATE, & Enlightenment. I booted it, logged into Gnome, installed KeePassXC from the TW Repo, then tested –> FULL functionality.

Logged out, then logged into Xfce –> FULL functionality.
Logged out, then logged into MATE –> FULL functionality.
Logged out, then logged into Enlightenment –> FULL functionality.
Logged out, then logged into IceWM –> FULL functionality.
Logged out, then logged into KDE Plasma Workspace –> INCOMPLETE functionality.

I stress that in each of these VMs tested today the KeePassXC pgm is the “real” one, ie, not a Snap or AppImage.

Summary:
In EVERY Plasma5 VM, the IDENTICAL (mis)behaviour occurs as with my Tower’s real oS TW KDE, & also Leap 42.3 KDE VMs, ie;

No manually-added attribute will copy to the clipboard, with these repos versions [the manual items are those that show up below the line in that second pic, above].

So now a clearer but weirder picture has emerged, viz, something specific about Plasma5 & only Plasma5, interferes with the extra functionality of KeePassXC when running natively [ie, not a Snap or AppImage].

Tomorrow i shall create an oS Bug Report summarising all this info [even though my testing proves the fault is in KDE, not TW or Leap]. How extremely strange !

A further, & finally very happy, Update.

The problem is solved. I stumbled across this … Documentation and FAQ – KeePassXC … from which i quote:

Q: Why can’t I copy advanced attributes to the clipboard or use certain shortcuts on KDE?

A: This is a “feature” in KDE’s platform theme. It automatically adds ampersand (&) characters to on-screen text to allow you to trigger an action by pressing Alt+HOTKEY on your keyboard. Unfortunately, this “feature” causes more trouble than it does good.
You can disable it by adding the following two lines to ~/.config/kdeglobals

[Development]
AutoCheckAccelerators=false

If you are like us and think this is a stupid feature, please consider voicing your concerns to the KDE guys.

This simple yet crucial file edit has completely solved the problem itself, AND also provided a good summary of the root cause. It is consistent with my discoveries from yesterday’s long testing that the problem only manifests in distros using the KDE DE.

No reboot, or even logout/in, was necessary. Simply make & save the edit, launch KeePassXC natively, & immediately enjoy the full functionality, at last.

Consequently:

  1. No Bug Report is necessary.
  2. The Repo version of KeePassXC is fine to use, thus…
  3. No need to privately build from source [unless of course the User wishes to compile with specific options enabled/disabled]
  4. No need to use the Snap
    package 1. No need to use the AppImage
    , thus consequently my non-unmounting Loop Device problem becomes irrelevant AppImages cause Loop Device mounting; can this be a cumulative problem? - Applications - openSUSE Forums

The End … lol!.