You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We had two separate checks to decide if we will allow a protobuf
message API call to proceed: in hww.rs (forbid if initialized and
locked) and in api.rs in the can_call() function that defines which
states the API call can run in.
This makes it a bit hard to follow as split into two locations, and it
also prevents us from introducing a protobuf call that is only allowed
to run if the device is initialized but still locked. `Unlock` would
be such a useful new API call if we want to allow entering the
passphrase on the host.
The hww.rs check passed if `!initialized || !locked`,
which means the same as `uninitialized || seeded || unlocked`.
We change the `can_call` state checks to include this condition. For
this we split the local `Initialized` state into
`InitializedAndLocked` and `InitializedAndUnlocked`. For each line in
can_call, the two conditions are combined. The equivalent state check
in the end is simply to convert all `Initialized` checks to
`InitializedAndUnlocked`.
The `true` entries become explicit as they can't include
`InitializedAndLocked` (e.g. can't change the name using `DeviceName`
if initialized but not yet unlocked).
0 commit comments