Package: release.debian.org Severity: normal Tags: buster User: release.debian....@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
signature.asc
Description: PGP signature
