Gitea: LFS Inconsitency with Authentication on Gitea <1.9

[storrgie]

• Gitea version (or commit ref): 1.8.1
• Git version: 2.20.1
• Operating system: debian buster
• Database (use [x]):
  
  
  
  • [x] PostgreSQL
  
  
  • [ ] MySQL
  
  
  • [ ] MSSQL
  
  
  • [ ] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [x] No
  
  
  • [ ] Not relevant
  
  
• Log gist:

Description

I have two instances with identical configurations that I'm reproducing this on (just different domain names). Here is the order of things:

• create a repository under your user account
• clone repository
• git lfs install in repository
• git lfs track "*.jpg"
• copy in a couple images
• git add .
• git commit
• git push

pushing works, cloning on new client system (or another location on the same client system) works. Tested this with a couple client systems and this seems to be consistent.

Do the same thing, but as an organizational repository (instead of user), even as site administrator and as owner of the organization:

• push seems to work
• clone causes a 401 authentication issue on the /info/lfs/objects/batch endpoint

Againt tested this with a couple client systems and this seems to be consistent.

So, from what I gather:

• LFS seems to work well if it is a repository that is created under your own user account
• LFS does not work when it is a repository that is created under an organization

I have tried to reproduce this on the try.gitea.io instance but I can't seem to push (repository object not found?)

[storrgie]

@lunny this is what you and I were talking about earlier.

[bryanpedini]

@storrgie I tried to reproduce your exact steps on my own server on version 1.7.5 and it does not give the same errors, everything seems to work fine...
Test repos can be found at https://git.bryanpedini.it/bryanpedini/test and https://git.bryanpedini.it/School/test.

[storrgie]

I'll repeat, maybe the test procedure was confusing above:

• create repo under user account
• create repo under organization that you are the owner of
• push lfs objects to both repos (should work)
• clone repo from user account to another location on your client machine (should work)
• clone repo from organization to another location on your client machine (get 401 authentication errors)

I am getting this on both of my instances, however both are 1.8.1.

[bryanpedini]

create repo under user account

done

create repo under organization that you are the owner of

done

push lfs objects to both repos (should work)

done ( TXT files )

clone repo from user account to another location on your client machine (should work)

working without problems

clone repo from organization to another location on your client machine (get 401 authentication errors)

unexpectedly working without problems, you can test yourself cloning with the two repos I linkes.

IDK, maybe it's 1.7.5 that does not have this issue...

[storrgie]

It might be, I remember doing some testing of LFS in the late 1.7.x run before turning it on, now I'm trying to use it and it seems to be biting me. It could also be configuration, but I shared configurations with @lunny for him to review and we were both stumped.

[bryanpedini]

Are both instances newly created ones?
Maybe try to recreate the issue with a quick test env installation from the gitea/gitea Docker Hub image or a quick VM with CentOS (lightweight enough) or Debian (also light) if you feel more comfortable with apt instead...

[storrgie]

I'm going to wait for someone to weigh in who is maintaining their test instance as I'd rather reproduce with the instance they are managing. I've already been able to reproduce this consistently on instances I deploy.

[bryanpedini]

Does the issue appears on https://try.gitea.io too?

[storrgie]

I have tried to reproduce this on the try.gitea.io instance but I can't seem to push (repository object not found?)

[bryanpedini]

I have tried to reproduce this on the try.gitea.io instance but I can't seem to push (repository object not found?)

nope...
https://try.gitea.io/johifsdgjikhfsdjihfsaehjisdf_test_org/test - seems to be working... now IDRK...
(did the exact same steps you described), (cloning works too)

[lunny]

Sorry, https://try.gitea.io didn't enable lfs. Could you try it on https://gitea.com ?

[bryanpedini]

Sorry, https://try.gitea.io didn't enable lfs. Could you try it on https://gitea.com ?

AH...
okay... trying it now...







(perfect..... I registered an account with a fake email address and now have to wait 3 hours to registration to timeout to reuse the same username..... I'm a genius.....)

[lunny]

Haven't told you that's need an email confirmation. It's a real site not a try site.

[bryanpedini]

Haven't told you that's need an email confirmation. It's a real site not a try site.

I figured that out by myself.... -.-
Could you delete instances for username "bryanpedini" on DB or resend a confirmation email at [email protected] please? (if you are maintainer there)?

[lunny]

I have deleted it.

[bryanpedini]

Thanks!
Trying the bug now.

[bryanpedini]

Nope, bug not present here: https://gitea.com/bryanpedini_test_org/test_repo
Can push without problems,
Can re clone without problems...

[lunny]

So that some PR fix that I think. Maybe @zeripath could answer and send a back port to v1.8.3 ?

[bryanpedini]

So that some PR fix that I think. Maybe @zeripath could answer and send a back port to v1.8.3 ?

Yeah.. idk, on 1.9.0dev issue is not present...

[lunny]

someone of https://github.com/go-gitea/gitea/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+milestone%3A1.9.0+lfs

[bryanpedini]

Did not say there weren't issues at all, I did say this particular one is not currently present on try.gitea.io and on gitea.com :P

[zeripath]

@Bryanpedini #7082 should fix the last major one I know about - however fixing the problems the inverse of #732 has caused may need #7199 and some admin features.

I'm afraid that if you have successfully merged from a fork with LFS changes you can currently lose LFS stored data if you then delete the fork and don't LFS push to the base repo from a separate checkout.

[bryanpedini]

@zeripath I don't actually know what LFS is 😅
I was just the betatester man for the issue the OP has brought out...

[storrgie]

I am unable to reproduce the same issue on gitea.com:

• https://gitea.com/storrgie/testinglfs
• https://gitea.com/epiphyte/testinglfs

My test sequence was:

• clone repository
• git lfs install
• git lfs track "*.jpg"
• added the three files
• git add .
• git lfs ls-files (confirm lfs is tracking these three images)
• git commit
• git push

then I was able to clone these repositories to another area on my client, and from a second client.

So the version running on gitea.com may resolve this issue. I am now wondering it @Bryanpedini wants to move his version to 1.8.1 to see if he can reproduce this issue there. Also @Bryanpedini I'm not sure you're doing the same thing that I am doing (are you positive that lfs is uploading objects?), when you said your procedure was working on try.gitea.io earlier and LFS was disabled that is a pretty dire sign that you're testing is matching mine.

[bryanpedini]

Also @Bryanpedini I'm not sure you're doing the same thing that I am doing.

Yes, same exact commands (except for git lfs ls-files) which, if there are three files in the repository after pushing, I expect that to be working. Tell me if I'm wrong here.

when you said your procedure was working on try.gitea.io earlier and LFS was disabled that is a pretty dire sign that you're testing is matching mine.

I didn't actually say that LFS was disabled on try.gitea.io ... @lunny did, in fact he gave me the suggestion to try the same things out on gitea.com ... I only tried the same steps over and over and over and over on my website on my account, on my website in an organization, on try.gitea.io in an org, and on gitea.com in an org, since your first problem seemed to be only with organizations' repositories...

I am now wondering it @Bryanpedini wants to move his version to 1.8.1 to see if he can reproduce this issue there.

That's actually for an entire different reason that I want to upgrade... (see #7218)

[storrgie]

@Bryanpedini were you doing all these operations over ssh or http? I would surmise that http is working but ssh isn't due to some pre-auth stuff with JWT not happening.

[zeripath]

I suspect that this a duplicate of #5478

[storrgie]

If its possible to backport fixes that would be great, I suspect it will be a little while before 1.9.x ships.

[zeripath]

Should be fixed by #7224

[storrgie]

I've consumed 1.8.3 and now the above "test" works on both user and organizational repositories.