Gábor,
sorry for the late reply. The issue is that arm64 binaries get signed no matter what (requirement by the kernel), but our post-install process changes the path entries (moving dependent libraries to $R_HOME/lib etc.) which invalidates the (anonymous) signatures. For released pkg that's no problem, because the packaging process re-signs everything with proper developer account signature so it works, but the tar balls were packed up "raw" without signing. I have now added an extra step where the whole framework is re-signed before taring-up - but to address your concern it's just signed, no entitlements are added. Some additional background - there are following layers: 1) unsigned 2) signed anonymously 3) signed with identity 4) hardened run-time / entitlements 5) notarization On Intel 1) is all you need to run. On arm64 2) is required else you get the Trap: 9 error. Entitlements are additional key/values attached to a binary at signing which are used by the OS to determine what the binary is allowed to do. They essentially declare what security the user can expect. Technically, they are voluntary, i.e. a binary without entitlements is essentially free to do anything (almost, some some system services are only available to processes which have entitlements so it does cut both ways). Finally, notarization is a process by which Apple scans software for malicious code and other things they may not like. If a software passes their checks it is "notarized" which is essentially a stamp from Apple that is it ok. The way it works is that you send the full package (pkg) to Apple, they inspect it and record its hash in their database as "passed". Anyone can then check that package with Apple to see that it's ok. As a convenience they also provide a "stamp" that you can then attach to the package so it doesn't need online service to check with Apple - it's essentially an additional signature from Apple you tack on. Anyway, for us most relevant is that Apple requires notarization in order to be able to install package using Apple Installer (.pkg) without any warnings. Notarization in turn requires hardened run-time - Apple simply won't notarize anything that is not using hardened run-time. So that's why we use hardened run-time + notarization for releases, but that puts restrictions on what we're allowed to do. Homebrew is just wild-west - they are random binaries downloaded from the internet so they don't come with any guarantees whatsoever. They now must sign on arm64 simply because the kernel requires it, but ther eis no meaning to that. I hope it helps - please let me know if today's binaries work. I still have some permission issues with R.app, but the framework should be ok. Cheers, Simon PS: I am playing with the macOS virtualization https://github.com/s-u/macosvm and it seems to work perfectly - I was able to check the new build tar ball on a clean VM in less than a minute ;). > On Nov 17, 2021, at 11:28 AM, Gábor Csárdi <csardi.ga...@gmail.com> wrote: > > This is Monterey: > ❯ uname -a > Darwin Gabors-MacBook-Pro-3.local 21.1.0 Darwin Kernel Version 21.1.0: > Wed Oct 13 17:33:01 PDT 2021; root:xnu-8019.41.5~1/RELEASE_ARM64_T6000 > arm64 > > The R-devel build segfaults: > > ❯ curl -O https://mac.r-project.org/monterey/R-devel/arm64/R-devel.tar.gz > ❯ sudo tar xzf R-devel.tar.gz -C / > ❯ R -q --vanilla > zsh: killed R -q --vanilla > > So does the R-4.1 build: > > ❯ curl -O > https://mac.r-project.org/monterey/R-4.1-branch/arm64/R-4.1-branch.tar.gz > ❯ sudo tar xzf R-4.1-branch.tar.gz -C / > ❯ R -q --vanilla > zsh: killed R -q --vanilla > > The big-sur arm64 builds at > https://mac.r-project.org/big-sur/R-devel/arm64/R-devel.tar.gz > and https://mac.r-project.org/big-sur/R-4.1-branch/arm64/R-4.1-branch.tar.gz > also do the same. > > I know that another user has seen this as well, so chances are that it > is not some issue on my machine. Can anyone reproduce this? > > Gabor > > _______________________________________________ > R-SIG-Mac mailing list > R-SIG-Mac@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
