You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CI: run the Windows runner trust probe under Windows PowerShell 5.1 - #3340
pwsh is not installed on every Windows runner label, but Windows PowerShell (powershell) is. This switches the Windows step of the runner trust probe to shell: powershell and makes the scripts it runs compatible with both Windows PowerShell 5.1 and PowerShell 7+.
.github/workflows/runner-trust-probe.yml: the Windows probe step uses shell: powershell.
.github/actions/upgrade-ca-certificates/emudhra_intermediates.ps1 (shared helper): certificates are built from the decoded PEM body instead of X509Certificate2.CreateFromPem (.NET 5+ only), SHA-256 is computed from RawData via a new Get-CertificateSha256 instead of GetCertHashString('SHA256'), and ChainPolicy.DisableCertificateDownloads is only set when the property exists.
ci/tools/runner_trust_probe.ps1: Invoke-WebRequest -SkipHttpErrorCheck (PowerShell 7+ only) is dropped, and any HTTP response, including an error status, is reported as a successful connection (FAIL). The step summary is appended as BOM-less UTF-8 because -Encoding utf8 writes a BOM on 5.1.
Behavior on PowerShell 7+ is unchanged. The upgrade-ca-certificates action still runs under pwsh and dot-sources the same helper, which now works on either shell.
Known limitation: on 5.1, a TrustFailureWebException does not distinguish a chain failure from a hostname mismatch, so a hostname-only failure would be reported as PASS rather than FAIL. Capturing the TLS policy errors would need a compiled validation callback, which is left out of this change. This only matters if the test endpoints' certificates stop matching their hostnames.
pwsh is not installed on every Windows runner label, while Windows
PowerShell (powershell) is. Switch the probe step to `shell: powershell`
and make the probe script and the shared eMudhra helper compatible with
both Windows PowerShell 5.1 and PowerShell 7+:
- Build certificates from the PEM body instead of CreateFromPem (.NET 5+).
- Compute SHA-256 from RawData instead of GetCertHashString('SHA256').
- Set ChainPolicy.DisableCertificateDownloads only when it exists.
- Drop Invoke-WebRequest -SkipHttpErrorCheck and treat any HTTP response
as a successful connection.
- Append the step summary as BOM-less UTF-8.
Improved certificate validation and trust-store checks on Windows across PowerShell 5.1 and PowerShell 7+.
Windows trust probes now handle HTTP certificate errors consistently and generate summaries with reliable UTF-8 encoding.
Certificate chain checks work with both .NET Framework and newer .NET versions.
Improved compatibility across supported PowerShell versions helps certificate checks run consistently on Windows.
The certificate update script and trust-store probe change certificate handling and endpoint checks for Windows PowerShell compatibility. The workflow now selects Windows PowerShell for the trust-store probe.
Changes: Windows PowerShell compatibility
Layer / File(s)
Summary
Certificate loading and chain validation .github/actions/upgrade-ca-certificates/emudhra_intermediates.ps1
Certificate loading enumerates JSON entries across PowerShell versions, decodes PEM data without CreateFromPem, and validates DER SHA-256 digests. Chain certificate downloads are disabled only when the policy supports that property.
Trust probe and workflow invocation .github/workflows/runner-trust-probe.yml, ci/tools/runner_trust_probe.ps1
The workflow step selects powershell. The probe writes BOM-less UTF-8 summaries, compares certificates using Get-CertificateSha256, and handles HTTP responses without -SkipHttpErrorCheck.
Change: Bug fix
Merge Risk: Moderate · up to deb1b
The probe can produce incorrect trust decisions for proxy failures or network-fetched certificate chains, so these issues should be resolved before merging.
- [ ] Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Tip
🎯 Customize your risk assessments
Guide how CodeRabbit assesses merge risk and security architecture risk. Highlight sensitive changes and explain your security boundaries using Merge Risk Instructions and Security Risk Instructions in your review settings. Security architecture risk assessments require the Advanced plan or above.
✅ Automatic approvals, with your rules
Let CodeRabbit approve pull requests once required threads are resolved, pre-merge checks pass, and your risk limits are met. Enable Automatic approvals in review settings, with overrides for teams or file paths.
CodeRabbit Verify
Run CodeRabbit Verify to test the changes in this pull request.
The reason will be displayed to describe this comment to others. Learn more.
Follow-up Comments
important: Classify proxy responses separately from target responses.
77-79: Minor · Functional Correctness · Quick win
important: Classify proxy responses separately from target responses.
When Invoke-WebRequest uses a system proxy, a failed HTTPS CONNECT, such as HTTP 407, can return a non-null Exception.Response before the target certificate is checked. This branch then reports certificate was trusted and fails the probe for a proxy failure. Distinguish proxy responses from target responses, or classify proxy-only failures as INCONCLUSIVE.
Reviewing files that changed from the base of the PR and between aa052a7 and deb1b4a.
Files selected for processing: 1
ci/tools/runner_trust_probe.ps1
Included review availability: This review used your included allowance. Your plan provides up to 12 included reviews per hour; 10 remain after this review.
The reason will be displayed to describe this comment to others. Learn more.
Known limitation: on 5.1, a TrustFailure WebException does not distinguish ...
That looks like a reasonable compromise to me.
codex GPT-6.1-Sol ultra (with small edits):
[P3] Proxy rejection can cause a false failure — runner_trust_probe.ps1:77–80: On 5.1, a proxy’s 407 rejection can populate Exception.Response before target TLS, causing “certificate was trusted” and a failed probe. This confirms CodeRabbit’s remaining concern; classify proxy failures as INCONCLUSIVE. See .NET’s CONNECT handling.
Regarding the known limitation explained in the PR description: The independent gating check still verifies explicit distrust of all 16 compromised certificates, so the hostname ambiguity is an acceptable compromise.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
CI/CDCI/CD infrastructuregithub_actionsPull requests that update GitHub Actions code
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
pwshis not installed on every Windows runner label, but Windows PowerShell (powershell) is. This switches the Windows step of the runner trust probe toshell: powershelland makes the scripts it runs compatible with both Windows PowerShell 5.1 and PowerShell 7+..github/workflows/runner-trust-probe.yml: the Windows probe step usesshell: powershell..github/actions/upgrade-ca-certificates/emudhra_intermediates.ps1(shared helper): certificates are built from the decoded PEM body instead ofX509Certificate2.CreateFromPem(.NET 5+ only), SHA-256 is computed fromRawDatavia a newGet-CertificateSha256instead ofGetCertHashString('SHA256'), andChainPolicy.DisableCertificateDownloadsis only set when the property exists.ci/tools/runner_trust_probe.ps1:Invoke-WebRequest -SkipHttpErrorCheck(PowerShell 7+ only) is dropped, and any HTTP response, including an error status, is reported as a successful connection (FAIL). The step summary is appended as BOM-less UTF-8 because-Encoding utf8writes a BOM on 5.1.Behavior on PowerShell 7+ is unchanged. The
upgrade-ca-certificatesaction still runs underpwshand dot-sources the same helper, which now works on either shell.Known limitation: on 5.1, a
TrustFailureWebExceptiondoes not distinguish a chain failure from a hostname mismatch, so a hostname-only failure would be reported as PASS rather than FAIL. Capturing the TLS policy errors would need a compiled validation callback, which is left out of this change. This only matters if the test endpoints' certificates stop matching their hostnames.Checklist