Use env var to set api key on install

[swebb]

What was the end-user or developer problem that led to this PR?

I want to be able to install gems from a private registry using gem install. However, instead of using ~/.gem/credentials I want to use a short term token (an OIDC token).

What is your fix for the problem, implemented in this PR?

Commit 42c1b42 added the ability to use the "GEM_HOST_API_KEY" environment variable when pushing a gem to set the authorization header.

This commit uses the same approach for authorization when installing gems via gem install. This is useful when working with private registries using tokens with a short lifetime (e.g., OIDC tokens).

For example:

GEM_HOST_API_KEY="secret_token" gem install private_gem --clear-sources \
  --source https://private.repo.com

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[welcome]

Thanks for opening a pull request and helping make RubyGems and Bundler better! Someone from the RubyGems team will take a look at your pull request shortly and leave any feedback. Please make sure that your pull request has tests for any changes or added functionality.

We use GitHub Actions to test and make sure your change works functionally and uses acceptable conventions, you can review the current progress of GitHub Actions in the PR status window below.

If you have any questions or concerns that you wish to ask, feel free to leave a comment in this PR or join our #rubygems or #bundler channel on Slack.

For more information about contributing to the RubyGems project feel free to review our CONTRIBUTING guide

[deivid-rodriguez]

👋 👋 Sorry for the delay.

This seems like a nice idea to avoid having to store any raw tokens on disk.

What kind of private registry are you using? I tried using this patch to install a private gem from gemfury and I had to modify it like this to make it work:

diff --git a/lib/rubygems/commands/install_command.rb b/lib/rubygems/commands/install_command.rb
index 95a6c6afc52..121d6d2dff0 100644
--- a/lib/rubygems/commands/install_command.rb
+++ b/lib/rubygems/commands/install_command.rb
@@ -160,7 +160,7 @@ def execute
     load_hooks
 
     if ENV["GEM_HOST_API_KEY"]
-      Gem::RemoteFetcher.fetcher.headers[:authorization] = ENV["GEM_HOST_API_KEY"]
+      Gem::RemoteFetcher.fetcher.headers["Authorization"] = ["Basic " + ["#{ENV["GEM_HOST_API_KEY"]}:"].pack("m0")]
     end
 
     exit_code = install_gems

I did not try gemstash but from reading this, maybe it works in the same way?

[swebb]

Hi @deivid-rodriguez. Thanks for checking this out.

What kind of private registry are you using?

I'm doing this purely for my personal interest; however, my day job is with Buildkite so I tested it using a Buildkite rubygem registry.

I wanted to avoid setting it to "Basic" to allow other authentication schemes. I particularly want to allow "Bearer" to allow for OIDC tokens.

After your message I did some experimenting with rubygems.org and MITM proxy to see how gem handles authentication when pushing gems using different methods.

command	authorization header
gem push something.gem --host="https://abcd@rubygems.org"	Authorization: Basic YWJjZDo=, rubygems_XXXXXXX
GEM_HOST_API_KEY="abcd" gem push something.gem	Authorization: abcd

So when pushing the GEM_HOST_API_KEY is used verbatim as the authorization header; allowing a different authorization scheme to be set.