apache
Manually bump packages
Dependabot had a lot of updates. I manually went through them.
Will do eslint and typescript in a separate PR because it broke our CI
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.
Working on it, looks like the react upgrade changed some typescript checks
Will this PR address https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
@tschroeder-zendesk Airflow is not exposed to this vulnerability.
If you think otherwise, I suggest you contact our security team at [email protected] with a report.
If you think otherwise, I suggest you contact our security team at [email protected] with a report.
Including POC @tschroeder-zendesk
Also @tschroeder-zendesk -> if you look at Security tab of our documentation, you will find SBOM - which is machine-readable, industry standard way how you can check which 3rd-party dependencies Airflow uses. Please use it next time when you want to see if particular component that you know is vulnerable. That will save a lot of time of maintainers that have to individually answer ssuch questions rather than users reading informatoin that is provided by maintainers so that they can use it.
When you are getting software for free, I think good idea is not to demand more time from maintainers than needed - especially if they provide you all information you need (for free mind you)
If you think otherwise, I suggest you contact our security team at [email protected] with a report.
Including POC @tschroeder-zendesk
Also @tschroeder-zendesk -> if you look at Security tab of our documentation, you will find SBOM - which is machine-readable, industry standard way how you can check which 3rd-party dependencies Airflow uses. Please use it next time when you want to see if particular component that you know is vulnerable. That will save a lot of time of maintainers that have to individually answer ssuch questions rather than users reading informatoin that is provided by maintainers so that they can use it.
When you are getting software for free, I think good idea is not to demand more time from maintainers than needed - especially if they provide you all information you need (for free mind you)
No need to be rude. I just asked if this addressed that as it seemed like it would since that CVE mentioned needing to bump react to 19.2.1 and react-dom 19.2.1 that seemed to be addressed here and after looking at the code it wasn't clear to me if this security issue was a problem. The version is definitely one of the affected so I don't think it was an unreasonable question.
No need to be rude. I just asked if this addressed that as it seemed like it would since that CVE mentioned needing to bump react to 19.2.1 and react-dom 19.2.1 that seemed to be addressed here and after looking at the code it wasn't clear to me if this security issue was a problem. The version is definitely one of the affected so I don't think it was an unreasonable question.
React != react-server-components. In all articles about the issue it's very clearly specifed which components are affected. And it's a great opportunity to remind people that there are ways to check it. You are not the first one who did not look in detail but saw "react" and did not check that it was really "react-server-components", there were few others with difference channels who did not check we are not using it. If everyone - like you and them - would do the same, we would have to spend the whole day just answering.
You have to be really careful when you mention a security issue in publick - it might not only be "irresponsive disclosure". This immediately triggers maintainers alert - and might drag attention of malicious actors who might want to use it against the project, So by publicly commenting on it you are putting the project in danger, if in-fact we would be affected. Our project have very clear policies, describing what you should do when you suspect security issue. Commenting on public PRs and issues is NOT the way it should be done. I recommend you check it (Security tab in GitHub project - easy to find).
Also - to be perfectly honest - the harsh tone is deliberate. Since those issues are public - I treat it as a teaching and unfortunately this time it was your turn - I hope this will serve as an example to others who will likely find the issue and learn about SBOMS and ways they should check things. If we receive 1000 questions like yours and 1 on of them will be important - we migh miss it, so I prefer to be slightly rude and through that have less of such questions - no more.
This is really a sign we are treating security seriously - and we simply ask our users to do the same. Just that.
Fortunately, we're not worried about the specific server components vulnerability. But I figured its not a bad idea to update react anyways.
Just pushed up changes that should fix all the eslint and typescript errors