[Distutils] PEP draft on PyPI/pip package signing

M.-A. Lemburg mal at egenix.com
Mon Jul 28 21:43:30 CEST 2014


Hi Giovanni,

this sounds like a good proposal. I only have one nit with it:
GPG signing should not be made mandatory for package authors,
but instead just be encouraged.

Not everyone is happy with the way GPG works, or want to maintain
their private keys and it's illegal to use / can cause problems in
some countries:

    http://www.cryptolaw.org/cls-sum.htm

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 28 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/


On 28.07.2014 17:01, Giovanni Bajo 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# 
> 
> 
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
> 




More information about the Distutils-SIG mailing list