You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello! 馃憢 When the client and server determine capabilities, is the client version passed through to the server? I've looked through the code and I don't believe it is. If this is the case, could it be added ?
git-lfs versions prior to the proposed 3.5.x don't include two critical fixes that cause pure-SSH based protocol support to fail. I was hoping to inspect the client version and inform the user if they weren't running the proposed 3.5.x version or later, instead of an error.
Another use case for providing client version would be to reject versions that may have security issues where we can inform users to look to upgrade.
The text was updated successfully, but these errors were encountered:
I don't think this is something we send, and it's not part of the protocol, so it would require a v2. It's possible we could stuff it in as an extra capability in v1, though.
Part of my concern in adding it is exactly what you describe: that you'd block older versions for security reasons, when typically most distros backport patches and thus the version number doesn't change. This is definitely true for Git versions; most people not on Windows using old versions of Git are using a distro version that's patched by their distro. For Git LFS, some security bugs have only affected Windows, and thus blocking older versions would primarily negatively affect Unix users.
We'd need to discuss it as part of @git-lfs/core and see where we stand. Given your stated intention to support blocking on it, I'm negative on the idea. However, if the rest of the core team thinks it's helpful, we could choose to accept a patch to that effect. In any event, it won't make it into 3.5, which is scheduled for Wednesday.
Hello! 馃憢 When the client and server determine capabilities, is the client version passed through to the server? I've looked through the code and I don't believe it is. If this is the case, could it be added ?
git-lfs
versions prior to the proposed 3.5.x don't include two critical fixes that cause pure-SSH based protocol support to fail. I was hoping to inspect the client version and inform the user if they weren't running the proposed 3.5.x version or later, instead of an error.Another use case for providing client version would be to reject versions that may have security issues where we can inform users to look to upgrade.
The text was updated successfully, but these errors were encountered: