Open bboston7 opened 4 years ago
I have heard more complaints about this from collaborators and potential clients. We should really take care of this for our core tools. See https://github.com/GaloisInc/cryptol/issues/992
I can confirm that we're discussing how to make this happen. I expect 2021 releases to be properly signed.
I have spent some time mucking around with trying to make the macOS CI notarize binaries, and I've come to the conclusion that it's probably easier and more direct just to apply the workaround here rather than pursue full notarization.
Sorry, but 🙄. Why can random open source authors do this and we cannot? Is it something about the PL stack we use?
It doesn't have to do anything with the language we're using so much as how many hoops you have to jump through in order to comply with Apple's notarization process. At minimum, you have to create an Apple ID and perform some non-trivial settings wrangling in Xcode in order to get the unique identifier you need for notarizing, and then perform the actual binary signing. I wasn't able to figure out how to do this the last time I tried, but admittedly, I am not very familiar with the Apple ecosystem.
If only DanZ were still working with us, as he'd eat this for lunch. Let's see if we can find a real macOS developer geek to take care of this with joy.
The SAW macos binary on the download page is unsigned, making it unintuitive to run. Simply running
./saw
will raise an error without an option to override it. Instead, the user must do the following:saw
in Finder.saw
and select "Open"saw
is from an unidentified developer. Click Open to continue.From then on, the user can run
./saw
from the terminal. It would be nice if the app were signed to avoid all of this, but if not then the download page should list these steps.