Setting the verified developer tick in GNOME Software

[Owen Taylor]

;There are various properties that a user might want out of their Flatpaks

 * Does not have a backdoor inserted
 * Gets timely security updates
 * Is updated when a new stable release of the software is made
 * Has not been modified from the upstream in a way that introduces new bugs
 * Upstream will accept bug reports if you are using this package
 * Bundled dependencies have appropriate licensing

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.

"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.

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.)

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.

Owen

On Thu, Aug 9, 2018 at 2:04 PM, Richard Hughes <hughsient at gmail.com> wrote:

> Hi all,
>
> GNOME Software now has the ability[1] to show a little tick when we
> know the developer providing the Snap is verified and I wondered if we
> could do something like that for Flatpak.
>
> How you define "verified" is the sticking point I'm sure. Ideally we'd
> have some kind of signature in the AppStream metadata (or flag in the
> summary file) that could be used by the client software that the
> author is actually the upstream vendor. Really this is a way for the
> downstream user to know if the "Skype" really is from Microsoft of if
> it's been repackaged by someone as "Skype  " who inserted a backdoor.
> This is made harder as flathub is the "packager" perhaps choosing
> extra patches or fixes that upstream might not contain. So the idea of
> it being "verified" breaks down a little. This is really a question of
> "this is not a fake" and I'm not completely sure how to quantify that.
> Perhaps all apps from flathub (whitelisted by the remote URI) are
> verified, based on the review process each application has to adhere
> to?
>
> As Allan pointed out, there probably needs to be a dispute resolution
> mechanism when upstreams are less than ideal -- perhaps the developer
> could check in a file into git (or include in the upstream tarball)
> much like you'd do with letsencrypt or google adwords. It would be
> weird for a developer-provided vanilla version to be marked as
> non-verified and the flathub one with patches to be verified. Comments
> and suggestions welcome.
>
> Richard.
>
> [1] https://gitlab.gnome.org/GNOME/gnome-software/merge_requests/71
> _______________________________________________
> Flatpak mailing list
> Flatpak at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/flatpak
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/flatpak/attachments/20180812/f6ade9a3/attachment.html>