We also need to protect prior removal of the binstub, otherwise it can
happen that:
* Process A removes prior binstub FOO.
* Process B removes prior binstub FOO (does nothing actually because Process A already removed it).
* Process A writes binstub FOO for gem BAR from the beginning of file.
* Process B writes binstub FOO for gem BAZ from the beginning of file.
Similarly as before, if binstub FOO for gem BAR is bigger that binstub
FOO for gem BAZ, garbage bytes will be left around at the end of the
file, corrupting the binstub.
The solution is to also protect removal of the previous binstub. To do
this, we use a file lock on an explicit `.lock` file.
https://github.com/rubygems/rubygems/commit/d99a80e62d
There's an issue when multiple processes try to write the same binstub.
The problem is that our file locking mechanism is incorrect because
files are truncated _before_ they are locked. So it can happen that:
* Process A truncates binstub FOO.
* Process B truncates binstub FOO.
* Process A writes binstub FOO for gem BAR from the beginning of file.
* Process B writes binstub FOO for gem BAZ from the beginning of file.
If binstub FOO for gem BAR is bigger than binstub FOO for gem BAZ, then
some bytes will be left around at the end of the binstub, making it
corrupt.
This was not a problem in our specs until the spec testing binstubs with
the same name coming from different gems changed from using gems named
"fake" and "rack" to using gems named "fake" and "myrack". Because of
the difference in gem name length, the generated binstub for gem
"myrack" is now longer, causing the above problem if binstub for gem
myrack is written first.
The solution is to make sure when using flock to always use modes that
DON'T truncate the file when opening it. So, we use `r+` if the file
exists previously (it requires the file to exist previously), otherwise
we use `a+`.
https://github.com/rubygems/rubygems/commit/ce8bcba90f
This method validates only what is required for resolution, skipping any
irrelevant metadata validation. This will be used by Bundler instead of
doing a full validation, allowing gem authors to use `bundle` commands
immediately in newly created gems without first having to fix invalid
metafata fields in the default gemspec.
https://github.com/rubygems/rubygems/commit/da7704cfc0
This patch adds `--target-rbconfig` option to specify the rbconfig.rb file
for the deployment target platform. This is useful when cross-compiling
gems. At the moment, this option is only available for `extconf.rb`-based
extensions.
https://github.com/rubygems/rubygems/commit/cf2843f7a2
When `gem uninstall <gem> --install-dir <dir>` is run, if the version
removed had a plugin, and that same version happened to also be
installed globally, then the plugin stub would fail to be removed.
https://github.com/rubygems/rubygems/commit/4e2fa0be77
This class handles all logic to handle the list of specifications, given
a set of GEM_PATH directories. Makes `Gem::Specification` has less
responsibilities and will help with fixing some bugs next.
https://github.com/rubygems/rubygems/commit/df280dbbed
The plugin loader from `@gem_home` was removed during uninstallation.
However, this could leave behind the plugins for `--user-install`
installed gems.
Use `Gem::Specifictaions#base_dir` instead. This ensures that the plugin
loader for associated .gemspec is uninstalled.
https://github.com/rubygems/rubygems/commit/6047f78210
This gets in the middle if we ever start allowing to build as if using a
different RubyGems version than the one being run.
This could be useful to make `gem rebuild` a little more usable, and
it's already done by Bundler specs which already make this method a noop
when they need this.
I'm not sure forcefully setting this, even if user explicitly specified
something else is helpful.
Since this could potentially prevent gems explicitly setting a constant
RubyGems version from building, I changed the error of incorrect
RubyGems version from a hard error to a warning, since it will start
happening in those cases if we stop overwriting the version.
https://github.com/rubygems/rubygems/commit/45676af80d
This is to prevent a malicious gem from causing a denial of service by
including a very large metadata or checksums file,
which is then read into memory in its entirety just by opening the gem package.
This is guaranteed to limit the amount of memory needed, since
gzips (which use deflate streams for compression) have a maximum compression
ratio of 1032:1, so the uncompressed size of the metadata or checksums file
will be at most 1032 times the size of the (limited) amount of data read.
This prevents a gem from causing 500GB of memory to be allocated
to read a 500MB metadata file.
https://github.com/rubygems/rubygems/commit/a596e3c5ec
Dmitriy Ivliev
David Rodríguez
なつき
Jerome Dalbert
Thomas Marshall
ccmywish
Yuri Kanivetsky
Alexey Schepin
Yuta Saito
Hiroshi SHIBATA
License Update
Samuel Giddins
Vít Ondruch
Jenny Shen
Nobuyoshi Nakada
Ellen Marie Dash