Package: release.debian.org Severity: normal Tags: bullseye User: release.debian.org@packages.debian.org Usertags: pu X-Debbugs-Cc: capnproto@packages.debian.org Control: affects -1 + src:capnproto Dear Release Team, This is a bit of an odd one... I have contacted the Security Team and they have recommended that this go through stable-proposed-updates. CVE-2022-46149 [1] is a recently announced vulnerability in the capnproto [2] package that impacts the versions available in oldstable and stable (0.7.0) and the upcoming bookworm release. As the upstream author notes in [3], the issue is present in inlined code, thus applications built against capnproto must be rebuilt against the patched version. The issue for unstable and bookworm is being addressed via an upload to experimental [4] and a subsequent transition [5]. Easy enough... For stable (and old-stable), we need to introduce 0.7.1, a new upstream version that generates a (new) libcapnp-0.7.1 binary package to address the vulnerability. Once those are present in the archive, we can trigger rebuilds of the reverse dependencies. At this time I am asking for bullseye. [ Reason ] This is to address CVE-2022-46149 [1]. [ Impact ] Packages built with capnproto in bullseye will remain potentially vulnerable to the CVE. [ Tests ] I have built the package in a clean bullseye chroot and then used ratt to rebuilt the (8) bullseye r-deps: - clickhouse_18.16.1+ds-7.2 - harvest-tools_1.3-6 - laminar_1.0-3 - librime_1.6.1+dfsg1-1 - mash_2.2.2+dfsg-2 - mir_1.8.0+dfsg1-18 - rr_5.4.0-2 - sonic-visualiser_4.2-1 [ Risks ] The upstream author has stated that there are no known vulnerable applications, yet advises that all capnproto users rebuild their applications using patched versions of capnproto. The patch is simple enough, but obviously the transition process is not. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in stable [x] the issue is verified as fixed in unstable [ Changes ] The upstream patch for this issue is small [6], but upstream used a slightly newer version of autoconf when packaging 0.7.1 than was used in 0.7.0, and so the debdiff between the source versions ends up with a lot of boilerplate autoconf diff. The only change to the Debian packaging is the requisite SONAME bump to generate the 0.7.1 library package for transition of the r-deps. [ Other info ] My email exchange with the Security Team included Salvatore Bonaccorso and Moritz Muehlenhoff. If this works and is amenable, old-stable would be next. If this is not amenable to stable-proposed-updates, would you recommend backports? Thank you for considering this request! tony [1] https://nvd.nist.gov/vuln/detail/CVE-2022-46149 [2] https://tracker.debian.org/pkg/capnproto [3] https://github.com/capnproto/capnproto/security/advisories/GHSA-qqff-4vw4-f6hx [4] https://tracker.debian.org/news/1393214/accepted-capnproto-092-1-source-amd64-into-experimental/ [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025449 [6] https://github.com/capnproto/capnproto/commit/14adbb11e98db714f09c30b8c40415325a55157a
Attachment:
signature.asc
Description: PGP signature