[Distutils] setuptools: package management and explicit version numbers

[Phillip J. Eby]

At 09:39 PM 8/11/2005 +0100, Paul Moore wrote:
>PS I will make one comment - I really do think that ez_setup should
>have an option to disable downloads. When I tried installing the
>PyProtocols egg, ez_setup happily grabbed the setuptools egg off the
>web, installed it, and ran code from it. I know it needs to, but
>that's a huge security risk - I'm not particularly obsessed by
>security, but even I found that a bit scary.

Note that you can trivially prevent this behavior by ensuring that you 
always have the latest setuptools egg on your machine ahead of time.  ;)

Also note that when you run *any* setup script, it already has the 
opportunity to execute arbitrary code on your machine, and could download 
whatever else it wanted to anyway, so I consider this mostly a non-issue, 
securitywise.  Even reading the setup script source doesn't help; a 
malicious author (or tamperer) could easily bury the evil code in a 
seemingly innocuous import deep in the code being distributed.

Anyway, what I could possibly do for the setuptools egg itself is start 
building up a table of MD5 hashes in ez_setup.py to allow verification of 
the downloaded egg.  ez_setup isn't part of the egg, so I could maybe do 
that with an external tool of some kind.  Of course, the list of hashes 
would get ever-longer with each release, and it wouldn't work for 
installing new versions of setuptools with an older version of ez_setup.


>Arguably, no-download
>should be the default, and auto-download should be the optional
>behaviour.

Not really.  The entire point of ez_setup is to make the process 
hands-free.  I'm fine with trying to make it more tamper-proof in case of a 
compromise of python.org or your personal network connection, but if one of 
those was compromised, who's to say that ez_setup itself wasn't compromised 
too?  Or the code you're installing?  At some point, you're just plain 
screwed, and installing things by hand isn't actually an improvement unless 
you're going to personally vet every single line of code or have a 
signature whose certificate chain you trust.  And once we have such 
signature chains available, then easy_install can become just as capable of 
validating them as you are.

But even then, it will likely be a false sense of security, because I 
expect that 1) most authors won't bother to sign their packages to start 
with, and 2) of those that do, most will likely use self-signed 
certificates, so knowing what signatures are "valid" will be difficult.  If 
you have no way to know if a particular cert is really the author's, then 
you are right back to square zero.  That is, if you trust the source of the 
package enough to run its setup script in the first place, you're trusting 
them to run arbitrary code on your computer.

So, if the package author wants to download and install the package's 
dependencies, at that point you're just quibbling over details; you already 
gave them permission to do as they wish with your machine.  At least when 
you install their code as a pre-built egg you don't have to run any code 
you don't want to, and easy_install runs source package setup scripts in a 
sandbox to prevent ill-mannered (but not malicious) setup scripts from 
throwing crap on your system wherever they want to.  (And yes, such setup 
scripts *do* exist, which is what prompted me to add the sandboxing code.)

I think that in the long-enough-run, we'll solve the cert chain problems 
through social means, and eventually signing PyPI uploads will be de 
rigeur.  But at the moment, most package authors can't be bothered to fill 
out all their PyPI metadata and links or upload their packages to PyPI, so 
it's not realistic to expect there's going to be much signature support out 
there any time soon.  (Ignoring also issues like projects already married 
to SourceForge or other download systems that don't have an easy way to 
distribute the signatures.)

And without those signatures, your hand-installation procedure provides you 
with *zero* additional security unless you're personally inspecting every 
single line of code you install.  Heck, you're running downloaded .exe 
files with unsigned code, for heaven's sake!  And you're worried because 
ez_setup downloads the setuptools egg?  Crikey.  :)

(Of course, as with anything else, I could be completely off-base here, and 
I'm sure someone here will straighten me out if I am.)