[Buildroot] [External] Re: Gsoc Interest : Follow upstream updates and CVEs of packages

[Matthew Weber]

Manas,

On Mon, Mar 11, 2019 at 9:53 AM Matthew Weber <matthew.weber at collins.com> wrote:
>
> On Thu, Mar 7, 2019 at 1:39 AM Manas Mangaonkar
> <manasmangaonkar at gmail.com> wrote:
> >
> >
> >
> > On Wednesday, March 6, 2019, Matthew Weber <matthew.weber at collins.com> wrote:
> > > Manas,
> > >
> > > On Wed, Mar 6, 2019 at 2:55 AM Manas Mangaonkar
> > > <manasmangaonkar at gmail.com> wrote:
> > >>
> > >> Hi,
> > >>
> > >> My Name is Manas  [IRC: Pac23/Pac23xyz] i am a CE undergrad at the University of Mumbai,Came across the Following Upstream project and would love to work on it as part of Gsoc.
> > >>
> > >> I discussed this on the IRC and was told to ping here,afaik there already exists some code for this,can someone kindly link to the codebase/repo. I have seen some of it in the mailing list archive.
> > >>
> > >
> > > I have been working a series to add CPE reporting to Buildroot so that
> > > a manifest could be produced with each build.  In the series [1], the
> > > [2] patch added the checking of CPE status in the pkg-stats script
> > > (this is the script with the new release monitoring hooks).  We did
> > > not look at the problem space of checking for valid CVE against each
> > > the CPE.  I do wonder if adding the CPE id and CVE tracking directly
> > > to release monitoring site would have more value then to our pkg-stats
> > > or a new script.  Then a report could be ran at the release-monitoring
> > > site level to list open CVE on the Buildroot project.
> > >
> > > I do owe a refresh of [1] as it has been awhile since I rebased and
> > > sent a new version.
> > >
> > > Matt
> > >
> > > [1] http://patchwork.ozlabs.org/project/buildroot/list/?series=71318&state=*
> > > [2] http://patchwork.ozlabs.org/patch/985550/
> > >
> >
> >
> > Hi,
> >
> > So I have couple of super basic questions
> >
> > I noticed the release site has a api, how do you plan to get this to integrate directly with the site?
> >
>
> I have not explored that and was just suggesting it as a collaboration
> that could be a path.  Another option for any CVE or other bug
> tracking could be something like
> https://www.owasp.org/index.php/OWASP_Dependency_Track_Project  .
>
> > What's the full form or significance of cpe? First time working with buildroot.
>
> It's one of the industry ways to label a package item
> (https://csrc.nist.gov/projects/security-content-automation-protocol/specifications/cpe/).
> Not Buildroot specific and also not comprehensive (see OWASP for a
> list of many feeds/sources that could be concentrated).
>
> >
> > Originally I had drummed up a workflow of having a db that tracks nvd, sends emails of each breakage, update, and keeps track using our own db but using release monitoring sounds good.I guess
> >
> > Also having something that automatically indicates upstream of breakages on our end due to upstream issues will be nice.Soemthing like automated issue filing on GitHub using their hooks.
>
> With respect to what breakages?  Test builds or versions not listed in
> NVD?   I don't think a NVD only approach makes sense.  It could be a
> start but there are tools that centralize feeds.  I'd suggest
> reviewing Debian, Gentoo, and other distros approaches and tooling for
> this situation.
>

Just noticed we dropped upstream on this email thread.  Adding them
back, would you mind responding again to the above items like you did
this morning?