VS Code SonarLint Storage

Hi

Firstly, apologies that there are several questions below. I’ve done a lot of Googling to try to find the answers… I hope somebody can please help.

I have VS Code set up to “talk to” SonarQube.
i.e in Settings.json in VS Code I have

"sonarlint.connectedMode.connections.sonarqube": [  

        {
            "serverUrl": "https://sonar.production.mydomain.com",
            "token": "abcdefabcdefabcdefabcdef",
            "connectionId": "MyConnectionID"
        }

    ],

and

"sonarlint.connectedMode.project": {
     "connectionId": "MyConnectionID",
      "projectKey": "my-project-key"
}

I have an error in a function (which is detailed in the “Problems” tab) and is highlighted with the typical wiggly underline (which in my case is yellow).

I don’t think the error is relevant but here it is anyway:
“Change this code to not perform client-side redirection based on user-controlled data. [+8 locations]”
“SonarQube Taint Analyzer(tssecurity:S6105)”

When I delete the implementation of the function I would expect the error to go away however the yellow underline remains in exactly the same place and the error remains in the Problems tab.

Now, I think this is because of some caching and it made me think of the storage for the connection.
I see there is a storage folder at “C:\Users\myFirstName.myLastName.sonarlint\storage”

Questions:
What’s held in storage?
Can it be safely deleted?
Is VS Code incorrectly caching old errors?
What’s actually happening when I “pair” with the project in SonarQube?
What are the folders “plugins”, “telemetry” and “work” for in “C:\Users\myFirstName.myLastName.sonarlint”
?

Lastly, When I stop my connection to SonarQube (by deleting my “sonarlint.connectedMode.project” config details in settings.json) why is it that the error goes away? I’m guessing different lint settings locally versus SonarQube but how do I get my local lint rules to correspond with those in SonarQube?

Many thanks for any help and advice on this

Hello @James_Whiteley, welcome to the community! And thanks for reporting this.

It seems to me that you are using SonarLint for VSCode in connected mode with a commercial edition of SonarQube - thanks!

Rule tssecurity:S6105 comes from our security engine and relies on a CPU-intensive algorithm that does not run on the local developer’s box; instead, SonarLint will fetch these issues from the latest SonarQube analysis results and show them in your IDE so that you can investigate.

In the particular case of these “SonarQube Taint Analyzer” rules, local changes won’t directly update the analysis results; instead, you would need to trigger a new SonarQube analysis (e.g push the modified code and let your CI run).

(I’m making a note here that we badly need documentation on this feature.)

And to answer your other questions, in connected mode:

  • SonarLint’s storage contains the analyzers downloaded from the server, the quality profile definitions and custom analysis settings that could have an impact on SonarLint (e.g include/exclude filters), as well as issue suppressions (false positive/won’t fix) from the last analysis
  • It can be deleted, and it will be re-created during the next server synchronization
  • VSCode should not be caching errors; what can happen is:
    • SonarLint cannot match a taint vulnerability from the server in the local source code (what happened to you)
    • The open file contains code that cannot be parsed; in this case, the “Problems” view won’t be updated until the next successful analysis
  • When you pair the project in SonarQube, SonarLint will:
    • Use the same versions of the analyzers as those available on the server (including additional languages like PL/SQL and SalesForce Apex)
    • Synchronize rule activation and parameters with the server’s quality profiles, as well as analysis settings
    • Show taint vulnerabilities detected in the latest analysis (when the file that contains the issue’s “sink” is open)
    • Notify about quality gate changes and new issues assigned to you
  • About the folders:
    • plugins caches the analyzers from the server
    • telemetry stores data that is sent once per day to our telemetry solution - you can check what we send in this telemetry sample
    • work stores temporary files generated during local analysis

Jean-Baptiste, thank you so much.

This is exactly the kind of detailed reply that I wanted.

So the most important thing for me is this bit:

" * SonarLint cannot match a taint vulnerability from the server in the local source code (what happened to you)"

So I’ll push to Sonar and hopefully, those local “red herring” errors will disappear.

And then I guess I’ll hope that SonarLint developers are able to create that mapping between “taint vulnerabilities” and SonarLint warnings/errors.

Thanks again. It’s much appreciated.
James

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.