v0.10
main
v0.5.0
v0.4.0
v0.3.0
v0.2.0
v0.1.0
${ noResults }
3 Commits (2c305cf2531fa6499994c7d58e933284ebb90d81)
| Author | SHA1 | Message | Date |
|---|---|---|---|
|
|
f79d8e2de8 |
Specification 0.16 draft: a seal without accuracy, drand's JSON read strictly
The draft v0.16 of datekeys-go at 4f78854 (branch v0.16): SPEC_VERSION 0.16, and testdata, wordlists and annex synced from that commit. The annex is §79 of the draft, with the CC BY-ND 4.0 license of the specification in its title and the key of words in 79.7. A seal without accuracy proves nothing before the opening date (§29.7, §29.11, as 7e3b810): a valid seal is S4 only when its token carries accuracy and t plus the accuracy is before round_time; otherwise S5, with the first reason that holds: late, no accuracy under the BTSP policy of ETSI EN 319 421 (0.4.0.2023.1.1), or no accuracy. cms.ts reads hasAccuracy and the policy of the token (tokenIsBTSP); securitycms.ts gives SealReason, Detail.sealReason and SignerLine.reason; S5 has no fixed text any more, and verdictLines writes it and the line of a signer of F6 with the reason, the texts of Go byte for byte (sealReasonText). encryptFiles returns the verdicts of the area it wrote in Encrypted.security, as Result.Security of Go, so that a writer warns of a seal without accuracy (§62.1 rule 19). drand's JSON is read strictly (§47.1, as b570338): parseDrandJSON, as ParseDrandJSON of Go, reads RFC 8259 JSON in valid UTF-8 whose value is an object, with no name repeated in any object, names compared exactly once their escapes are decoded, a lone escaped surrogate malformed, the round a number without sign, fraction or exponent from 1 to 2^53 - 1, and signature and randomness strings, with the error texts of Go. ParsedRelease is now a Release: no round above 2^53 - 1 is read. The page reads the answers of the relays with it (drand.ts), as the client of Go does, and the pasted release with strictJSON and jsonRound (release-input.ts), so that it never reads another round than step 10. Tests: security_cms.json with seal_reason (143 cases), the 38 JSON inputs of release.json, the new cases of signature2_test.go and drandjson_test.go (with the escapes written as escapes), and the new fixtures: format3_time_and_key_words opens with the identity that the words of its words_text give with normalizeWords and wordKey, in the library and in the page, and format3_full_chunk, whose PAYLOAD_AGE ends in a full STREAM chunk, opens. check-build.mjs counts words_text among the secrets of the fixtures. Reference files made again with Go at 4f78854: mutation-texts.json (its spec field only), ibe-vectors.json (the two new fixtures, the rest unchanged) and signing-vectors.json, in an export of 4f78854 with the same frozen samples read again: the capsules are the same, and the tokens of the sealer, without accuracy, now give S5. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
1 day ago |
|
|
67a9037839 |
The public note refuses malformed UTF-16, and no decoder drops a leading BOM
Fixes T4 and the rest of T5 of the review of the session of 1 and 2 October: - note.ts: checkNote refuses a string with a lone surrogate, which UTF-8 cannot hold, after its length and with the text that extension.CheckNote gives for invalid UTF-8. newNote wrote U+FFFD in its place, and the note is public and permanent (spec §62.1 rules 15 and 23). - note.ts: publicNote reads the data with decodeUtf8, which keeps a leading U+FEFF: such a note is unusable, as in Go, where it showed without it. - author.ts: authorCode takes the eight bytes of the code as Go's AuthorCode takes them, a leading U+FEFF kept. - inspector/drand.ts: an answer of a relay that starts with a BOM is refused, as json.Unmarshal refuses it in the client of the reference. - The texts of the head and the paths of format 3 already kept it, since cbor.ts decodes them with decodeUtf8: head.test.ts now pins it with the texts of Go. The other TextDecoder of src/lib, in age.ts, reads tokens of ASCII that are checked byte by byte before. The texts are those of extension.CheckNote, extension.Note, capsule.DecodeHead and capsule.AuthorCode at spec-v0.11, taken with an oracle on the same bytes; the drand client of the reference refuses the answer with json.Unmarshal. npm run verify passes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
7 days ago |
|
|
2ec7102f1b |
/inspect asks drand for the release when the person asks
The author found copying the release of the round tedious. A button, "Pedir la firma a drand", fetches it from the three public relays of the CLI of the reference, as its client does: raced, 6 s, at most 8 KiB an answer, no redirects, and the randomness checked against the signature; step 10 still verifies the signature with the pinned key, so a relay cannot make the page accept a false one. It is the only connection the page makes to another site, and only on that click: the CSP allows those three origins in connect-src, check-build.mjs requires exactly them, and the footer says so. Pasting by hand still works. Checked in Chromium: api2.drand.sh gave the release of round 32668196 and the capsule opened. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
1 week ago |