Requiring 2FA for Jupyter GitHub Orgs

[rpwagner]

Problem

GitHub accounts without 2FA are at higher risk of compromise. This could impact the integrity of the source code, or even disrupt access to GitHub.

Proposed Solution

Make 2FA a requirement at the GitHub organization level.

Additional context

Hi,

We're touching base on behalf of the Security Subproject about the goal to have 2FA enabled for all the Jupyter GitHub orgs by the end of September.

Let us know if you would like help contacting any of your members without 2FA, or figuring out a process for jupyterlab. Someone from the Security Subproject would be glad to join one of your team meetings to discuss the least disruptive way to get this done for your GitHub org. We also invite anyone interested to join our Security Subproject meetings.

How to do this for your org and contributors will depend on several things. Here are some suggestions to get started:

• Try to avoid publicly disclosing any GitHub usernames without 2FA.
• Remember: Access can always be restored. If you remove someone’s access it can be returned once they enable 2FA.
• Start by reviewing the critical accounts, namely GitHub organization or repository owners and admins. Encourage them to enable 2FA since these have the highest risk if they were compromised.
• After these high-risk accounts, review the accounts that have access to only a few repos and haven’t been active in a while (interns, occasional contributors, etc.). Consider removing their access and then sending them an email explaining why, and offering to restore access when they have 2FA enabled and are ready to contribute, again.
• For the rest of your members, you can send links to the Jupyter Blog post or Discourse topic.

We appreciate your time and effort to help improve the trust the Jupyter Community has in our work.

Once one of the jupyterlab GitHub org owners has enabled 2FA, we’d appreciate an update, either on this issue, or as an email to [email protected].

Many thanks!

–Rick & @rcthomas

P.S. This will be posted on a few team-compass repos today, so apologies to those of you who contribute to many areas.

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[fcollonval]

Thanks for reaching out @rpwagner and @rcthomas.

I find out how to list the organization users without 2FA. But do you know a way to contact them privately to warn them about the 2FA enforcement?

[rpwagner]

@fcollonval that is a great question--great as in it's not straightforward. Like we talked about in the meeting today, here's what I've come up with:

• GitHub doesn't have a private messaging system, so we're left with email, tagging a user in issues on private repos, or some other medium, like Slack or Discourse.
• Email addresses can be found on some GitHub profiles, from commit logs, or other links from the user. This is time consuming, but the Security Project is willing to gather these and share them privately with the jupyterlab GitHub org owners.
• If you want to use email, we can also help draft an email for you, or send one on your behalf, maybe making heavy use of BCC.
• Finally, you could set up a private repo just for this effort and tag a bunch of users in an issue. This would also be time consuming, since you would need to add all those users as collaborators to that repo. But, you could delete the repo afterwards.

[rcthomas]

@rpwagner GitHub's API may provide some email addresses more manageably, e.g., https://stackoverflow.com/a/44229207 but contributors from long ago of course could have abandoned the listed email addresses too.

[rpwagner]

As we're learning about this from working with other Subprojects, another option is to reinstate members if they're removed by enabling 2FA. This will send them an invite back into the organization with the same roles and permissions that they can accept after they enable 2FA.

[rpwagner]

@fcollonval as part of talking to the jupyter-server team, we wanted to know what GitHub would send to the user if they are removed because of the org enabling 2FA. Below is redacted screenshot of the email I received when I triggered the removal of one of my build accounts from a different org. This seems very appropriate (credit to GitHub) and clear communicates everything we would want.

If you decide to go ahead with enabling 2FA and aren't able to contact users ahead of time, at least we know they will be sent the necessary information.

[fcollonval]

Thanks a lot for sharing @rpwagner

[Carreau]

You can find the list of members here – there are both "members" and "outside collborators" tabs, if you have the right permissions as some people have their membership to private.

You can head to https://github.com/orgs/jupyterlab/teams/, in there the is a secret team (invisible to non-members and non-owner I believe) click on it and you can start a team-level discussion that only member of this team will see.

You can add and then ping folks that do not have 2FA to this team.

That will prevent having to create a separate private repo.

[fcollonval]

thanks for creating the team @Carreau

[rpwagner]

Hi,

This is a polite nudge to see if JupyterLab is ready to enable 2FA. So far, we're finding that the GitHub notifications are appropriate for the users we weren't able to contact to directly and that there's support within the community. If you prefer, the Security Subproject can make the actual change sometime before the end of the month.

Thanks

[rpwagner]

Good morning from California! I believe this is completed. Thank you for helping us to meet this goal and enabling 2FA on the JupyterLab org.

If you have any comments or feedback on the process, please share them. We want to ensure that all future security-related efforts have similar support from all the Subprojects. You can drop an issue the Security Subproject repo.