FAQ
Hey all,

I've scanned the list and the website and I might have missed a design doc
somewhere, but as far as I can tell I can't find any motivational reason
for why Go implemented its own SSL library.

Ordinarily, if the author of Go's SSL library wasn't someone of AGL's
caliber, I would have written off another implementation of SSL as just
plain crazy. It's hard to get crypto right, and OpenSSL or GnuTLS have been
tested and hardened, hopefully with most bugs worked out. However, since
AGL is also a contributor to OpenSSL directly, I can't help but wonder why
Go decided to re-invent the wheel here.

The only two things I can think of as possible pros are that perhaps the Go
authors wanted the Go standard library to be all written in Go, or that
maybe an existing library was hard to get to work with the event loop? The
first argument is poor since there's already a lot of native code that's
not Go in the standard library and OpenSSL is super portable. I can't
really say much toward the second argument. Even more speculative and crazy
(and something I wouldn't have considered at all until Snowden) is that
maybe Google knows something we don't about the OpenSSL codebase but isn't
allowed to say? Nah.

On the flip side, Go's reimplementation has caused some serious headaches (
https://code.google.com/p/go/issues/detail?id=5987 is one example, I can't
find the other ticket I have in mind at the moment, something about what
certificates in the chain Go chooses to present to the peer), raises
security questions (yet another codebase to vet and verify), and perhaps
most selfishly, none of my OpenSSL hardware acceleration modules work with
Go at all (cryptodev or AF_ALG support plz?).

I've had a few people show serious surprise and concern when I mention Go
uses its own crypto library.

So, yeah, given all that, having not seen any discussion of this before,
why? I assume there's good reasons.

-JT

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Rob Pike at Oct 9, 2013 at 4:29 pm
    We have someone of AGL's calibre, he wanted to do it, and it's nice to have
    it all in Go. If crypto is so hard that only one implementation is allowed
    to exist, it's crypto that needs to be rethought, not Go's library.
    Moreover, Go is safer and cleaner and I would argue therefore a safer
    language for writing crypto code than C or C++. The problems you list are
    due more to the youth of the library rather than to it being infeasible.

    But actually: When the SSL work was undertaken, there was no cgo, so doing
    it in Go was the only option.

    -rob

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rodrigo Kochenburger at Oct 9, 2013 at 5:13 pm
    Also, I think it's good to have the option to not dynamic link to a 3rd
    party library. You can always use CGO to wrap/use OpenSSL yourself if you
    want too.

    - RK

    On Wed, Oct 9, 2013 at 9:29 AM, Rob Pike wrote:

    We have someone of AGL's calibre, he wanted to do it, and it's nice to
    have it all in Go. If crypto is so hard that only one implementation is
    allowed to exist, it's crypto that needs to be rethought, not Go's library.
    Moreover, Go is safer and cleaner and I would argue therefore a safer
    language for writing crypto code than C or C++. The problems you list are
    due more to the youth of the library rather than to it being infeasible.

    But actually: When the SSL work was undertaken, there was no cgo, so doing
    it in Go was the only option.

    -rob

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Agl at Oct 9, 2013 at 7:13 pm

    On Wednesday, October 9, 2013 9:39:36 AM UTC-4, jto...@gmail.com wrote:
    Ordinarily, if the author of Go's SSL library wasn't someone of AGL's
    caliber, I would have written off another implementation of SSL as just
    plain crazy. It's hard to get crypto right, and OpenSSL or GnuTLS have been
    tested and hardened, hopefully with most bugs worked out. However, since
    AGL is also a contributor to OpenSSL directly, I can't help but wonder why
    Go decided to re-invent the wheel here.
    Have you seen the OpenSSL code? I do, indeed, work with it a lot and it
    doesn't exactly fill one with positive feelings. NSS has a different set of
    issues. (I'm not familiar with alternatives like Polar or GnuTLS.)

    The crypto/tls package doesn't solve every use case, but you're not forced
    to use it. Since you need client auth without KeyUsage + hardware accel
    then it is perfectly reasonable to wrap OpenSSL.


    Cheers

    AGL

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brainman at Oct 9, 2013 at 10:27 pm
    The lib "just works" on windows. There are no special requirements, like
    "install this compiler and extra libs, make sure they are in the path and
    ... and ... and ...". It just another package like strconv for example.

    Alex

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Carlos Castillo at Oct 10, 2013 at 3:57 am
    Aside from the reasons listed above, I like the fact that there are
    computationally complex libraries built in Go that are part of the std
    library, that way there is always an impetus to improve the quality of the
    code produced by the compiler, and a decent real-life benchmark to measure
    any performance improvements against.
    On Wednesday, October 9, 2013 6:39:36 AM UTC-7, jto...@gmail.com wrote:

    Hey all,

    I've scanned the list and the website and I might have missed a design doc
    somewhere, but as far as I can tell I can't find any motivational reason
    for why Go implemented its own SSL library.

    Ordinarily, if the author of Go's SSL library wasn't someone of AGL's
    caliber, I would have written off another implementation of SSL as just
    plain crazy. It's hard to get crypto right, and OpenSSL or GnuTLS have been
    tested and hardened, hopefully with most bugs worked out. However, since
    AGL is also a contributor to OpenSSL directly, I can't help but wonder why
    Go decided to re-invent the wheel here.

    The only two things I can think of as possible pros are that perhaps the
    Go authors wanted the Go standard library to be all written in Go, or that
    maybe an existing library was hard to get to work with the event loop? The
    first argument is poor since there's already a lot of native code that's
    not Go in the standard library and OpenSSL is super portable. I can't
    really say much toward the second argument. Even more speculative and crazy
    (and something I wouldn't have considered at all until Snowden) is that
    maybe Google knows something we don't about the OpenSSL codebase but isn't
    allowed to say? Nah.

    On the flip side, Go's reimplementation has caused some serious headaches (
    https://code.google.com/p/go/issues/detail?id=5987 is one example, I
    can't find the other ticket I have in mind at the moment, something about
    what certificates in the chain Go chooses to present to the peer), raises
    security questions (yet another codebase to vet and verify), and perhaps
    most selfishly, none of my OpenSSL hardware acceleration modules work with
    Go at all (cryptodev or AF_ALG support plz?).

    I've had a few people show serious surprise and concern when I mention Go
    uses its own crypto library.

    So, yeah, given all that, having not seen any discussion of this before,
    why? I assume there's good reasons.

    -JT
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 9, '13 at 4:15p
activeOct 10, '13 at 3:57a
posts6
users6
websitegolang.org

People

Translate

site design / logo © 2019 Grokbase