[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#996997: marked as done (buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster"))

Your message dated Fri, 10 Dec 2021 22:17:20 +0000
with message-id <E1mvoCe-000DW3-SE@fasolo.debian.org>
and subject line Bug#996997: fixed in http-parser 2.8.1-1+deb10u2
has caused the Debian Bug report #996997,
regarding buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
996997: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996997
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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


--- End Message ---
--- Begin Message --- 
Source: http-parser
Source-Version: 2.8.1-1+deb10u2
Done: Christoph Biedl <debian.axhn@manchmal.in-ulm.de>

We believe that the bug you reported is fixed in the latest version of
http-parser, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 996997@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christoph Biedl <debian.axhn@manchmal.in-ulm.de> (supplier of updated http-parser package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sun, 31 Oct 2021 23:50:09 +0100
Source: http-parser
Architecture: source
Version: 2.8.1-1+deb10u2
Distribution: buster
Urgency: medium
Maintainer: Christoph Biedl <debian.axhn@manchmal.in-ulm.de>
Changed-By: Christoph Biedl <debian.axhn@manchmal.in-ulm.de>
Closes: 996460 996939 996997
Changes:
 http-parser (2.8.1-1+deb10u2) buster; urgency=medium
 .
   * Fix ABI breakage introduced by accident in 2.8.1-1+deb10u1.
     Many thanks to Hilko Bengen.
     Closes: #996460, #996939, #996997
Checksums-Sha1:
 832abd09ed32a27eb52374d04251038a019907c9 2008 http-parser_2.8.1-1+deb10u2.dsc
 da14a2cdad872ca9aab8baaa0f3816ffdae1ab8d 9072 http-parser_2.8.1-1+deb10u2.debian.tar.xz
 5d78dbc15bf1d8cf1fa628d0219c01fab64afb5a 6082 http-parser_2.8.1-1+deb10u2_armel.buildinfo
Checksums-Sha256:
 4c002f09ea24001ff86dd50d09fd298f63a95a3388aec504d9a1408c34647218 2008 http-parser_2.8.1-1+deb10u2.dsc
 b577d28b8a1fadf23de3cd8d77e293abe8a399cc87c9a0b4a5997a3140fd37c8 9072 http-parser_2.8.1-1+deb10u2.debian.tar.xz
 d6699cd9421ace72101ff36778baab33deb421eb22d83e94ad97ed9131c190d9 6082 http-parser_2.8.1-1+deb10u2_armel.buildinfo
Files:
 6332a9adff4d19640f2c45a842a6b87e 2008 libs optional http-parser_2.8.1-1+deb10u2.dsc
 c53d0599f67f17b6cd63328d9daadff8 9072 libs optional http-parser_2.8.1-1+deb10u2.debian.tar.xz
 3429e3f81ba659571eb4c7afd18ed22f 6082 libs optional http-parser_2.8.1-1+deb10u2_armel.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEWXMI+726A12MfJXdxCxY61kUkv0FAmGnwHwACgkQxCxY61kU
kv1KZxAAlf+m57zBJUhtFRbHlvWb8URmFZdmUAKiLizangSEglc2NaZLU7k4Tqii
kYi79Qj2PuaZ0ZZrlRBd9so6Vtfj/FEn1dZzMy2e5QBlXjPsDStRufvYj2aD9VeW
d4+OsRfctt9E1VyO3c238VcCmZfVRuPRHtdsJODN8b8XDp9QzjoKijKIDBZhfpvQ
CbHgBhYwVocXOqEuEafBgExaOPBRvk1cJJQNCo2inalb7W5Agz8cUnkESEw3JLT/
bRXs5L1oifClJO4q5xckQ2NPjXvJgDlYbufuDPjuQYrifG2bzlq7Xwx9/l7JHh0K
nl1WfScokX5j9KwBeYuBKiiVmo8syVUVZLi8li10c+8FOuqxz5YCu3+RQKpKTy+m
onWCMli8EAPbyILixDgOlzYm7m4Pa//UWsDKMK4Q3U4RMVDXO3Q/V5sJaCuccWG0
JfKMjJrmwPsSvzizWr7efoaL0HhAochAtgclpyFnbcJLnZByPFHe3RpcGwD63HAW
iVnkQdy6l9vs26zj2NKpbV0kMe5zb9OhMJo8AtU0a/0LOwcNQzt3iqZ6yhusMIUT
Xt5283RC4gRvNdAlDD97ILFuhfDwZhZXRhSVOYS4Y1AetaR5JwQGGWc9JjsFVSqO
bJ62RzloqPtWkCnHP+bb7w44H3pa3BOiGlUSL0a/uY7Fpq2Xf+g=
=R/XX
-----END PGP SIGNATURE-----

--- End Message ---
Reply to: