Hi!

> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> This describes at which time which ares of the CIP kernel are handled by
> the CIP security team and how to report vulnerabilities to it. It
> furthermore state the this projects falls under the LF stewardship
> framework.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> 
> First proposal. Please review and provide feedback. If we all agree, 
> this should be merged into all CIP kernel branches.

So... latest kernel already has
Documentation/process/security-bugs.rst as an entry point for security
bugs. 6.1 and 5.10 have Documentation/admin-guide/security-bugs.rst .

security-bugs.rst tells people to basically do normal bug report,
Cc-ing security@kernel.org, avoiding mailing list cc. That will be
unencrypted email, and they offer up-to 7 to 14 days of embargo.

The "linux-distros" mailing list is mentioned there.

> +++ b/SECURITY.md
> @@ -0,0 +1,37 @@
> +# Security Policy
> +
> +This project is supported under the Linux Foundation CRA stewardship framework,
> +as described at https://www.linuxfoundation.org/security. Security
> +vulnerabilities should be reported through the mechanisms described below,
> +which we will coordinate with our CRA steward. For actively
> exploited

I don't believe all readers will know what "CRA" means in this
context. I'm not sure, for example, and knowledge will be even lower
for people outside EU.

> +Please DO NOT report any potential security vulnerability via a public channel
> +(mailing list, gitlab issue etc.). Instead, contact the CIP security team via
> +security@cip-project.org via email. Please provide a detailed description of
> +the issue, the steps to reproduce it, the affected versions and, if already
> +available, a proposal for a fix. You should receive a response within 5 working
> +days. If the issue is confirmed as a vulnerability by us, we will request a
> +CVE, publish the fix and give credits for your report if desired. This project
> +follows a 90 day disclosure timeline.

Ok, so here's security@cip-project.org , and we make promises
different from what security@kernel.org promises (90 days vs. 7 days,
for example). I'd suggest adopting policy from security-bugs.rst with
different email address.

Plus there's cra-steward-something@linuxfoundation.org, I assume.

I guess I'm quite confused at this point, and whoever hit a security
problem is confused, too.

First, what do we people to do? My understaning is:

if bug is actively exploited:
       mail cra-steward-something@linuxfoundation.org
elif there's misconfigured gitlab, someone stolen my passwords, malware in the repositories:
       mail cra-steward-something@linuxfoundation.org
elif bug is in -cip specific code in kernel:
       mail security@cip-project.org
elif bug is in 4.4-cip or 4.19-cip:
       mail security@cip-project.org
elif bug is in 5.10-cip or newer:
       mail security@kernel.org
else:
       # there may be bugs in self-maintained kernels, in parts we
       # don't support, such as arch/s390x. What to do with those?
       # Can we document we just don't care? Or do we need to handle
       # them?
       mail security@cip-project.org

Does that make sense? We probably should include real address for
cra-steward-something@linuxfoundation.org here.

Best regards,
								Pavel