Re: SECURITY_CONTACTS files

[Jordan Liggitt]

I agree we want to avoid having to maintain N additional private mailing lists.

On Thu, Jul 23, 2020 at 12:00 AM 'Benjamin Elder' via kubernetes-sig-architecture <kubernetes-si...@googlegroups.com> wrote:

Moving usernames to a mailing list moves stepped down users etc. to the mailing list allowed subscribers (surely it wouldn't be a public read list...) instead of the file, I don't see how this actually solves the problem.

GitHub handle => email is straightforward.

On Wed, Jul 22, 2020, 20:32 Lubomir I. Ivanov <neol...@gmail.com> wrote:

forwarded to kubernetes-security-discuss:

On Thu, 23 Jul 2020 at 06:26, Lubomir I. Ivanov <neol...@gmail.com> wrote:
>
> hello,
>
> as you may have seen Joel Smith from the Product Security Committee
> has recently created a number of tickets in the kubernetes/kubernetes
> repository to update SECURITY_CONTACTS files in our staged
> repositories. this is due to the PSC delegating the per-repository
> security contact to the repository owners.
>
> e.g.
> https://github.com/kubernetes/kubernetes/issues/92092
> https://github.com/kubernetes/kubernetes/labels/committee%2Fproduct-security
>
> for reference, the SECURITY_CONTACTS idea was announced here:
> https://groups.google.com/forum/#!topic/kubernetes-dev/codeiIoQ6QE
>
> instead of including individuals and given this is not part of GitHub
> user automation, can we have the SECURITY_CONTACTS files direct users
> towards mailing list email addresses where volunteers from SIGs can be
> on rotation?
>
> for example:
> - SIG Foo can have a "sig-foo-security" mailing list.
> - all repositories owned by SIG Foo can have "sig-foo-security"
> present in SECURITY_CONTACTS.
> - it would be up to the SIG to keep the security mailing list up-to-date.
>
> the current method has a couple of issues:
> - can be noisy if regular changes are required.
> - a GitHub username *is not* really a security contact unless it
> matches the local-part of an email address or a slack nickname (i'm
> excluding communication on private GitHub repositories as a scenario).
> - suffers from the same problem as OWNERS files; a person steps down
> from working on the project and the enumerated contact is no longer
> active.
>
> lubomir
> --

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAGDbWi9uNJLiV5FY%3DnCD9ANRbjCK58MmnKNiEXggOqNH1pn%3DQQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAOZRXm9bPnZ7%2BSfoxJ2d8yhGN%2B1BDquRNu6%2Bv_M%3DjCbqFMpz%3Dg%40mail.gmail.com.

[Tim Allclair]

Adding back +kubernetes-security-discuss (I updated the permissions so anyone can post). For the full context on the discussion so far, you can view the thread on kubernetes-sig-architecture: https://groups.google.com/d/topic/kubernetes-sig-architecture/0MUJBDGf3jg/discussion

@John - that's a good point. I like the idea of adding it to the approvers requirements, if we go that route.

On Fri, Jul 24, 2020 at 10:11 AM 'John Gardiner Myers' via kubernetes-sig-architecture <kubernetes-si...@googlegroups.com> wrote:

On Thursday, July 23, 2020 at 11:54:31 AM UTC-7, Tim Allclair wrote:

3. We default to contacting the approvers when security-contacts aren't specified. It is up to the PSC what depth to reach out to for approvers (probably not too much of a concern outside of k/k).

 I was recently made an approver for a subproject. As a consequence I was added to that subproject's communication mechanism for security incidents. At no point was I informed of or asked to abide by the Embargo Policy. I only know about it because I read the (out of date) SECURITY_CONTACTS file.

While I believe it is reasonable to equate approvers with security contacts, I would suggest that this responsibility and the requirement to abide by the Embargo Policy be added to the approver section of https://github.com/kubernetes/community/blob/master/community-membership.md

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/58f55ff9-1cd9-4d18-9c27-395e232661a8o%40googlegroups.com.

[Lubomir I. Ivanov]

hello,

the security contacts issues in k/k seem to remain open and are marked
as frozen:
https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+label%3Acommittee%2Fproduct-security+%22Security+contacts%22

was there any further discussion on how to proceed?

On Thu, 23 Jul 2020 at 21:54, Tim Allclair <tall...@google.com> wrote:
>> I propose that:
>> 1. We get rid of the SECURITY_CONTACTS file. It is also confusing once we add SECURITY.md
>> 2. We add a new _optional_ section to OWNERS files, something like `security-contacts:`

>> 3. We default to contacting the approvers when security-contacts aren't specified. It is up to the PSC what depth to reach out to for approvers (probably not too much of a concern outside of k/k).
>>

>> What do you think? I'm assuming the top level approvers are a pretty good proxy for security contacts in most cases. I know the owners can get out of date, but we already have some processes for keeping OWNERS up to date.

like i mentioned, i think this is a good idea. i can help with PRs
around these efforts if this is how the security committee would like
to proceed?

i've also verified in k/test-infra that the field in some OWNERS files
"emeritus_approvers" is not tracked in a structure, which tells me
that there is no strict parsing of OWNERS files and a
"security_contacts:" field can be optionally added without updating
code in that repository.

so removing SECURITY_CONTACTS files would immediately enable the
fallback to approvers as security contacts.
the addition of "security_contacts:" can be optional and a matter of
documentation + notification to the mailing lists if the change comes
in action.

lubomir
--

[Tim Allclair]

@PSC - It looks like this was on the agenda for last weeks meeting, but I joined late and missed it. Were there any conclusions?

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAGDbWi9b3t5XRBfZkzFh8pLdYWOhFWD7O5TYDpBV_G%2BHsqk4fw%40mail.gmail.com.

[Joel Smith]

+sfowler

We think that the best way forward is to go with Tim's plan below. (Remove SECURITY_CONTACTS, add an optional section to OWNERS, default to approvers if not present).  Sam Fowler, one of the Associate Members of the PSC expressed interest in helping with this effort. I will work with him to get it underway. We'll close those issues as we go.

Thanks,
Joel

You received this message because you are subscribed to the Google Groups "kubernetes-security-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-security...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-security-discuss/CALXpagx7yWt1S4mU4ztrcH1wiic2NSBrwkAmAYeWG7cZ4NbA%2BA%40mail.gmail.com.

[Lubomir I. Ivanov]

thank you, i can notify maintainers of the repositories that SIG
Cluster Lifecycle owns (quite a few) to remove the SECURITY_CONTACTS
files, but i'm assuming you are going to run automation using
something like "hub" across the whole GitHub orgs to file the PRs.

lubomir
--

> Thanks,
> Joel

[Sam Fowler]

Yep, this effort overlaps a lot with the below issue, which I had planned on working on as part of my Associate membership.

https://github.com/kubernetes/security/issues/56

We should hopefully be able to resolve all related issues in one swoop.