#23737 reports that flags generated by pkg-config -libs are being checked against the compiler whitelist, and CGO_CFLAGS_ALLOW, when they should instead by checked against the linker whitelist and CGO_LDFLAGS_ALLOW. There is a CL to fix this: https://golang.org/cl/92755.

The linker whitelist should accept .a files as it already accepts .o, .so, etc., files. There is a CL to fix this: https://golang.org/cl/92855. This is #23739.

Comments on #23672 list these compiler options:

-fno-exceptions
-fno-rtti
-fpermissive

and these linker options:

-Wl,-framework
-Wl,--no-as-needed

#23742 suggests adding the compiler option -fmodules. The clang compiler supports a number of -fmodules options, but it's not clear that they are all safe. In particular -fmodules-cache-path and -fmodules-user-build-path would seem to permit specifying a path that clang will use to read modules, which could perhaps change the compilation mode in various ways.

#23743 suggests adding the linker option -Wl,--no-as-needed. There is a CL for this: https://golang.org/cl/92795.

#23744 suggests adding these compiler options:

-finput-charset=UTF-8
--std=c99
-pedantic-errors

There are many compiler and linker options that may be used with either a single dash or a double dash. We should be similarly lax in the whitelists.

For orthogonality: I forget if the option to add a directory to -framework's search path is already covered or not. I also forget what option that is. (The typical use case that I can think of is /Library/Frameworks, which is where Apple puts app-specific frameworks, and is not searched by default.)

Also is -as-needed safe to use with cgo in the first place? This blog post (which is the first result I can find for "gcc as-needed") says that it's a positional argument, but I'm not sure if cgo guarantees anything about where your flags go on the resultant command lines.

@andlabs It's fine to write

#cgo LDFLAGS: -Wl,--as-needed -loptlib -WL,--no-as-needed

In any case, the topic for this issue should be whether options are safe to use from go get.

When using:

#cgo !windows pkg-config: --static ${SRCDIR}/vendor/libgit2/build/libgit2.pc

compilation fails with the following message:

invalid pkg-config package name: --static

Looking over the code (for go 1.9.4) it appears there aren't any enviroment variables that can be used to whiteslist pkg-config arguments.

@rgburke pkg-config output goes through the same FLAGS_ALLOW variables as other outputs.

However, it appears that pkg-config -libs checks CGO_CFLAGS_ALLOW when it ought to check CGO_LDFLAGS_ALLOW.

We link a large number of C libraries statically in a closed-source project. Up until now we have been doing the following:

#cgo LDFLAGS:/path/to/one/liblibrary1.a
#cgo LDFLAGS:/path/to/two/liblibrary2.a
etc.

This is of course disallowed now. A workaround:

#cgo LDFLAGS:-L/path/to/one -llibrary1
#cgo LDFLAGS:-L/path/to/two -llibrary2

However some of these directories contain dynamic libraries too, which confuses the linker. Another option is to add '/' to the list of allowed "names" in https://go-review.googlesource.com/c/go/+/92855 In particular change on line 91 is:

re(`[a-zA-Z0-9_\/].*\.(o|obj|dll|dylib|so|a)`), // direct linker inputs: x.o or libfoo.so (but not -foo.o or @foo.o)

the latter option fixes our issue but I can't speak to its impact on security.

@mirtchovski there's a patch for that (the issue is that .a was not whitelisted, but other object file formats were)

.a is now whitelisted (after that patch) so 'libsomething.a' will work, but '/path/to/libsomething.a' will not work.

@ianlancetaylor @rgburke I actually ran into the very same problem with --static which lead me down the hole to #23737. --static is rejected because it doesn't appear to be a valid package name before attempting to execute pkg-config, here

Our quick fix internally was to point PKG_CONFIG to a script which simply executed pkg-config --static "$@".

@jeddenlea - Thank you very much! I was trying to find a workaround but didn't think of that.

We hit this with -msse and -msse4.2.

We've hit this with --std=c99

@PassKit Did you solve this problem？

@zcm211 If you're talking about https://github.com/miekg/pkcs11 they removed the -I... linker flag in feb. If you're using a package that uses it then you have to set the environmental variable CGO_LDFLAGS_ALLOW="-I.*"

darwin 64-bit, go1.10.2, I thought .o files were whitelisted for LDFLAGs, but I'm getting:

jaten@jatens-MacBook-Pro ~/go/src/github.com/go-interpreter/chezgo (master) $ make run                           
cd chez_scheme_9.5.1/c; make                                                                                     
make[1]: Nothing to be done for `doit'.                                                                          
go build && ./chezgo                                                                                             
go build github.com/go-interpreter/chezgo: invalid flag in #cgo LDFLAGS: ./chez_scheme_9.5.1/boot/a6osx/kernel.o 
make: *** [run] Error 1                                                                                          
jaten@jatens-MacBook-Pro ~/go/src/github.com/go-interpreter/chezgo (master) $ go version                         
go version go1.10.2 darwin/amd64                                                                                 
jaten@jatens-MacBook-Pro ~/go/src/github.com/go-interpreter/chezgo (master) $  

due to the cgo preamble in https://github.com/go-interpreter/chezgo/blob/master/embed.go#L10

#cgo LDFLAGS:  -liconv -lm -lncurses -L/usr/local/lib ./chez_scheme_9.5.1/boot/a6osx/kernel.o

@glycerine According to https://go-review.googlesource.com/c/go/+/94676 they are. Maybe try a full path instead of a relative one?

Good catch @AlexRouSg, the accept regex is buggy as you point out;

re(`[a-zA-Z0-9_/].*\.(a|o|obj|dll|dylib|so)`), // direct linker inputs: x.o or libfoo.so (but not -foo.o or @foo.o)

src/cmd/go/internal/work/security.go#121 should allow .o files to start with a . to support relative paths.

After all, I can't predict the users' GOPATH, or how nested the location of that file will become, so setting an absolute path isn't practical.

Is the .o file in the source directory? If so, referring to the source directory is what ${SRCDIR} was provided for. (I forget specifically why this was introduced, but it was not because of this issue.)

@andlabs Even if there are klunky workarounds, relative paths should be linkable, and that is clearly a bug.

It is, except IIRC there is no guarantee that the link would be relative TO the source directory (it could very well be in $WORK, and then your relative path breaks again)... Again, I've forgotten the history; someone else will need to explain.

gtk4 uses -mfpmath=sse

@ianlancetaylor Instead of having separate whitelists for cflags and ldflags, should there just be one list? gcc/llvm doesn't seem to care that you mix ldflags into cflags and vice versa. And it seems sometimes C devs do that causing issues like #25493 or #23749 (comment)

Ah, I see we have a ticket already, so let me mention "-D_THREAD_SAFE" from protobuf as documented in #25493

Change https://golang.org/cl/115415 mentions this issue: cmd/go: accept more safe CFLAGS/LDFLAGS

Change https://golang.org/cl/115435 mentions this issue: [release-branch.go1.10] cmd/go: accept more safe CFLAGS/LDFLAGS

Change https://golang.org/cl/115436 mentions this issue: [release-branch.go1.9] cmd/go: accept more safe CFLAGS/LDFLAGS

Hey Guys,
Why is this issue closed when we still cannot build bimg with the latest version of Go as of 9/4/2018 ?
Please see issue: h2non/bimg#230
We cannot build anything that imports bimg since Go 1.10 and the problem still persist in Go 1.11
The error message we get is this:

# go build
go build gopkg.in/h2non/bimg.v1: invalid flag in pkg-config --libs: -Wl,--export-dynamic

Any advise?

EDIT:
I created a new issue: #27496

I believe this whitelist is responsible for the following: alexflint/gallium#63

@alexflint This issue is closed, please create a new one