You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
garble/testdata/script/basic.txtar

77 lines
2.4 KiB
Plaintext

# Check that the simplest use of garble works. Note the lack of a module or GOGARBLE.
exec garble build -o=main$exe garble_main.go
exec ./main
cmp stderr main.stderr
# Ensure that -w and -s worked.
[!windows] [exec:readelf] exec readelf --section-headers main$exe
[!windows] [exec:readelf] ! stdout 'debug_info'
[!windows] [exec:readelf] ! stdout '\.symtab'
# The buildid needs to be missing from the binary. Otherwise, we leak
# information unnecessarily, which is made worse by how we use part of said
# buildid to obfuscate the main package.
[!windows] [exec:readelf] ! stdout 'buildid'
go tool buildid main$exe
! stdout .
# The build version needs to be missing too.
go version main$exe
stdout 'unknown'
! stdout 'go1'
! stdout 'devel'
! stdout $gofullversion
# The binary can't contain the version string either.
! binsubstr main$exe ${WORK} 'garble_main.go' 'globalVar' 'globalFunc' 'garble' $gofullversion
5 years ago
[short] stop # checking that the build is reproducible is slow
# Check that we fail if the user used "go build -toolexec garble" instead of "garble build"
! go build -toolexec=garble -o=main$exe garble_main.go
stderr '^did you run.*instead of "garble \[command\]"'
! go build -toolexec='garble toolexec' -o=main$exe garble_main.go
stderr 'cannot open shared file.*did you run.*instead of "garble \[command\]"'
# Also check that the binary is reproducible.
initial support for build caching (#142) As per the discussion in https://github.com/golang/go/issues/41145, it turns out that we don't need special support for build caching in -toolexec. We can simply modify the behavior of "[...]/compile -V=full" and "[...]/link -V=full" so that they include garble's own version and options in the printed build ID. The part of the build ID that matters is the last, since it's the "content ID" which is used to work out whether there is a need to redo the action (build) or not. Since cmd/go parses the last word in the output as "buildID=...", we simply add "+garble buildID=_/_/_/${hash}". The slashes let us imitate a full binary build ID, but we assume that the other components such as the action ID are not necessary, since the only reader here is cmd/go and it only consumes the content ID. The reported content ID includes the tool's original content ID, garble's own content ID from the built binary, and the garble options which modify how we obfuscate code. If any of the three changes, we should use a different build cache key. GOPRIVATE also affects caching, since a different GOPRIVATE value means that we might have to garble a different set of packages. Include tests, which mainly check that 'garble build -v' prints package lines when we expect to always need to rebuild packages, and that it prints nothing when we should be reusing the build cache even when the built binary is missing. After this change, 'go test' on Go 1.15.2 stabilizes at about 8s on my machine, whereas it used to be at around 25s before.
4 years ago
# No packages should be rebuilt either, thanks to the build cache.
cp main$exe main_old$exe
rm main$exe
exec garble build -v -o=main$exe garble_main.go
initial support for build caching (#142) As per the discussion in https://github.com/golang/go/issues/41145, it turns out that we don't need special support for build caching in -toolexec. We can simply modify the behavior of "[...]/compile -V=full" and "[...]/link -V=full" so that they include garble's own version and options in the printed build ID. The part of the build ID that matters is the last, since it's the "content ID" which is used to work out whether there is a need to redo the action (build) or not. Since cmd/go parses the last word in the output as "buildID=...", we simply add "+garble buildID=_/_/_/${hash}". The slashes let us imitate a full binary build ID, but we assume that the other components such as the action ID are not necessary, since the only reader here is cmd/go and it only consumes the content ID. The reported content ID includes the tool's original content ID, garble's own content ID from the built binary, and the garble options which modify how we obfuscate code. If any of the three changes, we should use a different build cache key. GOPRIVATE also affects caching, since a different GOPRIVATE value means that we might have to garble a different set of packages. Include tests, which mainly check that 'garble build -v' prints package lines when we expect to always need to rebuild packages, and that it prints nothing when we should be reusing the build cache even when the built binary is missing. After this change, 'go test' on Go 1.15.2 stabilizes at about 8s on my machine, whereas it used to be at around 25s before.
4 years ago
! stderr .
bincmp main$exe main_old$exe
# Check that the program works as expected without garble. No need to verify
# this when we run with -short.
go build -o=main$exe garble_main.go
exec ./main
cmp stderr main.stderr
# The default build includes DWARF and the symbol table.
[!windows] [exec:readelf] exec readelf --section-headers main$exe
[!windows] [exec:readelf] stdout 'debug_info'
[!windows] [exec:readelf] stdout '\.symtab'
# The default build includes full non-trimmed paths, as well as our names.
# Only check $WORK on non-windows, because it's difficult to do it there.
binsubstr main$exe 'garble_main.go' 'globalVar' 'globalFunc' $gofullversion
[!windows] binsubstr main$exe ${WORK}
initial support for build caching (#142) As per the discussion in https://github.com/golang/go/issues/41145, it turns out that we don't need special support for build caching in -toolexec. We can simply modify the behavior of "[...]/compile -V=full" and "[...]/link -V=full" so that they include garble's own version and options in the printed build ID. The part of the build ID that matters is the last, since it's the "content ID" which is used to work out whether there is a need to redo the action (build) or not. Since cmd/go parses the last word in the output as "buildID=...", we simply add "+garble buildID=_/_/_/${hash}". The slashes let us imitate a full binary build ID, but we assume that the other components such as the action ID are not necessary, since the only reader here is cmd/go and it only consumes the content ID. The reported content ID includes the tool's original content ID, garble's own content ID from the built binary, and the garble options which modify how we obfuscate code. If any of the three changes, we should use a different build cache key. GOPRIVATE also affects caching, since a different GOPRIVATE value means that we might have to garble a different set of packages. Include tests, which mainly check that 'garble build -v' prints package lines when we expect to always need to rebuild packages, and that it prints nothing when we should be reusing the build cache even when the built binary is missing. After this change, 'go test' on Go 1.15.2 stabilizes at about 8s on my machine, whereas it used to be at around 25s before.
4 years ago
-- go.mod --
module test/mainfoo
go 1.20
-- garble_main.go --
5 years ago
package main
var globalVar = "global value"
func globalFunc() { println("global func body") }
func main() {
println(globalVar)
globalFunc()
}
-- main.stderr --
global value
global func body