at_activate can deliver an atKey file but not actually confirm the keys are in place on the atServer

[cconstab]

Describe the bug

If at_activate fails to put the keys in place it can error after cutting keys an be in aposition where atKey file is in place but the atServer does not have the public key.

Steps to reproduce

Unknown but it happens see below:-

$ at_activate -a @<REMOVED>_client
[Information] Root server is root.atsign.org
[Information] Registrar url provided is my.atsign.com
[Information] Activating your atSign. This may take up to 2 minutes.
[Information] Successfully sent verification code to your registered e-mail
[Action Required] Enter your verification code: (verification code is not case-sensitive)
484X
[Information] CRAM Key fetched successfully
Connecting to secondary ...1/50
[Information] Generating your encryption keys and .atKeys file

[Success] Your .atKeys file saved at /home/pi/.atsign/keys/@<REMOVED>_client_key.atKeys

SEVERE|2023-06-16 19:39:30.735357|AtLookup|Exception in sending to server, Exception: Waited for 10000 millis. No response after 2023-06-16 19:39:20.724651  

SEVERE|2023-06-16 19:39:30.735700|OnboardingCli|Caught exception: Exception: Waited for 10000 millis. No response after 2023-06-16 19:39:20.724651  

$

and on the atServer

read R BLOCK
@scan
data:["signing_publickey@<removed>_client"]
@

Expected behavior

Not to put the keys in place until the secondary is confirmed to have the keys in place.

Screenshots

No response

Smartphones

• sshnp Raspberry Pi

Were you using an atApplication when the bug was found?

sshnp

[cconstab]

I have asked to customer to re run at_activate and I think that should fix things, but will confirm once we hear back.

[gkc]

Ideal sequence is

1. Auth with CRAM. On error, exit
2. Generate keys file. On error, delete keys file and exit
3. Send PKAM public key to server. On error, retry. On repeat error, delete keys file and exit
4. PKAM auth. On error, retry. On repeat error, delete keys file and exit
5. Send delete for CRAM. On error, retry until success. If CRAM is not deleted then as a precaution we may wish to enhance AtServer to delete CRAM secret (if it exists in database) after a successful PKAM auth

[JeremyTubongbanua]

Wow ! I don't think this has ever happened before

[JeremyTubongbanua]

There's a bit of work done here for checking the public:publickey on an atServer:

atsign-foundation/noports#211

[gkc]

Fixed by #211