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
{{ message }}
Repository navigation
Commit da91570
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: README.md
+28-9Lines changed: 28 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -95,6 +95,16 @@ key, so pass such a file with `--from-trusted`, which takes its tree size and
95
95
root hash as your own record without checking the signature. The origin is
96
96
still enforced.
97
97
98
+
**Leaf field sets also ship by release.** The log commits each event under a
99
+
numbered set of fields (see *How verification works*), and a release can
100
+
rebuild only the sets that existed when it was cut. This release rebuilds v1
101
+
and v2; the log may begin writing v2 at any time after this release. A release
102
+
older than the log's newest set reports every event written under it as "not
103
+
what the log committed", whether or not the event carries a newer field. If
104
+
every event after some date fails that way, install the latest release and run
105
+
again until a pass completes without reporting truncation; a failure that
106
+
survives that is a security finding.
107
+
98
108
## Commands
99
109
100
110
| Command | What it does |
@@ -131,7 +141,7 @@ Schedule it — hourly is reasonable — and alert on the exit status:
131
141
| Exit | Meaning | Action |
132
142
|---|---|---|
133
143
|**0**| Nothing failed. Events served with no leaf, and — under `run` — events still awaiting a checkpoint, are reported rather than verified — see *Event outcomes*. | — |
134
-
|**1**|**Verification failed**: a bad signature, wrong origin, a log that shrank or forked, an invalid proof, or an event whose served content is not what the log committed. |Treat as a security finding. Keep the state file and the output; contact Anthropic. |
144
+
|**1**|**Verification failed**: a bad signature, wrong origin, a log that shrank or forked, an invalid proof, or an event whose served content is not what the log committed. |If every event after some date fails as "not what the log committed", first rule out an old release (*Leaf field sets also ship by release*). If that is not the cause, and for any other failure, treat it as a security finding. Keep the state file and the output; contact Anthropic. |
135
145
|**2**| Usage error. | Fix the invocation. |
136
146
|**3**| Could not complete: network failure, API errors, rate limiting after retries, or an `events` file holding an index the log has published no checkpoint for, or no proof for one it published while the check waited. | Rerun; page only if it persists. |
137
147
@@ -248,15 +258,21 @@ on that log staying reachable.
248
258
(`GET …/transparency_log/consistency?from=N`). Checkpoints that arrive
249
259
embedded in proof responses mid-run are linked into the same history the same
250
260
way before anything is verified against them.
251
-
-**Inclusion.** Each served event is projected onto leaf field set v1 —
252
-
eleven keys, RFC 8785 canonical JSON, prefixed with the version byte `0x01` —
253
-
exactly as the Compliance API reference's *Leaf canonicalization* section
254
-
specifies; `leaf/` is that specification in code and is tested against the
255
-
log's own golden vectors. The leaf hash and the audit path from
261
+
-**Inclusion.** Each served event is projected onto a leaf field set, as
262
+
RFC 8785 canonical JSON behind a version byte. Field set v1 (`0x01`) is
263
+
eleven keys, exactly as the Compliance API reference's *Leaf
264
+
canonicalization* section specifies; `leaf/`'s v1 renderer is that
265
+
specification in code and is tested against the log's own golden vectors.
266
+
Field set v2 (`0x02`) is the same eleven keys plus `user_profile_id` when
267
+
the event has one. An event that carries a `user_profile_id` is checked as
268
+
the `0x02` leaf with that key and as nothing else, so an id added to, removed
269
+
from or altered in a served event fails. Any other event is checked as a `0x02` leaf first and
270
+
then as a `0x01` leaf, and a match with either verifies it: both commit the
271
+
same eleven values. The leaf hash and the audit path from
256
272
`GET …/transparency_log/inclusion?leaf_index=N` must reproduce the signed
257
-
root. An event type outside v1's list (`anthropic_access`, `cmek_preserve`)
258
-
is refused: new types ship under a new version byte and need a newer
259
-
`axt-verify`.
273
+
root. An event type outside the two versions' shared list
274
+
(`anthropic_access`, `cmek_preserve`) is refused: new types ship under a
275
+
new version byte and need a newer `axt-verify`.
260
276
-**Nothing from the API is trusted** until it verifies against the key this
261
277
release carries: not the checkpoint, not the proofs, not the leaf index.
262
278
@@ -282,6 +298,9 @@ on that log staying reachable.
282
298
- Deleting the state file re-baselines the next run: it starts from whatever
283
299
checkpoint the log serves (exit 0) and can detect no rollback that run. Keep
284
300
an archived note (`--save`, handed back with `--from`) as the durable anchor.
301
+
- A state file a newer release has written is not for an older one: the older
302
+
release reads the newer leaf hashes as changed content and fails every event
303
+
that was awaiting a checkpoint.
285
304
- The Compliance Access Key is read from `$ANTHROPIC_COMPLIANCE_ACCESS_KEY` and
286
305
grants read access to all of your organization's compliance activities. A
287
306
process running as the same user can read the cron's environment; scope that
0 commit comments