[Bug][security][skills] Protect URL skill sources with secure transport and integrity verification

[wenjin272]

Description

Skills.from_url(...) / Skills.fromUrl(...) currently accepts both http:// and https:// skill archives in Python and Java. The archive is downloaded and extracted without checking an operator-supplied digest or other integrity expectation.

Remote skill content is privileged: its SKILL.md becomes instructions consumed by the agent, and its bundled resources may be used by the built-in tools. A URL skill source should therefore be treated with the same care as executable code rather than ordinary configuration data.

Flink Agents is currently in the experimental 0.x release series and does not provide production-readiness guarantees. This issue tracks the hardening needed before production readiness / 1.0.

Expected behavior

• Reject plain HTTP URL skill sources by default. If an unsafe compatibility opt-in is retained, it should be explicit and clearly documented.
• Allow an operator to pin an expected content digest, initially SHA-256, and verify it before extraction.
• Fail closed with a clear error when transport or integrity requirements are not met.
• Keep the source configuration and behavior aligned across Java and Python, including plan serialization where applicable.
• Document that remote skill content is trusted instructions/code and explain how skill directories interact with the built-in tools.
• Add focused Java and Python tests for HTTP rejection or opt-in behavior, matching and mismatching digests, and unchanged safe extraction behavior.

How to reproduce

1. Serve a valid skill archive over plain HTTP.
2. Configure it through Skills.from_url(...) or Skills.fromUrl(...).
3. Observe that the archive is accepted and materialized.
4. Change the archive at the same URL and load it again.
5. Observe that the changed content is accepted without any integrity signal or operator-provided expectation.

Version and environment

Confirmed in Apache Flink Agents 0.3.1 and on main as of 2026-08-12, in both the Java and Python implementations.

[weiqingy]

One thing that came up reviewing #1005, adjacent to this but maybe not inside it.

Neither runtime bounds how many bytes a URL skill source writes. The download streams straight to a temp file (shutil.copyfileobj in _materialize.py, Files.copy in SkillMaterializer.java), and extraction is unbounded too, so a small archive can expand well past its transfer size. Pinning doesn't help, since the digest is computed only after the file is already on disk, so a source that streams indefinitely fills TaskManager disk before any check runs.

Same code path as this issue, different property though: resource exhaustion rather than transport or integrity. And since #1005 implements the bullets here, adding it now would widen the scope late.

In scope for this one, or better tracked separately?

[wenjin272]

In scope for this one, or better tracked separately?

Thanks for raising this @weiqingy. I agree it would be better tracked in a separate issue. Although it shares the same materialization path, download and extraction size limits address resource exhaustion, while #1003 focuses on secure transport and integrity verification. Let’s keep #1005 focused and handle this in a follow-up issue.

[weiqingy]

Sounds good. Filed as #1072, scoped to download and extraction size limits in both runtimes, so this one stays on transport and integrity.