From 4a99d996db837bd3fa699941084b36142dbc8541 Mon Sep 17 00:00:00 2001 From: Ion Alpha Date: Wed, 4 Nov 2026 16:59:02 +0000 Subject: [PATCH] docs: prepare the README and notes for the v0.2.0 final The README told readers that main was a release candidate and pinned its install examples to v0.2.0-rc.1, and the notes had a section on installing a candidate that only makes sense before the final ships. The README now pins v0.2.0 in its example and points v0.1.3 users at flynn upgrade and the upgrade notes. The rc-only paragraphs are gone. The general instructions for testing a future candidate stay. The notes keep the one fact from the candidate section that still applies (v0.1.3 cannot read a data directory v0.2.0 wrote) under Upgrading, and add two known limitations: a planner that writes a check for a file outside the working directory, which the sandbox then refuses, and the GO-2026-5932 report from scanners that match by module version, with why Flynn does not reach the affected packages. Signed-off-by: Ion Alpha --- README.md | 21 ++++++--------------- docs/releases/v0.2.0.md | 15 +++++---------- 2 files changed, 11 insertions(+), 25 deletions(-) diff --git a/README.md b/README.md index b578bb12..8720a93d 100644 --- a/README.md +++ b/README.md @@ -46,16 +46,13 @@ curl -fsSL https://raw.githubusercontent.com/ionalpha/flynn/main/install.sh | sh irm https://raw.githubusercontent.com/ionalpha/flynn/main/install.ps1 | iex ``` -Pin a version with `FLYNN_VERSION` (for example `FLYNN_VERSION=v0.2.0-rc.1`) or change +Pin a version with `FLYNN_VERSION` (for example `FLYNN_VERSION=v0.2.0`) or change the install directory with `FLYNN_INSTALL_DIR`. -The script installs the newest release, v0.1.3. This README describes `main`, which is -the v0.2.0 release candidate: governed goals, the bundled skill pack and the new memory -are in v0.2.0-rc.1 and not in v0.1.3. To try the candidate, install with -`FLYNN_VERSION=v0.2.0-rc.1`, or run `flynn upgrade --pre` from v0.1.3. Read the -[v0.2.0 notes](docs/releases/v0.2.0.md#upgrading-from-v013) before upgrading: commands -the agent runs now have no network unless you pass `--allow-network`, except on Windows, -which cannot deny it (see Sandbox and network). +Coming from v0.1.3? Run `flynn upgrade`, and read the +[v0.2.0 notes](docs/releases/v0.2.0.md#upgrading-from-v013) first: commands the agent +runs now have no network unless you pass `--allow-network`, except on Windows, which +cannot deny it (see Sandbox and network). **Testing a release candidate?** The lines above install the latest final release, because GitHub's "latest" never includes a release candidate. To get the candidate, set @@ -120,11 +117,6 @@ The same image is on Docker Hub as `ionalpha/flynn:latest`. Pin a version by tag reach the agent, add a channel (for example `-e TELEGRAM_BOT_TOKEN=... -e FLYNN_TELEGRAM_ALLOW=`), or see [`deploy/README.md`](deploy/README.md) for remote access and hardening. -Until v0.2.0 ships, `latest` (the image tag and the release download) is v0.1.3, which -has no shell and no profiles. To run the release candidate, set -`base=https://github.com/ionalpha/flynn/releases/download/v0.2.0-rc.1` and use the image -`ghcr.io/ionalpha/flynn:0.2.0-rc.1`. - Every published manifest is keyless-signed with cosign: ```sh @@ -631,8 +623,7 @@ workspaces, SSO, and audit and backup. ## Status and roadmap -The features above work today on `main` and in v0.2.0-rc.1; see [Install](#install) -for what v0.1.3 lacks. Follow [@ionalpha_](https://x.com/ionalpha_) for +The features above are in v0.2.0. Follow [@ionalpha_](https://x.com/ionalpha_) for progress. **In progress** diff --git a/docs/releases/v0.2.0.md b/docs/releases/v0.2.0.md index b13dc129..6eafed59 100644 --- a/docs/releases/v0.2.0.md +++ b/docs/releases/v0.2.0.md @@ -10,16 +10,7 @@ Upgrading the binary: `flynn upgrade` from v0.1.3. Releases before v0.1.3 have n - **A served channel needs an allow-list.** `flynn serve` with a Telegram or Signal channel and no allow-list refuses to start. Add `--telegram-allow ` or `--signal-allow ` (or `FLYNN_TELEGRAM_ALLOW` and `FLYNN_SIGNAL_ALLOW`, comma separated). Telegram senders are matched by numeric user id, not username, since a username can be changed or reassigned. - **A host that cannot confine refuses commands.** v0.1.3 ran a command without a boundary where the sandbox was unavailable. This release refuses it. Ubuntu 24.04 and later restrict user namespaces through AppArmor, which is the common cause; `flynn sandbox check` names the cause on your host and the fix, and `deploy/apparmor/flynn` is the profile that lifts the restriction for the Flynn binary alone. - **The container image runs commands, given its profiles.** The image now carries busybox on `gcr.io/distroless/static-debian13:debug-nonroot`, so the agent can run commands in it, which the v0.1.3 image could not. Docker's default seccomp and AppArmor profiles stop the sandbox from starting, so pass the two Flynn ships with each release (`flynn-seccomp.json`, and `flynn-apparmor-container` on an AppArmor host); `deploy/README.md` has the commands. Without them `flynn serve` and the API run as before and every command is refused with the cause. Do not use `seccomp=unconfined`, `apparmor=unconfined` or `CAP_SYS_ADMIN` instead. - -### Testing a release candidate - -The one-line install in the README fetches the latest final release, which is v0.1.3 until v0.2.0 is out. To install the candidate, set `FLYNN_PRERELEASE`: - -- Linux and macOS: `curl -fsSL https://raw.githubusercontent.com/ionalpha/flynn/main/install.sh | FLYNN_PRERELEASE=1 sh` -- Windows (PowerShell): `$env:FLYNN_PRERELEASE = '1'; irm https://raw.githubusercontent.com/ionalpha/flynn/main/install.ps1 | iex` -- Already installed: `flynn upgrade --pre` - -Run `flynn version` afterwards; it should name a `v0.2.0-rc` release. v0.1.3 cannot read a data directory the candidate has written and fails with `sqlite: no such column: uses`. If you keep the older binary, give it its own `--data-dir`. +- **The data directory moves forward only.** v0.1.3 cannot read a data directory v0.2.0 has written and fails with `sqlite: no such column: uses`. If you keep the older binary, give it its own `--data-dir`. ### Goals you can govern @@ -115,6 +106,10 @@ The full exported-API report is at the end of these notes. - On Windows, Git for Windows' bash and other MSYS2 or Cygwin programs cannot start under the default confinement: the runtime has to create a named pipe and a per-user shared section that the write-restricted token is refused write access to, and allowing it would mean granting the user's own identity or changing objects other processes share. A host that confines a program through `sandbox.Local` with `WithDefaultConfinement` therefore cannot confine one that runs its commands through Git Bash. Native programs (cmd, PowerShell, Node, compiled binaries) run and are confined as described above. +- A goal's planner can write an acceptance check for a file the task never asked for, sometimes outside the working directory (for example under `%TEMP%` on Windows). The worker then tries to create that file, the sandbox refuses the write, and the goal ends failed. Flynn reports the failed check and the refused command, so the run does not claim work it did not do. How often this happens varies with the model and from run to run. Checking each acceptance check before work starts, and letting a wrong check be revised, is planned for v0.3. + +- Scanners that match by module version alone (Docker Scout, Trivy, Grype) report GO-2026-5932 against `golang.org/x/crypto` v0.58.0 in the binary and the image. The advisory covers `golang.org/x/crypto/openpgp` and its subpackages. Flynn imports none of them: `go list -deps ./...` lists no openpgp package, and govulncheck, which follows calls, reports the advisory as present in a required module and never called. Flynn will take the first tagged x/crypto release that contains the fix. + ### Release engineering - Every pull request runs the release in snapshot form (all six targets, archives, deb/rpm/apk, SBOMs, container images) and the end-to-end suite against the release's own binaries on Linux, macOS and Windows, so a break in the release fails a pull request instead of a tag.