This will allow for e.g. xous on riscv32-imac but not a precursor
target, for example: by using feature selectors we get to have
a bigger range of targets that we support, such as for implementations
that haven't been upstreamed or have official target-triples.
The downsides are:
- patch override libraries don't absorb feature flags. so, for
example, the AES crate that is used to patch other crates won't
be aware of the target features without modifying the referencing
crates.
- features are normally meant to be additive, but target features
are mutually exclusive. The mutex is enforced by a check in
utralib that throws a panic on build if two targets are accidentally
selected at the same time.
- HOTP now prompts for an initial count
- Found a code path where improperly formatted HOTP field can
lead to a 0-value being passed to a totp generator
- Added guardrails around the TOTP generator so it can't divide by 0:
it issues a warning instead.
hotp is merged as a "minor" feature off of totp. In other words,
the default mode is totp, but one can specify a totp record
to be an hotp record and it will behave as an hotp record.
We re-use the "step_seconds" field to specify the count parameter.
There is no separate initial count / count field -- the two are
tracked in a single u64 that is stored in the "step_seconds" field
of what would be a totp record.
This also revs the TOTP record to v2. This *should* not break
anything:
- v1 records deserialize as totp records into v2 (which is correct,
as there are no hotp in v1)
- when a v1 record is saved to disk, it is stored in v2 format
- v1 records that are not edited stay as v1
unique content
Instead of generating a unique GUID every time a new record gets
created, hash known unique content for every entry and use that as key.
The StorageContent trait now has a hash() method that returns a Vec
containing the SHA-256 hash of the object's unique content.
Hashing is done by re-using the same calls that ctap uses.
This allows dupes detection when restoring a backup, allowing us to
employ a "never overwrite" policy: Precursor is the main source of truth
for such data.
Still needs a way to deterministically generate a key for each entry.
Idea: a `hash() -> String` method on StorageContent so that new_record
can call it, store said object with the newly-generated key.
Since this is a deterministic operation, restoring a backup with dupes
would not overwrite what's present in PDDB already.
Instead of syncing for each new record, new_records() only syncs:
- when it's writing an entry that has index multiple of 10
- when it's the last packet in sequence
