Trust warning names a binary that does not exist, and prints twice #88

New issue

Closed

opened 2026-08-13 10:08:22 +00:00 by a73x · 0 comments

a73x commented

2026-08-13 10:08:22 +00:00

(Migrated from git.a73x.sh)

A clone with no trusted keys warns on sync, as documented. The text is wrong in the same way bf187d71 fixed elsewhere:

warning: no trusted keys configured — all valid signatures accepted. Run 'collab key add --self' to start.
warning: no trusted keys configured — all valid signatures accepted. Run 'collab key add --self' to start.

Two defects:

collab key add --self is not a command. The binary is git-collab. bf187d71 fixed exactly this in print_sync_summary ("Run `collab sync --remote X`") and this instance was missed. A wrong command in a security-related instruction is worse than most, since the reader is being asked to take an action they may not already know how to take.
It prints twice for a single remote. Observed on a clone with one remote configured.

Found while running a genuine two-clone round trip against the live server. Worth grepping for other occurrences of 'collab in user-facing strings rather than fixing these two — that is twice now that this specific mistake has surfaced in a different message.

Context on the surrounding behaviour, which is correct: the warning fires because a fresh clone has no trusted keys and therefore accepts every valid signature. That is the documented design ("enough to get started, not enough to rely on"). The round trip confirmed both halves: alice, who has trusted keys, rejected a patch signed by an unknown key (Rejecting patches 4c718907: … untrusted key) and accepted it after key add; bob, with no keys, accepted alice's review with this warning.

Migrated from git-collab issue a18e9b76461eb6311df6c79ed2d68afe2c6d788a.

Original author: a73x dev@a73x.sh.

Close reason: merged in patch 81ce00d2

A clone with no trusted keys warns on sync, as documented. The text is wrong in the same way `bf187d71` fixed elsewhere: ``` warning: no trusted keys configured — all valid signatures accepted. Run 'collab key add --self' to start. warning: no trusted keys configured — all valid signatures accepted. Run 'collab key add --self' to start. ``` Two defects: 1. **`collab key add --self` is not a command.** The binary is `git-collab`. bf187d71 fixed exactly this in `print_sync_summary` ("Run \`collab sync --remote X\`") and this instance was missed. A wrong command in a security-related instruction is worse than most, since the reader is being asked to take an action they may not already know how to take. 2. **It prints twice** for a single remote. Observed on a clone with one remote configured. Found while running a genuine two-clone round trip against the live server. Worth grepping for other occurrences of `'collab ` in user-facing strings rather than fixing these two — that is twice now that this specific mistake has surfaced in a different message. Context on the surrounding behaviour, which is correct: the warning fires because a fresh clone has no trusted keys and therefore accepts every valid signature. That is the documented design ("enough to get started, not enough to rely on"). The round trip confirmed both halves: alice, who has trusted keys, **rejected** a patch signed by an unknown key (`Rejecting patches 4c718907: … untrusted key`) and accepted it after `key add`; bob, with no keys, accepted alice's review with this warning. --- Migrated from git-collab issue `a18e9b76461eb6311df6c79ed2d68afe2c6d788a`. Original author: a73x <dev@a73x.sh>. Close reason: merged in patch 81ce00d2