Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand gem security build/install instructions; add checksum #70

Merged
merged 7 commits into from
Nov 21, 2013

Conversation

bf4
Copy link
Contributor

@bf4 bf4 commented Nov 21, 2013

For review, @drbrain

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

cc @yorickpeterse
cc @grant-olson
cc @tarcieri

@yorickpeterse
Copy link

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
Copy link
Contributor Author

bf4 commented Nov 21, 2013

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
Copy link
Member

drbrain commented Nov 21, 2013

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
Copy link
Contributor Author

bf4 commented Nov 21, 2013

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

@yorickpeterse
Copy link

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
Copy link
Contributor Author

bf4 commented Nov 21, 2013

@yorickpeterse Ha, thanks!

@drbrain
Copy link
Member

drbrain commented Nov 21, 2013

After a glance, it looks OK to me!

bf4 added a commit that referenced this pull request Nov 21, 2013
Expand gem security build/install instructions; add checksum; recommend against OpenPGP
@bf4 bf4 merged commit e63a922 into rubygems:gh-pages Nov 21, 2013
@bf4
Copy link
Contributor Author

bf4 commented Nov 21, 2013

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

@bf4
Copy link
Contributor Author

bf4 commented Nov 22, 2013

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)

ghost pushed a commit to rubygems/rubygems that referenced this pull request Jan 24, 2020
3063: Updates to some old gem-signing docs. r=bronzdoc a=tiegz

# Description:

Some of the gem-signing docs are out-of-date since most of them were updated in 2012:

* `gem build` includes a single checksum file now, relpacing the old *.sum files, as of 3f2e059
* updates the results of the `gem help cert` command in the docs with newer flags
* replaces an old YAML method that was removed from Psych

Additional question: I almost replaced ~/.gem in these docs with ~/.ssh for storing gem signing keys, since the [Rubygems guides use ~/.ssh](https://guides.rubygems.org/security/), for consistency between docs + guides. But then I wondered "why would you store gem signing keys in an ssh folder?" and couldn't find an explanation in rubygems/guides#70 . Curious which one would be best. 

# Tasks:

- [x] Describe the problem / feature
- [ ] Write tests
- [ ] Write code to solve the problem
- [ ] Get code review from coworkers / friends

I will abide by the [code of conduct](https://github.com/rubygems/rubygems/blob/master/CODE_OF_CONDUCT.md).


Co-authored-by: Tieg Zaharia <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants