Skip to content

Java: Replace incorrect usage of Literal.getLiteral()#6612

Merged
aschackmull merged 2 commits intogithub:mainfrom
Marcono1234:marcono1234/literal-getLiteral-usage
Sep 16, 2021
Merged

Java: Replace incorrect usage of Literal.getLiteral()#6612
aschackmull merged 2 commits intogithub:mainfrom
Marcono1234:marcono1234/literal-getLiteral-usage

Conversation

@Marcono1234
Copy link
Copy Markdown
Contributor

@Marcono1234 Marcono1234 commented Sep 4, 2021

Literal.getLiteral() returns the string representation of the literal the way it was written in source. This is rarely desired by queries and there were a few cases where it was used erroneously.

Notable changes:

  • Improves documentation for Literal.getLiteral()
  • Fixes Annotatable.suppressesWarningsAbout(string) using getLiteral().
    This might be a breaking change for third party queries, however the current state is somewhat broken:
    • It contains the enclosing double quotes of the string
    • It contains Unicode escapes the way they are written in source instead of the value they represent
  • Fixes BooleanLiteral.getBooleanValue() using getLiteral().
    This caused it to not work when a boolean literal was written using Unicode escapes (which are replaced during pre-processing), e.g. boolean b = \u0074\u0072\u0075\u0065;. A test for this will be added by the follow-up pull request Java: Split literals tests #6613.
  • Replaces some usages of StringLiteral.getValue() with getRepresentedString(). The result is the same (getRepresentedString delegates to getValue), but it might make the intention clearer.
  • Improves MagicConstants.qll (please let me know if this should be a separate pull request):
    • Replaces some usage of getLiteral()
    • Changes isNumber to check for NumericOrCharType. Note that this changes functionality because previously it did not consider byte, not sure if that was an oversight.
    • Changes intTrivial and longTrivial to remove _ from literal and to check for lowercase l for long literals.

lit.getType().getName() = "float" or
lit.getType().getName() = "double"
}
predicate isNumber(Literal lit) { lit.getType() instanceof NumericOrCharType }
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes behaviour by adding byte and boxed types

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is what I mentioned in the description. Sorry, would probably have been better to add a comment instead.
Was it intentional that byte was excluded? (I can also revert the change though)

Boxed types should not be an issue (except for performance?) because literals are always primitive, except for String but that is not a numeric type.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's fine to include byte. The dependent queries are low-precision recommendation queries so it doesn't matter too much.

aschackmull
aschackmull previously approved these changes Sep 7, 2021
@aschackmull aschackmull added the no-change-note-required This PR does not need a change note label Sep 7, 2021
@aschackmull
Copy link
Copy Markdown
Contributor

Additionally,

  FAILED: /home/runner/work/semmle-code/semmle-code/ql/java/ql/test/query-tests/security/CWE-327/semmle/tests/BrokenCryptoAlgorithm.qlref
  FAILED: /home/runner/work/semmle-code/semmle-code/ql/java/ql/test/query-tests/security/CWE-327/semmle/tests/MaybeBrokenCryptoAlgorithm.qlref

and there's also an internal qltest that's failing.

@Marcono1234
Copy link
Copy Markdown
Contributor Author

Have fixed the test failures, please let me know if the changes are fine.
The output of BrokenCryptoAlgorithm and MaybeBrokenCryptoAlgorithm now does not enclose the algorithm name in double quotes anymore (since it is not using getLiteral() anymore), is that alright?

Does the change to Annotatable.suppressesWarningsAbout(string) need a change note? It might break existing queries which are expecting the enclosing double quotes. Though usage of that predicate is probably not that common.

@Marcono1234 Marcono1234 force-pushed the marcono1234/literal-getLiteral-usage branch from d9ce781 to 37268bd Compare September 11, 2021 01:10
result =
[
"RSA", "SHA256", "SHA512", "CCM", "GCM", "AES([^a-zA-Z](?!ECB|CBC/PKCS[57]Padding)).*",
"RSA", "SHA256", "SHA512", "CCM", "GCM", "AES(?![^a-zA-Z](ECB|CBC/PKCS[57]Padding))",
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.* does not seem to be necessary here because the algorithmRegex predicate will add that.

Also, is there a reason why these queries use rank[...] and max instead of concat to concat the algorithm names? Should I replace that?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No good reason AFAICT, it's not important though

@smowton
Copy link
Copy Markdown
Contributor

smowton commented Sep 16, 2021

An internal test is failing because this changes the observed behaviour of annotations' get-value methods. Made an internal PR to update it.

@smowton smowton force-pushed the marcono1234/literal-getLiteral-usage branch from 37268bd to 020aa4d Compare September 16, 2021 13:11
@aschackmull aschackmull merged commit a67db45 into github:main Sep 16, 2021
@Marcono1234 Marcono1234 deleted the marcono1234/literal-getLiteral-usage branch September 17, 2021 19:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Java no-change-note-required This PR does not need a change note

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants