That sounds like a good strategy. We could call it a "pre-WG setting" to start with. For a change, let us start with looking at the known issues of a few open-source libc libraries, such as: - GNU C

Thanks, Wenhui; I think you replied on the wrong email. Anyhow, I will branch back to LFSCS and post the proposed agenda. Regards Elana

Hi, Ruide( ruide.zhang.r@... ) from security team and me from IaaS of bytedance/TikTok will be explaining our need for more documentation and tutorials on safety configurations for VM/Host in

Hi, Elena: I could help with the explanation then. Wenhui

IMO we should initially spawn an investigation task trying to work on one or few specific issues and, once we have a better view of the value the WG can and will provide, we can come back with a

Sorry, I missed to answer this question in my previous email. The point above is the critical first task for a group to agree on. ISO 26262 mentions: "the reactions of the functions under

That is correct. As the scope is limited to handling known issues, we can---even with a small team---probably cover more than just the kernel; further, the kernel development is certainly the

Hi Lukas Can you specify what you mean by "known issue"? IMO it is a bit vague. For example if you mean bug I could think of the kernel bugzilla (https://bugzilla.kernel.org/), if you mean

Elana, there is need for this. It may not be in your specific area of interest, and if no one else wants to spend time on this because it’s also not in their area of interest, so be it. But there

Lukas, that is not what I am saying. This is the same one sided argument, which ignores market and business needs. And which will inevitably lead to alternative solutions. If the meeting will be

Elana, so any system using Linux cannot be compliant to any safety standard that requires that for a system element based on Linux to present a list of known issues? If that is the case, we should

Jason, the review will only prove (once again) that it is a dead-end to expect Linux to be qualified by any safety standards. It will not help manufacturers in compliance with those standards because

<Elana.Copperman@...> wrote: I agree with you, Elana. Solutions are required: - Tools to collect, track and evaluate known issues. Every automatic tool starts with a human understanding the

Jason, the review will only prove (once again) that it is a dead-end to expect Linux to be qualified by any safety standards. It will not help manufacturers in compliance with those standards because

Strong disagree. Review of published bug/defect/anomaly/known issue lists of Software of Unknown Provenance (SOUP) is a normative requirement for several functional- or software-safety standards

Just pulling together a list of known issues from already published sources, has no value. For this to have any meaning, we need to focus on solutions: Tools, people, corrective actions. Can ELISA

Dear all, (Using the 'New working group proposal template' from https://github.com/elisa-tech/workgroups/blob/61d4beab67c3bc647086b1db41f0434ec2b98b31/new-wg-template.md) Proposed working group

Thanks, Wenhui. Would it be possible for someone who speaks English reasonably well to join the meeting tomorrow, and to clarify for the group what specific requirements could be focused? This would

Hi, Elana： We discussed with China Team of TikTok for what we would like to learn. Linux safety Configurations' usage , guarantees and performance tradeoffs. The recommendation for Linux safety

Good points, thanks Wenhui. If you can help to collect more feedback and generate interest from additional practitioners, we can help to build a community within ELISA who can work with the LF on