> By default, using `actions/checkout` causes a credential to be persisted in the checked-out repo's `.git/config`, so that subsequent `git` operations can be authenticated.
>
> Subsequent steps may accidentally publicly persist `.git/config`, e.g. by including it in a publicly accessible artifact via `actions/upload-artifact`.
>
> However, even without this, persisting the credential in the `.git/config` is non-ideal unless actually needed.
>
> **Remediation**
>
> Unless needed for `git` operations, `actions/checkout` should be used with `persist-credentials: false`.
>
> If the persisted credential is needed, it should be made explicit with `persist-credentials: true`.
This has now been addressed in all workflows.
Refs:
* https://unit42.paloaltonetworks.com/github-repo-artifacts-leak-tokens/
* https://docs.zizmor.sh/audits/#artipacked
Recently there has been more and more focus on securing GH Actions workflows - in part due to some incidents.
The problem with "unpinned" action runners is as follows:
* Tags are mutable, which means that a tag could point to a safe commit today, but to a malicious commit tomorrow.
Note that GitHub is currently beta-testing a new "immutable releases" feature (= tags and release artifacts can not be changed anymore once the release is published), but whether that has much effect depends on the ecosystem of the packages using the feature.
Aside from that, it will likely take years before all projects adopt _immutable releases_.
* Action runners often don't even point to a tag, but to a branch, making the used action runner a moving target.
_Note: this type of "floating major" for action runners used to be promoted as good practice when the ecosystem was "young". Insights have since changed._
While it is convenient to use "floating majors" of action runners, as this means you only need to update the workflows on a new major release of the action runner, the price is higher risk of malicious code being executed in workflows.
Dependabot, by now, can automatically submit PRs to update pinned action runners too, as long as the commit-hash pinned runner is followed by a comment listing the released version the commit is pointing to.
So, what with Dependabot being capable of updating workflows with pinned action runners, I believe it is time to update the workflows to the _current_ best practice of using commit-hash pinned action runners.
The downside of this change is that there will be more frequent Dependabot PRs.
If this would become a burden/irritating, the following mitigations can be implemented:
1. Updating the Dependabot config to group updates instead of sending individual PRs per action runner.
2. A workflow to automatically merge Dependabot PRs as long as CI passes.
Includes updating the version for `ossf/scorecard-action` as it was a couple of version behind.
Ref: https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions
Most predefined action runners offer a long-running branch or a tag which gets moved every release to allow staying on the "latest" version of a certain major of their action, without having to update the workflow scripts on every release of the action runner.
This works well for action runners which follow semver.
I've reviewed the existing workflows and tweaked the versions used whenever possible to make optimal use of this.
* For the `ossf/scorecard-action` action runner, I have not been able to find a workable tag/branch to fix this on.
Note: I have remove the "# v1.1.1" comment though as it doesn't get updated by Dependabot and was sorely out of date (you are currently on version `2.0.4`).
With the changes in this PR, Dependabot should become less noisy and will only send in PRs to update the action runner versions when a new major release has been tagged. (save for the one exceptions mentioned above)
I would recommend watching the following repos for new releases:
* https://github.com/actions/checkout
* https://github.com/actions/upload-artifact
* https://github.com/shivammathur/setup-php
* https://github.com/ramsey/composer-install
* https://github.com/nick-fields/retry
* https://github.com/codecov/codecov-action
* https://github.com/JamesIves/github-pages-deploy-action
* https://github.com/ossf/scorecard-action
* https://github.com/github/codeql-action
This will ensure you will get an email with the changelogs for those action runners on all releases, so you can still monitor for changes in the action runners you need to be aware of.
A number of predefined actions have had major release, which warrant an update the workflow(s).
These updates don't actually contain any changed functionality, they are mostly just a change of the Node version used by the action itself (from Node 14 to Node 16).
Refs:
* https://github.com/actions/checkout/releases
The `docs` workflow to deploy the GH Pages website is run on pushes to `master`, but that includes pushes to `master` in forks, which obviously can't deploy to the GH Pages site.
This means that in forks (and there are nearly 9000 of them), this workflow will always fail, while in reality, it shouldn't be run in the first place.
So, I'd like to propose making this small change, which _should_ prevent the `docs` workflow from being run on forks.
Co-authored-by: jrfnl <jrfnl@users.noreply.github.com>
dependabot[bot]
Marcus Bointon
jrfnl
Alex
Juliette
freezy