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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
