Zeronet: please do not depend on python-pip3 - security risk - use dependencies available from distribution package repositories

[adrelanos]

Instructions on Linux currently require to run sudo python3 -m pip install -r requirements.txt. Please consider to drop this if possible.

python pip is a security risk since it does not verify software signatures on packages it downloads. It is also a third party package manager.

Previously a bitcoin wallet was hacked that depended on a third party package manager that didn't verify software signatures.

https://bitpay.com/blog/npm-package-vulnerability-copay/

Could you please use dependencies available from distribution package repositories such as packages.debian.org?

This is also a blocker for ever getting ZeroNet accepted into official packages.debian.org.

This is also a blocker for pre-installation of ZeroNet by default in Whonix.

Related packaging issues:

https://github.com/HelloZeroNet/ZeroNet/issues/382
https://github.com/HelloZeroNet/ZeroNet/issues/241
https://github.com/HelloZeroNet/ZeroNet/issues/1786

[HelloZeroNet]

As far I know bitpay/copay like issue could also happen on any Linux repository: at that case someone took over the maintenance of a no longer maintained package, then commited a problematic code.

After a quick look the only packages that are missing from Debian repo:
bencode.py, coincurve, merkletools

If someone creates package for these, then it should work

[filips123]

I'm against using distribution package repositories. Packages in them are often outdated, take a lot of time to update, and many of them simply aren't available. They also aren't portable.

How would distribution package repositories prevent their developers from submitting malicious version? The same happened with event-stream. It was not because of NPM issue, but because event-stream used dependency by the malicious author which added malicious code. Same can happen with APT repositories.

[imachug]

I was personally attacked and discredited

these people are fascists criminals

:man_facepalming:

[adrelanos]

Filip Š:

I'm against using distribution package repositories. Packages in them are often outdated, take a lot of time to update, and many of them simply aren't available.

It works for thousands of applications available from
packages.debian.org. Among them, popular applcations such as firefox,
gimp, libreoffice, and whatnot.

How would distribution package repositories prevent their developers from submitting malicious version?

Debian developers don't allow malware into Debian. That fortunately
hasn't happened to Debian yet.

[filips123]

It works for thousands of applications available from

But that applications are not written in Python and are not using Python dependencies.

Debian developers don't allow malware into Debian.

NPM and PyPI also don't allow malware. But malicious maintainer of the package can still push it.

[HelloZeroNet]

Among them, popular applcations such as firefox, gimp, libreoffice, and whatnot.

Actually Firefox includes the dependencies inside the package: Just pdf.js (the part they use to display pdf files) has over 200 dependencies that are not installed using apt repository: https://github.com/mozilla/pdf.js
If this is fine, then we could do the same.

[adrelanos]

Filip Š:

It works for thousands of applications available from

But that applications are not written in Python and are not using Python dependencies.

Many python based applications in Debian are using python dependencies
also variable from Debian.

Here is a list of popular python based applications:

https://en.wikipedia.org/wiki/List_of_Python_software#Applications

Among them deludge (bittorrent client) and pip just to pick two examples.

Some of them are available from Debian package sources.

Debian developers don't allow malware into Debian.

NPM and PyPI also don't allow malware. But malicious maintainer of the package can still push it.

This has never happened in Debian yet which has thousands of packages.

[leycec]

Linux ≠ Debian. While popular, Debian-based Linux distributions occupy only a small fraction of the Linux space. Devolving ZeroNet from its current distro-agnostic installation instructions to distro-specific installation instructions makes little to no sense. ^{Mostly, no sense.}

The current distro-agnostic installation instructions are fine. What's not fine is the sluggish pace of package publication by Debian developers – but that's entirely on them. ZeroNet isn't to blame here. When even Gentoo and Arch Linux provide up-to-date packages for ZeroNet, you know that something's wrong with your rolling release model... or lack thereof.

It is also a third party package manager.

pip is the official Python package manager bundled with Python itself. It doesn't get more first-party than that. With respect to Python packaging, it's system-wide package managers like Debian's apt and CentOS' yum that are third-party – not pip.

Relative perspective: it matters.

Could you please use dependencies available from distribution package repositories such as packages.debian.org?

No, because distro-specific package repositories are (wait for it)... distro-specific. ZeroNet would only be installable under Debian-based Linux distributions – a significant regression from ZeroNet's current applicability to all Linux distributions. Does that actually sound like a good idea to anyone in attendance who is not @adrelanos?

If we really want to walk down this road in a sane way, we might consider publishing a distro-agnostic AppImage for ZeroNet. Unlike distro-specific packages, AppImages portably run on all Linux distributions. They also bundle all requisite dependencies in a safe, secure, robust, reproducible manner isolated from any package manager – pip and apt included.

If portability, security, and ease of installation are your concerns, AppImage is your answer. Debian is a non-answer to a question that no one asked.

This is also a blocker for ever getting ZeroNet accepted into official packages.debian.org.

No. The blockers here are Debian developers – not ZeroNet. Again, Gentoo and Arch Linux both publish ZeroNet packages. If the little guys with effectively no funding can do it, the big guys with absurd piles of multinational corporate venture capital absolutely can, too.

This is entirely on Debian. Debian's well-known internal torpor is entirely a Debian issue.

tl;dr

This issue is a non-issue and should probably be closed.

[HulaHoop0]

pip still has no idea about code signing in this day and age. It was conisdered a big leap forward when they implemented fetching over HTTPS and reject plaintext connections which is really sad considering the poor security assumptions that even this would have:

https://github.com/pypa/pip/issues/1167

Here are two different real world cases of malware snuck into PyPi being executed becuase of pip's non existent security:

https://arstechnica.com/information-technology/2017/09/devs-unknowingly-use-malicious-modules-put-into-official-python-repository/

The problem is ultimately the result of developers and administrators who fail to inspect packages thoroughly. Adding to the insecurity, the widely used pip package management system (pictured above), which most Python developers rely on, doesn't require cryptographic signature before executing code when a package is installed.

https://www.zdnet.com/article/twelve-malicious-python-libraries-found-and-removed-from-pypi/

---

Please consider an alternative packaging/installation model that doesn't rely on pip. Either using stuff in Debian backports or just making an AppImage (which includes code that is audited by you beforehand) - Electrum does the latter since their release cycle is far too rapid for it to sync with Debian's.

We really love Zeronet and want to include it in our privacy distro by default, but unless we can have a secure installation mechanism, we just can't do it.

PS. I am only interested in Zeronet dev replies. If you are an enthusiast please express yourself in another thread.

[filips123]

APT by default uses HTTP and there were already vulnerabilities to allow man-in-the-middle attacks (here and here.

Cryptographically signing packages does not prevent their authors to publish malicious packages, which happened in the case of npm and pip.

The only way to prevent this would me to manually review and check every single release of every single package but I don't think this happens on APT either.

Also, distribution package managers are often outdated and take a lot of time to update. Many APT packages do not have their latest version published, even if it exists on other package repositories. This means that we would need to wait a long time to get new features. And sometimes, if you use a bit old distribution, they are just not updated.

And using distribution package managers would require to set things for each of package managers. There are many Linux distributions so this would require a lot of work. Pip, on the other hand, is platform-independent and you don't need to configure packages for each platform separately. And you will still need to use yet another thing for Windows and macOS.

So, distro-specific managers are not a solution. The proper solution is to use distro-agnostic managers (AppImage, Flatpack, Snap) where they are available and continue using Pip where they are not.

[HulaHoop0]

Cryptographicly signing packages does not prevent their authors to publich malicious packages, which happened in case of npm and pip.

Right. What we want to do is ensure no one else, but the package author has modified its code.

The transport layer security is a nice plus in case the package manger itself has a RCE bug, but this is besides the point for code integrity.

I guess we are on the same page about AppImage which is a good sign. We know how to deal with those and they suit us.