8 ms·

I use Flathub, but I do not like that they support the ability for third parties to package commercial software on behalf of the publishers. https://flathub.or

I use Flathub, but I do not like that they support the ability for third parties to package commercial software on behalf of the publishers. https://flathub.org/apps/com.bitwarden.desktop https://flathub.org/apps/com.bitwarden.desktop - looks great, right? You have to click on "show more" to see "This wrapper is not verified by, affiliated with, or supported by 8bit Solutions LLC.", and prior to clicking "show more", everything looks like it is in fact published by 8bit Solutions. Because it's a third party packager, you end up with bugs like https://github.com/flathub/com.bitwarden.desktop/issues/147 https://github.com/flathub/com.bitwarden.desktop/issues/147 (because they haven't used a particular flag to launch it, which the deb/rpm version apparently does use by default.) Yes, the attack surface is relatively minimal, but it's still there -- https://github.com/flathub/com.bitwarden.desktop/blob/master/com.bitwarden.desktop.yaml https://github.com/flathub/com.bitwarden.desktop/blob/master... 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 https://github.com/flathub/com.bitwarden.desktop/pull/167 (or others in that repo). What's the actual process? (A couple other examples: https://flathub.org/apps/us.zoom.Zoom https://flathub.org/apps/us.zoom.Zoom likewise is not maintained by Zoom; https://flathub.org/apps/com.jetbrains.IntelliJ-IDEA-Ultimate https://flathub.org/apps/com.jetbrains.IntelliJ-IDEA-Ultimat... same goes for this; at least in these cases the crucial last sentence is not buried by the show more button). The other small irony that won't be lost on fellow 90s graybeards is that by sitting on github, we're moving significant parts of Linux infrastructure's distribution to be hosted by Microsoft.

orra 3y ago
> 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 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/issues/8 https://github.com/flathub/org.qutebrowser.qutebrowser/issue...
- smallerfish 3y ago
  > 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.
  - orra 3y ago
    > 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 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.
    - smallerfish 3y ago
      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://githսb.com/bitwarden/clients/releases/download/desktop-v2023.10.1/Bitwarden-2023.10.1-amd64.deb 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?
      - orra 3y ago
        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).
TotempaaltJ 3y ago
> 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
nani8ot 3y ago
Apps that are published by their developers themselves can verify to get a blue checkmark. E.g. https://flathub.org/apps/org.mozilla.firefox 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/ https://docs.flathub.org/docs/for-users/verification/
- smallerfish 3y ago
  > 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
  - nani8ot 3y ago
    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 https://github.com/flathub/flathub/issues/691 [2] https://docs.flathub.org/docs/for-app-authors/requirements https://docs.flathub.org/docs/for-app-authors/requirements [3] https://forum.snapcraft.io/t/temporary-suspension-of-automatic-snap-registration-following-security-incident/37077 https://forum.snapcraft.io/t/temporary-suspension-of-automat...

orra 3y ago

> 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 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/issues/8 https://github.com/flathub/org.qutebrowser.qutebrowser/issue...

smallerfish 3y ago
> 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.
- orra 3y ago
  > 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 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.
  - smallerfish 3y ago
    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://githսb.com/bitwarden/clients/releases/download/desktop-v2023.10.1/Bitwarden-2023.10.1-amd64.deb 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?
    - orra 3y ago
      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).

TotempaaltJ 3y ago

> 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

nani8ot 3y ago

Apps that are published by their developers themselves can verify to get a blue checkmark. E.g. https://flathub.org/apps/org.mozilla.firefox 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/ https://docs.flathub.org/docs/for-users/verification/

smallerfish 3y ago
> 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
- nani8ot 3y ago
  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 https://github.com/flathub/flathub/issues/691 [2] https://docs.flathub.org/docs/for-app-authors/requirements https://docs.flathub.org/docs/for-app-authors/requirements [3] https://forum.snapcraft.io/t/temporary-suspension-of-automatic-snap-registration-following-security-incident/37077 https://forum.snapcraft.io/t/temporary-suspension-of-automat...