namada
namada copied to clipboard
Cargo Audit
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 |
@tzemanovic @Fraccaman
Looking through these rn, some notes:
- not sure if we can upgrade to
libsecp256k1 >= 0.5.0 - the
parse_durationvuln has no patch - we already use
serde-json-wasm 1.0.1 & 0.5.2so 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.
libsecp256k1is transitive dependency oftiny-hderive. We would have to fork it.- anyway, we are using it just to derive HD wallets, not a big deal
parse_durationis used only in the sdk arguments parsingserde_yamlis a transitive dependency ofmadataand is only used innamada_encoding_spec. Not a big deal.
Maybe we can just fork and fix libsecp256k1 ? @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)
let's switch from parse_duration to https://crates.io/crates/iso8601-duration as it's no longer being maintained
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)
Completed in #3218