After upgrading Gitea to the latest version, the actions secrets are lost #14115

New Issue

GiteaMirror · 2025-11-02T11:03:20-06:00

GiteaMirror commented

2025-11-02 11:03:20 -06:00

Originally created by @ysicing on GitHub (Feb 8, 2025).

Description

After upgrading Gitea to the latest version, the pipeline keys are lost, but the database records are still present.

Gitea Version

1.23.3

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

The screenshots show my YAML configuration and the historical execution records, which were working fine before the upgrade. After the upgrade, I found that the environment variables are missing, so I manually added one. Finally, there is a screenshot of the database.

Git Version

No response

Operating System

docker

How are you running Gitea?

docker compose

Database

MySQL/MariaDB

Originally created by @ysicing on GitHub (Feb 8, 2025). ### Description After upgrading Gitea to the latest version, the pipeline keys are lost, but the database records are still present. ### Gitea Version 1.23.3 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots ![Image](https://github.com/user-attachments/assets/27337f42-4945-49e9-ba06-ba4fe58011b7) ![Image](https://github.com/user-attachments/assets/ddfa50c3-ad57-455c-8763-7fb381daec24) ![Image](https://github.com/user-attachments/assets/f5d4fd0a-0e3c-47f5-990f-d6c2e6a8fef0) ![Image](https://github.com/user-attachments/assets/83301947-48bf-4086-a67a-06902a51ebab) ![Image](https://github.com/user-attachments/assets/442c06bc-8659-4e00-8bab-3b5502993b30) The screenshots show my YAML configuration and the historical execution records, which were working fine before the upgrade. After the upgrade, I found that the environment variables are missing, so I manually added one. Finally, there is a screenshot of the database. ### Git Version _No response_ ### Operating System docker ### How are you running Gitea? docker compose ### Database MySQL/MariaDB

GiteaMirror added the issue/needs-feedback type/bug labels 2025-11-02 11:03:20 -06:00

GiteaMirror closed this issue

2025-11-02 11:03:20 -06:00

GiteaMirror commented

2025-11-02 11:03:20 -06:00

@lunny commented on GitHub (Feb 8, 2025):

Please check whether you changed the security key in the app.ini.

@lunny commented on GitHub (Feb 8, 2025): Please check whether you changed the security key in the app.ini.

GiteaMirror commented

2025-11-02 11:03:21 -06:00

@ysicing commented on GitHub (Feb 8, 2025):

I checked the app.ini file, and the last change was on July 28, 2024.

@ysicing commented on GitHub (Feb 8, 2025): I checked the app.ini file, and the last change was on July 28, 2024. ![Image](https://github.com/user-attachments/assets/eca54c4a-cdf7-4584-9c60-aa429d870291)

GiteaMirror commented

2025-11-02 11:03:21 -06:00

@ysicing commented on GitHub (Feb 8, 2025):

But I noticed that the value of security.SECRET_KEY seems to be empty. How should I fix this? There are hundreds of repositories! 😂

[security]
INSTALL_LOCK = true
SECRET_KEY =
REVERSE_PROXY_LIMIT = 1
REVERSE_PROXY_TRUSTED_PROXIES = *

@ysicing commented on GitHub (Feb 8, 2025): But I noticed that the value of security.SECRET_KEY seems to be empty. How should I fix this? There are hundreds of repositories! 😂 ``` [security] INSTALL_LOCK = true SECRET_KEY = REVERSE_PROXY_LIMIT = 1 REVERSE_PROXY_TRUSTED_PROXIES = * ```

GiteaMirror commented

2025-11-02 11:03:21 -06:00

@lunny commented on GitHub (Feb 8, 2025):

If it's empty, a default value will be given and the code hasn't been changed in two years.

@lunny commented on GitHub (Feb 8, 2025): If it's empty, a default value will be given and the code hasn't been changed in two years.

GiteaMirror commented

2025-11-02 11:03:21 -06:00

@techknowlogick commented on GitHub (Feb 8, 2025):

Which version did you upgrade from?

@techknowlogick commented on GitHub (Feb 8, 2025): Which version did you upgrade from?

GiteaMirror commented

2025-11-02 11:03:21 -06:00

@ysicing commented on GitHub (Feb 9, 2025):

There was no problem in version 1.22. This issue did not exist before the upgrade, and this Gitea service has been running for quite a while. The recent upgrade path is as follows:

You look at the database records. The owner of version 1.22 is 11, which is the organization ID. After upgrading to version 1.23, the value here is changed to 0.

@ysicing commented on GitHub (Feb 9, 2025): There was no problem in version 1.22. This issue did not exist before the upgrade, and this Gitea service has been running for quite a while. The recent upgrade path is as follows: ![Image](https://github.com/user-attachments/assets/6cb433e1-dee8-403e-9c43-acb3536a1c8c) You look at the database records. The owner of version 1.22 is 11, which is the organization ID. After upgrading to version 1.23, the value here is changed to 0. ![Image](https://github.com/user-attachments/assets/fb4b7ee2-5814-46bd-9e00-30ec6676c068)

GiteaMirror commented

2025-11-02 11:03:21 -06:00

@lunny commented on GitHub (Feb 9, 2025):

There was no problem in version 1.22. This issue did not exist before the upgrade, and this Gitea service has been running for quite a while. The recent upgrade path is as follows:

You look at the database records. The owner of version 1.22 is 11, which is the organization ID. After upgrading to version 1.23, the value here is changed to 0.

OK. Maybe that's the bug? maybe caused by #31724 @wolfogre

@lunny commented on GitHub (Feb 9, 2025): > There was no problem in version 1.22. This issue did not exist before the upgrade, and this Gitea service has been running for quite a while. The recent upgrade path is as follows: > > ![Image](https://github.com/user-attachments/assets/6cb433e1-dee8-403e-9c43-acb3536a1c8c) > > You look at the database records. The owner of version 1.22 is 11, which is the organization ID. After upgrading to version 1.23, the value here is changed to 0. > > ![Image](https://github.com/user-attachments/assets/fb4b7ee2-5814-46bd-9e00-30ec6676c068) OK. Maybe that's the bug? maybe caused by #31724 @wolfogre

GiteaMirror commented

2025-11-02 11:03:22 -06:00

@lunny commented on GitHub (Feb 9, 2025):

As a workaround, maybe update all owner_id = 0 if repo_id > 0 manually. Please backup this table before you do any operations.

@lunny commented on GitHub (Feb 9, 2025): As a workaround, maybe update all owner_id = 0 if repo_id > 0 manually. Please backup this table before you do any operations.

GiteaMirror commented

2025-11-02 11:03:22 -06:00

@ysicing commented on GitHub (Feb 11, 2025):

@wolfogre Is there any time you can take a look at this issue?

@ysicing commented on GitHub (Feb 11, 2025): @wolfogre Is there any time you can take a look at this issue?

GiteaMirror commented

2025-11-02 11:03:22 -06:00

@wolfogre commented on GitHub (Feb 11, 2025):

Yes, it is caused by #31724, but it's not a bug; it's by design.

Due to the special nature of secrets, I would rather choose to let Gitea forget some secrets as dirty data (which may bring some inconsistencies, sorry about that) than to let the secrets leak.

@ysicing So please update the database table manually, or recreate those secrets.

@lunny Maybe we can have a doctor tool to fix those dirty data, {OwnerID: x, RepoID: y} -> {OwnerID: 0, RepoID: y}

@wolfogre commented on GitHub (Feb 11, 2025): Yes, it is caused by #31724, but it's not a bug; it's by design. <img width="683" alt="Image" src="https://github.com/user-attachments/assets/fcbf0745-2818-4a5a-8db2-5c78dcbe23da" /> Due to the special nature of secrets, I would rather choose to let Gitea forget some secrets as dirty data (which may bring some inconsistencies, sorry about that) than to let the secrets leak. @ysicing So please update the database table manually, or recreate those secrets. @lunny Maybe we can have a doctor tool to fix those dirty data, `{OwnerID: x, RepoID: y}` -> `{OwnerID: 0, RepoID: y}`

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#14115