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

[Glenn Andreas]

At 4:18 PM -0400 10/3/03, Bob Ippolito wrote:
>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.

So the database, contained in the plist file of PackMan, contains the 
MD5 (or better) values.

If this file is easy to change, then so it the rest of PackMan, so 
nothing that the user sees when running PackMan can be trusted, 
correct?

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

Though SSL is more than just an encryption mechanism, it also 
provides an authentication mechanism .  But I definitely agree that 
it is easier to compromise a server than aquire a private key.

I'm clearly missing something here, because if we have the databases 
come from a trusted source (python.org) using SSL, we should be able 
to trust that they are correct when we get them (since part of the 
purpose of SSL is so that you know who you are talking to).  If 
nothing changes them, and if the "user experience code" is trusted, 
they should reliably reflect if the packages downloaded from 
non-trusted hosts are valid.

This may require retrieving the database from python.org every time 
that PackMan is run (though if anything can change the databases, it 
can change PackMan or whatever the "user experience code" is that 
verifies the intergrity), but I don't see what more is needed there.

Or is part of the issue the desire to be able to obtain the database 
from a non-trusted host? (Which might as well then be the place where 
the package came from, and so the two might as well be the same).  If 
they are packaged together, whomever signs the database could just 
sign the package (if you trust the signature of the database, you 
should be able to trust it on the package).

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

Exactly - if they trust it for the software in the first place, the 
ought to trust it for further updates.

>
>I might be leaving something small out, but I think that the 
>documents themselves need to be signed.

I'm missing the difference between "each package is signed by trusted 
entity" vs "checksum of all packages is put in a single file that is 
then signed by trusted entity".  After all, in either approach, 
updating it will require that trusted entity resign something.  With 
a signed package, there is no issue of the database being out of date 
(or how versioning works in the database).  If it is an issue of 
"trusted entity has to have entire sources and sign it", couldn't one 
just as easily have a single file with the checksum  signed (and then 
the author of the package would send checksum it themselves and send 
it using some trusted mode of communication to the trusted entity, 
who gives them back the signed version of just that "mini-database")? 
Obviously, that secondary file can't be put in the same 
tarball/archive as the source, since that would change the checksum 
of the archive.

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

Right - eavesdropping on the conversation isn't an issue here, but 
knowing where something comes from is, and that the reason that 
browser-trusted CA's get the big bucks...

-- 
Glenn Andreas                      gandreas at delver.com 
Theldrow, Blobbo, Cythera, oh my!
Be good, and you will be lonesome