microsandbox-rb 0.16.0 → 0.17.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 011c5bcfdd4eff6b2f86ec6ded70720520b5c77d93ceb575dc4ac9b0ce0a5078
-  data.tar.gz: 2e84a073bd4852e2cdbc124f4ce6b400beb5b20012c6b9ff81833169f13d58e1
+  metadata.gz: 37f44ca952f2885719237b06ea10b5316c383fee0a2fdfa5c51c76fd295c1591
+  data.tar.gz: 81e55203c1aea73d0368d93d7c36c73015b9a5a97634b69a3f5d805a48c7446c
 SHA512:
-  metadata.gz: 6a12d8b308f479630dc8b266c3129bb7e337939da1963faf975fda7ebb890fe95d50ccbf77b37e9f33d3ccb0506dd94633e0374ac6c52cac599c6c80348ee931
-  data.tar.gz: 730a26aef15b87d348e95a23ede127520aee10d410856526f956d3366118959dc51f60d418e7c876781191be0c72009daafaa442a353afc6b6010643adf1a46f
+  metadata.gz: 49876e1d24e9e64ab486932f6180c511ea5142a93f8b1c0edb67f04847b861310a4972046b08babe11679f88835883fa80b739fd2f8d5f7ff5d49316f6c26c8d
+  data.tar.gz: 3bf053fb8c2e63099c128655fce91335c3ce35c7459af3616acad7d3b773f32184107740c124df2e7f122053d807f74c2d9f6337f66d0c6ed9121c4ddadd2eb3

data/CHANGELOG.md

@@ -6,6 +6,104 @@ All notable changes to this gem are documented here. The format is based on
 microsandbox runtime it embeds; each release notes the upstream runtime tag it
 wraps, and the README's Versioning section keeps the full gem→runtime map.
 
+## [0.17.0] - 2026-09-13
+
+Adopts upstream runtime **`v0.6.16` → `v0.6.18`**, stepping through the
+intermediate tag (`v0.6.17` verified and committed on its own).
+
+### Added
+
+- **Strict hostname policy** — `strict:` (Boolean, default `false`) on
+  `Sandbox.create` / `connect_or_create` / `create_with_progress` (upstream
+  `v0.6.18`, from the security fork-merge below). In strict mode a flow that the
+  egress policy allows *only* through a hostname rule must be backed by an
+  inspectable request authority — the plain-HTTP `Host` header, or SNI /
+  `:authority` under TLS interception. Without that visibility (bypassed or
+  non-intercepted HTTPS) the runtime fails closed *before* dialing upstream
+  instead of trusting opaque hostname evidence. Mirrors the Python SDK's
+  `Network(strict=...)`. An explicit `false` is sent as-is (not dropped), like
+  `trust_host_cas:`. Create-only in Ruby, matching the Python SDK's `modify`
+  surface (which does not expose `strict`); the core itself does carry a
+  generated `strict` field on its network config patch (`ConfigPatch` derive),
+  so this is an SDK-parity choice, not a core limitation. Accepted by the cloud
+  create contract (`CloudNetworkSpec.strict`), so there is no `UnsupportedError`
+  path.
+
+- **Outbound SOCKS proxies** — `proxy:` on `Sandbox.create` /
+  `connect_or_create` / `create_with_progress` (upstream #1234 SOCKS4/SOCKS5
+  and #1507 SOCKS5 UDP + credentials, `v0.6.17`). The runtime's host-side
+  network stack dials the proxy for the sandbox's egress — SOCKS4 for TCP,
+  SOCKS5 for TCP and non-DNS UDP — uniformly for TLS-intercepted and
+  bypassed/plain TCP, while the egress policy (`network:`) still decides which
+  destinations may be reached. The address is resolved from the **host**
+  (`127.0.0.1` is the host's loopback). Spelled like the Python SDK's
+  `proxy=`, as a top-level create option rather than inside `network:`:
+  - `Microsandbox::OutboundProxy.socks4(address, user_id: nil)` and
+    `Microsandbox::OutboundProxy.socks5(address)`, the latter chaining
+    `#credentials(username, password)` which returns a **new** proxy (the
+    objects are immutable, like Python's frozen dataclass).
+  - `Microsandbox::SecretSource.env("VAR")` — the only password source: the
+    host environment variable's *name* is what reaches the runtime, which reads
+    the value host-side. No password value ever travels through the binding or
+    appears in `inspect`/error output.
+  - The equivalent plain Hash is accepted too: `{ protocol: :socks5,
+    address: "IP:port", credentials: { username:, password: { env: "VAR" } } }`
+    or `{ protocol: :socks4, address:, user_id: }`.
+  - Validation mirrors the Python SDK's `OutboundProxy.__post_init__`
+    (`ArgumentError`): `user_id` only for SOCKS4, credentials only for SOCKS5,
+    username and password together or neither, a non-empty String address.
+    `IP:port` parsing is left to the core, which reports an unparseable address
+    (or an invalid SOCKS4 user ID) at create time, before any boot; the binding
+    surfaces that as `InvalidConfigError` — a malformed proxy is a configuration
+    mistake, not a policy one — while every other network-builder error keeps
+    its `NetworkPolicyError` class. The cloud backend rejects the option with
+    `UnsupportedError` (`sandbox.create`, hint naming `network.outbound_proxy`).
+
+### Changed
+
+- **Plain-HTTP requests are now checked against the egress policy by their
+  `Host` / `:authority`, whenever the policy has any domain rule — in
+  non-strict mode too** (upstream `v0.6.18` hardening, `crates/network/lib/
+  tcp/proxy.rs`: `enforce_http_authority = network_policy.has_domain_rules()`).
+  Previously a plain-HTTP connection admitted by an IP/CIDR/group rule could
+  name any host in its `Host` header; now, if the policy carries `Domain` /
+  `DomainSuffix` rules (including `deny_domains:` / `deny_domain_suffixes:`,
+  which are domain rules), the request's authority is evaluated against the
+  **ordered** egress policy (rules first, then `default_egress`) together with
+  the real destination IP/port, and — for a request carrying valid authority
+  metadata — the request is denied only when that evaluation denies it.
+  Separately, a plain-HTTP request with a *missing*, *duplicate* or
+  *unparsable* `Host` / `:authority` is now rejected outright whenever domain
+  rules are present (the upstream validator requires exactly one well-formed
+  authority before any policy evaluation), so an HTTP/1.0 request without a
+  `Host` header no longer passes on such a policy. Existing IP/CIDR/group allows and a permissive
+  `default_egress` still count: a plain-HTTP request to an allowed IP that
+  sends an unrelated `Host` is still allowed unless a rule (or the default)
+  denies that hostname. Policies with no domain rules are unaffected, and so is
+  HTTPS without interception. What changes in practice: an IP-based request
+  whose `Host` names a host the ordered policy *denies* (a `deny_domains:`
+  entry, or a domain not matched by any allow under `default_egress: :deny`)
+  now fails even in non-strict mode — allow the hostname it actually sends.
+  `strict:` is not a substitute for a restrictive policy; it only tightens
+  hostname-rule allows that lack an inspectable authority.
+
+### Security
+
+- Runtime `v0.6.18` carries the upstream security fork-merge (`439a88a5`, no
+  public advisory identifier at the time of writing): aligns HTTP `Host` policy
+  checks with the rest of the egress enforcement (the Changed note above) and
+  adds the fail-closed pre-connect strict hostname mode (`strict:` above). No
+  gem-side change was needed beyond exposing `strict:`.
+
+### Fixed
+
+- Runtime `v0.6.17` restores the released database-migration order (upstream
+  #1517, fixing #1502): a local `~/.microsandbox` database last opened by an
+  upstream **`v0.6.15`** binary — typically the `msb` CLI, since this gem never
+  shipped `v0.6.15` on its own — failed to open under `v0.6.16` with "database
+  schema is newer than this msb binary". Any such database now migrates
+  forward cleanly on the next `require "microsandbox"` + first operation.
+
 ## [0.16.0] - 2026-09-01
 
 Adopts upstream runtime **`v0.6.14` → `v0.6.16`**, stepping through the