Security Advisory - yasm - CVE-2021-33461: Propose mv yasm_git.bb yasm-native_git.bb
+ Anuj for meta-intel-qat use of
yasm-native.
On 2022-10-13 10:05, Randy MacLeod
wrote:
On 2022-10-13 02:33, Khem Raj wrote:
The yasm CVEs have come up again. Sigh. Upstream seems not to be interested in fixing CVEs: https://github.com/yasm/yasm/commits/master
We only need yasm-native (1) so does anyone object to
../Randy
meta-oe.git on master [$?]
-- # Randy MacLeod # Wind River Linux |
|
On 30 Mar 2023, at 22:56, Randy MacLeod via lists.openembedded.org <randy.macleod=windriver.com@...> wrote:
The yasm CVEs have come up again. Sigh.It seems like a better alternative would be to reduce the number of assemblers that are effectively unmaintained from two (nasm and yasm) to one (just nasm, as that’s in oe-core). Also marking all yasm/nasm dependencies as being x86-specific for obvious reasons. I’m a firm believer that we should be able to rebuild all packages on target, so native-specific tools should be a special case. The moment you make it native only is the moment you discover that someone was using nativesdk-yasm or on-target yasm to develop. Looking at your search, I think we might be able to just remove yasm entirely: meta-multimedia/recipes-multimedia/aom/aom_3.4.0.bbAccording to the AOM readme: "For x86 targets, yasm, which is preferred, or a recent version of nasm.” So that dependency should be specific to x86 targets, and could be nasm. meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bbThis is just the meta packagegroup that pulls in all of the recipes, for testing. ../meta-browser.git/meta-firefox/recipes-browser/firefox/firefox_68.9.0esr.bbOf course firefox wants yasm *and* nasm. Those should most likely be x86-specific to start with, and I’m guessing that’s related to: ../meta-browser.git/meta-firefox/recipes-browser/firefox/firefox/fixes/pre-generated-old-configure.patchSo that patch adds a huge configure script with no explanation and is at least five years old. We happily build ICU in core without yaml as we have GNU as. I expect that can be removed. ../meta-intel-qat.git/recipes-extended/qat/qat17_4.20.0-00001.bbI’d be surprised if a quick s/nasm/yasm/ didn’t fix this. The nasm compiler is more actively maintained _and_ maintained by and Intel employee after all… Ross |
|
On 2023-03-31 05:51, Ross Burton wrote:
Few assembler recipes: good idea!On 30 Mar 2023, at 22:56, Randy MacLeod via lists.openembedded.org <randy.macleod=windriver.com@...> wrote:The yasm CVEs have come up again. Sigh. Upstream seems not to be interested in fixing CVEs: https://github.com/yasm/yasm/commits/master We only need yasm-native (1) so does anyone object to moving this recipe to yasm-native_git.bb ? This small change would make it clear that images/tagets/machines are not _directly_ vulnerable due to the fuzzing errors people are generating which result in CVEs.It seems like a better alternative would be to reduce the number of assemblers that are effectively unmaintained from two (nasm and yasm) to one (just nasm, as that’s in oe-core). Also marking all yasm/nasm dependencies as being x86-specific for obvious reasons. I’m a firm believer that we should be able to rebuild all packages on target, so native-specific tools should be a special case. The moment you make it native only is the moment you discover that someone was using nativesdk-yasm or on-target yasm to develop. Yes, it's best to keep the recipe working for both -native and target. Looking at your search, I think we might be able to just remove yasm entirely:meta-multimedia/recipes-multimedia/aom/aom_3.4.0.bb 18:DEPENDS = " yasm-native"According to the AOM readme: "For x86 targets, yasm, which is preferred, or a recent version of nasm.” So that dependency should be specific to x86 targets, and could be nasm.meta-oe/recipes-core/packagegroups/packagegroup-meta-oe.bb 310: yasm \This is just the meta packagegroup that pulls in all of the recipes, for testing.../meta-browser.git/meta-firefox/recipes-browser/firefox/firefox_68.9.0esr.bb 8: yasm-native nasm-native unzip-native \Of course firefox wants yasm *and* nasm. Those should most likely be x86-specific to start with, and I’m guessing that’s related to:../meta-browser.git/meta-firefox/recipes-browser/firefox/firefox/fixes/pre-generated-old-configure.patch 8213:+ { echo "configure: error: Building ICU requires either yasm or a GNU assembler. If you do not have either of those available for this platform you must use --without-intl-api" 1>&2; echo "configure: error: Building ICU requires either yasm or a GNU assembler. If you do not have either of those available for this platform you must use --without-intl-api" 1>&5; exit 1;So that patch adds a huge configure script with no explanation and is at least five years old. We happily build ICU in core without yaml as we have GNU as. I expect that can be removed. Let's hope so and Archana and I can take a look.
'everybody expects the blink rendering engine' camp. If Martin doesn't have any plans to update firefox, it might become a weekend project. ../meta-intel-qat.git/recipes-extended/qat/qat17_4.20.0-00001.bb 10:DEPENDS += "boost udev zlib openssl yasm-native"I’d be surprised if a quick s/nasm/yasm/ didn’t fix this. The nasm compiler is more actively maintained _and_ maintained by and Intel employee after all…
Ah, I didn't know that the nasm maintainer is an INTC geek, but
Thanks Ross. ../Randy
Ross
-- # Randy MacLeod # Wind River Linux |
|
Martin Jansa
On Fri, Mar 31, 2023 at 8:43 PM Randy MacLeod <randy.macleod@...> wrote:
I'm in the "I wish I didn't include it in my OE build-time benchmark" camp :). I've never used OE built firefox and don't plan to use it in future. And I don't plan to update it, in worst case I'll have to spent bare-minimal time to make it build-able again just to measure how much slower it builds with newer rust. |
|