release: package Windows builds with managed Tor

2 files changed, 22 insertions, 0 deletions

diff --git a/docs/release-verification.md b/docs/release-verification.md
index 408bab9..04d18a3 100644
--- a/docs/release-verification.md
+++ b/docs/release-verification.md
@@ -81,6 +81,12 @@ Publish, alongside the assets, `SHA256SUMS` and `SHA256SUMS.asc`, and update
 is ever rotated, announce the new fingerprint clearly and update the embedded
 key in `verify-release.sh`.
 
+For Windows releases with managed Tor built in, run `make windows-tor`. It
+creates `Bitflash-*-windows-with-tor.zip` by downloading the Tor Expert Bundle,
+checking the pinned SHA256 in `scripts/package-windows-tor.sh`, and placing
+`tor/tor.exe` next to `Bitflash.exe`. Include that zip in `SHA256SUMS` like any
+other release asset.
+
 ## Why this matters
 
 `SHA256SUMS` alone protects against a broken download, but not against someone
diff --git a/docs/tor.md b/docs/tor.md
index 1c0f589..be6a145 100644
--- a/docs/tor.md
+++ b/docs/tor.md
@@ -53,6 +53,22 @@ Without a value, Bitflash looks for Tor in this order:
 2. `tor.exe` or `tor` beside the Bitflash binary;
 3. `tor.exe` or `tor` on `PATH`.
 
+Windows releases can also be built as `Bitflash-*-windows-with-tor.zip`. That
+package includes the official Tor Expert Bundle under `tor/`, so the first path
+above exists immediately after extraction and `bitflash -managedtor` needs no
+separate Tor install.
+
+The bundled-Tor package is created by:
+
+```bash
+make windows-tor
+```
+
+The packaging script verifies a pinned SHA256 for the downloaded Tor Expert
+Bundle before copying it into the release directory. The Tor binary is bundled;
+the runtime data directory, hidden-service key, and control cookie are still
+created under the user's Bitflash data directory.
+
 To point at a specific Tor executable:
 
 ```bash