Go 1.9.1 and Go 1.8.4 are released
groups.google.com
Go 1.9.1 and Go 1.8.4 are released
1–10 of 33 posts
Re: Go 1.9.1 and Go 1.8.4 are released
#2It 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.
Edit: I am referring to only the SMTP issue here.
Re: Go 1.9.1 and Go 1.8.4 are released
#3It 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. Edit: I am referring to only the SMTP issue here.
Which problem do you mean?
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.
Re: Go 1.9.1 and Go 1.8.4 are released
#4It 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. Edit: I am referring to only the SMTP issue 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.
Re: Go 1.9.1 and Go 1.8.4 are released
#5If we installed with brew how long for 1.9.1 to propagate there?
Re: Go 1.9.1 and Go 1.8.4 are released
#6If we installed with brew how long for 1.9.1 to propagate there?
Seems like it's in progress. IIRC brew pulls from Git(hub) directly, so, I guess as soon as this is merged: https://github.com/Homebrew/homebrew-core/pull/19000
Re: Go 1.9.1 and Go 1.8.4 are released
#7It 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. Edit: I am referring to only the SMTP issue here.
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.
Re: Go 1.9.1 and Go 1.8.4 are released
#8It 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. Edit: I am referring to only the SMTP issue 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.
I've been out of the loop on Golang security for a bit, but last I recalled there might have been some timing vulnerabilities in the crypto library.
Is this not the case anymore?
Re: Go 1.9.1 and Go 1.8.4 are released
#9It 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. Edit: I am referring to only the SMTP issue here.
Which problem do you mean? 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…
> Which problem do you mean?
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.
Re: Go 1.9.1 and Go 1.8.4 are released
#10Earlier quoted context omitted.
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.
I've been out of the loop on Golang security for a bit, but last I recalled there might have been some timing vulnerabilities in the crypto library. Is this not the case anymore?
Bunch of stuff was discovered and fixed relatively promptly:
https://golang.org/doc/devel/release.html
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.