macOS Droid CLI binaries have invalid code signatures and are blocked by Gatekeeper

[shelltea]

Summary

The official macOS arm64 Droid CLI binaries for versions 0.142.0 and 0.143.0 contain invalid code signatures.

Because of this, macOS Gatekeeper blocks the binary with the following warning:

Apple could not verify “droid” is free of malware that may harm your Mac or compromise your privacy.

Removing the com.apple.quarantine attribute allows the CLI to run, but bypassing Gatekeeper should not be necessary for an official executable with access to source code, credentials, and shell commands.

Environment

• macOS: 15.7.7
• Architecture: Apple Silicon (arm64)
• Droid versions tested:
  • 0.142.0
  • 0.143.0
• Installation method: Homebrew Cask
• Homebrew: 5.1.15

Steps to reproduce

Install Droid through Homebrew:

brew install --cask droid

Verify the signature:

codesign --verify --deep --strict --verbose=4 "$(command -v droid)"

Result:

invalid signature (code or signature have been modified)
In architecture: arm64

Gatekeeper assessment also fails:

spctl --assess --type execute --verbose=4 "$(command -v droid)"

Result:

internal error in Code Signing subsystem

Signature metadata is present:

codesign -dv --verbose=4 "$(command -v droid)"

Relevant output:

Identifier=droid
Format=Mach-O thin (arm64)
TeamIdentifier=SW6TL4V6Q5
Authority=(unavailable)
Runtime Version=15.2.0

Verification against official downloads

I downloaded both versions directly from Factory's official distribution endpoint:

https://downloads.factory.ai/factory-cli/releases/0.142.0/darwin/arm64/droid
https://downloads.factory.ai/factory-cli/releases/0.143.0/darwin/arm64/droid

The SHA-256 hashes match the corresponding Homebrew Cask definitions.

Version 0.142.0

244d1a2ef075993fad8454bba10caf5fc7e777f563f21c8844c46bbf02370124

Version 0.143.0

20b8441bf2b9686b979035698cedb72a6acb6c0be523789f218d7120de45c856

The independently downloaded official binaries fail codesign --verify in exactly the same way. This indicates that the issue exists in the published artifacts rather than being caused by local modification or a corrupted Homebrew download.

Additional observations

The executable contains a __BUN Mach-O segment and appears to be a Bun standalone executable.

Bun's macOS documentation states that compiled executables should be signed after compilation:

https://bun.sh/docs/guides/runtime/codesign-macos-executable

This may indicate that the binary is being modified or compiled after signing, or that the final signing step is incomplete. This is only a hypothesis based on the published binary structure.

Security impact

There is no evidence that the binaries are malicious. However, the invalid signature prevents macOS from verifying:

• That the executable was authentically published by Factory
• That it has not been modified after signing
• That the Developer ID certificate is valid and trusted
• That the executable passes Gatekeeper validation

The current workaround is:

xattr -d com.apple.quarantine "$(command -v droid)"

This bypasses Gatekeeper and weakens an important security control. It is especially concerning for an agent that can read repositories, access credentials, make network requests, and execute shell commands.

Expected behavior

Official macOS binaries should:

1. Pass strict code-signature verification:

   codesign --verify --deep --strict --verbose=4 droid

2. Pass Gatekeeper assessment:

   spctl --assess --type execute --verbose=4 droid

3. Be signed with a valid Factory Developer ID Application certificate.

4. Ideally be notarized by Apple.

5. Launch without requiring users to remove quarantine attributes or bypass Gatekeeper.

Could the Factory team confirm whether this is a known packaging/signing issue and whether the currently published binaries are considered safe to run?