Pushing code - true. But opening a PR requires either a UI access or generated token (which has expiry and requires MFA). So you should not be able to open multiple PRs with stolen SSH key. Which limits potential damage you can do.
With UI/token access you could actually make all our machines busy mining Bitcoin in no time. With SSH key you would be limited to how many opened PRs the user already has. But regardless, actually i think promoting MFA this way is just worthy anyway even if it is not strictly necessary - as pure security education, so +1 on that one Elad. J wt., 22 lut 2022, 16:27 użytkownik Ash Berlin-Taylor <[email protected]> napisał: > MFA doesn't do much to protect against malicious code pushes via stolen > SSH keys so I don't think this is a necessary pre-condition, but we could > do it anyway (or ensure MFA is on by inviting them to another GH org) > > -a > > On 22 February 2022 08:53:00 GMT, Elad Kalif <[email protected]> wrote: >> >> +1 >> >> I would like to suggest we make a requirement that the trusted user has 2F >> authentication >> <https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication> >> set to reduce the risk of hacking the account. >> I think by joining the triage group ASF verifies it so there are some >> benefits to it. If we decide against the triage group then I guess the >> sponsor should verify it(?) >> >> On Tue, Feb 22, 2022 at 12:11 AM Vikram Koka <[email protected]> >> wrote: >> >>> +1 >>> >>> I really like the road to committership perspective on this as well! >>> I also like the suggestion of a periodic (ideally automated) clean up of >>> this list for inactive users and committers as well. >>> >>> >>> >>> On Fri, Feb 18, 2022 at 7:54 AM Jarek Potiuk <[email protected]> wrote: >>> >>>> +1. That will be a huge one and actually adds an interesting "path to >>>> committership" intermediate step. Being a committer (for code) is >>>> mostly the trust in the person that they can approve other's code. >>>> This will be "trust that they can run their code on our >>>> infrastructure". >>>> >>>> The nice thing about it is all trackable as well - which is enough >>>> reason for no-one doing anything bad. And those permissions cannot >>>> really impact much more than mostly impacting results of other CI >>>> builds and potentially ab-using the power of our self-hosted machines >>>> (which is not worthy to abuse just this one single repo - it would >>>> only make sense if you find a mass way of abusing it). >>>> >>>> And if we trust people also because they are in a work relationship - >>>> this is quite a good "trust" reason, >>>> >>>> One thing that I would add - it could be great to add a periodic >>>> (automated ? ) cleanup of the list for inactive users (maybe even >>>> inactive committers in this case)? This will - in the long run - make >>>> the list more "accurate" and easier to maintain. Also There is this >>>> (unlikely) even when GitHub user changes the username, there is >>>> currently no good protection from someone actually "taking over" the >>>> github name, so keeping the list to only "recently active" might help >>>> with that a lot. >>>> >>>> >>>> J. >>>> >>>> On Fri, Feb 18, 2022 at 4:07 PM Ash Berlin-Taylor <[email protected]> >>>> wrote: >>>> > >>>> > Hi all, >>>> > >>>> > I'd like to propose we start allowing more users to use the >>>> self-hosted runners -- they are much much quicker to run test workflows. >>>> And by making promising people's tests run quicker hopefully we can >>>> encourage them to make more PRs and continue on the path towards becoming a >>>> committer. >>>> > >>>> > Currently only committers and PMC members test builds are run using >>>> the self-hosted runners, everyone else has to use the GitHub public >>>> runners. The "stuck in queue" issue doesn't plague us much anymore (I >>>> think?), but the main issue is still that the GitHub runners only have 8GB >>>> vs the 64GB of the self-hosted (half of which is used as RAM FS) and as a >>>> result they are much, much slower. >>>> > >>>> > So I propose that we "allow users we trust" to run on the self-hosted >>>> runners. This is purposefully a lighter weight process than adding those >>>> users to the Triage group (which we need to have a "vote"/mailing list for >>>> and then ask ASF Infra team to make the changes to) and is essentially a >>>> way to make the contributing process nicer for those that have shown >>>> interest and promise. >>>> > >>>> > I am thinking that this would often be used for "this person is >>>> making a number of good quality PRs, and is on the road to being a >>>> committer". >>>> > >>>> > In terms of project process, all I'm envisaging is that this requires >>>> a PR to add someone's GitHub username to >>>> https://github.com/apache/airflow/blob/366c66b8f6eddc0d22028ef494c62bb757bd8b8b/.github/workflows/ci.yml#L80-L123 >>>> and then the "normal" review process to get the change merged. >>>> > >>>> > By adding a user to that list the committer/PMC member is saying "I >>>> am sponsoring this user and trust them to not be malicious". >>>> > >>>> > There will be a bit more work to finish this off, namely we'll need >>>> to get https://github.com/apache/airflow-ci-infra/pull/20 finished and >>>> working. >>>> > >>>> > We should probably be aware that if we do this it will likely be >>>> "people we (committers) work with" in the first instance. Are we okay with >>>> that, even if they haven't yet contributed (much/at all) to Airflow? >>>> > >>>> > Are there any other criteria that people thing we should apply before >>>> adding users to this list? >>>> > >>>> > Thoughts? >>>> >>> > >
