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

[Justin Cappos]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130207/f176eec7/attachment.html>