Venya v0.1.0alpha14

Venya v0.1.0alpha14 completes the secret-shape stack (env, askpass, and remote-sudo shapes now execute, not just declare), makes the output-masking pipeline fail-closed, fixes first-admin bootstrap for clientPin-only security keys, and lands the full installer/CLI field-report series. Every fix was physically verified end-to-end on a freshly provisioned fleet, including the mid-run session-expiry race and the relay dial-contract cells. This release is the canonical publication of the v0.1.0alpha13 code content — that GitHub release was deleted within ~1h of publishing because its installer-script ASSETS were built with a build-network mirror origin (installs outside that network failed loudly at the tarball fetch; product code and tarballs were unaffected). Supersedes v0.1.0alpha12.

Security

• Stage-2 output filter fails closed: an unknown or vanished execution session now answers 404 instead of 200-with-unmasked-output, and the executor falls back to its own Stage-1 masking — output masking can degrade to one stage, never to zero. (Previously, a session row deleted mid-run by the TTL reaper could turn the definitive masker into a passthrough.)

Added

• venya setup — one command points the CLI at a core and installs its CA certificate (fetched from /.well-known/venya-ca.crt), replacing the manual cert-export + SSL_CERT_FILE dance for workstation onboarding.
• GET /health — bare alias of /api/v1/health for load-balancer and operator probes (unknown paths still require auth).
• venya admin get-command-policy now works (the CLI previously GETted a POST-only route — 405 since the command shipped). The GET reports the stored policy or the honest built-in defaults and never mutates.

Changed

• Secret shapes execute: --shape env:NAME injects the value into the sandbox environment via a 0600 host-side env file (values never ride process argv; the file is zeroed when the command returns); --shape askpass wires GIT_ASKPASS/SSH_ASKPASS to an in-sandbox helper; remote sudo with a password is a runnable shape via one narrow <-redirect allowance for session-bound secret paths (sshpass -f /run/secrets/venya/<id> …sudo -S…) — every other metacharacter form stays rejected whole-string. venya store/update-metadata gained --shape/--usage metadata with server-side validation (usage templates interpolating secret VALUES are rejected — values in command text would persist unmasked in the audit log); venya list shows the shape, and MCP tool descriptions teach agents the injected-file pattern.
• venya run / MCP run_command wait out long sandbox runs: the execute-call read timeout defaults to 340s, keeping the client the last fuse (server relay 300s < nginx 330s < client 340s). Previously a 30s client default aborted the first run on a fresh executor (~65s cold sandbox-template pull) while the server completed it correctly — and the natural retry executed the command a second time. VENYA_EXECUTION_TIMEOUT overrides.
• venya init supersede: an abandoned PENDING first-admin enrollment (e.g. from a key-less attempt) is superseded by the next plain venya init <user> — --installation-reset is no longer required for that state. A COMPLETED admin still answers 409 (unchanged).
• Installers refuse co-location: installing the executor on a host that already runs a core (or vice versa) exits 1 with the detection evidence before any prompt; VENYA_SKIP_PROMPT does not bypass the guard. Same-component re-runs remain supported.
• Uninstallers are fully self-contained — no network fetch; uninstall is 100% local.
• Rate-limit 429s carry Retry-After (delta-seconds) on all four middleware paths.
• Release hygiene: published tarballs no longer carry development-lab coordinates (mirror addresses, workstation paths, harness credential defaults) — the bundled E2E harness and docs read VENYA_TEST_* environment variables and use placeholder examples.

Fixed

• clientPin-only security keys can enroll (keys with no built-in user verification, e.g. TrustKey T120 class): venya init now dispatches on the key's advertised options and drives the raw CTAP2 clientPin path — the same spec-canonical path venya login has always used — instead of a high-level ceremony that failed with a cryptic 0x31 PIN_INVALID and burned one key PIN-retry per attempt. Wrong-PIN handling retries with a friendly message instead of leaking a raw error tuple.
• Executor CLI/installer series from field reports: venya exec register honors the configured executor-id and accepts VENYA_EXECUTOR_ENROLLMENT_TOKEN (off argv), consistent --server-url/VENYA_SERVER_URL naming, a non-fatal dial-address pre-check with remedy guidance, actionable health-probe 401 diagnostics, enrollment-token expiry guidance, unbound installer env vars no longer crash mid-install, venya-executor --version prints the bare version.

Install

curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-core.sh | sudo VENYA_SKIP_PROMPT=yes bash -s

Same pattern for install-venya-executor.sh (requires VENYA_SERVER_URL) and the non-root install-venya-cli.sh; Windows CLI via install-venya-cli.ps1 (Administrator). The installers verify the tarball SHA-256 against the published sidecars and abort on any mismatch (fail-closed); pinning VENYA_TARBALL_SHA256 makes verification strict-path.

SHA-256:

• venya-core-install.tar.gz / venya-executor-install.tar.gz: 0df2e291b57a2626c3fdb378a12900aabfa0029569aeba298749cc1f9ba31ee2
• venya-cli-install.tar.gz: f83d9ec5cffdab4e66a42884f4484d1b99d70504a6f88fc1e751cb524dc29eb6

Docs at this tag: README · installation guide · full CHANGELOG. Licensing & third-party: BUSL-1.1 LICENSE (MPL-2.0 at the Change Date) · THIRD-PARTY-NOTICES (incl. Docker Sandboxes/sbx) · SECURITY.

Alpha software: interfaces and operational stories are still stabilizing — not yet for production secret material.

Venya v0.1.0alpha12

SUPERSEDED by v0.1.0alpha13 (2026-09-23) — the assets below are immutable and remain downloadable; new installations should use the latest release.

Venya v0.1.0alpha12 completes the pre-beta security remediation program: a full-codebase security sweep (all eight finding clusters fixed) with every fix physically verified end-to-end on a freshly provisioned fleet, plus a full-lifecycle acceptance run — provision, install, FIDO2 identity (including wrong-key and replay negatives), zero-knowledge secret storage, and MCP-driven command execution with secret injection and output redaction proven.

Security

• Unauthenticated WebAuthn registration closed (account-takeover class): registration endpoints require authentication, ceremonies verify clientDataJSON type/challenge/origin, RP ID hash and user presence, and credentials cannot be minted from another user's challenge.
• Executor endpoints now carry real mTLS identity: heartbeat and the session output-filter / secret-revoke paths require a verified executor client certificate (CN allowlist + revocation) — previously anonymous. Audit attribution is live.
• Secret unmasking hardened: the ?caller=executor plaintext bypass is gone; elevation tokens are single-use, bound to the requesting user, and travel in the X-Elevation-Token header. Breaking: GET /api/v1/secrets/{key}?elevation_token=… no longer elevates (403) — URL transport was removed because query strings persist in access logs.
• Per-IP rate limiting actually enforces now: fixed-window counters persist across requests; the auth tier answers 429 (Auth endpoint rate limited: too many requests per minute) above 20 requests/min on /api/v1/auth/* and /api/v1/enrollment/*; break-glass /recovery enforces 5/hr plus exponential failure backoff. Buckets key on the rightmost (proxy-appended) X-Forwarded-For entry — a spoofed leftmost entry no longer resets them.
• Disabled users lose access immediately: session validation re-checks user status per request; login issuance is gated at the single session-creation choke point.
• Secret metadata PATCH enforces role scope (IDOR fixed); scoped-out keys remain indistinguishable from nonexistent ones.
• Admin mTLS fails closed: empty CN allowlist denies; admin-certificate serial revocation is enforced in-process (403 Admin certificate revoked).
• Key material at rest: the root CA private key is now encrypted at rest (passphrase via restricted systemd EnvironmentFile), matching the admin CA. CA break-glass backups converge on one canonical AES-256-GCM VENYACA1 envelope; older exports remain restorable via dual-format readers — no key material stranded.
• Executor registration requires an enrollment token by default. Breaking for deployments relying on open registration: tokenless POST /executors/register fails with an error naming the knob and the re-enrollment path (executor_enrollment.require_token=false deliberately restores the old behavior).
• Log/leak hygiene: executor audit spool (full command lines) created 0600 with legacy-spool repair at startup; malformed relay responses no longer log body fragments; dead public endpoints removed; public CRL endpoints are read-only.

Changed

• Auth-tier enforcement (above) is the release's biggest operational signature: automation hammering auth endpoints will see 429. E2E scaffolds should set VENYA_RATE_LIMIT__AUTH_REQUESTS_PER_MINUTE explicitly.
• Installer: no development passphrase default — VENYA_DB_PASSPHRASE is always operator-provided (prompted interactively, required unattended) and safely reused across idempotent re-installs.
• nginx relay timeouts raised to 330s so long-running sandbox commands return the server's clean result instead of a 60s gateway timeout (a cold sandbox create can take ~65s).

Fixed

• Session refresh works as designed: /api/v1/auth/refresh is gated by the 4-hour hard cap only, so idle-expired sessions revive without human intervention; refresh rotates the token (the old one dies immediately).
• Expired execution sessions are now reaped (previously unbounded growth); post-relay bookkeeping on a vanished session no longer 500s.
• WebAuthn sign-counter persistence failures now refuse login (fail-closed) instead of silently losing clone-detection state.
• venya CLI honors VENYA_SERVER_URL for every command.

Install

curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-core.sh | sudo VENYA_SKIP_PROMPT=yes bash -s

Same pattern for install-venya-executor.sh and (non-root) install-venya-cli.sh. The installers verify tarball SHA-256 against the published sidecars (fail-closed).

SHA-256:

• venya-core-install.tar.gz / venya-executor-install.tar.gz: 6c8fac20cb90787428e636cb587371b8b422befbfcce289cb45229cd36fdb0c7
• venya-cli-install.tar.gz: 5eaed78f77e089f2c396f84c3ed133539502470e01724437bc32f487bda08408

Full detail: CHANGELOG.md → [0.1.0alpha12].

Venya v0.1.0-alpha.11

Venya 0.1.0-alpha.11 — supersedes v0.1.0-alpha.10. Tag v0.1.0-alpha.11 @ commit d2c6ff9.

Hardening + honesty release. Eight operator-facing fixes found by a full evidence-based documentation review (every claim traced to source), a generated CLI reference that cannot drift from the shipped parser, and threshold enforcement for Shamir CA-key restores.

What changed since v0.1.0-alpha.10

• NEW — docs/cli-reference.md: the complete CLI reference. Every command and argument (66 command paths, ~130 arguments), generated from the live argument parser and enforced by tests: any parser change without regeneration fails the suite, every documented example invocation is parse-validated, and every leaf command must carry at least one example. It cannot disagree with the shipped binary.
• SECURITY — Shamir CA-key backup now enforces threshold + integrity (V2 shares). Previously, restoring with fewer than K shares SILENTLY reconstructed a corrupt CA key — a break-glass path that could destroy the key at the worst moment. V2 share files carry K and a checksum; below-threshold, corrupt, truncated, or cross-split sets now fail loudly. Pre-V2 share files still restore (the CLI warns and tells you to verify the result against ca.crt).
• SECURITY — executor cert auto-rotation now persists on deployed systems. The systemd unit's ReadOnlyPaths=/etc/venya made the daemon's 30-day rotation die on the disk write after the server had already issued the replacement — ending in an unreachable executor at day 30. The unit now grants write access to /etc/venya/executor (identity files only), rotate() refuses before touching server state when the directory is unwritable, and the new serial is adopted only after the writes succeed. Executors installed before this fix need the refreshed unit (re-run the executor installer, or a ReadWritePaths=/etc/venya/executor drop-in — see the cert-rotation runbook §1).
• SECURITY — hidden passphrase prompts. venya admin export-ca-key / restore-ca-key passphrase prompts were echoed to the terminal; they now use getpass like every other secret prompt.
• FIXED — installer re-runs are idempotent. An unattended re-run over an existing core regenerated the admin CA passphrase while (correctly) preserving the encrypted key — then aborted decrypting it. The stored passphrase from /etc/venya/venya-core.env is now reused automatically; explicit VENYA_ADMIN_CA_PASSPHRASE still wins (and a wrong value still fails loudly). Found via a field report (macOS workstation + core in a lima VM).
• FIXED — venya admin key-version revoke <id> was dead on arrival. The parser accepted no argument while the handler required one: every invocation failed. It works now (and the regression test parses the shipped parser, so the two sides can't split again).
• FIXED — admin CA commands' --ca-dir default pointed at /etc/venya/ca, a path that exists in no deployment and contradicted the flag's own help text. Now /var/lib/venya/ca (the server's actual CA home).
• FIXED — CORS configuration was a silent no-op. The installer wrote VENYA_CORS_ORIGINS; the server reads VENYA_CORS__ORIGINS (nested delimiter) and ignores unknown names. Deployments ran on the default while operators believed they had set CORS. The installer now writes the name that works.
• FIXED — operator-facing messages name env vars that work. The startup RuntimeErrors named installer-level input vars instead of the server's real VENYA_DB__PASSPHRASE / VENYA_RECOVERY_CODE_PEPPER; the CORS warning had a double-underscore typo; the executor-enroll hint named a var no installer reads.
• REMOVED — dead executor config knobs (cert_rotation.rotation_days, revocation_poll_seconds): defined but never read — tuning them did nothing. Real values: 30-day cert validity (server-side) and ~30 s revocation poll (daemon loop). Legacy executor.toml files carrying the removed keys still load.
• DOCS — repo-wide accuracy sweep. The cert-rotation runbook was rewritten (the previous version described a pre-nginx layout and was largely unrunnable); the bandit-suppressions register is regenerated from the live tree with a drift interlock; corrections across installation, architecture, FAQ, agent brief, alpha demo, deployment-config, and the lifecycle test plan. New: macOS-workstation + lima-VM topology note (hostname mapping for TLS verification).

Suites at the tag (fresh GitHub clone): 2,416 passed (cli 868 / core 116+7 skipped / server 751 / executor 643 / mcp 38).

Upgrading from alpha.10? Core: re-run the core installer over the existing install — re-runs are idempotent now (admin CA + passphrase preserved; server/relay leaf certs re-signed; database and secrets untouched). Executors: re-run the executor installer (or add the drop-in) so the rotation fix lands — without it, certs installed under alpha.10 or earlier expire unrenewed at day 30. Workstations: reinstall via the one-liner / .ps1. If you hold pre-V2 Shamir share files, they still restore; the CLI will warn you to verify.

Verify it yourself

Release tarballs are byte-reproducible from any clone of the tag:

git clone git@github.com:tabith-llc/venya.git && cd /tmp && TAG=v0.1.0-alpha.11
git -C venya archive --format=tar --prefix=./ "$TAG" | gzip -n > venya-core-install.tar.gz
git -C venya archive --format=tar --prefix=./ "$TAG" packages/cli packages/mcp | gzip -n > venya-cli-install.tar.gz
BASE=https://github.com/tabith-llc/venya/releases/download/$TAG
curl -fsSLO $BASE/venya-core-install.tar.gz.sha256
curl -fsSLO $BASE/venya-cli-install.tar.gz.sha256
sha256sum -c venya-core-install.tar.gz.sha256 venya-cli-install.tar.gz.sha256

(--prefix=./ is load-bearing — installers extract with tar --strip-components=1. Executor tarball is byte-identical to core by design. Byte-stability needs gzip -n and the same git major version.)

Integrity

Asset	sha256
venya-core-install.tar.gz = venya-executor-install.tar.gz	8b5d6dfd5af3429fe97c5d07109a69d01ca25e1849e54fb42820883ca9dc2e6e
venya-cli-install.tar.gz	398b57583645487e17856645510a6f77ceb0120f7d48c6d91d1ec2d5ad650f50

Pinned VENYA_TARBALL_SHA256 = strict verification; the default installs fetch the .sha256 sidecar from the same origin as a corruption guardrail.

Install one-liners (Ubuntu 24.04; CLI also macOS + Windows)

# Core server (root)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-core.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_DB_PASSWORD=<strong-db-password> bash -s

# Executor (root; needs an enrollment token minted by an admin)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-executor.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_SERVER_URL=https://<core-host> VENYA_EXECUTOR_ENROLLMENT_TOKEN=<token> bash -s

# Workstation CLI (non-root, no sudo; Linux + macOS)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-cli.sh | bash -s

Windows workstation CLI (Administrator PowerShell, once per machine; standard users then use venya with no admin rights):

curl.exe -fsSL -o install-venya-cli.ps1 https://github.com/tabith-llc/venya/releases/latest/download/install-venya-cli.ps1
powershell -ExecutionPolicy Bypass -File .\install-venya-cli.ps1

(Uninstall: uninstall-venya-cli.ps1 from the same URL pattern; config is kept unless VENYA_PURGE_CONFIG=yes.)

Docs at this tag

CLI Reference · Installation · Cert-rotation runbook · Architecture · FAQ · Agent brief

License: BUSL-1.1 (see LICENSE); sandboxing depends on the proprietary Docker sbx runtime (see THIRD-PARTY-NOTICES). Alpha software — expect rough edges; report via SECURITY.md or info@tabith.com.

Venya v0.1.0-alpha.10

SUPERSEDED by v0.1.0-alpha.11 (2026-09-19) — 8 operator-facing fixes incl. executor cert-rotation persistence (executors installed before alpha.11 need the refreshed systemd unit or their certs expire unrenewed at day 30), Shamir restore threshold enforcement, and idempotent installer re-runs. latest/download now serves alpha.11; the assets below are unchanged and remain installable at their tag-pinned URLs.

Venya 0.1.0-alpha.10 — supersedes v0.1.0-alpha.9. Tag v0.1.0-alpha.10 @ commit f727844.

Windows CLI release. The workstation CLI now runs natively on Windows 10 1903+/Windows 11 — installed machine-wide by an administrator, usable by standard (non-admin) users, with FIDO2 ceremonies through the Windows platform WebAuthn API (OS-drawn PIN/touch dialogs). Also carries five cross-platform ceremony fixes that the Windows physical-acceptance run exposed, and the relay-mTLS startup fail-fast.

What changed since v0.1.0-alpha.9

• NEW — Windows workstation CLI. install-venya-cli.ps1 / uninstall-venya-cli.ps1 (this release's two new assets). The installer is admin-run, machine-wide (C:\Program Files\Venya, machine PATH): Windows refuses standard-user traversal of standard-user-created junctions, and uv needs one for its Python alias — an admin-created junction is traversable by everyone, so IT installs once and standard users just use it. Per-user config/token live in %APPDATA%\venya\. FIDO2 ceremonies (init, login, enroll, credential add) route through the platform WebAuthn API — raw CTAP/HID has been admin-only since Windows 10 1903, so this is what makes standard-user ceremonies work. Constraints to know: ceremonies need an interactive desktop session (not SSH/WinRM — the platform API requires a foreground window); authenticator reset and PIN set/change stay with the vendor tool / your IT. Accepted physically on Windows 11 25H2 as a genuine standard user (init + login + credential-add + elevation, server-side verified; no-key negative included).
• NEW — CLI error log. Every CLI stderr write is teed to <config-dir>/venya.log (%APPDATA%\venya\venya.log on Windows, ~/.config/venya/venya.log on Linux, ~/Library/Application Support/venya/venya.log on macOS): session header per invocation, 1 MiB single-generation rotation, and a log-path hint on failure. No secrets land there (PIN entry is TTY-direct, tokens are never printed to stderr).
• SECURITY — relay mTLS material is startup-validated. The core server refuses to boot when VENYA_MTLS_CERT/VENYA_MTLS_KEY are unset or missing (named error before DB/CA init); the executor daemon fails the same way at startup (exit 1, named single-line error) while keeping its runtime certificate-rotation tolerance. Previously a misconfigured relay endpoint discovered the problem later, in ambiguous runtime failures.
• FIXED — venya credential add never worked on any platform. Its duplicated inline ceremony read a credential.auth_response attribute the pinned fido2 library never returns (AttributeError after every successful ceremony) and hardcoded an https://localhost collector origin (RP-ID verification failure against every real deployment). The duplication is deleted; the command now shares the proven venya enroll machinery.
• FIXED — elevation sent no bearer token. Every elevated operation (credential add/remove, unmask) 401'd "Missing authentication token" on every platform since inception; the elevation calls now go through the token-carrying API client.
• FIXED — venya credential list crashed in table mode on the server's integer credential ids ("object of type 'int' has no len()").
• FIXED — WebAuthn options normalizer missed the browser-adapter wire shape (RP id inside an rp object instead of an rpId scalar): elevation ceremonies ran with rp_id=None (platform NTE_INVALID_PARAMETER on Windows; RP-hash rejection elsewhere).
• FIXED — Windows config saves. os.replace ran inside the open temporary-file block; Windows cannot rename an open handle, so every config write died PermissionError [WinError 32] (POSIX unaffected).
• NEW — readable Windows ceremony errors (pinned messages for observed HRESULTs, e.g. duplicate-key registration; OS text + HRESULT preserved otherwise — no more raw ClientError tuples) and Windows ceremony guidance that matches the OS dialogs (which key at which dialog, insert-vs-touch, the dual-key credential add sequence).

Suites at the tag (fresh clone): 1,872 passed (cli 336 / core 112+7 skipped / server 747 / executor 639 / mcp 38).

Upgrading from alpha.9? Core/executor: reinstall over the existing install as usual. Windows workstations: have IT run install-venya-cli.ps1 (admin). Linux/macOS CLI: reinstall via the one-liner below. Behavior notes: (1) elevation now actually works — anything that 401'd "Missing authentication token" before should succeed; (2) CLI failures now also write <config-dir>/venya.log. Stored secrets, sessions, and certificates are untouched.

Verify it yourself

Release tarballs are byte-reproducible from any clone of the tag:

git clone git@github.com:tabith-llc/venya.git && cd /tmp && TAG=v0.1.0-alpha.10
git -C venya archive --format=tar --prefix=./ "$TAG" | gzip -n > venya-core-install.tar.gz
git -C venya archive --format=tar --prefix=./ "$TAG" packages/cli packages/mcp | gzip -n > venya-cli-install.tar.gz
BASE=https://github.com/tabith-llc/venya/releases/download/$TAG
curl -fsSLO $BASE/venya-core-install.tar.gz.sha256
curl -fsSLO $BASE/venya-cli-install.tar.gz.sha256
sha256sum -c venya-core-install.tar.gz.sha256 venya-cli-install.tar.gz.sha256

(--prefix=./ is load-bearing — installers extract with tar --strip-components=1. Executor tarball is byte-identical to core by design. Byte-stability needs gzip -n and the same git major version.)

Integrity

Asset	sha256
venya-core-install.tar.gz = venya-executor-install.tar.gz	9a270fdfe4b417790879f283c1b28d3aba58e324225e8be59057bed6bb2ecf71
venya-cli-install.tar.gz	7a6dc2de3212e4b6ff700cfc977da763b812c433bdc3554a0e9b261529062842

Pinned VENYA_TARBALL_SHA256 = strict verification; the default installs fetch the .sha256 sidecar from the same origin as a corruption guardrail.

Install one-liners (Ubuntu 24.04; CLI also macOS + Windows)

# Core server (root)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-core.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_DB_PASSWORD=<strong-db-password> bash -s

# Executor (root; needs an enrollment token minted by an admin)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-executor.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_SERVER_URL=https://<core-host> VENYA_EXECUTOR_ENROLLMENT_TOKEN=<token> bash -s

# Workstation CLI (non-root, no sudo; Linux + macOS)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-cli.sh | bash -s

Windows workstation CLI (Administrator PowerShell, once per machine; standard users then use venya with no admin rights):

curl.exe -fsSL -o install-venya-cli.ps1 https://github.com/tabith-llc/venya/releases/latest/download/install-venya-cli.ps1
powershell -ExecutionPolicy Bypass -File .\install-venya-cli.ps1

(Uninstall: uninstall-venya-cli.ps1 from the same URL pattern; config is kept unless VENYA_PURGE_CONFIG=yes.)

Venya v0.1.0-alpha.9

SUPERSEDED by v0.1.0-alpha.10 (2026-09-19) — Windows CLI support + elevation-path cross-platform fixes. latest/download now serves alpha.10 bytes. Assets below are unchanged and remain installable at their pinned tag URLs.

Venya 0.1.0-alpha.9 — supersedes v0.1.0-alpha.8. Tag v0.1.0-alpha.9 @ commit 77a5a54.

Security-hardening release. Command strings are now structurally validated on the production sandbox path; the executor's relay perimeter is bounded; a misconfigured executor refuses to boot "healthy but deaf"; and truncation metadata finally tells the truth.

What changed since v0.1.0-alpha.8

• SECURITY — shell-metachar structural gate on the production execution path. An unconditional whole-string check (| ; & $ ` ( ) { } < > ! * ?, newlines) now runs in the executor before policy validation and before any sandbox dispatch. Previously the structural check existed only on the unused memfd/direct path while the production sandbox path handed the raw command string to sh -c. Quoted metachars (e.g. echo "a; b") are rejected too — a documented accepted tradeoff: quote-scoped parsing cannot soundly distinguish local from remote interpretation, since the sandbox shell sees the whole string. Shell features must use the script-file path (write a script, execute it). Structural and policy rejections both emit command_rejected audit events with distinct reasons; the full metachar alphabet is covered by a 23-case truth table through the production entry point.
• SECURITY — executor relay listener bounded against misbehaving authenticated peers. 16 MiB request-body cap (checked before any read/allocation → 413), negative Content-Length rejected with 400 (previously a read-until-EOF hang), and a 30-second per-recv inactivity timeout so a silent peer cannot pin the single relay handler. Fixed-length protocol documented (chunked bodies are not decoded → 400). Sequential one-command-at-a-time execution is unchanged and remains a deliberate isolation tradeoff (now documented in code).
• SECURITY — executor daemon refuses deaf boot. An empty relay_client_ids allowlist now exits 1 at startup with a log line naming the knob — checked before registration, so the one-shot enrollment token is never consumed on a doomed boot. Previously the daemon logged one ERROR, never bound the relay, and kept running healthy-looking to every normal ops probe. Bind/SSL-failure gets the same refusal.
• Output-truncation metadata tells the truth. The sandbox path sliced stdout/stderr to the 256 KB cap before computing output_truncated (structurally always False) and original_*_size recorded post-slice lengths — oversized output silently lied about completeness. True pre-slice sizes are now threaded through the shared result builder; a truncated payload is exactly the cap (the marker is carved out of it); and a latent crash in the direct path's truncation marker (KeyError on any real >256 KB output) is fixed.
• Core relay maps executor-mid-response death to 503. httpx2.RemoteProtocolError (executor died mid-response) now returns 503 "Executor unreachable (connection lost mid-response)" instead of an unhandled 500.
• venya run -- <command> works as intended. argparse REMAINDER captured the literal -- separator into the command string, which broke validator ssh-shape recognition (false "Dangerous pattern" rejections of legitimate sshpass … ssh … flows) and would exit 127 in the sandbox. Exactly one leading separator is consumed; run --help documents it.
• Tests: the CLI's FIDO2 login entry point (cmd_login) gained a full truth table (success + server-identity contract + auth-rejection / unexpected-error / malformed-response negatives) — it previously had zero coverage.

Suites at the tag (fresh clone): 1,837 passed (cli 310 / core 112+7 skipped / server 741 / executor 636 / mcp 38).

Upgrading from alpha.8? Reinstall over the existing core/executor as usual. Behavior changes to know: (1) commands containing shell metacharacters — including quoted ones — are now rejected on the sandbox path; move such commands into script files; (2) an executor with an empty relay_client_ids now fails to start (exit 1, named error) instead of running deaf; (3) relay requests over 16 MiB answer 413. Stored secrets, sessions, and certificates are untouched.

Verify it yourself

Release tarballs are byte-reproducible from any clone of the tag:

git clone git@github.com:tabith-llc/venya.git && cd /tmp && TAG=v0.1.0-alpha.9
git -C venya archive --format=tar --prefix=./ "$TAG" | gzip -n > venya-core-install.tar.gz
git -C venya archive --format=tar --prefix=./ "$TAG" packages/cli packages/mcp | gzip -n > venya-cli-install.tar.gz
BASE=https://github.com/tabith-llc/venya/releases/download/$TAG
curl -fsSLO $BASE/venya-core-install.tar.gz.sha256
curl -fsSLO $BASE/venya-cli-install.tar.gz.sha256
sha256sum -c venya-core-install.tar.gz.sha256 venya-cli-install.tar.gz.sha256

(--prefix=./ is load-bearing — installers extract with tar --strip-components=1. Executor tarball is byte-identical to core by design. Byte-stability needs gzip -n and the same git major version.)

Install one-liners (Ubuntu 24.04; CLI also macOS)

# Core server (root)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-core.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_DB_PASSWORD=<strong-db-password> bash -s

# Executor (root; needs an enrollment token minted by an admin)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-executor.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_SERVER_URL=https://<core-host> VENYA_EXECUTOR_ENROLLMENT_TOKEN=<token> bash -s

# Workstation CLI (non-root, no sudo; Linux + macOS)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-cli.sh | bash -s

Installers hard-fail without VENYA_TARBALL_SHA256 when pointed at non-default tarballs; the defaults above verify against the published sidecars automatically.

Venya v0.1.0-alpha.8

SUPERSEDED by v0.1.0-alpha.9 (security: whole-string shell-metachar gate on the production sandbox path; relay body cap + inactivity timeout; deaf-boot refusal; truncation metadata truth). Assets below are immutable and remain downloadable.

Venya 0.1.0-alpha.8 — supersedes v0.1.0-alpha.7. Tag v0.1.0-alpha.8 @ commit 4290897.

Security + honesty release. The break-glass recovery code is now truly single-use; key rotation stopped being administratively broken; venya store keeps secrets out of argv and replaces instead of duplicating.

What changed since v0.1.0-alpha.7

• SECURITY — break-glass recovery codes are now truly single-use. POST /api/v1/recovery always claimed (docstring) to burn the one-shot code but never did: the same recovery code could mint new admins repeatedly, forever. The stored hash is now nulled in the same transaction that mints the recovered admin; reuse answers the same 401 as an invalid code. Failed recoveries (existing user id, missing admin role) deliberately do NOT consume the code. Covered by a real-database burn truth table plus an in-process end-to-end break-glass test (real init → recovery → replay rejected → recovered admin completes a real FIDO2 assertion).
• Key rotation made honest and functional. Previously one admin call to POST /admin/key-versions/rotate left the installation with NO active key version (the route deactivated the old one and activated nothing — no worker ever completed the "pending" job), breaking secret storage until manual repair. Rotation is now a synchronous label-boundary operation under single-KEK alpha semantics: the new version is active when the request returns (HTTP 200 with status: "completed" and a note field, replacing 202/"pending"), the job row is terminal with truthful counters, and rollback (both routes) performs a real flip-back with explicit 409 guards. Migration 028 adds a partial unique index enforcing at most one ACTIVE key version at the database level — concurrent rotations cannot both commit. No secrets are re-wrapped (there is no per-version key material; decryption never consults key versions) — existing secrets keep their label and remain decryptable; the request body's fictional new_key field is removed.
• venya store reads the secret value from stdin (as its help always claimed): pass - as the value (or omit it when piped), or omit it at a TTY for a hidden prompt. Values no longer need to ride argv (ps/shell-history exposure). Empty input fails with an actionable error; nothing is sent.
• Secret store is now a visibility-scoped upsert. Re-storing a key you can see (one of your roles in its scope, or you created it) REPLACES that row in place — stable id, immutable creator, value/roles/metadata overwritten — and the response says "replaced": true. A key that exists but is scoped out for you still inserts a second row with an identical response shape (no existence leak, no cross-role clobber). Previously every re-store silently created a duplicate row.
• Executor sandbox honors env_override and cwd. Both were accepted, documented, and silently dropped on the production sandbox path. They now thread through to sbx exec as -e KEY=VALUE / -w DIR argv tokens (values are data, never shell-parsed). No wire surface sends either yet — the internal contract simply stopped lying.
• Docs: full-lifecycle test plan corrected (suite-gate rule, --ref build flow, TTL-knob verification step, criterion #4 pass conditions per command shape).

Suites at the tag (fresh clone): 1,781 passed (cli 299 / core 112+7 skipped / server 740 / executor 592 / mcp 38).

Upgrading from alpha.7? Reinstall over the existing core as usual — the installer runs migrations (028 adds the single-active index with a defensive pre-clean). Behavior changes to know: re-storing a visible secret key now REPLACES it instead of adding a duplicate row; rotate answers 200/"completed" instead of 202/"pending"; recovery codes are consumed on successful use. Stored secrets are untouched by all three.

Verify it yourself

Release tarballs are byte-reproducible from any clone of the tag:

git clone git@github.com:tabith-llc/venya.git && cd /tmp && TAG=v0.1.0-alpha.8
git -C venya archive --format=tar --prefix=./ "$TAG" | gzip -n > venya-core-install.tar.gz
git -C venya archive --format=tar --prefix=./ "$TAG" packages/cli packages/mcp | gzip -n > venya-cli-install.tar.gz
BASE=https://github.com/tabith-llc/venya/releases/download/$TAG
curl -fsSLO $BASE/venya-core-install.tar.gz.sha256
curl -fsSLO $BASE/venya-cli-install.tar.gz.sha256
sha256sum -c venya-core-install.tar.gz.sha256 venya-cli-install.tar.gz.sha256

(--prefix=./ is load-bearing — installers extract with tar --strip-components=1. Executor tarball is byte-identical to core by design. Byte-stability needs gzip -n and the same git major version.)

Install one-liners (Ubuntu 24.04; CLI also macOS)

# Core server (root)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-core.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_DB_PASSWORD=<strong-db-password> bash -s

# Executor (root; enrollment token from the core admin; Docker credentials via stdin;
# host needs /dev/kvm — nested virtualization on VM deployments)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-executor.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_SERVER_URL=https://<core-host> VENYA_EXECUTOR_ID=<executor-id> \
  VENYA_EXECUTOR_ENROLLMENT_TOKEN=<token> bash -s

# Workstation CLI (non-root; Ubuntu 24.04 or macOS)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-cli.sh | \
  VENYA_SKIP_PROMPT=yes bash

Integrity: pin VENYA_TARBALL_SHA256 (hashes below) for strict verification; unset, the installer fetches the .sha256 sidecar from the same origin (corruption guardrail, not a security boundary) and fail-closes.

Artifacts (sha256)

File	sha256
venya-core-install.tar.gz	de91fb4b85f33799ebb7c7cdf6de2bb6010ec53d6b423e809e5d593ebf22d494
venya-executor-install.tar.gz	de91fb4b85f33799ebb7c7cdf6de2bb6010ec53d6b423e809e5d593ebf22d494
venya-cli-install.tar.gz	bc202b02d5e62c4baf04f29753a1b5d90c065de486493f29bf862867d8e0889c

Uninstallers for all three artifacts are attached. The executor sandbox requires Docker Sandboxes (sbx, proprietary; Docker account required) — see THIRD-PARTY-NOTICES.md. Licensed under BUSL-1.1 (LICENSE).

Documentation (in-repo at the tag)

docs/installation.md (full guide), docs/full-lifecycle-test.md (A-Z test plan), docs/architecture.md, docs/alpha-demo.md, docs/faq.md, docs/agents.md (LLM-agent/MCP integration), SECURITY.md (responsible disclosure). These guides ship inside the tarballs as well.

Status

ALPHA prerelease — functional but rough edges are expected. Known limitations are documented in docs/faq.md and the test plan (session tokens cannot be refreshed after expiry — re-login; key rotation is a label boundary under single-KEK alpha semantics — no per-version key material or re-wrap; break-glass recovery does not re-issue a fresh code for the recovered system). No support commitment yet.

Venya 0.1.0-alpha.7

SUPERSEDED by v0.1.0-alpha.8 (security: recovery-code burn; rotation honesty + single-active invariant; stdin store; visibility-scoped upsert). Assets below are immutable and remain downloadable.

Venya 0.1.0-alpha.7 — supersedes v0.1.0-alpha.6. Tag v0.1.0-alpha.7 @ commit fac1f5a.

Usability + robustness release. Fresh installs no longer need any workaround to store secrets; the enrollment-token TTL knob works; first-run errors are clean.

What changed since v0.1.0-alpha.6

• Flag-free secret storage on fresh installs. Migration 027 seeds one active key version (v1) at install — idempotent, and it never touches installs that already have key versions. venya store now resolves the active version automatically (no --key-version v1), and GET /api/v1/key-versions/active answers 200 instead of 503. The alpha-era "fresh installs need --key-version v1" limitation is gone.
• VENYA_FIDO2__ENROLLMENT_TOKEN_TTL (minutes) is now wired. It was defined but read by nothing — enrollment token lifetimes were hardcoded to 900 s and the reported expires_in_seconds was a literal. All enrollment routes construct through a single config-aware helper; reported lifetimes are derived from the same config. Default unchanged (15 min). Tokens already minted keep their issued expiry.
• venya-mcp first-run errors are clean. Missing session/config (or a malformed config file) prints the actionable message ("Run the venya CLI … and approve your security key") to stderr and exits 1 — no raw Python traceback.
• Executor reaper fixed (audit hygiene). Orphaned-secret cleanup scanned a pre-sandbox file layout the live writer no longer produces (it never matched anything), and revocations targeted a phantom session id. The reaper now scans the real per-run session directories and attributes credential_revoked audit events to the actual execution session.
• Installer robustness. Nine command-substitution sites under set -e could kill installs silently at the assignment, making the intended error handling unreachable (e.g. a failing Rust-extension import check died before printing its own diagnostic). Error paths now fire as designed; happy-path behavior unchanged.
• Docs synced: FAQ, alpha demo, and the full-lifecycle test plan reflect the flag-free store and the working TTL knob.

Suites at the tag (fresh clone): 1,741 passed (cli 291 / core 99+7 skipped / server 729 / executor 584 / mcp 38).

Upgrading from alpha.6? Reinstall over the existing core as usual — the installer runs migrations; 027 seeds v1 only if key_versions is empty, and stored secrets are untouched (labels are metadata; decryption never consults key versions). No data migration needed.

Verify it yourself

Release tarballs are byte-reproducible from any clone of the tag:

git clone git@github.com:tabith-llc/venya.git && cd /tmp && TAG=v0.1.0-alpha.7
git -C venya archive --format=tar --prefix=./ "$TAG" | gzip -n > venya-core-install.tar.gz
git -C venya archive --format=tar --prefix=./ "$TAG" packages/cli packages/mcp | gzip -n > venya-cli-install.tar.gz
BASE=https://github.com/tabith-llc/venya/releases/download/$TAG
curl -fsSLO $BASE/venya-core-install.tar.gz.sha256
curl -fsSLO $BASE/venya-cli-install.tar.gz.sha256
sha256sum -c venya-core-install.tar.gz.sha256 venya-cli-install.tar.gz.sha256

(--prefix=./ is load-bearing — installers extract with tar --strip-components=1. Executor tarball is byte-identical to core by design. Byte-stability needs gzip -n and the same git major version.)

Install one-liners (Ubuntu 24.04; CLI also macOS)

# Core server (root)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-core.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_DB_PASSWORD=<strong-db-password> bash -s

# Executor (root; enrollment token from the core admin; Docker credentials via stdin;
# host needs /dev/kvm — nested virtualization on VM deployments)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-executor.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_SERVER_URL=https://<core-host> VENYA_EXECUTOR_ID=<executor-id> \
  VENYA_EXECUTOR_ENROLLMENT_TOKEN=<token> bash -s

# Workstation CLI (non-root; Ubuntu 24.04 or macOS)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-cli.sh | \
  VENYA_SKIP_PROMPT=yes bash

Integrity: pin VENYA_TARBALL_SHA256 (hashes below) for strict verification; unset, the installer fetches the .sha256 sidecar from the same origin (corruption guardrail, not a security boundary) and fail-closes.

Artifacts (sha256)

File	sha256
venya-core-install.tar.gz	bb29756d465969fe89e79314ccea76796e1bbf1303464c2bdae8f941a50cec9f
venya-executor-install.tar.gz	bb29756d465969fe89e79314ccea76796e1bbf1303464c2bdae8f941a50cec9f
venya-cli-install.tar.gz	5f16b5cf3247c108be23d96453d7e8fb2d3c4c93c959667efc851bf63510d081

Uninstallers for all three artifacts are attached. The executor sandbox requires Docker Sandboxes (sbx, proprietary; Docker account required) — see THIRD-PARTY-NOTICES.md. Licensed under BUSL-1.1 (LICENSE).

Documentation (in-repo at the tag)

docs/installation.md (full guide), docs/full-lifecycle-test.md (A-Z test plan), docs/architecture.md, docs/alpha-demo.md, docs/faq.md, docs/agents.md (LLM-agent/MCP integration), SECURITY.md (responsible disclosure). These guides ship inside the tarballs as well.

Status

ALPHA prerelease — functional but rough edges are expected. Known limitations are documented in docs/faq.md and the test plan (session tokens cannot be refreshed after expiry — re-login; key rotation is bookkeeping-only until the rotation worker lands). No support commitment yet.

Venya 0.1.0-alpha.6

SUPERSEDED by v0.1.0-alpha.7 (usability+robustness: flag-free venya store on fresh installs via migration 027, VENYA_FIDO2__ENROLLMENT_TOKEN_TTL wired, clean venya-mcp first-run errors, reaper real-session audit attribution, installer error-path hardening) — assets below are immutable and remain as published; use the newer release for installs.

Venya 0.1.0-alpha.6 — supersedes v0.1.0-alpha.5 (DEFECTIVE — do not install). Tag v0.1.0-alpha.6 @ commit 333f407.

Distribution release: no product-code change. git diff v0.1.0-alpha.5 v0.1.0-alpha.6 -- packages/ is empty; product code is identical to v0.1.0-alpha.4. The delta is the artifact build fix below plus its documentation.

What changed since v0.1.0-alpha.5

• Fixed: alpha.5 core/executor installs failed. alpha.5 was the first release with git archive-built tarballs, and the archives were unprefixed. The installers extract with tar --strip-components=1, calibrated to the ./-prefixed entries of prior releases — strip-1 on an unprefixed archive discards every top-level file (venya-core-requirements.txt among them) and shifts packages/* up one level. Result: dependency install skipped, core/server not importable, install exits 1 loudly (no silent breakage, no service left half-configured). Caught by our own physical acceptance run on an ephemeral VM before announcement. alpha.5 is flagged prerelease and bannered; its assets are immutable and remain as published.
• Fix: tarballs are built with git archive --format=tar --prefix=./ <tag> | gzip -n — byte-reproducible AND layout-compatible with the installers. Zero installer changes. The build script now runs a fail-closed pre-publish extraction check with the installer's exact flags (requirements file + packages/ layout asserted before anything is served or published).
• The CLI installer was unaffected (it extracts without --strip-components); alpha.5 CLI assets install correctly. alpha.6 CLI assets are rebuilt with the uniform recipe anyway.

Verify it yourself

Release tarballs are byte-reproducible from any clone of the tag:

git clone git@github.com:tabith-llc/venya.git && cd /tmp && TAG=v0.1.0-alpha.6
git -C venya archive --format=tar --prefix=./ "$TAG" | gzip -n > venya-core-install.tar.gz
git -C venya archive --format=tar --prefix=./ "$TAG" packages/cli packages/mcp | gzip -n > venya-cli-install.tar.gz
BASE=https://github.com/tabith-llc/venya/releases/download/$TAG
curl -fsSLO $BASE/venya-core-install.tar.gz.sha256
curl -fsSLO $BASE/venya-cli-install.tar.gz.sha256
sha256sum -c venya-core-install.tar.gz.sha256 venya-cli-install.tar.gz.sha256

(--prefix=./ is load-bearing — see the defect above. Executor tarball is byte-identical to core by design. Byte-stability needs gzip -n and the same git major version.)

Suites at the product-identical alpha.5 tag (fresh clone): 1,729 passed (cli 291 / core 95+7 skipped / server 726 / executor 581 / mcp 36); inherited — packages/ diff alpha.4→alpha.5→alpha.6 is empty.

Install one-liners (Ubuntu 24.04; CLI also macOS)

# Core server (root)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-core.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_DB_PASSWORD=<strong-db-password> bash -s

# Executor (root; enrollment token from the core admin; Docker credentials via stdin;
# host needs /dev/kvm — nested virtualization on VM deployments)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-executor.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_SERVER_URL=https://<core-host> VENYA_EXECUTOR_ID=<executor-id> \
  VENYA_EXECUTOR_ENROLLMENT_TOKEN=<token> bash -s

# Workstation CLI (non-root; Ubuntu 24.04 or macOS)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-cli.sh | \
  VENYA_SKIP_PROMPT=yes bash

Integrity: pin VENYA_TARBALL_SHA256 (hashes below) for strict verification; unset, the installer fetches the .sha256 sidecar from the same origin (corruption guardrail, not a security boundary) and fail-closes. Sidecar hashes are independently reproducible from the tag (recipe above).

Artifacts (sha256)

File	sha256
venya-core-install.tar.gz	b22f7a4794e005fdaf6a3e61374febb315b97359867fe198c7f912bdc3e1d640
venya-executor-install.tar.gz	b22f7a4794e005fdaf6a3e61374febb315b97359867fe198c7f912bdc3e1d640
venya-cli-install.tar.gz	1f58559f5565a9b6052a86f9a5438d3398f307716bbc581ad3e3f25a6ba85897

Uninstallers for all three artifacts are attached. The executor sandbox requires Docker Sandboxes (sbx, proprietary; Docker account required) — see THIRD-PARTY-NOTICES.md. Licensed under BUSL-1.1 (LICENSE).

Documentation (in-repo at the tag)

docs/installation.md (full guide), docs/full-lifecycle-test.md (A-Z test plan), docs/architecture.md, docs/alpha-demo.md, docs/faq.md, docs/agents.md (LLM-agent/MCP integration), SECURITY.md (responsible disclosure). These guides ship inside the tarballs as well.

Status

ALPHA prerelease — functional but rough edges are expected. Known limitations are documented in docs/faq.md and the test plan (fresh installs need --key-version v1 for venya store; session tokens cannot be refreshed after expiry — re-login). No support commitment yet.

Venya 0.1.0-alpha.4

SUPERSEDED by v0.1.0-alpha.5 (distribution: deterministic git-archive assets, byte-reproducible from the tag; no product-code change — packages/ diff empty) — assets below are immutable and remain as published; use the newer release for installs.

Venya 0.1.0-alpha.4 — supersedes v0.1.0-alpha.3. Tag v0.1.0-alpha.4 @ commit 4ac4559.

What changed since v0.1.0-alpha.3

• SECURITY — secret role scoping is now enforced on listing and execution-session injection. A secret is visible/usable only if one of the caller's roles is in its --roles scope, or the caller created it. No admin bypass: the admin role matches only admin-scoped secrets. A scoped-out key returns the same 404 as a nonexistent key — cross-role key-name enumeration gets nothing. Previously, any user with read permission could list every secret, and any read-write user could inject and use any secret via run_command (values stayed masked by output redaction — the gap was use: e.g. ssh-ing with an admin-scoped credential without ever seeing it). Found by our own full-matrix test negative, fixed, and physically accepted: the exact probe that succeeded pre-fix now 404s, while the in-scope happy path still injects and redacts. Executor (mTLS) callers remain the trusted injection plane.
• Test hardening: the core visibility rules now have a real-SQLite truth table (in-scope, out-of-scope-indistinguishable, creator fallback, injection pos+neg, list matrix, metadata filters); a server test that had pinned the old any-reader-sees-all behavior was reversed into a shared-role-visible + out-of-scope-hidden pair; session-create gained an indistinguishable-404 paired negative. Suites at the tag: 1,729 passed (cli 291 / core 95+7 skipped / server 726 / executor 581 / mcp 36), fresh-clone verified.

Install one-liners (Ubuntu 24.04; CLI also macOS)

# Core server (root)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-core.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_DB_PASSWORD=<strong-db-password> bash -s

# Executor (root; enrollment token from the core admin; Docker credentials via stdin;
# host needs /dev/kvm — nested virtualization on VM deployments)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-executor.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_SERVER_URL=https://<core-host> VENYA_EXECUTOR_ID=<executor-id> \
  VENYA_EXECUTOR_ENROLLMENT_TOKEN=<token> bash -s

# Workstation CLI (non-root; Ubuntu 24.04 or macOS)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-cli.sh | \
  VENYA_SKIP_PROMPT=yes bash

No VENYA_TARBALL / VENYA_TARBALL_SHA256 needed: installers default to this release's assets. Integrity: pin VENYA_TARBALL_SHA256 (hashes below) for strict verification; unset, the installer fetches the .sha256 sidecar from the same origin (corruption guardrail, not a security boundary) and fail-closes.

Upgrading a core from alpha.3? After install, existing secrets keep their stored role scopes — enforcement is at read/inject time, no data migration needed.

Artifacts (sha256)

File	sha256
venya-core-install.tar.gz	529a63bd5fe321c2053ded21d7d58f427642eff8377e243b61363291cdd3f82d
venya-executor-install.tar.gz	529a63bd5fe321c2053ded21d7d58f427642eff8377e243b61363291cdd3f82d
venya-cli-install.tar.gz	6056628697e921c301b3664c09c057df88e6cf8cea6ca3236079d8779470b9d6

(core and executor tarballs are byte-identical this release: both are whole-tree archives built from a clean tag checkout with no local build cache.)

Uninstallers for all three artifacts are attached. The executor sandbox requires Docker Sandboxes (sbx, proprietary; Docker account required) — see THIRD-PARTY-NOTICES.md. Licensed under BUSL-1.1 (LICENSE).

Documentation (in-repo at the tag)

docs/installation.md (full guide), docs/full-lifecycle-test.md (A-Z test plan), docs/architecture.md, docs/alpha-demo.md, docs/faq.md, docs/agents.md (LLM-agent/MCP integration), SECURITY.md (responsible disclosure).

Status

ALPHA prerelease — functional but rough edges are expected. Known limitations are documented in docs/faq.md and the test plan (fresh installs need --key-version v1 for venya store; session tokens cannot be refreshed after expiry — re-login). No support commitment yet.

Venya 0.1.0-alpha.3

SUPERSEDED by v0.1.0-alpha.4 (security: secret role scoping enforcement) — assets below are immutable and remain as published; use the newer release for installs.

Venya 0.1.0-alpha.3 — supersedes v0.1.0-alpha.2. Tag v0.1.0-alpha.3 @ commit 3fbe9e1.

What changed since v0.1.0-alpha.2

• macOS support for the Workstation CLI: platform-convention config dir (~/Library/Application Support/venya), and the CLI installer runs on stock macOS (shasum fallback for hash verification, no readlink -f dependency, Linux-only /dev/hidraw check replaced with an IOKit note). Verified on macOS 26.6.2 arm64 with a full FIDO2 login round-trip.
• venya store fixed: it now sends the required key_version_id — previously every store failed with HTTP 422. Without --key-version, the CLI resolves the server's active key version; a failed lookup (fresh install: no active key version yet) exits loudly with a hint and writes nothing. New flag: --key-version (fresh installs: pass --key-version v1 until key-version bootstrap ships).
• venya store --force removed: it was a silent no-op (the server never accepted a force field; there are no upsert semantics). Storing an existing key creates a new row — delete the old secret first when replacing one.
• --show-sensitive removed CLI-wide: admin commands that mint enrollment tokens (admin enroll, admin create-user, admin executor-enroll, admin issue-token, admin re-enroll) now always print the token — these are single-use, short-TTL bootstrap artifacts, and the redaction gate protected nothing (the --json output of the same commands already printed tokens unredacted). Passing the flag is now an argparse error.
• CLI installer: the day-one printout now includes venya init <user-id> (creates the first admin account, FIDO2 key required) before venya login — previously an operator following the printout attempted login with no account.
• Executor installer: registration failures are now loud — full command output plus an explicit error block — instead of a silent exit that left no service unit and no diagnostics.
• Docs: new README Testing section (full A-Z lifecycle testing is ongoing; verified MCP clients: opencode and local LLMs via omlx.ai; FIDO2 hardware verified with the $29 Yubico Security Key C NFC; longer-timeout configuration for test runs). Published the self-contained Full-Lifecycle Test Plan and an interactive MCP driver so anyone can reproduce the provision → install → identity → secret → MCP-use-a-secret proof by hand. The alpha demo now uses venya store (the curl workaround is gone).
• Test suites at the tag: 1,722 passed (cli 291 / core 90+7 skipped / server 724 / executor 581 / mcp 36), fresh-clone verified.

Install one-liners (Ubuntu 24.04; CLI also macOS)

# Core server (root)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-core.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_DB_PASSWORD=<strong-db-password> bash -s

# Executor (root; enrollment token from the core admin; Docker credentials via stdin;
# host needs /dev/kvm — nested virtualization on VM deployments)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-executor.sh | sudo \
  VENYA_SKIP_PROMPT=yes VENYA_SERVER_URL=https://<core-host> VENYA_EXECUTOR_ID=<executor-id> \
  VENYA_EXECUTOR_ENROLLMENT_TOKEN=<token> bash -s

# Workstation CLI (non-root; Ubuntu 24.04 or macOS)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-cli.sh | \
  VENYA_SKIP_PROMPT=yes bash

No VENYA_TARBALL / VENYA_TARBALL_SHA256 needed: installers default to this release's assets. Integrity: pin VENYA_TARBALL_SHA256 (hashes below) for strict verification; unset, the installer fetches the .sha256 sidecar from the same origin (corruption guardrail, not a security boundary) and fail-closes.

Artifacts (sha256)

File	sha256
venya-core-install.tar.gz	05657b6d6630fe561edb3de4dcffcd8b40114b5e5fb34596b6b1e7fa186be6e4
venya-executor-install.tar.gz	05657b6d6630fe561edb3de4dcffcd8b40114b5e5fb34596b6b1e7fa186be6e4
venya-cli-install.tar.gz	783aa2ab5ab5240ec872089da2fd9c23c346d8f40b3ee8055ba2bd44a67b072c

(core and executor tarballs are byte-identical this release: both are whole-tree archives built from a clean tag checkout with no local build cache.)

Uninstallers for all three artifacts are attached. The executor sandbox requires Docker Sandboxes (sbx, proprietary; Docker account required) — see THIRD-PARTY-NOTICES.md. Licensed under BUSL-1.1 (LICENSE).

Documentation (in-repo at the tag)

docs/installation.md (full guide), docs/full-lifecycle-test.md (A-Z test plan), docs/architecture.md, docs/alpha-demo.md, docs/faq.md, docs/agents.md (LLM-agent/MCP integration), SECURITY.md (responsible disclosure).

Status

ALPHA prerelease — functional but rough edges are expected. Known limitations are documented in docs/faq.md and the test plan (fresh installs need --key-version v1 for venya store; session tokens cannot be refreshed after expiry — re-login). No support commitment yet.