Really enjoyed the (extended version with more attacks / issues: http://isis.poly.edu/~jcappos/papers/cappos_pmsec_tr08-02.pdf ) paper, especially how trust delegation is handled by having the repository track keys that are then used to delegate trust to individual developers, and how revocation is handled at the same speed as learning which keys are allowed rather than by CERT advisories. And how for example revoking a developer's right to publish apache wouldn't affect their ability to use the same key to publish some other software.
I suppose developer-signed Python package metadata is a little different since it can change dynamically at runtime depending on code in setup.py... On Thu, Feb 7, 2013 at 9:06 AM, Justin Cappos <[email protected]> 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 <[email protected]>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 >> [email protected] >> http://mail.python.org/mailman/listinfo/catalog-sig >> >> > > _______________________________________________ > Catalog-SIG mailing list > [email protected] > http://mail.python.org/mailman/listinfo/catalog-sig > >
_______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
