docs(audit): U22 says what the log's redaction removes on the new base

The branch was replayed onto release/2.0 at 4e01519, which has the
redaction fixes that closed W40. U22 said that the log's redaction
removes only the value of state from the text of a failed browser start
and that id_token_hint passes unchanged. That was true where it was
found, at ebea861, and is not true any more.

Run against the replayed head, in a scratch copy, with the text Windows
gives for a failed start: the sign-out address loses its id_token_hint
and its state; the sign-in address loses its state and keeps its nonce
and code_challenge. The row now says what held when it was found and
what holds now. Nothing else in it changes: BrowserLaunch keeps the
address out of the line whatever the redaction does.

Signed-off-by: James Maes <james@kof22.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

docs/AUDIT-2026-11-10.md

@@ -273,7 +273,7 @@ Found while building the companion's sign-in for the connection wizard (2026-11-
 
 | ID | Severity | Finding | Status |
 | --- | --- | --- | --- |
-| U22 | Not rated | A browser that cannot be started puts the address it was asked to open into the companion's log and, at sign-in, into the dialog. The companion starts the browser through the Windows shell, and when that fails .NET's failure text names what could not be started: "An error occurred trying to start process '<the whole address>' ..." (seen on .NET 10.0.14 with a shell start of a file that does not exist; no browser was involved). At a browser sign-in the address is the provider's authorization address, with that attempt's `state`, `nonce` and `code_challenge`; the text was logged at error level and shown as the reason of "Browser sign-in not completed", and the whole failure was logged again as debug detail (`SignInFlow.Browser.cs:98-103`, started at `:152`, read at `ebea861`). At a provider sign-out the address is the provider's end-session address, with the `id_token_hint` (the provider's ID token) and the sign-out's `state`; the text was logged as a warning and not shown (`SignInFlow.SignOut.cs:121-125`, started at `:114`). The log file's own redaction removes the value of `state` from such a line in 2.0 and nothing else of it; `id_token_hint=` passes unchanged, which is the gap W40 records, and W40's note that no log line can carry it did not hold for this one. The dialog's message is not redacted at all. It takes a failed browser start to happen: no default browser, or a broken handler for web addresses. Tags (from `git tag --contains` and the code at each tag): the sign-in case is in the eleven version tags from `v0.2.0-rc.1` to `v1.2.1` and in `snapshot-2.0.0-rc.1`; the four 0.1.x tags have no browser sign-in. It was introduced by `2c1c5f1` (2026-10-31); in `v1.2.1` the start is `src/Qqq.PrintAgent/MainWindow.Authentication.cs:339` and the catch that logs and shows the text is at `:294-298`, and 1.2.1's log has no rule for `state`, so installed 1.2.x systems write and show the address whole. The sign-out case came with `5d4b7f4` (2026-11-09) and is in one tag, `snapshot-2.0.0-rc.1`, and in no version tag. That snapshot (commit `6f0237d`) has both cases unguarded (`SignInFlow.Browser.cs:152`, `SignInFlow.SignOut.cs:114`); `docs/SESSION-STATE.md` records it as a Gitea prerelease published on 2026-11-10 as a development snapshot and not installed anywhere. The unreleased `release/1.2.2` branch, which is in no tag, has both cases too (`MainWindow.Authentication.cs:303`, `:311` for the sign-out; `:395`, `:354` for the sign-in). Read from the code in each case, not run | Closed for 2.0 builds after `snapshot-2.0.0-rc.1` by the change that adds this row: every browser start in the presentation assembly goes through `BrowserLaunch`, which replaces the failure with fixed text (that the default browser could not be opened, the kind of failure or the Windows error number, and what to check), in the dialog's flow and in the new `CompanionSignIn` and `ProviderSignOut`. The snapshot itself has both cases and stays as published. Open for 1.2.x: `release/1.2.2` still has both cases, and 1.2.1 as installed has the sign-in case |
+| U22 | Not rated | A browser that cannot be started puts the address it was asked to open into the companion's log and, at sign-in, into the dialog. The companion starts the browser through the Windows shell, and when that fails .NET's failure text names what could not be started: "An error occurred trying to start process '<the whole address>' ..." (seen on .NET 10.0.14 with a shell start of a file that does not exist; no browser was involved). At a browser sign-in the address is the provider's authorization address, with that attempt's `state`, `nonce` and `code_challenge`; the text was logged at error level and shown as the reason of "Browser sign-in not completed", and the whole failure was logged again as debug detail (`SignInFlow.Browser.cs:98-103`, started at `:152`, read at `ebea861`). At a provider sign-out the address is the provider's end-session address, with the `id_token_hint` (the provider's ID token) and the sign-out's `state`; the text was logged as a warning and not shown (`SignInFlow.SignOut.cs:121-125`, started at `:114`). When this was found (at `ebea861`) the log file's own redaction removed the value of `state` from such a line in 2.0 and nothing else of it: `id_token_hint=` passed unchanged, which was the gap W40 recorded, and W40's note that no log line can carry it did not hold for this one. The redaction fixes that closed W40 now remove the ID token hint as well; a sign-in address still keeps its `nonce` and `code_challenge` (run against 2.0 at `4e01519`, with the text Windows gives for a failed start). The dialog's message is not redacted at all. It takes a failed browser start to happen: no default browser, or a broken handler for web addresses. Tags (from `git tag --contains` and the code at each tag): the sign-in case is in the eleven version tags from `v0.2.0-rc.1` to `v1.2.1` and in `snapshot-2.0.0-rc.1`; the four 0.1.x tags have no browser sign-in. It was introduced by `2c1c5f1` (2026-10-31); in `v1.2.1` the start is `src/Qqq.PrintAgent/MainWindow.Authentication.cs:339` and the catch that logs and shows the text is at `:294-298`, and 1.2.1's log has no rule for `state`, so installed 1.2.x systems write and show the address whole. The sign-out case came with `5d4b7f4` (2026-11-09) and is in one tag, `snapshot-2.0.0-rc.1`, and in no version tag. That snapshot (commit `6f0237d`) has both cases unguarded (`SignInFlow.Browser.cs:152`, `SignInFlow.SignOut.cs:114`); `docs/SESSION-STATE.md` records it as a Gitea prerelease published on 2026-11-10 as a development snapshot and not installed anywhere. The unreleased `release/1.2.2` branch, which is in no tag, has both cases too (`MainWindow.Authentication.cs:303`, `:311` for the sign-out; `:395`, `:354` for the sign-in). Read from the code in each case, not run | Closed for 2.0 builds after `snapshot-2.0.0-rc.1` by the change that adds this row: every browser start in the presentation assembly goes through `BrowserLaunch`, which replaces the failure with fixed text (that the default browser could not be opened, the kind of failure or the Windows error number, and what to check), in the dialog's flow and in the new `CompanionSignIn` and `ProviderSignOut`. The snapshot itself has both cases and stays as published. Open for 1.2.x: `release/1.2.2` still has both cases, and 1.2.1 as installed has the sign-in case |
 
 ### Repository