yamine 0.20.0 → 0.21.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: c48a7ce222b3ffe113f542e81d84aca45270e4c3ea4f4f7da74bd22e8d0747d7
-  data.tar.gz: 8a8c1ad0f17b8bd741723cb9d83100248c559f5c7c995d64f30abfcebfe4fa60
+  metadata.gz: 8e920f5f6d29a92e0a6e81ca671bccf62e0a264ec453f9b5bc4d42d4e56980d3
+  data.tar.gz: cc06342930ee7c882cf30fd2818f1a60495c8a59e44ec6779cc666f569493ac0
 SHA512:
-  metadata.gz: c9c3ae18ac29e5a30b378d7b70c7dd6c538b9140b058f4308ee2d9e5075567cde9ea21d169d30c54808d6a06a4283d3454d2a652b4b254b40e406d2de4a7edbc
-  data.tar.gz: 594bf48948e649c390aa3aed20246abd1c0eabbd0889f2a159f3b4a35d77b0d8cf8874b1eb1f8ebb51be9b0dc4300879139b943a35bde12fbc421a789b08f809
+  metadata.gz: 4164dabf9bd5537023ad59d426a958a5e284a90f0226cc83e0533cf635edf0c65acc16dd311d58a88df83d7abdcdfb92034703ecda06d89af08bb5ec96c73635
+  data.tar.gz: 1e3af2b55e54885fe8aeed98856c4371eab280ec981cd2644ebb75aba0206752ae44307c0252f51188a778426efbb882ef2285c63f142def39f4e876f77302d6

data/CHANGELOG.md

@@ -2,6 +2,105 @@
 
 ## [Unreleased]
 
+## [0.21.1] — 2026-09-29
+
+### Fixed
+
+- **Claiming a per-worktree database no longer raises `NoMethodError`
+  on Ruby 3.2/3.3.** The claim stamps the state file with
+  `Time#iso8601`, but `lib/yamine/database.rb` never required the
+  stdlib `time` library, and on 3.2/3.3 nothing else loads it
+  implicitly — so every claim raised (34 unit errors on those rubies
+  in CI). 0.21.0 is affected. One `require "time"`, alongside the
+  stdlibs that file already pulls in.
+- **A closed WebSocket upgrade no longer leaks a thread on Linux.**
+  `pipe_both` tore each end down with `close` from the sibling
+  thread, and a close from another thread does not interrupt that
+  copy's blocking read on Linux (it does on macOS) — so every closed
+  upgrade parked a thread forever, `handle` never unwound, and they
+  accumulated in the root daemon. Teardown is now symmetric
+  `shutdown(2)`, which wakes the parked read with EOF; both sockets
+  still close exactly once, and no timeout was added to the
+  unbounded upgrade path.
+
+## [0.21.0] — 2026-09-28
+
+### Security
+
+- **The privileged service no longer runs user-writable code.** The
+  launchd/systemd unit used to execute the gem's `bin`+`lib` straight
+  out of the user's home (a version-stamped, user-writable gem
+  directory), so anything that could write those paths — a gem upgrade,
+  a `bundle install`, an agent editing the gem — ran as root at every
+  boot. `service install` now stages `bin`+`lib` into a root-owned
+  directory at a stable, version-independent path (`/Library/Application
+  Support/yamine` on macOS, `/usr/local/share/yamine` on Linux):
+  copied aside, ownership/modes locked, verified fail-closed (a bad
+  tree registers no unit and leaves the running daemon untouched), then
+  swung live with an atomic symlink swap plus a root-owned `VERSION`
+  marker. The unit pins only that path.
+- **The passwordless grant can no longer introduce root-executed
+  code.** `yamine sudoers` used to grant the version-stamped gem path
+  with `service install --internal` — effectively arbitrary code as
+  root for anyone who could write the gem, and stale after every
+  release. It now grants only the staged, version-independent payload:
+  `hosts sync` (the recurring agent need) and `service uninstall`
+  (which only deletes yamine's own files). Staging new root code stays
+  a human interactive sudo; a non-interactive `service install` fails
+  fast saying so. If your `/etc/sudoers.d/yamine` still pins a
+  version-stamped gem path, re-run `yamine sudoers` and replace it.
+- **`hosts sync` is strictly validated before anything is written.**
+  Route names are user-writable and the sync runs as root, so every
+  name must now be well-formed (no newline/breakout), written only
+  inside yamine's managed block, and under `.localhost` or a domain in
+  the root-owned staged allowlist. Anything else fails closed naming
+  the policy. Custom `proxy.host` domains need one human step: append
+  the parent domain to the staged `allowed-tlds` file.
+- **`yamine doctor` gains a `service` check.** It names a legacy unit
+  (payload in a user home or version-stamped gem path) with the exact
+  migration (`sudo yamine service install`), warns on staged-vs-CLI
+  version skew, fails on any root-executed path that is not root-owned
+  or is group/other-writable, and always reports the service
+  interpreter's path and writability. The legacy daemon keeps working
+  until the next elevated install.
+
+### Changed
+
+- `service install` (human, interactive, elevated) migrates a legacy
+  install in place and prints the interpreter caveat; `service
+  uninstall` removes the staged payload as well as the unit, scoped to
+  yamine's own files.
+- Non-interactive (`sudo -n`) failure messaging points at the new
+  provisioning story: humans install the 443 service once per machine,
+  agents keep hosts entries fresh through the grant.
+
+### Fixed
+
+- **The printed grant now matches what the CLI invokes, byte for
+  byte.** Elevated re-execs went through `env YAMINE_STATE_DIR=…`,
+  which made the command `/usr/bin/env` — a path no rule names — so
+  every passwordless attempt fell through to the password-required
+  admin rule; and the staged macOS path's space was unescaped in the
+  sudoers output, so that rule could never match either. No
+  environment crosses sudo anymore (no `env` prefix, no SETENV): the
+  root half derives the invoking user's state dir from `SUDO_USER`,
+  and spaces are backslash-escaped when the rules are printed. Pinned
+  by a parity test that parses the printed specs and asserts equality
+  with the captured elevated argv.
+- **The `--no-service` sudo daemon no longer executes the gem
+  directory as root.** A privileged `proxy start` spawns the staged
+  root-owned payload, staging it first under the same
+  human-authorized sudo (`service stage --internal`, never granted)
+  when missing. The unprivileged spawn path is unchanged.
+
+### Open caveat (not closed, stated plainly)
+- **The interpreter is still user-writable.** No root-owned Ruby ≥ 3.2
+  exists on a stock machine, so the daemon necessarily runs the
+  invoking (user-writable) Ruby. The payload is root-owned; the
+  interpreter is not. Doctor reports it truthfully and the README says
+  so. Fixed only by a root-owned Ruby new enough for the gem; yamine
+  will not vendor or stage an interpreter.
+
 ## [0.20.0] — 2026-09-28
 
 ### Added

data/README.md

@@ -54,21 +54,35 @@ to get back to 443.
 
 Binding 443 is privileged, so yamine installs a **root-owned launchd
 service** (macOS) or systemd unit (Linux) that binds 443 at boot — the
-same model as puma-dev and portless. Installing it needs sudo **once per
-machine**; after that, every `yamine` run in any project gets a clean
-`https://<app>.localhost` with no elevation and no prompt.
+same model as puma-dev and portless. Installing it needs an interactive
+sudo **once per machine** (one Touch ID tap); after that, every `yamine`
+run in any project gets a clean `https://<app>.localhost` with no
+elevation and no prompt.
 
-**Human (interactive):** run setup once — it trusts the CA, installs the
-service, syncs hosts, and verifies:
+**Human (interactive):** run setup once — it stages a root-owned copy of
+yamine, installs the service, trusts the CA, syncs hosts, and verifies:
 
 ```bash
 yamine setup
+# or, for just the service: sudo yamine service install
 ```
 
-**Agent / CI (no TTY):** the same commands fail fast with guidance,
-because sudo needs a terminal. To pre-provision a machine or image so
-agents can install the service without a prompt, install the scoped
-passwordless-sudo rules once (as an admin):
+The unit runs a **staged payload**, not your gem directory: the install
+copies yamine's `bin`+`lib` into a root-owned directory at a stable,
+version-independent path (`/Library/Application Support/yamine` on
+macOS, `/usr/local/share/yamine` on Linux), verifies root ownership and
+modes fail-closed (a bad tree registers nothing), and pins that path in
+the unit. Ordinary user-space writes — a gem upgrade, a `bundle
+install`, an agent editing the gem — can no longer change what runs as
+root, and upgrades never stale the setup. `yamine doctor` names a legacy
+install (a unit still pointing at a user-writable gem path) with the
+exact migration, plus staged-vs-CLI version skew and any ownership
+problem.
+
+**Agents: the steady-state grant.** New project ⇒ new hostname ⇒ Safari
+needs the `/etc/hosts` entry; that recurring privileged need stays
+agent-invocable without a prompt. Install the scoped passwordless-sudo
+rules once (as an admin):
 
 ```bash
 yamine sudoers > /tmp/yamine.sudoers
@@ -76,11 +90,41 @@ sudo install -o root -g wheel -m 440 /tmp/yamine.sudoers /etc/sudoers.d/yamine
 sudo install -o root -g root -m 440 /tmp/yamine.sudoers /etc/sudoers.d/yamine   # Linux
 ```
 
-`yamine sudoers` prints rules scoped to yamine's own service
-re-exec — the gem's exact ruby + bin path with the `service install
---internal` / `service uninstall --internal` subcommands — never a bare
-interpreter. Re-run it after upgrading the gem if the install path
-changes. To undo: `sudo rm /etc/sudoers.d/yamine`.
+`yamine sudoers` prints rules for the **staged payload only** — `hosts
+sync` (hostnames strictly validated: well-formed, written only inside
+yamine's managed block, and only under `.localhost` or an allowlisted
+domain) and `service uninstall` (which only deletes yamine's own
+files). Installing or upgrading the staged payload moves user-writable
+source into root-owned paths, so it deliberately stays a human
+interactive sudo — no grant will ever cover it, and a non-interactive
+`service install` fails fast saying so. To undo the grant:
+`sudo rm /etc/sudoers.d/yamine`.
+
+If you installed an older yamine, your `/etc/sudoers.d/yamine` may still
+pin a version-stamped gem path (`.../gems/yamine-X.Y.Z/...`) including
+an install rule — re-run `yamine sudoers` and replace the file. The old
+rules go stale every release (which pushed people toward `NOPASSWD:
+ALL`); the new ones survive upgrades.
+
+**Custom domains** (e.g. `proxy.host: myapp.local.example.com` for OAuth
+parity) need their parent domain allowlisted once by a human — `hosts
+sync` refuses anything outside `.localhost` and the staged allowlist,
+because an unvalidated root hosts write could point a real vendor domain
+at loopback:
+
+```bash
+echo 'local.example.com' | sudo tee -a "/Library/Application Support/yamine/allowed-tlds"   # macOS
+echo 'local.example.com' | sudo tee -a /usr/local/share/yamine/allowed-tlds                 # Linux
+```
+
+**Open caveat: the interpreter.** The unit runs the invoking Ruby, and
+there is no root-owned Ruby ≥ 3.2 on a stock machine (`/usr/bin/ruby` is
+2.6), so the daemon necessarily runs a user-writable interpreter today.
+The payload is root-owned; the interpreter is not — `yamine doctor`
+reports its path and writability truthfully. Anything that can write
+that Ruby can change what runs as root. This hole stays open until the
+machine has a root-owned Ruby new enough for the gem; yamine will not
+vendor or stage an interpreter to pretend otherwise.
 
 ## The one-file model
 
@@ -464,10 +508,11 @@ bundle exec rake test
   self-signed, and there is no buffering or rate limiting.
 
 
-The `yamine-apps` fixture fleet (sibling checkout) exercises
+The `test/fixtures/apps/` fixture fleet exercises
 detection, inference, and boot across Rails variants, Roda, Sinatra,
-bare Rack, Jekyll, compound Procfiles, and a monorepo. CI runs the
-fixture sweep automatically.
+bare Rack, Jekyll, compound Procfiles, and a monorepo. It ships with
+the repo and runs as part of the unit suite across the Ruby matrix —
+no sibling checkout, no separate CI job.
 
 ## License
 

data/lib/yamine/cli/boot.rb

@@ -940,10 +940,11 @@ module Yamine
         privileged = port < 1024 && !ProxyControl.root?
         if privileged && !ctx.interactive?
           $stderr.puts "Error: proxy is not running and port #{port} needs root."
-          $stderr.puts "  Human: run this once — yamine setup"
-          $stderr.puts "  Agent/CI: pre-provision passwordless sudo once —"
-          $stderr.puts "    yamine sudoers > /tmp/yamine.sudoers"
-          $stderr.puts "    sudo install -o root -g wheel -m 440 /tmp/yamine.sudoers /etc/sudoers.d/yamine"
+          $stderr.puts "  Human: run this once in a terminal — yamine setup (or: sudo yamine service install)"
+          $stderr.puts "  Agent/CI: the 443 service is installed by a human once per machine — it cannot be provisioned passwordlessly."
+          $stderr.puts "    Steady-state hosts sync works via the grant instead:"
+          $stderr.puts "      yamine sudoers > /tmp/yamine.sudoers"
+          $stderr.puts "      sudo install -o root -g wheel -m 440 /tmp/yamine.sudoers /etc/sudoers.d/yamine"
           $stderr.puts "  Or start the proxy by hand: sudo yamine proxy start"
           exit 1
         end