macOS Catalina error: “helm” cannot be opened because the developer cannot be verified.

[guitmz]

Output of helm version: v2.14.3

Information from hashicorp/terraform#23033 suggests that Apple is requiring applications to be signed with an Apple developer key from now on.

A workaround is also mentioned in the above issue and works but it is not ideal.

[marckhouzam]

I can confirm this. A colleague just upgraded to Catalina and helm won't start anymore.
kubectl does not seem to have this problem though...

[rimusz]

I'm using macOS Catalina and helm v2 and v3 CLI work for me there.
Under System Preferences/Security & Privacy/General in Allow apps downloaded from: I have set to Anywhere

[tdensmore]

@rimusz I do not have that option. My only options are: App Store and App Store and identified developers

[rimusz]

@tdensmore just run sudo spctl --master-disable
ref: http://osxdaily.com/2016/09/27/allow-apps-from-anywhere-macos-gatekeeper/

[tdensmore]

Thanks @rimus . sudo spctl --master-disable works for me.

[myersg86]

Allow apps from anywhere and sudo spctl --master-disable disable protections that can potentially leave a Mac vulnerable to malware, and should be avoided if at all possible. This is not an ideal solution.

After taking the following steps, I now seem to have an "Open anyways" option now, allowing running individual applications without disabling secure defaults.

Here's what I did, not sure if all steps are relevant:

• Switch spctl off and on:

sudo spctl --master-disable
sudo spctl --master-enable

• Set "Allow apps downloaded from: App Store" in Security and Privacy
• Reboot

[bacongobbler]

So from a comment in the terraform issue, it looks like we need a key signed from Apple themselves to have Helm binaries verified.

Indeed the new version of MacOS is stricter about running software you've downloaded that isn't signed with an Apple developer key. Terraform distributions are signed with a HashiCorp key with signatures distributed out of band on releases.hashicorp.com, but MacOS Catalina is requiring participation in Apple's developer program specifically, and Terraform is currently not built to support that.

Will be keeping an eye on that upstream issue for recommended next steps. What an interesting turn of events.

[scotthew1]

as a less dramatic workaround to disabling all protections, you should be able to grant an exception to helm specifically. after you try to open helm and get the error prompt, you can go to System Preferences -> Security & Privacy -> General and it will give you the option to set a special exception for helm:

the next time you try to run helm, you'll get one last warning prompt that now gives you the option to open helm.

[marckhouzam]

I haven't upgraded to Catalina yet but I was told kubectl doesn't have this problem. If that is indeed the case, could someone check if kubectl is signed in any particular way?
On my Mac OS Mojave kubectl 1.15 is not signed according to
codesign -d --verbose=4 $(which kubectl)

[guitmz]

@marckhouzam macOS Catalina, the latest kubectl downloaded from the kubernetes official install guide (or homebrew) is not signed but surprisingly I have a kubectl version that is from Docker (I do not recall installing it like this but well, it is what it is - I think it came with the Docker Mac app):

From Docker app:

$ codesign -dv --verbose=4 $(which kubectl)
Executable=/Applications/Docker.app/Contents/Resources/bin/kubectl
Identifier=kubectl
Format=Mach-O thin (x86_64)
CodeDirectory v=20200 size=380647 flags=0x0(none) hashes=11891+2 location=embedded
VersionPlatform=1
VersionMin=657664
VersionSDK=657664
Hash type=sha256 size=32
CandidateCDHash sha1=b18e260e3ebeee0a2ec7ae68edfba3ccfbb190e8
CandidateCDHashFull sha1=b18e260e3ebeee0a2ec7ae68edfba3ccfbb190e8
CandidateCDHash sha256=499ddda92336379963951a09c9ab78e21bd80968
CandidateCDHashFull sha256=499ddda92336379963951a09c9ab78e21bd8096809b626c8840d9c9406ea30c2
Hash choices=sha1,sha256
CMSDigest=e4b7eba0ece54ff12ee0e45f1aa45443a01a00d147d54bde3b479087211901dc
CMSDigestType=2
Page size=4096
CDHash=499ddda92336379963951a09c9ab78e21bd80968
Signature size=4693
Authority=Developer ID Application: Docker Inc (9BNSXJN65R)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=13. Sep 2019 at 10:28:10
Info.plist=not bound
TeamIdentifier=9BNSXJN65R
Sealed Resources=none
Internal requirements count=1 size=200

Downloading via official link (same binary as homebrew):

$ curl -sLO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
$ codesign -dv --verbose=4 kubectl
kubectl: code object is not signed at all

[marckhouzam]

@marckhouzam macOS Catalina, the latest kubectl downloaded from the kubernetes official install guide (or homebrew) is not signed [...]

Thanks @guitmz. Is Catalina blocking you when you try to use the unsigned kubectl like it does for helm?

[guitmz]

For some reason it is not. But perhaps it's because first time I used it, it was the signed binary (from Docker), maybe macOS added it to some sort of whitelist (just a wild guess, not sure how Catalina security works). Anyway as of now both the official binary and the one from Docker are working fine.

[marckhouzam]

My colleague was also was blocked for helm but not kubectl, although kubectl seems unsigned. Maybe a trail to follow...

[micheas]

I worked around this by deleting helm and then downloading it with wget.

It seems that it is because the file was downloaded via chrome. I'm guessing you also have this problem if helm has been downloaded via safari or firefox.

[marckhouzam]

Wow, @micheas is right! If I download RC3 with wget it works but with chrome it triggers MacOS's security (Gatekeeper).

Googling a bit led me to this info:
"Additionally, Gatekeeper only monitors files downloaded from the Internet through an Internet browser..."

This is good news as it means installing helm using brew will not trigger the security prompt. I have confirmed this.

This explains why it worked for my installation of kubectl.

[sozercan]

You can run xattr -d com.apple.quarantine /path/to/file to whitelist the binary from CLI. As others have noted, disabling gatekeeper using spctl should be avoided.

[skrhlm]

If you try running helm once, then go to settings > security & privacy, click the "click the lock to make changes", authorize, then you will see the text and button where you can click to allow Helm to be run.

[MinghongGao]

Enable install from "anywhere" not work for me. But @sozercan 's method did if you want to remotely run some binary via ssh. You save my night.!!

[vhosakot]

@scotthew1's reply in #6615 (comment) worked for me with macOS Catalina and helm v3.2.4.

[github-actions]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

[aturetta]

Found the solution

Do not download the archive with a GUI browser, it will get tainted by macos that will pretend downloaded binaries to be signed.

Just download with wget or curl, and live happy!

Downloaded archives/binaries get some additional attributes on the file system, look at a ls -l of your Downloads folder

-rw-r--r--@  1 angelo  staff     4089627 26 Aug 12:00 PSTools.zip

You see the @ sign right after the permissions?
that is the extended attribute, and files downloaded by curl will not have it