Il giorno 13/feb/2013, alle ore 04:31, Nick Coghlan <[email protected]> ha scritto:
> On Wed, Feb 13, 2013 at 2:27 AM, Giovanni Bajo <[email protected]> wrote: >> Il giorno 12/feb/2013, alle ore 14:12, Nick Coghlan <[email protected]> ha >> scritto: >> >>> On Tue, Feb 12, 2013 at 10:09 PM, Giovanni Bajo <[email protected]> wrote: >>>> Hello Nick, >>>> >>>> I've added the initial Requirements and Thread Model section to my >>>> document. I've also added a section "Future scenarios" at the end of the >>>> document. >>>> >>>> I hope they complete what you were feeling was missing from the proposal. >>> >>> Thanks, that helps me a lot in understanding the overall goals of your >>> approach - in particular, it more clearly puts several things out of >>> scope :) >>> >>> Your Task #6/#7 (related to PyPI generating the trust file, and pip >>> verifying it) are the ones where I think the input of the TUF team >>> will be most valuable, as well as potentially the folks responding to >>> the rubygems.org attack. >> >> My undestanding is that #6/#7 are not currently covered by TUF. > > It's not explained very clearly in the spec, but #6/#7 are covered by > TUF's "target delegation" concept (see > https://www.updateframework.com/browser/specs/tuf-spec.txt#L241 and > https://www.updateframework.com/browser/specs/tuf-spec.txt#L382) > > The PyPI target role key can delegate authority to individual package > developer keys by delegating authority for the relevant paths within > PyPI (i.e. the locations of the sdists and other files). > > This is discussed briefly at > https://www.updateframework.com/wiki/SecuringPythonPackageManagement#Notes > (where they note they have added an extra level of delegation to > separate out the package specific delegations by first letter rather > than dumping them all in one directory). Thanks for explaining, I must say it wasn't really clear in the docs. > TUF's target delegation is thus in direct competition to the "trusted > keys" file in your design. TUF specifically aims to take care of the > "online key needed" problem, by confining the online key role to the > generation of the timestamp file, with offline keys used to sign the > regenerated metadata when a target delegation changes. Does this mean that adding a package to PyPI, adding a maintainer to a package, removing a maintainer from a package, etc. all require an offline operation in this model? I wouldn't oppose it. In fact, I was just scared that such a model would not be accepted as it would break too much flexibility (within my design, the equivalent would be having the trust file signed by a master PyPI GPG key, whose fingerprint is hardcoded in pip, and it is kept offline; or it might even be online, but on a separate signing server, that eg. logs everything it does by email to a public mailing list, like "Adding this fingerprint to django"). Does TUF have also a way to let end users not trust PyPI, that is what is obtained by manually hand-editing/tuning the trust file in my design? -- 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
