Well lots of software like Ruby is a pain in the ass to install. Package managers make plenty of sense there. But Go is as easy as it comes. I was just offering that since this seems like a time-sensitive update.
This has nothing to do with Go being easy or hard to install, and everything to do with giving people a uniform way to manage installation, updates and removal of software, independent of what software that is.
OK. Well, for what it's worth, I use ubuntu and find it much easier to install Go using their website than using apt (which I do use for most things). Thanks for the downvotes guys.
I don’t use Homebrew, given that Go is now written in Go, how does Homebrew bootstrap it when there are no binaries available? Does it download Go 1.4, builds it with a C compiler and uses that to build the latest version?
Sure, it's that simple until you need a specific non-default version. In cases like that I have found it easier to install from golang.org, that's all I was trying to say.
I’ve been installing Go from source since back when that was necessary to get cross compilation working, and have continued because I am a crazy person. It only takes a couple minutes and a previous version of Goto do.
If you are building from source, it's very trivial to update. git pull, checkout the new tag and build.
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
It seems like this should have been noticed earlier. If you are working on authentication code, you should think about how it could be used by a malicious actor.
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.
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.
Could you name any projects of a similar age, exposure, and utility, that don't have similar bugs? Furthermore a comparison between the vulnerability and discoverability dates - I think Go would prove well above average here...
It's not related to crypto/tls or net/http. This has to do with sending mail via SMTP. It's totally worth fixing but probably had close to zero real world effect.
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.
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.
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.
I do disagree with this type of comment, but I'd like to note this was a very popular response to e.g. the TrueCrypt & VeraCrypt audits. Shouldn't a piece of software having been audited (or otherwise examined) and having problems fixed increase confidence not decrease it? At the same time, you can't necessarily argue that a piece of software is more secure due to having more security bugs found and fixed. I guess the only response you can have is something nebulous based on the number of eyes on a project, how many bugs are found, their severity, their complexity, and the maintainers' response.
> Shouldn't a piece of software having been audited (or otherwise examined) and having problems fixed increase confidence not decrease it?
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.
