
Open-Source Go Libraries - jtolds
https://www.spacemonkey.com/blog/posts/go-open-source
======
tptacek
Adam Langley will disagree with me on this point, but if you were a client and
put a choice of Golang crypto/tls and OpenSSL in front of me, I'd
professionally recommend crypto/tls.

This doesn't come up that much, because most production-scale deployments
terminate TLS at a cluster of load balancers, so you don't really get to
choose which TLS library you use in prod. But if you have the option, I get
warmer fuzzies from crypto/tls than from native bindings to the scariest
library in cryptography.

This could change in a year or so when the forks settle out, but I hope not,
because crypto/tls is a very nice piece of code.

~~~
jtolds
Totally. I'd love to see crypto/tls fixed. Until then, though, I'd rather not
choose the option with known, existing attack vectors.

Too bad it took such a horrible bug to shake everyone into auditing these
libraries.

Edit: fwiw, the hw acceleration is a pretty big deal for us. We have little
ARM devices.

~~~
tptacek
Are you working from the presumption that Golang crypto/tls admits practical
side-channel attacks and OpenSSL doesn't? I would question that assumption.
Again: if I had to make a recommendation between the two, then from a security
perspective I'd lean crypto/tls.

Regardless, if I was stuck on hardware acceleration, I'd probably stick a
reverse proxy in front of my Golang code before I incorporated an OpenSSL
Golang binding.

~~~
jtolds
Having a separate process for SSL termination is of course completely doable,
but was a little more challenging. We use client-side certificates for
application level authentication logic, so we would have needed to side-
channel the authentication information from our reverse proxy to our app.
Again, completely, totally doable, was just harder for our transliteration
project [1].

Good advice.

[1] [https://www-staging.spacemonkey.com/blog/posts/go-space-
monk...](https://www-staging.spacemonkey.com/blog/posts/go-space-monkey)

------
chimeracoder
> While Go has very deliberately not implemented class hierarchies, a quick
> perusal of Go's net and os packages should indicate that sometimes error
> hierarchies are useful.

I just want to point out - I would hesitate from drawing too many conclusions
from "net" and "os" (the latter in particular). Not only is "os" some of the
oldest Go code, but it is also designed to wrap conveniently around external
interfaces that follow very different idioms.

Another example would be the constant declarations[0], which use ALL_CAPS -
this is actually not idiomatic in Go, but it is used here (a) because it was
done very early on, and (b) because it more closely matches the C libraries it
interfaces with[1].

I need to take a closer look at this errors package before drawing an opinion
about the rest of it, but this sentence caught my attention.

[0] [http://golang.org/pkg/os/#pkg-constants](http://golang.org/pkg/os/#pkg-
constants)

[1]
[https://github.com/golang/lint/issues/32](https://github.com/golang/lint/issues/32)

------
kbd
In their errors library -
[http://godoc.org/github.com/SpaceMonkeyGo/errors](http://godoc.org/github.com/SpaceMonkeyGo/errors)
\- they write:

> It doesn't take long during Go development before you may find yourself
> wondering where an error came from. In other languages, as soon as an error
> is raised, a stack trace is captured and is displayed as part of the
> language's error handling. Go error types are simply basic values, and no
> such magic happens to tell you what line or what stack an error came from.

I was thinking the other day that Go's "if err != nil { return err }" is just
the explicit version of what's done implicitly with exceptions, except the
'err' doesn't remember where it came from. This lack of information seems like
a pretty big inconvenience. How do Go developers typically deal with this
problem?

~~~
_Soulou
github.com/juju/errgo from Canonical is really great. 100% compatible with the
error interface, allow you to get the source and the explanation of an error.

~~~
vendakka
Thanks for pointing to this. I remember reading about it a while back, but
when I needed a stack trace wrapper I couldn't remember the name. I ended up
adding a function to an error library I maintain (github.com/surullabs/fault).

When I find some time I'll pull out my code and start using either errgo or
the SpaceMonkey version.

------
tagrun
> Go TLS does not support hardware accelerated crypto.

Go uses AES-NI instructions on amd64 when available
[http://tip.golang.org/src/pkg/crypto/aes/asm_amd64.s](http://tip.golang.org/src/pkg/crypto/aes/asm_amd64.s)

> Go TLS does not have wide support for backwards compatibility with less
> secure and older protocol versions (a good thing, until you have no other
> option).

LibreSSL people beg to differ about this "feature".

> Go TLS does not give much control over the certificate validation process,
> which makes it difficult or impossible to add additional checks and
> validations.

What exactly is this about?

> Oh, and Go TLS is vulnerable to timing attacks.

A mitigation is in WIP
[https://codereview.appspot.com/94850043](https://codereview.appspot.com/94850043)

~~~
jtolds
AES-NI doesn't work on ARM, which is what we have.

>> Go TLS does not have wide support for backwards compatibility with less
secure and older protocol versions (a good thing, until you have no other
option).

> LibreSSL people beg to differ about this "feature".

Agreed agreed! Don't use old protocols!

>> Go TLS does not give much control over the certificate validation process,
which makes it difficult or impossible to add additional checks and
validations.

> What exactly is this about?

OpenSSL allows you to specify your own validation callback, to add additional
checks to the certificate validation step. The only certificate validation
option Go's TLS gives you is either InsecureSkipVerify or not.

>> Oh, and Go TLS is vulnerable to timing attacks.

> A mitigation is in WIP
> [https://codereview.appspot.com/94850043](https://codereview.appspot.com/94850043)

awesome!

~~~
tagrun
> AES-NI doesn't work on ARM, which is what we have.

I'm afraid this falls into scope of the low-priority issue 4299 then:
[https://code.google.com/p/go/issues/detail?id=4299](https://code.google.com/p/go/issues/detail?id=4299)

> OpenSSL allows you to specify your own validation callback, to add
> additional checks to the certificate validation step. The only certificate
> validation option Go's TLS gives you is either InsecureSkipVerify or not.

I'm not sure about the necessity or the details of the particular use case,
but if it is general enough, you can file an issue.

~~~
jtolds
Thanks for the pointer to #4299. Unfortunately, custom asm isn't going to be
nearly as fast as what we're doing, but I left a comment to that affect.

As for adding options to Go TLS, it is worth filing an issue for sure. Go 1
compatibility guarantee (and resulting standard library interface freeze)
definitely restricts options here, but yeah I'll look into it.

------
Xorlev
Nice set of libraries. I wonder if they looked at log4go before writing their
own logger, and if so what drove them to do so.

~~~
ominous_prime
is there an active fork of log4go? The original hasn't been updated in 2
years, with a couple serious issues which have been open at least as long.

I would also love a flexible logging package (that isn't glog ;).

~~~
mratzloff
I use seelog
([https://github.com/cihub/seelog](https://github.com/cihub/seelog)) and have
been pretty happy with it.

