How well are flathub packages moderated?

There has been a recent wave of AUR malware; is flathub or flatpaks susceptible to this? My understanding is that each Flatpak must be reviewed and approved. Is it possible that the AUR malware would hit flathub too?

I recently learned that we should be inspecting the pkgbuild before installing AUR packages. Should flatpaks be inspected?

Every new application is reviewed by us reviewers before a submission is accepted. And major changes to an application on Flathub are held for review as well.

Additionally, we now try to build as much of the applications as possible on our infrastructure. It’s mandatory for new submissions where source code is available and encouraged for existing applications. So, at least with open-source applications you also have a record on what source code the application was build from.

If you wish to check yourself, you can find a link to the manifest from which the application was build on the application page on our website.

Risks I’ve Seen

Changes Made Upstream

Flathub maintainers don’t have a system in place to monitor and verify changes made upstream. If code released upstream is malicious, it’s impossible to automatically detect it. Ultimately, apart from a tag and commit ID change, no changes are reflected in the Flathub manifest.

The biggest risk here is that the developer account could be compromised, and malicious code could be injected into the repository and distributed via Flathub. I believe there have been one or two such incidents with Snapcraft.

Vulnerabilities Due to Dependencies

Dependencies used in applications are also prone to problems. For example, when we update the Python modules that a Python application depends on, we are installing untested new packages. If there is a malicious package on the PyPi side and that version was downloaded during compilation, it’s always possible for it to be transmitted to the end user. This also applies to other package managers. The risk mentioned in the upstream section also applies here.

Vulnerabilities stemming from maintainers

Not every application is maintained by verified developers, and some packages are handled by volunteer maintainers like myself. In these cases, any intervention in the application’s resources has the potential to be released without triggering a general warning. However, this risk is relatively low because the number of maintainers with access to multiple repositories is limited, and sending multiple unrelated changes to random repositories would attract attention.

Risky applications

Since this type of malware generally targets crypto applications, VPNs, and password services, considering additional security measures for these types of risky applications might be beneficial.

(Google translate)