Manually reviewing third party actions would be comparable to reviewing shared libraries in Jenkins or Maven plugins or similar. Since the code runs in a privileged context, allowing arbitrary git repositories to take part would allow for supply chain attacks. While pinning to a commit is a good workaround, it doesn’t substitute for a security review.
On Sun, Dec 27, 2020 at 09: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/> >
