livingsocial / bundler-patch Goto Github PK

View Code? Open in Web Editor NEW

65.0 65.0 3.0 321 KB

Update your gems conservatively to deal with vulnerable gems or just get more current.

License: MIT License

Ruby 99.89% Shell 0.11%

bundler plugin vulnerable-gems

bundler-patch's People

Contributors

Stargazers

Watchers

Forkers

chrismo jasnow isabella232

bundler-patch's Issues

Research the --source hack

rubygems/bundler#2016, rubygems/bundler#3759

Doesn't appear to work 1.10.x, but does work in 1.9.x.

Slop 4 is going to be a problem

pry uses slop 3.x -- there is a commit to inline it, since slop 4 isn't backward compatible, but that's not released yet, and then won't get out into dependencies (like guard) for a while. I'm not doing that much with slop, prolly better to fall back to slop 3.

BUG: Updating Gemfile for vuln update left line with incorrect syntax

gem 'rubyzip', '~> 1.1', require: 'zip' => gem 'rubyzip', '~> 1.2' require: 'zip'

No comma after the requirement anymore. Whoops.

`--dry-run` to match outdated pretty & parseable

patch vulnerable not handling 4 digit version properly

CVE-2016-4658 came out, saying >= 1.7.1 is patched, but this tool is only bumping 1.6.8 to 1.6.8.1

Don't keep re-executing target shell if rubies match.

Ensure cache is updated after gems installed

~~Currently bundler-patch doesn't install new gems, which if vendor/cache is in play, means a bundle command must be issued separately.~~

Whups! Installation already happens - but the step AFTER it to update the cache is missing. The comment below is still valid, but ... prolly I guess fix this up in bundler-patch.

If I change the Gemfile requirement to older gem, bundle patch doesn't work

Not sure if it should in this case, since bundle itself should be fine?

Change underscore options to hyphens

Should it prevent reverting to older versions?

It currently still does that. I had a TODO to remove the note in the README, but the code is still there. I remmed out the functionality, but no tests failed (whoops) ... anyway. Bundler 1.13.0.rc.2 added a new option for bundle update to NOT regress ... so consider that too.

Ruby version updates shouldn't touch the file

A ruby app with .ruby-version 2.3.1, run bundle patch -v -r --rubies 2.3.1 - no content changes, BUT the timestamp on the .ruby-version file is touched. That will cause the git library to detect that change, even though CLI won't see it.

Minor, minor issue - but came across it inside LivingSocial

--ruby AND --rubies is redundant - both are required now.

Perhaps should just kill off the -r / --ruby switch - or don't require it if --rubies is provided.

Warn on major version update

Bundler has this issue rubygems/bundler#4515 - would make sense here as well, both for #13 and #14.

Haven't figured out what to do if no Ruby version in Gemfile[.lock] and no .ruby-version.

Reflect to stdout the open3 stuff.

Is there an option for this with capture3?

Cannot issue `bundle patch -h`

bundle patch help works, but with 1.12.5, the -h isn't passed through properly:

Bundler version 1.12.5
[chrismo@momac crack (master)]$ bundle patch -h
/Users/chrismo/.rbenv/versions/2.3.1/bin/ruby: warning: RUBY_HEAP_MIN_SLOTS is obsolete. Use RUBY_GC_HEAP_INIT_SLOTS instead.
Could not find command "patch -h".
[chrismo@momac crack (master)]$ bundler-patch -h
/Users/chrismo/.rbenv/versions/2.3.1/bin/ruby: warning: RUBY_HEAP_MIN_SLOTS is obsolete. Use RUBY_GC_HEAP_INIT_SLOTS instead.
Bundler Patch Version 0.7.2

New option to only update "proven" gems by date.

If I use bundler-patch in an automated process to keep me up-to-date on patched gems, I may not want to use a new gem version the day after it's released. Maybe I'd like to be a week or a month behind, to give it time to "prove" itself.

Implementation on this would be sketchy depending on access to the gem's release date.

--gemfile option can take a dir and just blink atchya

$ bundler-patch -l --gemfile /tmp/bundler
No known vulnerabilities to update.
$ bundler-patch -l --gemfile /tmp/bundler/Gemfile

Detected vulnerabilities:
-------------------------
rack ["1.6.2", "1.5.4", "1.4.6", "1.1.6", "1.2.8", "1.3.9"]

Fully support Bundler 2

Make sure all specs pass
use target ruby is wrong in 2.3
See if you can re-enable 1.9 and 1.10 support in Travis.

--minor_preferred --strict_updates still allow a major version increment

-    crack (0.4.1)      +    crack (0.4.3)
-      safe_yaml (~> 0.9.0)     +      safe_yaml (~> 1.0.0)
-    safe_yaml (0.9.4)      +    safe_yaml (1.0.4)

not 100% that those flags made it through, so need to recreate in isolation.

Consider PR to bundler proper for conservative upgrade

Support dry-run / outdated behavior to list what would be done

Output options in play

Be nice to confirm the options in effect in the header output

why this WARN output?

WARN: Unresolved specs during Gem::Specification.reset:
      rake (>= 0)
      json (>= 0)
      rack (>= 0)
      ...
WARN: Clearing out unresolved specs.
Please report a bug if this causes problems

Support --gemfile argument

If wanting to patch from a different current directory, bundle install will work with --gemfile command line switch, be nice if bundler-patch was consistent.

change bin to `bundler-patch` from `bundle-patch`

via @mattr- Hooks into Bundler's execution system to run the script.

Sooooo, I found out that Bundler works a bit like git. You can extend it by having executables in the $PATH that are prefixed with bundler- and then they become subcommands of bundler itself.

This changes the command name from bundle-patch to bundler patch, which seems 👍 to me. Don't know if we really want to do that but I'm throwing it out there anyways.

Support all bundler-patch commands without installing gems

There is a bundle lock command (introduced in rubygems/bundler#3439) that will do exactly like bundle update (update lockfile without installing any gems).

Should we add --patch support to the lock command?

What's great about this lock command is that you can update your lockfile with a script, and let the script send the changes of lockfile to open a Pull Request, and your CI will run to know if anything went wrong.

So more for automation consumers. :)

Not looking in target directory for .ruby-version if --gemfile?

$ bundler-patch --gemfile /tmp/bundler/Gemfile  --use-target-ruby
/Users/chrismo/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/bundler-patch-1.1.0.pre2/lib/bundler/patch/target_bundle.rb:31:in `read': No such file or directory @ rb_sysopen - .ruby-version (Errno::ENOENT)
	from /Users/chrismo/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/bundler-patch-1.1.0.pre2/lib/bundler/patch/target_bundle.rb:31:in `ruby_version'
	from /Users/chrismo/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/bundler-patch-1.1.0.pre2/lib/bundler/patch/target_bundle.rb:42:in `ruby_bin'
	from /Users/chrismo/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/bundler-patch-1.1.0.pre2/lib/bundler/patch/target_bundle.rb:67:in `ruby_bin_exe'
	from /Users/chrismo/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/bundler-patch-1.1.0.pre2/lib/bundler/patch/cli.rb:72:in `patch'
	from /Users/chrismo/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/bundler-patch-1.1.0.pre2/lib/bundler/patch/cli.rb:45:in `execute'
	from /Users/chrismo/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/bundler-patch-1.1.0.pre2/bin/bundler-patch:10:in `<top (required)>'
	from /Users/chrismo/.rbenv/versions/2.3.3/bin/bundler-patch:22:in `load'
	from /Users/chrismo/.rbenv/versions/2.3.3/bin/bundler-patch:22:in `<main>'

Align options with bundler patch-level options

The names are too verbose in bundler-patch and don't align very well.

--gemfile without --use-target-ruby should warn if different Ruby.

Because otherwise it will install with executing Ruby, look successful, then CD into the dir and it may be broken because it can't find the gems.

Possible once this is all supported properly that --use-target-ruby is removed.

Update BUNDLER.md now that 1.14 is out

Prolly just remove the doc, and link over to official docs from README.md

No option to use `-v` AND a list

which was the intent of the flag - but currently am wanting to feed it -v AND rails since none of the security vulns show up with rails, but always with dependent gems, but dependent gems (in Rails apps) are usually NOT in the Gemfile.

Only workaround is to add a custom vuln .yml for rails itself in a custom advisory dir

Redo the command names

currently,

bundle-patch scan
bundle-patch patch
bundle-patch update

First two are security vulnerability related. Third is a general update.

These names aren't necessarily the best, and if going forward we make this a bundler plugin, then would be nice to stick all of those options underneath patch itself. So, here's an issue I can think out loud about it.

Here's all the options on the 3 commands currently:

  -a, --advisory_db_path  Optional custom advisory db path.
  -g, --gems_to_update  Optional list of gems to update, in quotes, space delimited
  -m, --minor_allowed     Upgrade to the latest minor.release version.
  -s, --strict            Do not allow any gem to be upgraded past most recent release (or minor if -m used). Sometimes raises VersionConflict.

Vulnerability code will update gem requirement, broaden into an option.

I think for our purposes internally, 'twould be good to add the requirements tweaking that the vulnerability code will do as an option to be applied to all gems_to_patch.

Prolly a separate ticket: consider option to feed specific versions from the command line, same as is read from advisories.

If `-m` not used, but only minor increase is available, it looks like maybe it's broken since there's no feedback.

bundler-patch 0.7.2

* Could not attempt upgrade for mail from 1.0.0 to any patched versions 2.6.0, 2.2.15, 2.4.4. Most often this is because a major version increment would be required and it's safer for a major version increase to be done manually.
No known vulnerabilities to update.
Updating 'mail' conservatively.
Fetching gem metadata from https://rubygems.org/..............
Fetching version metadata from https://rubygems.org/..
Resolving dependencies...
Using mime-types 2.0
Using polyglot 0.2.5
Using treetop 1.4.1
Using mail 1.0.0
Using bundler 1.10.6

My first concern was the vuln warning was interfering, but it turns out there is no release version increment available for mail 1.0.0 - the next version is 1.1.0.

Support 1.11.x of Bundler

/Users/chrismo/.rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/gems/bundler-1.11.2/lib/bundler/resolver.rb:187:in `initialize': wrong number of arguments (3 for 4) (ArgumentError)
    from /Users/chrismo/.rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/gems/bundler-patch-0.7.0/lib/bundler/patch/conservative_definition.rb:19:in `new'
    from /Users/chrismo/.rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/gems/bundler-patch-0.7.0/lib/bundler/patch/conservative_definition.rb:19:in `resolve'
    from /Users/chrismo/.rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/gems/bundler-1.11.2/lib/bundler/definition.rb:137:in `specs'
    from /Users/chrismo/.rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/gems/bundler-1.11.2/lib/bundler/definition.rb:126:in `resolve_remotely!'
    from /Users/chrismo/.rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/gems/bundler-1.11.2/lib/bundler/installer.rb:194:in `resolve_if_need'
    from /Users/chrismo/.rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/gems/bundler-1.11.2/lib/bundler/installer.rb:69:in `run'
    from /Users/chrismo/.rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/gems/bundler-1.11.2/lib/bundler/installer.rb:21:in `install'
    from /Users/chrismo/.rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/gems/bundler-patch-0.7.0/lib/bundler/patch/cli.rb:61:in `conservative_update'
    from /Users/chrismo/.rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/gems/bundler-patch-0.7.0/lib/bundler/patch/cli.rb:107:in `_patch'
    from /Users/chrismo/.rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/gems/bundler-patch-0.7.0/lib/bundler/patch/cli.rb:50:in `patch'
    from /Users/chrismo/.rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/gems/bundler-patch-0.7.0/lib/bundler/patch/cli.rb:26:in `execute'
    from /Users/chrismo/.rbenv/versions/2.1.7/lib/ruby/gems/2.1.0/gems/bundler-patch-0.7.0/bin/bundler-patch:10:in `<top (required)>'
    from /Users/chrismo/.rbenv/versions/2.1.7/bin/bundler-patch:23:in `load'
    from /Users/chrismo/.rbenv/versions/2.1.7/bin/bundler-patch:23:in `<main>'```

$ grep rails Gemfile
  gem 'rails', '4.2.6'

Detected vulnerabilities:
-------------------------
rails ["3.2.22.2", "4.1.14.2", "4.2.5.2"]

Checkout https://github.com/joonty/pessimize

https://github.com/joonty/pessimize

Port behavior to bundler 2

2-0-dev-update is the current branch for 2.0 code.

unify bundler outdated code? in 1.12 it got some upgrades with --major, --minor, and --patch flags
2.0 allows breaking, so make the default level patch.
Which terminology to use for third version? bundler-patch uses release. outdated uses --patch. SemVer uses patch. Use patch.
with a little refactoring of Bundler, this code could go into Bundler 1.x, though default behavior would have to change to prevent breaking behavior.
update --dry-run to match outdated pretty & parseable
patch includes vulnerable gems - should that behavior go as well? prolly not
if we include vulnerable gems, what about the modification of the Gemfile requirements to fit the patched version? and esp. #7. prolly not

Any additional options that Bundler core team decides to exclude in Bundler can stay in this plugin.

bug running in gem dev

No known vulnerabilities to update.
Updating 'bundler-fixture' conservatively.
Fetching gem metadata from https://rubygems.org/.........
Fetching version metadata from https://rubygems.org/..
/Users/chrismo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/bundler-1.11.2/lib/bundler/resolver.rb:354:in `block in verify_gemfile_dependencies_are_found!': Could not find gem 'bundler-advise' in source at `.`. (Bundler::GemNotFound)
Source contains 'bundler-advise' at: 1.0.3
        from /Users/chrismo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/bundler-1.11.2/lib/bundler/resolver.rb:330:in `each'
        from /Users/chrismo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/bundler-1.11.2/lib/bundler/resolver.rb:330:in `verify_gemfile_dependencies_are_found!'
        from /Users/chrismo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/bundler-1.11.2/lib/bundler/resolver.rb:199:in `start'
        from /Users/chrismo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/bundler-patch-0.7.2/lib/bundler/patch/conservative_definition.rb:36:in `resolve'
        from /Users/chrismo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/bundler-1.11.2/lib/bundler/definition.rb:137:in `specs'
        from /Users/chrismo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/bundler-1.11.2/lib/bundler/definition.rb:126:in `resolve_remotely!'
        from /Users/chrismo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/bundler-1.11.2/lib/bundler/installer.rb:194:in `resolve_if_need'
        from /Users/chrismo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/bundler-1.11.2/lib/bundler/installer.rb:69:in `run'
        from /Users/chrismo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/bundler-1.11.2/lib/bundler/installer.rb:21:in `install'
        from /Users/chrismo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/bundler-patch-0.7.2/lib/bundler/patch/cli.rb:59:in `conservative_update'
        from /Users/chrismo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/bundler-patch-0.7.2/lib/bundler/patch/cli.rb:105:in `_patch'
        from /Users/chrismo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/bundler-patch-0.7.2/lib/bundler/patch/cli.rb:48:in `patch'
        from /Users/chrismo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/bundler-patch-0.7.2/lib/bundler/patch/cli.rb:26:in `execute'
        from /Users/chrismo/.rbenv/versions/2.2.3/lib/ruby/gems/2.2.0/gems/bundler-patch-0.7.2/bin/bundler-patch:10:in `<top (required)>'
        from /Users/chrismo/.rbenv/versions/2.2.3/bin/bundler-patch:23:in `load'
        from /Users/chrismo/.rbenv/versions/2.2.3/bin/bundler-patch:23:in `<main>'