I looked into this, I will try to summarize the situation to the best of my
knowledge.
CVE-2024-7254 was fixed in rust-protobuf 3.7.2, but testing ships 2.27.1 and
the fix was not backported to v2. An informal backport request was made in [1],
a backport commit was proposed in [2] but ignored, and earlier today I filed
a more formal backport request in [3] explaining our position.
As usual we have 3 ways to fix this: backport, remove, update.
* Backporting
As I said above, no official backport is currently available. The developer who
proposed [2] does not seem to be entirely sure about why one test is not
failing in the first place and the proposal was not reviewed. I'm not
personally going down this route because I'm not knowledgeable enough about
Protocol Buffers to attempt fixing a CVE that affects how parsing is
implemented. But if someone is able to take a shot at this, this is probably
the best solution. Also, maybe [3] will receive an answer, who knows?
* Removing
Static-Built-Using and company [4] say there are only 3 applications in
testing built against rust-protobuf:
- erbium (maintainer: Jelmer Vernooij <jelmer@debian.org>, popcon: 1)
- protobuf-codegen (maintainer: Ximin Luo <infinity0@debian.org>, popcon: 40)
- scaphandre (maintainer: Jonas Smedegaard <dr@jones.dk>, popcon: 22)
Their maintainers are cc'ed to this email. I did not investigate whether the
dependency on rust-protobuf can be patched out for these.
According to codesearch, the full (r)dependency tree is:
- rust-protobuf-codegen (leaf + library, rdeps below)
- rust-protobuf-codegen-pure (rdeps below)
- rust-protoc-rust (no rdeps, essentially unmaintained, can be removed)
- rust-pprof (pending autoremoval, Rust Team already wants to see it gone)
- rust-handlebars (only tests depend on pprof, has many rdeps, cannot be
removed, needs decoupling)
- rust-prometheus
- rust-erbium-core
- rust-erbium (leaf, no rdeps)
- rust-opendal (no rdeps, never in testing, can be removed)
- rust-ttrpc (no rdeps)
- scaphandre (leaf, no rdeps)
Library-wise, it seems many of these packages can already be removed. But we
must hear from the applications' maintainers before going down this route [5].
* Updating
Updating requires 2 transitions: rust-prometheus is currently at v0.13, but
only v0.14 is compatible with protobuf 3. Porting prometheus to protobuf 3
seems to be non trivial: it was done in [6] with a +1400,-1500 LOC PR. Thus in
addition to updating the toplevel crates in the list above -- a draft for which
is kinda complete in [7] -- we should also update prometheus' rdeps -- namely,
rust-erbium-core and rust-opendal (but the latter could just be removed). Note
that the version of rust-protobuf-codegen that goes with the fixed version of
rust-protobuf (3.7.2) requires a package not in Debian: rust-protobuf-parse.
So to update we would not only need an unblock for a full transition and a
semver-breaking update/small transition, but also an unblock from NEW (the
package is not even in NEW yet, to be clear). Clearly this is the least
feasible option, only motivated by the high-severity CVE (score: 8.7) if there
is a strong need to keep the three applications above, no way to decouple them
from the insecure behavior in rust-protobuf and no way to backport the fix.
Cheers!
[1] https://github.com/stepancheg/rust-protobuf/pull/756#issuecomment-2710162444
[2] https://github.com/stepancheg/rust-protobuf/pull/756#issuecomment-2715961002
[3] https://github.com/stepancheg/rust-protobuf/issues/763
[4] `grep-dctrl -s Package -F Static-Built-Using,X-Cargo-Built-Using rust-protobuf /var/lib/apt/lists/*Packages | sort -u`
[5] I understand based on recent history Ximin Luo may not answer.
[6] https://github.com/tikv/rust-prometheus/pull/541
[7] https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/896