I feel like I should stress this a bit more, because it's really important:
It is under no circumstances reasonable to rely on lack of source code for security. History has taught us time and time again that security through obscurity doesn't work, and home grown/custom algorithms are usually broken. For authentication, you should always be using off-the shelf, open source libraries which implement publicly known algorithms that have been peer reviewed by experts. These will be more secure than anything that hasn't seen the light of day, and don't rely on people not knowing about them. There is no good reason why there should be anything security-sensitive in your source code. -Ian Quoting Ian Lance Taylor (2019-01-22 16:26:27) > 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. -- 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.
