Re: Contour to CNCF sandbox
Matt Klein
If we are targeting sandbox IMO we can just do it. If incubation I think we need to route through SIG network (cc @Lee Calcote) for DD.
On Tue, Jan 7, 2020 at 3:17 PM Joe Beda <jbeda@...> wrote:
|
|
Re: Contour to CNCF sandbox
Matt Klein
The PR lists incubation as the desired level. So that is not accurate?
|
|
Contour to CNCF sandbox
Joe Beda <jbeda@...>
Hi all,
I know we’ve talked about not syncing on TOC meetings to get new projects in. As things stand, we have just submitted contour as a sandbox project and there is support from Alexis and Matt and me.
What do we want to consider necessary before we move forward? Do we want to have SIG-network take a look or do we want to just “make it so”?
Personally, I’d be cool with just getting it in but don’t want to jump the gun.
Joe
|
|
Re: An interesting issue wrt CLA
swinslow@...
Thanks for raising this. In the case of Dependabot, if it is only modifying version numbers and hashes to bump dependency versions, I don't think there is any realistic concern that this bot would be contributing copyrightable content. That might not be the case for other bots but in this case I don't see a concern.
Because of that, from the CNCF / LF side I think we would be comfortable with having Dependabot changes not being blocked by the CLA bot. I'm coordinating with the LF IT team to whitelist Dependabot so that it will not be gated for the k8s CLA bot going forward. Thanks, Steve
|
|
Re: [EXTERNAL] Re: [cncf-toc] An interesting issue wrt CLA
Matt Farina
What is the legal approach for a bot contributing code under a CLA? I'd be curious to know what the guard rails are. Then we can try to make the process as streamlined as possible. On Tue, Jan 7, 2020, at 2:34 PM, Brendan Burns via Lists.Cncf.Io wrote:
|
|
Re: [EXTERNAL] Re: [cncf-toc] An interesting issue wrt CLA
Brendan Burns
I will definitely ping GitHub folks about this, but I thought it useful to at least document the desired approach in general.
From: cncf-toc@... <cncf-toc@...> on behalf of Matt Farina via Lists.Cncf.Io <matt=mattfarina.com@...>
Sent: Tuesday, January 7, 2020 11:30 AM To: CNCF TOC <cncf-toc@...> Cc: cncf-toc@... <cncf-toc@...> Subject: [EXTERNAL] Re: [cncf-toc] An interesting issue wrt CLA
Dependabot is a service now owned by GitHub. Do we want to expect all people offering a service like this to sign the CNCF CLA and associate their bot with it? The person choosing to use the bot is different from those providing it and the person choosing
to use it is a member of the project.
This problem only affects those using the CLA. Dependabot appropriately signs for the DCO. The majority of CNCF projects are not affected by this issue.
Dependabot creates a PR like any other random person to come along on GitHub. A person with merge access has to merge the PR and the PR has to pass tests and review as if a person were suggesting the same change.
https://dependabot.com/#how-it-works
What would an attack vector for a bot like this be? If a bot had write access to the code I would be concerned.
A thought for this case... GitHub is a CNCF member and has a signed CLA (I assume) since GitHub employees contribute to Kubernetes. Is there someone there who can add Dependabots account to the CLA?
This would be the quick and easy approach. It would not scale to similar services.
- Matt Farina
On Tue, Jan 7, 2020, at 2:05 PM, Sarah Allen wrote:
|
|
Re: An interesting issue wrt CLA
Matt Farina
Dependabot is a service now owned by GitHub. Do we want to expect all people offering a service like this to sign the CNCF CLA and associate their bot with it? The person choosing to use the bot is different from those providing it and the person choosing to use it is a member of the project.
This problem only affects those using the CLA. Dependabot appropriately signs for the DCO. The majority of CNCF projects are not affected by this issue.
Dependabot creates a PR like any other random person to come along on GitHub. A person with merge access has to merge the PR and the PR has to pass tests and review as if a person were suggesting the same change. https://dependabot.com/#how-it-works What would an attack vector for a bot like this be? If a bot had write access to the code I would be concerned.
A thought for this case... GitHub is a CNCF member and has a signed CLA (I assume) since GitHub employees contribute to Kubernetes. Is there someone there who can add Dependabots account to the CLA? This would be the quick and easy approach. It would not scale to similar services. - Matt Farina On Tue, Jan 7, 2020, at 2:05 PM, Sarah Allen wrote:
|
|
Re: [VOTE] SIG Runtime
Hong Zhang <cathy.zhang@...>
+1 NB
Cheers, Cathy Zhang On 6 January 2020 at 21:39:42, Amye Scavarda Perrin (ascavarda@...) wrote: A new CNCF Runtime SIG has been proposed with Brian Grant and BrendanAmazon Data Services Ireland Limited registered office: One Burlington Plaza, Burlington Road, Dublin 4, Ireland. Registered in Ireland. Registration number 390566.
|
|
Re: An interesting issue wrt CLA
Sarah Allen
Bots can have delegated authority to sign things on behalf of their makers. It seems like it would be even more important for this kind of a bot to have a signature since if it was compromised or impersonated (can I say that about a bot?) that could be a pretty powerful attack vector. Thanks for raising this question! Sarah
|
|
An interesting issue wrt CLA
Brendan Burns
Folks,
See:
Dependabot is automatically generating a PR to update vulnerable dependencies, but of course the CNCF CLA is required, and dependabot (being a bot) has no ability to sign.
Any thoughts about the right approach here? (for this specific one I'm going to clone the PR myself, but in general it's an interesting issue)
Thanks
--brendan
|
|
Re: [VOTE] SIG Runtime
Kiran Mova
+1 NB
On Tue, Jan 7, 2020 at 11:04 PM Hausenblas, Michael via Lists.Cncf.Io <hausenbl=amazon.com@...> wrote: +1 (nb)
|
|
Re: [VOTE] SIG Runtime
Hausenblas, Michael
+1 (nb)
Cheers, Michael -- Developer Advocate @ AWS +353 86 0215164 On 6 January 2020 at 21:39:42, Amye Scavarda Perrin (ascavarda@...) wrote: A new CNCF Runtime SIG has been proposed with Brian Grant and Brendan BurnsAmazon Data Services Ireland Limited registered office: One Burlington Plaza, Burlington Road, Dublin 4, Ireland. Registered in Ireland. Registration number 390566.
|
|
Re: [EXTERNAL] Re: [cncf-toc] [VOTE] SIG Runtime
Li, Xiang
toggle quoted messageShow quoted text
------------------------------------------------------------------
|
|
Re: [EXTERNAL] Re: [cncf-toc] [VOTE] SIG Runtime
Brendan Burns
+1, binding
--brendan
From: cncf-toc@... <cncf-toc@...> on behalf of Brian Grant via Lists.Cncf.Io <briangrant=google.com@...>
Sent: Tuesday, January 7, 2020 8:25:17 AM To: Liz Rice <liz@...> Cc: cncf-toc@... <cncf-toc@...> Subject: [EXTERNAL] Re: [cncf-toc] [VOTE] SIG Runtime +1 binding
On Tue, Jan 7, 2020 at 6:49 AM Liz Rice <liz@...> wrote:
|
|
Re: [VOTE] SIG Runtime
Brian Grant
CNCF SIGs should not affect Kubernetes SIGs.
On Tue, Jan 7, 2020 at 7:41 AM Ricardo <raravena80@...> wrote:
|
|
Re: [VOTE] SIG Runtime
Brian Grant
+1 binding
On Tue, Jan 7, 2020 at 6:49 AM Liz Rice <liz@...> wrote:
|
|
Re: [VOTE] SIG Runtime
Haining Zhang
+1 nb
On 1/7/20 5:39 AM, Amye Scavarda Perrin
wrote:
|
|
[RESULT] SIG Network (Approved)
Amye Scavarda Perrin
The CNCF Network SIG has been approved: https://github.com/cncf/toc/pull/317 Binding: 6/9 Matt Klein: https://lists.cncf.io/g/cncf-toc/message/3757 alexis richardson: https://lists.cncf.io/g/cncf-toc/message/3759 Jeff Brewer: https://lists.cncf.io/g/cncf-toc/message/3781 Liz Rice: https://lists.cncf.io/g/cncf-toc/message/3783 Joe Beda: https://lists.cncf.io/g/cncf-toc/message/3789 Xiang Li: https://lists.cncf.io/g/cncf-toc/message/3806 Non-Binding: Lee Calcote: https://lists.cncf.io/g/cncf-toc/message/3752 Dave Zolotusky: https://lists.cncf.io/g/cncf-toc/message/3753 Gou Rao: https://lists.cncf.io/g/cncf-toc/message/3754 Alex Chircop: https://lists.cncf.io/g/cncf-toc/message/3755 Jon Mittelhauser: https://lists.cncf.io/g/cncf-toc/message/3756 Xing Yang: https://lists.cncf.io/g/cncf-toc/message/3758 Ken Owens: https://lists.cncf.io/g/cncf-toc/message/3762 Suresh Krishnan: https://lists.cncf.io/g/cncf-toc/message/3763 Roger Klorese: https://lists.cncf.io/g/cncf-toc/message/3764 Anil Vishnoi: https://lists.cncf.io/g/cncf-toc/message/3766 Golfen Guo: https://lists.cncf.io/g/cncf-toc/message/3768 Jeyappragash Jeyakeerthi: https://lists.cncf.io/g/cncf-toc/message/3770 Steven Dake: https://lists.cncf.io/g/cncf-toc/message/3773 Nicola Marco Decandia: https://lists.cncf.io/g/cncf-toc/message/3774 Kiran Mova: https://lists.cncf.io/g/cncf-toc/message/3776 Michael H Payne: https://lists.cncf.io/g/cncf-toc/message/3782 Chris Short: https://lists.cncf.io/g/cncf-toc/message/3795 Natraj Thuduppathy: https://lists.cncf.io/g/cncf-toc/message/3796 Klaus Ma: https://lists.cncf.io/g/cncf-toc/message/3799 Amye Scavarda Perrin | Program Manager, CNCF | amye@...
|
|
Re: [VOTE] SIG Runtime
Ricardo Aravena
Xu, AFAIK, k8s sig-node should remain as it is. Part of this group's focus would be working with sig-node so that runtimes can interface with k8s. For example, having a particular runtime implement the CRI. Thx, Ricardo
|
|
Re: [VOTE] SIG Runtime
Liz Rice
+1 binding (on the assumption the minor details in the PR get addressed)
-- Liz Rice
@lizrice | lizrice.com | +44 (0) 780 126 1145
On 7 Jan 2020, 14:00 +0000, Pengfei Ni , wrote:
|
|