`cargo-deny` advisory check failing due to RUSTSEC-2026-0009 (time crate)

[lalitb]

Summary

The cargo-deny advisory check is failing in CI due to RUSTSEC-2026-0009, a newly published advisory (Feb 5, 2026) for the time crate v0.3.41 - Denial of Service via stack exhaustion in RFC 2822 date parsing.

The cargo-deny job has continue-on-error: true, so CI is not blocked.

Why we can't fix it yet

The fix (time >= 0.3.47) requires Rust 1.88.0, which is incompatible with the workspace MSRV of 1.75.0.

Resolution alternatives

1. Wait for time crate backport - upstream releases a fix compatible with Rust <1.88.0
2. Bump workspace MSRV to >= 1.88.0 to allow time 0.3.47 resolution
3. Ignore the advisory in deny.toml until a compatible fix is available
4. Not take dependency on time crate and write the necessary functionality ourselves.

Affected dependency tree

time v0.3.41
--> actix-web v4.12.1
--> azure_identity v0.29.0 (via typespec_client_core)
--> cookie v0.16.2 (via actix-web)
--> rcgen v0.14.7
--> yasna v0.5.2 (via rcgen)

Upstream tracking: https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05

[utpilla]

Resolution alternatives

1. Wait for time crate backport - upstream releases a fix compatible with Rust <1.88.0
2. Bump workspace MSRV to >= 1.88.0 to allow time 0.3.47 resolution
3. Ignore the advisory in deny.toml until a compatible fix is available

I would like to add another resolution alternative which is to not take dependency on time crate and write the necessary functionality ourselves.

"until a compatible fix is available" and "upstream releases a fix compatible with Rust <1.88.0"

It doesn't look like this would happen. Check this issue: time-rs/time#767

[lalitb]

I would like to add another resolution alternative which is to not take dependency on time crate and write the necessary functionality ourselves.

+1, added in the options

[jhpratt]

I will note that Rfc2822 does not appear anywhere in this repository, so there's no vulnerability here.

[lalitb]

The time advisory comes from azure-core and azure-identity, which have resolved it in their 0.31+ releases. However, those releases also bump the MSRV to 1.88. We'd need to decide whether to bump our MSRV accordingly - this would cascade to the Geneva exporter in the otel-arrow repo as well.

otel-arrow is currently at MSRV 1.87, so going to 1.88 for contrib-crates in otel-arrow would be a minor bump and shouldn't be an issue in practice.

I vote for bumping geneva-uploader, and also subsequently contrib-crates in otel-arrow to fix this.