[Distutils] setuptools: package management and explicit version numbers

[Ian Bicking]

Phillip J. Eby wrote:
>> 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.

I think from a make-people-feel-comfortable perspective, it might be 
better if ez_setup informed the user of what it's doing (installing a 
build dependency) and get a confirmation.  For instance, it can be 
disconcerting to do something that shouldn't require any privilege 
(e.g., setup.py --help-commands) and end up triggering something that 
does require privilege (global installation of a package).  Just an "I'm 
going to do this; OK?" question would be reassuring.

> 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.  :)

Realistically it's very hard to do coordinated attacks; it's as things 
get automated that larger holes can become exploitable and dangerous. 
One scary one is if someone uses a Wiki page as a package index, and 
other people reference that without understanding the (considerable) 
danger.  I *almost* did that myself, then I thought again and realized 
what a bad idea it would be.

But anyway, I think lots of attacks can be foiled by checking 
consistency.  E.g., check the file you downloaded against an MD5 
checksum stored elsewhere.  This doesn't prevent someone from uploading 
a completely bogus file, if they are able to get access to someone's 
PyPI account, for instance.

But other layers of consistency are possible.  For instance, for a 
package to be "trusted" by PyPI (on some level), maybe an email 
confirmation of substantive package updates would be required (like new 
releases, new versions of files, etc).  This is just another consistency 
check -- make sure that the person on the other end of the registered 
email address approves what the person with the login account is doing 
(of course usually those are the same person).

Anyway, those are just a few idea off the top of my head.  I find 
cryptographic standards of security can be a little misguided at times. 
  When I read this article I found it to be a quite refreshing way to 
think about security: http://iang.org/ssl/wytm.html

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org