[Pythonmac-SIG] Package Manager idea, adding a URL scheme
bob at redivi.com
Fri Oct 3 16:18:17 EDT 2003
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, 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
> 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),
> 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
- 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
- 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
- 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).
More information about the Pythonmac-SIG