guides icon indicating copy to clipboard operation
guides copied to clipboard

Don't hardcode path to private signing_key

Open svoop opened this issue 5 years ago • 2 comments

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.

svoop avatar Mar 15 '20 12:03 svoop

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

rubyFeedback avatar Mar 15 '20 14:03 rubyFeedback

@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.

svoop avatar Mar 15 '20 17:03 svoop