Which Flatpaks and other resources should be included in the "Downloads" section?

Site Development
1

Continuing the discussion from Fedora is not a user friendly Linux Distro:

2

We are probably being inconsistent here, I think some contributors are adding as many downloads as they can find, while others are only adding downloads officially published by the developer.

I think whether or not a download is linked to on the developer’s own website is a good base criteria in this situation.

1 Like
3

I think flatpaks should be generally reccommended, except when they’re browsers as they weaken the sandbox (both on Firefox and Chromium).

Stuff like Electron is a bit tricky - it would probably be an improvement for stuff like Signal that disables the electron sandbox, but for apps like Element I genuinely have no clue.

4

6 posts were split to a new topic: Does Flatpak weaken Chromium/Firefox’s sandbox?

10

I think it should be only official sources and no experimental builds or beta/alpha builds or anything. If we only link to the developer’s downloads page, then we might as well just have that link and nothing else.

11

I’m still talking about making direct links, but sourcing those links from the developer’s downloads page.

Actually, I would even say we should link to unofficial downloads if they are endorsed by the developer. For example, I think we could link to these downloads listed on Brave’s download page. Lots of projects have community builds.

12

Having a verified check on Flathub seems to be a more straightforward and easy to understand mark of trust?

If I see that the developer of “App X” is on GitHub list of developers (on the right side of the page) and the same is seen also in the maintainers of “App X” on flatpak, does that lend a certain degree of credibility that more or less the maintainers are the same enough, even without the verified mark on Flathub?

13

16 posts were split to a new topic: Are community maintained packages as safe as developer-provided ones?

15

I don’t think packages being community maintained is that big of a deal, as it has been the case for years without issues. For example, Fedora RPMs are arguably mostly community maintained and so is most other distros.

Fedora Packages are maintained collectively by a community of both Red Hat members and volunteers.

Take bitwarden for example, we all know people complained that bitwarden flatpak ain’t maintained officially by bitwarden itself. But so what? You can easily see the package manifest yourself . It beats going to the official website and getting an appimage. Isn’t the good thing of linux (aside from privacy) when compared to windows the package management system? Going to the website of every publisher and manually downloading things is just trying to recreate windows distribution system on linux. Which will likely lead to a mess of appimages and apps needing to update itself (look how that went on windows)

Or take our beloved firefox for example, nowhere in the website lists the flatpak repo. Do you want the user to download a tar.bz2 file and figure out how to install it themselves?

Software being packaged by a third party is not a problem as long as the process is transparent and verifiable

16

Whats the proper way of doing these manifest checks? What are the gotchas that you have to avoid?

17

Look for something like this:

modules:
- name: appname
  sources:
    - type: file
      url: https://url-to-source-code-or-binary.com/package.tgz

There can be multiple of these throughout the package manifest.

Ask yourself: do all the URLs point to something on the original developer’s website or Github/Gitlab? If other modules are there: do you think their URLs are trustworthy or potential malware? (The other modules are dependencies and libraries the app needs.)

2 Likes
18

While I understand that in a way, I have to do these as well in the original code, but do i have to check for these before each update so that the flatpak maintainers have not inserted malicious URLs?

19

This is a good point. The Flatpak cli utility doesn’t inform me when the manifest changes with diffs as AUR helpers like yay do.

20
  • I don’t use unofficial Flatpak or Snap packages.
  • I tend to avoid Electron apps. Because they’re usually running on an outdated Electron version, which would affect both the performance and security of the app. Many apps also run without sandboxing. If there’s a PWA AKA web version, I would use it instead.
  • Using Firefox from a distro’s repo is a bad idea, at least for openSUSE Tumbleweed here, as it is usually very late from many days to weeks on updating. At the time of this writing, it is still at version 118, see here.

EDIT: I put in the wrong link there regarding Firefox situation in the OBS repo. The one I previously linked is a devel repo officially managed by Mozilla, which is not added/enabled by default. Nevertheless, it is still many days behind the official release on other channels.

The correct repo link should be the one from openSUSE’s factory repo, as this is the main update channel for openSUSE Tumbleweed. This repo is even behind the devel repo I previously linked. You can expect up to a few weeks behind other update channels. Therefore, I do not recommend anyone to use both of the repo versions of Firefox on Tumbleweed.

Personally, I use Brave and call it a day :joy: