[Pythonmac-SIG] Package Manager idea, adding a URL scheme

[Bob Ippolito]

On Friday, Oct 3, 2003, at 15:08 America/New_York, Glenn Andreas wrote:

> Taking a step back here for a second, I think we're confusing a couple 
> of things (at least different people seem to have different underlying 
> assumptions/ideas/points of view here).
>
> When talking security, you need to define what it is that you are 
> trying to secure in the first place, and what do you trust and what is 
> beyond your control (and untrusted).  It's not clear that we've done 
> that yet...

 From my perspective:
	PackMan, or the user of PackMan, should trust the scapegoat.  The 
scapegoat is the maintainer of a given PackMan database (plist file, 
currently).
	Currently, if you trust the PackMan database, you can trust its 
contents because every tarball (whether hosted at a trusted site or 
not) is tagged with md5.
	It is easy to attack this method by changing the plist file and 
potentially changing the contents of the tarballs.  It's trivial to 
update the md5 hashes to look authentic.

> Is PackMan "trusted"?  For example, are we trying to address "what if 
> PackMan is compromised"?  Because if it can be compromised, and we are 
> assuming it was trusted in the first place, all the other layers of 
> authentication, signatures, certificates, etc... are probably 
> meaningless.
>
> I think the whole idea is to let the user "know" if the package that 
> they just installed is really what they think they just installed, 
> especially if it came from an untrusted host (e.g., I installed 
> package Foo from Foobar.com, but want to make sure nobody hacked 
> Foobar.com and installed an incorrect version of the Foo package), 
> right?
>
> Certainly if we want to make sure that PackMan is trusted (and remains 
> so), running any sort of code from Foo to get a version number would 
> allow PackMan to become compromised.
>
> It is probably reasonable to assume that SSL is trusted (so a 
> previously mentioned "man in the middle" attack shouldn't be possible 
> with SSL), but is it reasonable to assume that your web-browser is 
> trusted?  If PackMan is trusted (and URL access or WebKit support it), 
> could it just do SSL itself?

PackMan doesn't really use a web browser at all.  Besides, if their web 
browser was compromised then they're already screwed.  Compromised 
users do not effect the security upstream.

> If we look at PyCrypto, this would require that whatever used it be 
> "trusted" (since otherwise something could subvert the authentication 
> process and just fake the call to PyCrypto and return "why, yes, it is 
> valid").  This really would require that whatever told  the user that 
> it was an authentic Foo package never run any code from Foo to get the 
> version number.

If the user's computer is compromised with a false version of PyCrypto, 
they've already lost and there is nothing we can do for them.  Again, 
compromised users don't effect security upstream.

> On the other hand, if PackMan were trusted (as were the MD5 modules), 
> do a simple MD5 checksum of the package, and then getting the 
> "official" checksum from a trusted host (python.org) with a trusted 
> transport mechanism (SSL) and comparing them should be sufficient 
> (though something a bit stronger than MD5 might be desirable).

An encrypted transport mechanism is not sufficient.  Anyone can setup a 
SSL web server, not anyone can get a certificate signed by a particular 
CA (i.e. one of the big nasty CAs that browsers trust by default, or an 
official Python.org CA).  There has to be a trusted public key 
somewhere to do anything more than hide communication from an 
eavesdropper.  Transport encryption is looser than cryptographic 
authentication because presumably it's easier to compromise a server 
than to acquire the private key of the scapegoat (which usually means 
the server can be compromised, anyways).

Anyways, here's what I see as a good enough solution:
	- PackMan ships with the URL and scapegoat public key of at least one 
PackMan database (for convenience)
	- PackMan databases are cryptographically signed for authentication 
purposes
	- User downloads a PackMan database
	- If user has pycrypto installed:
		- pycrypto verification of cryptographic signature is performed
			- if failed: warn user (allow them to notify scapegoat?)
			- else: no warning, maybe put a "padlock" somewhere
	- else:
		- warn user that the source can not be authenticated, please install 
pycrypto ASAP. maybe put an "obviously unlocked padlock" somewhere

When downloading a package, before installation:
	- Database has sha-1 of the tarball already (was it md5?  I don't 
remember.. sha-1 is the way to go these days, anyways)
	- Tarball gets downloaded
	- Compare database hash with actual hash of file:
		- if failed: warn user, allow them to continue anyway if they really 
want to (and option to notify scapegoat)
		- else: go ahead and install, no warnings

To add new trusted databases to user's PackMan:
	- PackMan has a UI option to add a URL with a public key that they can 
copy + paste from a website (and maybe a checkbox to blindly trust 
without the public key)
	- Python.org has a SSL certificate, which the user can inspect + 
verify from their browser if they choose, and the python.org website 
will have a page so that users can copy and paste the public key and 
URLs from PackMan databases that Python.org trusts (its own, maybe 
mine? :)
	- This public key + URL doesn't necessarily have to come from 
Python.org, but the users of Python will probably trust these (since 
they're trusting software that they acquired from python.org already).

I might be leaving something small out, but I think that the documents 
themselves need to be signed.  The transport encryption is completely 
redundant and the only use for SSL would be for the certificate, 
because presumably a browser-trusted CA would not sell a SSL 
certificate to someone posing to be python.org with the same 
information as the real certificate (which would've been previously 
issued in their database).

-bob