3 ms·

Go makes it easy to build an all in one statically compiled binary with no external dependencies. No glibc, etc. It makes it really easy to build software and

by Dobbs 11y ago

Go makes it easy to build an all in one statically compiled binary with no external dependencies. No glibc, etc. It makes it really easy to build software and distribute it to your server farms.

revelation 11y ago
That's a sweet bullet point on page 3. I don't see what that has to do with security of rolling your own crypto and coupling it with the whole distribution. If you want, you can link OpenSSL statically. It's about as recommended as statically linking the entire universe into a binary.
- f2f 11y ago
  you need as many functional implementations of TLS as you can get. written by people with pedigree. you need them to cross-polinate and find bugs in each other. Go's TLS stack for example is used to test the TLS implementation is BoringSSL: https://www.imperialviolet.org/2015/10/17/boringssl.html https://www.imperialviolet.org/2015/10/17/boringssl.html Go's crypto wasn't rolled out by amateurs.
  - deleted 11y ago
    [deleted]
  - revelation 11y ago
    The evidence points elsewhere. TLS is such a complex protocol that any new library will make fundamental errors in implementing it and the requisite crypto primitives (of which there are many). What crypto libraries need is usage and, this usually goes with it, attention from people looking to break them. There are plenty of TLS libraries out there like mbedTLS and the mentioned JSEE, and looking at CVE reports a few years ago you would think these are the most secure libraries in the entire world compared to the constant trickle of issues in OpenSSL. Except when heartbleed got attention and people started looking at these rarely used alternatives they found massive problems. For years, the protocol FSM in JSEE was fatally broken. MbedTLS had and continues to have issues with just basic things like buffer overflows. And often these libraries just plain lack features and timely updates.
    - f2f 11y ago
      > What crypto libraries need is usage openssl is by far the most widely used tls library out there. still, occasionally our collective hearts bleed. what's even worse is you get forks of openssl for each vendor that wants to abide by this government's policy or that. in effect, you have a single bad codebase multiplied n-fold. where's the economy of scale there? if you're arguing that "with many eyes all bugs are shallow", this has been disproven. if you're arguing that java's tls implementers were crap, well, that's fine. doesn't mean go's are.
    - nindalf 11y ago
      Interesting that you mention heartbleed while also claiming that Go implementing its own TLS library was a bad move. fyi, the popular Heartbleed test used a modified Go TLS stack - [1]. Clearly having an alternate implementation that was easy to work with was a win here. https://filippo.io/Heartbleed/ https://filippo.io/Heartbleed/

by Dobbs 11y ago

Go makes it easy to build an all in one statically compiled binary with no external dependencies. No glibc, etc. It makes it really easy to build software and distribute it to your server farms.

revelation 11y ago

That's a sweet bullet point on page 3. I don't see what that has to do with security of rolling your own crypto and coupling it with the whole distribution. If you want, you can link OpenSSL statically. It's about as recommended as statically linking the entire universe into a binary.

f2f 11y ago
you need as many functional implementations of TLS as you can get. written by people with pedigree. you need them to cross-polinate and find bugs in each other. Go's TLS stack for example is used to test the TLS implementation is BoringSSL: https://www.imperialviolet.org/2015/10/17/boringssl.html https://www.imperialviolet.org/2015/10/17/boringssl.html Go's crypto wasn't rolled out by amateurs.
- deleted 11y ago
  [deleted]
- revelation 11y ago
  The evidence points elsewhere. TLS is such a complex protocol that any new library will make fundamental errors in implementing it and the requisite crypto primitives (of which there are many). What crypto libraries need is usage and, this usually goes with it, attention from people looking to break them. There are plenty of TLS libraries out there like mbedTLS and the mentioned JSEE, and looking at CVE reports a few years ago you would think these are the most secure libraries in the entire world compared to the constant trickle of issues in OpenSSL. Except when heartbleed got attention and people started looking at these rarely used alternatives they found massive problems. For years, the protocol FSM in JSEE was fatally broken. MbedTLS had and continues to have issues with just basic things like buffer overflows. And often these libraries just plain lack features and timely updates.
  - f2f 11y ago
    > What crypto libraries need is usage openssl is by far the most widely used tls library out there. still, occasionally our collective hearts bleed. what's even worse is you get forks of openssl for each vendor that wants to abide by this government's policy or that. in effect, you have a single bad codebase multiplied n-fold. where's the economy of scale there? if you're arguing that "with many eyes all bugs are shallow", this has been disproven. if you're arguing that java's tls implementers were crap, well, that's fine. doesn't mean go's are.
  - nindalf 11y ago
    Interesting that you mention heartbleed while also claiming that Go implementing its own TLS library was a bad move. fyi, the popular Heartbleed test used a modified Go TLS stack - [1]. Clearly having an alternate implementation that was easy to work with was a win here. https://filippo.io/Heartbleed/ https://filippo.io/Heartbleed/