Secure Flatpaks on Fedora. How to handle Flathub and unofficial packages after the Snap Malware accidents?

Ask Fedora
, , ,
1

Currently, Fedora default is no Flathub at all, afaik. At least in Kinoite, without the custom GNOME setup dialog.

These Fedora Flatpaks are probably very secure. Problem: They are not official and some packages cannot work, like video players and Browsers.

So in the end, users need rpmfusion, or they need to add flathub, best UX is to remove Fedora Flatpak in the same instance, to automatically get the correct Firefox for example. Also to remove the Fedora runtimes and reduce RAM usage.

Now you have Flathub, unfiltered, some apps verified, some just random apps from any random person. Which can be a problem, as we saw in the Snap cases with Malware spreaded there.

I can imagine this should be solved upstream, via a flathub and flathub_unofficial repo. Where the official ones are the ones made by verified original developers.

But then there are exceptions, like secure and well maintained apps, well known, established, like Bitwarden, VLC and so on, where the upstream developers are not responding to any Feature Requests and have no idea of Flatpak.

This would lead me to think, a list of approved apps would make sense. Then there could be two repos, or configurations of the one repo, or however done, where you can opt-in to the untested apps, but the rest is “Fedora Community verified”.

This would not mean you have no apps anymore available, but a secure system where all apps are checked prior to just appearing there. Many lack good isolation from the system, may be phishing etc. I can imagine that the Flathub community manage the apps well, but I am not too sure.

What do you think?

2

On the Flathub thing, I think half of the issue is that many of the proprietary packaged apps are marked under the actual developer and not who packaged it; eg if you searched CLion, it looks like it’s packaged by JetBrains, but this note at the bottom tells all:

NOTE: This wrapper is not verified by, affiliated with, or supported by JetBrains s.r.o.

You actually have to scroll down to see that. I personally think that there should be a separate category on Flathub for these for people that package proprietary apps.

Another thing could also be having some sort of indicator to see if it was packaged by a maintainer of the app or a third party; or as you said, split the repos.

2 Likes
3

Yes, a seperate proprietary repo would be great.

And the verification seems to be a mistake then?

4

It’s worth noting that Flathub has a thorough review process for initial app submission. This can’t fully prevent a bad actor from introducing malware in an update, but it does provide a sort of ‘social’ barrier. By contrast, Snapcraft submission is entirely automated, with manual review only for specific permissions. (They’ve apparently resumed automatic registration after the incident, with daily reviews of new snaps for suspicious behavior.)

Also, there is already support for a verified subset of Flathub:

flatpak remote-modify --subset=verified flathub

or

flatpak remote-add --if-not-exists --subset=verified flathub-verified https://flathub.org/repo/flathub.flatpakrepo

With the second option, you can still install unverified apps from the normal flathub remote, but you can check verification by an app’s presence in flathub-verified.

There are similar subsets for free software (floss) and for the intersection of both (verified_floss).

2 Likes
6

CLion is not marked as verified. Admittedly, the absence of a badge isn’t particularly obvious to the uninitiated, hence the disclaimer. Perhaps Flathub should also explicitly mark unverified apps.

What are you referring to here?

1 Like
7

didnt check it, so the verification is no problem.

I just meant that maybe it would enhance trust if the flatpaks would not only come from a clear origin, but also be sorted for proprietary or FOSS.

Currently, its like having the chrome repo preinstalled, not making clear that thats not open source software.

8

This discussion seems to be related to a repo that is something like the apple store, or the google play store where apps are supposedly verified by the store to not contain malware.

In order for a repo to do something like that it would require some amount of resources to quarantine submissions while performing the verification as well as possibly a dedicated team to verify the software.

Certifying software as malware free may also incur some amount of liability.

I like the idea of being able to select packages that are verified as malware free, but wonder if any team/repo/individuals would be willing to front the resources and assume potential liabilities if something slipped through the verification process. Not to mention the potential costs involved.

1 Like
9

What do you mean by verification being a mistake?

The definition of “verified” should probably be “added to Flathub/other repo by maintainer(s) of apps”.

10

I understood your comment so, that the app was marked verified but isnt. But yes, if its just a wrapper like many others, that also look official, its the typical Flathub state and would be dealt with using the --subset=verified stage.

11

My point was less that there should be a flag for when something is repackaged by a third party, not that it’s verified.

1 Like
13

isnt that the same thing? Verification verifies that is was not packaged by a third party, but by the correct people

14

Actually, yeah. I think it does.

15

Hey, I want to create a just file for that and was wondering, how to revert the subset manipulation of the existing remote?

does this work?

flatpak remote-modify --subset=all flathub

I could not find a list of all subsets, which would be really needed

16

That seems like a missing feature in the flatpak UI. You’d need to flatpak remote-delete --force flathub and then add it again without the subset.

The subsets are listed here: Installation | Flathub Documentation

1 Like
17

which is not an option as all apps installed from that repo will be removed. I will report the issue

18

That’s what --force is for. It should let you delete the remote anyway.

19

so this removed the remote and leaves the apps with no remote?

Is there a command to rebase the apps to another remote then?

20

You can just add the remote back with the same name and everything should keep working.

1 Like