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/>
