Unsigned apps on M1 Macs

[alexreg]

There's a problem with unsigned apps on the new M1 Macs (at least, I believe it's an M1 thing rather than a new version of macOS) — namely, it's impossible to run unsigned apps without self-signing them first. Whereas before, unsigned apps seem to have been treated the same as apps signed by unknown developers, now you won't even get a prompt in the Security pane of System Preferences to "Allow" (add an exception). Consequently, after installing a cask with an unsigned app, it will refuse to open. e.g., from Finder, you get a message like, The application “Foo.app” can’t be opened. with an error message about security in the Console.

The obvious solution seems to be to self-sign all apps that Homebrew Cask installs (at least on M1 Macs). This is typically done via the command line with

sudo codesign --force --deep -s - Foo.app

Unsurprisingly, it requires admin privileges. Alternatively, a post-install not could just be displayed to the user to tell them to do this, but this is obviously less than ideal in light of automatically updated casks and their apps.

Any thoughts about how Homebrew should deal with this situation?

[SMillerDev]

Does this solution https://docs.brew.sh/FAQ#why-cant-i-open-a-mac-app-from-an-unidentified-developer no longer work?

[alexreg]

@badonyx Okay, so that still incurs the same problem: macOS won't let them run on ARM chips?

[badonyx]

It can run (unquarantined) if they rework their build pipeline to incorporate the ad-hoc signature from the apple toolchain.

[alexreg]

Ah okay, that's what I thought. Looks like they have no desire to do so, judging by the responses I've got from the maintainers.

[badonyx]

The unsigned intel apps should still work (with rosetta) so until they decide to really support Apple Silicon you can simply remove the arm builds from the casks (and add the rosetta caveat).

[badonyx]

Submitted PRs for this.

• Caveats for unsigned casks brew#16243
• Remove unsigned apple silicon builds homebrew-cask#160619

[lougreenwood]

I also have a similar issue. It seems that self-signed apps won't auto-launch.

Or possibly more specifically - self-signed apps which are installed by another user who is admin and the current user is not admin.

I need to investigate this some more, but it's super annoying!

[shemeshg]

is it still ok?

Supposed the app is failed with

  * line 5, col 2: Signature verification failed:
    /private/tmp/d20231117-26929-727bs7/pass-simple.app: rejected

    macOS on ARM requires software to be signed.
    Please contact the upstream developer to let them know they should sign and notarize their software.
Error: 3 problems in 1 cask detected.

Maybe the request to notarize for open source developer is too much (They will not pay the fee)?

asking to sign and not notarize actually increase homebrew security

asking developers to

codesign --deep --timestamp --options runtime -s "Apple Development" application-name.app

might help auto approve upgraded versions from the same developer.

• Maybe homebrew can use codesign -dv --verbose=4 app-name.app for verification instead ?

however mandatory notarize might be too much...

According to ChatGpt

If your app is signed but not notarized, it will still open on another Mac. However, users might encounter a security warning.
The error message you received indicates that the app failed signature verification. While it will run, macOS on ARM requires signed software. Notarization is recommended for enhanced security.

complete log:

macos@macoss-Mac-mini Casks % brew audit --new-cask quicktest
==> Downloading and extracting artifacts
==> Downloading https://downloads.sourceforge.net/pass-simple/quicktest.dmg
==> Downloading from https://master.dl.sourceforge.net/project/pass-simple/quick
######################################################################### 100.0%
==> Downloading https://downloads.sourceforge.net/pass-simple/quicktest.dmg
Already downloaded: /Users/macos/Library/Caches/Homebrew/downloads/404a43a9727e0b574c9b52bdb3e9b58aac8f41f3447cea2107bd2b031336a2c5--quicktest.dmg
audit for quicktest: failed
 - Use `sha256 :no_check` when URL is unversioned.
 - Download is hosted on SourceForge, please add a livecheck. See https://docs.brew.sh/Cask-Cookbook#stanza-livecheck
 - Signature verification failed:
/private/tmp/d20231117-26929-727bs7/pass-simple.app: rejected

macOS on ARM requires software to be signed.
Please contact the upstream developer to let them know they should sign and notarize their software.
shemeshg/tap/quicktest
  * Use `sha256 :no_check` when URL is unversioned.
  * line 5, col 2: Download is hosted on SourceForge, please add a livecheck. See https://docs.brew.sh/Cask-Cookbook#stanza-livecheck
  * line 5, col 2: Signature verification failed:
    /private/tmp/d20231117-26929-727bs7/pass-simple.app: rejected

    macOS on ARM requires software to be signed.
    Please contact the upstream developer to let them know they should sign and notarize their software.
Error: 3 problems in 1 cask detected.

[SMillerDev]

Ah I see. Is there any possibility of generic post-install hooks for formulas/casks though? So maybe users could automate this ourselves if needed? I have something already in place, but it's a little hacky.

Formulae are automatically ad-hoc signed already, since there Homebrew builds it so we can't ask upstream to sign it.

As for a general solution, you can always make a pull request.

Is there a scheduled due date or a cutoff point when non-notarized software on Homebrew Casks will be removed?

I don't have any plans to remove existing software, but new software without signing is not allowed because the user experience is so bad.

Additionally,
until which date will updates for non-notarized software continue to be supported for existing Homebrew Casks?

In the main tap, I have no plans to extend the signing check to existing casks

[alexreg]

@SMillerDev Thanks for the clarification. How would you like to see a general solution designed, if I do take that root? Is a generic post-install hook (for casks only or formulas & casks) a fair approach to you?

[shemeshg]

@SMillerDev

If I understand you correctly, the recommended way to distribute non-notarized executables is to use formula instead of cask. However, I could not find any clear guidance or examples on how to formula gui applications for Homebrew. This applies to most used frameworks

1. electron+javascript
   Consider for example, Electron deployment tool, that today used for automatically produce DMG, snap, deb, NSIS will need to know how to produce homrbew formula also
2. cmake + qt6 + qml + c++ frameworks.
3. xcode swiftUi gui native applications

that to say this issue is specific to gui applications, as there are plenty of resources and documentation for libraries and non-gui.

• is it planned to publish best practices for that?
• for this is a huge change, is it gone be communicated in your blog, including list to example formulas best practices?
• How about soft due dates (with no cutoff), for helping developers to make the transition, and dedicated pinned discussion thread.
• Adjusting formula to handle desktop shortcut, and linking etc... (integrating functionality and tags exists in cask, so it will be available in formulas)

[SMillerDev]

Thanks for the clarification. How would you like to see a general solution designed, if I do take that root? Is a generic post-install hook (for casks only or formulas & casks) a fair approach to you?

I'm not sure, but that's probably something that can be worked out in a review

If I understand you correctly, the recommended way to distribute non-notarized executables is to use formula instead of cask. However, I could not find any clear guidance or examples on how to formula gui applications for Homebrew.

It is not, the recommended way to distribute GUI applications is as signed casks.

[alexreg]

@SMillerDev Okay, sure. I was thinking of generic pre-post install scripts for all formulas/casks, to be searched for at a fixed set of paths. Could you kindly point me to the right place in the codebase I could look at, when it comes to running these scripts pre/post-installation of a formula/cask?

[SMillerDev]

No such place currently exists, so it's totally up to you

[alexreg]

No such place currently exists, so it's totally up to you

Surely there's an install function/method that I should look at at least...

[shemeshg]

It could be that initiating work without a detailed technical description of the proposed solution would be premature.
Additionally, the term ‘hooks’ seems to have caused confusion, as it could refer to

• GitHub server hooks,
• • Ruby-level callbacks, or
• • new tags within the Cask implementation.

Maybe @SMillerDev can briefly describe expected solution?

Also now that we know( @badonyx) Apple original intensions we just and only just binary completeness,
Maybe the solution is replacing one line of code from current new cask validation, to validating existence of app bundle signature
(notarise by apple or not)