To use ACTIONS_RUNTIME_TOKEN for writing into Package Registry

[mstup]

Feature Description

Because ACTIONS_RUNTIME_TOKEN could be used to pull the code from Repository, it looks obvious to use this token later to write build result into Package Registry.

Screenshots

No response

[lunny]

Pulling the code from the Repository is a read permission of Code, it's not a write permission. I don't think the logic is reasonable.

[mstup]

I think that end user should be able to make this decision. Because hardcoding or mocking some dummy user looks even less reasonable.

[mstup]

This is screenshot from GitHub page and looks like they agreed with that.

[mstup]

GitLab as well propose as option to use ${CI_JOB_TOKEN} to access to Maven Package Registry.

[ChristopherHX]

I assume ACTIONS_RUNTIME_TOKEN will stop working for use in package registry.

This token were never usable for this task on GitHub Actions.

I propose to edit your proposal to mention ${{ secrets.GITHUB_TOKEN }}, ${{ secrets.GITEA_TOKEN }}, ${{ github.token }} or ${{ gitea.token }}

If you really use the env ACTIONS_RUNTIME_TOKEN to pull packages expect a broken workflow after upgrading runner + gitea.

[mstup]

@ChristopherHX As I see it, ACTIONS_RUNTIME_TOKEN regenerates each time on job starts execution. It looks much more secure instead of any hard coded value. No sense to store and remember this at all.
BTW: System variable ACTIONS_RUNTIME_TOKEN already exist and is equals to system variable GITHUB_TOKEN (checked it on Gitea v1.21.7)

The problem is that ACTIONS_RUNTIME_TOKEN don't have access to Package Registry to write.

[mstup]

Looks like these issues 23642, 24635 are about the same problem.

[ChristopherHX]

BTW: System variable ACTIONS_RUNTIME_TOKEN already exist and is equals to system variable GITHUB_TOKEN (checked it on Gitea v1.21.7)

Yes on the current release, no for the upcoming release. actions/upload-artifact@v4 need a jwt and not the PAT format used before.

I changed that ACTIONS_RUNTIME_TOKEN token to a jwt token with only internal artifact api access, your setup will break in v1.22.0 unless you refuse to upgrade act_runner as well, it was incorrectly set to GITEA_TOKEN.

ACTIONS_RUNTIME_TOKEN regenerates each time on job starts execution

${{ github.token }} should regenerate for each job as well it should be what you use incorrectly as ACTIONS_RUNTIME_TOKEN today

env:
  MY_RUNTIME_TOKEN: ${{ github.token }}

The tokens I mentioned are the exact same as of Gitea 1.21 Starting

[mstup]

@ChristopherHX No problem, I understood your explanation about ACTIONS_RUNTIME_TOKEN. It's fine to switch to use ${env.GITHUB_TOKEN}. It could be any dynamically generated value with package write access. Approach with hard coded token looks ugly and this is the main reason why I reported this issue.
All these unexpected changes for new releases is the main reason why I avoiding to use GitHub Actions as much as it possible. I tend to do it with own control of process which value or parameter to use and which command to execute.

[Frankkkkk]

I agree, this would be really nice and remove the need for PATs. The way Gitlab does it is quite neat IMHO :)

[lolen]

I also think it would be a great feature :)

[vizh]

It seems that for each project (many many projects), we now need to create unique dummy user and two tokens for it:

1. will be hardcoded in CI and used in the build process to upload packages.
2. will be hardcoded on the test and production servers to download packages.

This results in the creation of a large number of extra users, which will interfere with regular users using the interfaces, as they cannot be hidden.

Consequently, the system will have hundreds of dummy users. Creating just a few and grant access to multiple repositories is not correct from a security standpoint. Additionally, we need to remember their passwords to log in and generate tokens.

Perhaps a good solution would be an ability to create tokens for projects rather than users. This way, there would be no extra users in the system.

Or provide the ability to restrict a user-generated token to a specific project. This way, tokens for CI/CD can be created under one's own account without worrying that a leak would give an attacker access to all projects.