Please describe the problem.
Trying to copy annexed files to an lfs server via the configured http schemed url results in an error of this form:
$ git-annex copy -t lfsonly
copy mod_access_compat.so (HttpExceptionRequest Request {
host = "computer-ubul.local"
port = 5965
secure = True
requestHeaders = [("Accept","application/vnd.git-lfs+json"),("Content-Type","application/vnd.git-lfs+json"),("User-Agent","git-annex/10.20241031-1~ndall+1")]
path = ".git/info/lfs/objects/batch"
queryString = ""
method = "POST"
proxy = Nothing
rawBody = False
redirectCount = 10
responseTimeout = ResponseTimeoutDefault
requestVersion = HTTP/1.1
proxySecureMode = ProxySecureWithConnect
}
(InternalException (HandshakeFailed (Error_Packet_Parsing "Failed reading: invalid header type: 72\nFrom:\theader\n\n")))) failed
copy mod_autoindex.so (HttpExceptionRequest Request {
host = "computer-ubul.local"
port = 5965
secure = True
requestHeaders = [("Accept","application/vnd.git-lfs+json"),("Content-Type","application/vnd.git-lfs+json"),("User-Agent","git-annex/10.20241031-1~ndall+1")]
path = ".git/info/lfs/objects/batch"
queryString = ""
method = "POST"
proxy = Nothing
rawBody = False
redirectCount = 10
responseTimeout = ResponseTimeoutDefault
requestVersion = HTTP/1.1
proxySecureMode = ProxySecureWithConnect
}
(InternalException (HandshakeFailed (Error_Packet_Parsing "Failed reading: invalid header type: 72\nFrom:\theader\n\n")))) failed
copy: 2 failed
From what I can see, there is no way to work around this. Unlike, for example, the S3 special remotes, initremote doesn't take a protocol=http setting.
What steps will reproduce the problem?
$ git-annex initremote lfsonly type=git-lfs encryption=none url=http://computer-ubul.local:5965/
initremote lfsonly ok
(recording state in git...)
$ git config annex.security.allowed-ip-addresses 172.17.0.1 # required to overcome ConnectionRestricted error
$ git-annex copy -t lfsonly
... eror from above
What version of git-annex are you using? On what operating system?
git-annex/10.20241031-1~ndall+1 on Ubuntu 22.04 LTS:
Linux computer-ubul 6.8.0-40-generic #40~22.04.3-Ubuntu SMP PREEMPT_DYNAMIC Tue Jul 30 17:30:19 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Please provide any additional information below.
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.
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
andremote.<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.