Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
cconstab opened this issue Jun 16, 2023 · 5 comments
Assignees
Labels
bug Something isn't working P1 Priority 1

Comments

@cconstab
Copy link
Member

cconstab commented Jun 16, 2023

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 cconstab added bug Something isn't working P1 Priority 1 labels Jun 16, 2023
@cconstab
Copy link
Member Author

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
Copy link
Contributor

gkc commented Jun 16, 2023

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
Copy link
Member

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

@JeremyTubongbanua
Copy link
Member

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

atsign-foundation/noports#211

@gkc
Copy link
Contributor

gkc commented Jul 9, 2023

Fixed by #211

@gkc gkc closed this as completed Jul 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working P1 Priority 1
Projects
None yet
Development

No branches or pull requests

6 participants