Closed buhund closed 2 years ago
That is NOT official, but it looks like its just instructions for a machine to auto-build from source. The patch doesn't do anything but add Flatpack to the cmake file. We could support this officially in the future.
This is related to https://github.com/keepassxreboot/keepassxreboot.github.io/issues/28
Slightly confused. droidmonkey says it's not official, but is not the one I found on Flathub the same as the one mentioned on the ticked linked by TheZ3ro, which is there under "offical Flatpak from flathub"? The url for both seems to be the same at least.
@lutracw the first comment is not by a KeePassXC owner. It's official for flathuib in the sense that flathub directly release it (they maintain it) It NOT official by us, in the sense that we don't build it directly ourself and we don't offer support for it
@TheZ3ro I see. Thanks for the clarification. I should think it would be "safe" then, to use it, but I understand that you can't in good conscience vouch for it since you're not the ones to package/provide it. I'll just keep to the PPA for now (already installed, after all), and keeping an eye out for an official Flatpack release by you guys.
It not so much about security, it's more about deployment bugs we cannot fix.
Whoever created the flatpak repo, you could just ask them to take it over. I'd also suggest you to do that.
@rugk it's the flathub repository, we can't "take it over". As said in https://github.com/keepassxreboot/keepassxc/issues/1524#issuecomment-368344808 flatpak is an "offical" build since it's compiled locally from github sources, but we do NOT offer support for bug with that distribution channel (unlike snap and appimage)
That's stupid. First, most bugs are likely not related to the flatpak and secondly it is kinda unfair to offer it for one technology, but not for the other. To get a widespread software, you should support as much technology stacks as possible.
They Offer it in 4 Different forms. Source, PPA, Snap, and Appimage. Demanding a fifth and saying they are "stupid" not to is entitled and borderline useless when someone else has already packaged and is supporting it on there own and there is no reason one of the other formats can be used at essentially no cost.
On Fri, Mar 16, 2018 at 4:10 PM, rugk notifications@github.com wrote:
That's stupid. First, most bugs are likely not related to the flatpak and secondly it is kinda unfair to offer it for one technology, but not for the other. To get a widespread software, you should support as much technology stacks as possible.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/keepassxreboot/keepassxc/issues/1524#issuecomment-373830999, or mute the thread https://github.com/notifications/unsubscribe-auth/ACk71BsGsDjnTGNa3XmDPEFfAVj-rdfkks5tfBwagaJpZM4SR344 .
We simply cannot support all platforms. Bugs that are present in any KeePassXC release will be fixed by us, but any packaging-related bugs have to be fixed by the package provider. We already have enough weird packaging bugs with Snaps and we really don't feel like (and don't have the time for) fixing a whole bunch more for another "bleeding-edge" distribution channel.
Maybe my comment was not clear enough: we do NOT offer support for bugs in that specific distribution channel, the guys at flathub will take care of bugs in the KeePassXC flatpak package. Bugs in KeePassXC itself are always "supported"*
[*] Note: this project is open-source and maintained on our free-time as an hobby
Would be still nice to have you guys taking a look on it too, because at the end of the day the flatpak is not usable right now (because of sandboxing).
What I dont understand is that you support PPA and snap, both are Ubuntu packages. 🤔
I think https://github.com/flathub/org.keepassxc.KeePassXC/issues/4 is a bug and could be fixed. Maybe the flatpak needs some more permissions or so, or you need to save it somewhere else. So it is not flatpak's problem that this does not work…
@rugk could be a Qt/kde runtime thing or a portal bug. I have no idea..
Snaps are not just for ubuntu, they can be run on many different distributions. https://snapcraft.io/
In fact based on the icons i see on their website, every single major linux distro...
@droidmonkey it's only in the AUR of arch, wich sucks, because the reason for me to use flatpak is to not use the AUR.. it's based on the ubuntu runtime, instead of a nice generic one. It's not secure, there is no desktop integration yet and there is this annoying visible snap folder in my users home.
So all in all, they can advertise whatever they want, its a Ubuntu thing, while flatpak is the freedesktop project project.
Also AFAIK it does not have sandboxing on other distros than Ubuntu.
I'll take a look at flatpak and possibly fork the existing one being run by the other individual. It looks like we can achieve feature parity with snap at this point, but its just another syntax to learn and maintain...
FlatPak is great. The sand boxing is really a great security feature and matched KeePassXC narrative of securing the user data.
I think the main issue with the FlatPak is the the need to allow access to the Home
folder.
I wrote about it here - https://github.com/flathub/org.keepassxc.KeePassXC/issues/4#issuecomment-392418043.
May I ask why did you prefer Snap over FlatPak (Or for that matter AppImage over FlatPak)?
AppImage is just a self-contained binary that runs everywhere. Flatpak and Snap both need some other software installed first, so those are not comparable for that matter. The reason we chose Snap was that is was probably the most mature and widely available implementation of confined cross-platform application environments at that time. Generally, we might have chosen Flatpak as well, but it happened to be Snap and we don't want to maintain both.
Snaps are 100x easier to define, build, and deploy at this point. Flatpak reminds me of using command line Git... I could not get the Flatpak hosted on Flathub built using the standard commands....
@droidmonkey @phoerious , Out of curiosity, what are the difference between FlatPak and Snap security and performance wise?
There are no performance differences since they run natively in the OS. security is largely dependent on the number of plugs (snaps) or portals (flatpaks) that you connect/open. You can read all about each of them on their respective websites.
I'm not involved in this project, so I'll acknowledge that there could be something I'm missing. But as an end user of this software, and as a Linux enthusiast, I find it quite bizarre that a PPA, Snap, and AppImage are provided officially, and yet not Flatpak. Flatpak is becoming the modern standard of application distribution on Linux, whereas Snap is an Ubuntu-specific thing. As someone else mentioned, a PPA is also being official provided, so that's now two things for Ubuntu.
Despite the advertising on the Snap store, it is Ubuntu specific, and if you look at the Linux community (for example, visit Reddit or Hacker News or anywhere where Linux users congregate), you'll see that Flatpak is everyone's go-to rather than Snap. Why? Because it's the standard solution that most everyone is uniting on, a Freedesktop project as somebody mentioned, and is the superior technical solution. Fedora has Flatpak installed by default, and Arch has it in the official repositories. As was mentioned, on Arch, Snap is only available via the Arch User Repository, which is an unsupported way of obtaining unofficial packages, which can be complicated for some people to use, and which can run the risk of malware. Part of the reason of using something like Flatpak or Snap is to get away from the AUR.
There are even at least two distros using Flatpak as the default, primary method of distributing applications: Endless OS and Fedora Silverblue (previously known as Fedora Atomic Workstation). Fedora Silverblue might end up replacing Fedora Workstation at some point in the future. The point is, the world is moving towards Flatpak as the standard distribution model for applications on Linux. By all means, have a PPA, a Snap, or an AppImage if you want. But not providing a Flatpak seems very strange to me.
Would a flatpak help with the issues seen on RHEL7 for v2.5.0 and above? (2.4.3 ran fin but the 2.5.0 AppImage does not even start due to increased requirements in the binary).
The problem is not the packaging format, the problem is the base system used for building that package.
@phoerious What does your build system need to enable reproducible Flatpak builds?
p.s. I thought there is no official package from you so far? https://flathub.org/apps/details/org.keepassxc.KeePassXC But the explanation "Developer KeePassXC Team" doesn't let me conclude that it is an unofficial third party package of your app.
I had installed keepassxc from flathub, do I have to worry or does the current version match the version on Github?
The flatpak downloads the sources from GitHub upon building. You always have to worry, but the maintainers of the flatpak have published their build code.
I think some official endorsement of https://flathub.org/apps/details/org.keepassxc.KeePassXC by the KeePassXC maintainers and/or a link on https://keepassxc.org/download/#linux (ultimately with some sort of signature/hash to validate authenticity) would make everyone happy, even if it came with a "don't bug us with installation problems" disclaimer. The essential problem at the moment is that people are reluctant to open their password database in a KeePassXC executable not downloaded from an official source because it could do who-knows-what.
I would like to add an ethical quality to the discussion.
Flathub currently does not separate into FLOSS and proprietary apps. If I get even one Free Software app as a flatpak from Flathub, I have the entire remote repository with all proprietary apps in my Software Center.
There will certainly be some users like me who want their KeePassXC Flatpak to come not only from a secure source, as discussed in previous posts, but also from a 100% FLOSS source.
Therefore I would like to ask you to consider providing an officially maintained Flatpak download from https://keepassxc.org/download/#linux, which is maintained & signed by the KeePassXC team. At least until Flathub offers a libre spin-off for its platform.
Nobody forces you to install any of the proprietary software packages.
Another thing is that my distro wants to go with Flatpak first/only. So I need a secure source for a security sensitive application like your password manager. That's why I care what happens to your Flatpak whenever you want to offer one.
Yes, I do not need to install the proprietary packages, nor do I need to use Flathub. But where should I get it alternatively as Flatpak? And: Hiding or do not install does not mean that it is no longer there in the remote repo sources. I consciously choose an ethical solution when choosing my operating system. I would like to be able to realize this for the choice of my software and its sources as well.
My concern is not that KeePassXC should not be on Flathub. Since Flathub does not seem to act actively in the direction to maintain a separate repository for FLOSS packages flathub/flathub#691, I would be glad if you offer an official version as a download e.g. via your website or another safe place as an alternative for people who are looking for 100% Free Software. So my request is about an Flatpak alternative in addition to Flathub. At least for the transition until Flathub also works for users like me. I know it's extra work and I'm very grateful for what you're doing now! Nevertheless, my wish remains that you as the developer of KeePassXC not only appreciate my use case, but also actively support my positive FLOSS attitude wherever possible.
How do you [as a team of developers or part of the KeePassXC community] feel about this?
Thanks for your time!
@4jNsY6fCVqZv have not read all of that, but what could solve your use case are Fedora flatpaks. They are packaged according to the Fedora rules (i.e. FLOSS only e.g.), but can be, of course, installed on any distro.
registry.fedoraproject.org
is the source for these.
@rugk Hi, thank you for pointing that out! It would certainly be a wonderful alternative if it is FLOSS compatible. At this point it would also be exciting to point out that the developers of the elementary OS platform are already working on such a free repository base for Flatpaks. https://github.com/elementary/flatpak-platform Nevertheless, the same applies to all alternatives: In order for users to be able to trust them, an official version would be required, which is provided, signed and maintained by KeePassXC. That's why I suggested the download area on the KeePassXC website, because this way seems to be independent from third party repositories. And also the question if those are pure FLOSS or not will not be important anymore.
To put things into perspective, according to https://github.com/paulcarroty/flathub-app-stats/releases/download/20200107122249-08e9356/yearly.json the community run version of KeePassXC on Flathub has been downloaded 85,626 times within the last year.
I also would prefer using the Flatpak, but only if it's an officially supported by the KeePassXC team.
Within a year that's not much. We get three times more direct downloads than that for a single release in two months. I believe the Snap is also way more popular.
Flathub is considered trustworthy by the general Linux community. It is easy to confirm at any time that Flathub is fetching the source tarballs from public repositories and building KeePassXC that way.
Therefore, I feel more confident in the unofficial Flatpak on Flathub to remain safe and unaffected in the case that a malicious party compromises the account of a KeePassXC maintainer.
The daily auto-updating Snap package seems to be entirely in the hands of @droidmonkey, while the PPA is with @phoerious. When using these ways to acquire a binary of KeePassXC, users place their entire trust in the account safety and goodwill of these individuals.
Additionally, my understanding is that the prebuilt assets published on Github for every release, which are then used for download links on the website and the in-application update checker, are all uploaded by the listed author. Consequently, those binaries could be compromised in a similar manner too. The exception to this are the Source code (zip/tar.gz) links on the bottom such as https://github.com/keepassxreboot/keepassxc/archive/<tag>.tar.gz
, which, as I understand, are provided directly by Github based on that tagged commit in the repository.
In summary, I believe that the most secure methods to acquire KeePassXC are to personally compile it from source or let a party you already trust by default to do it for you, including Flathub or the official repositories of your Linux distribution's package manager (install with apt, dnf, etc.). Am I mistaken to think that the binaries provided by this project's maintainers are more prone to being compromised?
When using these ways to acquire a binary of KeePassXC, users place their entire trust in the account safety and goodwill of these individuals.
If our accounts or signing keys get compromised, Flathub as a downstream platform will be compromised as well.
BTW I personally would prefer flatpak. In contrast to snap, you can also self-host it, so you stay in control, and it is widely supported. (snap is not so nice to setup in many distros and snap's security depends on AppArmor, which is not always available in many distros) Also – in contrast to snaps – flatpaks do not only claim to be distro-independent, but actually are. Furthermore even Linux Mint criticizes snap, because you cannot self-host a snap server as it is proprietary and (thus) also cannot modify the packages that are served centralized by Ubuntu.
When using these ways to acquire a binary of KeePassXC, users place their entire trust in the account safety and goodwill of these individuals.
If our accounts or signing keys get compromised, Flathub as a downstream platform will be compromised as well.
Perhaps I should have clarified that, if the public source code itself is maliciously compromised, of course building it downstream would not make a difference. But it would be difficult to hide malicious, compromised source code in a public repository, as it will be easily discovered.
On the other hand, the binaries released by the maintainers' accounts as PPA, Snap, or other binaries on the releases page could contain malicious elements and be built from a different source, while the public code remains clean and unaffected. This is the issue that reproducible builds tackle.
I think Flatpak used to fetch the binaries built by us, not the source code. At least homebrew is still doing it.
Edit: Actually, I think Flatpak has always built from source, but other third-party distribution platforms are using the binaries.
Right now, Flathub is using the manually uploaded source tarball from e.g. https://github.com/keepassxreboot/keepassxc/releases/download/2.5.4/keepassxc-2.5.4-src.tar.xz
which could potentially contain different code than the repository on Github (which as I noted would be more difficult to covertly compromise than a binary). I will open an issue with Flathub to switch the URL to https://github.com/keepassxreboot/keepassxc/archive/<tag>.tar.gz
which should be provided by Github and will always contain the contents of the publicly available repository.
It does contain different files than the GitHub-provided one. If you build from the tar.gz, you will need to configure your build differently, otherwise your binary will be marked as a snapshot or pre-release build.
It does contain different files than the GitHub-provided one. If you build from the tar.gz, you will need to configure your build differently, otherwise your binary will be marked as a snapshot or pre-release build.
The maintainer-uploaded release tarballs only include two additional one-liner files over the Github-provided .tar.gz of the same tag. Only in [.tar.xz]: .gitrev Only in [.tar.xz]: .version
The rest is identical. If these two files are necessary for a release build, it would be trivial to include them in the Flatpak-specific patchset.
I would also be very eager to see KeepassXC as an officially supported flatpak. I have used the flatpak, as that is my preferred way to install software, but there are some issues with the user interface, and it didn't receive the update to 2.6.0. I understand this might involve some developer work, but if it were possible that would be AMAZING!
I am currently moving as many GUI applications as possible from PPAs to Flatpak. KeePassXC would be awesome to be part of this, too.
The process of overtaking the flathub repository by the official maintainers is described in the Flaghub App Submission guide.
@darkdragon-001 KeePassXC is available as an "inofficial" flatpak on Flathub. See https://flathub.org/apps/details/org.keepassxc.KeePassXC. @kd2flz update to v2.6.0 seems to be blocked currently. For more information see/follow https://github.com/flathub/org.keepassxc.KeePassXC/issues/60.
FWIW, the version now in flathub is 2.6.0, I have been waiting for 2.6.1 with no luck. It would be nice to have the latest and greatest version in flathub.
Before migrating to flatpak, I tried the keepassxc snap version extensively and it's not there yet, flatpak is more reliable; specially when restricting some capabilities; in my case I wanted the container to not have access to internet. With flatpak this is super simple and works great; with snaps, I couldn't get it to work; the snap version wouldn't honour my dark theme setting, fonts look weird, etc. Flatpak = seamless. All of this in Ubuntu where snaps are supposed to "just work" :)
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: