🤖
## Summary
On 2026-10-23, RustSec published RUSTSEC-2026-0385 against `ctutils`, a
constant-time helper crate used by the RustCrypto hashing and HMAC
crates. Some of its functions were meant to run in constant time, so
their timing would reveal nothing about secret values, but in versions
before 0.4.4 they could compile to code that branches on those values.
Since the advisory came out, `cargo-deny check` reports advisories as
failed. That breaks `Security Domain / Security` on `main` and on every
PR that runs the Rust security job.
This PR changes `ctutils` from 0.4.2 to 0.4.5 in the three lockfiles
that pin it: `Cargo.lock`, `desktop/src-tauri/Cargo.lock`, and the
`buzz-feature-flags` relay-feature-selection test fixture. No other
packages change.
| Advisory | Crate | Change |
|---|---|---|
| [RUSTSEC-2026-0385](https://rustsec.org/advisories/RUSTSEC-2026-0385)
| `ctutils` (non-constant-time mask generation and `u128` comparisons) |
0.4.2 → 0.4.5 |
### Related issue
N/A. I searched open and closed PRs for `ctutils` and
`RUSTSEC-2026-0385` and found none.
### Testing
- `cargo deny check advisories`: `advisories ok`. On `origin/main` the
Security job fails on this advisory.
- `cargo check --workspace` passes.
- `cargo test -p buzz-feature-flags --test
relay_feature_selection_contract` passes. This test compiles the fixture
with `--locked`.
- The pre-push hook's Rust and Tauri lanes pass.
Signed-off-by: Logan Johnson <loganj@squareup.com>
Co-authored-by: Larry <627498bd4bd1f281a16431e3c6cce3b5c25b6692798c78672298aefbf2f8f8b5@buzz.block.builderlab.xyz>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
## Why
Buzz server components need one typed feature-flag contract without
forcing the open-source build to depend on LaunchDarkly. A staging or
production relay must not be able to choose the wrong provider through
runtime configuration.
## What
- Adds typed boolean and signed `i64` flags with static, environment,
and compile-gated LaunchDarkly evaluators.
- Defines an executable relay artifact contract that compiles exactly
one provider.
- Rejects zero or multiple relay provider features at compile time.
- Runs the LaunchDarkly feature tests and the provider compile matrix in
the unit CI lane and fallback test script.
## How
`buzz-feature-flags` stays provider-neutral. The future relay
composition root will expose one build path per artifact feature:
`static-feature-flags`, `environment-feature-flags`, or
`launchdarkly-feature-flags`. Runtime configuration carries only
settings for the selected provider. It never carries a provider name,
fallback, or precedence rule.
The crate still has no relay consumer. A locked compile fixture proves
each singleton builds and every zero or multi-provider combination fails
until the relay adopts this contract.
This removes the proposed runtime `ProviderMode` and leaves one
provider, one construction path, and one evaluator per artifact.
## Risk
This PR still has no relay or app consumer, so it changes no
user-visible behavior. Risk is limited to the new feature-flag crate,
its compile contract, and its unit-test lane.
## Testing
An external Rust consumer at `30cf968bfe85e82980fda7e63f5bebe649ca939f`
exercised six environment-evaluator scenarios and 59 assertions. The
compile-time correction adds no live consumer to exercise manually.
## Bigger picture
When `buzz-relay` adopts this crate, its build manifests must map each
distribution to one provider feature. That consumer PR must verify live
Relay Proxy reachability, secret ingestion, lifecycle ownership, and
user-visible behavior.
Generated with Codex
---------
Signed-off-by: tornquist <tornquist@squareup.com>
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
