bosh-release 283.1.7 tarball packages s3cli 0.0.435 despite blobs.yml listing 0.0.436

The bosh-release-283.1.7.tgz final release tarball contains the s3cli 0.0.435 binary inside its s3cli package, even though config/blobs.yml at the v283.1.7 tag references s3cli 0.0.436. This causes broken presigned URL generation with S3-compatible blobstores (AWS S3, Ceph/RadosGW) and results in HTTP 403 errors when compilation VMs try to download package blobs.

Root Cause

The config/blobs.yml blob bump commit (8daacb2c, Aug 29 11:10 UTC) updated the registry entry from s3cli-0.0.435 to s3cli-0.0.436, but the final release was cut at 18:38 UTC the same day (88a2e714) without syncing the new blob to the pipeline worker's local blobs/ directory. The packaged binary still carries the 0.0.435 filename and SHA.

SHA evidence:

The file inside the tarball is even named s3cli-0.0.435-linux-amd64.

Reproduction

# Extract s3cli from the published tarball
mkdir -p /tmp/s3cli-check
tar xzO -f bosh-release-283.1.7.tgz packages/s3cli.tgz | tar xz -C /tmp/s3cli-check

# Confirm version
/tmp/s3cli-check/s3cli/s3cli-0.0.435-linux-amd64 -v
# → version 0.0.435

# Confirm SHA matches 0.0.435, not 0.0.436
sha256sum /tmp/s3cli-check/s3cli/s3cli-0.0.435-linux-amd64
# → 821e2b88d3beaaf4c41bb20ca03da0589bec98bcb1722d45dc29d69074b559ac

Relevant commits

• 8daacb2c — "Updating blob s3cli/s3cli-0.0.435-linux-amd64 -> s3cli/s3cli-0.0.436-linux-amd64" (Aug 29, 11:10 UTC)
• 88a2e714 — "Final release 283.1.7" (Aug 29, 18:38 UTC)

Questions / Investigation

1. Why did the final release pipeline not sync blobs before running bosh create-release --final? Was the blob sync step skipped, failed silently, or not part of the pipeline at all?
2. Should the pipeline verify that the SHA of each packaged blob matches config/blobs.yml before publishing a final release tarball?
3. Is there an existing guard against this class of packaging regression?

Start with config/blobs.yml at the v283.1.7 tag, the blob bump commit 8daacb2c, and the final release commit 88a2e714. Reproduce the mismatch with the tar commands and SHA checks in the issue, then trace the release pipeline around bosh create-release --final. Done means the sync failure or omission is explained and an appropriate pre-publish verification or guard is identified.