feat: prove basic + sigv4 live end-to-end (publish 0.5.4 + twilio/aws examples)

[FiscalMindset]

What & why

#1 (my own review) flagged that the flagship schemes — Twilio HTTP Basic and AWS SigV4 — were built and unit-tested but never proven live: the enclave still ran the old bearer-only wasm, and there were no live demos. This PR closes that gap.

Changes

• Publish the basic/sigv4-capable contract. Bump CONTRACT_VERSION 0.5.3 → 0.5.4 (Cargo to match) and publish it live (contract id 461). The old 0.5.3 stays registered for rollback. Bearer regression (GitHub, Stripe, Gemini) still 200.
• examples/twilio/ — HTTP Basic proof (no Twilio account needed).
• examples/aws/ — SigV4 proof against real S3.
• integration-stack.md — records both live proofs + the publish/secrets-ACL gotcha.

Proof (live, against the published 0.5.4 enclave)

HTTP Basic (Twilio scheme) — a known password is sealed, the agent sends no credential, the enclave builds base64(user:secret) and httpbin validates it:

BASIC_STATUS 200  { "authenticated": true, "user": "blindfold" }

httpbin returns 200 only if the enclave's base64 is exactly right.

AWS SigV4 — byte-exact unit vectors (get-vanilla + signing-key derivation) plus a live structural probe against real S3 with AWS's example key:

SIGV4_STATUS 403  AWS_CODE InvalidAccessKeyId

AWS parsed our SigV4 header (echoed AWSAccessKeyId=AKIDEXAMPLE) and reached credential lookup — not AuthorizationHeaderMalformed/IncompleteSignature (what a malformed signature yields). A real IAM key → 200.

Operational notes (documented in integration-stack.md)

• Publishing a new contract id resets the secrets-map read ACL (readers: only:[id]) — grantContractReads(newId) must run after every publish, or forward calls fail with cannot read map "…:secrets". Hit and fixed here.
• grant replaces the egress allowlist — grant all hosts in one call.
• Testnet has a per-minute fuel_per_minute quota (surfaces as generic 500s under load).

Notes

• No secrets committed. The dummy httpbin_basic_pass and AWS example key are public test values; real Twilio/AWS demos just re-seal with real creds.

---

Summary by cubic

Publishes the blindfold-proxy 0.5.4 contract to enable live HTTP Basic (Twilio) and AWS SigV4 in the enclave, and adds runnable demos proving both end-to-end. Bearer flows remain unchanged.

• New Features

  • Published contract v0.5.4 (id 461) with basic and sigv4; 0.5.3 kept for rollback; GitHub/Stripe/Gemini still 200.
  • Added examples/twilio/ (HTTP Basic via httpbin, no Twilio account) and examples/aws/ (SigV4 vs real S3, well-formed signature).
  • Updated docs (examples/README.md, integration-stack.md) and bumped CONTRACT_VERSION to 0.5.4.

• Migration

  • After publishing, run grantContractReads(<newId>) to restore secrets-map read ACLs.
  • Re-grant the full egress allowlist in one call (grant replaces, not appends).

^{Written for commit f51dba4. Summary will update on new commits.}

[gitar-bot]

💡 Quality: Contract version left inconsistent across docs/scripts

This PR advances the published contract to 0.5.4 (bumping CONTRACT_VERSION and contract/Cargo.toml, which jumped 0.5.1 → 0.5.4). However several docs and scripts still hardcode older versions: README.md and explain.md reference 0.5.3, and usage.md, current_status.md, scripts/test-v5-release.ts and scripts/grant-and-call.ts reference 0.5.1. Since the PR explicitly documents a publish gotcha (new contract id resets the secrets-map read ACL, requiring grantContractReads(newId)), stale version strings in the operational scripts (scripts/grant-and-call.ts, scripts/test-v5-release.ts) are the most likely to mislead an operator into targeting the wrong contract id. Consider having these scripts derive the version from CONTRACT_VERSION rather than hardcoding it, and update the docs to 0.5.4. This is non-blocking for the examples/demos themselves, which correctly use the shared client and type definitions.

Derive the version from the single source of truth instead of hardcoding it, so scripts stay in sync with future bumps.:

// scripts/grant-and-call.ts / test-v5-release.ts
import { CONTRACT_VERSION } from "../packages/blindfold/src/constants.ts";
// ...use CONTRACT_VERSION instead of the hardcoded "0.5.1" string

• Apply fix

_{Check the box to apply the fix or reply for a change | Was this helpful? React with 👍 / 👎}

[gitar-bot]

Code Review 👍 Approved with suggestions 0 resolved / 1 findings

Publishes contract version 0.5.4 to enable live HTTP Basic and AWS SigV4 support with accompanying end-to-end examples. Ensure consistent version numbering across all documentation and scripts to resolve the minor inconsistency finding.

💡 Quality: Contract version left inconsistent across docs/scripts

📄 contract/Cargo.toml:3 📄 packages/blindfold/src/constants.ts:18

This PR advances the published contract to 0.5.4 (bumping CONTRACT_VERSION and contract/Cargo.toml, which jumped 0.5.1 → 0.5.4). However several docs and scripts still hardcode older versions: README.md and explain.md reference 0.5.3, and usage.md, current_status.md, scripts/test-v5-release.ts and scripts/grant-and-call.ts reference 0.5.1. Since the PR explicitly documents a publish gotcha (new contract id resets the secrets-map read ACL, requiring grantContractReads(newId)), stale version strings in the operational scripts (scripts/grant-and-call.ts, scripts/test-v5-release.ts) are the most likely to mislead an operator into targeting the wrong contract id. Consider having these scripts derive the version from CONTRACT_VERSION rather than hardcoding it, and update the docs to 0.5.4. This is non-blocking for the examples/demos themselves, which correctly use the shared client and type definitions.

Derive the version from the single source of truth instead of hardcoding it, so scripts stay in sync with future bumps.

// scripts/grant-and-call.ts / test-v5-release.ts
import { CONTRACT_VERSION } from "../packages/blindfold/src/constants.ts";
// ...use CONTRACT_VERSION instead of the hardcoded "0.5.1" string

🤖 Prompt for agents

Code Review: Publishes contract version 0.5.4 to enable live HTTP Basic and AWS SigV4 support with accompanying end-to-end examples. Ensure consistent version numbering across all documentation and scripts to resolve the minor inconsistency finding.

1. 💡 Quality: Contract version left inconsistent across docs/scripts
   Files: contract/Cargo.toml:3, packages/blindfold/src/constants.ts:18

   This PR advances the published contract to 0.5.4 (bumping `CONTRACT_VERSION` and `contract/Cargo.toml`, which jumped 0.5.1 → 0.5.4). However several docs and scripts still hardcode older versions: README.md and explain.md reference 0.5.3, and usage.md, current_status.md, scripts/test-v5-release.ts and scripts/grant-and-call.ts reference 0.5.1. Since the PR explicitly documents a publish gotcha (new contract id resets the secrets-map read ACL, requiring `grantContractReads(newId)`), stale version strings in the operational scripts (`scripts/grant-and-call.ts`, `scripts/test-v5-release.ts`) are the most likely to mislead an operator into targeting the wrong contract id. Consider having these scripts derive the version from `CONTRACT_VERSION` rather than hardcoding it, and update the docs to 0.5.4. This is non-blocking for the examples/demos themselves, which correctly use the shared client and type definitions.

   Fix (Derive the version from the single source of truth instead of hardcoding it, so scripts stay in sync with future bumps.):
   // scripts/grant-and-call.ts / test-v5-release.ts
   import { CONTRACT_VERSION } from "../packages/blindfold/src/constants.ts";
   // ...use CONTRACT_VERSION instead of the hardcoded "0.5.1" string

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}