[Distutils] setuptools: package management and explicit version numbers
ianb at colorstudy.com
Fri Aug 12 01:09:59 CEST 2005
Phillip J. Eby wrote:
>> Arguably, no-download
>> should be the default, and auto-download should be the optional
> 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
More information about the Distutils-SIG