Open
Description
openedon Jun 3, 2024
TL;DR
We kept Legacy:: tables
for JWT in #6175, for reasons explained here. This can be safely removed after ensuring old tables are no longer used anywhere in the system.
In CCF we periodically fetch/store key certificates for the configured issuer.
Before 5.0.x
we stored the needed info in this tables
After 5.x.x
, we only put the newly fetched one new table:
public_signing_keys_metadata
(here)
After upgrading 4.x.x
- > 5.x.x
the new code will store JWT certificates in the new tables, but will read from both new and old tables in order. Old tables are used if the keys haven’t been fetched yet by any of the new nodes.
This task is to support further upgrading from the first 5.x.x
to the 5.x.y
with a proper clean-up of the old tables. It's two-fold:
- Dev side
- new code with deleted references to
Legacy::
tables - new custom action JS which will drop old KVs. Example
// actions.js ... [ "remove_old_jwt_tables", new Action( function (args) {}, function (args) { ccf.kv["public:ccf.gov.jwt.public_signing_keys_metadata"].clear(); }, ), ],
- new code with deleted references to
- Operator side
- verify the new table has been populated
- We may grep a brand new snapshot (or force-trigger one) and grep it with
read_ledger.py
- Alternatively, can just call
set_jwt_issuer
(or expose and call a privatejwt_keys/refresh
endpoint) to unconditionally reset the keys instead
- We may grep a brand new snapshot (or force-trigger one) and grep it with
- propose new action to prune the old tables
- To be created as a dev-part
- verify old tables have been deleted
- We may add
triggerSnapshot
to a proposal so we get a fresh snapshot to grep withread_ledger.py
and check there's no entries in the old tables
- We may add
- verify the new table has been populated
Metadata
Assignees
Labels
No labels
Activity