Clarify security model for fetching remote content with HTTP module imports

[til2000]

Description

Clarify security model for HTTP module imports

I was reviewing the security model around network access and found an ambiguity worth clarifying.

Issue #1147 established network access as a permission-controlled capability. However, I could not find documentation or an issue explaining whether HTTP module imports are covered by the same permission boundary.

The relevant code is:

crates/mq-run/Cargo.toml
    default = ["std", "use_mimalloc", "http-import", "css-selector", "watch"]

crates/mq-lang/Cargo.toml
    http-import-ureq = ["http-import", "http"]

crates/mq-lang/src/module/resolver.rs
    HTTP module resolver setup

crates/mq-lang/src/module/resolver/http_import.rs
    HTTP/GitHub import handling

crates/mq-lang/src/module/resolver/http_resolver.rs
    Fetching remote modules

The important point is that an HTTP module is not just data. The fetched .mq file becomes source code and is evaluated by mq.

That raises a few questions:

1. Why is http-import enabled in the default CLI feature set?
2. Is remote module loading intentionally part of the default security model?
3. When network access is denied through the permission/sandbox system, is an HTTP module import guaranteed to fail without making an outbound request?
4. If not, is the HTTP module resolver intentionally outside the Io/SandboxedIo permission boundary?
5. Would it be safer to make remote module imports explicit opt-in, for example with --allow-http-import and --allowed-domain?
6. Is the first download of a remote module intentionally trust-on-first-use, or is the lockfile expected to be present first for reproducible/CI use?

I am not reporting this as a vulnerability at this point. I am looking for clarification of the intended security model, particularly whether SandboxedIo is supposed to mean that evaluated mq code has no network access.

This matters because mq is commonly used as a local data-processing tool, while the default build also enables retrieval and execution of remote mq source.

Steps to Reproduce

.

Environment

.

Additional Context

No response

Checklist

• I searched existing issues to make sure this bug hasn't already been reported.
• I am using the latest version of mq.

[harehare]

Thanks for the detailed report, really appreciate you digging into this.

http-import predates the sandbox/permission system. When SandboxedIo (--allow-net/--allow-read/etc.) arrived, module resolution was kept outside it on purpose, so existing HTTP-import users wouldn't suddenly need --allow-net for something that already worked. That's the compatibility reason behind the code you found.

Answers:

• 1-2. Yes, intentionally in the default build, scoped to one default domain, not open to arbitrary hosts. It's also top-level only: a module reached via import/include can't itself trigger another HTTP import, so there's no way for a script to pull in remote code you didn't write yourself.
• 3-4. No, and that's the real gap. --allow-net only ever gated the http()/http_request() builtins, never module resolution, so denying it didn't stop an import from making a request. Not unprotected though: HTTPS-only, SSRF-hardened client, 1 MiB cap, HTML rejection all applied regardless.
• 5. Agreed. Addressed in 🔒 feat(mq-lang,mq-run): make HTTP module imports opt-in via --allow-http-import #2199, landing in the next release: HTTP imports will be opt-in via a new --allow-http-import flag, separate from --allow-net. --allowed-domain still scopes hosts once enabled.
• 6. TOFU is intentional, but you're right it shouldn't be silent in CI. mq.lock doesn't need to pre-exist, so a new dependency could get trusted mid-pipeline instead of during a reviewable local run. Also in 🔒 feat(mq-lang,mq-run): make HTTP module imports opt-in via --allow-http-import #2199: a new --frozen flag turns a missing mq.lock entry into a hard error instead of recording it. Record locally once, commit the diff, then require --frozen in CI.

SandboxedIo/--allow-net was really scoped to "what a running query's builtins can do," not "no network anywhere in this process," and that distinction wasn't written down anywhere. Fix is in #2199, landing in the next release: without --allow-http-import (or --allow-all), any HTTP/GitHub import will fail immediately, no request made.