Thanks, Bob (and JJB)! I have put the signing in a launch agent and we’ll see.
As for notarization, that will be interesting. The R installer is fine, the R.app likely, too (except for the hardening requirement and Xcode versions), but I’m not sure how that will affect the R.framework. I’ll experiment later next week. Cheers, Simon > On Sep 22, 2019, at 1:29 PM, Bob Rudis <b...@rud.is> wrote: > > (apologies for a second spam addendum, I hit "send" too quickly) > > In theory, once the latest Xcode is truly stable (the Xcode 11 GM is broken > in some places so there's going to be another release before Apple release > macOS Vista in October) the notarization "API" (that's way too kind of a word > for it) should be fully baked and can be added to any build pipeline. That > will require some other things for command line binaries (e.g. an Info.plist > and entitlements file just for the notarization) to get ask for, receive, and > then staple a ticket to a command line app. > > R.app will likely "need" said stapling come January 2020 (to avoid the "this > app is malware" message from Apple). > > For the previous mail, you should be able to also use `productsign` to sign > the installer the same way. > > -boB > >> On Sep 22, 2019, at 1:23 PM, Bob Rudis <b...@rud.is> wrote: >> >> Something like: >> >> <?xml version="1.0" encoding="UTF-8"?> >> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" >> "http://www.apple.com/DTDs/PropertyList-1.0.dtd";> >> <plist version="1.0"> >> <dict> >> >> <key>Label</key> >> <string>is.rud.buildr</string> >> >> <key>ProgramArguments</key> >> <array> >> <string>sh</string> >> <string>-c</string> >> <string>/Users/bob/Development/R-3.6.1/build-and-sign.sh</string> >> </array> >> >> <key>StartCalendarInterval</key> >> <dict> >> <key>Hour</key> >> <integer>13</integer> >> </dict> >> >> <key>UserName</key> >> <string>bob</string> >> >> <key>SessionCreate</key> >> <true/> >> >> <key>WorkingDirectory</key> >> <string>/Users/bob/Development/R-3.6.1</string> >> >> <key>StandardOutPath</key> >> <string>/Users/bob/tmp/buildr-stdout.log</string> >> >> <key>StandardErrorPath</key> >> <string>/Users/bob/tmp/buildr-sterr.log</string> >> >> </dict> >> </plist> >> >> put into ~/Library/LaunchAgents/whatever.you.want.plist >> >> then: >> >> $ launchctl load -w ~/Library/LaunchAgents/whatever.you.want.plist >> >> will run the build-and-sign.sh script at 1300 daily (made that up b/c it >> just turned 1300 here as I was typing) with std[out|err] logs preserved. >> >> The key elements of the plist to enable access to the cert are: >> >> <key>UserName</key> >> <string>bob</string> >> >> and: >> >> <key>SessionCreate</key> >> <true/> >> >> That should work on any recent/supported macOS. >> >> Use: >> >> $ launchctl unload -w ~/Library/LaunchAgents/whatever.you.want.plist >> >> to unload any active launchd agent so you can reload. >> >> To get verbose output from the code signing in the logs do: >> >> codesign -vs "Developer-id-stirng-from-keychain" file >> >> I belive only: >> >> Resources/bin/exec/R >> >> and any dylibs in: >> >> Resources/lib/ >> >> [need to|should be] be signed. >> >> While the script name I used is "build and sign" there's no reason you >> couldn't just have a launchd process for the code signing and keep the R >> build in cron. >> >> There are (or used to be, at least) quite a few google-able solutions to >> other scenarios for this, the most common of which has the use of Jenkins >> (or other build pipeline managers) to manage build pipelines for macOS and >> iOS apps. I did a quick "jenkins macos code sign" and they all still seem to >> be there (just looked at the list, didn't dig into the URLs to see if >> they're alive). >> >> -boB >> >>> On Sep 21, 2019, at 4:16 PM, Balamuta, James Joseph <balam...@illinois.edu> >>> wrote: >>> >>> Greetings and Salutations All, >>> >>> I think `launchd` jobs would properly sign the installer. `launchd` is >>> Apple's re-envisioning of `cron`. >>> >>> So, would it be possible to port over the cron job to `launchd`? >>> >>> Sincerely, >>> >>> JJB >>> >>> On 9/20/19, 11:06 PM, "R-SIG-Mac on behalf of Simon Urbanek" >>> <r-sig-mac-boun...@r-project.org on behalf of simon.urba...@r-project.org> >>> wrote: >>> >>> For some reason signing doesn't work in cron jobs even if the keychain is >>> unlocked. Hence only runs that I run from the shell are successfully signed >>> (like releases). If anyone has a solution, I'd like to hear it. >>> >>> Cheers, >>> Simon >>> >>> >>>> On Sep 19, 2019, at 12:55 PM, Kevin Ushey <kevinus...@gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> It looks like the builds of R from http://mac.r-project.org/ are typically >>>> not code-signed, and so one normally gets a Gatekeeper warning when trying >>>> to install them. E.g. I see (on macOS 10.14.6): >>>> >>>> “R-3.6-branch-el-capitan.pkg” can’t be opened because it is from an >>>> unidentified developer. >>>> >>>> Your security preferences allow installation of only apps from the App >>>> Store and identified developers. >>>> >>>> >>>> Is there any chance this might change in the future? >>>> >>>> Thanks, >>>> Kevin >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> _______________________________________________ >>> 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 > _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
