After the recent Rubygems.org hack it became clear that somethings needs to be done about authenticating gems. One of the efforts that was launched is http://www.rubygems-openpgp-ca.org/. We at Phusion have just finished signing all our gems and repositories with our PGP key, and our PGP key has been verified and signed by this CA. It would be great if Unicorn can participate as well by signing future releases. If you already use GnuPG then the process is extremely straightforward. -- Phusion | Ruby & Rails deployment, scaling and tuning solutions Web: http://www.phusion.nl/ E-mail: info at phusion.nl Chamber of commerce no: 08173483 (The Netherlands)
Hongli Lai <hongli at phusion.nl> wrote:> After the recent Rubygems.org hack it became clear that somethings > needs to be done about authenticating gems. One of the efforts that > was launched is http://www.rubygems-openpgp-ca.org/. We at Phusion > have just finished signing all our gems and repositories with our PGP > key, and our PGP key has been verified and signed by this CA. > > It would be great if Unicorn can participate as well by signing future > releases. If you already use GnuPG then the process is extremely > straightforward.Can we designate gems be signed by a trusted third party (e.g. you?) That''s how Debian (and presumably other OS distros work). _Nobody_ should trust me. I have and maintain zero credibility. The only credibility any unicorn has is what its users give it.
On Mon, Mar 11, 2013 at 11:48 PM, Eric Wong <normalperson at yhbt.net> wrote:> Can we designate gems be signed by a trusted third party (e.g. you?) > That''s how Debian (and presumably other OS distros work). > > _Nobody_ should trust me. I have and maintain zero credibility. > The only credibility any unicorn has is what its users give it.Well the kind of trust we''re talking about here is not trustworthiness (i.e. "does the software work well and will it refrain from formatting my harddisk?"), but authenticity ("is this gem made by the Unicorn and not someone pretending to be him?"). Given that definition of "trust", having a third party sign the gem is not very useful, and letting you sign the gem will not make it a statement about trustworthiness, warranty or credibility. What do you think? -- Phusion | Ruby & Rails deployment, scaling and tuning solutions Web: http://www.phusion.nl/ E-mail: info at phusion.nl Chamber of commerce no: 08173483 (The Netherlands)
Hongli Lai <hongli at phusion.nl> wrote:> On Mon, Mar 11, 2013 at 11:48 PM, Eric Wong <normalperson at yhbt.net> wrote: > > Can we designate gems be signed by a trusted third party (e.g. you?) > > That''s how Debian (and presumably other OS distros work). > > > > _Nobody_ should trust me. I have and maintain zero credibility. > > The only credibility any unicorn has is what its users give it. > > Well the kind of trust we''re talking about here is not trustworthiness > (i.e. "does the software work well and will it refrain from formatting > my harddisk?"), but authenticity ("is this gem made by the Unicorn and > not someone pretending to be him?"). Given that definition of "trust", > having a third party sign the gem is not very useful, and letting you > sign the gem will not make it a statement about trustworthiness, > warranty or credibility. > > What do you think?The only thing that matters in the end is whether the code is good or not. I have the same likelyhood of having my GPG key compromised as I do of writing broken code that breaks things horribly: a very likely one. I make my commits public and and send patches to mailing lists to encourage others to verify what I''m doing isn''t horribly broken. I never tell anybody to accept patches/code based on who wrote it; same goes for gems/tarballs. So yes, gems/tarballs should have the same level of scrutiny as every commit. If somebody else assumed my identity, but continued doing things in the way I''ve done in the past; unicorn users would not (nor should they) notice the difference. That may''ve already happened :)