minghuaw
Upgrade to parking_lot 0.12 to avoid RUSTSEC-2024-0384
You depend fluvio-wasm-timer 0.2.5 - still the latest after 4 years - which depends on parking_lot 0.11. This uses instant, which is generating RUSTSEC-2024-0384 because it's unmaintained. Is this still necessary, or could you patch parking_lot safely to 0.12? They removed the dependency on instant during the prerelease minor version bump.
I think this is only enabled when compiled to wasm, but let me double check and see if it's still necessary
If it is, are you only using Instant for date math? You don't need to get the current system time (which WASM can't anyway)? I presume so.
I ask because I opened a bug long ago on rust and was working on a fix but haven't had much vested interest in completely it that would allow instant to work for WASM (sans the current date/time).
@LarryOsterman were there other issues blocking WASM support when using fe2o3 or was it external factors? If we don't need WASM support and if @minghuaw would be so kind as to add a feature to exclude that crate except for wasm32-unknown-unknown (or similar), we could opt out of that dependency.
I don't quite remember why I use it. I'll try to take a look tomorrow and see if it's really needed.
@heaths I have published a new patch release "0.13.2" where fluvio-wasm-timer was replaced with wasmtimer which is based on parking_lot "0.12". I haven't added a new feature to gate that part of the code yet tho, which I'm considering in the next breaking release ("0.14.0"). Would the current change in "0.13.2" suffice your needs so far?
We were on fe2o3-amqp (and dependencies) version 0.12 so we'll have to migrate some of our code first; however, seems like it would solve the issue and get rid of the transitive instant dependency. /cc @LarryOsterman
Awesome - I'll take care of it asap.
Current PR moves us to 0.13. Not 100% sure how I didn't notice the 0.13 release :(.
👍 I think the there wasn't any major changes in fe2o3-amqp's API between "0.12" and "0.13". The breaking change was caused by removing an error variant in serde_amqp, which is re-exported in fe2o3-amqp
Yup, that was straightforward. Moving between 0.12 and 0.13 ended up being a bit trickier and I need to dig a bit deeper (unrelated to the fe2o3 changes - there's an unrelated conflict between two different indirect dependencies.
But that fix is on us, and we need to make it to move forward - it is not on fe2o3.
To summarize, our problem is in duplicate dependencies on getrandom, which 0.2 is a transitive dependency as well and the WASM support workarounds are incompatible between 0.2 and 0.3, as discussed a bit in https://github.com/rust-random/getrandom/issues/433. For example, fe2o3-amqp and our crates both have a dependency on uuid, which has a dependency on getrandom 0.2; though, it seems like sometime between 1.11 (what we have) and 1.16 they upgraded to getrandom 0.3. Since you only depend on "1" and don't have a Cargo.lock file checked in (recommended for a while for lib crates, BTW), maybe we can peel this onion and try to get all getrandom dependents upgraded, @LarryOsterman.
I am considering yanking 0.13.2 once 0.13.3 is released (#310) as 0.13.2 introduced some unintended changes in the dependencies due my fault (see #309). This, however, should have no impact on azure sdk as the affected deps are gated behind rustls feature flag