Unable to update Personal Access Tokens for GitHub pull-mirror repositories #9536

New Issue

GiteaMirror · 2025-11-02T08:42:11-06:00

GiteaMirror commented

2025-11-02 08:42:11 -06:00

Originally created by @g-a-c on GitHub (Sep 8, 2022).

Description

I had some GitHub → Gitea pull mirrors working, but I need to rotate the GitHub token. I could not find any documentation about how to do this, but I narrowed it down to the Mirror Settings part of the Settings page in the repository.

The Mirror Settings page shows:
Clone from URL: https://github.com/g-a-c/myrepo.git
Authorization/Username: oauth2
Authorization/Password: (Unchanged)

I then paste my new GitHub Personal Access Token into the Password box, and click the Update Settings button below the Password field. I get a green message saying “The repository settings have been updated.”

I have verified in my browser DevTools that the HTTPS POST to https://gitea.mydomain.com/g-a-c/myrepo/settings does contain the new token in the mirror_password field of the form data.

However. When I check the gitea.log file, I still see a SQL update happening with the old token.

2022/09/05 21:43:51 .../web/repo/setting.go:237:SettingsPost() [I] [63166d97] [SQL] UPDATE `repository` SET `original_url` = ?, `updated_unix` = ? WHERE `id`=? [https://oauth2:ghp_REDACTED_OLD_TOKEN@github.com/g-a-c/myrepo.git 1662414231 87] - 6.627054ms

When I look inside the SQLite database manually, I see the old token assigned to repo 87

sqlite> select id,name,original_url,is_mirror from repository where id=87;
87|myrepo|https://oauth2:ghp_REDACTED_OLD_TOKEN@github.com/g-a-c/myrepo.git|1

And when I check the Git config file on the container filesystem, I see the old token

[remote "origin"]
        url = https://oauth2:ghp_REDACTED_OLD_TOKEN@github.com/g-a-c/myrepo.git

I’m running Gitea v1.17.1, inside a Docker container, with a SQLite database, behind Traefik as a reverse proxy.

I have not yet tried this on the public demo site as this means potentially cloning private repositories to a public instance. But I'm happy to do this if it's considered necessary.

Gitea Version

1.17.1

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

Debian 11 amd64, Docker 20.11

How are you running Gitea?

Docker
Compose
Gitea official image gitea/gitea:1.17.1
- SQLite backend
- Local filesystem bind mount
Traefik 2.8 reverse proxy
- HTTPS via Traefik HTTPS service
- SSH via Traefik TCP service

Database

SQLite

Originally created by @g-a-c on GitHub (Sep 8, 2022). ### Description I had some GitHub → Gitea pull mirrors working, but I need to rotate the GitHub token. I could not find any documentation about how to do this, but I narrowed it down to the Mirror Settings part of the Settings page in the repository. The Mirror Settings page shows: Clone from URL: `https://github.com/g-a-c/myrepo.git` Authorization/Username: `oauth2` Authorization/Password: `(Unchanged)` I then paste my new GitHub Personal Access Token into the Password box, and click the Update Settings button below the Password field. I get a green message saying “The repository settings have been updated.” I have verified in my browser DevTools that the HTTPS POST to `https://gitea.mydomain.com/g-a-c/myrepo/settings` **does** contain the new token in the `mirror_password` field of the form data. However. When I check the `gitea.log` file, I still see a SQL update happening with the **old** token. ``` 2022/09/05 21:43:51 .../web/repo/setting.go:237:SettingsPost() [I] [63166d97] [SQL] UPDATE `repository` SET `original_url` = ?, `updated_unix` = ? WHERE `id`=? [https://oauth2:ghp_REDACTED_OLD_TOKEN@github.com/g-a-c/myrepo.git 1662414231 87] - 6.627054ms ``` When I look inside the SQLite database manually, I see the old token assigned to repo 87 ``` sqlite> select id,name,original_url,is_mirror from repository where id=87; 87|myrepo|https://oauth2:ghp_REDACTED_OLD_TOKEN@github.com/g-a-c/myrepo.git|1 ``` And when I check the Git config file on the container filesystem, I see the old token ``` [remote "origin"] url = https://oauth2:ghp_REDACTED_OLD_TOKEN@github.com/g-a-c/myrepo.git ``` I’m running Gitea v1.17.1, inside a Docker container, with a SQLite database, behind Traefik as a reverse proxy. I have not yet tried this on the public demo site as this means potentially cloning private repositories to a public instance. But I'm happy to do this if it's considered necessary. ### Gitea Version 1.17.1 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System Debian 11 amd64, Docker 20.11 ### How are you running Gitea? - Docker - Compose - Gitea official image `gitea/gitea:1.17.1` - SQLite backend - Local filesystem bind mount - Traefik 2.8 reverse proxy - HTTPS via Traefik HTTPS service - SSH via Traefik TCP service ### Database SQLite

GiteaMirror added the type/bug label 2025-11-02 08:42:11 -06:00

GiteaMirror closed this issue

2025-11-02 08:42:11 -06:00

GiteaMirror commented

2025-11-02 08:42:12 -06:00

@g-a-c commented on GitHub (Sep 15, 2022):

To be clear, after it was pointed out to me on the Gitea Discord - this causes pulls (either with Synchronize Now, or on the timer) to fail with authorization errors

@g-a-c commented on GitHub (Sep 15, 2022): To be clear, after it was pointed out to me on the Gitea Discord - this causes pulls (either with Synchronize Now, or on the timer) to fail with authorization errors

GiteaMirror commented

2025-11-02 08:42:13 -06:00

@SeanOMik commented on GitHub (Sep 15, 2022):

I'm also running into this issue. I was able to get it working temporarily by deleting the repo on Gitea and re-migrating it from GitHub to Gitea as a mirror and immediately setting the authorization token but after a restart of the docker-compose services, it goes back to failing with authorization errors.

@SeanOMik commented on GitHub (Sep 15, 2022): I'm also running into this issue. I was able to get it working temporarily by deleting the repo on Gitea and re-migrating it from GitHub to Gitea as a mirror and immediately setting the authorization token but after a restart of the docker-compose services, it goes back to failing with authorization errors.

GiteaMirror commented

2025-11-02 08:42:13 -06:00

@lunny commented on GitHub (Sep 16, 2022):

Have you tried v1.17.2?

@lunny commented on GitHub (Sep 16, 2022): Have you tried v1.17.2?

GiteaMirror commented

2025-11-02 08:42:13 -06:00

@g-a-c commented on GitHub (Sep 16, 2022):

Have you tried v1.17.2?

I haven't, it didn't exist when I saw this problem. I don't see anything in the release notes that stands out to me that would address this, but I'll upgrade and try updating the tokens again to see what happens.

@g-a-c commented on GitHub (Sep 16, 2022): > Have you tried v1.17.2? I haven't, it didn't exist when I saw this problem. I don't see anything in the release notes that stands out to me that would address this, but I'll upgrade and try updating the tokens again to see what happens.

GiteaMirror commented

2025-11-02 08:42:14 -06:00

@g-a-c commented on GitHub (Sep 16, 2022):

OK, it looks like 1.17.2 may have fixed it - I do now see one entry in the release notes referring to invalid CloneURL, perhaps that's the thing that's addressed it? I will now need to go through all the mirrors and update them to make sure they all work afterwards - perhaps there is value in a feature request here to be able to store a GitHub Personal Access Token either globally or as part of an organisation containing all mirrors so that tokens can be rotated even more easily? It does look like the actual bug is now fixed though

@g-a-c commented on GitHub (Sep 16, 2022): OK, it looks like 1.17.2 may have fixed it - I do now see one entry in the release notes referring to invalid CloneURL, perhaps that's the thing that's addressed it? I will now need to go through all the mirrors and update them to make sure they all work afterwards - perhaps there is value in a feature request here to be able to store a GitHub Personal Access Token either globally or as part of an organisation containing all mirrors so that tokens can be rotated even more easily? It does look like the actual bug is now fixed though

GiteaMirror commented

2025-11-02 08:42:14 -06:00

@SeanOMik commented on GitHub (Sep 16, 2022):

1.17.2 fixes it for me, thanks!

@SeanOMik commented on GitHub (Sep 16, 2022): 1.17.2 fixes it for me, thanks!

GiteaMirror commented

2025-11-02 08:42:14 -06:00

@lunny commented on GitHub (Sep 17, 2022):

OK, it looks like 1.17.2 may have fixed it - I do now see one entry in the release notes referring to invalid CloneURL, perhaps that's the thing that's addressed it? I will now need to go through all the mirrors and update them to make sure they all work afterwards - perhaps there is value in a feature request here to be able to store a GitHub Personal Access Token either globally or as part of an organisation containing all mirrors so that tokens can be rotated even more easily? It does look like the actual bug is now fixed though

A secret storage PR #14483 should fix that.

@lunny commented on GitHub (Sep 17, 2022): > OK, it looks like 1.17.2 may have fixed it - I do now see one entry in the release notes referring to invalid CloneURL, perhaps that's the thing that's addressed it? I will now need to go through all the mirrors and update them to make sure they all work afterwards - perhaps there is value in a feature request here to be able to store a GitHub Personal Access Token either globally or as part of an organisation containing all mirrors so that tokens can be rotated even more easily? It does look like the actual bug is now fixed though A secret storage PR #14483 should fix that.

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#9536