-
Notifications
You must be signed in to change notification settings - Fork 603
✨ Update unsafeblock probe to detect use of Java's Unsafe classes #4849
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
base: main
Are you sure you want to change the base?
Conversation
|
This pull request has been marked stale because it has been open for 10 days with no activity |
Looks for references to the classes sun.misc.Unsafe or jdk.internal.misc.Unsafe classes which can bypass the JVM's memory safety features (garbage collection, checks against out-of-bound read and write, etc.). Signed-off-by: Thomas Leplus <thomasleplus@users.noreply.github.com> ci(github): improve performance
|
This pull request has been marked stale because it has been open for 10 days with no activity |
|
This pull request has been marked stale because it has been open for 10 days with no activity |
|
Hi @thomasleplus thanks a lot for the PR and sorry for the long wait here. I think we want coverage of unsafe code blocks in Java added to Scorecard since Scorecard already supports it for other languages, however, given the size of your PR, have you thought of ways to do this with less code? For example, have you explored simple pattern search? At the time of writing, the PR has almost 59k lines of code, and I am not sure the added feature justifies that amount of code. |
|
Hi @AdamKorcz, First let me say that I understand your concern. I considered using a simple regex but the trade off is reliability. The regex might create false positives if it finds an import statement inside commented code for example. With some advanced regex magic, we may be able to exclude some false positives but there are too many to exclude them all (what if the import is inside a string literal, or in an annotation attribute, etc.). I know that it sounds unlike but given a large enough code base, I am sure someone will find an occurrence in their code and complain about it. Only a real Java parser can handle all the cases (except dead code maybe). That's why the equivalent Golang check uses a parser too, it just happens that one was available ready-made whereas I couldn't find a Golang parser for Java, hence my decision to generate one with Antlr. Another option I considered is to use something like go-tree-sitter which supports Java but it would requires the tree-sitter binaries to be either either installed separately or shipped with scorecard. That doesn't seem ideal. I think that my approach has the benefit of being a pure Golang solution. It's definitely a lot of code for just the feature described in this PR but it also means that any future Java check can benefit from the fact that the parser is there if it needs to find more complex code issues. If your main concern is that it is impossible to review that many lines of code, a workaround could be to generate the parser code at build time from the grammar instead of committing it. Ultimately I will respect what you guys as maintainers feel is best for the project. As I said it's a trade-off, there is no perfect answer. If you want me to rewrite this PR with a regex, I can do that. Cheers, Tom |
|
This pull request has been marked stale because it has been open for 10 days with no activity |
What kind of change does this PR introduce?
This PR is adding Java support to the probe introduced by #4499. It looks for references to the classes
sun.misc.Unsafeorjdk.internal.misc.Unsafeclasses which can bypass the JVM's memory safety features (garbage collection, checks against out-of-bound read and write, etc.).Note that the PR includes a Java source code parser generated with Antlr4 that can be reused to add more Java probes and checks in the future.
What is the current behavior?
The probe looks for unsafe patterns in go and c# code.
What is the new behavior (if this is a feature change)?
The probe also looks for unsafe patterns in Java code.
Which issue(s) this PR fixes
Contributes to #3736.
Special notes for your reviewer
Does this PR introduce a user-facing change?
For user-facing changes, please add a concise, human-readable release note to
the
release-note(In particular, describe what changes users might need to make in their
application as a result of this pull request.)