macOS Binary Signing (Developer ID) and .pkg Installer support

[uurazzle]

Hi:

Currently, sops for macOS is distributed as a standalone binary. While functional, it poses challenges for enterprise deployment because it lacks a verifiable Apple Developer Team ID embedded in the code signature.

The Request

We propose two enhancements to your macOS release workflow:

Sign the standalone binary with a Developer ID: Ensure the binary is signed and notarized by Apple so that the command spctl -a -vv /usr/local/bin/sops returns a valid "TeamID" (e.g., TeamID=XXXXXXXXXX).

Provide a standard Apple Installer Package (.pkg): Along with the binary, provide a notarized .pkg. This allows for "Zero-Touch" deployments where MDMs can install the tool without user intervention or "unidentified developer" Gatekeeper warnings.

Why this matters for the Mac Admin community:

Verification (Installomator/AutoPkg): These tools use the Team ID to verify that a download is authentic. Without it, admins must rely on less secure methods (like SHA checksums alone), which do not guarantee the vendor's identity.

Gatekeeper Compatibility: Notarized binaries bypass the "app is from an unidentified developer" prompt, which is critical for developers and automated CI/CD runners on macOS.

Enterprise Deployment: MDMs natively support .pkg files. A signed installer can be deployed to thousands of machines instantly, whereas a raw binary requires custom scripting to move the file and set permissions.

Implementation Overview:

If your team has an Apple Developer Program account, these steps can be integrated into your CI/CD (e.g., GitHub Actions):

For the Binary:

# Sign the binary
codesign --timestamp --options runtime --sign "Developer ID Application: [Your Team Name]" sops
# Notarize (via notarytool)
xcrun notarytool submit sops.zip --team-id [TeamID] --apple-id [AppleID] --password [AppSpecificPassword] --wait

For the Package (.pkg):

# Build and sign the package
pkgbuild --identifier "com.getsops.sops" --version [version] --install-location /usr/local/bin --root ./root sops.pkg
productsign --sign "Developer ID Installer: [Your Team Name]" sops.pkg sops-signed.pkg
# Notarize the .pkg
xcrun notarytool submit sops-signed.pkg ...

Supporting these standards would significantly lower the barrier for security-conscious organizations to adopt and maintain sops across their macOS fleets.

We would be happy to assist with testing or providing more detailed documentation for your CI pipeline if needed.

Thank you for your incredible work on this project.

[felixfontein]

@getsops/maintainers is it possible to get this done through CNCF? (On macOS I so far installed sops with Homebrew, that didn't require anything special...)

[uurazzle]

Hi @felixfontein :

"That’s a fair point! Homebrew is excellent for individual developers and local setups. However, the reason for this request centers on Enterprise Fleet Management and Security Verifiability at scale.

In a high-security or enterprise environment, those are two very different things. Here is why relying on Homebrew is often not enough for security teams:

Integrity vs. Identity

Homebrew (Integrity): When you run brew install, Homebrew checks a SHA256 checksum. This proves the file you downloaded is the same file the Homebrew contributor saw.

Apple Signing (Identity): A Team ID proves the binary was compiled and issued by the actual SOPS developers.

The Security Gap: If a malicious actor gains access to the Homebrew "Formula" repository, they could update the checksum to match a malicious version of SOPS. Homebrew would install it without complaint because the checksum matches. However, the Team ID would be missing or wrong, and macOS would block it.

Here is why a signed binary/PKG is needed beyond what Homebrew provides:

MDM & Zero-Touch Deployment: In managed environments (using Jamf, Kandji, or Munki), admins need to push software to thousands of Macs silently. MDMs natively support .pkg installers. Installing Homebrew on every end-user Mac just to install sops is considered a security risk in many regulated environments.

The 'Team ID' for Security: Tools like Installomator and AutoPkg (the industry standards for Mac patch management) use the Apple Team ID to verify that the binary hasn't been tampered with. Currently, since the binary isn't signed with a Developer ID, there is no 'Source of Truth' that macOS security tools can programmatically verify.

Gatekeeper & macOS Tahoe: As macOS security (Gatekeeper) becomes stricter, unsigned binaries often require users to manually go into 'System Settings' to allow them. A signed/notarized binary works out of the box without user intervention.

Regarding the CNCF: That is an excellent suggestion. Since SOPS is a CNCF project, the CNCF Service Desk often provides assistance with infrastructure costs, including Apple Developer Program memberships for signing/notarization. Other CNCF projects (like kubectl or helm) have navigated this to ensure their binaries are trusted by the OS.

[brandonkal]

Note that homebrew now no longer disables the quarantine flag, so all binaries need to be signed. Homebrew/brew#20755

[felixfontein]

@brandonkal Homebrew seems to build SOPS and other tools like Helm themselves (I also checked Helm since it was mentioned here as an example of having signed releases), so I don't think this makes a difference for installing SOPS through Homebrew.