Hi Jarek, we (Apache SkyWalking project) are using one of them (https://github.com/apache/airflow-cancel-workflow-runs). The tools listed here are very helpful, they save the resources by cancelling duplicated builds.
> I do not want to take any responsibility for it for other projects to use it > without them reviewing it. This is a really bad idea. I totally agree with your idea, at the other hand, we don’t really want to double the maintenance work if we could work together (by reviewing or contributing codes) instead of having another clone. I’m rather glad to review or add features to the existing repos. We (SkyWalking community) are also building some useful tools that may benefit more ASF projects, such as a license audit tool (http://github.com/apache/skywalking-eyes) that I believe most projects will need it, and I’d also like to see more contributors from other communities to join and make it better, instead of forking everywhere. Another idea from me is that if the infra team can evaluate whether such kind of tools are beneficial to ASF-wide projects and can be migrated into infra team, so that all other communities are more aware of them and can use / contribute to them. ————————— Zhenxu Ke (柯振旭) GitHub @kezhenxu94 > On Dec 27, 2020, at 23:05, Jarek Potiuk <jarek.pot...@polidea.com> wrote: > > I have now clones of the actions we've been using in Airflow but I know few > other projects are using it. > > I think I should NOT encourage others to use it. Not at all. If you want to > use them you should create your own clones. > The skywalking project switched to those but I am going to ask them to make > their own clone. > > Greg, others, > > Is there any way we can add it to the policy? I think it should be strongly > discouraged to use cross-project clones of the actions because of the > reasons explained below: > > Those are our clones: > > * potiuk/cancel-workflow-runs -> apache/airflow-cancel-workflow-runs : > https://github.com/apache/airflow-cancel-workflow-runs > * potiuk/get-workflow-origin -> apache/airflow-get-workflow-origin : > https://github.com/apache/airflow-get-workflow-origin > * TobKed/label-when-approved-action -> apache/airflow-label-when-apprved: > https://github.com/apache/airflow-label-when-approved > * LouisBrunner/checks-action -> apache/airflow-checks-action: > https://github.com/apache/airflow-checks-action > * ad-m/github-push-action -> apache/airflow-github-push-action: > https://github.com/apache/airflow-github-push-action > * aws-actions/configure-aws-credentials/ > -> apache/airflow-configure-aws-credentials: > https://github.com/apache/airflow-configure-aws-credentials > > But when I am thinking about it, I do not want to take any responsibility > for it for other projects to use it without them reviewing it. This is a > really bad idea. > > This basically shifts the trust from a 3rd-party (for example me personally > on potiuk account), to apache-airflow PMCs for any other projects using it. > And I do not think as a PMC of Airflow I want to take responsibility for > all the commits in those repos. > > Those repos are clones of someone else's code. And we will likely continue > simply pushing stuff there from the original repositories (after reviewing > the exact version that we are planning to use but nothing else). > > So I am not sure if this actually solves the problem that infra wants to > deal with. > > Of course, I cannot prevent anyone, if anybody wants to use those > repositories. But you are basically on your own if you want to use any of > those: > > * make sure you review if the exact version you want to use is > * Make sure you use commit hash as specified here: > https://docs.github.com/en/free-pro-team@latest/actions/learn-github-actions/security-hardening-for-github-actions#using-third-party-action > > J. > > > > On Sun, Dec 27, 2020 at 2:30 PM Jarek Potiuk <jarek.pot...@polidea.com> > wrote: > >> Sure. I perfectly understand, no problem and no hard feelings. I am not at >> all against such immediate actions, just to message >> >> I perfectly understand why it happened and I'd probably do the same. >> >> But I would try to at least warn everyone involved immediately after, >> explaining it was a necessity). >> >> And since the subject was raised and discussed before (and I was well >> aware of the potential threat), I would love to know what we can do >> to prevent things like this from happening in the future. After I deal with >> it and restore service for our users, I will try to find all the discussion >> threads about it, and maybe we can analyze why this was not picked up >> before and acted before? I think we could have prevented it. Maybe it's >> simply us @Airflow that we knew about it and did not raise it to the >> security team? Or maybe it was just missed among other problems raised in >> the same discussion? I think we should treat it as a learning experience. >> >> It would be great to find out how in the future we could help infra to act >> proactively rather than reactively in such cases. >> >> J. >> >> On Sun, Dec 27, 2020 at 2:26 PM Greg Stein <gst...@gmail.com> wrote: >> >>> We are all human, and fallible. Could we have resolved this earlier, and >>> rolled it out in a controlled manner? Yes. But we did not understand the >>> issue, and (thus) did not apply the restriction sooner. >>> >>> Volunteers help out Infra with alerts on JDK releases, about email >>> issues, etc ... We would certainly welcome more alerts/contributions when >>> these kinds of issues arise. >>> >>> And yes: DGruno noted in Slack that you were using a pinned version >>> (yay!). This isn't about Airflow, but about protecting the overall >>> Foundation attack surface. >>> >>> Thx, >>> -g >>> >>> >>> On Sun, Dec 27, 2020 at 7:04 AM Jarek Potiuk <jarek.pot...@polidea.com> >>> wrote: >>> >>>> Ok. Thanks. I understand now. >>>> >>>> But it would be great if you would explain the context in the >>>> announcement and try to be a bit more vocal (builds@ seems like a great >>>> place to announce such changes). >>>> >>>> It caught everyone by surprise. >>>> >>>> Again - the scenarios you explain were already discussed before (I have >>>> to now rush and fix stuff for our committers so I cannot find it quickly). >>>> I raised it a few months ago and it was a consensus to use >>>> https://docs.github.com/en/free-pro-team@latest/actions/learn-github-actions/security-hardening-for-github-actions#using-third-party-actions >>>> explains exactly what to do (using pinned hashes) which we rigorously >>>> follow and recommended everyone to do - to prevent exactly the scenarios >>>> you described. >>>> >>>> While I understand this approach can't be enforced (and the policy is >>>> reasonable), it could have been acted on before I think, and without such >>>> rush. >>>> >>>> J. >>>> >>>> >>>> On Sun, Dec 27, 2020 at 1:57 PM Greg Stein <gst...@gmail.com> wrote: >>>> >>>>> On Sun, Dec 27, 2020 at 6:54 AM Jarek Potiuk <jarek.pot...@polidea.com> >>>>> wrote: >>>>>> ... >>>>> >>>>>> Was it as a response to some security incident that would justify such >>>>>> immediate and disruptive action without an earlier warning? What was the >>>>>> reasoning behind this? >>>>>> >>>>> >>>>> Yes. >>>>> >>>>> >>>> >>>> -- >>>> >>>> Jarek Potiuk >>>> Polidea <https://www.polidea.com/> | Principal Software Engineer >>>> >>>> M: +48 660 796 129 <+48660796129> >>>> [image: Polidea] <https://www.polidea.com/> >>>> >>>> >> >> -- >> >> Jarek Potiuk >> Polidea <https://www.polidea.com/> | Principal Software Engineer >> >> M: +48 660 796 129 <+48660796129> >> [image: Polidea] <https://www.polidea.com/> >> >> > > -- > > Jarek Potiuk > Polidea <https://www.polidea.com/> | Principal Software Engineer > > M: +48 660 796 129 <+48660796129> > [image: Polidea] <https://www.polidea.com/>
