On Tue, Jul 25, 2023 at 10:19:50PM +0100, Jonathan Wiltshire wrote: > 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.
Ping? -- Jonathan Wiltshire [email protected] Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
