Using another formatter

[vsalbaba]

How would I go about outputing brakeman into html file? The text output is almost unreadable. Is this supported via guard block options, or is this not implemented?

In vanilla brakeman, I would use

 brakeman -f output.html

[oreoshake]

+1 adding this now
On Feb 13, 2012 6:26 AM, "Vojtech Salbaba" <
[email protected]>
wrote:

How would I go about outputing brakeman into html file? The text output is
almost unreadable. Is this supported via guard block options, or is this
not implemented?

In vanilla brakeman, I would use

brakeman -f output.html

---

Reply to this email directly or view it on GitHub:
#1

[vsalbaba]

Thanks for quick reaction. It outputs to file every time, but on second and so on runs it outputs also into the console. Can you have a look into this?

[oreoshake]

I'm just wondering if specifying an output_file should imply that there shouldn't be any stdout or it should be a separate option.

guard 'brakeman', :output_file => 'brakeman.html', :no_console_output => true do 

The problem is that the standard brakeman report doesn't give you any diff context so the stdout is incredibly useful which is why I left it in there. Because of this, I'm thinking it should be a separate config option that suppresses the guard-brakeman stdout.

[vsalbaba]

You are the owner, and this is opensource, therefore it can do whatever you like :)

On more serious note, that is a good idea. I was thinking about it, and IMHO a good idea is:

• support "cli" option ala guard-rspec (passes its arguments directly to rspec command), killing two birds with one stone just like that
• support no_console_output, allowing to suppress output if needed.

I do realize that on ideal project it is ok to output to console, because there are no errors to output. But warnings, errors and bugs come hand in hand, and when rails_best_practices, brakeman, cucumber and rspec all report at once ... Sometimes my console buffer is not enough to read em all.

[oreoshake]

Sorry to leave this hanging for so long...

I totally support your ideas, especially the no_console_output. This will be done.

The only reason I chose not to go down the cli route like most other guards is that we would not be able to take advantage of the rescanning capabilities of brakeman, essentially making the guard-brakeman task take much longer than it should. This is due to the fact that the "analyze" phase of brakeman is the biggest time sink. The actual checking for vulnerabilities is lightning fast (especially in JRuby land). This was a tough decision, but having a guard that takes longer than a few seconds seems unacceptable.

Case study:

brakeman . takes 2m30s
brakeman --compare takes another 2m30s

5 minutes each cycle

guard_brakeman
setup: 2 minutes 15 seconds
rescan: 20 seconds

2m15s up front,
20s each cycle

So unfortunately, I think I'll be adding features piecemeal, matching up to the brakeman internals (and would gladly take any contribution on this front). I totally admit this is janky and needs to be redone. e.g. the -w flag is implemented as the :min_confidence argument which acts as the inverse to the -w flag. Even I had to refer to the docs to set my correct threashold :-/