LFS pull fails on public SSH-cloned repo

[flashka07]

• Gitea version (or commit ref): f17524b
• Git version: 2.17.1
• Operating system: official docker image
• 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:

The problem is that one can't even clone a repo with LFS over SSH if the repo isn't private.
'GIT_TRACE=1 GIT_CURL_VERBOSE=1 git lfs pull'
fails with
'trace git-lfs: api error: Authentication required: Authorization error: https://example.com/gitea/user/repo.git/info/lfs/objects/batch', which is indeed 'HTTP/1.1 401 Unauthorized'.

It is the case because this fragment

		userID, ok := claims["user"].(float64)
		if !ok {
			return nil, r, opStr, fmt.Errorf("Token user id invalid")
		}

in modules/lfs/server.go (parseToken) gives an error.

From the other side command
'ssh -- git@example.com git-lfs-authenticate user/repo.git download'
returns auth token without 'user' field because this condition

if requestedMode == models.AccessModeWrite || repo.IsPrivate || setting.Service.RequireSignInView

in cmd/serv.go (runServ) is false. It is even false if one has 'REQUIRE_SIGNIN_VIEW = true' in his config, because noone initializes setting.Service.RequireSignInView (setting.newService() doesn't get called I guess).
Changing repo type to private solves the problem, but here is the bug anyway.
I also think that initalizing RequireSignInView should be performed, but this is not a proper solution to the issue, since HTTPS cloning of public repo works fine with the same settings.

[cnzgray]

I have the same problem.

[techknowlogick]

Closing as duplicate of #2475

[cnzgray]

I think this is not the same as #2475.

The problem is that using git-lfs-authenticate will get the correct response in the private repository.

In the public repository, but its own gitea's REQUIRE_SIGNIN_VIEW=true, an unauthorized exception was raised.

[techknowlogick]

@cnzgray my understanding of this issue is that LFS fails when trying to clone via SSH, because LFS isn't supported under SSH per linked issue. So I think that the linked issue should be solved first because then this issue might not even exist. @flashka07 is free to open this issue again, and if so I will relabel it as bug

[cnzgray]

@techknowlogick You are right, the essence of the problem is the transmission of LFS under SSH. However, for LFS related issues under SSH, there is still no complete point in time.

The current gitea support for git-lfs-authenticate is correct (git clone uses ssh, LFS uses http), there is only one bug.

When the gitea site is set to be authorized to access, the token of the public repository in the site cannot be correctly identified.

thank you very much.

[techknowlogick]

That sounds reasonable, thank you for taking the time to explain. I will re-open.

[flashka07]

@cnzgray exactly, thank you.
I think it is reasonable to add user id to the token in any case (either on download or upload action), if the git-lfs-authenticate is being issued via ssh (I don't know if it can be issued by someone not via ssh), because there is no anonymous ssh access at all.
It will solve both mentioned problems (ignorance of REQUIRE_SIGNIN_VIEW and cloning public repositories without 'sign-in' restriction).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[lunny]

Can not reproduce this. Is this still a problem?