Add disable-library-validation entitlement to fix Satori on osx-x64
#189
Conversation
|
You should never add this entitlement to any public facing application/executable. It's quite literally there what your problem is, your dylib is signed with a certificate from a different team than what the main executable is signed with. Use library load constraints on the main executable to allow dylibs signed by the team of the dylib's signing certificate, or sign the dylib and the main executable with the same certificate. |
|
If that statement holds, the simple fix is likely to drop the certificate on the satori lib files before running |
|
Here's the codesigning info for a few builds:
To be clear, we only replace Unless I'm missing something, everything looks signed correctly to me. The only difference I can find is
I can understand this in context of the ad-hoc certificate I used in the OP and I've tried to mention as much but I guess my wording was confusing. I had tested with a developer certificate which gets past that and to the actual error our users are seeing: This is already happening from code executing inside
This is done automatically by the If this weren't the case, then we'd expect the app to also fail on osx-arm64 or for previous builds to also fail on osx-x64, but that is not what is happening. |
|
I'll look into it a little bit more and see if I can find something specific inside CoreCLR itself, or perhaps a build difference (could be an Xcode SDK difference)... As far as DYLD goes: Good: Bad: |
|
CLR built in debug mode asserts: Corresponds to this code: https://github.com/ppy/Satori/blob/cf8046d24861d63ce23fff3073f233c4e8baaa07/src/coreclr/vm/threads.cpp#L1200-L1212 This part wasn't directly touched by Satori, however that code segment is gone from .NET since dotnet/runtime#114982. Not sure how changing the entitlements resolves this... But I'm not sure where to go from here. Don't use Satori on osx-x64? I'll find some time to report upstream in case it's an issue with Satori itself... |
|
Closing this one - we won't deploy Satori to |
3 participants
I've gone super deep into this. Enough so that I can't write up everything I've done to try and resolve the issue, and at the end of the day I have no idea why things are as they are. I'll try to condense my findings.
Here's a test. Download the latest Tachyon release and perform the following using the entitlements on
master:Now, using the entitlements in this PR:
Now, the error from the first attempt is still different from what happens if you try to run the app directly after downloading, which is:
I don't know exactly why this is but I expect it's due to the adhoc signature. I can reproduce this error using my developer certificate. Thus, I'm only using the above as a demonstration that simply changing the entitlements fixes the issue.
From what I can surmise:
osx-x64or Rosetta, and to fix it we need to add this entitlement.osu!executable itself, but it likely goes beyond that for the case where you replace more than just the host. .NET Entitlements.codesign -d --entitlements - osu\!.app/Contents/MacOS/libcoreclr.dylibdon't include that entitlement on either release. As far as every tool I've used can tell me, the two files look practically identical between the releases. I'd expect that re-signing would lock down the app further, yet...