Downgrade time dependency to 0.3.5

[tankyleo]

    Downgrade time dependency to 0.3.5

    We downgrade to a version unaffected by a stack exhaustion denial of
    service attack in the time dependency reported in

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

    We cannot upgrade to 0.3.47 as this requires an MSRV bump.

    We will follow-up with a drop of the time dependency.

[ldk-reviews-bot]

👋 I see @tnull was un-assigned.
If you'd like another reviewer assignment, please click here.

[tankyleo]

To reproduce: cargo update -p time --precise 0.3.5

[tnull]

As discussed elsewhere, I'm not sure we want to do this. It seems we're not directly affected by the vulnerability, so could simply go for dropping the dependencies soon.

Here's a summary generated by Claude:

Vulnerability Summary

The fix in time addresses a stack exhaustion DoS in the RFC2822 date parser. Specifically, the comment() / ccontent() / cfws() functions could be made to recurse infinitely via deeply nested comments in RFC2822-formatted input. The fix adds a DEPTH_LIMIT of 32.

Your Dependency Chain

The time crate (v0.3.45) is a transitive dependency, pulled in via:

vss-server
└── auth-impls
└── jsonwebtoken v9.3.1
└── simple_asn1 v0.6.3
└── time v0.3.45

There is no direct usage of time anywhere in your source code.

Are the Patched Codepaths Reachable?

No, you are not impacted.

simple_asn1 enables the parsing feature of time, but it only uses:

• time::format_description::parse() — to build custom format descriptors for ASN.1 date formats (UTCTime and GeneralizedTime)
• PrimitiveDateTime::parse() / PrimitiveDateTime::format() — with those custom format descriptors

It never invokes the RFC2822 parser. The vulnerable functions (comment(), ccontent(), cfws()) are part of time's RFC2822 parsing module, which is a completely separate code path from format_description-based parsing. Even though the parsing feature is compiled in, the RFC2822 module's
functions are only reached if explicitly called — and nothing in your dependency chain calls them.

In short: the vulnerable code is compiled but dead/unreachable from your crate's perspective. You can safely disregard this advisory for your project.