[Buildroot] Google Summer of Code 2018 ?

[Buildroot] Google Summer of Code 2018 ?

[Thomas Petazzoni]

Hello,

For information, organizations can apply for GSoC 2018 until January
23, so there is less than a week left to apply. The questions are: do
we want to apply? And if yes, for what topics?

Looking at https://elinux.org/Buildroot:GSoC2017Ideas:

 - Reproducible builds. While some initial work was done, there is
   definitely a lot more that could be done.

 - Testing infrastructure: the runtime testing infrastructure was
   added in the mean time. Writing more tests and extending the
   infrastructure is still needed though.

 - Relocatable SDK: this topic is pretty much solved IMO, so this topic
   is no longer relevant.

 - Follow upstream updates and CVEs of packages. I think this topic is
   still relevant, and IMO is the most interesting topic.

 - Support for LLVM: an intern from Smile (France) just announced that
   he will be working on this topic during the next months, so I don't
   see the point of having a GSOC on the same topic.

 - Support new languages and complete existing ones. I'm not sure about
   this one:
   * For NodeJS, I'm not sure we want to have zillions of packages for
     the different NodeJS modules
   * The Go package infrastructure has been resubmitted, and is
     actively being pushed by Angelo
   * The Rust support is actively being pushed by Eric
   So I don't know if there's enough things left to do for this project
   idea.

Any other idea of what's missing in Buildroot, or that could be
improved ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Google Summer of Code 2018 ?

[Matthew Weber]

On Wed, Jan 17, 2018 at 2:52 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> For information, organizations can apply for GSoC 2018 until January
> 23, so there is less than a week left to apply. The questions are: do
> we want to apply? And if yes, for what topics?
>
> Looking at https://elinux.org/Buildroot:GSoC2017Ideas:
>
>  - Reproducible builds. While some initial work was done, there is
>    definitely a lot more that could be done.
>
>  - Testing infrastructure: the runtime testing infrastructure was
>    added in the mean time. Writing more tests and extending the
>    infrastructure is still needed though.
>
>  - Relocatable SDK: this topic is pretty much solved IMO, so this topic
>    is no longer relevant.
>
>  - Follow upstream updates and CVEs of packages. I think this topic is
>    still relevant, and IMO is the most interesting topic.

I'd second that this is an interesting one (even just a manual
approach to start with).  ie. Minimally having our legal-info (or a
new cpe-info) generate CPE compliant tags for our packages would be a
great addition.  Then those lists can be fed into various tools.

>
>  - Support for LLVM: an intern from Smile (France) just announced that
>    he will be working on this topic during the next months, so I don't
>    see the point of having a GSOC on the same topic.
>
>  - Support new languages and complete existing ones. I'm not sure about
>    this one:
>    * For NodeJS, I'm not sure we want to have zillions of packages for
>      the different NodeJS modules
>    * The Go package infrastructure has been resubmitted, and is
>      actively being pushed by Angelo
>    * The Rust support is actively being pushed by Eric
>    So I don't know if there's enough things left to do for this project
>    idea.
>
> Any other idea of what's missing in Buildroot, or that could be
> improved ?
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot



-- 
Matthew L Weber / Pr Software Engineer
Airborne Information Systems / Security Systems and Software / Secure Platforms
MS 131-100, C Ave NE, Cedar Rapids, IA, 52498, USA
www.rockwellcollins.com

Note: Any Export License Required Information and License Restricted
Third Party Intellectual Property (TPIP) content must be encrypted and
sent to matthew.weber at corp.rockwellcollins.com.

[Buildroot] Google Summer of Code 2018 ?

[Thomas Petazzoni]

Hello,

On Wed, 17 Jan 2018 16:50:13 -0600, Matthew Weber wrote:

> >  - Follow upstream updates and CVEs of packages. I think this topic is
> >    still relevant, and IMO is the most interesting topic.  
> 
> I'd second that this is an interesting one (even just a manual
> approach to start with).  ie. Minimally having our legal-info (or a
> new cpe-info) generate CPE compliant tags for our packages would be a
> great addition.  Then those lists can be fed into various tools.

Could you describe in more details what are those "CPE compliant tags" ?

Ideally, what I'd like to see is a script that generates a webpage
showing for each package the current version in Buildroot, the latest
upstream version available, and whether the current version in
Buildroot is affected by CVEs. Optionally, such a script could be used
combined with the DEVELOPERS file to generate some notifications to
Buildroot developers that the packages they are looking after should
probably be upgraded (with a weekly notification, or something like
that).

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Google Summer of Code 2018 ?

[Matthew Weber]

Thomas,

On Thu, Jan 18, 2018 at 1:51 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> Hello,
>
> On Wed, 17 Jan 2018 16:50:13 -0600, Matthew Weber wrote:
>
> > >  - Follow upstream updates and CVEs of packages. I think this topic is
> > >    still relevant, and IMO is the most interesting topic.
> >
> > I'd second that this is an interesting one (even just a manual
> > approach to start with).  ie. Minimally having our legal-info (or a
> > new cpe-info) generate CPE compliant tags for our packages would be a
> > great addition.  Then those lists can be fed into various tools.
>
> Could you describe in more details what are those "CPE compliant tags" ?
>
> Ideally, what I'd like to see is a script that generates a webpage
> showing for each package the current version in Buildroot, the latest
> upstream version available, and whether the current version in
> Buildroot is affected by CVEs. Optionally, such a script could be used
> combined with the DEVELOPERS file to generate some notifications to
> Buildroot developers that the packages they are looking after should
> probably be upgraded (with a weekly notification, or something like
> that).
>

NIST maintains the "official" Common Platform Enumeration (CPE)
Dictionary.  It is basically a big xml file that is a collection of
COTS systems, software, and hardware available for commercial and
personal use.  The dictionary (defined by this xsd) contains tens of
thousands of CPEs (defined by this xsd).  When our security team does
CVE evaluations for a platform, we upstream any missing CPEs to NIST.
They run the suggestions through a normalization process checking for
duplicates, spelling, format, etc.  In the end, NIST updates the CPE
list every 24 hours with new inclusions.

If the buildroot legal-info (or something similar) could produce the
accurate CPE information for each specific software version in the
list, that data could easily be used to query the Mitre CVE database
or anything else that conforms to Security Content Automation Protocol
(SCAP).  This is easier said that done of course.  With buildroot
being on the bleeding edge for many software packages that can be
included, the CPE dictionary often hasn't caught up to the versions
included in buildroot.  For a specific company's case, that is
rectified by a security team upstreaming new CPEs to NIST.

An example of a recent CPE identifier that we upstreamed to NIST is:
cpe:2.3:a:bzip:bzip2:1.0.5:*:*:*:*:*:*:*  NIST link

We definitely agree with the vision of ultimately having a list of
CVEs available for a buildroot tag or even on demand.  This would most
easily be accomplished by connecting the "webpage" to a vulnerability
site that allows direct query of their vulnerability database via and
API.  Then for specific users, having a generated CPE list would allow
them to plug them into paid/corporate vulnerability management
database(s).  Having an accurate list of CPEs is the cornerstone for
buildroot users to be able to design their own process and generally
access current states of upstream.

As far as a concept.  We don't see any way to get the CPE information
into buildroot other than adding something to the package makefile
that the community maintains.  Sometimes the name of the package in
buildroot does not match the product name field in the CPE entry.  A
vendor field would have to be added.  The version field in buildroot
might be ok.  NIST has shown that having a community of engineers
trying to be consistent is a challenge, possibly some sort of
normalization would be necessary.  I don't know.

A CPE name then could be assembled in most cases by doing something like this:

LIBFUSE_VERSION = 2.9.7
LIBFUSE_SOURCE = fuse-$(LIBFUSE_VERSION).tar.gz
LIBFUSE_SITE = https://github.com/libfuse/libfuse/releases/download/fuse-$(LIBFUSE_VERSION)
+ LIBFUSE_VENDOR = libfuse_project
LIBFUSE_LICENSE = GPL-2.0, LGPL-2.1
LIBFUSE_LICENSE_FILES = COPYING COPYING.LIB
LIBFUSE_INSTALL_STAGING = YES
LIBFUSE_DEPENDENCIES = $(if $(BR2_PACKAGE_LIBICONV),libiconv)
LIBFUSE_CONF_OPTS = \
        --disable-example \
        --enable-lib \
        --enable-util

+ LIBFUSE_CPE =
cpe:2.3:a:$(LIBFUSE_VENDOR):<packagename>:$(LIBFUSE_VERSION):*:*:*:*:*:*:*



Matt

[Buildroot] Google Summer of Code 2018 ?

[Matthew Weber]

Ron,

On Thu, Jan 18, 2018 at 9:52 AM, Matthew Weber
<matthew.weber@rockwellcollins.com> wrote:
> Thomas,
>
> On Thu, Jan 18, 2018 at 1:51 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>>
>> Hello,
>>
>> On Wed, 17 Jan 2018 16:50:13 -0600, Matthew Weber wrote:
>>
>> > >  - Follow upstream updates and CVEs of packages. I think this topic is
>> > >    still relevant, and IMO is the most interesting topic.
>> >
>> > I'd second that this is an interesting one (even just a manual
>> > approach to start with).  ie. Minimally having our legal-info (or a
>> > new cpe-info) generate CPE compliant tags for our packages would be a
>> > great addition.  Then those lists can be fed into various tools.
>>
>> Could you describe in more details what are those "CPE compliant tags" ?
>>
>> Ideally, what I'd like to see is a script that generates a webpage
>> showing for each package the current version in Buildroot, the latest
>> upstream version available, and whether the current version in
>> Buildroot is affected by CVEs. Optionally, such a script could be used
>> combined with the DEVELOPERS file to generate some notifications to
>> Buildroot developers that the packages they are looking after should
>> probably be upgraded (with a weekly notification, or something like
>> that).
>>
>
> NIST maintains the "official" Common Platform Enumeration (CPE)
> Dictionary.  It is basically a big xml file that is a collection of
> COTS systems, software, and hardware available for commercial and
> personal use.  The dictionary (defined by this xsd) contains tens of
> thousands of CPEs (defined by this xsd).  When our security team does
> CVE evaluations for a platform, we upstream any missing CPEs to NIST.
> They run the suggestions through a normalization process checking for
> duplicates, spelling, format, etc.  In the end, NIST updates the CPE
> list every 24 hours with new inclusions.
>
> If the buildroot legal-info (or something similar) could produce the
> accurate CPE information for each specific software version in the
> list, that data could easily be used to query the Mitre CVE database
> or anything else that conforms to Security Content Automation Protocol
> (SCAP).  This is easier said that done of course.  With buildroot
> being on the bleeding edge for many software packages that can be
> included, the CPE dictionary often hasn't caught up to the versions
> included in buildroot.  For a specific company's case, that is
> rectified by a security team upstreaming new CPEs to NIST.
>
> An example of a recent CPE identifier that we upstreamed to NIST is:
> cpe:2.3:a:bzip:bzip2:1.0.5:*:*:*:*:*:*:*  NIST link
>
> We definitely agree with the vision of ultimately having a list of
> CVEs available for a buildroot tag or even on demand.  This would most
> easily be accomplished by connecting the "webpage" to a vulnerability
> site that allows direct query of their vulnerability database via and
> API.  Then for specific users, having a generated CPE list would allow
> them to plug them into paid/corporate vulnerability management
> database(s).  Having an accurate list of CPEs is the cornerstone for
> buildroot users to be able to design their own process and generally
> access current states of upstream.
>
> As far as a concept.  We don't see any way to get the CPE information
> into buildroot other than adding something to the package makefile
> that the community maintains.  Sometimes the name of the package in
> buildroot does not match the product name field in the CPE entry.  A
> vendor field would have to be added.  The version field in buildroot
> might be ok.  NIST has shown that having a community of engineers
> trying to be consistent is a challenge, possibly some sort of
> normalization would be necessary.  I don't know.
>
> A CPE name then could be assembled in most cases by doing something like this:
>
> LIBFUSE_VERSION = 2.9.7
> LIBFUSE_SOURCE = fuse-$(LIBFUSE_VERSION).tar.gz
> LIBFUSE_SITE = https://github.com/libfuse/libfuse/releases/download/fuse-$(LIBFUSE_VERSION)
> + LIBFUSE_VENDOR = libfuse_project
> LIBFUSE_LICENSE = GPL-2.0, LGPL-2.1
> LIBFUSE_LICENSE_FILES = COPYING COPYING.LIB
> LIBFUSE_INSTALL_STAGING = YES
> LIBFUSE_DEPENDENCIES = $(if $(BR2_PACKAGE_LIBICONV),libiconv)
> LIBFUSE_CONF_OPTS = \
>         --disable-example \
>         --enable-lib \
>         --enable-util
>
> + LIBFUSE_CPE =
> cpe:2.3:a:$(LIBFUSE_VENDOR):<packagename>:$(LIBFUSE_VERSION):*:*:*:*:*:*:*
>

Ron, above is what has been discussed so far.  Maybe we could hash out
a architecture and the pieces involved to do this so we could breakup
the work?

I'm most interested in the report generation and defining package
level CPE strings.  I've got a good amount of data and string examples
I can share.  We use a separate tool to perform the analysis and
record keeping.

Matt

[Buildroot] Google Summer of Code 2018 ?

[Arnout Vandecappelle]

On 17-01-18 21:52, Thomas Petazzoni wrote:
> Hello,
> 
> For information, organizations can apply for GSoC 2018 until January
> 23, so there is less than a week left to apply. The questions are: do
> we want to apply? And if yes, for what topics?
> 
> Looking at https://elinux.org/Buildroot:GSoC2017Ideas:
> 
>  - Reproducible builds. While some initial work was done, there is
>    definitely a lot more that could be done.

 This is indeed an interesting topic for GSoC.

> 
>  - Testing infrastructure: the runtime testing infrastructure was
>    added in the mean time. Writing more tests and extending the
>    infrastructure is still needed though.

 Useful, but probably a difficult topic.


>  - Relocatable SDK: this topic is pretty much solved IMO, so this topic
>    is no longer relevant.

 Ack.


>  - Follow upstream updates and CVEs of packages. I think this topic is
>    still relevant, and IMO is the most interesting topic.

 Although interesting, I think this is not very suitable for GSoC. Mostly
because it fits more in a "commercial" use of Buildroot and I don't think GSoC
is really meant for that. But maybe that's more a personal feeling. Probably
doesn't hurt to propose it.


>  - Support for LLVM: an intern from Smile (France) just announced that
>    he will be working on this topic during the next months, so I don't
>    see the point of having a GSOC on the same topic.

 Ack.


>  - Support new languages and complete existing ones. I'm not sure about
>    this one:
>    * For NodeJS, I'm not sure we want to have zillions of packages for
>      the different NodeJS modules
>    * The Go package infrastructure has been resubmitted, and is
>      actively being pushed by Angelo
>    * The Rust support is actively being pushed by Eric
>    So I don't know if there's enough things left to do for this project
>    idea.

 Yeah, and it's also a very tricky subject. All languages are pretty different.


 So, is anyone going to submit these three proposals?

 Regards,
 Arnout


> Any other idea of what's missing in Buildroot, or that could be
> improved ?



-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Google Summer of Code 2018 ?

[Matthew Weber]

Arnout,

On Mon, Jan 22, 2018 at 4:04 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
[snip]
>
>  So, is anyone going to submit these three proposals?
>

I checked this morning and it looks like submission is now closed....

Matt

[Buildroot] Google Summer of Code 2018 ?

[Peter Korsgaard]

>>>>> "Matthew" == Matthew Weber <matthew.weber@rockwellcollins.com> writes:

 > Arnout,
 > On Mon, Jan 22, 2018 at 4:04 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
 >> 
 >> 
 > [snip]
 >> 
 >> So, is anyone going to submit these three proposals?
 >> 

 > I checked this morning and it looks like submission is now closed....

Argh, indeed - Deadline was January 23th, 17:00 UTC :/

https://developers.google.com/open-source/gsoc/timeline

-- 
Bye, Peter Korsgaard