Expand gem security build/install instructions; add checksum

[bf4]

For review, @drbrain

• section demarcation
• syntax highlighting
• verbosity / correctness of examples

cc @yorickpeterse
cc @grant-olson
cc @tarcieri

[yorickpeterse]

Re: https://github.com/YorickPeterse/ruby-lint/issues/72#issuecomment-29004447

I do not think that the rubygems PGP CA is worth mentioning/using. Although the idea in itself was interesting it was of little value over the existing key server infrastructure out there. Having a single developer act as a CA is no more secure than a group of developers that share mutual trust.

Whether it's worth mentioning the PGP plugin is also something I'm not sure about. This isn't per definition because PGP is back but because unless it's enforced (that is, RubyGems enforces signed packages only) nobody will use it. In fact, although I do sign ruby-lint myself I've yet to see a single other Gem do it.

Personally I'm considering to stop signing Gems using PGP as based on my own use and the use of others I consider it no more secure than providing a list of SHA1 checksums in a Git repository.

The built-in certificate signing system is definitely worth mentioning although I don't think it solves anything. Users are required to set trust levels, put all kinds of extra stuff in Gemspecs and due to it not being enforced it will only be a massive pain.

For example, if the Rails maintainers decide to sign rails then unless every Gem that it depends on is also signed it's still fairly useless. One of those Gems is still unverified and depending on your trust settings the entire install will fail. Although the latter makes sense from a security point of view (that's the point of said trust level) I'm 95% sure that the first developer that is not a security expert will just turn the trust system off the moment they experience a problem like this.

OK so I kinda went off topic there. To cut a long story short: I don't think mentioning GPG is worth it unless it becomes a standard, which it probably never will due to it not being available on every platform. For certificate signing it's important to state both the upsides and downsides as well as why one should do it in the first place. Just listing a bunch of commands isn't going to get Average Joe or Average Alice to suddenly sign their Gems.

[bf4]

Thanks @yorickpeterse, @grant-olson was just giving me similar advice to abandon use of the ca until it gets official backing, and for any gems using openpgp, to ask users to trust keys on an individual basis, as he notes at the bottom of the stackdriver-ruby readme

[drbrain]

This week employees of Square are working on adding TUF to RubyGems which will probably replace the existing signing code. It's not worth inclusion yet, though.

[bf4]

Ok, @drbrain @yorickpeterse @grant-olson what do you think of this?

[yorickpeterse]

There's a small typo:

For details, see dicussion with Grant Olson and Yorick Peterse.

should be

For details, see discussion with Grant Olson and Yorick Peterse.

[bf4]

@yorickpeterse Ha, thanks!

[drbrain]

After a glance, it looks OK to me!

[bf4]

Ok, merged. Still needs attention, but I think this is a marked improvement (thanks to all comments!)

[bf4]

I think the questions asked in #62 would be good content to add:

1. How to report gem security issues to an author/rubygems.org and
2. How a gem author should publicize the gem security release. (very few seem to [ANN] on ruby-lang or check it)