Hello from the TUF team

James Tucker jftucker at gmail.com
Sat Feb 16 00:16:37 UTC 2013


Thank you for stopping by and offering your assistance, I really appreciate

I have been digesting the Survivable Key Compromise paper, spec and
implementation, and it very much maps to my major concerns for the Rubygems
system; it is so far the first proposal I have seen that appears to be
close to complete.

I still need more time to digest everything fully, but in the meantime I
have some questions already (some of which may be born of
misunderstandings, so your patience is appreciated):

 * What are your recommendations for the targets/* topology?
   - If we use simply gem names (not full name-version-platform tuples or
strings), then I think the revocation model requires a rewrite of a whole
target metadata be rewritten after target key compromise. This may be
acceptable, however,
   - If we use targets/gemname/version-platform then we can rewrite
targets/gemname.txt to disallow future publishing using compromised keys,
but existing (non-malicious) gemname/version-platform.txt remain valid. Is
this the case, and is this safe? (assuming all other standard roles)
   - The paper loosely suggests in the language having these map to files,
which makes sense, but is somewhere between the above two options, and
requires new targets to be issued regularly (maybe that is a good thing?).
   - There are some scaling concerns with each different approach that we
may need to consider. In any of the latter cases, release.txt will continue
to grow fast, although gzip and such will also continue to work well. At
some point though, parsing becomes slow and/or memory intensive.
 * The paper mentions the metadata files for 8000 PyPI binaries reaching
several megabytes. We have considerably more data than this, as such we may
very much need to alter both the data format, and possibly slice the files
into pieces. Do you have any particular recommendations in this area? Are
there non-obvious key security considerations here (I think most are
covered by timestamp.txt and release.txt)?
 * Given the existence of the release and higher level targets roles in
this system, do you still strongly recommend leaf-targets (e.g.
targets/gems/rails-3.2.0-ruby.txt) be rewritten in the event of a
compromise of the rails key that signed it (in the event of t=1)?
 * There is scope in the metadata, for two roles to have the same paths or
path patterns. Is it recommended such an event be a validation error?

Many thanks,


On 15 February 2013 00:39, Trishank Karthik Kuppusamy <
tk47 at students.poly.edu> wrote:

> Hello rubygems,
> We hear from Donald Stufft at the Python Catalog-SIG mailing list that you
> are interested in securing rubygems.
> We are The Update Framework (TUF) project [https://www.updateframework.**
> com/ <https://www.updateframework.com/>], and we would like to help Ruby
> and Python folks to help secure their package managers.
> TUF is a framework designed by computer scientists from NYU-Poly,
> University of Washington and the Tor project to help solve some of the more
> common problems with securing software updaters.
> Here are some papers we wrote on the subject:
> https://isis.poly.edu/~**jcappos/papers/cappos_mirror_**ccs_08.pdf<https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf>
> https://isis.poly.edu/~**jcappos/papers/samuel_tuf_ccs_**2010.pdf<https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf>
> What we would like to do is to help the rubygems community to understand
> how you may use TUF to secure your package manager with security designed
> carefully and intrinsically, so that you do not have to worry about the
> most common security issues.
> Donald, havenwood and raggi introduced us to the Rubygems Trust Model
> document [http://goo.gl/ybFIO], and we will comment on it as soon as we
> find the time. In fact, we are going to have a TUF hackathon here in a few
> hours, and we hope to make more progress on these matters soon enough.
> Please feel free to reach out to us with your questions!
> Thanks,
> Trishank
> ______________________________**_________________
> RubyGems-Developers mailing list
> http://rubyforge.org/projects/**rubygems<http://rubyforge.org/projects/rubygems>
> RubyGems-Developers at rubyforge.**org <RubyGems-Developers at rubyforge.org>
> http://rubyforge.org/mailman/**listinfo/rubygems-developers<http://rubyforge.org/mailman/listinfo/rubygems-developers>

More information about the RubyGems-Developers mailing list