`newHTTPErrorFromResponse` in `pkg/client/oci` can leave the start of a password in `HTTPError.ResponseBody` when a credentialed URL straddles the read cap. Raised in review of [!332](https://gitlab.com/gitlab-org/ops/registry-conformance/-/merge_requests/332), which fixes the same gap for npm. Line references are pinned at `9e0fc823`. The constructor [reads at most `readCap` = 4112 bytes](https://gitlab.com/gitlab-org/ops/registry-conformance/-/blob/9e0fc8230a0ec69df474dc9ad8c00345468af152/pkg/client/oci/client.go#L909-910), then [runs `RedactURLUserinfo` over the read and truncates to 4081 content bytes](https://gitlab.com/gitlab-org/ops/registry-conformance/-/blob/9e0fc8230a0ec69df474dc9ad8c00345468af152/pkg/client/oci/client.go#L925). `RedactURLUserinfo` anchors on the `@`. When a URL's userinfo starts before byte 4081 and its `@` sits at byte 4112 or later, the `@` is never read, nothing matches, and the kept prefix carries the start of the password. Measured on the npm constructor in !332, which has the same shape and constants: a 40-byte password starting at byte 4075 leaks 6 bytes; a 64-byte one starting at byte 4048 leaks 33. Passwords up to 31 bytes are safe. The renderers' `scanFreeText` sees only the clipped body, so the prefix reaches stdout and JUnit as well as library consumers. Not introduced by !332. The npm and OCI constructors share the same read-then-scrub-then-truncate shape and the same constants. ## Proposed fix When the read hits the cap (`len(body) == int(readCap)`), replace a trailing unterminated authority (`[a-zA-Z][a-zA-Z0-9+.\-]*://[^@/?#\s]*$`) with its scheme plus `redact.Sentinel` before the two passes. Add a `client_test.go` case with a 40-byte password whose `@` lands past byte 4112; it turns red without the fix. If !332 lands a fix for npm first, reuse it here. ## Related `pkg/client/maven`'s [`newHTTPErrorFromResponse`](https://gitlab.com/gitlab-org/ops/registry-conformance/-/blob/9e0fc8230a0ec69df474dc9ad8c00345468af152/pkg/client/maven/client.go#L446) runs `ScanContent` only, with no `RedactURLUserinfo` pass, so a credentialed URL with no keyword reaches its `ResponseBody` whole. That is a wider gap than this one and may need its own issue. ## Second case: a read cut short by a transport error The read-cap check above covers a read that stops at `readCap`. A read can also stop early: the server sends less than its `Content-Length`, the connection resets, or the client times out. `io.ReadAll` then returns the partial body with an error, and [`body, _ :=`](https://gitlab.com/gitlab-org/ops/registry-conformance/-/blob/28130d53511ea1f8de3619dba1dbb0ef48215359/pkg/client/oci/client.go#L910) drops it. `len(body)` is below `readCap`, so a body that ends inside `https://ci:<password>` keeps the password prefix. Reproduced in review of !332 on the npm constructor at `28130d53`: a 4xx with `Content-Length: 6000` that sends 4090 bytes ending in `https://ci:` plus part of a password, then closes, leaves 39 password bytes in `ResponseBody`. npm has the same [`body, _ :=`](https://gitlab.com/gitlab-org/ops/registry-conformance/-/blob/28130d53511ea1f8de3619dba1dbb0ef48215359/pkg/client/npm/client.go#L498), and !332 does not fix this case, so this issue covers npm for it too. Not introduced by !332: both clients drop the read error on `main`. Fix: keep the read error and run the trailing-authority redaction when `len(body) == int(readCap) || readErr != nil`. Add a case in each client with a reader that returns an error right after `https://ci:<password>`; it turns red without the fix. ## Third case: redaction before the cut can drop the truncation marker `truncateBody` ([npm](https://gitlab.com/gitlab-org/ops/registry-conformance/-/blob/28130d53511ea1f8de3619dba1dbb0ef48215359/pkg/client/npm/client.go#L632-640), [oci](https://gitlab.com/gitlab-org/ops/registry-conformance/-/blob/28130d53511ea1f8de3619dba1dbb0ef48215359/pkg/client/oci/client.go#L982-990)) appends `... [truncated]` only when its input is over 4096 bytes, and it receives the scrubbed body. When redaction shrinks a clipped read to 4096 bytes or less, the marker is dropped. That breaks [S04 AC #33](https://gitlab.com/gitlab-org/ops/registry-conformance/-/blob/28130d53511ea1f8de3619dba1dbb0ef48215359/docs/specs/S04-contracts.md#L2528-2531), which requires a 5 KiB body to end with the marker. Both clients have this through `ScanContent` and `RedactURLUserinfo`. The npm read-cap branch from !332 makes it more common. `unterminatedAuthorityPattern` stops only at `@`, `/`, `?`, `#` or whitespace, so in compact JSON it runs from the last path-less URL to the end of the read, even when the body holds no credential. A 6021-byte body of entries like `{"name":"pkg","homepage":"https://example.com","license":"MIT","deprecated":false},` comes back as 4073 bytes ending `"homepage":"https://[REDACTED]`, with no marker. No check's verdict changes, because the error envelope is parsed from the raw body. The cost is a report that shows a clipped body as complete, and a `[REDACTED]` with no secret behind it. Fix: decide truncation from the raw read. When `len(body) > responseBodyCap`, cut the scrubbed string to `responseBodyCap - len(truncationMarker)` if it is longer, and always append the marker. Pin it with a `strings.HasSuffix(got.ResponseBody, "... [truncated]")` check in the read-cap and straddle tests, plus a compact-JSON row. Land this before copying the read-cap branch into OCI under "Proposed fix" above. While in npm's `newHTTPErrorFromResponse`: `var unterminatedAuthorityPattern` sits directly under the function's doc comment with no blank line, so `go doc` attaches the whole block to the var and the function shows none. Move the var above [L417](https://gitlab.com/gitlab-org/ops/registry-conformance/-/blob/28130d53511ea1f8de3619dba1dbb0ef48215359/pkg/client/npm/client.go#L417).