We (from the TUF project) would be also happy to review and discuss the designs you guys are thinking about. Especially anything you are thinking about diverging from TUF on is worth a discussion.
Even if you implement TUF verbatim, there are also some subtleties to key / role setup that can make a big difference. 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. 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. So let us know what you're thinking and we can maybe suggest some security / performance tweaks. By the way, it is excellent that you have Dan Boneh to look over potential issues as well. He's a really world-class crypto guy and I'm sure will give great feedback. Thanks, Justin On Sat, Sep 14, 2013 at 2:22 PM, Tony Arcieri <basc...@gmail.com> wrote: > Hi there. I've talked to some people within Square and we're interested in > creating a system for providing end-to-end integrity of RubyGems, as well > as being able to revoke known compromised RubyGems while still surviving > the compromise of system keys. > > While the specific design goals are up for debate, we'd probably try to do > a prototype implementation of The Update Framework on top of the existing > RubyGems X.509 certificate system (with perhaps a few modifications): > > http://www.updateframework.com/projects/project > > The main goals would be: > > - Try to leverage as much of the existing work on signed RubyGems as > possible > - Depend only on the Ruby standard library and try not to pull in any > additional dependencies that RubyGems doesn't already depend on > - Produce a system with minimum (i.e. "zero") cost and operational > overhead which would still provide practical security guarantees and > could > ensure all gems are signed (and also provide a way to retroactively sign > all existing gems) > > If this sounds good to you, I'd love to talk more about fleshing out what > we would actually implement during Hack Week so we can have a plan that > lets us hit the ground running and get as much done as possible in a week, > with the goal of having something worthwhile that can be merged into the > upstream projects. > > We also have Dan Boneh as a staff cryptographer and can probably rope him > in to review our design ;) > > -- > Tony Arcieri > _______________________________________________ > RubyGems-Developers mailing list > http://rubyforge.org/projects/rubygems > RubyGems-Developers@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > _______________________________________________ RubyGems-Developers mailing list http://rubyforge.org/projects/rubygems RubyGems-Developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
