Re: [R-SIG-Mac] Nightly build segfaults
To paraphrase Bob Dylan, I would just like to reiterate: Without R-core, we’d all be in the swamp! > On Nov 18, 2021, at 2:58 AM, Simon Urbanek > wrote: > > > 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://urldefense.com/v3/__https://github.com/s-u/macosvm__;!!DZ3fjg!uKiUxJCX1SOhxn6XRbdVDGVpehTyT6pel_n4rvGaIez1HZpjzm-WXhftdqU_KeTkefc$ > 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 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://urldefense.com/v3/__https://mac.r-project.org/monterey/R-devel/arm64/R-devel.tar.gz__;!!DZ3fjg!uKiUxJCX1SOhxn6XRbdVDGVpehTyT6pel_n4rvGaIez1HZpjzm-WXhftdqU_xOZkD2o$ >> >> ❯ 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://urldefense.com/v3/__https://mac.r-project.org/monterey/R-4.1-branch/arm64/R-4.1-branch.tar.gz__;!!DZ3fjg!uKiUxJCX1SOhxn6XRbdVDGVpehTyT6pel_n4rvGaIez1HZpjzm-WXhftdqU_cx-HCp4$ >> >> ❯ 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://urldefense.com/v3/__https://mac.r-project.org/big-sur/R-devel/arm64/R-devel.tar.gz__;!!DZ3fjg!uKiUxJCX1SOhxn6XRbdVDGVpehTyT6pel_n4rvGaIez1HZpjzm-WXhftdqU_2VUrzbE$ >> >> and >> https://urldefense.com/v3/__https://mac.r-project.org/big-sur/R-4.1-branch/arm64/R-4.1-branch.tar.gz__;!!DZ3fjg!uKiUxJCX1SOhxn6XRbdVDGVpehTyT6pel_n4rvGaIez1HZpjzm-WXhftdqU_X3MZvq8$ >> >> 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 >>
Re: [R-SIG-Mac] Nightly build segfaults
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 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
Re: [R-SIG-Mac] Nightly build segfaults
On Wed, Nov 17, 2021 at 8:45 PM Prof Brian Ripley wrote: > > On 17/11/2021 19:32, Gábor Csárdi wrote: > > On Wed, Nov 17, 2021 at 8:14 PM Prof Brian Ripley > > wrote: > > [...] > >> With the tarball I get a popup telling me > >> > >> “R.framework” cannot be opened because the developer cannot be verified. > > > > Interesting. I am on 12.0.1 and there is no popup, but there is a > > crash report with > > > > Exception Type:EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)) > > > > Possibly the popup was added in 12.1 beta. > > I am running 12.0.1. Interesting. FWIW I tried to start it from an iTerm2 terminal, and there was no popup, just the "Killed" message and the crash report. Nevertheless the .tar.gz builds not working is an inconvenience, because it seems that the only way to run lldb now is to turn off the SIP. AFAICT homebrew signs its arm64 binaries now, but they are not notarized, and they seem to work fine. AFAICT they don't use the hardened runtime, so they are not notarized and I can run lldb on them. Gabor ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Nightly build segfaults
On 17/11/2021 19:32, Gábor Csárdi wrote: On Wed, Nov 17, 2021 at 8:14 PM Prof Brian Ripley wrote: [...] With the tarball I get a popup telling me “R.framework” cannot be opened because the developer cannot be verified. Interesting. I am on 12.0.1 and there is no popup, but there is a crash report with Exception Type:EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)) Possibly the popup was added in 12.1 beta. I am running 12.0.1. [...] The .pkg I tried is unsigned/not notarized so cannot be installed, not even with 'Open With'. But packages are at least sometimes signed. FWIW I did some local builds on a Big Sur machine with Xcode 12.x with the same settings as the CRAN builds (for readline support primarily), and those (https://files.r-hub.io/macos/readline/) work fine on Monterey as well. -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Nightly build segfaults
On Wed, Nov 17, 2021 at 8:14 PM Prof Brian Ripley wrote: [...] > With the tarball I get a popup telling me > > “R.framework” cannot be opened because the developer cannot be verified. Interesting. I am on 12.0.1 and there is no popup, but there is a crash report with Exception Type:EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)) Possibly the popup was added in 12.1 beta. [...] > The .pkg I tried is unsigned/not notarized so cannot be installed, not > even with 'Open With'. But packages are at least sometimes signed. FWIW I did some local builds on a Big Sur machine with Xcode 12.x with the same settings as the CRAN builds (for readline support primarily), and those (https://files.r-hub.io/macos/readline/) work fine on Monterey as well. Gabor [...] ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Nightly build segfaults
On 17/11/2021 07:17, Prof Brian Ripley wrote: On 16/11/2021 22:28, Gábor Csárdi 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 That is not a segfault, although they have been seen to cause this behaviour. It more often indicates a security issue: arm64 macOS is prone to doing so with incremental rebuilds of R that it thinks have been tampered with. With the tarball I get a popup telling me “R.framework” cannot be opened because the developer cannot be verified. Try installing the .pkg. (Downloading from mac.r-project.org is far too slow at the moment for me to do so, but I recall past troubles with the tarballs not seen with Installer packages.) And this evening downloads took a few seconds rather then the 2h predicted when I wrote that. The .pkg I tried is unsigned/not notarized so cannot be installed, not even with 'Open With'. But packages are at least sometimes signed. 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 -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Nightly build segfaults
On 16/11/2021 22:28, Gábor Csárdi 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 That is not a segfault, although they have been seen to cause this behaviour. It more often indicates a security issue: arm64 macOS is prone to doing so with incremental rebuilds of R that it thinks have been tampered with. Try installing the .pkg. (Downloading from mac.r-project.org is far too slow at the moment for me to do so, but I recall past troubles with the tarballs not seen with Installer packages.) 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 -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] Nightly build segfaults
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
