PyPI is a third-party software repository for Python packages. Everybody can upload packages to it (see The Python Package Index (PyPI)).

  • How does PyPI prevent people from uploading malware?
  • When I am searching for software, how can I be (more) sure that it is not malware?
  • What can I, as a developer of packages, do to make others feel safer using my packages?
  • Are there "historic" examples of malware in the repositories? How much harm did they do?

I've asked the question for PyPI, but I'll also be interested in similar repositories like npm (JavaScript) or composer (PHP).

I have asked this question for CTAN (tex) in the tex.SE chat. The answer was there are no security measures. They trust people / developers not to upload malware.


I actually wrote a blog post on this topic recently.

To answer your points:

How does PyPI prevent people from uploading malware?

It doesn't. Any Python code can be uploaded. Arbitrary code execution is possible during package installation. Audit your dependencies carefully.


Download the tarball and look at the code.

What can I, as a developer of packages, do to make others feel more save using my packages?

If your users trust you, PyPI works perfectly fine. Packages are served over HTTPS and checksums are available to verify against.


I'm not aware of any historic examples but I can easily upload a demo package. PyPI doesn't do anything to prevent this. It acts as a simple index of Python packages, it is up to the users which developers they trust.

  • 2
    Downloading the source code and checking it is not realistic. Think of numpy / scipy. They are HUGE. It would take me weeks to check them. I could, of course, check "easy" malware checks like grepping for 'http' to check if they call websites, but I guess (hope) there are more sophisticated automatic ways to check packages. – Martin Thoma Jan 16 '15 at 13:31
  • 1
    @moose There isn't. It's either audit your dependencies or place your trust on the developers. – user10211 Jan 16 '15 at 13:32
  • 2
    @TerryChia and trust the developers own operational security and the security of the people running the repos, and the background of new developers on the project. . . – Rory McCune Jan 16 '15 at 13:33
  • @RоryMcCune Well, yeah. Computers are broken. Nothing new there. – user10211 Jan 16 '15 at 13:34
  • 1
    The link is broken. – Martin Thoma Jan 12 '17 at 13:02

There are two threat models here:

  1. Malicious developer uploading malicious packages
  2. Malicious attacker uploading malicious packages that belongs to legitimate developers

PyPI does not make any attempt to try to resolve #1. Auditing code before installs and only installing packages from reputable developers are the only "protection" you have against these. If you found malicious package, you can report it to PyPI maintainers and the package will probably get removed. But effectively, there's no protection against it as PyPI packages are not pre vetted before they are available for installs.

On the second threat model, there are a number of security measures. Newer version of PyPI downloads packages over HTTPS, and packages can optionally be GPG signed. There are proposals to implement theupdateframework (tuf), though I don't know how far that they have gone to.

Installing to your user packages or virtualenv can limit the damages that malicious package can have, by limiting the installer to not use sudo during install. But don't rely on it too much.

  • 1
    3. malicious attacker grabbing a package name similar to a very popular one (i.e. adding/removing a dash from the package name, or feasting on common spelling mistakes... a package that installs in the hundred-thousands could yield hundreds of infections...) – user40660 Nov 4 '16 at 2:15

As far as I'm aware, in general there are very limited assurances around the code available from online code repositories (e.g. rubygems, npm, nuget, PyPI etc). In a lot of cases they don't support or enforce things like signed code or other integrity based security measures and authentication to the sites to deploy is, in some case, just a username/password combination, so you're reliant not only on the developers not deliberately placing malware in their code but also that those developers have good operational security practices.

An even larger problem is that in a lot of cases the libraries you install have dependencies, in some cases a large number of dependences, so you are reliant that the developers of those dependencies also are not malicious and have good security practices.

As Terry says with many code libs there are hooks to execute arbitrary code on installation (before the library is even used) so just the act of installing can have bad consequences, especially if done as a privileged user.

In terms of historical instances of compromise, well there was the Rubygems compromise in 2013 as an example of a repository being attacked.

In terms of fixing the problem, well there's the Update Framework initiative to try and improve the situation.

Your Answer

