-
Notifications
You must be signed in to change notification settings - Fork 50
Show a badge for certified apps #48
Comments
We discussed recently on flatpak irc about adding something like this in the appdata so the webapp will be able to show "Published by the upstream developer" or "Endorsed by the upstream developer" message I'll ask @alexlarsson about this |
Will need some trust-worthy way to set that information. |
I think As the build-bot could validate the claim and just pass the official badge downwards and clients could re-validate if they want. vs. Clients have to validate it themselves and therefore we pass an cryptographic proof using app metadata to the client. |
@SISheogorath At a glance I don't think that approach is helpful at all, package maintainers can do anything including control the metadata. There has to be something set by the repo admins externally. |
Copied over from #214: One way to differentiate between developer-published packages and “community-published” packages could be to have the storefront check for a specific
Flathub could provide a similar template, along the lines of:
This
Obviously, anybody could unilaterally add this Note: there’s an existing |
(This is just what I posted on the other issue, so it may not be framed in the most relevant way here.) |
I’m not terribly familiar with how Mastodon does things, but it looks like the big difference with my suggestion is that:
(There would need to be additional safeguards in place to remove verification in the case of suspicious domain transfers, e.g. DNS hacking redirecting a domain to a phishing site, though something like DNSSEC support might be useful to submit to the Freedesktop AppStream specification, as well.) FWIW the Apple precedent I’m comparing this to does allow for affiliate tracking, but Flathub doesn’t need to implement any similar functionality. That is, if a page were to include tracking data, The biggest limitation, of course, is that verifying that the entity publishing the Flatpak on Flathub also controls the page at This is to say that providing verified links could be in and of itself a useful feature, even if Flathub doesn’t verify applications themselves, per se. This feature would probably work best if it were paired with a clearer contextualization of what each URL means on the Flathub app page template. |
Well, I just submitted an issue on the AppStream specification, if you want to weigh in there. |
Had an idea how this could be done. I'm not familiar with Flatpak/Flathub so much so probably needs some more thoughts. If the Flatpak app manifest had a way to identify the main application module, then the URL set as the source could be used to verify the publisher of the app. If it's an archive on a website, the developer can place a file under Another idea, for public GitHub repository, it could also be done by checking that the user publishing is also the owner of the source repo. But that wouldn't necessarily work for organizations and not at all for archives coming from websites or other git hosting. So not much of a solution. |
As @TingPing has pointed out, we can not use anything that is maintainer-controlled (on the flatpak side) to validate that the maintainer is the actual maintainer. So I guess the only way to mark an app published by the developers is either by maintaining a list of these apps somewhere externally and/or by marking only apps that are actually uploaded by maintainers (such as it currently is the case with Firefox) to flathub and have no flatpak repository representation. However, AFAIK the Firefox app is currently and might be permanently the exception. So I don't see this going anywhere near future unless one wants to do manual verifications. |
My idea was that if the source in the manifest of the app is set to the developer repository, then the developer controls that repository and could place a piece of information to identify the account used to maintain the app on Flathub. For example, the manifest for CherryTree includes the following in the
Someone that wants to upload CherryTree on Flathub would need to use the repository A user could still fork the repository and upload an app using the forked repository, which would show the "verified" badge. I guess forks are allowed as long as they are not malicious, so what would be important is to clearly show the app ID and the repository or website containing the program source for user to be able to see those are different app. Some semi-automated verification could also be done to verify that an app is not pretending to be another app (for example check if app with similar name already exists). Again, that would require to modify Flatpak manifest to be able to identify which source in the modules section is the "main" program source and for every maintainer to add it if they want to get the verified badge. This may not work for every app depending on where the source comes from, but should work for git repo and when hosted on website controlled by the developer. |
The problem is that having control of some website or some repository absolutely doesn't mean you are the actual upstream. For repositories nowadays, with everyone "forking" every repo, it is harder to determine valid upstream, especially for smaller projects. When we add new dependency source, I always spend 10 minutes to make sure we get the right upstream. I'm sure many people who make flatpak manifests here can relate to this. As for websites, it's the same. Even for bigger projects, there are many cases of impersonation. Here for instance is a recent message by the Inkscape team warning everyone not to trust anything but inkscape.org because there are actual cases of fakes in the wild: https://twitter.com/inkscape/status/1446169748656431134 At GIMP, we also have had various cases of impersonations. I remember one app on some store publishing GIMP and pretending to be a fake "Gimp foundation". While it might seem obvious for seasoned developers what is the real GIMP or Inkscape website, many users don't even know we have a website (they just download from various third-party sources, like repositories or sometimes more shaddy software-download websites, so they don't need to know!) so even less which URL it is. So yeah the Note though that it can be coupled with the proposed process, i.e. that we could have |
I agree manual verification would be the way to go to have any added security associated with showing a verified badge. Otherwise has you said it is easy to impersonate an app just by forking and using a similar looking name and URL. Adding the information that the owner of a repo is also the maintainer could be a signal that there is a good probability the app on Flathub will get new releases at the same time as the upstream. But that would need not to give any sense of added security to the user and I don't know if it's worth it as a feature by itself. |
Don't get me wrong, I personally believe having a "Upstream-maintained" notice (or "badge" or whatever you want to call it) is a nice idea. That's why I'm subscribed to this discussion (hence answering). Just it has to be well done. And I think human-verification (based on trusted community members for instance, not necessary the developers of Flathub or maintainers who may not want to do this day-to-day additional work) is one of the few sane ways to go. Actually just now I thought about a secondary way, which would be to base ourselves on a trustful database of projects. For instance, we were recently introduced to this Anitya database mostly used to automatically check for new versions of dependencies in flatpak manifests. Well if the info there is well-maintained and is considered trustworthy, then a project could use the For instance, I see GIMP page is properly set so it would work in our case. |
I'm not sure to follow how the information from Anitya would be used. Would it serve as a source of information for a team of moderators? Right now it seems like anyone with an account can modify the information on https://release-monitoring.org, so that is a problem. But it does make sense to share the workload of verifying app with other distribution projects. |
VS Code just implemented a system for publisher URL verification that might be a useful precedent. The linked help section doesn’t go into a lot of detail, but it sounds like they do it using DNS. |
They just require adding a TXT DNS entry; it’s a commonly used approach (e.g. Google Search Console uses this to verify you own the domain). |
Well, that’s an option here, I guess? |
That's a technical implementation but it doesn't solve the main issue which is: how do you validate that a website is the one from the upstream developers? Let me give you an example:
So the problem is not how Flathub would validate a domain (there are many good solution for this), but it is how you validate that the said domain is really the upstream one. As far as I can see, the only way to do this with little doubt is through human validation (not perfect, one can still make mistakes, but it more trustworthy than without), which means a community of trusted people who would manually verify a claim of being an upstream domain (the human verification can then be backed by the automatic verifications as secondary step). For instance with any of the proposed techniques above, the only verification to do is whether or not the given domain is the upstream domain. Only then the automatic check has any value. For the record, the risk stated above is not theoretical. I posted a link above where the Inkscape developer warned people of a fake website (for which a real domain Now would this community of reviewers be Flathub-only or use a shared resource (such as the Anitya project I linked previously)? Both are possible.
I don't know enough this project to give an opinion. It would definitely need to be verified. Nevertheless a process based on community-trust is not so bad, even if it does indeed result in some small risky windows. It all depends on whether there are counter-measures to detect and fix quickly the malevolent edits. Anyway not saying this is necessarily the database to use. I don't know. I simply discovered this project recently and thought it was of interest for this discussion. |
One take on this is that as long as Now, the broader problem this doesn’t solve is when you have multiple versions of the same application with different distributors. In that case, the best practice would probably be to do some degree of investigation to see which version has the best claim to the trademark for the application name. Obviously some preemptive check would be ideal for trademark purposes, which could potentially allow for someone submitting an application they don’t control but that still uses the official upstream repository. In this case, the application would be “unofficial” but still potentially allowed. And in general each submission should be manually checked to make sure the repository it points to is indeed the upstream repository, and, if it isn’t, the submitter would be required to use a sufficiently distinguishable name for their fork. So, yes, there are kind of two separate issues at play, but I don’t think forks should necessarily be rejected outright so long as they don’t use confusingly similar branding to the originating project. What do you think of that? |
In this case, |
Of course. But this report is about certifying an application as "being maintained on the store by the official developer." Please check the initial report description. It is not about whether third-party are allowed to publish the software too. We know they are, we know the definition of Free Software too, don't worry. 😛 So the rest of the post is simply off-topic for this report.
I don't think anyone said anything like this. This is not the topic we are discussing here. Nobody has said anything about rejecting apps, or forks, or anything of the sort. 🤷 |
It had been a while since I last interacted with this thread, so maybe #214 would have been a better place for me to comment about the VS Code DNS thing. |
Verification badges are now tracked in flathub-infra/website#44 |
Just like on Twitter, show a badge for an app being maintained on the store by the official developer.
The text was updated successfully, but these errors were encountered: