-
Notifications
You must be signed in to change notification settings - Fork 38
fix(signingscript): Bug 2034166 reduce notarization requests #1426
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
Draft
hneiva
wants to merge
1
commit into
master
Choose a base branch
from
hneiva/smart-notarize
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+160
−31
Draft
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand why this is as it is, but this override based on
pkg_pathsis a code smell. Even for cases where we have both.pkgand.appinputs to notarize, this breaks down if an.appis not contained within a.pkg.Rather than relying on retries, can we do something a bit more intelligent here? Perhaps we can keep track of which
.apppackages are in a.pkgand do the right thing based on that instead?(This issue also goes away if we rework the order things are done in CI, of course.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mmmmm that's a good point.
Unfortunately I don't know of an easy way of checking what's inside the pkg without having to unpack the whole thing just to find out which locale is it.
I think the best long-term solution is to:
It also begs the question, should we always staple probe before sending for notarization? (even on pkgs) Reruns on chunked tasks are wasteful, since they always submit everything to notarization even if previous attempts have already notarized.
Or maybe this task should be "run-aware"? If it's the first run, don't probe pkgs?
I think we should avoid 2 notarizations here.
What we can do instead (the patch I liked gets us close to this):
sign .app -> create .pkg -> notarize+staple .pkg -> only staple the .app (which becomes the .dmg)
The .app inside the .pkg doesn't have to be notarized before it's packed inside the pkg.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough -- and unpacking just for this is probably expensive enough that it may not be worthwhile.
When you say "staple probe", do you mean inspection of local artifacts, or querying the remote server? If it's the latter, I think that's an excellent idea (more on that below).
This is an excellent idea that might be good to take up later/elsewhere. On runs > 0 we could have no, some, or all packages already notarized...and ideally we'd handle that gracefully. We do a similar thing in landoscript where we dump out status when submitting a job, but before polling its status. And when we first start up, we look for status from an earlier run when run_id is > 0.
In the case of notarization, I think there's one or more URLs we'd want to write out and use in a similar fashion?
Are we sure this doesn't have negative consequences? Presumably the
.appstill has its notarization status checked (whether through talking to apple, or checking for a stapled ticket)?Or does it get implicitly notarized when the
pkgis submitted? If that's the case, my view is that it's more comprehensible to sign and notarize the.appfirst, and then use the notarized app to make thepkg. The idea of making theapp, then stuffing it into apkg, then notarizing that, then pulling theappout of it and stapling it afterwards seems awkward to me. It also seems like it risks running into update issues -- if the.appin thepkgand thedmgare not identical, partial mars will fail for one or the other.I'd be happy to hop on Zoom to hash this out more at some point if that's useful; we might be reaching the limits of what we can hash out here.
In any case, if there's plans to improve and rework this in the near future I'm a little less fussed about what's happening here if it gives us a short term win.