8 ms·

So, Snaps are bad, Flatpak is bad. What's good?

pizza234 6y ago
Spreading the PPAs culture, hoping that usage, and consequently tooling, will improve. What at least some people don't understand, is that PPAs make the source available, so one is not downloading a black box. Plus, they also add reproducibility, which is not to underestimate.
- alanfranz 6y ago
  Do PPAs work on non-Ubuntu distributions? I thought there was one old ticket about supporting Debian, and it was ultimately closed or abandoned. Also, PPAs do absolutely nothing about sandboxing. It's a different kind of concern.
  - cies 6y ago
    > Also, PPAs do absolutely nothing about sandboxing. It's a different kind of concern. Therefor we use opensource. Anything you dont trust is even hard to run safely in a sandbox. BTW +1 for PPA culture.
    - zaarn 6y ago
      OpenSource doesn't prevent CVEs that allow attackers to take over anyway. What If you install script has a bug that lets an attacker place arbitrary SUID binaries? Or it has a bug that deletes your entire system (Steam had this bug and the script was open and available, they weren't the only ones either).
    - alanfranz 6y ago
      It's a totally different concern. I don't understand how PPAs and similar distribution approaches (i.e. native packages with hosted build systems) are getting mingled with flatpak and/or snap sandboxing objectives. You can distribute open source software via flatpak or snap. And you can create a build system that takes open source software as a source and creates a flatpak or snap distribution. It's totally possible to hide a backdoor in an open source software. A working sandbox will prevent certain attacks to your system, whether it was built from an open source or not. This already works on most (all?) mobile operating systems.
      - cies 6y ago
        i was responding to the sandboxing part. not having a sandbox is less of a problem when you run FLOSS (in the context of PPAs that's relevant i think)
        alanfranz 6y ago
        > not having a sandbox is less of a problem when you run FLOSS (in the context of PPAs that's relevant i think) I disagree. Source auditing is irrelevant for day-to-day software use.
    - Xylakant 6y ago
      when was the last time you fully audited a ppa? Like the source, that it builds from the canonical source, all patches it applies, all install scripts it packages and all changes it actually does? The trustworthiness of the ppa author. I know that I at best do cursory checks based on the reputation the author or the source linking to the PPA have, but I'm aware that this is a honor based system, and open source is practically irrelevant to that.
      - cies 6y ago
        good point. i never checked it.
  - aesh2Xa1 6y ago
    PPA (personal package archive) is the Ubuntu name, but other distributions make it possible to do the same. The system is a way to distribute packages through the package manager, and repository metadata is hosted centrally. Fedora has such repositories (RPM Fusion, Copr). Arch does, too (AUR). Other distributions, including Debian, can use them as well, so long as there exists a community.
    - m4rtink 6y ago
      I would not really call RPM Fusion a PPA - it's basically a repo with packages that are inherent not open source or patent encumbered and can't thus be in regular Fedora repos (and Copr actually). Otherwise the community maintains it to a very similar standard as the regular Fedora repos. Compared to that Copr is a real PPA where you can build stuff into personal repo (as long as its built from source, licensing is fine & the thing is not patent encumbered).
  - husam212 6y ago
    It is a completely different approach, instead of sandboxing potentially malicious software, prevent it from getting into your machine, this approach works for open-source only. Most popular distors provide similar stuff to PPA, the AUR in Arch for example.
    - viraptor 6y ago
      This is the perfect and not possible territory. Even with full access to the source, you can't be sure if it's malicious, or if it can be made malicious at runtime.
  - viraptor 6y ago
    For rpms the alternative would be Fedora COPR. (https://copr.fedorainfracloud.org/ https://copr.fedorainfracloud.org/) It is rpm-specific, but not Fedora-specific.
- kd913 6y ago
  PPAs are the worst of the worst and absolutely should not be encouraged. With PPAs, everytime someone runs sudo apt upgrade, they are giving root privileges to their machine to some random person on the internet. No, having users scan the source code every time a package is upgraded is awful. I reiterate, the most popular PPA is an old 3rd party Java PPA which doesn't even offer Java anymore. That PPA has root access to thousands of machines.
  - pizza234 6y ago
    Using an old 3rd party Java PPA is as foolish as it gets, as there is an official OpenJDK PPA that supports all the JDK versions for many Ubuntu releases. I'm also skeptical of the statistic you mention, since Canonical doesn't publish rankings, and download stats need to be retrieved via API on an individual repository basis. Relying on extremely incompetent users to make a general point is a strawman, not to talk about defining PPAs as "random people", as many software products have official repositories or affiliations (I take you don't use PPAs). If one likes to scream about administrative privileges to get attention, they're forgetting that any Linux user is giving root access to thousands of packages. So the point is really the web of trust. If we talk about the past and present, there has been no malicious attacks (or in number so small, that it's hard to find reports). So much for the "worst of the worst". If we talk about the future, there's no reason why a web of trust can't be built. "To reiterate", lots of PPAs are official, including the OpenJDK one, so if the PPAs approach happened to get traction, it'd be really a matter of software authors to build their own or to appoint somebody to do. This is really the concept of maintainers and their network, it's applying to the distro you're using, and it's nothing fundamentally different.
    - kd913 6y ago
      >Using an old 3rd party Java PPA is as foolish as it gets, as there is an official OpenJDK PPA that supports all the JDK versions for many Ubuntu releases. I'm also skeptical of the statistic you mention, since Canonical doesn't publish rankings, and download stats need to be retrieved via API on an individual repository basis. It was from a podcast from Canonical's apopey who described precisely some of the technical decisions behind snap and why they never bothered to open source it after the disaster that was open sourcing launchpad. He knows the statistics because most of these 3rd party PPAs were hosted on Launchpad that was only run by Canonical. >Relying on extremely incompetent users to make a general point is a strawman, not to talk about defining PPAs as "random people", as many software products have official repositories or affiliations (I take you don't use PPAs). Systems like this should be designed for 99% of users. PPAs were designed for 0.1% of system admins, and developers, not users. They are absolutely awful UX design, they are inherently unsafe, and unreliable. Expecting users to vet that software is safe just because the source code is available is flatly a stupid idea. 99% of users for any piece of software will have no idea what they are looking at and are incapable of vetting it. Have you vetted manually chromium, vlc, firefox, vscode etc? Publishers on PPAs don't test against every distribution, and if they publish a package or dependency that breaks system libs than users are stuffed. Users would have little recourse. I doubt every ppa owner tests 14.04, 16.04, 18.04, 20.04 and 20.10 builds to check their ppa won't break anything. >If we talk about the past and present, there has been no malicious attacks (or in number so small, that it's hard to find reports). So much for the "worst of the worst". Which has inspired both RedHat and Canonical to try and move towards flatpaks/snaps instead? The reason malicious attacks aren't there is because ppas aren't that popular because for good reason people tend to main repos. Already on snap there was evidence of people bundling a cryptominer that was detected by Canonical. You think nobody has ever attempted to build/publish malware through ppas? Please. >If we talk about the future, there's no reason why a web of trust can't be built. "To reiterate", lots of PPAs are official, including the OpenJDK one, so if the PPAs approach happened to get traction, it'd be really a matter of software authors to build their own or to appoint somebody to do. My web of trust is purely Canonical. I chose it when I downloaded their OS. I trust their repos and snap store. I don't need to trust random Russian PPA for any reason. If a dev wants to publish something newer, put it on the snap or flatpak store or I won't use it.
kthxb 6y ago
compiling from source, i guess
phkahler 6y ago
Packages from your linux distribution. Install using their standard package manager.
- kanox 6y ago
  Distro packages get full access to your system (install scripts get root) so if your issue is trusting the software vendor they are strictly worse.
  - trasz 6y ago
    How is it any worse than flatpaks having full access to your home directory?
    - Xylakant 6y ago
      How is it any better than flatpaks having full access to your home directory? Yet, one of the points of criticism against flatpak is that it doesn't protect the users home directory. Now, it's certainly debatable if flatpak could or should push more in that direction, like apple did when they introduced the sandbox for app store applications, but flatpak certainly does not have leverage to the same extend as apple has. So it's up to the app to opt in to a suitable sandbox set. It's a sad state of affairs, but I don't see a viable path for the flatpak folks to change that.
      - trasz 6y ago
        It’s better by not depending on yet another component or layer of abstraction. If you had a distribution which would use flatpaks for everything (ie no other packaging system involved), then sure, usual packages probably wouldn’t be any better than flatpaks.
        Xylakant 6y ago
        But that’s not the point that is made against flatpaks - the point made in the article is “it allows access to the home directory, so it’s worse.” Whether flatpaks is better or worse than packages depends on many other factors. Flatpaks allow software providers to package for multiple operating systems in one package, for example. This makes software available that otherwise wouldn’t be. Whether that’s worth it or not is debatable, but raising clearly invalid points to attack flatpaks is disingenuous.
butterknife 6y ago
appimage
- AnIdiotOnTheNet 6y ago
  AppImage has a feature that neither Snaps nor Flatpak do: You don't need a repository or special manager for them to work. You can literally just take the AppImage file to (almost) any Linux Desktop on a thumb drive and run it.
  - the_why_of_y 6y ago
    Provided that the application inside the AppImage is built in a portable way, for which AppImage provided zero support whatsoever, last time I checked. FlatPak has Runtimes/SDKs for this, Snap has the one true Canonical-controlled base snap.
akerro 6y ago
Native apps are bad, webapps are really bad, firmware is worse, CPU firmware is even worse. That's the state of the world.
geokon 6y ago
PPAs? You get the source and the build and it's all open... I mean, Launchpad could be modernized and brought to the 21st century but all the functionality is there. I'd love to hear arguments against it though :)
flavor8 6y ago
We need easier/more integrated app sandboxing. Last time I tried firejail it was a pain in the ass, but looking at the docs it seems like it may have gotten better. Regardless, distributions could actively promote it (or something like it) as a default way of running apps, with some convenience features.
- johnisgood 6y ago
  I have been using firejail for quite some time now. It definitely has gotten better.
deleted 6y ago
[deleted]

Spreading the PPAs culture, hoping that usage, and consequently tooling, will improve. What at least some people don't understand, is that PPAs make the source available, so one is not downloading a black box. Plus, they also add reproducibility, which is not to underestimate.

alanfranz 6y ago
Do PPAs work on non-Ubuntu distributions? I thought there was one old ticket about supporting Debian, and it was ultimately closed or abandoned. Also, PPAs do absolutely nothing about sandboxing. It's a different kind of concern.
- cies 6y ago
  > Also, PPAs do absolutely nothing about sandboxing. It's a different kind of concern. Therefor we use opensource. Anything you dont trust is even hard to run safely in a sandbox. BTW +1 for PPA culture.
  - zaarn 6y ago
    OpenSource doesn't prevent CVEs that allow attackers to take over anyway. What If you install script has a bug that lets an attacker place arbitrary SUID binaries? Or it has a bug that deletes your entire system (Steam had this bug and the script was open and available, they weren't the only ones either).
  - alanfranz 6y ago
    It's a totally different concern. I don't understand how PPAs and similar distribution approaches (i.e. native packages with hosted build systems) are getting mingled with flatpak and/or snap sandboxing objectives. You can distribute open source software via flatpak or snap. And you can create a build system that takes open source software as a source and creates a flatpak or snap distribution. It's totally possible to hide a backdoor in an open source software. A working sandbox will prevent certain attacks to your system, whether it was built from an open source or not. This already works on most (all?) mobile operating systems.
    - cies 6y ago
      i was responding to the sandboxing part. not having a sandbox is less of a problem when you run FLOSS (in the context of PPAs that's relevant i think)
      - alanfranz 6y ago
        > not having a sandbox is less of a problem when you run FLOSS (in the context of PPAs that's relevant i think) I disagree. Source auditing is irrelevant for day-to-day software use.
  - Xylakant 6y ago
    when was the last time you fully audited a ppa? Like the source, that it builds from the canonical source, all patches it applies, all install scripts it packages and all changes it actually does? The trustworthiness of the ppa author. I know that I at best do cursory checks based on the reputation the author or the source linking to the PPA have, but I'm aware that this is a honor based system, and open source is practically irrelevant to that.
    - cies 6y ago
      good point. i never checked it.
- aesh2Xa1 6y ago
  PPA (personal package archive) is the Ubuntu name, but other distributions make it possible to do the same. The system is a way to distribute packages through the package manager, and repository metadata is hosted centrally. Fedora has such repositories (RPM Fusion, Copr). Arch does, too (AUR). Other distributions, including Debian, can use them as well, so long as there exists a community.
  - m4rtink 6y ago
    I would not really call RPM Fusion a PPA - it's basically a repo with packages that are inherent not open source or patent encumbered and can't thus be in regular Fedora repos (and Copr actually). Otherwise the community maintains it to a very similar standard as the regular Fedora repos. Compared to that Copr is a real PPA where you can build stuff into personal repo (as long as its built from source, licensing is fine & the thing is not patent encumbered).
- husam212 6y ago
  It is a completely different approach, instead of sandboxing potentially malicious software, prevent it from getting into your machine, this approach works for open-source only. Most popular distors provide similar stuff to PPA, the AUR in Arch for example.
  - viraptor 6y ago
    This is the perfect and not possible territory. Even with full access to the source, you can't be sure if it's malicious, or if it can be made malicious at runtime.
- viraptor 6y ago
  For rpms the alternative would be Fedora COPR. (https://copr.fedorainfracloud.org/ https://copr.fedorainfracloud.org/) It is rpm-specific, but not Fedora-specific.
kd913 6y ago
PPAs are the worst of the worst and absolutely should not be encouraged. With PPAs, everytime someone runs sudo apt upgrade, they are giving root privileges to their machine to some random person on the internet. No, having users scan the source code every time a package is upgraded is awful. I reiterate, the most popular PPA is an old 3rd party Java PPA which doesn't even offer Java anymore. That PPA has root access to thousands of machines.
- pizza234 6y ago
  Using an old 3rd party Java PPA is as foolish as it gets, as there is an official OpenJDK PPA that supports all the JDK versions for many Ubuntu releases. I'm also skeptical of the statistic you mention, since Canonical doesn't publish rankings, and download stats need to be retrieved via API on an individual repository basis. Relying on extremely incompetent users to make a general point is a strawman, not to talk about defining PPAs as "random people", as many software products have official repositories or affiliations (I take you don't use PPAs). If one likes to scream about administrative privileges to get attention, they're forgetting that any Linux user is giving root access to thousands of packages. So the point is really the web of trust. If we talk about the past and present, there has been no malicious attacks (or in number so small, that it's hard to find reports). So much for the "worst of the worst". If we talk about the future, there's no reason why a web of trust can't be built. "To reiterate", lots of PPAs are official, including the OpenJDK one, so if the PPAs approach happened to get traction, it'd be really a matter of software authors to build their own or to appoint somebody to do. This is really the concept of maintainers and their network, it's applying to the distro you're using, and it's nothing fundamentally different.
  - kd913 6y ago
    >Using an old 3rd party Java PPA is as foolish as it gets, as there is an official OpenJDK PPA that supports all the JDK versions for many Ubuntu releases. I'm also skeptical of the statistic you mention, since Canonical doesn't publish rankings, and download stats need to be retrieved via API on an individual repository basis. It was from a podcast from Canonical's apopey who described precisely some of the technical decisions behind snap and why they never bothered to open source it after the disaster that was open sourcing launchpad. He knows the statistics because most of these 3rd party PPAs were hosted on Launchpad that was only run by Canonical. >Relying on extremely incompetent users to make a general point is a strawman, not to talk about defining PPAs as "random people", as many software products have official repositories or affiliations (I take you don't use PPAs). Systems like this should be designed for 99% of users. PPAs were designed for 0.1% of system admins, and developers, not users. They are absolutely awful UX design, they are inherently unsafe, and unreliable. Expecting users to vet that software is safe just because the source code is available is flatly a stupid idea. 99% of users for any piece of software will have no idea what they are looking at and are incapable of vetting it. Have you vetted manually chromium, vlc, firefox, vscode etc? Publishers on PPAs don't test against every distribution, and if they publish a package or dependency that breaks system libs than users are stuffed. Users would have little recourse. I doubt every ppa owner tests 14.04, 16.04, 18.04, 20.04 and 20.10 builds to check their ppa won't break anything. >If we talk about the past and present, there has been no malicious attacks (or in number so small, that it's hard to find reports). So much for the "worst of the worst". Which has inspired both RedHat and Canonical to try and move towards flatpaks/snaps instead? The reason malicious attacks aren't there is because ppas aren't that popular because for good reason people tend to main repos. Already on snap there was evidence of people bundling a cryptominer that was detected by Canonical. You think nobody has ever attempted to build/publish malware through ppas? Please. >If we talk about the future, there's no reason why a web of trust can't be built. "To reiterate", lots of PPAs are official, including the OpenJDK one, so if the PPAs approach happened to get traction, it'd be really a matter of software authors to build their own or to appoint somebody to do. My web of trust is purely Canonical. I chose it when I downloaded their OS. I trust their repos and snap store. I don't need to trust random Russian PPA for any reason. If a dev wants to publish something newer, put it on the snap or flatpak store or I won't use it.

kthxb 6y ago

compiling from source, i guess

phkahler 6y ago

Packages from your linux distribution. Install using their standard package manager.

kanox 6y ago
Distro packages get full access to your system (install scripts get root) so if your issue is trusting the software vendor they are strictly worse.
- trasz 6y ago
  How is it any worse than flatpaks having full access to your home directory?
  - Xylakant 6y ago
    How is it any better than flatpaks having full access to your home directory? Yet, one of the points of criticism against flatpak is that it doesn't protect the users home directory. Now, it's certainly debatable if flatpak could or should push more in that direction, like apple did when they introduced the sandbox for app store applications, but flatpak certainly does not have leverage to the same extend as apple has. So it's up to the app to opt in to a suitable sandbox set. It's a sad state of affairs, but I don't see a viable path for the flatpak folks to change that.
    - trasz 6y ago
      It’s better by not depending on yet another component or layer of abstraction. If you had a distribution which would use flatpaks for everything (ie no other packaging system involved), then sure, usual packages probably wouldn’t be any better than flatpaks.
      - Xylakant 6y ago
        But that’s not the point that is made against flatpaks - the point made in the article is “it allows access to the home directory, so it’s worse.” Whether flatpaks is better or worse than packages depends on many other factors. Flatpaks allow software providers to package for multiple operating systems in one package, for example. This makes software available that otherwise wouldn’t be. Whether that’s worth it or not is debatable, but raising clearly invalid points to attack flatpaks is disingenuous.

butterknife 6y ago

appimage

AnIdiotOnTheNet 6y ago
AppImage has a feature that neither Snaps nor Flatpak do: You don't need a repository or special manager for them to work. You can literally just take the AppImage file to (almost) any Linux Desktop on a thumb drive and run it.
- the_why_of_y 6y ago
  Provided that the application inside the AppImage is built in a portable way, for which AppImage provided zero support whatsoever, last time I checked. FlatPak has Runtimes/SDKs for this, Snap has the one true Canonical-controlled base snap.

akerro 6y ago

Native apps are bad, webapps are really bad, firmware is worse, CPU firmware is even worse. That's the state of the world.

geokon 6y ago

PPAs? You get the source and the build and it's all open... I mean, Launchpad could be modernized and brought to the 21st century but all the functionality is there. I'd love to hear arguments against it though :)

flavor8 6y ago

We need easier/more integrated app sandboxing. Last time I tried firejail it was a pain in the ass, but looking at the docs it seems like it may have gotten better. Regardless, distributions could actively promote it (or something like it) as a default way of running apps, with some convenience features.

johnisgood 6y ago
I have been using firejail for quite some time now. It definitely has gotten better.

deleted 6y ago

[deleted]