Suggested process for kubernetes-distributors list

[dankohn]

The security release process says:

The Fix Lead will email the patches to kubernetes-distributors-announce@googlegroups.com so distributors can prepare builds to be available to users on the day of the issue's announcement. Distributors can ask to be added to this list by emailing kubernetes-security@googlegroups.com and it is up to the Product Security Team's discretion to manage the list.
TODO: Figure out process for getting folks onto this list.

The K8s software conformance working group is maintaining a public spreadsheet of all known Kubernetes offerings, which was initially created by @josephjacks.

I propose adding a security contact column to the spreadsheet and soliciting the security contact (or comma separated list of contacts) for each offering. Some comments and open questions:

• Here are some details on how the Linux kernel distro list is managed: https://lwn.net/Articles/566123/
• Many folks (including CNCF staff) are monitoring the spreadsheet, and only @josephjacks and I can edit, so we should be able to avoid bad actors adding their email addresses.
• I presume we should limit security contacts to come from the appropriate domain (e.g., redhat.com for OpenShift).
• Can we just email new submissions to kubernetes-security@googlegroups.com or is there a better process for administering list membership? We would escalate any questionable entries to the security group.

Cc: @philips @jessfraz @WilliamDenniss @gregkh

[jessfraz]

I propose adding a security contact column to the spreadsheet and soliciting the security contact (or comma separated list of contacts) for each offering.

The less people added, the more likely embargo will not be leaked so at most we should say 1 person from each, pending certain circumstances. Security emails can also not be an internal mailing list group but should be required to be an individual, since groups would be up to the vendor to maintain who is on it and is out of our control.

Can we just email new submissions to kubernetes-security@googlegroups.com or is there a better process for administering list membership? We would escalate any questionable entries to the security group.

I do think the request should ultimately be handled by the group, but can be based off the spreadsheet.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[jessfraz]

This was handled by #1153 so I think it can be closed :)

[cblecker]

So it was! Thanks @jessfraz
/close

[justaugustus]

/remove-lifecycle stale
/remove-sig pm
/committee product-security