This is required for some versions of OpenSSL having trouble to establish and verify the new certificates for rubygems.org SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash. http://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html
We need to deploy a new server certificate as Google Chrome no longer trusting SHA-1-signed certificates: http://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html In order to avoid interruption of service users will need the updated root certificates to verify the new server certificate. Users may be able to install these certificates by hand into their OpenSSL certificates pem as well.
Previously RubyGems would continue to try to determine the git hash for a reference even if it did not exist. This would cause RubyGems to spew git errors on the console but continue to install and create a bad lockfile. Now RubyGems raises immediately if it cannot find a hash for a revision. Fixes #1031
Previously this worked (I think) by updating to the next prerelease automatically. This broke with the recent changes for prereleases. Now RubyGems checks for a prerelease version to update to (as indicated by the requirement given to update_gems) and creates a new installer with the option enabled. This allows RubyGems to properly resolve the dependencies necessary to update the gem. The test for this change is poor as I can't see how to reproduce the failure indicated in #1028 as it is complex. Instead I just check to see if the flag is correct as I trust the resolver. A test duplicating the failure in #1028 seems like it would result in a functional test anyhow, so this is probably OK. Fixes #1028
Previously the dependencies for the gemspec itself and its dependencies were not added to the lockfile. This may have caused an incompatibility, but it is unknown if it would be automatically fixed by bundler or not, nor if it caused any real damage. Fixes #1020