Signal 1.31.0 for Mac has no ticket stapled to it

[ghost]

• [X] I have searched open and closed issues for duplicates

---

Bug Description

After installing Signal 1.31.0 in macOS 10.15.3, attempting to execute it results in a dialog indicating that it cannot be opened because "Apple cannot check it for malicious software". It goes on to say that "This software needs to be updated. Contact the developer for more information."

According to xcrun, the application has not had a ticket stapled to it:

$ xcrun stapler validate /Applications/Signal.app
Processing: /Applications/Signal.app
Signal.app does not have a ticket stapled to it

The signal-desktop-mac-1.31.0.dmg file was downloaded by brew. I have confirmed that it matches the file that can be obtained by manually downloading from https://signal.org/download.

On a somewhat related note, I am surprised that the download page provides no guidance as to how to verify the authenticity of the files that are offered.

Steps to Reproduce

1. Install Signal 1.31.0 to /Applications
2. Attempt to run it

Actual Result:

Observe that the aforementioned dialog appears (see also the screenshot below).

Expected Result:

That a dialog associated with notarized software appears instead. That's the one that asks "Are you sure you want to open it?" and which goes on to say that "Apple checked it for malicious software and none was detected."

Screenshots

Platform Info

Signal Version:

Signal Desktop 1.31.0

Operating System:

macOS Catalina 10.15.3

[scottnonnenberg-signal]

We haven't tested that brew workflow. What happens when you download the .dmg file directly from https://signal.org/download, then copy the Signal.app file into applications with Finder?

[ghost]

As concerns the dialogs, I am now getting inconsistent results. I believe that macOS has a system of stashing user 'intents' (due to forcibly opening an application or through the use of drag and drop) in extended attributes somewhere, which is making it difficult for me to perform further testing from the point of view of the initial experience. Somehow, the OS remembers that the application was previously downloaded and now acts differently upon opening. I'm trying to figure out how to clean the slate, as it were.

One thing I can confirm, though, is that the dmg that brew obtained is the same as the copy that I have manually downloaded.

$ find . -name '*signal-desktop-mac-1.31.0.dmg' -exec shasum -a 256 {} +
dce5202a6883e0858577cb8813d445903b05fbfb33f2e694acc58af23d893520  ./Downloads/signal-desktop-mac-1.31.0.dmg
dce5202a6883e0858577cb8813d445903b05fbfb33f2e694acc58af23d893520  ./Library/Caches/Homebrew/downloads/fd7053e48441493a1317b144a3c2c42d71420f26ae4c12fd1d65f2e0734a7478--signal-desktop-mac-1.31.0.dmg

Upon manually extracting Signal.app from this dmg, xcrun continues to indicate that it has no ticket, which is in contrast to other applications I have on my system that I know to be fully notarized. To pick a random example:

$ xcrun stapler validate /Applications/Sublime\ Text.app
Processing: /Applications/Sublime Text.app
The validate action worked!

But for Signal:

$ xcrun stapler validate /Applications/Signal.app
Processing: /Applications/Signal.app
Signal.app does not have a ticket stapled to it.

Anyway, I'll do some more digging and try to establish a clean slate so that I can answer the question accurately.

[ideologysec]

A notarization ticket is stapled into the app package anyway; whether it came from brew or not shouldn't matter. It's not an extended attribute, it's a function of the build pipeline, wherein Xcode submits the binary to Apple for notarization.

https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution

Downloading a fresh binary from the signal.org website does not have the notarization ticket stapled in; moving an app via Finder or not is completely irrelevant to this.

❯ xcrun stapler validate /Volumes/Signal\ 1.31.0/Signal.app
Processing: /Volumes/Signal 1.31.0/Signal.app
Signal.app does not have a ticket stapled to it.

EDIT: per the link above, opting into the hardened runtime is a requirement for notarization. Signal already appears to implement this, so notarization should be just an extra step in the release process. (though, it opts out of a great many of them via exceptions, presumably due to it being an Electron app and requiring JIT + many other things).

❯ codesign -vvvv --display --entitlements - /Volumes/Signal\ 1.31.0/Signal.app
Executable=/Applications/Signal.app/Contents/MacOS/Signal
Identifier=org.whispersystems.signal-desktop
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=1805 flags=0x10000(runtime) hashes=47+5 location=embedded
VersionPlatform=1
VersionMin=657920
VersionSDK=658688
Hash type=sha256 size=32
CandidateCDHash sha1=b754c213fff5e60c2ef268f93ba01b2ddab2d3ac
CandidateCDHashFull sha1=b754c213fff5e60c2ef268f93ba01b2ddab2d3ac
CandidateCDHash sha256=f7a01be84a31432ca2872d2df8f3cfbec0d36568
CandidateCDHashFull sha256=f7a01be84a31432ca2872d2df8f3cfbec0d36568205f018ca04ddbbd480d1bdb
Hash choices=sha1,sha256
CMSDigest=3ff605e03ba2d7f6643e5cb53ace1037b0b533665946045f73753ed18fedd9b3
CMSDigestType=2
Page size=4096
CDHash=f7a01be84a31432ca2872d2df8f3cfbec0d36568
Signature size=9081
Authority=Developer ID Application: Quiet Riddle Ventures LLC (U68MSDN6DR)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Feb 10, 2020 at 14:05:17
Info.plist entries=28
TeamIdentifier=U68MSDN6DR
Runtime Version=10.13.0
Sealed Resources version=2 rules=13 files=1040
Internal requirements count=1 size=196
��qqH<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.security.cs.allow-dyld-environment-variables</key>
    <true/>
    <key>com.apple.security.cs.allow-jit</key>
    <true/>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
    <key>com.apple.security.device.audio-input</key>
    <true/>
    <key>com.apple.security.device.microphone</key>
    <true/>
    <key>com.apple.security.files.downloads.read-write</key>
    <true/>
    <key>com.apple.security.files.user-selected.read-write</key>
    <true/>
    <key>com.apple.security.network.client</key>
    <true/>
  </dict>
</plist>

[ghost]

A notarization ticket is stapled into the app package anyway; whether it came from brew or not shouldn't matter. It's not an extended attribute, it's a function of the build pipeline, wherein Xcode submits the binary to Apple for notarization.

I didn't say that a ticket was an extended attribute.

https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution

Downloading a fresh binary from the signal.org website does not have the notarization ticket stapled in; moving an app via Finder or not is completely irrelevant to this.

That is why the title of the issue incorporates the words "has no ticket stapled to it".

I didn't say that moving files in Finder was related to stapling. It is unclear as to how you concluded this from the first sentence of my second comment.

❯ xcrun stapler validate /Volumes/Signal\ 1.31.0/Signal.app
Processing: /Volumes/Signal 1.31.0/Signal.app
Signal.app does not have a ticket stapled to it.

As mentioned in the initial comment.

Where I was likely in error was the intial presumption that the absence of a stapled ticket was the cause of the unfortunate dialog shown in the original post - that which was bereft of an Open button. As alluded to in my second comment, after removing the copy of Signal that I had at the time, I have not since been able to reproduce the experience described. I can assure anyone reading that it occurred, though.

My intention now is to try to reproduce all of this in a clean install. If I cannot, then I will just have to accept it as unaccounted for and move on. For all I know, it could have been a UI bug in Catalina.

[ideologysec]

Most of the first half of your post is responding to me as though I were responding to you, when I was in fact mostly responding to Scott. Apologies for any confusion.

The popup about malicious software is occurring because Signal is not notarized. This can also appear if you are offline even with a notarized app, as an internet connection is required to verify the validity of the notary ticket. This warning can be bypassed by removing the com.apple.quarantine xattr from the app once it has been copied out of the disk image, or by opening it once by right-clicking and selecting "open" and then confirming.

This step (opening the app either forcefully or after decontamination) registers the bundle identifier in the Gatekeeper database, and software updates won't trigger this warning again unless the whole binary is replaced to my understanding.

The enforcement of notarization requirements for Catalina is new as of February 3rd, see here for more details.

For your testing purposes, resetting the System Policy database should trigger the warning again; sudo spctl --reset-default should do the trick (and if not, please report back!)

In general, the way to resolve this for users old and new is for Signal to be notarized by Apple as part of the build release process; @scottnonnenberg-signal are there any plans for this?

[scottnonnenberg-signal]

Thanks for your deep investigation into this.

It turns out that we are notarizing. Try this:

$ xcrun stapler validate signal-desktop-mac-1.31.0.dmg 
Processing: signal-desktop-mac-1.31.0.dmg
The validate action worked!

When this was implemented, the Apple documentation claimed that it would reach into the .dmg and notarize the .app file inside. Seems that isn't exactly happening, but some benefit from the action of copying from a notarized .dmg into /Applications is preventing every one of our macOS users from popping the error you originally saw.

We can change our build process to be sure to staple the notarization into the .app before we build our final release artifact. That should cover us in more scenarios.

[ideologysec]

Awesome! That would be very helpful for those of us who try to manage software via homebrew/cask (and hate using the mouse in general). :)

[ideologysec]

An update, more than a year later (tested on v 5.6.2) - there is still no ticket stapled to the binary. Has this been worked on?

$ xcrun stapler validate /Applications/Signal.app                                                                                                                                                         
Processing: /Applications/Signal.app
Signal.app does not have a ticket stapled to it.

[ideologysec]

Following up again, new computer, new Signal install -

M1 MacBook Air, Big Sur 11.4 $ brew install --cask signal

-> attempt to open Signal:

Now - there's no reason the lack of a stapled ticket should prevent this from opening (or at least offering the option of essentially "Open Anyway") - especially since I had an internet connection at the time. Is there some other bug in the signing process that is preventing this?

of course after the usual $ xattr -cr /Applications/Signal.app it opens just fine.