Hello from the TUF team

Justin Cappos jcappos at poly.edu
Sat Feb 16 01:10:04 UTC 2013


Just to be a little more specific on our timeline, we have some grant
deadlines and paper deadlines all coming up on Thursday of next week.
We'll try to get back to you with answers after that.   You're asking a lot
of good questions that I can't necessarily give off-the-cuff answers to.
I need to take time and really digest Ruby's use case and think through my
answers.

Sorry for the delay!

Thanks,
Justin


On Fri, Feb 15, 2013 at 7:42 PM, Trishank Karthik Kuppusamy <
tk47 at students.poly.edu> wrote:

> Hello James,
>
> Thanks very much for your email. I just realized that I forgot to copy
> my advisor and one of the primary designers of the TUF framework, Prof.
> Justin Cappos.
>
> We are currently under some intense deadlines, but we will strive to get
> back to you as soon as possible. Thanks in advance for your patience!
>
> With best regards,
> Trishank
>
> On 02/15/2013 07:16 PM, James Tucker wrote:
> > Trishank,
> >
> > Thank you for stopping by and offering your assistance, I really
> appreciate
> > it.
> >
> > 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,
> >
> > James
> >
> >
> >
> > 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>
> >>
> > _______________________________________________
> > 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