Github fine grained access token does not work after initial pull

[TheDom42]

I have configured a mirror repo to pull clone a github repo in my account, using the "new"/beta fine-grained access token (instead of classical tokens).

When setting up the repo in gitea, everything works perfectly and the inital pull is fast. However, the automatic cron pull as well as the manual pull fail complete silently:

1. The user initiating the pull manually receives the message that the repos will be synced
2. The cron is marked as "last run at..."
   However, in both cases, no sync actually takes place!

As I'm rather new to gitea, I finally stumbled upon the admin logs which are spammed with messages looking like this:

Failed to update mirror repository '<REDACTED>': fatal: could not read Username for 'https://github.com': 
terminal prompts disabled
error: could not fetch origin

I have set tup the personal access tokens with read-only permissions and only allow access to that specific repo on Github. As the inital setup with the token worked, I was very surprised that the mirror updates fail afterwards.
Just as clarification for me: are the new Github "fine grained access tokens" fully supported yet? If so, which of the repo access rights (https://docs.github.com/en/rest/overview/permissions-required-for-fine-grained-personal-access-tokens?apiVersion=2022-11-28) are mandatory to work for a read-only pull mirror? Do I actually need to set some of them to write permissions (which I would like to avoid)?

Originally posted by @TheDom42 in #20984 (comment)

[Aric-Sun]

My situation is similar to yours, but I'm using classic personal access tokens. The initial pull of the private repo is very fast, but when you click the "Sync Now" button in the repo settings, it will appear in the system prompt of the background management.Failed to update mirror repository 'F:\Gitea\data\gitea-repositories\xxxx\xxxxxx.git': fatal: could not read Username for 'https://github.com': terminal prompts disabled

[lng2020]

What's your Gitea version? Sometimes I encountered issues with the Gitea pull mirror too. But I don't know how to reproduce stably.

[Aric-Sun]

What's your Gitea version? Sometimes I encountered issues with the Gitea pull mirror too. But I don't know how to reproduce stably.

Gitea Ver. 1.20.5 built with GNU Make 4.2.1, go1.20.8 : bindata, sqlite, sqlite_unlock_notify
Git Ver. 2.40.0, Wire Protocol Version 2 Enabled
Windows 10 22H2 Workstation

[Aric-Sun]

I found a detail: when I modify the interval for mirroring a mirror repository in the repository settings (changing the default 8h to 24h), and then click 'Update Mirror Settings,' the automatic mirroring functionality may not work properly. I suspect that leaving the authorization information (the input fields for only username and password) blank when updating the mirror settings will override the reserved personal access token, causing the mirroring to fail.

[delvh]

@Aric-Sun Yes, I think I've observed similar behavior on 1.20.
However, I haven't observed it on 1.21. yet.

[lng2020]

I suspect that leaving the authorization information (the input fields for only username and password) blank when updating the mirror settings will override the reserved personal access token, causing the mirroring to fail.

Yes. I can recall such relevant code because I handled a similar issue before.

[Aric-Sun]

@Aric-Sun Yes, I think I've observed similar behavior on 1.20. However, I haven't observed it on 1.21. yet.

@delvh I am looking forward to the official release of 1.21.

[Aric-Sun]

I suspect that leaving the authorization information (the input fields for only username and password) blank when updating the mirror settings will override the reserved personal access token, causing the mirroring to fail.

Yes. I can recall such relevant code because I handled a similar issue before.

Based on my understanding, shouldn't updating the mirror settings ignore empty fields? So, does changing the sync interval of the mirror repository ultimately need to be modified in the global configuration file, for example:

[cron.update_mirrors]
SCHEDULE = @every 24h

[delvh]

As I said: It's a bug, and I think 1.21. fixed it.