Ensuring integrity of flatpaks on flathub

[mYnDstrEAm]

It looks like flatpak and flathub currently don't have a comprehensive system for verifying downloaded files built in. Checksums of the files are only compared to sha256 hashsums specified in json files like this.

However:

• how can users / the client software ensure that the hash is compared to the json file which can be accessed publicly on sites like GitHub?
• users / the client software currently can't ensure that flatpak packages are genuine

It's important to verify the downloaded files because maintainers of a flatpak package might not be the authors or official maintainers of a software or the the build- and flathub rollout-process might have resulted in flawed files (due to a mistake or software or hardware issues). Furthermore, for security software-providers should be untrusted inherently and the integrity of files be checked by technical means. Data integrity is a really important part of software distribution; I'll cite from the Wikipedia article:

Any unintended changes to data as the result of a storage, retrieval or processing operation, including malicious intent, unexpected hardware failure, and human error, is failure of data integrity. If the changes are the result of unauthorized access, it may also be a failure of data security. Depending on the data involved this could manifest itself as benign as a single pixel in an image appearing a different color than was originally recorded, to the loss of vacation pictures or a business-critical database, to even catastrophic loss of human life in a life-critical system.

Here is some information on how data integrity of packages is currently being ensured on Debian. And here the same for apt-get. Using flatpak/flathub instead of a package-manager using apt-get and official repositories would mean a substantial decline of security (and definitely not increased security despite of the sandboxing features).
A thorough system of data integrity verification would include GPG verification as already outlined previously here where Alexander Larsson wrote:

I agree that its important that flatpak packagers are careful with the sources they refer to, making sure they are actually from the real upstream. But, I don't really think there is currently an widespread in-use system that does this, and I don't think it is the place of flatpak to invent it. This affects all distros, and a solution needs buy-in from "everyone", so should be done as a separate project.

The complete file verification system would ensure that:

• the built files match the publicly available source code of the software intended to be installed
• the downloaded files match the built files whose checksums are made publicly available
• the installed files match the downloaded files whose checksums have been verified to be valid
• the installed files remain unchanged

Flatpak with flathub could revolutionize Linux app distribution, making things easier/more convenient, more up-to-date, more widely available, more consistent and possibly even more secure. However, this issue with both flatpak and flathub imo stand in the way of this. Hence I'd consider this the top priority issue, even more important than any major bugs.

There already (or rather: still) is an open issue for this at flatpak here: https://github.com/flatpak/flatpak/issues/16

[mwleeds]

The complete file verification system would ensure that:

* the built files match the publicly available source code of the software intended to be installed

Here you're talking about reproducible builds, which are mostly outside the scope or control of Flatpak but are being worked on in the broader community. One thing that is in scope for Flatpak is checking if a built flatpak is reproducible; see flatpak/flatpak-builder#251

Note also that Flathub builds happen on Flathub servers, unlike Debian which allows developers to upload binaries (last I checked). However a Flathub maintainer is still responsible for pointing to the correct sources.

* the downloaded files match the built files whose checksums are made publicly available

* the installed files match the downloaded files whose checksums have been verified to be valid

Flatpak does verify the integrity of files as it is downloading/installing them. For ostree remotes this is done using GPG signatures (which are better than mere checksums). If you want to see the commit ID (which is like a checksum) for something on flathub use e.g. flatpak remote-info -c flathub org.gnome.Builder and for the local copy flatpak info -c org.gnome.Builder. For OCI remotes we at least check SHA256 sums and there might be more integrity verification mechanisms I'm unaware of.

* the installed files remain unchanged

We don't check the integrity of installed files when using them because that would be resource intensive, but one could check manually with the ostree fsck command.

Flatpak with flathub could revolutionize Linux app distribution, making things easier/more convenient, more up-to-date, more widely available, more consistent and possibly even more secure. However, this issue with both flatpak and flathub imo stand in the way of this. Hence I'd consider this the top priority issue, even more important than any major bugs.

There already (or rather: still) is an open issue for this at flatpak here: flatpak/flatpak#16

Right, more strongly verifying source files when building flatpaks would be a step forward, but as you point out we already have an issue for that so no need for a duplicate.

[mwleeds]

I don't have permission to but I think we can close this; it's essentially a duplicate of a few issues as I said above.