9 ms·

Ready to ruin the security of Linux, you mean. The split between package vendor and package maintainer has classically been the primary reason for malware being

Ready to ruin the security of Linux, you mean. The split between package vendor and package maintainer has classically been the primary reason for malware being rare on Linux. Getting maintainers out of the loop for auditing packages, ensuring security updates go out, etc - is an awful idea. Sandboxing applications is great, but it can be done without subverting the package manager.

matharmin 8y ago
Package managers work well for the large proportion of software on Linux that is open-source, and has enough users to warrant the effort of packaging it separately for each distro, and doesn't require you to have the latest version (or specific older version) all the time. However, there is still a large amount of software out there for which the above does not hold. That software is not currently being installed with a package manager - it is the curl | bash scripts you see all the time, as well as a whole bunch of other more manual methods of downloading and installing. It is this software that solutions like flatpack and snap are for, and it is improving both the security and usability in these cases.
- v_lisivka 8y ago
  It improves usability only. It also creates false perception of security. Malware already found in NPM packages, AUR packages, and other packaging systems without maintainers.
  - detaro 8y ago
    Is the sandboxing in Flatpack completely useless then? Any details on this?
    - deadbunny 8y ago
      Not the person you're replying to by you're intentionally being obtuse to try and prove a point he never argued. v_lisivka never mentioned sandboxing as an issue. They were clearly talking about the fact it's a free for all user submitted repo which have a provable history of people adding malware.
      - scrollaway 8y ago
        You're overly aggressive in your reply, GP just asked a legitimate question.
      - detaro 8y ago
        The comparison above was vendor-provided install scripts. From my understanding, Flatpak provides sandboxing and asks the user to confirm exceptions, which if it works reliably does seem like I win something security-wise going from "go to vendor website, use their installation script" to "go to vendor website, get their flatpak thing, know that it can't totally screw my system without me granting it exceptions". Parent claims it's only a usability benefit, so I'd like to know details about the problems with its sandboxing (totally willing to accept that they exist, sandboxing is tricky and not a cure-all)
    - TingPing 8y ago
      It is a work in progress. A few packages are very secure but many have lax permissions for now. There are big improvements coming like PipeWire, DConf sandboxing, etc but it will not happen over night.
    - v_lisivka 8y ago
      It depends. Historically, sandboxing used to protect from takeovers, because computer time and network bandwidth was costly. But today, user information is much more valuable than computer time. Flatpack partially protects from both attacks on system and on user data, but this protection is not perfect. We should expect that Flatpack protection is (or will be) on par with Android anit-malware protection.
  - Vinnl 8y ago
    Do you not think Flatpaks (and Snaps) are more secure than curl | bash scripts?
    - lugg 8y ago
      I suspect they provide a far more consistent attack surface for exploitation. One that likely won't change for many months in the case of some proprietary vendors. So no. I don't, but that doesn't make curlbash good either.
- lugg 8y ago
  > That software is not currently being installed with a package manager - it is the curl | bash scripts you see all the time, On Mac. This is mostly a sovled problem on Linux. Hell even slackware has this mostly solved. I will concede there is a lot of Linux users out there either misinformed or simply don't mind the hassle of upgrading via random curl scripts if at all. Maybe it will help them? Maybe it will just increase the target size making exploitation more worthwhile / likely? Who knows. For me, if it's not in the Arch repos (or aur) I'm incredibly unlikely to install it, to the point I don't actually have any software installed out of band other than stuff I specifically work on.
gurkendoktor 8y ago
But that doesn't really work for proprietary software. I use Flatpak/Snap for Spotify, IntelliJ, Slack etc. Audited packages are not really an alternative here, and (partially) sandboxed, distro-agnostic containers are the next best thing.
- deadbunny 8y ago
  Sure it does. I add that companies repo to my sources and install their packages. I'm trusting their keys to install their software. I'm not trusting them to install software they have zero control over.
  - TingPing 8y ago
    Flatpak repos are GPG signed, nothing changes.
    - deadbunny 8y ago
      Yes it does. I go from trusting one vendor (with one key) to install one package (and dependencies) to one 3rd party repo (with one key) to install N packages, and the owners of the 3rd part repo don't verify the uploaders to their repo. That's going from trusting 1 person to trusting thousands.
      - TingPing 8y ago
        There is nothing stopping one repo containing one app+runtime.
        deadbunny 8y ago
        Sure, just like there is nothing stopping them doing the same with apt/yum/etc... the things is that they don't. SO if they stop publishing their native packages and push to a handful of central repos I'm forced into a 1:N trust situation rather than the 1:1 it should be.
curt15 8y ago
>Getting maintainers out of the loop for auditing packages Do maintainers commonly audit source code to look for vulnerabilities? And at any rate, aren't the common security-critical libraries for flatpaks, like OpenSSL, already (in theory) provided and maintained by the runtimes? All the major consumer OSs distinguish between system components, like cryptographic services and graphics libraries, and user-facing applications. The world hasn't collapsed for them so far, and in an ideal world that distinction allows for better delegation of responsibilities.
- shittyadmin 8y ago
  It's definitely not so cut and dry - maintainers have actually managed to introduce vulnerabilities into software too. The famous Debian SSH key generation issue comes to mind. https://github.com/g0tmi1k/debian-ssh https://github.com/g0tmi1k/debian-ssh
  - repolfx 8y ago
    My experience when I worked on upstream open source software was that distribution package makers would routinely introduce subtle bugs into programs via the act of packaging. In fact on the project I worked on we stopped supporting users who didn't use our own upstream packages because the number of bugs introduced by downstream packagers was just so huge. I can't see any real benefits to the Linux approach and never could. It's one of the reasons I ended up moving to macOS. There's hardly any malware there too and yet app developers build packages themselves.
  - ris 8y ago
    This was in 2006. 2006. And people still have to dig back to then to make this point. In 2006 the security landscape was very different. The common understanding of security being a tremendously subtle issue was much, much lower. A typical system from 2006 was much more trivially exploitable than one today. A lot of things can be said about security attitudes in 2006 vs now.
- Sir_Cmpwn 8y ago
  Not always and not comprehensively, but they work alongside their users to tune packages as appropriate. It introduces a dispassionate 3rd party for users to report issues to who can fix problems which the upstream has an incentive not to fix. >The world hasn't collapsed for [major OS vendors] so far Hell yes it has. Malware and user-hostile is running rampant on the "major" platforms like Windows and macOS. Have you ever used a non-technical person's computer for a few minutes? It's like a warzone.
AnIdiotOnTheNet 8y ago
> The split between package vendor and package maintainer has classically been the primary reason for malware being rare on Linux. It's also one of the reasons users and proprietary software have been rare on Linux.
- deleted 8y ago
  [deleted]
- dec0dedab0de 8y ago
  > The split between package vendor and package maintainer has classically been the primary reason for malware being rare on Linux. It's also one of the reasons users and proprietary software have been rare on Linux. It may be why proprietary software is lagging, but I think most users prefer an OS level package manager. They just didn't know about them until the Appstore.
  - AnIdiotOnTheNet 8y ago
    Which is why everyone loves the Windows Appstore and uses it exclusively. The Appstore works on phones and tablets because they are primarily consumption-only devices, and because users are not given any other choice (also, the installer/uninstaller model has a lot of its own suck). I don't know about you, but that's not what I want out of personal computing.
    - TingPing 8y ago
      Most complaints about the appstore revolve around things like it being slow, clunky, failing to work, being designed around DRM, forbidding win32 early on, etc. Nobody is complaining that applications are in a central location.
    - blacksmith_tb 8y ago
      I am assuming that's sarcasm when it comes to Win10, but 'exclusively using the app store' comes closer to the truth for non-dev macOS users, at least that's my impression.
akerro 8y ago
There are several linux distros, I'm a single OSS developer. I once tried making my program available for Debian (deb), Ubuntu (ppa) and Fedora (rpm). I ended up supporting only AUR. There are too many differences in packaging managers, different requirements, too many websites I have to register on, too many config files for each distro. Support from people who work as packagers is non-existent, questions on SO out of date, error and warning from packaging software misleading or completely useless. It's a huge mess, and if you think existing system is better than Flatpak/Snap/AppImage, I'm sure you haven't tried porting your software to top 6 distributions. Also, enjoy dependency hell, Debian has old Qt and PA, Mint has PA compiled without noise-cancelling flags, Ubuntu had SQLite3 with not working encryption, Fedora had backported Qt5 patch (old Qt with latest patch) witch fixed one issue, but broke CSS on Cancel/OK button group. I welcome AppImage and Flatpak.
- AnIdiotOnTheNet 8y ago
  > I'm sure you haven't tried porting your software to top 6 distributions In his world developers don't do that, they throw a pile of source files into the wind and let package maintainers put it together for a distribution.
  - oblio 8y ago
    And then your package reaches distributions 1-5-7 years later. I guess that's an acceptable software distribution practice. If you're still living in the 80's :D
    - digi_owl 8y ago
      Want things to make it into STABLE distros quicker, do not break APIs because the latest bling bling framework/language/whatever got released!
    - ris 8y ago
      There are many people who have got tired of wanting the absolute latest exciting version of their text editor, mail client, IRC client, spreadsheet and want things to just work and leave them alone. The larger part of me dreads debian upgrades these days.
nickik 8y ago
The split might have some amount of minimal value, but it also has many problems. Just the insane amount of work spent, by literally 100s of different communities is almost beyond insane. Massive amount of identical work that the WASTE majority of the time, does not improve anything for the end user. Security should come from moving into well maintained platform, automatic scanners and many users. Instead of the package maintainers being the 'security reviewers' we should have app stores and sub repositories with security reviews. Nothing stops a distro from only offering flatpaks from their own repo. Centralizing and automating these things will allow for far better security processes in the long run.
- oblio 8y ago
  Don't forget the craziness in /etc. Where do I edit the hostname? Where do I edit the network card configuration? How can I check the distribution name and its version number? Where are the configuration files for Nginx and how are they structured? Etc, ad nauseam. Just try to do some of these steps on 2-3 versions (versions for non-rolling distributions) of each of the following distributions: RHEL, Debian, Ubuntu, Arch, Gentoo. The Linux distribution ecosystem is insane.
jamesgeck0 8y ago
> Getting maintainers out of the loop for auditing packages, ensuring security updates go out, etc - is an awful idea. Package maintainers can also be a bad idea! They have the ability to make the user experience worse and create a lot of unnecessary work for vendors. The version of AbiWord on Ubuntu was out of date and unsupported for a while. There was a steady stream of people going through vendor support channels reporting bugs that had been fixed a year previously. The maintainers ignored the vendor's requests to update the package to a more recent, supported version.
- Sir_Cmpwn 8y ago
  Patches speak louder than bugs. The source material used to prepare the packages is often available and sending a patch to the maintainer's inbox (or other maintainers in similar software if the maintainer is unresponsive) is a sure way to make it easier for them to accomodate you.
  - takluyver 8y ago
    So if the maintainers haven't done something, we should assume it's upstream's fault for not making it convenient enough for them, or not prompting them enough? For every distro that has packaged their code? There are real downsides to the maintainer system - it creates a lot of extra, uninteresting work, and frequently no-one's that interested in doing it, especially for smaller packages. That's why there's so much interest in other models. To give another example, if you install jupyter-notebook through apt on Ubuntu 18.04 today, you get a version with a security issue (CVE-2018-8768) that upstream released a fix for months ago. Package maintainers are not making anyone safer there.
    - Sir_Cmpwn 8y ago
      It's everyone's fault. The upstream, the maintainer, and the users. The first person who becomes aware of an issue should take steps to resolve it. By distributing this along everyone you make sure that there's enough hands to do the work and people can specialize in supporting the packages they want to work on. Maintaining a package is not hard. This isn't some hypothetical, for the record. I'm explaining how this actually works in practice.
moocowtruck 8y ago
linux security is honestly more obscurity; most linux servers by anyone but experts is like swiss cheeses.. and desktops..are just not that appealing to people who want to exploit. hell I could easily get around my login manager in ubuntu without breaking a sweat.. As a linux user I'm eager for flatpak/snap/whatever.
nickysielicki 8y ago
I don't agree. If you want to install Flatpak applications that you can trust to the same extent that you currently trust packages, all you need to do is encourage your distribution to host their own Flatpak repository and have current package maintainers move over. They can still implement their own fixes and patches and release cycles. Flathub isn't trying to replace your package manager for everything, just for graphical desktop apps. As far as I'm concerned, it's more than welcome. I'm tired of hearing about a major release of a desktop app and not having it available for months. Even worse, I'm tired of hearing about a major release, experiencing horrible bugs when the maintainer updates it, and not having any long-term option to install the previous version so that I can get work done. Flatpak solves all of this and more.

matharmin 8y ago

Package managers work well for the large proportion of software on Linux that is open-source, and has enough users to warrant the effort of packaging it separately for each distro, and doesn't require you to have the latest version (or specific older version) all the time. However, there is still a large amount of software out there for which the above does not hold. That software is not currently being installed with a package manager - it is the curl | bash scripts you see all the time, as well as a whole bunch of other more manual methods of downloading and installing. It is this software that solutions like flatpack and snap are for, and it is improving both the security and usability in these cases.

v_lisivka 8y ago
It improves usability only. It also creates false perception of security. Malware already found in NPM packages, AUR packages, and other packaging systems without maintainers.
- detaro 8y ago
  Is the sandboxing in Flatpack completely useless then? Any details on this?
  - deadbunny 8y ago
    Not the person you're replying to by you're intentionally being obtuse to try and prove a point he never argued. v_lisivka never mentioned sandboxing as an issue. They were clearly talking about the fact it's a free for all user submitted repo which have a provable history of people adding malware.
    - scrollaway 8y ago
      You're overly aggressive in your reply, GP just asked a legitimate question.
    - detaro 8y ago
      The comparison above was vendor-provided install scripts. From my understanding, Flatpak provides sandboxing and asks the user to confirm exceptions, which if it works reliably does seem like I win something security-wise going from "go to vendor website, use their installation script" to "go to vendor website, get their flatpak thing, know that it can't totally screw my system without me granting it exceptions". Parent claims it's only a usability benefit, so I'd like to know details about the problems with its sandboxing (totally willing to accept that they exist, sandboxing is tricky and not a cure-all)
  - TingPing 8y ago
    It is a work in progress. A few packages are very secure but many have lax permissions for now. There are big improvements coming like PipeWire, DConf sandboxing, etc but it will not happen over night.
  - v_lisivka 8y ago
    It depends. Historically, sandboxing used to protect from takeovers, because computer time and network bandwidth was costly. But today, user information is much more valuable than computer time. Flatpack partially protects from both attacks on system and on user data, but this protection is not perfect. We should expect that Flatpack protection is (or will be) on par with Android anit-malware protection.
- Vinnl 8y ago
  Do you not think Flatpaks (and Snaps) are more secure than curl | bash scripts?
  - lugg 8y ago
    I suspect they provide a far more consistent attack surface for exploitation. One that likely won't change for many months in the case of some proprietary vendors. So no. I don't, but that doesn't make curlbash good either.
lugg 8y ago
> That software is not currently being installed with a package manager - it is the curl | bash scripts you see all the time, On Mac. This is mostly a sovled problem on Linux. Hell even slackware has this mostly solved. I will concede there is a lot of Linux users out there either misinformed or simply don't mind the hassle of upgrading via random curl scripts if at all. Maybe it will help them? Maybe it will just increase the target size making exploitation more worthwhile / likely? Who knows. For me, if it's not in the Arch repos (or aur) I'm incredibly unlikely to install it, to the point I don't actually have any software installed out of band other than stuff I specifically work on.

gurkendoktor 8y ago

But that doesn't really work for proprietary software. I use Flatpak/Snap for Spotify, IntelliJ, Slack etc. Audited packages are not really an alternative here, and (partially) sandboxed, distro-agnostic containers are the next best thing.

deadbunny 8y ago
Sure it does. I add that companies repo to my sources and install their packages. I'm trusting their keys to install their software. I'm not trusting them to install software they have zero control over.
- TingPing 8y ago
  Flatpak repos are GPG signed, nothing changes.
  - deadbunny 8y ago
    Yes it does. I go from trusting one vendor (with one key) to install one package (and dependencies) to one 3rd party repo (with one key) to install N packages, and the owners of the 3rd part repo don't verify the uploaders to their repo. That's going from trusting 1 person to trusting thousands.
    - TingPing 8y ago
      There is nothing stopping one repo containing one app+runtime.
      - deadbunny 8y ago
        Sure, just like there is nothing stopping them doing the same with apt/yum/etc... the things is that they don't. SO if they stop publishing their native packages and push to a handful of central repos I'm forced into a 1:N trust situation rather than the 1:1 it should be.

curt15 8y ago

>Getting maintainers out of the loop for auditing packages Do maintainers commonly audit source code to look for vulnerabilities? And at any rate, aren't the common security-critical libraries for flatpaks, like OpenSSL, already (in theory) provided and maintained by the runtimes? All the major consumer OSs distinguish between system components, like cryptographic services and graphics libraries, and user-facing applications. The world hasn't collapsed for them so far, and in an ideal world that distinction allows for better delegation of responsibilities.

shittyadmin 8y ago
It's definitely not so cut and dry - maintainers have actually managed to introduce vulnerabilities into software too. The famous Debian SSH key generation issue comes to mind. https://github.com/g0tmi1k/debian-ssh https://github.com/g0tmi1k/debian-ssh
- repolfx 8y ago
  My experience when I worked on upstream open source software was that distribution package makers would routinely introduce subtle bugs into programs via the act of packaging. In fact on the project I worked on we stopped supporting users who didn't use our own upstream packages because the number of bugs introduced by downstream packagers was just so huge. I can't see any real benefits to the Linux approach and never could. It's one of the reasons I ended up moving to macOS. There's hardly any malware there too and yet app developers build packages themselves.
- ris 8y ago
  This was in 2006. 2006. And people still have to dig back to then to make this point. In 2006 the security landscape was very different. The common understanding of security being a tremendously subtle issue was much, much lower. A typical system from 2006 was much more trivially exploitable than one today. A lot of things can be said about security attitudes in 2006 vs now.
Sir_Cmpwn 8y ago
Not always and not comprehensively, but they work alongside their users to tune packages as appropriate. It introduces a dispassionate 3rd party for users to report issues to who can fix problems which the upstream has an incentive not to fix. >The world hasn't collapsed for [major OS vendors] so far Hell yes it has. Malware and user-hostile is running rampant on the "major" platforms like Windows and macOS. Have you ever used a non-technical person's computer for a few minutes? It's like a warzone.

AnIdiotOnTheNet 8y ago

> The split between package vendor and package maintainer has classically been the primary reason for malware being rare on Linux. It's also one of the reasons users and proprietary software have been rare on Linux.

deleted 8y ago
[deleted]
dec0dedab0de 8y ago
> The split between package vendor and package maintainer has classically been the primary reason for malware being rare on Linux. It's also one of the reasons users and proprietary software have been rare on Linux. It may be why proprietary software is lagging, but I think most users prefer an OS level package manager. They just didn't know about them until the Appstore.
- AnIdiotOnTheNet 8y ago
  Which is why everyone loves the Windows Appstore and uses it exclusively. The Appstore works on phones and tablets because they are primarily consumption-only devices, and because users are not given any other choice (also, the installer/uninstaller model has a lot of its own suck). I don't know about you, but that's not what I want out of personal computing.
  - TingPing 8y ago
    Most complaints about the appstore revolve around things like it being slow, clunky, failing to work, being designed around DRM, forbidding win32 early on, etc. Nobody is complaining that applications are in a central location.
  - blacksmith_tb 8y ago
    I am assuming that's sarcasm when it comes to Win10, but 'exclusively using the app store' comes closer to the truth for non-dev macOS users, at least that's my impression.

akerro 8y ago

There are several linux distros, I'm a single OSS developer. I once tried making my program available for Debian (deb), Ubuntu (ppa) and Fedora (rpm). I ended up supporting only AUR. There are too many differences in packaging managers, different requirements, too many websites I have to register on, too many config files for each distro. Support from people who work as packagers is non-existent, questions on SO out of date, error and warning from packaging software misleading or completely useless. It's a huge mess, and if you think existing system is better than Flatpak/Snap/AppImage, I'm sure you haven't tried porting your software to top 6 distributions. Also, enjoy dependency hell, Debian has old Qt and PA, Mint has PA compiled without noise-cancelling flags, Ubuntu had SQLite3 with not working encryption, Fedora had backported Qt5 patch (old Qt with latest patch) witch fixed one issue, but broke CSS on Cancel/OK button group. I welcome AppImage and Flatpak.

AnIdiotOnTheNet 8y ago
> I'm sure you haven't tried porting your software to top 6 distributions In his world developers don't do that, they throw a pile of source files into the wind and let package maintainers put it together for a distribution.
- oblio 8y ago
  And then your package reaches distributions 1-5-7 years later. I guess that's an acceptable software distribution practice. If you're still living in the 80's :D
  - digi_owl 8y ago
    Want things to make it into STABLE distros quicker, do not break APIs because the latest bling bling framework/language/whatever got released!
  - ris 8y ago
    There are many people who have got tired of wanting the absolute latest exciting version of their text editor, mail client, IRC client, spreadsheet and want things to just work and leave them alone. The larger part of me dreads debian upgrades these days.

nickik 8y ago

The split might have some amount of minimal value, but it also has many problems. Just the insane amount of work spent, by literally 100s of different communities is almost beyond insane. Massive amount of identical work that the WASTE majority of the time, does not improve anything for the end user. Security should come from moving into well maintained platform, automatic scanners and many users. Instead of the package maintainers being the 'security reviewers' we should have app stores and sub repositories with security reviews. Nothing stops a distro from only offering flatpaks from their own repo. Centralizing and automating these things will allow for far better security processes in the long run.

oblio 8y ago
Don't forget the craziness in /etc. Where do I edit the hostname? Where do I edit the network card configuration? How can I check the distribution name and its version number? Where are the configuration files for Nginx and how are they structured? Etc, ad nauseam. Just try to do some of these steps on 2-3 versions (versions for non-rolling distributions) of each of the following distributions: RHEL, Debian, Ubuntu, Arch, Gentoo. The Linux distribution ecosystem is insane.

jamesgeck0 8y ago

> Getting maintainers out of the loop for auditing packages, ensuring security updates go out, etc - is an awful idea. Package maintainers can also be a bad idea! They have the ability to make the user experience worse and create a lot of unnecessary work for vendors. The version of AbiWord on Ubuntu was out of date and unsupported for a while. There was a steady stream of people going through vendor support channels reporting bugs that had been fixed a year previously. The maintainers ignored the vendor's requests to update the package to a more recent, supported version.

Sir_Cmpwn 8y ago
Patches speak louder than bugs. The source material used to prepare the packages is often available and sending a patch to the maintainer's inbox (or other maintainers in similar software if the maintainer is unresponsive) is a sure way to make it easier for them to accomodate you.
- takluyver 8y ago
  So if the maintainers haven't done something, we should assume it's upstream's fault for not making it convenient enough for them, or not prompting them enough? For every distro that has packaged their code? There are real downsides to the maintainer system - it creates a lot of extra, uninteresting work, and frequently no-one's that interested in doing it, especially for smaller packages. That's why there's so much interest in other models. To give another example, if you install jupyter-notebook through apt on Ubuntu 18.04 today, you get a version with a security issue (CVE-2018-8768) that upstream released a fix for months ago. Package maintainers are not making anyone safer there.
  - Sir_Cmpwn 8y ago
    It's everyone's fault. The upstream, the maintainer, and the users. The first person who becomes aware of an issue should take steps to resolve it. By distributing this along everyone you make sure that there's enough hands to do the work and people can specialize in supporting the packages they want to work on. Maintaining a package is not hard. This isn't some hypothetical, for the record. I'm explaining how this actually works in practice.

moocowtruck 8y ago

linux security is honestly more obscurity; most linux servers by anyone but experts is like swiss cheeses.. and desktops..are just not that appealing to people who want to exploit. hell I could easily get around my login manager in ubuntu without breaking a sweat.. As a linux user I'm eager for flatpak/snap/whatever.

nickysielicki 8y ago

I don't agree. If you want to install Flatpak applications that you can trust to the same extent that you currently trust packages, all you need to do is encourage your distribution to host their own Flatpak repository and have current package maintainers move over. They can still implement their own fixes and patches and release cycles. Flathub isn't trying to replace your package manager for everything, just for graphical desktop apps. As far as I'm concerned, it's more than welcome. I'm tired of hearing about a major release of a desktop app and not having it available for months. Even worse, I'm tired of hearing about a major release, experiencing horrible bugs when the maintainer updates it, and not having any long-term option to install the previous version so that I can get work done. Flatpak solves all of this and more.