refactor: restrict OpenAPI $ref resolution to in-document pointers

[etairl]

Summary

• OpenAPIServiceToFunctions._parse_openapi_spec was calling jsonref.replace_refs with the library default loader, which dispatches arbitrary $ref URIs to the filesystem (file://) and the network (http(s)://).
• Pass an explicit loader that refuses any non-in-document $ref and set proxies=False so references must resolve eagerly during parsing.
• In-document JSON-pointer references (those starting with #) continue to work unchanged.

This is a defensive hardening change for OpenAPI specs whose contents are not fully trusted (e.g. fetched from third-party catalogs, generated by an LLM, or uploaded by end users). Specs that depend on external $ref resolution will now raise a RuntimeError instead of silently performing filesystem reads or outbound HTTP requests.

Test plan

• CI runs OpenAPIServiceToFunctions unit tests with the new loader.
• Manual: a spec containing an in-document $ref (e.g. #/components/schemas/Foo) still resolves correctly.
• Manual: a spec containing $ref: file:///etc/passwd or $ref: http://... raises and does not perform the I/O.

🤖 Generated with Claude Code

[vercel]

@etairl is attempting to deploy a commit to the deepset Team on Vercel.

A member of the Team first needs to authorize it.

[anakin87]

Hello, @etairl!

Could you better explain why this is needed?
Please also read our security policy before. If you have identified a vulnerability, please send us the details confidentially via email.

I also noticed that you opened multiple PRs. I'd suggest focusing on one at a time.

[etairl]

Hello, @etairl!

Could you better explain why this is needed? Please also read our security policy before. If you have identified a vulnerability, please send us the details confidentially via email.

I also noticed that you opened multiple PRs. I'd suggest focusing on one at a time.

Hi @anakin87,

Sorry about the spam (they've been sitting in my todos for a few days, created the PRs today in one batch). So on one hand this probably falls under out of scope category ("attacker-controlled input to Haystack is considered out of scope"). The reason it still should be a PR is that users expect "parse this spec" to just parse - not to read files or hit the network, so the default should be safer. This is security hardening rather than vulnerability patching.

[anakin87]

Thank you! I'll give this a better look later...

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
haystack/components/converters
openapi_functions.py					241, 268
Project Total

This report was generated by python-coverage-comment-action

[CLAassistant]

All committers have signed the CLA.

[etairl]

Thank you! I'll give this a better look later...

Thanks. Let me know of any required changes / questions.