Re: [Qemu-devel] [ANNOUNCE] QEMU 4.1.0-rc3 is now available

[Marc-André Lureau]

Hi

On Fri, Aug 2, 2019 at 2:44 PM Peter Maydell <address@hidden> wrote:
>
> On Fri, 2 Aug 2019 at 11:31, Marc-André Lureau
> <address@hidden> wrote:
> >
> > Hi
> >
> > On Fri, Aug 2, 2019 at 2:19 PM Peter Maydell <address@hidden> wrote:
> > >
> > > On Wed, 31 Jul 2019 at 19:17, Peter Maydell <address@hidden> wrote:
> > > >
> > > > On Wed, 31 Jul 2019 at 19:05, Philippe Mathieu-Daudé <address@hidden> 
> > > > wrote:
> > > > >
> > > > > >   Unless there are any release critical bugs discovered, this
> > > > > >   will be the last release candidate before final release of 4.1.0
> > > > > >   on the 6th August. Otherwise we'll do an rc4 and release on
> > > > > >   the 13th August.
> > > > >
> > > > > We forgot to update the slirp submodule :(
> > > >
> > > > Were there any RC bugs in it?
> > >
> > > Ping! If we want to put this into an rc4 can we have a
> > > pull request with a justification on the mailing list
> > > sooner rather than later, please?
> >
> > It's about a CVE-2019-14378, that Samuel fixed a few days ago:
> > https://gitlab.freedesktop.org/slirp/libslirp/commit/126c04acbabd7ad32c2b018fe10dfac2a3bc1210
> >
> > Imho, it's not a regression, so no need to delay qemu release.
>
> Yeah, but it is a security bug, presumably, given the CVE.
> https://access.redhat.com/security/cve/cve-2019-14378
> suggests the consequences are more than just a DoS.
> I think that merits including in the release.

I don't think non-regression deserve rc4, it could be a stable update.

And Samuel probably thought the same, since he didn't update the submodule.


> > I would encourage distributions to switch to the shared library
> > version instead, so they can more easily and quickly apply updates.
>
> Well, that might be nice eventually, but it's not where we are
> right now. QEMU is the primary consumer of the slirp library
> and we ship a copy of it, so we need to coordinate about releases
> and potential security issues.

fwiw, Fedora rawhide qemu links to libslirp already, and it is also
possible to do it on f30 and earlier.

podman uses slirp4netns, which also embeds an old copy of slirp.

With the upcoming libslirp release, we should have what is necessary
to make slirp4netns link to libslirp.

I hope in the near future we will have better alternatives, such as
vpnkit or netstack or other.

> Could you send out a pull request which updates our slirp
> submodule to a version which just has that CVE fix on top
> of what we already have (slirp commit f0da6726207b740f6),
> please?

According to MAINTAINERS, this is for Samuel to take care of. But I'll
do it if he ask me.

-- 
Marc-André Lureau