v0.45.2

v0.45.2

Security fix. Upgrade from 0.45.1 if you run the HTTP transport, or if you call
operate/fetch on records you did not publish yourself.

Fixed

• A record's file URL could make the server read addresses the caller cannot
  reach. operate and fetch take that URL straight from an upstream record,
  and every source that accepts uploads — Zenodo, HuggingFace, figshare, OpenML —
  lets it be anything. A record whose file was NAMED data.csv while pointing at
  http://127.0.0.1:9200/ or http://169.254.169.254/ was fetched, and with
  op='head' the body came back to the caller as rows.

  None of the existing controls covered this, each for a structural reason:

  • The DuckDB filesystem lock added in 0.45.0 is applied AFTER the source is
    materialized, and must be — a lazily-evaluated view would be blocked along
    with the legitimate read. It protects the user's SQL, not the source read.
  • The scheme allowlist governs HOW we fetch, never WHERE.
  • The operable-file check gates on the file's NAME, so the extension test never
    looked at the URL at all.

  A new egress guard resolves the host and refuses private, loopback, link-local,
  reserved, multicast and unspecified addresses before any request is made.

  Harmless over stdio, where the server is the caller's own child process and
  shares its network position. The exposure was SSRF with response exfiltration
  under --transport http, where the server may sit in a network the caller
  cannot otherwise reach.

  Set DATA_AGGREGATOR_MCP_ALLOW_PRIVATE_EGRESS=1 if you deliberately serve
  records from private address space.

  Two limits stated rather than implied: a host that does not resolve is still
  allowed through, because it points nowhere and refusing it would block offline
  callers while closing nothing; and this does not defeat DNS rebinding, which
  would require pinning the checked address into the connection itself.