[go-nuts] Why did Go implement its own SSL library?

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