Hacker News Reader

Comment by kasabali | Hacker News Reader

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.

View on HN

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. ;-)

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.

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

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.

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.

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.

> 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.

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.

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.

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

> 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)

I would just like to point out that a "fix" for a vulnerability does occasionally introduce others.

> 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...

A.K.A., the Debian openssl Fiasco.

Just one example of distros fucking up the packages from upstream and causing major havoc.

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.

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.

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.

> 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.

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.

> 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.

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

> 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.

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.

Reply on news.ycombinator.com