Bug#1025518: bullseye-pu: package capnproto/0.7.1-1+deb11u1
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 jmw@debian.org
Debian Developer http://people.debian.org/~jmw
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Reply to: