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. Response avatar

    Resolution Note (fix version 2021.1):

    fixed in 2021.1.1f1

  2. Response avatar

    Resolution Note (fix version 2020.2):

    fixed in 2020.2.5f1

Comments (4)

  1. Cb0088335925614ac61657710cac4207?d=mm

    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

  2. Cb0088335925614ac61657710cac4207?d=mm

    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.

  3. D0845e73bbd64eb9b1ad7d5bb2461396?d=mm

    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.

  4. 5425fa6185bf2dc77376d87d94925979?d=mm

    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.