| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Ruby core needs to change `Spec::Path.root` and gemspec, bin, spec
directories structure.
* Added Spec::Path.bin, gemspec, spec methods.
* Replace Spec::Path methods from relative references like "../../..".
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
r=segiddins
remove forbidden chars in cassettes pathname
### What was the end-user problem that led to this PR?
Users running Micorsoft Windows are currently unable to clone to Bundler project due to a forbidden character in the folder path:
`spec/support/artifice/vcr_cassettes/realworld/api.rubygems.org/api/v1/dependencies?gems=bundler'`
The `?` being the forbidden character.
See #5828
### What is your fix for the problem, implemented in this PR?
Replaced the forbidden character in the folder name with a `-` and updated the VCR spec helper to replace any forbidden character with a `-` in the filename function.
### Why did you choose this fix out of the possible options?
This was the most simple approach to fix the issue.
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[2.0] Remove RubyGems Aggregate & support transitive source pinning
### What was the end-user problem that led to this PR?
The problem was that the resolver could resolve specs from _any_ of the sources specified in the Gemfile, even if that source had nothing to do with the spec in question. This was such a large security vulnerability that, when discovered, it warranted a CVE and its own minor release of Bundler.
Closes #3671.
Closes #3696.
Closes #4059.
### Was was your diagnosis of the problem?
My diagnosis was that we needed to get rid of the notion of a `rubygems aggregate` and enforce that specs could only come either from the source they were declared to come from (the top-level source if declared at the top-level of the Gemfile, else a scoped source), or a source that it transitively "inherited" from the gems that required it.
### What is your fix for the problem, implemented in this PR?
My fix is to disable multiple top-level sources in the Gemfile, remove the RubyGems aggregate, and filter the sources gems could come from as described above.
### Why did you choose this fix out of the possible options?
I chose this fix because it allows doing the filtering in a reasonably performant manner, and refactors the way we handle sources to abstract some of the grossness in such a way that the machinations to make sure that all of the necessary gem info is downloaded is encapsulated into a single method, driven from the definition, rather than being specific to rubygems sources.
See https://github.com/bundler/bundler/pull/4714 and https://github.com/bundler/bundler/pull/4930 for the prior implementation.
|
| |/ |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
content-length headers
|
| |
|
| |
|
|
|
|
| |
Run `rubocop -a --only Style/PercentLiteralDelimiters` and `rubocop --auto-gen-config`.
|
| |
|
|
|
|
| |
This is so persistent will use our override class
|
| |
|
|
|
|
| |
This avoids loading rack, which conflicts with some specs
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When bundler is run concurrently using the same bundle dir in $HOME,
the versions file can be updated from two processes at once. The
download has been changed to a temporary file, which is securely moved
into place over the original.
If retrying the update operation, the original file is no longer
immediately deleted and instead a full download is performed, later
overwriting the original file if successful.
If two processes are updating in parallel, this should ensure the
original file isn't corrupted and that both processes succeed.
- Fixes #4519
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|