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. So yes, I would 
surely value their input to review my design, evolve it together or scratch it 
and come up with something new.

Sorry for the repetition, but I also volunteer for implementation. I don't mind 
if someone else does it (or a subset of it, or we split, etc.), but I think it 
is important to say that this is not a theoretical proposal that someone else 
will have to tackle, but I'm happy to submit patches (all of them, in the worst 
case) to the respective maintainers and rework them until they are acceptable.

> The rubygems.org will also be looking at server side incident response
> - I suspect a lot of that side of things will end up running through
> the PSF infrastructure team moreso than catalog-sig (although it may
> end up here if it involves PyPI code changes.


While I do have some ideas, I don't think I'm fully qualified for that side of 
things. Primarily, my proposal helps by not forcing PyPI to handle an online 
"master" signing key with all the required efforts (migration, rotation, 
mirroring, threat responses, mitigations, etc.). If you read it, you had seen 
that PyPI is only required to validate signature (like pip), not sign anything.
-- 
Giovanni Bajo   ::  [email protected]
Develer S.r.l.  ::  http://www.develer.com

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






Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig

Reply via email to