<div dir="ltr"><div>;There are various properties that a user might want out of their Flatpaks<br></div><div><br></div><div> * Does not have a backdoor inserted</div><div> * Gets timely security updates</div><div> * Is updated when a new stable release of the software is made<br></div><div> * Has not been modified from the upstream in a way that introduces new bugs</div><div> * Upstream will accept bug reports if you are using this package</div><div> * Bundled dependencies have appropriate licensing<br></div><div><br></div><div>As a Flatpak ecosystem, we have a responsibility to try to make sure that most of these properties are true for *all* software that is presented to the user. If there are multiple versions of an application presented, it should not matter deeply which one the user selects, because it's not the user's responsibility to pay that much attention. If I'm buying a particular brand of tea kettle from Amazon, Amazon will present different sellers. and they might have different prices and shipping speeds, but if I select the wrong seller and instead get a bobcat in the box, then the Amazon ecosystem is not working.</div><div><br></div><div><div>"accepted as an official build by the software 
author" is an interesting factor to take into account when picking between sources of the same application. But it's certainly not the only one. E.g., someone might prefer Debian built Flatpaks because they want to make sure that everything has been independently verified.<br></div></div><div><br></div><div>So I don't think it's the right interface if, when browsing in GNOME Software you see one Inkscape icon and another with a "verified" check next to it. How should the user react if there's only one Firefox icon and it doesn't have the verified check? What if, instead, you had a single Inkscape icon, and when you went to the details page, some source was selected by default (perhaps the policy has site/system/user configurability), and then you could change that if you cared. (Perhaps the same interface for switching the source of  installed applications as well.)<br></div><div><br></div><div>When displaying available sources you could show some sort of "official build" badge. I think that would have to have the meaning that the upstream developers have approved/blessed that source, think it's a good representation of their software, and it is expected to stay in sync with upstream released versions. As has been pointed out, any verification of this would have to be done by the remote - at the GNOME Software level it's just some flag in the appstream data that it trusts. <br></div><div><br></div><div>Owen</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 9, 2018 at 2:04 PM, Richard Hughes <span dir="ltr"><<a href="mailto:hughsient@gmail.com" target="_blank">hughsient@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
GNOME Software now has the ability[1] to show a little tick when we<br>
know the developer providing the Snap is verified and I wondered if we<br>
could do something like that for Flatpak.<br>
<br>
How you define "verified" is the sticking point I'm sure. Ideally we'd<br>
have some kind of signature in the AppStream metadata (or flag in the<br>
summary file) that could be used by the client software that the<br>
author is actually the upstream vendor. Really this is a way for the<br>
downstream user to know if the "Skype" really is from Microsoft of if<br>
it's been repackaged by someone as "Skype  " who inserted a backdoor.<br>
This is made harder as flathub is the "packager" perhaps choosing<br>
extra patches or fixes that upstream might not contain. So the idea of<br>
it being "verified" breaks down a little. This is really a question of<br>
"this is not a fake" and I'm not completely sure how to quantify that.<br>
Perhaps all apps from flathub (whitelisted by the remote URI) are<br>
verified, based on the review process each application has to adhere<br>
to?<br>
<br>
As Allan pointed out, there probably needs to be a dispute resolution<br>
mechanism when upstreams are less than ideal -- perhaps the developer<br>
could check in a file into git (or include in the upstream tarball)<br>
much like you'd do with letsencrypt or google adwords. It would be<br>
weird for a developer-provided vanilla version to be marked as<br>
non-verified and the flathub one with patches to be verified. Comments<br>
and suggestions welcome.<br>
<br>
Richard.<br>
<br>
[1] <a href="https://gitlab.gnome.org/GNOME/gnome-software/merge_requests/71" rel="noreferrer" target="_blank">https://gitlab.gnome.org/<wbr>GNOME/gnome-software/merge_<wbr>requests/71</a><br>
______________________________<wbr>_________________<br>
Flatpak mailing list<br>
<a href="mailto:Flatpak@lists.freedesktop.org">Flatpak@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/flatpak" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/flatpak</a><br>
</blockquote></div><br></div></div>