On 2024-03-24 at 02:24:46, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > ... and because of this difficulty and the fact that NTLM uses cryptography
> > known to be insecure since 1995, there is often little interest in
> > implementing this support outside of libcurl. However, it would be
> > helpful if people who want to use it can still use it.
> 
> This position was a bit surprising to me to come from you, but
> perhaps I am mixing up my recollection of your past work on this
> project with somebody else's?  I somehow expected to hear something
> more like "if a less secure thing is cumbersome to implement, let it
> be, as that is better for the world".  But I am OK to add less secure
> thing as long as it is an opt-in "easy way out".
> 
> Everything else I read in the cover letter made sense to me.  I just
> wanted to say that the above part was a bit surprising.

I do firmly feel that NTLM should go gentle into that good night.

However, we've seen a lot of user questions on Git LFS from users who
want to use NTLM or Digest, which we don't support and probably will not
for security and maintainability reasons, but which their corporate
environment imprudently requires. Thus, my goal is to make it _possible_
for people to implement this, but it to make it their responsibility (or
that of a suitable open source project) to do so instead of asking me to
maintain it.  That, I think, is a fair and equitable tradeoff for this
situation.

Also, right now, Windows users sometimes choose to use the older v2.13.3
version of Git LFS which, due to a Go standard library bug, has an
arbitrary code execution vulnerability, but which did support NTLM.
Thus, it would also be better for security to have people on a suitably
patched version of Git LFS with an external NTLM helper.

This series would also, in an approach that's better for security, allow
people to use better Kerberos mechanisms than what Windows supports
natively, or to use an AWS HMAC-v4-style request signing (using
HMAC-SHA-256) if they want to do so, both of which would be a win for
security.

I could have put all of this into the cover letter, but I felt it was
pretty long and didn't want to sell this as an advantage only for Git
LFS when I think it provides general benefit for Git users.  I know
the policy of the project is not to prioritize any one external
project, and I try to be sensitive to that here.

I don't think this constitutes a marked change in my historical
"let's-remove-all-the-obsolete-cryptography-and-obsolete-operating-systems"
approach, but I see how it might look that way at first glance.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA