So what happens if a malicious contributor were to change the source URL to a malicious domain? And if this were to happen, hypothetically, would the users of the compromised flatpak be alerted somehow?
In the case that the manifest is compromised, sandboxing would not prevent confidential data from being exfiltrated from within the application. For example, if you were to use Proton Pass, which is an unverified package for a password manager: a malicious actor could replace the source with their own malicious version and exfiltrate all user passwords in a smash and grab, until the package is corrected.
What measures have been taken to prevent this scenario?
What measures does Flathub take to prevent a malicious, established Flathub contributor from updating the manifest with a malicious source?
What happens if a malicious contributor were to change the source URL to a malicious domain?
If (2) were to happen, would the users of the compromised flatpak be alerted somehow?
I do not understand your answer in relation to any of these questions. Do you mean to say that it’s unreasonable for me to entertain the idea of Flathub employing supply-chain attack prevention measures and harm mitigation responses, in the case that the application package is not published by its developer?
Even modified source code must use the same sandbox permissions. Otherwise, some major changes made to the manifest file will automatically trigger certain alarms, and the application will not be released. We also track changes made to the manifest file. I wish there was a restriction preventing changes to the main repository. Sometimes applications change repository names, sometimes developers change usernames, and there is currently no strict restriction against changing the main repository URL.
I couldn’t find any documentation to link to regarding the last question.
That’s all the information I have. I didn’t want to just paste an AI-generated answer.
We attempted that but it was unrealistic. I’m working on some heuristic to flag “invasive” changes but as always, I can’t say if or when.
We would roll back a change like that, or yank the package altogether, combined with an announcement on the website.
This is not really different to other Linux distributions by any means. As every open source project, we put a lot of trust into people maintaining apps. The unverified ProtonPass you mentioned in your initial post is a fairly old apps and submission process has been hugely tightened since. I don’t think it’s likely it would be accepted these days, that being said, it’s maintained by a long-term Flathub maintainer.
So there has been an attempt. What was unrealistic about it? Was it the review load on human reviewers?
I do have a suggestion. What if we flagged a change for human review if the domain in a URL is modified? This should tighten the restriction on changes at a great cost-benefit ratio. I imagine domain changes are infrequent in legitimate scenarios. Though, we’d have to also create stricter cases for git repos, since changing the owner/name URL portion changes ownership.
I’m interested in hearing about the heuristics you’re working if you don’t mind talking about it publicly.