| Re: [oniro-dev] CVE status for 2.0 |
The list will work at the moment of generation. From that point on there will be new issues that aren't fixed. At this point we should get 2.0.1 that obsoletes 2.0.0. The security status file should then say that CVE-2022-xxxx is fixed in 2.0.1.
Now, if we're going to amend release notes of 2.0.1 to 2.0.0, this can work for the security status too.
I'll draft the needed scripting, this is just a different formatting of the output. 'Fixed in 2.0.1' is something we do not have directly yet. However, we can get it from the cve diff.
What we will need is to store the cve status at the release time. When we have that, we can get all the needed lists.
Regards,Marta
Kind regards,Marta
On Thu, 24 Nov 2022, 21:07 Andrei Gherzan, <andrei.gherzan@xxxxxxxxxx> wrote:
The release notes are for the 2.0.0 release which has a fixed version of the software components pool. So in theory having a static reference or an explicit list would make sense to me. So I'm up for a rst version of that report that we include in as a reference in the release notes. Would you be able to handle that?
From:Marta Rybczynska <marta.rybczynska@xxxxxxxxxx>To:Andrei Gherzan <andrei.gherzan@xxxxxxxxxx>Cc:onirocore developer discussions <oniro-dev@xxxxxxxxxxx>Date:2022-11-24 16:51:10Subject: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?
Kind regards,Marta
On Thu, 24 Nov 2022 at 17:03, Andrei Gherzan <andrei.gherzan@xxxxxxxxxx> wrote:
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.
From:Davide Ricci <davide.ricci@xxxxxxxxxx>To:Marta Rybczynska <marta.rybczynska@xxxxxxxxxx>Cc:onirocore developer discussions <oniro-dev@xxxxxxxxxxx>Date:2022-11-24 14:23:13Subject: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
Basically 171 issues with high severity as defined in https://docs.oniroproject.org/en/latest/security/cve_policy.html
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.
Marta
On Thu, 24 Nov 2022 at 15:16, Davide Ricci <davide.ricci@xxxxxxxxxx> wrote:
Stupid me,
An excel sheet was attached … I am reviewing it now.
D
From: oniro-dev <oniro-dev-bounces@xxxxxxxxxxx> On Behalf Of Davide Ricci
Sent: giovedì 24 novembre 2022 15:12
To: Marta Rybczynska <marta.rybczynska@xxxxxxxxxx>; onirocore developer discussions <oniro-dev@xxxxxxxxxxx>
Subject: Re: [oniro-dev] CVE status for 2.0
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
Dear all,
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)?
Kind regards,
Marta