Homebrew install: "Kui.app" cannot be opened because the developer cannot be verified.

[jsolbrig]

Describe the topic
I installed Kui using brew install kui, but when I try to run the executable I get "Kui.app" cannot be opened because the developer cannot be verified. While I know how to get around this, I think this will be a deterrent to people (including me) using Kui. Are there plans to get Kui verified with Apple?

[starpit]

Howdy, yes! We are already set up to allow for signed+notarized builds. Unfortunately, due to Apple's recent switch to enforcement of its "hardened runtime" (in macOS 11), combined with a bug in libuv [1]... the result is that signed+notarized builds are excessively slow -- adding about 300ms to every subprocess execution.

The libuv people have been trying to fix this for quite a while. In their latest attempt, they have run into macOS kernel bugs (sigh)... But I think they are close.

So... on the Kui side, we could decide to use signed+notarized builds, with a slowness/lag warning... It depends which is prioritized, UX latency/responsiveness versus unsigned builds. Thoughts?

[1] electron/electron#26143

[starpit]

For a bit more detail: when using the hardened runtime, the POSIX fork call is very slow, because it has to copy lots of state. The solution is to use the newer posix_spawn API. But this is apparently new enough to be still buggy. Why Apple thought they could mandate the use of a buggy API is beyond me.

This also affects the node-pty library, which similarly uses fork rather than posix_spawn. I opened an issue there [2]

[2] microsoft/node-pty#476

[jsolbrig]

I think that to give a good answer to your question I'd need to be able to test how intrusive the UX latency/responsiveness issues are. I'd be happy to test things and give you my opinion if that's possible.

I'm personally giving Kui a test drive right now, but I don't think I'm going to recommend it to coworkers until it's signed.

That's really frustrating that Apple made changes without a viable solution in place.

[starpit]

Agreed. We can make a build for the next patch release and upload it to the releases page. I'll ping this thread when that happens. We could probably release something by EOD, or some time tomorrow.

[jsolbrig]

Sounds great! I'll keep an eye out for it and will give it a try tomorrow. I don't think I'll have time to test by EOD today.

[starpit]

The 10.5.5 release has signed builds for darwin x86 and arm64. I just tried it on x86. It is definitely laggy, though still usable.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[starpit]

At long last, Kui 11.0.0 (just released to homebrew: brew upgrade kui) now ships with signed+notarized builds for macOS.