Improve CI security and maintanability

[Harvester57]

Hi !

This PR introduce the following changes to the CI workflow files:

• Update existing Actions versions to their latest releases
• Pin the Actions and Docker images used with their digest, as recommended by GitHub best practices for third party Actions¹. The first pinning was done using SecureRepo² and I verified that they are pointing to the correct commit in each source repos, but I invite you to double check.
• Add a Dependabot configuration file to check for updates daily and automatically open a PR in case of a new release. To avoid opening multiple PRs for each Action, Dependabot is configured to group all updates in one PR.

Let me know if you have any questions or remarks :)

Good weekend everyone !

Footnotes

1. Cf. https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions ↩

2. Cf. https://app.stepsecurity.io/securerepo ↩

[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]

Thanks for your contribution.

I am not in favor of pinning (at least for this project) because it will unnecessary noise (lots of PRs), work (see next point) and might actually cause problems in case we rely on the upstream to be updated to get a fix.

We are usually going with rolling updates on a certain version/branch.

The heightened security is not necessary as we are not automatically uploading/writing to any repo which could be poisoned or secrets which could be exposed (I think the jobs are all read-only). And these changes actually decrease the maintainability.

IMO pinning is also is not making much sense. Sure it might protect from pulling a possibly poisoned version without your knowledge. But if you pin a version and it was already poisoned you need to do manual work to make sure that you will be using the bad version. And if something breaks in the pinned version because of some external dependency you also need to check all the time all the time and update branches so they keep working instead of "fixing itself" when the fix was supplied. And if the bot generates a PR there is not much point for us in checking the changes and they will probably just be merged so they won't pile up - so there is no point on not just using the branch. And the obfuscation by the using the hash instead of a proper version is a really bad thing as it makes things harder to understand - a tag would be better (but those could also be poisoned).

[firewave]

Also bumping a lot of different versions of multiple modules in a single merge is also not great since it makes it harder to bisect potential issues later on and produces less "documentation" via the commit log.

[firewave]

Something that would be very helpful thought, if you could configure dependabot to generate a PR when a new high-level branch (e.g. v4-> v5) is available.

[Harvester57]

Hi firewave, thanks for the feedback, appreciate it

Thanks for your contribution.

I am not in favor of pinning (at least for this project) because it will unnecessary noise (lots of PRs)

Regarding this point, Dependabot is configured to group updates in a single PR opened once a week, and this configuration can be changed to whatever rhythm would work for you. I specifically chose this configuration to avoid too much noise in the first place ;)

We are usually going with rolling updates on a certain version/branch.

Only for Cygwin and ClusterFuzz, if I'm not mistaken ? While I understand the logic for ClusterFuzz (it's the recommended way in the documentation, and they do not version using tags AFAICT), I fail to see why it is the case for Cygwin (it's the way mentioned in the README, but they also version using tags, and there is not much active development happening on the master branch since July). But fair point, I can revert the change for these Actions.

The heightened security is not necessary as we are not automatically uploading/writing to any repo which could be poisoned or secrets which could be exposed (I think the jobs are all read-only). And these changes actually decrease the maintainability.

These are also fair points. The only comment I have on this, is that by using only the major tag (like v6), you do not have a reproducible pipeline, and you actually do not know which version you are using when the workflow is triggered. Could be v6.0.1, v6.1.0 or whatever. It might be fine if the the Action maintainer is following the semantic versioning rules and is not introducing breaking changes for minor versions, but you might also run into regressions introduced from v6.0.x to v6.1.x, for example.

And the obfuscation by the using the hash instead of a proper version is a really bad thing as it makes things harder to understand - a tag would be better (but those could also be poisoned).

The version is also provided in comments next to the hash, and is updated by Dependabot in its PRs, so you do not lose any information about the version being used compared to what you already have today (you actually have more infos, as it provides the full tag)

Also bumping a lot of different versions of multiple modules in a single merge is also not great since it makes it harder to bisect potential issues later on and produces less "documentation" via the commit log.

Fair point, would you prefer multiple commits updating one Action per commit, or multiple PRs instead ?

Something that would be very helpful thought, if you could configure dependabot to generate a PR when a new high-level branch (e.g. v4-> v5) is available.

I believe this should be just a matter of cherry-picking the Dependabot config proposed in this PR with your current workflows, I'll try in my fork and let you know.

Since we are on the topic of the CI, I have some comments that could lead to several minor improvements (I can open an issue or a discussion for them, but I thought it could be "pre-discussed" here):

1. About the Python Action and pip packages

The latest v6.1.0 release for the setup-python action used for ASAN, CI-Windows, scriptcheck, TSAN and UBSAN introduced the capability to directly install pip packages with the pip-install parameter¹. This could simplify those workflows by removing the extra step that currently installs pip dependencies. For example, this step in tsan.yml:

- name: Install missing Python packages
        run: |
          python3 -m pip install pip --upgrade
          python3 -m pip install pytest
          python3 -m pip install pytest-timeout
          python3 -m pip install pytest-xdist
          python3 -m pip install psutil

Could be removed and replaced with the following Action definition:

- name: Set up Python
        uses: actions/setup-python@v6
        with:
          python-version: '3.14'
          check-latest: true
          pip-install: pip pytest pytest-timeout pytest-xdist psutil

I can also suggest to use the cache: pip parameter to speedup somewhat this step.

Additionally, the scriptcheck workflow is currently defining the following Python versions as a matrix strategy:

python-version: [3.7, 3.8, 3.9, '3.10', '3.11', '3.12', '3.13', '3.14']

Versions 3.7, 3.8 and 3.9 are now end of life and unsupported, is there a potential cleanup to do here ?

2. About the Runners OSes

Most of the workflows running on Ubuntu are using v22.04 for the runs-on: parameter, except for the buildman workflow that is using both v22.04 and 24.04 for its two jobs, and cpppremium that is running on v24.04. cifuzz and coverity are using ubuntu-latest (now v24.04).

Is there any updating or harmonization that would be useful here (migrating v22.04 to v24.04 or ubuntu-latest) ?

Regarding MacOS, all jobs are using macos-15, except for iwyu that is still defining macos-13, any change that would be useful here ?

Regarding Windows, all jobs or matrixes are using windows-2025 (with addition of windows-2022 for matrixes) so this seems fine.

3. About the TODOs

There are quite a lot of TODOs in the workflow files, some of them seems outdated and/or fixable, for example in the CI-Windows file:

aqtversion: '==3.1.*' # TODO: remove when aqtinstall 3.2.2 is available

Would it be useful to revisit them ?

Sorry for the long post, and thanks for the feedback !

Footnotes

1. Cf. the release changelog: https://github.com/actions/setup-python/releases/tag/v6.1.0 ↩