When I first started using Linux 15 years ago (Ubuntu) , if there was some software you wanted that wasn’t in the distro’s repos you can probably bet that there was a PPA you could add to your system in order to get it.

Seems that nowadays this is basically dead. Some people provide appimage, snap or flatpak but these don’t integrate well into the system at all and don’t integrate with the system updater.

I use Spek for audio analysis and yesterday it told me I didn’t have permission to read a file, I a directory that I owned, that I definitely have permission to read. Took me ages to realise it was because Spek was a snap.

I get that these new package formats provide all the dependencies an app needs, but PPAs felt more centralised and integrated in terms of system updates and the system itself. Have they just fallen out of favour?

  • federico3@lemmy.ml
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    29 days ago

    They do now have a verified tick in Flathub to show if a Flatpak is official

    Jia Tan liked your comment

    Without the traditional distribution workflow what prevents flatpaks to be full of security issues? Unfortunately sandboxing cannot protect the data you put in the application.

    • Gecko@lemmy.world
      link
      fedilink
      arrow-up
      6
      arrow-down
      1
      ·
      edit-2
      29 days ago

      Jia Tan liked your comment

      Without the traditional distribution workflow […]

      You are aware that the xz exploit made it into Debian Testing and Fedora 40 despite the traditional distribution workflows? Distro maintainers are not a silver bullet when it comes to security. They have to watch hundreds to thousands of packages so having them do security checks for each package is simply not feasible.

      • federico3@lemmy.ml
        link
        fedilink
        English
        arrow-up
        4
        arrow-down
        1
        ·
        29 days ago

        I am well aware of it. It is an example of the traditional distribution workflow preventing a backdoor from landing into Debian Stable and other security-focused distributions. Of course the backdoor could have been spotted sooner, but also much later, given its sophistication.

        In the specific case of xz, “Jia Tan” had to spend years of efforts in gaining trust and then to very carefully conceal the backdoor (and still failed to reach Debian Stable and other distributions). Why so much effort? Because many simpler backdoors or vulnerabilities have been spotted sooner. Also many less popular FOSS projects from unknown or untrusted upstream authors are simply not packaged.

        Contrast that with distributing large “blobs”, be it containers from docker hub or flatpak, snap etc, or statically linked binaries or pulling dependencies straight from upstream repositories (e.g. npm install): any vulnerability or backdoor can reach end users quickly and potentially stay unnoticed for years, as it happened many times.

        There has been various various reports and papers published around the topic, for example https://www.securityweek.com/analysis-4-million-docker-images-shows-half-have-critical-vulnerabilities/

        They have to watch hundreds to thousands of packages so having them do security checks for each package is simply not feasible.

        That is what we do and yes, it takes effort, but it is still working better than the alternatives. Making attacks difficult and time consuming is good security.

        If there is anything to learn from the xz attack is that both package maintainers and end users should be less lenient in accepting blobs of any kind.