[question] [mac] NDK that can be hardened and notarized #1060
Comments
|
From the docs it's not clear what we need to do for a non-xcode workflow (and I wasn't able to turn up much from searching either). Do you know if this is just a matter of building on a newer OS/with a newer version of the mac sdk? |
|
Hello @DanAlbert, This document has more information about doing it outside of Xcode: https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution/customizing_the_notarization_workflow Basically, for each of the native (Mach-O) binaries, you need to run This file also has more information related to those flags: https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution/resolving_common_notarization_issues |
|
Ah, okay. I'd seen that but I thought the notarization and hardening options were two different things. Thanks for the info. I'll see what we can/need to do. |
|
Hello @DanAlbert, any update on this? |
|
Nope. Haven't had a chance to look. |
|
Hey @DanAlbert, any update on this? Is there any workaround? |
|
We're not currently working in this. We'll update the bug when someone has a chance to look, but we're all currently busy with other tasks. |
|
Unlikely to be in beta 1, but I'd like to at least get the ball rolling on this since it would be good to have for our first LTS. |
|
+1 |
|
from https://arstechnica.com/gadgets/2019/10/macos-10-15-catalina-the-ars-technica-review/11/ i learn that notarization is more hassle than just signing... (this is actually mentioned in the docs linked to above, so i may be the only person that this is a surprise to, but i hadn't scrolled down as far as the "Add the username and password flags to supply your App Store Connect credentials" and "Check the Status of Your Request" and "Ensure Your Build Server Has Network Access" sections.) |
|
@enh @DanAlbert The requirement for Runtime Hardening has been relaxed in late summer 2019, but it will be enforced again January 2020. So it shouldn't be too difficult right now to submit the current release of the NDK and get that notarized. Past January 2020, the requirements will be made higher again (hardened runtime), so it's a good time now to invest in the build process to support that. |
|
Talked to our build folks about it. The rest is out of our hands but we'll update here when we know more. |
|
I'm a bit confused by part of https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution. Based on the image in the overview, notarizing doesn't actually save you from needing to step through approvals, it just changes the text on the approval message? |
|
We just ran through building an NDK app on a fresh install of Catalina and ran into no issues with the NDK not being notarized or hardened. From what I've heard, these restrictions do not apply to command line tools, only actual Mac apps. That also might be just because the restrictions got pushed back to January. I agree that it's still something we should do simply because code signing is good, but is there anything about this that's actually user observable? |
|
We ship binaries from the NDK as part of our package, so that reason, we'd need to have notarized (later hardened) binaries when we submit the package for notarization. |
|
Ah, okay. That makes sense. Thanks for the explanation. Out of curiosity, what package? |
|
Looks like this is worse for anyone directly downloading the NDK rather than getting it from the SDK: https://stackoverflow.com/q/58347120/632035. I'm guessing that getting it via the SDK manager means it inherits the permission already granted to Android Studio, but I haven't been able to confirm that yet. I'll try to get the priority of the infra bug raised. |
|
Thanks @DanAlbert - I work on Xamarin and we include parts of the NDK in Xamarin.Android. |
|
Finally got a working install of Catalina and confirmed that, yes, if you download the NDK directly you do have to click through a bunch of things when you first run. Still the same status as before. I'll try to get the priority raised. |
|
Hello @DanAlbert, nice blog post here: https://android-developers.googleblog.com/2019/10/introducing-ndk-r21-our-first-long-term.html. Do you think hardening will make it in the final r21 release? |
|
The bug for the infra support seems to be moving along, and I've done most of the work to get us ready to take advantage of it once it's ready, so that's starting to look possible. I'm not totally sure how long the infra work will take, but there are a handful of other teams that need this too so that helps. Even if it doesn't, this is having enough of an impact (measured in the highly scientific SO posts per week) that we'll push a hotfix when it becomes available if it doesn't make the initial stable release. |
|
@duncanmak What are the requirements you need to comply with for mach-o notarization? According to the docs Apple hasn't actually made it possible to staple notary tickets to binaries yet. Is it sufficient for you to lean on Apple's copy of that record? That seems to be how gatekeeper handles it (which AFAICT means that even after the NDK is notarized it can't be used on Catalina without internet access), but I'm not sure if there are different requirements for you getting your package notarized. I also wonder how that use case handles a binary if it's been notarized by multiple organizations, since I don't think there's anything preventing someone from signing and notarizing an unsigned binary themselves. |
|
To clarify: we'll end up with two artifacts for Mac.
Since it sounds like we have most of the infrastructure in place and (I think) all of the outstanding questions resolved, I'm optimistically putting this in the r21b bucket. r21b is coming a little later than I'd like (Android 11 got in the way), but I'm willing to hold it another couple of weeks if it means we can get this resolved. If this does take more than a couple weeks to complete, this will be moved to r21c, which will release as soon as this fix is ready to ship (possibly with no other changes). Not the same issue but somewhat related, in case anyone ends up here with a similar question: the next step of this process will be signing for Windows binaries. Windows doesn't have any strict requirements for this, but it sounds like the infrastructure that we integrated for Mac is general purpose enough that Windows should be easy once Mac is done. |
|
Another update to give everyone an idea of where we currently stand with this: this is still being actively looked at, but has turned up additional problems that we need to solve before it works. Our macOS target version is too low for some tools. The minimum version of macOS supported by the NDK needs to be lifted for Catalina. This shouldn't be much of a problem for users since Studio already targets 10.10, and we're not going above that. We're waiting for buildbots that are able to build with this SDK level so we can confirm the fix. The other problem that has come up is that it seems this effectively makes rpath unsupported for most distribution types. https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html
It would seem that for any binaries distributed by some means other than an app bundle, the restriction is that libraries only be loaded from the same directory as the executable. Still confirming that this is actually a problem, but that's what the logs seem to be saying. |
Test: Removed the mac conditional part of this and the DMG packaging to build on Linux. Output looks correct. Bug: android/ndk#1060 Change-Id: I55c36c89e145aa5f74e5b4c4d3e363539e1c7962
|
Hello. Any status on this? Thanks for working on this! |
|
We're making progress, but we've seen the goal posts move enough times as we reach them that I'm not sure how much longer it will take. The rpath issues have been solved (we'll distribute a framework bundle for macOS). We're still working on updating the version of macOS that we build binutils against. It's a very old build that we're trying to not change too radically since that would risk adding new bugs, and that's proving difficult. I have some changes out for review that might fix it, but things are moving a little slow right now. |
|
We have a build of binutils that's signable now (at least for one architecture; I've sent the config change to adjust all the others). In a day or so we should have a build to pull into the NDK branch and try signing/notarizing that. Assuming that works out, I'll cherry-pick the necessary changes into r21b (which I actually thought I'd be sending to QA today, but it seems we're very close on this one, so I'll give it another couple days). |
|
We did get a good build of each binutils, and https://android-review.googlesource.com/c/platform/prebuilts/ndk/+/1276898 updates master to that build. Once that's submitted and built we can try signing it to make sure it's all behaving correctly. Our mac builders are slow, so we probably won't know today, but tomorrow we should know whether this is going to get punted to r21c or not. |
|
Unfortunately it seems this is not quite ready yet (still a few more quirks to work out with our release tooling to account for the new delivery format). We'll follow up with r21c just as soon as it is ready even if it's the only thing we need the release for, but we really need to get r21b out the door and it's tough to tell how many more "just one more problem" cases we're going to encounter here. Thanks everyone for being patient about this. I know it's a pain point. |
|
Thanks for the updates, @DanAlbert |
|
The framework bundle seems to be inadequate (though you wouldn't know if from the docs). Trying to reorganize once again into an app bundle even though we're really not an app. Not sure how familiar folks on the thread are with the various bundle types, but if it sounds like I'm doing something stupid here, please let me know :) All the docs I'm finding guide us through how to notarize a typical application, but the information for something shaped like the NDK (a directory full of a ton of command line tools and libraries that need to keep the same layout) are extremely lacking. |
|
From here |
|
If you just want an NDK that works on your machine all you need to do is download it from the SDK manager. |
|
The app bundle worked. I was able to build an ndk-build hello world without bypassing gatekeeper. There's still more QA that this needs to go through, but @hhb is getting started on cherry-picking everything for releasing r21c. Here's the explanatory blurb I wrote for the changelog:
To be absolutely crystal clear here: the notarized app bundle works for all the currently known restrictions, but Gatekeeper may continue adding new restrictions. It's possible that we may need to distribute in a different format in the future, alter the layout of the app bundle, or make some other incompatible change. The layout or even the existence of the app bundle may not be stable across even point releases. We will do the best we can to avoid unnecessary breakage, and we'll give notice of any required changes as soon as we're able, but we can't predict changes that may be required of us in the future. For macOS, the SDK manager is the most reliable method of acquiring the NDK for most use cases and should be preferred until something else changes. That is not viable for all users, but if it is an option for you that's your best option. |
|
Hello @DanAlbert, sorry for not responding earlier. From my catch up of the thread, it looks like the r21c release of NDK (a zip file) will include binaries that will be hardened by Google? Do you have a timeline for when that will come out? You wrote earlier about how to submit to notarization - from my reading of the docs [0], I remember seeing somewhere that mentioned that it's possible to submit zip files for notarization, even though the majority of the documentation focuses on executable package formats like app bundles and installers. But for the use case that triggered this issue, we're looking for a released zip file with hardened binaries (verifiable via Thanks again for working on this. [1] https://lapcatsoftware.com/articles/hardened-runtime-sandboxing.html |
Very soon. We're just waiting on QA (that can mean anywhere between a day and a couple weeks depending on what other things they have on their schedule, but aiui they should be done with the NDK by the end of the week). Once they sign off it only takes us an hour or so to publish.
Zips can be notarized, yes, but unfortunately executables in the zip may not use RPATH. Everything we ship depends heavily on that, so we had to go with a bundle format packaged as a DMG.
It's a DMG rather than a zip, but to the best of my knowledge we have you covered. |
|
r21c is out. |
Context: https://github.com/android/ndk/wiki/Changelog-r21#r21c Changes: * [Issue 1060][0]: A macOS app bundle that is signed and notarized is now available for download from our wiki and our website. Note that because only bundles may use RPATHs and pass notarization, the traditional NDK package for macOS *cannot be notarized. The SDK will continue to use the traditional package as the app bundle requires layout changes that would make it incompatible with Android Studio. The NDK is not quarantined when it is downloaded via the SDK manager, so is curently allowed by Gatekeeper. The SDK manager is currently the most reliable way to get the NDK for macOS. * [Issue 1207][1]: Fix fatal error in clang when building with -O2 on arm64. * [Issue 1239][2]: Fix network drive issues for clang. * [Issue 1229][3]: README.md turned back to ordinary file. [0]: android/ndk#1060 [1]: android/ndk#1207 [2]: android/ndk#1239 [3]: android/ndk#1229
Context: android/ndk#1060 Context: https://android.googlesource.com/platform/ndk/+/39308a11b5e34a83aa6ff18523a59593e450a323%5E%21/#F0 Context: dotnet@2d89c74 The Android NDK build has been updated to support a minumum version of macOS 10.9 to meet notarization requirements. Now that these changes are live in NDK r21c, we can revert the NDK related notarization workaround introduced in commit 2d89c74. Instead of obfuscating these files, we can now sign and harden them ourselves before redistribution.
Context: android/ndk#1060 Context: https://android.googlesource.com/platform/ndk/+/39308a11b5e34a83aa6ff18523a59593e450a323%5E%21/#F0 Context: dotnet@2d89c74 The Android NDK build has been updated to support a minumum version of macOS 10.9 to meet notarization requirements. Now that these changes are live in NDK r21c, we can revert the NDK related notarization workaround introduced in commit 2d89c74. Instead of obfuscating these files, we can now sign and harden them ourselves before redistribution.
Context: https://github.com/android/ndk/wiki/Changelog-r21#r21c Changes: * [Issue 1060][0]: A macOS app bundle that is signed and notarized is now available for download from our wiki and our website. Note that because only bundles may use RPATHs and pass notarization, the traditional NDK package for macOS *cannot* be notarized. The SDK will continue to use the traditional package as the app bundle requires layout changes that would make it incompatible with Android Studio. The NDK is not quarantined when it is downloaded via the SDK manager, so is currently allowed by Gatekeeper. The SDK manager is currently the most reliable way to get the NDK for macOS. * [Issue 1207][1]: Fix fatal error in clang when building with -O2 on arm64. * [Issue 1239][2]: Fix network drive issues for clang. * [Issue 1229][3]: README.md turned back to ordinary file. [0]: android/ndk#1060 [1]: android/ndk#1207 [2]: android/ndk#1239 [3]: android/ndk#1229
Context: android/ndk#1060 Context: https://android.googlesource.com/platform/ndk/+/39308a11b5e34a83aa6ff18523a59593e450a323%5E%21/#F0 Context: dotnet@2d89c74 The Android NDK build has been updated to support a minumum version of macOS 10.9 to meet notarization requirements. Now that these changes are live in NDK r21c, we can revert the NDK related notarization workaround introduced in commit 2d89c74. Instead of obfuscating these files, we can now sign and harden them ourselves before redistribution.
Context: android/ndk#1060 Context: https://android.googlesource.com/platform/ndk/+/39308a11b5e34a83aa6ff18523a59593e450a323%5E%21/#F0 Context: 2d89c74 The Android NDK build has been updated to support a minimum version of OS X 10.9 to meet notarization requirements. Now that these changes are live in NDK r21c and xamarin-android is using NDK r21c (6d26c9a), we can revert the NDK-related notarization workaround introduced in commit 2d89c74. Instead of obfuscating these files, we can now sign and harden them ourselves before redistribution.
Context: https://github.com/android/ndk/wiki/Changelog-r21#r21c Changes: * [Issue 1060][0]: A macOS app bundle that is signed and notarized is now available for download from our wiki and our website. Note that because only bundles may use RPATHs and pass notarization, the traditional NDK package for macOS *cannot* be notarized. The SDK will continue to use the traditional package as the app bundle requires layout changes that would make it incompatible with Android Studio. The NDK is not quarantined when it is downloaded via the SDK manager, so is currently allowed by Gatekeeper. The SDK manager is currently the most reliable way to get the NDK for macOS. * [Issue 1207][1]: Fix fatal error in clang when building with -O2 on arm64. * [Issue 1239][2]: Fix network drive issues for clang. * [Issue 1229][3]: README.md turned back to ordinary file. [0]: android/ndk#1060 [1]: android/ndk#1207 [2]: android/ndk#1239 [3]: android/ndk#1229
Context: android/ndk#1060 Context: https://android.googlesource.com/platform/ndk/+/39308a11b5e34a83aa6ff18523a59593e450a323%5E%21/#F0 Context: 2d89c74 The Android NDK build has been updated to support a minimum version of OS X 10.9 to meet notarization requirements. Now that these changes are live in NDK r21c and xamarin-android is using NDK r21c (6d26c9a), we can revert the NDK-related notarization workaround introduced in commit 2d89c74. Instead of obfuscating these files, we can now sign and harden them ourselves before redistribution.
We're including bits from the NDK android-ndk-r20-darwin-x86_64.zip in our Mac installer package.
Some of the files from the NDK, particularly the
as,ldandstripcommands from the various toolchains. These files were built on an older version of macOS, and these binaries are also not hardened, per https://developer.apple.com/documentation/security/hardened_runtime_entitlements, so they are rejected by Apple's notarization service.Will there be a newer drop of the NDK with hardened binaries coming out soon? Around the Android Q timeframe?
The text was updated successfully, but these errors were encountered: