cadline_web/www_archline_hu
11
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

helix3 index.php: baseline still byte-diverges from deployed file after #4/#5 #6

New Issue
Closed
opened 2026-07-19 21:08:03 +02:00 by imre.agent · 1 comment
imre.agent commented 2026-07-19 21:08:03 +02:00
Owner
Copy Link

Problem

Despite #4 (helix3 baseline content restored, cloaking backdoor dropped) and #5 (.gitattributes -> LF) both merged, the generated baseline templates/shaper_helix3/index.php still byte-diverges from the clean file deployed on the server. The difference is not malicious content -- the customization (warehouse logic, analytics) is legit and the backdoor is gone -- it is a byte-level mismatch between the generated baseline and the deployed file.

Impact

A byte-exact integrity comparison flags this known-good, legit file as modified (false positive):

  • noise in the integrity report (a clean file shows as changed);
  • an automated restore-to-baseline would push the divergent baseline back over the correct deployed file -- a regression.

Diagnosis (first step)

Given #4/#5 are already merged, determine where the residual byte-difference originates:

  • Stale build? Was build-baseline.sh re-run after #4/#5 merged -- or is the deployed baseline still carrying the pre-#4 helix3?
  • Line endings? Confirm #5's * text=auto eol=lf actually normalized this file on a fresh checkout (client core.autocrlf state at build time).
  • Content? Byte-diff the generated baseline templates/shaper_helix3/index.php against the deployed file and classify the remaining delta (whitespace/EOL vs. real character differences).

Acceptance criteria

  1. The generated baseline templates/shaper_helix3/index.php byte-exactly reproduces the deployed clean file.
  2. A byte-exact integrity comparison reports no difference for this file.
  3. The root cause of the residual divergence (stale build / EOL / content) is identified and recorded, so the same class of false positive does not recur for other override files.
## Problem Despite #4 (helix3 baseline content restored, cloaking backdoor dropped) and #5 (`.gitattributes` -> LF) both merged, the generated baseline `templates/shaper_helix3/index.php` still **byte-diverges** from the clean file deployed on the server. The difference is **not** malicious content -- the customization (warehouse logic, analytics) is legit and the backdoor is gone -- it is a byte-level mismatch between the generated baseline and the deployed file. ## Impact A byte-exact integrity comparison flags this known-good, legit file as *modified* (false positive): - noise in the integrity report (a clean file shows as changed); - an automated restore-to-baseline would push the divergent baseline back over the correct deployed file -- a regression. ## Diagnosis (first step) Given #4/#5 are already merged, determine **where** the residual byte-difference originates: - **Stale build?** Was `build-baseline.sh` re-run *after* #4/#5 merged -- or is the deployed baseline still carrying the pre-#4 helix3? - **Line endings?** Confirm #5's `* text=auto eol=lf` actually normalized this file on a fresh checkout (client `core.autocrlf` state at build time). - **Content?** Byte-diff the generated baseline `templates/shaper_helix3/index.php` against the deployed file and classify the remaining delta (whitespace/EOL vs. real character differences). ## Acceptance criteria 1. The generated baseline `templates/shaper_helix3/index.php` byte-exactly reproduces the deployed clean file. 2. A byte-exact integrity comparison reports **no** difference for this file. 3. The root cause of the residual divergence (stale build / EOL / content) is identified and recorded, so the same class of false positive does not recur for other override files.
imre.agent commented 2026-07-19 22:07:45 +02:00
Author
Owner
Copy Link

Resolved — no repo content change needed. Root cause was deploy-side: the baseline build pinned a stale revision (a commit predating #4/#5), so the generated baseline still carried the old helix3. After bumping the deploy-side pinned rev to the current main HEAD and rebuilding, a byte-exact integrity comparison now reports 0 differences for templates/shaper_helix3/index.php — and 0 modified files across the entire tree. The repo content was already byte-correct (the #4/#5 merges); no renormalization required. AC 1–3 met.

Resolved — no repo content change needed. Root cause was **deploy-side**: the baseline build pinned a stale revision (a commit predating #4/#5), so the generated baseline still carried the old helix3. After bumping the deploy-side pinned rev to the current main HEAD and rebuilding, a byte-exact integrity comparison now reports **0 differences** for `templates/shaper_helix3/index.php` — and **0 modified files across the entire tree**. The repo content was already byte-correct (the #4/#5 merges); no renormalization required. AC 1–3 met.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
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: cadline_web/www_archline_hu#6
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?