On 2024-03-24 at 02:24:46, Junio C Hamano wrote: > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
