LFS Pure SSH implementation uses ROOT_URL instead of LOCAL_ROOT_URL

[florolf]

Description

When using the LFS Pure SSH protocol, the "download" links in the batch responses are generated using setting.AppURL (aka ROOT_URL). While this makes sense for the classic hybrid transport mode where the LFS client needs to connect to the externally facing API URLs to download objects, in the SSH protocol case, subsequent LFS download requests are being originated from the SSH server node.

This causes a number of problems:

• One major reason to use the SSH protocol in the first place is to avoid having to publicly expose the HTTP LFS endpoints in the first place. However, as implemented, the server side SSH protocol implementation will still try to access the public endpoints (unlike other code which needs to talk to the main Gitea service, which will use LOCAL_ROOT_URL, which can bypass a reverse proxy in front if Gitea.
• ROOT_URL might not be even accessible from the SSH server node, which will cause obscure failures when cloning a repository (LFS: got status 500 when fetching OID)

Gitea Version

1.23.5

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Self-hosted setup running behind a HTTPS reverse proxy and using OpenSSH for SSH. Both SSH, the reverse proxy and Gitea are running on the same machine, but because of some unrelated peculiar network configuration, the external URL (ROOT_URL) is not accessible locally.

Database

SQLite

[wxiaoguang]

I don't know why people insist to play with LOCAL_ROOT_URL .... see this for explanation: #32554 (comment) and #32554 (comment) . The document also says that "you do not need to change the default value" https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini#L128-L136

In short: forget it, it is not for end users.

[wxiaoguang]

but because of some unrelated peculiar network configuration, the external URL (ROOT_URL) is not accessible locally.

TBH, ROOT_URL should always be accessible and be used when you need to access to Gitea.

The "peculiar network configuration" should be fixed or use some workaround to make ROOT_URL work.

[florolf]

I don't know why people insist to play with LOCAL_ROOT_URL

I'm not insisting on playing with it, I'm merely pointing out that there is an inconsistency in how the lfstransfer module handles it. Because of

gitea/modules/lfstransfer/backend/backend.go

Line 45 in 7290bfa

server, err := url.Parse(setting.LocalURL)

it uses LOCAL_ROOT_URL for all the requests where it constructs the request URL itself, but Download (via

gitea/modules/lfstransfer/backend/backend.go

Line 182 in 7290bfa

url := action.Href

) uses whatever the previous batch request has returned, which uses ROOT_URL.

This means that this code will break in any configuration where there is a meaningful distinction between ROOT_URL and LOCAL_ROOT_URL.

The "peculiar network configuration" should be fixed or use some workaround to make ROOT_URL work.

I could work around the network issue but my main motivation for wanting to use the SSH LFS transport is avoiding having to expose the HTTP LFS endpoint publicly in the first place, so this wouldn't help.

[florolf]

The document also says that "you do not need to change the default value" https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini#L128-L136

As a further note: I'm actually not trying to change it from its default value. The default value would be correct but the LFS Download operation is not making use of it, as described above.

[wxiaoguang]

Thank you for the clarification. I see your point, it makes sense.

Let's see how to convert the "public action.Href" to an internal URL ........

[wxiaoguang]

I proposed a PR ( Fix LFS URL #33840 ) and updated the tests. Does it look good to you?

[florolf]

I've rebuilt 1.23.5 with this patch on top and tested it in my setup and can confirm that it works, thanks!

[wxiaoguang]

Thank you very much for the report! The investigation is really helpful.