Greptile Summary

This PR adds x86_64-unknown-linux-musl and aarch64-unknown-linux-musl targets to the release matrix and gates the FIDO2 provider behind cfg(not(target_env = "musl")) throughout the codebase, since ctap-hid-fido2 → hidapi → libudev cannot be statically linked on musl.

The implementation is thorough: the Cargo dependency is conditioned via [target.'cfg(...)'.dependencies], the build script skips fido2.toml on musl using CARGO_CFG_TARGET_ENV, the ProviderType::Fido2 variant and its match arm in add.rs are both cfg-gated, the fido2 module is conditionally compiled out of src/providers/mod.rs, and the test in mod.rs mirrors the exclusion with cfg!(). The previous thread concern about Cross.toml missing musl entries is moot because libudev is no longer a dependency on musl at all.

Confidence Score: 5/5

Safe to merge — all cfg-gates are consistent across Cargo.toml, build script, source, and tests; no outstanding issues remain.

No P0 or P1 issues found. The fido2 exclusion is applied consistently in every required location (dependency declaration, build codegen, provider module, CLI enum variant, match arm, and test). The previous thread's Cross.toml concern is resolved because libudev is no longer pulled in on musl. The test fix using cfg!() is a compile-time evaluation, which is correct.

No files require special attention.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Release Matrix] --> B{target_env}
    B -->|gnu| C[x86_64/aarch64-linux-gnu\ncross + libudev-dev via Cross.toml]
    B -->|musl| D[x86_64/aarch64-linux-musl\ncross, no libudev needed]

    D --> E{build/generate_providers.rs\nCARGO_CFG_TARGET_ENV == musl?}
    E -->|yes| F[Skip fido2.toml\nGenerate providers without FIDO2]
    E -->|no| G[Include fido2.toml\nGenerate all providers]

    F --> H[Cargo.toml\ncfg-not-musl dep:\nctap-hid-fido2 excluded]
    F --> I[src/providers/mod.rs\ncfg-gate: pub mod fido2 excluded]
    F --> J[src/commands/provider/mod.rs\ncfg-gate: ProviderType::Fido2 excluded]
    F --> K[src/commands/provider/add.rs\ncfg-gate: Fido2 match arm excluded]

    G --> L[All providers compiled\nincluding FIDO2]

_{Reviews (3): Last reviewed commit: "test(musl): exclude fido2 from provider/..." | Re-trigger Greptile}

Addressed Greptile P1: musl builds now exclude the fido2 provider so they don't pull ctap-hid-fido2 → hidapi → libudev (which can't be statically linked into a musl binary — apt-installing libudev-dev in a cross musl image links the glibc variant).

Changes in 3e0c397:

• Cargo.toml: moved ctap-hid-fido2 to [target.'cfg(not(target_env = "musl"))'.dependencies]
• src/providers/mod.rs: gated pub mod fido2; and the fido2 import
• src/commands/provider/{mod.rs,add.rs}: gated ProviderType::Fido2 variant and its match arm
• build/generate_providers.rs: skip providers/fido2.toml when CARGO_CFG_TARGET_ENV=musl so the generated ProviderConfig enum and dispatch tables don't reference it

Verified locally:

$ cargo tree --target x86_64-unknown-linux-musl --prefix none | grep -E 'ctap|hidapi|udev'
(no matches)

$ cargo tree --target x86_64-unknown-linux-gnu --prefix none | grep -E 'ctap|hidapi|udev'
ctap-hid-fido2 v3.5.9
hidapi v2.6.5

So musl builds shouldn't need the libudev pre-build step that the gnu targets use. No Cross.toml change required for the new musl entries.

Trade-off: musl binaries won't have the fido2 provider. That seems acceptable since musl/Alpine deployments are typically headless containers without USB hardware-key access; users who need fido2 on musl can build from source on a glibc host or wait for a future libusb-static backend.

Re Gemini's review — those comments are reviewing the stale chore: add communique 1.0.1 commit that was on the branch base before I rebased onto current main. The current diff on the PR is just the release.yml matrix change + the fido2 gating. Re-running the review should clear those.