[Distutils] PEP draft on PyPI/pip package signing

Tue Jul 29 00:22:55 CEST 2014

So, I think Vlad covered the status of the implementation side well.

We've also done some work on the writing / doc side, but haven't pushed
fixes to the PEP.   We can (and should) do so.   We have an academic
writeup that speaks in more detail about many of the issues you mention,
along with other items.   We will make the revised documents easier to find
publicly, but let me address your specific concerns here.

 * what a maintainer is supposed to do to submit a new signed package

A maintainer will upload a public key when creating a project.   When
uploading a package, metadata is signed and uploaded that indicates trust.
  Our developer tools guide (
https://github.com/theupdateframework/tuf/blob/develop/tuf/README-developer-tools.md)
is meant to be a first draft at this document that answers any questions.

There will also be a quick start guide which is just a few steps:

generate and upload a key
sign metadata and upload it with your project

 * how can differ maintainers signal that they both maintain the same
package

A project can delegate trust to multiple developers.   Depending on how
this is done, either developer may be trusted for the package.   The
developer tools guide shows this.

 * how the user interface of PyPI will change

We're open to suggestions here.   There is flexibility from our side for
how this works.

 * what are the required security maintenance that will need to be
regularly performed by the PyPI ops

Essentially, the developers need to check a list of 'revoked claimed keys'
and ensure that this list matches what they will sign with their offline
claimed key.   This is also detailed in the writeup.

Giovanni: TUF retains security even when PyPI is compromised (including
online keys).   I didn't have time to read the latest version of your
proposal, but from what I understand what is proposed will have problems in
this scenario.

Justin

On Mon, Jul 28, 2014 at 6:13 PM, Vladimir Diaz <vladimir.v.diaz at gmail.com>
wrote:

> Hi, I'm Vladimir Diaz and have been leading the development of the TUF
> project.
>
> > 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.
>
> The implementation of TUF is not really evolving, unless you mean that it
> has been updated to improve test coverage and add a minor feature.   The
> code is available and ready for use.  In fact, it is about to be deployed
> by the LEAP project https://leap.se/en.
>
> We've largely heard that the integration of TUF (with any necessary
> changes by Donald) will happen once Warehouse is further along.  I have
> helped a bit with the Warehouse migration (unrelated to TUF) and will put
> in more time in the next few months.  We are ready to integrate TUF into
> Warehouse once we have the green light from Donald.
>
>
> On Mon, Jul 28, 2014 at 11: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
>>
>>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140728/9e05feb9/attachment.html>