This factors the junk drawer of constants into the relevant files.
There are still a few "global" ones left but they can be addressed in a
followup commit.
YubiKey NEOs are legacy YubiKey devices, most of which contain
unpatchable security vulnerabilities.
They have smaller buffer sizes than YK4 and YK5, which necessitates a
whole bunch of conditional gating and buffer size calculations.
Getting rid of them simplifies this logic and allows us to assume
consistent buffer sizes everywhere.
We never tested on NEOs anyway, and looking at the deleted code it seems
it may have been miscalculating the NEO's buffer size!
If someone *really* wants to support NEOs, it shouldn't be that hard to
restore, but the codebase is definitely cleaner without it.
Converts a bag of constant values (`YKPIV_INS_*`) into an enum
representing APDU instruction codes (a.k.a. `ins`).
Among other things, this makes the `Debug` output for `APDU` more human
meaningful, since it can print a text label for the instruction rather
than a code number, which is helpful in trace debugging.
This commit merges the `apdu` and `response` modules: the responses are
APDU responses, and so the two are related.
This also moves the `trace` logging into the APDU type, which allows it
to display `Debug` output for APDUs and responses, which makes it easier
to understand what's going on (and will be even better once instructions
are converted into an enum so you can actually see what's happening).
This commit contains a "big bang" refactor/rewrite which does the
following:
- Replaces all `SCard*` FFI calls with the `pcsc` crate, which provides
a safe, portable PC/SC API across Windows, macOS, and Linux
- Refactors the `util` module into modules representing the various
device functions and concepts, e.g. `certificate`, `key`, `mgm`
- Replaces all usage of `libc` with `std` functionality, and in many
places rewriting functionality to use safe code.
- Removes `ykpiv_` from all function names, and `Piv*` from type names.
In 20/20 hindsight I wish I had done this commit more incrementally so
as to make it easier to review. Que sera sera.
However, realistically we need to test all functionality on the device
to ensure that it actually works. Going forward I would like to put
pretty much all of the current code behind an `untested` cargo feature,
and then remove it for each bit of functionality we test.
Jack Grigg