Hello from the TUF team
Trishank Karthik Kuppusamy
tk47 at students.poly.edu
Sat Feb 16 00:42:51 UTC 2013
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.
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,
On 02/15/2013 07:16 PM, James Tucker wrote:
> 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:
>> 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!
>> RubyGems-Developers mailing list
>> RubyGems-Developers at rubyforge.**org <RubyGems-Developers at rubyforge.org>
> RubyGems-Developers mailing list
> RubyGems-Developers at rubyforge.org
More information about the RubyGems-Developers