Source: rust-protobuf
Followup-For: Bug #1103833
X-Debbugs-Cc:
noisycoil@tutanota.com,
jelmer@debian.org,
infinity0@debian.org,
dr@jones.dk
Control: forwarded -1
https://github.com/stepancheg/rust-protobuf/issues/763
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)