Revert pwsh preference for Windows upgrades#487
Conversation
| if ($sha256) { | ||
| $sha256.Dispose() | ||
| } |
There was a problem hiding this comment.
🟡 Accessing potentially uninitialized $sha256 in finally block throws under strict mode
In the SHA256 fallback path of Verify-Checksum, if [System.Security.Cryptography.SHA256]::Create() on line 83 throws before assigning to $sha256, the finally block at line 88 references $sha256 which was never set. Because Set-StrictMode -Version Latest is active (install.ps1:2), accessing an uninitialized variable throws a RuntimeException, masking the original error.
Root Cause
PowerShell try/finally blocks share the same scope, so $sha256 is visible in finally only if the assignment on line 83 succeeded. If SHA256::Create() throws, $sha256 is never assigned. Under strict mode, if ($sha256) on line 88 raises:
The variable '$sha256' cannot be retrieved because it has not been set.
This replaces the original exception, making it harder to diagnose the real failure. The fix is to initialize $sha256 = $null before the try block.
Impact: On the rare occasion that SHA256::Create() fails (e.g., FIPS policy restrictions), the user sees a confusing "variable not set" error instead of the actual SHA256 creation failure.
| if ($sha256) { | |
| $sha256.Dispose() | |
| } | |
| if ($null -ne $sha256) { | |
| $sha256.Dispose() | |
| } |
Was this helpful? React with 👍 or 👎 to provide feedback.
Motivation
install.ps1removes the need to preferpwsh.Description
spawn_powershellclosure that triedpwshthenpowershelland instead invokepowershelldirectly viaCommand::new("powershell")while keeping-NoProfile,-ExecutionPolicy Bypass,-Command,CREATE_NO_WINDOW, theGIT_AI_RELEASE_ENVenv var, and the silentstdout/stderrbehavior.Testing
Codex Task