Discover: show flathub verification status

On Flathub, app listings show a good deal of data about a particular Flatpak; most notably the verification status, permissions, and license. Discover shows the permissions and license, but notably not the verification status. For example, the Google Chrome flatpak is not verified, and while realistically it’s safe (it’s built from the official .deb) there no indication in the UI that this isn’t an official Flatpak provided by the vendor even though it looks extremely official. In this particular case there is only because the provider put it in the description, but that’s not universally true, for example see Sublime Merge which looks similarly official, but is not.

If I want to know more about an app, I know to go to Flathub and look at those additional details, but it’d be nice if:

  • Verification status were shown directly in Discover
  • A link was provided to Flathub to see additional details
  • A link was provided to the manifest, but this isn’t strictly necessary if there’s a link to Flathub; I imagine not as many folks want to verify that

I’m not familiar with developing for KDE, but was considering attempting this change if it were something that the maintainers were looking for, but I don’t really know the process so I figured I’d start by opening a topic here as the bug tracker suggests. Thoughts?

3 Likes

Welp, I think I see why this isn’t present; I’d love to hear that I’m wrong though or that it’s still worth attempting but this is my read on it after some research this evening:

Discover is agnostic about its Flatpak backends; Flathub is obviously the popular one and is available on my distro by default, but it’s not the only one. The “verification” status is a feature specifically of Flathub, it’s not part of the Flatpak repository spec or the Appstream definition file but is part of their HTTP API, see for example Chrome’s verification status. So this could be added, but it would have to be specific to Flathub, and as far as I can see so far it’d have to be inferred from the repository’s URL, which makes this feel like not the greatest idea, unfortunately.

I did check to see if this comes through in the metadata (such as where permissions are stored) and it does not that I can see.

I’m not entirely done looking at this, but it’s feeling a bit like a non-starter.