P1 windows release: consume promoted OpenPath installer fixes and prove generated ClassroomPath EXE end-to-end

[balejosg]

Severity

P1 downstream rollout / security verification

Summary

On 2026-09-03 a Windows installer generated through ClassroomPath was new as a personalized .exe, but its embedded OpenPath Windows template came from the last exact promoted OpenPath contract (a3846d6cbbb5c816d12dc4c5a60409760e121b90, release scripts-v4.1.0-a3846d6c, 2026-08-30).

That template predates the Firefox discovery fix OpenPath #246 and also predates the fixes that will be produced for the newly discovered AppLocker/watchdog fail-open incident.

This is not a reason to resolve OpenPath main dynamically. ClassroomPath must continue consuming one exact immutable OpenPath Promotion Contract v2 as established by #160.

This issue owns the downstream step after OpenPath publishes a corrected contract.

Blocked by:

• release(windows): promote post-#246/#253 fixes with physical installer evidence before claiming them delivered OpenPath#255 — publish/promote the corrected Windows component and exact v2 contract.

Upstream security fixes/evidence feeding #255:

• OpenPath #253 — installer cannot leave AppLocker/watchdog absent while config says Enforced;
• OpenPath #186 — health/recovery must reflect missing AppControl/watchdog;
• OpenPath #246 — Firefox Release discovery source fix;
• OpenPath #254 — strict Firefox-only allowlist hardening (may land in the same or a subsequent promoted release according to upstream security decision).

Related ClassroomPath release architecture:

• refactor(release): consume exact OpenPath contract and promote immutable release bundles #160 — exact OpenPath contract + immutable Release Bundle v2;
• hardening(release): make production promotion and rollback hermetic and operationally provable #162 — production executor/rollback hardening.

---

Incident evidence

The generated installer installed OpenPath files with timestamps matching the 2026-08-30 template:

C:\OpenPath\lib\AppControl.psm1               8/30/2026 11:17:06 PM
C:\OpenPath\lib\internal\Watchdog.Runtime.ps1 8/30/2026 11:17:06 PM

The machine then showed:

config enableNonAdminAppControl = true
mode = Enforced
approved browser = Firefox

OpenPath-Restricted = absent
OpenPath-* scheduled tasks = absent
AppLocker Local = empty
AppLocker Effective = empty
portable EXE = AllowedByDefault
Edge = launches

OpenPath installation log also reproduced the pre-#246 Firefox detection symptom:

Firefox machine ExtensionSettings policy written ...
WARN Firefox not detected; network autoconfig skipped
=== OpenPath update completed successfully ===

The OpenPath installer phase ordering then allows Firefox readiness failure before scheduled-tasks and app-control; root fix is upstream #253.

---

Core downstream invariant

ClassroomPath may only claim the Windows installer fix shipped when the exact OpenPath contract embedded in the active ClassroomPath Release Bundle points to a physically verified Windows template containing the fixes, and a .exe generated through the live ClassroomPath path has been installed/tested successfully.

Required identity chain:

ClassroomPath source SHA
-> exact OpenPath submodule SHA
-> exact OpenPath Promotion Contract v2 bytes
-> contract SHA256
-> windowsOfflineInstaller.sourceSha
-> releaseTag
-> templateSha256
-> ClassroomPath Release Bundle releaseId
-> provisioned exact template
-> generated personalized EXE
-> real Windows installed bytes/runtime

No step may substitute latest, OpenPath main, a current release tag, or a recomputed pin.

---

Implementation / rollout instructions for an LLM agent

Phase 0 — read contracts before changing anything

1. Read ClassroomPath root AGENTS.md completely.
2. Read refactor(release): consume exact OpenPath contract and promote immutable release bundles #160 completion/current implementation.
3. Read hardening(release): make production promotion and rollback hermetic and operationally provable #162 but do not mix its production-executor work into this ticket.
4. Read upstream OpenPath #255 completion report and exact published v2 contract.
5. Inspect:
   • scripts/resolve-openpath-promotion-contract.mjs;
   • release bundle builder/parser;
   • scripts/resolve-windows-offline-installer-template-pin.mjs in its current verifier/projection role;
   • template provisioning code;
   • Windows installer generation service/API;
   • Windows installer canary;
   • RC/staging Windows evidence;
   • production bundle/runtime projection.
6. Do not edit upstream/openpath/ from ClassroomPath.
7. Do not deploy staging/production, create tags, or promote without separate explicit authorization.

Phase 1 — update only to an exact promoted OpenPath SHA

After #255 publishes its contract:

S = exact promoted OpenPath SHA from #255

Update the OpenPath submodule only to S.

Then require exact retrieval of:

promotion-contracts/v2/S.json

Assert:

contract.openpathSha == S
contract.components.windowsOfflineInstaller matches #255 completion identity

A missing exact contract must fail. Do not search ancestors or choose a previous template.

Phase 2 — prove release bundle projection

The ClassroomPath RC/release bundle must contain the exact contract bytes/hash and project the Windows tuple without independent selection:

windows_offline_installer_template_version
windows_offline_installer_template_commit/sourceSha
windows_offline_installer_template_release_tag
windows_offline_installer_template_sha256
payload manifest identity where exposed

Add/extend tests that fail if the active release bundle can carry an OpenPath SHA/contract while projecting a different Windows template identity.

Phase 3 — provision exact template atomically

Provision from the contract only.

Verify before publish/use:

release tag exact
template sidecar exact
template bytes SHA256 exact
payload manifest exact

Do not destroy a known-good current template before the replacement is fully verified.

Readiness must fail if the required release bundle points to a template that is absent/corrupt/wrong generation.

Phase 4 — generated EXE provenance test

Generate a personalized Windows installer through the same ClassroomPath service/API/UI path used by users.

Do not test only the generic OpenPath template file.

Prove that the resulting personalized EXE was produced from the exact provisioned template. Use the canonical trailer/overlay parser and template identity checks; do not infer from file modification timestamps.

Safe test/evidence should include:

ClassroomPath releaseId
OpenPath SHA
OpenPath contract SHA256
Windows template source SHA
releaseTag
template SHA256
generated EXE SHA256

Never include enrollment tokens, raw download refs, Authorization/Cookie values, or personalized trailer secrets.

Phase 5 — real Windows end-to-end

Install the exact generated .exe on a clean/supported Windows test endpoint.

Required proof after successful installation:

Firefox regression

normal Firefox Release discovered
no false firefox-release-missing
managed extension readiness passes

AppControl lifecycle

OpenPath-Watchdog task exists
required restricted targeting state exists
AppIDSvc running
Get-AppLockerPolicy -Effective has required enforced collections

Runtime boundary

Under a local standard student account:

Firefox -> allowed
Edge -> denied
portable arbitrary PE in Downloads -> denied

If upstream #254 is included in this promoted release, also run its unknown-browser/strict-allowlist adversarial probes.

Health

healthy after valid install

Then deliberately break/remove effective AppLocker in the disposable test endpoint and prove health no longer reports healthy, as required by OpenPath #186.

Phase 6 — staging evidence (only when explicitly authorized)

A staging deployment must consume the exact RC bundle produced above.

Prove:

live RELEASE_ID == selected releaseId
live OPENPATH_SHA == bundle OpenPath SHA
live contract SHA == bundle contract SHA
provisioned template SHA == contract template SHA
ClassroomPath-generated EXE canary uses that template

Do not claim staging proof without actually running it.

Phase 7 — production promotion (only when explicitly authorized)

Use #160/#162 release semantics:

promote exact staged releaseId
no rebuild
no OpenPath re-resolution
no current/latest template lookup

Production completion requires safe evidence that a live generated Windows installer is backed by the intended contract/template identity. A full destructive Windows reinstall in production is not required if product policy uses staging/canary machines for runtime proof, but the production service/template identity must match the release proven in staging.

---

Provenance/diagnostic improvement

The incident was harder to diagnose because config.json had a blank agentVersion and file timestamps were used as a clue.

Add the smallest safe operator-visible provenance necessary to answer:

Which OpenPath Windows component produced this installed endpoint?

Prefer immutable identities already present in the promotion contract/payload manifest, for example:

OpenPath source SHA
Windows template source SHA/release tag

Do not duplicate release selection logic in the endpoint. Do not treat filesystem timestamps as provenance.

If this belongs upstream in OpenPath rather than ClassroomPath, create/link the upstream follow-up and only consume/display the canonical value here.

---

Tests required

Contract / bundle

• exact submodule SHA requires exact v2 contract;
• wrong/missing contract fails;
• Windows template projection equals contract component exactly;
• contract hash is preserved in release bundle;
• no previous-pin fallback can authorize the RC.

Provisioning

• wrong releaseTag fails;
• sidecar mismatch fails;
• template bytes mismatch fails;
• payload manifest mismatch fails;
• atomic replacement preserves previous valid generation on failure.

Generation

• personalized EXE is based on exact provisioned template;
• generated EXE hash recorded safely;
• fresh generation semantics remain intact;
• no secret provenance/evidence leak.

Windows E2E

• #246 Firefox regression;
• #253 watchdog/AppLocker install invariant;
• Edge denied;
• arbitrary portable PE denied;
• Firefox allowed;
• #186 health negative test.

Release regression

Add a test/gate that makes it impossible to report a ClassroomPath Windows canary as proving a fix for an OpenPath SHA different from the exact openpathSha + contract hash + template identity in the selected releaseId.

---

Acceptance criteria

• Blocked until OpenPath #255 publishes a corrected exact v2 contract.
• ClassroomPath submodule updates to that exact promoted SHA, not an arbitrary later main.
• Exact v2 contract exists and validates for the submodule SHA.
• Release Bundle contains the exact contract hash and source SHA.
• Windows runtime projection comes only from the contract.
• Exact new template is provisioned and SHA-verified.
• Personalized EXE generation proves it uses that exact template.
• Real Windows install no longer reproduces #246.
• Real Windows install satisfies #253 AppLocker/watchdog invariant.
• Edge is denied for standard student when Firefox-only.
• Portable arbitrary EXE is denied.
• Firefox is allowed.
• Broken effective AppLocker makes health non-healthy per #186.
• Safe provenance can identify the OpenPath/Windows component without relying on timestamps.
• Required ClassroomPath tests pass.
• Staging/production evidence is claimed only after explicit authorization and actual execution.
• Production, when eventually promoted, uses the exact releaseId proven in staging with no OpenPath/template re-resolution.

---

Non-goals

• Do not make ClassroomPath consume OpenPath main/latest.
• Do not recreate OpenPath component selection in ClassroomPath.
• Do not patch OpenPath source from this repo.
• Do not weaken immutable Release Bundle v2.
• Do not deploy or tag without explicit authorization.

Completion report

Report separately:

1. CONSUMED — exact OpenPath SHA/contract/template identity in ClassroomPath RC;
2. WINDOWS PROVEN — exact generated EXE + real Windows results;
3. STAGING SHIPPED — only if authorized and executed;
4. PRODUCTION SHIPPED — only if authorized and executed.

Do not collapse these states into a generic "fixed".

[balejosg]

2026-09-08 design review — normative clarification for downstream implementers

This comment supersedes the earlier wording that described OpenPath #254 as the "strict Firefox-only allowlist" ticket.

Upstream responsibilities are now intentionally split:

OpenPath #253
  = installer/AppControl lifecycle + effective/runtime boundary + physical generated-installer gate

OpenPath #186
  = truthful health/watchdog/recovery

OpenPath #254
  = default compatibility-mode hardening:
      discovered/supported unapproved browsers
      portable/student-writable execution
      valid AppLocker path variables
      preserve legitimate centrally installed classroom apps

OpenPath #256
  = optional StrictApplicationAllowlist profile:
      unknown executable/browser denied unless explicitly approved

OpenPath #255
  = build/prove/promote the exact consumer-ready Windows component/contract

#165 remains blocked only on the exact contract delivered by #255. Do not make ClassroomPath independently decide whether #254 or #256 must be in the release; consume the exact promoted OpenPath contract selected upstream.

Current upstream blocker

As of this review, #253 has been reopened. At OpenPath SHA 1481869d05b8cf68235811dc85eaa08dcec8bc6b, canonical Release Installation Scripts run 34227283744 still fails the real generated-installer E2E in app-control.

Therefore do not start the downstream submodule/RC rollout merely because OpenPath main contains the source changes. Wait for #255 to publish the exact v2 contract after the canonical physical lane is green.

---

Keep the ClassroomPath E2E intentionally thinner than upstream policy E2E

ClassroomPath must prove that the exact user-facing personalized EXE preserves the upstream security contract, but it should not duplicate every AppLocker adversarial case from #253/#254/#256.

Mandatory downstream integration proof for the exact generated .exe:

identity:
  ClassroomPath releaseId
  OpenPath SHA
  OpenPath contract SHA256
  Windows component sourceSha/releaseTag/templateSha256
  generated personalized EXE SHA256

install:
  installer exit = 0
  Firefox readiness succeeds (no #246 regression)
  AppControl commit state is committed
  OpenPath-Watchdog / required targeting state present
  effective AppLocker boundary present

student smoke:
  approved Firefox launches
  Edge is denied for Firefox-only configuration
  benign PE from a student-writable location is denied

health smoke:
  valid installed boundary reports healthy according to upstream contract

If the promoted OpenPath release includes #254, add one smoke proving the promoted compatibility behavior is actually present (for example, a discovered custom-location unapproved browser or the canonical #254 release evidence). Do not reproduce its entire registry/removable-media matrix downstream.

If the promoted release includes #256 and ClassroomPath actually opts into strict mode, add one strict-profile integration smoke. Otherwise #256 is irrelevant to #165.

The exhaustive application-policy matrix remains OpenPath's responsibility.

---

Provenance ownership clarification

Do not create a ClassroomPath-specific endpoint provenance format.

Preferred authority:

OpenPath installer/runtime owns any persisted installed-component provenance
ClassroomPath Release Bundle owns downstream release identity
ClassroomPath evidence binds those identities together

For #165, it is sufficient to prove the generation/install chain cryptographically from the exact release artifacts:

releaseId
-> exact OpenPath contract bytes/hash
-> exact Windows template hash
-> exact generated personalized EXE hash
-> that exact EXE used by the Windows test

Do not use filesystem modification timestamps as provenance.

If OpenPath does not yet expose a canonical installed-source/template marker, do not invent one here or block the emergency rollout solely on that diagnostic feature. Record the generated EXE identity in safe test evidence and track any desired endpoint-visible provenance upstream as a separate follow-up.

---

Generation proof must account for the overlay

A personalized ClassroomPath .exe is expected to have a different SHA256 from the immutable OpenPath template.

Prove derivation using the canonical OpenPath trailer/overlay parser/contract, not by expecting whole-file hash equality.

Required assertions should establish that:

base/template portion belongs to the exact verified template generation
personalized trailer parses under the canonical schema
embedded classroom/enrollment configuration is the expected test configuration
resulting personalized EXE hash is recorded

Never print the enrollment token, raw download reference, Authorization/Cookie headers, or complete sensitive trailer payload into evidence.

---

Closure states remain separate

Keep the existing completion-state distinction:

CONSUMED
WINDOWS PROVEN
STAGING SHIPPED
PRODUCTION SHIPPED

CONSUMED requires exact contract/release-bundle identity.

WINDOWS PROVEN requires the exact ClassroomPath-generated personalized EXE and real Windows evidence above.

STAGING SHIPPED / PRODUCTION SHIPPED may only be claimed after separately authorized deployments that actually use the same releaseId; never infer them from source/CI state.

Do not perform staging/production mutation, tag creation, or promotion while implementing #165 unless separately authorized.

[balejosg]

Compatibility with the immutable-signed-installer roadmap (#161 / OpenPath #252)

#165 is an incident-delivery proof, not a mandate to preserve ClassroomPath's current personalized-EXE path.

Before implementation, inspect the status of:

OpenPath #250/#248/#251/#249/#252
ClassroomPath #161

If the legacy personalized-EXE path is still canonical

Follow the current #165 generation/provenance steps and prove the exact personalized EXE produced from the exact promoted OpenPath Windows component.

If OpenPath #249 + ClassroomPath #161 have already cut over

Do not update, revive, or add tests that make the retired per-request PE-personalization path authoritative again.

Translate #165's identity chain to the canonical immutable model:

ClassroomPath releaseId
-> exact OpenPath Promotion Contract
-> exact final signed OpenPath-Windows-Setup.exe identity from #251
-> exact external deployment/bootstrap bundle/reference used by the test
-> same immutable EXE bytes executed on Windows
-> #246/#253/#186 runtime proof

In that architecture, the downloaded deployment package may contain deployment-specific external data while the .exe SHA256 remains identical to the promoted signed installer. Evidence must distinguish:

immutable EXE identity
external bootstrap/deployment identity
ClassroomPath releaseId

without exposing bearer credentials.

Final invariant across either architecture:

ClassroomPath proves the exact user-facing Windows installation path selected by its releaseId.
It must never preserve a superseded installer architecture just to satisfy stale ticket wording.

Coordinate any actual cutover/legacy deletion with #161; #165 should not duplicate that migration work.

[balejosg]

2026-09-08 implementer clarification — consume the canonical OpenPath Windows architecture, not historical template terminology

The body of #165 is intentionally incident-focused and still uses the personalized-template model because that was the architecture of the failing 2026-09-03 installer. Do not turn those field names into a permanent downstream dependency.

1. First determine which OpenPath Windows architecture #255 actually promoted

Before changing ClassroomPath, inspect the exact #255 completion contract and the status of OpenPath #249/#250/#251.

Then follow exactly one canonical path:

A. legacy template/personalized EXE still canonical
   -> consume windowsOfflineInstaller template/sourceSha/releaseTag/hash
   -> generate personalized EXE through the supported OpenPath/ClassroomPath integration
   -> prove derivation + install that exact generated EXE

B. immutable signed installer cutover is canonical
   -> consume final signed installer identity/provenance from the exact OpenPath contract
   -> use the external deployment/bootstrap contract
   -> do NOT resurrect template overlay/personalized-PE generation merely to satisfy old #165 wording

The downstream invariant is architecture-independent:

ClassroomPath releaseId
-> exact OpenPath contract
-> exact canonical Windows artifact/deployment identity
-> exact bytes/bootstrap used by ClassroomPath user flow
-> real Windows proof

2. Do not duplicate OpenPath artifact semantics in the Release Bundle

The Release Bundle should preserve the exact OpenPath contract bytes/hash and project only the runtime fields ClassroomPath actually needs. Do not create a second ClassroomPath schema that independently interprets signing/template inheritance rules.

If OpenPath changes interfaces.windowsOfflineInstaller, ClassroomPath must explicitly validate/support the new interface version rather than silently treating old template fields as still authoritative.

3. Keep downstream Windows proof thin but exact

Do not rerun the whole upstream adversarial AppLocker matrix. ClassroomPath must prove integration identity and one representative security smoke against the exact user-facing path:

OpenPath contract identity matches selected releaseId
canonical Windows artifact/bootstrap identity matches contract
actual generated/downloaded artifact used by test is recorded
installer succeeds
Firefox readiness succeeds
AppControl committed
Edge denied
benign student-writable PE denied
Firefox allowed
health healthy

If upstream strict mode #256 is not enabled by ClassroomPath, do not add strict-mode expectations here.

4. Do not use timestamps as artifact identity

The original incident used file timestamps only as forensic clues. Future #165 evidence must use immutable hashes/SHAs/contract identity. Installed endpoint provenance, if added, should come from canonical OpenPath metadata rather than ClassroomPath inventing its own marker.

5. Rollout sequencing

Do not update the submodule to a source-only fix before #255 publishes the exact consumer-ready contract. Once #255 is complete:

update submodule to exact promoted SHA
-> build RC
-> verify exact contract/releaseId
-> run ClassroomPath generated/download integration E2E
-> only then, with separate authorization, staging
-> production promotes the same proven releaseId

No new OpenPath/template resolution is allowed during staging or production promotion.

6. Failure handling

If the ClassroomPath user-facing generation/download path produces bytes whose canonical OpenPath base/signed identity cannot be proven against the selected contract, fail the canary/release gate. Do not fall back to the previously provisioned Windows artifact silently.

This is especially important after the 2026-09-03 incident: a newly generated/downloaded file can still contain an older OpenPath runtime unless its provenance is bound to the selected release contract.