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

[Bob Ippolito]

On Friday, Oct 3, 2003, at 17:21 America/New_York, Glenn Andreas wrote:

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

Yes but AFAIK you can't get to this information without M2Crypto or 
some other OpenSSL wrapper.  The SSL certificate authentication 
mechanism, in my opinion, should be for the user's eyes to trust when 
they look at a page containing the public key and URL of a particular 
PackMan database.

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

But using a cryptographic signature on the PackMan database is a little 
more secure, and is much easier and less expensive than SSL.  I think 
the SSL trusted site should be used to acquire public keys and 
locations for PackMan databases that should be trusted.  After the 
public key is acquired safely, the user can download the PackMan 
database files from untrusted communication channels because they can 
verify whether the person who signed it is who you think it is.

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

The database has to be retrieved every time PackMan is run to check for 
new packages.

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

We don't need to sign packages because we are signing the database, and 
the database has hashes.  But yes, it would be very nice to obtain 
PackMan databases through insecure means and verify their authenticity. 
  We should definitely do this.

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

Yes but a PackMan database doesn't have to come from python.org, 
therefore it is not trusted by PackMan by default (even if it is 
through SSL).  Only the official PackMan database, and perhaps any 
databases it explicitly trusts, are to be trusted by the PackMan 
client.  For example, the PackMan website ( 
http://www.python.org/packman/ ) currently links to my PackMan 
database.  In the future, the PackMan website would also have the 
public key for my database, such that once you retrieve my database you 
will be able to verify that I was the last one to modify its contents 
because I will have signed it.

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

Each *PackMan database* is signed by a trusted entity.  Not all PackMan 
databases will be hosted at python.org, such as mine.  Not all PackMan 
databases, whether on python.org or not, will be maintained by the same 
scapegoat either.  There is no need to sign tarballs, as they can be 
verified by hash from the PackMan database.

Package authors are not directly involved in this process.  It's up to 
a "platform scapegoat" to maintain the binary distributions for each 
package.  However that happens is not part of the PackMan system, we're 
not trying to get too complicated.

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

Exactly.  We only need one host to be trusted by the big boys, which 
will host public keys for the rest of them (the ones that are trusted 
to some degree by the python.org team).  Trusting anything else should 
be up to the user's explicit discretion.

I have a SSL certificate and server that is trusted by the big boys at 
https://pythonmac.org/ which I will host for as long as is needed (and 
then some, probably) :)

Does Camino or Safari even let you read a SSL certificate?  I 
distinctly remember being able to look at them with some browser at 
some time.. I can't figure out how to do it with either of these though.

-bob