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.

Sign up for GitHub

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

Jump to bottom

error on parse github.com/go-openapi #858

Closed
kakuilan opened this issue Jun 11, 2024 · 4 comments
Closed

error on parse github.com/go-openapi #858

kakuilan opened this issue Jun 11, 2024 · 4 comments
Labels
bug Something isn't working reflection

Comments

@kakuilan
Copy link

What version of Garble and Go are you using?

$ garble version
mvdan.cc/garble v0.12.1

Build settings:
      -buildmode exe
       -compiler gc
  DefaultGODEBUG httplaxcontentlength=1,httpmuxgo121=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1
     CGO_ENABLED 1
          GOARCH amd64
            GOOS linux
         GOAMD64 v1

$ go version
go version go1.22.0 linux/amd64

	github.com/go-openapi/jsonpointer v0.21.0 // indirect
	github.com/go-openapi/jsonreference v0.21.0 // indirect
	github.com/go-openapi/spec v0.21.0 // indirect
	github.com/go-openapi/swag v0.23.0 // indirect

What environment are you running Garble on?

go env Output
$ go env
GO111MODULE='on'
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/vagrant/.cache/go-build'
GOENV='/home/vagrant/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/var/www/_go-linux/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/var/www/_go-linux'
GOPRIVATE=''
GOPROXY='https://goproxy.cn,https://goproxy.io,https://proxy.golang.com.cn,direct'
GOROOT='/usr/lib/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/lib/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.0'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
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-build130710698=/tmp/go-build -gno-record-gcc-switches'

What did you do?

CGO_ENABLED=1 GOOS=linux GOARCH=amd64 garble -literals -tiny -seed=random build -v -a

What did you expect to see?

build successful

What did you see instead?

github.com/go-openapi/swag
go/version
github.com/prometheus/client_golang/prometheus/internal
github.com/prometheus/common/expfmt
internal/types/errors
github.com/go-openapi/jsonpointer
go/types
github.com/go-openapi/jsonreference
github.com/go-openapi/spec
github.com/prometheus/client_golang/prometheus
# github.com/go-openapi/spec
:3: cannot use struct{GeBWmay []string; TIAIXBK bool}{…} (value of type struct{GeBWmay []string; TIAIXBK bool}) as struct{List []string; Pad bool} value in assignment
exit status 2
@jerome-laforge
Copy link

jerome-laforge commented Jul 4, 2024 •
edited
Loading

I have the same kind of error:

github.com/go-openapi/spec
# github.com/go-openapi/spec
keucNQGuiSH_.go:3: cannot use struct{D31brC6 []string; JCNB1W0W3 bool}{…} (value of type struct{D31brC6 []string; JCNB1W0W3 bool}) as struct{List []string; Pad bool} value in assignment
D6hjXDPQG.go:3: cannot use struct{D31brC6 []string; JCNB1W0W3 bool}{…} (value of type struct{D31brC6 []string; JCNB1W0W3 bool}) as struct{List []string; Pad bool} value in assignment
exit status 2

go version
go version go1.22.5 linux/amd64

garble version
mvdan.cc/garble v0.12.1

Build settings:
      -buildmode exe
       -compiler gc
  DefaultGODEBUG httplaxcontentlength=1,httpmuxgo121=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1
     CGO_ENABLED 1
          GOARCH amd64
            GOOS linux
         GOAMD64 v1

@jerome-laforge
Copy link

It seems duplicate with #690

@Sreejit7
Copy link

hey @jerome-laforge has it resolved for you? I'm facing the same issue still

@jerome-laforge
Copy link

jerome-laforge commented Sep 6, 2024 •
edited
Loading

hey @jerome-laforge has it resolved for you? I'm facing the same issue still

No, I have always the same pb with v0.13.0

garble version

mvdan.cc/garble v0.13.0ble  (command)

Build settings:
      -buildmode exe
       -compiler gc
  DefaultGODEBUG asynctimerchan=1,gotypesalias=0,httpservecontentkeepheaders=1,tls3des=1,tlskyber=0,x509keypairleaf=0,x509negativeserial=1
     CGO_ENABLED 1
          GOARCH amd64
            GOOS linux
         GOAMD64 v1

@lu4p lu4p added reflection bug Something isn't working labels Oct 28, 2024
@lu4p lu4p mentioned this issue Oct 28, 2024
Closed
lu4p added a commit that referenced this issue Nov 26, 2024
@lu4p
revised reflection handling
e982a61 
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
@lu4p
revised reflection handling
7eb700c 
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
@lu4p
revised reflection handling
07aa888 
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
@lu4p
revised reflection handling
a4dc374 
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
@lu4p
revised reflection handling
18fcf7c 
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
@lu4p
revised reflection handling
6ad5929 
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
@lu4p
revised reflection handling
f7e59c3 
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
@lu4p
revised reflection handling
e31525c 
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
@lu4p
obfuscate all names used in reflection
70d7267 
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
@lu4p
obfuscate all names used in reflection
926f3de 
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
Assignees
No one assigned
Labels
bug Something isn't working reflection
Milestone
No milestone
Development

No branches or pull requests
4 participants
@kakuilan @jerome-laforge @lu4p @Sreejit7