[Security] Bump rubyzip from 1.2.1 to 1.2.2

[dependabot-preview]

Bumps rubyzip from 1.2.1 to 1.2.2. This update includes security fixes.

Vulnerabilities fixed

Sourced from The Ruby Advisory Database.

Directory Traversal in rubyzip
rubyzip version 1.2.1 and earlier contains a Directory Traversal vulnerability
in Zip::File component that can result in write arbitrary files to the filesystem.
If a site allows uploading of .zip files, an attacker can upload a malicious file
which contains symlinks or files with absolute pathnames "../" to write arbitrary
files to the filesystem.

Patched versions: >= 1.2.2
Unaffected versions: none

Commits

• d07b13a Merge pull request #376 from jdleesmiller/fix-cve-2018-1000544
• fd81bd5 Bump version to 1.2.2
• cf35774 Bump version to 1.3.0
• ffb374c Bump version to 2.0.0
• 8a1de58 Expand from root rather than current working directory
• 3dd165b Disable symlinks and check for path traversal
• ffebfa3 Consolidate path traversal tests
• 9c468f3 Add jwilk's path traversal tests
• 0586329 Trigger CI again
• cf71583 Move jruby to allow failures matrix till crc uint 32 issues are resolved
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Note: This repo was added to Dependabot recently, so you'll receive a maximum of 5 PRs for your first few update runs. Once an update run creates fewer than 5 PRs we'll remove that limit.

You can always request more updates by clicking Bump now in your Dependabot dashboard.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge
• @dependabot reopen will reopen this PR if it is closed
• @dependabot ignore this [patch|minor|major] version will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Pull request limits (per update run and/or open at any time)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

Finally, you can contact us by mentioning @dependabot.

[PierreMesure]

This one is not great because it's only updating rubyzip in Gemfile.lock. I personally generate this file myself so I don't get these updates, unless I manage to keep track of all these silent updates manually. And that's probably a problem that all the forks which use Gemfile_custom to add their own gems have.

What do you think @greysteil? Is there any good practice for this? A simple solution would be to update the parent dependency (selenium in that case) but what do you do when you can't and you still want these security fixes?

[greysteil]

Ah, interesting. That's a little tricky for Dependabot - it's used to the Gemfile.lock being a source of truth, not something that users will override.

I think the best solution here is to promote rubyzip to a top-level dependency, with a comment about why that's been done, but that's not something that Dependabot is going to be capable of knowing 😞

[PierreMesure]

I don't think anything has been overridden by the developers here, Dependabot updated a subdependency of Selenium, which is also outdated. I understand why it might be justified (security fix) but this is not something that a human would do, they would probably try to update Selenium.

Regarding the solution you recommend, I feel like it's not a good practice to keep a subdependency in the Gemfile, it might become useless if the parent dependency doesn't use it in a later update. Optionally, that could be something that you bot could keep track of but that seems too complicated and intrusive.

My 2 cents is that Dependabot shouldn't open pull requests to update dependencies that are not in the Gemfile. When it detects a subdependency with a security fix, it should create a pull request for the parent dependency (selenium here) and emphasise (with the security label and a mention in the PR message) why the update is important. Optionally, there could be a command to create a PR for just that subdependency if the developers don't want to update the parent but want to patch the vulnerability. This way, updating the Gemfile.lock without the Gemfile would always be a choice of the developer.

[greysteil]

I don't think anything has been overridden by the developers here

Sorry, perhaps I wasn't clear - I thought you said in your previous comment that you regenerate the Gemfile.lock yourself? That's what I meant by overwriting it.

In this case there's no update available to selenium-webdriver that would ensure a secure version of rubyzip - the requirement on the latest version is still ~> 1.2. What would you want Dependabot to do in that case?