Secrets are not available in Gitea Actions builds of PRs from repo forks when event is pull_request_target #10967

Closed
opened 2025-11-02 09:23:34 -06:00 by GiteaMirror · 7 comments
Owner

Originally created by @sebthom on GitHub (Jun 5, 2023).

Description

Secrets seem not to be populated in gitea action runs of PRs from repo forks.

I created a fork of a repo hosted in an org into my personal account. The repo uses secrets in the gitea action build.
When creating a PR to the upstream repo the gitea action builds fail, despite the given secret being defined in my repo fork as well as in the upstream repo.

When I merge such a PR and the gitea action runs in the upstream repo triggered by the branch push, then the run succeeds.

Gitea Version

1.19.3

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Dockerized

Database

SQLite

Originally created by @sebthom on GitHub (Jun 5, 2023). ### Description Secrets seem not to be populated in gitea action runs of PRs from repo forks. I created a fork of a repo hosted in an org into my personal account. The repo uses secrets in the gitea action build. When creating a PR to the upstream repo the gitea action builds fail, despite the given secret being defined in my repo fork as well as in the upstream repo. When I merge such a PR and the gitea action runs in the upstream repo triggered by the branch push, then the run succeeds. ### Gitea Version 1.19.3 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? Dockerized ### Database SQLite
GiteaMirror added the type/bug label 2025-11-02 09:23:34 -06:00
Author
Owner

@lunny commented on GitHub (Jun 6, 2023):

It's by design for security reason.

@lunny commented on GitHub (Jun 6, 2023): It's by design for security reason.
Author
Owner

@sebthom commented on GitHub (Jun 6, 2023):

It's by design for security reason.

That unfortunately makes the PR review process a bit useless and also is for example not how github actions works.

It would be great if this can be configured in app.ini (similar to the enablement of git hooks).

We for example need to checkout code from another repo in the same org (for which we need a token we store as secret) to generate/verify schema files and want to publish a container image based on the pr to the internal package registry for faster review purposes. for this we also need a token.

@sebthom commented on GitHub (Jun 6, 2023): > It's by design for security reason. That unfortunately makes the PR review process a bit useless and also is for example not how github actions works. It would be great if this can be configured in app.ini (similar to the enablement of git hooks). We for example need to checkout code from another repo in the same org (for which we need a token we store as secret) to generate/verify schema files and want to publish a container image based on the pr to the internal package registry for faster review purposes. for this we also need a token.
Author
Owner

@sebthom commented on GitHub (Jun 6, 2023):

Gitea could also allow usage of tokens in PRs of all users that have write access to the PR target repo. Because in this case there is no additional security value by not populating the secrets.

@sebthom commented on GitHub (Jun 6, 2023): Gitea could also allow usage of tokens in PRs of all users that have write access to the PR target repo. Because in this case there is no additional security value by not populating the secrets.
Author
Owner

@lunny commented on GitHub (Jun 6, 2023):

It's by design for security reason.

That unfortunately makes the PR review process a bit useless and also is for example not how github actions works.

It would be great if this can be configured in app.ini (similar to the enablement of git hooks).

We for example need to checkout code from another repository in the same org (for which we need a token we store as secret) to generate/verify schema files and want to publish a container image based on the pr to the internal package registry for faster review purposes. for this we also need a token.

I think the logic is similiar as Github's default settting. And in future we will have options in repository settings to change that.

This is only for fork repositories pull requests, for pull requests from the base repositories, they could read secrets.

@lunny commented on GitHub (Jun 6, 2023): > > It's by design for security reason. > > That unfortunately makes the PR review process a bit useless and also is for example not how github actions works. > > It would be great if this can be configured in app.ini (similar to the enablement of git hooks). > > We for example need to checkout code from another repository in the same org (for which we need a token we store as secret) to generate/verify schema files and want to publish a container image based on the pr to the internal package registry for faster review purposes. for this we also need a token. I think the logic is similiar as Github's default settting. And in future we will have options in repository settings to change that. This is only for fork repositories pull requests, for pull requests from the base repositories, they could read secrets.
Author
Owner

@wolfogre commented on GitHub (Jun 6, 2023):

See https://docs.github.com/en/actions/security-guides/encrypted-secrets#using-encrypted-secrets-in-a-workflow

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

@wolfogre commented on GitHub (Jun 6, 2023): See https://docs.github.com/en/actions/security-guides/encrypted-secrets#using-encrypted-secrets-in-a-workflow > With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.
Author
Owner

@sebthom commented on GitHub (Jun 6, 2023):

According https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/#improvements-for-public-repository-forks secrets are populated when using pull_request_target instead of pull_request.

I tried it and can confirm that for GitHub Actions:

However, Gitea Actions currently does not populate the secrets when using pull_request_target. Would be awesome if that can be changed.

@sebthom commented on GitHub (Jun 6, 2023): According https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/#improvements-for-public-repository-forks secrets are populated when using `pull_request_target` instead of `pull_request`. I tried it and can confirm that for **GitHub Actions**: - This is a test PR https://github.com/gha-secrets-test/gha-secrets-test/pull/1 from a repo fork. - And in the action run you can see that the secret was indeed populated https://github.com/gha-secrets-test/gha-secrets-test/actions/runs/5187246139/jobs/9349382225 However, **Gitea Actions** currently does not populate the secrets when using `pull_request_target`. Would be awesome if that can be changed.
Author
Owner

@wolfogre commented on GitHub (Jun 12, 2023):

@sebthom Thanks for pointing it out. I get the point, Gitea doesn't support pull_request_target well, instead it treats it as pull_request.

@wolfogre commented on GitHub (Jun 12, 2023): @sebthom Thanks for pointing it out. I get the point, Gitea doesn't support `pull_request_target` well, instead it treats it as `pull_request`.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#10967