Search Issue Tracker

Fixed in 2020.1.9f1

Fixed in 2019.4.X, 2020.1.X, 2020.2.X, 2021.1.X

Votes

0

Found in

2018.4.10f1

Issue ID

1188947

Regression

No

[macOS] Code Signing using '--deep' flag Fails on Built Package due to incorrect case in built Contents/PlugIns folder

MacOS

-

When building a macOS package for the game, which now needs to be signed and notarized, Unity adds a 'Plugins' folder to the Contents folder. This folder should be called 'PlugIns' (see https://developer.apple.com/library/archive/technotes/tn2206/_index.html - `Table 3 Standard locations for code inside a bundle`). As such when signing using the `--deep` flag the libraries in the 'Plugins' folder are not signed.

Steps:
1. Open attached project "80Days_repro.zip"
2. Build macOS standalone
3. In finder navigate to built player > right-click > Show Package Contents
4. Go to Contents/ folder
Expected: there is a PlugIns folder (capital I)
Actual: the folder name is Plugins (lowercase i)

Reproduced with: 2017.4.37f1, 2018.54, 2020.1.0a25

  1. Resolution Note (fix version 2021.1):

    fixed in 2021.1.1f1

  2. Resolution Note (fix version 2020.2):

    fixed in 2020.2.5f1

Comments (5)

  1. thomalade

    Jan 11, 2022 17:58

    Hello,
    unfortunately this fix seems to be causing other issues. We need urgent clarification.

    The computer is an M1 max. We are using Unity 2020.3.24f1, the same issue occurs on 2020.3.25.

    We need to deploy directly to macOs platform but our builds fail as such:

    UnauthorizedAccessException: Access to the path projName/Temp/StagingArea/25.main.app/Contents/PlugIns/FirebaseCppAnalytics.bundle is denied.

    Switching the plugin to force intel 64 or the build itself to intel 64 does not resolve this issue.

    A slightly different example is
    UnauthorizedAccessException: Access to the path projName/Temp/StagingArea/mainline.app/Contents/PlugIns/agoraSdkCWrapper.bundle/Contents/Frameworks/AgoraAIDenoiseExtension.framework/Versions/A/AgoraAIDenoiseExtension" is denied.

    Note that this one sits within a framework within a bundle. The bundles fails to be copied to folder "plugins" because the existent folder is named "PlugIns"

    There are bespoke solutions on the web from users mentioning to unset and re-set the bundle import settings, some say it should be forced to intel64 with the project at intel64.
    Unfortunately none of these solve our issue and I am failing to find suitable instructions to use SDK bundles

    Deploying to an Xcode project works but then running the build fails as soon as the relevant SDKs are initialised, just like the incomplete .app which found in temp/StagingArea.

    Thank for any advice, links, suggestions

  2. Gillissie

    Aug 03, 2021 19:24

    After typing my previous comment, I searched for the FBX exporter issue, and apparently someone else reported it, and it seems to have been fixed, though I haven't tested this.
    https://issuetracker.unity3d.com/issues/building-osx-standalone-with-fbx-exporter-package-installed-includes-extra-bundle-in-the-app-package

  3. Gillissie

    Aug 03, 2021 19:18

    Interesting... I always wondered why deep signing didn't seem to work. Maybe it was the lower-case i. I got around it by manually signing each library, which may be a little more code, but in the long run I think it's better to know exactly what libraries are in your build.

    For example, I found the hard way that the Unity FBX exporter asset ends up including a library in the build, which isn't needed or wanted. If it wasn't for the failed notarization telling me that the library wasn't signed, I wouldn't have noticed it was included in the build.

    Note: I submitted a bug report to Unity about the FBX library being included in builds when it shouldn't, but I think it was largely ignored. Now I have code in my build script that checks for the existence of the FBX exporter package, and throws a warning and stops the build process if it's found.

  4. sw-teooh

    Sep 25, 2020 10:20

    On 2019.4.9f1 and lower, we were doing this:

    1. Manually codesign everything inside "Contents/Plugins" and inside any subdirectory/framework within "Contents/Frameworks" (for example, "Chromium Embedded Framework")
    2. codesign --deep at the top level (i.e. codesign --deep XXXX.app)
    3. Bundle that app into another app generated by an Xcode project (Unity app sits inside "Data" within the parent app). XCode handles signing the parent app using normal xcodebuild behaviour.
    4. pkgbuild and productbuild to make a .pkg, and then that is sent for Notarization.

    This all worked fine.

    Since we upgraded to 2020.1.6f1 however, "Contents/Plugins" has changed to "Contents/PlugIns" as-per this ticket.

    Now, whether you manually codesign Contents/PlugIns or not (we assume that we must still manually sign all libs inside it because Unity doesn't do our signing as part of the build process), Notarization now fails due to "The signature of the binary is invalid.".

    The only way to make Notarization pass is to rename the directory back to Plugins with a lower-case "i".

    codesign -vvvv at any of the XCode-generated parent app, or the Unity-generated app passes and shows a valid certificate (and the same Developer ID certificate is used across the entire signing process and hasn't changed between 2019.4 and 2020.1), as does spctl --assess when run locally.

    I expect the problem may be that Apple's documentation says this directory must be PlugIns, but in reality they've changed it.

  5. pascal-teooh

    Sep 25, 2020 09:53

    This fix seems to break Notarization for us (2020.1.6), we've had to rename the folder back to Plugins (lowercase i).

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.