Il giorno 10/feb/2013, alle ore 13:54, Nick Coghlan <[email protected]> ha scritto:
> On Sun, Feb 10, 2013 at 10:36 PM, Jannis Leidel <[email protected]> wrote: >> >> On 10.02.2013, at 05:44, Nick Coghlan <[email protected]> wrote: >> >>> On Sun, Feb 10, 2013 at 7:23 AM, Giovanni Bajo <[email protected]> wrote: >>>> Hello, >>>> >>>> my proposal for fixing PyPI and pip security is here: >>>> https://docs.google.com/a/develer.com/document/d/1DgQdDCZY5LiTY5mvfxVVE4MTWiaqIGccK3QCUI8np4k/edit# >>>> >>>> I tried to sum up the discussions we had here last week, elaborating on >>>> Heimes' proposal by simplifying it where I thought the additional steps >>>> wouldn't guarantee additional security. At this point, the proposal does >>>> not include a central, uber-master online GPG signing key to be stored on >>>> PyPI, which is IMO quite hard to handle correctly. >>> >>> I think the parts related to improving the HTTPS/SSL based security >>> are solid, but for the other aspects of secure updates, integrating >>> TUF (https://www.updateframework.com/) into the PyPI based >>> distribution infrastructure sounds like the best available option for >>> enhancing the end-to-end integrity checking. TUF has a comparatively >>> well-developed threat model, and systematically covers many of the >>> attack vectors discussed in the past few day (including provision of >>> old, known vulnerable, versions). >> >> Would you mind explaining why TUF is good? > > The main benefit in my mind is that it isn't a from-scratch design of > a secure update infrastructure. Instead, it's a project that was > started in order to resolve some security holes found in Tor's already > robust automatic update mechanism, then proceeded from there into > updates to yum, yast, apt, etc (i.e. the distro update mechanisms that > are vetted by the security teams of the various Linux vendors). Notice that all those big-profile names don't use TUF, as far I can tell. I don't know exactly what it's been fixed with the help of the TUF guys, but it's not that it's a world-deployed standard model. > However, the design itself also seems sensible, and is able to provide > its security guarantees even if you're *not* using SSL certs to > protect the in-flight traffic (thus meaning that the SSL > infrastructure in the near term will become a matter of providing > defence-in-depth, rather than being a required part of the security > scheme). The same applies to my design, and to any design that achieves end-to-end integrity, but the point is still only theoretical because TUF doesn't solve the problem of trust. TUF designers will have to come up to a trust model for PyPI, which is what 50% of my document is about. > I trust our collective ability to make TUF sufficiently easy to use as > part of Python's packaging infrastructure a *lot* more than I trust > our collective ability to come up with a from-scratch distribution > scheme that is both usable *and* secure. I would like to see existing large-scale/high-profile deploys of TUF. Are there any? Otherwise the argument "TUF already exists, let's use it" is a bit weak. -- Giovanni Bajo :: [email protected] Develer S.r.l. :: http://www.develer.com My Blog: http://giovanni.bajo.it
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
