From richard.purdie at linuxfoundation.org Tue Mar 3 22:57:34 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 03 Mar 2020 22:57:34 +0000 Subject: [Openembedded-architecture] Yocto Project Long Term Support (LTS) Announced Message-ID: <0587ded5e0871e7b92052cbe6e5d72fc31968669.camel@linuxfoundation.org> Its posted at: https://www.yoctoproject.org/yocto-project-long-term-support-announced/ but I'll copy it below since this is an important announcement """ To fulfill the evolving requirements of its members and users, the Yocto Project announced a new plan to extend support for selected releases. The new support plan covers an initial two-year period and the first candidate to benefit from this change will be the Yocto Project 3.1 release. A very important criterion for evaluating and adopting a software platform is support. This holds true when it comes to development tools as well. Yocto Project releases are usually maintained for one year. Beyond this period, 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. Although this follows the open source culture, where development is particularly known for speed and bleeding-edge innovation, there has been a rising interest among project members and end users for extending this period. As a result, the Yocto Project technical leadership put together a proposal to address this need as well as arranging the tools and processes to allow it to best benefit the project and its users. The project aims to choose an LTS release every two years. The project components covered under the new plan will match the core subset of those included in the standard release process: Bitbake, OE-Core, meta- yocto, and yocto-docs. These components will now receive the usual defect fixes and updates for the extended period of two years. Additional layers, such as meta-mingw, meta-gplv2 or general OSV vendor layers will not be covered and will follow their usual standard support models. The LTS release will support the original kernel it has been shipped with. Yocto Project technical leadership will continuously evaluate other similar older LTS kernels on a case by case basis depending on the status of upstream support. The version of linux-libc-headers would not change to avoid user-space problems. This change will also benefit other downstream projects relying on Yocto Project releases that have longer life cycles such as AGL, RDK etc. The decisions that the technical leadership makes will take into account the community feedback, people committing resources and input from the member organizations. The LTS maintainer will be responsible for queuing and reviewing suitable changes and starting and monitoring builds. The maintainer may have assistance from the community in resolving new issues identified during build or the QA run. Reviews will use the usual community review mailing list processes. For example, where applicable, a merge request will be sent to the appropriate repo owner once all issues found during the review have been addressed. The Yocto Project LTS maintainer role hasn?t been appointed yet. At the moment, the project technical leadership is focused on finding the dedicated resources. For more information, and to discuss the LTS maintainer role, contact lts-maintainer at yoctoproject.org. """ I think there will be some questions and the TSC has been working on documenting the processes around this which are on the wiki. I believe Armin will follow up with some details about what this means for the existing stable series. Cheers, Richard From akuster808 at gmail.com Wed Mar 4 05:43:47 2020 From: akuster808 at gmail.com (akuster808) Date: Tue, 3 Mar 2020 21:43:47 -0800 Subject: [Openembedded-architecture] Stable release changes now that YP has an LTS program Message-ID: <8e1a92f2-b131-4594-b07c-58192fa2f5b7@gmail.com> Hello, As Richard has pointed out, The Yocto Project now has a LTS program.? It means the stable branch life cycles are changing.? The new standard life span for a stable release will be 7 months before transitioning to "Community Supported". That extra month is so we can pull in changes missed in the release.? With Zeus, we are giving it 9 months to help folks transition? and before it goes to "Community Supported". The "Community Supported" and "EOL" policies are being work on by the Yocto TSC. The LTS and Stable processes are on the YP wiki and where the "Community Supported" and "EOL" policies/processes will be noted. https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS let me know if anything needs clarification. regards, Armin From bunk at stusta.de Wed Mar 4 14:01:09 2020 From: bunk at stusta.de (Adrian Bunk) Date: Wed, 4 Mar 2020 16:01:09 +0200 Subject: [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: References: <20200223193408.5602-1-bunk@stusta.de> <20200224051745.GA6683@localhost> <20200227132729.GA6240@localhost> <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> Message-ID: <20200304140109.GC7923@localhost> On Wed, Mar 04, 2020 at 01:13:19PM +0100, Alexander Kanavin wrote: > On Wed, 4 Mar 2020 at 12:32, Adrian Bunk wrote: > > > I am sure there will be an update to the announcement if this doesn't > > reflect current reality. > > Who is expected to do the actual work of tracking CVEs, making action > points and performing the actions? The current reality is this: the > security update work is done ad hoc by community, even for stable branches. > There is no rigorous security process like in Debian, and no roles to > follow in that process. This means that if no one bothers to make a patch, > the security issue will remain unfixed, and this does happen often. If you > are expecting anything else (e.g. that listed recipe maintainers should do > something), you're setting yourself up to be disappointed. All I am expecting is honesty. If YP does not provide security support for supported stable branches, then public statements that community support would be worse than stable branches due to lack of security support are dishonest and offensive. It also puts all users of Yocto stable and LTS releases and billions of devices at danger if the Yocto project announces security support but does not deliver. The normal user expects that that the announced "usual defect fixes and updates for the extended period of two years" in LTS include the regular security updates that were claimed for stable branches earlier in the same announcement. For cases where I am the user the only benefit of going through the pain of upgrading existing products from older releases to Yocto 3.1 would be 2 years of security support from upstream. Doing the upgrade and only discovering afterwards that it doesn't bring the benefit that was promised would make me . Let me repeat that the only thing I am expecting is honesty, and all I am asking for is that if YP does not provide security support for stable and LTS branches this should be communicated clearly so that all users are aware. > Alex cu Adrian From alex.kanavin at gmail.com Wed Mar 4 16:00:44 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Wed, 4 Mar 2020 17:00:44 +0100 Subject: [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: <20200304140109.GC7923@localhost> References: <20200223193408.5602-1-bunk@stusta.de> <20200224051745.GA6683@localhost> <20200227132729.GA6240@localhost> <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> Message-ID: Taking offense or getting angry at the yocto project is entirely misdirected. The liability for insecure millions of devices does not lie with the yocto project, it lies with the OEMs. If the OEMs are unwilling to allocate manpower to work on security, there?s very little the yocto project can do. We are already struggling to find people to work on actual bugs, and there?s simply no manpower to do security properly. Still, stable releases *are* much better than community supported ones, they do get a lot of CVEs and bugs fixed, all I wanted to say is that the exhaustive process to fix everything that could be insecure is not there. Alex On Wed 4. Mar 2020 at 15.01, Adrian Bunk wrote: > On Wed, Mar 04, 2020 at 01:13:19PM +0100, Alexander Kanavin wrote: > > On Wed, 4 Mar 2020 at 12:32, Adrian Bunk wrote: > > > > > I am sure there will be an update to the announcement if this doesn't > > > reflect current reality. > > > > Who is expected to do the actual work of tracking CVEs, making action > > points and performing the actions? The current reality is this: the > > security update work is done ad hoc by community, even for stable > branches. > > There is no rigorous security process like in Debian, and no roles to > > follow in that process. This means that if no one bothers to make a > patch, > > the security issue will remain unfixed, and this does happen often. If > you > > are expecting anything else (e.g. that listed recipe maintainers should > do > > something), you're setting yourself up to be disappointed. > > All I am expecting is honesty. > > If YP does not provide security support for supported stable branches, > then public statements that community support would be worse than stable > branches due to lack of security support are dishonest and offensive. > > It also puts all users of Yocto stable and LTS releases and billions of > devices at danger if the Yocto project announces security support but > does not deliver. > > The normal user expects that that the announced "usual defect fixes and > updates for the extended period of two years" in LTS include the regular > security updates that were claimed for stable branches earlier in the > same announcement. > > For cases where I am the user the only benefit of going through the pain > of upgrading existing products from older releases to Yocto 3.1 would be > 2 years of security support from upstream. Doing the upgrade and only > discovering afterwards that it doesn't bring the benefit that was > promised would make me . > > Let me repeat that the only thing I am expecting is honesty, > and all I am asking for is that if YP does not provide security > support for stable and LTS branches this should be communicated > clearly so that all users are aware. > > > Alex > > cu > Adrian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bunk at stusta.de Wed Mar 4 17:24:15 2020 From: bunk at stusta.de (Adrian Bunk) Date: Wed, 4 Mar 2020 19:24:15 +0200 Subject: [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: References: <20200224051745.GA6683@localhost> <20200227132729.GA6240@localhost> <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> Message-ID: <20200304172415.GA29456@localhost> On Wed, Mar 04, 2020 at 05:00:44PM +0100, Alexander Kanavin wrote: > Taking offense or getting angry at the yocto project is entirely > misdirected. I am not angry if YP does not provide security support. I am angry when YP is telling lies that it would provide security support, but does not actually provide it. > 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. If security support for YP stable and LTS releases is only on a community support basis and usually incomplete, then it is on YP to make that clear to all users instead of claiming the opposite - in other projects LTS does include security support, sometimes only security fixes are permitted. This could be combined with a call for help for security support, an advantage of being honest would be that it becomes visible for users that there is a resource shortage. > Alex cu Adrian From akuster808 at gmail.com Wed Mar 4 20:26:29 2020 From: akuster808 at gmail.com (akuster808) Date: Wed, 4 Mar 2020 12:26:29 -0800 Subject: [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: <20200304172415.GA29456@localhost> References: <20200224051745.GA6683@localhost> <20200227132729.GA6240@localhost> <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> Message-ID: <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> Adrian, On 3/4/20 9:24 AM, Adrian Bunk wrote: > On Wed, Mar 04, 2020 at 05:00:44PM +0100, Alexander Kanavin wrote: >> Taking offense or getting angry at the yocto project is entirely >> misdirected. > I am not angry if YP does not provide security support. > > I am angry when YP is telling lies that it would provide security > support, but does not actually provide it. ?I am sure its not the intent of the Yocto Project to miss lead folks. > >> 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 new new LTS / Stable process wiki does not claim such claims either. https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS > > If security support for YP stable and LTS releases is only on a > community support basis and usually incomplete, then it is on YP > to make that clear to all users instead of claiming the opposite - in > other projects LTS does include security support, sometimes only > security fixes are permitted. Can point out where those statements are made? Again, I am sure the Yocto Project would like to know. > > This could be combined with a call for help for security support, > an advantage of being honest would be that it becomes visible for > users that there is a resource shortage. There are weekly status reports? and minutes from various meeting that include the attendees list.? The attendees list has not grown. The build swat team was shut down as no one stepped up to help. That was an opportunity for the community to step up. There is request for help regarding defects sent out every week and if it wasn't for WindRiver, Intel, Joshua Watt and Richard the open defects would go uncheck. So the resource issue has been floating around on the various mailing lists for some time. What do you think needs to be done to make it even more visible? regards, armin > >> Alex > cu > Adrian > _______________________________________________ > Openembedded-architecture mailing list > Openembedded-architecture at lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture From bunk at stusta.de Fri Mar 6 10:04:22 2020 From: bunk at stusta.de (Adrian Bunk) Date: Fri, 6 Mar 2020 12:04:22 +0200 Subject: [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> References: <20200227132729.GA6240@localhost> <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> Message-ID: <20200306100422.GA17785@localhost> On Wed, Mar 04, 2020 at 12:26:29PM -0800, akuster808 wrote: ... > On 3/4/20 9:24 AM, Adrian Bunk wrote: ... > > This could be combined with a call for help for security support, > > an advantage of being honest would be that it becomes visible for > > users that there is a resource shortage. > There are weekly status reports? and minutes from various meeting that > include the attendees list.? The attendees list has not grown. The build > swat team was shut down as no one stepped up to help. That was an > opportunity for the community to step up. Yocto is setup as a B2B project providing a basis for embedded products, your "community" are mainly companies. The "build everything yourself" niche for non-embedded is already occupied by Gentoo. For most community companies there is no clear Return on Investment if they would use the opportunity to invest in upstream involvement. > There is request for help regarding defects sent out every week and if > it wasn't for WindRiver, Intel, Joshua Watt and Richard the open defects > would go uncheck. > > So the resource issue has been floating around on the various mailing > lists for some time. What do you think needs to be done to make it even > more visible? >... You are confusing developers with users. Developers are following development discussions. Users who are being paid for building a product based on Yocto read the user information at https://www.yoctoproject.org/ especially the great manuals written by Scott. Development discussions are mostly irrelevant for users. To make a non-Yocto example: I am using Ubuntu LTS on my laptop. The security support provided by Canonical is essential for me, and as part of the community I am using their bugtracker in rare cases where I have problems. I have neither time nor interest in following upstream discussions regarding development of future Ubuntu releases. >... > >> 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. YP then claims for LTS that "These components will now receive the usual defect fixes and updates for the extended period of two years." 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. 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. 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. cu Adrian From richard.purdie at linuxfoundation.org Fri Mar 6 10:36:59 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Fri, 06 Mar 2020 10:36:59 +0000 Subject: [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: <20200306100422.GA17785@localhost> References: <20200227132729.GA6240@localhost> <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> <20200306100422.GA17785@localhost> Message-ID: <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> 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 From richard.purdie at linuxfoundation.org Sat Mar 7 16:17:28 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Sat, 07 Mar 2020 16:17:28 +0000 Subject: [Openembedded-architecture] buildtools-extended-tarball wrapping builds Message-ID: Hi, I just wanted to mention that we now have the ability to wrap builds on specific workers with specific buildtools tarballs. Currently this functionality is in master, we do have the option of porting the helper code to other stable branches. We have had multiple issues, with the infrastucture internal url/cert handling, git/cert environment issues, an issue with eSDK testing (next has a fix in testing), the crypt fix already submitted (meaning M2's tarball doesn't help) and so on, I'm hoping we've gotten to the bottom of those. This does mean we could drop gcc 4.8/4.9 support if we wanted to and rely on the tarball support for centos7/debian8. I'm torn on that, we are still missing: a) Support for wrapping a build with buildtools more auotmatically (like we do with uninative) b) documentation of buildtools-extended-tarball and to drop, we'd probably need these pieces. I'd note the people who vocally said they needed centos7 support are not the ones who are doing this work. The only reason I'm pushing it is I know it will ultimately help support our LTS efforts. Cheers, Richard From bunk at stusta.de Sun Mar 8 21:46:10 2020 From: bunk at stusta.de (Adrian Bunk) Date: Sun, 8 Mar 2020 23:46:10 +0200 Subject: [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> References: <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> <20200306100422.GA17785@localhost> <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> Message-ID: <20200308214610.GB1425@localhost> 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 From alex.kanavin at gmail.com Sun Mar 8 22:08:08 2020 From: alex.kanavin at gmail.com (Alexander Kanavin) Date: Sun, 8 Mar 2020 23:08:08 +0100 Subject: [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: <20200308214610.GB1425@localhost> References: <20200304090507.GA7923@localhost> <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> <20200306100422.GA17785@localhost> <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> <20200308214610.GB1425@localhost> Message-ID: On Sun, 8 Mar 2020 at 22:46, Adrian Bunk wrote: > 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. > Do you have any actual evidence for actual users shipping insecure products because they mistakenly believe Yocto takes care of security for them? This has been the situation from the start of the project, certainly this was the case 5 years ago when I joined it, and the only person ever to make an issue out of it is you. Everyone else seems to understand the deal they're getting by using Yocto without a commercial support contract. Yes, there are millions of insecure yocto-based devices out there, but there reasons they are insecure have nothing to do with what you say. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From bunk at stusta.de Mon Mar 9 00:23:08 2020 From: bunk at stusta.de (Adrian Bunk) Date: Mon, 9 Mar 2020 02:23:08 +0200 Subject: [Openembedded-architecture] Does YP provide security support for stable and LTS branches? In-Reply-To: References: <20200304113217.GB7923@localhost> <20200304140109.GC7923@localhost> <20200304172415.GA29456@localhost> <01b3bb37-f65f-8048-1a27-b859b62d7f98@gmail.com> <20200306100422.GA17785@localhost> <877e317932176664bc7b0120439c56d4dda791af.camel@linuxfoundation.org> <20200308214610.GB1425@localhost> Message-ID: <20200309002308.GD1425@localhost> On Sun, Mar 08, 2020 at 11:08:08PM +0100, Alexander Kanavin wrote: > On Sun, 8 Mar 2020 at 22:46, Adrian Bunk wrote: > > > 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. > > > > Do you have any actual evidence for actual users shipping insecure products > because they mistakenly believe Yocto takes care of security for them? Nothing to discuss in public. > This > has been the situation from the start of the project, certainly this was > the case 5 years ago when I joined it, and the only person ever to make an > issue out of it is you. Everyone else seems to understand the deal they're > getting by using Yocto without a commercial support contract. >... You are saying that 'track and fix CVEs' is on users. Let's check what YP is telling users. Click on the "Is Yocto Project for you?" link on the YP frontpage: https://www.yoctoproject.org/is-yocto-project-for-you/ 13. Yocto Project follows a strict release schedule incorporating security patches in all supported releases. This predictability is crucial for projects that are based on Yocto Project and allows the development teams to plan their activities. Developers can choose which Yocto Project branch on which to base their activities as a function of their needs. The development branch will ensure access to the latest features while the stable branches will reduce the pace of changes. CVEs (common vulnerabilities and exposures) issues are supported for the latest 2 releases. > Alex cu Adrian From persaur at gmail.com Mon Mar 9 10:01:47 2020 From: persaur at gmail.com (Rich Persaud) Date: Mon, 9 Mar 2020 06:01:47 -0400 Subject: [Openembedded-architecture] buildtools-extended-tarball wrapping builds Message-ID: <0C4A6E55-81B1-4AC1-B143-19AED076F2F4@gmail.com> On Mar 7, 2020, at 11:17, Richard Purdie wrote: > ?Hi, > > I just wanted to mention that we now have the ability to wrap builds on > specific workers with specific buildtools tarballs. > > Currently this functionality is in master, we do have the option of > porting the helper code to other stable branches. > > We have had multiple issues, with the infrastucture internal url/cert > handling, git/cert environment issues, an issue with eSDK testing (next > has a fix in testing), the crypt fix already submitted (meaning M2's > tarball doesn't help) and so on, I'm hoping we've gotten to the bottom > of those. > > This does mean we could drop gcc 4.8/4.9 support if we wanted to and > rely on the tarball support for centos7/debian8. I'm torn on that, we > are still missing: > > a) Support for wrapping a build with buildtools more auotmatically > (like we do with uninative) > > b) documentation of buildtools-extended-tarball This would be valuable to wrap older Haskell [1] and Ocaml [2] compilers, which are often challenging to support with newer versions of OE. I've tested buildtools-extended-tarball with an OpenXT build, but we would need to use an older tarball for the Haskell/Ocaml native compilers. Rich [1] https://github.com/OpenXT/meta-openxt-haskell-platform [2] https://github.com/OpenXT/meta-openxt-ocaml-platform -------------- next part -------------- An HTML attachment was scrubbed... URL: From bunk at stusta.de Mon Mar 9 10:52:40 2020 From: bunk at stusta.de (Adrian Bunk) Date: Mon, 9 Mar 2020 12:52:40 +0200 Subject: [Openembedded-architecture] buildtools-extended-tarball wrapping builds In-Reply-To: References: Message-ID: <20200309105240.GA2477@localhost> On Sat, Mar 07, 2020 at 04:17:28PM +0000, Richard Purdie wrote: >... > This does mean we could drop gcc 4.8/4.9 support if we wanted to and > rely on the tarball support for centos7/debian8. >... Debian 8 - will have LTS support ending at the end of June, and - ships Python 3.4, which is no longer supported by bitbake. 3 months ago Yocto master stopped working on Debian 8, and as expected noone complained. > Cheers, > > Richard cu Adrian From richard.purdie at linuxfoundation.org Mon Mar 9 11:41:13 2020 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Mon, 09 Mar 2020 11:41:13 +0000 Subject: [Openembedded-architecture] buildtools-extended-tarball wrapping builds In-Reply-To: <20200309105240.GA2477@localhost> References: <20200309105240.GA2477@localhost> Message-ID: On Mon, 2020-03-09 at 12:52 +0200, Adrian Bunk wrote: > On Sat, Mar 07, 2020 at 04:17:28PM +0000, Richard Purdie wrote: > > ... > > This does mean we could drop gcc 4.8/4.9 support if we wanted to > > and > > rely on the tarball support for centos7/debian8. > > ... > > Debian 8 > - will have LTS support ending at the end of June, and > - ships Python 3.4, which is no longer supported by bitbake. > > 3 months ago Yocto master stopped working on Debian 8, > and as expected noone complained. We still have one debian8 autobuilder worker: https://autobuilder.yoctoproject.org/typhoon/#/workers/9 and with buildtools tarball it works 'fine'. Cheers, Richard From bunk at stusta.de Mon Mar 9 12:08:06 2020 From: bunk at stusta.de (Adrian Bunk) Date: Mon, 9 Mar 2020 14:08:06 +0200 Subject: [Openembedded-architecture] buildtools-extended-tarball wrapping builds In-Reply-To: References: <20200309105240.GA2477@localhost> Message-ID: <20200309120806.GB2477@localhost> On Mon, Mar 09, 2020 at 11:41:13AM +0000, Richard Purdie wrote: > On Mon, 2020-03-09 at 12:52 +0200, Adrian Bunk wrote: > > On Sat, Mar 07, 2020 at 04:17:28PM +0000, Richard Purdie wrote: > > > ... > > > This does mean we could drop gcc 4.8/4.9 support if we wanted to > > > and > > > rely on the tarball support for centos7/debian8. > > > ... > > > > Debian 8 > > - will have LTS support ending at the end of June, and > > - ships Python 3.4, which is no longer supported by bitbake. > > > > 3 months ago Yocto master stopped working on Debian 8, > > and as expected noone complained. > > We still have one debian8 autobuilder worker: > > https://autobuilder.yoctoproject.org/typhoon/#/workers/9 > > and with buildtools tarball it works 'fine'. Ah right, buildtools tarball ships python3. So yes, this invalidates my second point. > Cheers, > > Richard cu Adrian From mhalstead at linuxfoundation.org Fri Mar 13 23:58:30 2020 From: mhalstead at linuxfoundation.org (Michael Halstead) Date: Fri, 13 Mar 2020 16:58:30 -0700 Subject: [Openembedded-architecture] Mailing list platform change March 20th Message-ID: We are moving our lists from Mailman to Groups.io. E-mail to lists will be delayed during the move window. We are aiming to complete the migration during business hours in the Pacific time zone. A new account will be created for you on the Groups.io platform if you don't already have one. You can read more about the change on the wiki: https://www.openembedded.org/wiki/GroupsMigration If there are serious issues we will rollback the changes. We will e-mail all lists when work is complete. -- Michael Halstead Linux Foundation / Yocto Project Systems Operations Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhalstead at linuxfoundation.org Thu Mar 19 16:44:43 2020 From: mhalstead at linuxfoundation.org (Michael Halstead) Date: Thu, 19 Mar 2020 09:44:43 -0700 Subject: [Openembedded-architecture] Mailing list platform change March 20th In-Reply-To: References: Message-ID: Everything is proceeding smoothly and this work will continue as planned. The migration starts at noon PDT tomorrow. List owners please take care of all outstanding moderation in the next 24 hours to ensure a smooth transition. Thank you, -- Michael Halstead Linux Foundation / Yocto Project Systems Operations Engineer On Fri, Mar 13, 2020 at 4:58 PM Michael Halstead < mhalstead at linuxfoundation.org> wrote: > We are moving our lists from Mailman to Groups.io. E-mail to lists will > be delayed during the move window. We are aiming to complete the migration > during business hours in the Pacific time zone. > > A new account will be created for you on the Groups.io platform if you > don't already have one. > > You can read more about the change on the wiki: > https://www.openembedded.org/wiki/GroupsMigration > > If there are serious issues we will rollback the changes. We will e-mail > all lists when work is complete. > > -- > Michael Halstead > Linux Foundation / Yocto Project > Systems Operations Engineer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhalstead at linuxfoundation.org Fri Mar 20 18:59:42 2020 From: mhalstead at linuxfoundation.org (Michael Halstead) Date: Fri, 20 Mar 2020 11:59:42 -0700 Subject: [Openembedded-architecture] Mailing list platform change March 20th In-Reply-To: References: Message-ID: The migration will begin shortly. List mail will be delayed until the process is complete. E-mail sent during downtime should eventually be delivered. However waiting to send until after the switch is recommended. Thank you, -- Michael Halstead Linux Foundation / Yocto Project Systems Operations Engineer On Thu, Mar 19, 2020 at 9:44 AM Michael Halstead < mhalstead at linuxfoundation.org> wrote: > Everything is proceeding smoothly and this work will continue as planned. > The migration starts at noon PDT tomorrow. > > List owners please take care of all outstanding moderation in the next 24 > hours to ensure a smooth transition. > > Thank you, > -- > Michael Halstead > Linux Foundation / Yocto Project > Systems Operations Engineer > > On Fri, Mar 13, 2020 at 4:58 PM Michael Halstead < > mhalstead at linuxfoundation.org> wrote: > >> We are moving our lists from Mailman to Groups.io. E-mail to lists will >> be delayed during the move window. We are aiming to complete the migration >> during business hours in the Pacific time zone. >> >> A new account will be created for you on the Groups.io platform if you >> don't already have one. >> >> You can read more about the change on the wiki: >> https://www.openembedded.org/wiki/GroupsMigration >> >> If there are serious issues we will rollback the changes. We will e-mail >> all lists when work is complete. >> >> -- >> Michael Halstead >> Linux Foundation / Yocto Project >> Systems Operations Engineer >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: