Closed janvennemann closed 3 years ago
@ssjsamir I think that's potentially just an artifact of downloading and using the zipped module from the Jenkins UI as opposed to being installed from the SDK zip itself. Although we probably need to be wary about the possibility of Apple requiring the binary to be signed in future I think @janvennemann @sgtcoolguy
@ewanharris @ssjsamir I've noticed similar notifications after downloading a Hyperloop release from our hyperloop-builds repo. However, after clicking "Cancel" i was able to manually allow it via System Preferences > Security & Privacy > General.
I'm not sure if just signing the binary is enough to get rid of this warning or if we even need to notarize it, which could be an issue because AFAIK only installer packages can be notarized and not the command line tool itself. We probably should file a ticket to double check this.
Eurgh yeah I forgot about the notarization process, I think this should be fine to merge then @ssjsamir
I have seen the metabase error as well. After I did a cancel
& allow
it in the security settings it did not come up again.
@ewanharris , do we plan to notarize it or something ? or it should be ok ?
@lokeshchdhry, Jan is right the notarisation only applies to Mac apps, installer packages, and kernel extensions so the metabase parser can't be notarized, it's possible we could codesign it like this to maybe prevent that warning eventually
Did you also see this when downloading from Jenkins? I haven't heard of anyone complain about this issue in the community, and I myself only get blocked from running it when download via Jenkins/GitHub, not when hyperloop gets installed by the SDK so for now I think we're fine to punt down the road.
Edit: I took a quick look at what is causing browser downloads to fail, it's because the OS is marking them with a com.apple.quarantine
attribute (see here) whereas when installed by the SDK it doesn't have that attribute
@ewanharris , yes I agree I only see it when downloaded via jenkins & not via SDK. Merging it.
JIRA: https://jira.appcelerator.org/browse/TIMOB-28154
This fixes a couple of issues with XCFramework packages introduced in 9.2.0:
.xcframework
packages. This is kind of a hacky fix since i only read in the headers from the first architecture listed in theInfo.plist
. I assume there is a possibility of the individual architectures exposing different different headers/types? Do we need to handle that? Should we check and make sure to use an arch that target's theios
platform in case the XCFramework containmacos
archs as well?LD_RUNPATH_SEARCH_PATHS
contains the correct values by default now so it doesn't need to be changed by Hyperloop.