LFS Inconsitency with Authentication on Gitea <1.9 #7219

andrewgdunn · 2019-06-16T13:30:20Z

Gitea version (or commit ref): 1.8.1
Git version: 2.20.1
Operating system: debian buster
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

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?)

The text was updated successfully, but these errors were encountered:

andrewgdunn · 2019-06-16T13:31:35Z

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

bryanpedini · 2019-06-16T13:47:12Z

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

andrewgdunn · 2019-06-16T13:53:51Z

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 · 2019-06-16T13:57:25Z

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

andrewgdunn · 2019-06-16T13:59:33Z

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 · 2019-06-16T14:01:56Z

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

andrewgdunn · 2019-06-16T14:03:44Z

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 · 2019-06-16T14:04:42Z

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

andrewgdunn · 2019-06-16T14:05:18Z

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

bryanpedini · 2019-06-16T14:14:45Z

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 · 2019-06-16T14:16:18Z

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

bryanpedini · 2019-06-16T14:18:19Z

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 · 2019-06-16T14:27:50Z

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

bryanpedini · 2019-06-16T14:31:20Z

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 · 2019-06-16T14:32:28Z

I have deleted it.

bryanpedini · 2019-06-16T14:33:54Z

Thanks!
Trying the bug now.

bryanpedini · 2019-06-16T14:39:50Z

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

lunny · 2019-06-16T14:43:04Z

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

bryanpedini · 2019-06-16T14:44:43Z

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 · 2019-06-16T14:46:16Z

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

bryanpedini · 2019-06-16T14:52:22Z

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 · 2019-06-16T15:13:16Z

@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 · 2019-06-16T15:24:41Z

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

andrewgdunn · 2019-06-16T15:33:00Z

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

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 · 2019-06-16T16:56:17Z

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)

andrewgdunn · 2019-06-16T17:23:56Z

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

Fix go-gitea#5478 Fix go-gitea#7219

zeripath · 2019-06-16T19:56:34Z

I suspect that this a duplicate of #5478

andrewgdunn · 2019-06-16T20:33:56Z

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

* Always set userID on LFS authentication Fix go-gitea#5478 Fix go-gitea#7219 * Deploy keys should only be able to read their repos

zeripath · 2019-06-18T03:06:14Z

Should be fixed by #7224

andrewgdunn · 2019-06-18T03:08:05Z

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

lunny mentioned this issue Jun 16, 2019

Fix LFS Locks over SSH #6999

Merged

zeripath mentioned this issue Jun 16, 2019

Fix LFS Locks over SSH (#6999) #7223

Merged

zeripath added a commit to zeripath/gitea that referenced this issue Jun 16, 2019

Always set userID on LFS authentication

6ea7c0a

Fix go-gitea#5478 Fix go-gitea#7219

zeripath mentioned this issue Jun 16, 2019

Always set userID on LFS authentication #7224

Merged

zeripath changed the title ~~LFS Inconsitency with Authentication~~ LFS Inconsitency with Authentication on Gitea <1.9 Jun 16, 2019

jonas-hagen mentioned this issue Jun 17, 2019

LFS and deploy key: Authorization error on private repos #7227

Closed

jolheiser pushed a commit to jolheiser/gitea that referenced this issue Jun 17, 2019

Always set userID on LFS authentication (go-gitea#7224)

5d1a8d2

* Always set userID on LFS authentication Fix go-gitea#5478 Fix go-gitea#7219 * Deploy keys should only be able to read their repos

zeripath closed this as completed Jun 18, 2019

go-gitea locked and limited conversation to collaborators Nov 24, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

LFS Inconsitency with Authentication on Gitea <1.9 #7219

LFS Inconsitency with Authentication on Gitea <1.9 #7219

andrewgdunn commented Jun 16, 2019 •

edited

Loading

andrewgdunn commented Jun 16, 2019

bryanpedini commented Jun 16, 2019

andrewgdunn commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 •

edited

Loading

andrewgdunn commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 •

edited

Loading

andrewgdunn commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 •

edited

Loading

andrewgdunn commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 •

edited

Loading

lunny commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 •

edited

Loading

lunny commented Jun 16, 2019

bryanpedini commented Jun 16, 2019

lunny commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 •

edited

Loading

bryanpedini commented Jun 16, 2019 •

edited

Loading

lunny commented Jun 16, 2019

bryanpedini commented Jun 16, 2019

lunny commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 •

edited

Loading

zeripath commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 •

edited

Loading

andrewgdunn commented Jun 16, 2019 •

edited

Loading

bryanpedini commented Jun 16, 2019 •

edited

Loading

andrewgdunn commented Jun 16, 2019

zeripath commented Jun 16, 2019

andrewgdunn commented Jun 16, 2019

zeripath commented Jun 18, 2019

andrewgdunn commented Jun 18, 2019

LFS Inconsitency with Authentication on Gitea <1.9 #7219

LFS Inconsitency with Authentication on Gitea <1.9 #7219

Comments

andrewgdunn commented Jun 16, 2019 • edited Loading

Description

andrewgdunn commented Jun 16, 2019

bryanpedini commented Jun 16, 2019

andrewgdunn commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 • edited Loading

andrewgdunn commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 • edited Loading

andrewgdunn commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 • edited Loading

andrewgdunn commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 • edited Loading

lunny commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 • edited Loading

lunny commented Jun 16, 2019

bryanpedini commented Jun 16, 2019

lunny commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 • edited Loading

bryanpedini commented Jun 16, 2019 • edited Loading

lunny commented Jun 16, 2019

bryanpedini commented Jun 16, 2019

lunny commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 • edited Loading

zeripath commented Jun 16, 2019

bryanpedini commented Jun 16, 2019 • edited Loading

andrewgdunn commented Jun 16, 2019 • edited Loading

bryanpedini commented Jun 16, 2019 • edited Loading

andrewgdunn commented Jun 16, 2019

zeripath commented Jun 16, 2019

andrewgdunn commented Jun 16, 2019

zeripath commented Jun 18, 2019

andrewgdunn commented Jun 18, 2019

andrewgdunn commented Jun 16, 2019 •

edited

Loading

bryanpedini commented Jun 16, 2019 •

edited

Loading

bryanpedini commented Jun 16, 2019 •

edited

Loading

bryanpedini commented Jun 16, 2019 •

edited

Loading

bryanpedini commented Jun 16, 2019 •

edited

Loading

bryanpedini commented Jun 16, 2019 •

edited

Loading

bryanpedini commented Jun 16, 2019 •

edited

Loading

bryanpedini commented Jun 16, 2019 •

edited

Loading

bryanpedini commented Jun 16, 2019 •

edited

Loading

bryanpedini commented Jun 16, 2019 •

edited

Loading

andrewgdunn commented Jun 16, 2019 •

edited

Loading

bryanpedini commented Jun 16, 2019 •

edited

Loading