runtime: GOOS=ios fails Apple's app validation due to use of private API

[danderson]

What version of Go are you using (go version)?

$ go version
go version go1.20rc3-ts178d6bc darwin/amd64

This is Tailscale's Go toolchain from https://github.com/tailscale/go. It has some minor changes, but for the purposes of this bug it's identical to the final Go 1.20 release. You can see our very minor additional commits at https://github.com/tailscale/go/commits/tailscale.go1.20 , prefixed [tailscale1.20].

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/tsbuild/Library/Caches/go-build"
GOENV="/Users/tsbuild/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/tsbuild/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/tsbuild/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/tsbuild/.cache/tailscale-go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/tsbuild/.cache/tailscale-go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.20rc3-ts178d6bc"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/h6/n1fmcdqs5z765682qxt8sr7w0000gn/T/go-build460345883=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Built a test release of Tailscale's iOS app, which unfortunately is not open-source. It's a mixed swift+Go application built through xcode.

What did you expect to see?

A working app that passes Apple's app store validation.

What did you see instead?

Apple rejected the app bundle, on the grounds that it failed "SPI validation". This is apparently the process where Apple checks for unauthorized use of private APIs by the app.

*** Error: ERROR: Asset validation failed (11) The app references non-public symbols in Payload/Tailscale.app/PlugIns/IPNExtension.appex/IPNExtension: _xpc_date_create_from_current (ID: e6cd0a76-b3c5-4ce4-8a35-600308487c8c)

AFAICT, this is due to 76d39ae , which added a call to xpc_date_create_from_current in an attempt to fix atfork problems on darwin.

The same app builds and validates successfully when targeting macOS, so it appears that xpc_date_create_from_current is marked private only on iOS, not macOS.

[danderson]

cc @rsc, who appears to have all the state on this unfortunate set of fork issues. Sorry to be the bearer of annoying news :(

[danderson]

@bradfitz suggested just removing the osinit_hack on iOS as a test, on the principle that apparently fork+exec is forbidden in non-jailbroken iOS anyway.

Patch is at tailscale@d0f872e, which through dead code elimination removes the offending call from the binary. With this patch applied to the toolchain, Apple is once again happy with the Tailscale iOS app.

We haven't dug very deeply into whether disabling osinit_hack is safe, we're just going off internet claims that fork+exec is not permitted in the iOS runtime environment. If y'all have a direct line to Apple, it'd be good to get verification from them.

[bradfitz]

@bcmills, you targeted this at the Go1.21 milestone, but this is really a regression in Go 1.20.

[bcmills]

Yes. Presumably it should be addressed at HEAD and backported.

[rsc]

Yes, this should be fixed at HEAD and backported. Simply skipping the calls on ios makes sense to me: if you can't call exec, you don't need to work around the bugs introduced by calling exec.

[rsc]

Ironically, an Apple engineer suggested using xpc_date_create_from_current specifically because it was a public function. But maybe that's only true on macOS.

[rsc]

@danderson can you please check whether https://go-review.googlesource.com/c/go/+/466516 also signs properly? It's the same as your patch except the if statement is in a darwin-specific file to try to keep the ios knowledge more localized. If that works too, we will commit it and backport the fix. Thanks!

[gopherbot]

Change https://go.dev/cl/466516 mentions this issue: runtime: skip darwin osinit_hack on ios

[rsc]

@gopherbot please backport go1.20

[gopherbot]

Backport issue(s) opened: #58419 (for 1.20).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

[danderson]

Sorry, missed this today. I can cut another toolchain and app release tomorrow to test your change.

[rsc]

Thanks!

[heschi]

This is coming right down to the wire for 1.20.1. Is there a strong reason it can't wait for .2, which will probably be released on March 7?

[danderson]

No strong reason for us (Tailscale) since we are carrying the patch in our toolchain fork. If this doesn't ship in .1, Go development on iOS will be outright broken until .2 ships, since nobody will be able to ship any app that incorporates any Go code.

[danderson]

We patched https://go.dev/cl/466516 into our toolchain and built an unstable iOS app release. It worked fine, Apple was happy with the resulting binaries. LGTM!

[rsc]

Thank you!

[gopherbot]

Change https://go.dev/cl/467316 mentions this issue: [release-branch.go1.20] runtime: skip darwin osinit_hack on ios