On Sat, Sep 14, 2013 at 2:30 PM, Justin Cappos <jcap...@poly.edu> wrote:
> For example, we set up PyPI's metadata in such a way that even if the repo > is compromised users requesting packages from most projects would not be at > risk. The design still allows developers to create new projects with zero > lag / extra overhead / manual intervention. So it's much better security > with the same usability. > Awesome! It would be great it we didn't impact the system usability. In my opinion, if we do a good job, people shouldn't notice the signature system is even there unless something is actually compromised ;) > Another minor change with PyPI's setup resulted in an absolutely huge > metadata overhead reduction. A straightforward metadata signing setup > required several MB of data to be downloaded for each install. We > implemented hash-based delegations and reduced this by more than a factor > of 10x. Nice, I would love to hear more about that, as well as more general practical advice about implementing TUF. So far I have just read the "Survivable Key Compromise..." paper and can see how it could be potentially mapped to tools like RubyGems and Gemcutter. At Square we have a lot of experience with PKI, but mostly for TLS purposes, and a system like RubyGems where there are many publishers is definitely quite the special case versus what we're used to. If there's any particularly awesome resources on what you've done in PyPI I'd love to check them out. -- Tony Arcieri _______________________________________________ RubyGems-Developers mailing list http://rubyforge.org/projects/rubygems RubyGems-Developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
