MacOS Catalina blocks execution of kubectl-cloudflow about cloudflow HOT 18 CLOSED

We will need to apply something like this: https://github.com/mitchellh/gon to code-sign our apps.

from cloudflow.

An even simpler workaround is the following:

xattr -d com.apple.quarantine [path to]/kubectl-cloudflow

That command removes the "downloaded from the internet" filesystem flag from the file so MacOS doesn't treat it as special anymore.

from cloudflow.

A verified workaround is to build the CLI locally. Catalina only seems to block unsigned executables that have been downloaded.

from cloudflow.

Another workaround, press cancel in the above dialog (do not move to Trash), go to Security & Privacy settings, select to Allow anyway:

Then, when you open it, select Open:

from cloudflow.

Thanks guys for a quick turn around. This works

from cloudflow.

Presumably if you ran cat kubectl-cloudflow > bin/kubectl-cloudflow, that would work around it.

from cloudflow.

Also, another workaround that would probably work would be to distribute an installer as a shell script. That shell script could have the binaries packaged as base64ed here documents, which it would base64 decode and write to files, and then set the executable bit on. You'd run the installer by running bash cloudflow-installer.sh in a terminal - I guess the quarantine checking is done by the OS, but when you pass the script as an argument to bash, it's not the OS that executes it, bash reads the file and then executes it, the file doesn't even have to be executable.

from cloudflow.

If you just curl the binary won't it work? I think the notarization bit is only set by web browsers. It seems like there are plenty of ways to handle this. I'm not sure the notarization is necessary for a CLI tool. Looking at Homebrew - they are not going to notarize everything. Simply downloading it outside of a browser seems sufficient to bypass gatekeeper.

from cloudflow.

@jsravn OK, good point but it feels a bit hard to translate that into a nice UX.

We currently have three binary builds of our CLI, Mac/Linux/Windows, distributed as tar.gz files. We would have to find another, Mac-specific distribution method (like a shell script or an explicit instruction to always use curl) that is easy for our users to apply without triggering the quarantine bit.

from cloudflow.

Yeah it's super clunky for sure. I suspect though that a developer using Catalina is going to run into this problem a lot - and will figure out the workaround quickly (right click, open in finder). It's something we need to figure out at some point but not sure it is particularly urgent.

from cloudflow.

curl makes total sense. And besides, most developers on OSX don't think twice before copy/pasting a command that curls then executes a shell script, it's the normal way of doing things. And since Catalina validates that all binaries are signed, they're now super safe. What could go wrong?

from cloudflow.

Are there plans on adding the CLI to Homebrew as a cask? As a fellow Mac user, that'd be my preferred way of installing instead of downloading tars or copy-pasting curl commands. I can submit a new cask to Homebrew if you agree that this is the way to go

from cloudflow.

@mrooding that is a good question. I would have to look into the publishing workflow and how we could automate that when we release a new version of the CLI. But if that is not too much trouble then I'm all for it.

from cloudflow.

We have documented a workaround in the docs. Currently we have higher priority items in our backlog, so won't be able to get to it anytime soon. @mrooding If you have time to work on submitting a new cask to Homebrew, that would be great.

from cloudflow.

It would certainly be good to kickstart this by creating the core Homebrew Cask definition.
The next step would be to automate the submission process and hook it into our release process so we publish a new version as part of every release.

@mrooding could you perhaps let us know whether you would be willing to pick up the initial Homebrew work? If not then I would probably closing this issue since we have a good enough workaround in place, e.g. the docs describe the command to execute in order to enable the downloaded binary.

from cloudflow.

@agemooij I'll try to get it done next week. It's a bit hectic at the moment juggling between children, work and free time to do these kinds of things. It'll definitely make installing and updating the CLI more effortless

from cloudflow.

(curl and xattr command both fix the issue)

from cloudflow.

We now have:

curl -sL http://cloudflow.io/docs/get.sh | sh

from cloudflow.