support pqcrypto in wasm unknown unknown

[biryukovmaxim]

PR Description

This PR adds support for the wasm32-unknown-unknown target to most pqcrypto-* crates (ML-KEM, ML-DSA, Falcon, HQC, SPHINCS+),

Motivation

Rust's wasm32-unknown-unknown target is commonly used for WebAssembly applications (e.g., via wasm-bindgen). Previously, pqcrypto crates did not compile on this target

What this PR does

• Removes the unconditional dependency on the libc crate.

• Switches FFI types from libc::c_int to core::ffi::c_int (libc itself will reexport core according to the issue: Remove the libc version of core::ffi primitives rust-lang/libc#4257)

• For the wasm32-unknown-unknown target, adds a conditional dependency on wasm32-unknown-unknown-openbsd-libc = "0.2" (see https://github.com/trevyn/wasm32-unknown-unknown-openbsd-libc).

• Adds build.rs logic to include the libc port's headers and link against it when targeting wasm, enabling compilation of C code in wasm.

• Introduces a getrandom_wasm_js feature that enables getrandom = { features = ["wasm_js"] }.

• Updates templates.

• Propagates the feature to the umbrella pqcrypto crate.

This allows successful compilation and execution in WASM. simple example

Usage examples

Compile a single crate:

cargo build --target wasm32-unknown-unknown \
  --features getrandom_wasm_js \
  -p pqcrypto-hqc

[thomwiggers]

Thanks, on first glance this looks pretty good. Could you please confirm the following:

• You modified the templates (which is the correct move); can you confirm you ran generate-implementations.py instead of making manual changes to schemes (i.e., running that on this branch should not create a

Secondly, could you please add this to CI, so that it won't get out of date? I don't have a wasm32 build environment locally.

[biryukovmaxim]

Thanks, on first glance this looks pretty good. Could you please confirm the following:

• You modified the templates (which is the correct move); can you confirm you ran generate-implementations.py instead of making manual changes to schemes (i.e., running that on this branch should not create a

Yes, correct. I think it makes sense to add the step in ci confirming equality of code compared to generated one(if it's not done yet)

Secondly, could you please add this to CI, so that it won't get out of date? I don't have a wasm32 build environment locally.

Should it be clippy, check, build or all three?

[thomwiggers]

Checking idempotency of code generation is a good idea, we don't have that yet! If you want to have a go at it, a separate PR sounds great. Let's not let it block this PR.

I think building the WASM target is most important, that covers checking. I don't think there are code paths that would be hidden from clippy in the other build targets, so running Clippy is not that important — but otoh it's pretty free to add, so might as well?

[biryukovmaxim]

@thomwiggers I added ci job here.
also i changed serialization feature so it doesnt enable all inner crates by default. It only enables crate/serialization feature if crate is already enabled

#95
separate pr that checks idempotency of code generation