• Gitea version (or commit ref): 1.5.2
• Git version: 2.18
• Operating system: CentOS 7.5 (server) / Windows 10 (client)
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • [?] MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

0a) On on Centos 7.5 server, installed Gitea 1.5.2, git 2.18 (Followed steps at https://docs.gitea.io/en-us/install-from-binary/). Started Gitea web server as a service.
0b) On Windows 10 client, installed MSYS2 git 2.15 + Putty. Substituted ssh with Putty's PLINK.EXE by setting the GIT_SSH environment variable. Also start PAGEANT.EXE and insert the ppk file for Centos login git who is running gitea service.

1. Sign up first (administrative) account p.copissa via web UI, and setup the server with a few custom values (as shown in the Site administration > Configuration web page):

Gitea Base URL           http://git.lan:3000/
SSH Server Domain        git.lan
Repository Root Path     /var/lib/git
Static File Root Path    /var/lib/gitea
Log Path                 /var/lib/gitea/log

Also register a Gitea user named git with the same password as the Centos git login.

2. In the web UI, log in as p.copissa, create a repository test, (be sure to tick the check box Initialize Repository to avoid issue When creating repo without init it shows still howto #2898), create two issues (Rename import paths: "github.com/gogits/gogs" -> "github.com/go-gitea/gitea" #1 and Fix sender of issue notifications #2).

3. On the client, clone repository test via HTTP (or HTTPS) using git.exe command:
   git clone http://git.lan:3000/p.copissa/test.git test-http

4. On the client, create a new file, commit and push it:
   git commit -a -m "this fixes issue #1"
git push
   (specify user p.copissa and give its Gitea password when asked)

5. In the web UI, refresh the issues: Issue Rename import paths: "github.com/gogits/gogs" -> "github.com/go-gitea/gitea" #1 is now closed, as expected. Look at the file: the new file has shown up with the expected commit message.

6. On the client, redo step 3 but this time use SSH:
   git clone git@git.lan:p.copissa/test.git test-ssh

7. Redo step 4 but with issue 2:
   git commit -a -m "this fixes issue #2"
git push
   Note that no username nor password is asked. Also note that the Gitea user git has the same password as Centos git login.

8. In the web UI, refresh the issue: Issue 2 is still opened. Click on the Code tab: The commit of step 7 is there with the user name git. In fact you can choose whatever user name on the client (via git config user.name whatever and mail as well) and the commit is there bearing that name. But closing the issue always fails even when user name is the owner or a collaborator.

Expected behavior:
At step 8, issue #2 should be closed, like it was at step 2. In general, closing issues should not depend on the protocol used. If the remote server trusted the user to commit, then it should trust him to close the issue as well.

See also https://discourse.gitea.io/t/how-to-close-an-issue-with-a-commit-push/604/23 for more context.

Screenshots