On Tue, Jul 18, 2023 at 11:49 AM Randy MacLeod <randy.macleod@windriver.com> wrote:Add Kai, On 2023-07-14 18:32, Steve Sakoman via lists.openembedded.org wrote: From: Yogita Urade <yogita.urade@windriver.com> Dmidecode before 3.5 allows -dump-bin to overwrite a local file. This has security relevance because, for example, execution of Dmidecode via Sudo is plausible. References: https://nvd.nist.gov/vuln/detail/CVE-2023-30630 https://lists.nongnu.org/archive/html/dmidecode-devel/2023-04/msg00016.html https://lists.nongnu.org/archive/html/dmidecode-devel/2023-04/msg00017.html Signed-off-by: Yogita Urade <yogita.urade@windriver.com> Signed-off-by: Steve Sakoman <steve@sakoman.com> --- .../dmidecode/CVE-2023-30630_1.patch | 237 ++++++++++++++++++ .../dmidecode/CVE-2023-30630_2.patch | 81 ++++++ .../dmidecode/CVE-2023-30630_3.patch | 69 +++++ .../dmidecode/CVE-2023-30630_4.patch | 137 ++++++++++ Summary: I think this can merge but we should agree on how to handle dmidecode. Details: These changes work but it's bringing back 4 patches rather than bumping the version to 3.5 and picking up 2 patches. My conclusion is that it's okay but we should probably talk about how to maintain dmidecode since it just produces a bunch of programs for dumping HW DMI/SMBIOS info and doesn't provide a runtime ABI, we can probably update to 3.5 ( or even 3.6 when that's out). Do you agree Steve?You'll always get the same answer from me: no version bumps that implement new features/apis. Bug/security fixes only. If there is a strong case to be made for something outside this policy, it should go to the TSC for consideration. I don't want our stable branches to start resembling the kernel "stable" branches ... So, yes, I think we should merge this patch rather than version bump :-) Steve
Fine with me!
<snip>
There is no change to this commit and it will be merged so
read on only if you are interested in dmidecode maintenance and
my motivations in causing this bit of noise on the list. ;-)
I checked with the dmidecode upstream (1) about their versioning
scheme and if they
have considered having a structured release numbering scheme and
even a stable branch.
They said they increment versions at will and don't have a stable
branch other than latest release.
As Richard and Steve have said, we should be more conservative and
if we find that anyone needs
the additional hardware support that I was hoping to pick up, we
can back port patches.
Sorry for the noise,
../Randy
1)
https://lists.nongnu.org/archive/html/dmidecode-devel/2023-07/msg00006.html
-- # Randy MacLeod # Wind River Linux