[Catalog-sig] A modest proposal for securing PyPI with TUF

[Justin Cappos]

Yes, Nick's suggestions are good ones.

I'd agree that getting an initial deployment together that doesn't include
things like custom metadata is probably for the best.   We can certainly
add things incrementally.

Thanks,
Justin




On Thu, Mar 14, 2013 at 3:21 AM, Trishank Karthik Kuppusamy <
tk47 at students.poly.edu> wrote:

> On 3/14/13 3:03 AM, Nick Coghlan wrote:
>
>>
>> I think what you currently propose (signing the metadata pip already
>> understands) is a good first step, especially if we can have PyPI
>> signing *all* the target metadata in the initial deployment, and defer
>> the delegation to package developers until the next phase of the
>> rollout (we obviously want to do that eventually, but it's easier if
>> we can get a preliminary version working without needing to change the
>> upload tools).
>>
>> While such an approach doesn't immediately give us the end-to-end
>> security we ultimately want to set up, it means a few things become
>> possible:
>> 1. Rather than requiring every developer to start signing end-to-end
>> metadata immediately, we can ask a few major projects (e.g. Django,
>> Zope, NumPy) if they're willing to serve as guinea pigs for the
>> developer target signing delegations. Once we're happy the signing
>> process is usable, we can make it generally available as an option to
>> projects (while also allowing them to continue with PyPI's existing
>> upload mechanisms and only offer PyPI-user integrity checks rather
>> than developer-user)
>> 2. Gives the PSF infrastructure team and the PyPI maintainers a chance
>> to work with the installation tool developers to get the PyPI-user
>> link sorted out, before needing to work on the developer-PyPI link
>> 3. Considering alternate mirroring solutions based on replicating the
>> TUF metadata rather than PEP 381
>>
>> Eventually I would also like to tunnel a subset of the PEP 426
>> metadata through TUF's "custom" fields, but again, I think we're
>> better off skipping that for the first iteration. Incremental
>> enhancements are a good thing :)
>>
>
> This sounds good to me --- I like the idea of incremental enhancements.
> Justin, what are your thoughts from a security perspective?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130314/5b760105/attachment.html>