RUSTSEC-2023-0085 recommends fluke-hpack, which still reproduces the advisory's own test case

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.

Locate the RUSTSEC-2023-0085 advisory entry and read its recommendation for fluke-hpack. Confirm the reported behavior against the stated fluke-hpack and loona-hpack versions, then update or qualify the recommendation according to the chosen resolution; done means the advisory no longer misleadingly directs readers to the affected crate name.