On Tue, Jan 22, 2019 at 1:06 PM Wei Tang <tomjame...@gmail.com> wrote: > > Well, I do think Binary-only packages are very important for some security > case, such as authentication algorithm in a private enterprise。
I would not recommend using them in that way. A binary package should be thought of as a slightly shrouded form of the original source code. An attacker with access to the binary-only package can easily reproduce a variant of the original Go source code. Comments and local variable names will be lost, but everything else will be there, including any certificates and all algorithms. Ian > 在 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. -- 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.
