-
Notifications
You must be signed in to change notification settings - Fork 732
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
Prevent explicit engine/lib paths from being excluded from app tree #1679
Comments
Agree. |
We also ran into this in ManageIQ/manageiq#21751 where our CI runs with bundler installing gems into The PR above monkey patches brakeman temporarily to only exclude vendor paths that aren't in the requested index fcc927665..d1f0b3a23 100644
--- a/lib/brakeman/app_tree.rb
+++ b/lib/brakeman/app_tree.rb
@@ -205,7 +205,7 @@ module Brakeman
paths.reject do |path|
relative_path = path.relative
- if @skip_vendor and relative_path.include? 'vendor/'
+ if @skip_vendor and relative_path.include? 'vendor/' and @engine_paths.none? { |p| path.absolute.include?(p) }
true
else
EXCLUDED_PATHS.any? do |excluded| The code above works in properly excluding the default global excludes while still allowing our requested engine paths to be scanned. If desired, I can draft a PR and tests to extract the engine_paths and lib_paths into methods if @skip_vendor and relative_path.include? 'vendor/' and !in_engine_path(path) and !in_lib_path(path) } Note, this change is quite inefficient because we need to traverse the engine_paths and lib paths list 2x times where x is the number originally included files to scan. It feels like we could move these various lists: "default includes" and "excludes" and "explicit includes" into 3+ I don't know if my suggested surgical fix expanded for lib and engine paths would be a good first step to resolving this bug. If you're not using lib or engine paths, the performance impact should be minimal. |
I'd be happy if someone wants to dive into this! I did look through the current code and it's not an easy change. Essentially, the excluded paths are the last thing that happens. That makes it difficult to give priority to explicitly-allowed paths. |
Thanks for responding. Yeah, my fix above should be ok although it's not terribly efficient. If that's fine, I can try doing it for "lib" and "engine" paths. I'll try to open a PR with tests soon. We can discuss it there. I do think glob matching of files: "includes" - "excludes" + "lib paths" + "engine paths" would be more efficient but like I mentioned above, there's other caveats like only_files and other details I'm not familiar with. Thanks! |
Fixes presidentbeef#1679 Currently, we find files that match various patterns such as the engine or lib paths and exclude them if they reside in a vendor directory. Instead, we should honor explicitly-allowed paths, even if we're excluding vendor and they reside in a vendor directory. Note, there are several globally EXCLUDED_PATHS such as: /generators, test/, log/ that are still excluded even if they're in opt-in engine/lib paths. This still seems reasonable and a test is included to demonstrate this behavior is unchanged.
Ok, I finally got back to looking at this. Here's the surgical fix: #1699 |
Fixes presidentbeef#1679 Currently, we find files that match various patterns such as the engine or lib paths and exclude them if they reside in a vendor directory. Instead, we should honor explicitly-allowed paths, even if we're excluding vendor and they reside in a vendor directory. Note, there are several globally EXCLUDED_PATHS such as: /generators, test/, log/ that are still excluded even if they're in opt-in engine/lib paths. This still seems reasonable and a test is included to demonstrate this behavior is unchanged.
Related problem description
I was coming up with a workaround for #1677 & hit on adding the path to the gem as an engine path. Happily, it worked great locally. Unhappily, it failed on CI. We're using https://github.com/ruby/setup-ruby, and it configures Bundler to install gems into
vendor/cache
. Brakeman skips overvendor
(good) but also ignores any additional engine or lib paths that matchvendor
(oh no).Description of the solution you'd like
When I specify a lib or engine path in config or a command-line argument, have it be scanned even if it matches one of the reject patterns in
Brakeman::AppTree
.Alternatives you've considered
--no-skip-vendor
Pretty hopeless, some of the gems we're using are tricky for Brakeman to parse & I'd prefer to work on our own code instead of making PRs to third-party projects
This is what we had previously, we're trying to separate the code so it's easier to reuse in other projects
The current workaround, extremely fiddly to explain to other devs how to do it before they run Brakeman locally
Additional context
I'm discussing how to get
ruby/setup-ruby
to not put gems invendor
in ruby/setup-ruby#291The text was updated successfully, but these errors were encountered: