'git push' over SSH does not close issues, but does over HTTP(S).

[pcopissa]

• 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

[OvermindDL1]

Ah, this explains why commits don't close issues! I see this same issue.

[Etzelia]

For what it's worth, I don't have this issue and I do all my operations via SSH.
Differences in settings:
For a client I use TortoiseGit on Windows 10
My server is running Ubuntu 16.04 with a Git version of 2.7.4

[zeripath]

Hmm. You don't mention setting a key for p.copissa - how do you login through SSH?

Are you just using the generic git username and password?

If so that explains your problem. If you look at the way the authorized_keys file is created for gitea - on login with the appropriate key with id <id> the command: "gitea serv key-<id>" is run, and this sets up the appropriate environment variables for the post-commit hooks that will close issues.

If you don't login with a key that gitea knows about and manages, you will need to set those environment variables yourself.

[pcopissa]

@zeripath: I don't have a key for p.copissa. I do for git (which is also a Centos login), as I wrote above.
But the point is that git push over an HTTP URL doesn't need a key for p.copissa. It happily closes the bug without any (instead git asks for user name and password). No so for SSH: The push does happen but not the close. And to me that looks like a bug:

As I said, if the system trusts me enough to modify the remote repo, why should it not trust me for closing the issue ? Even more so when the same system DOES trust me closing when I have no key !! (i.e. when pushing over HTTP)

[pcopissa]

@Etzelia: I think I will eventually switch to TortoiseGit : It seems to work with both HTTP and SSH, whereas I have trouble with HTTP on GitExtension. (That may be down to how I installed the bits and pieces on that system. MSYS2 came first via a Ruby environment, and the GUI came later but apparently relies on its own subset of MSYS2. Not sure what happens here. And that's off topic here anyway. There is a bit more context on here )

[Etzelia]

It has nothing to do with not trusting you (I think). The likely reason that it doesn't close the issue is because your SSH key is for git, a user not associated within Gitea itself.

When you push using HTTP, you are authenticating as p.copissa, which Gitea can associate with your Gitea user, which it uses to create logs, etc. "This issue was referenced by p.copissa..."

When you push using an SSH key for git, my guess is the commit works because git has access to that repo, as it is the Centos user that Gitea itself uses. However, the SSH key is not associated with a Gitea user, therefore Gitea has no way of knowing who is trying to do what.

If I am way off base, let me know and I'll remove this comment.

EDIT: Adding comment back for reference. I re-read too hastily.
There is a git user in Gitea, however the SSH key was not managed by Gitea. So the above explanation is still plausible.

[pcopissa]

@Etzelia: That looks like a plausible mechanism.
But still... I can specify any user by setting some environment variables (as I wrote) and that user shows up as the committer (and the closer, IIRC. Will try tomorrow in the office) when pushing over HTTP...

[zeripath]

@Etzelia you were right. @pcopissa if the key is not managed by gitea then when you login with SSH, gitea will not do any permissions checks and it's hooks won't work unless you set the environment variables it needs.

[pcopissa]

So what I take from that discussion is that I have to take the trouble to set keys for each Gitea user if I want to use SSH, while I can do the same by not bothering and using HTTP(S) ?
Interesting.

[zeripath]

@pcopissa your findings of the setting environment variables meaning you're able to set yourself as any user is correct. It's why you shouldn't use non managed keys. You'll also find that apart from locked branches no permissions are checked.

Managed keys are sufficiently locked down in the authorized_keys file to prevent users from changing their environment like this (and running other commands).

[pcopissa]

@Etzelia: I re-read your comment above:

your SSH key is for git, a user not associated within Gitea itself.

Actually, I had suspected the issue was authentication or user related, so (as I wrote above) I also created a Gitea user named git and declared it as a contributor. I went as far as using the same password for Centos login git and Gitea user git. Still, that did not allow to close the issue either. So not sure what you mean by the sentence above ?

[Etzelia]

Does the Gitea user git have the SSH key installed?

[pcopissa]

SSH key installed

You mean if I sign in in Gitea web UI as (Gitea user) git, then click on the top right user avatar, then click on Settings, then click on SSH / GPG keys and I should have something there ?
If that's what you mean, then the answer is no, I never added keys there.