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.

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.

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"?

@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.

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?

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/

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.

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

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

@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.

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