LFS push fails on authenticateToken - opStr string has 2 parts

[kubatyszko]

• Gitea version (or commit ref): master
• Git version: recent - supports LFS
• Operating system: OSX (same issue on Linux)
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • [ X ] SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • [ X ] No
  • Not relevant
• Log gist:

2017/03/16 20:58:15 [D] KUBA token claims ok
2017/03/16 20:58:15 [D] KUBA token requireWrite: %!i(bool=true)
2017/03/16 20:58:15 [D] KUBA token opStr: upload 87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7
2017/03/16 20:58:15 [D] KUBA after token
2017/03/16 20:58:15 [D] LFS request - Method: POST, URL: /kuba/test1.git/info/lfs/objects, Status 401
2017/03/16 20:58:15 [D] LFS request - Method: POST, URL: /kuba/test1.git/info/lfs/objects, Status 202

(it has some additional debugging info I added)

Description

git push with LFS enabled fails with 401 error.

I traced it precisely to this statement:

if requireWrite && opStr != "upload" {
                return false
        }

in modules/lfs/server.go

The opStr being passed does not equal to "upload" but it begins with "upload" - with space and cryptic hex after.

Sample opStr:

upload 87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7

I'm not sure which component generates the hex stuff after upload, if it's LFS client - I might have an older version (that works OK with github LFS and git-lfs-s3 (s3 backed)).

I'm not an expert in Go, but to solve this exact issue, I did the following change:

if requireWrite && strings.Split(opStr," ")[0] != "upload" {
                return false
        }

This ensures that if the opStr happens to have something additional following "upload" - it works without failing.

I'd be happy to submit a pull request if anybody could verify whether this makes any sense.

[fabian-z]

Please provide the full command you are running along with its complete output and the output of git lfs env.

If your failing commands output includes a message like 'Errors logged to /path/to/.git/lfs/objects/logs/*.log', please provide the log file contents as well.

After that, could you please apply the following patch and capture the resulting output of the operation?

[fabian-z]

On a second look at your debugging, it seems like the object hash is passed after the action verb. However, I'd still like to narrow the issue down a bit more before patching it.

[kubatyszko]

$ssh kt@localhost -p2222 git-lfs-authenticate kuba/test.git upload

cmd: 'git-lfs-authenticate kuba/test.git upload' - verb: 'git-lfs-authenticate' - args: 'kuba/test.git upload'

$ssh kt@localhost -p2222 git-lfs-authenticate kuba/test.git upload 123123123123
cmd: 'git-lfs-authenticate kuba/test.git upload 123123123123' - verb: 'git-lfs-authenticate' - args: 'kuba/test.git upload 123123123123'

it just passes back what I supply with the request

Which part controls what's being passed to git-lfs-authenticate?

[kubatyszko]

btw, I'm using:

git lfs env
git-lfs/2.0.1 (GitHub; darwin amd64; go 1.8)
git version 2.9.3

The command I run is simply "git push" after setting up lfs (git lfs install and git lfs trace '*bin')

[fabian-z]

I just retried with the latest version of git-lfs (2.0.1), and I cannot reproduce the issue here.

it just passes back what I supply with the request

That was the original intention. However, i just realized it will be easier to post a debug log here, there should be a line with SSH: Payload: stating the same information.

Which part controls what's being passed to git-lfs-authenticate?

The LFS client itself, and I suspect it should not be generating such commands according to the spec. If we can confirm this, we are going to work around this client bug and file an upstream issue for it.