Provide KeePassXC as a FlatPak

[buhund]

Hello.

First, thanks for the awesome work you do!

My question pertains to KeepassXC as Flatpak. I have found KeepassXC on Flathub, but since there's no mention of it on the official KeepassXC page (neither on download, nor blog), I'm hessitant to use it.

https://flathub.org/apps/ (ctrl+F --> "keepassxc")

https://github.com/flathub/org.keepassxc.KeePassXC

I currently use the offical PPA, since the Snaps I've used (KPXC and others) always end up with "Win 95" interface, and a Win 95 window for locating files.

My question is largely this:

• Are these official Flatpaks of KeepassXC?
• ...if no, are there any plans for an official Flatpak?

[WalnussPower]

I personnally see Flatpak as a direct competitor too Snap. Given, that a lot of people dislike Canonical and therefore Snap, it seems sensible to offer them the choice.

[ssokolow]

Out of curiosity, what are the difference between FlatPak and Snap security and performance wise?

I know it's been a while but, for anyone else who's wondering:

• Flatpak has no apparent performance downsides aside from possibly a little "having multiple versions of a dependency to ensure ABI stability will increase the chance that a shared library isn't in your disk cache". (Compared to the distro repo approach of rebuilding whatever is necessary to minimize the number of installed versions of the dependencies.)
• In my experience, snaps are visibly slow to start and are eager to clutter up the mount output with a forest of loopback mounts that make mount useless in practical terms unless you pipe its output through grep to filter them out.

[soredake]

Out of curiosity, what are the difference between FlatPak and Snap security and performance wise?

I know it's been a while but, for anyone else who's wondering:

• Flatpak has no apparent performance downsides aside from possibly a little "having multiple versions of a dependency to ensure ABI stability will increase the chance that a shared library isn't in your disk cache". (Compared to the distro repo approach of rebuilding whatever is necessary to minimize the number of installed versions of the dependencies.)
• In my experience, snaps are visibly slow to start and are eager to clutter up the mount output with a forest of loopback mounts that make mount useless in practical terms unless you pipe its output through grep to filter them out.

https://github.com/flatpak/flatpak/issues/4187

[ssokolow]

Point. I should have phrased it as "I haven't personally observed any performance downsides to using Flatpak".

...and, to be fair, I generally play indie games with low system requirements and already run them under Firejail (which also uses seccomp filtering) to ensure that they can't put non-hidden files/folders into $HOME (I'm looking at your use of getpwuid/getpwnam to try to force making a mess, The Escapists) and to ensure single-player GOG games are actually "Whatever experience I play now, I can archive", rather than having some kind of "It crashes if it can't reach the analytics server" bug.

[soredake]

https://github.com/flathub/org.keepassxc.KeePassXC/issues/81

[puelp]

It's an old post but may be relevant here: https://happyassassin.net/posts/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/

Basically in that person's opinion, Canonical conducted a heavy PR campaign early on to give off a sense of community consensus surrounding Snap where there was none, to mislead developers into thinking "Oh snap is backed by Canonical/Ubuntu? Then it must be the dominant Linux standard. OK, let's distribute our software with snap."

So anway...I thought I would add to the arguments in trying to convince the devs to add Flathub support.

First, there is the historical precedent.

Snap is developed by Canonical, while Flatpak and Flathub is developed and backed by a group of people who are primarily employed by Red Hat, and develop for Fedora/Freedesktop/GNOME/Red Hat/systemd/Wayland.

And the historical precedent that I'm speaking of is these guys' software outlasting Canonical's, of which some examples are:

• Unity: competed with GNOME 3 until it was killed and replaced by GNOME 3.
• Mir: competed with Wayland until it was killed and in the process of being replaced by Wayland
• upstart: competed with systemd until it was killed and replaced by systemd
• Ubuntu Software: competed with GNOME Software until it was killed and replaced by a surface-level rebrand of GNOME Software

Basically you can see the picture that I'm trying to paint here. Canonical has a juggernaut in the Ubuntu Linux distribution itself, but when they try to go beyond that and try to make their projects into the community standard, it doesn't work out so well.

In contrast, I do believe that a genuine community consensus is slowly but surely being built up around Flatpak and Flathub.

elementaryOS, Fedora, KDE, Linux Mint, all huge names in the Linux community just off the top of my head, and they have adopted Flathub as a primary method of distributing their apps, while shunning Snap.

For example, you can see that Kdenlive on the Snap Store is outdated (v20.12.3 on the stable channel, v21.04.1 on the beta channel) while the one Flathub is fresh (v21.04.2): https://snapcraft.io/kdenlive https://flathub.org/apps/details/org.kde.kdenlive

I hope that the KeePassXC devs are open to changing their minds. :)

[ghost]

I'm -1 on an officially supported Flatpak. See: https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html. Historically, when developers have taken over packages, they usually do a very poor job of it because they don't understand the ecosystem or the packaging guidelines. Furthermore, it undermines the community aspect of package management. As long as your software is easy to package or the developer cooperates with downstream, it shouldn't be an issue.

For the security aspect, Flathub is a curated repository and the Flatpaks are built directly from upstream. If you don't trust Flathub, then why would it be any different if a developer was in control? It would be vulnerable to exactly the same issues. None of the countermeasures I've seen either are 100% foolproof against malware and most of it is security theater. It doesn't matter how sandboxed or locked down the application is, at some point the password has to be in memory for it be usable by literally any other software (your browser, the keychain, unattended backups, the list goes on).

Snap is disliked by a large part of the community for being basically a Canonical initiative with a proprietary backend. Like most Canonical projects, they have a strong not-invented-here syndrome and it is designed to mainly work with Ubuntu. It also is inferior to Flatpak from a technical standpoint that I won't get into, but I think most people prefer Flatpak anyway.

So I find this whole discussion to be a little silly and I vote that we keep things the way that they are, which is to allow the developers on Flathub to keep maintaining the package. They are doing a fine job. If updates are slow, just open an issue and they will get around to it when they get around to it.

[droidmonkey]

Snaps and snap definitions have gotten way worse since we first created our snap. However, your argument doesn't hold water. Developers and Distributors need to work together to make the best experience for the end user. It has been demonstrated time and again that when the two don't work together the user experience suffers dramatically. To this end, we will be taking over the FlatPak definition at some point

[ssokolow]

Not to mention that systems which provide a consistent runtime across multiple distros are designed with the intent to make insights derived from packaging and testing done by upstream (who have the best understanding of what's being packaged) as broadly applicable to multiple target distros as possible.

In other words, Flatpak runtimes are, by definition, a mechanism to help upstream QA remain applicable despite distro variations.

Traiditional "upstream develops, downstream packages" is intended to allow the package maintenance to be divided among distro experts to make up for variations the upstream doesn't have the knowledge and manpower to anticipate.

This isn't about "Flathub maintainers may be malicious" but more about preventing the next Debian-OpenSSL fiasco. (When Debian package maintainers accidentally rendered OpenSSL server key generation grossly insecure by commenting out some code GCC was warning about that they didn't understand, which was seeding the random number generator.)

[Hasshu]

I'm -1 on an officially supported Flatpak. See: https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html.

@remyabel DeVault fails to understand one simple thing: the shorter the chain of trust is, the better. Instead, he insists on adding more links to it, and that's somehow supposed to make it stronger. I shouldn't have to trust additional people, especially when it comes to security-related software.

Historically, when developers have taken over packages, they usually do a very poor job of it because they don't understand the ecosystem or the packaging guidelines.

Except that Flatpak is supposed to be universal — there are no different ecosystems or packaging guidelines anymore.

Flatpaks are built directly from upstream

Not necessarily. "The application on Flathub should reflect, as closely as possible, the application in its unadulterated form, direct from its authors", but "should" =/= "must".

If you don't trust Flathub, then why would it be any different if a developer was in control?

I would trust Flathub much more if it hosted software packaged by its actual developer(s) instead of random Internet people.

None of the countermeasures I've seen either are 100% foolproof against malware and most of it is security theater. It doesn't matter how sandboxed or locked down the application is, at some point the password has to be in memory for it be usable by literally any other software (your browser, the keychain, unattended backups, the list goes on).

Perfect-solution fallacy.

If updates are slow, just open an issue and they will get around to it when they get around to it.

Because I have nothing better to do than reminding lazy third parties that they should be doing their job?

[ssokolow]

Not necessarily. "The application on Flathub should reflect, as closely as possible, the application in its unadulterated form, direct from its authors", but "should" =/= "must".

Yeah. Not long ago, having forgotten about that passage, I took the long route to convincing the maintainer of the MPV Flatpak to remove their custom extensions which were overriding my disabling of the OSC GUI to add features I didn't care about.

[phoerious]

I couldn't disagree more with that article.

There are hundreds of Linux distros and each does things differently — the package maintainers are the experts who save you the burden of learning how all of them work.

That is exactly the point. So how do we fix it? Certainly not by fostering more divergence by encouraging distros even more to do their own thing, right? On the contrary: Developers should absolutely ship their own apps. They are the only ones who know their apps inside out and things like backporting CVE patches are a total farce. Nobody knows if a 4-year old backport Frankenstein app is really any more secure than the original unpatched 4-year old app, because who knows if the patch works at all on that old code base? Worst case, it's even less secure because your untested partial patch created a totally new security vulnerability. Nobody tests those things. Also the argument that packagers take care of creating the best user experience is total bullshit. Yes, they do a great job ironing out certain minor platform bugs, but in the end it is us developers who have to fix such stuff. The number of reports that we have to deal with saying "KeePassXC does this weird thing X on Tipsydibble Linux with Kittybims-i3 wm" is utterly ridiculous.

So developers should package their apps and there should be a good, well-maintained, easy easy-to-use, and universal platform for it. There should of course also be guidelines for basic quality assurance, but they better be universal as well. It is absolutely absurd that even in 2021 it is still near-impossible to make a proper Linux binary. All other operating systems solved that problem decades ago.

I do agree that Snaps are quite clearly the worst implementation of this model and totally Canonical's NIH syndrome, but at least they try to break with Linux's technical debt of being virtually unpackageable for in their own weird way. If you ask me, I would prefer if all distros switched to Flatpak tomorrow, but as it stands, Flatpak is just yet another package format for us, unfortunately. We have to maintain at least three different Linux package formats already and they are not going away any time soon.

[Hasshu]

Yeah. Not long ago, having forgotten about that passage, I took the long route to convincing the maintainer of the MPV Flatpak to remove their custom extensions which were overriding my disabling of the OSC GUI to add features I didn't care about.

@ssokolow Ah, I've seen that one... Incidentally, mpv remains the only thing (apart from Nvidia drivers) that forces me to use third-party RPM repos on Fedora. But I digress.

@phoerious Heck, even Linus Torvalds himself believes it's a problem.

[JaneSmith]

I just want to chime in and point out that Valve's upcoming new portable Linux PC — the Steam Deck — will be making use of a similar approach to Fedora Silverblue. That is, an immutable base OS with third-party applications installed via modern Flatpaks. Further evidence that Flatpak is the solution most everyone is uniting on and standardising on. Having a modern Flatpak package for this application will make it much easier for users to install on the Steam Deck.

[ssokolow]

See: https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html

I agree with most of what's presented, but I don't agree with the effects. Namely that an elite collection of users (myself included) who know how to build stuff from source should have "This doesn't interest me, therefore it will never get popular" power of veto over projects that may not be targeting their demographic.

Ship your software as a simple tarball. Don’t ship pre-built binaries

One thing you shouldn’t do is go around asking distros to add your program to their repos. Once you ship your tarballs, your job is done. It’s the users who will go to their distro and ask for a new package.

How are users supposed to know they want a package if nobody can try it out first?

That's like saying that any music/audio technology which doesn't interest people sufficiently audiophile to know how to hook up a multi-component hi-fi system should be denied a chance to compete in the market. Thus delegitimizing the opinions of anyone outside our/your demographic.

P.S. Systems which invert this model, e.g. Flatpak, are completely missing the point.

Flathub. Flatpak is just a technology and Red Hat is providing its own APT/RPM-style repo for Fedora that meets the stated maintainership criteria and is pretty obviously intended to become a successor to RPM at the application level for spins like Fedora Silverblue.

[phoerious]

That is, an immutable base OS with third-party applications installed via modern Flatpaks.

Sounds like classic Android. Funny that most modern Android phones tend to diverge from that pattern again.

[rugk]

Funny that most modern Android phones tend to diverge from that pattern again.

Huh no? Android (respectively it's apps) is/are and always was/were sandboxed. And yes, I guess they got some inspiration from it. Generally, sandbox-like the desktop systems are worse than mobile platforms, because they miss a lot of strong/solid sandboxing. See xckd 1200. Even flatpak is far from perfect, but it is a try for a larger user base, at least. So yes, that's a very good development.

Anyway, to get on-topic again, don't even know why this issue here is still open, KeePassXC is available as a flatpak already, so what's up here?

[ssokolow]

Even flatpak is far from perfect, but it is a try for a larger user base

To be fair to Flatpak, they are very much focused on retrofitting an improved security baseline onto existing codebases. The more you need to modify the codebases, the harder that is to scale up. Most of their more impressive successes, like XDG portals, were achieved by retrofitting "the platform" in places like the GTK and Qt common dialogs.

KeePassXC is available as a flatpak already, so what's up here?

It's maintained by others, which adds another opportunity for a mistake or malicious action to open up a hole without someone familiar with the codebase noticing.

[phoerious]

Huh no? Android (respectively it's apps) is/are and always was/were sandboxed.

The apps are sandboxed, but the OS is usually no longer an immutable ROM that needs to be flashed in full in order to update it.

[gasinvein]

The KeePassXC flatpak has several patches improving quality of life for flatpak users. Maybe those could be merged into KeePassXC upstream codebase? Was it even proposed/considered?

[droidmonkey]

And we have now taken over the FlatPak repository and published 2.7.1 to the main line Flathub distribution.

[ghost]

Reading your 2.7.1 release blog post, I wonder if you will be announcing the official transition to Flatpak separately?

we recommend you switch to one of our other two supported Linux packages or to Flatpak once we announce an official Flathub channel.

The blog post gives me the impression that it will still take a while for this transition to be completed. Is that the case?

[ghost]

And I also want to take this opportunity to say thank you for making official KeePassXC Flatpak support possible!

[droidmonkey]

It's already done, the existing flathub instance is now controlled by us

[ghost]

So the updated version her https://flathub.org/apps/details/org.keepassxc.KeePassXC from April 15th is already the official version of the KeePassXC team and therefore safe to install?

P.s. Would you like to see issues concerning the Flatpak opened here https://github.com/flathub/org.keepassxc.KeePassXC/issues or here https://github.com/keepassxreboot/keepassxc/issues? At least the link on https://flathub.org/apps/details/org.keepassxc.KeePassXC refers to the KeePassXC repository for the issues.

[droidmonkey]

If it is a flatpak packaging or sandbox issue it goes in the flathub repo

[ghost]

It is an issue with screenshots not being up to date. I think that's part of the packaging, isn't it?

Can you imagine giving me a more clear statement on my first question?

[droidmonkey]

So the updated version her flathub.org/apps/details/org.keepassxc.KeePassXC from April 15th is already the official version of the KeePassXC team and therefore safe to install?

Yes

I'll see if I can get the screenshots updated.

[ghost]

thank you very much! yes, the screenshots do not show a dark mode yet, for example. maybe they can be matched regularly with the ones on your website when there are visible changes or new features.

[ghost]

P.s. I had also noticed that I do not get to KeePassXC in the Flathub search for "keepass". Only when I enter at least "keepassx". Maybe you can make the application even easier to find by adjusting the keywords?

[droidmonkey]

That seems like a major problem with the search function on flathub to me.

[fossrob]

That seems like a major problem with the search function on flathub to me.

Looks like it's being worked on: https://github.com/flathub/linux-store-frontend/issues/280

https://flathub.vercel.app/apps/search/keepass