potiuk commented on PR #70884:
URL: https://github.com/apache/airflow/pull/70884#issuecomment-5151137723
Superseded by #70886, which now targets the same 3.4.0 milestone.
@shahar1's review here found that the cross-team read is still open in a
spelling
none of these guards reach: a caller in `team_a` asking for the **bare** id
`prod___dbconn` builds `AIRFLOW_CONN__TEAM_A___PROD___DBCONN`,
byte-identical to
what team `team_a___prod` builds for id `dbconn`. The *scoped* lookup hits,
so the
team agnostic fall-through — which is all this PR narrows — is never
consulted. I
reproduced it; it returns the other team's secret.
The root cause he identified is that `___` is not reserved, so
`_<TEAM>___<ID>`
does not parse uniquely, and every revision here has been an after-the-fact
ambiguity check. #70886 fixes that at the source by forbidding
**consecutive**
underscores in a team name (relaxed from forbidding every underscore, so
`team_a`
stays legal). With the separator unspellable the split becomes one
`partition`,
and `team_a___prod` simply stops being a name a team can have.
His other two findings are folded in there as well:
- `teams sync` now validates **stored** names, not only the bundle config —
it
shipped in 3.3.0 with no validation, so an upgrading deployment can
already hold
a name the guard cannot recognise;
- the pattern is defined once and imported, unanchored and used with
`re.fullmatch` throughout, with a test pinning that the CLI and backend
agree —
`re.match` against a `$`-anchored pattern accepts a trailing newline and
the sync
path has no `.strip()`.
This PR is now a draft on 3.4.0 with the backport label removed. Closing it
in
favour of #70886 once that lands; leaving it open for now so the review
thread
stays reachable.
Worth stating plainly: the relaxation here rested on team names being at
least 3
characters, and `teams sync` never enforced that — so its new test asserting
`_ab___x` **must** resolve was pinning the vulnerable behaviour. Good catch.
--
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]
