HotLoop Cascade 1.0.2 release notes

What this is

1.0.2 lets a workflow sign and verify things without a secret ever sitting in item data, and lets a public form on another website call a webhook from the browser. Nothing else changed from 1.0.1.

What is new in the Code step

• Crypto helpers. sha256(text), hmacSHA256(key, text), randomHex(bytes), base64Encode(text), base64Decode(text) and safeEqual(a, b). They are computed in Go, so the answers are the standard library’s, and the script still has no require, no network and no files.
• A credential for the step. The Code step has a secret credential slot. Give it an HMAC key credential (a new built in credential type with one secret field, key) and the script reads it as credential.key. The key lives in the vault like every other secret, and the vault scrubs it from everything the run saves, even if the script returns it. A step with no credential sees an empty credential object.

The reason: a public form checks a proof of work with an HMAC. Before this, the only way to do that in a workflow was to put the key in an item or a variable, and both end up in stored runs or in plain text. Now the key is a credential and the stored run has the signature and nothing else.

What is new on a webhook

• corsOrigins. A webhook trigger takes a list of web origins (https://example.com, or *) whose pages may call it from a browser. Cascade answers the browser’s preflight itself, without starting a run, and adds Access-Control-Allow-Origin to the answer for a listed origin. A webhook that lists none behaves exactly as before: no CORS headers, so a browser page cannot read the answer. An entry has to be an origin, with no path.

What was tested

The full local suite (test/run.sh) did not run for this release. Only the targeted tests ran: the Code step’s helpers and credential (the step, the runner and the vault), the webhook trigger’s CORS settings and preflight, and the catalog and workflow packages, all passing on The Beast. The lab’s MQTT broker would not start on that box.

Upgrading, and going back

No migrations. helm upgrade to 1.0.2, or let :stable roll the Quadlet units. Workflows that never touch the new helpers behave exactly as before, so putting 1.0.1 back is safe for them; a workflow that calls a new helper fails on 1.0.1 with the helper undefined. A backup before any update is still the right habit.