-
-
Notifications
You must be signed in to change notification settings - Fork 265
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
Add findsecbugs plugin to spotbugs. #361
Conversation
@@ -72,6 +74,7 @@ static Checksum forFile(File file) throws IOException { | |||
/** | |||
* Returns the checksum for the given URL. | |||
*/ | |||
@SuppressFBWarnings(value = "URLCONNECTION_SSRF_FD", justification = "This is only used for managing the jar cache as files, not URLs.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add an assertion that the URL's scheme is file or at least not http/s?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean something like this?
assert url.getProtocol().equalsIgnoreCase("file") : "Non-file URL protocol generating checksum";
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah basically. Might want to support vfs type URLs for some servlet runtimes (JBoss/Wildfly used to do this for files in the war rather than unzipping it like Tomcat/Jetty do).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm concerned here by your comment that there might be other types we might want to also include in the assert. That was why I was reluctant to add the assertion initially. I suppose it won't hurt, but since we're not certain about the total set maybe it would be better to leave it off for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks good. Could you add deprecation annotations to the things you noted should be deprecated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a more thorough look through the various warnings. Some need better descriptions, while others could potentially be updated to guard against the bug even if it's not exploitable in the current ecosystem.
src/main/java/org/jenkinsci/remoting/engine/JnlpAgentEndpointResolver.java
Show resolved
Hide resolved
@jvz, thanks for the review! I've updated the PR for many of the findings and responded to some of your comments / questions. Please respond again or take another look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks to be in a generally good state now.
Try building again. |
With a close |
Co-Authored-By: Matt Sicker <boards@gmail.com>
64e8b12
to
8483caa
Compare
Add findsecbugs plugin to spotbugs. And suppress existing warnings. We should clean some of them up, but that's for different PRs at a later time.
Some of the issues findsecbugs just misidentifies. With some it doesn't understand enough context.
As always with these sort of of analysis tools, adding them to existing code correctly can be a bit of a challenge. It's easier to suppress things that aren't really problems than to clean all of them up. Most of the benefit from applying these tools comes from checking newly added code and preventing new issues from creeping in.