Hacker News Reader

Apps that are published by their developers themselves can verify to get a blue checkmark.

E.g. https://flathub.org/apps/org.mozilla.firefox

> Flathub has verified the developer's identity using the app id and the developer's website or profile on a source code hosting site.

https://docs.flathub.org/docs/for-users/verification/

> Apps that are published by their developers themselves can verify to get a blue checkmark.

OK great. Why don't apps that are published by third parties get a giant red exclamation mark? If you read all the way through this thread, you'll see a very feasible supply chain attack on BitWarden. For FlatHub to have a credible security posture, they need to do something like very clearly identifying third party packaging as "experimental" or "dangerous". This has been a known issue for years, and yet they appear to be taking a "our volunteers are nice people, thanks community" collective shrug.

FWIW the website isn't everything, since a) you can install from the CLI without viewing the website[0], and b) there are third party tools like KDE's Discover which quietly integrate with FlatHub. My father would never understand the difference between FlatHub, Snap, and the Canonical deb repositories, even if I explained 50 times - and yet he's been a happy KDE user for 15 years. How is he supposed to know that he's no longer necessarily accepting properly audited software when he clicks the "update" button?

[0]:

    > flatpak install bitwarden
    Looking for matches…
    Found ref ‘app/com.bitwarden.desktop/x86_64/stable’ in remote ‘flathub’ (system).
    Use this ref? [Y/n]: y
    Required runtime for com.bitwarden.desktop/x86_64/stable (runtime/org.freedesktop.Platform/x86_64/23.08) found in remote flathub
    Do you want to install it? [Y/n]: y

I don't believe third parties maintainers packaging software on flathub is a big issue but I'm also not familiar with how other distro repos trust their maintainers. Hopefully more developers maintain their flatpak themselves (or someone they trust) and get their apps verified. If most apps are verified, warning users of unverified apps might be a good idea.

There's ongoing discussion about splitting open source and proprietary apps in to seperate repos [1]. Additionally having seperate repos for verified and unverified apps might make it more obvious where an app comes from in the cli.

But I don't know how seamlessly an app could transition between being in the third party repo and being in the official repo. Having the user quietly stop receiving updates seems like a bad idea, but automatically migrating might not be desirable either.

I also think flatpaks cli interface needs some work. It is functional but far from distro package managers.

Being verified is especially important for critical apps. Recently someone added malicious versions of apps to the snap store [3]. This lead to people getting their cryptocurrency stolen.

[1] https://github.com/flathub/flathub/issues/691

[2] https://docs.flathub.org/docs/for-app-authors/requirements

[3] https://forum.snapcraft.io/t/temporary-suspension-of-automat...

> One thing I don't know about (which maybe somebody can inform me/us about): the wiki states that PRs are reviewed by Flathub reviewers, but I see no sign of human review on e.g. https://github.com/flathub/com.bitwarden.desktop/pull/167 (or others in that repo). What's the actual process?

In this case, I think the lack of human involvement is mostly a good thing. Flathub was criticised for having outdated packages[1]. Using automation to automatically update packages is mostly a good thing.

Obviously, we want to see thorough review of new packages, but that's a separate issue.

[1] I thought I read this in an LWN article, but I can't find it. But see e.g. https://github.com/flathub/org.qutebrowser.qutebrowser/issue...

> Using automation to automatically update packages is mostly a good thing.

Maybe. The CI rules should be made public in that case, though, surely? Maybe they are?

The enormous amount of value the distros bring (aside from sponsorship of the ecosystem) is audit of packages (and packaging). If we want to move application packaging away from the distros, Flathub needs to be at least as competent in its process, automated or not.

> Maybe. The CI rules should be made public in that case, though, surely? Maybe they are?

Agreed, but thankfully they are. The PRs link to <https://github.com/flathub/flatpak-external-data-checker>. That said, it'd be clearer if the flathubbot 'user' profile also linked to that URL.

> The enormous amount of value the distros bring [...] is audit of packages (and packaging).

Yes, auditing against supply chain attacks is good! But there's also a risk in running outdated software. I don't have easy answers. But if automation leaves more time for the hard part, great.

Maybe unfair to ask you (but thanks for the helpful answers so far).

Is there a check for "this distribution comes from the official source"?

Let's say some state actor compromises taaem's desktop computer, and changes the url in the manifest to (say) https://xn--githb-bjg.com/bitwarden/clients/releases/downloa... (that's a unicode lookalike ս in there, which in github at least renders without expansion as "github.com" - HN is smart enough to expand it), or something equally nefarious. CI's not going to catch that, right? And nobody's actually paying attention to changes?

Not an expert, but unfortunately I think you're right in identifying a potential attack vector with the Flathub maintainership model. Even if flathubbot is being used, manual changes can still be made by maintainers.

And I think there are far more maintainers to trust, than for say scoop or winget. The difference is, Flathub has one repo per package (and hence allows more maintainers).

> everything looks like it is in fact published by 8bit Solutions

In fact the store seems to state exactly that in the big primary heading that says

> Bitwarden

> by 8bit Solutions LLC