On Wed, Sep 13, 2023 at 6:28 PM Mark Hatle <mark.ha...@kernel.crashing.org> wrote: > >> * Visibility of the security work of the YP > >> > >> There is much work on security in the YP, but it lacks visibility. > > > > Is there a common nexus for this work? eg. do most of the folks who are > > doing security work tend to congregate on the security sublist? > > Security means different things to different people. I.e. > > 1) Secure design > - Is the system designed to have security services, if so are the defaults > setup to both be appropriate and also functional? > > 2) Additional security software > - i.e. meta-security, what additional software can be available to enhance > security design/implementation of the system > > 3) Security (bug) response > - This is where I see a lack of common nexus for work. We don't have a > good > place to discuss CVE specific information. Now the question really is, should > we have a separate space. CVEs are just bugs. Bugs are usually worked on via > the main mailing list. So that argument says no, we shouldn't have a special > list. BUT the perception is CVEs are "special", so maybe a list specifically > to > discuss the ramifications of a CVE, fix/mitigation strategy or similar would > make sense -- keeping actual bug fixes to the main mailing list? >
It might e interesting to have opinion on people who are submitting CVE fixes... Would keeping that discussion in a separate place be helpful? > >> > >> * SRTool > >> > >> We might decide to use it again. It allows one to do much but requires > >> constant commitment. > > > > I think I passed over the wiki pages and presentations for SRTool once, > > a while ago. But I didn't pay much attention at the time because it > > wasn't clear *what it did*. > > > > After reviewing it again, I think it might be the kind of tooling I've > > been searching for to help my team coordinate our CVE response work. > > I'll test it out and see if it is something I can use/contribute towards. > > SR Tool requires constant feeding and maintenance from staff, at a minimum to > do > initial triage work. This means we need a small group of individuals who can > take the new items (and changes to existing) and comment on a regular (daily) > basis. This is the part we've not been terribly successful in the past. > People > are great at delivering patches, but trying to do the proactive (before > cve-checker) evaluation of CVEs is an activity that often feels like busy > work, > so it's easy to get behind on and never catch up. > > I would love to see the project use SR Tool to manage CVE information, > (bugzilla > is where the bugs need to be managed and processed), as well as cve-checker to > be able to continue to feed information or what we believe the current state > of > things are. This combination would give us per-emptive notification of new > items (SR-Tool), and late validation of items (cve-checker) on the perceived > state of things. SRTools code base (https://git.yoctoproject.org/srtool) has seen no changes for 4 years. If we decide to use, we'll also need to maintain the tool. Is Windriver going to update the fork? David (adding in copy), do you have any information? Otherwise we would need to maintain our version, and update to the code to take into account how the world have changed. For example, with the CVE v5 JSON, using the CVE database directly for the feed of new CVE list makes more sense than using NVD, for example. For the reason of performance and delay. When SRTool was developed, that data wasn't available. Cheers, Marta
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187660): https://lists.openembedded.org/g/openembedded-core/message/187660 Mute This Topic: https://lists.openembedded.org/mt/101340097/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
