Dealing with workflow execution restriction following enforcement of more stringent security rules

jupyterlab / frontends-team-compass

A repository for team interaction, syncing, and handling meeting notes across the JupyterLab ecosystem.

https://jupyterlab-team-compass.readthedocs.io/en/latest/

BSD 3-Clause "New" or "Revised" License

59 stars 30 forks source link

Dealing with workflow execution restriction following enforcement of more stringent security rules #256

Open fcollonval opened 3 months ago

fcollonval commented 3 months ago

Description

Follow-up of https://github.com/jupyterlab/frontends-team-compass/issues/251#issuecomment-2249825259

I looked at how best handle the current situation that prevents the update job to be executed on non-member PRs. It looks like the easiest would be to create a team with Read access (aka nothing more than what you can do on public repo) in which we invite trusted contributor as outside collaborator. For example I invited a GSoC contributor for test purpose (should be dropped at the end of this meeting if the approach is deemed wrong): image Then on https://github.com/jupyterlab/jupyterlab/pull/16438#issuecomment-2247942877, the first update snapshot comment failed (she was not yet a collaborator). The second passed (she accepted the invitation).

jtpio commented 3 months ago

Some questions:

what are the criteria for someone to be added to that list as outside collaborator? Should this apply to one-of contributors, or should there be a minimum number of PRs merged before someone can be added to that list?
should there then be a team of "regular contributors", for those who often contribute but are not part of the council?
when should someone be removed from that list?

Overall the "Read" permission is probably fine and low risk. It's more about guidelines for JupyterLab maintainers for how to manage that list.

fcollonval commented 3 months ago

what are the criteria for someone to be added to that list as outside collaborator? Should this apply to one-of contributors, or should there be a minimum number of PRs merged before someone can be added to that list?

What about as soon as they open a second PR? So we don't add one shot contributors.

should there then be a team of "regular contributors", for those who often contribute but are not part of the council?

Definitely better to use a team as it is easier to manage and to audit for security.

when should someone be removed from that list?

That one is always tricky. We could set up a job like we do for the council with a rule like every six months, list regular contributors who haven't contribute in the last six months. Then we could remove those.

krassowski commented 3 months ago

Ah, I just saw that it is not only that non-members cannot invoke the update, but it cannot be invoked even by members on non-member PRs. I think this needs to be changed.

For example see: https://github.com/jupyterlab/jupyterlab/pull/16341 with https://github.com/jupyterlab/jupyterlab/actions/runs/10330748123/job/28600154607