I think GitLab uses a better approach. Secret environment variables (holding keys/passwords) in CI are only accessible from protected contexts. You can configure who is allowed to create or update such protected tag or branch.
Something else GitLab does is provide a ephemeral API token to CI jobs. It’s only valid until the job ends, so it can’t be extracted and used elsewhere later on. It’s limited in scope (and obviously isn’t useful when your CI job has to interact with external services) but the approach is very useful when working with Docker images written by someone else.
I remarked on this a while back, but good to see confirmation (and the commit hash work-around; I didn’t realize that was possible.)
I have doubts with respect to the trust model and third-party actions. I’m happy to trust the Github provided actions with my secrets, and I’m happy to trust e.g. peaceiris/actions-gh-pages@v2.5.0 with my deploy key after reviewing it. But I don’t see any guarantees that it won’t be replaced by a malicious version.
I think GitLab uses a better approach. Secret environment variables (holding keys/passwords) in CI are only accessible from protected contexts. You can configure who is allowed to create or update such protected tag or branch.
Something else GitLab does is provide a ephemeral API token to CI jobs. It’s only valid until the job ends, so it can’t be extracted and used elsewhere later on. It’s limited in scope (and obviously isn’t useful when your CI job has to interact with external services) but the approach is very useful when working with Docker images written by someone else.
I remarked on this a while back, but good to see confirmation (and the commit hash work-around; I didn’t realize that was possible.)
An interesting observation regarding using commit hash as version, as demonstrated in the command-line: