[Distutils] PEP draft on PyPI/pip package signing

Noah Kantrowitz noah at coderanger.net
Mon Jul 28 21:19:44 CEST 2014

To be clear, this adds literally no security. It adds some developer experience improvement in that you could do releases securely even while PyPI is unreachable. This has been repeatedly stated as cute but not a huge priority for PyPI. Our uptime has been good enough for the last several years that this doesn't address enough of a niche to be worth the _massive_ increase in complexity. Any solution like that involves both online keys and an RBAC/trust list distributed from PyPI will share these properties. Adding offline keys puts you back in the realm of TUF, and does potentially add some security benefits, though they are way way down the long tail. Overall strong -1.


On Jul 28, 2014, at 8:01 AM, Giovanni Bajo <rasky at develer.com> wrote:

> Hello,
> on March 2013, on the now-closed catalog-sig mailing-list, I submitted a proposal for fixing several security problems in PyPI, pip and distutils[1]. Some of my proposals were obvious things like downloading packages through SSL, which was already in progress of being designed and implemented. Others, like GPG package signing, were discussed for several days/weeks, but ended up in discussion paralysis because of the upcoming TUF framework.
> 16 months later, we still don’t have a deployed solution for letting people install signed packages. I see that TUF is evolving, and there is now a GitHub project with documentation, but I am very worried about the implementation timeline.
> I was also pointed to PEP458, which I tried to read and found it very confusing; the PEP assumes that the reader must be familiar with the TUF academic paper (which I always found quite convoluted per-se), and goes with an analysis of integration of TUF with PyPI; to the best of my understanding, the PEP does not provide a clear answer to practical questions like: 
> * what a maintainer is supposed to do to submit a new signed package
> * how can differ maintainers signal that they both maintain the same package
> * how the user interface of PyPI will change
> * what are the required security maintenance that will need to be regularly performed by the PyPI ops
> I’m not saying that the TUF team has no answers to these questions (in fact, I’m 100% sure of the opposite); I’m saying that the PEP doesn’t clearly provide such answers. I think the PEP is very complicated to read as it goes into integration details between the TUF architecture and PyPI, and thus it is very complicated to review and accept. I would love the PEP to be updated to provide an overview on the *practical* effects of the integration of TUF within PyPI/pip, that must be fully readable to somebody with zero previous knowledge of TUF.
> As suggested by Richard Jones during EuroPython, I isolated the package signing sections from my original document, evolved them a little bit, and rewritten them in PEP format:
> https://gist.github.com/rasky/bd91cf01f72bcc931000
> To the best of my recollection, in the previous review round, there were no critical issues found in the design. It might well be that TUF provides more security in some of the described attack scenarios; on the other hand, my proposal:
>  * is in line with the security of (e.g..) existing Linux distros
>  * is very simple to review, analyze and discuss for anybody with even a basic understanding of security
>  * is much simpler than TUF
>  * is a clear step forward from the current situation
>  * cover areas not covered by PEP458 (e.g.: increasing security of account management on PyPI)
>  * can be executed in 2-3 months (to the alpha / pre-review stage), and I volunteer for the execution.
> I thus solicit a second round of review of my proposal; if you want me to upload to Google Docs for easier of commenting, I can do that as well. I would love to get the PEP to its final form and then ask for a pronouncement.
> I apologize in advance if I made technical mistakes in the PEP format/structure; it is my first PEP.
> [1] See here: https://docs.google.com/a/develer.com/document/d/1DgQdDCZY5LiTY5mvfxVVE4MTWiaqIGccK3QCUI8np4k/edit# 
> -- 
> Giovanni Bajo   ::  rasky at develer.com
> Develer S.r.l.  ::  http://www.develer.com
> My Blog: http://giovanni.bajo.it
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140728/b07243e0/attachment-0001.sig>

More information about the Distutils-SIG mailing list