[Catalog-sig] RubyGems Threat Model and Requirements

[Giovanni Bajo]

Il giorno 13/feb/2013, alle ore 04:31, Nick Coghlan <ncoghlan at gmail.com> ha scritto:

> On Wed, Feb 13, 2013 at 2:27 AM, Giovanni Bajo <rasky at develer.com> wrote:
>> Il giorno 12/feb/2013, alle ore 14:12, Nick Coghlan <ncoghlan at gmail.com> ha scritto:
>> 
>>> On Tue, Feb 12, 2013 at 10:09 PM, Giovanni Bajo <rasky at develer.com> 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   ::  rasky at develer.com
Develer S.r.l.  ::  http://www.develer.com

My Blog: http://giovanni.bajo.it






-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4346 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20130213/6b59d35c/attachment.bin>