For the records - I also looked up the discussion we had about the
Github Action issues
That was a discussion on 7th of October on priv...@airflow.apache.org (for
those who have access there - here is the link:
https://lists.apache.org/thread.html/re92b77f64e5923ec0044edf3a060339b9e170f9438e2fde08
Ok. The issue is solved for Airflow now. We moved 7 repos in and merged PR
changing the location, enabled workflows back and it seems to be back to
normal - but I think we need to conclude the discussion and make good
learning from the problem.
If anyone has similar problems, GitHub support confir
FYI. Following Github Advise - I disabled the workflows manually and seems
that it stopped the infinite loop.
Anyone else having a similar issue should do the same I think.
J
On Sun, Dec 27, 2020 at 4:32 PM Jarek Potiuk
wrote:
> I updated the
> https://issues.apache.org/jira/projects/INFRA/is
| While pinning to a commit is a good workaround, it doesn’t substitute for
a security review.
Absolutely. And we do review the particular commit we want to switch to. We
do it since this commit as of October 7th in Apache Airflow when we
discussed and realized the threat:
https://github.com/apach
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
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 wo
I updated the
https://issues.apache.org/jira/projects/INFRA/issues/INFRA-21234 but I
think we might have even bigger problem.
I think disabling my account did not help.
It looks like the infinite loop is still running ... In Airflow we continue
having 30K failed jobs/hour...
I think you will ha
I think we have far bigger problem now.
Seems that the change triggered an infinite loop of some kind and my user
now is disabled from Github Actions. I pushed a change just before the
policy change went live. I guess other people might have similar pro
J.
Hello Jarek,
I work on the Support te
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 ma
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).
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 cert
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
On Sun, Dec 27, 2020 at 6:54 AM Jarek Potiuk
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.
"badly executed" occurs when we believe there is a *security* issue.
Using an action defined by a third party, which might modify Apache
repositories in unknown ways ... not something we want.
Or when a PMC determines that third party Action is safe, in April, but
then gets compromised in August
Question:
Do you think it was a good idea, to restrict it on Sunday right after Xmas
literally two minutes after it has been announced on users@, where really
builds@ is the list we are mostly discussing stuff related to builds?
I am sure you do realize that this way you force all the project
mai
Ok. IT works after logging. I will make another comments shortly after
subscribing to the list but I think this was very badly executed.
J.
On Sun, Dec 27, 2020 at 1:38 PM Jarek Potiuk wrote:
> the link does not work
>
> On Sun, Dec 27, 2020 at 1:34 PM Roy Lenferink
> wrote:
>
>> This is rel
the link does not work
On Sun, Dec 27, 2020 at 1:34 PM Roy Lenferink wrote:
> This is related to the thread Daniel just posted on the users@infra list:
>
> https://lists.apache.org/thread.html/r900f8f9a874006ed8121bdc901a0d1acccbb340882c1f94dad61a5e9%40%3Cusers.infra.apache.org%3E
>
> Op zo 27 d
This is related to the thread Daniel just posted on the users@infra list:
https://lists.apache.org/thread.html/r900f8f9a874006ed8121bdc901a0d1acccbb340882c1f94dad61a5e9%40%3Cusers.infra.apache.org%3E
Op zo 27 dec. 2020 om 13:26 schreef Andreas Veithen <
andreas.veit...@gmail.com>:
> Same for http
Same for https://github.com/apache/axis-axis2-java-core (with no
configuration changes on our side).
Andreas
On Sun, Dec 27, 2020 at 12:25 PM Jarek Potiuk wrote:
> Is there a change in the policy of Apache Airflow to only allow
> actions hosted in-organization? Or is it a mistake in configurati
Is there a change in the policy of Apache Airflow to only allow
actions hosted in-organization? Or is it a mistake in configuration?
We've just started @Apache Airflow to experience errors of this kind out of
a sudden (literally within the last hour).
potiuk/get-workflow-origin@588cc14f9f1cdf1b8b
20 matches
Mail list logo
