* Add basic setup for multi-PIN
- Reserve the storage keys for maximum of 8 user slots.
- Modify the storage functions to take a slot_id parameter.
- Add the slot_count() customization.
- Assume slot_id as a parameter when needed except these places:
- Entrance functions of command processing that directly takes the
command parameter structure. slot_id is set as 0, and will be
parsed from the parameters when we enable the feature.
- MakeCredential/GetAssertion/AuthenticatorConfig will take the
slot_id from active token state when we enable the feature,
resulting in an `Option<usize>`. Below code will act on the option
value correctly. When the feature isn't enabled, we're always
referring to the only PIN slot so set slot_id as Some(0).
- GetInfo returns verdict of whether PIN is supported and enabled, and
whether PIN needs to be forced changed. There will be new fields to
represent those values when the feature is enabled, and the old
fields will not be populated. So when the feature isn't enabled, we
can treat slot_id as 0.
Not covered in this commit:
- Unittests for other slots. The existing tests all pass and I plan to
add unittests for multi-slot case after the codebase allows enabling
the feature.
- Persisting and checking the slot_id in credentials. This is planned to
come in the next commit.
* Fix storage and some other style
* Add support for concatenated values
* Switch some storage entries back to multi-entry
* Set bumpalo version for fuzzing (#532)
* maximum working bumpalo version
* explicit comment to explain version locking
* removes incorrect comment
* moves serde version lock to dev dependencies
* removes serde dependencies
* reverts serde removal in crypto library
* Make PIN_PROPERTIES use concatenated storage entry
* Fix bumpalo issue
* Use concatenated storage entry for force_pin_change too
* Fix cargofmt
Co-authored-by: Julien Cretin <cretin@google.com>
Co-authored-by: kaczmarczyck <43844792+kaczmarczyck@users.noreply.github.com>
Those need the driver to deal with the fact that the store is stateful. Those
tests can't be moved to the test suite because they use private functions.
With dirty storage we hit the assert. Returning an error permits to continue to
catch if the invariant is broken for normal operation while being able to
continue fuzzing with dirty storage.
We don't need to build a production key without persistent storage. Tests and
fuzzing continue to use the std feature to use the RAM implementation (that does
sanity checks).
We prefer to return those errors to the fuzzer which can then decide whether
they are expected or not (e.g. when starting from a dirty storage, the store is
expected to have errors).
