vaultwarden/issues/FEASIBILITY-WEBAUTHN-WEBPKI.md

Feasibility report: webauthn-rs (MPL-2.0) and webpki-roots (CDLA-Permissive-2.0)

Date: 2025-11-09 Branch: remediations/audit-2025-11-09

Summary

This short report captures the dependency graph findings and remediation options for the two license clusters discovered by cargo-deny:

• webauthn-rs family (webauthn-rs, webauthn-rs-core, webauthn-rs-proto, webauthn-attestation-ca) — license: MPL-2.0
• webpki-roots — license: CDLA-Permissive-2.0 (pulled transitively via reqwest / hyper-rustls in our graph)

Reverse-dependency findings (what pulled them into the workspace)

• webauthn-rs v0.5.3 is a direct dependency in Cargo.toml (we use features: danger-allow-state-serialisation, danger-credential-internals).

  • Reverse deps: webauthn-rs v0.5.3 -> vaultwarden v1.0.0 (direct)

• webpki-roots v1.0.3 is transitive via the HTTP/TLS stack:

  • webpki-roots v1.0.3 -> hyper-rustls v0.27.7 -> reqwest v0.12.24 -> openidconnect v4.0.1 -> vaultwarden v1.0.0
  • reqwest is also used in other paths (opendal, yubico-ng, etc.) so webpki-roots appears multiple times transitively.

Feasibility and remediation options (short)

For each cluster below I list pragmatic options, effort estimate, and recommended next action.

1. webauthn-rs (MPL-2.0)

Options:

• Upgrade: check whether webauthn-rs publishes a newer version with a different license. If a newer release exists that uses a more permissive license (or is relicensed), upgrade and test. Effort: low-to-moderate (run cargo update -p webauthn-rs and run tests; review any breaking API/behaviour changes).
• Replace: adopt an alternative WebAuthn crate or implement minimal functionality in-house. Effort: medium-to-high depending on coverage and features used (we currently enable two non-trivial features).
• Vendor / shim: vendor the needed logic into the repo (or a small wrapper using a different crypto backend) and maintain it as in-tree or as a local crate. Effort: medium; maintenance burden shifts to the project.
• Per-crate exception: timeboxed exception for webauthn-rs* in deny.toml. Effort: trivial config change but increases audit scope (temporary).

Likelihood / comments:

• Because webauthn-rs is a direct dependency and we enable special features for state/credential internals, replacing it may be disruptive.
• First attempt should be: verify upstream for newer versions (minor patch/feature releases), test upgrade locally, and evaluate behavior differences.

Recommended immediate action for webauthn-rs:

• Run cargo search / check crates.io for webauthn-rs releases (manual step / maintainers action).
• Locally try cargo update -p webauthn-rs then run the test suite and exercise WebAuthn flows.
• If upgrade is not available or disruptive, open a narrow, documented, timeboxed per-crate exception for the webauthn-rs family while planning a replacement path.

2. webpki-roots (CDLA-Permissive-2.0)

Options:

• Swap TLS backend or reqwest features: reqwest supports multiple TLS backends (rustls vs native-tls) and root-store options (webpki-roots vs system roots). Switching to native-tls or rustls variant with system roots might eliminate the webpki-roots dependency.
• Upgrade reqwest / hyper-rustls: newer versions may use different transitive root crates; attempt cargo update -p reqwest and cargo update -p hyper-rustls and test.
• Replace or vendor: if a dependency requires webpki-roots specifically and cannot be changed, consider an explicit per-crate exception or select alternative upstream crates that avoid CDLA.

Likelihood / comments:

• Because webpki-roots is pulled in by reqwest/hyper-rustls, a small change in reqwest features (switching to native-tls) or upgrading reqwest often avoids webpki-roots. This is generally low-to-moderate effort.

Recommended immediate action for webpki-roots:

• Try switching reqwest features (in Cargo.toml) to use native-tls (or system roots) and run cargo update and the test suite.
• Alternatively, try cargo update -p reqwest and cargo update -p hyper-rustls to bring in newer upstream transitive changes, then re-run cargo-deny.

Commands to try (local dev / CI experimentation)

In a branch / local dev container

1) Try upgrading webauthn-rs

cargo update -p webauthn-rs cargo test

2) Try upgrading reqwest/hyper-rustls

cargo update -p reqwest cargo update -p hyper-rustls cargo test

3) Try switching reqwest TLS features to native-tls (edit Cargo.toml):

reqwest = { version = "0.12.24", features = ["native-tls", "stream", "json", ...], default-features = false }

cargo update cargo test

4) Re-run the audit after any change

(inside audit container or CI) - this verifies cargo-deny results

/usr/local/cargo/bin/cargo-deny --manifest-path Cargo.toml check licenses --format json

Risk assessment & policy suggestion

• Short-term: a documented, timeboxed, per-crate exception for the webauthn-rs family and/or webpki-roots is acceptable to unblock CI while we attempt upgrades. However, because webauthn-rs is a direct dependency and non-trivial, invest effort to try an upgrade/replacement within a short timeline (30-90 days).
• Medium-term: prefer dependency upgrades or swapping reqwest TLS options over perpetual exceptions. Upgrades reduce maintenance debt and long-term audit risk.

Deliverables included with this report

• Reverse dependency outputs captured in docker/audit/output/webauthn-tree.txt and docker/audit/output/webpki-tree.txt.
• License triage CSV: docker/audit/output/license_triage_2025-11-09.csv.
• Recommended commands and next steps (above).

If you want, I can attempt the low-risk experiments now:

• Try cargo update -p reqwest and re-run cargo-deny (low effort, downloads crates), or
• Try cargo update -p webauthn-rs and run test suite (may require exercising WebAuthn flows).

Next suggested step

Run the quick experiment: upgrade reqwest (and hyper-rustls) in a temporary branch, re-run cargo-deny and tests, and report the results. This often removes webpki-roots without deeper changes.

Experiment results (2025-11-10)

Summary of actions run in a temporary experiment branch and container:

• Performed cargo search webauthn-rs inside the audit container; crates.io shows webauthn-rs = "0.5.3" as the current published version in that namespace (search results saved to docker/audit/output/webauthn_search.txt).
• Ran a safe workspace copy upgrade attempt (in /tmp/wrk_upgrade) where I attempted incremental updates: cargo update -p reqwest, cargo update -p hyper-rustls, and cargo update -p webauthn-rs. Build and cargo-deny were run in the copy. Outputs were captured to docker/audit/output/upgrade_*.{out,err,json}.

Findings:

• The quick experiments did not eliminate the MPL-2.0 or CDLA-Permissive-2.0 diagnostics. cargo-deny still reports 7 license errors — the same clusters identified earlier (webauthn-rs family and webpki-roots). See docker/audit/output/upgrade_deny.err for the diagnostic JSON lines.
• The crates.io search indicates no newer webauthn-rs version in the same crate name space beyond 0.5.3 (at time of experiment). That suggests upgrading webauthn-rs may not be an option unless an alternate crate name or published fork exists.

Next steps recommended:

• Given that webauthn-rs appears to be at 0.5.3 on crates.io, investigate upstream (project repository) for planned releases or contact upstream about licensing/maintenance.
• For the TLS/root-store problem (webpki-roots), continue with a coordinated upgrade of reqwest + hyper-rustls and dependent crates (openidconnect/opendal) on a feature-aware branch; if upgrades are blocked, trial a native-tls switch in a dedicated branch where dependent features are adjusted accordingly.

All experiment artifacts are available under docker/audit/output/.