Problem

main is red on the Windows test lane.
PR #6129 / #5981 (passkey, WebAuthn) added webauthn-rs, which pulls in webauthn-rs-core and through it the native openssl-sys crate.
On the Windows MSVC CI runners there is no discoverable system OpenSSL and the vendored build was not enabled, so the workspace test build fails with:

Could not find directory of OpenSSL installation, and this -sys crate cannot proceed.

Linux and macOS runners ship a probed system OpenSSL, so they are unaffected — the failure is Windows-only.
Failing run: https://github.com/librefang/librefang/actions/runs/27675199468

Fix

Add a cfg(windows)-gated dependency to crates/librefang-api/Cargo.toml that enables the vendored OpenSSL build:

[target.'cfg(windows)'.dependencies]
openssl = { version = "0.10", features = ["vendored"] }

Cargo feature-unification then makes openssl-sys build from vendored source on Windows only.
Unix targets keep using the fast system library already present in CI — the cfg(windows) gate means nothing changes for Linux/macOS.
The dependency is added to the existing [target.'cfg(windows)'.dependencies] table (which already carries windows-sys), not a duplicate table.
version = "0.10" matches the openssl 0.10.81 already resolved in Cargo.lock.

Why no NASM / Perl setup step

The vendored builder is openssl-src. It auto-detects whether nasm.exe is on PATH: if present it enables the assembly routines, if absent it configures no-asm and builds without them rather than failing (OPENSSL_RUST_USE_NASM left unset → auto-detect).
So the absence of NASM on the GitHub Windows runner images is not a build blocker.
Both windows-2022 and windows-2025 runner images ship Perl (5.32.1 / 5.42.0), which is the only host prerequisite the vendored build actually needs.
This keeps the change to a single line — no new CI install step. (I verified the test-windows job in .github/workflows/ci.yml has no existing nasm/perl setup step and confirmed against the actions/runner-images readmes that Perl is preinstalled and NASM is not.)

Changes

• crates/librefang-api/Cargo.toml: add cfg(windows)-gated openssl = { version = "0.10", features = ["vendored"] } with an explanatory comment.
• Cargo.lock: regenerated — adds openssl-src 300.6.1+3.6.3 as a dependency of openssl-sys, and openssl as a direct dep of librefang-api. The lockfile is target-agnostic, so the cfg(windows) dep resolves and locks even on a Linux host.
• CHANGELOG.md: one ### Fixed bullet under [Unreleased].
• .secrets.baseline: line-number refresh emitted by the detect-secrets pre-commit hook (an existing already-baselined CHANGELOG entry shifted down 6 lines); no new secret.

Verification

This host has no native cargo, so verification ran through the repo's sanctioned librefang-rust-dev Docker image (Linux), using a per-worktree target volume + the shared download volume, exactly as CLAUDE.md (“Verifying without a native toolchain”) prescribes:

docker build -t librefang-rust-dev:latest -f Dockerfile.rust-dev .

WORKTREE="$(git rev-parse --show-toplevel)"
TARGET_VOL="librefang-target-$(basename "$WORKTREE")"
docker run --rm \
  -v "$WORKTREE":/work \
  -v librefang-cargo:/cargo -v "$TARGET_VOL":/target \
  -e CARGO_HOME=/cargo -e CARGO_TARGET_DIR=/target -w /work \
  librefang-rust-dev:latest \
  sh -c 'export PATH=/usr/local/cargo/bin:$PATH; cargo check -p librefang-api'
# → Finished `dev` profile in 1m 12s (updated Cargo.lock with openssl-src)

Results:

• cargo check -p librefang-api — clean (Finished in ~1m12s); this regenerated Cargo.lock.
• cargo check -p librefang-api --locked — clean, no further lockfile changes (Finished in 0.26s), confirming Cargo.lock is --locked-clean.
• cargo check --workspace --lib --locked — clean (Finished in ~1m05s).

No .rs files were touched, so cargo fmt was not required.

The container is Linux-only and cannot compile the cfg(windows) branch, so it does not itself exercise the vendored OpenSSL build — but the lockfile resolution above proves the dependency graph is correct, and the fix is the standard MSVC remedy for an openssl-sys link failure.

CI nuance

The Windows test lane (test-windows in .github/workflows/ci.yml) runs only on push to main and in the merge queue (github.event_name == 'push' || 'merge_group') — it does not run on pull requests, and there is no workflow_dispatch or label to trigger it on a PR.
So this PR's own CI will not exercise Windows.
If the repo merges through a merge queue, the merge_group event will run the Windows job before this lands on main; otherwise the first Windows validation happens on the post-merge main push.
Either way the fix is the canonical vendored-OpenSSL remedy and has been validated by dependency-graph resolution + the Docker Linux checks above.

Closes #6161.