Actions - Inconsistency accessing user's variables and secrets #30361

QuantumQuacken · 2024-04-09T09:59:50Z

Description

Hello,
I'm trying to implement a CI/CD pipeline using Gitea Actions, and I found an inconsistent behaviour when accessing user variables and secrets.
I set up a variable named USERNAME_VARIABLE with value tester-user, a secret named USERNAME_SECRET with value tester-user, both on the user, and a simple workflow:

name: Test Secrets and Vars
on:
  push:
    branches: [main]
  
jobs:
  build:
    runs-on: [ubuntu-latest]
    container:
      image: catthehacker/ubuntu:mod-hosts
    steps:
      - name: Print secret and var
        run: |
          echo "Username var: ${{ vars.USERNAME_VARIABLE }}"
          echo "Username secret: ${{ secrets.USERNAME_SECRET }}"

With a repository owned by an organization, with no variables or secrets on the ORG or REPO level, the output of the workflow is:

Username var: tester-user
Username secret:

Same case, with the USERNAME_SECRET set on the ORG, the output is:

Username var: tester-user
Username secret: ***

The inconsistency is the action being able to access a user's variable, but not a user's secret. I'd expect the action being able to access the user's secrets, the same way it does for variables.

In other words:
The variable is available when requested, because it's found on the user's variables (expected).
The secret is not available (empty string) when requested, even if it's on the user's secrets (not expected). The secret is only available when the owner of the repository (an org or an user) has the required secrets.

Is the expected behaviour, or is it not correct?

Set up job of the workflow:

2024-04-09T08:33:35.9732276Z testRunner(version:v0.2.6) received task 297 of job 316, be triggered by event: push
2024-04-09T08:33:35.9748040Z workflow prepared
2024-04-09T08:33:35.9750946Z evaluating expression 'success()'
2024-04-09T08:33:35.9753135Z expression 'success()' evaluated to 'true'
2024-04-09T08:33:35.9753595Z 🚀  Start image=catthehacker/ubuntu:mod-hosts
2024-04-09T08:33:35.9867221Z   🐳  docker pull image=catthehacker/ubuntu:mod-hosts platform= username= forcePull=false
2024-04-09T08:33:35.9867396Z   🐳  docker pull catthehacker/ubuntu:mod-hosts
2024-04-09T08:33:35.9887351Z Image exists? true
2024-04-09T08:33:36.0954194Z   🐳  docker create image=catthehacker/ubuntu:mod-hosts platform= entrypoint=["/bin/sleep" "10800"] cmd=[]
2024-04-09T08:33:36.1022365Z Common container.Config ==> &{Hostname: Domainname: User: AttachStdin:false AttachStdout:false AttachStderr:false ExposedPorts:map[] Tty:false OpenStdin:false StdinOnce:false Env:[RUNNER_TOOL_CACHE=/opt/hostedtoolcache RUNNER_OS=Linux RUNNER_ARCH=X64 RUNNER_TEMP=/tmp LANG=C.UTF-8] Cmd:[] Healthcheck:<nil> ArgsEscaped:false Image:catthehacker/ubuntu:mod-hosts Volumes:map[] WorkingDir:/workspace/digital/supBack Entrypoint:[] NetworkDisabled:false MacAddress: OnBuild:[] Labels:map[] StopSignal: StopTimeout:<nil> Shell:[]}
2024-04-09T08:33:36.1137538Z Common container.HostConfig ==> &{Binds:[/var/run/docker.sock:/var/run/docker.sock] ContainerIDFile: LogConfig:{Type: Config:map[]} NetworkMode:GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build-network PortBindings:map[] RestartPolicy:{Name: MaximumRetryCount:0} AutoRemove:true VolumeDriver: VolumesFrom:[] ConsoleSize:[0 0] Annotations:map[] CapAdd:[] CapDrop:[] CgroupnsMode: DNS:[] DNSOptions:[] DNSSearch:[] ExtraHosts:[] GroupAdd:[] IpcMode: Cgroup: Links:[] OomScoreAdj:0 PidMode: Privileged:false PublishAllPorts:false ReadonlyRootfs:false SecurityOpt:[] StorageOpt:map[] Tmpfs:map[] UTSMode: UsernsMode: ShmSize:0 Sysctls:map[] Runtime: Isolation: Resources:{CPUShares:0 Memory:0 NanoCPUs:0 CgroupParent: BlkioWeight:0 BlkioWeightDevice:[] BlkioDeviceReadBps:[] BlkioDeviceWriteBps:[] BlkioDeviceReadIOps:[] BlkioDeviceWriteIOps:[] CPUPeriod:0 CPUQuota:0 CPURealtimePeriod:0 CPURealtimeRuntime:0 CpusetCpus: CpusetMems: Devices:[] DeviceCgroupRules:[] DeviceRequests:[] KernelMemory:0 KernelMemoryTCP:0 MemoryReservation:0 MemorySwap:0 MemorySwappiness:<nil> OomKillDisable:<nil> PidsLimit:<nil> Ulimits:[] CPUCount:0 CPUPercent:0 IOMaximumIOps:0 IOMaximumBandwidth:0} Mounts:[{Type:volume Source:GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build Target:/workspace/digital/supBack ReadOnly:false Consistency: BindOptions:<nil> VolumeOptions:<nil> TmpfsOptions:<nil> ClusterOptions:<nil>} {Type:volume Source:act-toolcache Target:/toolcache ReadOnly:false Consistency: BindOptions:<nil> VolumeOptions:<nil> TmpfsOptions:<nil> ClusterOptions:<nil>} {Type:volume Source:GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build-env Target:/var/run/act ReadOnly:false Consistency: BindOptions:<nil> VolumeOptions:<nil> TmpfsOptions:<nil> ClusterOptions:<nil>}] MaskedPaths:[] ReadonlyPaths:[] Init:<nil>}
2024-04-09T08:33:36.2710536Z Created container name=GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build id=669befa3a5a42b5e6bae1067779f191cb142dbe63abc6537ab0d51176d37a077 from image catthehacker/ubuntu:mod-hosts (platform: )
2024-04-09T08:33:36.2710950Z ENV ==> [RUNNER_TOOL_CACHE=/opt/hostedtoolcache RUNNER_OS=Linux RUNNER_ARCH=X64 RUNNER_TEMP=/tmp LANG=C.UTF-8]
2024-04-09T08:33:36.2711117Z   🐳  docker run image=catthehacker/ubuntu:mod-hosts platform= entrypoint=["/bin/sleep" "10800"] cmd=[]
2024-04-09T08:33:36.2711229Z Starting container: 669befa3a5a42b5e6bae1067779f191cb142dbe63abc6537ab0d51176d37a077
2024-04-09T08:33:36.5270495Z Started container: 669befa3a5a42b5e6bae1067779f191cb142dbe63abc6537ab0d51176d37a077
2024-04-09T08:33:36.6712413Z Writing entry to tarball workflow/event.json len:4217
2024-04-09T08:33:36.6713296Z Writing entry to tarball workflow/envs.txt len:0
2024-04-09T08:33:36.6713569Z Extracting content to '/var/run/act/'
2024-04-09T08:33:36.7119767Z setupEnv => map[ACT:true ACTIONS_CACHE_URL:http://172.17.0.2:41349/ ACTIONS_RUNTIME_TOKEN:*** ACTIONS_RUNTIME_URL:http://REDACTED:3000/api/actions_pipeline/ A_TEST_ENV_NAME_1:a_test_env_value_1 A_TEST_ENV_NAME_2:a_test_env_value_2 CI:true GITEA_ACTIONS:true GITEA_ACTIONS_RUNNER_VERSION:v0.2.6 GITHUB_ACTION:0 GITHUB_ACTIONS:true GITHUB_ACTION_PATH: GITHUB_ACTION_REF: GITHUB_ACTION_REPOSITORY: GITHUB_ACTOR:tester GITHUB_API_URL:http://REDACTED:3000/api/v1 GITHUB_BASE_REF: GITHUB_EVENT_NAME:push GITHUB_EVENT_PATH:/var/run/act/workflow/event.json GITHUB_GRAPHQL_URL: GITHUB_HEAD_REF: GITHUB_JOB:build GITHUB_REF:refs/heads/main GITHUB_REF_NAME:main GITHUB_REF_TYPE:branch GITHUB_REPOSITORY:digital/supBack GITHUB_REPOSITORY_OWNER:digital GITHUB_RETENTION_DAYS: GITHUB_RUN_ID:219 GITHUB_RUN_NUMBER:25 GITHUB_SERVER_URL:http://REDACTED:3000 GITHUB_SHA:7b37b5765defe012936001b3b6e718e47248c01d GITHUB_TOKEN:*** GITHUB_WORKFLOW:Test Secrets and Vars GITHUB_WORKSPACE:/workspace/digital/supBack ImageOS:ubuntu20 JOB_CONTAINER_NAME:GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build RUNNER_PERFLOG:/dev/null RUNNER_TRACKING_ID:]
2024-04-09T08:33:36.7225739Z evaluating expression ''
2024-04-09T08:33:36.7226320Z expression '' evaluated to 'true'
2024-04-09T08:33:36.7226477Z ⭐ Run Main Print secret and var
2024-04-09T08:33:36.7226699Z Writing entry to tarball workflow/outputcmd.txt len:0
2024-04-09T08:33:36.7226885Z Writing entry to tarball workflow/statecmd.txt len:0
2024-04-09T08:33:36.7227024Z Writing entry to tarball workflow/pathcmd.txt len:0
2024-04-09T08:33:36.7227160Z Writing entry to tarball workflow/envs.txt len:0
2024-04-09T08:33:36.7227263Z Writing entry to tarball workflow/SUMMARY.md len:0
2024-04-09T08:33:36.7227390Z Extracting content to '/var/run/act'
2024-04-09T08:33:36.7598506Z expression 'echo "Username var: ${{ vars.USERNAME_VARIABLE }}"\necho "Username secret: ${{ secrets.USERNAME_SECRET }}"' rewritten to 'format('echo "Username var: {0}"\necho "Username secret: {1}"', vars.USERNAME_VARIABLE, secrets.USERNAME_SECRET)'
2024-04-09T08:33:36.7598902Z evaluating expression 'format('echo "Username var: {0}"\necho "Username secret: {1}"', vars.USERNAME_VARIABLE, secrets.USERNAME_SECRET)'
2024-04-09T08:33:36.7599367Z expression 'format('echo "Username var: {0}"\necho "Username secret: {1}"', vars.USERNAME_VARIABLE, secrets.USERNAME_SECRET)' evaluated to '%!t(string=echo "Username var: tester"\necho "Username secret: ")'
2024-04-09T08:33:36.7599498Z Wrote command \n\necho "Username var: tester"\necho "Username secret: "\n\n to 'workflow/0.sh'
2024-04-09T08:33:36.7599696Z Writing entry to tarball workflow/0.sh len:54
2024-04-09T08:33:36.7599905Z Extracting content to '/var/run/act'
2024-04-09T08:33:36.7626815Z   🐳  docker exec cmd=[sh -e /var/run/act/workflow/0.sh] user= workdir=
2024-04-09T08:33:36.7627145Z Exec command '[sh -e /var/run/act/workflow/0.sh]'
2024-04-09T08:33:36.7627518Z Working directory '/workspace/digital/supBack'
2024-04-09T08:33:36.8295547Z Username var: tester
2024-04-09T08:33:36.8296062Z Username secret: 
2024-04-09T08:33:36.8451802Z Cleaning up services for job build
2024-04-09T08:33:36.8452363Z Cleaning up container for job build
2024-04-09T08:33:37.0474596Z Removed container: 669befa3a5a42b5e6bae1067779f191cb142dbe63abc6537ab0d51176d37a077
2024-04-09T08:33:37.0489031Z   🐳  docker volume rm GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build
2024-04-09T08:33:37.0519061Z   🐳  docker volume rm GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build-env
2024-04-09T08:33:37.0536361Z Cleaning up network for job build, and network name is: GITEA-ACTIONS-TASK-297_WORKFLOW-Test-Secrets-and-Vars_JOB-build-network
2024-04-09T08:33:37.1731766Z 🏁  Job succeeded

If something is not clear or detailed enough, please let me know so I can add the appropriate information.

Gitea Version

1.21.10

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.39.2

Operating System

Debian GNU/Linux 12 (bookworm) - Linux 6.1.0-17-amd64

How are you running Gitea?

My Gitea instance is running using the binary downloaded from GitHub. I installed the instance as described in the docs and set it up as a service as described here.

I'm using act-runner v0.2.6 in Docker 26.0.0 build 2ae903e.

Database

PostgreSQL

The text was updated successfully, but these errors were encountered:

wolfogre · 2024-04-10T06:08:44Z

The inconsistency is the action being able to access a user's variable, but not a user's secret. I'd expect the action being able to access the user's secrets, the same way it does for variables.

It shouldn't be, if you set a variable or secret for a user, then the repo belonging to an org cannot read it, regardless of whether the user is the creator of the repo or a member of the org.
It is designed that a repo can only read variables and secrets from its own and its owner (user or org).

So what surprised me is:

... I set up a variable named USERNAME_VARIABLE with value tester-user, a secret named USERNAME_SECRET with value tester-user, both on the user ...
With a repository owned by an organization, with no variables or secrets on the ORG or REPO level, the output of the workflow is:
Username var: tester-user
Username secret: 

It shouldn't be, and I tried to reproduce it in my local environment. Please point out which step should be adjusted.

Log in with the user "root".
Create a repo for the org "test_org".
Set a variable "USERNAME_VARIABLE" for the user "root".
Run actions for the repo.

This is as expected.

QuantumQuacken · 2024-04-10T06:44:54Z

It shouldn't be, if you set a variable or secret for a user, then the repo belonging to an org cannot read it, regardless of whether the user is the creator of the repo or a member of the org.
It is designed that a repo can only read variables and secrets from its own and its owner (user or org).

Thank you for the clarification.
Sorry for going slightly OT: is there a way to use the actor's variables and secrets in this scenario (repo owned by org)? Can they somehow be securely injected into the workflow?

It shouldn't be, and I tried to reproduce it in my local environment. Please point out which step should be adjusted.

I'd say the steps are correct. I tried reproducing it again, and I got the same output (see screenshot).

My steps:

Logged in with my root user, set a variable "USERNAME_VARIABLE" to "tester-user".
With my root user I created a new org "test_org".
Under that org I created a repo "test_repo" and added the .yaml file (same as the one in the orginal post).
Run action.

I also tried running the action with a different user (non-root). I added the user to the collaborators of the "test_repo", set the same variable with value "tester-user2", and I got the same behaviour. Same happens when adding the second user to an org's team with write permissions to the code, instead of the collaborators.

Let me know what I can share to dig deeper into the issue.

wolfogre · 2024-04-10T09:53:51Z

is there a way to use the actor's variables and secrets in this scenario (repo owned by org)? Can they somehow be securely injected into the workflow?

TBH, I think there's no way to do that. And I don't think it could be supported by Gitea or even GitHub. It could make the workflows very fragile when sometimes the variable/secret is A while sometimes it is B. And it's also unsafe, since the actor could be a collaborator. How can the owner of a repo ask their collaborators to share their secrets? Just a joke: Hi QuantumQuacken, I would like to invite you to my personal project. Please commit to my repo, and the scripts will send all your secrets to my email. 😄

I tried reproducing it again, and I got the same output (see screenshot).

Could you please check:

/test_org/test_repo/settings/actions/variables, is there any variable for the repo?
/org/test_org/settings/actions/variables, is there any variable for the org?
/admin/actions/variables, is there any variable for the whole Gitea instance? (I almost forgot it since it was just recently supported)

QuantumQuacken · 2024-04-10T12:20:11Z

TBH, I think there's no way to do that. And I don't think it could be supported by Gitea or even GitHub. It could make the workflows very fragile when sometimes the variable/secret is A while sometimes it is B. And it's also unsafe, since the actor could be a collaborator. How can the owner of a repo ask their collaborators to share their secrets? Just a joke: Hi QuantumQuacken, I would like to invite you to my personal project. Please commit to my repo, and the scripts will send all your secrets to my email. 😄

It's a new topic for me, so thank you very much for the explanation!

test_repo variables:

test_org variables:

I can't see any variables section in the Admin settings. Was it added in 1.22 or later?

wolfogre · 2024-04-11T02:39:08Z

I can't see any variables section in the Admin settings. Was it added in 1.22 or later?

Sorry, I was mistaken. You are right, it was added in v1.22.

Thank you for patiently providing such a detailed troubleshooting process. In the end, I identified the bug.

Fix #30361, regression of #29782 which is a backport, not the original #29468. #29468 did a small refactor which introduced a new function `GetVariablesOfRun`. However, it's designed for v1.22 which supports global variables. After backporting it to v1.21, it will still try to get global variables, which causes it to retrieve all variables.

lunny · 2024-04-11T03:54:59Z

Closed by #30402

QuantumQuacken added the type/bug label Apr 9, 2024

wolfogre mentioned this issue Apr 11, 2024

No global variables #30402

Merged

wolfogre linked a pull request Apr 11, 2024 that will close this issue

No global variables #30402

Merged

lunny added this to the 1.21.11 milestone Apr 11, 2024

lunny added the topic/gitea-actions related to the actions of Gitea label Apr 11, 2024

lunny closed this as completed Apr 11, 2024

go-gitea locked as resolved and limited conversation to collaborators Jul 10, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Actions - Inconsistency accessing user's variables and secrets #30361

Actions - Inconsistency accessing user's variables and secrets #30361

QuantumQuacken commented Apr 9, 2024

wolfogre commented Apr 10, 2024 •

edited

Loading

Uh oh!

QuantumQuacken commented Apr 10, 2024

Uh oh!

wolfogre commented Apr 10, 2024 •

edited

Loading

Uh oh!

QuantumQuacken commented Apr 10, 2024

Uh oh!

wolfogre commented Apr 11, 2024 •

edited

Loading

Uh oh!

lunny commented Apr 11, 2024

Uh oh!

Uh oh!

Actions - Inconsistency accessing user's variables and secrets #30361

Actions - Inconsistency accessing user's variables and secrets #30361

Comments

QuantumQuacken commented Apr 9, 2024

Description

Gitea Version

Can you reproduce the bug on the Gitea demo site?

Log Gist

Screenshots

Git Version

Operating System

How are you running Gitea?

Database

wolfogre commented Apr 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

QuantumQuacken commented Apr 10, 2024

Uh oh!

wolfogre commented Apr 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

QuantumQuacken commented Apr 10, 2024

Uh oh!

wolfogre commented Apr 11, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lunny commented Apr 11, 2024

Uh oh!

wolfogre commented Apr 10, 2024 •

edited

Loading

wolfogre commented Apr 10, 2024 •

edited

Loading

wolfogre commented Apr 11, 2024 •

edited

Loading