Skip to content

loader: use the real crypto/tls on hosted linux and darwin - #5635

Open
yohimik wants to merge 2 commits into
tinygo-org:devfrom
yohimik:upstream-pr/hosted-crypto-tls
Open

loader: use the real crypto/tls on hosted linux and darwin#5635
yohimik wants to merge 2 commits into
tinygo-org:devfrom
yohimik:upstream-pr/hosted-crypto-tls

Conversation

@yohimik

@yohimik yohimik commented Aug 30, 2026

Copy link
Copy Markdown

loader: use the real crypto/tls on hosted linux and darwin

Depends on upstream-pr/weak-strong-from-weak.

What this does

TinyGo replaces crypto/tls with a stub whose handshake does nothing, so a
program that dials https:// gets a plaintext connection behind the TLS API.
That stub is correct for a target with no OS below it, which has neither the
code size for a full TLS implementation nor usually a socket to speak it over.
Hosted linux and macOS have both, and there the crypto/tls of the Go standard
library compiles and runs.

The override becomes conditional. Without an entry in the map, crypto/tls
falls under the "crypto/" merge, which links the package of the standard
library into the synthetic GOROOT. GOOS alone cannot decide this, because a
baremetal target reports GOOS=linux, so the build tags decide as well. The
goroot cache key is a hash of the merge links, so the two variants get separate
cache entries.

Evidence

testdata/hostcryptotls.go makes an ECDSA key and a self-signed certificate at
run time, then does a TLS handshake over net.Pipe. It needs no network and no
netdev. TestHostCryptoTLS in main_test.go runs it on the host, and skips
where the host is not linux or darwin, in the same way as
TestTimerStopResetRace.

Measured on macOS 26.6 arm64.

Build Output
current dev, with the stub negotiated an unexpected version: 0
with this change got: pong and unknown certificate refused

The first row shows what the stub does. It reports a completed handshake and a
version of zero, and it does not verify anything. The second row shows a real
TLS 1.3 handshake, data through the connection, and a client with an empty root
pool refusing the certificate.

loader/goroot_test.go covers the decision itself, with the baremetal case that
reports GOOS=linux.

A downstream product ships binaries built with these changes in a production
release. dispat v1.4.0 is published and is not a prerelease. It carries
dispat-tiny-linux-amd64 and dispat-tiny-linux-arm64, built by the fork
release v0.42.0-net.4 from sha256-pinned tarballs and smoke-executed under
binfmt before upload, beside six binaries from the gc toolchain.
https://github.com/yohimik/dispat/releases/tag/services%2Fdispat%2Fv1.4.0

The acceptance record of that repository is committed at
packages/docs/docs/internals/tinygo.md. It reports the net.2 to net.4
acceptance history, an integration suite of 694 rows that passes with 0 failures
and 1 documented skip on darwin, and a size table of 0.58x to 0.63x against the
gc equivalents with TinyGo -opt=z -no-debug against go build -trimpath -ldflags "-s -w". Those figures come from that document. They are not a
measurement of this branch.

The self-update path of that program runs over real TLS against a live host, and
its suite has negative rows as well. An unknown CA is refused, and a plaintext
server on a TLS port is refused.

Scope and known gaps

  • Windows keeps the stub. So do wasm, wasip1, wasip2, wasm_unknown,
    nintendoswitch and every baremetal target. Their behaviour does not change.
  • Only a program that imports crypto/tls sees a size change, and such a
    program did not work before.
  • crypto/x509 on darwin uses the platform verifier, and
    crypto/x509/internal/macos in TinyGo is a stub, so a nil RootCAs fails on
    darwin. net/http in tinygo-org/net handles this by giving the client a root
    pool. A caller that dials tls.Dial directly on darwin has to supply
    RootCAs. See the tinygo-org/net PR "net/http: give the HTTPS client trust
    roots on darwin".
  • http.Client.Timeout is inert in the tinygo-org/net client. It is not
    addressed here.
  • crypto/tls API mismatch: missing tls.X509KeyPair and ClientAuth constants, LoadX509KeyPair stubbed #5204 lists crypto/tls API gaps such as tls.X509KeyPair. This change makes
    the real package available on hosted targets, so those gaps disappear there,
    but the stub keeps them on every other target.

Related

This is a smaller change than the netdev reworks in #4187, #4273 and #4498. It
does not replace the net package or add a netpoller. It only stops the
substitution of the TLS stub where the standard library package works.

Enables

A command line program that needs an HTTPS client path. Self-update, an API
client, a webhook sender. Client side only. There is no server claim here beyond
what the tests show.

Related pull requests

This change is part of one body of work. Together the changes make programs that use the network and child processes work on hosted linux and macOS. A full CLI was tested end to end with all of them and ships binaries built this way, see dispat v1.4.0 in the evidence section.

In this repository

In tinygo-org/net

A merge order that works. The three bug fixes are independent. #5633 goes before #5635. HTTPS on linux needs only #5633 and #5635. Full darwin support also needs #5636, the net changes and a new src/net submodule pin.

The runtime had weak.runtime_registerWeakPointer but not its counterpart, so a
program that reads a weak pointer back did not link. crypto/tls does this in
the certificate cache that it keeps behind a weak.Pointer.

Weak pointers are not weak here. registerWeakPointer returns the pointer that
it got, so the value it refers to stays and the way back to a strong pointer is
the identity too. weak.Pointer.Value thus never reports a collected value,
which the documented contract permits.

testdata/weak.go does not link on the current dev branch and prints the
expected value with this change.
TinyGo replaces crypto/tls with a stub whose handshake does nothing, so a
program that dials https gets a plaintext connection behind the TLS API. That
stub is correct for a target with no OS below it, which has neither the code
size for a full TLS implementation nor usually a socket to speak it over.
Hosted linux and macOS have both, and there the crypto/tls of the Go standard
library compiles and runs.

Make the override conditional. Without an entry in the map, crypto/tls falls
under the "crypto/" merge, which links the package of the standard library into
the synthetic GOROOT. GOOS alone cannot decide this, because a baremetal target
reports GOOS=linux, so the build tags decide as well.

The goroot cache key is a hash of the merge links, so the two variants get
separate cache entries.

testdata/hostcryptotls.go does a TLS handshake over an in-memory pipe with a
certificate that it makes at run time. On the current dev branch it prints
"negotiated an unexpected version: 0", because the stub does no handshake. With
this change the handshake completes, the data goes through, and a client that
does not trust the certificate refuses it. loader/goroot_test.go covers the
targets that keep the stub, the baremetal one that reports GOOS=linux included.
@yohimik
yohimik force-pushed the upstream-pr/hosted-crypto-tls branch from 2d41706 to 4b2c48c Compare September 2, 2026 08:50
@yohimik

yohimik commented Sep 2, 2026

Copy link
Copy Markdown
Author

Rebased on dev after the 0.42.0 release. The change applies on top of v0.42.0
as released without a conflict. An observation about the released toolchain:
testdata/hostcryptotls.go from this branch, built with the official v0.42.0
tarballs, prints "negotiated an unexpected version: 0" on linux/arm64 and on
darwin/arm64. The stub gives back a plaintext connection from tls.Dial that
verifies nothing. This change puts the real package in its place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant