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

cmd/link: keep MacOS binaries compatible with Apple Notary #31918

Closed
networkimprov opened this issue May 8, 2019 · 12 comments
Closed

cmd/link: keep MacOS binaries compatible with Apple Notary #31918

networkimprov opened this issue May 8, 2019 · 12 comments

Comments

@networkimprov
Copy link

@networkimprov networkimprov commented May 8, 2019

Review this before each release, as the required SDK value will eventually change.

The minimum SDK is given by a pair of constant expressions, last seen at:
https://github.com/golang/go/tree/master/src/cmd/link/internal/ld/macho.go#L418

// The version must be at least 10.9; see golang.org/issues/30488.
ml := newMachoLoad(ctxt.Arch, LC_VERSION_MIN_MACOSX, 2)
ml.data[0] = 10<<16 | 9<<8 | 0<<0 // OS X version 10.9.0
ml.data[1] = 10<<16 | 9<<8 | 0<<0 // SDK 10.9.0

See also https://developer.apple.com/documentation/security/notarizing_your_app_before_distribution/resolving_common_notarization_issues

Originally raised in #30488

@networkimprov

This comment has been minimized.

Copy link
Author

@networkimprov networkimprov commented May 8, 2019

Milestone should be 1.14 (unless there is a milestone for "every release").
Tag should be NeedsFix, or none.

I opened this at request of @ianlancetaylor.

@macetw

This comment has been minimized.

Copy link

@macetw macetw commented May 8, 2019

My team used this basic fix, to change the constants as cited, with a binary that was later submitted to Apple Notary and it worked with flying colors. The Certification is officially stapled to our application. I believe this should satisfy the "NeedsInvestigation" portion of this issue.

@dmitshur dmitshur modified the milestones: Go1.13, Go1.14 May 8, 2019
@randall77

This comment has been minimized.

Copy link
Contributor

@randall77 randall77 commented May 9, 2019

So what's the specific action item we should do for each release? Check that "See also" page and make sure it still says "10.9"?

@macetw

This comment has been minimized.

Copy link

@macetw macetw commented May 9, 2019

@randall77 are you asking me? Do you mean what action should you take to ensure binaries can be Notary-certified?
Well, the best practice would be to embed a binary into a .pkg file in some way, run the .pkg file through the notary-cerification process, and ensure that it passes. That would be 100%. I'm not sure whether that's realistic, because I don't know the steps to begin that relationship to submit anything to apple. My experience was relying on members of my team in another office who set up the relationship.
I wonder about the same kind of test that checks whether "codesign" works on Go binaries. codesign is a prerequisite of getting approval for notary. It requires a certificate, and I also don't know how an open source project would acquire such a certificate.

@randall77

This comment has been minimized.

Copy link
Contributor

@randall77 randall77 commented May 9, 2019

I'm asking anyone who might know.

Actually getting something notarized would certainly be a good test. That seems hard though. You need to sign a binary, have a valid Apple developer ID, etc.

I'm wondering about the simpler problem of this issue - how will we know when Apple changes the minimum version from 10.9 to something larger? Is there a canonical reference we can check?

@macetw

This comment has been minimized.

Copy link

@macetw macetw commented May 9, 2019

According to my associate, enrollment in the Apple developer program costs $100. It seems to include both a login to notarize and a codesign certificate.
https://developer.apple.com/programs/enroll/

@pieterclaerhout

This comment has been minimized.

Copy link

@pieterclaerhout pieterclaerhout commented May 13, 2019

You need to be enrolled as an Apple Developer to be able to notarize your app. Additionally, there is quite a bit of setup needed to get notarization up and running.

The notarization process is also rather tricky as it's an async thing. You need to submit your app after building to the notarization service. You then need to poll for the status to see if it gets notarized or not (which takes anywhere from seconds to several minutes). If the notarization fails, you need to parse the output, download a log, parse that again to figure out what is wrong.

My guess is that checking if the required SDK version is 10.9 should be what needs to be checked.

I'm not sure if this minimum requirement is going to change anytime soon though.

@andybons

This comment was marked as off-topic.

Copy link
Member

@andybons andybons commented Nov 1, 2019

We got bit by this (#34986). Luckily Apple extended the deadline before the notarization service gets more strict. We still have work to do before we abide by every rule:

  • Enable the Hardened Runtime for the go, gofmt, link, etc. binaries (and figure out whatever entitlements are needed)
  • Figure out what to do about binaries shipped (within testdata) that will never be signed but the notary will reject

EDIT: this isn’t the right issue for this work. This should be about whether binaries produced by the Go toolchain remain compatible with Apple’s notary, not whether the toolchain itself is compatible.

@mtibben

This comment has been minimized.

Copy link

@mtibben mtibben commented Nov 1, 2019

Actually getting something notarized would certainly be a good test. That seems hard though. You need to sign a binary, have a valid Apple developer ID, etc.

If it helps create a reproducable workflow or test, here's a script in use that signs a go binary, packages in dmg, then signs and notorizes the dmg via the CLI.

https://github.com/99designs/aws-vault/blob/master/bin/create-dmg

@thanm

This comment has been minimized.

Copy link
Member

@thanm thanm commented Nov 13, 2019

@andybons Are there any linker changes needed here? Let me know if I can help.

@andybons

This comment has been minimized.

Copy link
Member

@andybons andybons commented Nov 13, 2019

@thanm I don't believe so. For the internal linker, we're all set. For the external linker (cgo binaries), users can specify the right flag using CGO_CFLAGS when compiling. We're discussing on #35459 what to do for the go command specifically.

@andybons

This comment has been minimized.

Copy link
Member

@andybons andybons commented Nov 22, 2019

As we need to notarize every toolchain release and all toolchain binaries except for the go command are built using the internal linker, we’ll notice problems there quicker than we will by checking this issue during every release cycle. We have plans to do nightly notarization checks to catch issues, but that is being tracked internally as we’re using internal-only infrastructure (we need access to certain private Apple certs/keys).

Closing as binaries created by the current toolchain have the correct Mach-O header values for notarization. If new problems arise, we’ll create a new issue for them.

Thanks

@andybons andybons closed this Nov 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.