User story: publish `webauthn-rs` related binaries (`fido-key-manager`, `webauthn-rp-proxy`) as Docker containers

[micolous]

Is your feature request related to a problem? Please describe.

I want to be able to run webauthn-rs' binaries (like fido-key-manager and webauthn-rp-proxy) on an Linux distribution that ships an outdated version of OpenSSL.

webauthn-rs demands OpenSSL 3.0.0 and later, but my distribution still ships OpenSSL 1.x in 2025.

Unfortunately, my organisation's IT department forces me to run this Linux distribution.

Describe the solution you'd like

My Linux distribution has access to a version of Docker. At worst, I can install the current version of Docker from Docker's repositories directly.

This might be difficult with fido-key-manager, because it needs a way to access USB/BLE/NFC from the host machine. But there are work arounds which give containers direct hardware access from the host, at the cost of abandoning some of its isolation properties.

So if there were Docker containers for this, then I think it would solve my problem.

This would only need a small number of extra CI targets to support, one for each binary. We'd turn on all features for these builds.

Describe alternatives you've considered

• Switching out OpenSSL for a different cryptography library: that will take a lot of work: Removal of OpenSSL kanidm#3476
• Using a vendored version of OpenSSL 3.x: this is hard to audit, and means we need to double our CI targets
• Supporting OpenSSL 1.1: please no 😄

Additional context

Related to #475, #416

[yaleman]

I wouldn't build a container per binary, that's SO many containers for the sake of it... Just make a webauthn-rs-tools container or something?

[micolous]

I was thinking container per binary because then they just become ENTRYPOINTs.

Plus the use cases are all a bit different – like we'd want to setup USB pass-through for fido-key-manager, TCP forwarding for cable-tunnel-server, and probably neither for webauthn-rp-proxy (I think that uses stdio, right?)