[Util] Fix #33919: az upgrade: Warn about Device Guard / WDAC blocking after MSI install - #33920
[Util] Fix #33919: az upgrade: Warn about Device Guard / WDAC blocking after MSI install#33920Aditya Pujara (a0x1ab) with Copilot wants to merge 15 commits into
az upgrade: Warn about Device Guard / WDAC blocking after MSI install#33920Conversation
|
Hi Copilot, |
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
microsoft-github-policy-service
Bot
added
Auto-Assign
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
Co-authored-by: a0x1ab <59631311+a0x1ab@users.noreply.github.com>
az upgrade MSI install
Live test results —
|
![x-engineering-agent[bot]](https://avatars.githubusercontent.com/in/4205534?s=60&v=4){kind=small}
There was a problem hiding this comment.
CI Review — PR #33920
The live-test workflow passed successfully. However, one required CI check
is currently failing:
Azure.azure-cli(Build #20260818.18) — https://github.com/Azure/azure-cli/runs/95796544110
Looking at the Azure DevOps build logs (buildId 339177), the failure trace shows:
##[error]The Operation will be canceled. The next steps may not contain expected logs.
fatal: early EOF
##[error]The operation was canceled.
This occurred during the Checkout step (Checkout Azure/azure-cli@copilot/fix-azure-cli-289-issue)
while cloning the repository, which in turn caused the dependent Unit Test for Core Python312 job
to be canceled. This looks like a transient infrastructure hiccup (an interrupted/canceled git clone)
rather than an issue introduced by this PR's changes.
Copilot please take a look — if the change itself doesn't explain the checkout failure, this is
likely a flaky CI infrastructure issue and re-running the pipeline (e.g. via a new commit or asking
a maintainer to restart the failed job) should resolve it. If you do find something in the diff that
could plausibly affect checkout/build (e.g. very large added files, submodule changes), please fix it.
Posted by agent-assist (autonomous bug-fix pipeline).
|
Started a Copilot task using Posted by agent-assist (autonomous bug-fix pipeline). |
The CI failure was a transient infrastructure issue — the build was canceled due to an |
Root cause identified and fixed in the latest commit. Root cause: Azure Linux 4.0 (Beta) removed the Fix (3 files):
|
|
/azp run |
|
Azure Pipelines: Successfully started running 3 pipeline(s). |
Live test results —
|
x-engineering-agent
Bot
changed the title
az upgrade MSI installaz upgrade: Warn about Device Guard / WDAC blocking after MSI install
There was a problem hiding this comment.
CI Failure Summary
Live test passed, but 2 required checks are failing on this PR (head commit 6c3a31b):
Azure.azure-cli(build) — failed: https://dev.azure.com/azclitools/5147fa83-336e-44ef-bbe0-c86b8ae86cbb/_build/results?buildId=340543Azure.azure-cli (Check the Format of Pull Request Title and Content)— failed: https://dev.azure.com/azclitools/5147fa83-336e-44ef-bbe0-c86b8ae86cbb/_build/results?buildId=340543
The PR title itself is already compliant ([Util] Fix #33919: \az upgrade`: Warn about Device Guard / WDAC blocking after MSI install), so the title/content check failure is likely due to missing required PR description content (e.g. #33919` link format, history entry, or other required section) — please review the Azure Pipelines build log linked above for the exact validation error and also inspect the build failure log for the root cause.
Please fix both failures.
|
Started a Copilot task using |
Azure Linux 4.0 removed the /usr/lib64 -> /usr/lib symlink that AZL3 carried.
On Azure Linux, %{_libdir} expands to /usr/lib, so the CLI RPM is installed to
/usr/lib/az. The previous code hardcoded lib64 in three places, which worked on
AZL3 (via the symlink) but broke on AZL4.
- azure-cli.spec: generated /usr/bin/az entry script now probes lib64 first then
falls back to lib at runtime, supporting both Fedora/RHEL and Azure Linux 4+.
- test_azurelinux_in_docker.sh: detects the actual az install dir before
installing pytest and passes AZ_LIB_DIR to the test script.
- test_rpm_package.py: uses AZ_LIB_DIR env var or auto-detects via os.path.isdir
instead of hardcoding /usr/lib64/az.
Co-authored-by: a0x1ab <59631311+a0x1ab@users.noreply.github.com>
Investigated both failures from buildId=340543:
|
Live test results —
|
|
Automated sensitive-information remediation ran on this pull request.
Agent Assist does not modify source files. The PR creator must remove or replace each suspected value at the linked line:
If a credential was exposed, rotate or revoke it immediately. Detected values are never copied into this comment. ✅ Confirm the finding · ❌ Dispute the finding GitHub only supports a fixed reaction set, so 👍 represents ✅ and 👎 represents ❌. The bot-created reactions are only poll choices. |
|
Automated sensitive-information remediation ran on this pull request.
Azure Client Tools Agent does not modify source files. The PR creator must remove or replace each suspected value at the linked line:
If a credential was exposed, rotate or revoke it immediately. Detected values are never copied into this comment. ✅ Confirm the finding · ❌ Dispute the finding GitHub only supports a fixed reaction set, so 👍 represents ✅ and 👎 represents ❌. The bot-created reactions are only poll choices. |
Aditya Pujara (a0x1ab)
added
X Engineering Agent Reviewed
|
🔔 Routing this PR to @Azure/act-platform-engineering-squad. |
|
Automated sensitive-information remediation ran on this pull request.
X Engineering Agent does not modify source files. The PR creator must remove or replace each suspected value at the linked line:
If a credential was exposed, rotate or revoke it immediately. Detected values are never copied into this comment. ✅ Confirm the finding · ❌ Dispute the finding GitHub only supports a fixed reaction set, so 👍 represents ✅ and 👎 represents ❌. The bot-created reactions are only poll choices. |
Live test results —
|
There was a problem hiding this comment.
Automated review handoff
All CI checks passed (110/110) and the dispatched live test succeeded, but this PR still has an outstanding repository-policy finding and a scope concern. The automated fixer has already made 3 attempts on this PR and reached its iteration cap, so this is being handed off for human review instead of triggering another automated fix cycle.
Test validation
- Live test: Passed. Workflow run
- Regression coverage: Present for
util: 1 focused test file(s) changed.
Repository policy findings
- Release artifact validator (blocking) —
src/azure-cli/HISTORY.rst:134: Azure CLI aggregate history is generated from pull-request metadata and must not be edited directly.
Remediation: Remove the direct history-file edit. Put one customer-facing note in the[Component]PR title, or put multiple or overriding notes in the PR description'sHistory Notessection.
Verify: Run the PR title/content check and confirm the release-note generator derives the intended entry from PR metadata.
Scope-consistency finding (evidence-confirmed)
- Unrelated packaging changes bundled into a Windows-only fix —
scripts/release/rpm/azure-cli.spec,scripts/release/rpm/test_azurelinux_in_docker.sh, andscripts/release/rpm/test_rpm_package.pyall change RPM packaging/test logic to support Azure Linux 4.0's removal of the/usr/lib64 -> /usr/libsymlink (probinglib64then falling back tolib). None of this is related to the PR's stated purpose (az upgrade: warn about Device Guard/WDAC blocking a Windows MSI upgrade). The.specchange also touches the generatedazlauncher shell script (bin_dir=... ${BASH_SOURCE[0]},_az_pypathprobing loop).
Remediation: Split the RPM/Azure-Linux-4.0 packaging fix into its own PR with its own title/History Notes, so each change gets independent review and its History entry accurately describes it. Keep this PR scoped to the Device Guard/WDAC warning inutil/custom.py, its test, and the troubleshooting doc.
Verify: Confirm theutilPR alone reproduces/fixes issue #33919, and that the RPM packaging fix is validated independently (e.g. building the RPM against Azure Linux 4.0 and runningtest_rpm_package.py).
Risk assessment
29/100 · Medium · High confidence
The Medium rating is driven by public CLI behavior, failure-handling behavior.
- Change scope: 7 changed files, 230 changed lines (
+215/-15), including 1 production file. - Affected components:
util - Risk drivers: public CLI behavior (+18); failure-handling behavior (+12)
- Regression evidence: Changed regression tests are included, reducing risk.
- Confidence: High because changed-line patches were available for every production file.
- Required review: Owning-squad review is recommended for
utilbefore merge.
🤖 PR Validation — ️✔️ All clear
Related command
az upgradeDescription
On machines enforcing Device Guard / Windows Defender Application Control (WDAC) code integrity policies (e.g. Azure Local cluster nodes),
az upgradecan install a newer MSI whose bundledpython.exeis blocked by the policy, leaving a previously working Azure CLI unusable. The CLI has no supported way to query the enforced WDAC policy or predict whether a specific binary will be allowed, so this can't be reliably auto-detected before the upgrade runs.custom.py:_upgrade_on_windows()now logs a warning during the MSI upgrade flow reminding users on locked-down machines to verifyaz versionworks after upgrading, and pointing to the rollback path if it's blocked.doc/install_troubleshooting.md: Added a troubleshooting section documenting the symptom (Code Integrity Event IDs 3033/3077, "blocked by your organization's Device Guard policy") with remediation steps — roll back to the previous MSI, stage-test upgrades before broad rollout across a cluster, or engage the policy administrator._upgrade_on_windows().Testing Guide
History Notes
[Core]
az upgrade: Warn about Device Guard / WDAC policies potentially blocking the CLI after a Windows MSI upgradeThis checklist is used to make sure that common guidelines for a pull request are followed.
The PR title and description has followed the guideline in Submitting Pull Requests.
I adhere to the Command Guidelines.
I adhere to the Error Handling Guidelines.