Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Errors while working with anonymous structs #842

Closed
linted opened this issue Mar 28, 2024 · 5 comments
Closed

Errors while working with anonymous structs #842

linted opened this issue Mar 28, 2024 · 5 comments
Labels
bug Something isn't working reflection

Comments

@linted
Copy link

linted commented Mar 28, 2024

What version of Garble and Go are you using?

$ garble version
mvdan.cc/garble v0.11.0

Build settings:
      -buildmode exe
       -compiler gc
     CGO_ENABLED 1
          GOARCH amd64
            GOOS linux
         GOAMD64 v1
$ go version
go version go1.21.6 linux/amd64

What environment are you running Garble on?

go env Output
$ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.6'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD=''
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1325620773=/tmp/go-build -g

What did you do?

# git clone https://github.com/libp2p/go-libp2p.git
# cd go-libp2p/examples/chat
# garble build

What did you expect to see?

garble to be able to build the examples from this popular library.

What did you see instead?

/go-libp2p/examples/chat# garble build
# github.com/libp2p/go-libp2p/p2p/protocol/holepunch
Kc_daTySOcx.go:1: cannot use make(map[peer.ID]struct{bBnKb2bxZ8V4 int; nnXie6 time.FVJzTyFdo}) (value of type map[RFoWLhGaEDb.ID]struct{bBnKb2bxZ8V4 int; nnXie6 gvdD72.FVJzTyFdo}) as map[RFoWLhGaEDb.ID]struct{counter int; last gvdD72.FVJzTyFdo} value in struct literal
HK5CVSzxh4D4.go:1: cannot use make(map[peer.ID]struct{bBnKb2bxZ8V4 int; nnXie6 time.FVJzTyFdo}) (value of type map[RFoWLhGaEDb.ID]struct{bBnKb2bxZ8V4 int; nnXie6 gvdD72.FVJzTyFdo}) as map[RFoWLhGaEDb.ID]struct{counter int; last gvdD72.FVJzTyFdo} value in struct literal
OmJ69f.go:1: cannot use make(map[peer.ID]struct{bBnKb2bxZ8V4 int; nnXie6 time.FVJzTyFdo}) (value of type map[RFoWLhGaEDb.ID]struct{bBnKb2bxZ8V4 int; nnXie6 gvdD72.FVJzTyFdo}) as map[RFoWLhGaEDb.ID]struct{counter int; last gvdD72.FVJzTyFdo} value in struct literal
exit status 2
exit status 1
@mvdan
Copy link
Member

mvdan commented Mar 31, 2024

v0.11.0 is pretty old. Have you tried with the latest stable version and master?

@mvdan mvdan added the needs info Requires extra information to be solved label Mar 31, 2024
@linted
Copy link
Author

linted commented Apr 2, 2024

You're right, I didn't notice I was using an old version. This is what I get after updating, which appears to be the same error.

# garble version
mvdan.cc/garble v0.12.1

Build settings:
      -buildmode exe
       -compiler gc
     CGO_ENABLED 1
          GOARCH amd64
            GOOS linux
         GOAMD64 v1
# garble build
# github.com/libp2p/go-libp2p/p2p/protocol/holepunch
HtiNa9cD6f.go:1: cannot use make(map[peer.ID]struct{g7OR7KZxrxF int; gmni7cw time.Elg7daBRDEu}) (value of type map[XaEgkY.ID]struct{g7OR7KZxrxF int; gmni7cw zGPEB0e1.Elg7daBRDEu}) as map[XaEgkY.ID]struct{counter int; last zGPEB0e1.Elg7daBRDEu} value in struct literal
cgXBPv5kb7aG.go:1: cannot use make(map[peer.ID]struct{g7OR7KZxrxF int; gmni7cw time.Elg7daBRDEu}) (value of type map[XaEgkY.ID]struct{g7OR7KZxrxF int; gmni7cw zGPEB0e1.Elg7daBRDEu}) as map[XaEgkY.ID]struct{counter int; last zGPEB0e1.Elg7daBRDEu} value in struct literal
whUWrW.go:1: cannot use make(map[peer.ID]struct{g7OR7KZxrxF int; gmni7cw time.Elg7daBRDEu}) (value of type map[XaEgkY.ID]struct{g7OR7KZxrxF int; gmni7cw zGPEB0e1.Elg7daBRDEu}) as map[XaEgkY.ID]struct{counter int; last zGPEB0e1.Elg7daBRDEu} value in struct literal
exit status 2
exit status 1

@mvdan mvdan removed the needs info Requires extra information to be solved label Apr 27, 2024
@lu4p lu4p added reflection bug Something isn't working labels Oct 28, 2024
@interbattles
Copy link

:( i have the exact same issue on the same library

@interbattles
Copy link

@lu4p

I was gonna make a pull request myself but someone got to it first 😁

p.s. Never knew until now that go doesn't pull from master (afaik ?) so after a bit of confused googling after upgrading my packages I got this: go get -u (Maybe required, probably needs to refetch the whole libp2p repo?) then go get github.com/libp2p/go-libp2p/p2p/protocol/holepunch@master

maybe this is a bandaid solution for garble's end, but anonymous structs are bad practice imo

@lu4p
Copy link
Member

lu4p commented Nov 24, 2024

@interbattles after #889 we can handle bad practices

lu4p added a commit that referenced this issue Nov 26, 2024
Instead of excluding specific names from obfuscation "all" names are now  obfuscated.

For reflected names, a mapping to the original name is injected in internal/abi to resolve them correctly.

Fixes #884, #799, #817, #881, #858, #843, #842

Closes #406
lu4p added a commit that referenced this issue Nov 26, 2024
Instead of excluding specific names from obfuscation "all" names are now  obfuscated.

For reflected names, a mapping to the original name is injected in internal/abi to resolve them correctly.

Fixes #884, #799, #817, #881, #858, #843, #842

Closes #406
lu4p added a commit that referenced this issue Nov 27, 2024
Instead of excluding specific names from obfuscation "all" names are now  obfuscated.

For reflected names, a mapping to the original name is injected in internal/abi to resolve them correctly.

Fixes #884, #799, #817, #881, #858, #843, #842

Closes #406
lu4p added a commit that referenced this issue Nov 27, 2024
Instead of excluding specific names from obfuscation "all" names are now  obfuscated.

For reflected names, a mapping to the original name is injected in internal/abi to resolve them correctly.

Fixes #884, #799, #817, #881, #858, #843, #842

Closes #406
lu4p added a commit that referenced this issue Nov 27, 2024
Instead of excluding specific names from obfuscation "all" names are now  obfuscated.

For reflected names, a mapping to the original name is injected in internal/abi to resolve them correctly.

Fixes #884, #799, #817, #881, #858, #843, #842

Closes #406
lu4p added a commit that referenced this issue Nov 27, 2024
Instead of excluding specific names from obfuscation "all" names are now  obfuscated.

For reflected names, a mapping to the original name is injected in internal/abi to resolve them correctly.

Fixes #884, #799, #817, #881, #858, #843, #842

Closes #406
lu4p added a commit that referenced this issue Nov 27, 2024
Instead of excluding specific names from obfuscation "all" names are now  obfuscated.

For reflected names, a mapping to the original name is injected in internal/abi to resolve them correctly.

Fixes #884, #799, #817, #881, #858, #843, #842

Closes #406
lu4p added a commit that referenced this issue Nov 27, 2024
Instead of excluding specific names from obfuscation "all" names are now  obfuscated.

For reflected names, a mapping to the original name is injected in internal/abi to resolve them correctly.

Fixes #884, #799, #817, #881, #858, #843, #842

Closes #406
lu4p added a commit that referenced this issue Nov 27, 2024
Go code can retrieve and use field and method names via the `reflect` package.
For that reason, historically we did not obfuscate names of fields and methods
underneath types that we detected as used for reflection, via e.g. `reflect.TypeOf`.

However, that caused a number of issues. Since we obfuscate and build one package
at a time, we could only detect when types were used for reflection in their own package
or in upstream packages. Use of reflection in downstream packages would be detected
too late, causing one package to obfuscate the names and the other not to, leading to a build failure.

A different approach is implemented here. All names are obfuscated now, but we collect
those types used for reflection, and at the end of a build in `package main`,
we inject a function into the runtime's `internal/abi` package to reverse the obfuscation
for those names which can be used for reflection.

This does mean that the obfuscation for these names is very weak, as the binary
contains a one-to-one mapping to their original names, but they cannot be obfuscated
without breaking too many Go packages out in the wild. There is also some amount
of overhead in `internal/abi` due to this, but we aim to make the overhead insignificant.

Fixes #884, #799, #817, #881, #858, #843, #842

Closes #406
lu4p added a commit that referenced this issue Nov 27, 2024
Go code can retrieve and use field and method names via the `reflect` package.
For that reason, historically we did not obfuscate names of fields and methods
underneath types that we detected as used for reflection, via e.g. `reflect.TypeOf`.

However, that caused a number of issues. Since we obfuscate and build one package
at a time, we could only detect when types were used for reflection in their own package
or in upstream packages. Use of reflection in downstream packages would be detected
too late, causing one package to obfuscate the names and the other not to, leading to a build failure.

A different approach is implemented here. All names are obfuscated now, but we collect
those types used for reflection, and at the end of a build in `package main`,
we inject a function into the runtime's `internal/abi` package to reverse the obfuscation
for those names which can be used for reflection.

This does mean that the obfuscation for these names is very weak, as the binary
contains a one-to-one mapping to their original names, but they cannot be obfuscated
without breaking too many Go packages out in the wild. There is also some amount
of overhead in `internal/abi` due to this, but we aim to make the overhead insignificant.

Fixes #884, #799, #817, #881, #858, #843, #842

Closes #406
@lu4p lu4p closed this as completed Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working reflection
Development

No branches or pull requests

4 participants