This is not a vulnerability report. It concerns a recommendation inside an existing advisory that points readers at a crate which still reproduces that advisory's own reproducer.
The advisory
RUSTSEC-2023-0085 documents a panic in the unmaintained hpack crate:
let input = &[0x3f];
let mut decoder = hpack::Decoder::new();
let _ = decoder.decode(input);
It closes with:
Also consider using fluke-hpack or httlib-huffman as an alternative.
The observation
fluke-hpack is a fork of the affected code, and the same input still panics in the newest published version under that name:
// fluke-hpack 0.3.1 — panics: called `Option::unwrap()` on a `None` value
let _ = fluke_hpack::Decoder::new().decode(&[0x3f]);
Call site, src/decoder.rs:505:
let (new_size, consumed) = decode_integer(buf, 5).ok().unwrap();
decode_integer returns the correct error; .ok().unwrap() discards it.
Why this is a naming issue rather than a maintainer issue
The project was renamed from fluke to loona, and the successor crate is already fixed. At the equivalent site in loona-hpack 0.4.3 (src/decoder.rs:538):
let (new_size, consumed) = decode_integer(buf, 5)?;
Verified across all 256 single-byte inputs:
| Crate |
latest version |
last published |
single bytes that panic |
hpack |
0.3.0 |
(unmaintained) |
affected, per this advisory |
fluke-hpack |
0.3.1 |
2024-05-28 |
1 (0x3f) |
loona-hpack |
0.4.3 |
2024-11-03 |
0 |
So the advisory currently steers readers from a known-affected crate to a superseded crate name that is also affected, while the maintained successor under the new name is fine.
Possible resolutions
Entirely your call which, if any:
- update the recommendation to name
loona-hpack instead of fluke-hpack;
- qualify the existing recommendation with a minimum version or a note;
- or leave it and let the upstream maintainers decide, if they choose to yank or supersede the affected
fluke-hpack version.
We are not requesting a new advisory for fluke-hpack. We reported the finding to the maintainers first, at bearcove/loona#247, and noted there that their current code already carries the fix.
A secondary observation, offered only as context
cargo deny did not surface this for us, because RUSTSEC-2023-0085 is keyed to the package name hpack while the fork ships under a different name. That is expected behaviour and not a defect in the database — we mention it only because it is the mechanism by which a renamed fork and a name-keyed advisory can drift apart, which may be relevant to how the recommendation is worded.
How we found it
A differential test of our own HPACK decoder against fluke-hpack and httlib-hpack, including an exhaustive sweep of all single-byte inputs.
This is not a vulnerability report. It concerns a recommendation inside an existing advisory that points readers at a crate which still reproduces that advisory's own reproducer.
The advisory
RUSTSEC-2023-0085 documents a panic in the unmaintained
hpackcrate:It closes with:
The observation
fluke-hpackis a fork of the affected code, and the same input still panics in the newest published version under that name:Call site,
src/decoder.rs:505:decode_integerreturns the correct error;.ok().unwrap()discards it.Why this is a naming issue rather than a maintainer issue
The project was renamed from
fluketoloona, and the successor crate is already fixed. At the equivalent site inloona-hpack0.4.3 (src/decoder.rs:538):Verified across all 256 single-byte inputs:
hpackfluke-hpack0x3f)loona-hpackSo the advisory currently steers readers from a known-affected crate to a superseded crate name that is also affected, while the maintained successor under the new name is fine.
Possible resolutions
Entirely your call which, if any:
loona-hpackinstead offluke-hpack;fluke-hpackversion.We are not requesting a new advisory for
fluke-hpack. We reported the finding to the maintainers first, at bearcove/loona#247, and noted there that their current code already carries the fix.A secondary observation, offered only as context
cargo denydid not surface this for us, because RUSTSEC-2023-0085 is keyed to the package namehpackwhile the fork ships under a different name. That is expected behaviour and not a defect in the database — we mention it only because it is the mechanism by which a renamed fork and a name-keyed advisory can drift apart, which may be relevant to how the recommendation is worded.How we found it
A differential test of our own HPACK decoder against
fluke-hpackandhttlib-hpack, including an exhaustive sweep of all single-byte inputs.