rotp | Ruby One Time Password library | Identity Management library

In your example, the gem would be loaded via HTTPS, because the Gemfile of a dependency will not be loaded at all. From dependencies, only the gemspec file is evaluated by Bundler. The gem's Gemfile is only used during the development of that gem. Interesting read in this context: How bundler priorities sources.

The following for the interested reader why it is important to use HTTPS when downloading gems:

When you load a gem from a non-HTTPS source and there is a man-in-the-middle attacker then this attacker would be able to send you back anything instead of the gem you requested.

Of course, there are man ifs and whens. But let's imagine you are going to download a gem on a non-secure communication channel like pure HTTP. And let's imagine there is a man-in-the-middle attacker that is able to sniff your traffic. This might be possible when using the same WiFi in a café or hotel, or when there are different customers on virtual servers in a data center or they have physical access to your landline.

Because they can read your unencrypted request for a gem then know what gems you are using. Now imagine that they do not just sniff your traffic but instead manipulate the response from the servers to you too. When you, for example, request a new version of a popular gem to handle user authentication and authorization or payments they could send you back their version instead of the original version.

And their version could include some minor changes like:

• when loaded the gem could upload your Gemfile to the attacker which would give the attacker a great overview of your application.
• when loaded the gem could take all ENV variables and/or Rails.credentials and upload them to a server that is controlled by the attacker. This would certainly git the attacker all your application's passwords.
• because it changed the original gem dealing with user credentials the malicious gem would be able to track users or your admin credentials when they log in or update their credentials. Given that many users use the same email/password combination everywhere this would be a nightmare.
• if the gem can read ENV variables or Rails.credentials then that means that it could change them too. For example, to connect to another payment provider would mean your customer's payment would be redirected into a different account.
• And on top of that, the malicious gem could also replace itself with the original gem once it was loaded into memory. What would make it difficult to figure out that your server was attacked.

tl;dr When an attacker is able to do a man-in-the-middle attack then they can send you malicious versions of a gem. These malicious gems could do almost everything with your application you can imagine. Sure, attacks like this are not simple, but they are not super-hard neither.

The rule of thumb is: Always use HTTPS whenever possible (not just for downloading gem but for all network traffic).