Stripping package paths would break runtime.Caller and reflect.Type.PkgPath. I don't think there is any reasonable way that we can do it.

I found that too, and it makes me unhappy
@ianlancetaylor

Stripping package paths would break runtime.Caller and reflect.Type.PkgPath. I don't think there is any reasonable way that we can do it.

is it possible to set an argument or something as a choice to switch those on or off for a distributed version?

Stripping the package paths to prevent exploits is security by obscurity.
People can do pattern matching on the instructions to match a given package
just as easily.

Sure, but the current behavior shows personal information like the full URI including Github/Bitbucket username and names of internal packages.

The username part seems like a red herring. It's just the package's import path, no?

I think the point is that the import path can contain confidential information. Not every Go project is open source, some use it to displace C++ in their organization and are surprised when strip has different semantics. Security-sensitive projects strip binaries to protect intellectual property as part of a defense in depth approach.

People concerned about import paths may find the compiler's -trimpath option to be useful.

I don't think there is anything we can actually do here, so I'm going to close this issue. If anybody has a concrete proposal for a change here, please comment or open a new issue. (I don't think that "drop all package path information" can work, as it would break too many libraries.)

@ianlancetaylor
May I ask how to pass the -trimpath to Go toolchain?

@ianlancetaylor
thanks. I thought the -trimpath was a asm flag