Enable USE_PCSC at build time, so libfido2 can use FIDO devices over
PCSC/contactless smartcard readers (e.g. NFC taps via a USB CCID reader),
not just the Linux kernel NFC subsystem or USB HID.

Background
----------
libfido2 has three transports on Linux: USB HID, the kernel NFC subsystem
(NFC_LINUX), and PCSC (USE_PCSC). The PCSC transport is for contactless
readers that the kernel's NFC subsystem doesn't drive directly -- e.g.
PC/SC-class readers like the ACS ACR1252, which are common, inexpensive,
and already fully supported by pcscd/pcsc-lite in Debian.

Upstream's CMakeLists.txt defaults USE_PCSC to ON on the current main
branch, but the maintainers disable it in the CMakeLists.txt shipped in
each release tag just before cutting a release, considering it
"experimental" (see upstream discussion:
https://github.com/Yubico/libfido2/discussions/855). Because of that,
every tagged release -- including 1.17.0 -- ships with USE_PCSC OFF by
default, and Debian's debian/rules doesn't override it, so the built
libfido2-1 package has no PCSC support at all (confirmed via ldd: no
libpcsclite linkage). libpcsclite-dev also isn't currently a
Build-Depends.

Since Debian already ships pcsc-lite and pcscd, and libpcsclite-dev is
readily available, there's no reason PCSC support can't be built in
alongside the existing USB and kernel-NFC transports.

Evidence it works
------------------
I built libfido2 from the upstream main branch with -DUSE_PCSC=ON
(pkg_check_modules picks up libpcsclite cleanly, no patches needed to
libfido2 itself), then built libpam-u2f 1.4.0 against it. Tested against
a YubiKey 5-series key resting on an ACS ACR1252 Dual Reader's
contactless (PICC) interface, with no USB connection:

  $ fido2-token -L
  pcsc://slot0: vendor=0x0000, product=0x0000 (PC/SC ACS ACR1252 Dual
  Reader [ACR1252 Dual Reader PICC] 00 00)

  $ fido2-token -I pcsc://slot0
  [... full CTAP2 getInfo response, including "transport strings: nfc,
  usb" ...]

I then used the same setup for real: pam_u2f authenticating `sudo` over
this transport, with the existing U2F credential (originally registered
over USB) working unmodified over PCSC/NFC -- no re-enrollment needed,
no APDU-chaining errors, clean round trip.

Proposed patch
--------------
Attached: two-line change to debian/control (add libpcsclite-dev to
Build-Depends) and debian/rules (pass -DUSE_PCSC=ON to
dh_auto_configure), diffed against debian/sid HEAD
(56ac1a33ba8953bec4fcc10243c6fb2d8b288c8d).

Attaching the patch referenced in the original report.

It makes two changes against debian/sid HEAD
(56ac1a33ba8953bec4fcc10243c6fb2d8b288c8d):

  * debian/control: add libpcsclite-dev to Build-Depends
  * debian/rules:   pass -DUSE_PCSC=ON to dh_auto_configure

Tested locally: libfido2 built with -DUSE_PCSC=ON drives a YubiKey 5
over an ACS ACR1252 contactless reader, and pam_u2f authenticates sudo
over that transport with an existing USB-registered credential,
unmodified.

Control: retitle 1141189 libfido2: enable PCSC support

I accept that we're currently lacking this feature and that it could in
principle be enabled using your patch.  However, I'm reluctant to do so
in our distributed packages while upstream still has it marked as
experimental.  See https://github.com/Yubico/libfido2/discussions/867:

   "That said, devices that expose multiple interfaces at the same time
   are a bit of an unknown. This is part of the reason USE_PCSC is
   disabled by default."

   "I'd again like to mention that -DUSE_PCSC=ON is only experimental and
   we do not recommend running with it enabled at this time."

This doesn't fill me with warm enough fuzzies to be confident in
applying your (or your LLM's - your bug report seemed to be in a
distinctly LLMish writing style) patch.

Thanks,