[Catalog-sig] [Draft] Package signing and verification process

[Daniel Holth]

+1 on listening to the computer science professor.


On Thu, Feb 7, 2013 at 9:06 AM, Justin Cappos <jcappos at poly.edu> wrote:

> There are a whole host of subtle problems that you can get into with
> security for package distribution.
>
> For some issues with handling metadata in the presence of a MITM that have
> been fixed in most of the popular Linux package managers:
> http://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf   (extended
> version with more attacks / issues:
> http://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.pdf )
>
> Some of the difficulties with key distribution and revocation for package
> managers:   http://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf
>
>
> We'd like to integrate TUF ( https://www.updateframework.com/ ) into PyPI
> to help out if it makes sense.   In theory the integration should be
> straightforward.   It's basically just importing a few libraries in the
> client tools and asking package publishers / PyPI to do an extra step to
> add signatures.   We believe it should be incrementally deployable (i.e.
> work if not everyone is using TUF everywhere) without being a usability
> problem for anyone.   We're looking into this now to see what sort of
> complications this may have.   We do have some looming deadlines, but we'd
> like to get a demo together later this month.
>
> One issue I'm not sure I understand is whether or not PyPI is trusted to
> know which developer's key is supposed to be signing updates for a specific
> package.  I assume this would be the case, because otherwise I don't
> understand how the user gets this information.  If so, how often does this
> list get updated with new developers / key changes?   (I'm trying to
> understand what sort of key storage is appropriate here...)
>
> Thanks,
> Justin
>
>
>
> On Thu, Feb 7, 2013 at 8:20 AM, Donald Stufft <donald.stufft at gmail.com>wrote:
>
>> On Thursday, February 7, 2013 at 5:32 AM, Jesse Noller wrote:
>>
>> That tutorial would have to be amazingly easy, and GPG could never be a
>> hard requirement. GPG is still annoying, clunky and painful enough that it
>> would just become a nuisance and people would move elsewhere.
>>
>> So adding support? Ok; but it would have to be optional and not
>> mandatory. I'd rather finish the ssl certs first, and get hashes upgraded
>> from md5 to sha-256 and getting clients to enforce those just to start
>>
>> pip will support any of the guaranteed hashes. I added that in because I
>> wanted sha256 on Crate.io.
>>
>> easy_install and Buildout probably need that still.
>>
>> _______________________________________________
>> Catalog-SIG mailing list
>> Catalog-SIG at python.org
>> http://mail.python.org/mailman/listinfo/catalog-sig
>>
>>
>
> _______________________________________________
> Catalog-SIG mailing list
> Catalog-SIG at python.org
> http://mail.python.org/mailman/listinfo/catalog-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130207/1bf4aa1c/attachment.html>