Because this code doesn't validate whether the filesystem is case
sensitive, a malicious repository can cause unintended write to the
symbolic link using conflicted filenames.
For example, assuming the following two files are included in the
repository, hacked will be written to the .git directory instead of
the dir1 directory on the case-insensitive filesystem.
Dir1 (symbolic link to .git directory)dir1/hacked
Steps to reproduce:
Since I read that the Eclipse security team can't download
attachments, I'm embedding all codes into this email.
@msohn, please log in to GitLab before accessing this issue; otherwise, you will get a 404.
Also, note that it is a confidential issue; only JGit people who are directly added can access it. If you need any other project members to be added, please let us know.
Hi RyotaK, thanks for your report.
I could reproduce what you described and will look into fixing that.
Could you explain what's done in that docker container ?
Why should I compile git in order to prepare this test ?
It's about a jgit vulnerability right ? I guess you could instead install the latest git release.
What's the purpose of running node in that container ?
Hello @msohn, Thank you for validating the report!
Could you explain what's done in that docker container ? Why should I compile git in order to prepare this test ? It's about a jgit vulnerability right ? I guess you could instead install the latest git release. What's the purpose of running node in that container ?
Because I was originally trying to find a vulnerability that is exploitable on Linux, I had to modify Git itself and host a malicious tree object with / in the name. (This is not possible with JGit.)
While doing so, I built a Docker image that compiles the Git and runs an http-git-backend with Node.js. It currently doesn't do anything against Git itself, but rather setups a malicious repository.
However, since I thought that end-to-end PoC is easier to reproduce, I kept it as-is and sent you Dockerfile. (But as you mentioned, compiling Git wasn't necessary. You can install it via apt and adjust the path to git-http-backend in index.js)
I'd like to see a write up of the actual impact and threat model. Right now I don't see this classifying as a "security" issue but rather a regular bug.
If you imagine the link going to .git/hooks, it seems that this gives a server a way to install an arbitrary hook file (for instance, a pre-commit hook), which git then may blindly execute.
The attack scenario I envision is that a service uses JGit to clone a user-specified repository, and when that service clones a specially crafted repository, arbitrary files are overwritten, resulting in remote code execution. (Before finding this vulnerability, I found one service that uses JGit to clone repositories on the server side, so I'd say this is a realistic scenario.)
However, this may not be a security issue if JGit's security model does not support cloning untrusted repositories. (In that case, it would be better to state the security model in the documentation.)
@twolf I theory the scenario is possible but is it plausible? It seems easier to trick users into pasting curl .. | bash commands into their shells (which they do all the time unquestioned to install some fancy Terminal helpers). Hence my ask for a realistic threat model write up.
@ryotak Thanks for the link. That's a good example and hence my ask for the threat model write up. It seems indeed important to share this information with service owners implementing cloning from untrusted repositories.
@gunnar Does the security model of JGit support the cloning of untrusted repositories? If it does, this issue is a security bug since there are many use cases that clones untrusted repositories without explicit warnings (such as cloning user-specified repositories on the server side or cloning the repository that is specified in the custom URI passed from the browser)
And if it doesn't, this is something that should be explicitly stated in the documentation, and might be better to make an announcement since JGit is already used in many products that is potentially cloning the untrusted repository.
@ryotak JGit itself does not implement cloning controls its only a library. It depends on the application its embedded in.
For example, I would classify Eclipse EGit use of JGit as not vulnerable because the user has to paste (or manually enter) the URL (from any source) into Eclipse, at which point it cannot be considered untrusted (user intention).
However, if there is a service allowing such blind clones by some form of browser redirects it may be at risk. Hence I think there is value in publishing this.
JGit itself does not implement cloning controls its only a library. It depends on the application its embedded in.
Yes, I know JGit is only a library. However, as Git itself actively prevents this kind of arbitrary file overwrite on the machine vulnerability while cloning the repository, users/developers expect cloning the repository wouldn't overwrite arbitrary files on the device (or execute arbitrary commands).
Does JGit's security model allow this kind of behavior?
For example, I would classify Eclipse EGit use of JGit as not vulnerable because the user has to paste (or manually enter) the URL (from any source) into Eclipse, at which point it cannot be considered untrusted (user intention).
I don't know much about EGit, but if the user just wants to clone the random repository instead of executing codes from the random repository, this behavior easily breaks the security boundary assumed by the user.
However, if there is a service allowing such blind clones by some form of browser redirects it may be at risk. Hence I think there is value in publishing this.
Does the JGit team consider this a bug instead of a vulnerability? If so, I agree that this issue can be published (although I don't recommend it since this behavior easily results in the vulnerability in products using JGit.)
I recommend fixing this privately and publish the advisory later. However, I follow what the maintainer decides, so if the JGit team considers this a normal bug, I respect that decision.
However, as Git itself actively prevents this kind of arbitrary file overwrite on the machine vulnerability while cloning the repository
I don't think this is entirely correct. I am working in a very large Git repository and there is constant support needed because developers creating camelCase.java files on one file system and later renaming because it should be CamelCase.java. This causes issues for folks on non case sensitive file systems, which require manual work to address those.
if the user just wants to clone the random repository instead of executing codes from the random repository
On a side note, with security items I've learned that it is essential to be very precise. The description of the issue is talking about overriding of files on the file system. Has a remote execution been successfully tested, i.e. is there confirmation that the attack as given does execute remote remote random code? Looking through the JGit code I see only few hooks support, which seems to indicate that the user must at least attempt to commit to the repository. I doesn't look like there is proper hook support on the server side.
I recommend fixing this privately and publish the advisory later.
There is a different thing to consider. JGit is OSS and not backed by a vendor. Without this being public there won't be enough attention. This has been open for more than a month now without a PR.
I don't think this is entirely correct. I am working in a very large Git repository and there is constant support needed because developers creating camelCase.java files on one file system and later renaming because it should be CamelCase.java. This causes issues for folks on non case sensitive file systems, which require manual work to address those.
I assume that happens because Git considers both camelCase.java and CamelCase.java as the same file while checking out on the case-insensitive filesystem and shows an error for filename conflicts instead of continuing the checkout. It prevents this kind of vulnerability from being exploited.
The problem I reported is that cloning a malicious repository on a case-insensitive filesystem allows files outside of the repository to be overwritten, which isn't possible with Git.
(If you know a way to overwrite arbitrary files while cloning with Git, please refer to https://github.com/git/git/security for how to report a vulnerability. That behavior is considered a vulnerability in Git, so you should report it.)
On a side note, with security items I've learned that it is essential to be very precise. The description of the issue is talking about overriding of files on the file system. Has a remote execution been successfully tested, i.e. is there confirmation that the attack as given does execute remote remote random code? Looking through the JGit code I see only few hooks support, which seems to indicate that the user must at least attempt to commit to the repository. I doesn't look like there is proper hook support on the server side.
The hook support isn't necessary to exploit this vulnerability. Since there are many files that can be used to execute code/commands (.bashrc gets executed when bash is launched, /var/spool/cron/* is executed by the cron, or Windows execute any programs under %AppData%\Microsoft\Windows\Start Menu\Programs\Startup upon startup etc), arbitrary file overwrite is usually allowing the code execution.
As this vulnerability affects case-insensitive filesystems only, I think you might want to try the %AppData%\Microsoft\Windows\Start Menu\Programs\Startup one and see if it works. (If you have macOS, you can also use the .bashrc / .zshrc approach or cron approach)
Also, overwriting arbitrary files on the system itself has a security impact as it affects the integrity of files.
There is a different thing to consider. JGit is OSS and not backed by a vendor. Without this being public there won't be enough attention. This has been open for more than a month now without a PR.
As there is a known vulnerabilities page for Eclipse Foundation projects, publishing the advisory here should get enough attention: https://www.eclipse.org/security/known/
If you think we need much larger attention, I can contact my local CERT/CC to publish the advisory, so please let me know.
But again, publishing about the vulnerability without the patch makes it hard for developers using the product to apply patches, so I wouldn't recommend it.
(As a side note, the latest vulnerability on the known vulnerabilities page took about 8 months to fix, so I assume we don't need to rush much unless Eclipse Foundation has new policies for handling vulnerabilities. At this point, I'm not planning to disclose this vulnerability before the fix.)
The hook support isn't necessary to exploit this vulnerability. Since there are many files that can be used to execute code/commands (.bashrc gets executed when bash is launched, /var/spool/cron/* is executed by the cron, or Windows execute any programs under %AppData%\Microsoft\Windows\Start Menu\Programs\Startup upon startup etc), arbitrary file overwrite is usually allowing the code execution.
As this vulnerability affects case-insensitive filesystems only, I think you might want to try the %AppData%\Microsoft\Windows\Start Menu\Programs\Startup one and see if it works. (If you have macOS, you can also use the .bashrc / .zshrc approach or cron approach)
I don't follow. How is overriding a file within a Git repository .git folder related to .bashrc or %AppData%?
@gunnar
Basically, symbolic links are a way to link a file or directory to another file or directory.
For example, if we create a symbolic link called /home/user/test1 that points to /tmp/test2, writing contents into /home/user/test1 modifies the /tmp/test2 instead.
So, by creating a symbolic link that points outside of the repository, it's possible to write arbitrary contents into arbitrary location on the system.
(Please refer to the man page for the details about how symbolic links work: https://man7.org/linux/man-pages/man2/symlink.2.html#top_of_page)
So, by creating a symbolic link that points outside of the repository, it's possible to write arbitrary contents into arbitrary location on the system.
Again, this is very theoretical. I don't see any proof that this is actually possible with JGit given the sparse information in the description. It only talks about a file .git/hacked.
For example, does JGit even support %AppData% of ~ resolution for the theoretical case to become true?
@gunnar
It's not theoretical since it's already demonstrating that JGit follows symbolic links.
If you want to change where the symbolic link points, you can edit the argument for the ln command of the Dockerfile included in the PoC.
(ln command is used to create symbolic links. Please see https://man7.org/linux/man-pages/man1/ln.1.html for more details about the ln command.)
For example, does JGit even support %AppData% of ~ resolution for the theoretical case to become true?
I believe the resolution doesn't occur since JGit doesn't perform expansion of the environment variable or ~.
However, as symbolic links support relative paths (e.g., ../../../../tmp/test1), you don't need to guess the username if the user decides to clone the repository into any directories under the user's home directory.
Ok, so now we are talking about tricking a user to clone a prepared repository plus cloning it not into his/her favorite working directory but into a very specific location.
This brings me back to my earlier question: why not simply asking them to execute curl ... | bash? That seems easier than the effort required with this kind of attack.
Again, I do agree it's a problem that should be fixed. However, I am very sensitive to over-defining the severity of such security issues. I got the impression that's the case here. Maybe I am wrong.
cloning it not into his/her favorite working directory but into a very specific location.
This is not correct. As mentioned above, symbolic links can point to arbitrary paths on the filesystem, so repositories cloned into any directory can write arbitrary contents into arbitrary paths.
For example, repositories cloned under /home/user/repositories/malicious-repo using JGit can write a file with arbitrary contents into /tmp/malicious-file.
You can confirm it by modifying the ln command of the Dockerfile included in the PoC.
This brings me back to my earlier question: why not simply asking them to execute curl ... | bash? That seems easier than the effort required with this kind of attack.
Executing a malicious bash script is something that users should avoid since it essentially results in the compromise of the system, but cloning the repository shouldn't result in the compromise of the system.
This is what you should consider when thinking about the security boundary.
Again, I do agree it's a problem that should be fixed. However, I am very sensitive to over-defining the severity of such security issues. I got the impression that's the case here. Maybe I am wrong.
I think we are misunderstanding something. Do you agree that we can write arbitrary contents into arbitrary locations on the system, which might be unrelated to the repository?
(Also, do we want to use CVSS here? I don't know how projects of Eclipse Foundation calculates the severity of security issues.)
For example, repositories cloned under /home/user/repositories/malicious-repo using JGit can write a file with arbitrary contents into /tmp/malicious-file.
And how does this ties back into remote execution and .bashrc? I don't have my .bashrc configured to execute stuff in /tmp/....
@gunnar
This should prove we can write arbitrary files into arbitrary locations. Symbolic links can point to arbitrary paths, so by creating a symbolic link that points /home/user or ../../ in the /home/user/repositories/malicious-repo, we can write .bashrc to the home directory.
Also, the .bashrc case is just an example, and there are many ways to achieve code execution via arbitrary file write. (When calculating the severity for security issues in the library, we usually assume the worst case implementation scenario. But if Eclipse Foundation has original scoring rule, I'd like to check them and see if what severity we should use here.)
Writing to locations outside the git working tree of the repository being cloned: this is evidently possible.
Using (1) to target specific files is hard and in practice will not work in many cases:
Targeting the user's home directory via ~ or $HOME is not possible since links don't resolve those.
To try to overwrite for instance a user's .bashrc one would be reduced to guess the user's home directory location. A link to /home/user for instance wouldn't work if I clone that repo on OS X :-) You could guess where my home directory might be on a typical OS X installation, and prepare links to likely locations in the git repo, and then I might be vulnerable to this (if I haven't configured my file system to be case-sensitive, which is possible on OS X) and have a bad surprise the next time my .bashrc is executed. Using relative navigation via .. to target specific files can only work if the repository is cloned to a specific location.
Trying to overwrite critical stuff in /usr, /etc or other such system directories most likely won't work unless the process executing JGit runs as root -- which unfortunately is not so uncommon in docker containers. (But still poor practice.)
Using (1) to set up a git repo such that the clone is automatically configured to execute either a hook or a filter that is also provided by the git repo is possible. (Yes, I've done this locally; and it's possible without any assumptions about the clone location or ~ or anything.) The hook or filter is not executed during the clone, but will run when the next commit (if a pre-commit hook is used for the attack), or the next check-out (smudge filter), or the next git add (clean filter) is performed in the git repo. The filter or hook script evidently has access to anything the running process has access to, and can use ~ substitutions and environment variable replacements, and can do just about anything.
The user has to perform some explicit action (commit, check-out, stage a file) to trigger the execution of this clandestinely installed hook or filter.
But the user might not be aware that such hooks or filters have been created by the cloning. The working tree is not clean after the clone, and git status (or the EGit staging view) will report strange deleted files, but that's easy to miss.
The big difference I see to curl ... | bash is that with this command, the user is aware that he or she is executing essentially arbitrary code, and has agreed to do so. With cloning a git repository, the user has not agreed to get files outside the working tree overwritten, and has not agreed to getting hooks or filter scripts injected.
Using EGit and cloning a repo where (1) has been used to inject a clean filter, cloning the repo will automatically run the injected script. Without any further user interaction. EGit basically runs a git status when a new repo appears in the workbench, and that triggers the clean filter in FileTreeIterator.contentCheck() called via FileTreeIterator.isModified().
:-(
I hadn't noticed that so far because my proof-of-concept had used only a smudge filter.
So with EGit, we have a clear RCE (Remote Code Execution); not just an arbitrary file overwrite.
With JGit, that shouldn't happen automatically, but if the user runs a StatusCommand after the clone, I would expect this to happen, too.
Cloning the repo with JGit and then running git status on the command-line (using the normal C git) also executes the injected script.
Note that the attack link and directory don't have to be at the working tree root; they can be hidden away in some nested directory at an arbitrary depth.
Attached is a demo2.bundle git bundle of a small proof-of-concept git repo that exhibits this behavior.
The git repo is set up to inject a smudge and clean filter into the cloned repo; the filter script writes a file ~/gitCloneDemo. Filter setup and the filter script are hidden away inside the .git directory of the clone.
If you download that bundle file and clone it with EGit in Eclipse, you should see the RCE (i.e., the file ~/gitCloneDemo having been created).
@twolf Thank you so much for the detailed investigation! That reminds me about the core.fsmonitor configuration, which also allows command execution while running git status.
There might be a few other attack vectors that I didn't realize, so I'll investigate it once I got time to set up the dev environment (Hopefully this weekend)
@gunnar
Do you think this is enough severity to keep this issue confidential?
@ryotak@gunnar As a reminder of Foundation policies, we recommend to keep the issue confidential until a resolution is found and a release with the fix done. If possible within 90 days.
This said, with my security researcher hat on, this looks quite serious and exploitable.
A bit of a reality check: the corresponding vulnerability was reported and fixed in Git some time ago, so I wouldn't expect that attackers and security researchers don't already know about the issue.
If we want to handle it confidentially to help with maintaining the habit, I don't mind, but I don't think an embargo meaningfully improves security in this example.
The basic gist is: request a CVE number, develop patches in private, commit with innocuous commit messages, publish patch releases including the fix. Only then go public with the CVE and advisory. (If we had a non-public repo, we could develop patches there and publish patched releases from there, and merge to the public repo only after the CVE is published. But I don't think we have such a non-public repo where all committers could collaborate.)
From code inspection I see more possibilities to exploit this:
Checkout is the case exploited by the proof of concept. This affects primarily DirCacheCheckout and CheckoutCommand. StashApplyCommand has the same problem, but is less critical since stashes are never downloaded but always created locally in the clone.
Note that it's not cloning a repo that causes the problem. Cloning is a multi-step process: it first creates an empty local git repo, sets up an upstream reference, fetches from upstream, and finally checks out HEAD into the working tree. The problem occurs in this last step.
Other checkouts are also affected. See the steps below given for merging: instead of merging, checking out the fetched "side" branch would also run into this problem.
Merging could be affected. (Not verified yet, just from code inspection.) The fix would have to be in ResolveMerger (or rather, its WorkingTreeUpdater). Proof-of-concept would be something like
Create an upstream repo containing a file "xyz" (single commit on "main").
Clone that repository. Nothing bad happens.
In the upstream repo, add on another branch "side" a commit that uses this exploit to write outside the working tree.
Fetch from upstream. Nothing bad happens yet.
Merge "side" into "main". No conflict, but I'd expect an out-of-workingtree file to be created.
Pulling: (2) implies that PullCommand is affected, too. (A pull is a fetch followed by a merge/rebase).
Applying a patch might be affected. Same idea as with merging: have a patch that contains such a symlink, plus a file at a directory with the same name on a case-insensitive file system. However, it's not entirely clear to me what our PatchApplier does with symlinks anyway. fileExists(), for instance, is completely oblivious to symlinks.
I can't test on Windows, but I suspect that the attack would not work there since symlinks are not supported, and moreover JGit AFAIK can't run hooks. It might work on Cygwin, but I don't know whether it would have a case-insensitive file system.
The attack works only if the file system is case-insensitive. Which basically leaves only OS X as a realistic target, plus maybe Cygwin.
Where the attack works, any process using JGit to perform any of the operations mentioned (checkout, merge, apply patch) is vulnerable. Like Eclipse using EGit, but also others, e.g., a Jenkins (agent) running on OS X and using JGit for git operations.
Setting core.symlinks = false before checking out should avoid the problem. (With that setting, JGit, like C git, does not create symlinks but writes them as ordinary files.)
I have a preliminary fix for JGit master (except for PatchApplier, haven't looked at that yet in detail). Will take a while to verify and write tests.
How do we want to organize the code review to keep it private?
Which branches should be fixed? Are we going back all the way to 6.0? That might be significant work; current master has seen many changes in the areas to be fixed since 6.0 or 5.13.x.
We should probably also do a patch for the stable-5.x branch. Who's still using JGit 5.13.x?
Which branches should be fixed? Are we going back all the way to 6.0?
I'd recommend preparing the fix for master and then we can look into how much work it is to backport. I do think we'll want to backport, but I don't know how far (I'd base it on what best supports EGit, since that's the main user of this code).
Great. I even have access to that repo. Except that my user at that Gerrit (user ID 1149436) doesn't seem to have a user name, so I don't quite see how I could push. (I need a user name to go with the HTTP password, don't I?) (Solved, see below.)
I'd base it on what best supports EGit, since that's the main user of this code
For EGit, a backport to 6.6 is sufficient. We've always only promised to maintain one release back.
Another major user of JGit and using it to do check-outs is Jenkins. git-client 4.4.0 uses JGit 6.6.0.202305301015-r.
For whom are we maintaining the 5.13 branch? Who still does not want to or cannot switch to Java 11? (Apache MINA sshd is one candidate, but I don't know who uses its sshd-git bundle. For client-side usage it's superseded by our own org.eclipse.jgit.ssh.apache, and I definitely wouldn't use it to implement a git server.)
Luca still has some Gerrit customers using old Gerrit versions on Java 8, I think Gerrit is not affected since it doesn't use repositories with a working tree but only bare repositories
@twolf can the fix be released for 5.13.x branch? We are still using java 8 and for us it's a huge effort to move to java 11. We have planned. We consume jgit directly.
While Windows supports symbolic links, it requires a specific privilege (SeCreateSymbolicLinkPrivilege) to create, which only administrators have by default. However, it's possible to add this privilege to non-administrator users.
This limits who can be targeted but doesn't limit who can initiate the attack.
I've tested it on the just installed Windows 10 using the user with SeCreateSymbolicLinkPrivilege and confirmed that the following bundle file executes notepad.exe when cloned with EGit: windows.bundle
Anyone can initiate this attack; constructing a repo containing such a link/directory alias is not limited to particular systems. A Linux user can easily prepare such a repo that would cause the attack to work on OS X or Windows. Or using JGit, it is super-trivial to construct such repos even on OS X or on Windows. (Just did so for the unit tests for my fix proposal in work.)
Meanwhile confirmed:
Merging exhibits the same problem.
PatchApplier doesn't create symlinks (seems to be a missing feature?), but if a symlink exists already, it also has the same problem.
@twolf if you need any help with CI (like spanning a private one for your test), let me know, we can ask releng to create what's needed
I also confirm that the typical approach is to develop fixes in private, share in a private fork if need multiple eyes to have a look. Then submit as a regular pull request without referencing to a bug (in your case something like "fixing checkouts/merges with symlinks". This step isn't a big protection, however. When you have merged the fix, you spawn the release and when it is done we publish the CVE record.
@jnieder I absolutely agree that if someone has been following git development and had a look in JGit for the same issue, might have already found it. There are other people scanning CVEs to get vulnerabilities. Keeping the issue silent until the fix brings less risk to JGit users.
@mrybczyn : thanks for the offer, but I don't think Eclipse releng needs to do anything. The Gerrit Jonathan linked to will be perfectly fine. It's the Gerrit instance of Gerrit itself; there is a private up-to-date clone of JGit there already. Many JGit committers including Matthias are active there, too, and do have access. We'll just have to sort out my having push access there. Solved, see below.
Basically it replaces the static operation DirCacheCheckout.checkoutEntry(...) by Checkout.checkout(). The advantage of this new Checkout object is that it can keep state over checking out multiple entries, which gives the place to hook a FileModeCache into the process. The FileModeCache caches information about non-leaf path items, and has an operation to check all path elements for being a symlink. If it finds a symlink, it removes it before creating the directories. A cache is used because this might otherwise be rather inefficient.
PatchApplier uses the FileModeCache directly.
Also included are tests for trying to write directly to a file at ".git/b". As expected, that doesn't work (already before this patch). Only PatchApplier needed additional path validation to guard against
this.
@mrybczyn: can you provide a CVE for announcing the fixed vulnerability in the release notes ?
For now I only added a generic description for the fix to the release notes.
@msohn Thank you! Could you please now also create a new EGit 6.6.1 release? That should update the updates-6.6 p2 repo, including these JGit 6.6.1 bundles, and that in turn should clear the path for people updating their Eclipses (or even getting them updated automatically) if they're currently using 6.6.
For publishing the CVE we need a description of the vulnerability.
The process is described here.
@twolf: as the one who fixed it, could you provide that description ?
I tried applying the patch to older stable branches but the patch doesn't apply cleanly.
I propose to not patch older 6.x branches, we don't have the capacity to maintain more than the last release.
Should we backport it to stable-5.13 which is the last version supporting Java 8 ? WDYT ?
If you want I can post a CVE description and announcement texts here. Or someone gives me access to wherever such a description should properly go.
BTW, the ASF has a nice online tool accessible to Apache PMC members of Apache projects that guides one through the process of creating a proper CVE (affected product, versions, description, mitigations, when fixed, how to get the fix, CVE score, CWEs, credits, ...) and that also automatically generates e-mail texts to be sent to accounce@apache.org, oss-security@lists.openwall.com, and the project mailing list(s), and that also can send these e-mails on a button click.
Does something like that exist in the Eclipse pocket of the universe, too?
the patch doesn't apply cleanly
I know. That's why I said we should decide first where to backport it to. I can backport it to 5.13, but it'd be quite a bit of work, and if you then ever merge 5.13 into the stable-6 branches, you'll get into trouble. So it's either
backport to 5.13 and merge all the way up until 6.7 and master (which basically means adapting the patch for each and every version since this area has seen several changes in the stable-6 stream), or
backport only to 5.13 and treat stable-5 and stable-6 as officially diverged, and never merge up from 5.13 but henceforth cherry-pick individual 5.13 fixes to stable-6.
I don't know if it's worth fixing 5.13. That's why I asked who still used it.
@ryotak : how exactly would you like to be credited in the CVE announcement? (If at all?) Would be a single line under a header "Credits", something like "The JGit maintainers would like to thank <whoever> for finding and reporting this issue." What should "<whoever>" be? Could be your name or also "firstname lastname of companyname". If you prefer not to be credited, just say so; that's perfectly fine, too.
Hi, we still use Java 8 and can not upgrade to JGit 6 with Java 11. I made my attempt to backport the upstream fix to 5.13 branch https://git.eclipse.org/r/c/jgit/jgit/+/204642 The CI is passed. May I ask for a review from the experts? Thanks.
I submitted your backport to stable-5.13 branch and released it with JGit 5.13.3.202401111512-r.
Announcement will be sent as soon as deployment to Maven Central is finished.
Hello @msohn , could you update the CVE record to mark 5.13.3.202401111512-r as a viable option to upgrade. Right now this still shows the CVE-2023-4759 as unresolved. Thank you for taking care of the 5.13 release as this is also required for one of our products which runs on Java 8.
Edit: Sorry, I just saw that you already requested the CVE to be updated here
FYI: the CVE is still shown e.g. on mvnrepository at for 5.13.3.202401111512-r