-
Notifications
You must be signed in to change notification settings - Fork 28
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
[signingscript] Add apple notarization support #681
[signingscript] Add apple notarization support #681
Conversation
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.
This looks quite good overall! I'd like to see a few things before this lands:
- Agreement on what pool(s) we're going to use for these new workers
- Reworking the creds to set-up the files at init (instead of with each task)
- Some testing through
dev
before this lands (perhaps through adhoc-signing as we discussed before?).
command = [ | ||
"rcodesign", | ||
"notary-submit", | ||
"--staple", |
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.
This causes rcodesign to block on notarization completing. This is a notable change from our current process, and will tie up available workers in whatever pool this runs in.
I think this is OK to do, however, this argues for creating a new pool that is exclusively responsible for notarization and stapling (to avoid other signing types getting blocked or delayed if there's a spike in notarization requests, or Apple is slow, etc, etc.). This will end up being a nice simplification and clean up of the current graph (where we have the confusing "sign1" -> "poll" -> "sign3" flow).
(I don't think we need to use the current model of separate workers for notarization and stapling, as long as we do use a separate worker type here, and make sure its maxCapacity
is set fairly high.)
In an ideal world, each signingscript
that is handling notarization would be able to claim multiple tasks (since most of its work is just sleeping and waiting on Apple) -- but that is well into the realm of future improvements, and absolutely not part of this initial work.
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.
Let's get some measurements on how quick this goes with adhoc, then we'll have a better idea of how bad it could be.
|
||
# Notarize | ||
with tempfile.NamedTemporaryFile() as temp_creds: | ||
temp_creds.write(json.dumps(credential).encode("ascii")) |
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.
Is there a reason we can't simply deploy creds as this, rather than write them out with each task? We do this, for example, with Google credentials in pushapk workers: creating files as part of init, setting the file path as part of the worker config
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'm not sure I love the idea of either:
a. Having the credentials in SOPS base64'd
b. Having to construct the json file in init_worker.sh
What if we moved the credentials creation to async_main
? (if !credential.exist, create it
sort of deal)
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.
It will have to be in SOPS either way, no? (I don't think we have any other place to put secrets that these workers need?)
As far as init_worker vs. async_main - I don't feel terribly strongly either way. Although requiring an intermediary format to async_main
makes local testing a bit more annoying? I'm not going to block on either approach - as long as it's not being done per-task I'm pretty happy.
2ae1178
to
01ecc91
Compare
Tested on dev pool: mozilla-releng/adhoc-signing#152 |
os.path.dirname(context.config["apple_notarization_configs"]), | ||
'apple_api_key.json', | ||
) | ||
if os.path.exists(context.apple_credentials_path): |
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.
This code path means that this function doesn't do what it claims ("write credentials"), and also doesn't throw an error. Why does it exist, and what can we do to improve this? Is it a remnant from when this was being called per task?
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.
Basically it will write the first time, and skip for any subsequent tasks.
The function still checks for scope issues, so there's a reason for it to exist.
Any specific suggestions on improving it?
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.
In that case, it ought to have a different name, or move the scope checks out :).
await rcodesign_notarize(workdir_files, notarization_workdir, context.apple_credentials_path) | ||
|
||
# Compress files and return path to tarball | ||
return await _create_tarfile(context, path, all_file_names, compression, notarization_workdir) |
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.
Is there a particular reason we're sending these back as tarballs instead of pkg or apps (as we do with authenticode signing)?
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.
.app
s are not compressed at all.
Since this is a "new" type of task, defaulting to a compressed output seems reasonable.
That being said, we might adjust it later if required 🙃
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.
Ah right - I totally lost the plot on .app
format 😆 . This is fine.
949063d
to
8275397
Compare
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'm good with this with the write_credentials
function renamed (or the scope check moved out).
359fefe
to
8b17c13
Compare
DO NOT MERGESecrets still need to be added to SOPSIt's ready to roll