Support for C/C++ Language and OpenSSL library

[chmodshubham]

For detailed reference, follow Issue: #374.

Signed-off-by: Shubham Kumar chmodshubham@gmail.com

[chmodshubham]

Hi @n1ckl0sk0rtge, I have a questtion regarding adding sonar-cxx plugin in parent pom.xml file. Unlike other sonar language plugins, sonar-cxx is not hosted on central maven repository. And currently, I am referencing the plugin from my local maven cache. So, can you suggest what should be the right way to reference here? Should I/cbomkit host the artifacts on github packages and then reference it in pom.xml or add instructions in readme to download the sonar-cxx plugin locally?

[n1ckl0sk0rtge]

Hi @chmodshubham, thanks for the question! I looked a bit around and think JitPack could be a good solution. JitPack builds and serves Maven artifacts directly from GitHub repositories on demand.

Something like that should work:

Add the JitPack repository to the parent pom.xml:

  <repository>    
      <id>jitpack.io</id>                                                                                                            
      <url>https://jitpack.io</url>
  </repository>          

Reference the sonar-cxx dependency using the GitHub coordinates:

  <dependency>                                                                                                                       
      <groupId>com.github.SonarOpenCommunity</groupId>
      <artifactId>sonar-cxx</artifactId>                                                                                             
      <version>{commit-hash-or-tag}</version>
  </dependency>

The first time someone builds, JitPack fetches the source from GitHub, builds it, and caches the artifact. After that it's served like any normal Maven dependency.

This avoids both the manual local install step for every contributor and the maintenance burden of hosting/re-publishing artifacts ourselves. What do you think?

[chmodshubham]

Hi @n1ckl0sk0rtge,

Ohh, nice, this tool is good. It will definitely solve this hosting problem.

Btw, I have also raised the same issue in sonar-cxx, SonarOpenCommunity/sonar-cxx#3037, in the hope that they may host it like other sonar language plugins. Will look how it will resolve, and if it goes well, will not have to put effort on this; otherwise, will do it.

Though this doesn’t look like much work. Good finding. Thanks

[chmodshubham]

Hi @n1ckl0sk0rtge, I have added the jitpack-based artifact build support, and it's working too. And I guess it will take a while to come to a resolution for sonar-cxx on whether to have a gh-pkg hosting or not, so it’s better to keep it this way. We can modify it once it is hosted; until then, we can use this approach.

[san-zrl]

Hi @chmodshubham,

Thank you very much for adding C/C++ language supportm to CBOMkit. This is a long-wanted feature and we greatly appreciate your contributions.

I had a look into the PR and could easily build the code. @n1ckl0sk0rtge - very good idea to use jitpack. I saw that although there is infrastructure for tests in the cpp module, there are no real test cases yet. Could you add test cases for the rules in cpp/src/main/java/com/ibm/plugin/rules?

[chmodshubham]

Could you add test cases for the rules in cpp/src/main/java/com/ibm/plugin/rules?

Hi @san-zrl,

Thanks for the review.

I plan to add the tests by the end of this month or next month. Apologies for the delay. If that's fine, I can raise a separate PR for it so this one doesn't get held up. Let me know if this works.

[san-zrl]

Hi @chmodshubham - no problem. We will start merging when the tests are available. I'll keep this PR open until then.

[chmodshubham]

Ok, sure. That will work.

[chmodshubham]

Hi there,

Apologies for late following up.

I have a quick question: currently, sonar-cxx builds the AST tree after preprocessing, which causes the macros to be expanded to the underlying functions.

For example, SSL_CTX_set_min_proto_version are actually macros that expand to underlying functions like SSL_CTX_ctrl (ref). Therefore, in the detection rule, instead of matching SSL_CTX_set_min_proto_version, I had to match SSL_CTX_ctrl with the appropriate constant (123 / SSL_CTRL_SET_MIN_PROTO_VERSION).

So, does this work, or do I need to find a workaround for it?

[san-zrl]

Hi @chmodshubham - I think this should work. The only challenge I see is when you have macros that expand to multiple lines. In this case the location reporting would break. Don't know if this is an issue for SSL macros.

[chmodshubham]

Hi @san-zrl,

I checked the sonar-cxx code to see how it handles macro expansion, specifically for multi-line macros.

So basically, sonar-cxx doesn't care whether a macro is defined on one line or spread across multiple lines. It reassembles the macro body into one logical line of text. the raw line layout in the header file doesn't matter at all.

For example,
When sonar-cxx finds SSL_CTX_set_min_proto_version in the code, it records its call site location. Then it expands the macro body and creates a new set of tokens for SSL_CTX_ctrl, (, ctx, etc. These new tokens don't hold any meaningful position at the start, not even point to ssl.h. But later, it then overwrites these new token's position with the call site's position. The AST is built from these re-stamped tokens, and that's what the detection rules run on.

So, yes, I also think sticking with writing the detection rules based on the macro expansion should be fine for now.

Moving forward with this!

[chmodshubham]

Hi, thanks for pointing out such issues. I have resolved all of them; here are explanations for some points:

9. Build-time OpenSSL download. Every clean cpp build downloads the OpenSSL 3.6.2 tarball from GitHub and runs perl Configure (cpp/pom.xml), which makes CI flaky and offline builds impossible. A cached download with a checksum, or a committed pruned header subset, would be more robust. (Side note: ${openssl.skip.configure} is defined — the Copilot flag on that was stale.)

I have removed the OpenSSL headers completely from the build. Initially, I was not including these headers in the final jar file (was only testing with the test suite), due to which the sonar-cxx preprocessor was not able to expand the macros properly during scanning. Later, I included them in the jar file, and it worked completely fine during scanning. However, I realized that in the future, as support for more libraries gets added, more headers will need to be included in the jar file, which will keep increasing the final artifact size.

So I checked how other languages are dealing with this, and noticed that they don't include their headers/classpaths at all - yet they're still able to discover findings. The other language libs define the raw APIs (not expanded macros) in the rules and don't include the classpath at all, and are still able to detect the crypto primitives. The only side effect is that the debug logs show something like "preprocessor can't find that path/file" and skip expanding it, which seems fine as long as we're still able to detect the crypto assets. On top of that, this means we no longer need to worry about expanded forms at all.

Let me know your thoughts.

7. No fixture exercises symbol resolution. Every algorithm argument in the fixtures is a direct string literal, so the sonar-cxx 2.3.0 Symbol support you upstreamed (the headline feature of #374) never actually runs in tests. One fixture along the lines of const char* alg = "AES-128-GCM"; EVP_CIPHER_fetch(NULL, alg, NULL); would cover it.

Thanks for pointing this out. On checking sonar-cxx, I realized the symbol resolution API (Symbol/SymbolTable interfaces, accessor methods) was added by me, but nothing actually populated the table — there was no visitor walking the AST to resolve declarations. So I raised another PR on sonar-cxx adding that visitor along with the concrete implementation (such as Symbol/TypeSymbol/VariableSymbol/FunctionSymbol) behind it.

For now, I'm temporarily pointing at my local fork of sonar-cxx so others can test it. Once it's merged upstream, I'll update the pom file to the sonar-cxx repo's commit.

Ready for review again.