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
