6687: Fix assignment in condition. r=colby-swandale a=voxik
I am not sure what is the purpose of this code neither I have idea if the proposed fix is actually correct, but I am quite sure that the condition does not make sense, because the assignment takes priority and therefore the branch is never accessible. So I just take a guess and submitted this PR to open the discussion ;)
Please note this was pointed out by Coverity scan of the Bundler code:
~~~
Error: DEADCODE (CWE-561):
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: cond_return: Condition "nil && Bundler.rubygems().loaded_specs("bundler")", returning "nil". Now the type of "nil && Bundler.rubygems().loaded_specs("bundler")" must be null.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: assignment: Assigning: "loaded_spec" = "nil && Bundler.rubygems().loaded_specs("bundler")".
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: possible_types: At condition "loaded_spec = (nil && Bundler.rubygems().loaded_specs("bundler"))", the type of "loaded_spec" must be null.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: implied_false: "nil" implies that the truth value of "nil" must be false.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: cond_return: Condition "nil && Bundler.rubygems().loaded_specs("bundler")", returning "nil". The truth value of "nil && Bundler.rubygems().loaded_specs("bundler")" must be false.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: truth: At condition "loaded_spec = (nil && Bundler.rubygems().loaded_specs("bundler"))", the truth value of "loaded_spec" must be false.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: dead_error_condition: The condition "loaded_spec = (nil && Bundler.rubygems().loaded_specs("bundler"))" cannot be true.
rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/source/metadata.rb:22: dead_error_line: Execution cannot reach the expression "idx << loaded_spec" inside this statement: "(loaded_spec = (nil && Bund...".
# 20| s.loaded_from = File.expand_path("..", __FILE__)
# 21| end
# 22|-> if loaded_spec = nil && Bundler.rubygems.loaded_specs("bundler")
# 23| idx << loaded_spec # this has to come after the fake gemspec, to override it
# 24| elsif local_spec = Bundler.rubygems.find_name("bundler").find {|s| s.version.to_s == VERSION }
~~~
Co-authored-by: Vít Ondruch <vondruch@redhat.com>
6708: Fix only_update_to_newer_versions regression r=greysteil a=theflow This is my attempt to fix #6529 ### What was the end-user problem that led to this PR? Running `bundle update` with `BUNDLE_ONLY_UPDATE_TO_NEWER_VERSIONS: "true"` resulted in a gem getting downgraded to a really old version in a certain edge case. Ironically it wouldn't get downgraded when `BUNDLE_ONLY_UPDATE_TO_NEWER_VERSIONS` was set to false. ### What was your diagnosis of the problem? My diagnosis was that https://github.com/bundler/bundler/commit/47256d20cb05ebc724ee67173094682153b6b4aa tried to solve the problem of still allowing manual downgrades in the Gemfile while `only_update_to_newer_versions` is true. But introduced a regression that prevented the `additional_base_requirements_for_resolve` method to work as intended: This is the relevant change from that commit that tries to avoid adding the `>=` requirement if the requirement in the Gemfile is different than the requirement in the lockfile (as far as I understand it): ```ruby next requirements if @locked_deps[name] != dependencies_by_name[name] ``` I identified two problems 1. `dependencies_by_name[name]` returns an array of `Bundler::Dependency`, where as `@locked_deps[name]` just returns a single `Bundler::Dependency`. Comparing the two will always be false. 1. `@locked_deps` is always empty in case of `bundle update`. See: https://github.com/bundler/bundler/blob/3d9e6167a7df9ca89a030dfe95c7cdff293e74a9/lib/bundler/definition.rb#L95 ### What is your fix for the problem, implemented in this PR? My fixes: 1. Make sure `dependencies_by_name` is a hash with `Bundler::Dependency` as values 1. Fetch the `@locked_gems.dependencies` again instead of using `@locked_deps` 1. The existing test worked for me with and without the `only_update_to_newer_versions` set to true, I replaced it with a reproduction of the edge case I was investigating (this is as minimal as I could make it) 1. I've added a test for the manual downgrading case. ### Why did you choose this fix out of the possible options? This is the only way I could make these cases work. It's possible there are other edge cases I don't understand. Co-authored-by: Florian Munz <surf@theflow.de>
6707: Run more assertions in more cases r=deivid-rodriguez a=deivid-rodriguez ### What was the end-user problem that led to this PR? I noticed a couple of places where assertions were being excluded and they shouldn't: * One was introduced by me in #6702, where the specs added (and some already present) started being tested only on bundler 2.x. * The other one was introduced in f7414bcb17fe1bd67246021251b5f0527bd6afd1, where one assertion would be run only if a certain env variable was not set. I think it was because of a TravisCI environmental issue that now seems fixed. ### What was your diagnosis of the problem? My diagnosis was that none of these exclusions are necessary. ### What is your fix for the problem, implemented in this PR? My fix is to restore the excluded assertions to all environments and branches. ### Why did you choose this fix out of the possible options? I chose this fix because it seems best to avoid future problems. Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
6686: Output OpenSSL information only when OpenSSL is available. r=segiddins a=voxik It seems that only single OpenSSL availability check should be enough to output or not output the OpenSSL information. I split this into two commits, so you can cherry-pick, in case you want to be more cautious about the availability of specific constants, but since they were introduced in Ruby 1.8.0 (https://github.com/ruby/ruby/commit/78ff3833fb67c8005a9b851037e7), I would not bother. Please note that that this code was pointed out by Coverity scanner (although it is definitely not an error): ~~~ Error: FORWARD_NULL (CWE-476): rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/env.rb:113: null_check: Calling "defined?(OpenSSL)" implies that "OpenSSL" might be null-like. rubygem-bundler-1.16.1/usr/share/gems/gems/bundler-1.16.1/lib/bundler/env.rb:114: property_access: Accessing a property of null-like value "OpenSSL". # 112| out << [" Bin Dir", Gem.bindir] # 113| out << ["OpenSSL"] if defined?(OpenSSL) # 114|-> out << [" Compiled", OpenSSL::OPENSSL_VERSION] if defined?(OpenSSL::OPENSSL_VERSION) # 115| out << [" Loaded", OpenSSL::OPENSSL_LIBRARY_VERSION] if defined?(OpenSSL::OPENSSL_LIBRARY_VERSION) # 116| out << [" Cert File", OpenSSL::X509::DEFAULT_CERT_FILE] if defined?(OpenSSL::X509::DEFAULT_CERT_FILE) ~~~ Co-authored-by: Vít Ondruch <vondruch@redhat.com>
So they are run on bundler 1.x too.
I think this was a bad fix and it's no longer necessary.
6316: Display reason to require sudo r=colby-swandale a=okkez This is useful for non-interactive installation with bundler. ### What was the end-user problem that led to this PR? https://github.com/treasure-data/omnibus-td-agent/issues/166 I could not notice that bundler needs sudo privilege from logs. So I checked bundler code. ### What was your diagnosis of the problem? Bundler does not show the reason to need sudo privilege. ### What is your fix for the problem, implemented in this PR? Display reason to require sudo. ### Why did you choose this fix out of the possible options? If bundler displays reason to require sudo, we can notice permission problems as soon as possible. Co-authored-by: Kenji Okimoto <okimoto@clear-code.com>