mirror of
https://github.com/go-gitea/gitea.git
synced 2026-03-22 14:34:54 -05:00
checking out repo with LFS fails - keeps on trying to use http authentication #533
Closed
opened 2025-11-02 03:27:15 -06:00 by GiteaMirror
·
21 comments
No Branch/Tag Specified
main
release/v1.25
release/v1.24
release/v1.23
release/v1.22
release/v1.21
release/v1.20
release/v1.19
release/v1.18
release/v1.17
release/v1.16
release/v1.15
release/v1.14
release/v1.13
release/v1.12
release/v1.11
release/v1.10
release/v1.9
release/v1.8
v1.25.3
v1.25.2
v1.25.1
v1.25.0
v1.24.7
v1.25.0-rc0
v1.26.0-dev
v1.24.6
v1.24.5
v1.24.4
v1.24.3
v1.24.2
v1.24.1
v1.24.0
v1.23.8
v1.24.0-rc0
v1.25.0-dev
v1.23.7
v1.23.6
v1.23.5
v1.23.4
v1.23.3
v1.23.2
v1.23.1
v1.23.0
v1.23.0-rc0
v1.24.0-dev
v1.22.6
v1.22.5
v1.22.4
v1.22.3
v1.22.2
v1.22.1
v1.22.0
v1.23.0-dev
v1.22.0-rc1
v1.21.11
v1.22.0-rc0
v1.21.10
v1.21.9
v1.21.8
v1.21.7
v1.21.6
v1.21.5
v1.21.4
v1.21.3
v1.21.2
v1.20.6
v1.21.1
v1.21.0
v1.21.0-rc2
v1.21.0-rc1
v1.20.5
v1.22.0-dev
v1.21.0-rc0
v1.20.4
v1.20.3
v1.20.2
v1.20.1
v1.20.0
v1.19.4
v1.21.0-dev
v1.20.0-rc2
v1.20.0-rc1
v1.20.0-rc0
v1.19.3
v1.19.2
v1.19.1
v1.19.0
v1.19.0-rc1
v1.20.0-dev
v1.19.0-rc0
v1.18.5
v1.18.4
v1.18.3
v1.18.2
v1.18.1
v1.18.0
v1.17.4
v1.18.0-rc1
v1.19.0-dev
v1.18.0-rc0
v1.17.3
v1.17.2
v1.17.1
v1.17.0
v1.17.0-rc2
v1.16.9
v1.17.0-rc1
v1.18.0-dev
v1.16.8
v1.16.7
v1.16.6
v1.16.5
v1.16.4
v1.16.3
v1.16.2
v1.16.1
v1.16.0
v1.15.11
v1.17.0-dev
v1.16.0-rc1
v1.15.10
v1.15.9
v1.15.8
v1.15.7
v1.15.6
v1.15.5
v1.15.4
v1.15.3
v1.15.2
v1.15.1
v1.14.7
v1.15.0
v1.15.0-rc3
v1.14.6
v1.15.0-rc2
v1.14.5
v1.16.0-dev
v1.15.0-rc1
v1.14.4
v1.14.3
v1.14.2
v1.14.1
v1.14.0
v1.13.7
v1.14.0-rc2
v1.13.6
v1.13.5
v1.14.0-rc1
v1.15.0-dev
v1.13.4
v1.13.3
v1.13.2
v1.13.1
v1.13.0
v1.12.6
v1.13.0-rc2
v1.14.0-dev
v1.13.0-rc1
v1.12.5
v1.12.4
v1.12.3
v1.12.2
v1.12.1
v1.11.8
v1.12.0
v1.11.7
v1.12.0-rc2
v1.11.6
v1.12.0-rc1
v1.13.0-dev
v1.11.5
v1.11.4
v1.11.3
v1.10.6
v1.12.0-dev
v1.11.2
v1.10.5
v1.11.1
v1.10.4
v1.11.0
v1.11.0-rc2
v1.10.3
v1.11.0-rc1
v1.10.2
v1.10.1
v1.10.0
v1.9.6
v1.9.5
v1.10.0-rc2
v1.11.0-dev
v1.10.0-rc1
v1.9.4
v1.9.3
v1.9.2
v1.9.1
v1.9.0
v1.9.0-rc2
v1.10.0-dev
v1.9.0-rc1
v1.8.3
v1.8.2
v1.8.1
v1.8.0
v1.8.0-rc3
v1.7.6
v1.8.0-rc2
v1.7.5
v1.8.0-rc1
v1.9.0-dev
v1.7.4
v1.7.3
v1.7.2
v1.7.1
v1.7.0
v1.7.0-rc3
v1.6.4
v1.7.0-rc2
v1.6.3
v1.7.0-rc1
v1.7.0-dev
v1.6.2
v1.6.1
v1.6.0
v1.6.0-rc2
v1.5.3
v1.6.0-rc1
v1.6.0-dev
v1.5.2
v1.5.1
v1.5.0
v1.5.0-rc2
v1.5.0-rc1
v1.5.0-dev
v1.4.3
v1.4.2
v1.4.1
v1.4.0
v1.4.0-rc3
v1.4.0-rc2
v1.3.3
v1.4.0-rc1
v1.3.2
v1.3.1
v1.3.0
v1.3.0-rc2
v1.3.0-rc1
v1.2.3
v1.2.2
v1.2.1
v1.2.0
v1.2.0-rc3
v1.2.0-rc2
v1.1.4
v1.2.0-rc1
v1.1.3
v1.1.2
v1.1.1
v1.1.0
v1.0.2
v1.0.1
v1.0.0
v0.9.99
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
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
Mirrored from GitHub Pull Request
No Label
type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/gitea#533
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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?
Originally created by @kubatyszko on GitHub (Mar 17, 2017).
[x]):I was able to clone non-LFS repo, push some files, even with GIT-LFS and then cloning it fails.
$ git clone ssh://git@git.domain:2222/avd/test.git test1
Cloning into 'test1'...
The authenticity of host '[git.domain]:2222 ([10.61.2.112]:2222)' can't be established.
RSA key fingerprint is SHA256:8x9uZXuGSs4cATzr21c/iU2lhHliale/E94rqCNzsXk.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[git.domain]:2222,[10.61.2.112]:2222' (RSA) to the list of known hosts.
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (4/4), done.
Checking connectivity... done.
Downloading a.bin (4 B)
Username for 'http://git.domain':
Password for 'http://git.domain':
Username for 'http://git.domain':
Password for 'http://git.domain': warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'
$ git lfs env
git-lfs/2.0.1 (GitHub; linux amd64; go 1.8; git 678cdbd4)
git version 2.7.4
Endpoint=https://git.domain/avd/test.git/info/lfs (auth=basic)
SSH=git@git.domain:avd/test.git
LocalWorkingDir=/home/nfs/avd/kuba/test1
LocalGitDir=/home/nfs/avd/kuba/test1/.git
Thanks
@fabian-z commented on GitHub (Mar 17, 2017):
I cannot reproduce this issue either.
auth=basicand your output suggest that the client somehow chose not to try fetching a token with SSH.Please post the full output of
git lfs envinstead of truncating the relevant information.Can you confirm you don't have any .lfsconfig file or [lfs] sections in your .gitconfig?
@fabian-z commented on GitHub (Mar 17, 2017):
For clarification: In the output you posted, did you actually enter valid credentials when asked by the client or did you press return on the prompts?
@kubatyszko commented on GitHub (Mar 17, 2017):
I press return, entering credentials doesn't help.
I do not have any .lfsconfig - tried this on several different clean account as well
@fabian-z commented on GitHub (Mar 17, 2017):
It shows
for me when checking a LFS repository I only used over SSH.
If you are not already using the built-in SSH server, you could try that to rule out issues with your SSH setup. Just add
START_SSH_SERVER = trueto your configuration.@fabian-z commented on GitHub (Mar 17, 2017):
Please also include Gitea debug logs for a clone attempt.
@kubatyszko commented on GitHub (Mar 17, 2017):
I am using builtin SSH server.
I am cloning repo over SSH (and it correctly gets the JWT token over SSH).
I'll be posting logs later investigating another issue related to private repo with LFS cloning
@kubatyszko commented on GitHub (Mar 17, 2017):
I'm going to post it here, since the issue may be related, basically I'm trying to clone a repo (that's marked as private).
I added a ton of debugging information, and I found that at some point it keeps on trying to authenticate me to a repoID==2 while token is granted (claims) for repo==4.
Repo 2 belongs to completely different user, Repo 4 is correct.
The debug info that I added is here:
debug log from gitea is here:
I marked the relevant bit with asterisks, you can see that the first time it goes to batch handler, it passes correct repo (id==4) and the http status on the POST method is 200.
Then, it goes to OID handler and content handler, but then it ends up with repo id==2. - this is why it fails because in the end, the auth token function compares repository.ID with int64(repoID) and simply 2!=4
I haven't investigated why the OID -> content handler thinks it should be repo id==2 yet...
@kubatyszko commented on GitHub (Mar 18, 2017):
Minor update, so far I traced to the GetLFSMetaObjectByOid, when passed OID (a correct object - I verified in the physical lfs storage), somehow it returns a structure that thinks it belongs to repo id==2 not 4.
This may have something to do with the fact I have 4 repos (across different users), and the reason why it's hard to reproduce is because you might have only 1 repo for testing - this is likely why I can't reproduce it my my own mac either.
My repos might be somehow broken - but I'll keep tracing, since I somehow ended up with this situation there may be a bug somewhere...
@kubatyszko commented on GitHub (Mar 18, 2017):
More investigating:
The object in question (17e682) in database clearly belongs to repo id==2 but is should belong to repo id==4...
I'm not wondering whether it's the batch handler that gave the wrong object OID or whether the OID was incorrectly saved in database somehow...
@kubatyszko commented on GitHub (Mar 18, 2017):
I know!!!!
The reason for the OID clash between repos 2 and 4 is that both have a file with the same content - resulting in the same SHA and therefore the same OID.
Database keeps track of what repo the file belongs to (first time added) but when the second repo ended up with the same file it already was in LFS (kind of deduplication).
The solution is likely to have a list of repos in that table instead of a single value.
@fabian-z commented on GitHub (Mar 18, 2017):
Great debugging, thank you!
Funnily enough, I was just about to post the same conclusion since I could reproduce after your hint with multiple repositories.
Since we now know that the OID collision triggers the failure condition, I will look into reworking the OID <-> Repository relation later today.
@kubatyszko commented on GitHub (Mar 18, 2017):
Or alternatively have different index on that table so that the same sha can be stored multiple times with each repo it belongs to.
This will actually work because it will keep track of all the repos.
The only catch will be in the content handler - it has to match one of object's repo Id's (a list perhaps?) with repo is the token is for.
@kubatyszko commented on GitHub (Mar 18, 2017):
Great stuff. I'm glad we figured it out.
Looking forward to seeing your solution to this, happy to test whenever.
@fabian-z commented on GitHub (Mar 19, 2017):
Could you test out my duplicateoids branch?
It did resolve the issue for me in my first tests. However, this still needs validation (see TODOs) in order to prevent a malicious client (with push access to the server) from obtaining object contents by OID without actually proving ownership of or access right for the file.
@kubatyszko commented on GitHub (Mar 20, 2017):
Will check together with the other PR. Looking at the code, I see that you didn't change database schema - how are you planning on keeping track of all the repositories that have given file and ensure that it stays there until the last repository deletes it?
I see that you're trying to access the object this way:
but without changes to database - will it even allow multiple rows with the same OID ?
Looking at the schema, both OID and repository are unique - I don't think database will let you insert multiple rows like that, it would need joint index on both fields together...
@lunny commented on GitHub (Mar 20, 2017):
OidandRepositoryIDis a composite unique@kubatyszko commented on GitHub (Mar 20, 2017):
Ok, I'll verify that as well tomorrow, I'm pretty good with databases, but looking at the xorm spec it's not clear to me that the index (and therefore uniqueness) is composite.
@fabian-z commented on GitHub (Mar 20, 2017):
The data structure is already there since each object is saved together with its repository id. It already works with forks and deletions of repositories.
Have a look at the column definiton manual
@kubatyszko commented on GitHub (Mar 20, 2017):
Ok, I'm clear now on the indexing, verified that my database shows correct index:
I verified both of your patches - the sshfix and duplicateoids,
I tried interacting with multiple repos and ensure that the files with the same oid are saved in the database, you can see at least 87428 and a6a00 repeated twice (3,13 ; 9,12 ).
All seems to be working well, I'm not getting any prompts for http user/password and no issues with lfs so far.
Thank you.
Consider this my LGTM for both patches.
@fabian-z commented on GitHub (Mar 21, 2017):
Thanks for your testing! Nice that everything seems to work out well.
I will sent a PR for the changes in
duplicateoidsas soon as I can finish the verification part.@lunny commented on GitHub (Apr 20, 2017):
resolved by #1328