-
Notifications
You must be signed in to change notification settings - Fork 695
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add details on authentication / permissions used during upload #197
Comments
After some searching through GitHub I found out that this action relies on a special undocumented token that is made available to actions as environment variable and is unrelated to GITHUB_TOKEN. Side note: this token is not made available to I created a small demo that shows how with the code of the upload-artifact action someone can create a seemingly innocent action that overwrites previously uploaded artifacts. This is not great if publishing of artifacts to package repositories is fully automated. One possible solution would be if artifacts could be marked as immutable so that they can't be overridden, and maybe that should be the default. |
I am also interested in the documentation of what permissions are required. None of the GitHub Token permissions documented seem relevant.
If that is true, then we also need advice about how to lock down that token. |
I've stumbled across this issue as I'm currently exploring the implications for our workflow files of moving our org default access level from 'permissive' to 'restricted' (see Permissions for the The greater focus on finer grained permissions scope is a welcome improvement to the GitHub Actions ecosystem, however I think the developer experience would be greatly enhanced were GitHub to take the initiative to explicitly document permissions required (in the same terms as referred to in workflow files) in the actions published under this org. At the time of writing this I'm yet to discover whether invoking this action with the default restricted permissions will fail my workflows or not. I could, perhaps, spend some time exploring the multiple layers of source code orchestrated to achieve what this action does - but, honestly, I don't have the time for that. So, as is so often the case, I'm going to resort to 'suck and see' - i.e. make the change and see if stuff breaks. Not ideal. |
…ll workflows. see: https://docs.github.com/en/actions/reference/authentication-in-a-workflow#permissions-for-the-github_token This is an experiment to explore what will break when we switch our org level default from 'permissive' to 'restricted'. see also: actions/upload-artifact#197 (comment)
agreed there's a lack of support. Once you understand how permissions work, you can make an informed decision. But it takes a little getting used to :-) In the meantime, try https://github.com/naveensrinivasan/ghactionspermissions, written by someone on my team https://github.com/ossf/scorecard. |
Don't use that tool. Sorry, it is not the right approach. Here is the discussion github/codeql-action#689 (comment) |
With GitHub per-job tokens moving to fine-grained permissions I was wondering how this action authenticates in order to upload artifacts. Does it use the token? If so, which permissions are needed? If not, how is authentication handled instead?
The text was updated successfully, but these errors were encountered: