sfowl

@tallclair @joelsmith @BenTheElder I circled back on this today and have created an [example PR](https://github.com/sfowl/kubernetes/pull/2) into my own fork of what the proposed changes could look like. I made a...

/assign

Thanks for feedback @tallclair ! I've taken out the auto-inclusion of github profile email addresses and added a `slack` key. Values for all `email` and `slack` will be `null` initially,...

Removed the `slack` field from the proposal due to slack usernames not being unique across the kubernetes.slack.com. More info in kubernetes/community/pull/5398

@BenTheElder Right, that was mentioned in the kubernetes/community PR. My concern was that even if the spec declares that slack _id_s should be used, there doesn't seem to be a...

The last round of PRs for this task languished due to my own neglect. @tallclair suggested a more simple approach of: 1. Add a `security_contacts` field to OWNERS with just...

> Thanks! I'm not sure what the merge order should be, but you should also update the template repo: https://github.com/kubernetes/kubernetes-template-project/blob/main/SECURITY_CONTACTS https://github.com/kubernetes/kubernetes-template-project/pull/38 My thinking was this PR into k/community was a...

Hey @PushkarJ , yes, there would need to be a second phase to address the private communication aspect. This first phase does have benefits of its own though, @tallclair gave...

/assign

Some other options aside from having a second Containerfile could be: * Use a base image like registry.redhat.io/openshift4/ose-cli-rhel9 which includes kubectl * Use the output from something like `uname -p`...