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

Don't hardcode path to private signing_key #294

Open
svoop opened this issue Mar 15, 2020 · 2 comments
Open

Don't hardcode path to private signing_key #294

svoop opened this issue Mar 15, 2020 · 2 comments

Comments

@svoop
Copy link

svoop commented Mar 15, 2020

There is a flaw in the security guide:

Add cert paths to your gemspec

s.cert_chain  = ['certs/yourhandle.pem']
s.signing_key = File.expand_path("~/.ssh/gem-private_key.pem") if $0 =~ /gem\z/

This works fine when building a gem with gem build, however, the signing_key won't be set if you use the gem tasks provided by Bundler, most notably rake build and rake release because $0 won't match gem. Simply adding rake to the pattern seems risky.

The current behaviour is particularly nasty since rake release implicitly rebuilds the gem. So even if you have built and signed the gem with gem build, using rake release will result in a broken release. (Just had to yank a release due to this.)

How about a less magic approach such as:

s.cert_chain  = ['certs/yourhandle.pem']
s.signing_key = File.expand_path(ENV['GEM_SIGNING_KEY']) if ENV['GEM_SIGNING_KEY']

This gets rid of the assumption that you're on a Posix-like OS as well and works with whatever tool you use for building or releasing the gem:

rake release GEM_SIGNING_KEY=~/.ssh/gem-private_key.pem

The risk of cause is that you forget to set GEM_SIGNING_KEY which is why a warning should be displayed whenever a gem is built without signing it. This would also help promote the whole idea of signing gems in the first place – probably a good thing in the light of recent abuses.

@rubyFeedback
Copy link

Well, I am not against your suggestion per se, but environment variables are also problematic. For example, I sometimes run into situation where I set an env variable years ago, leading to problems at a later time.

I think it may be better to show BOTH examples, while having support for GEM_SIGNING_KEY, on the tutorial/documentation, for people to then decide which variant to go. For me personally, although I in general do not like hardcoded paths as such, I'd probably prefer the hardcoded variant rather than having to deal with ENV variables per se. :D

@svoop
Copy link
Author

svoop commented Mar 15, 2020

@rubyFeedback I'm wondering if someone could shed some light on why the signing_key should not be set unless when building the gem. It's just a path and from an outside perspective, it appears wrong to decide whether to set this or not in the gemspec itself. I'll dig a little into the code there, but maybe you know someone with further experience in these parts of the code. Soneone who could chime in and elaborate whether always setting the signing_key and then letting the toolchain decide whether to use it or not would be a feasible and safe solution.

@sonalkr132 sonalkr132 transferred this issue from rubygems/rubygems.org Oct 13, 2021
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

No branches or pull requests

2 participants