Cargo Audit

[github-actions]

Vulnerabilities

Id	Package	Title	Date
RUSTSEC-2024-0021	eyre	Parts of Report are dropped as the wrong type during downcast	2024-03-05
RUSTSEC-2024-0332	h2	Degradation of service in h2 servers with CONTINUATION Flood	2024-04-03
RUSTSEC-2024-0003	h2	Resource exhaustion vulnerability in h2 may lead to Denial of Service (DoS)	2024-01-17
RUSTSEC-2024-0013	libgit2-sys	Memory corruption, denial of service, and arbitrary code execution in libgit2	2024-02-06
RUSTSEC-2021-0076	libsecp256k1	libsecp256k1 allows overflowing signatures	2021-07-13
RUSTSEC-2024-0019	mio	Tokens for named pipes may be delivered after deregistration	2024-03-04
RUSTSEC-2021-0041	parse_duration	Denial of service through parsing payloads with too big exponent	2021-03-18
RUSTSEC-2024-0336	rustls	rustls::ConnectionCommon::complete_io could fall into an infinite loop based on network input	2024-04-19
RUSTSEC-2018-0005	serde_yaml	Uncontrolled recursion leads to abort in deserialization	2018-09-17
RUSTSEC-2024-0006	shlex	Multiple issues involving quote API	2024-01-21

[brentstone]

@tzemanovic @Fraccaman

Looking through these rn, some notes:

• not sure if we can upgrade to libsecp256k1 >= 0.5.0
• the parse_duration vuln has no patch
• we already use serde-json-wasm 1.0.1 & 0.5.2 so we shouldn't be vulnerable anymore
• not sure if we can update serde_yaml

In cases where I'm not sure if we can upgrade, I tried cargo update <dep>, which ended up doing nothing.

[Fraccaman]

• libsecp256k1 is transitive dependency of tiny-hderive. We would have to fork it.
  • anyway, we are using it just to derive HD wallets, not a big deal
• parse_duration is used only in the sdk arguments parsing
• serde_yaml is a transitive dependency of madata and is only used in namada_encoding_spec. Not a big deal.

Maybe we can just fork and fix libsecp256k1 ? @tzemanovic

[tzemanovic]

let's fork tiny-hderive and replace libsecp256k1 with k256 - let's try to upstream it too so we don't have to stay on a fork (for ref this is where we switched to it #1958)

[tzemanovic]

let's switch from parse_duration to https://crates.io/crates/iso8601-duration as it's no longer being maintained

[sug0]

parse-duration is only being used in the CLI, but it can't hurt to move away from it

EDIT: here's an alternative: https://docs.rs/duration-str/latest/duration_str/

it depends on winnow for parsing, which is a fork of nom (a well known parser combinator lib in Rust). cargo-edit uses winnow, so it's widely adopted.

iso8601-duration doesn't seem to be suitable for parsing human readable strings I think, such as 5m (5 minutes)

[brentstone]

Completed in #3218