dependency on cJSON?
- Dominant language
- C
- Stars
- 8.8k
- Forks
- 1.5k
- PR merge metrics
- No merged PRs in 30d
Description
A [recent discussion](https://www.openwall.com/lists/oss-security/2026/07/30/22) on the [Openwall oss-security Mailing List](https://oss-security.openwall.org/wiki/mailing-lists/oss-security) talked about the article ["33 Vulnerabilities in cJSON"](https://joshua.hu/cjson-json-parser-cve-vulnerabilities) that got me searching where in my systems is it used... it turned out, for me, only `iperf` currently seems to need it :-/ ... or at least so I thought.
Given the (claimed) non-maintenance mode of https://github.com/DaveGamble/cJSON I was wondering how deeply dependent is iperf on cjson ...
Digging deeper it is getting weird... I see that there is a local copy of it inside iperf: https://github.com/esnet/iperf/blob/master/src/cjson.c then on my Gentoo systems it is linked to system-wide cjson...
On Gentoo linux, it looks like iperf is coded to require system-wide cjson via a patch:
* the [iperf-3.21.ebuild](https://github.com/gentoo/gentoo/blob/master/net-misc/iperf/iperf-3.21.ebuild) requires the patch
* the [iperf-3.18-unbundle-cJSON.patch](https://github.com/gentoo/gentoo/blob/master/net-misc/iperf/files/iperf-3.18-unbundle-cJSON.patch) itself
In the current situation (until cJSON is fixed upstream) this brings nothing, but at least it shows that the external lib is not that hard to use...
That raises some questions:
* Can iperf be compiled without JSON output (couldn't find any obvious way) ?
* Why was cJSON brought in-tree and what version is it?
* Will it be easy/wise to use out-of-tree (installed in the OS) library?
* Does `iperf` team need to triage (at least) those 33 vulnerabilities, since I assume they are contained in the distributed cjson, and patch what is needed?
Contributor guide
Research direction
Start with the in-tree src/cjson.c and the build configuration to determine how cJSON is included and whether JSON output can be disabled. Compare this with the Gentoo unbundling patch and identify the bundled cJSON version and affected usage. Done means documenting the dependency, build options, and any required vulnerability triage or fixes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- networking, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 45/100