On May 26, 2011, at 5:26 PM, Grant Olson wrote: > Fair enough. I'll look into exactly how hairy this will be. > > But for now, let's go under the assumption that I write a plugin for > rubygems. Not part of the base system. This plugin allows you to sign > and verify gems, and does require a working gpg installation. Only > people who care about software verification install it and use it. And > then in the year 2013 or 2038 or whatever, there's a pure ruby version > of the back end crypto stuff and we merge the code with rubygems. > > 1) Is the gpg requirement still a dealbreaker in this scenario?
RubyGems must either be contained within RubyGems or Ruby. If Ruby had a PGP/GPG library this would be no longer be a dealbreaker (hint). > 2) Does rubygems do any verification of the contents? Will a few extra > files in the main .tgz flag the gem as invalid? The structure of a plain gem is: blah.gem data.tar.gz metadata.gz The structure of a signed gem (with current code) is: blah.gem data.tar.gz data.tar.gz.sig metadata.gz metadata.gz.sig You could put whatever other files in there you wanted. > 3) Is there interest in a simulated CA at a site like rubygems, as > described in the original post? Yes We could do something lazier too, IIRC `gem push` uses SSL to upload the gem, so rubygems.org could simply sign any gems with its own cert. No need for a CA or any of that stuff. (This proposal is overly simplistic currently). _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
