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

[Richard Purdie]

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.

> > > > The liability for insecure millions of devices does not lie
> > > > with the yocto project, it lies with the OEMs.
> > > > ...
> > > The liability for insecure millions of devices lies 100% with the
> > > Yocto 
> > > Project if it claims to provide security support but does not
> > > actually 
> > > provide it.
> > > 
> > > If a user has to decide today whether an upcoming product will
> > > run
> > > Ubuntu 20.04 LTS or Yocto 3.1 LTS, then it should be clear to the
> > > user whether or not choosing Yocto will provide upstream
> > > security 
> > > support the same way as Ubuntu.
> > > 
> > > A user reading the YP LTS announcement expects security support
> > > similar 
> > > to what Ubuntu is offering, and might only notice that this isn't
> > > true 
> > > after a known vulnerability gets exploited on millions of
> > > devices.
> > I didn't get that out of the announcement. It only reference in the
> > LTS
> > announcement  regarding Security was in context to Community
> > support.
> > ...
> 
> 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.

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.

Even with the non-stable side of the project, the patch
review/testing/merging and debugging which patch causes which
regression basically falls onto one person, me. Yes, people help, its
hugely appreciated when they do but I'm the only person paid to do it
(amongst many other things) and I therefore know first hand how much
work this is.

We want to extend the lifespan of some releases. We can't ask/force our
volunteers to do that, its not reasonable. The project is therefore
looking to try something different where we have someone with time
dedicated to this.

There are certainly limitations to what will likely be one part time
person can do, however we are hoping it improves on what we have today
and may even set a mechanism by which the project can better operate
for key functionality in future.

We're putting this into the context of the maintainer who coordinates
things, not someone to write the individual security fixes as that is
the only realistic way we can make this work. If people share their
security patches they'll have a lot of work, if nobody shares such
fixes, it will be minimal. Time will tell if people can/will share. I
do think it makes sense to try.

> YP then claims for LTS that "These components will now receive the
> usual defect fixes and updates for the extended period of two years."

So the current process is extended for a longer period. That seems
quite clear.

> When YP states "A very important criterion for evaluating and
> adopting a software platform is support." the one kind of support
> that really  matters for users of long term support releases is
> security support. This is the baseline users expect from anything
> called LTS, and the main reason why users want to use LTS releases.

And we are trying to put something in place which better supports
review and merging of patches into that LTS. That is a form of security
support. We can't afford a team of 20 to work on it but it is an
improvement from our current volunteer best efforts?

We're also not competing with member company offerings. If you want a
full set of security guarantees, please use a company which offers that
service, several project members will be happy to help (and charge
accordingly).

> 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 allows users to mitigate by allocating resources for security
> support of their products, instead of unknowingly shipping millions
> of insecure devices.
> 
> It would also allow YP to develop offers for community companies to
> pool smaller contributions together - 50 companies each paying 2k per
> year for pooled security support is cheaper for them than each of
> them locally providing the same security support.

This is what we're effectively trying to do. The level of "security
support" you can do with $100k/year is a maintainer/coordinator of the
stable branch. Even writing a spec for that is hard, if you have one
we'd love a copy btw.

Taking a step back, please realise that we are trying to improve what
we can offer within the realms of what is practical. We can improve the
maintenance function, we're not going to be able to write every
security fix or provide guarantees.

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.

If we need to clarify how this is documented/presented, we should do
so. Accusing people of misleading/lying/false information isn't
helpful, or in fact accurate.

Cheers,

Richard