GITS-364: fix(ghostty-ssh-fixture): re-sync vendored sshd-fixture.sh to app live 7ad2dfee #709

Merged

pi-landing merged 1 commit from plane/GITS-364-emu-drift-fix into live 2026-10-31 07:59:33 +00:00

Conversation 4 Commits 1 Files changed 3 +67 -13

aaron commented 2026-10-31 07:27:43 +00:00

Owner

Copy link

What

The required emu drift gate in Homelab/ghostty-in-the-shell .forgejo/workflows/emu.yaml (GITS-23 / E0.T14, PR #71) compares sha256sum /fixture/bin/sshd-fixture.sh inside the pinned FIXTURE_IMAGE against the app repo's live fixtures/sshd-fixture.sh. Since #71 merged, every app PR fails the required emu context:

• app repo live script: 7ad2dfee…aed9 (post-GITS-306 fail-closed resolver, GITS-349 SFTP subsystem, GITS-350 loopback-only AllowTcpForwarding local + PermitOpen 127.0.0.1:*)
• pinned image label com.ghostty.fixture-script.sha256: 18bbafe7…e686 — a hand-appended layer on the stale E0.T12 image (GITS-346 history: first append had wrong uid, second lacked dir entries; both problems were patched ad hoc)
• this repo's vendored copy: fe89658c…f804 (pre-GITS-306), with the Dockerfile ARG default and the emu-images.yaml verify-step env pinning the same stale hash

This PR is the proper rebuild path, not another appended layer:

1. platform/ghostty-ssh-fixture/fixtures/sshd-fixture.sh — byte-identical copy of Homelab/ghostty-in-the-shell live fixtures/sshd-fixture.sh at d50a714 (sha256 verified 7ad2dfee…aed9).
2. platform/ghostty-ssh-fixture/Dockerfile — FIXTURE_SCRIPT_SHA256 default → 7ad2dfee…; header comment now records the sync contract (vendored copy + ARG default + workflow verify pin move together). RUN-stage self-test contract unchanged and still satisfied by the new script (start --session default refused, start/sshd -t/stop round-trip, env/add-key present).
3. .forgejo/workflows/emu-images.yaml — verify-step FIXTURE_SCRIPT_SHA256 env pin updated in lockstep.

Proof surface (PR-head CI, per this workflow's design)

The build-fixture job on this head must show, all fail-capable:

• RUN-stage self-test re-printed against the finished image (sha256 pin == vendored script, herdr --version == herdr 0.9.1, start --session default exits non-zero with the refusal message)
• runtime control API: add-key + real ssh login over the fixture sshd
• keystore/docker-config scan prints nothing (no secret material), plus the planted-keystore negative test
• wrong HERDR_SHA256 and wrong FIXTURE_SCRIPT_SHA256 build-args each fail the build (mismatched-pin failure)

Stage 2 (after landing workers merge this)

The push to live run publishes the corrected image (tag <merge-short-sha>). Then the app repo PR (GITS-364 stage 2) changes only the FIXTURE_IMAGE tag/digest in .forgejo/workflows/emu.yaml to that published immutable digest, restoring repo copy == vendored drift. Landing pipeline (independent review, merge by landing worker) owns both merges; the orchestrator does not merge.

Ref: GITS-364, GITS-346, GITS-306, GITS-349, GITS-350, GITS-21/E0.T12, GITS-23/E0.T14.

## What The required `emu` drift gate in `Homelab/ghostty-in-the-shell` `.forgejo/workflows/emu.yaml` (GITS-23 / E0.T14, PR #71) compares `sha256sum /fixture/bin/sshd-fixture.sh` inside the pinned `FIXTURE_IMAGE` against the app repo's live `fixtures/sshd-fixture.sh`. Since #71 merged, **every app PR fails the required emu context**: - app repo live script: `7ad2dfee…aed9` (post-GITS-306 fail-closed resolver, GITS-349 SFTP subsystem, GITS-350 loopback-only `AllowTcpForwarding local` + `PermitOpen 127.0.0.1:*`) - pinned image label `com.ghostty.fixture-script.sha256`: `18bbafe7…e686` — a **hand-appended layer** on the stale E0.T12 image (GITS-346 history: first append had wrong uid, second lacked dir entries; both problems were patched ad hoc) - this repo's vendored copy: `fe89658c…f804` (pre-GITS-306), with the Dockerfile ARG default and the emu-images.yaml verify-step env pinning the same stale hash This PR is the **proper rebuild path**, not another appended layer: 1. `platform/ghostty-ssh-fixture/fixtures/sshd-fixture.sh` — byte-identical copy of `Homelab/ghostty-in-the-shell` live `fixtures/sshd-fixture.sh` at `d50a714` (sha256 verified `7ad2dfee…aed9`). 2. `platform/ghostty-ssh-fixture/Dockerfile` — `FIXTURE_SCRIPT_SHA256` default → `7ad2dfee…`; header comment now records the sync contract (vendored copy + ARG default + workflow verify pin move together). RUN-stage self-test contract unchanged and still satisfied by the new script (`start --session default` refused, `start`/`sshd -t`/`stop` round-trip, `env`/`add-key` present). 3. `.forgejo/workflows/emu-images.yaml` — verify-step `FIXTURE_SCRIPT_SHA256` env pin updated in lockstep. ## Proof surface (PR-head CI, per this workflow's design) The `build-fixture` job on this head must show, all fail-capable: - RUN-stage self-test re-printed against the finished image (sha256 pin == vendored script, `herdr --version` == `herdr 0.9.1`, `start --session default` exits non-zero with the refusal message) - runtime control API: `add-key` + real ssh login over the fixture sshd - keystore/docker-config scan prints nothing (no secret material), plus the planted-keystore negative test - wrong `HERDR_SHA256` and wrong `FIXTURE_SCRIPT_SHA256` build-args each fail the build (mismatched-pin failure) ## Stage 2 (after landing workers merge this) The `push to live` run publishes the corrected image (tag `<merge-short-sha>`). Then the app repo PR (GITS-364 stage 2) changes **only** the `FIXTURE_IMAGE` tag/digest in `.forgejo/workflows/emu.yaml` to that published immutable digest, restoring `repo copy == vendored` drift. Landing pipeline (independent review, merge by landing worker) owns both merges; the orchestrator does not merge. Ref: GITS-364, GITS-346, GITS-306, GITS-349, GITS-350, GITS-21/E0.T12, GITS-23/E0.T14.

aaron added 1 commit 2026-10-31 07:27:43 +00:00

GITS-364: fix(ghostty-ssh-fixture): re-sync vendored sshd-fixture.sh to app live (7ad2dfee) ... e402bbb194

The required emu drift gate (ghostty-in-the-shell .forgejo/workflows/emu.yaml,
GITS-23/E0.T14) compares sha256 of /fixture/bin/sshd-fixture.sh inside the
pinned FIXTURE_IMAGE against the app repo's live fixtures/sshd-fixture.sh.
The vendored copy here still pinned the pre-GITS-306 script (fe89658c) while
the app repo live script is 7ad2dfee (GITS-306 fail-closed resolver, GITS-349
SFTP subsystem, GITS-350 loopback-only forwarding), so every app PR now fails
drift. The currently pinned image (653f4022) is a hand-appended layer carrying
18bbafe7 (GITS-346) — also stale. Proper rebuild instead of another appended
layer:

- platform/ghostty-ssh-fixture/fixtures/sshd-fixture.sh: byte-identical copy
  of Homelab/ghostty-in-the-shell live (d50a714) fixtures/sshd-fixture.sh
- Dockerfile: FIXTURE_SCRIPT_SHA256 default pin -> 7ad2dfee..., header comment
  updated; RUN-stage self-test contract unchanged and still satisfied (start
  refuses 'default', start/sshd -t/stop round-trip, add-key/env/stop present)
- .forgejo/workflows/emu-images.yaml: verify-step FIXTURE_SCRIPT_SHA256 env
  pin updated in lockstep with the ARG default

After this lands on live, the workflow publishes the corrected image; the app
repo then re-pins FIXTURE_IMAGE to that immutable digest (GITS-364 stage 2).

ld-reviewer approved these changes 2026-10-31 07:29:54 +00:00

Dismissed

ld-reviewer left a comment

Collaborator

Copy link

Verdict: APPROVED

model: deepseek/deepseek-flash
head: e402bbb194

Dangerous class: this edits .forgejo/workflows/emu-images.yaml, an oversight path, so it needs two verdicts on different declared models with one premium at this head. This is one of them. The change itself is small (3 files, +161/−7 lines) and I verified the claim that carries the whole PR by hashing the files myself rather than reading the numbers:

• The vendored copy is genuinely the app's live script. I fetched platform/ghostty-ssh-fixture/fixtures/sshd-fixture.sh at this head and Homelab/ghostty-in-the-shell's fixtures/sshd-fixture.sh at live independently: both are 7ad2dfeebae106b9d033f5843378d49dfb7241e14f0c08134f0d21f83264aed9, and cmp reports them byte-identical. The body's "byte-identical copy at d50a714" is true.
• All three pins are the same value: the file hash, ARG FIXTURE_SCRIPT_SHA256= in the Dockerfile, and the workflow's verify-step FIXTURE_SCRIPT_SHA256: env — 7ad2dfee… in each. That is the lockstep the header now records, and it is the failure the previous two hand-appended layers kept producing.
• The image label follows the pin rather than repeating it: com.ghostty.fixture-script.sha256="${FIXTURE_SCRIPT_SHA256}" is derived from the ARG, so the label the app's emu drift gate compares will carry the new hash once this image is built. No third place to forget.
• The pin is enforced, not decorative: sha256sum --check --strict runs at build time on /fixture/bin/sshd-fixture.sh (Dockerfile line 58) and again inside the self-test (line 82), so a mismatched --build-arg fails the image rather than producing a mislabeled one.
• The workflow change is only the env pin plus a comment: no new steps, triggers, permissions or environment. The rest of the diff is the vendored script and two Dockerfile comments.

Two things the landing record should carry, neither a condition:

1. This PR is stage 1 of 2, and alone it does not restore the app's emu context. The Homelab/ghostty-in-the-shell required check still pins the stale FIXTURE_IMAGE; it goes green only when stage 2 bumps it to the digest this merge publishes. Until then every app PR keeps failing the required emu context, which is the state the ticket exists to end — so the two merges should be treated as one unit of work, and stage 2 must pin the digest (immutable), not the <merge-short-sha> tag the publish run creates.
2. The redeploy path this replaces was two ad-hoc appended layers with hand-patched uid/dir-entry fixes (GITS-346). The header's "when the app script moves again, all three move together" is now the durable answer to that — worth keeping in the ticket's close-out so the next hand-append is visibly the wrong move.

Post-merge proof is the publish run's unchanged fail-capable surface: the re-printed RUN self-test against the finished image, herdr --version, the start --session default refusal, the runtime add-key + real ssh login, the keystore/docker-config scan printing nothing, and the two wrong-build-arg negatives.

No file edits, no commits, no merges from me.

## Verdict: APPROVED model: deepseek/deepseek-flash head: e402bbb194dbcebfd682da9044ddd063786b97b2 **Dangerous class**: this edits `.forgejo/workflows/emu-images.yaml`, an oversight path, so it needs two verdicts on different declared models with one premium at this head. This is one of them. The change itself is small (3 files, +161/−7 lines) and I verified the claim that carries the whole PR by hashing the files myself rather than reading the numbers: - **The vendored copy is genuinely the app's live script.** I fetched `platform/ghostty-ssh-fixture/fixtures/sshd-fixture.sh` at this head and `Homelab/ghostty-in-the-shell`'s `fixtures/sshd-fixture.sh` at `live` independently: both are `7ad2dfeebae106b9d033f5843378d49dfb7241e14f0c08134f0d21f83264aed9`, and `cmp` reports them **byte-identical**. The body's "byte-identical copy at `d50a714`" is true. - **All three pins are the same value**: the file hash, `ARG FIXTURE_SCRIPT_SHA256=` in the Dockerfile, and the workflow's verify-step `FIXTURE_SCRIPT_SHA256:` env — `7ad2dfee…` in each. That is the lockstep the header now records, and it is the failure the previous two hand-appended layers kept producing. - **The image label follows the pin rather than repeating it**: `com.ghostty.fixture-script.sha256="${FIXTURE_SCRIPT_SHA256}"` is derived from the ARG, so the label the app's `emu` drift gate compares will carry the new hash once this image is built. No third place to forget. - **The pin is enforced, not decorative**: `sha256sum --check --strict` runs at build time on `/fixture/bin/sshd-fixture.sh` (Dockerfile line 58) and again inside the self-test (line 82), so a mismatched `--build-arg` fails the image rather than producing a mislabeled one. - **The workflow change is only the env pin** plus a comment: no new steps, triggers, permissions or environment. The rest of the diff is the vendored script and two Dockerfile comments. Two things the landing record should carry, neither a condition: 1. **This PR is stage 1 of 2, and alone it does not restore the app's `emu` context.** The `Homelab/ghostty-in-the-shell` required check still pins the stale `FIXTURE_IMAGE`; it goes green only when stage 2 bumps it to the digest this merge publishes. Until then every app PR keeps failing the required `emu` context, which is the state the ticket exists to end — so the two merges should be treated as one unit of work, and stage 2 must pin the **digest** (immutable), not the `<merge-short-sha>` tag the publish run creates. 2. The redeploy path this replaces was two ad-hoc appended layers with hand-patched uid/dir-entry fixes (GITS-346). The header's "when the app script moves again, all three move together" is now the durable answer to that — worth keeping in the ticket's close-out so the next hand-append is visibly the wrong move. Post-merge proof is the publish run's unchanged fail-capable surface: the re-printed RUN self-test against the finished image, `herdr --version`, the `start --session default` refusal, the runtime `add-key` + real ssh login, the keystore/docker-config scan printing nothing, and the two wrong-build-arg negatives. No file edits, no commits, no merges from me.

ld-reviewer approved these changes 2026-10-31 07:52:08 +00:00

Dismissed

ld-reviewer left a comment

Collaborator

Copy link

Verdict: APPROVED — head e402bbb194

model: omniroute/kimi-pool
head: e402bbb194

Dangerous class (.forgejo/workflows/emu-images.yaml, oversight path): second verdict on a different declared model, premium tier, on the current head. All checks below are my own against primary sources — PR diff, GITS-364/GITS-346 (Plane REST, project 4d1ea3eb), app repo live d50a714, CI runs 2532–2534 on this exact SHA.

• Byte sync, independently re-hashed: sha256sum of the PR's vendored fixtures/sshd-fixture.sh = 7ad2dfee…aed9; cmp against Homelab/ghostty-in-the-shell live working tree at d50a714 reports byte-identical. The "byte-identical to app live" claim is true.
• All three pins lockstep: vendored script hash, ARG FIXTURE_SCRIPT_SHA256 default in the Dockerfile, and the workflow verify-step env pin are all 7ad2dfee…; the OCI label is derived from the ARG (com.ghostty.fixture-script.sha256="${FIXTURE_SCRIPT_SHA256}"), so the label the app drift gate compares cannot drift from the pin.
• Proper rebuild, not an appended-layer workaround: the Dockerfile COPYs the script and enforces sha256sum --check --strict at build time plus inside the RUN-stage self-test — a mismatched build-arg fails the image. This replaces the GITS-346 hand-appended-layer history with a from-base rebuild.
• Fail-capable proof surface, green on this head: CI 2532–2534 all pass on e402bbb194; the build-fixture job's steps are each capable of failing — RUN-stage self-test re-print (pin check, herdr --version == herdr 0.9.1, start --session default refused non-zero), runtime control API (add-key + real ssh login over the fixture sshd), keystore/docker-config scan printing nothing plus its planted-keystore negative, and wrong-HERDR_SHA256 / wrong-FIXTURE_SCRIPT_SHA256 build-arg negatives. Green jobs imply all of these ran and passed.
• Claim honesty on scope: this is honestly stage 1 of 2 — merging alone does not restore the app's required emu context, because app live still pins the stale FIXTURE_IMAGE digests (653f4022… in emu.yaml, 235043d0… in probe-emu.yaml); green returns only when stage 2 pins the immutable digest the post-merge live publish run reads back with crane. Sequencing is sound (the digest cannot exist before this merge); landing continuation must treat both merges as one unit.
• Post-merge proof design: push is live-only (if: github.event_name != 'pull_request'), scoped robot creds via env (never inlined), throwaway DOCKER_CONFIG, immutable short-sha tag, crane digest readback — then stage-2 app PR whose drift step itself guards parity going forward.

No file edits, no commits, no merges from me.

## Verdict: APPROVED — head e402bbb194dbcebfd682da9044ddd063786b97b2 model: omniroute/kimi-pool head: e402bbb194dbcebfd682da9044ddd063786b97b2 **Dangerous class** (`.forgejo/workflows/emu-images.yaml`, oversight path): second verdict on a different declared model, premium tier, on the current head. All checks below are my own against primary sources — PR diff, GITS-364/GITS-346 (Plane REST, project 4d1ea3eb), app repo live `d50a714`, CI runs 2532–2534 on this exact SHA. - **Byte sync, independently re-hashed**: `sha256sum` of the PR's vendored `fixtures/sshd-fixture.sh` = `7ad2dfee…aed9`; `cmp` against `Homelab/ghostty-in-the-shell` live working tree at `d50a714` reports **byte-identical**. The "byte-identical to app live" claim is true. - **All three pins lockstep**: vendored script hash, `ARG FIXTURE_SCRIPT_SHA256` default in the Dockerfile, and the workflow verify-step env pin are all `7ad2dfee…`; the OCI label is derived from the ARG (`com.ghostty.fixture-script.sha256="${FIXTURE_SCRIPT_SHA256}"`), so the label the app drift gate compares cannot drift from the pin. - **Proper rebuild, not an appended-layer workaround**: the Dockerfile `COPY`s the script and enforces `sha256sum --check --strict` at build time plus inside the RUN-stage self-test — a mismatched build-arg fails the image. This replaces the GITS-346 hand-appended-layer history with a from-base rebuild. - **Fail-capable proof surface, green on this head**: CI 2532–2534 all pass on `e402bbb194`; the build-fixture job's steps are each capable of failing — RUN-stage self-test re-print (pin check, `herdr --version` == `herdr 0.9.1`, `start --session default` refused non-zero), runtime control API (`add-key` + real ssh login over the fixture sshd), keystore/docker-config scan printing nothing plus its planted-keystore negative, and wrong-`HERDR_SHA256` / wrong-`FIXTURE_SCRIPT_SHA256` build-arg negatives. Green jobs imply all of these ran and passed. - **Claim honesty on scope**: this is honestly stage 1 of 2 — merging alone does not restore the app's required `emu` context, because app live still pins the stale `FIXTURE_IMAGE` digests (`653f4022…` in `emu.yaml`, `235043d0…` in `probe-emu.yaml`); green returns only when stage 2 pins the **immutable digest** the post-merge live publish run reads back with crane. Sequencing is sound (the digest cannot exist before this merge); landing continuation must treat both merges as one unit. - **Post-merge proof design**: push is live-only (`if: github.event_name != 'pull_request'`), scoped robot creds via env (never inlined), throwaway DOCKER_CONFIG, immutable short-sha tag, `crane digest` readback — then stage-2 app PR whose drift step itself guards parity going forward. No file edits, no commits, no merges from me.

ld-reviewer approved these changes 2026-10-31 07:52:51 +00:00

ld-reviewer left a comment

Collaborator

Copy link

Verdict: APPROVED — head e402bbb194

model: omniroute/deepseek-flash
head: e402bbb194
verified: PR#709 diff at head · GITS-364 + GITS-346 (Plane project 4d1ea3eb) · app repo live d50a7142 fixtures/sshd-fixture.sh · CI runs 2532/2533/2534 on this head · build-fixture job log
scope: dangerous-class independent review, fresh context, primary sources only

Byte equality and pin lockstep

• platform/ghostty-ssh-fixture/fixtures/sshd-fixture.sh at this head hashes to 7ad2dfee…aed9; the app repo live (d50a7142) copy hashes to the same value and cmp reports byte-identical. Git mode 100755 preserved, so it stays executable as the entrypoint.
• The pin appears as exactly two literals in the tree — Dockerfile ARG FIXTURE_SCRIPT_SHA256 and the emu-images.yaml verify-step env — plus the vendored file itself. Neither the stale fe89658c… nor the appended-layer 18bbafe7… occurs anywhere at this head, so no third copy was missed.

Rebuild, not another appended layer

The publish path is docker build -f platform/ghostty-ssh-fixture/Dockerfile from debian:bookworm-slim, docker push <IMAGE>:<short-sha>, then crane digest readback. The workflow contains no crane append/mutate/copy at all; the script arrives by COPY and is verified inside the build (Step 11/22 … /fixture/bin/sshd-fixture.sh: OK). That is a clean rebuild from the Dockerfile, which is what the stale/appended history needed.

Fixture contract proved on this head

The build-fixture job log shows the RUN-stage self-test passing end to end: pin check OK, herdr 0.9.1, start --session default exit 1, and a real start / sshd -t / stop round-trip that also exercises the new resolver's stop-target line. Runtime control API: add-key, then a real ssh -i … -p <port> fixture@127.0.0.1 true login. Negative controls are fail-capable and actually fired: the planted keystore printed /planted.p12 with exit 1, and the wrong HERDR_SHA256 and wrong FIXTURE_SCRIPT_SHA256 builds each failed as required. The clean scan printed nothing.
No secret material in the diff: it changes comments, two pin literals and the script body only; no key/token/password patterns; the push steps are gated off pull-request events, so this run carried no registry credential.

New script semantics

Fail-closed FIX_DIR (GITS-306), the stop-target log line, the FIX vs FIX_DIR refusal before any destructive step, loopback-only AllowTcpForwarding local + PermitOpen 127.0.0.1:* (GITS-350) and Subsystem sftp internal-sftp (GITS-349). All of it is confined to a throwaway fixture reachable only from inside its own container, and sshd -t accepts the generated config.

Findings

Concerns, none gating:

1. Publish and digest readback run only on push to live, so this head proves the build, not a published digest. That is the workflow's design and the PR states it; closing the drift is Stage 2, pinning FIXTURE_IMAGE to the digest read back with crane in the app repo.
2. PermitOpen 127.0.0.1:* matches the client-requested host, so a client that asks for localhost can be refused. Fine for the S5 spike; worth knowing if the channel is ever opened by hostname.
3. Nothing mechanically forces the three copies to move together; after Stage 2 the app repo's drift step is the guard, and the Dockerfile header comment is the discovery path. Keep that sentence.

All dimensions clear: acceptance criteria, solution quality, codebase fit, test adequacy (the assertions can fail and did fail in the negative controls), security, and claim honesty — every claim in the PR body reproduced from the job log at this head.

## Verdict: APPROVED — head e402bbb194dbcebfd682da9044ddd063786b97b2 model: omniroute/deepseek-flash head: e402bbb194dbcebfd682da9044ddd063786b97b2 verified: PR#709 diff at head · GITS-364 + GITS-346 (Plane project 4d1ea3eb) · app repo live d50a7142 fixtures/sshd-fixture.sh · CI runs 2532/2533/2534 on this head · build-fixture job log scope: dangerous-class independent review, fresh context, primary sources only ## Byte equality and pin lockstep - `platform/ghostty-ssh-fixture/fixtures/sshd-fixture.sh` at this head hashes to `7ad2dfee…aed9`; the app repo `live` (`d50a7142`) copy hashes to the same value and `cmp` reports byte-identical. Git mode `100755` preserved, so it stays executable as the entrypoint. - The pin appears as exactly two literals in the tree — Dockerfile `ARG FIXTURE_SCRIPT_SHA256` and the `emu-images.yaml` verify-step env — plus the vendored file itself. Neither the stale `fe89658c…` nor the appended-layer `18bbafe7…` occurs anywhere at this head, so no third copy was missed. ## Rebuild, not another appended layer The publish path is `docker build -f platform/ghostty-ssh-fixture/Dockerfile` from `debian:bookworm-slim`, `docker push <IMAGE>:<short-sha>`, then `crane digest` readback. The workflow contains no `crane append/mutate/copy` at all; the script arrives by `COPY` and is verified inside the build (`Step 11/22 … /fixture/bin/sshd-fixture.sh: OK`). That is a clean rebuild from the Dockerfile, which is what the stale/appended history needed. ## Fixture contract proved on this head The `build-fixture` job log shows the RUN-stage self-test passing end to end: pin check OK, `herdr 0.9.1`, `start --session default` exit 1, and a real `start` / `sshd -t` / `stop` round-trip that also exercises the new resolver's stop-target line. Runtime control API: `add-key`, then a real `ssh -i … -p <port> fixture@127.0.0.1 true` login. Negative controls are fail-capable and actually fired: the planted keystore printed `/planted.p12` with exit 1, and the wrong `HERDR_SHA256` and wrong `FIXTURE_SCRIPT_SHA256` builds each failed as required. The clean scan printed nothing. No secret material in the diff: it changes comments, two pin literals and the script body only; no key/token/password patterns; the push steps are gated off pull-request events, so this run carried no registry credential. ## New script semantics Fail-closed `FIX_DIR` (GITS-306), the stop-target log line, the `FIX` vs `FIX_DIR` refusal before any destructive step, loopback-only `AllowTcpForwarding local` + `PermitOpen 127.0.0.1:*` (GITS-350) and `Subsystem sftp internal-sftp` (GITS-349). All of it is confined to a throwaway fixture reachable only from inside its own container, and `sshd -t` accepts the generated config. ## Findings Concerns, none gating: 1. Publish and digest readback run only on `push` to `live`, so this head proves the build, not a published digest. That is the workflow's design and the PR states it; closing the drift is Stage 2, pinning `FIXTURE_IMAGE` to the digest read back with `crane` in the app repo. 2. `PermitOpen 127.0.0.1:*` matches the client-requested host, so a client that asks for `localhost` can be refused. Fine for the S5 spike; worth knowing if the channel is ever opened by hostname. 3. Nothing mechanically forces the three copies to move together; after Stage 2 the app repo's drift step is the guard, and the Dockerfile header comment is the discovery path. Keep that sentence. All dimensions clear: acceptance criteria, solution quality, codebase fit, test adequacy (the assertions can fail and did fail in the negative controls), security, and claim honesty — every claim in the PR body reproduced from the job log at this head.

ld-reviewer commented 2026-10-31 07:54:07 +00:00

Collaborator

Copy link

Landing-record note from the lane review leg (not a verdict; I am not re-posting mine, which would just dismiss another row).

Rows at this head e402bbb194db, in posting order:

review	declared model	state now
1416	deepseek/deepseek-flash	dismissed
1419	omniroute/kimi-pool (premium)	dismissed
1420	omniroute/deepseek-flash	official, not dismissed

Same hazard as infra-core#708 earlier today (comment 18398): the cross-model + premium evidence for the dangerous-class panel is at this exact head, but Forgejo's same-key dismissal leaves the surviving row a deepseek one. If the landing lock refuses on "no premium verdict", the fix is for the premium reviewer to re-post at this head so the premium row is the last one — do not post another deepseek row, and do not edit or delete anything.

For the record, the substance of my 1416 still stands and I re-verified nothing changed: the vendored fixtures/sshd-fixture.sh at this head and Homelab/ghostty-in-the-shell's live copy are byte-identical (cmp) at 7ad2dfee…aed9, the Dockerfile ARG default and the emu-images.yaml verify-step env carry that same value, the image label is derived from the ARG, and build-fixture/build-emulator are green on this head (#2533) — the build enforces the pin, so the claim is confirmed by both my own hash comparison and the image build itself.

model: deepseek/deepseek-flash

Landing-record note from the lane review leg (not a verdict; I am not re-posting mine, which would just dismiss another row). Rows at this head `e402bbb194db`, in posting order: | review | declared model | state now | |---|---|---| | 1416 | `deepseek/deepseek-flash` | dismissed | | 1419 | **`omniroute/kimi-pool`** (premium) | **dismissed** | | 1420 | `omniroute/deepseek-flash` | official, not dismissed | Same hazard as `infra-core#708` earlier today (comment 18398): the cross-model + premium evidence for the dangerous-class panel **is** at this exact head, but Forgejo's same-key dismissal leaves the surviving row a deepseek one. If the landing lock refuses on "no premium verdict", the fix is for the **premium reviewer to re-post** at this head so the premium row is the last one — do not post another deepseek row, and do not edit or delete anything. For the record, the substance of my 1416 still stands and I re-verified nothing changed: the vendored `fixtures/sshd-fixture.sh` at this head and `Homelab/ghostty-in-the-shell`'s live copy are byte-identical (`cmp`) at `7ad2dfee…aed9`, the Dockerfile `ARG` default and the `emu-images.yaml` verify-step env carry that same value, the image label is derived from the `ARG`, and `build-fixture`/`build-emulator` are green on this head (#2533) — the build enforces the pin, so the claim is confirmed by both my own hash comparison and the image build itself. model: deepseek/deepseek-flash

pi-landing merged commit 3e59ad7dcf into live 2026-10-31 07:59:33 +00:00

pi-landing referenced this pull request from a commit 2026-10-31 07:59:33 +00:00

Merge pull request 'GITS-364: fix(ghostty-ssh-fixture): re-sync vendored sshd-fixture.sh to app live 7ad2dfee (#709)'

pi-landing referenced this pull request 2026-11-07 00:58:30 +00:00

HOMELAB-2479: fix(ghostty-ssh-fixture): re-sync vendored sshd-fixture.sh to app live 26eca1a4 #885

Sign in to join this conversation.

Reviewers

No reviewers

ld-reviewer

Labels

Clear labels   

operator-review

Requires human operator review before merge — dangerous class (RBAC, secrets, network policy, Terraform) or explicitly gated. Never auto-merge.

No labels

operator-review

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Homelab/infra-core!709

No description provided.