microsandbox-rb 0.15.0 → 0.17.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 241dfe5d94b8c98d3c790994698b004a591d66229d9965799fc5886b01e5a19d
-  data.tar.gz: a134b4cbb4b58a60d72d6a7ace30ab6333da4057d0868c1a6e351396b7ff4d00
+  metadata.gz: 37f44ca952f2885719237b06ea10b5316c383fee0a2fdfa5c51c76fd295c1591
+  data.tar.gz: 81e55203c1aea73d0368d93d7c36c73015b9a5a97634b69a3f5d805a48c7446c
 SHA512:
-  metadata.gz: c326c0481781ae1f3fc19994dfd8e4c004c4bdc8aa81b33e67386538f4fa9ff58cb84514955079c39daa09817c8eba65ac7d4ebe91ab34698ac5fce8cfa9c574
-  data.tar.gz: 1d93018f5982d2767cd66e29c50a195a3d138d7f60f93a2a3e6020384f41ce843e3a0b85d5152a2d17995a724ed9cc6169e72c0bcfc506017e7ae84b3acbe73f
+  metadata.gz: 49876e1d24e9e64ab486932f6180c511ea5142a93f8b1c0edb67f04847b861310a4972046b08babe11679f88835883fa80b739fd2f8d5f7ff5d49316f6c26c8d
+  data.tar.gz: 3bf053fb8c2e63099c128655fce91335c3ce35c7459af3616acad7d3b773f32184107740c124df2e7f122053d807f74c2d9f6337f66d0c6ed9121c4ddadd2eb3

data/CHANGELOG.md

@@ -6,6 +6,203 @@ 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
+intermediate tag (`v0.6.15` verified and committed on its own).
+
+### Added
+
+- Per-mount fallback ownership: a bind or named mount in `volumes:` accepts
+  `uid:`/`gid:`, pinning the guest owner presented for host files that carry no
+  per-file stat override (upstream #1451, `v0.6.15`). They travel on the wire as
+  the core's `override_uid`/`override_gid` and mirror the Python SDK's public
+  `uid:`/`gid:` spelling. Validation matches the Python SDK: the pair must be
+  given together, each must be a plain `Integer` in `0..4294967295` (strings,
+  Floats and Booleans are rejected rather than coerced — a truncated or parsed
+  owner ID is never what the caller meant), and they conflict with both
+  `stat_virtualization: :off` (no overlay to rewrite the owner in) and
+  tmpfs/disk mounts. The one Python rule with no Ruby counterpart is
+  "unsupported for disk-backed named volumes": a Ruby `{ named: "vol" }` spec
+  only references an existing volume by name, so the volume's kind is known
+  only to the core, which rejects that combination at create time.
+- **Convergent lifecycle APIs** (upstream #1462, `v0.6.16`) — idempotent
+  operations that take a name to the state you want, whatever state it is in
+  now:
+  - `Sandbox.connect_or_create(name, **kwargs)` — connect to (and start) the
+    persisted sandbox with this name, or create it when none exists; concurrent
+    callers converge on the winning identity instead of one losing to a name
+    clash. Takes exactly `create`'s keyword options — the same normalization
+    path, not a second copy of it — and they apply only when a create actually
+    happens. The block form yields the sandbox and then stops it **only when the
+    call owns its lifecycle** — a deliberate divergence from `create`, whose
+    block form always stops: `connect_or_create` can hand back a sandbox this
+    process did not start, and tearing down someone else's long-lived service on
+    the way out of a block is never what the caller meant. So a sandbox created
+    here is stopped as usual; one merely *connected* to, or started with
+    `detached: true`, is left running. `replace:` / `replace_with_timeout:` are
+    accepted for kwargs parity but rejected by the core with
+    `InvalidConfigError`: replacing a sandbox is the opposite of converging
+    on it.
+  - `Sandbox#id` and `SandboxHandle#id` — the opaque, backend-assigned identity
+    of the *persisted* sandbox. Names are reusable labels; this changes when a
+    name is removed and recreated.
+  - `Sandbox#wait_for_status(status)` and `SandboxHandle#wait_for_status(status)`
+    — block until this exact sandbox reaches one of `:created`, `:starting`,
+    `:running`, `:draining`, `:paused`, `:stopped`, `:crashed`, returning a fresh
+    `SandboxHandle` (from both receivers, mirroring the official SDKs). There is
+    no built-in timeout and the wait is uninterruptible from Ruby (the native
+    call releases the GVL with no unblock function), so an unknown status name
+    raises `ArgumentError` up front rather than blocking forever — and only
+    states the active backend can reach are worth waiting for (`:created` and
+    `:paused` are cloud-side). Impose a deadline by running the call on its own
+    Thread.
+  - `Sandbox#restart(force:, timeout:, detached:)` and
+    `SandboxHandle#restart(...)` — stop and start this exact sandbox, returning a
+    new live `Sandbox`.
+  - `Sandbox#destroy(force:, timeout:)` and `SandboxHandle#destroy(...)` — stop
+    and remove this exact sandbox in one step.
+  - `SandboxHandle#connect_or_start(detached:)` — connect when the sandbox is
+    running, wait while it is starting, start it when it is created/stopped/
+    crashed.
+- `Microsandbox::SandboxReplacedError` (code `"sandbox-replaced"`) — raised by
+  every one of the identity-checked operations above when the name now refers to
+  a different persisted sandbox, instead of quietly acting on the replacement.
+  Mirrors the Python SDK's `SandboxReplacedError`; wired into the native
+  error-code mapping like the other `sandbox-*` codes.
+
+### Fixed
+
+- **The live `Sandbox#stop` no longer stops a same-name replacement.** The
+  binding re-fetched a `SandboxHandle` *by name* and stopped that — a pattern
+  left over from before the core's live `stop` was identity-scoped. As of
+  runtime v0.6.16 the core routes `stop` → `request_stop` →
+  `stop_identified(name, self.identity())`, so the fix is to route through the
+  live sandbox (`self.inner.stop()`) the way `kill`/`drain`/`wait`/
+  `stop_and_wait` already did, and the way both official bindings do. A sandbox
+  removed and recreated under the same name now raises `SandboxReplacedError`
+  (or `SandboxNotFoundError` when nothing holds the name) instead of terminating
+  whoever answers to it. This also hardens `Sandbox.connect_or_create`'s block
+  form, whose teardown calls `#stop`.
+- **Operations that can boot a microVM now provision the runtime first.**
+  `SandboxHandle#connect_or_start`, `SandboxHandle#restart` and
+  `Sandbox#restart` were missing the `ensure_runtime!` call `Sandbox.create` and
+  `Sandbox.start` make, so on a machine with no runtime installed they failed in
+  the native layer instead of fetching it. (`Sandbox.connect_or_create` was
+  already covered — it shares `create`'s option builder.)
+
+### Changed
+
+- Upstream runtime highlights carried without further Ruby surface:
+  - `v0.6.15` — read-only mounts no longer fail a write probe at mount time,
+    Windows DNS/NTFS handling, and the mount-ownership core work above.
+  - `v0.6.16` — log retrieval rerouted through the SDK backends (#1459; the
+    `logs`/`log_stream` bindings are unchanged and keep their behaviour — the
+    new `follow_logs`/`boot_error` core entry points are not bound, matching the
+    Python binding), sandbox config overlaid by field presence with
+    `LocalConfig` renamed to `GlobalConfig` (#1460; the gem touches neither —
+    the ext only calls `config::set_sdk_*_path` — and no Ruby config
+    round-trip or `modify` semantics changed), network-slot recycling and
+    migration, single-file mount isolation, empty `MSB_HOME` treated as unset.
+
 ## [0.15.0] - 2026-08-24
 
 Adopts upstream runtime **`v0.6.9` → `v0.6.14`**, stepping through every