Use version of yajl with fixes to known problems

[Arithmomaniac]

cextern/yajl points to the original lloyd/yajl, which has been abandoned for a decade now. CVEs have been accumulating since then.
Consider using a maintained fork like https://github.com/robohack/yajl.

[rtobar]

@Arithmomaniac thanks for the suggestion, I didn't know about the fork, although I knew Lloyd's yajl was fairly unmaintained.

CVEs have been accumulating since then

I see only one related to yajl itself (https://nvd.nist.gov/vuln/detail/CVE-2023-33460), and it concerns a function we don't use, so I'm not particularly worried about it.

Consider using a maintained fork like https://github.com/robohack/yajl

I didn't know about this fork, thanks for pointing me to it!

I gave it a cursory look. One think that caught my attention immediately is that they decided to not keep updating, and then remove, the changelog. A related commit around that operation reads "Use the Source", which I think it implies ones has to go and figure out the changes between releases by inspecting git diffs,.commit messages, and figuring out what they do.

The from has been active since 2016, and it changed the build system from cmake to BSD make (I had never seen that, either). Most commits seemed to be related to that change, so I honestly can't really say what's been actually changed/fixed in the library itself, apart from the fix for that CVE, that again isn't relevant to us. Sure, I could go and spend more time doing the diffs, etc, but that's time I don't have.

Having said all that, I'm not fully closed to the idea of there's actual, real merit to using that fork.

Also mind you that we not always embed the yajl library in our package, but also dynamically load it (via ctypes, cffi, or even from the C extension if you're building locally instead of creating a stand-alone binary wheel), so I'd need to be mindful of not breaking any of that support.

I'll close this issue for now, as I think there's nothing I'll be doing around it, but please feel free to continue the discussion, like I said I'm not closed to the idea, I just don't want an issue stalled forever if I know so won't probably address it.

[jpmckinney]

FWIW https://github.com/openEuler-BaseService/yajl looks like a simpler fork that just focuses on fixing CVEs and memory leaks.

[Arithmomaniac]

It seems the Linux distros that package yajl prefer to use patch files. That's another alternatives.
(Looking at the patch files, you can see all three CVEs.)

• https://src.fedoraproject.org/rpms/yajl/tree/rawhide
• https://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/yajl/yajl
• https://git.launchpad.net/ubuntu/+source/yajl/tree/debian/patches
  • Mirrored at https://github.com/pexip/os-yajl/tree/d7dc4a8f2b75e5660cc5c6748f3cc9eabbffcaef/debian/patches

[rtobar]

Thanks both @Arithmomaniac and @jpmckinney for the further pointers for patches and CVEs (when I originally searched for CVEs I did find three, but annoyingly the other two were attributed to the ruby yajl extension, so I quickly --but wrongly-- dismissed them).

Keeping around a couple of patches sounds like a way better idea than relying on a heavily modified fork, and seeing that Linux repos have been doing the same gives the solution more credibility. With that, let me reopen this issue and change its title for clarity.

Also, like I justed mentioned elsewhere in #109 (comment) (last paragraph, last couple of phrases), I won't be working on this for at least two weeks, maybe more.

[rtobar]

An update: I've been looking closer to the CVEs and associated patches. From the three, two are relevant, while the third doesn't concern our usage of yajl. Still, it's probably still worth keeping around, just in case.

I previously said I'd store some patches, but thinking about it I'd rather keep a fork with the patches applied as commits and refer to that, otherwise I have to add code to deal with patches, which I'd rather not do.

[rtobar]

Merged to master, closing this issue. Thanks again everyone for the pointers and input!