Which can be helpful when debugging assembly build errors
such as the one from #948.
I could not get an obfuscated binary to ever print or show its
assembly positions or filenames, so this has no test.
* reflect_abi_patch.go was added into reflect.go
* shared.go was renamed into cache_shared.go and package caching was moved to cache_pkg.go
* transformer methods in main.go are moved to transformer.go
As spotted by scripts/check-third-party.sh, it's possible to import
the testing package without using `go test`, so our previous solution
to only load testing/synctest when running `go test` was not enough.
Add a regression test via stdimporter in gogarble.txtar.
The behavior is the same, but now we track the dependency in go.mod
via `go get -tool`, which is a better approach.
While here, make a package loading error slightly clearer.
While strictly speaking it would be okay to leave Go 1.24 support
in place for the time being, we are behind on a few tasks at the moment
so it's best to keep the setup at master simpler for the next release.
Go 1.25 already came out two weeks ago, and it seems to have been
a fairly smooth release, so I don't suspect any end users will have
trouble upgrading to it.
Note that two changes were necessary for garble to work on Go 1.25.0.
First, we stop deduplicating runtimeAndLinknamed with runtimeAndDeps.
Otherwise, for GOOS=windows, internal/runtime/cgroup would be missing
as it is a //go:linkname target from runtime on all platforms,
but it is not transitively imported from runtime on GOOS=windows.
Second, the testing/synctest package is now part of std,
and it is a //go:linkname target from the testing package
but not a transitive import from it. Teach appendListedPackages that,
when loading all packages for a `go test` run, it should load
the new testing/synctest package too.
Fixes#968.
Due to unsafe not being a real dependency, type checking during control-flow obfuscation was performed incorrectly.
This is fixed by excluding unsafe from the dependency checks.
Fixes#903
Some programs which could automatically reverse string literals obfuscated with `-literals` exist.
They currently work by emulating the string literal decryption functions we insert.
We prevent this naive emulation from succeeding by making the decryption functions dependent on global state.
This can still be broken with enough effort, we are curious which approach reverse-engineers come up with next, we certainly still have some ideas to make this harder.
Fixes#926
---------
Co-authored-by: Paul Scheduikat <lu4p@pm.me>
I forgot to update the original Go template away from `go version`.
Note that `go env` already tells us what we need via e.g. GOVERSION,
so we can avoid asking for `go version` separately.
The way computePkgCache caches per-package results in GARBLE_CACHE,
under normal circumstances where a user isn't deleting GARBLE_CACHE
we will only load gob files for direct imports, not indirect ones.
Hence, loading a package's gob file twice is not happening normally.
And the way we use go/types, we don't need to set Config.GoVersion.
Some Go version managers like github.com/voidint/g use GOROOT symlinks,
which silently broke the way we patch the linker via go build -overlay.
Reproduced the original crash via the following testscript:
env GARBLE_CACHE=${WORK}/garble-cache
symlink goroot -> /usr/lib/go
env GOROOT=${WORK}/goroot
exec garble run main.go
-- main.go --
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
We don't commit this testscript given how it's an expensive test
and for a relatively rare edge case whose fix is now well documented.
Moreover, as GOTOOLCHAIN is now available, I expect version managers
for Go to fade away with time.
While here, remove a debugging 'exec cat' from a testscript.
Fixes#915.
Our ISSUE_TEMPLATE.md helpfully stopped working without any warning.
I only noticed as we started getting low-quality bug reports.
This YAML borrows a bit from Go's own bug report template,
much like we had done previously with our markdown template.
Or any other package which uses a //go:linkname to the runtime names
"lastmoduledatap" or "moduledataverify1". These are used by sonic
to inject function headers to the runtime, which does not work
as garble patches the runtime as part of obfuscation.
The way it alters the magic number in function headers breaks this.
Add a summary of this as a comment too.
Fixes#898.
When obfuscating a main package whose Go files all import "C",
the first Go file in CompiledGoFiles ends up being _cgo_gotypes.go.
We cannot add our code from reflect_abi_code.go there,
as it leads to the following error about its _trieNode type:
typecheck error: $WORK/b001/_cgo_gotypes.go:185:10: cannot define new methods on non-local type _trieNode
Avoid patching any _cgo_*.go file with our reflect code,
as all of those files are special glue code for cgo.
While here, tweak reflectMainPrePatch to return a string
for consistency with abiNamePatch.
Fixes#916.
Seems to happen when the main package only has Go files importing "C",
meaning that it has zero "pure Go" files.
To avoid needing two main package Go builds for cgo.txtar,
switch our main package to this scenario as it seems more interesting.
While here, add a test case for a Go callback function taking a C param
as that is relatively common and we had no coverage for it.
This only reproduces the bug; the fix is coming separately.
For #916.
Before Go 1.24, `go build` only stamped module versions for modules
resolved via GOPROXY, as the local module only had VCS information.
For that reason, we manually built a pseudo-version from the VCS
timestamp and revision stamped for local builds.
Go 1.24 started stamping the main module with a module version
derived from the local VCS information, much like we already did.
For example, comparing a clean build before this change
against a build with this uncommitted change:
$ go install
$ garble version
mvdan.cc/garble v0.14.3-0.20250413182748-e97968ccae46
[...]
$ git stash pop
$ go install
$ garble version
mvdan.cc/garble v0.14.3-0.20250413182748-e97968ccae46+dirty
[...]
The only user-visible change is that local builds with any
uncommitted changes now get a `+dirty` suffix, but that's probably
a good thing for the majority of users, and provides a useful hint
in case a user forgot about local changes.
The test logic to inject VCS information via an env var
and see that the resulting pseudo-version is what we expect can go too,
as that was testing our own main module version logic.
We now rely on `go build` to do the right thing, so don't test that.
When creating a new debugdir directory, add a sentinel .garble-debugdir
file at its root so that we can later know that we created it
and the user is very unlikely to have left important data there.
When emptying an existing debugdir directory, only do so if it has
that sentinel file, for added safety.
Fixes#932.
On CI we test on go1.23.x and go1.24.x, so if we always upgrade
to the latest go1.24.x, that will cause garble to complain
when running on go1.23.x:
garble was built with "go1.23.7" and can't be used with the newer "go1.24.1"
Moreover, the test hard-coded go1.24.1, which is currently the latest
go1.24.x but will not be for long, so this test was brittle.
We call `go list` to collect information about all the packages
to obfuscate and build, which is crucial to be able to perform
obfuscation of names used across packages.
However, when GOTOOLCHAIN causes a toolchain upgrade,
we must ensure that we use the upgraded Go tool;
otherwise we are mixing information from different toolchain versions.
Fixes#934.
When we build the patched cmd/link binary for use by garble,
we perform this build in a temporary directory so that the Go module
from the user does not get in the way.
When the user module made us upgrade the toolchain per GOTOOLCHAIN,
leaving that module's directory stops upgrading the toolchain,
so we patch a newer toolchain and build it with an older toolchain.
This is largely harmless, but it makes the newer toolchain think
it is actually an older toolchain, which leads to those pesky
"linker object header mismatch" version errors.
Updates #934.
The diffstat for go_std_tables.go shows that we were missing
more than two dozen new intrinsic functions from Go 1.24,
which could lead to the intrinsification done by the toolchain
to no longer work and leave programs with slower generic functions.
debugdir.txtar also needed tweaking as runtime/map.go is gone
starting in Go 1.24.
Finally, modinfo.txtar needed tweaking since Go 1.24 started stamping
Go binaries with VCS-derived module versions, so we no longer end up
with empty "(devel)" versions.
We only did this for Container in the type switch, but not for Struct.
The added test case panics otherwise.
Just like in the previous case, we still don't need to recurse
into type parameters for fieldToStruct to be filled correctly.
Fixes#899
