Drop the embedded leakless binary that trips antivirus#69
Merged
Conversation
go-rod's launcher imports github.com/ysmood/leakless, which base64/gzip embeds a prebuilt leakless.exe for every target. On Windows that helper is linked straight into kage.exe, and Windows Defender flags its signature and quarantines a fresh scoop install before kage ever runs. kage already launches Chrome with leakless disabled (browser/leakless.go), so the guard was never doing anything, only adding the flagged bytes. This adds an API-compatible stub for the package under third_party/leakless with no embedded binary and points a replace directive at it. The Windows build loses about 1.28 MB of packed executable and no longer carries the payload that antivirus reacts to. Support() returns false, so go-rod skips the leakless path even if a caller re-enabled it.
Add the release-notes and changelog entries for the leakless helper removal (#68), so the docs site and CHANGELOG explain why the Windows build shrank and what the earlier virus warning was.
The replace points leakless at a local directory, so go mod tidy no longer needs the upstream module's checksum. Keeps the tidy CI check green.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Fixes #68. A fresh
scoop install kageon Windows was quarantined by Windows Defender, which flaggedleakless.exe.go installwas unaffected.Why
kage renders pages with go-rod, whose launcher imports leakless, a watchdog that force-kills Chrome if the parent exits. leakless base64/gzip-embeds a prebuilt helper for every platform (
bin_amd64_windows.goand friends), so the Windows helper is linked straight intokage.exe. Defender recognises that helper asTrojan:Win32/Kepavll!rfn.#54 already disabled leakless at runtime (
Leakless(false)), so the helper never runs. But the payload bytes stayed in the binary, and leakless extractsleakless.exeto%TEMP%\leakless-amd64-<ver>\the moment it is used, which is the file the reporter saw flagged.Fix
Add an API-compatible stub for the package under
third_party/leakless(New, Support, LockPort, and the Launcher type's Command/Pid/Err) with no embedded binary, and point areplacedirective at it.Support()returns false, so go-rod skips the leakless path even if a caller re-enabled it.Verification (on a Windows box, native build)
kage.exe:1.28 MBsmaller; the gzip'd payload, theleaklessBinariesmap, andGetLeaklessBinare all gone. Windows Defender full scan: no threats.Trojan:Win32/Kepavll!rfn, confirming those are the bytes that were being detected.kage clone https://example.com: Chrome launches through the stub and the page renders; noleakless.exeis written to temp.go test ./...passes.