The PR to merge `v2-11-test` to `v2-11-stable` with release notes is here:
https://github.com/apache/airflow/pull/61921

For posterity and so that we are all aware what is the set of changes, here
it is:

Airflow 2.11.1 (2026-02-14)
---------------------------

Significant Changes
^^^^^^^^^^^^^^^^^^^

Python 3.8 support removed
""""""""""""""""""""""""""
Support for Python 3.8 has been removed, as it has reached end-of-life.
Airflow 2.11 requires Python 3.10, 3.11, or 3.12.

Publishing timer and timing metrics in seconds is now deprecated
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
In Airflow 3.0, the ``timer_unit_consistency`` setting in the ``metrics``
section will be
enabled by default and setting itself will be removed. This will
standardize all timer and timing metrics to
milliseconds across all metric loggers.
**Users Integrating with Datadog, OpenTelemetry, or other metric backends**
should enable this setting. For users, using
``statsd``, this change will not affect you.
If you need backward compatibility, you can leave this setting disabled
temporarily, but enabling
``timer_unit_consistency`` is encouraged to future-proof your metrics
setup. (#39908)

The ``core.worker_precheck`` config option is not effective any more
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Celery provider uses ``celery.worker_precheck`` config option in celery
provider < 3.5.0
and as of 3.5.0 it is not used at all. (#48568)

Retrieving historical log templates is disabled in Airflow 2.11.1
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
When you change the log template in Airflow 2.11.1, the historical log
templates are not retrieved.
This means that if you have existing logs that were generated using a
different log template,
they will not be accessible using the new log template.
This change is due to potential security issues that could arise from
retrieving historical log templates,
which allow Dag Authors to execute arbitrary code in webserver when
retrieving logs.
By disabling the retrieval of historical log templates, Airflow 2.11.1 aims
to enhance the security of the
system and prevent potential vulnerabilities in case the potential of
executing arbitrary code in webserver
is important for Airflow deployment.
Users who need to access historical logs generated with a different log
template will need to manually
update their log files to match the naming of their historical log files
with the latest log template
configured in Airflow configuration, or they can set the
"core.use_historical_filename_templates"
configuration option to True to enable the retrieval of historical log
templates, if they are fine with
the Dag Authors being able to execute arbitrary code in webserver when
retrieving logs. (#61880)

Updated dependencies
""""""""""""""""""""
Airflow 2.11.1 includes updates to a number of dependencies including
connexion, Flask-Session, Werkzeug,
that were not possible to upgrade before, because the dependencies did not
have compatible versions
with Airflow 2.11.0, but we worked together with the community to update
them. Many thanks to connexion
team and a number of community members to help with the updates so that we
could upgrade to newer
versions and get rid of some dependency versions that had known security
vulnerabilities (#51681)

Bug fixes
"""""""""
- Add proxy values to be masked by secrets manager (#61906)
- Masking details while creating connections using json & uri (#61882)
- Fix redaction of illegal args (#61883)
- Fix stuck queued tasks by calling executor fail method and invoking
failure callbacks (#53038)
- Fix recursion depth error in _redact_exception_with_context (#61797)
- Avoid warning when passing none as dataset alias (#61791)
- Add pool name validation to avoid XSS from the DAG file (#61732)
- Prevent scheduler to crash due to RecursionError when making a SQL query
(#55778)
- Fix root logger level cache invalidation in LoggerMutationHelper (#61644)
- update null event values to empty string in downgrade for migration
revision_id d75389605139 (#57131)
- Fix WeightRule spec (#53947)
- Correctly treat request on reschedule sensors as resetting after each
reschedule (#51410) (#52638)
- Allow more empty loops before stopping log streaming (#52614) (#52636)
- Ensuring XCom return value can be mapped for dynamically-mapped
@task_group's (#51668)
- Fix archival for cascading deletes by archiving dependent tables first
(#51952) (#52211)
- Stop streaming task logs if end of log mark is missing (#51904)
- Fix bad width w/no options in multi-select DAG parameter (#51516)
- Fix remove filter button visibility in Pools list page (#51161)
- Fix delete button visibility in search filters (#51100)
- Fix migration from 2.2.0 to 2.11.0 for Sqlite (#50745)
- Check if stand alone dag processor is active in get_health endpoint
(#48612)

J.


On Sat, Feb 14, 2026 at 12:14 AM Pavankumar Gopidesu <
[email protected]> wrote:

> Indeed it's a huge effort Jarek, Looking forward to testing it.. :)
>
> Regards,
> Pavan
>
> On Fri, Feb 13, 2026 at 11:08 PM Jens Scheffler <[email protected]>
> wrote:
>
> > Hi Jarek,
> >
> > thanks for putting all the efforts in making a 2.11.1! I am looking
> > forward and promise to contribute testing!
> >
> > Jens
> >
> > On 13.02.26 22:24, Jarek Potiuk wrote:
> > > Hello here,
> > >
> > > Another milestone (it does take a bit longer than I anticipated ..
> > > estimation and guessing is difficult when you have ):
> > >
> > > * we have a green v2-11-test build with all tests passing for all
> > databases
> > > - including sqlite. The constraints for 2-11 have been updated today
> > > https://github.com/apache/airflow/commits/constraints-2-11/ (two
> times)
> > -
> > > and the dependencies are "refreshed"
> > > * i reviewed/merged all remaining PRs / Issues that were marked for
> 2.11
> > > from those people who submitted them (in the past and recently) - that
> > also
> > > includes some rework to make those "better" and handle more edge-cases
> > > * I opened last three PRs that were outstanding from past discussions
> > > https://github.com/apache/airflow/milestone/114  -> and look forward
> to
> > > reviews/making them green/merging
> > >
> > > Once this is done I will make an RC for airflow 2.11.1 and fab provider
> > > 1.5.4 that should be tested together.
> > >
> > > I have a kind request to everyone who is looking forward to 2.11.1 - to
> > get
> > > prepared for testing next week, I am planning to have the
> voting/testing
> > > open for 5 days, in order to get more feedback and potential issue
> > > resolving time.
> > >
> > > The whole experience with 2.11.1 for me is kind of proof of the "if
> > > sometimes is painful - do it more often" - many months passed from
> > > releasing 2.11.0 and this caused a natural decay .. and bringing it
> back
> > to
> > > a fresh state is really, really painful.
> > >
> > > J.
> > >
> > >
> > >
> > > On Mon, Feb 9, 2026 at 2:08 AM Jarek Potiuk <[email protected]> wrote:
> > >
> > >> Hello Everyone. I am almost done with all the tests and fixes and
> > >> preparation for RC candidates. The last PR
> > >> https://github.com/apache/airflow/pull/61633 solves the stability db
> > >> connection issues with flask-session (still have some sqlite test
> issues
> > >> but it's a nuance).
> > >>
> > >> I will be proceeding with preparing the release and adding a few last
> > >> "dependency/security" related fixes tomorrow.
> > >>
> > >> I am also going to merge very few, very small and targeted (and safe
> to
> > >> merge) fixes - such as https://github.com/apache/airflow/pull/61644
> . I
> > >> aim to make an RC in the next few days.
> > >>
> > >> But If you have any (very small) backport fix that you would like to
> get
> > >> to v2-11-test to fix it in 2.11.1 -> please open a PR against
> > "v2-11-test"
> > >> and let me know - ping me on slack ideally. However I have a request
> > there
> > >> - I will tag those who made those PRs and I will expect that they will
> > test
> > >> them in their system while we are testing RC candidates.
> > >>
> > >> J,
> > >>
> > >>
> > >> On Sat, Feb 7, 2026 at 4:41 PM Jarek Potiuk <[email protected]> wrote:
> > >>
> > >>> Hello here.
> > >>>
> > >>> I just achieved a significant milestone.
> > >>> https://github.com/apache/airflow/pull/51681 which I worked on for
> > 2.11
> > >>> got green finally (it took quite a bit more effort than I expected).
> > >>>
> > >>> There is still at least one issue I am working on and few "backports"
> > to
> > >>> male but I wanted to get the 2-11-test to the state where the CI is
> > green
> > >>> so that subsequent fixes can be merged with tests and usual process.
> In
> > >>> order to make reviews easier - I split the big PR I worked on into
> > several
> > >>> smaller ones focused on groups of changes that will be easier to
> > review and
> > >>> approve (hopefully). I also added appropriate people - I think as
> > >>> reviewers, so please take a look at reviewing those quickly. It is
> > >>> **UNLIKELY** that those PRs will get green on their own - but once we
> > merge
> > >>> them all, the 51681 is proof that this will happen eventually.
> > >>>
> > >>>
> > >>>
> > >>> * Synchronize GitHub workflows and Breeze tooling for 2.11 branch:
> > >>> https://github.com/apache/airflow/pull/61598
> > >>> * Synchronize FAB provider with 1.5.4 version
> > >>> https://github.com/apache/airflow/pull/61601
> > >>> * Synchronize common compat to 1.2.1 in v2-11-test branch
> > >>> https://github.com/apache/airflow/pull/61602
> > >>>
> > >>> Please review (and approve ?) so I can proceed..
> > >>>
> > >>> J,
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Thu, Feb 5, 2026 at 11:29 PM Jarek Potiuk <[email protected]>
> wrote:
> > >>>
> > >>>> Interesting that you ask now - I literally am working on in as you
> > speak
> > >>>>
> > >>>> On Thu, Feb 5, 2026 at 5:28 PM Damian Shaw <
> > [email protected]>
> > >>>> wrote:
> > >>>>
> > >>>>> What's the current thinking on a 2.11.1?
> > >>>>>
> > >>>>> Totally understandable if this was too much work and has been
> > dropped,
> > >>>>> but just trying to gauge what advice I should giving to cautious
> > upgraded
> > >>>>> on a path to Airflow 3.x.
> > >>>>>
> > >>>>> Damian
> > >>>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Jarek Potiuk <[email protected]>
> > >>>>> Sent: Sunday, October 5, 2025 3:44 AM
> > >>>>> To: [email protected]
> > >>>>> Subject: Upcoming Airflow 2.11.1 release [was: [DISCUSS] Possible
> > >>>>> Werkzeug vulnerabilities fix for Airflow 2]
> > >>>>>
> > >>>>> Hello here,
> > >>>>>
> > >>>>> *TL;DR; I wanted to start a process of preparing to 2.11.1 release
> > and
> > >>>>> I would like the community to be aware of it as I am taking the
> role
> > of
> > >>>>> release manager for it. *
> > >>>>>
> > >>>>> I will need help with reviewing PRs from the committers (I will try
> > to
> > >>>>> move it forward even during the Summit, but realistically speaking,
> > I think
> > >>>>> I will start release process some time after the Summit as likely a
> > lot of
> > >>>>> us won't have the usual attention/time.
> > >>>>>
> > >>>>> *First: good news.* We are unblocked with long overdue Werkzeug
> > upgrade
> > >>>>> - with a serious vulnerabiity (via Connexion 2.15.0) - there are
> > also few
> > >>>>> small security-related patches that we want to implement alongside.
> > >>>>>
> > >>>>> *Then: not so good news* (well, depends for whom): while we are
> going
> > >>>>> to release 2.11.1,  this is is going to be **critical bugfixes
> only +
> > >>>>> security** release. There will be absolutely no new features, or
> > fixes
> > >>>>> to - even annoying - issues in 2.11 if they are not critical.
> > >>>>>
> > >>>>> You can skip the rest of the message if you are not interested in
> > more
> > >>>>> details or do not want to be involved in the 2.11.1 release
> testing.
> > >>>>>
> > >>>>> *MORE DETAILS:*
> > >>>>>
> > >>>>> *Again - what is going to be included?*
> > >>>>>
> > >>>>> Only absolutely critical issues and security related changes.
> > >>>>>
> > >>>>> If you think there is an absolutely critical fix that should be
> > >>>>> included - please let me know and explain why - here in this
> > discussion.
> > >>>>> But the approach I am going to take is that only absolutely
> critical/
> > >>>>> security related fixes should be included in this release - and
> > there has
> > >>>>> to be a really good justification to fix anything in 2.11.
> > >>>>>
> > >>>>> I will also absolutely expect, that whoever wants to get any fix
> > there
> > >>>>> and we will agree here that it's a good idea, it's **on the one who
> > proposes
> > >>>>> it** to make a green PR to v2-11-test with the fix and that they
> 100%
> > >>>>> commit to testing and verifying it when the release candidate is
> out.
> > >>>>>
> > >>>>> If you think that something should be included in 2.11.1 because of
> > >>>>> security reasons - please do not write about it in public. Send an
> > email to
> > >>>>> [email protected] explaining the issue and ideally
> > solution
> > >>>>> / PR to backport. Generally follow our Security Policy
> > >>>>> https://github.com/apache/airflow/security/policy
> > >>>>>
> > >>>>> *Help needed*
> > >>>>>
> > >>>>> Eventually - I will need community help in testing it - especially
> > for
> > >>>>> authentication/FAB integration because this part will be changed a
> > bit. I
> > >>>>> will ask for a bit longer time of testing likely and will need
> > community
> > >>>>> support from people who are already at 2.11.0 to test it.
> > >>>>>
> > >>>>> *A little more details on wha triggered it*
> > >>>>>
> > >>>>> It took a LOONG time, but finally - with help of some friends of
> mine
> > >>>>> who did a little nudging and conveniently just before coming back
> > from my
> > >>>>> vacations - which will happen on Monday BTW - we finally have
> > Connexion
> > >>>>> 2.15.0 released. This was a bit of a blocker that we waited for -
> > this
> > >>>>> **should** help us to solve one of the longest standing issue with
> > >>>>> Werkzeug dependency version of ours having a critical
> vulnerability.
> > >>>>>
> > >>>>> I think (that was few months ago) I fixed all the compatibility
> > issues
> > >>>>> for Airflow 2.11.
> > >>>>>
> > >>>>> It was done some time ago on a version of Connexion built from a
> > branch
> > >>>>> and it required a few changes (the way how percent encoding of urls
> > are
> > >>>>> handled by Werkzeug 2.3.0 and few internal things + i had to
> > implement a
> > >>>>> bit of a "hack" on Serialization in flask-session, this PR
> > >>>>> https://github.com/apache/airflow/pull/51681 - should likely
> > >>>>> eventually lead to a green build.
> > >>>>>
> > >>>>> *A little more details on what is going to happen*
> > >>>>>
> > >>>>> I will need to do a few more steps to get there:
> > >>>>>
> > >>>>> 1) I need to release Fab provider 1.5.4 (initially beta, but when I
> > get
> > >>>>> it
> > >>>>> tested) from providers/fab/v1-5 (working on it). This is needed to
> > >>>>> "unblock" some of the depenendency limits in 1.5.3 and adapt
> > provider to a
> > >>>>> new flask-session that is needed for the upgrade..
> > >>>>>
> > >>>>> 2) I will continue with the "connexion-2.15" PR
> > >>>>> https://github.com/apache/airflow/pull/51681 to use this new
> > provider
> > >>>>> version, get constraints generated - and **hopefullly** get
> > v2-11-test
> > >>>>> branch green (might require some tweaks to the old branches - they
> > are a
> > >>>>> bit rusty I am afraid)
> > >>>>>
> > >>>>> 3) then I will apply remaining critical changes, That will be the
> > time
> > >>>>> when anyone who thinks a change should be included, should work on
> > >>>>> backporting critical/implementing security related PRs.
> > >>>>>
> > >>>>> What this will allow (fingers crossed it will not be too
> difficult) -
> > >>>>> is to release 2.11.1 version of Airflow with bumped Werkzeug and
> few
> > other
> > >>>>> dependencies, and critical changes that we plan for 2.11.1 -
> > following the
> > >>>>> regular release process.
> > >>>>>
> > >>>>> J.
> > >>>>>
> > >>>>>
> > >>>>> On Sun, Jun 22, 2025 at 8:55 AM Jarek Potiuk <[email protected]>
> > wrote:
> > >>>>>
> > >>>>>> Good news. As a result of our request, Connection 2.15.0rc2 was
> > >>>>>> released in PyPI this morning with Flask>3. I am running now tests
> > >>>>>> with it
> > >>>>>> https://github.com/apache/airflow/pull/51681 and we **finally**
> > have
> > >>>>>> non-conflicting dependencies in Airflow 2.11 with it.
> > >>>>>>
> > >>>>>> It still fails - i.e. we will have to fix things with session
> > handling
> > >>>>>> (we knew we will have to do it because of flask-session upgrade)
> but
> > >>>>>> this is something we are now unblocked with :).
> > >>>>>>
> > >>>>>>   Hopefully soon we will get rid of the Werkzeug drama.
> > >>>>>>
> > >>>>>> root@a20ed58d4f59:/opt/airflow# pip freeze | grep lask
> > >>>>>> Flask==2.3.3
> > >>>>>> Flask-AppBuilder==4.5.2
> > >>>>>> Flask-Babel==2.0.0
> > >>>>>> Flask-Bcrypt==1.0.1
> > >>>>>> Flask-Caching==2.3.1
> > >>>>>> Flask-JWT-Extended==4.7.1
> > >>>>>> Flask-Limiter==3.11.0
> > >>>>>> Flask-Login==0.6.3
> > >>>>>> Flask-Session==0.8.0
> > >>>>>> Flask-SQLAlchemy==2.5.1
> > >>>>>> Flask-WTF==1.2.2
> > >>>>>> root@a20ed58d4f59:/opt/airflow# pip freeze | grep erkzeug
> > >>>>>> *Werkzeug==3.1.3*
> > >>>>>> root@a20ed58d4f59:/opt/airflow#
> > >>>>>>
> > >>>>>> J.
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On Thu, Jun 19, 2025 at 7:44 AM Jarek Potiuk <[email protected]>
> > >>>>> wrote:
> > >>>>>>> Dear Airflow community,
> > >>>>>>>
> > >>>>>>> Thank you. You are amazing. With all the upvotes and comments we
> > had
> > >>>>>>> the contributor of connexion working on bringing Flask 2.3.3+
> back
> > to
> > >>>>>>> the upcoming Connexion release
> > >>>>>>> https://github.com/spec-first/connexion/pull/2058/
> > >>>>>>>
> > >>>>>>> Particularly Kamil - thanks for the thoughtful comments and the
> > >>>>>>> diligent check on what Flask version we need. We are currently at
> > 2.2
> > >>>>>>> in Airflow 2.11 but I checked that if Connexion sets their limit
> to
> > >>>>>>>> =2.3.3, we should be able update to that version in 2.11 (and
> it's
> > >>>>>>> good in general as 2.3+ is now the only recommended branch still
> > >>>>>>> being "supported" for Flask 2 for security issues it seems. So we
> > get
> > >>>>>>> additional benefit there that we will be less likely to hit
> similar
> > >>>>> issues until Airflow 2 EOL.
> > >>>>>>> J.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Wed, Jun 18, 2025 at 8:07 PM Jarek Potiuk <[email protected]>
> > >>>>> wrote:
> > >>>>>>>> Thank you Kamil - that's very thoughtful and nice to see your
> > >>>>>>>> message back on the devlist :D
> > >>>>>>>>
> > >>>>>>>> On Wed, Jun 18, 2025 at 7:38 PM Kamil Breguła <
> [email protected]
> > >
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> I proposed to split the new connexion release into two
> versions.
> > >>>>>>>>> First release one release that supports the new Werkzereg
> > release,
> > >>>>>>>>> and then release a new Connexion release that supports Flask 3
> > >>>>>>>>> only. This is not ideal, because Airflow 2 will still be on an
> > >>>>>>>>> unsupported version of Connexion, but we will have at least one
> > >>>>>>>>> release that has the new Werkzeug version and has a fix for the
> > CVE
> > >>>>>>>>> bug. This might be easier to do, as I understand that connexion
> > >>>>>>>>> might not want to support Flask 2 if there is no specific end
> > date
> > >>>>>>>>> for when other dependencies will support Flask 3, but it may
> > still
> > >>>>>>>>> turn out to be enough for us.
> > >>>>>>>>>
> > >>>>>>>>> śr., 18 cze 2025 o 08:54 Jarek Potiuk <[email protected]>
> > >>>>> napisał(a):
> > >>>>>>>>>> I WOULD LIKE TO TAP INTO POWER OF OUR COMMUNITY... PLEASE
> HELP.
> > >>>>>>>>>>
> > >>>>>>>>>> We again had another issue with FAB where the root cause was
> our
> > >>>>>>>>>> old Werkzeug version - that we cannot upgrade until now) - old
> > >>>>>>>>>> Werkzeug
> > >>>>>>>>> does
> > >>>>>>>>>> not support `scrypt` hashing algorithm and latest FAB version
> > >>>>>>>>> defaulted
> > >>>>>>>>>> password hashing to scrypt - we have a workaround but we will
> > >>>>>>>>>> have to
> > >>>>>>>>> make
> > >>>>>>>>>> a more complete fix with FAB provider. And I am sure Airflow 2
> > >>>>>>>>>> users
> > >>>>>>>>> will
> > >>>>>>>>>> have more and more problems as the time passes.
> > >>>>>>>>>>
> > >>>>>>>>>> I think there is a **real** chance with the Connexion team
> > >>>>>>>>>> working on
> > >>>>>>>>>> 2.15.0 - https://pypi.org/project/connexion/2.15.0rc1/  that
> we
> > >>>>>>>>>> can finally get rid of it - in Both Airflow 2 and Airflow 3.
> But
> > >>>>>>>>>> we have one
> > >>>>>>>>> problem ->
> > >>>>>>>>>> Connexion 2.15.0rc1 seems to require Flask 3 where we cannot
> > >>>>>>>>>> upgrade
> > >>>>>>>>> to
> > >>>>>>>>>> Flask 3 because of the FAB <3 limit. I started a discussion
> > about
> > >>>>>>>>>> it
> > >>>>>>>>> here:
> > >>>>>
> https://github.com/spec-first/connexion/pull/1992#issuecomment-2976
> > >>>>>>>>> 706491
> > >>>>>>>>>> and explained that it would be great if Connexion 2.15.0
> > >>>>>>>>>> supported
> > >>>>>>>>> still
> > >>>>>>>>>> flask 2.
> > >>>>>>>>>>
> > >>>>>>>>>> And it would be great if more people could support it and
> > explain
> > >>>>>>>>> that this
> > >>>>>>>>>> would be a major win for the Airflow community if they could
> > >>>>>>>>>> relax
> > >>>>>>>>> this.
> > >>>>>>>>>> I do not think this is a big problem for them - the
> explanation
> > >>>>>>>>>> we
> > >>>>>>>>> had from
> > >>>>>>>>>> them is "hey Flask 2 is really old" - but there is no "real"
> > >>>>> reason.
> > >>>>>>>>>> On the other hand migrating FAB to Flask 3 would like be a
> very
> > >>>>>>>>> complex and
> > >>>>>>>>>> risky thing (and Daniel already struggles with just SQLalchemy
> > >>>>>>>>> upgrade and
> > >>>>>>>>>> FAB 5 so it would be too much to put the pressure on him).
> > >>>>>>>>>>
> > >>>>>>>>>> Can you please help and upvote/comment on
> > >>>>>>>>>>
> > >>>>>
> https://github.com/spec-first/connexion/pull/1992#issuecomment-2976
> > >>>>>>>>> 706491
> > >>>>>>>>>> I would (and the whole community) really, really appreciate
> it.
> > >>>>>>>>>>
> > >>>>>>>>>> J.
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Fri, Jun 13, 2025 at 11:16 AM Jarek Potiuk <
> [email protected]
> > >
> > >>>>>>>>> wrote:
> > >>>>>>>>>>> Hello everyone,
> > >>>>>>>>>>>
> > >>>>>>>>>>> As you might know, Airflow 2 has a long-time issue with not
> > >>>>>>>>>>> being
> > >>>>>>>>> able to
> > >>>>>>>>>>> upgrade Werkzeug dependency to a non-vulnerable version and
> > >>>>>>>>>>> that
> > >>>>>>>>> raises a
> > >>>>>>>>>>> lot of alarms for users who run CVE checks on Airflow.
> > >>>>>>>>>>>
> > >>>>>>>>>>> We've been waiting for a long time for that - but it looks
> like
> > >>>>>>>>> there is
> > >>>>>>>>>> a
> > >>>>>>>>>>> light in a tunnel. We have two options that we can attempt:
> > >>>>>>>>>>>
> > >>>>>>>>>>> 1) Connexion 2.15.0.rc1
> > >>>>>>>>>>> 2) Releasing a package that will patch Werkzeug 2.2.3 with
> > >>>>>>>>> backported CVE
> > >>>>>>>>>>> fixes
> > >>>>>>>>>>>
> > >>>>>>>>>>> Recently Google team attempted to back-port and test fixes to
> > >>>>>>>>>>> older version of Werkzeug and I helped to get through to the
> > >>>>>>>>>>> maintainers -
> > >>>>>>>>>>> https://github.com/pallets/werkzeug/discussions/3034 -
> however
> > >>>>>>>>> they are
> > >>>>>>>>>>> not really willing to make that into regular release -
> > >>>>>>>>>>> reasoning
> > >>>>>>>>>> explained
> > >>>>>>>>>>> in the discussion.
> > >>>>>>>>>>>
> > >>>>>>>>>>> However, after many months of discussions and at least 3
> > >>>>>>>>>>> attempts
> > >>>>>>>>> to bump
> > >>>>>>>>>>> dependencies for Connexion - we seem to have an RC candidate
> > >>>>>>>>> (2.15.0rc1
> > >>>>>>>>>>> https://pypi.org/project/connexion/2.15.0rc1/) that lifts
> the
> > >>>>>>>>> limit for
> > >>>>>>>>>>> Werkzeug (released 4 days ago).
> > >>>>>>>>>>>
> > >>>>>>>>>>> There were some breaking changes in Werkzeug that made it so
> > >>>>>>>>>>> long
> > >>>>>>>>> and
> > >>>>>>>>>>> difficult but I think we should be able to release a 2.11.1
> > >>>>>>>>>>> version
> > >>>>>>>>> of
> > >>>>>>>>>>> Airflow with it
> > >>>>>>>>>>>
> > >>>>>>>>>>> I made  first attempt to migrate - here:
> > >>>>>>>>>>> https://github.com/apache/airflow/pull/51681 and while I was
> > >>>>>>>>>>> able
> > >>>>>>>>> to
> > >>>>>>>>>> work
> > >>>>>>>>>>> out non-conflicting dependencies and bump Werkzeug, there are
> > >>>>>>>>>>> some
> > >>>>>>>>> things
> > >>>>>>>>>>> to be fixed with session handling and there is still one
> > >>>>>>>>>>> outstanding problem - FAB requires Flask < 3 and currently
> > >>>>>>>>>>> Connexion 2.0.15rc1
> > >>>>>>>>>> requires
> > >>>>>>>>>>> flask >= 3 - which FAB (even upcoming FAB 5) does not
> support.
> > >>>>>>>>>>> And
> > >>>>>>>>> likely
> > >>>>>>>>>>> migrating to Flask 3 is **not** an option for us anyway.
> > >>>>>>>>>>>
> > >>>>>>>>>>> I started discussion here with those who worked on the
> > >>>>>>>>>>> Connexion
> > >>>>>>>>> patch
> > >>>>>>>>>> for
> > >>>>>>>>>>> Werkzeug to see if that is a "hard" limit..:
> > >>>>>>>>>>>
> > >>>>>
> https://github.com/spec-first/connexion/pull/1992#issuecomment-2969
> > >>>>>>>>> 565640
> > >>>>>>>>>>> Alternative option - patch package:
> > >>>>>>>>>>>
> > >>>>>>>>>>> We also have a "last-resort" approach that we are looking at
> > >>>>>>>>>>> with
> > >>>>>>>>> the
> > >>>>>>>>>>> Google team. We might want to release a "werkzeug-patch"
> > >>>>>>>>>>> package
> > >>>>>>>>> that
> > >>>>>>>>>> will
> > >>>>>>>>>>> apply the CVE patches to Werkzeug 2.2.3
> > >>>>>>>>>>>
> > >>>>>>>>>>> Option 1) is not clear yet if it is possible due to Flask 3 /
> > >>>>>>>>>>> Flask
> > >>>>>>>>> 2  -
> > >>>>>>>>>>> and it would only work for 2.11.1 - we need to make some
> fixes
> > >>>>>>>>>>> and
> > >>>>>>>>> change
> > >>>>>>>>>>> dependencies for Airflow to make it work.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Option 2) Is hacky (I am talking to Werkzeug maintainers what
> > >>>>>>>>>>> do
> > >>>>>>>>> they
> > >>>>>>>>>>> think about it as we would likely need to have at least a
> > >>>>>>>>>>> comment
> > >>>>>>>>> in the
> > >>>>>>>>>>> CVE advisory that this package fixes it as well) . But it has
> > >>>>>>>>>>> the
> > >>>>>>>>> benefit
> > >>>>>>>>>>> that it will **just work** by installing the patch on
> basically
> > >>>>>>>>>>> all
> > >>>>>>>>> past
> > >>>>>>>>>>> Airflow versions
> > >>>>>>>>>>>
> > >>>>>>>>>>> Just wanted to let everyone know it happens and ask if you
> have
> > >>>>>>>>>>> any opinions on those.
> > >>>>>>>>>>>
> > >>>>>>>>>>> J.
> > >>>>>>>>>>>
> > >>>>> ________________________________
> > >>>>>   Strike Technologies, LLC (“Strike”) is part of the GTS family of
> > >>>>> companies. Strike is a technology solutions provider, and is not a
> > broker
> > >>>>> or dealer and does not transact any securities related business
> > directly
> > >>>>> whatsoever. This communication is the property of Strike and its
> > >>>>> affiliates, and does not constitute an offer to sell or the
> > solicitation of
> > >>>>> an offer to buy any security in any jurisdiction. It is intended
> > only for
> > >>>>> the person to whom it is addressed and may contain information that
> > is
> > >>>>> privileged, confidential, or otherwise protected from disclosure.
> > >>>>> Distribution or copying of this communication, or the information
> > contained
> > >>>>> herein, by anyone other than the intended recipient is prohibited.
> > If you
> > >>>>> have received this communication in error, please immediately
> notify
> > Strike
> > >>>>> at [email protected], and delete and destroy any copies
> > >>>>> hereof.
> > >>>>> ________________________________
> > >>>>>
> > >>>>> CONFIDENTIALITY / PRIVILEGE NOTICE: This transmission and any
> > >>>>> attachments are intended solely for the addressee. This
> transmission
> > is
> > >>>>> covered by the Electronic Communications Privacy Act, 18 U.S.C
> > ''2510-2521.
> > >>>>> The information contained in this transmission is confidential in
> > nature
> > >>>>> and protected from further use or disclosure under U.S. Pub. L.
> > 106-102,
> > >>>>> 113 U.S. Stat. 1338 (1999), and may be subject to attorney-client
> or
> > other
> > >>>>> legal privilege. Your use or disclosure of this information for any
> > purpose
> > >>>>> other than that intended by its transmittal is strictly prohibited,
> > and may
> > >>>>> subject you to fines and/or penalties under federal and state law.
> > If you
> > >>>>> are not the intended recipient of this transmission, please DESTROY
> > ALL
> > >>>>> COPIES RECEIVED and confirm destruction to the sender via return
> > >>>>> transmittal.
> > >>>>>
> > >>>>>
> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: [email protected]
> > >>>>> For additional commands, e-mail: [email protected]
> > >>>>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>

Reply via email to