clang 21

[mbrousset-ledger]

…inated-string-initialization being addded to -Wextra in clang 21

Adding build flags for migration to clang-21

Description

Please provide a detailed description of what was done in this PR.
(And mention any links to an issue docs)

Changes include

• Bugfix (non-breaking change that solves an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (change that is not backwards-compatible and/or changes current functionality)
• Tests
• Documentation
• Other (for changes that might not fit in any category)

Breaking changes

Please complete this section if any breaking changes have been made, otherwise delete it.

Additional comments

Please post additional comments in this section if you have them, otherwise delete it.

Auto cherry-pick in API_LEVEL

If requested to port the commits from this PR on a dedicated API_LEVEL branch,
select the targeted one(s), or add new references if not listed:

[ ] TARGET_API_LEVEL: API_LEVEL_25

This will only create the PR with cherry-picks, ready to be reviewed and merged.

Remember:

• The merge will ALWAYS be a manual operation.
• It is possible the cherry-picks don't apply correctly, mainly if previous commits have been forgotten.
• In case of failure, there is no other solution than redo the operation manually...

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.52%. Comparing base (e591d2e) to head (4211d91).
⚠️ Report is 6 commits behind head on API_LEVEL_25.

Additional details and impacted files

@@              Coverage Diff              @@
##           API_LEVEL_25    #1430   +/-   ##
=============================================
  Coverage         82.52%   82.52%           
=============================================
  Files                46       46           
  Lines              5670     5670           
  Branches            774      774           
=============================================
  Hits               4679     4679           
  Misses              934      934           
  Partials             57       57           

Flag	Coverage Δ
unittests	82.52% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ledger-wiz-cspm-secret-detection]

Wiz Scan Summary

Scanner	Findings
Sensitive Data	-
Secrets	-
IaC Misconfigurations	-
SAST Findings	-
Software Management Findings	-
Total	-

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

In general, the fix is to explicitly declare a minimal permissions block rather than relying on repository defaults. Since multiple jobs in this workflow use actions/checkout and artifact upload/download, but none modify repository state (no pushes or PR/issue writes), a conservative and correct choice is to set contents: read at the workflow root. This documents intent and prevents unexpected elevation if org defaults change.

The single best way to fix this without changing functionality is:

• Add a top-level permissions: block near the top of .github/workflows/build_all_c_apps.yml (e.g., after name:), setting contents: read. This applies to all jobs (build-docker, build-docker-full, prepare-matrix, test-build-official, etc.) that don’t override permissions, including the one flagged by CodeQL.
• No per-job overrides are needed based on the shown snippet: jobs only read repository contents and use artifacts and Docker, all of which work with contents: read and the default implicit scopes for artifacts.

Concretely, edit .github/workflows/build_all_c_apps.yml:

• Insert:

permissions:
  contents: read

right after the name: Build all C apps on latest C SDK line (line 1). No imports or other definitions are required.

To fix the problem, add an explicit permissions block that limits the GITHUB_TOKEN to the minimal required scope. This workflow only needs to read repository contents (for actions/checkout in other jobs, if present) and to allow built-in actions to function; it does not need to write to the repo, issues, or pull requests. The safest and clearest fix is to define a root-level permissions block (applies to all jobs) with contents: read. If in the broader file some jobs needed more, they could override it, but we are constrained to the shown snippet and should not widen permissions unnecessarily.

Concretely, in .github/workflows/build_all_c_apps.yml, add:

permissions:
  contents: read

near the top of the workflow, after the on: block (line 10–11) and before jobs: (line 15). This documents and enforces least-privilege for all jobs, including compare, without changing any existing functionality, because all current steps rely only on artifact and local operations, which work with read-only contents permissions.

In general, the fix is to add an explicit permissions block to the workflow (at the top level under name: / on:) or to each job, granting only the minimal GITHUB_TOKEN scopes required. Since the jobs here only read the repository (via actions/checkout) and use artifacts, and do not push commits, manage PRs, or alter releases, they can operate with contents: read. The reusable workflow that receives secrets.GITHUB_TOKEN also typically needs at most read access to the repo unless it’s designed to push or manage PRs.

The single best, minimally invasive change is to add a root-level permissions section that applies to all jobs, right after the on: block. This documents and enforces least privilege without changing the workflow’s functional behavior. A safe baseline is:

permissions:
  contents: read

This aligns with GitHub’s recommended read-only default for most build/test workflows and is sufficient for actions/checkout and the artifact actions being used. No additional imports or dependencies are needed; this is purely a YAML configuration change in .github/workflows/build_all_c_apps.yml.

Specifically:

• Edit .github/workflows/build_all_c_apps.yml.
• Insert a permissions: block after the on: section (after line 10, before the # NOTE comment).
• Set contents: read as the minimal required permission.

To fix this, define explicit, least-privilege permissions for the workflow so that all jobs (including the highlighted build-docker-full job) do not rely on repo/org defaults. This is best done at the workflow root so that all jobs inherit the same minimal permissions, and only expanded if some job later needs more.

In this workflow, the token is only needed for standard operations like actions/checkout and accessing the repository; no job writes to repository contents or issues. Therefore, contents: read is sufficient and aligns with the minimal starting point suggested by CodeQL. We can add:

permissions:
  contents: read

near the top of .github/workflows/build_all_c_apps.yml, at the same indentation level as on: and jobs:. No other code changes, imports, or dependencies are required, and existing functionality (checking out code, using artifacts, building Docker images) remains unchanged because read access to contents is all that is needed.

---

In general, the fix is to explicitly declare a permissions block that grants only the minimal scopes required for this workflow. Since none of the jobs push commits, manage issues, or otherwise modify repository state, they can safely run with contents: read (and no additional write permissions). This both documents intent and ensures the workflow does not accidentally gain more privileges if repo/org defaults change.

The best minimal fix without altering behavior is to add a top-level permissions block near the top of .github/workflows/build_all_c_apps.yml, applying to all jobs, e.g.:

permissions:
  contents: read

This satisfies CodeQL’s requirement and provides least-privilege defaults. None of the shown jobs require more than read access: they build Docker images, download/upload artifacts, run Docker containers, check out code, and call a Python script; these all work with contents: read. No job appears to need write access to PRs, issues, or repository contents. Concretely, insert the permissions block after the on: trigger section (after line 11), before the jobs: key. No imports or additional definitions are required.