feat: add wasm-bindgen feature for wasm

[Its-Just-Nans]

This MR add the wasm-bindgen feature of the time crate on wasm https://docs.rs/crate/time/latest/features

Without the feature we have the error

time not implemented on this platform

Test file

//! cargo add --dev wasm-bindgen-test
//! wasm-pack test --node
#![cfg(target_arch = "wasm32")]

use x509_parser::pem::{parse_x509_pem, Pem};
use x509_parser::{parse_x509_certificate, x509::X509Version};

static IGCA_PEM: &[u8] = include_bytes!("../assets/IGC_A.pem");



#[wasm_bindgen_test::wasm_bindgen_test]
fn test_x509_parse_pem() {
    let pem: Vec<Pem> = Pem::iter_from_buffer(IGCA_PEM)
        .collect::<Result<_, _>>()
        .ok()
        .unwrap();
    let x509 = pem[0].parse_x509().unwrap();
    assert_eq!(x509.validity.is_valid(), false);
}

cargo install wasm-pack

cargo add --dev wasm-bindgen-test
wasm-pack test --node

[Its-Just-Nans]

note that the tests/test01.rs needs to be restricted for non-wasm because usize is not the same in wasm

I can add that on this MR

Edit: DONE

[cpu]

Seems reasonable, but is there a way to add CI coverage so that support doesn't accidentally regress?

[Its-Just-Nans]

is there a way to add CI coverage so that support doesn't accidentally regress?

yes, I will add that

[Its-Just-Nans]

Unfortunalty it's seems not possible because of the current MSRV

Or i can add dymanicly in the CI the

cargo add --dev wasm-bindgen-test

needs re-review with the latest pushes

[cpu]

Thanks for iterating on this, I think it's getting close :-)

I don't know how others feel, but I'd personally have an easier time reviewing this if you were able to rebase to squash your own iteration down into the original commits.

[Its-Just-Nans]

Thanks for the review!

I don't know how others feel, but I'd personally have an easier time reviewing this if you were able to rebase to squash your own iteration down into the original commits.

Okay, I understand that the commits history is missleading since I did multiple changes.
I cleaned the commits

btw a save of the commit order is available on https://github.com/Its-Just-Nans/x509-parser/tree/time-wasm-bindgen-save

[Its-Just-Nans]

In my latest change

• conditional compilation on parser02 and test02 only feat: add wasm-bindgen feature for wasm #231 (comment)
• added a comment on the rust.yml for the dependency feat: add wasm-bindgen feature for wasm #231 (comment)

[cpu]

Thanks!

I think you misunderstood me and squashed everything into one commit. That's better and I'm OK approving, but in the future my personal preference would be something like:

• a commit fixing the typos
• a commit gating the tests that won't run on wasm32
• a commit fixing the time dependency feature
• a commit adding the test & CI integration

Hope that makes sense! I know it's more work, but in my experience it optimizes for the reviewer and it's hard to find time for this crate already :-)

[Its-Just-Nans]

Okay I understand, sorry for that

Should I bump the time dep since the security audit is failing ?

https://github.com/rusticata/x509-parser/actions/runs/22038536527/job/63675425805?pr=231

## Vulnerabilities

### [RUSTSEC-2026-0009](https://rustsec.org/advisories/RUSTSEC-2026-0009.html)

> Denial of Service via Stack Exhaustion

| Details             |                                                |
| ------------------- | ---------------------------------------------- |
| Package             | `time`                      |
| Version             | `0.3.41`                   |
| URL                 | [https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05](https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05) |
| Date                | 2026-02-05                         |
| Patched versions    | `>=0.3.47`                  |
| Unaffected versions | `<0.3.6`               |

## Impact

When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
service attack via stack exhaustion is possible. The attack relies on formally deprecated and
rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
non-malicious input will never encounter this scenario.

## Patches

A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
rather than exhausting the stack.

## Workarounds

Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
the stack consumed would be at most a factor of the length of the input.

[cpu]

Okay I understand, sorry for that

NP!

Should I bump the time dep since the security audit is failing ?

No, it's OK to ignore that for now. There's a fix pending in #223