potiuk commented on PR #3052: URL: https://github.com/apache/drill/pull/3052#issuecomment-4792565319
Thanks @cgivre — both points folded into `THREAT_MODEL.md` (just pushed): 1. **`contrib/` plugins are in scope.** You're right that the storage/format plugins under `contrib/` ship with Drill and are maintained as part of the project — they carry the same connector trust surface as the core storage plugins. I'd over-broadly lumped them into the "tests/examples" out-of-scope bullet. Fixed in three places: the §2 component-family table now has a dedicated **"`contrib/` storage + format plugins → In"** row; §3 narrows the out-of-scope bullet to tests/examples/sample-data only, with an explicit "the `contrib/` plugins **are** in scope" note; and the §13 `unsupported-component` disposition row carries the same caveat so a triager can't misroute a `contrib/` finding. 2. **Storage/filesystem enumeration is by-design, not a vuln.** Added a `KNOWN-NON-FINDING` bullet to §11a capturing exactly this: *"Drill can enumerate / read the files, schemas, or storage systems it is pointed at"* is the **function** of a federated query engine, not a vulnerability — in-model only when the access crosses the authenticated identity's authorization (reading data an impersonated user shouldn't, or bypassing a Drill view). It cites your "yes… that's the point of Drill" framing directly, so the audit has a citable line to suppress that whole class. Also tagged the relevant §14 question as partially answered by your review. The model is still a v0 draft for the PMC to react to — corrections welcome on any of the *(inferred)* claims. -- 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]
