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)
With the current state of lockfiles in python, this might happen - it shouldn’t happen in other languages - at least it shouldn’t be different from what is already upstream.
It should be noted that the AUR attack relied on fact that both submitting new packages and adopting existing orphaned ones are completely unmoderated actions, enabling a relatively large-scale attack that could only be discovered rather than prevented in advance. On Flathub both submissions and adoption have to go through manual approval; if you want to minimize risks further, stick to only installing verified Flatpaks, as these are officially approved by the application’s developers.
It also should be noted that malware in AUR used post-install scripts (although in a fairly non-sophisticated way) that run with root privileges, something that a Flatpak application is incapable of doing. Nonetheless, it’s a good idea to be mindful of what permissions a Flatpak application requires, to assess possible damage in the event of a compromise.
With the current state of lockfiles in python, this might happen - it shouldn’t happen in other languages
None of it is specifically tied to Python. Pretty much everything is going to be vulnerable or compromisable in the same way. None of it has also anything to do with lockfiles (unless you are pinning with exact hashes and never updating which almost no one does).
at least it shouldn’t be different from what is already upstream.
Most of the recent supply chain attacks have been specifically about compromising the upstream in some way and most of the recent major ones have been in the Node / JS ecosystem.
I’m not sure what point you tried to make but the attack described in the previous comment is specifically about an upstream source getting compromised. Other languages along with Python are also vulnerable - it doesn’t even have anything to do with the “language”.
Also I would note that the risks described in How well are flathub packages moderated? - #3 by yakushabb are absolutely true but none of that is specifically tied to Flathub. It affects every distribution system out there equally. There isn’t a known universal solution out there either to apply. This isn’t something that can be practically moderated either. The response is going to be reactive and staying vigilant otherwise for maintainers.
In general this entire thing in that comment has very little to do with end users.
Lockfiles should always be the pinned sources, that’s why they exist and that’s why CI always installs from the pinned sources in lockfiles, as you don’t want drift. E.g. an electron typescript app, generates a lockfile. Ideally the flatpak just creates it’s dependencies from that + what’s needed to run on the runtime site.
The problem with python is, that they still don’t have a standardized lockfile, which makes support hard.
Most stuff in Node / JS has been due to the hook design, people (including me) have been pointing at for at least 6 years. It was bound to happen, luckily the ecosystem finally seems to be moving on it, but it will still take some time.
You missed the point again. This again has nothing to do with Python or pinning or lockfiles
Flathub is generally better moderated than a random third-party repository, but it is not curated to the same level as a tightly controlled distribution repository such as Fedora or Debian main. Packages go through an automated build process, metadata checks, and human review for new submissions and some updates. Maintainers are expected to use reproducible manifests and declare permissions clearly.
That said, moderation is not a full security audit. Flathub does not inspect every line of application code, and trust still depends largely on the upstream project and the package maintainer. For popular open-source apps maintained by the original developers, the risk is relatively low. For lesser-known apps or packages maintained by third parties, it is worth checking the maintainer, permissions, source repository, and community feedback before installing.