-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SECURITY_CONTACTS contact information #56
Comments
@tallclair: Please ensure the request meets the requirements listed here. If this request no longer meets these requirements, the label can be removed In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale Updated proposal:
|
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
+1 #56 (comment) |
@BenTheElder Nothing (just someone to do the work), except for the concerns raised in the discussion thread about confusing the intent of security contacts. |
Thanks! I agree that the current concept is confusing.
Will think on the easy access to email issue as well (just caught up on the
thread).
…On Thu, Jul 23, 2020 at 1:54 PM Tim Allclair ***@***.***> wrote:
@BenTheElder <https://github.com/BenTheElder> Nothing (just someone to do
the work), except for the concerns raised in the discussion thread
<https://groups.google.com/d/msg/kubernetes-sig-architecture/0MUJBDGf3jg/wYrr8i1tBQAJ>
about confusing the intent of security contacts.
xref: kubernetes/kubernetes-template-project#35
<kubernetes/kubernetes-template-project#35>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#56 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHADKY5EOU5LVRMSM63PB3R5CPRPANCNFSM4JNSBF4Q>
.
|
@tallclair @joelsmith @BenTheElder I circled back on this today and have created an example PR into my own fork of what the proposed changes could look like. I made a Some thoughts I had while making this:
Any/all feedback is very welcome. If this approach makes sense, then the next step would be to open PRs for all OWNERS in the kubernetes org. Given the size (and noise!) of that task I thought it best to start with an example for review. Thanks! |
Thanks for picking this up Sam! I think we should not automatically copy the approvers into security contacts. I'd prefer it to be an explicit add, and we (PSC) can just escalate to the approvers if there aren't any security_contacts. Once the changes go in, I think it would be worth sending out a call to action to kubernetes-dev for maintainers to review their security_contacts. re: emails - as much as it would be nice for us to have easy access to emails, I think it needs to be an explicit opt-in. We can encourage people to add an email in the call-to-action. Maybe it would be worth giving a slack option too? |
/assign |
Thanks for feedback @tallclair ! I've taken out the auto-inclusion of github profile email addresses and added a I've updated the demo PR and spec update, and made a revised version of the script |
Removed the |
slack has user _id_s that are unique however, xref: kubernetes/community#2349 click on a user, click "view full profile", under the profile click "more ..." then "copy member ID" our moderation reporting robot uses IDs. |
@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 way to enforce that, i.e. users would likely still add their usernames, which adds the risk of mistaken identity. The issue you've linked above is interesting. I've wondered if it's the wrong approach to be adding extra fields like I guess I'm saying that I like the idea simplifying @tallclair wdyt? |
Actually we already enforce other forms of validity in these files and the form of slack user IDs is well-known.
I don't think we should allow security contacts that don't provide a contact method. I also don't think kubernetes/community#2349 is going to happen, but it's relatively straight forward to require a user ID and we can validate the correct format. |
If the intent is to have private space to communicate with SRC, would it be simpler to update the SECURITY_CONTACTS file with the following:
For all new sub-projects, we could add a step to create a private group like this before the repo is created. For existing sub-projects, we can auto-create that group in bulk and open an automated PR to update their SECURITY_CONTACTS with this group and also ask sub-project maintainers, as part of that PR to add any relevant members (maintainers) to it. |
The last round of PRs for this task languished due to my own neglect. @tallclair suggested a more simple approach of:
This does seem a more conservative approach, and hopefully less controversial. To that end I created a new issue, as the comment history on the old issues is quite long and noisy: @PushkarJ I think your proposal has some merit and could fit in step 2. However, I believe the consolidation of OWNERS and SECURITY_CONTACTS is the higher priority part for the SRC. |
SECURITY_CONTACTS files currently use github user names, but github doesn't have private messaging, and users don't always have public email addresses.
We need a better solution, so that the PSC is able to reach out to the security contacts through a private channel. A few ideas include:
/help
The text was updated successfully, but these errors were encountered: