| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
Due to the way rubygems monkey-patched require interacts with default
gems, and given that bundler is a default gem, and that bundler
manipulates the LOAD_PATH in very intricated ways, we can reduce the
risk of "leaking" to a different copy of `bundler` by using
`require_relative` for internal requires.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Avoid Range Not Satisfiable errors during normal request flow
### What was the end-user problem that led to this PR?
Previously, Bundler was requesting partial response ranges for the Rubygems compact index that could be empty. Since Rubygems was [ignoring the `ETag` header](https://github.com/rubygems/rubygems.org/pull/1652) for these requests, empty ranges would occur whenever the versions index (for instance) hadn't been modified since the version Bundler currently had cached. When this happened, Rubygems would respond with a 416 (Range Not Satisfiable). Bundler would treat this as a `Bundler::HTTPError`, and fall back to using `Fetcher::Dependency` for dependency info. Sadly, that meant metadata about what Ruby version each dependency required was no-longer checked, and updates for gems which should be limited by the system Ruby version were failing.
Closes #5373.
### What was your diagnosis of the problem?
See above
### What is your fix for the problem, implemented in this PR?
This PR updates the range Bundler requests from Rubygems to ensure it's always satisfiable. It does that but requesting all bytes from (and including) the final byte in the Bundler cache, rather than all bytes after (and not including) it.
### Why did you choose this fix out of the possible options?
An alternative fix would be to catch the 416 responses and retry the index lookup in those cases, asking for a full response. That would mean an extra request in all of those cases, though - this method keeps the number of calls to Rubygems down.
|
| | | |
|
| |/ |
|
| |
|
| |
- the ETag header may not be available in the response, if so, we ignore that
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As we noticed in #4519, we need to use a temporary directory to hold
compact index downloads so that multiple processes don't write to the
same files at the same time and break everything.
The fix for that was #4561, which added temporary directories to hold
all files as they download, and then uses the (atomic) `FileUtils.cp` to
move the completed downloads into place, so there is never a point where
multiple processes are trying to write into the file at once.
Unfortunately, using `Dir.mktmpdir` requires that the parent directory
be _either_ world writable or sticky, but not both. Based on #4599, it
looks like it's common for home directories to be both world writable
and sticky. While that's a security problem by itself, it's not a big
concern for Bundler and the compact index. So we want to let users
continue to use Bundler, even with the compact index, without having to
change the permissions on their home directories.
This commit changes the `mktmpdir` call to create the temporary
directory inside the default OS tempdir, which is typically `/tmp` or
`/var/tmp` depending on distro. Since that directory is designed to hold
other temporary directories, that change should (theoretically) reduce
or eliminate the problem reported in #4599.
|
| | |
|
| |
|
