https://github.com/ruby/openssl/pull/958 changed the common logic for
digest algorithm lookup:
- If the argument is neither an OpenSSL::Digest instance nor a String,
it is now implicitly converted to String with #to_str. This is
consistent with algorithm name lookup logic in ruby/openssl for pkeys
and ciphers.
- If the name is not recognized, OpenSSL::Digest::DigestError is raised
instead of RuntimeError.
Update the specs accordingly:
- Remove specs that expect #to_str not to be called.
- Relax regexps matching TypeError messages.
- Expect OpenSSL::Digest::DigestError instead of RuntimeError for
ruby/openssl 4.0.0 and later.
- ### Problem
Running `bundle lock --add-checksums` doesn't add the checksum of
gems hosted on server that don't implement the compact index API.
This result in a lockfile which is unusable in production as
some checksums will be missing and Bundler raising an error.
Users can work around this problem by running:
`BUNDLE_LOCKFILE_CHECKSUMS=true bundle install --force`
But this means redownloading and installing all gems which isn't
great and slow on large apps.
### Context
Bundler uses the Compact Index API to get the checksum of gems,
but most private gem servers don't implement the compact index API
(such as cloudsmith or packagecloud). This results in a soft failure
on bundler side, and bundler leaving out blank checksum for those
gems.
### Solution
For gems that are hosted on private servers that don't send back
the checksum of the gem, I'd like to fallback to the
`bundle install` mechanism, which don't rely on an external API but
instead compute the checksum of the package installed on disk.
This patch goes through the spec that didn't return a checksum,
and compute one if the package exists on disk.
This solution makes the `bundle lock --add-checksums` command
actually usable in real world scenarios while keeping the
`bundle lock` command fast enough.
https://github.com/rubygems/rubygems/commit/8e9abb5472
- Fix https://github.com/rubygems/rubygems/pull/8985
- ### Problem
If you have a Gemfile that contains a `install_if` git gem, it will
be impossible to add other gems in the Gemfile and run
`bundle install`, you'll get a "The git source [...] is not yet
checked out".
### Context
The change that modified this behaviour was in https://github.com/rubygems/rubygems/commit/abbea0cc94dd,
and the issue is about the call to `current_dependencies`.
This call filters out irrelevant dependencies such as the one that
get condtionnally installed. By doing so, we skip over setting
the source based of the lockfile for that dependency
ade324bdc8/bundler/lib/bundler/definition.rb (L978)
Ultimately, because of this, the dependency source doesn't have
any additional information such as the `revision`. Down the line,
when we end up to converge the spec, Bundler will attempt to get the
revision for that spec but won't be able to because the git source
isn't configured to allow running git operations.
### Solution
Filter out the irrelevant only spec only after we have set its
source.
https://github.com/rubygems/rubygems/commit/d2af439671
If using a gem with precompiled versions having different dependencies
than the generic version from a path source, and with a lockfile
including a precompiled version, we would materialize the
generic version, but end up using dependencies for the precompiled
version. That will result in the parallel installer missing the
specifications for the extra dependencies of the generic version,
causing a crash.
If we are materializing for installation, make sure we use the
materialized specification when traversing dependencies.
https://github.com/rubygems/rubygems/commit/5f75d75de7
