Does Git LFS use different authentication logic to Git client?

user_197229 0
Viewed 740

We use on-premise Azure DevOps and are just starting to trial Git LFS. I've installed the latest client (3.0.2) alongside my git (2.31.1.windows.1 installed by Visual Studio IIRC) and everything initially looked good when cloning a Git repo from DevOps that has LFS files.

However my local repo only has references to the LFS files and when trying to run commands like git lfs pull (or fetch, or pushing a new LFS tracked file) I get authentication errors relating to http://<server>:8080/tfs/<collection>/<project>/_git/<repo>.git/info/lfs - i.e. a subpath of our git repo URL.

Googling has shown other people with similar problems but not clear answer what is happening, or why, or how to fix it. I don't understand if it's a DevOps implementation issue, or a local client issue on my side.

I did come across discussion about Git LFS not using the same credentials or authentication types as Git, or maybe looking in a different place for them - note we are on-premises using HTTP not HTTPS, maybe this is a factor?

git-lfs azure-devops git
1 Answers

Git LFS uses a different HTTP and TLS library than the one in Git. Git uses libcurl, and Git LFS uses the Go HTTP library. As a result, the supported authentication logic is different, although both programs will use the Git credential helpers and other credential lookup logic.

Since you mention Azure DevOps, my guess is that you're using NTLM. In 3.0, Git LFS removed NTLM because it had known bugs and nobody was interested in fixing them, and because it uses cryptography known to be insecure since 1995. Azure DevOps is the only major site known to use NTLM, and the Git LFS maintainers asked if they'd like to be involved in helping maintain it, and they declined.

NTLM can be handled in one of two ways: via the NTLM authentication scheme or the Negotiate scheme. The latter is also used by Kerberos, which both Git and Git LFS do support, and which is secure. Currently, if you have NTLM set up to use Negotiate, Git LFS simply won't work, since it prioritizes Negotiate over Basic. In the upcoming 3.1, expected out this month or next, Git LFS will fall back to Basic if Negotiate fails, so you'll be able to work even if you have NTLM enabled on your instance.

I strongly encourage everyone to get rid of NTLM because it's so insecure. There's really no defensible reason to use it anymore: even Microsoft tells you to turn it off. If you turn off NTLM on your instance, or switch to Kerberos, things should just work. Otherwise, you'll need to wait for Git LFS 3.1 or explicitly set the authentication method to basic in the configuration.

user_87054320
Related