On Fri, Oct 20, 2023 at 5:25 PM akuster808 <[email protected]> wrote: > > > > On 10/20/23 5:49 AM, Richard Purdie wrote: > > On Fri, 2023-10-20 at 10:56 +0200, Marta Rybczynska wrote: > >> While working on multiple aspects of security processes, one question > >> comes back frequently: which are the layers we support with those > >> processes? This has impact on the number of SECURITY.md I will be > >> submitting, of configuring any CVE synchronization work etc. > >> > >> The YP download page offers a download of poky. The release > >> documentation > >> https://docs.yoctoproject.org/migration-guides/index.html#release-information > >> nor the Release page (https://wiki.yoctoproject.org/wiki/Releases) > >> does not exactly list layers covered. > >> > >> Is it poky only? Poky + meta-openemedded? With some BSP layers? > >> > >> This has a general impact, because I assume that layers maintained > >> "externally" might have different security contacts, for example. > >> > >> Do we have that documented somewhere so that we can reference in the > >> security documentation? > > It will be for the layer maintainers to decide what to do about this > > file. From the Yocto Project perspective, we should cover bitbake, > > meta-yocto, openembedded-core (done) and yocto-docs. > > > > Looking over https://git.yoctoproject.org/ we should add one to meta- > > mingw as a tested layer. I've asked meta-gplv2 move to other layers. > > > > We should probably mention this issue to the other layer maintainers, > > maybe on the architecture list and perhaps also open a bug to make > > SECURITY.md a requirement for Yocto Project Compatible status? > Why? My layers only have upstream components. I would just tell an > individual to go to the upstream source and deal with those maintainers. > I bring no value being in the middle. > SECURITY.md is a (practically) standarized way of saying how to to contact a given project when someone has a non-public security issue. Saying in the file that you want to report upstream instead is a fair game, but won't work in two cases: - if the issue comes from locally maintained patches (eg. badly applied patch, a bug in a specific patch) - in a case of a multi-project embargo
Today the security researcher would probably mail the maintainer (if any easy to find in the README or so), and if they can't find any, just drop the info on a public mailing list (or IRC). My idea is to have a SECURITY.md and definitely, allow every layer to adjust to their needs. Hope that makes it clear, Marta
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1804): https://lists.openembedded.org/g/openembedded-architecture/message/1804 Mute This Topic: https://lists.openembedded.org/mt/102083332/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
