keys doctor should restore server public key

[dmiddlecamp]

maybe either prompt for this, or provide it as an option, or just do it by default, I think people are sometimes removing / corrupting their server keys, and this would help recover when possible? Thoughts?

[kennethlimcp]

sounds good though it causes some breaking changes with the local ☁️

[dmiddlecamp]

Totally, that's why I suspect maybe a prompt or extra parameter might help avoid that

[kennethlimcp]

👍

sounds good but during the process if we perform a dfu :leavethen it's gonna exit before the next command though that's simple to fix.

Or spark keys doctor all core_id.der

[technobly]

I just ran into this issue myself when changing a Core that was setup for the Staging server back to the Production server. I just assumed spark keys doctor xxxx fixed everything about the keys. Definitely happen to see this in the issues list already ;-)

If we have a couple known Public keys for these servers, my suggestion would be to Prompt within the doctor command if you'd like to restore 2: staging or 1: production and if the answer is no to both, explain that spark keys server is the command you'll need for a custom key (ala local cloud). Then just make sure the CLI can pull those keys down from amazon, or build them into the CLI.

[kennethlimcp]

@technobly, sounds awesome but too specific for spark team development though. Also, i don't think you guys would want to share the staging public key + ip address/domain and have people hitting it randomly during your testing.

No harm sharing but for a development environment, it would probably be better to leave that variable out.

Suggesting to have a "cert" folder of some sort that we can check against and flash accordingly.

Maybe even tag each cert to a profile so that you know you are flashing the right cert based on the profile you are currently on ;)

[dmiddlecamp]

@kennethlimcp 👍

[technobly]

If the CLI downloads the staging key on demand, it could be a secured option based on your login permissions. But yeah, it's not really that critical to add staging to the CLI, maybe more importantly it should just default to putting the public cloud key back on the device, unless you specify not to with spark keys doctor xxxx --no-server. Then you can follow up with spark keys server xxxx.der.

If you are running the doctor command, you might as well fix everything up.

[dmiddlecamp]

I like the idea of making it available via the API, then the CLI could grab it from whatever API it was pointed at

[affinity-matrix]

I like the idea of having the CLI pull the cloud public key on-demand as well.
If we're in agreement on this being the default behaviour (without a flag) then I'll add this as a TODO!