Use “Verify an inbound artifact” in Recued. Run every applicable check against a file on disk — version fingerprint against the sender's published checksum, a detached Minisign signature against a public key you already hold, archive integrity, and a member listing — and record each result separately.
Verify an inbound artifact
Use “Verify an inbound artifact” in Recued. Run every applicable check against a file on disk — version fingerprint against the sender's published checksum, a detached Minisign signature against a public key you already hold, archive integrity, and a member listing — and record each result separately.
Complete workflow
Use Inbound Artifact Verification in Recued for signature, checksum, minisign, and integrity. It includes 8 built-in actions and 3 ready-to-run workflows. Actions that change data use Recued's approval controls.
You are viewing one recipe in this workflow. Installing it opens the complete pack so its other recipes and background automations arrive together.
Use “Register an inbound artifact” in Recued. Record a file you have received so it can be verified. Keyed on its path, so re-registering the same file converges on the same row instead of creating a second one.
Use “Show artifact verifications” in Recued. List received artifacts with each check's result shown separately. It reads information without changing data in the connected service.
Use “Records runtime” in Recued. It helps you complete this workflow using the connections and settings you choose.
Why the checks are PREFETCH steps
⛔⛔ This is the whole design, and it is not stylistic. Every one of these tools reports failure the same way: a non-zero exit. signature.verify, file.test_gzip and archive.list_tar are all exit_code_handling: zero_is_success with no captured output — so a failed check is a failed step. And a failed sequential step ends the run (errors.push(log.error); break;), which would mean a recipe whose entire job is to record a failure could never record one.
optional: true — the flag that turns a step failure into a null result and lets the run continue — is honoured only in prefetch (prefetch.ts:232; the sequential runner has no equivalent). So the checks run as optional prefetch steps, and the sequential half reads which ones survived.
⚠ Prefetch steps run in PARALLEL and cannot read each other, so every check takes its inputs from {{config.*}} — never from another step. That is why you pass the path, the signature and the key here rather than having the recipe read them off the artifact row.
Reading the result
⚠ A skipped check and a failed check both land as null. They are told apart by whether the check was APPLICABLE, which is computed from your config: Archive kind decides whether the listing and integrity checks apply, and a blank Signature file means no signature check was asked for. A check that was applicable and came back null is a failure; one that was never applicable is reported as not-run. The card shows both counts separately.
⚠ verified requires every applicable check to pass AND at least one to have run. An artifact with no checksum, no signature and no archive kind runs zero checks and is recorded failed with a note — because "nothing was checked" must never read as "nothing was wrong".
⛔ Digests are compared case-insensitively but exactly. Paste the sender's checksum whole; a truncated prefix will not match and is not treated as a partial pass.
⚠ This reads a path on your disk that you name. The ops are read-only — digest, verify, test, list — and none of them extracts, writes or executes anything. Nothing is uploaded.
How it works
Inspect the data fetches, transforms, gates, and output this recipe runs.
Settings
Configurable at install. Defaults shown — change them anytime in Recued.
kind
setting
=
file
path
setting
=
public key
setting
=
artifact id
setting
=
[object Object]
signature path
setting
=
expected sha256
setting
=