Page History

...

Similarly, builds triggered with issue_comment  run with a 'permissive' GITHUB_TOKEN. Again, no code may be loaded after switching to the PR branch. You use this technique to switch to the branch.

Builds triggered with

...

workflow_

...

run

A common technique for building untrusted code but also using privileges to act on the build result is to split the build into two parts: a low-privilege one triggered by pull_request that runs the untrusted code, stores the result in an artifact, and triggers a second, high-privilege build with onworkflow_workflowrun  that acts on that result.

In such a scenario, you must be careful to make sure all evaluation of untrusted code happens in the pull_request  build, and no untrusted code is executed in the onworkflow_workflowrun part of the workflow.

When extracting and using the artifacts it is important to remember that they were produced in an untrusted context and their content is not to be trusted.:

• Always extract into a directory separate from the trusted code in a step before checking out said  trusted code. This stops files extracted from the archive from clobbering trusted code.
• A separate directory can also prevent files in the artifact impersonating often used python modules like pip  as running python -m pip ...  would execute a pip.py file in the cwd
• Validate any content you retrieve from an artifact before you use it to avoid command injection, especially in steps using bash  and Github Actions macros.
  • This includes using cat  on such files as well as putting their content into environment variables (a popular exploit is to modify LD_PRELOAD, some examples ), step outputs to use via ${{ steps.id.outputs.sus_content }} to be used in e.g. if  in bash.

...