[OE-core] [Openembedded-architecture] Does YP provide security support for stable and LTS branches?

Adrian Bunk bunk at stusta.de
Sun Mar 8 21:46:10 UTC 2020


On Fri, Mar 06, 2020 at 10:36:59AM +0000, Richard Purdie wrote:
> On Fri, 2020-03-06 at 12:04 +0200, Adrian Bunk wrote:
> > For most community companies there is no clear Return on Investment
> > if they would use the opportunity to invest in upstream involvement.
> 
> That isn't true. If you fix something yourself and hold the change you
> get to maintain it. If you work with upstream you can share the
> maintenance burden with the community going forward. That is a direct
> ROI, there are also more indirect benefits.

I was responding to Armin talking about the build swat team.
It is hard to see the ROI for a community company when participating
in something like that.

Upstreaming of own local changes is a different story.

>...
> Today, our stable branch maintenance is done "ad-hoc" by volunteers.
> I/we can't ask them to do anything in any given time frame, its a best
> effort. I *hugely* appreciate what those people do but it has its
> limitations.

On developer lists the message is always "we are short on resources,
please help". Which reaches the few people already involved in 
development.

The message to users is that everything is fine and what new things
Yocto is additionally offering.

No regular user of Wikipedia would miss the regular fundraising where 
the project needs/wants money.

>...
> > The wording is "releases move to community support, which means they 
> > only receive occasional patches for critical defects and updates,
> > and no regular defect fixes and security updates".
> > 
> > When the move to community support means no regular security updates,
> > this is a clear claim from YP that before the move there are regular
> > security updates.
> 
> I think you're being rather pedantic here and I'd suggest we go back to
> what the essence of this announcement is.

The essence for me is that a few days after I am told on the developer 
list that 'track and fix CVEs' for stable releases is on users, YP makes 
an announcement that is worded to make users believe the opposite.

I am getting attacks like being accused of making "toxic accusations" 
for stating the fact that millions of devices being put at risk by
YP misrepresenting the status of security support to users who are
building products based on Yocto.

It is on YP to make it clear to users whether or not Yocto comes with
the same set of security guarantees as distributions like Ubuntu or Debian. 
If it is the duty of every user of Yocto to track and fix CVEs,
then this has to be stated clearly instead of implying the opposite.
This gives users the opportunity to mitigate, instead of unknowingly
shipping insecure products.

E.g. embedded products based on Ubuntu with its security support from 
Linux Foundation member Canonical are clearly better than embedded 
products based on any distribution without similar security support.

And while you are downloading an Ubuntu image from their website you are 
on a "Contribute with PayPal" page.

>...
> > If YP does not want to be responsible for insecure millions of
> > devices, it is up to YP to not make incorrect claims and make it
> > clear in announcements and user documentation if security support is
> > not provided by YP.
> 
> I think the definition of "security support" is arguable to be
> different things but the intent of what we're trying to do here is
> clear. No, the person will not write the patches, the intent is to
> coordinate the maintenance of the branch. If there are huge security
> holes I would at least expect they can highlight the issues and then
> coordinate any help in fixing them. That in itself is a level of
> security support btw.

This is a bit of a strawman, the problem is elsewhere.

Vulnerabilities are rarely OE/Yocto-specific, in practice security
support means applying the same patches that other distributions
are also applying.

When a security advisory will be published for Ubuntu 20.04 LTS
there will be a patch available for usually approximately the
same version of this software as is in Yocto 3.1 LTS.

Going back to where this discussion started:

If YP gives the impression that stable and LTS series are security
supported by YP, then it is a problem when a crypto library like
nss is not getting any security fixes in Yocto 2.7.

Debian stable ships the same upstream version and applied fixes for 5 
CVEs last year. In practice security support means integrating these 
existing patches. And providing security support means that there is
a person resposible for integrating such existing patches from elsewhere.

>...
> Its incredibly hard to find funding to try and then organise what we're
> trying to do, it would be nice if you could try and help us support in
> doing so.
>...

Do you have constructive suggestions how people can help with funding 
who do not have access to money sources that could contribute 6 digit 
amounts to upstream Yocto?

Any support I could provide or might be able to organize would be
4 digits per year, and I am not aware of any existing way to pool
such contributions easily for paying people for upstream YP work.

The best I could offer would be that I open a company that sends 
invoices for small contributions and pays people from that money.
Which sounds like a clear non-starter for financing YP stable/LTS branch 
maintainance - this would likely have to be organized through the LF.

I might have use for continued warrior maintainance and might volunteer
as community maintainer for that after the 12 months, but this doesn't 
generate funding for YP.

It is really hard to help you find funding when you are offering 
opportunities to fund YP only for big companies with huge budgets,
but aren't offering any opportunity to give a 1k contribution to YP.

I fully understand that improving on that would be difficult,
but this is a reason why most businesses are not able to help
you even if they want to.

> Cheers,
> 
> Richard

cu
Adrian


More information about the Openembedded-core mailing list