• ⸻ Ban DHMO 🇦🇺 ⸻@aussie.zoneEnglish
        2·
        3 months ago

        It makes it obvious to people whether they are downloading Google Chrome as packaged by Google or as by someone else. That being said, Google Chrome is malware. That being said there is a lot more that needs to be done to truly prevent malware, which will be costly but will hopefully take effect when they’ve got the budget for it

      • TheGrandNagus@lemmy.worldEnglish
        0·
        3 months ago

        Because if you search Firefox and see a badge that says verified, you can be confident that it was Mozilla that packaged it and added it to FlatHub as opposed to some random scammer.

    • Pantherina@feddit.de
      821·
      3 months ago

      Verification doesnt help at all if the source is not trusted. All this says is “upstream developers maintain this package”. Unofficial packages can be safe too, like VLC.

      • dsemy@lemm.eeEnglish
        281·
        3 months ago

        It does help prevent actual malware from being downloaded, though, since upstream developers probably won’t publish malware on Flathub.

        But this is still a half-measure. I don’t understand why Red Hat and Canonical don’t treat this issue seriously; people on Linux are used to assuming software installed from the repos are safe, and yet Snap and Flatpak are being pushed more and more despite their main repositories being potentially unsafe.

        • Pantherina@feddit.de
          5·
          3 months ago

          Flathub is doing more and more, but stuff like hiding --subset=verified is very bad.

          They simply need to gain critical mass until they can force changes like portals etc.

        • Pantherina@feddit.de
          3·
          3 months ago

          If you create malware and publish it on flathub, you are the upstream dev. But for sure it helps against duplicate scams.

          • dsemy@lemm.eeEnglish
            11·
            3 months ago

            I can’t find it now, but I read that the verification process also includes human review (for the initial verification, not every update), so it should actually prevent “verified” malware (though it does nothing against unverified malware).

            Edit: Here’s an article with this and more info: https://lwn.net/SubscriberLink/966187/3ef48792e5e8c71d/

            • Pantherina@feddit.de
              1·
              3 months ago

              Nice!

              Add flathub with --subset=verified and get apps you really need from their .flatpakref files

  • million@lemmy.worldEnglish
    27·
    3 months ago

    This is a good step but I still feel like it’s pretty obscure where a package is actually coming from. “by Google” or for the Steam package “by Value” is really confusing and makes it sounds like it’s coming directly from the company. Unverified tells the user to pay attention but there is no hover over to say what it actually means.

    • conorab@lemmy.conorab.com
      14·
      3 months ago

      Wait… so the author displayed in “by <author>” is the supposed author of the software, not the one that put it on the store? That’s insane! Also sounds like you’d be open to massive liability since the reputation of the software author will be damaged if somebody publishes malware under their name.

      It should be:

      • Developed by: <author of software>
      • Uploaded by: <entity who uploaded to store>
    • thingsiplay@beehaw.org
      1·
      3 months ago

      I still don’t understand why a central repository for AppImages exist. The moment you are using a repository (and possibly version management), the format looses its reason to exist.

        • thingsiplay@beehaw.org
          0·
          3 months ago

          I personally use a few AppImages, but want replace them with Flatpaks. Flatpaks have their own issues, and because I did not want to troubleshoot in case I encounter another issue, just carry on using AppImages for these selected applications. Also I was not able to archive Flatpak easily, its very complicated with keys and not. Compared to it, I just have the AppImages included in my regular backup process with regular files.

          My point was not if AppImages are useful (they clearly are and I use them), but was talking bout repositories. However after some other replies I thought about it and indeed such a repository makes sense even for AppImages. I personally just don’t have to use them.

            • thingsiplay@beehaw.org
              0·
              3 months ago

              Not really. AppImages are as much secure as any other executable you run on your system. If you download it from a trusted source, like you download trusted Flatpaks or your systems repository, then they are not worse. If you say AppImages are highly insecure, because you run executable code, then you have to take that logic to any other executable format. The problem is not the format itself that makes it insecure, it’s the source.

  • Captain Beyond@linkage.ds8.zone
    1·
    3 months ago

    Traditional GNU/Linux distributions (as well as F-Droid) are not “app stores” even though they are superficially similar. Traditional distributions are maintained and curated by the community, and serve the interests of users first and software developers second, whereas an “app store” has minimal curation and serves the needs of software developers first and users second.

    I point this out because there’s an annoying meme that traditional distributions are obsoleted by the “app store” model. I don’t think that’s the case. “Verification” is essential for an app store but pointless for a distribution.

            • AProfessional@lemmy.worldEnglish
              1·
              3 months ago

              There is no such thing as a “package”. It is a repository of binary data with references to data in it (ala git). The whole repo and all data is gpg signed.

                • AProfessional@lemmy.worldEnglish
                  1·
                  3 months ago
                  > ostree show flathub:runtime/org.kde.Platform/x86_64/6.6
commit a7443e846cf67d007fcecda5c9dc27844001cfb8929064395cfc25c6d71d9474
Parent:  23107550082daf3b2892a4a0db2543838578ca882340a756b988bc5c1614540c
ContentChecksum:  607ba9475d32a24c51509bc7919f5a93d401f8f7198c30ad93ad74051d966c41
Date:  2024-01-30 13:55:08 +0000

    build of org.kde.Sdk, Tue Jan 30 11:23:00 UTC 2024 (5998d2f3ef21414d14f066ab91fa44e5aef65b90)

    Name: org.kde.Platform
    Arch: x86_64
    Branch: 6.6
    Built with: Flatpak 1.14.4

Found 1 signature:

  Signature made Tue 30 Jan 2024 12:21:18 PM CST using RSA key ID 562702E9E3ED7EE8
  Good signature from "Flathub Repo Signing Key <[email protected]>"
  Primary key ID 4184DD4D907A7CAE
  Key expires Mon 14 Jun 2027 08:19:40 AM CDT
  Primary key expires Mon 14 Jun 2027 08:18:56 AM CDT