Control: tag -1 moreinfo On Mon, Dec 05, 2022 at 11:22:51PM -0800, tony mancill wrote: > 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.
This doesn't immediately make any of us enthusiastic, it has to be said... Can we get the proposed debdiff at least please? The hazards are: - ftbfs in the rdeps in stable - much reduced testing of proposed-updates vs. for example sid/testing > 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 laminar in particular doesn't seem to have much maintainer attention. If there are problems with the rdeps on rebuild are you going to be in a position to resolve them? > [ 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. An abundance of caution? Otherwise the statements seem at odds with each other. > If this is not amenable to stable-proposed-updates, would you recommend > backports? I'm not sure a transition in backports is going to be well received either. Let's start with the debdiff and at least know what we're looking at. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
