Go 1.9.1 and Go 1.8.4 are released
groups.google.com
groups.google.com
There’s a reason people use package managers.
brew install go
[1] https://github.com/Homebrew/homebrew-core/blob/master/Formul... [2] https://github.com/golang/go/blob/master/src/bootstrap.bash
I can probably stop now.
"brew upgrade go" just pulled 1.9.1 for me
go: unknown subcommand "update" Run 'go help' for usage.
Building from source gives you the awesome cross compilation features of Go, apart from easy updates and make it easy to see how specific features are implemented in the source. So highly recommend
Does anyone know why it took several years to realize the problem here? This kind of simple vulnerability makes me concerned about other security issues in Go.
Edit: I am referring to only the SMTP issue here.
Both are relatively minor on a scale from "meh" to "OMG shut everything down!". Every major project has security bugs now and then.
There are many mail clients that will send passwords over non-TLS links (that was standard practice for decades...and you can still convince many mail clients to do it without much fanfare). This change prevents foot-shooting and that's good, but, the fact that they didn't prevent foot-shooting for a little while due to an oversight isn't some massive security failure.
The git-in-git issue is pretty subtle. I'm not surprised it slipped by unnoticed for a while.
I was referring to the SMTP issue. I should have made that more clear.
> Both are relatively minor on a scale from "meh" to "OMG shut everything down!". Every major project has security bugs now and then.
Definitely. I don't think the problem itself is that bad. My main issue is that it was introduced with the ramifications in mind (see the original issue) and an RFC specifically stating it should only be used with TLS connections. The only reasonable use case is for connections to localhost; so the fix should have been implemented when the feature was added.
So my main issue is with the culture around the SMTP issue; if the Go contributing community lets an easy to recognize (and was recognized) issue through, I don't have much faith more subtle and important bugs will be properly handled. It may be that more security critical pieces of GO have a more rigorous culture.
> The git-in-git issue is pretty subtle. I'm not surprised it slipped by unnoticed for a while.
I agree.
Go has an incredible security track record. Out of the box, net/http and crypto/TLS are safe to deploy in production. No reverse proxy shield required.
Is this not the case anymore?
There was a pretty thorough audit that discovered some of those issues. I'm not aware of anything outstanding - they're pretty good about patching things promptly.
https://github.com/golang/go/issues/16100
Your choice is to support streaming requests and suffer from a trivial slow client DOS, out of the box, or force a timeout and kill streaming requests that exceed that timeout. For this and other reasons I still recommend fronting golang net/http with something more capable on this front.
Not necessarily. Clearly the project has less bugs in it now, but if you thought that the project was very secure and then a very simple but critical vulnerability is found, your previous estimation of the security was wrong. And so whether or not it increases or decreases your confidence depends on if the vulnerability is within your estimation of the security of the project.
For example, Heartbleed shook my faith in OpenSSL. I believed OpenSSL to be very secure and that any vulnerabilities would not be something as obvious as Heartbleed. So the existence of Heartbleed implies that there might be others of a similar nature, and my previous confidence precluded the existence of similar issues. Therefore my confidence must go down; I have more evidence though so my variance also goes down.
Largely its an issue of "I trust X to not have security vulnerabilities worse as bad (or simple) as Y" and then a Y type bug appears and is fixed. You can no longer have the same trust.