Restrictive version ranges for 3rd party components

[ptziegler]

I'm currently in the process of updating MINA SSHD in our application due to CVE-2026-48827, but struggling with our dependency to JGit, which requires this artifact exactly in version 2.17.1.

I noticed that the nightly build already updated to 2.19.0. But we can't integrate the new version until the official release in September. Is there a specific reason why those version ranges are so restrictive? Because if I understand 60880a2 and 986dd12 correctly, JGit 7.7.0 should work fine with MINA SSHD 2.19.0 if it weren't for the manifest.

This effectively means that we can't update any dependency (which is also required by JGit) without also updating JGit. So in the worst case, we have to carry a vulnerable dependency with us for up to three months.

[iloveeclipse]

Just matter of resources I guess.
Typically EGit development is closely coupled with JGit and simply inherits most of its dependencies and I believe we don't have tests which would validate wheter any arbitrary EGit build is compatible with some JGit build or its changed dependencies tree or vice versa.

[ptziegler]

Can you explain what you mean by EGit? We're using both JGit and EGit in version 7.7.0 in our product and I don't plan on mixing different versions. So I don't see how this would cause problems.

The problem is that we can't fully update to MINA SSHD 2.19.0, because JGit requires exactly the version 2.17.1 (even though newer versions should also be compatible). The only way around this if we were to integrate the current nightly build directly. But I don't see that as an ideal solution, either. Because until the official release, our product builds would no longer be reproducible.

[iloveeclipse]

Arrgh, sorry, I misread your question, for some reason I've assumed you want have dfferent version restrictions between j & egit.

The strict range is what is tested & verified to work. I believe in the past we had troubles with version updates in this area, where workarounds or fixed were needed.

[msohn]

CVE-2026-48827 is reported for org.apache.sshd:sshd-git which JGit doesn't depend on. I guess you want to avoid updating this bundle to a newer version than the other sshd bundles also used by JGit.

I can tag a 7.7.1 to fix this.

I don't remember why we have the upper version constraint on the next minor version (2.17.1,2.18.0] instead of on all newer minor versions up to the next major version excluding (2.17.1,3.0.0].

[ptziegler]

CVE-2026-48827 is reported for org.apache.sshd:sshd-git which JGit doesn't depend on. I guess you want to avoid updating this bundle to a newer version than the other sshd bundles also used by JGit.

That is true. But even then I'd still end up mixing a 2.19.0 SSHD Git plugin with a 2.17.1 SSHD Core plugin, which is just asking for problems. Apologies for not being clear enough.

I can tag a 7.7.1 to fix this.

If it isn't too much work, this would be very much appreciated. Otherwise I'll just wait for the next release.

I don't remember why we have the upper version constraint on the next minor version (2.17.1,2.18.0] instead of on all newer minor versions up to the next major version excluding (2.17.1,3.0.0].

If this could somehow be adapted to the next major version, it'd save me a lot of future headache. I think a similar problem also appeared in #277?