fix(libsodium): disable C11 Annex K declarations to fix build with picolibc and update library to 1.0.22

[hrushikesh430]

Problem

Building libsodium with ESP-IDF v6.0+ (picolibc) fails with:

picolibc/include/errno.h:43:9: error: unknown type name '__errno_t'
picolibc/include/string.h:219:9: error: unknown type name '__rsize_t'

Root Cause

libsodium's utils.c defines __STDC_WANT_LIB_EXT1__=1 to request C11 Annex K types. In picolibc those types (__errno_t, __rsize_t) live in sys/_types.h, gated behind that same macro.

Via the force-include in libsodium/CMakeLists.txt, the PSA → mbedTLS → libc chain pulls sys/_types.h in before utils.c sets the macro:

port_include/sodium/crypto_hash_sha256.h
  └── <psa/crypto.h>
      └── <psa/crypto_struct.h>
          └── <psa/crypto_driver_contexts_primitives.h>
              └── … (PSA driver context chain) …
                  └── <mbedtls/platform_time.h>
                      └── <time.h>
                          └── <sys/_types.h>   ← typedefs gated here

Once the include guard fires, __errno_t / __rsize_t are never declared, and later errno.h / string.h fail. The libsodium test app doesn't reach this chain, so CI never tripped on it.

Fix

Add -D__STDC_WANT_LIB_EXT1__=0 as a compile definition in libsodium/CMakeLists.txt. The -D applies before any source, overriding utils.c, so picolibc skips the Annex K declarations regardless of include order. libsodium on ESP-IDF does not use Annex K functions.

Component version bumped to 1.0.22.

References

• picolibc#868 — upstream fix rejected; per C standard, only applications should define __STDC_WANT_LIB_EXT1__
• zephyr#104666 — same issue in Zephyr

Update libsodium to v1.0.22

This PR also bumps the libsodium submodule from 1.0.21-RELEASE to 1.0.22-RELEASE, so the 1.0.22 component version actually matches the underlying source.

What changed:

• Submodule pointer moved to the 1.0.22-RELEASE tag.
• New 1.0.22 sources added to the build: ML-KEM768, X-Wing hybrid KEM (ML-KEM768 + X25519), the high-level crypto_kem_* API, and SHA-3.
• sbom_libsodium.yml updated with the new version and commit hash.
• Upstream KEM tests (kem, kem_mlkem768, kem_xwing) added to the test app to verify ML-KEM and X-Wing on target.

Found no CVE using command esp-idf-sbom manifest check --local-db --extended-scan libsodium/

[hrushikesh430]

@mahavirj @AdityaHPatwardhan PTAL

[mahavirj]

@Lapshin PTAL

[Lapshin]

@hrushikesh430 , thank you for the PR. I found it difficult to follow the description due to factual inconsistencies introduced by AI.

This is safe because libsodium does not use any Annex K functions (memset_s, etc.) on ESP-IDF — it uses its own sodium_memzero() implementation instead.

Could not find if Espressif's own implementation exists. Could you add a link?

Looks like it is "safe" for now, because original libsodium defines HAVE_MEMSET_S and others based on OS which looks wrong to me. It should be defined by configure script or something similar to their build system. It could be a task to send a patch to upstream (cc @mahavirj )

This happens in real user projects that have multiple ESP-IDF components (WiFi, HTTP, MQTT, etc.) whose headers transitively pull in sys/_types.h before libsodium's utils.c can set the macro.

From your description, it sounds like utils.c sets macro globally for every other translation unit. But this is not true. utils.c sets macro only for it's own code (until you do #include "utils.c" in another translation unit). And it's done at the very top of the file (looks correct to me). I see one way to reproduce the issue by passing -include <file> in cmdline

libsodium can fail to compile with:

Could you please share a minimal example that reproduces the issue?

[mahavirj]

@Lapshin @hrushikesh430

Include file dependency is coming from the CMakeLists include injection here:

idf-extra-components/libsodium/CMakeLists.txt

Lines 196 to 197 in 84363b0

	"$<$<COMPILE_LANGUAGE:C>:SHELL:-include ${CMAKE_CURRENT_SOURCE_DIR}/port_include/sodium/crypto_hash_sha256.h>"
	"$<$<COMPILE_LANGUAGE:C>:SHELL:-include ${CMAKE_CURRENT_SOURCE_DIR}/port_include/sodium/crypto_hash_sha512.h>")

  port_include/sodium/crypto_hash_sha256.h                                             
    └── <psa/crypto.h>                                    ← the entry point
        └── <psa/crypto_struct.h>                                                      
            └── <psa/crypto_driver_contexts_primitives.h>
                └── … (PSA driver context chain) …                                     
                    └── <mbedtls/platform_time.h>                                      
                        └── <time.h>                       ← first libc header         
                            └── <sys/_types.h>             ← typedefs gated here 

The fix from this PR should work well. @hrushikesh430 Can you please update the PR description and also bump the component version?

CC @Ashish285

[Ashish285]

LGTM! The fix is similar as mbedTLS 4.1 (with tf-psa-crypto 1.1).

@Lapshin, is it safe to set __STDC_WANT_LIB_EXT1__=0 as default in ESP-IDF when building with picolibc?

[Lapshin]

@Ashish285 , toolchains are not required to have this feature supported. I think this can be disabled by default

[hrushikesh430]

@mahavirj @Ashish285 @AdityaHPatwardhan Updated the PR, PTAL.