feat: add MacOS support to confcom

[Adam Short (ashort96)]

🤖 PR Validation — ️✔️ All clear

Breaking Changes
️✔️ None

Add MacOS support for both Intel and Apple Silicon Macs. By updating integrity-vhd to v2.3 and pulling this
microsoft/integrity-vhd#21, we now have the ability to run confcom generation on MacOS. This only adds support for confcom, it does not touch katapolicygen.

---

This checklist is used to make sure that common guidelines for a pull request are followed.

Related command

General Guidelines

• Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
• Have you run python scripts/ci/test_index.py -q locally? (pip install azdev required)
• My extension version conforms to the Extension version schema

For new extensions:

• My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish

There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify src/index.json.

[azure-client-tools-bot-prd]

Hi Adam Short (@ashort96),
Please write the description of changes which can be perceived by customers into HISTORY.rst.
If you want to release a new extension version, please update the version in pyproject.toml (or setup.py, if the extension has not migrated yet) as well.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[microsoft-github-policy-service]

Thank you for your contribution Adam Short (@ashort96)! We will review the pull request and get back to you soon.

[Copilot]

Copilot review overview

🟡 Changes recommended

The extension version and image-layer binary selection need fixes, along with documented requirements and Darwin architecture coverage.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 · 1 · 2

Open (4)

• Use host-specific dmverity binaries in image layer resolution · New
• Bump extension version and add matching history section · New
• Add Darwin architecture selection and unsupported-architecture tests · New
• Add Darwin architecture selection and unsupported-architecture tests · New

What changed in this PR

Adds macOS support for confcom Linux-container policy generation using native Intel and Apple Silicon binaries.

Changes:

• Packages and selects Darwin dmverity-vhd and sign1util binaries.
• Updates documentation and CLI help.
• Records the macOS support history entry.

File	Summary
src/​confcom/​setup.py	Packages Darwin binaries; version bump and host-specific image-layer selection remain needed.
src/​confcom/​README.md	Documents macOS support; Docker requirements should distinguish image and --tar workflows.
src/​confcom/​HISTORY.rst	Records the feature under the current version; a new version section is needed.
src/​confcom/​azext_confcom/​rootfs_proxy.py	Selects Darwin hashing binaries; architecture coverage is needed.
src/​confcom/​azext_confcom/​cose_proxy.py	Selects Darwin signing binaries; architecture coverage is needed.
src/​confcom/​azext_confcom/​_params.py	Updates CLI parameter help; Docker and Linux-container requirements need clarification.
src/​confcom/​azext_confcom/​_help.py	Updates command help; Docker and Linux-container requirements need clarification.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🟡 Changes recommended

Unresolved moderate issues remain in executable permissions, platform propagation, and Darwin/Windows validation.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 · 1 · 3

Open (5)

• Use host-specific dmverity binaries in image layer resolution
• Reject Windows policy targets on macOS · New
• Qualify Docker requirement for Windows image workflows · New
• Add Darwin architecture selection and unsupported-architecture tests
• Add Darwin architecture selection and unsupported-architecture tests

Resolved since last review (1)

• Bump extension version and add matching history section

[Yong Zhang (yonzhan)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).

[Adam Short (ashort96)]

Ethan Yang (@necusjz) what is the best path forward for getting this merged? I'd love to have native MacOS support for this since the upstream dependencies are now published for MacOS.

[Ethan Yang (necusjz)]

Adam Short (@ashort96) are you from confcom team? +owner Tingmao Wang (@micromaomao) for awareness.

[Adam Short (ashort96)]

Adam Short (Adam Short (@ashort96)) are you from confcom team? +owner Tingmao Wang (Tingmao Wang (@micromaomao)) for awareness.

I am not from the confcom team, I just have a great interest in getting native MacOS support for azure-cli, along with Daniel James (@dwhjames).

Tingmao Wang (@micromaomao) has helped us in this effort by merging the following PRs:

• Add builds for macOS microsoft/cosesign1go#34
• Add builds for macOS microsoft/integrity-vhd#21

[Tingmao Wang (micromaomao)]

Hi, this looks good to me but to merge it we will want to do some confcom end-to-end testing beforehand, which our team has no space to do this week.

[KenGordon]

We can't support a MacOS version of this tool, certainly not a PR from someone we do not know. If you have a proper use case please email me and explain.

[Daniel James (dwhjames)]

KenGordon

We are customers of Azure, and are users of confidential containers with ACI. Some of our fleet is macOS, hence the desire to expand the multi-OS support of this confcom extension from Windows and Linux to include macOS.

We are trying to be good customers by contributing back into the product ecosystem.
And some customer feedback: it’s been surprisingly difficult to contribute. We’ve submitted minor fixes in the past year and had quite the challenge to get these accepted.

• Fix doc link to dmverity-vhd tool #9068
• Fix README for attest package microsoft/confidential-sidecar-containers#237
• Add builds for macOS microsoft/integrity-vhd#21
• Choose message digest for ECDSA explicitly in tests microsoft/cosesign1go#33
• Add builds for macOS microsoft/cosesign1go#34

But most of these have now been accepted; the upstream changes relevant to this PR are

• Add builds for macOS microsoft/integrity-vhd#21
• Add builds for macOS microsoft/cosesign1go#34

Thanks you Tingmao Wang (@micromaomao) for engaging with us on these.

In our honest estimation, we didn’t think the maintenance burden for the support of a third OS on this confcom extension would be blocking issue.

1. The changes here are primarily about extending the lookup tables for which binaries to download and use for integrity-vhd and cosesign1go.
2. The upstream projects integrity-vhd and cosesign1go built and functioned correctly for macOS without any code changes. And ORAS, the other third-party binary dependency in this project, already has macOS support.
3. We’ve used the development tooling for azure cli to confirm that we can get matching hashes across operating systems for the confidential computing enforcement policy.

We’d happily take feedback on minimizing these changes, if the maintenance burden is the primary objection.

Another approach we could take here is a code change that would allow environment variables to override the binary dependencies. We took this initial approach, because integrity-vhd and cosesign1go now have official binary releases; however, we would happily fall back to managing the binaries outside of the extension, as long as there was a mechanism to override.

I hope you’ll consider this; we are customers, and we’re trying to remain as customers.

[KenGordon]

Can you email me directly and tell me who you are please?     Ken

…

________________________________ From: Daniel James ***@***.***> Sent: Tuesday, October 06, 2026 18:24 To: Azure/azure-cli-extensions ***@***.***> Cc: Ken Gordon ***@***.***>; Mention ***@***.***> Subject: Re: [Azure/azure-cli-extensions] feat: add MacOS support to confcom (PR #10380) [https://avatars.githubusercontent.com/u/470008?s=20&v=4]dwhjames left a comment (Azure/azure-cli-extensions#10380)<#10380 (comment)> KenGordon<https://github.com/KenGordon> We are customers of Azure, and are users of confidential containers with ACI. Some of our fleet is macOS, hence the desire to expand the multi-OS support of this confcom extension from Windows and Linux to include macOS. We are trying to be good customers by contributing back into the product ecosystem. And some customer feedback: it’s been surprisingly difficult to contribute. We’ve submitted minor fixes in the past year and had quite the challenge to get these accepted. * #9068<#9068> * microsoft/confidential-sidecar-containers#237<microsoft/confidential-sidecar-containers#237> * microsoft/integrity-vhd#21<microsoft/integrity-vhd#21> * microsoft/cosesign1go#33<microsoft/cosesign1go#33> * microsoft/cosesign1go#34<microsoft/cosesign1go#34> But most of these have now been accepted; the upstream changes relevant to this PR are * microsoft/integrity-vhd#21<microsoft/integrity-vhd#21> * microsoft/cosesign1go#34<microsoft/cosesign1go#34> Thanks you Tingmao Wang ***@***.***)<https://github.com/micromaomao> for engaging with us on these. In our honest estimation, we didn’t think the maintenance burden for the support of a third OS on this confcom extension would be blocking issue. 1. The changes here are primarily about extending the lookup tables for which binaries to download and use for integrity-vhd and cosesign1go. 2. The upstream projects integrity-vhd and cosesign1go built and functioned correctly for macOS without any code changes. And ORAS, the other third-party binary dependency in this project, already has macOS support. 3. We’ve used the development tooling for azure cli to confirm that we can get matching hashes across operating systems for the confidential computing enforcement policy. We’d happily take feedback on minimizing these changes, if the maintenance burden is the primary objection. Another approach we could take here is a code change that would allow environment variables to override the binary dependencies. We took this initial approach, because integrity-vhd and cosesign1go now have official binary releases; however, we would happily fall back to managing the binaries outside of the extension, as long as there was a mechanism to override. I hope you’ll consider this; we are customers, and we’re trying to remain as customers. — Reply to this email directly, view it on GitHub<#10380?email_source=notifications&email_token=ABI7RIDKN562DRJDT7ZPMVL5SUTENA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMBSGE3DQMRVGU4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-6021682558>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABI7RIBHIM2I2Z72FEZOQXT5SUTENAVCNFSNUABFKJSXA33TNF2G64TZHMYTANRVHAYDAMRUHNEXG43VMU5TKNJUGEYDGNBUGQZKC5QC>. You are receiving this because you were mentioned.Message ID: ***@***.***>