[tuf] Re: RubyGems/TUF Hack Week Project at Square

Justin Cappos jcappos at nyu.edu
Mon Nov 18 19:46:11 UTC 2013


Four of the students in my App Sec class built this.   They are trying to
get an end-to-end integration of TUF with gem going.

I'll forward the email they sent a few days ago to the lists.

Thanks,
Justin


On Mon, Nov 18, 2013 at 2:38 PM, Tony Arcieri <bascule at gmail.com> wrote:

> We found this somehow and it seems interesting:
>
> http://mirror1.poly.edu/test-rubygems/
>
> This looks like an example of how TUF's metadata formats could live
> side-by-side with the existing RubyGems formats. Is that the case? Any idea
> where this came from?
>
>
>
> On Sun, Nov 17, 2013 at 4:44 PM, Tony Arcieri <bascule at gmail.com> wrote:
>
>> Square's Hack Week starts tomorrow, and we'll be doing a project to add
>> security to RubyGems. We have been looking at the TUF work that is already
>> being done on PyPI/pip as a sort of design document for how we might apply
>> these same sorts of ideas to RubyGems:
>>
>> https://github.com/theupdateframework/pep-on-pypi-with-tuf
>>
>> I'm thinking we could even fork this document and create a derived one
>> that's applicable to RubyGems.
>>
>> There are at least 17 interested developers on this project, so I hope we
>> can accomplish something within a week!
>>
>> I just wanted to touch base with the RubyGems people/TUF people so you
>> know 1) this is happening 2) can give us some feedback as far as whether
>> we're doing a good job ;)
>>
>> This project will focus on looking at the RubyGems ecosystem end-to-end
>> and applying the TUF design principles to the respective parts of this
>> system. It's expected to leverage the existing digital signature system
>> that's already in place in RubyGems, but add additional security around
>> things like Gemcutter, bundler-api, and RubyGems mirrors, per TUF's
>> separation-of-responsibilities principles.
>>
>> One of the design principles of TUF is for users to not see an impact in
>> their experience *unless* the system has been compromised and we certainly
>> hope to attain that too. The only additional step this project would add to
>> the workflow would be mandatory gem signing using the standard RubyGems
>> commands for doing so as they exist today.
>>
>> --
>> Tony Arcieri
>>
>
>
>
> --
> Tony Arcieri
>


More information about the RubyGems-Developers mailing list