On 2023-07-18 18:32, Steve Sakoman wrote:
On Tue, Jul 18, 2023 at 11:49 AM Randy MacLeod
<[email protected]> wrote:
Add Kai,
On 2023-07-14 18:32, Steve Sakoman via lists.openembedded.org wrote:
From: Yogita Urade<[email protected]>
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<[email protected]>
Signed-off-by: Steve Sakoman<[email protected]>
---
.../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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184662):
https://lists.openembedded.org/g/openembedded-core/message/184662
Mute This Topic: https://lists.openembedded.org/mt/100151225/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
