turbo

600bdf96 - feat: Add `futureFlags.longerSignatureKey` to enforce minimum HMAC key length (#12142)

feat: Add `futureFlags.longerSignatureKey` to enforce minimum HMAC key length (#12142) ## Summary - Adds a new `futureFlags.longerSignatureKey` flag that enforces a minimum 32-byte length for `TURBO_REMOTE_CACHE_SIGNATURE_KEY` when `remoteCache.signature` is enabled - Without the flag, short keys emit a warning; with it, the run fails immediately - This will become the default behavior in the next major version ## Why HMAC-SHA256 accepts any key length, but keys shorter than 32 bytes significantly weaken the signature, making brute-force tag collision feasible. Today, there's no guardrail — users can sign artifacts with a 3-character key and get a false sense of security. This future flag lets teams opt into the stricter requirement now, and documents the intent to enforce it by default in the next major. To be clear, this signature being too short doesn't expose the Remote Cache to unauthenticated access. This signature is used for **artifact integrity**, meaning a short signature makes it easier for something like a partial upload to accidentally slip by. A longer signature makes it harder for your Remote Cache to mistakenly allow an artifact to be used that shouldn't pass integrity checks. This is an extreme edge case. `TURBO_REMOTE_CACHE_SIGNATURE_KEY` becomes an input to hashing, so even a short key changes the hash. We have no reason to believe that a short key or a long key makes a difference. Still, this **is** an HMAC-SHA256 key and we want to raise our quality bar, and ensure we enforce a safe length according to that spec. ## Testing - Unit tests on `ArtifactSignatureAuthenticator::validate_key_length` for short, exact-32, and long keys - Integration tests on `HTTPCache::new` verifying enforcement rejects short keys, non-enforcement allows them, and valid keys pass - Deserialization test for the new `longerSignatureKey` future flag in turbo.json