Proposal: introduce a required flag to trigger installation from a package index

[mitchellrj]

Currently, the pip install command accepts either a local path (absolute or relative) as an argument, or the name of a package to be retrieved from a package index, defaulting to PyPI.

I propose that a new flag be introduced to indicate that the argument should be interpreted as a package name to be retrieved from a package index.

Consider the situation where a user mis-types:

sudo pip install src

where there is no src directory relative to the user's current working directory. This will trigger pip to fetch the package named src from PyPI and run its setup script with root privileges.

Forcing the user to instead type:

sudo pip install -pi foo

to install a package from a package index and only allowing the previous usage to install packages from the local filesystem eliminates this potential security risk.

Making a similar change to require a flag for local installation introduces a similar risk that the user forgets to use the flag and the remote package is still downloaded and run. Introducing a flag for installation from a package index means that even if the user omits the flag, the worst case scenario is that they install something from their own filesystem.

I have raised a similar issue for setuptools.

TL;DR: Package managers should never download & run remote code just because a user mistypes a filename.

[pfmoore]

-1. The main use case for pip is to install packages from PyPI. Installing local packages is secondary (but important, obviously). Making users add a mandatory flag for the key use case is not practical.

The real mistake here is careless use of sudo. While it's fine for pip to help reduce the risks involved in such mistakes, ultimately it's not pip's problem.

It may, I guess, be an option to require the flag when pip is running as root. That seems confusing to me, as just adding "sudo" to an otherwise working command isn't sufficient, but I'm not a Unix user so I'll defer to them on what is reasonable for that environment.

[mitchellrj]

Regardless of sudo usage, even running potentially untrusted, unknown code as the current user is dangerous. Being one typo away from having all your documents erased should be avoidable.

[mangecoeur]

-1 The main use of pip is to install from Pypi. By definition, if you install something from Pypi you implicitly place a level of trust in it. If you are worried about running the wrong remote package because you typed in the wrong name, then this problem exists whether you have an extra flag or not.
Perhaps it may make sense to have an install-local command or something to guarantee you don't download anything when you didn't intend to.

[dstufft]

So, I am -1 on mandating a flag just to install from PyPI for the reasons that @pfmoore and @mangecoeur have already stated.

The only thing I could see us actually doing is taking a leaf out of apt-get's book and once we've decided everything we're going to install is prompt the user and say "hey here's what were going to install, is that OK?" along with a -y flag to pre-accept that we're going to do that. I think that's kind of a nice thing to do in general so that we don't modify a users system without making sure it's OK (Including removals for upgrades and the like).

However even the above won't provide the kind of safety that this ticket is asking for because in order to build a dependency graph we need to execute the setup.py. It would provide that kind of safety when only using Wheels (or a future hypothetical sdist 2.0) but not today.

[mitchellrj]

I think @dstufft's suggestion is certainly a reasonable one that would move this in the right direction, if not solve it completely.

[Ivoz]

Being one typo away from having all your documents erased should be avoidable.

Hell's bells, could you be any more alarmist? There are not a million packages all with names subtly misspelled from popular PyPI packages that are exclusively designed to rm -rf ~/*.

The fact that you are running user-contributed code coming from the wider community (or whoever) is part of the core design of PyPI; and npm, and rubygems, and cabal, and every other language's user package repo in existence. This isn't potentially untrusted, it is untrusted. You have to review it yourself, because it's from someone else who you haven't paid a dime to do The Right Thing™ (for whatever your definition of that is). That's just the deal.

If you don't wish to run untrusted code I suggest you move away from using pip at all, and either stick to distribution package managers or disconnect from the internet.

In the mean time, you might also be interested to hear that we plan to move pip away from requiring a user using a system python to run pip with sudo, by making the --user flag enabled by default.

[mitchellrj]

Yes, it's a extreme, corner-case example. Even if packages are not malicious is it still not worth warning the user that what they are attempting to do is likely not their true intent, or help preventing error in some way?

As a side note: you don't necessarily have the right to review code from PyPI yourself - there are plenty of closed-source binary distributions available through it.

[Ivoz]

Even if packages are not malicious is it still not worth warning the user that what they are attempting to do is likely not their true intent, or help preventing error in some way?

The problem is accurately guessing a "true intent" in the first place. If you have a specific case where you think pip could be issuing a warning that it currently doesn't that would be helpful, we'd love to hear it.

As a side note: you don't necessarily have the right to review code from PyPI yourself - there are plenty of closed-source binary distributions available through it.

Yes, although it's perfectly possible to download any distribution from PyPI before executing it (and look at it, if its easily unpackable), PyPI does not place any restriction on the license under which users must upload their package (apart from, implicitly afaik, allowing for its distribution by PyPI...). I don't see this changing.

[dstufft]

I'm going to close this, I don't think we'll ever implement it and a number of maintainers are against it.