Briefcase 0.3.20 fails to staple the notarization onto my application #2090
Comments
|
Maybe the stapling fails because the notarization fails? The first few lines of the log seem to indicate that Apple returns an "invalid" response and briefcase fails to register that and tries to staple anyway? |
|
For briefcase 0.3.19 it returns: |
|
And briefcase 0.3.20 it returns: |
|
The notarization failing definitely sounds like a plausible underlying cause. To clarify the reproduction case - are you seeing this on a vanilla empty app? Or can you share the pyproject.toml (and in particular, the list of dependencies) that are packaged with the app? |
|
Glad you asked. I tried just now with: with different results. It works without problems. I will further investigate... |
|
This is strange. It is not any extra dependencies, it turns out to be the Python version. Maybe because of the specific wheels that get included in the application? Maybe because of Briefcase's specific stub binary for the different Python versions? This is what I get:
Unfortunately, I might need 3.11 at the latest. |
|
Managed to get my app working on 3.12, so for me this not high-priority anymore. Still, it's strange and might be a problem for other people. |
|
Thanks for those extra details. No idea what is going on - I can't think of any obvious reason why the 3.10/11 stub would be different to the 3.12/13 stub. - but I'm glad you've found an immediate workaround. Also, for anyone investigating: flagging that this could be a manifestation of #1218. |
|
Also flagging that #1472 would potentially make this error easier to diagnose. |
|
I've been able to do a little more diagnosis here:
This seems to indicate there was something wrong with the support packages published around the time of Briefcase 0.3.20. The immediate workaround would be to either:
The latter change (bumping the support revision) is something we should on the development branch anyway, as the support packages are out of date; but if I can get some confirmation from @davidfokkema or @amaretz that it resolves their notarization problem, I can backport the fix to 0.3.20 as well. I suspect the issue was fixed by this commit. If the support package contains files with extended attributes, that's the sort of thing that might cause errors with notarization that don't report as signing problems. The version of the support package that was being used by 3.12 and 3.13 had this change; 3.11 and earlier did not. |
|
Hi Russ -
I created and moved to a clean 13.1 based conda environment, and packaging/stapling work for me now. Such a huge relief, thank you. By the way I ran that successful “briefcase package” in my normal source tree, which as you may recall is in a part of my directory structure that syncs with Google Drive. Mentioning that as you had wondered whether the GD backing was possibly causing issues – I can now confirm ‘no’ on that.
Thanks,
Andy
From: Russell Keith-Magee ***@***.***>
Sent: Thursday, January 09, 2025 1:32 AM
To: beeware/briefcase ***@***.***>
Cc: amaretz ***@***.***>; Mention ***@***.***>
Subject: Re: [beeware/briefcase] Briefcase 0.3.20 fails to staple the notarization onto my application (Issue #2090)
I've been able to do a little more diagnosis here:
1. It's not PySide specific. I can see this on a vanilla Toga HelloWorld app as well.
2. It's not DMG specific. I get the same error with .zip packaging.
3. Python 3.10 packaging fails; but Python 3.12 packaging works.
4. On Python 3.10, you can also fix the problem by bumping the support package revision to b11.
This seems to indicate there was something wrong with the support packages published around the time of Briefcase 0.3.20. The immediate workaround would be to either:
* upgrade your environment so you're building using Python 3.12 or 3.13; or
* Add a support_revision definition to the macOS section of your app's config file. The exact version will depend on your Python version:
* Python 3.9: support_revision = "15"
* Python 3.10: support_revision = "11"
* Python 3.11: support_revision = "6"
The latter change (bumping the support revision) is something we should on the development branch anyway, as the support packages are out of date; but if I can get some confirmation from @davidfokkema <https://github.com/davidfokkema> or @amaretz <https://github.com/amaretz> that it resolves their notarization problem, I can backport the fix to 0.3.20 as well.
I suspect the issue was fixed by this commit <beeware/Python-Apple-support@d8fdaae> . If the support package contains files with extended attributes, that's the sort of thing that might cause errors with notarization that don't report as signing problems. The version of the support package that was being used by 3.12 and 3.13 had this change; 3.11 and earlier did not.
—
Reply to this email directly, view it on GitHub <#2090 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/A7IVDK3CRGV4TN5DOVTJSPL2JYJVLAVCNFSM6AAAAABT64HLDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZZGI3TGMZQGI> .
You are receiving this because you were mentioned. <https://github.com/notifications/beacon/A7IVDK2JEWKM76EDW4AUNZT2JYJVLA5CNFSM6AAAAABT64HLDGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUZXSLFM.gif> Message ID: ***@***.*** ***@***.***> >
|
|
I can confirm the notarization fails in Python 3.10, but succeeds with |
|
Ok - on the basis of those reports. I've backported the support package update to 0.3.20. You should be able to remove the Closing this ticket as resolved. |
|
I dropped |
Describe the bug
Version 0.3.20 fails in the stapling step during my application build. This is the error message:
Version 0.3.19 works fine.
Steps to reproduce
briefcase createbriefcase buildbriefcase package -i <developer id>Expected behavior
Completes the packaging step successfully.
Screenshots
No response
Environment
Logs
Additional context
No response
The text was updated successfully, but these errors were encountered: