Open briansmith opened 3 years ago
TODO:
action/checkout@v2
is impractical to audit meaningfully, IMO. Instead, I hope to replace most or all use of third-party actions with alternatives code/scripts that live within the repository or within a as-yet-uncreated "briansmith/github-actions" repository that would store such.$ grep "uses:" .github/workflows/ci.yml | sort | uniq
- uses: briansmith/actions-cache@v2
- uses: briansmith/actions-checkout@v2
- uses: briansmith/actions-rs-toolchain@v1
- uses: briansmith/codecov-codecov-action@v1
Here is my currently rough plan for replacing the actions:
actions/cache@v2: Instead of building tools like cargo deny
from source and then caching them (which is way too slow), I'm considering a couple of alternatives. The most likely to succeed is to create a repository of the pre-built tools, and then use shallow/skinny git clones/checkouts to fetch those prebuilt binaries. Eventually I hope to use smarter alternatives. I've been meaning to do this to improve the reliability and security of CI anyway by eliminating the downloading of tools from third-party servers (Now I do SHA-256 checksum checks of the downloads, but sometimes the servers are down.)
actions/checkout@v2: It's a github-supplied action so it's not an emergency. However, I'm worried about the persist-github-token-by-default policy of the action; I might accidentally forget to disable it. It seems like it wouldn't be too hard to write a shell script that does a shallow clone of the correct branch/revision from https://github.com/briansmith/<repo name>
. Then no github.token would even be required, since it's a public repo. However, sometimes I have private forks of this repo and it would be nice if the script could work with the private copies too, using the github token only in the case of a private repo.
actions-rs/toolchain: I will extend the mk/install-build-tools.[sh|ps1]
scripts with the ability to (securely) download and install the Rust toolchain. I've been needing this for other reasons anyway.
codecov/codecov-action: I've been meaning to replace this with a script that works locally.
BTW, I noticed lots of Rust projects use the actions-rs/cargo
action. I found it was pretty easy to avoid using that; it doesn't seem to do anything particularly useful, though maybe I'm just an easy-to-satisfy person.
TODO:
TODO:
Regarding ::stop-commands::
, see https://github.com/actions/runner/issues/807; we need to keep the token from being logged.
After switching to my forks of each action I used, I also switched the Allowed Actions setting of this repository to "Allow local actions only."
For the codecov action, we might consider using the GitHub Actions artifacts mechanism (https://docs.github.com/en/actions/guides/storing-workflow-data-as-artifacts) to separate the collecting of the coverage, which requires a git checkout, from the uploading of the coverage results to codecov, which doesn't.
After switching to my forks of each action I used, I also switched the Allowed Actions setting of this repository to "Allow local actions only."
Since I forked the entire repository for each action, that means every revision of every action, with every tag and every commit, is in my fork. Instead of "Allow local actions only," having an allowlist of a single specific tag (v1, v2, whatever) for each action would be safer. I'll give that a shot tomorrow.
In https://docs.github.com/en/actions/security-guides/automatic-token-authentication it is noted that if we set the repository- or organization- level Actions policy to be "restricted" then we get exactly what we want. But, I couldn't find a way to publicly expose the fact that the Actions policy is "restricted," nor could I find a way to declare in the workflow YAML that I want the workflow to use "restricted" defaults.
In https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token several permissions besides "contents" are mentioned, but in our YAML we only lock don't the contents
permission. So, should take the full list of permissions mentioned there and set each one explicitly to none
(except contents: read
) in the YAML?
Should we have a job that simply checks the workflow configuration? E.g. checks that the repository is in "restricted" default mode and/or enumerates all the permissions and verifies that they are all none
? I would love to learn how one would do this.
I just merged PR #49 which minimizes the permissions of the GitHub token. I also changed the default permission of the GitHub token from read-write to read-only in the repository settings over the weekend, but I don't think people can see this.
Now we still need to follow the (rest of the) guidance in https://docs.github.com/en/actions/learn-github-actions/security-hardening-for-github-actions to lock down our CI/CD.
untrusted
has no dependencies besides actions and the Rust toolchain, so it is less urgent to do work to ensure dependencies are following the recommended GitHub Actions security practices. However, eventually we'll need to extend our CI/CD to ensure that no new dependencies without such hardening are added as dependencies of untrusted.