[chmodshubham]

Fixes #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]

I have added some more changes based on the Opus 5.5 review. Open for review again

[san-zrl]

Hi @chmodshubham, FYI - I tested the latest version via SonarQube running on docker. I'm still using sonar-scanner 5.0.1 which apparently came with a bundled Java 17 runtime. I had to make it use Java 21 (set JAVA_HOME to my Java 21 jre and set use_embedded_jre=false in sonar-scanner) and set the file suffixes via -Dsonar.cxx.file.suffixes. Maybe this is worth a comment.

Scan result for https://github.com/n1flh31mur/QSimpleCrypto.git:

INFO: ========== CBOM Statistics ==========
INFO: Detected Assets                  : 13
INFO:  - PseudorandomNumberGenerator   : 1
INFO:  - PrivateKey                    : 1
INFO:  - Signature                     : 2
INFO:  - BlockCipher                   : 2
INFO:  - AuthenticatedEncryption       : 4
INFO:  - MessageDigest                 : 3
INFO: =====================================

BTW, the signatures in this example are X509_Sign calls which are detected as 'unknown' signatures.

    {
      "type" : "cryptographic-asset",
      "bom-ref" : "3947c150-7367-41eb-aaa2-a15613df0c2d",
      "name" : "unknown",
      "evidence" : {
        "occurrences" : [
          {
            "location" : "src/sources/QX509.cpp",
            "line" : 65,
            "offset" : 13,
            "additionalContext" : "X509_sign"
          },
          {
            "location" : "src/sources/QX509.cpp",
            "line" : 191,
            "offset" : 13,
            "additionalContext" : "X509_sign"
          }
        ]
      },
      "cryptoProperties" : {
        "assetType" : "algorithm",
        "algorithmProperties" : {
          "primitive" : "signature",
          "cryptoFunctions" : [
            "sign"
          ]
        }
      }
    },

[chmodshubham]

Hi @chmodshubham, FYI - I tested the latest version via SonarQube running on docker. I'm still using sonar-scanner 5.0.1 which apparently came with a bundled Java 17 runtime. I had to make it use Java 21 (set JAVA_HOME to my Java 21 jre and set use_embedded_jre=false in sonar-scanner) and set the file suffixes via -Dsonar.cxx.file.suffixes. Maybe this is worth a comment.

I have added a .md file that I use for running with SonarQube and also updated the README.