+1 On Tue, Feb 22, 2022 at 11:52 AM Jarek Potiuk <[email protected]> wrote:
> 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? >>>>> >>>> >> >>
