Skip to content

fix(daemon): answer the client when its binary image is rejected (#1383) - #1439

Merged
DeusData merged 1 commit into
mainfrom
fix/1383-image-rejection-response
Aug 4, 2026
Merged

fix(daemon): answer the client when its binary image is rejected (#1383)#1439
DeusData merged 1 commit into
mainfrom
fix/1383-image-rejection-response

Conversation

@DeusData

@DeusData DeusData commented Aug 4, 2026

Copy link
Copy Markdown
Owner

Part of #1383 (the client-hang half).

Root cause

The image-verification rejection was the only admission-failure path that never sent a hello response — version conflicts and capacity rejections both answer the peer. The client sat on status: "pending" indefinitely, indistinguishable from a slow cold start, with daemon.client_image_rejected visible only in the daemon log.

Fix

The rejection now sends a CONNECT_REJECTED hello response carrying the reason (fingerprint_mismatch / image_unverifiable) and an actionable message, in the same style as the cache-dir conflict message the reporter praised. Security posture unchanged: the version-conflict path already responds to unverified same-uid peers before image verification, and admission stays rejected either way.

Adds a CBM_ENABLE_TEST_SEAMS-only seam forcing peer-image verification to fail — the in-process harness's peer pid is OS-authenticated socket credentials, so the rejection path was untestable without it.

Verification

  • daemon_runtime_image_rejection_reaches_client_issue1383: client receives CONNECT_REJECTED with the reason in the message. RED without the response block (client times out in CONNECT_ERROR — the pending-forever symptom), GREEN with it.
  • daemon_runtime + daemon_ipc + daemon: 102 passed. lint-ci clean.

Not in this PR

Why the reporter's Linux 6.x box failed to fingerprint a byte-identical peer at all (image_unverifiable from /proc/<pid>/exe acquire) — content-based admission of byte-identical binaries is already the implemented model, so their case should have been admitted. Needs reporter environment data; follow-up question going on the issue.

An image-verification rejection logged daemon.client_image_rejected and
finished the worker WITHOUT sending a hello response - the only
admission-failure path that never answered the peer. The client
reported status "pending" indefinitely, indistinguishable from a slow
cold start, with the reason visible only in the daemon log.

The rejection now sends a CONNECT_REJECTED hello response carrying the
reason (fingerprint_mismatch / image_unverifiable) and an actionable
message, matching the version-conflict and capacity paths. The
version-conflict path already responds to unverified peers, so this
discloses nothing new to a same-uid local peer; admission stays
rejected either way.

Adds a CBM_ENABLE_TEST_SEAMS-only seam forcing peer-image verification
to fail, since the in-process harness's peer pid is OS-authenticated
socket credentials and always verifies against the service's own
active image.

Test: daemon_runtime_image_rejection_reaches_client_issue1383 - the
client receives CONNECT_REJECTED with the reason in the message. RED
without the response block (client times out), GREEN with it.

Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
@DeusData
DeusData enabled auto-merge August 4, 2026 17:15
@DeusData
DeusData merged commit 5da4698 into main Aug 4, 2026
34 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant