Backport sha256 verification for yq download in functional-tests.yml

[fullsend-ai-retro]

What happened

On PR #80, the author added sha256 verification to the yq install step in script-test.yml (commit ee103ac) after the fullsend review agent flagged the missing verification on the second review pass. The third review (run 29048848209) then noted that functional-tests.yml (lines 140-144) downloads the same yq binary without sha256 verification, creating an inconsistency.

The author acknowledged this as out-of-scope: "Out of scope for this PR — we'll pick it up in a follow-up."

Existing issue #77 covers hardening binary installations in functional-tests.yml broadly (fullsend CLI and OpenShell), but does not specifically mention the yq download at lines 143-144.

What could go better

The yq download in functional-tests.yml is the same binary, same version, same pattern — but without the sha256 verification that script-test.yml now has. This inconsistency means one workflow is hardened against supply-chain tampering while the other (which runs with GCP credentials and GitHub tokens) is not. The more sensitive workflow is the one lacking verification.

Confidence: High. The maintainer explicitly acknowledged this as a follow-up item, the fix is trivial (add the same sha256sum line), and the inconsistency is clear.

Proposed change

In .github/workflows/functional-tests.yml, add sha256 verification to the Install yq step (lines 140-144). Change:

- name: Install yq
  if: steps.changes.outputs.relevant != 'false'
  run: |
    curl -sSfL "https://github.com/mikefarah/yq/releases/download/v4.47.1/yq_linux_amd64" -o /usr/local/bin/yq
    chmod +x /usr/local/bin/yq

To:

- name: Install yq
  if: steps.changes.outputs.relevant != 'false'
  run: |
    curl -sSfL "https://github.com/mikefarah/yq/releases/download/v4.47.1/yq_linux_amd64" -o /usr/local/bin/yq
    echo "0fb28c6680193c41b364193d0c0fc4a03177aecde51cfc04d506b1517158c2fb  /usr/local/bin/yq" | sha256sum -c
    chmod +x /usr/local/bin/yq

This can be done as part of issue #77 or as a standalone change. The sha256 hash is the same value already verified in script-test.yml.

Validation criteria

After the change: (1) functional-tests.yml yq install step includes sha256 verification matching script-test.yml. (2) The functional-tests workflow continues to pass on main branch. (3) Both workflows use identical yq version and hash, eliminating the inconsistency flagged in the third review of PR #80.

---

Generated by retro agent from #80

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 9:25 PM UTC · Completed 9:27 PM UTC
Commit: e8381e3 · View workflow run →

[fullsend-ai-triage]

Triage Summary

Severity: Medium · Category: Security (supply-chain hardening)

Problem

The Install yq step in .github/workflows/functional-tests.yml downloads yq v4.47.1 without sha256 verification, while the same download in script-test.yml already includes it (added in PR #80). The functional-tests workflow is the more sensitive of the two — it runs with GCP credentials and GitHub tokens — yet it lacks the verification.

Root Cause

When sha256 verification was added to script-test.yml in PR #80, the same fix was not applied to functional-tests.yml. The PR author acknowledged this as out-of-scope for that PR.

Recommended Fix

Add the sha256sum verification line to the Install yq step in functional-tests.yml, between the curl and chmod lines:

echo "0fb28c6680193c41b364193d0c0fc4a03177aecde51cfc04d506b1517158c2fb  /usr/local/bin/yq" | sha256sum -c

This is a one-line change using the same hash already verified in script-test.yml.

Proposed Test

1. Verify functional-tests.yml yq install step includes sha256sum -c
   with hash 0fb28c6680193c41b364193d0c0fc4a03177aecde51cfc04d506b1517158c2fb
2. Verify the hash matches the one in script-test.yml (consistency)
3. Run functional-tests workflow → should pass with verification
4. Temporarily alter the hash → step should fail with checksum mismatch

Related Issues

• Issue Harden external binary installations in functional-tests CI workflow #77 covers hardening fullsend CLI and OpenShell binary installations in the same workflow. The yq fix can be done standalone or combined with Harden external binary installations in functional-tests CI workflow #77.
• PR fix(ci): persist fullsend version and validate before use #90 also modifies functional-tests.yml (version persistence) but does not touch the yq install step — no conflict expected.

---

Labels: This is a triaged security hardening issue. Remove ready-for-triage since triage is complete, and add triaged label.

[fullsend-ai-prioritize]

RICE Priority Score: 5.4

Score breakdown

Dimension	Score	Reasoning
Reach	1.5	This affects the functional-tests CI workflow which runs with GCP credentials and GitHub tokens — a supply-chain compromise here could impact all contributors and downstream users of the project. Scored at 1.5 because the security exposure is project-wide infrastructure, though the probability of exploitation is low.
Impact	1	Medium impact — this is a preventive security hardening measure that closes a real inconsistency between two workflows. It doesn't fix an active problem but hardens the more sensitive workflow (the one with cloud credentials) against supply-chain tampering. A workaround doesn't really apply since this is about preventing a potential future attack.
Confidence	0.9	Very high confidence. The issue is extremely well-described with exact file, line numbers, and the complete fix. The maintainer explicitly acknowledged it as a follow-up item in PR #80. The scope is unambiguous — one line in one file using an already-known hash.
Effort	0.25	Trivial — this is a single-line addition of a sha256sum check between existing curl and chmod lines, using the exact hash already verified in script-test.yml. The fix is fully specified in the issue body.

Formula: (1.5 x 1 x 0.9) / 0.25 = 5.4