- 
                Notifications
    You must be signed in to change notification settings 
- Fork 22
Open
Description
We just had a report of an issue where someone configured shared secret credentials but left the configurator implicit (which is the usual thing and what the docs indicate). But he had added nerves_key as a dependency. So NervesHubLink went for the NervesKey configurator.
The NervesKey chip was there but not provisioned. It all boiled down to {:error, :execution_error} popping out of the NervesKey. And the Shared Secret was never tried or used.
The order of how the choice of configurator is made seems like it could be better.
- Log which configurator we are using.
- Setting the shared_secretkey ofnerves_hub_linkconfig seems more explicit than having added thenerves_keydep. And maybe that could take precedence. At the very least we can log that it was overridden as a warning.
- Checking NervesKey.provisioned?/1would help mitigate attempts to use unprovisioned NervesKeys. It would seem a legit case to prefer the NervesKey if provisioned but fall back to a shared secret in development or something to that effect.
Similar issue would probably occur with an unprovisioned TPM. Haven't tried.
So some fairly simple things can be done to improve this. And then there are some more nuanced decisions as well.
Metadata
Metadata
Assignees
Labels
No labels