Well, I do think Binary-only packages are very important for some security case, such as authentication algorithm in a private enterprise。
在 2018年10月19日星期五 UTC+8上午1:16:43，Russ Cox写道： > > The go command supports "binary-only packages", in which > the compiled .a file is installed in GOROOT/pkg or GOPATH/pkg > but the corresponding source code is only a stub with relevant > imports (for linking), a special comment marking it as a binary-only > package, and perhaps documentation for exported API. > > While the go command will use these packages if they exist in > GOROOT or GOPATH, 'go get' will not download them: 'go get' > is intentionally only about source code distribution. > > Furthermore, binary-only packages only work when the build is > using the exact versions of whatever imported packages are > needed by the binary-only package. If there were any important > differences in a dependency between compilation and linking, > the binary-only portion might have stale information about details > of the imported package, such as type sizes, struct field offsets, > inlined function bodies, escape analysis decisions, and so on, > leading to silent memory corruption at runtime. > > Binary-only packages also only work when the build is using the > exact version of the Go toolchain that was used for compilation. > This is at least enforced at link time, with the effect that if your > binary-only package only imports the standard library and you don't > use any special compilation flags, then the toolchain version check > suffices to avoid the silent memory corruption problem described in > the previous package. But if your package imports any non-standard > package for which that the eventual user might try to combine with > a different version, you're in trouble again. > > Compiled Go programs also contain much richer amounts of runtime > information than compiled C programs, so that for example all the > details of type declarations, including struct definitions, are in the > compiled code, along with file names and line numbers for the compiled > code, and increasingly good debug information that was impossible to > turn off until very recently. Overall, a binary-only package obscures very > little. > > In short, binary-only packages: > > - have never been supported by 'go get', > so you've had to go out of your way to use them, > - aren't even guaranteed to work when you do use them, > possibly leading to silent memory corruption, and > - still expose quite a lot more than most people would expect > about the original source code. > > For these reasons, we're looking at removing binary-only package > support entirely. > > If you use binary-only packages and think it's important to keep that > support around, please let us know either on this thread or at > golang.org/issue/28152. > > Thanks. > Russ > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
