fix(host): tolerate browser-injected unusable SSLKEYLOGFILE paths

[danekurian-git]

What

• Sanitize SSLKEYLOGFILE when the browser launches Tailchrome's native host with a path it cannot open.
• Preserve usable key-log paths so intentional TLS debugging continues to work.
• Add regression coverage for unusable and usable key-log targets.

Why

Closes #113.

Bitdefender's encrypted web scanning injects SSLKEYLOGFILE=\\?\Volume{...}\virtual_file.log into Firefox child processes. The Tailchrome helper inherits the protected absolute volume path. Tailscale 1.100.0's TLS dialer treats the failed open as fatal, so the helper exits before initialization and Tailchrome repeatedly reports native-host-stopped.

The sanitization runs only in native-host mode. Installer, uninstaller, and version operations are unchanged.

How to Test

• corepack pnpm typecheck
• corepack pnpm test (567 tests)
• corepack pnpm test:installer under Ubuntu 24.04 WSL
• (cd host && go test ./... && go vet ./...) on Windows amd64
• git diff --check
• Reproduced with Firefox 154, Tailchrome 0.1.13, and Bitdefender Total Security 27.0.61.344
• Built and installed the revised helper; Firefox launched it directly, it remained logged in with established connections, and a proxied route check exited in Miami, Florida
• go test -race ./... locally (Windows host has no C compiler; Linux PR CI runs this gate)

Checklist

• Tested in Chrome (Firefox/Bitdefender-specific reproduction)
• Tested in Firefox
• Updated README if needed (no documentation change needed)

[dantraynor]

@danekurian-git thanks for the issue and the fix — great writeup. Verified the root cause against tailscale 1.100.0 (the log.Fatal in tlsdial.go) and the approach checks out. Only thing I added was a log line when the var gets cleared, so the reason shows up in helper stderr instead of key logging silently disappearing. Since you have the actual Firefox + Bitdefender setup, a quick run on the updated branch to confirm it still behaves would be appreciated. Marking this ready for review.

[danekurian-git]

@dantraynor Honestly, I was pleasantly surprised to hear back so quickly — thank you for independently validating the root cause and for adding the stderr trace. I pulled your update and retested commit 145d1649dfb9f7df33eaf86b19522360f855d85c on the affected setup:

• Windows x86-64, Firefox 154, Tailchrome 0.1.13, Bitdefender Total Security 27.0.61.344 with encrypted web scanning enabled
• Built the exact PR head with Go 1.26.5; go test ./... and go vet ./... pass
• Bitdefender injected its protected absolute volume path into SSLKEYLOGFILE
• The new clearing unusable SSLKEYLOGFILE stderr line appeared and reported the expected access denial (machine-specific path redacted)
• The helper continued through initialization to loggedIn=true, stayed alive for the 60-second captured run, and established its proxy/control connections
• Re-registered the same binary directly with Firefox after the captured run (no wrapper); Firefox is the parent process and the helper remains connected
• An end-to-end request through the helper proxy used a different public IP from the direct connection and exited in Miami, Florida through the configured exit node

Confirmed: the logging addition behaves as intended, and the fix remains effective with the real Firefox + Bitdefender injection.

[dantraynor]

@danekurian-git absolutely, thanks for opening the issue and the associated pr, will merge this and should be able to make a new release soon