dvzrv
commented
4 years ago This makes a lot of sense from an organizational and from a security point of view and I very much welcome this incentive. Speaking from experience with other github organizations:
- archlinux doesn't allow members without 2fa, has very strict policies on who is allowed a maintainer role
- linuxaudio doesn't allow maintainer roles without 2fa
Especially in the first case the motivation behind this has been occurences such as the gentoo organization hack in 2018, which luckily did not have serious repercussions for users of the distribution (unnoticed this would have been a complete disaster though, potentially affecting thousands of systems worldwide).
What can be learned from these problems is though, that the fewer people with far-reaching access rights are in an organization, the better. IMHO people such as distribution maintainers, release managers and maintainers of widely used software should ensure, that they increase their effort in securing their access as much as possible (e.g. using 2fa hardware tokens such as nitrokey or yubikey). Failing to do so opens the door to supply chain attacks which can have far reaching and very damaging implications for thousands of people. Running an organization of this size means a lot of responsibility and I assume no one would like to get into a situation in which accidentally source code or binary content containing malware is shipped or control over the supercollider organization is lost.
dyfer
mossheim
Motivation
note a terminology point, there are 2 sets of permissions here: "organization level" and "repo level".
this was a topic at the last dev call. right now, there 17 people with owner-level permissions in the organization. of them, only 5 people have 2-factor authentication enabled. in addition, all 24 members of the core team have admin-level permissions to the supercollider, supercollider-language, sc3-plugins, and website repos.
owner-level organization permissions mean:
admin-level repo permissions mean:
having this many people with this kind of access on the project is a significant and unnecessary security concern. first, because not using 2FA makes one's account more vulnerable to becoming compromised. second, because changes made by people with these permission levels do not always produce notifications (for example, replacing a release artifact on a published release which could be downloaded onto thousands of systems!). third, because it increases the chances for accidents to happen. it's a disaster waiting to happen; i literally think about this when i lie awake at night :joy:
Description of Proposed Feature
for now, i'd like to propose these changes, which seem reasonable to me and will greatly increase the security of the project:
note that all these actions are already viewable in the organization's audit log, but this gives an extra layer of transparency.
Plan for Implementation
if there's no objections to the contrary (1) and (2) can be implemented right away and a notice sent out (to sc-dev, slack # dev, and scsynth.org).
for (3) and (4), i would just like to email everyone individually to see if they would like to keep their owner-level permissions, and if so, that they enable 2FA. anyone who does not respond and/or enable 2FA within 2 weeks will also have their permissions revoked.
forgive me this one ping please -- i feel that for the sake of transparency these people should know this conversation has been started. the people with owner level permissions currently are:
@adcxyz @brianlheim @crucialfelix @danstowell @gusano @jamshark70 @jleben @joshpar @joslloand @LFSaw @lijon @miguel-negrao @muellmusik @Sciss @scztt @sicklincoln @telephon