You can clone with
HTTPS or Subversion.
The following should produce the desired installation process:
[git@host gitlab]$ bundle install --deployment --without development test mysql
Instead I get this:
Fetching source index from https://rubygems.org/
Could not verify the SSL certificate for https://rubygems.org/.
There is a chance you are experiencing a man-in-the-middle attack, but most likely
your system doesn't have the CA certificates needed for verification.
For information about OpenSSL certificates, see bit.ly/ruby-ssl.
To connect without using SSL, edit your Gemfile sources and change 'https' to 'http'.
Editing config/Gemfile and changing from https:// to http:// works as a temporary fix but perhaps someone could shed some light on this or fix this?
(wrong forum but) I've never liked Ruby and am only forced to install it due to this lovely project. Hence I have no clue in which direction to go on about addressing this Ruby issue but this felt like a good start.
Without being able to try much on my current development environment it might be that the proxy (which in normal use-cases lets SSL traffic straight through without doing anything to it) tries to replace the SSL certificate with a local certificate in order to parse the data being sent and verify the contents.
This in turn, results in a "bad" certificate which the setup scripts can't take into considerations (for instance, setting a flag if a proxy is in place or even do a sanity check on it and then ignoring the certificate validity even tho, that would go against the norm of why certificates was enforced in the first place).
Couldn't find this information anywhere but a little bit of digging got me to this conclusion. Perhaps it's useful for someone else ending up in the same seat or if someone could report a more permanent fix for this issue (people behind proxies)?
@randx is there a specific reason we use https? I've seen several reports that is causing issues.
I would consider signed packages instead and have a signed hash-sum of all the files that is downloaded. That way you get the (most likely) intended security with SSL but you don't have to worry about MITM attacks even without SSL because the packages themselves are signed and content-hashed.
@senny I guess it was a temporary ssl problem with rubygems.
Since error description is pretty clean and you can always handle this case I recommend to leave Gemfile as is
@Torxed can you confirm that this was a temporary problem? Does it work now?
@randx Wouldn't it be easier (for someone who's not familiar with crypto messages etc) to have an option to download from a second non-https link (same link, just not SSL)?
@senny Not at the moment, won't have access to the environment until monday or somewhere around that time.
The problem will most likely still be there tho, since it's a proxy related issue and the SSL will always come out as "malicious" to the client.
Does this issue still exist on the latest master? Thanks for the issue report. Please reformat your issue to conform to the issue tracker guidelines found in our contributing guidelines.
Don't know, and i can't verify either because of the one time install i did in a test environment :/
@Torxed please open a new issue once you can provide reproduction steps.