CoreTend 0.9.1-rc.2

CoreTend 0.9.1-rc.2 (release candidate)

This release candidate supersedes 0.9.1-rc.1. It is not a stable 1.0.

Why rc.2 exists. The rc.1 artifacts were built before the work below
landed, so the binaries published under that tag did not contain it. Rather
than replace rc.1's files — which would have broken every checksum anyone had
already recorded — rc.1 is left exactly as it was published, and this is a new
build from the current source.

New in this build

• Check for Updates, in Settings and in the app menu (Cmd-Shift-U). It
  reports the installed version, the latest published version and its notes,
  and opens the official release page. It never downloads or installs an
  update: see below.
• Stable and prerelease channels are separated. A stable user is never
  offered a release candidate, even a newer one. Automatic checking is off
  by default and opt-in.
• A trust section on the website where every claim links to the evidence,
  and a Verify your download page in both languages.
• The release itself is now built by a workflow from the tag, and ships a
  provenance attestation, an SPDX SBOM, SHA-256 checksums and Minisign
  signatures.

Why the app will not update itself

Installing an update means running code fetched from the network, which is
only safe if the publisher can be proven. A SHA-256 checksum published beside
the file it describes proves the download was not corrupted; it proves nothing
about who produced it, because anyone able to replace the artifact can replace
the checksum too. These builds also carry no Apple Developer ID.

So the app does the honest subset: it tells you a version exists, shows you
what changed, and sends you to the official release page to download and
verify it yourself. CoreTend remains fully functional offline; the check is
optional and asks first.

Verifying this release

Four independent checks, weakest to strongest — each answers a different
question and none replaces the others:

1. SHA-256 — the file arrived intact. shasum -a 256 -c SHA256SUMS
2. Minisign — the file was signed by CoreTend's release key.
   minisign -Vm <file> -P RWQwtx2esD9H+O7kDWTJcdyTfcWYkmnRMqlDrk0L8xHZkSk4lA6rZqSg
   (key ID F8473FB09E1DB730, also published as minisign.pub)
3. Provenance attestation — this exact file was produced by this
   repository's release workflow from a named commit.
   gh attestation verify <file> --repo ahmetbsbnr/coretend
4. Build it yourself — Documentation/BUILDING.md, tested end to end.

Minisign is not Apple code signing and not notarization. It proves the
release key signed the file. It does not make macOS trust the app.

Still true, and stated plainly

Unsigned and not notarized. security find-identity -v -p codesigning
reports zero valid identities on the build machine, because a Developer ID
requires a paid Apple Developer Program membership this project does not have.
macOS will refuse to open the app on first launch, and that warning is
accurate.

Two official ways to open it anyway, both of which keep every system
protection in place:

• Control-click (or right-click) CoreTend in Finder, choose Open, confirm.
• Or System Settings → Privacy & Security, find the blocked-app message,
  choose Open Anyway.

Never disable Gatekeeper to install this. Nothing here is worth turning
off a system-wide protection, and nothing in this project will ever ask you
to.

The trademark watch item on COREXTEND is unresolved and legalReviewStatus
remains pending. No legal or trademark clearance is claimed.