[Catalog-sig] [DRAFT] Proposal for fixing PyPI/pip security
Giovanni Bajo
rasky at develer.com
Sun Feb 10 15:45:02 CET 2013
Il giorno 10/feb/2013, alle ore 15:32, Justin Cappos <jcappos at poly.edu> ha scritto:
> So we obviously have egg on our face about the domain expiry. Our sys admin should be fixing this now.
>
> I'm a bit crunched for time with other deadlines right now, but one quick thing I'd like to correct is that TUF works with package managers / metadata, etc. TUF certainly handles package managers and appropriately protects their metadata, which in turn makes sure that dependency resolution is secure, etc.
It's a word issue. "TUF handles package managers" means that it can be applied to, but (as per your previous mail) you don't have a ready solution for handling the trust issue with (distributed) package managers. That's a hairy issue, because you have thousands of people that can release software, and you need a way to convey the trust to the end user running the installer.
I'm not saying that TUF can't *eventually* handle it; I'm saying that it's sort of outside the current TUF scope, so it needs a custom design for integration with PyPI. It's not a drop-in; there is no "let's commit TUF and call it a day". We still need to agree and work on the design of such integration.
> TUF does also prevent against replay attacks on old package versions (or at least those that were not valid within the lifetime of the timestamp.txt file and aren't earlier than the last time the user fetched a package.)
That's correct, but it is ineffective in the context of PyPI where showing/hiding a version of the package can be done simply with the user password on the web interface, thus completely bypassing the signing model that TUF is based upon. A naive integration of TUF would have the PyPI server signs the timestamp.txt based on what the maintainer configured in the web interface. So an attacker that has compromised the PyPI credentials of a maintainer, can still perform a replay attack.
Generally speaking, TUF doesn't take into account the existence of the (weak, password-based) PyPI credentials, which are necessary for a distributed package manager where, at any time, anybody can add a new package to PyPI. So, a full integration of TUF would need to redesign the access levels gained with the PyPI access credentials.
This is what I was saying with: "an integration of TUF doens't "magically" fix the replay attack of older versions, unless we also specifically modify distutils to include package management administrative commands to it, with GPG validation/signing, and we expose the corresponding webserver API from PyPI. We still need a design here."
> I'll be happy to give a detailed look at the other proposal before PyCon and send some notes. (Unfortunately I have a conflicting venue I need to attend so will miss PyCon.)
Thanks!
--
Giovanni Bajo :: rasky at develer.com
Develer S.r.l. :: http://www.develer.com
My Blog: http://giovanni.bajo.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130210/96f73629/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4346 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130210/96f73629/attachment.bin>
More information about the Catalog-SIG
mailing list