Bug#1025518: bullseye-pu: package capnproto/0.7.1-1+deb11u1
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 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: