I think it would be a great addition because there are users such as myself who wish to stick to official packaging formats provided by the developer. So, Providing this would help.
4 Likes
Steam is unverified, you want that to be excluded?
How about Google Chrome? Spotify? VLC? Bitwarden? Wine? etc etc etc…
Verification on flathub does not mean what you probably think it means…
If you want that kind of functionality. you can read about how to achieve that here: Verified apps | Flathub Documentation
flatpak remote-add --if-not-exists --subset=verified flathub-verified https://flathub.org/repo/flathub.flatpakrepo
I feel KDE devs have other more important things to focus on than implementing a checbox filtering search results from flathub.
1 Like
Having support to filter out this would be wonderful.
@bedna no one is requesting anything to be excluded.
There are a lot of customization options on KDE to make it fit better one’s workflow. A toggle of only allowing verified apps could issue remote-modify command on that particular remote.
And, according to the very link you shared, a verified app is precisely what OP’s meant:
A verified app is an app that is published on Flathub by its original developer or a third party approved by the developer.
No need to be so harsh. Have a good day.
2 Likes
Harsh or not, it’s the reality that verified != more secure/better.
And no, I still don’t think that’s what op actually is after and think that verified means something other than what it actually means.
What if the “original developer” does not CARE about verifying, but the build you get is EXACTLY the same (code wise) as the flatpak version?
What is the actual REASON to exclude that (yes, you are talking about excluding things here) flatpak version?
What if the dev simply does not have time? Like KDE that needs to verify every single application (I could be mistaken here) to give it the “verified” stamp?
It can’t be about open source, verification has nothing to do with that. If the source is available, it is linked to, witch is obv not the case for with proprietary software on flathub, that CAN be verified.
So… Reason?
Look into the reasons Mint removed the option as default after the massive backlash it caused…
Edit
I should add, I am not AGAINST the option in itself. I just question the validity of spending developer time implementing it.
I meant that it’s just better to have it as a filter. Because sticking to official Packaging formats made by the developer is safer than community maintained ones and better than later regret about Backdoor like the xz attack.
And I also said similar and not enforicing it by default. There could be adjustments made.
2 Likes
Firstly, let me thank you for sharing that link. I wasn’t aware of that. Did the change locally and Discover loads up waaaay faster.
All the apps you listed are usually available from distro packages, or directly from the developer.
No one asked to be the default behavior, just to add an option. Some people like things different from others.
Flatpak is usually my last resort if the developer does not provide any other packaging format, including AppImages and Snaps.
There are few apps I prefer to compile from source than using flatpaks (mostly to enable compile time flags).
Using a developer sanctioned packaging usually makes asking for support much easier. Both for users and developers.
I don’t have anything against flatpaks per se. It is just my personally least preferred format. And although things improved a lot recently, dealing with poorly default sandbox permissions from packagers, specially 3rd-party ones, consumed a lot of my time. I also had problems with localization.
And yes, I do report those to flatpak developers, and provide all the info they need. You can check for me on their issue tracker.
And no one is “spending” developer time. If a developer finds the proposal interesting, they pick up the idea and send an MR.
Almost all work on KDE is done by volunteers, on their will.
There is no resource being spent that could have been spent on somewhere else.
It is not like they are not working on some other thing to work on this. Either a developer will find this interesting enough and pick it up, or not, and that is totally fine.
1 Like
You are wildly inaccurate in your assessment.
- Verified != made by the developer.
- The XZ project WAS the official developer
- The XZ thing has nothing to do with anything about this
This was exactly what I was referring to when saying “not what you think it means”.
Again, I think spending any time on implementing something like this false sense of security, in effect excluding perfectly fine software because a user “thought it was safer” is a complete waste of time IMHO.
I am always amazed of how fast people forget about how gReAt Canonicals snaps are… 
I know what you are referring here :
I just brought the xz as another point. I am not a person, who doesn’t know what it is. Maybe I brought up a point not related to my discussion. You are welcome to correct it. But they way you are speaking is outright, slapping those on whoever makes comments, like “Who gave you permission to speak”. Please be civil, you messages depict outright rage.
To be clear, I liked the functionality of Linux Mint’s implementation (and I do know verified means it’s endorsed by the official developer not that being secure. I meant more of a community package have possibilities of being backdoored), I would like it personally if endorsed by Discover Devs. But I don’t want it to be enabled by default for all. Just those who need it like myself.
2 Likes
You clearly knows the stuff…
If you don’t appreciate me trying to correct your errors and sees that as toxic, I won’t continue. I don’t want to upset people. Sorry about that. 
Facts never cares about your feelings though.
I’ll leave you with a moral dilemma:
The fact is, a TON of developers would probably be excluded in peoples available choices because the user THINKS it is “safer” to toggle the option.
Ever thought about those developers and that it might be unfair towards them?
You have not stated many facts though, please calm down.
You seem very pre-disposed to not wanting this feature (and trying to frame it as a “waste of time”.) That’s fine, but this conversation has turned into an unnecessary argument and I can imagine the end-result if I let it continue. I think you’ve made your point very clear and this is an unofficial warning to stop shutting down conversation of it in here.
3 Likes
A verified account adds an extra of confidence to whatever a user would download. A filter, eases the process of finding the right program.
Flathub (and Snap) repository is continuously growing, it is good to be prepared for when it grows big enough to look more enticing to malicious actors. The metadata is already there anyway, there is no wrong in using it (for snaps too).
1 Like
I only use snaps for developer published apps. I only have Skype, some Intellij’s IDE, and XournalApp as snaps.
The reason I looked into snaps as I was tired of the 3rd-party packaged Skype flatpak not integrating well with KWallet and asking logging me out on every reboot.
And snap is the only package format supported by Skype, and is the first thing they ask when you reach for support. At the end of the day, I want my work tools to work for me, and not the opposite.
All package formats have flaws. Including Flatpak.
I am sure you are aware of their recent incident. I won’t link any demeaning links to any package format.
The deal is to vet from who you want to install your apps. And having choices, and tools that improve those choices, such as the verified filter, let us focus on doing actual work.
Actually, your argument does great to support the idea of having the verified toggle on Discover.
Thanks for changing your mind! This is a rare trait these days.
I couldn’t care less. Discover is unusable since Fedora,40. I have eliminated it from my system.
Discover still works with Flatpaks/Flathub, at least on Arch.
I just uninstalled the currently unusable Packagekit backend as it annoyed me that it not only not reported any available updates but also refused to install anything from the repository.
But for the Flatpak side of things maybe I’m blind but I do NOT see a clearly distinguishable verified or unverified Tag at the entries.
Some say “unknown Author” some have “a Name” but is this “name” verified in one way or another or the original author or even a imposter with just a partially matching name? Don’t know.
Maybe someone should start to make verified or not clearly visible first (maybe with some mouseover popup what it actually means), and let the user decide what he does with this info first.
And the option to completely hide “unverified” stuff later/only as a second option.
1 Like
Flathub “Verified” status certainly isn’t a panacea for application security…but it’s also important, IMO, for users to understand that the “developer” field does not necessarily translate to who actually packaged the app for Flathub.
IMO one solution that might be easier than filters/toggles/etc. would be to offer a direct link to the Flathub page for the app from within Discover - that way folks can at least see the Verified status from there, and click further to inspect the manifest, etc. if they so choose.