github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-05-21 11:55:31 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

LFS pull fails on public SSH-cloned repo #2625

New Issue
Closed
opened 2025-11-02 04:42:34 -06:00 by GiteaMirror · 18 comments
GiteaMirror commented 2025-11-02 04:42:34 -06:00
Owner
Copy Link

Originally created by @flashka07 on GitHub (Dec 5, 2018).

  • 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.

Originally created by @flashka07 on GitHub (Dec 5, 2018). - Gitea version (or commit ref): f17524b - Git version: 2.17.1 - Operating system: official docker image - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] 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.
GiteaMirror added the issue/confirmedtype/bug labels 2025-11-02 04:42:34 -06:00
GiteaMirror commented 2025-11-02 04:42:35 -06:00
Author
Owner
Copy Link

@cnzgray commented on GitHub (Dec 6, 2018):

I have the same problem.

@cnzgray commented on GitHub (Dec 6, 2018): I have the same problem.
GiteaMirror commented 2025-11-02 04:42:35 -06:00
Author
Owner
Copy Link

@techknowlogick commented on GitHub (Dec 6, 2018):

Closing as duplicate of https://github.com/go-gitea/gitea/issues/2475

@techknowlogick commented on GitHub (Dec 6, 2018): Closing as duplicate of https://github.com/go-gitea/gitea/issues/2475
GiteaMirror commented 2025-11-02 04:42:35 -06:00
Author
Owner
Copy Link

@cnzgray commented on GitHub (Dec 7, 2018):

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.

@cnzgray commented on GitHub (Dec 7, 2018): 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.**
GiteaMirror commented 2025-11-02 04:42:36 -06:00
Author
Owner
Copy Link

@techknowlogick commented on GitHub (Dec 7, 2018):

@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

@techknowlogick commented on GitHub (Dec 7, 2018): @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
GiteaMirror commented 2025-11-02 04:42:36 -06:00
Author
Owner
Copy Link

@cnzgray commented on GitHub (Dec 7, 2018):

@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.

@cnzgray commented on GitHub (Dec 7, 2018): @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.
GiteaMirror commented 2025-11-02 04:42:36 -06:00
Author
Owner
Copy Link

@techknowlogick commented on GitHub (Dec 7, 2018):

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

@techknowlogick commented on GitHub (Dec 7, 2018): That sounds reasonable, thank you for taking the time to explain. I will re-open.
GiteaMirror commented 2025-11-02 04:42:36 -06:00
Author
Owner
Copy Link

@flashka07 commented on GitHub (Dec 7, 2018):

@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).

@flashka07 commented on GitHub (Dec 7, 2018): @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).
GiteaMirror commented 2025-11-02 04:42:36 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Feb 9, 2019):

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.

@stale[bot] commented on GitHub (Feb 9, 2019): 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.
GiteaMirror commented 2025-11-02 04:42:37 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Feb 9, 2019):

Can not reproduce this. Is this still a problem?

@lunny commented on GitHub (Feb 9, 2019): Can not reproduce this. Is this still a problem?
GiteaMirror commented 2025-11-02 04:42:37 -06:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Apr 10, 2019):

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.

@stale[bot] commented on GitHub (Apr 10, 2019): 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.
GiteaMirror commented 2025-11-02 04:42:37 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 19, 2019):

this is still relevant, i could not clone with ssh but once LFS was disabled it bypassed the error

edit: but pushing doesn't work with this workaround

@ghost commented on GitHub (Apr 19, 2019): this is still relevant, i could not clone with ssh but once LFS was disabled it bypassed the error edit: but pushing doesn't work with this workaround
GiteaMirror commented 2025-11-02 04:42:37 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Apr 19, 2019):

@laerus could you very quickly give me a minimal test case for this. (I appreciate you can't replicate on try because LFS is turned off.)

@zeripath commented on GitHub (Apr 19, 2019): @laerus could you very quickly give me a minimal test case for this. (I appreciate you can't replicate on try because LFS is turned off.)
GiteaMirror commented 2025-11-02 04:42:37 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Apr 19, 2019):

can you reproduce on the latest docker?

@zeripath commented on GitHub (Apr 19, 2019): can you reproduce on the latest docker?
GiteaMirror commented 2025-11-02 04:42:38 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (May 3, 2019):

@zeripath i've updated to v1.8 and this is still an issue, cannot ssh clone when LFS is enabled and if i disable LFS cloning works but pushing doesn't

@ghost commented on GitHub (May 3, 2019): @zeripath i've updated to v1.8 and this is still an issue, cannot ssh clone when LFS is enabled and if i disable LFS cloning works but pushing doesn't
GiteaMirror commented 2025-11-02 04:42:38 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (May 3, 2019):

Give me a minimal testcase to reproduce and I'll see what I can do. At present I just don't have enough information to figure out what's going wrong and I can't reproduce it.

@zeripath commented on GitHub (May 3, 2019): Give me a minimal testcase to reproduce and I'll see what I can do. At present I just don't have enough information to figure out what's going wrong and I can't reproduce it.
GiteaMirror commented 2025-11-02 04:42:38 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (May 6, 2019):

@zeripath atm i can only reproduce this on the production machine and not on a clean gitea deployment. I will have to do some more digging, if you have any tips on how to debug this i may be able to provide more info.

@ghost commented on GitHub (May 6, 2019): @zeripath atm i can only reproduce this on the production machine and not on a clean gitea deployment. I will have to do some more digging, if you have any tips on how to debug this i may be able to provide more info.
GiteaMirror commented 2025-11-02 04:42:38 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (May 6, 2019):

Hmm... that makes me suspicious that this may be something to do with the setup of that machine. Perhaps proxy settings or something else.

I see you are mounting your gitea as a suburl of a domain? I wonder if there's (another) bug with that. When you try to duplicate are you also mounting as a sub-domain?

@zeripath commented on GitHub (May 6, 2019): Hmm... that makes me suspicious that this may be something to do with the setup of that machine. Perhaps proxy settings or something else. I see you are mounting your gitea as a suburl of a domain? I wonder if there's (another) bug with that. When you try to duplicate are you also mounting as a sub-domain?
GiteaMirror commented 2025-11-02 04:42:39 -06:00
Author
Owner
Copy Link

@nopjmp commented on GitHub (May 18, 2019):

It was mentioned by @zeripath in the #6916 that the two commands cmd/serv and cmd/dump should be modified in order to do internal api requests instead of doing the work themselves. This would allow all internal gitea logging and settings to be centralized to avoid logging to multiple places.

My minimum test case is to make a "public" repo with REQUIRE_SIGNIN_VIEW set to true, and commit at least 1 LFS file.

Thus the following:
requestedMode == models.AccessModeWrite || repo.IsPrivate || setting.Service.RequireSignInView

This is evaluated as false since the requestedMode is Read, repo.IsPrivate is false, and setting.Service.RequireSignInView is false due to the settings not being initialized.

My fix was to initialize the settings like cmd/dump did, but after taking some time to think, I agree with @lunny that this is not the way to fix it and @zeripath idea is best.

@nopjmp commented on GitHub (May 18, 2019): It was mentioned by @zeripath in the #6916 that the two commands cmd/serv and cmd/dump should be modified in order to do internal api requests instead of doing the work themselves. This would allow all internal gitea logging and settings to be centralized to avoid logging to multiple places. My minimum test case is to make a "public" repo with REQUIRE_SIGNIN_VIEW set to true, and commit at least 1 LFS file. Thus the following: `requestedMode == models.AccessModeWrite || repo.IsPrivate || setting.Service.RequireSignInView` This is evaluated as `false` since the requestedMode is Read, repo.IsPrivate is false, and setting.Service.RequireSignInView is false due to the settings not being initialized. My fix was to initialize the settings like cmd/dump did, but after taking some time to think, I agree with @lunny that this is not the way to fix it and @zeripath idea is best.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/confirmed type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#2625
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?