Add details on authentication / permissions used during upload

[letmaik]

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?

[letmaik]

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 run: scripts, only to actions.

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.

[briansmith]

I am also interested in the documentation of what permissions are required. None of the GitHub Token permissions documented seem relevant.

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 run: scripts, only to actions.

If that is true, then we also need advice about how to lock down that token.

[QuintinWillison]

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 GITHUB_TOKEN and workflow syntax: permissions).

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.

[laurentsimon]

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.
The tool allows you to extract permission failure from a check run and tells you which permissions you need.
FYI @naveensrinivasan

[naveensrinivasan]

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
FYI @naveensrinivasan

Don't use that tool. Sorry, it is not the right approach. Here is the discussion github/codeql-action#689 (comment)