I recently started migrating my organization from localshop to devpi, which seems to be a much more active project. Thank you to everyone who has and continues to contribute.

I'm worried about what I consider a security risk when using devpi as a repository for private python packages, using pypi.python.org as the attack vector. I'd like to start a discussion with this community with the hopes of determining if my fear is well founded, and what possible solutions we can implement going forward.

If a legitimate package x is uploaded to a private devpi index at version n, and an illegitimate package x is uploaded to pypi.python.org with a version >n, then it is possible that your deployment scripts, or setup.py of packages dependent on x will install the illegitimate package instead of the intended package. All the attacker would need to know is the package name, and possibly the version depending on how strict your dependencies are defined to pwn your system.

I have thought of two possible solutions to this problem, the first being secure by default and the second insecure by default, but at least security is possible.

Secure By Default

Simply don't use inheritance on packages that exist in the child index. If x exists in child index then don't include x from the parent index. I haven't used a complicated inheritance scheme, and I don't know if others are, but this could be reduced to only excluded packages from root/pypi. This is also the simplest solution, but also could be disruptive depending on how you are using devpi. I can't think of a case when I personally would want both root/pypi and my private versions of a package included in the same index, but that's not to say it's not a valid use case for others. Valid permutations of this solution would be allowing inheritance of existing packages to be toggled per index.

This is the solution I'd like to see implemented. I actually have a (probably insufficient) implementation of this solution at https://bitbucket.org/doki_pen/devpi. The change is very simple.

Secure By Configuration

The other idea is less elegant and harder to implement, blacklisting inherited modules per index. This would involved extending the api to allow modules to be added to and removed from the blacklist on a per index bases. The advantage to this solution is that it would be less disruptive to any existing implementations of devpi.