id(list/find): blob-name TSV output renders names raw — a newline in a remote node's blob name forges extra rows in id list and id find, and a tab forges columns #1742

Problem

The blob-name plain-text renderers in pkgs/id print stored names raw in a tab-separated, one-row-per-item format. A blob name containing a newline forges extra rows, and a tab forges extra columns — the same row-forgery class fixed for claim/doc/group in #1611 (merged in #1703) and filed separately for peers (#1613) and meta-tags (#1735), but never filed for the blob list/find renderers.

Evidence (verified this run on main 0e245370)

• Name storage accepts the characters: src/fileops.rs:170-178 — FileOps::put rejects only a name that is empty after trim; a name containing \n or \t is stored as the blob's tag verbatim.
• Server pass-through: src/protocol.rs:556-562 — the MetaRequest::List handler copies each tag name with String::from_utf8_lossy into MetaResponse::List items with no escaping or validation.
• id list renders raw in all three modes:
  • src/commands/list.rs:91 (via local serve): println!("{hash}\t{name}")
  • src/commands/list.rs:110 (direct store): println!("{}\t{}", item.hash, name)
  • src/commands/list.rs:157 (remote node): println!("{hash}\t{name}") — this is the attacker-controlled case: listing a remote node's store prints that node's names.
• REPL list renders raw the same way: src/commands/repl.rs:439 (serve) and src/commands/repl.rs:452 (local).
• id find renders raw: src/helpers.rs:158-166 (print_match_cli), src/helpers.rs:190-220 (print_matches_cli, including the [query] group header), and src/helpers.rs:246-257 (print_match_repl) interpolate m.name (and the query) with \t separators and no quoting. Find matches against a remote node carry that node's names.

So a node that stores a blob under the name x\n<64-hex>\tfake.txt makes every client that runs id list <that-node> or a remote id find print a forged row that is indistinguishable from a real <hash>\t<name> row — a script parsing the output (the documented format, src/commands/list.rs:8-15) reads a hash/name pair the listing node never had.

Why it matters

id list / id find output is the machine-readable surface other tools and scripts parse. Row forgery by a remote (or merely careless) naming node corrupts inventories, can point a downstream id get at a name/hash pairing that does not exist on the listing node, and breaks the one-row-per-item invariant the rest of the fleet's plain-text output now guarantees after #1611/#1703.

Acceptance criteria

• A blob name containing \n, \r, \t, or other control characters renders in id list (CLI serve/store/remote modes and the REPL list) as exactly one physical line with the name unambiguously delimited (e.g. the JSON-string quoting rule id(claim/doc/group): plain-text output renders names/values raw — a newline in a tag name or value forges extra rows and duplicate author=/event= fields #1611/id: quote whitespace/control values in plain-text renderer so rows cannot be forged (#1611) #1703 adopted for commands/group.rs text()), and a tab in a name cannot create a second column.
• The same quoting applies to names (and the query header) in print_match_cli, print_matches_cli, and print_match_repl used by id find and the REPL.
• Names without whitespace/control characters render byte-identically to today, and any --json output is unchanged.
• Regression tests at the renderer level: a name with an embedded newline + forged <hash>\t<name> payload produces one line whose only unquoted hash column is the real one; a tabbed name stays one column.
• Existing id crate tests still pass (laptop or CI).

Dedup

Searched open + recently closed issues for list/find/helpers TSV, newline and forgery terms. #1611/#1703 covered only the shared tokens() renderer in claim/doc/group; #1613 is peers/gossip; #1735 is commands/tag.rs meta-tag rows. The blob-name renderers in commands/list.rs, commands/repl.rs, and helpers.rs are not covered by any of them.