ci: drop rocksbot for collaborators list#309
Conversation
upils
left a comment
upils
left a comment
There was a problem hiding this comment.
Thanks @cjdcordeiro! I have a couple of suggestions and questions but overall it seems to be safer, easier to maintain to more robust than the previous solution.
If we are happy with it we may want to do the same with the Security workflow.
| # - How could this token be compromised? | ||
| # - By unintentionally merging a change that allows this step to run unvetted scripts | ||
| # (either via a "pull_request_target", use of an insecure 3rd party action, or malicious changes to the | ||
| # current script) |
There was a problem hiding this comment.
This maybe superfluous now but this bit was informative and would maybe prevent us from falling into this trap again. WDYT of keeping it (probably by rewording it a bit)?
There was a problem hiding this comment.
I agree. however, as you say, this is applicable to any other job in the CI that uses any token. It is less relevant now cause if this token gets compromised, the risk only exists during the execution of the job (unlike the previous FGT).
| for dir in chisel_*/; do | ||
| for file in "$dir"*; do | ||
| echo "Uploading $file to release $CHISEL_VERSION" | ||
| gh release upload "$CHISEL_VERSION" "$file" --repo "$GITHUB_REPOSITORY" |
There was a problem hiding this comment.
Why is the --repo $GITHUB_REPOSITORY argument needed now?
There was a problem hiding this comment.
previously it was running in a checkout, but now it's not (its now a separate job)
| for dir in chisel_*/; do | ||
| for file in "$dir"*; do | ||
| echo "Uploading $file to release $CHISEL_VERSION" | ||
| gh release upload "$CHISEL_VERSION" "$file" --repo "$GITHUB_REPOSITORY" |
There was a problem hiding this comment.
previously it was running in a checkout, but now it's not (its now a separate job)
Co-authored-by: Upils <5464641+upils@users.noreply.github.com>
Re-word the new CI job comments
3 participants
This is a CI security enhancement.
In #284, we improved the security of the
buildCI workflow, ensuring the whole CI job wouldn't have unnecessarywritepermissions to the repository, instead shifting towards a fine grained personal token that would only be used within a single, conditional step that only ran on GitHubreleaseevents.NEW: this PR goes one step further by removing the need to have a bot account (which owns the aforementioned fine grained personal token) with
writepermissions in the repository's collaborators list. Instead, this PR splits the privileged step into a separate privileged job. This means the new job can use the ephemeral GITHUB_TOKEN to perform the privileged step, without giving unnecessary privileges to other jobs&steps of the workflow.closes #308