GITHUB_TOKEN is provided in the environment to authenticate git clones. However as it remains in the environment after the initial clone, users can consume this token in their own scripts to impersonate Shipit on Github through the API. This is not ideal because:
The token is only designed to be valid at the start of a task to facilitate git cloning (can potentially only be valid for 10 minutes) - if people are relying on it later on in a longer task, it will break unexpectedly from their point of view
The unexpected use of the token by users creates an unreliable 'feature' from their perspective
Shipit is already a highly privileged entity - lots of access to Github and lots of credentials for production - allowing custom code to impersonate Shipit makes reasoning about its access even harder. We want to be limiting Shipit's access where possible, letting people hit the API on their own means we're likely to break something without realising it
I consider this a bug and would like to fix it. Some options:
Can we limit the access of the token itself to only repo read(/write?)?
Can we only set the variable for git commands?
Obfuscation: move the token into a file or expose it via an endpoint
Consider unsetting the variable after the git clone has finished. One big issue with that I see is it would break any user supplied git commands at the start of a task - e.g. fetching tags/submodules.