Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian.org@packages.debian.org
Folks,
perhaps I should start with an outright confession: When doing
http-parser version 2.8.1-1+deb10u1 for a buster point release,
I messed up things horribly. Nobody noticed in time, it's in stable
now, and all I can do now is bringing things back in order.
# Problem
As described in #996939: The fix for CVE-2019-15605 changed, among
other things, the layout of "struct http_parser", by increasing the
size of the "flag" field and also its position¹ within the struct.
The latter ought not to do harm as the fields affected are marked as
private. But since that is not enforced in C, applications still might
access them.
The size change however is way worse, it caused the following elements,
especially "public" ones like "data" to change their offset.
Subsequently, applications built using the old header file will access
the wrong offset, and possibly segfault. This has been reported for the
tang package in #996460, and I have reason to assume *all* nine²
packages that use http-parser are affected.
# Solutions
After some discussion with Hilko Bengen (Cc:'ed) I can see two ways out
of this:
## Rebuild rdeps
In buster, re-build all packages that were built against http-parser.
So more or less a binNMU, but in a rather unusual area. Tightening the
install dependency to something like "libhttp-parser2.8 (>=
2.8.1-1+deb10u1~)" was nice to have.
Pros:
* If you have a process/automation for that, it should be little work
and therefore the risk of mistakes rather low.
Cons:
* Several packages are affected.
* If this has to be done manually, co-ordination with package
maintainers is needed, yada-yada.
* The ruby-http-parser.rb will FTBFS as mentioned in #989494. My old
patch for unstable should apply. That would be my job.
## Rework the patch
Revert the ABI break by reworking the patch to restore the previous
struct layout - while maintaining the purpose of the change: Storing a
ninth status bit. Hilko Bengen did a great job implementing this, and
also reported success with several tests.
Pros:
* Only http-parser needs an upload.
* External applications (built using Debian but not shipped by Debian)
continue to work. While this is not within our scope, it provides a
good service.
Cons:
* Requires testing on all architectures supported in buster. My job.
* Applications that access private fields still might break. Highly
unlikely to happen, and I have little mercy here.
* Applications and packages built *since* the ABI break will require
a rebuild since technically this is a second ABI break. For Debian,
the intersection with
https://release.debian.org/proposed-updates/oldstable.html
seems to be empty.
## Or ...
Still I am open for other ideas - my main goal is to find a sensible
fix for this issue.
Please advise how to proceed. I would like to see this handled as soon
as possible - knowing users out there encounter problems and will do so
until the next oldstable point release is not quite a pleasant
situation.
Personally I have a slight preference for the second ("rework the
patch") way, but that's not put in stone.
Kind regards,
Christoph
PS: Related, do you check autopkgtest of reverse dependencies as part
of a stable point release procedure? If not, please consider doing
so - although this time it would not have avoided the situation: Of
the list of packages, only libgit2 has an autopkgtest in buster,
and it still passes.
Related (not so) fun fact: Out of curiosity, I backported the
autopkgtest of the tang package locally, and it failed due to the
ABI breakage. Lesson learned: Do more autopkgtests!
¹ See
https://sources.debian.org/src/http-parser/2.8.1-1+deb10u1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch/#L223
and line 228
² Affected packages should be:
cargo
jabberd2
libgit2
libgit-raw-perl
ocserv
python-httptools
ruby-http-parser.rb
sssd
tang
tcpflow
Attachment:
signature.asc
Description: PGP signature