-
Notifications
You must be signed in to change notification settings - Fork 26.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MacOS builds getting rejected by Apple #126705
MacOS builds getting rejected by Apple #126705
Comments
@borjandev Are you trying to re-sign already signed FlutterMacOS.framework? |
I am following the official Xcode MacOS app submission flows, same issue from the GUI and even from fastlane flows, the only variable is the commit change, once 3d25049 landed, every newer commit submission has resulted in the same rejection Can you specify a commit hash that you want me to test specifically? |
Let's try with |
@godofredoc same issue with 9c72f5a • Flutter version 3.11.0-5.0.pre.57 on channel master at /Users/devdemo/fvm/versions/9c72f5a7e62e63c199739267f3feeee0559caf11 |
Umm my understanding is that we only sign binaries tied to a release, umm should we also sign artifacts associated with a random hash? |
@borjandev are these files in your app tree: If they are can you please delete them and try to sign again? |
Used the Xcode GUI and default flows to upload, same issue, same email from Apple |
thanks for explaining! As a side note, the engine revision of 3d25049 points to 689eb6ee904772cf1ffa458ac7fa16b903215c8f as the hash of the engine binary. I visited google cloud buckets of the engine binary and it looks like the FlutterMacOS binary in FlutterMacOS.framework wasn't signed. Not sure if this is the expected behavior. entitlements.txt and without_entitlements.txt are present in the zip. the libswiftCoreImage.dylib files listed here are not on the list of files we would code sign. umm if we are expecting 3d25049 to be signed, does this mean we published a release with unsigned binaries? |
When I look at the first release branch AFTER 3d25049, it looks like it had a different engine hash: 55c988f Thus I don't think flutter/engine@689eb6e was ever included in a RC branch, and I don't think it was ever codesigned. I'm not sure the issue, but I don't think it's related to the desktop release codesigning process. |
@XilaiZhang @christopherfujino @godofredoc The flutter master commit that started causing this MacOS rejection 3d25049 has the following PR linked to it #125598 This #125598 PR contains 2 commits : reland "Migrate mac_host_engine to engine v2 builds." (flutter/engine#41531) - acc49d3 Roll buildroot to 5708f2051772fd02c949e5dc9397e54f8c7a4478 (flutter/engine#41540) - deef282 So one of these 2 commits above caused the issue (unless I am missing something?) If it's not connected to the engine v2 builds, maybe it's related to the buildroot change? With the PR flutter/engine#41540
Which is linked to flutter/buildroot#722 which has a ton of files removed as noted here https://github.com/flutter/buildroot/pull/722/files Glancing through the removals, the obvious ones removed in reference to 'mac' are shown on the screenshot below, so I am not sure if they are relevant? |
Here is the diff in a github view: https://github.com/flutter/engine/compare/19045bb99c..689eb6ee I suspect the root cause is some subtle directory structure change (as speculated in #126705 (comment)). Note, a google search on the error message "unsealed contents present in root directory" results in https://developer.apple.com/forums/thread/93914, where a new QT release no longer had an accepted Mac framework directory structure. |
Umm for the potential branches that could have contained 3d2504, here is the list from
among this list of branches, my understanding is that only flutter-3.11-candidate.0 is a recent release branch? switching into this branch and grep the first release after 3d2504, using |
Let me replicate the build locally. Seems like a symlink may be the culprit. Will use 3d25049 for the replication and engine hash |
I think you're mixing two different ideas:
For number 1, I don't think there are any releases that have that exact commit. However, since most likely the issue isn't with our codesigning process, I don't think this matters. Thus, I think we actually care about number 2, in which case you're right that our 3.11.0-0.0.pre beta release WOULD be affected. |
An important note, which makes this even more painstaking to debug, is that the actual MacOS build is accepted by App Store Connect when this issue happens, which means that the upload succeeds and everything is "looking good" until Apple sends this email after they are done with their processing, which also "burns" the version number, and the app needs to be re-compiled with an increased version number, and re-submitted again, and to wait for apple to process it again, and waiting at least 5 or more minutes for Apple to send the email detailing the rejection reason. |
umm right I was trying to eliminate/verify that codesigning wasn't the culprit.
|
@XilaiZhang @christopherfujino @godofredoc as suspected, I can confirm that the issue is reproducible as well on the beta channel 3.11.0-0.0.pre
|
@borjandev thanks so much for verifying and for all of your thorough research. |
@borjandev can you please give it another try using 3d25049 and deleting and regenerating the app? |
@godofredoc I have already tried that prior to opening the issue,
Do you want me to try the same test one more time exactly with 3d25049 ? Or do you want me to try some variation? |
That's correct, it will be great if you can re-rerun with |
@godofredoc oh wow that seem to have worked, the issue is gone for the example app (i will confirm for the real app) |
Congratulations! |
This is great news, if that works we'll send a fix on Monday and cherry pick it to Beta. For context the issue is caused by the new signing metadata files being extracted in a folder expected to contain only the files to be signed. |
This should be fixed on master and there is a cherry-pick request to get this fixed on beta: #127350 |
@godofredoc @christopherfujino did you guys verify that the rejection issue has been solved? I tried the TOT on master branch, which is c313083 at the moment, and still the same rejection happens. (unless I am missing some extra step?) |
hmm, no I didn't verify (I don't have neither a developer account nor an app to publish). I'll have to investigate this more tomorrow. |
I can replicate the issue running the following commands:
Finds the following files:
|
I think I know what the problem is. Do we need to duplicate the delete logic where we extract the second zip of FlutterMacOS.framework? |
Sure, i can do this tomorrow |
Thanks for the catch! |
@vashworth it looks like I ALSO need my previous change, where I deleted it at the time we copied from the cache to the build dir |
…d dir (flutter#127417) Fixes flutter#126705 Follow up fix after flutter#126875 did NOT work.
…d dir (flutter#127417) Fixes flutter#126705 Follow up fix after flutter#126875 did NOT work.
when traversing every directory, trigger the logic to cleanup codesign metadata files. This will help remove codesign metadata everywhere in the engine binary. As pointed out by Godofredo, currently we have multiple metadata files due to the double zip structure in mac framework zip file. context: flutter/flutter#126705
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of |
Is there an existing issue for this?
Steps to reproduce
master
branch at commit 3d25049 or laterflutter create --org com.yourdomain example
(change to a real bundle identifier)flutter build macos --release
Xcode Version 14.3 (14E222b)
and click"Product --> Archive"
"Validate App"
once the archive completes and perform the signing process which is a part of the same flow"Distribute App"
and keep the"App Store Connect"
selected, and perform the re-sign process for App Store Connect distribution which is part of the same flowExpected results
App appears in TestFlight without issues.
Last known good commit on master is 4fb146e where the app appears in TestFlight without issues.
Actual results
App doesn't appear in TestFlight on
master
branch at commit 3d25049 or laterInstead, I get an email from Apple :
Code sample
Code sample
Screenshots or Video
Screenshots / Video demonstration
[Upload media here]
Logs
Logs
[Paste your logs here]
Flutter Doctor output
Doctor output
The text was updated successfully, but these errors were encountered: