I had this commit ready for when the next EDK2 release were go out, which just happened: https://edk2.groups.io/g/devel/message/51502 Laszlo doesn't think it's worth the churn to rush to get this update into into 4.2-rc4: https://bugs.launchpad.net/qemu/+bug/1852196/comments/2 I agree with Laszlo, users shouldn't use the EDK2 bundled within QEMU in production, and should rather build it from source. However some distributions seem to rely on this convenience way to package EDK2, and few CVEs are fixed in this new release. So it might be worthwhile to get this into 4.2-rc4. Anyhow distributions don't use QEMU stable tag directly and backport patches, so if there is no other rc4 patch, we could skip this for after 4.2, as Laszlo originally planned. Philippe Mathieu-Daudé (1): roms/edk2: update submodule from edk2-stable201905 to edk2-stable201911 roms/edk2 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.21.0
Hi Phil, On 11/29/19 11:44, Philippe Mathieu-Daudé wrote: > I had this commit ready for when the next EDK2 release were go out, > which just happened: https://edk2.groups.io/g/devel/message/51502 > > Laszlo doesn't think it's worth the churn to rush to get this update > into into 4.2-rc4: https://bugs.launchpad.net/qemu/+bug/1852196/comments/2 > > I agree with Laszlo, users shouldn't use the EDK2 bundled within QEMU > in production, and should rather build it from source. However some > distributions seem to rely on this convenience way to package EDK2, > and few CVEs are fixed in this new release. So it might be worthwhile > to get this into 4.2-rc4. Anyhow distributions don't use QEMU stable > tag directly and backport patches, so if there is no other rc4 patch, > we could skip this for after 4.2, as Laszlo originally planned. > > Philippe Mathieu-Daudé (1): > roms/edk2: update submodule from edk2-stable201905 to > edk2-stable201911 > > roms/edk2 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > if we want to do this, then the above diffstat is not enough. - please evaluate whether we should do something like 9153b9d7401f ("roms/Makefile.edk2: update input file list for "pc-bios/edk2-licenses.txt"", 2019-06-14) - we need to rebuild the binaries: 3583cb29f28f ("pc-bios: refresh edk2 build artifacts for edk2-stable201905", 2019-06-14) - we should update the README file: 541617cad344 ("pc-bios: update the README file with edk2-stable201905 information", 2019-06-14) Thanks Laszlo
On Fri, Nov 29, 2019 at 1:10 PM Laszlo Ersek <lersek@redhat.com> wrote: > > Hi Phil, > > On 11/29/19 11:44, Philippe Mathieu-Daudé wrote: > > I had this commit ready for when the next EDK2 release were go out, > > which just happened: https://edk2.groups.io/g/devel/message/51502 > > > > Laszlo doesn't think it's worth the churn to rush to get this update > > into into 4.2-rc4: https://bugs.launchpad.net/qemu/+bug/1852196/comments/2 > > > > I agree with Laszlo, users shouldn't use the EDK2 bundled within QEMU > > in production, and should rather build it from source. However some > > distributions seem to rely on this convenience way to package EDK2, > > and few CVEs are fixed in this new release. So it might be worthwhile > > to get this into 4.2-rc4. Anyhow distributions don't use QEMU stable > > tag directly and backport patches, so if there is no other rc4 patch, > > we could skip this for after 4.2, as Laszlo originally planned. > > > > Philippe Mathieu-Daudé (1): > > roms/edk2: update submodule from edk2-stable201905 to > > edk2-stable201911 > > > > roms/edk2 | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > if we want to do this, then the above diffstat is not enough. > > - please evaluate whether we should do something like 9153b9d7401f > ("roms/Makefile.edk2: update input file list for > "pc-bios/edk2-licenses.txt"", 2019-06-14) > > - we need to rebuild the binaries: 3583cb29f28f ("pc-bios: refresh edk2 > build artifacts for edk2-stable201905", 2019-06-14) > > - we should update the README file: 541617cad344 ("pc-bios: update the > README file with edk2-stable201905 information", 2019-06-14) Oops sorry for missing all these points, I'll do them.
On 11/29/19 1:36 PM, Philippe Mathieu-Daudé wrote: > On Fri, Nov 29, 2019 at 1:10 PM Laszlo Ersek <lersek@redhat.com> wrote: >> On 11/29/19 11:44, Philippe Mathieu-Daudé wrote: >>> I had this commit ready for when the next EDK2 release were go out, >>> which just happened: https://edk2.groups.io/g/devel/message/51502 >>> >>> Laszlo doesn't think it's worth the churn to rush to get this update >>> into into 4.2-rc4: https://bugs.launchpad.net/qemu/+bug/1852196/comments/2 >>> >>> I agree with Laszlo, users shouldn't use the EDK2 bundled within QEMU >>> in production, and should rather build it from source. However some >>> distributions seem to rely on this convenience way to package EDK2, >>> and few CVEs are fixed in this new release. So it might be worthwhile >>> to get this into 4.2-rc4. Anyhow distributions don't use QEMU stable >>> tag directly and backport patches, so if there is no other rc4 patch, >>> we could skip this for after 4.2, as Laszlo originally planned. Since I was looking at the Debian packaging, I confirm 1/ Debian builds with -DNETWORK_HTTP_BOOT_ENABLE=TRUE -DSECURE_BOOT_ENABLE=TRUE: https://salsa.debian.org/qemu-team/edk2/blob/debian/debian/rules#L32 2/ The CVE fixes were indeed backported: https://salsa.debian.org/qemu-team/edk2/commit/e6630d57b >>> >>> Philippe Mathieu-Daudé (1): >>> roms/edk2: update submodule from edk2-stable201905 to >>> edk2-stable201911 >>> >>> roms/edk2 | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >> >> if we want to do this, then the above diffstat is not enough. >> >> - please evaluate whether we should do something like 9153b9d7401f >> ("roms/Makefile.edk2: update input file list for >> "pc-bios/edk2-licenses.txt"", 2019-06-14) >> >> - we need to rebuild the binaries: 3583cb29f28f ("pc-bios: refresh edk2 >> build artifacts for edk2-stable201905", 2019-06-14) >> >> - we should update the README file: 541617cad344 ("pc-bios: update the >> README file with edk2-stable201905 information", 2019-06-14) > > Oops sorry for missing all these points, I'll do them. >
© 2016 - 2024 Red Hat, Inc.