You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,12 +11,15 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
11
11
12
12
### Added
13
13
14
+
- Backup nodes can now be configured to automatically fetch snapshots from the primary when snapshot evidence is detected. This is controlled by the `snapshots.backup_fetch` configuration section, with `enabled`, `max_attempts`, `retry_interval`, `max_size` and `target_rpc_interface` options. Note that the target RPC interface selected must have the `SnapshotRead` operator feature enabled.
14
15
- Added `ccf::IdentityHistoryNotFetched` exception type to distinguish identity-history-fetching errors from other logic errors in the network identity subsystem (#7708).
15
16
- Added `ccf::describe_cose_receipt_v1(receipt)` to obtain COSE receipts with Merkle proof in unprotected header for non-signature TXs, and empty unprotected header for signature TXs (#7700).
16
17
-`NetworkIdentitySubsystemInterface` now exposes `get_trusted_keys()`, returning all trusted network identity keys as a `TrustedKeys` map (#7690).
18
+
- Added support for self-transparent code update policies (#7681).
17
19
18
20
### Changed
19
21
22
+
- On recovery, the UVM descriptor SVN is now set to the minimum of the previously stored value in the KV and the value found in the new node's startup endorsements. On start, the behaviour is unchanged (#7716).
20
23
- Refactored the user facing surface of self-healing-open and local sealing. The whole feature is now `sealing-recovery` with `self-healing-open` now referred to as the `recovery-decision-protocol`. (#7679)
21
24
- Local sealing is enabled by setting the `sealing-recovery` config field (for both the sealing node, and the unsealing recovery node)
22
25
- The local sealing identity is under `sealing-recovery.location.name`
Copy file name to clipboardExpand all lines: doc/operations/code_upgrade.rst
+131Lines changed: 131 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -184,3 +184,134 @@ Notes
184
184
185
185
- The :http:GET:`/node/version` endpoint can be used by operators to check which version of CCF a specific node is running.
186
186
- A code upgrade procedure provides very little service downtime compared to a disaster recovery. The service is only unavailable to process write transactions while the primary-ship changes (typically a few seconds) but can still process read-only transactions throughout the whole procedure. Note that this is true during any primary-ship change, and not just during the code upgrade procedure.
187
+
188
+
Code Update Policy
189
+
------------------
190
+
191
+
Instead of explicitly trusting host data values, members can set a **code update policy** — a JavaScript function that evaluates transparent statements presented by joining nodes. A transparent statement is a COSE_Sign1 envelope carrying a signed statement about the node's code, countersigned with a CCF receipt that proves the statement was registered on a ledger.
192
+
193
+
.. note::
194
+
195
+
CCF currently only supports **self-issued** transparent statements: the service itself acts as the transparency service, issuing receipts over signed statements registered on its own ledger.
196
+
197
+
The policy receives an array of transparent statements and must return ``true`` to accept or a string describing the rejection reason. Any other return value is treated as an error. Structural validation (non-empty fields, receipt signature verification, claims digest binding) is performed by CCF before the policy runs; the policy only needs to compare values.
198
+
199
+
Policy Input Schema
200
+
~~~~~~~~~~~~~~~~~~~
201
+
202
+
The ``apply(transparent_statements)`` function receives an array of transparent statement objects. Each element has the following shape:
203
+
204
+
.. code-block:: javascript
205
+
206
+
[
207
+
{
208
+
phdr: { // COSE_Sign1 protected header
209
+
alg:<int>, // REQUIRED - COSE algorithm (e.g. -7 for ES256)
210
+
cty:<int|string|undefined>, // OPTIONAL - content type
Use the ``set_node_join_policy`` governance action to register the policy and ``remove_node_join_policy`` to remove it.
301
+
302
+
Joining with a Transparent Statement
303
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
304
+
305
+
When a node joins the network, it can present a transparent statement by setting the ``host_data_transparent_statement_path`` field in the ``join`` section of its configuration file. This must point to a COSE Sign1 file (the transparent statement) that attests to the node's host data:
If the joining node's host data is not in the trusted list (i.e. not registered via ``add_snp_host_data``), CCF falls back to evaluating the transparent statement against the code update policy. If no transparent statement is provided, or the policy rejects it, the node will not be allowed to join. If the host data is already explicitly trusted, the node joins without evaluating the policy, regardless of whether a transparent statement is provided.
0 commit comments