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
The response to get OpenSSH to work is non-compliant
(because it's trying to read a 2.1 command set out of a 2.0
device). This will lead to breakage in the 2.0 test bench,
but, it will allow the device to work with OpenSSH.
meh. specs, schmecs.
read_to_end() "guesses" the total amount of data to read by doing
roughly 5 calls per couple hundred bytes: it starts by guessing
it's 32 bytes long, then another 32, then 64, then 128, and then
a final call to make sure there's nothing more.
The read() call is somewhat expensive in that it involves initializing
and sending page-sized memory chunks, and every time it also
descends the entire basis hierarchy, recomputing the overlay.
Probably, this can be improved with some sort of server-side caching
of read results -- if a file is read, it seems very likely that
the next few bytes will be read and a smarter caching implementation
could smooth over some of the expense.
However, a much easier fix for now is to just change the read
call to read exactly the length of the file being presented. Since
we already have the key handle, we can get the attributes and then
do a single read of the exact amount.
Doing this improves the speed of the UX substantially, about 40%
faster for the same operation (at least).
