Not speaking for INFRA (I am but a humble user of INFRA services) but my comments below.
On Tue, Dec 29, 2020 at 2:12 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Jarek>Github Action can use the GITHUB_TOKEN to perform write operations to > anything in the repo > > Once again: GITHUB_TOKEN has to be explicitly used in the YAML file. > If GITHUB_TOKEN is not mentioned in the YAML, then write access is NOT > possible. > Yes. And this is a valid and useful case to keep. As you see we use it in airflow extensively. Forbidding using GITHUB_TOKEN is not an option for us. We need it. We can still move the actions to apache repos (we did) so the decision from Infra has a good workaround to follow. Just clone the actions you use to new repos (those can be created easily with self-service ASF tools) Just to repeat again: GITHUB_TOKEN is needed in many cases. Jarek>This is exactly what Greg is writing about > > Greg's message was very vague, so I asked for clarification. > I hope my explanations help :) > > Jarek>Basically, any non-trivial action will likely have the requirement to > add GITHUB_TOKEN > > Should infra forbid non-trivial workflows then? > Not at all. The cases where GITHUB_TOKEN is needed are very much legitimate and needed. > Why should others suffer? > Indeed people suffered. You just were just hit by the hard reality, that sometimes suffering is unavoidable and that sometimes you suffer not because of your fault. The action was apparently because of a security incident. I personally spent half of the after-Xmas Sunday restoring the service to our users, moving 7 repositories in and discussing with GitHub support because they blocked my account due to an infinite loop of jobs (30K/hour) that were triggered as the result. The action was apparently because of a security incident. While I do not think that was the best timing and that communication should be better, rather than whining and complaining I simply raised my concerns and then did my job - and did what I could - moved the repos in. It's not for me to judge if the call was justified and how big a problem the incident was but I have full trust that the infra team did what they had to do as a short-term remedy. If someone started to actively exploit it against Apache projects, it would be plain stupid not doing it (and yes we suffered because of that). Now I hope we can discuss it and find a good "long-term" solution. By making some constructive proposals and understanding the consequences (which I think this discussion is all about). I really hope that all of us + infra will find a good solution. But we need to cooperate. > > The action to deny third-party actions looks too intrusive, and the > risks/damage of a runaway action > does not seem to exceed the risks of adding a compromised dependency / > compromised build system plugin. > This is for infra to judge, not for me or you. I personally think neither you nor I have any data to make the call. I have no slightest idea how you've reached that conclusion, to be honest. You do not know what was the incident. We do not know what was the extent of the security incident (and maybe we won't ever find, as this is usually confidential stuff). So judging what was worse, is completely outside of my or your realm I am afraid. > > Jarek>But those practices are very difficult to enforce > > One of the approaches would be to forbid committing GITHUB_TOKEN. > I think Greg was very clear in his message that after reacting to the security incident - this is the right time to start discussion on what INFRA can do next. I believe it was not possible to forbid GITHUB_TOKEN in the short term, that the INFRA got for reaction to the security incident. We might discuss it as an option to follow but I can tell you immediately that this is something we need badly. So even if this is going to be one of the options in the future, it must be only one option. And also, it has to be supported by GitHub. The "restrict only to the organization" was a change that could be implemented by the configuration of the organization and was immediately in effect and with a single flip of a config, all the Apache repos were immediately cut off from anyone trying to exploit the vulnerability. I think it was great that there was such an option and making a bold decision like that is something that I have full trust INFRA team did because I believe and Greg confirmed that they had a very good reason to do it. > GitHub Actions doc>This means that a compromise of a single action within a > workflow can be very significant, > GitHub Actions doc>as that compromised action would have access to all > secrets configured on your repository > > > A compromise of a single build script plugin can be very significant, as > that compromised code > would have access to all secrets configured on developer (committer/PMC) > machines, > it would have access to all secrets configured on ASF Jenkins, and so on. > > Does that mean the next step is to forbid all non-ASF build systems and the > corresponding plugins? From what I know, INFRA already controls and reviews all plugins that are installed in the ASF Jenkins (at least that was the case where I was involved in the Apache Beam Infrastructure upgrade project). This was a major pain for us because we had to first do the tests on our local Jenkins and then ask INFRA to install the plugins. But it turns this is a really wise approach in retrospect from the INFRA side. AFAIK other build systems do not have similar plugin systems with such an issue. But if you do know of any system like that, I really urge you to IMMEDIATELY write to secur...@apache.org - to let them know. I believe if a similar issue exists in other systems, they should be immediately disabled. Not in the future or as a next step, but NOW. So please, if you know of any such system, please take immediate action, because it puts in danger some projects (and please do not write it here - the builds group is publicly readable, and by disclosing such problems publicly before they are fixed you put those systems in greater danger - this is a "responsible disclosure" policy. > > Vladimir On Tue, Dec 29, 2020 at 2:12 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Jarek>Github Action can use the GITHUB_TOKEN to perform write operations > to anything in the repo > > Once again: GITHUB_TOKEN has to be explicitly used in the YAML file. > If GITHUB_TOKEN is not mentioned in the YAML, then write access is NOT > possible. > > Jarek>This is exactly what Greg is writing about > > Greg's message was very vague, so I asked for clarification. > > Jarek>Basically, any non-trivial action will likely have the requirement > to add GITHUB_TOKEN > > Should infra forbid non-trivial workflows then? > Why should others suffer? > > Apache Calcite, Apache JMeter use GitHub actions, and GITHUB_TOKEN is not > used at all. > The action to deny third-party actions looks too intrusive, and the > risks/damage of a runaway action > does not seem to exceed the risks of adding a compromised dependency / > compromised build system plugin. > > Jarek>But those practices are very difficult to enforce > > One of the approaches would be to forbid committing GITHUB_TOKEN. > > GitHub Actions doc>This means that a compromise of a single action within > a workflow can be very significant, > GitHub Actions doc>as that compromised action would have access to all > secrets configured on your repository > > A compromise of a single build script plugin can be very significant, as > that compromised code > would have access to all secrets configured on developer (committer/PMC) > machines, > it would have access to all secrets configured on ASF Jenkins, and so on. > > Does that mean the next step is to forbid all non-ASF build systems and > the corresponding plugins? > > Vladimir > > -- Jarek Potiuk Polidea <https://www.polidea.com/> | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea] <https://www.polidea.com/>
