go build 时如何才能不携带 BuildInfo 信息？

[lysShub]

直接二进制查看 go 编译的二进制文件，会发现带有 import 包信息，挺敏感的

dep	github.com/cespare/xxhash/v2	v2.3.0	h1:UL815xU9SqsFlibzuggzjXhog7bL6oX9BbNZnL2UFvs=
dep	github.com/google/uuid	v1.6.0	h1:NIvaJDMOsjHA8n1jAhLSgzrAzy1Hgr+hNrb57e+94F0=
dep	google.golang.org/grpc	v1.70.0	h1:pWFv03aZoHzlRKHWicjsZytKAiYCtNS0dHbXnIdq7jQ=
dep	google.golang.org/protobuf	v1.36.2	h1:R8FeyR1/eLmkutZOM5CWghmo5itiG9z0ktFlTVLuTmU=
dep	github.com/golang-jwt/jwt/v5	v5.2.1	h1:OuVbFODueb089Lh128TAcimifWaLhJwVflnrgM17wHk=

但查了下没发现去除的办法

[lysShub]

https://github.com/golang/go/issues/50501 直接关了？

[kk2syc]

翻 go 编译器源码，找到关于这块信息的部分去除，diy 一个编译器就行了。

[Dreax]

https://github.com/burrowers/garble garble 可以去掉但是可能有副作用

[liuidetmks]

同好奇，c 语言也有同样问题

[realpg]

不用开源的 自己撸就完了

[rekulas]

有个邪教方法 把三方包下载到本地自己改成随机名字 import 如何

[conn457567]

这也算敏感信息？安全过度了吧。按这种标准大部分语言的编译打包工具全不用玩了，自己发明一种？

[yolee599]

@liuidetmks #4 用了 10 年 c 语言，我也好奇你说的这个，c 语言哪里有 build info ？

[seers]

如果是在字符串区就直接删了呗，应该不影响功能，注意对齐就行

[CHTuring]

@conn457567 #7 「自主研发」的含金量

[xtreme1]

@yolee599 8# 符号表吧可能...

[bruce0]

@CHTuring 遥遥领先

[bv]

SBOM 清单，在安全与合规审计，软件溯源时还是很有用的，建议留着。
要说怎么去除，我也不知道

[NessajCN]

你可以自己把库都 fork 下来改个包名 import

[owen800q]

@bv 主要是上面的意思是不想让某部门知道是用 Go 写的

[bv]

@owen800q buildinfo 留着是利大于弊，藏着掖着弄的好像有什么见不得人的地方一样（公开依赖项不利于宣称自主研发吗？ ）。

即便把 buildinfo 去掉，只需要简单的命令 strings ./xxx 就可以看到内部的依赖软件路径。

[skiy]

加个壳行不？

[qieqie]

strip --remove-section=.go.buildinfo ./bin
可以删一些 section ，但想让人看不出来是 go 写的基本没可能

[ExplodingFKL]

直接用 upx 压缩,再剔除二进制文件的 upx 的字段,这样至少静态分析没法判断是 go 写的

[lysShub]

@kk2syc 我也是这个思路，是在 cmd/go/internal/load.setBuildInfo

[bugfan]

编译时候，加参数把符号表去掉就行了

[Sendya]

是不是加 `-ldflags="-w -s -extldflags=-static"` 可以去除？ 我还真没直接看过二进制里的这些信息

[Sendya]

#22 无效，还是有的

[gullitintanni]

@yolee599 #8 比如 gcc 会在 .comment 段记录版本号，而且这个信息默认不会被 strip 掉（ strip --strip-unneeded ）

@bv #16 有的时候还是挺有用的，比如某些国内 VPS 厂商会用脚本自动化扫描机器上的二进制文件，利用这些信息能初步检测你有没有在搞不合规的事（比如搭梯子中转）

[bigtear]

传统逆向对抗的加壳加反调试呗，VMP 之类的