[WIP][DO NOT REVIEW YET] Replace YAJL with yyjson for JSON parsing and generation

[giuseppe]

Switch from the unmaintained YAJL library to yyjson for all JSON operations. Update the build system (configure.ac, Makefile.am) to use yyjson, and update the libocispec submodule to the version with yyjson support.

gitmodules is pointing to my git repo for now.

Needs: containers/libocispec#170

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[gemini-code-assist]

Code Review

This pull request replaces the YAJL JSON library with yyjson across the crun codebase, updating build scripts, submodules, and source files to use the new API. The migration includes transitioning from YAJL types and macros to yyjson's document and value structures for container management and feature reporting. Review feedback identifies critical safety issues, specifically potential segmentation faults in src/libcrun/status.c and src/libcrun/utils.c due to missing type and NULL checks when processing JSON strings. Additionally, it is recommended to use signed integer getters for pid_t to ensure proper type handling and range validation.

[gemini-code-assist]

The new implementation lacks type validation for the JSON value. yyjson_get_str(tmp) returns NULL if the value is not a string. Passing NULL to xstrdup will likely cause a segmentation fault. The previous YAJL implementation was safer as it explicitly checked for the string type during retrieval. You should verify the type before attempting to duplicate the string.

    const char *val = yyjson_get_str (tmp);
    if (UNLIKELY (val == NULL))
      return crun_make_error (err, 0, "`cgroup-path` is not a string in `%s`", file);
    status->cgroup_path = xstrdup (val);

[gemini-code-assist]

Using yyjson_get_uint to populate a pid_t (which is typically a signed integer) is slightly risky if the value could be negative or if it exceeds the range of pid_t. Additionally, the previous implementation using YAJL checked the type of the node. yyjson_obj_get followed by yyjson_get_uint will return 0 if the key exists but is not a number. Consider using yyjson_get_int and adding a type check to ensure robustness against malformed status files.

    status->pid = (pid_t) yyjson_get_int (tmp);

[gemini-code-assist]

Calling strlen on jsondata without checking if it is NULL will lead to a segmentation fault if the caller passes a null pointer. While the previous YAJL implementation might have handled this internally or via the caller, it is safer to add an explicit check here, especially since this is a utility function.

  if (UNLIKELY (jsondata == NULL))
    return crun_make_error (err, 0, "JSON data is NULL");

  *out = yyjson_read (jsondata, strlen (jsondata), YYJSON_READ_NUMBER_AS_RAW);

[paravoid]

(Sorry if this counts as a review 😛 )

Ubuntu actually ships yyjson (as libyyjson-dev) since 25.04, so ubuntu-latest should have it. Debian ships it since stable (trixie) as well. I see this removes libyajl-dev but does not add libyyjson-dev. Same for the other "apt-get" changes in test.yaml etc.

[giuseppe]

thanks but they are not yet available in the versions used in the CI