Sync proposals (all require confirmation)
1. Remove label needs triage; add label airflow. Triage is complete —
severity agreed, approach agreed, location agreed.
2. Update issue body fields that are currently _No response_:
- Short public summary: "A Dag author could create a symlink under
their task's log directory pointing to an arbitrary file readable by the
API server process (for example /etc/passwd or airflow.cfg), and the log
viewer would follow the symlink and display the
target file's contents. This only affects deployments where the worker
log folder is shared with the API server. Fixed by refusing to follow
symlinks that escape the configured base_log_folder."
- Affected versions: < 3.1.9 (to be confirmed based on where the fix
lands — see Part 2 backport strategy).
- CWE: CWE-59: Improper Link Resolution Before File Access ('Link
Following').
- Severity: change from Critical → Low (team consensus).
- PR with the fix: leave empty for now; the fix skill fills it after
the PR is opened.
- CVE tool link: leave empty until the CVE is allocated.
3. Change milestone from Airflow 3 → 3.1.9 (next 3.1.x patch, matches the
backport strategy in Part 2).
4. Allocate a CVE via the ASF CVE tool. This is a human step — please
open:
- https://cveprocess.apache.org/allocatecve
and allocate one. Once you have the CVE ID, tell me and I'll add both the
ID (as a linked reference per the "Linking CVEs" rule) and the CVE-tool URL
to the issue body in the same edit as items 1–3.
5. Status comment on the issue recording the sync and noting the 3-month
stall + pivot to team-implemented fix.
6. No reporter draft. The reporter is on HackerOne; direct email isn't an
option. Once there is a PR + advisory, a status update can be relayed via
Arnout — but that's for the post-advisory sync, not today.
Part 2 — Fixability classification: ✅ Easily fixable
┌─────────────────────────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Signal │
Status
│
├─────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Clear consensus on the approach │ ✅ Reporter's proposal approved by
Jarek on 2026-01-14; @aritra24 agreed on severity. No disagreement.
│
├─────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Known location │ ✅
airflow-core/src/airflow/utils/log/file_task_handler.py, method
_read_from_local, around line 860. Verified against local clone. │
├─────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Code snippet provided │ ✅ The reporter provided a full
implementation in the discussion. Usable almost verbatim.
│
├─────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Small scope │ ✅ One method in one file + one new
test. No migration, no new API, no config change.
│
├─────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ No open technical questions │ ✅ Approach + severity +
CVE-worthiness all settled.
│
├─────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Security classification settled │ ✅ Team agreed: valid, Low severity.
│
└─────────────────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
This is one of the cleanest "easily fixable" candidates possible.
I am proceeding with the fix.
On Wed, Apr 15, 2026 at 3:39 PM Jarek Potiuk <[email protected]> wrote:
> Skill for fixing the issue https://github.com/airflow-s/airflow-s/pull/271
>
> On Wed, Apr 15, 2026 at 3:34 PM Jarek Potiuk <[email protected]> wrote:
>
>> > This was ambiguous regarding the value you wanted to retrieve and the
>> intended change.
>>
>> While I see why we cannot (should not) bring back the "exact" behaviour,
>> I think we could - potentially at least - make it non-ambiguous and
>> predictable by defining the semantics and ordering and selecting the first
>> one. And - I think - we do not **have** to bring it back in this particular
>> method. Maybe we can just a new method call with defined ordering and
>> semantics - behaving predictably, similar to Airflow 2—and clearly defined
>> semantically. That would at least give people an easier way to migrate?
>>
>> While I think the cat if out-of-the bag and we cannot truly revert the
>> change (because that would again potentially affect 3.0 - 3.2 users) - but
>> we could at least make it easier for people to cope with it without too
>> much hassle while waiting for the task state to be available in this
>> particular case?
>>
>> Just a thought I had - ... listen to your users and do things easier for
>> them - without breaking our SemVer promises.
>>
>> J.
>>
>>
>>
>> On Wed, Apr 15, 2026 at 3:20 PM Foldvari, Gyorgy via dev <
>> [email protected]> wrote:
>>
>>> I do not want to use XCom for managing task state. It was just a very
>>> simple - and seemingly misleading - example to explain the original
>>> behavior.
>>>
>>> I gave details about valid use cases and issues caused by this change in
>>> the behavior, in my original post. Those are not addressed by the AIP you
>>> are referring to.
>>>
>>> But that AIP would definitely address another valid use case what I am
>>> missing especially for implementing stateful sensors, so I really hope it
>>> goes through and gets implemented.
>>>
>>>
>>> Information Classification: GENERAL
>>> -----Original Message-----
>>> From: Ash Berlin-Taylor <[email protected]>
>>> Sent: Wednesday, April 15, 2026 14:49
>>> To: [email protected]
>>> Subject: Re: [DISCUSS] Reconsidering `xcom_pull(task_ids=None)` behavior
>>> change in Airflow 3
>>>
>>> [You don't often get email from [email protected]. Learn why this is
>>> important at https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>> CAUTION: This email originated from outside of the organization. Do not
>>> click links or open attachments unless you recognize the sender and know
>>> the content is safe.
>>>
>>>
>>> This was ambiguous as to what value you wanted to get, and an intended
>>> change.
>>>
>>> If you want this sort of behaviour, then you probably want to look at
>>> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-103%3A+Task+State+Management
>>> which provides a dedicated way to manage state without many of the quirks
>>> of XCom interface as it stands today. Reading between the lines, I think
>>> this API describes what you want?
>>>
>>> -ash
>>>
>>> > On 15 Apr 2026, at 12:45, Foldvari, Gyorgy via dev <
>>> [email protected]> wrote:
>>> >
>>> > I see where the confusion is coming from, it is my mistake. Sorry
>>> about that.
>>> >
>>> > To clarify, I am taking about the use case where the key parameter is
>>> passed but the task_ids parameter is not or it is None.
>>> >
>>> > -----Original Message-----
>>> > From: Foldvari, Gyorgy via dev <[email protected]>
>>> > Sent: Wednesday, April 15, 2026 13:42
>>> > To: [email protected]
>>> > Cc: Foldvari, Gyorgy <[email protected]>
>>> > Subject: RE: Re: [DISCUSS] Reconsidering `xcom_pull(task_ids=None)`
>>> > behavior change in Airflow 3
>>> >
>>> > CAUTION: This email originated from outside of the organization. Do
>>> not click links or open attachments unless you recognize the sender and
>>> know the content is safe.
>>> >
>>> >
>>> > The original behavior is to return the most recent value put by any
>>> upstream task of the same run. Not all the values, only the recent one.
>>> > Supposing that there are multiple tasks pushing values to XCom in this
>>> order:
>>> > Task1: ti.xcom_push(key="example", value=1)
>>> > Task2: ti.xcom_push(key="example", value=2)
>>> > Task3: ti.xcom_push(key="example", value=3) Then in a downstream task
>>> ti.comm_pull(key="example") returns 3.
>>> > I do not propose to change this behavior.
>>> >
>>> > On 2026/04/14 16:09:05 Daniel Standish via dev wrote:
>>> >> So the behavior before would be that it would return all xcom values
>>> >> that were emitted from the present run?
>>> >>
>>> >
>>> >
>>> > ________________________________
>>> >
>>> > Information regarding MSCI's processing of personal data may be found
>>> > at http://www.msci.com/privacy-pledge. This email message and any
>>> attachments
>>> > are for the sole use of the intended recipients and may contain
>>> > proprietary and/or confidential information which may be privileged or
>>> > otherwise protected from disclosure. Any unauthorized review, use,
>>> > disclosure or distribution is prohibited. All rights and remedies are
>>> > reserved. If you are not an intended recipient, please contact the
>>> > sender by reply email and destroy the original message and any copies
>>> > of the message as well as any attachments to the original message.
>>> > Local registered entity information:
>>> > https://www.msci.com/local-registered-entities
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: [email protected]
>>> > For additional commands, e-mail: [email protected]
>>> >
>>>
>>>
>>> ________________________________
>>>
>>> Information regarding MSCI’s processing of personal data may be found at
>>> http://www.msci.com/privacy-pledge. This email message and any
>>> attachments are for the sole use of the intended recipients and may contain
>>> proprietary and/or confidential information which may be privileged or
>>> otherwise protected from disclosure. Any unauthorized review, use,
>>> disclosure or distribution is prohibited. All rights and remedies are
>>> reserved. If you are not an intended recipient, please contact the sender
>>> by reply email and destroy the original message and any copies of the
>>> message as well as any attachments to the original message. Local
>>> registered entity information:
>>> https://www.msci.com/local-registered-entities
>>>
>>
