fix: use verified local packages for windows updates - #2816
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughWindows updates now resolve package formats, download and verify packages locally, and invoke the bundled PowerShell installer with package metadata. The installer supports validated local-package arguments, while tests cover rejection and successful activation paths. ChangesWindows local package update flow
Estimated code review effort: 4 (Complex) | ~45 minutes Merge Risk: ⚪ Minimal · up to The Windows update flow now uses locally downloaded and verified packages while preserving the existing activation path; no actionable merge-blocking risk remains after normal checks and review. Sequence Diagram(s)sequenceDiagram
participant WindowsUpdater
participant ReleasePackage
participant BundledInstaller
participant herdr.exe
WindowsUpdater->>ReleasePackage: download and verify package
WindowsUpdater->>BundledInstaller: pass local package metadata
BundledInstaller->>herdr.exe: install and activate executable
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
great ty! |
What
Windows self-updates still ran the web installer through:
That process chain triggers Cortex XDR's PowerShell downloader rule. In #2751 it terminated the complete Windows Terminal causality chain and left the update incomplete.
herdr updatenow downloads the exact Windows package selected by the already-fetched release manifest, verifies its published SHA-256, and runs the bundled installer against that local package.This brings Windows in line with the existing Linux and macOS update flow for release acquisition. Herdr now owns manifest selection, artifact download, and checksum verification on every platform. PowerShell receives only local paths and release metadata.
The public
install.ps1flow stays unchanged for first-time installs.Why
Linux and macOS already let Herdr select the release, download the exact artifact, verify it, and then perform the platform-specific activation.
Windows took a separate detour. After Herdr selected the release, it handed acquisition back to a remote PowerShell script, which fetched the manifest and package again. That duplicated work and looked exactly like a PowerShell downloader to endpoint protection.
Removing that Windows-only detour simplifies updater ownership and removes the observed trigger. This is not an EDR-specific retry or exception.
The Windows-specific activation path stays where it already works. The PowerShell installer still owns ConPTY validation, the install lock, atomic activation, rollback, junction updates, retention, and cleanup. Only release acquisition moves into Herdr.
Testing
just checkcurlperforms network downloads and PowerShell receives local paths and metadata onlyRefs #2751