can't run rakubrew on OS X

[coke]

After downloading a copy of rakubrew for mac and putting it in my bin (and making it executable), attempting to invoke it generates a popup:

"rakubrew" cannot be opened because the developer cannot be verified.

macOS cannot verify that this app is free from malware.

Chrome download this file today at 3:02 PM from rakubrew.org

[coke]

Blocking some diagnostics on https://github.com/MoarVM/MoarVM/pull/1417

[coke]

Something like

spctl --add bin/rakubrew

Would theoretically allow a user to override the security requirements for the binary.

This should be noted on the mac download instructions) - Ideally the binary would be signed.

I was unable to find an invocation of spctl that allowed me to run the program, it keeps complaining. (tried rakubrew, relative path, absolute path...)

[patrickbkr]

Thanks for the report!

Just for info: It's still possible to install rakubrew from source via CPAN. cpanm App::Rakubrew That shouldn't suffer from this.

[patrickbkr]

Do you have Big Sur on ARM running? Asking because of this: https://eclecticlight.co/2020/08/22/apple-silicon-macs-will-require-signed-code/

If yes, it's interesting that it complained about the missing signature and not about the wrong architecture.

[patrickbkr]

Ping @coke

[coke]

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.15.7
BuildVersion:   19H114

[coke]

Note: the curl|sh instructions DID work. I had tried the direct download which complained about security, but even though the sh instructions end up with the same executable, that didn't trigger the security issue.

[raydiak]

I haven't used a mac in a long time and can't test this, but I ended up reading about it for a few hours out of curiosity, and thought I'd share what I learned. Running xattr -d com.apple.quarantine or xattr -c on the downloaded file should fix this specific issue. Piping the output of curl to sh means there's isn't a directly downloaded file to attach the extended attributes to, which is one of the reasons it works. I suspect that files downloaded with curl don't get the extended attributes set anyway, even if you did write the file directly to disk with e.g. curl -o/-O.

A number of possible user-end solutions for related problems are mentioned in the discussion at https://stackoverflow.com/questions/64842819/cant-run-app-because-of-permission-in-big-sur, and even some of the failed attempts there would have been successful pre-Big Sur (since this particular issue was reported under Catalina). For future reference though, the situation with Big Sur may be more complicated, even on Intel: https://developer.apple.com/forums/thread/667231 https://developer.apple.com/forums/thread/666611. I don't know anything about it firsthand, but I suspect that the "codesign" solution in the above-linked SO question may work (perhaps with some tweaks to the command line parameters) both pre- and post-BS. But it still needs to be run by the end user after download.

WRT signing, here is way more than you ever wanted to know: https://developer.apple.com/library/archive/technotes/tn2206/_index.html. According to that, the only way to sign something that isn't a Mach-O binary is for the signature to be stored in, you guessed it, another extended attribute. Which, being filesystem-specific metadata, won't survive most forms of file transfer including download over a network. You'd have to package the script up somehow for it to be distributable with the signature intact. Here is a fairly thorough (though somewhat ad-laden) article on the hoops you have to jump through to distribute a usable, signed, notarized app outside of the Mac App Store: https://www.appcoda.com/distribute-macos-apps/.

The options for distributing a simple textual script on macOS without special hoops the user has to jump through are pretty limited. You can wander down the dark enclosed tunnel of Apple's intended tools, methods, and infrastructure (and pay them $99/yr to be able to sign as an "Identified Developer"), to build signed app bundles. Perhaps you could recommend installing rakubrew on macOS via macports with a provided portfile or something similar. Pretty sure I saw that done occasionally by other projects many years ago when I was using a mac. Another approach would be to preserve the extended attributes attached to the script inside of some carefully-crafted archive of one format or another with some "preserve xattrs" option passed to the archiving tool at creation, but that still doesn't guarantee that it'll be preserved by whatever tool the user uses to extract it without them also taking extra care in the options they use while extracting. Further investigation of that last method may or may not be fruitful, but that's as far as I'm willing to research this for the time being, as it's making my head and heart both hurt.

[patrickbkr]

@raydiak So adding the following note to the website would be a good start, right?

Should you observe the following error when trying to run the rakubrew executable, then you need to run xattr -d com.apple.quarantine /path/to/rakubrew first to debrand the executable.

"rakubrew" cannot be opened because the developer cannot be verified.
macOS cannot verify that this app is free from malware.
Chrome downloaded this file today at 10:08 AM from rakubrew.org

[raydiak]

@patrickbkr As long as they aren't running Big Sur, then yes I believe that should work. The error under Big Sur probably says something different anyway. I'm not sure if "debrand" is precisely the right word, I haven't seen it called "branding" in anything I've read. "Unquarantine" or possibly "unsandbox" may be closer to the native dialect.

Given that it shouldn't need any xattrs at all, it may be cleaner to use xattr -c to wipe out all of them. I don't know if that information is stored in just com.apple.quarantine, or if it's spread across multiple xattrs for e.g. quarantine flag, source app, url, etc, and what functional difference (if any) there is between these two variations, both now or in the future. It'd be best if somebody could test them first. You could also just suggest that they use the curl | sh method instead of downloading the file to disk and running it by hand, as at least we have confirmation that it worked in one real-life case.

If they are running Big Sur, some things I read indicated that xattr may not work at all there. Suggesting codesign --sign - /path/to/rakubrew may solve this problem and additionally other related problems on any macOS version including Big Sur, making xattr unnecessary. Again, we need to test, as I'm unclear whether the codesign tool specifically will work on non-binary scripts, or if signing a script in extended attributes requires something different. I believe codesign should work from clues in its man page, but it's not explicitly clear. I also don't know if codesign comes with macOS, or if it's part of something like Xcode which the user may or may not have installed. curl | sh may even work on Big Sur too; it'd be good to know either way.

Maybe @coke would be willing to test these other approaches? I also saw @lizmat and @tony-o discussing their macOS experiences in #raku-dev the other day; perhaps one of these 3 people has access to a mac with Big Sur on it somewhere? Ideally, what we need is to fill in a testing matrix like:

Command	masOS 10.*	macOS 11 BS
curl https://rakubrew.org/install-on-macos.sh | sh	Works	Works
xattr -d com.apple.quarantine /path/to/rakubrew	?	No
xattr -c /path/to/rakubrew	?	No
codesign --sign - /path/to/rakubrew	?	No

Any notes about observed differences (e.g. presence or absence of warning/confirmation dialogs) would help us pick the best approach, and document it as clearly as possible.

[raydiak]

It appears that making /path/to/rakubrew executable and then running it via the instructions at https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac (which does include a one-time warning dialog) is adequate to get a directly downloaded copy running. IDK if xattr or codesign methods work on pre-Big Sur, but they all threw errors on Big Sur. Big thanks to @ugexe for taking the time to help us map out the problem space! I've updated the matrix above with his results; see https://colabti.org/irclogger/irclogger_log/raku?date=2021-05-03#l290.

Based on what we know at this point, I recommend just documenting what works for all recent macOS versions including BS:

• Use the "curl | sh" method
• Or else set the directly downloaded rakubrew as executable and use the instructions at the link above to run it the first time. It adds a permanent exception, so it ought to work all normal ways and without warnings after that.

If they download the installer script instead of the rakubrew binary, I expect that the same instructions will work. But really, "curl | sh" seems like the easiest and most reliable method by far on any version of macOS. We may want to heavily emphasize that in the barebones instructions.

[patrickbkr]

The website is up with respective instructions. Thanks for all the support raydiak++ coke++