Skip to content

1.2.0

Latest
Latest

Choose a tag to compare

View all tags
@vreff vreff released this 30 Jul 21:03
1.2.0
96f4d47
This commit was signed with the committer’s verified signature.
vreff
SSH Key Fingerprint: pHHB4BknjhKposMJ2Ku6xo2cyA9p2ifsKRJfXE3PhjM
Verified
Learn about vigilant mode.

Enclave measurements for this release can be seen here: https://github.com/smartcontractkit/chainlink-confidential-compute/actions/runs/30637617319

Built from 96f4d477 on release/1.2.0 — main @ e7862afc plus a cherry-pick of #31. Capability go.mod files are pinned to v0.0.0-20260730202721-e7862afc469d. Images are tagged sha-96f4d47.

Note: the measurements below supersede those published earlier for 2d6fd4e9. If you already trusted the 2d6fd4e9 values, they must be replaced.

Highlights

ARM64 enclave support (#23)

nitro-enclave (confidential-http) and nitro-workflows (confidential-workflows) are now built and published as multi-arch images for both linux/amd64 and linux/arm64. This adds a second set of PCR measurements per app — see the tables below, and note that measurements are architecture-specific.

  • wireguard-go-vsock is now shipped per-architecture as wireguard-go-vsock-amd64 and wireguard-go-vsock-arm64
  • New enclave/nitro/nitro-cli/Dockerfile for cross-arch EIF builds
  • New CI helpers .github/scripts/build-eif.sh and .github/scripts/push-multiarch-image.sh

Disable connection reuse on the gateway client (#31)

The enclave→gateway HTTP client previously used Go's default transport, which pools idle connections indefinitely. It now uses a cloned transport with DisableKeepAlives, opening a fresh connection per request.

The problem being addressed: sparse requests over a long-pooled idle connection tend to find it already closed server-side, producing a bare EOF on POSTs, which Go will not auto-retry. The gateway path (dynamic secrets and capability calls) is exactly that low-traffic pattern.

The commit also drops a DisableKeepAlives override from the workflow-facing httpfetch.Fetcher. That is a redundancy cleanup, not a behavior change — util.NewRestrictedHTTPClient has disabled keepalives centrally since a45eedcc (shipped in 1.1.0), because that client is shared across workflows and connection reuse would carry TCP/TLS and server-side connection state across workflow boundaries. Outbound workflow HTTP was, and remains, unpooled.

Settings consolidation

  • cresettings is now the sole source of truth for workflow settings; job-spec overrides have been removed (#29)
  • Four new injected settings on WorkflowSettings (#30):
    • requestTimeout — global in-enclave request timeout, default deadline for outbound workflow HTTP
    • gatewayRequestTimeout — HTTP client timeout for enclave→gateway requests (dynamic secrets + capability calls)
    • executionTimeout — wall-clock bound on a single WASM execution, capping how long a runaway workflow holds a bounded execution slot
    • workflowGracePeriod — delay before a validated execution starts running; defaults to 2s, negative disables
  • Updated BFT settings (#25)

Dependencies

  • Bumped the chainlink dependency (#28)
  • Bumped the legacy enclave version (#26)

Repo hygiene

  • Removed the scripts/ and runbooks/ directories (#27)

PCR Measurements

Both architectures must be trusted for a given capability, or attestation fails for pods scheduled on the architecture that was left out.

confidential-http (nitro-enclave)

linux/amd64
PCR0 4024f7f7d75e935a82ad23e64ec1db1d43c312306c6f59becc4b4d4af6d9da6e2fe7cd3af16ed4bc98e88268fae6afaf
PCR1 4b4d5b3661b3efc12920900c80e126e4ce783c522de6c02a2a5bf7af3a2b9327b86776f188e4be1c1c404a129dbda493
PCR2 f6628e8043e98125c201f5c3ec482b41f4ce5d2406c258b00896ea3e7873ec07ebdf659544e4ff68fcc3a2594a2f6b2c

linux/arm64
PCR0 0518d6c24a27fdf39d1595e063fd493ba548b589954a537d73548e70597529f8d675a4b60840648a593500b3871c2ccc
PCR1 3b4a7e1b5f13c5a1000b3ed32ef8995ee13e9876329f9bc72650b918329ef9cf4e2e4d1e1e37375dab0ba56ba0974d03
PCR2 01e4ba191c94856d920af1dc0a25cb777453b87c699e604c2898057dfbbb988ff57e9ad0646cfb5a17aa210d8330bec0

confidential-workflows (nitro-workflows)

linux/amd64
PCR0 4a26252669300d4fb074f013dd27482778d071291fbe14ea057cd735ddf1ad6e5e2f91232de68d6767b6c6800137f602
PCR1 4b4d5b3661b3efc12920900c80e126e4ce783c522de6c02a2a5bf7af3a2b9327b86776f188e4be1c1c404a129dbda493
PCR2 888d30a44e90111f3c87b3f820634788b1ae22867b5adf21d2486b45eb257a4779d0958e51ca8221e363a97e71a589b0

linux/arm64
PCR0 8397c162040a3dabbdb415b319ac9c4603769f08e2b183ed7bb271801e5239c31fe5d396f3aee5a5a5a9e33e2ddcaf3c
PCR1 3b4a7e1b5f13c5a1000b3ed32ef8995ee13e9876329f9bc72650b918329ef9cf4e2e4d1e1e37375dab0ba56ba0974d03
PCR2 39dc0ab2160cd137e0a3df601d1665e47f5e88ca2cb21f51cbde92cd7f3549ad0512bd88573cea692171b0d7b0336dd1

Note that both capabilities' measurements changed relative to 2d6fd4e9, even though #31 only touches confidential-workflows source. This is expected: the enclave Dockerfiles COPY enclave/ ./enclave/, so both enclaves take the whole tree as build context and any source change under it moves both sets. PCR1 is unchanged, as it measures the kernel/bootstrap.

Full diff: 1.1.0...1.2.0

Assets 2
Loading