fixed #12517 - added initial safety guide [skip ci]

[firewave]

No description provided.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[firewave]

As a side note - I am considering making the tree read-only in the CI before invoking the selfchecks. Clearing PATH and explicitly specifying the Python executable is also something to consider. Will file a ticket later.

There's possibly a few more tickets which can come out of this guide.

[firewave]

As a side note - I am considering making the tree read-only in the CI before invoking the selfchecks. Clearing PATH and explicitly specifying the Python executable is also something to consider. Will file a ticket later.

I filed https://trac.cppcheck.net/ticket/14382#ticket and https://trac.cppcheck.net/ticket/14383 about this.

[sonarqubecloud]

Please retry analysis of this Pull-Request directly on SonarQube Cloud

[danmar]

I don't understand the exact purpose of this document. Is it for developers or for certain users or both?

[danmar]

from the ticket:

• the processes which will be invoked (python, clang, clang-tidy, etc.)
• required permissions and controlling them (e.g. #14237)
• what files will be written and controlling where they will be written

these would be interesting to a security department when determining if Cppcheck is allowed.. is this a purpose? If we use processes or threads does not seem interesting to them right? but others could be interested in that.

[danmar]

these would be interesting to a security department when determining if Cppcheck is allowed

for the security department it would be interesting to know what network connections we use.. but that info might be out of scope for "safety" I guess.

[firewave]

these would be interesting to a security department when determining if Cppcheck is allowed.. is this a purpose?

The purpose is to document how to harden the environment in which Cppcheck is run. It is unlikely that somebody will leverage a memory error in Cppcheck to execute an exploit. But the job could be compromised in another way and it makes sense to be able to minimize the attack vector.

I plan to use this information (along with other best practices) to write a reference GitHub action (maintained externally so it doesn't fall under the GPL).

If we use processes or threads does not seem interesting to them right? but others could be interested in that.

That is a technical detail. The important part is that the main process will be intact and you will get a result. And that is what the section should say. I will try to re-phrase that in a more common way

these would be interesting to a security department when determining if Cppcheck is allowed

for the security department it would be interesting to know what network connections we use.. but that info might be out of scope for "safety" I guess.

Good point. I only wrote it from the view of the CLI. The GUI has the update check if I recall correctly.

[danmar]

Good point. I only wrote it from the view of the CLI. The GUI has the update check if I recall correctly.

ok I have the feeling that the GUI does not use any network connections but please feel free to check. I know cppcheclipse does have an update check.

[firewave]

ok I have the feeling that the GUI does not use any network connections but please feel free to check. I know cppcheclipse does have an update check.

The GUI contains an online version check - you added it yourself in 94c3108.

[danmar]

It might be worth talking about what happens if the analysis of a file is aborted (when there is some kind of critical error). In CI I would say that --safety could be a good idea. In IDEs where analysis happens during editing I think that --safety is not a good idea.