RehanAhmad25 commented on issue #72377:
URL: https://github.com/apache/airflow/issues/72377#issuecomment-5511457267
Yes, exactly, and I checked to be sure rather than just agree.
`Connection.password` goes through the identical path:
`_mask_connection_secrets()` in
`task-sdk/src/airflow/sdk/execution_time/context.py` calls
`mask_secret(conn.password)` at fetch time, same as what we're planning for
password-format params. Its own docstring even says what it's for: "Mask
sensitive connection fields from logs." Not everywhere, from logs. There's
nothing in that flow that special-cases XCom either, so `{{ conn.password }}`
pushed to XCom today shows up in plaintext in the XCom UI right now, completely
unrelated to this issue.
So this isn't a new limitation our change introduces, it's the same known
tradeoff that already exists for every secret `mask_secret()` touches. If a
task deliberately hands a secret to something outside masking's reach (XCom, a
return value, a print statement targeting a channel outside logging), it'll
show up there. Good to have that confirmed before I start, means I don't need
to treat the XCom point as a gap in this PR, just as expected/existing behavior
consistent with how Connections already work.
--
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]
