[Pythonmac-SIG] Package Manager idea, adding a URL scheme
gandreas at delver.com
Fri Oct 3 17:21:39 EDT 2003
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
> 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,
>>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
>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
> - 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
> - 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
>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
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
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
More information about the Pythonmac-SIG