Square Hack Week project: secure updates for RubyGems

Justin Cappos jcappos at poly.edu
Sat Sep 14 21:30:01 UTC 2013


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 <bascule at 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
>


More information about the RubyGems-Developers mailing list