search

code-star / sbt-findsecbugs

An SBT plugin for FindSecurityBugs
MIT License
7 stars 6 forks source link

RFC: add support for checks outside findsecbugs-plugin #30

Closed nigredo-tori closed 5 years ago

nigredo-tori commented 5 years ago

At the moment this project focuses on findsecbugs-plugin, and ignores many useful checks from the core SpotBugs. This is pretty narrow. We can provide support for other plugins without much bloat.

  1. Generalize pluginList resolution, expose this as a setting.
  2. Support providing a custom filter file (or not providing one at all).
  3. Support tweaking the SpotBugs command line.

We can do all of these without changing the default behavior (although in the long run it would be cleaner to default to what SpotBugs does - no plugins, no filter files and so on).

I realize that this changes the scope of this project to overlap that of https://github.com/sbt/sbt-findbugs and https://github.com/josephearl/sbt-findbugs. Both of these seem to be dead, though, so having a leaner, actively maintained alternative would be nice.

@jqno, would you be open to a PR that does this?

jqno commented 5 years ago

I'm in doubt. I've tried FindBugs on Scala code back in the day and got a LOT of false positives from it. I don't know if the situation has improved in the mean time. The intent of this project has always been to be a wrapper around the find-sec-bugs project, so integrating SpotBugs was necessary for doing that. We didn't do it for SpotBugs's own sake. Did you have a specific set of SpotBugs checks in mind?

nigredo-tori commented 5 years ago

I'm new to FindBugs/SpotBugs, so I don't have a specific set of checks in mind. My goal at the moment is to check as much aspects of my code as I can. I'm OK with a few silenced false positives here and there, as long as there are enough true positives to justify enabling the rule. Also, I have Java code in some legacy parts, and I'd like to tighten that up as well.

This brings me to this issue. Basically, I'm in the market for a thin wrapper over SpotBugs, that won't impose additional constraints on what checks I can enable. From what I can gather, there's a choice between https://github.com/josephearl/sbt-findbugs/ (which seems to be dead, and which looks too heavy-handed for my liking), https://github.com/sbt/sbt-findbugs (definitely dead), and this project (actively supported, lean enough, but focused on a single plugin).

If this project's scope is, indeed, only limited to find-sec-bugs, then I'm going to have to roll something of my own. In which case I'll probably end up forking this, and generalizing it as described above. To that end, could you please provide a license for this project?

jqno commented 5 years ago

When I last checked, FindBugs choked in the fact that Scala's bytecode looks very different from Java's bytecode, so a great many of their checks resulted in garbage. I welcome you to give it a try but I soon gave up. You're probably much better off using something like WartRemover, which is specific for Scala. I've been a happy user for several years.

You're welcome to fork this project. I have to talk to my coworkers about the license though, so I'll get back to you on that.

nigredo-tori commented 5 years ago

@jqno, we use WartRemover extensively throughout our projects, and will continue to do so. However, there are a lot more checks in SpotBugs, and I'm under orders to jam as much static analysis into our projects as I possibly can, so it's going to be both :smile:.

jqno commented 5 years ago

OK, good luck to you then 😄 Please let me know how SpotBugs works out for you though? I'm very curious!

Also, I've just added an MIT license to the project, which should enable you to make the fork you want.

jqno commented 5 years ago

By the way, I just published a release that contains your other PR's: version 0.13.