-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bumped up nokogiri version. #199
Conversation
@kakuzei since we seem to be lacking a response from MS I think this PR should be changed to include Since nokogiri uses SemVer no client facing changes will occur without a major version change. This would prevent us being back in this situation when 1.13.0 etc. are released. |
Thank you @scsmith for your suggestion. Unless I'm mistaken, if we want to avoid this situation when nokogiri 1.13.0 will be released, the change must be |
@kakuzei I think Thanks for updating, hopefully it gets approved and merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm. Thank you! fwiw, the version bump mitigates a high-severity vulnerability in nokogiri before 1.12.5, so it would be delightful to get this merged sooner rather than later.
@katmsft Can you please merge this? Thank you!! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
Not merging this is now blocking a security update in Nokogiri. |
Gemfile
Outdated
if RUBY_VERSION < "2.4.0" | ||
gem "nokogiri", "~> 1.10.4", :require => false | ||
else | ||
gem "nokogiri", "~> 1.11.0.rc2", :require => false | ||
gem "nokogiri", "~> 1", ">= 1.12.5", :require => false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This breaks all ruby 2.4.x support.
Please change it to:
if RUBY_VERSION < "2.4.0"
gem "nokogiri", "~> 1.10.4", :require => false
elsif RUBY_VERSION < "2.5.0"
gem "nokogiri", "~> 1.11.0.rc2", :require => false
else
gem "nokogiri", "~> 1", ">= 1.12.5", :require => false
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add 2.4.x version support, as 1.11.0 of nokogiri drops the support for it we need to add special elsif
statement for it.
…or equal to 2.5.0
@katmsft Thank you for your review, I made the change you suggested to not break Ruby 2.4.x support |
We can simplify things greatly by just ensuring that the user has any version 1.x of nokogiri where x >= 10, regardless of the version of Ruby: # 😁 GOOD: let users use any nokogiri version above the minimum
gem "nokogiri", "~> 1.10", :require => false Alternatively, if we really do want specific minimum versions per Ruby version (for some reason I don't understand) then we could use: # 😵💫 BAD: specific versions per version of Ruby
if RUBY_VERSION < "2.4.0"
gem "nokogiri", "~> 1.10", :require => false
elsif RUBY_VERSION < "2.5.0"
gem "nokogiri", "~> 1.11", :require => false
else
gem "nokogiri", "~> 1.12", :require => false
end See also #196 (comment) |
The alternative you provide won't work due to 1.11.0 deprecating 2.4.x support. And the proposal you gave might regress some customers' nokogiri version back to those versions with security fix not yet applied, which is also not ideal. |
Ruby gems won't install nokogiri 1.11 on Ruby 2.4 because it's gemspec requires Ruby >= 2.5. It doesn't matter what your gem's requirements are, rubygems enforces this automatically. If you want to allow 1.10 only for Ruby 2.4 and disallow 1.10 for Ruby 2.5+, then go ahead and use the conditional. But please remove the artificial upper bound either way. Just know that if someone really wants to use nokogiri 1.10 on Ruby 2.5+ alongside your gem, Bundler will just resolve to an earlier version of your gem without the restrictions. By being aggressive with your gem requirements, you are actively preventing some subset of your users from upgrading. I understand that you don't want your users to downgrade their version of nokogiri because they install your gems. I want you to know that my applications are in this exact position because of the overzealous requirements of the azure storage gems. Being more straightforward will allow your users the flexibility to upgrade and address security issues quickly, instead of keeping them dependent on your team's release schedule. The irony is that the efforts to force users to upgrade are currently backfiring and preventing us from upgrading. Thank you for your attention and I hope we can all come to a mutually beneficial solution. I want to do what I can to help improve the ecosystem. We are happy with Azure storage and want to continue to use and trust it. |
Thank you very much for your input.
|
I agree, if you mean that we should accept this pull request and release a new version of the gems. Let's get this merged. Thanks! |
Given I have an open security flag set, I advise releasing something that looks decent now rather than waiting. You can release again if you must. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🍦 . Resolves nokogiri security vulnerability CVE-2021-41098 and unblocks other updates that depend on nokogiri due to this gem's nokogiri versioning. I see the requested change was agreed it's not needed. Can we get this released? 🚀 ⭐
Also LGTM 🌟 Any update on when we can get this merged? |
Is this merge blocked because the following 3 gemspecs are missing the RUBY 2.4 support common/azure-storage-common.gemspec Is adding this stanza to those three gemspecs enough to unblock the merge?
|
Yes, that's the main reason, sorry for not posting any update. I'm merging this PR and sending a new one to resolve it instead of waiting for the author's fix. We are also pushing for release soon. |
No description provided.