Provide KeePassXC as a FlatPak #1524
Comments
|
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 keepassxreboot/keepassxc-org#28 |
droidmonkey
changed the title
|
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. |
|
@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 #1524 (comment) 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 ***@***.***> 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
<#1524 (comment)>,
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. [*] 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 flathub/org.keepassxc.KeePassXC#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.. 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. I think the main issue with the FlatPak is the the need to allow access to the 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 , |
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. |
|
I couldn't disagree more with that article.
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. 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. |
@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. |
|
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. |
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.
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.
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. |
Sounds like classic Android. 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. 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? |
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.
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. |
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. |
|
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? |
ghost
mentioned this issue
|
And we have now taken over the FlatPak repository and published 2.7.1 to the main line Flathub distribution. |
|
Reading your 2.7.1 release blog post, I wonder if you will be announcing the official transition to Flatpak separately?
The blog post gives me the impression that it will still take a while for this transition to be completed. Is that the case? |
|
And I also want to take this opportunity to say thank you for making official KeePassXC Flatpak support possible! |
|
It's already done, the existing flathub instance is now controlled by us |
|
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 |
|
If it is a flatpak packaging or sandbox issue it goes in the flathub repo |
|
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? |
Yes I'll see if I can get the screenshots updated. |
|
thank you very much! yes, the screenshots do not show a dark mode yet, for example. |
|
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? |
|
That seems like a major problem with the search function on flathub to me. |
Looks like it's being worked on: flathub-infra/linux-store-frontend#280 |
and others
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:
The text was updated successfully, but these errors were encountered: