potiuk commented on PR #29194: URL: https://github.com/apache/airflow/pull/29194#issuecomment-1406660686
A bit more detailed response: This is not a good (nor needed) fix. First of all it only updates Python 3.9 and Airflow 2.5 supports 4 different Python minor releases (3.7, 3.8, 3.9, 3.10). Secondly, Airflow constrainst are automatically maintained and upgraded whenever we release Airlfow and we do not update the constraints afterwards (unless there is a critical fix). The constraints are the "result" of attempting to upgrade all requirements - they are not "source of it" and manualy upgrades can only be done following this process: https://github.com/apache/airflow/blob/main/dev/REFRESHING_CI_CACHE.md#manually-generating-constraint-files Manually updating the constraints bears the risk that there are some dependencies that will conflict with the manually updated versions. For example if there is a dependency of ours that has `< 3.20.2` on protobufs, and if we update constraints with 3.20.3, we will have a conflict. Thirdly, constraints are NOT the way to solve CVEs. Constraints serve one and only one purpose - they allow to install Airlfow and it's all 70+ providers in a reproducible way. So we never upgrade the constraints in order to fix CVEs in airflow dependencies. Constraints (and that why we chose them) do not limit the user in upgrading the affected dependencies independentlt (they should test and make sure things still work when they do), we will not upgrade constraints for already released versions of Airflow because it breaks reproducibility principle. The only time we manually upgrade released constraints (with constraint-tags) is when there is an external change which breaks the reproducible installation - not when CVE is published. This is still on the user's side to make sure they update dependencies - Airlfow in vast majority of cases does not upper-bind the dependencies it uses (except some very specific cases) so users are free to test and upgrade the dependencies when CVEs are releassed. We do-however treat security seriously and we automatically upgrade the constraints to latest applicable, non-conflicting versions at the time we release a new version. So the next time we will update the constraints automatically is when we release 2.5.2 - then part of the process is to generate and update constraints automatically. Hopefully this one will bump the protobuf as well, though, there might be a case that there is another dependency of some of our providers that limits the protobuf. In whic case it will not be updated. And here is when you can actually help @dimon222 . If you care about this particular dependency - I invite you to track down whether protobuf is limited by some of our dependencies and which one it is. This is not a very difficult task but sometimes might require a bit intelligent guessing. I usually simply use `breeze` with latest image installed and use "pip freeze" and some querying on installed package metadata (wia simplejson interface of Pypi) where the limitation comes from. As @eladkal helpfully pointed out - this one comes from bitable client - so the solution here is to bump the client version (and make sure all the tests pass) or communicate with those who implemented it to fix it. Which I heartily invite you to do :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
