mirrors/arti.git/crates/tor-netdoc/src/parse2/lex.rs, branch arti-v2.5.1mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.5.12026-06-09T16:02:36Zeverywhere: Add #[allow(clippy::string_slice)]2026-06-09T16:02:36ZClara Englercve@cve.cx2026-06-09T16:00:38Zurn:sha1:d0af4abbd7b371f1eade609202a730cd9a1c21d3
This commit adds #[allow(clippy::string_slice)] to all functions in the
code where string slices are used, alongside a TODO comment.
We do this add the function header to have it consistent, as things like
expression based allow's are still experimental.
tor-netdoc: Rename NetdocUnverified trait to NetdocParseableUnverified2026-06-02T10:39:51ZIan Jacksonijackson@chiark.greenend.org.uk2026-06-02T10:32:02Zurn:sha1:9b014fc0c02be35576fde6cb927e7c9645b5f827
The NetdocParseableUnverified derive macro implements this
trait (amongst other things). Traits and derive macros should have
aligned names.
This is only used for parsing, so let's keep the "Parseable" part of
the name.
I don't think the effort of deprecated alias, for downstream
compatibility, is worth it, our compatibility policy notwithstanding.
tor-netdoc: Properly replace parse2::lex::NoFurtherArguments2026-05-27T12:43:10ZIan Jacksonijackson@chiark.greenend.org.uk2026-05-18T16:51:43Zurn:sha1:7071a5e65591a7257f41eb7674ca379a7fc68fe5
As pointed out in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3985#note_3413185
this was a duplicate.
The new NoFurtherArguments
* Implements encoding
* Implements more traits
* Is in the right module (types::misc - it's not just for parsing)
* Has a slightly better name
* Had an open-coded parsing impl (which we now replace)
* Had minor differences to docs (so we add a line to NoFurtherArguments)
Fix typos2026-03-24T16:04:08ZTobias Stoeckmanntobias@stoeckmann.org2026-03-24T16:04:08Zurn:sha1:1fb2b8dd4aee7c943ce90d6631be473f2a296fe6
Typos found with codespell
tor-netdoc: signature orderliness: change terminology2026-03-19T10:37:47ZIan Jacksonijackson@chiark.greenend.org.uk2026-03-18T16:18:19Zurn:sha1:7108314102c3e1f41b146a4c8e2d69e2727ea538
"Regular" is confusing, especially since in American English it tends
to mean "usual" - whereas, there are no orderly signatures in Tor
netdocs.
tor-netdoc: parse2: Include body length in SignaturesData2026-03-19T10:37:47ZIan Jacksonijackson@chiark.greenend.org.uk2026-03-10T18:03:31Zurn:sha1:3b363ca3f616dc2e7242a3206d495a12a0dace4c
This could allow users to attach and detach signatures, hash (only)
the body part, etc.
tor-netdoc: parse2: Don't impl NetdocParseable for bodies of signed docs2026-03-19T10:37:47ZIan Jacksonijackson@chiark.greenend.org.uk2026-03-11T12:24:55Zurn:sha1:5e5dc10f0f4d477bf0e8e4d2197610c149a59541
Such an impl is a footgun. Explain this in docs & comments.
tor-netdoc: parse2: Don't impl NetdocParseable for bodies of signed docs (pre-fmt)2026-03-19T10:37:47ZIan Jacksonijackson@chiark.greenend.org.uk2026-03-11T12:24:50Zurn:sha1:e98087c302527047d3505d03b424b2e8ef8cf605tor-netdoc: parse2: Move hash out of signature items2026-03-19T10:37:47ZIan Jacksonijackson@chiark.greenend.org.uk2026-03-11T13:06:35Zurn: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.
tor-netdoc: parse2: SignatureHashInputs: Include document so far2026-03-19T10:37:47ZIan Jacksonijackson@chiark.greenend.org.uk2026-03-05T11:05:46Zurn:sha1:34d3e3e857d64c5ef96c45e9241b78fde1cb0f2d