mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.2.0 2026-03-19T10:37:47Z 2026-03-19T10:37:47Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-03-11T12:59:17Z urn:sha1:9427eca66096a2a333fafb360532a3679dc52fd9 2026-03-19T10:37:47Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-03-10T15:34:25Z urn:sha1:356afa6e7993ceb726d4c0784b7a17d39e6aef75 We want to stop deriving NetdocParseable directly for body structs. This test case does in fact parse a signed authcert and extract just the body without verifying the signatures. That's fine in a test, but we're going to make it involve some hoop-jumping. So, jump those hoops. 2026-03-19T10:37:47Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-03-09T17:48:49Z urn:sha1:575261d3f0c6f537640ecbe810396aac35652de2 Replace the two separate NetdocParseable and NetdocUnverified derives, for toplevel signed documents, with a single derive. This makes the derive API simpler. It will also make it reasonably possible to avoid deriving NetdocParseable directly for body structs. Such impls are a security hazard! In detail: * Rename NetdocUnverified to NetdocParseableUnverified * Have it use $IMPL_NETDOC_PARSEABLE from the NetdocParseable deftly module so that it derives NetdocParseable for the body. (We'll change this later in the series.) * Adjust the docs and all call sites. 2026-03-19T10:37:47Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-03-11T13:06:35Z urn:sha1:aefa48e251f514a2cdbcb9e4a26292438b74af68 During encoding, including these hashes in the signature items makes no sense. The hashes are an *input* to the signature items, but not part of them. Move the hashes out of the items. Instead, provide each signatures section type with a hash accumulator type, in which the hash(es) are stored. 2026-03-19T10:37:47Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-03-03T19:24:42Z urn:sha1:399c09200a008b02f4a9551fed22032feacf198d This is going to contain body information, and the hashes, too. 2026-03-19T10:37:47Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-03-03T19:04:43Z urn:sha1:e12328a78e03425465320d98ad695c00614dac8d This is going to be its own trait and it is usually best if macros are named after traits, rather than having the macro derive a different trait depending on meta attributes. 2026-03-03T18:57:38Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-03-03T18:57:38Z urn:sha1:96114eb9a68ca1c8062bc3f8761aee90115e003d 2026-03-03T18:56:01Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-03-03T18:46:00Z urn:sha1:9018c73d34ca60c5f671eeafc540446864998941 This was a weird name, and while working in this area it all seemed to make the docs strange. Rename it. This is quite invasive! In theory we could have the macros generate compatibility aliases, but that seems quite complex. 2026-03-03T18:46:11Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-03-03T16:22:27Z urn:sha1:807890deecfb215e9dc59611d5b4898924994c28 This test case constructs a "netdoc" which consists of one dir-key-certification item, and parses it using `AuthCertSignatures as NetdocParseable`. But we're going to split out the parsing trait for signatures sections, so that's not going to work any more. This test tests only corner cases of the derived SignatureItemParseable implementation; but that's unit tested in the parse2 tests. (Once upon a time there was perhaps manual parsing code which needed a specific test.) Remove it. 2026-01-15T12:37:13Z Ian Jackson ijackson@chiark.greenend.org.uk 2026-01-15T11:14:48Z urn:sha1:67b24f4b924311e1ae89c2962983d663fa607466 The feature arrangements in tor-netdoc are getting to be in need of a serious overhaul.