ghsa

Affected versions of this crate did not implement `Drop` when `#[zeroize(drop)]` was used on an `enum`. This can result in memory not being zeroed out after dropping it, which is exactly what is intended when adding this attribute. The flaw was corrected in version 1.2 and `#[zeroize(drop)]` on `enum`s now properly implements `Drop`.

Affected versions of this crate did not require event handlers to have `Send` bound despite there being no guarantee of them being called on any particular thread, which can potentially lead to data races and undefined behavior. The flaw was corrected in commit [afe3252](https://github.com/microsoft/windows-rs/commit/afe32525c22209aa8f632a0f4ad607863b51796a) by adding `Send` bounds.

Affected versions of this crate claimed to construct a const `Vec` with nonzero length and capacity, but that cannot be done because such a `Vec` requires a pointer from an allocator. The implementation was later changed to just construct a `std::borrow::Cow`.

Affected versions of this crate maintains references to memory that might have been freed already. If affects the following two `tremor-script` language constructs: * A [Merge](https://www.tremor.rs/docs/tremor-script/index#merge) where we assign the result back to the target expression and the expression to be merged needs to reference the `event`: ``` let state = merge state of event end; ``` * A [Patch](https://www.tremor.rs/docs/tremor-script/index#patch) where we assign the result back to the target expression and the patch operations used need to reference the `event`: ``` let state = patch state of insert event.key => event.value end; ``` For constructs like this (it doesnt matter what is references in the expression to be merged or the patch operations) an optimization was applied to manipulate the target value in-place, instead of cloning it. Our `Value` struct which underpins all event data in `tremor-script`, is representing as borrowed strings `beef::Cow<'lifetime...

`tower_http::services::fs::ServeDir` didn't correctly validate Windows paths meaning paths like `/foo/bar/c:/windows/web/screen/img101.png` would be allowed and respond with the contents of `c:/windows/web/screen/img101.png`. Thus users could potentially read files anywhere on the filesystem. This only impacts Windows. Linux and other unix likes are not impacted by this. See [tower-http#204] for more details. [tower-http#204]: https://github.com/tower-rs/tower-http/pull/204

In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.

Affected versions of this crate passes an uninitialized buffer to a user-provided `Read` implementation. Arbitrary `Read` implementations can read from the uninitialized buffer (memory exposure) and also can return incorrect number of bytes written to the buffer. Reading from uninitialized memory produces undefined values that can quickly invoke undefined behavior. The problem was fixed in commit `cdff034` by zero-initializing the buffer before passing it to a user-provided `Read` implementation.

Version 0.6.0 of the `simple_asn1` crate panics on certain malformed inputs to its parsing functions, including `from_der` and `der_decode`. Because this crate is frequently used with inputs from the network, this should be considered a security vulnerability. The issue occurs when parsing the old ASN.1 "UTCTime" time format. If an attacker provides a UTCTime where the first character is ASCII but the second character is above 0x7f, a string slice operation in the `from_der_` function will try to slice into the middle of a UTF-8 character, and cause a panic. This error was introduced in commit [`d7d39d709577710e9dc8`](https://github.com/acw/simple_asn1/commit/d7d39d709577710e9dc8833ee57d200eef366db8), which updated `simple_asn1` to use `time` instead of `chrono` because of [`RUSTSEC-2020-159`](https://rustsec.org/advisories/RUSTSEC-2020-0159). Versions of `simple_asn1` before 0.6.0 are not affected by this issue. The [patch](https://github.com/acw/simple_asn1/pull/28) was applied i...

The v0.9.7 release of the `sha2` crate introduced a new AVX2-accelerated backend which was automatically enabled for all x86/x86_64 CPUs where AVX2 support was autodetected at runtime. This backend was buggy and would miscompute results for long messages (i.e. messages spanning multiple SHA blocks). The crate has since been yanked, but any users who upgraded to v0.9.7 should immediately upgrade to v0.9.8 and recompute any hashes which were previously computed by v0.9.7.

Affected versions of this crate did not properly calculate secret shares requirements. This reduces the security of the algorithm by restricting the crate to always using a threshold value of three, rather than a configurable limit. The flaw was corrected by correctly configuring the threshold.