pr checkout <number> - no supported methods remain #262

Closed
opened 2020-12-05 19:24:31 +00:00 by khmarbaise · 11 comments
Member

Using current master state of tea:

tea (master)$ ./tea 
NAME:
   tea - Command line tool to interact with Gitea

USAGE:
   tea [global options] command [command options] [arguments...]

VERSION:
   0.5.0+23-g476900a

First overview of login:

test-release-repo (ISSUE-2)$ ~/Downloads/tea-0.5.0-darwin-10.6-amd64 login ls
+-------------+--------------------------+--------------+---------------+---------+
|    NAME     |           URL            |   SSHHOST    |     USER      | DEFAULT |
+-------------+--------------------------+--------------+---------------+---------+
| admin       | http://localhost:3000/   | localhost    | administrator | false   |
| kh.marbaise | http://IP:3000           | IP           | kh.marbaise   | false   |
+-------------+--------------------------+--------------+---------------+---------+

List of PR via 'pr ls':

test-release-repo (ISSUE-2)$ /Users/khmarbaise/go/src/gitea.com/tea/tea pr 
+-------+----------------+-------+-------------+-----------+------------------+
| INDEX |     TITLE      | STATE |   AUTHOR    | MILESTONE |     UPDATED      |
+-------+----------------+-------+-------------+-----------+------------------+
|     8 | ISSUE-2-Take-1 | open  | kh.marbaise |           | 2020-12-05 20:12 |
|     7 | ISSUE-1-Take-2 | open  | kh.marbaise |           | 2020-12-05 19:58 |
+-------+----------------+-------+-------------+-----------+------------------+

Current state in Git:

test-release-repo (ISSUE-2)$ git br
  CHANG1
  ISSUE-1-Take-2
* ISSUE-2
  X1BRANCH
  backport-1.1.X
  master

Now I'm trying to checkout the PR#7:

test-release-repo (ISSUE-2)$ /Users/khmarbaise/go/src/gitea.com/tea/tea pr checkout 7
Fetching PR 7 (head ssh://git@IP:Port/Test/test.git:ISSUE-1-Take-2) from remote 'origin'
2020/12/05 20:15:59 Failed to run app with [/Users/khmarbaise/go/src/gitea.com/tea/tea pr checkout 7]: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

I'm not sure if this related to the fact that the remotes in my repository look like this:

test-release-repo (ISSUE-2)$ git remote -v 
origin	ssh://git@IP:Port/Test/test.git (fetch)
origin	ssh://git@IP:Port/Test/test.git (push)

Furthermore I've observed that I can't set the URL:

tea login add -n kh.marbaise -u ssh://git@IP:Port/Test/test.git -t TOKEN

Maybe I mistaken here a thing (I'm not sure if this related).

Using current master state of `tea`: ``` tea (master)$ ./tea NAME: tea - Command line tool to interact with Gitea USAGE: tea [global options] command [command options] [arguments...] VERSION: 0.5.0+23-g476900a ``` First overview of `login`: ``` test-release-repo (ISSUE-2)$ ~/Downloads/tea-0.5.0-darwin-10.6-amd64 login ls +-------------+--------------------------+--------------+---------------+---------+ | NAME | URL | SSHHOST | USER | DEFAULT | +-------------+--------------------------+--------------+---------------+---------+ | admin | http://localhost:3000/ | localhost | administrator | false | | kh.marbaise | http://IP:3000 | IP | kh.marbaise | false | +-------------+--------------------------+--------------+---------------+---------+ ``` List of PR via 'pr ls': ``` test-release-repo (ISSUE-2)$ /Users/khmarbaise/go/src/gitea.com/tea/tea pr +-------+----------------+-------+-------------+-----------+------------------+ | INDEX | TITLE | STATE | AUTHOR | MILESTONE | UPDATED | +-------+----------------+-------+-------------+-----------+------------------+ | 8 | ISSUE-2-Take-1 | open | kh.marbaise | | 2020-12-05 20:12 | | 7 | ISSUE-1-Take-2 | open | kh.marbaise | | 2020-12-05 19:58 | +-------+----------------+-------+-------------+-----------+------------------+ ``` Current state in Git: ``` test-release-repo (ISSUE-2)$ git br CHANG1 ISSUE-1-Take-2 * ISSUE-2 X1BRANCH backport-1.1.X master ``` Now I'm trying to checkout the PR#7: ``` test-release-repo (ISSUE-2)$ /Users/khmarbaise/go/src/gitea.com/tea/tea pr checkout 7 Fetching PR 7 (head ssh://git@IP:Port/Test/test.git:ISSUE-1-Take-2) from remote 'origin' 2020/12/05 20:15:59 Failed to run app with [/Users/khmarbaise/go/src/gitea.com/tea/tea pr checkout 7]: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain ``` I'm not sure if this related to the fact that the remotes in my repository look like this: ``` test-release-repo (ISSUE-2)$ git remote -v origin ssh://git@IP:Port/Test/test.git (fetch) origin ssh://git@IP:Port/Test/test.git (push) ``` Furthermore I've observed that I can't set the URL: ``` tea login add -n kh.marbaise -u ssh://git@IP:Port/Test/test.git -t TOKEN ``` Maybe I mistaken here a thing (I'm not sure if this related).
Member

This is a duplicate of #253.
Though I'll close the other one as you provided a better bug description ;)

I guess the bug boils down to tea selecting the wrong auth method/key in git.GetAuthForURL().

On my machine the command works fine, so could you provide some details on your SSH setup?

  • Is your gitea ssh key different from ~/.ssh/id_rsa?
  • If so, do you have an ssh agent running?
  • If not, did you specify ssh_key for the kh.marbaise login in your tea config?
  • If not, did you specify a key in ~/.ssh/config for the IP:Port host?
This is a duplicate of #253. Though I'll close the other one as you provided a better bug description ;) I guess the bug boils down to tea selecting the wrong auth method/key in `git.GetAuthForURL()`. On my machine the command works fine, so could you provide some details on your SSH setup? - Is your gitea ssh key different from `~/.ssh/id_rsa`? - If so, do you have an ssh agent running? - If not, did you specify `ssh_key` for the `kh.marbaise` login in your tea config? - If not, did you specify a key in `~/.ssh/config` for the `IP:Port` host?
noerw added the
kind/bug
label 2020-12-06 11:47:52 +00:00
noerw added this to the v0.6.0 milestone 2020-12-06 11:47:59 +00:00
Member

Furthermore I've observed that I can't set the URL:

This is as expected; the -u --url param should include just the hostname of the gitea instance¸possibly prefixed with https://.

> Furthermore I've observed that I can't set the URL: This is as expected; the `-u --url` param should include just the hostname of the gitea instance¸possibly prefixed with `https://`.
Author
Member

This is a duplicate of #253.
Though I'll close the other one as you provided a better bug description ;)

I guess the bug boils down to gitea selecting the wrong auth method in git.GetAuthForURL().

On my machine the command works fine, so could you provide some details on your SSH setup?

  • Is your gitea ssh key different from ~/.ssh/id_rsa?

No it's exactly the same.

  • If so, do you have an ssh agent running?
ps awx | grep ssh-agent

Yes /usr/bin/ssh-agent -l (MacOS).

  • If not, did you specify ssh_key for the kh.marbaise login in your tea config?

No I did not see my tea.yml:

 cat ~/.tea/tea.yml 
logins:
- name: admin
  url: http://localhost:3000/
  token: TOKEN1
  default: false
  ssh_host: localhost
  ssh_key: ""
  insecure: false
  user: administrator
- name: kh.marbaise
  url: http://IP:3000
  token: TOKEN2
  default: false
  ssh_host: IP
  ssh_key: ""
  insecure: false
  user: kh.marbaise
  • If not, did you specify a key in ~/.ssh/config for the IP:Port host?

Nothing defined for that IP:Port combination...

> This is a duplicate of #253. > Though I'll close the other one as you provided a better bug description ;) > > I guess the bug boils down to gitea selecting the wrong auth method in `git.GetAuthForURL()`. > > On my machine the command works fine, so could you provide some details on your SSH setup? > > - Is your gitea ssh key different from `~/.ssh/id_rsa`? No it's exactly the same. > - If so, do you have an ssh agent running? ``` ps awx | grep ssh-agent ``` Yes `/usr/bin/ssh-agent -l` (MacOS). > - If not, did you specify `ssh_key` for the `kh.marbaise` login in your tea config? No I did not see my `tea.yml`: ``` cat ~/.tea/tea.yml logins: - name: admin url: http://localhost:3000/ token: TOKEN1 default: false ssh_host: localhost ssh_key: "" insecure: false user: administrator - name: kh.marbaise url: http://IP:3000 token: TOKEN2 default: false ssh_host: IP ssh_key: "" insecure: false user: kh.marbaise ``` > - If not, did you specify a key in `~/.ssh/config` for the `IP:Port` host? > Nothing defined for that IP:Port combination...
Member

@khmarbaise Thank you! Looks like a standard setup, so this should certainly work.
I'll try to reproduce on my side

@khmarbaise Thank you! Looks like a standard setup, so this should certainly work. I'll try to reproduce on my side
6543 closed this issue 2020-12-07 14:14:57 +00:00
Member

@khmarbaise Could you build tea from #277 and try if you still have this issue?

Please test once with your existing configuration, and then once after re-adding the login to your tea config (tea login edit, tea login add)

@khmarbaise Could you build tea from #277 and try if you still have this issue? Please test once with your existing configuration, and then once after re-adding the login to your tea config (`tea login edit`, `tea login add`)
noerw reopened this issue 2020-12-07 18:10:35 +00:00
Author
Member

First no change in my configuration etc. also login ls as describe above.

So using:

noerw-tea (master)$ git co origin/improve-ssh-handling 
Note: switching to 'origin/improve-ssh-handling'.

$ git log -1 
commit 455269c1427b2136639dda125c9e8bcd11f2f08f (HEAD, origin/improve-ssh-handling)
Author: Norwin Roosen <git@nroo.de>
Date:   Mon Dec 7 18:56:04 2020 +0100

    fix import order

Building via:

make clean; make

The Git state:

test-release-repo (ISSUE-277-2)$ git br
  CHANG1
  ISSUE-1-Take-2
  ISSUE-277-1
* ISSUE-277-2
  X1BRANCH
  backport-1.1.X
  master

Now the list of PR available:

test-release-repo (ISSUE-277-2)$ /..../noerw-tea/tea pr ls
+-------+--------------+-------+-------------+-----------+------------------+
| INDEX |    TITLE     | STATE |   AUTHOR    | MILESTONE |     UPDATED      |
+-------+--------------+-------+-------------+-----------+------------------+
|    10 | -Issue 277-2 | open  | kh.marbaise |           | 2020-12-07 19:54 |
|     9 | Issue 277-1  | open  | kh.marbaise |           | 2020-12-07 19:54 |
+-------+--------------+-------+-------------+-----------+------------------+

So trying to change onto branch ISSUE-277-1 via:

test-release-repo (ISSUE-277-2)$ /.../noerw-tea/tea pr checkout 9
Fetching PR 9 (head http://IP:HTTPPORT/Test/test:ISSUE-277-1) from remote 'pulls/Test'
Created branch 'pulls/9-ISSUE-277-1'

No errors so far but there has been created a branch (which not needed because there does already exist one ISSUE-277-1). This could make sense if I try to get a PR from someone else.

test-release-repo (pulls/9-ISSUE-277-1)$ git br 
  CHANG1
  ISSUE-1-Take-2
  ISSUE-277-1
  ISSUE-277-2
  X1BRANCH
  backport-1.1.X
  master
* pulls/9-ISSUE-277-1

and really astonishing is the following:

test-release-repo (pulls/9-ISSUE-277-1)$ git remote -v 
origin	ssh://git@IP:SSHPORT/Test/test.git (fetch)
origin	ssh://git@IP:SSHPORT/Test/test.git (push)
pulls/Test	http://IP:HTTPPORT/Test/test.git (fetch)
pulls/Test	http://IP:HTTPPORT/Test/test.git (push)

Added a supplemental remote with a different transport protocol (http instead of ssh based on the information from login ls maybe this could/should be controled different? ) for a PR which is coming from a different repository it makes sense...

The question is if it would be possible to give some options to prevent generation of new branch and supplemental remote...(maybe special case and should be discussed in a different issue).

First no change in my configuration etc. also `login ls` as describe above. So using: ``` noerw-tea (master)$ git co origin/improve-ssh-handling Note: switching to 'origin/improve-ssh-handling'. $ git log -1 commit 455269c1427b2136639dda125c9e8bcd11f2f08f (HEAD, origin/improve-ssh-handling) Author: Norwin Roosen <git@nroo.de> Date: Mon Dec 7 18:56:04 2020 +0100 fix import order ``` Building via: ``` make clean; make ``` The Git state: ``` test-release-repo (ISSUE-277-2)$ git br CHANG1 ISSUE-1-Take-2 ISSUE-277-1 * ISSUE-277-2 X1BRANCH backport-1.1.X master ``` Now the list of PR available: ``` test-release-repo (ISSUE-277-2)$ /..../noerw-tea/tea pr ls +-------+--------------+-------+-------------+-----------+------------------+ | INDEX | TITLE | STATE | AUTHOR | MILESTONE | UPDATED | +-------+--------------+-------+-------------+-----------+------------------+ | 10 | -Issue 277-2 | open | kh.marbaise | | 2020-12-07 19:54 | | 9 | Issue 277-1 | open | kh.marbaise | | 2020-12-07 19:54 | +-------+--------------+-------+-------------+-----------+------------------+ ``` So trying to change onto branch `ISSUE-277-1` via: ``` test-release-repo (ISSUE-277-2)$ /.../noerw-tea/tea pr checkout 9 Fetching PR 9 (head http://IP:HTTPPORT/Test/test:ISSUE-277-1) from remote 'pulls/Test' Created branch 'pulls/9-ISSUE-277-1' ``` No errors so far but there has been created a branch (which not needed because there does already exist one `ISSUE-277-1`). This could make sense if I try to get a PR from someone else. ``` test-release-repo (pulls/9-ISSUE-277-1)$ git br CHANG1 ISSUE-1-Take-2 ISSUE-277-1 ISSUE-277-2 X1BRANCH backport-1.1.X master * pulls/9-ISSUE-277-1 ``` and really astonishing is the following: ``` test-release-repo (pulls/9-ISSUE-277-1)$ git remote -v origin ssh://git@IP:SSHPORT/Test/test.git (fetch) origin ssh://git@IP:SSHPORT/Test/test.git (push) pulls/Test http://IP:HTTPPORT/Test/test.git (fetch) pulls/Test http://IP:HTTPPORT/Test/test.git (push) ``` Added a supplemental remote with a different transport protocol (http instead of ssh based on the information from `login ls` maybe this could/should be controled different? ) for a PR which is coming from a different repository it makes sense... The question is if it would be possible to give some options to prevent generation of new branch and supplemental remote...(maybe special case and should be discussed in a different issue).
Member

@khmarbaise thanks for testing.
With the changes in my branch, tea will always use https remotes, unless a ssh key has been configured for the login (which now happens automatically during tea login add, or manually by filling in a path in ssh_key in tea.yml).
So that explains why it is https.

If the branch is already present in the local repo, no new branch or remote should be added (we search for a branch whose PR URL & remote URL point to the same repo).
This check fails however, when you have a ssh remote with explicit port specified, as tea has no way to tell which ssh and http host:port tuples point to the same gitea instance. I'm not sure if we can do anything about that.

This problem should not be present, when you configure tea with your ssh key as described above; then the existing branch & ssh remote should be reused.

@khmarbaise thanks for testing. With the changes in my branch, tea will always use https remotes, unless a ssh key has been configured for the login (which now happens automatically during `tea login add`, or manually by filling in a path in `ssh_key` in `tea.yml`). So that explains why it is https. If the branch is already present in the local repo, no new branch or remote should be added (we search for a branch whose PR URL & remote URL point to the same repo). This check fails however, when you have a ssh remote with explicit port specified, as tea has no way to tell which ssh and http `host:port` tuples point to the same gitea instance. I'm not sure if we can do anything about that. This problem should not be present, when you configure tea with your ssh key as described above; then the existing branch & ssh remote should be reused.
Member

@khmarbaise I finally could reproduce the issue by starting a fresh instance of ssh-agent without any keys added. Can you verify that ssh-agent actually holds your key via ssh-add -l?
If it's not listed there, your ssh setup is broken (-> either ssh-agent shouldn't be running or it should list your key).

edit:
If a broken setup like this is common (it seems so looking at repeated bug reports), tea should handle this gracefully, falling back to file-based publickey auth.
It turns out that this is rather tricky to implement with go-git / golang.org/x/crypto/ssh: golang's ssh lib does not support providing two different publickey auth methods (i.e. ssh-agent based & file system based), because it tries to be smart and skips methods of the same type if the type was already tried.

I patched that function, so now we have a working fallback. Question is, do we really want to maintain a local patch to x/crypto/ssh? You can take a look at the patches here..

@khmarbaise I finally could reproduce the issue by starting a fresh instance of ssh-agent without any keys added. Can you verify that ssh-agent actually holds your key via `ssh-add -l`? If it's not listed there, your ssh setup is broken (-> either ssh-agent shouldn't be running or it should list your key). *edit:* If a broken setup like this is common (it seems so looking at repeated bug reports), tea should handle this gracefully, falling back to file-based publickey auth. It turns out that this is rather tricky to implement with `go-git` / `golang.org/x/crypto/ssh`: golang's ssh lib does not support providing two different publickey auth methods (i.e. ssh-agent based & file system based), because it tries to be smart and [skips methods of the same type if the type was already tried](https://gitea.com/gitea/tea/src/commit/a91168fd366e3d23eff3ccefce1a7d2535ca33f9/vendor/golang.org/x/crypto/ssh/client_auth.go#L51-L55). I patched that function, so now we have a working fallback. Question is, do we really want to maintain a local patch to `x/crypto/ssh`? You can take a look at the patches [here](https://gitea.com/noerw/tea/compare/68710c790e...ssh-agent-fallback)..
6543 referenced this issue from a commit 2020-12-11 13:42:42 +00:00
Owner

@khmarbaise can you recheck current master if the issue still exist?

@khmarbaise can you recheck current master if the issue still exist?
Author
Member

@noerw Can you explain in which way the ssh setup is broken ? and I've rechecked ssh-agent and it does not hold any key:

test-release-repo (CHANGE-2)$ ssh-add -l
The agent has no identities.

So checking against tea master (f5b0004a52)

test-release-repo (master)$ /../gitea.com/tea/tea login ls 
+-------------+--------------------------+--------------+-------------+---------+
|    NAME     |           URL            |   SSHHOST    |    USER     | DEFAULT |
+-------------+--------------------------+--------------+-------------+---------+
| kh.marbaise | http://IP:HTTPPort       | IP           | kh.marbaise | false   |
+-------------+--------------------------+--------------+-------------+---------+

So the list of git branches and my current location:

test-release-repo (CHANGE-2)$ git br 
  CHANGE-1
* CHANGE-2
  master

Furthermore the list of PR's which are avaialable on Gitea:

test-release-repo (CHANGE-2)$ /...//gitea.com/tea/tea pr
+-------+----------+-------+-------------+-----------+------------------+
| INDEX |  TITLE   | STATE |   AUTHOR    | MILESTONE |     UPDATED      |
+-------+----------+-------+-------------+-----------+------------------+
|    12 | CHANGE-2 | open  | kh.marbaise |           | 2020-12-12 20:09 |
|    11 | CHANGE 1 | open  | kh.marbaise |           | 2020-12-12 20:09 |
+-------+----------+-------+-------------+-----------+------------------+

So now I try to get PR with index 11 (branch: CHANGE 1)

test-release-repo (CHANGE-2)$ /.../gitea.com/tea/tea pr checkout 11
Fetching PR 11 (head ssh://git@IP:SSHPORT/Test/test:CHANGE-1) from remote 'origin'
2020/12/12 20:23:10 Failed to run app with [/.../gitea.com/tea/tea pr checkout 11]: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

I've realized one change in the ~/.tea/tea.yml file:

logins:
- name: kh.marbaise
  url: http://IP:HTTPPORT
  token: TOKEN
  default: false
  ssh_host: IP
  ssh_key: ~/.ssh/id_rsa
  insecure: false
  user: kh.marbaise
  created: 1607800041

The ssh_key has been set which hasn't been before.

Also check as suggested to use:

test-release-repo (CHANGE-2)$ git fetch --all 
Fetching origin
@noerw Can you explain in which way the ssh setup is broken ? and I've rechecked ssh-agent and it does not hold any key: ``` test-release-repo (CHANGE-2)$ ssh-add -l The agent has no identities. ``` So checking against `tea` master (f5b0004a524fd55a6abd81fb7dbb95a7b3a8ef2c) ``` test-release-repo (master)$ /../gitea.com/tea/tea login ls +-------------+--------------------------+--------------+-------------+---------+ | NAME | URL | SSHHOST | USER | DEFAULT | +-------------+--------------------------+--------------+-------------+---------+ | kh.marbaise | http://IP:HTTPPort | IP | kh.marbaise | false | +-------------+--------------------------+--------------+-------------+---------+ ``` So the list of git branches and my current location: ``` test-release-repo (CHANGE-2)$ git br CHANGE-1 * CHANGE-2 master ``` Furthermore the list of PR's which are avaialable on Gitea: ``` test-release-repo (CHANGE-2)$ /...//gitea.com/tea/tea pr +-------+----------+-------+-------------+-----------+------------------+ | INDEX | TITLE | STATE | AUTHOR | MILESTONE | UPDATED | +-------+----------+-------+-------------+-----------+------------------+ | 12 | CHANGE-2 | open | kh.marbaise | | 2020-12-12 20:09 | | 11 | CHANGE 1 | open | kh.marbaise | | 2020-12-12 20:09 | +-------+----------+-------+-------------+-----------+------------------+ ``` So now I try to get PR with index 11 (branch: CHANGE 1) ``` test-release-repo (CHANGE-2)$ /.../gitea.com/tea/tea pr checkout 11 Fetching PR 11 (head ssh://git@IP:SSHPORT/Test/test:CHANGE-1) from remote 'origin' 2020/12/12 20:23:10 Failed to run app with [/.../gitea.com/tea/tea pr checkout 11]: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain ``` I've realized one change in the `~/.tea/tea.yml` file: ``` logins: - name: kh.marbaise url: http://IP:HTTPPORT token: TOKEN default: false ssh_host: IP ssh_key: ~/.ssh/id_rsa insecure: false user: kh.marbaise created: 1607800041 ``` The `ssh_key` has been set which hasn't been before. Also check as suggested to use: ``` test-release-repo (CHANGE-2)$ git fetch --all Fetching origin ```
Member

Can you explain in which way the ssh setup is broken ? and I've rechecked ssh-agent and it does not hold any key:

@khmarbaise If you have the environment variable SSH_AUTH_SOCK set, SSH clients are inclined to use the SSH agent listening at that socket for key management. tea is no exception, and tries to authenticate using that ssh-agent.

This fails in your case, as your ssh-agent has no keys registered in it. I'm not sure how that happens; scripts that start ssh-agent and export SSH_AUTH_SOCK usually also take care of populating the agent with keys (eg. from ~/.ssh dir).
The solution is to either stop ssh-agent from running, or to have it hold your keys.

I'm closing this issue, as this is not a tea bug. If this problem comes up more often, we can consider making tea handle this case with a fallback as outlined in this comment, but thats tricky.

> Can you explain in which way the ssh setup is broken ? and I've rechecked ssh-agent and it does not hold any key: @khmarbaise If you have the environment variable `SSH_AUTH_SOCK` set, SSH clients are inclined to use the SSH agent listening at that socket for key management. tea is no exception, and tries to authenticate using that ssh-agent. This fails in your case, as your ssh-agent has no keys registered in it. I'm not sure how that happens; scripts that start ssh-agent and export `SSH_AUTH_SOCK` usually also take care of populating the agent with keys (eg. from `~/.ssh` dir). The solution is to either stop ssh-agent from running, or to have it hold your keys. I'm closing this issue, as this is not a tea bug. If this problem comes up more often, we can consider making tea handle this case with a fallback as outlined in [this comment](https://gitea.com/gitea/tea/issues/262#issuecomment-121788), but thats tricky.
noerw closed this issue 2020-12-12 21:22:43 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/tea#262
No description provided.