• Pantherina@feddit.de
      1434·
      9 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.

        • Pantherina@feddit.de
          14·
          9 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
          12·
          9 months ago

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

        • pmk@lemmy.sdf.org
          5·
          9 months ago

          Fedora has their own flatpak repo built from their own rpms and their own runtime. Flathub has more flatpaks though.

        • Billegh@lemmy.world
          61·
          9 months ago

          Because both Red Hat and Canonical are of the “pay us to care” mindset. If you aren’t paying for support, you’re a freeloader and need to do your own research.

          • TheGrandNagus@lemmy.worldEnglish
            2·
            9 months ago

            I mean, that’s pretty much all open source software and isn’t specific at all to RH/Canonical.

            What’s provided to you is provided without warranty and you’re not automatically entitled to support, etc.

            • Billegh@lemmy.world
              1·
              9 months ago

              That’s not entirely true with Red Hat. There’s a lot of work that they’ve done in the open source community that they haven’t shared back. And canonical seems to think this is a good idea.

              • TheGrandNagus@lemmy.worldEnglish
                1·
                9 months ago

                I’m not really sure what you mean by that. What do you mean they’ve done a lot of work for the open source community that they haven’t shared back?

                And what does it have to do with providing software support free of charge?

        • thingsiplay@beehaw.org
          1·
          9 months ago

          This unverified badge does not prevent from malware being downloaded. This is a false statement! An upstream developer can have malicious intention and be verified as the upstream developer. This unverified badge only helps identifying its not a modified version by someone else and is guaranteed to be from the original developer. It does not prevent anyone from downloading and installing unverified apps. If that was the goal, then why having unverified apps in the first place on the store? Yes, because its useful. Therefore people will download unverified apps or just blindly trust verified apps.

          At the moment his is enough. But if the Flathub store grows, this can be an issue. Look at the Android and ios app stores; there are plenty of apps from original developers with malicious intentions.

  • million@lemmy.worldEnglish
    64·
    9 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 Valve” 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.

  • Captain Beyond@linkage.ds8.zone
    19·
    9 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·
              8 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·
                  8 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 "
  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
    • thingsiplay@beehaw.org
      102·
      9 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.

      • GnomeComedy@beehaw.org
        10·
        9 months ago

        I don’t see how that’s true. The main point of AppImage is it ‘just works’ on any distro. If you have one primary place to distribute them to any distro - it’s still meeting AppImage’s vision.

        • thingsiplay@beehaw.org
          9·
          9 months ago

          To be fair, after some thinking I think you are right and I was a bit in a tunnel vision logic. My previous statement looks a bit foolish now.

        • thingsiplay@beehaw.org
          1·
          9 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
              1·
              9 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.

                • thingsiplay@beehaw.org
                  2·
                  9 months ago

                  I read that page and there is nonsense included too. Just because I read that page does not make it correct. If you think that AppImages insecure, then you did not understand my point that its not the format thats insecure, but the source where you get the files. Every packaging system is insecure if you get it from bad source.

                  That’s not even a question. AppImages are fine and not insecure if you download it from a secure place you trust (like your system packages, you trust your distro maintainer fully). Would you trust every distribution maintainer on every distribution? Let’s say a Chinese Linux distribution, that maintains Flatpaks and native packages. Let’s say they are flaky. See? It’s the source you don’t trust, not the file format or packaging system.

                  Read my replies (just like you said I should read the linked post). And understand the issues.

      • simple@lemm.eeEnglish
        26·
        9 months ago

        The only good GUI for Flatpaks…

        Ain’t that the truth. I don’t know why KDE Discover is so sluggish when it comes to Flatpak, it takes me like 10+ seconds to load the landing page and see the popular apps.

          • Spectranox@lemmy.dbzer0.comEnglish
            4·
            9 months ago

            First time I’ve heard someone call Gnome Software fast. In my experience that app feels like it’s on it’s last legs; the Flatpak CLI is far better than any desktop GUI.

            • Chewy@discuss.tchncs.de
              4·
              9 months ago

              Gnome Software has received numerous updates over the last few years which make it considerable faster. Searching and viewing apps is now fast enough to be usable, compared to it taking many seconds to minutes for basic tasks.

              I’ve stopped removing Software on every system, altough I’m not usually using it. I’ve not tested it, but I feel like Discover is now slower than Software.

          • Russ@bitforged.spaceEnglish
            1·
            9 months ago

            My main issue with Gnome Software is if I queue something to install, and go back to browse for more apps, once something is done installing it “refreshed” and I lose the spot I was at. Makes me feel I can only install one thing at a time.

        • stockRot@lemmy.world
          1·
          9 months ago

          Likewise with Gnome in my experience. I’ve been using the CLI but am now realizing I might be missing out on some important information by doing that

          • TheGrandNagus@lemmy.worldEnglish
            1·
            9 months ago

            It’s definitely faster than it used to be. But yeah, searching for app updates is still more sluggish than through the terminal, at least on Fedora Workstation.