Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")
On Fri, 2021-10-22 at 09:18 +0200, Christoph Biedl wrote:
> 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.
>
Ack. :-(
>
> # Solutions
>
> After some discussion with Hilko Bengen (Cc:'ed) I can see two ways
> out of this:
>
[...]
> ## 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.
>
This seems like the best option if we can, although I realise it does
break from our usual desire to use a patch as-implemented in later
versions.
Do you already have a proposed new upload / debdiff?
> 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.
>
[...]
> 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.
>
>From the information you've provided above, I think I agree. We could
release the update via buster-updates to make it available to users in
advance of 10.12.
> 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.
We did discuss this on IRC briefly, but for the record - there's a
britney instance that produces "excuses" for p-u and o-p-u, including
scheduling autopkgtests via ci.d.n. The results show up on our tracking
pages and we (mainly Paul; thanks!) investigate any failures raised to
determine if they resulted from the proposed update and, if so, what to
do about that.
Regards,
Adam
Reply to: