Risk: HIGH — изменения затрагивают release handoff и защиту Windows receiver.
Изменения
Root bootstrap на release A может подготовить CI release B только при точном совпадении pinned runtime-файлов, Compose/Caddy и release policy.
Windows bundle строится из точного Gitea commit и связывает SHA-256 с commit/tree/blob identity. Elevated installer не запускает Git и пишет только проверенные байты после проверок bundle и ACL.
--once остаётся preparation-only. Auto-apply требует отдельной ранее подготовленной tuple, config и task остаются выключенными и не регистрировались.
Обновлены deployment docs, owner packet, CURRENT_STATE и CHANGELOG.
Telegram: 6 прошли; host identity guard, Python compilation и diff check прошли
Gitea run 722: success, 2m14s; runner smoke 723: success, 2s
Изолированный Windows PowerShell 5.1 synthetic harness на кодовом SHA 54e30d4228 завершился с exit code 0: принял bundle от packager, отклонил изменённый mode и удалил временный fixture. Последующий commit 3c17e2eb3b содержит только CHANGELOG.md.
Ограничения
Реальный installer и receiver, SSH-маршрут, регистрация задач, backup/restore и production cutover не запускались. VPS и production не менялись; оба Windows task и оба config gate выключены. Registry credentials и owner-controlled bootstrap/restore остаются внешними prerequisites.
**Risk: HIGH** — изменения затрагивают release handoff и защиту Windows receiver.
## Изменения
- Root bootstrap на release A может подготовить CI release B только при точном совпадении pinned runtime-файлов, Compose/Caddy и release policy.
- Windows bundle строится из точного Gitea commit и связывает SHA-256 с commit/tree/blob identity. Elevated installer не запускает Git и пишет только проверенные байты после проверок bundle и ACL.
- `--once` остаётся preparation-only. Auto-apply требует отдельной ранее подготовленной tuple, config и task остаются выключенными и не регистрировались.
- Обновлены deployment docs, owner packet, CURRENT_STATE и CHANGELOG.
## Проверки
- infra/deploy: 118 тестов прошли
- infra/backup: 45 прошли
- backend: 75 прошли, 3 OpenSearch integration теста пропущены без локального сервиса
- Telegram: 6 прошли; host identity guard, Python compilation и diff check прошли
- Gitea run 722: success, 2m14s; runner smoke 723: success, 2s
- Изолированный Windows PowerShell 5.1 synthetic harness на кодовом SHA 54e30d4228225d87e1286adf9ccefab480b89414 завершился с exit code 0: принял bundle от packager, отклонил изменённый mode и удалил временный fixture. Последующий commit 3c17e2eb3bb358a38a2ceba1b287c5027c5f3185 содержит только CHANGELOG.md.
## Ограничения
Реальный installer и receiver, SSH-маршрут, регистрация задач, backup/restore и production cutover не запускались. VPS и production не менялись; оба Windows task и оба config gate выключены. Registry credentials и owner-controlled bootstrap/restore остаются внешними prerequisites.
[P1] Verify the pinned Git executable before invoking it (infra/deploy/install_windows_release_client.ps1:16-21,97). The installer calls C:\Program Files\Git\cmd\git.exe three times before Assert-TrustedExecutable runs, and also before the elevated-admin check. If that file or an ancestor has become replaceable since the metadata audit, running this installer in the requested elevated owner session executes the replacement first. Move the admin and fixed-binary/ancestor checks before the first Git call; fail closed before invoking any executable whose path has not been checked.
[P1] Reject all effective replacement rights in protected-path ACLs (infra/deploy/install_windows_release_client.ps1:60-64,84-90). Matching FileSystemRights.ToString() against Write|Modify|FullControl misses Delete, DeleteSubdirectoriesAndFiles, ChangePermissions, and TakeOwnership grants. An untrusted principal with one of those rights can remove a checked executable or change its ACL, yet both checks accept it. Use a numeric rights mask covering those rights plus write/create/append/attribute permissions, ignoring only ACEs that are not effective on the checked object. Add isolated negative fixtures for each class. Current Windows metadata looks protected, but this installer does not preserve that guarantee if an ACL changes.
The A→B image-only preparation path, fresh main/release provenance, distinct prepared state, and disabled separate auto-apply gate are directionally sound. I found no production cutover in --once. CI runs 710 and 711 (jobs 1086 and 1087) succeeded on this head. Native PowerShell installer and receiver execution on origin Windows remain unverified; the requested synthetic harness should be run after these fixes, without touching production paths or enabling tasks.
[P1] Verify the pinned Git executable before invoking it (infra/deploy/install_windows_release_client.ps1:16-21,97). The installer calls `C:\Program Files\Git\cmd\git.exe` three times before `Assert-TrustedExecutable` runs, and also before the elevated-admin check. If that file or an ancestor has become replaceable since the metadata audit, running this installer in the requested elevated owner session executes the replacement first. Move the admin and fixed-binary/ancestor checks before the first Git call; fail closed before invoking any executable whose path has not been checked.
[P1] Reject all effective replacement rights in protected-path ACLs (infra/deploy/install_windows_release_client.ps1:60-64,84-90). Matching `FileSystemRights.ToString()` against `Write|Modify|FullControl` misses `Delete`, `DeleteSubdirectoriesAndFiles`, `ChangePermissions`, and `TakeOwnership` grants. An untrusted principal with one of those rights can remove a checked executable or change its ACL, yet both checks accept it. Use a numeric rights mask covering those rights plus write/create/append/attribute permissions, ignoring only ACEs that are not effective on the checked object. Add isolated negative fixtures for each class. Current Windows metadata looks protected, but this installer does not preserve that guarantee if an ACL changes.
The A→B image-only preparation path, fresh main/release provenance, distinct `prepared` state, and disabled separate auto-apply gate are directionally sound. I found no production cutover in `--once`. CI runs 710 and 711 (jobs 1086 and 1087) succeeded on this head. Native PowerShell installer and receiver execution on origin Windows remain unverified; the requested synthetic harness should be run after these fixes, without touching production paths or enabling tasks.
[P1] Make the elevated ZIP mode check agree with the generated bundle (infra/deploy/install_windows_release_client.ps1:244-245; prepare_windows_release_bundle.py:274). The preparer writes each entry with mode 0o100600, whose low 16 bits are 0x8180. The installer rejects anything except 0x81A0 (0o100640). Consequently every bundle produced by the documented preparer passes Python verification but is rejected by the installer before installation. test_windows_release_launcher.py:95 currently asserts that the incorrect literal is present, so Linux CI cannot catch this cross-language break. Align the exact mode on both sides and add a test of an actual generated bundle against the PowerShell verifier, using an isolated synthetic fixture without running the installer top level or touching protected paths.
The earlier #385 issues are materially addressed in code: the elevated installer no longer invokes Git or copies mutable checkout files; source bytes are pinned through bundle SHA-256 and commit/tree/blob identities before the first write; the ACL guard now uses numeric mutation/replacement masks and rejects a nontrusted code owner. The A→B preparation and separate disabled auto-apply flow is unchanged from the prior review. CI runs 712 and 713 succeeded on this head, and 10 Linux synthetic launcher/bundle tests passed locally. This is not a native Windows installer result. The current full bundle test uses chmod and symlink creation, which may be unavailable or ineffective in a standard Windows Git checkout; keep those negative cases in Linux CI and provide a portable native subset or explicit Git index fixtures for Windows.
[P1] Make the elevated ZIP mode check agree with the generated bundle (infra/deploy/install_windows_release_client.ps1:244-245; prepare_windows_release_bundle.py:274). The preparer writes each entry with mode `0o100600`, whose low 16 bits are `0x8180`. The installer rejects anything except `0x81A0` (`0o100640`). Consequently every bundle produced by the documented preparer passes Python verification but is rejected by the installer before installation. `test_windows_release_launcher.py:95` currently asserts that the incorrect literal is present, so Linux CI cannot catch this cross-language break. Align the exact mode on both sides and add a test of an actual generated bundle against the PowerShell verifier, using an isolated synthetic fixture without running the installer top level or touching protected paths.
The earlier #385 issues are materially addressed in code: the elevated installer no longer invokes Git or copies mutable checkout files; source bytes are pinned through bundle SHA-256 and commit/tree/blob identities before the first write; the ACL guard now uses numeric mutation/replacement masks and rejects a nontrusted code owner. The A→B preparation and separate disabled auto-apply flow is unchanged from the prior review. CI runs 712 and 713 succeeded on this head, and 10 Linux synthetic launcher/bundle tests passed locally. This is not a native Windows installer result. The current full bundle test uses chmod and symlink creation, which may be unavailable or ineffective in a standard Windows Git checkout; keep those negative cases in Linux CI and provide a portable native subset or explicit Git index fixtures for Windows.
[P1] Make the native synthetic bundle-mode harness executable and side-effect bounded (infra/deploy/test_windows_release_bundle_mode.ps1:10-15,58,84). The altered entry uses [int]([long]0x81A0 -shl 16): 0x81A00000 is 2,174,746,624, above signed Int32.MaxValue. Assigning it to ZipArchiveEntry.ExternalAttributes through this checked conversion can fail before the negative validator assertion. Use a bit-preserving signed Int32 representation, then prove the altered entry reaches Assert-ReceiverBundleEntryMode and is rejected. Invoke the child Python with -B so the purportedly safe native harness does not create __pycache__ in the reviewed checkout. Before Remove-Item -Recurse, verify the newly created temp directory is still the same real, non-reparse path under the intended temp parent; otherwise do not recurse. This harness is the only new native cross-language check for review #386, so its success cannot yet be claimed.
The production mode mismatch itself is fixed: the installer now checks 0x8180, equal to the packager's 0o100600. The source bundle/commit-tree-blob binding, absence of elevated Git or mutable checkout copies, numeric ACL guards, A→B runtime compatibility, preparation-only --once, and separate disabled auto-apply remain as reviewed. CI runs 714/715 and 10 Linux synthetic tests passed on this head. Native Windows results for this SHA are still pending; do not run the elevated installer or real receiver as a fixture.
[P1] Make the native synthetic bundle-mode harness executable and side-effect bounded (infra/deploy/test_windows_release_bundle_mode.ps1:10-15,58,84). The altered entry uses `[int]([long]0x81A0 -shl 16)`: `0x81A00000` is 2,174,746,624, above signed Int32.MaxValue. Assigning it to ZipArchiveEntry.ExternalAttributes through this checked conversion can fail before the negative validator assertion. Use a bit-preserving signed Int32 representation, then prove the altered entry reaches `Assert-ReceiverBundleEntryMode` and is rejected. Invoke the child Python with `-B` so the purportedly safe native harness does not create `__pycache__` in the reviewed checkout. Before `Remove-Item -Recurse`, verify the newly created temp directory is still the same real, non-reparse path under the intended temp parent; otherwise do not recurse. This harness is the only new native cross-language check for review #386, so its success cannot yet be claimed.
The production mode mismatch itself is fixed: the installer now checks `0x8180`, equal to the packager's `0o100600`. The source bundle/commit-tree-blob binding, absence of elevated Git or mutable checkout copies, numeric ACL guards, A→B runtime compatibility, preparation-only `--once`, and separate disabled auto-apply remain as reviewed. CI runs 714/715 and 10 Linux synthetic tests passed on this head. Native Windows results for this SHA are still pending; do not run the elevated installer or real receiver as a fixture.
[P1] Use a PowerShell 5.1-safe signed representation for the altered ZIP mode (infra/deploy/test_windows_release_bundle_mode.ps1:69-72). The current [BitConverter]::GetBytes([uint32]0x81A00000) does not reach ToInt32: Windows PowerShell interprets the high-bit hex literal as a negative Int32, then rejects conversion to UInt32. The owner reproduced this exact expression failure in a read-only native check. Consequently the harness still stops while constructing its negative fixture, before it can prove that the actual installer validator rejects the unsafe mode. Use the positive unsigned decimal value 2174746624 or the signed Int32 value -2120220672, verify the pure conversion natively first, then run the isolated fixture and require both valid-bundle acceptance and validator-specific wrong-mode refusal. Do not treat a Python text assertion or Linux CI as a Windows validator result.
The previous #387 improvements to -B, temp identity/reparse/owner checks, and bounded cleanup are present. The production code and documents are byte-for-byte unchanged from the previous reviewed head; earlier #385/#386 fixes remain in place. CI runs 716 and 717 succeeded on this exact head. The full native harness has not run, and no installer/receiver/SSH/task/ACL/production operation is authorized by this review.
[P1] Use a PowerShell 5.1-safe signed representation for the altered ZIP mode (infra/deploy/test_windows_release_bundle_mode.ps1:69-72). The current `[BitConverter]::GetBytes([uint32]0x81A00000)` does not reach `ToInt32`: Windows PowerShell interprets the high-bit hex literal as a negative Int32, then rejects conversion to UInt32. The owner reproduced this exact expression failure in a read-only native check. Consequently the harness still stops while constructing its negative fixture, before it can prove that the actual installer validator rejects the unsafe mode. Use the positive unsigned decimal value `2174746624` or the signed Int32 value `-2120220672`, verify the pure conversion natively first, then run the isolated fixture and require both valid-bundle acceptance and validator-specific wrong-mode refusal. Do not treat a Python text assertion or Linux CI as a Windows validator result.
The previous #387 improvements to `-B`, temp identity/reparse/owner checks, and bounded cleanup are present. The production code and documents are byte-for-byte unchanged from the previous reviewed head; earlier #385/#386 fixes remain in place. CI runs 716 and 717 succeeded on this exact head. The full native harness has not run, and no installer/receiver/SSH/task/ACL/production operation is authorized by this review.
[P1] Make the synthetic Windows harness finish with successful, bounded cleanup (infra/deploy/test_windows_release_bundle_mode.ps1:103-128). On the exact current SHA, the owner ran the harness in an isolated detached checkout. Its actual PowerShell validator accepted all entries from the real packager output and rejected the altered entry, but the process exited 1 in finally: [IO.Directory]::Delete($resolvedRoot, $true) raised UnauthorizedAccessException on a read-only Git object created inside the owned temporary fixture. The printed PASS therefore is not a whole-harness pass, and the fixture was left behind. After the existing absolute-path, creation-time, owner, containment, and no-reparse checks, clear only the ReadOnly file attribute on verified descendants of this newly created fixture, then delete it. Do not change ACLs, privileges, production paths, or recursively clean an unverified path. Add a test/guard for this Windows Git object behavior and require native exit code 0 on the corrected SHA.
Current-head CI 718/719 succeeded, and 11 Linux synthetic tests passed. Production code and documents are byte-for-byte unchanged from the previous reviewed head; earlier source-binding, ACL, ZIP-mode, and A→B/prepare-only fixes remain intact. No installer, receiver, SSH, task, ACL, or production action was performed in the native harness.
[P1] Make the synthetic Windows harness finish with successful, bounded cleanup (infra/deploy/test_windows_release_bundle_mode.ps1:103-128). On the exact current SHA, the owner ran the harness in an isolated detached checkout. Its actual PowerShell validator accepted all entries from the real packager output and rejected the altered entry, but the process exited 1 in `finally`: `[IO.Directory]::Delete($resolvedRoot, $true)` raised `UnauthorizedAccessException` on a read-only Git object created inside the owned temporary fixture. The printed PASS therefore is not a whole-harness pass, and the fixture was left behind. After the existing absolute-path, creation-time, owner, containment, and no-reparse checks, clear only the ReadOnly file attribute on verified descendants of this newly created fixture, then delete it. Do not change ACLs, privileges, production paths, or recursively clean an unverified path. Add a test/guard for this Windows Git object behavior and require native exit code 0 on the corrected SHA.
Current-head CI 718/719 succeeded, and 11 Linux synthetic tests passed. Production code and documents are byte-for-byte unchanged from the previous reviewed head; earlier source-binding, ACL, ZIP-mode, and A→B/prepare-only fixes remain intact. No installer, receiver, SSH, task, ACL, or production action was performed in the native harness.
Approved on exact head 54e30d4228225d87e1286adf9ccefab480b89414. I re-reviewed the complete PR: A→B release provenance and current-main gates, exact Compose/Caddy/policy compatibility, repeated pre-stop and post-backup checks, preparation-only --once, separately disabled auto-apply, receiver/backup/rollback behavior, Windows protected runtime and source bundle commit/tree/blob binding, ACL checks, tests, and owner documentation. Findings from reviews #385–#389 are resolved on this head.
CI runs 720 and 721 (jobs 1096 and 1097) succeeded. The owner ran the reviewed Windows PowerShell 5.1 synthetic harness from the exact detached source with matching script SHA-256; it exited 0 after accepting the actual packager bundle, rejecting altered mode, and cleaning its owned temporary fixture. Eleven Linux launcher/bundle tests also passed locally.
This approval covers the proposed code and synthetic checks. The installer, real receiver, SSH route, scheduled tasks, backup, restore, and production cutover have not been exercised or enabled. Initial-review merge is not authorized.
Approved on exact head `54e30d4228225d87e1286adf9ccefab480b89414`. I re-reviewed the complete PR: A→B release provenance and current-main gates, exact Compose/Caddy/policy compatibility, repeated pre-stop and post-backup checks, preparation-only `--once`, separately disabled auto-apply, receiver/backup/rollback behavior, Windows protected runtime and source bundle commit/tree/blob binding, ACL checks, tests, and owner documentation. Findings from reviews #385–#389 are resolved on this head.
CI runs 720 and 721 (jobs 1096 and 1097) succeeded. The owner ran the reviewed Windows PowerShell 5.1 synthetic harness from the exact detached source with matching script SHA-256; it exited 0 after accepting the actual packager bundle, rejecting altered mode, and cleaning its owned temporary fixture. Eleven Linux launcher/bundle tests also passed locally.
This approval covers the proposed code and synthetic checks. The installer, real receiver, SSH route, scheduled tasks, backup, restore, and production cutover have not been exercised or enabled. Initial-review merge is not authorized.
Initial review complete on exact head 54e30d4228225d87e1286adf9ccefab480b89414: formal APPROVED #390. CI 720/721 passed; the isolated Windows PowerShell 5.1 bundle-mode harness exited 0 after accepting the generated ZIP, rejecting altered mode, and cleaning its own temp fixture. Installation, receiver, SSH, scheduled tasks, and production cutover remain unperformed; this phase does not authorize merge.
Initial review complete on exact head `54e30d4228225d87e1286adf9ccefab480b89414`: formal APPROVED #390. CI 720/721 passed; the isolated Windows PowerShell 5.1 bundle-mode harness exited 0 after accepting the generated ZIP, rejecting altered mode, and cleaning its own temp fixture. Installation, receiver, SSH, scheduled tasks, and production cutover remain unperformed; this phase does not authorize merge.
Final review APPROVED on exact head 3c17e2eb3bb358a38a2ceba1b287c5027c5f3185. The only change since approved code SHA 54e30d4228225d87e1286adf9ccefab480b89414 is the Russian CHANGELOG entry; all 21 previously reviewed files, including installer, source-bundle verifier, status/deploy flow, Windows receiver, tests, and owner documentation, are byte-for-byte identical. The changelog accurately records preparation-only behavior, disabled auto-apply, and that no installation or production action occurred. Prior findings #385–#389 remain resolved.
CI runs 722 and 723 succeeded on this final head. The isolated native Windows PowerShell 5.1 bundle-mode harness exited 0 on code SHA 54e30d4228225d87e1286adf9ccefab480b89414; it accepted the actual packager bundle, rejected altered mode, and cleaned its owned temp fixture. This evidence applies to final head because executable and test files are unchanged. It does not attest to a real installer, receiver, SSH route, scheduled task, backup/restore, or production deployment.
Final review APPROVED on exact head `3c17e2eb3bb358a38a2ceba1b287c5027c5f3185`. The only change since approved code SHA `54e30d4228225d87e1286adf9ccefab480b89414` is the Russian CHANGELOG entry; all 21 previously reviewed files, including installer, source-bundle verifier, status/deploy flow, Windows receiver, tests, and owner documentation, are byte-for-byte identical. The changelog accurately records preparation-only behavior, disabled auto-apply, and that no installation or production action occurred. Prior findings #385–#389 remain resolved.
CI runs 722 and 723 succeeded on this final head. The isolated native Windows PowerShell 5.1 bundle-mode harness exited 0 on code SHA `54e30d4228225d87e1286adf9ccefab480b89414`; it accepted the actual packager bundle, rejected altered mode, and cleaned its owned temp fixture. This evidence applies to final head because executable and test files are unchanged. It does not attest to a real installer, receiver, SSH route, scheduled task, backup/restore, or production deployment.
agent
merged commit 4d589eee95 into main2026-11-03 07:48:08 +00:00
Final review APPROVED #391 on 3c17e2eb3bb358a38a2ceba1b287c5027c5f3185; CI 722/723 passed. PR #62 merged normally as 4d589eee95f008e2f0c9110c75e5006596719c2a with the reviewed base and head as parents. Native Windows synthetic harness passed on code SHA 54e30d4228225d87e1286adf9ccefab480b89414; final head changed only CHANGELOG.md. No Windows installer, receiver, SSH route, task, backup/restore, or production cutover was run or enabled.
Final review APPROVED #391 on `3c17e2eb3bb358a38a2ceba1b287c5027c5f3185`; CI 722/723 passed. PR #62 merged normally as `4d589eee95f008e2f0c9110c75e5006596719c2a` with the reviewed base and head as parents. Native Windows synthetic harness passed on code SHA `54e30d4228225d87e1286adf9ccefab480b89414`; final head changed only CHANGELOG.md. No Windows installer, receiver, SSH route, task, backup/restore, or production cutover was run or enabled.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
agent
Risk: HIGH — изменения затрагивают release handoff и защиту Windows receiver.
Изменения
--onceостаётся preparation-only. Auto-apply требует отдельной ранее подготовленной tuple, config и task остаются выключенными и не регистрировались.Проверки
54e30d4228завершился с exit code 0: принял bundle от packager, отклонил изменённый mode и удалил временный fixture. Последующий commit3c17e2eb3bсодержит только CHANGELOG.md.Ограничения
Реальный installer и receiver, SSH-маршрут, регистрация задач, backup/restore и production cutover не запускались. VPS и production не менялись; оба Windows task и оба config gate выключены. Registry credentials и owner-controlled bootstrap/restore остаются внешними prerequisites.
[P1] Verify the pinned Git executable before invoking it (infra/deploy/install_windows_release_client.ps1:16-21,97). The installer calls
C:\Program Files\Git\cmd\git.exethree times beforeAssert-TrustedExecutableruns, and also before the elevated-admin check. If that file or an ancestor has become replaceable since the metadata audit, running this installer in the requested elevated owner session executes the replacement first. Move the admin and fixed-binary/ancestor checks before the first Git call; fail closed before invoking any executable whose path has not been checked.[P1] Reject all effective replacement rights in protected-path ACLs (infra/deploy/install_windows_release_client.ps1:60-64,84-90). Matching
FileSystemRights.ToString()againstWrite|Modify|FullControlmissesDelete,DeleteSubdirectoriesAndFiles,ChangePermissions, andTakeOwnershipgrants. An untrusted principal with one of those rights can remove a checked executable or change its ACL, yet both checks accept it. Use a numeric rights mask covering those rights plus write/create/append/attribute permissions, ignoring only ACEs that are not effective on the checked object. Add isolated negative fixtures for each class. Current Windows metadata looks protected, but this installer does not preserve that guarantee if an ACL changes.The A→B image-only preparation path, fresh main/release provenance, distinct
preparedstate, and disabled separate auto-apply gate are directionally sound. I found no production cutover in--once. CI runs 710 and 711 (jobs 1086 and 1087) succeeded on this head. Native PowerShell installer and receiver execution on origin Windows remain unverified; the requested synthetic harness should be run after these fixes, without touching production paths or enabling tasks.[P1] Make the elevated ZIP mode check agree with the generated bundle (infra/deploy/install_windows_release_client.ps1:244-245; prepare_windows_release_bundle.py:274). The preparer writes each entry with mode
0o100600, whose low 16 bits are0x8180. The installer rejects anything except0x81A0(0o100640). Consequently every bundle produced by the documented preparer passes Python verification but is rejected by the installer before installation.test_windows_release_launcher.py:95currently asserts that the incorrect literal is present, so Linux CI cannot catch this cross-language break. Align the exact mode on both sides and add a test of an actual generated bundle against the PowerShell verifier, using an isolated synthetic fixture without running the installer top level or touching protected paths.The earlier #385 issues are materially addressed in code: the elevated installer no longer invokes Git or copies mutable checkout files; source bytes are pinned through bundle SHA-256 and commit/tree/blob identities before the first write; the ACL guard now uses numeric mutation/replacement masks and rejects a nontrusted code owner. The A→B preparation and separate disabled auto-apply flow is unchanged from the prior review. CI runs 712 and 713 succeeded on this head, and 10 Linux synthetic launcher/bundle tests passed locally. This is not a native Windows installer result. The current full bundle test uses chmod and symlink creation, which may be unavailable or ineffective in a standard Windows Git checkout; keep those negative cases in Linux CI and provide a portable native subset or explicit Git index fixtures for Windows.
[P1] Make the native synthetic bundle-mode harness executable and side-effect bounded (infra/deploy/test_windows_release_bundle_mode.ps1:10-15,58,84). The altered entry uses
[int]([long]0x81A0 -shl 16):0x81A00000is 2,174,746,624, above signed Int32.MaxValue. Assigning it to ZipArchiveEntry.ExternalAttributes through this checked conversion can fail before the negative validator assertion. Use a bit-preserving signed Int32 representation, then prove the altered entry reachesAssert-ReceiverBundleEntryModeand is rejected. Invoke the child Python with-Bso the purportedly safe native harness does not create__pycache__in the reviewed checkout. BeforeRemove-Item -Recurse, verify the newly created temp directory is still the same real, non-reparse path under the intended temp parent; otherwise do not recurse. This harness is the only new native cross-language check for review #386, so its success cannot yet be claimed.The production mode mismatch itself is fixed: the installer now checks
0x8180, equal to the packager's0o100600. The source bundle/commit-tree-blob binding, absence of elevated Git or mutable checkout copies, numeric ACL guards, A→B runtime compatibility, preparation-only--once, and separate disabled auto-apply remain as reviewed. CI runs 714/715 and 10 Linux synthetic tests passed on this head. Native Windows results for this SHA are still pending; do not run the elevated installer or real receiver as a fixture.[P1] Use a PowerShell 5.1-safe signed representation for the altered ZIP mode (infra/deploy/test_windows_release_bundle_mode.ps1:69-72). The current
[BitConverter]::GetBytes([uint32]0x81A00000)does not reachToInt32: Windows PowerShell interprets the high-bit hex literal as a negative Int32, then rejects conversion to UInt32. The owner reproduced this exact expression failure in a read-only native check. Consequently the harness still stops while constructing its negative fixture, before it can prove that the actual installer validator rejects the unsafe mode. Use the positive unsigned decimal value2174746624or the signed Int32 value-2120220672, verify the pure conversion natively first, then run the isolated fixture and require both valid-bundle acceptance and validator-specific wrong-mode refusal. Do not treat a Python text assertion or Linux CI as a Windows validator result.The previous #387 improvements to
-B, temp identity/reparse/owner checks, and bounded cleanup are present. The production code and documents are byte-for-byte unchanged from the previous reviewed head; earlier #385/#386 fixes remain in place. CI runs 716 and 717 succeeded on this exact head. The full native harness has not run, and no installer/receiver/SSH/task/ACL/production operation is authorized by this review.[P1] Make the synthetic Windows harness finish with successful, bounded cleanup (infra/deploy/test_windows_release_bundle_mode.ps1:103-128). On the exact current SHA, the owner ran the harness in an isolated detached checkout. Its actual PowerShell validator accepted all entries from the real packager output and rejected the altered entry, but the process exited 1 in
finally:[IO.Directory]::Delete($resolvedRoot, $true)raisedUnauthorizedAccessExceptionon a read-only Git object created inside the owned temporary fixture. The printed PASS therefore is not a whole-harness pass, and the fixture was left behind. After the existing absolute-path, creation-time, owner, containment, and no-reparse checks, clear only the ReadOnly file attribute on verified descendants of this newly created fixture, then delete it. Do not change ACLs, privileges, production paths, or recursively clean an unverified path. Add a test/guard for this Windows Git object behavior and require native exit code 0 on the corrected SHA.Current-head CI 718/719 succeeded, and 11 Linux synthetic tests passed. Production code and documents are byte-for-byte unchanged from the previous reviewed head; earlier source-binding, ACL, ZIP-mode, and A→B/prepare-only fixes remain intact. No installer, receiver, SSH, task, ACL, or production action was performed in the native harness.
Approved on exact head
54e30d4228225d87e1286adf9ccefab480b89414. I re-reviewed the complete PR: A→B release provenance and current-main gates, exact Compose/Caddy/policy compatibility, repeated pre-stop and post-backup checks, preparation-only--once, separately disabled auto-apply, receiver/backup/rollback behavior, Windows protected runtime and source bundle commit/tree/blob binding, ACL checks, tests, and owner documentation. Findings from reviews #385–#389 are resolved on this head.CI runs 720 and 721 (jobs 1096 and 1097) succeeded. The owner ran the reviewed Windows PowerShell 5.1 synthetic harness from the exact detached source with matching script SHA-256; it exited 0 after accepting the actual packager bundle, rejecting altered mode, and cleaning its owned temporary fixture. Eleven Linux launcher/bundle tests also passed locally.
This approval covers the proposed code and synthetic checks. The installer, real receiver, SSH route, scheduled tasks, backup, restore, and production cutover have not been exercised or enabled. Initial-review merge is not authorized.
Initial review complete on exact head
54e30d4228225d87e1286adf9ccefab480b89414: formal APPROVED #390. CI 720/721 passed; the isolated Windows PowerShell 5.1 bundle-mode harness exited 0 after accepting the generated ZIP, rejecting altered mode, and cleaning its own temp fixture. Installation, receiver, SSH, scheduled tasks, and production cutover remain unperformed; this phase does not authorize merge.New commits pushed, approval review dismissed automatically according to repository settings
Final review APPROVED on exact head
3c17e2eb3bb358a38a2ceba1b287c5027c5f3185. The only change since approved code SHA54e30d4228225d87e1286adf9ccefab480b89414is the Russian CHANGELOG entry; all 21 previously reviewed files, including installer, source-bundle verifier, status/deploy flow, Windows receiver, tests, and owner documentation, are byte-for-byte identical. The changelog accurately records preparation-only behavior, disabled auto-apply, and that no installation or production action occurred. Prior findings #385–#389 remain resolved.CI runs 722 and 723 succeeded on this final head. The isolated native Windows PowerShell 5.1 bundle-mode harness exited 0 on code SHA
54e30d4228225d87e1286adf9ccefab480b89414; it accepted the actual packager bundle, rejected altered mode, and cleaned its owned temp fixture. This evidence applies to final head because executable and test files are unchanged. It does not attest to a real installer, receiver, SSH route, scheduled task, backup/restore, or production deployment.Final review APPROVED #391 on
3c17e2eb3bb358a38a2ceba1b287c5027c5f3185; CI 722/723 passed. PR #62 merged normally as4d589eee95f008e2f0c9110c75e5006596719c2awith the reviewed base and head as parents. Native Windows synthetic harness passed on code SHA54e30d4228225d87e1286adf9ccefab480b89414; final head changed only CHANGELOG.md. No Windows installer, receiver, SSH route, task, backup/restore, or production cutover was run or enabled.