crypto/x509: build tag "ios" broken at tip on darwin/amd64

[bradfitz]

In previous Go releases, the "ios" build tag with darwin/amd64 produced working binaries:

barloga5k:x509 $ go1.14.2 download
...
Downloaded 100.0% (125040726 / 125040726 bytes)
Unpacking /Users/bradfitz/sdk/go1.14.2/go1.14.2.darwin-amd64.tar.gz ...
Success. You may now run 'go1.14.2'
barloga5k:x509 $ GOARCH=amd64 go1.14.2 install --tags=ios crypto/x509
barloga5k:x509 $

(Such a configuration is used when running under the iOS simulator in Xcode)

But at Go tip:

barloga5k:x509 $ go version
go version devel +a7e9e84716 Mon Apr 27 20:20:53 2020 +0000 darwin/amd64
barloga5k:x509 $ go install --tags=ios crypto/x509
# crypto/x509
./cert_pool.go:65:9: undefined: loadSystemRoots
./root.go:21:32: undefined: loadSystemRoots

Looks like https://go-review.googlesource.com/c/go/+/227197 (da8591b, @aclements) dropped the // +build arm arm64 ios disjunction.

Labeling release-blocker in that it's a regression.

[FiloSottile]

The ios build tag was only used in crypto/x509, and not documented anywhere I could find. Is "like iOS but on amd64" a supported configuration? Is crypto/x509 really the only thing that needs to support it?

[bradfitz]

I have no clue about the history other than it used to work and I stumbled into a project that was depending on it.

[bradfitz]

(fwiw, I was also surprised it ever worked)

[aclements]

Probably we just need to drop the !ios build constraint from root_cgo_darwin.go? I guess previously that was meant to be exclusive with root_darwin_armx.go, but I only dropped the positive build tag. That would just make it ignore the ios build tag.

[bradfitz]

@aclements, that might not work because cgo might be disabled in such an environment.

What I ended up doing for our build was renaming those files from "arm" to "embed" (in tailscale@1f0b2d1) and making the build tags be:

// +build !x509omitbundledroots
// +build darwin
// +build arm64 ios

[aclements]

@FiloSottile , what do you think is the right fix here? It should be easy to fix, I'm just not sure what the right way to do it is. :)

[toothrot]

@FiloSottile Friendly ping as this is a Go 1.15 release blocking issue.

[dmitshur]

I have no clue about the history other than it used to work and I stumbled into a project that was depending on it.

@bradfitz Can you elaborate on how the project is depending on it? What was the expected behavior? If we can make it more clear what the mode represents and is supposed to do, it will make it easier to make progress here. I'll update the issue state to NeedsInvestigation because I don't think we know what the fix needs to be yet (as confirmed from discussion above).

While it's true this is a regression, if we take the potential plan for 1.15 described in #38485 (comment) into account, we may want to deliberately make a change here anyway. This would be in scope of Go 1 compatibility promise since the mobile support is considered experimental and the ios tag was not documented. I don't know yet if we'll want or need to do that, just pointing out that issue is relevant here.

I understand the current (Go 1.14) modes of operation and the tags that are satisfied are:

Mode	Satisfied Build Tags
macOS, x86 64-bit	darwin, amd64, !ios
iOS mobile, ARM 64-bit	darwin, arm64, !ios
Issue #38710 mode	darwin, amd64, ios

We would execute the plan in #38485 (comment) only if we know that darwin/arm64 needs to be reclaimed for macOS, which would be if there is an announcement of a future ARM-based macOS configuration (we may learn more from WWDC 2020 keynote in 4~ days). So the forward-looking table may look like this:

Mode	Satisfied Build Tags
macOS, x86 64-bit	darwin, amd64, !ios
macOS, ARM 64-bit	darwin, arm64, !ios
iOS mobile, ARM 64-bit	darwin, arm64, ios
Issue #38710 mode	darwin, amd64, ios

At that point, it would only be possible to preserve "Issue #38710 mode" behavior of Go 1.14 on an incomplete subset of macOS configurations. If it's important for this mode to be available to all macOS users, some change will be needed.

@bradfitz From the commit message of tailscale@1f0b2d1, I understand "Issue #38710 mode" is related to the iOS simulator. Do you know if it needs to be different from normal iOS mobile (other than the architecture difference)?