git-lfs apiurl parameter

git-lfs: Added an optional apiurl parameter.

This needs version 1.2.5 of the haskell git-lfs library to be used.
stack.yaml updated to use that.

Note that git-annex enableremote can be used to add apiurl= to an existing
git-lfs special remote. To allow unsetting the apiurl and instead use
the probed url, support enableremote with apiurl set to an empty string.

Sponsored-by: Luke T. Shumaker
This commit is contained in:
Joey Hess 2025-02-18 14:11:11 -04:00
parent dcf2f71696
commit d394f0b020
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
6 changed files with 95 additions and 29 deletions

View file

@ -66,3 +66,5 @@ Nil
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Love git-annex. Long time supporter.
> [[fixed|done]] --[[Joey]]

View file

@ -0,0 +1,35 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2025-02-18T16:23:23Z"
content="""
LFS uses http basic auth, so using it over http probably allows
any man in the middle to take over your storage.
With that rationalle, <https://hackage.haskell.org/package/git-lfs>
hardcodes a https url at LFS server discovery time. And I don't think it
would be secure for it to do anything else by default; people do clone
git over http and it would be a security hole if LFS then exposed their
password.
In your case, you're using a nonstandard http port, and it's continuing
to use that same port for https. That seems unlikely to work in almost any
situation. Perhaps a http url should only be upgraded to https when
it's using a standard port. Or perhaps the nonstandard port should be
replaced with the standard https port. I felt that the latter was less
likely to result in security issues, and was more consistent, so I've gone
with that approach. That change is in version 1.2.4 of
<https://hackage.haskell.org/package/git-lfs>.
git-lfs has git configs `lfs.url` and `remote.<name>.lfsurl`
that allow the user to specify the API endpoint to use. The special
remote's url= parameter is the git repository url, not the API endpoint.
So I think that to handle your use case, it makes sense to add an optional
apiurl= parameter to the special remote, which corresponds to those git
configs.
Unfortunately, adding apiurl= needed a new version 1.2.5 of
<https://hackage.haskell.org/package/git-lfs>, so it will only
be available in builds of git-annex that use that version of the library.
Which will take a while to reach all builds.
"""]]

View file

@ -9,7 +9,7 @@ These parameters can be passed to `git annex initremote` to configure
the git-lfs special remote:
* `url` - Required. The url to the git-lfs repository to use.
Can be either a ssh url (scp-style is also accepted) or a http url.
Can be either a ssh url (scp-style is also accepted) or a https url.
* `encryption` - One of "none", "hybrid", "shared", or "pubkey".
Required. See [[encryption]]. Also see the encryption notes below.
@ -18,6 +18,10 @@ the git-lfs special remote:
git-annex stores in the repository, as well as to encrypt the git
repository itself when using gcrypt.
* `apiurl` - Optional. The url to the LFS API endpoint. This can be a https
or a http url. When this is not specified, or is not set to an url,
the API endpoint url is guessed based on the url parameter.
## efficiency note
Since git-lfs uses SHA256 checksums, git-annex needs to keep track of the