ruby.git/lib/rubygems/installer.rb, branch v3_4_9 The Ruby Programming Language [rubygems/rubygems] Rely on PATH if Ruby is not installed in the same directory as the binstub 2024-10-30T19:38:08+00:00 David Rodríguez deivid.rodriguez@riseup.net 2024-07-18T18:17:55+00:00 5da1cc6c9c548bf95599ad7aa1b3877f8ccda953 https://github.com/rubygems/rubygems/commit/ab7d65cc18 Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org> 
https://github.com/rubygems/rubygems/commit/ab7d65cc18

Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
[rubygems/rubygems] Simplify enable-load-relative prolog script creation 2024-10-30T19:38:07+00:00 David Rodríguez deivid.rodriguez@riseup.net 2024-07-18T18:01:02+00:00 116d6cbc834c5c58a414d94f93f54e1007c0b60b https://github.com/rubygems/rubygems/commit/f2ed507afe 
https://github.com/rubygems/rubygems/commit/f2ed507afe
[rubygems/rubygems] Warning about PATH in `--user-install` mode is only necessary for gems with executables 2024-09-27T16:49:32+00:00 David Rodríguez deivid.rodriguez@riseup.net 2024-09-25T14:59:57+00:00 d1324170b6c25e893b0dec4d7829e6d561b15cf3 https://github.com/rubygems/rubygems/commit/2fe0f452a2 
https://github.com/rubygems/rubygems/commit/2fe0f452a2
[rubygems/rubygems] Remove temporary `.lock` files left around by gem installer 2024-09-16T11:37:58+00:00 David Rodríguez deivid.rodriguez@riseup.net 2024-09-11T14:42:24+00:00 fab01b15e999e9f9e18389dabfce3919e080ed56 https://github.com/rubygems/rubygems/commit/edbb2e3475 
https://github.com/rubygems/rubygems/commit/edbb2e3475
[rubygems/rubygems] Ensure that the lock file will be removed 2024-09-06T14:46:43+00:00 Nobuyoshi Nakada nobu@ruby-lang.org 2024-08-16T11:19:22+00:00 30176e3f238f198ae835bf1c593d2ad2dce2df49 https://github.com/rubygems/rubygems/commit/2706acb271 
https://github.com/rubygems/rubygems/commit/2706acb271
[rubygems/rubygems] Remove the lock file for binstubs 2024-09-06T14:46:42+00:00 Nobuyoshi Nakada nobu@ruby-lang.org 2024-08-13T08:19:41+00:00 5afee4d79599e5aad366a788b0c84e68594e6d34 https://github.com/rubygems/rubygems/pull/7806#issuecomment-2241662488 https://github.com/rubygems/rubygems/commit/4f06ee234a 
https://github.com/rubygems/rubygems/pull/7806#issuecomment-2241662488

https://github.com/rubygems/rubygems/commit/4f06ee234a
[rubygems/rubygems] Fix another race condition 2024-07-08T05:38:31+00:00 David Rodríguez deivid.rodriguez@riseup.net 2024-07-03T11:26:21+00:00 e4825a5194af822104ec9fcac00004a2bad30f18 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 
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
[rubygems/rubygems] Properly protect writing binstubs with a file lock 2024-07-08T05:38:30+00:00 David Rodríguez deivid.rodriguez@riseup.net 2024-07-02T19:32:31+00:00 d90a930edea311c0f3fe2a8aade03efb1697c3e0 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 
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
[rubygems/rubygems] Remove unnecessary FileUtils usage 2024-07-08T05:38:28+00:00 David Rodríguez deivid.rodriguez@riseup.net 2024-05-28T13:06:28+00:00 6db1c53fce7a0f2f80dd78b5020132a09994c47d All other `chmod` usages in the file use `File.chmod`, so keep it consistent. https://github.com/rubygems/rubygems/commit/3dc0cf8703 
All other `chmod` usages in the file use `File.chmod`, so keep it
consistent.

https://github.com/rubygems/rubygems/commit/3dc0cf8703
[rubygems/rubygems] Protect binstub access during creation with a flock 2024-06-28T10:49:07+00:00 David Rodríguez deivid.rodriguez@riseup.net 2024-06-26T14:47:06+00:00 5c826ebea585dad8aa351632a9de3162d59fb898 https://github.com/rubygems/rubygems/commit/88e3f1d23c 
https://github.com/rubygems/rubygems/commit/88e3f1d23c