Verify bare binaries in `macos_verify_code_signing` by mokagio · Pull Request #782 · wordpress-mobile/release-toolkit

mokagio · 2026-11-04T07:56:13Z

What does it do?

Lets macos_verify_code_signing verify bare binaries, identified by having no file extension, so CLIs can stop hand-rolling this check.

@iangmaia asked why beeper/cli had its own lane instead of using the action; the answer was that the action only took .app and .dmg.

It also adds a verify_hardened_runtime option, off by default, for app bundles and bare binaries.
Notarization requires the hardened runtime, so verify_notarization already covers it implicitly, but a caller verifying before submission has to turn that off.
beeper/cli still keeps its own check for this; once this lands it can drop it.

Gotchas

Gatekeeper is assessed with --type open --context context:primary-signature, not the --type execute used for app bundles.
--type execute rejects every bare binary, notarized or not, with the code is valid but does not seem to be an app.
A bare binary can't be stapled, so there is no stapler check and the Gatekeeper result relies on an online lookup that can lag a fresh submission.
Pass verify_notarization: false when verifying right after signing.
verify_hardened_runtime skips disk images instead of failing, so a list mixing an app with its .dmg still works.

How to test

The specs stub the shell commands, so I also ran the action on a notarized beeper arm64 binary from Buildkite:

Binary	Result
As built, expected authority	Passes (`Notarized Developer ID`)
Different expected authority	Fails: not signed by the authority
Ad-hoc signed	Fails: wrong authority, and rejected by Gatekeeper
Signature removed	Fails: not signed at all
One byte changed	Fails: signature not valid

verify_hardened_runtime, run directly against ad-hoc signed copies of /usr/bin/true, passes with --options runtime (flags=0x10002(adhoc,runtime)) and fails without it.

Re-signing with Developer ID without notarizing makes spctl itself report rejected, source=Unnotarized Developer ID.
I ran that command directly, not through the action.

Checklist before requesting a review

Run bundle exec rubocop to test for code style violations and recommendations.
Add Unit Tests (aka specs/*_spec.rb) if applicable.
Run bundle exec rspec to run the whole test suite and ensure all your tests pass. Only this action's spec ran locally; the full suite is left to CI.
Make sure you added an entry in the CHANGELOG.md file to describe your changes under the appropriate existing ### subsection of the existing ## Trunk section.

Note

Notice the missing apps-infra-tooling review request. More in pbArwn-89X-p2#comment-9038

CLIs ship bare Mach-O binaries, so `beeper/cli` and the Day One CLI each hand-roll this verification because the action only accepted `.app` and `.dmg`. Raised in beeper/cli#56 (comment). --- Generated with the help of Claude Code (Opus 5.5), https://code.claude.com

`spctl --type execute` rejects every bare binary, notarized or not, with `the code is valid but does not seem to be an app`. The stubbed specs could not catch this; running against a real binary did. Checked on a notarized `beeper` binary from Buildkite: `--type open --context context:primary-signature` reports `Notarized Developer ID`, and rejects a Developer ID re-signed copy as `Unnotarized Developer ID`. --- Generated with the help of Claude Code (Opus 5.5), https://code.claude.com

--- Generated with the help of Claude Code (Opus 5.5), https://code.claude.com

mokagio · 2026-11-06T00:02:29Z

+          when ''
+            verify_binary(path: path, expected_authority: params[:expected_authority], verify_notarization: params[:verify_notarization])


I suppose this could backfire if someone generates a package without an extension, but that seems like a perverse case. And the spctl check may (haven't checked) fail because of the mismatch. Seems like an edge case not yet worth covering at this stage.

I can see actual cases where this would backfire in the opposite direction, i.e. a binary-only CLI with a name that make it looks like it has an extension. For example my-tool-v1.2.3 would be detected like having an extension .3…

The method doc comment now covers only what affects the caller. Why `spctl` runs with `--type open` is an implementation detail, so it sits inline. --- Generated with the help of Claude Code (Opus 5.5), https://code.claude.com

A caller that verifies before notarizing passes `verify_notarization: false`, so nothing asserted the hardened runtime that notarization will later demand. beeper/cli#64 kept its own check for exactly this. The option defaults to `false` so existing callers are unaffected. Disk images are skipped with a warning rather than failed, because a list mixing an app with its `.dmg` is a normal call. --- Generated with the help of Claude Code (Opus 5.5), https://code.claude.com

--- Generated with the help of Claude Code (Opus 5.5), https://code.claude.com

The `macos_verify_code_signing` action gained a `verify_hardened_runtime` option in wordpress-mobile/release-toolkit#782, so the lane no longer needs its own `codesign --display` check. --- Generated with the help of Claude Code (Opus 5.5), https://code.claude.com

A correctly configured call that lists an app with its `.dmg` should not print a warning. The docs now state outright that notarization implies the hardened runtime, which is why the option is for verifying before submission. --- Generated with the help of Claude Code (Opus 5.5), https://code.claude.com

Copilot

🟡 Changes recommended

Hardened-runtime verification can falsely pass when a universal binary has an unhardened architecture slice or an executable path contains text mimicking the required runtime flags.

2 open issues

_{Review effort: Balanced}

AliSoftware · 2026-11-10T13:21:57Z

+        return if expected_authority.nil? && !verify_hardened_runtime

-        UI.user_error!("#{path} is not signed by '#{expected_authority}':\n#{details}")
+        details = sh('codesign', '--display', '--verbose=2', path)


Confirmed by my Claude, we should fix this.

AliSoftware · 2026-11-10T13:21:41Z

+        details = sh('codesign', '--display', '--verbose=2', path)
+        UI.user_error!("#{path} is not signed by '#{expected_authority}':\n#{details}") unless expected_authority.nil? || details.include?("Authority=#{expected_authority}")
+        # The flags list every option the code was signed with, e.g. `flags=0x10002(adhoc,runtime)`.
+        UI.user_error!("#{path} is not signed with the hardened runtime:\n#{details}") if verify_hardened_runtime && !details.match?(/flags=0x\h+\([^)]*\bruntime\b/)


Confirmed by my Claude, we should fix this

AliSoftware · 2026-11-10T11:45:49Z


        if signed?(path)
-          verify_authority!(path: path, expected_authority: expected_authority) unless expected_authority.nil?
+          verify_signature_details!(path: path, expected_authority: expected_authority, verify_hardened_runtime: false)


What's the point of passing the verify_hardened_runtime parameter to the function if you're not gonna use its value (besides the conditional printing of the UI.message log on line 49) and instead always pass false here? 🤔

AliSoftware · 2026-11-10T13:21:41Z

+        details = sh('codesign', '--display', '--verbose=2', path)
+        UI.user_error!("#{path} is not signed by '#{expected_authority}':\n#{details}") unless expected_authority.nil? || details.include?("Authority=#{expected_authority}")
+        # The flags list every option the code was signed with, e.g. `flags=0x10002(adhoc,runtime)`.
+        UI.user_error!("#{path} is not signed with the hardened runtime:\n#{details}") if verify_hardened_runtime && !details.match?(/flags=0x\h+\([^)]*\bruntime\b/)


Confirmed by my Claude, we should fix this

AliSoftware · 2026-11-10T13:21:57Z

+        return if expected_authority.nil? && !verify_hardened_runtime

-        UI.user_error!("#{path} is not signed by '#{expected_authority}':\n#{details}")
+        details = sh('codesign', '--display', '--verbose=2', path)


Confirmed by my Claude, we should fix this.

AliSoftware · 2026-11-10T13:23:50Z

+          when ''
+            verify_binary(path: path, expected_authority: params[:expected_authority], verify_notarization: params[:verify_notarization])


I can see actual cases where this would backfire in the opposite direction, i.e. a binary-only CLI with a name that make it looks like it has an extension. For example my-tool-v1.2.3 would be detected like having an extension .3…

mokagio added 2 commits November 4, 2026 18:53

mokagio self-assigned this Nov 4, 2026

Add CHANGELOG.md entry for bare binary support

3ad7e2f

--- Generated with the help of Claude Code (Opus 5.5), https://code.claude.com

mokagio mentioned this pull request Nov 4, 2026

Verify signatures with macos_verify_code_signing beeper/cli#64

Draft

mokagio commented Nov 6, 2026

View reviewed changes

mokagio added 3 commits November 6, 2026 11:15

Move spctl type rationale next to the call

d194c8a

The method doc comment now covers only what affects the caller. Why `spctl` runs with `--type open` is an implementation detail, so it sits inline. --- Generated with the help of Claude Code (Opus 5.5), https://code.claude.com

Add CHANGELOG.md entry for hardened runtime check

3b3d222

--- Generated with the help of Claude Code (Opus 5.5), https://code.claude.com

mokagio commented Nov 6, 2026

View reviewed changes

Comment thread lib/fastlane/plugin/wpmreleasetoolkit/actions/macos/macos_verify_code_signing.rb Resolved

mokagio added 2 commits November 7, 2026 05:21

Delete confusing comment

f411b2c

mokagio marked this pull request as ready for review November 6, 2026 21:56

Copilot AI balanced review requested due to automatic review settings November 6, 2026 21:56

This comment was marked as outdated.

Sign in to view

mokagio requested review from AliSoftware and iangmaia November 10, 2026 02:17

iangmaia requested a balanced review from Copilot November 10, 2026 09:55

Copilot started reviewing on behalf of iangmaia November 10, 2026 09:55

View session

Copilot AI reviewed Nov 10, 2026

View reviewed changes

AliSoftware reviewed Nov 10, 2026

View reviewed changes

Navigation Menu

Repository navigation

Verify bare binaries in `macos_verify_code_signing` - #782

Verify bare binaries in `macos_verify_code_signing`#782
mokagio wants to merge 8 commits into
trunkfrom
mokagio/macos-verify-bare-binaries

mokagio commented Nov 4, 2026 •

edited

Loading

Uh oh!

mokagio Nov 6, 2026

Uh oh!

AliSoftware Nov 10, 2026

Uh oh!

Uh oh!

This comment was marked as outdated.

Uh oh!

Copilot AI left a comment

Uh oh!

AliSoftware Nov 10, 2026

Uh oh!

AliSoftware Nov 10, 2026

Uh oh!

AliSoftware Nov 10, 2026

Uh oh!

AliSoftware Nov 10, 2026

Uh oh!

AliSoftware Nov 10, 2026

Uh oh!

AliSoftware Nov 10, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		when ''
		verify_binary(path: path, expected_authority: params[:expected_authority], verify_notarization: params[:verify_notarization])

Conversation

mokagio commented Nov 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does it do?

Checklist before requesting a review

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

This comment was marked as outdated.

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

mokagio commented Nov 4, 2026 •

edited

Loading