Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client version passed to the server? #5656

Open
ashmckenzie opened this issue Feb 23, 2024 · 2 comments
Open

Client version passed to the server? #5656

ashmckenzie opened this issue Feb 23, 2024 · 2 comments

Comments

@ashmckenzie
Copy link

ashmckenzie commented Feb 23, 2024

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.

@bk2204
Copy link
Member

bk2204 commented Feb 23, 2024

Hey,

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.

@ashmckenzie
Copy link
Author

Thanks @bk2204 for the quick reply 馃檱

when typically most distros backport patches and thus the version number doesn't change.

Oh, I was not aware the version number wouldn't change, interesting! That does change things considerably.

We'd need to discuss it as part of @git-lfs/core and see where we stand.

Many thanks 馃檱 I'm happy to contribute if the opportunity arises.

3.5, which is scheduled for Wednesday.

That's exciting, thanks for the update! 馃檱

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants