Caprine: No Flatpak install option for Linux users

[yerbestpal]

I recently migrated to Fedora from Ubuntu. Though I appreciate that there are only so many distros you can support, Flatpak support would make installation much easier for many users, as well as increase user base.

[sindresorhus]

It needs to be supported by electron-builder first. See: https://github.com/electron-userland/electron-builder/issues/3212

[yerbestpal]

Does this help?

[sindresorhus]

Going to pass on Flatpack because of http://flatkill.org/

[TamasBarta]

The problem with flatkill.org is that most of its complaints are about packagers not the format itself. Letting a project die from starvation (no packages distributed in its library) because of a random website doesn't help it improve. Also I saw Caprine on Snapcraft and I don't know if you're the packager or someone else did it for you, but every single discussion I came across about flatkill.org agrees that Snap is ever worse. If I make a snapkill.org, will you stop supporting the packaging of Caprine in Snap?
No offensive intentions in my comment, I love you made Caprine, but it looks like the discussion around Flatpak and Snap is hacked with money (Cannonical), and bullshit like flatkill.org, an anonymus random manipulative piece of text on the internet.

[yerbestpal]

I agree that it is a hasty decision ie flatkill.org, but I can understand if you don't want to cater to yet _another_ packing format for Linux, since the app is very well supported outside of Flatpak.

[zer09]

@sindresorhus please add support for flatpak

[yerbestpal]

@zer09 doubtful that anything will come of that since the issue is closed. I would be interested in maintaining a Flatpak of Caprine, though I have zero experience in it. Once I have more time, I will look into it.

[TheEvilSkeleton]

@yerbestpal in case you're interested, I created a flatpak: https://github.com/TheEvilSkeleton/com.sindresorhus.Caprine

I based it from com.wire.WireDesktop.yml, so all my thanks go to them for making my life much easier.

Anyway, just run:

git clone https://github.com/TheEvilSkeleton/com.sindresorhus.Caprine.git ~/com.sindresorhus.Caprine
git clone https://github.com/flathub/shared-modules ~/com.sindresorhus.Caprine/shared-modules
cd ~/com.sindresorhus.Caprine
flatpak-builder --force-clean --install-deps-from=flathub --install --user build-dir com.sindresorhus.Caprine.yml

And you should have the flatpak running.

I'm not planning to publish it in Flathub as I am not planning to maintain it anytime soon, but just letting everyone know that I'll be keeping this flatpak so if anyone wants to maintain it, they are free to do so.

[TheEvilSkeleton]

Going to pass on Flatpack because of http://flatkill.org/

(Now https://flatkill.org/2020/)

That article is a legit shitpost and it's filled with FUD. Edit: this article is still filled with FUD, but there are good points.

---

Almost all popular apps on Flathub still come with filesystem=host or filesystem=home permissions, in other words, write access to the user home directory (and more) so all it takes to escape the sandbox is trivial echo download_and_execute_evil >> ~/.bashrc. That's it.

Almost all popular apps on Flathub still come with filesystem=host or filesystem=home permissions

This is completely false. Steam, Discord, Chrome and Spotify don't come with those permissions, and they're most-likely the most popular programs.

Gimp

They're planning on fixing it: https://github.com/flathub/org.gimp.GIMP/pull/74#issuecomment-716149065, and then again, developers use GIMP very extensively, thus requiring more permissions.

VSCodium, PyCharm

Seriously? Those are IDEs. Why would one just unironically restrict an IDE?

[...] are still not sandboxed.

That makes no sense. All programs are sandboxed and there's no option to remove the sandboxing.

echo download_and_execute_evil >> ~/.bashrc.

That's a fair point, but that almost never happens with popular programs, unless someone can prove me wrong.

Flatpak apps and runtimes STILL contain long known security holes

This is correct but unfair. He's targeting Flatpak when it's obviously a packager issue.

Recently I stumbled upon an article from 2011 which started what is today known as flatpak, in the words of the project founder:

"Another problem is with security (or bugfix) updates in bundled libraries. With bundled libraries its much harder to upgrade a single library, as you need to find and upgrade each app that uses it. Better tooling and upgrader support can lessen the impact of this, but not completely eliminate it."

That is a very good point and I agree.

---

This post was made to hate on Flatpak just for the sake on hating. Although they have a really good point, it doesn't mean that Flatpak should die. Flatpak was the only one to make software distribution actually easy while also providing good security and keeping it ethical: it supports custom GTK themes, XDG FileChooser Portal, all apps are sandboxed and you can't disable it, you can use a program like Flatseal to manage permissions, easy to create a manifest, cross-architecture, free software, containerized, etc.

---

https://github.com/sindresorhus/caprine/issues/577#issuecomment-438611105

Also this ^

https://www.reddit.com/r/linux/comments/9n50ba/lets_see_why_flatpak_and_sandboxing_are_awesome/

And this ^

[dusansimic]

@TheEvilSkeleton I agree that most of the problems with outdated libraries and no security patches is the packagers fault, not formats. I also agree that Flatpak does a lot of good, I use it myself. However, flatkill.org is not really the reason we don't want to support it. The main, and probably the only reason, is that it's not supported by Electron Builder. We want to have a clean pipeline and run builds that are easy to maintain and debug (which still proves to be a challenge if you're building for 5 targets). Until Electron Builder adds Flatpak support, we won't consider adding it.

Anyone is however welcome to make their own builds and even share them with everyone else! For example, we're not maintaining the Arch package.

Again, we personally don't have anything against Flatpak, we just don't want to maintain our scripts for building the Flatpak package.

[TheEvilSkeleton]

@dusansimic what are your thoughts on using something like electron-installer-flatpak in the meantime? I don't know much about it because I'm pretty new in Electron, but it might be useful.

[dusansimic]

@TheEvilSkeleton thanks for the link. As I said, we are trying to stick to Electron Builder but electron-installer might be useful for third party package, not an official one. I can see that it uses an outdated base package for electron (io.atom.electron.BaseApp) while the latest one is org.electronjs.Electron2.BaseApp. I'm not sure what's the difference and which version of electron do they actually run but if anyone has any input on this it would be very welcome!