Skip to content
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

Support macOS (darwin) amd64 and arm64 builds of Microsoft Go #1368

Closed
dagood opened this issue Oct 23, 2024 · 2 comments
Closed

Support macOS (darwin) amd64 and arm64 builds of Microsoft Go #1368

dagood opened this issue Oct 23, 2024 · 2 comments
Assignees
Labels
Area-Acquisition New ways to acquire our build of Go new-platform Support a platform new to the microsoft/go infrastructure

Comments

@dagood
Copy link
Member

dagood commented Oct 23, 2024

This issue tracks supporting Microsoft Go toolset builds for macOS on our scripts/infra. A tricky point here is signing. We need to be able to sign the macOS binaries so that when we do publish a macOS build, it's compliant. (Also, I believe only 2/4 of us have access to macOS machines at the moment.)

Note: it's probably better to do this without FIPS compliance support initially. It will be easier to work on that with the basic workflow in place. (#1013)

@dagood dagood added Area-Acquisition New ways to acquire our build of Go new-platform Support a platform new to the microsoft/go infrastructure labels Oct 23, 2024
@dagood dagood self-assigned this Oct 23, 2024
@dagood
Copy link
Member Author

dagood commented Oct 28, 2024

Signing macOS archives seems pretty nasty. If I'm reading @gdams change and how notarization works correctly, we need three passes:

  1. Sign individual binaries from inside the tar.gz and put them back in.
    • I've started changing the bulk of our signing code from MSBuild to Go so that we can ensure the permissions are set correctly on our Windows builder that is running all this. Also so the logic isn't as hostile to maintenance.
  2. Sign/notarize the tar.gz, which actually modifies the tar.gz itself.
  3. Create a signature for the tar.gz.
    • Arguably not necessary?

We currently have just one pass. We sign individual files in the zip, but we don't create a signature for the zip. For tar.gz files, we only create a signature.

We can use the necessity of having at least two passes as an opportunity to produce signatures for our zip files, simply to keep our artifacts more similar.

@dagood
Copy link
Member Author

dagood commented Nov 8, 2024

Complete, but there is some followup:

Test builder: #1394
Notarization, or determining that we don't need to do it: https://github.com/microsoft/go-lab/issues/147

@dagood dagood closed this as completed Nov 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Acquisition New ways to acquire our build of Go new-platform Support a platform new to the microsoft/go infrastructure
Projects
None yet
Development

No branches or pull requests

1 participant