That’s ok – it’s a given that maintenance is an ongoing activity – a static list against a tagged release is more proof that we know what’s inside and we have applied decisional criteria (release criteria) before releasing
Oniro, and such criteria are consistent and will be applied to future updates.
It’s about building trust in the process rather than claiming perfection.
Cheers
D
From: oniro-dev <oniro-dev-bounces@xxxxxxxxxxx>
On Behalf Of Marta Rybczynska
Sent: giovedì 24 novembre 2022 17:51
To: Andrei Gherzan <andrei.gherzan@xxxxxxxxxx>
Cc: onirocore developer discussions <oniro-dev@xxxxxxxxxxx>
Subject: Re: [oniro-dev] CVE status for 2.0
I'm wondering about the correct way to do so... as the CVE list is always changing. The one statically in the release notes will be outdated immediately and we should be maintaining a dynamic one that is updated.
We *could* convert the scripting results to an RST file in fact... What do you think?
I reckon this is the only feasible way forward at this point. That means having a CVE report section in release notes and handle them as part of the maintenance process.
Subject:Re: [oniro-dev] CVE status for 2.0
I think we can only align with YP which is a bigger project (for now) than Oniro and if they gave up, I don’t think we’ll stand a chance as things stand to do
any better.
We want to capture decision and release status when it comes to CVEs in our release note – meaning – ideally we would have a pointer to this sheet hosted somewhere
with known / open / addressed CVEs present in what we’ll tag as 2.0.
D
From: Marta Rybczynska <marta.rybczynska@xxxxxxxxxx>
Sent: giovedì 24 novembre 2022 15:20
To: Davide Ricci <davide.ricci@xxxxxxxxxx>
Cc: onirocore developer discussions <oniro-dev@xxxxxxxxxxx>
Subject: Re: CVE status for 2.0
Most are due to incomplete database data/obscure kernel subsystems. I've hand reviewed some and it is confirmed. However, just fixing database is a big work.
YP gave up on that for the kernel.
Stupid me,
An excel sheet was attached … I am reviewing it now.
D
Since we are aware of the issues, we ought to try to fix the most sever ones – do we have the breakdown and know how many CVEs per CVSS severity class do we have?
Thanks
D
From: Marta Rybczynska <marta.rybczynska@xxxxxxxxxx>
Sent: giovedì 24 novembre 2022 14:30
To: Davide Ricci <davide.ricci@xxxxxxxxxx>; onirocore developer discussions <oniro-dev@xxxxxxxxxxx>
Subject: CVE status for 2.0
I have first results of CVE checks for the upcoming 2.0. For simplification, you have the details from the qemu x86-64 image (rootfs only, excluding SDK).
With the database of yesterday, we have 378 issues. Out of that:
4 at or above CVSSv3 9.0 (curl, libpam, 2xlinux)
122 at or above CVSSv3 7.5 (including the openssl issue that made the news, expat, python, dropbear)
Apart from the Linux kernel, most should go away with a kirkstone update.
The question is if we release like that or we spend time to fix issues above certain CVSS (like 9.0 or 8.0)?
|
