Drop YAJL dependency

[mikelolasagasti]

yajl library has been unmaintained upstream[1] since 2015. Last published release contians multiple CVEs (CVE-2023-33460, CVE-2022-24795, CVE-2017-16516) and fixes have had to be carried by downstream distributions and third parties. This is not an ideal situation. While a fork exists[2], it is unclear how widely adopted or blessed it is downstream.

As the maintainer of libmodsecurity for Fedora[3] and EPEL, I recently found that the yajl library will not be shipped with RHEL 10. This means a new maintainer would be required to add it to EPEL. The previous maintainer for RHEL & EPEL has recommended moving away from yajl[4].

Currently, libmodsecurity can be built without yajl, but I understand that making it mandatory is considered desirable, as per #3144 and #3151.

Given the security concerns and the upstream status of yajl, I recommend opening a discussion on dropping yajl as a dependency and exploring alternative JSON libraries, such as JSON-C, which is actively maintained and more widely adopted.

[1] https://github.com/lloyd/yajl
[2] https://github.com/robohack/yajl/
[3] https://src.fedoraproject.org/rpms/libmodsecurity
[4] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YPFHPOKAND3RZR7ZKWTDHUQEESG6IUJ3/

[airween]

Agree, we should change.

What do you think about the "official" YAML library?

[airween]

Note, I added label [2.x] too, because mod_security2 is also affected.

[dune73]

This does not sound good. Thank you for bringing this to the attention @mikelolasagasti.

[berrange]

What do you think about the "official" YAML library?

I'm the Fedora yajl maintainer quoted in the link above. While YAML may be a superset of JSON, I'd not recommend using a YAML parser instead of a native JSON parser. It'll perform worse, and potentially open the code up to attacks that are impossible with pure JSON (aka the "Billion laughs attack" in YAML context). I can vouch for using json-c as an alternative to yajl, as that's what was successfully adopted in projects I work on. Be slightly cautious about jansson - when we previously tried it, we found it was not able to cope with the full numeric range of the uint64 type - if that's important to modsecurity's needs.

[airween]

Hi @berrange,

While YAML may be a superset of JSON, I'd not recommend using a YAML parser instead of a native JSON parser.

You're right, that was a mistake from me - sorry, and thank you.

[dune73]

Thank you for this very valuable input @berrange. That puts the replacement discussion on a far better base.

[marcstern]

These are the libraries that are reported (by their authors and third-parties) as the fastest:

• https://github.com/stephenberry/glaze
• https://github.com/simdjson/simdjson
• https://ibireme.github.io/yyjson/

It would be interesting to check their functionalities for our intended use:

• validation
• callback to store ARGS (or should we avoid that and use only the resulting sJSON onjects?)
• memory footprint

[dune73]

There are a few subtle behavior quirks of yajl that should be examined for alternative libraries too. And then documented in case.

The behavior with empty request body for example. From the back of my head I am no longer sure if yajl rejects that and other parsers are OK with it or if it's the other way around. But I've seen this problem in production before.

[marcstern]

This would definitely need extensive test cases

[airween]

Just a quick remark for this issue:

• I started to make a small tool which can help to compare different JSON implementations; still work in progress
• I've contacted with YAJL developer but after (almost) two weeks still no reply
  • Perhaps we should contact other contributors and fork YAJL repository, then fix the available issues...?

Other ideas?

[berrange]

I've contacted with YAJL developer but after (almost) two weeks still no reply

AFAICT they haven't replied to anyone asking about YAJL on github in many years. I see no notable github activity on their account in 10 years.

* Perhaps we should contact other contributors and fork YAJL repository, then fix the available issues...?

The thing about yajl forks is that there are already many to choose from, each with a random selection of changes, but none seem to gain critical mass/attention.

Personally I'd just recommend letting yajl fade out. There are already two actively maintained alternative plain C JSON libraries - jansson & json-c - json-c slightly more active, as well as glib-json for apps which happen to use GLib. Between them they ought to be able to satisfy JSON needs for C applications, unless there's an unavoidable need for historical bug compatibility with YAJL. Even bug compatibility is questionable since JSON ought to be used/consumed in a way that ensures it is interoperable across impls, so it doesn't feel like further investment in YAJL is a long term benefit.

[airween]

AFAICT they haven't replied to anyone asking about YAJL on github in many years. I see no notable github activity on their account in 10 years.

I saw that in some place but gave a try...

* Perhaps we should contact other contributors and fork YAJL repository, then fix the available issues...?

The thing about yajl forks is that there are already many to choose from, each with a random selection of changes, but none seem to gain critical mass/attention.

that's said.

Personally I'd just recommend letting yajl fade out. There are already two actively maintained alternative plain C JSON libraries - jansson & json-c - json-c slightly more active, as well as glib-json for apps which happen to use GLib. Between them they ought to be able to satisfy JSON needs for C applications, unless there's an unavoidable need for historical bug compatibility with YAJL. Even bug compatibility is questionable since JSON ought to be used/consumed in a way that ensures it is interoperable across impls, so it doesn't feel like further investment in YAJL is a long term benefit.

If we don't have other chance we must switch, but honestly I'd like to avoid that. If we will switch, I do not see any reason to keep any compatibility with old bugs, I agree with you.

And thanks for following this issue.