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.
UPD More tables to prune after #6601. Check out the ticket and the PR for details.
In CCF we periodically fetch/store key certificates for the configured issuer.
Before 5.0.x we stored the needed info in this tables
public_signing_keys (here)
jwt.public_signing_key_issuer (here)
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();
},
),
],
- 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 private jwt_keys/refresh endpoint) to unconditionally reset the keys instead
- 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 with read_ledger.py and check there's no entries in the old tables
TL;DR
We kept
Legacy:: tablesfor JWT in #6175, for reasons explained here. This can be safely removed after ensuring old tables are no longer used anywhere in the system.UPD More tables to prune after #6601. Check out the ticket and the PR for details.
In CCF we periodically fetch/store key certificates for the configured issuer.
Before
5.0.xwe stored the needed info in this tablespublic_signing_keys(here)jwt.public_signing_key_issuer(here)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.xthe 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.xto the5.x.ywith a proper clean-up of the old tables. It's two-fold:Legacy::tablesread_ledger.pyset_jwt_issuer(or expose and call a privatejwt_keys/refreshendpoint) to unconditionally reset the keys insteadtriggerSnapshotto a proposal so we get a fresh snapshot to grep withread_ledger.pyand check there's no entries in the old tables