You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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 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.
There is a flaw in the security guide:
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 notablyrake build
andrake release
because$0
won't matchgem
. Simply addingrake
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 withgem build
, usingrake release
will result in a broken release. (Just had to yank a release due to this.)How about a less magic approach such as:
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:
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.
The text was updated successfully, but these errors were encountered: