ripcord 0.11.1

What is in 0.11.1

Changed

• The publisher's hourly log line gives min, mean and max, took 0.8 s min, 1.1 s mean,
  6.2 s max, instead of the slowest attempt alone: one slow cold start and a host slow on every
  attempt no longer read the same.

Before you update

Update both hosts, one after the other, and finish. Ripcord's failover sequences are encoded
in the binary and they span two hosts, so a pair running two versions would execute half a
sequence written by each. A planned failover and a failback therefore refuse on a version
mismatch rather than warning — which means a pair left half-updated cannot be moved electively.
The window between the two hosts is the one time the tool will not work.

The one exception is failover --scenario unplanned, which runs entirely on the host it is
typed on. There is no half for the other binary to execute, and refusing a disaster failover for
want of a version string the dead host never published would fail at the one thing this tool
exists for.

Do it when nothing is on fire, not during an incident.

Verify what you are installing

There is no Authenticode signature yet; it needs a paid certificate. Until then the SHA-256
checksum published beside the binary is the only way to tell that the file on the host is the
file that was built. Check it before replacing anything.

(Get-FileHash ripcord.exe -Algorithm SHA256).Hash.ToLower()

Updating

After updating a host, run ripcord service install --dry-run, then
ripcord service install. A release can need something new on the host; install applies it,
and restarts a Ripcord service still running the build from before the update. Then the other
host, the same way.

ripcord update installs a newer release on the host it is run on. It is off unless
updates.install says so, it asks y/n with Enter declining, and it refuses any release
whose detached signature does not verify against the key compiled into the running binary.
Copying the .exe by hand still works and is still supported; fully offline operation stays
possible.

This reverses what earlier versions of this file said. The objection was sound and has not gone
away: a binary that replaces itself, with Hyper-V privileges, on both hosts of a disaster
recovery pair, from the internet, is a supply chain reaching past the controls the rest of the
tool is built around. What changed is that the path now has a trust root that is not the release
page — the signature is checked against a pinned key, and an unverifiable release is refused
before anything is touched. What has not changed is that the signing key lives in the
release workflow, so an account with write access to the repository can still sign; see
SECURITY.md.

Update one host at a time, and update both. While the two differ, a failover spanning them
is refused — the sequences are encoded in the binary and one executed half by each version is
the error nobody recovers from at 3 a.m. The command says which host to run next.

The full procedure is in docs/RELEASING.md.

ripcord 0.11.0

What is in 0.11.0

Changed

• The publisher's hourly log line says its slowest attempt, slowest 1.2 s: from the start
  of the read to the end of the write. Near 15 s, the other host's view starts to age.
• Each publication asks Hyper-V for its replication service once, not once per VM.

Before you update

Update both hosts, one after the other, and finish. Ripcord's failover sequences are encoded
in the binary and they span two hosts, so a pair running two versions would execute half a
sequence written by each. A planned failover and a failback therefore refuse on a version
mismatch rather than warning — which means a pair left half-updated cannot be moved electively.
The window between the two hosts is the one time the tool will not work.

The one exception is failover --scenario unplanned, which runs entirely on the host it is
typed on. There is no half for the other binary to execute, and refusing a disaster failover for
want of a version string the dead host never published would fail at the one thing this tool
exists for.

Do it when nothing is on fire, not during an incident.

Verify what you are installing

There is no Authenticode signature yet; it needs a paid certificate. Until then the SHA-256
checksum published beside the binary is the only way to tell that the file on the host is the
file that was built. Check it before replacing anything.

(Get-FileHash ripcord.exe -Algorithm SHA256).Hash.ToLower()

Updating

After updating a host, run ripcord service install --dry-run, then
ripcord service install. A release can need something new on the host; install applies it,
and restarts a Ripcord service still running the build from before the update. Then the other
host, the same way.

ripcord update installs a newer release on the host it is run on. It is off unless
updates.install says so, it asks y/n with Enter declining, and it refuses any release
whose detached signature does not verify against the key compiled into the running binary.
Copying the .exe by hand still works and is still supported; fully offline operation stays
possible.

This reverses what earlier versions of this file said. The objection was sound and has not gone
away: a binary that replaces itself, with Hyper-V privileges, on both hosts of a disaster
recovery pair, from the internet, is a supply chain reaching past the controls the rest of the
tool is built around. What changed is that the path now has a trust root that is not the release
page — the signature is checked against a pinned key, and an unverifiable release is refused
before anything is touched. What has not changed is that the signing key lives in the
release workflow, so an account with write access to the repository can still sign; see
SECURITY.md.

Update one host at a time, and update both. While the two differ, a failover spanning them
is refused — the sequences are encoded in the binary and one executed half by each version is
the error nobody recovers from at 3 a.m. The command says which host to run next.

The full procedure is in docs/RELEASING.md.

ripcord 0.10.0

What is in 0.10.0

Changed

• The listener logs in a folder of its own, logs\listener\, like the publisher in
  logs\publish\. It no longer has modify on logs\, where commands write, so the process
  facing the network cannot rewrite or delete their log. On an existing host,
  ripcord service install creates the folder, restarts the listener onto it and then takes
  back its grant on logs\. The listener-*.log files already in logs\ stay there and are
  pruned after 30 days like the rest.
• ripcord service remove is now ripcord service uninstall, the counterpart of install.
  remove changes nothing and says what to type instead.

Fixed

• A snapshot write that met another one is retried, up to 80 ms, instead of failing: Windows
  refuses a replace while another one of the same file is under way, so the publisher and an
  administrator's ripcord status could have status report could not publish its snapshot.

Before you update

Update both hosts, one after the other, and finish. Ripcord's failover sequences are encoded
in the binary and they span two hosts, so a pair running two versions would execute half a
sequence written by each. A planned failover and a failback therefore refuse on a version
mismatch rather than warning — which means a pair left half-updated cannot be moved electively.
The window between the two hosts is the one time the tool will not work.

The one exception is failover --scenario unplanned, which runs entirely on the host it is
typed on. There is no half for the other binary to execute, and refusing a disaster failover for
want of a version string the dead host never published would fail at the one thing this tool
exists for.

Do it when nothing is on fire, not during an incident.

Verify what you are installing

There is no Authenticode signature yet; it needs a paid certificate. Until then the SHA-256
checksum published beside the binary is the only way to tell that the file on the host is the
file that was built. Check it before replacing anything.

(Get-FileHash ripcord.exe -Algorithm SHA256).Hash.ToLower()

Updating

After updating a host, run ripcord service install --dry-run, then
ripcord service install. A release can need something new on the host; install applies it,
and restarts a Ripcord service still running the build from before the update. Then the other
host, the same way.

ripcord update installs a newer release on the host it is run on. It is off unless
updates.install says so, it asks y/n with Enter declining, and it refuses any release
whose detached signature does not verify against the key compiled into the running binary.
Copying the .exe by hand still works and is still supported; fully offline operation stays
possible.

This reverses what earlier versions of this file said. The objection was sound and has not gone
away: a binary that replaces itself, with Hyper-V privileges, on both hosts of a disaster
recovery pair, from the internet, is a supply chain reaching past the controls the rest of the
tool is built around. What changed is that the path now has a trust root that is not the release
page — the signature is checked against a pinned key, and an unverifiable release is refused
before anything is touched. What has not changed is that the signing key lives in the
release workflow, so an account with write access to the repository can still sign; see
SECURITY.md.

Update one host at a time, and update both. While the two differ, a failover spanning them
is refused — the sequences are encoded in the binary and one executed half by each version is
the error nobody recovers from at 3 a.m. The command says which host to run next.

The full procedure is in docs/RELEASING.md.

ripcord 0.9.0

What is in 0.9.0

Changed

• ripcord update shows its progress on one line, redrawn in place: the step running,
  with the download's percentage (megabytes when the server gives no size), erased once the
  result is printed. Redirected to a file, nothing is drawn. The closing done: list is gone,
  and a failed step's description no longer appears twice in the failure message.
• services.msc names and describes both services, as Ripcord listener and Ripcord
  publisher, each with one line on what it does and what stopping it costs. A host installed
  before this gets them on its next service install.

Before you update

Update both hosts, one after the other, and finish. Ripcord's failover sequences are encoded
in the binary and they span two hosts, so a pair running two versions would execute half a
sequence written by each. A planned failover and a failback therefore refuse on a version
mismatch rather than warning — which means a pair left half-updated cannot be moved electively.
The window between the two hosts is the one time the tool will not work.

The one exception is failover --scenario unplanned, which runs entirely on the host it is
typed on. There is no half for the other binary to execute, and refusing a disaster failover for
want of a version string the dead host never published would fail at the one thing this tool
exists for.

Do it when nothing is on fire, not during an incident.

Verify what you are installing

There is no Authenticode signature yet; it needs a paid certificate. Until then the SHA-256
checksum published beside the binary is the only way to tell that the file on the host is the
file that was built. Check it before replacing anything.

(Get-FileHash ripcord.exe -Algorithm SHA256).Hash.ToLower()

Updating

After updating a host, run ripcord service install --dry-run, then
ripcord service install. A release can need something new on the host; install applies it,
and restarts a Ripcord service still running the build from before the update. Then the other
host, the same way.

ripcord update installs a newer release on the host it is run on. It is off unless
updates.install says so, it asks y/n with Enter declining, and it refuses any release
whose detached signature does not verify against the key compiled into the running binary.
Copying the .exe by hand still works and is still supported; fully offline operation stays
possible.

This reverses what earlier versions of this file said. The objection was sound and has not gone
away: a binary that replaces itself, with Hyper-V privileges, on both hosts of a disaster
recovery pair, from the internet, is a supply chain reaching past the controls the rest of the
tool is built around. What changed is that the path now has a trust root that is not the release
page — the signature is checked against a pinned key, and an unverifiable release is refused
before anything is touched. What has not changed is that the signing key lives in the
release workflow, so an account with write access to the repository can still sign; see
SECURITY.md.

Update one host at a time, and update both. While the two differ, a failover spanning them
is refused — the sequences are encoded in the binary and one executed half by each version is
the error nobody recovers from at 3 a.m. The command says which host to run next.

The full procedure is in docs/RELEASING.md.

ripcord 0.8.0

What is in 0.8.0

Added

• A second service, ripcord-publish, republishes this host's snapshot every 15 seconds.
  The other host's view no longer ages until somebody runs ripcord status here. The
  network-facing listener still reads nothing of Hyper-V; the publisher, which has no socket,
  runs as NT SERVICE\ripcord-publish in Hyper-V Administrators, with modify on state\ and
  on its own logs\publish\ only, and one ACE on the BitLocker namespace while
  storage.check_bitlocker_autounlock is on. BitLocker it still cannot read is carried from
  the last administrator's read, dated. ripcord publish does it once by hand.
• service install and service remove handle both services; restart, start and
  stop act on both, and ripcord service shows the publisher with the last lines of its log.
  Install also restarts a service still running the build from before ripcord update, sets
  both to restart a minute after a crash, and narrows the listener's 0.7.0 read on the install
  folder to its own files.

Upgrading a host: ripcord update, then ripcord service install --dry-run and
ripcord service install. It creates the publisher and state\, restarts the listener onto
the new binary and state\state.json, and starts the publisher. If a stale snapshot remains,
ripcord service names the one command that fixes it. The old state.json beside
ripcord.yaml can be deleted.

Changed

• The snapshot moves to state\state.json beside ripcord.yaml, and is no longer
  configurable. A folder of its own, so nothing that writes it is ever granted anything
  beside ripcord.exe. A listener.snapshot_path line still loads, is ignored, and every
  command says so. See Upgrading a host above.
• service install grants the listener read access to ripcord.yaml explicitly, on the
  files of the install folder only. It used to come from the snapshot grant on that folder.

Fixed

• The peer's lag grew with its snapshot's age. A snapshot 7 minutes old showed 7m19s of
  lag on a replication 17 s behind: the lag was measured to now instead of to when the
  snapshot was taken. status and the dashboard now measure it at the snapshot.

• ripcord service install takes back access nothing uses any more. The service account
  kept read access to the private key of every certificate replaced by pair or a renewal,
  and to the old install folder after the binary moved. Install now revokes them, last, after
  everything the listener needs; with the configured key not found it touches no key.

Before you update

Update both hosts, one after the other, and finish. Ripcord's failover sequences are encoded
in the binary and they span two hosts, so a pair running two versions would execute half a
sequence written by each. A planned failover and a failback therefore refuse on a version
mismatch rather than warning — which means a pair left half-updated cannot be moved electively.
The window between the two hosts is the one time the tool will not work.

The one exception is failover --scenario unplanned, which runs entirely on the host it is
typed on. There is no half for the other binary to execute, and refusing a disaster failover for
want of a version string the dead host never published would fail at the one thing this tool
exists for.

Do it when nothing is on fire, not during an incident.

Verify what you are installing

There is no Authenticode signature yet; it needs a paid certificate. Until then the SHA-256
checksum published beside the binary is the only way to tell that the file on the host is the
file that was built. Check it before replacing anything.

(Get-FileHash ripcord.exe -Algorithm SHA256).Hash.ToLower()

Updating

After updating a host, run ripcord service install --dry-run, then
ripcord service install. A release can need something new on the host; install applies it,
and restarts a Ripcord service still running the build from before the update. Then the other
host, the same way.

ripcord update installs a newer release on the host it is run on. It is off unless
updates.install says so, it asks y/n with Enter declining, and it refuses any release
whose detached signature does not verify against the key compiled into the running binary.
Copying the .exe by hand still works and is still supported; fully offline operation stays
possible.

This reverses what earlier versions of this file said. The objection was sound and has not gone
away: a binary that replaces itself, with Hyper-V privileges, on both hosts of a disaster
recovery pair, from the internet, is a supply chain reaching past the controls the rest of the
tool is built around. What changed is that the path now has a trust root that is not the release
page — the signature is checked against a pinned key, and an unverifiable release is refused
before anything is touched. What has not changed is that the signing key lives in the
release workflow, so an account with write access to the repository can still sign; see
SECURITY.md.

Update one host at a time, and update both. While the two differ, a failover spanning them
is refused — the sequences are encoded in the binary and one executed half by each version is
the error nobody recovers from at 3 a.m. The command says which host to run next.

The full procedure is in docs/RELEASING.md.

ripcord 0.7.0

What is in 0.7.0

Changed

• Two confirmation levels. Only what moves production VMs — failover, failback,
  fence — still asks for the node name typed in full. service install, remove and stop,
  test-failover, update and rollback ask y/n [n] instead, Enter declining: each is
  undone by running it again or touches only a test VM, and a typed name asked for every
  change becomes the reflex the failover confirmation must never be.

Added

• ripcord service shows this host's certificate: the thumbprint of each unexpired
  certificate whose CN is this host's, with a private key in LocalMachine\My, marked when it
  is the one in ripcord.yaml, even when that file does not load — with the one line to run
  on the other host.

• ripcord pair <host>:<thumbprint> writes both certificate thumbprints into
  ripcord.yaml from that line: this host's own is found in LocalMachine\My, the other's is
  the one pasted. Two lines change, the previous file is kept as .1, y/n, --dry-run.
  A key pasted on the host it came from, or naming another host than peer.hostname, is
  refused. No more editing the thumbprints by hand.

• ripcord status says the listener is running, in one LISTENER line with the build
  its process runs, instead of leaving a missing block to mean it. After an update without a
  restart, a second line names ripcord service restart.

• ripcord service start and ripcord service stop. start starts a stopped listener
  without confirmation and leaves a running one alone. stop asks y/n — the
  other host cannot read this one until the listener starts again — and waits for Windows to
  report it stopped.

• ripcord service shows the build the running listener runs, from a record the listener
  writes when it starts (logs\listener-process.txt), believed only when its process id is
  the one Windows gives. After ripcord update without a restart it says the process still
  runs the old build and ends with ripcord service restart. A listener started before this
  version has no record: unknown until it restarts.

Changed

• The samples' placeholder thumbprints are refused by name. A listener block still
  carrying AAAA1111… or 1111AAAA… used to load, and the pair channel then failed as a
  SILENT peer, which reads as a network fault. A ripcord.yaml whose listener is enabled
  with them no longer loads: put the thumbprints of the two hosts' certificates, or set
  enabled: false, behind which they are ignored.

Fixed

• A refusal no longer blames Hyper-V when Hyper-V was not involved. Every failure line
  began "cannot read the local Hyper-V state", including check-update refusing because
  checking was off. Only a failed Hyper-V read says so now.
• updates.check and updates.install refusals say how to switch them on:
  set updates.check: true in ripcord.yaml, and likewise for install.
• Failure and refusal lines wrap at 75 columns, so a reason from Windows or the network
  no longer runs off a 1024×768 console.

Before you update

Update both hosts, one after the other, and finish. Ripcord's failover sequences are encoded
in the binary and they span two hosts, so a pair running two versions would execute half a
sequence written by each. A planned failover and a failback therefore refuse on a version
mismatch rather than warning — which means a pair left half-updated cannot be moved electively.
The window between the two hosts is the one time the tool will not work.

The one exception is failover --scenario unplanned, which runs entirely on the host it is
typed on. There is no half for the other binary to execute, and refusing a disaster failover for
want of a version string the dead host never published would fail at the one thing this tool
exists for.

Do it when nothing is on fire, not during an incident.

Verify what you are installing

There is no Authenticode signature yet; it needs a paid certificate. Until then the SHA-256
checksum published beside the binary is the only way to tell that the file on the host is the
file that was built. Check it before replacing anything.

(Get-FileHash ripcord.exe -Algorithm SHA256).Hash.ToLower()

Updating

ripcord update installs a newer release on the host it is run on. It is off unless
updates.install says so, it asks y/n with Enter declining, and it refuses any release
whose detached signature does not verify against the key compiled into the running binary.
Copying the .exe by hand still works and is still supported; fully offline operation stays
possible.

This reverses what earlier versions of this file said. The objection was sound and has not gone
away: a binary that replaces itself, with Hyper-V privileges, on both hosts of a disaster
recovery pair, from the internet, is a supply chain reaching past the controls the rest of the
tool is built around. What changed is that the path now has a trust root that is not the release
page — the signature is checked against a pinned key, and an unverifiable release is refused
before anything is touched. What has not changed is that the signing key lives in the
release workflow, so an account with write access to the repository can still sign; see
SECURITY.md.

Update one host at a time, and update both. While the two differ, a failover spanning them
is refused — the sequences are encoded in the binary and one executed half by each version is
the error nobody recovers from at 3 a.m. The command says which host to run next.

The full procedure is in docs/RELEASING.md.

ripcord 0.6.0

What is in 0.6.0

Added

• ripcord status ends with a LISTENER block when the other host cannot read this one:
  the service is not installed, not running, or could not be read,
  with the command to run next. Over there this host only shows SILENT, which reads as a
  network fault. The exit code is unchanged.
• ripcord init asks whether to check GitHub for a newer release, last, defaulting to
  no, and writes updates.check either way. updates.install is still never asked: a re-run
  keeps it, unless the check is answered no — install cannot be on without it. The samples'
  commented-out # updates: example is dropped from the rewritten file.

Fixed

• Each ripcord init re-run added a blank line between the sections it carries over
  (listener, checks, …). A second re-run now gives the file back unchanged.

Before you update

Update both hosts, one after the other, and finish. Ripcord's failover sequences are encoded
in the binary and they span two hosts, so a pair running two versions would execute half a
sequence written by each. A planned failover and a failback therefore refuse on a version
mismatch rather than warning — which means a pair left half-updated cannot be moved electively.
The window between the two hosts is the one time the tool will not work.

The one exception is failover --scenario unplanned, which runs entirely on the host it is
typed on. There is no half for the other binary to execute, and refusing a disaster failover for
want of a version string the dead host never published would fail at the one thing this tool
exists for.

Do it when nothing is on fire, not during an incident.

Verify what you are installing

There is no Authenticode signature yet; it needs a paid certificate. Until then the SHA-256
checksum published beside the binary is the only way to tell that the file on the host is the
file that was built. Check it before replacing anything.

(Get-FileHash ripcord.exe -Algorithm SHA256).Hash.ToLower()

Updating

ripcord update installs a newer release on the host it is run on. It is off unless
updates.install says so, it asks for the node name to be typed, and it refuses any release
whose detached signature does not verify against the key compiled into the running binary.
Copying the .exe by hand still works and is still supported; fully offline operation stays
possible.

This reverses what earlier versions of this file said. The objection was sound and has not gone
away: a binary that replaces itself, with Hyper-V privileges, on both hosts of a disaster
recovery pair, from the internet, is a supply chain reaching past the controls the rest of the
tool is built around. What changed is that the path now has a trust root that is not the release
page — the signature is checked against a pinned key, and an unverifiable release is refused
before anything is touched. What has not changed is that the signing key lives in the
release workflow, so an account with write access to the repository can still sign; see
SECURITY.md.

Update one host at a time, and update both. While the two differ, a failover spanning them
is refused — the sequences are encoded in the binary and one executed half by each version is
the error nobody recovers from at 3 a.m. The command says which host to run next.

The full procedure is in docs/RELEASING.md.

ripcord 0.5.0

What is in 0.5.0

No changelog entry was written for this version.

Compare the tags on GitHub to see what changed, and read the standing notes below
before putting it on a host.

Before you update

Update both hosts, one after the other, and finish. Ripcord's failover sequences are encoded
in the binary and they span two hosts, so a pair running two versions would execute half a
sequence written by each. A planned failover and a failback therefore refuse on a version
mismatch rather than warning — which means a pair left half-updated cannot be moved electively.
The window between the two hosts is the one time the tool will not work.

The one exception is failover --scenario unplanned, which runs entirely on the host it is
typed on. There is no half for the other binary to execute, and refusing a disaster failover for
want of a version string the dead host never published would fail at the one thing this tool
exists for.

Do it when nothing is on fire, not during an incident.

Verify what you are installing

There is no Authenticode signature yet; it needs a paid certificate. Until then the SHA-256
checksum published beside the binary is the only way to tell that the file on the host is the
file that was built. Check it before replacing anything.

(Get-FileHash ripcord.exe -Algorithm SHA256).Hash.ToLower()

Updating

ripcord update installs a newer release on the host it is run on. It is off unless
updates.install says so, it asks for the node name to be typed, and it refuses any release
whose detached signature does not verify against the key compiled into the running binary.
Copying the .exe by hand still works and is still supported; fully offline operation stays
possible.

This reverses what earlier versions of this file said. The objection was sound and has not gone
away: a binary that replaces itself, with Hyper-V privileges, on both hosts of a disaster
recovery pair, from the internet, is a supply chain reaching past the controls the rest of the
tool is built around. What changed is that the path now has a trust root that is not the release
page — the signature is checked against a pinned key, and an unverifiable release is refused
before anything is touched. What has not changed is that the signing key lives in the
release workflow, so an account with write access to the repository can still sign; see
SECURITY.md.

Update one host at a time, and update both. While the two differ, a failover spanning them
is refused — the sequences are encoded in the binary and one executed half by each version is
the error nobody recovers from at 3 a.m. The command says which host to run next.

The full procedure is in docs/RELEASING.md.

ripcord 0.4.0

What is in 0.4.0

No changelog entry was written for this version.

Compare the tags on GitHub to see what changed, and read the standing notes below
before putting it on a host.

Before you update

Update both hosts, one after the other, and finish. Ripcord's failover sequences are encoded
in the binary and they span two hosts, so a pair running two versions would execute half a
sequence written by each. A planned failover and a failback therefore refuse on a version
mismatch rather than warning — which means a pair left half-updated cannot be moved electively.
The window between the two hosts is the one time the tool will not work.

The one exception is failover --scenario unplanned, which runs entirely on the host it is
typed on. There is no half for the other binary to execute, and refusing a disaster failover for
want of a version string the dead host never published would fail at the one thing this tool
exists for.

Do it when nothing is on fire, not during an incident.

Verify what you are installing

There is no Authenticode signature yet; it needs a paid certificate. Until then the SHA-256
checksum published beside the binary is the only way to tell that the file on the host is the
file that was built. Check it before replacing anything.

(Get-FileHash ripcord.exe -Algorithm SHA256).Hash.ToLower()

Updating

ripcord update installs a newer release on the host it is run on. It is off unless
updates.install says so, it asks for the node name to be typed, and it refuses any release
whose detached signature does not verify against the key compiled into the running binary.
Copying the .exe by hand still works and is still supported; fully offline operation stays
possible.

This reverses what earlier versions of this file said. The objection was sound and has not gone
away: a binary that replaces itself, with Hyper-V privileges, on both hosts of a disaster
recovery pair, from the internet, is a supply chain reaching past the controls the rest of the
tool is built around. What changed is that the path now has a trust root that is not the release
page — the signature is checked against a pinned key, and an unverifiable release is refused
before anything is touched. What has not changed is that the signing key lives in the
release workflow, so an account with write access to the repository can still sign; see
SECURITY.md.

Update one host at a time, and update both. While the two differ, a failover spanning them
is refused — the sequences are encoded in the binary and one executed half by each version is
the error nobody recovers from at 3 a.m. The command says which host to run next.

The full procedure is in docs/RELEASING.md.

ripcord 0.3.0

What is in 0.3.0

No changelog entry was written for this version.

Compare the tags on GitHub to see what changed, and read the standing notes below
before putting it on a host.

Before you update

Update both hosts, one after the other, and finish. Ripcord's failover sequences are encoded
in the binary and they span two hosts, so a pair running two versions would execute half a
sequence written by each. A planned failover and a failback therefore refuse on a version
mismatch rather than warning — which means a pair left half-updated cannot be moved electively.
The window between the two hosts is the one time the tool will not work.

The one exception is failover --scenario unplanned, which runs entirely on the host it is
typed on. There is no half for the other binary to execute, and refusing a disaster failover for
want of a version string the dead host never published would fail at the one thing this tool
exists for.

Do it when nothing is on fire, not during an incident.

Verify what you are installing

There is no Authenticode signature yet; it needs a paid certificate. Until then the SHA-256
checksum published beside the binary is the only way to tell that the file on the host is the
file that was built. Check it before replacing anything.

(Get-FileHash ripcord.exe -Algorithm SHA256).Hash.ToLower()

Updating

ripcord update installs a newer release on the host it is run on. It is off unless
updates.install says so, it asks for the node name to be typed, and it refuses any release
whose detached signature does not verify against the key compiled into the running binary.
Copying the .exe by hand still works and is still supported; fully offline operation stays
possible.

This reverses what earlier versions of this file said. The objection was sound and has not gone
away: a binary that replaces itself, with Hyper-V privileges, on both hosts of a disaster
recovery pair, from the internet, is a supply chain reaching past the controls the rest of the
tool is built around. What changed is that the path now has a trust root that is not the release
page — the signature is checked against a pinned key, and an unverifiable release is refused
before anything is touched. What has not changed is that the signing key lives in the
release workflow, so an account with write access to the repository can still sign; see
SECURITY.md.

Update one host at a time, and update both. While the two differ, a failover spanning them
is refused — the sequences are encoded in the binary and one executed half by each version is
the error nobody recovers from at 3 a.m. The command says which host to run next.

The full procedure is in docs/RELEASING.md.