potiuk opened a new pull request, #72172: URL: https://github.com/apache/airflow/pull/72172
## Why The *What is NOT considered a security vulnerability* section of the security model opens by saying it is written for security researchers **and AI agents performing security analysis** to read before reporting. That framing is right, and it is increasingly load-bearing as automated analysis becomes a common source of reports. Several recurring report shapes are not covered by it. Each currently costs a triage cycle to re-derive from first principles, and — because the reasoning ends up only in closed-issue discussions — it gets re-derived again next time. Writing the boundaries down is cheaper than answering them repeatedly, and lets a reporter self-serve before spending their own time on something out of scope. ## What **Five new entries**, covering boundaries the project already applies in practice: | Section | Boundary | |---|---| | Client libraries and caller-supplied values | A library acts on what its calling application passes it; that application owns the trust decision — the same position already taken for Dag authors passing unsanitized input to operators. Includes the converse: a library mishandling *correctly*-supplied input is in scope. | | Experimental and alpha features | Features documented as experimental or alpha carry no guarantees yet. Worth fixing, but not handled through this process — with an explicit clause to reassess when a feature graduates. | | Request size limits and other reverse-proxy responsibilities | Bounding request size belongs at the terminating proxy. Stated as **distinct** from the authenticated-DoS entry, since it applies to unauthenticated requests too, including endpoints that must be reachable without credentials. | | Issues only reachable on end-of-life versions | No release in which to ship a fix — including where a provider package still installs on that line. | | Params and schema validation | A correctness feature, not a control. Declaring no params opts out of validation rather than asserting the field will be empty. | **One existing entry sharpened.** *Connection configuration capabilities* currently reads, in effect, as "this role is privileged, so nothing counts." That is too broad in one direction and unhelpful in the other. The revision draws the line actually applied: - **Within the grant** — worker-context execution, and the connection values the role may write, even where the mechanism resembles injection. - **Outside it** — recovering credential material the role cannot read (the role has *write-only* access to stored credentials), or reaching a component it has no execution rights over. The distinguishing question is what the defect *yields*, not which role holds it. **One limitation recorded.** The hardening guidance states workers must never hold the JWT signing key. The `edge3` worker signs its own API requests, so remote edge-worker hosts must be provisioned with `[api_auth] jwt_secret`, and there is no asymmetric alternative on that path. That also voids the assurance in *Token signing key might be a shared secret*, which is explicitly conditioned on the secret reaching only the API server and scheduler. Deployment Managers should either treat edge-worker hosts as part of the control-plane trust boundary, or accept the equivalence knowingly. Documenting it is the resolution — the alternative is an architectural change to how edge workers authenticate. ## Notes - Additions only. No existing entry is narrowed, and nothing previously in scope moves out of it. - The experimental-features entry deliberately defers rather than dismisses, via the graduation clause. - No new `:ref:` targets are introduced; cross-references are by section name to avoid adding labels. - RST heading/underline structure verified, and `docutils` parses the file with no new errors — the pre-existing ones are Sphinx-only roles and the `mermaid` directive, which bare docutils does not recognise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
