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

Enforce node<id+1> names in EnhancedKeyStoreLoader #15824

Open
Tracked by #17292
anthony-swirldslabs opened this issue Oct 4, 2024 · 2 comments · May be fixed by #17487
Open
Tracked by #17292

Enforce node<id+1> names in EnhancedKeyStoreLoader #15824

anthony-swirldslabs opened this issue Oct 4, 2024 · 2 comments · May be fixed by #17487
Assignees
Labels
Platform Tickets pertaining to the platform

Comments

@anthony-swirldslabs
Copy link
Contributor

anthony-swirldslabs commented Oct 4, 2024

Background

  1. The EnhancedKeyStoreLoader uses node self names from the AddressBook to compose file names that contain keys for that node.
  2. As the Platform migrates from using the AddressBook to using the Roster, custom node names are getting replaced with generated names of form node<id+1>.
  3. Per @iwsimon , in production all nodes already use self names of this format, and we already use .pem keys via the EnhancedKeyStoreLoader in prod.
  4. In Regenerate keys and update node names for tests #15789 , we've also updated Platform tests that used custom node names and replaced legacy .pfx keys with new .pem keys.

Acceptance criteria

  1. The EnhancedKeyStoreLoader should stop using custom self names, and should enforce using names of form node<id+1> for the purpose of loading keys.
  2. Unit tests for the EnhancedKeyStoreLoader should be updated to follow this changes, which may require regenerating some legacy keys to use the new names. Alternatively, support for the legacy keys should be removed from the code-base altogether.

Notes

  1. There may or may not be additional impact to any of the testing environments (e.g. testnet, perfnet) as well as testing frameworks (JRS, Solo, etc.) that may require extra changes or coordination (with devops etc.) We'll only be able to discover them once the main change from the Acceptance criteria is implemented and merged.
@anthony-swirldslabs anthony-swirldslabs added the Platform Tickets pertaining to the platform label Oct 4, 2024
@poulok
Copy link
Member

poulok commented Oct 9, 2024

@anthony-swirldslabs , please add this ticket to the TSS Roster Implementation epic

@anthony-swirldslabs
Copy link
Contributor Author

@poulok : just added it to #14706

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Platform Tickets pertaining to the platform
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants