8 ms·

Yet another attack vector that doesn't exist at all in Linux distributions but invented by language package managers, sadly. They solved the issue 2 decades a

Yet another attack vector that doesn't exist at all in Linux distributions but invented by language package managers, sadly. They solved the issue 2 decades ago by heavily vetting packages before accepting them into repositories. Users are allowed to add and use packages from 3rd party repositories. Maybe solution to this is creating curated repositories based on publicly open ones and using them by default (and requiring opt-in for using other repositories). Conda for Python and Stackage for Haskell seems like relevant solutions.

mikehollinger 9y ago
There's a certain amount of work (and therefore money) required to do this. That incremental difference is small for a well designed application, but - someone must actually vet and curate the contents of the repo. That tends to slow down execution, leading to scenarios where things like docker a year or two ago from the canonical "trusty" repo were hopelessly behind the "real" docker since docker was evolving so quickly and trusty was by design slowing down. Each commit that went into trusty required a team to submit and a team to approve. That costs money. ;-)
- kasabali 9y ago
  It is a matter of distribution and release policy and not an inherent limitation of the model. Stable/lts/enterprise distributions have other concerns like preventing regressions and configuration or behavior changes during lifetime of release. Rolling distributions like Arch and OpenSuse Tumbleweed on the other hand can move a lot faster but still provide basic vetting wrt security and sanity of new/updated packages.
disconnected 9y ago
> Yet another attack vector that doesn't exist at all in Linux distributions but invented by language package managers, sadly. https://www.schneier.com/blog/archives/2008/05/random_number_b.html https://www.schneier.com/blog/archives/2008/05/random_number... A.K.A., the Debian openssl Fiasco. Just one example of distros fucking up the packages from upstream and causing major havoc.
- ex_amazon_sde 9y ago
  You are cherry-picking one example involving a library that had a plethora of vulnerabilities from upstream. Contrast it with reviewing and maintaining 50k+ packages, managing thousands of CVEs every year, sometimes even writing security patches before upstream. Also the project pioneered reproducible builds and implemented build hardening for most packages.
  - daenney 9y ago
    None of that, nor the good that they have done, negates the fact that distributions can fuck up too. And regardless of whether OpenSSL had a plethora of bugs from upstream, this one wasn't one of them. It was only in Debian, because of changes the project had made. Just because it's packaged in Debian by Debian maintainers doesn't mean you're immune to these kind of issues. They're arguably less likely but you'd need to do a comprehensive study of all packages in the repo to get to some usable statistic.
    - lanstin 9y ago
      So the PyPi issue isn't a bug. It is an attack by hostiles. There are always bugs but this is a person packaging malware probably as a practice to package worse stuff that runs at build time. If package maintainers have time to respond to valgrind reports on their package they have time to check strace on the installer. Edited: longer rant.
      - daenney 9y ago
        > So the PyPi issue isn't a bug. It is an attack by hostiles. Arguably. The issue with typosquatting on PyPi has been known and demonstrated for a long time, but nothing has been done about it. Considering there are ways of closing this attack vector, even though it would require some serious work, I'd consider this a bug. It's just a bug that's being exploited now.
- cookiecaper 9y ago
  This is a totally different issue. Distro package management isn't perfect, but you don't have to worry about a random malicious individual squatting on "opensssl" and including compromised code. That's a whole different ball game than a bug inadvertently introduced during a backport.
collyw 9y ago
Sure its nice (and easier) to use the distro's package management system, but it often just isn't up to date enough. You end up using thing that are a while out of date and may have security flaws as a result.
- mikeyjk 9y ago
  This is incorrect of rolling release distros. Even Ubuntu is fairly quick to update, which is not a rolling release. CentOS on the other hand can be like pulling teeth. I'm going to be glad to stop dealing with CentOS 6.
  - dagw 9y ago
    Ubuntu is fairly quick to update For popular packages perhaps, but for many more obscure and niche python packages Ubuntu is often a several releases behind, and that is if there even exists a package to begin with
- eeZah7Ux 9y ago
  > using thing that are a while out of date and may have security flaws as a result On the contrary, on distributions that perform security updates the level of security of a package can only increase over time. It might sound obvious but vulnerabilities are created in new releases, while vulns in existing packages can be only be found and fixed, not created. (Of course I'm talking only about vulnerabilities here and excluding removal of obsoleted crypto or addition of new security features)
  - andrewflnr 9y ago
    I would just like to point out that a "fix" for a vulnerability does occasionally introduce others.
pjmlp 9y ago
> Yet another attack vector that doesn't exist at all in Linux distributions but invented by language package managers, sadly. Language package managers solve the problem that we don't have neither an universal package format that works across all programming language requirements and all sort of OSes, nor the time to create an OS specific package for all sort of OSes.
- kasabali 9y ago
  Solving that problem is orthogonal to vetting repositories. There is nothing wrong with inventing their own solution if they're solving other problems, what is wrong is not learning from previous examples and fucking up creating problems that have been already solved in the process.
IshKebab 9y ago
The Linux distribution approach to package management ("we'll package everything ourselves!") simply doesn't scale.
- eeZah7Ux 9y ago
  That's a feature. You want a set of vetted and curated packages you can trust, and you want to receive security updates on them.
  - takluyver 9y ago
    But developers also want a way to get software without getting it blessed by Debian and waiting months/years for a distro release. That's why repositories like PyPI exist and are in very widespread use. Distro repositories are a great example of 'secure for ideal users'. They give you security if you can put up with a small selection of software and older versions. In practice, we end up working around distro repositories by installing stuff with pip, or PPAs, or downloaded from websites.
    - larrykwg 9y ago
      I don't understand why they even try, Debian stable seem to have an almost arbitrary selection of outdated ruby and python libraries, at this point that hardly seems worth the effort. Sure I get the idea, but it obviously doesn't work in practice. Their security methodology also seems heavily flawed, to backport security fixes to older versions is neither scalable nor particularly reliable. I sincerely doubt that Debian can provide adequate security to its almost 50,000 packages. If the security community would invest equal amount of resources that they invest in finding flaws in iOS or Chrome, nothing would be left of Debian but a pile of smoking ashes.
      - ex_amazon_sde 9y ago
        > Debian stable seem to have an almost arbitrary selection of outdated ruby and python libraries Yet Amazon and other big tech companies have a very similar process of packaging open source software for internal use and relying on "outdated" libraries. > I sincerely doubt that Debian can provide adequate security to its almost 50,000 packages. There's a security tracker where you can see how quickly packages are assigned CVEs and patched - sometimes even before the upstream patch is ready.
zokier 9y ago
> Yet another attack vector that doesn't exist at all in Linux distributions but invented by language package managers, sadly Not really, PPAs (and equivalents like copr or obs or aur etc etc) are mostly vulnerable to similar problems. People do want to install upstream software for various reasons, blaming language package managers for the reduced security of that is imho disingenuous.
- kasabali 9y ago
  Read my comment carefully. Though I've used terms loosely you'll see I'm actually talking about package repositories and their inclusion policies.

mikehollinger 9y ago

There's a certain amount of work (and therefore money) required to do this. That incremental difference is small for a well designed application, but - someone must actually vet and curate the contents of the repo. That tends to slow down execution, leading to scenarios where things like docker a year or two ago from the canonical "trusty" repo were hopelessly behind the "real" docker since docker was evolving so quickly and trusty was by design slowing down. Each commit that went into trusty required a team to submit and a team to approve. That costs money. ;-)

kasabali 9y ago
It is a matter of distribution and release policy and not an inherent limitation of the model. Stable/lts/enterprise distributions have other concerns like preventing regressions and configuration or behavior changes during lifetime of release. Rolling distributions like Arch and OpenSuse Tumbleweed on the other hand can move a lot faster but still provide basic vetting wrt security and sanity of new/updated packages.

disconnected 9y ago

> Yet another attack vector that doesn't exist at all in Linux distributions but invented by language package managers, sadly. https://www.schneier.com/blog/archives/2008/05/random_number_b.html https://www.schneier.com/blog/archives/2008/05/random_number... A.K.A., the Debian openssl Fiasco. Just one example of distros fucking up the packages from upstream and causing major havoc.

ex_amazon_sde 9y ago
You are cherry-picking one example involving a library that had a plethora of vulnerabilities from upstream. Contrast it with reviewing and maintaining 50k+ packages, managing thousands of CVEs every year, sometimes even writing security patches before upstream. Also the project pioneered reproducible builds and implemented build hardening for most packages.
- daenney 9y ago
  None of that, nor the good that they have done, negates the fact that distributions can fuck up too. And regardless of whether OpenSSL had a plethora of bugs from upstream, this one wasn't one of them. It was only in Debian, because of changes the project had made. Just because it's packaged in Debian by Debian maintainers doesn't mean you're immune to these kind of issues. They're arguably less likely but you'd need to do a comprehensive study of all packages in the repo to get to some usable statistic.
  - lanstin 9y ago
    So the PyPi issue isn't a bug. It is an attack by hostiles. There are always bugs but this is a person packaging malware probably as a practice to package worse stuff that runs at build time. If package maintainers have time to respond to valgrind reports on their package they have time to check strace on the installer. Edited: longer rant.
    - daenney 9y ago
      > So the PyPi issue isn't a bug. It is an attack by hostiles. Arguably. The issue with typosquatting on PyPi has been known and demonstrated for a long time, but nothing has been done about it. Considering there are ways of closing this attack vector, even though it would require some serious work, I'd consider this a bug. It's just a bug that's being exploited now.
cookiecaper 9y ago
This is a totally different issue. Distro package management isn't perfect, but you don't have to worry about a random malicious individual squatting on "opensssl" and including compromised code. That's a whole different ball game than a bug inadvertently introduced during a backport.

collyw 9y ago

Sure its nice (and easier) to use the distro's package management system, but it often just isn't up to date enough. You end up using thing that are a while out of date and may have security flaws as a result.

mikeyjk 9y ago
This is incorrect of rolling release distros. Even Ubuntu is fairly quick to update, which is not a rolling release. CentOS on the other hand can be like pulling teeth. I'm going to be glad to stop dealing with CentOS 6.
- dagw 9y ago
  Ubuntu is fairly quick to update For popular packages perhaps, but for many more obscure and niche python packages Ubuntu is often a several releases behind, and that is if there even exists a package to begin with
eeZah7Ux 9y ago
> using thing that are a while out of date and may have security flaws as a result On the contrary, on distributions that perform security updates the level of security of a package can only increase over time. It might sound obvious but vulnerabilities are created in new releases, while vulns in existing packages can be only be found and fixed, not created. (Of course I'm talking only about vulnerabilities here and excluding removal of obsoleted crypto or addition of new security features)
- andrewflnr 9y ago
  I would just like to point out that a "fix" for a vulnerability does occasionally introduce others.

pjmlp 9y ago

> Yet another attack vector that doesn't exist at all in Linux distributions but invented by language package managers, sadly. Language package managers solve the problem that we don't have neither an universal package format that works across all programming language requirements and all sort of OSes, nor the time to create an OS specific package for all sort of OSes.

kasabali 9y ago
Solving that problem is orthogonal to vetting repositories. There is nothing wrong with inventing their own solution if they're solving other problems, what is wrong is not learning from previous examples and fucking up creating problems that have been already solved in the process.

IshKebab 9y ago

The Linux distribution approach to package management ("we'll package everything ourselves!") simply doesn't scale.

eeZah7Ux 9y ago
That's a feature. You want a set of vetted and curated packages you can trust, and you want to receive security updates on them.
- takluyver 9y ago
  But developers also want a way to get software without getting it blessed by Debian and waiting months/years for a distro release. That's why repositories like PyPI exist and are in very widespread use. Distro repositories are a great example of 'secure for ideal users'. They give you security if you can put up with a small selection of software and older versions. In practice, we end up working around distro repositories by installing stuff with pip, or PPAs, or downloaded from websites.
  - larrykwg 9y ago
    I don't understand why they even try, Debian stable seem to have an almost arbitrary selection of outdated ruby and python libraries, at this point that hardly seems worth the effort. Sure I get the idea, but it obviously doesn't work in practice. Their security methodology also seems heavily flawed, to backport security fixes to older versions is neither scalable nor particularly reliable. I sincerely doubt that Debian can provide adequate security to its almost 50,000 packages. If the security community would invest equal amount of resources that they invest in finding flaws in iOS or Chrome, nothing would be left of Debian but a pile of smoking ashes.
    - ex_amazon_sde 9y ago
      > Debian stable seem to have an almost arbitrary selection of outdated ruby and python libraries Yet Amazon and other big tech companies have a very similar process of packaging open source software for internal use and relying on "outdated" libraries. > I sincerely doubt that Debian can provide adequate security to its almost 50,000 packages. There's a security tracker where you can see how quickly packages are assigned CVEs and patched - sometimes even before the upstream patch is ready.

zokier 9y ago

> Yet another attack vector that doesn't exist at all in Linux distributions but invented by language package managers, sadly Not really, PPAs (and equivalents like copr or obs or aur etc etc) are mostly vulnerable to similar problems. People do want to install upstream software for various reasons, blaming language package managers for the reduced security of that is imho disingenuous.

kasabali 9y ago
Read my comment carefully. Though I've used terms loosely you'll see I'm actually talking about package repositories and their inclusion policies.