New release?

[Alexander Orlovsky]

Can you create a new release, please? The latest one doesn't work with new google proto options like debug_redact, however grpcurl installed from main branch have no such issue.

[gfrankliu]

The security scanner also reports lots of vulnerabilities in the released binaries since they were compiled using the old vulnerable go compiler.

[Scott Blum]

It's in the works!

[gfrankliu]

Thanks for the release!

I noticed one difference in the binary release. 1.8.7 was probably built was cgo disabled, but 1.8.8 has C lib dependencies:

I tried linux_x86_64.tar.gz, for 1.8.7

ldd grpcurl
	not a dynamic executable

and it works fine in the alpine docker image

for 1.8.8

Error loading shared library libresolv.so.2: No such file or directory (needed by ./grpcurl.new)
Error relocating ./grpcurl.new: __res_search: symbol not found

It works on Debian:

$ ldd grpcurl
	linux-vdso.so.1 (0x00007ffd2250a000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f7bd5383000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7bd537e000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7bd519c000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f7bd53ad000)

Can the binary releases be compiled with cgo off, so they can have best compatibility?

[gfrankliu]

I checked the "grcpurl" binary inside the container image https://hub.docker.com/r/fullstorydev/grpcurl/tags and see it doesn't have C dependencies.
This is confirmed by this line in the Dockerfile.
Maybe we should add "CGO_ENABLED=0" in the Makefile so that future releases won't have this problem, eg:

dev_build_version=$(shell git describe --tags --always --dirty)

export PATH := $(shell pwd)/.tmp/protoc/bin:$(PATH)

export PROTOC_VERSION := 22.0

export CGO_ENABLED := 0

...

[Scott Blum]

Strange... I wonder if on 1.8.7 we cross compiled the binaries from OSX (which intrinsically disables CGO)? I think @gpassini built the linux binaries on linux this time around.