Live data from Hacker News

Go 1.9.1 and Go 1.8.4 are released

groups.google.com

11–20 of 33 posts

Re: Go 1.9.1 and Go 1.8.4 are released

#11
post #7

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. 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 th…

> 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.

Re: Go 1.9.1 and Go 1.8.4 are released

#14
post #4

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. 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.

It's pretty good, but I disagree about net/http being ready out of the box.

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.

Re: Go 1.9.1 and Go 1.8.4 are released

#15
post #7

Earlier quoted context omitted.

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 th…

> 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 co…

I feel like Go sailed way past Y when http://www.cvedetails.com/cve/CVE-2017-3204/ happened.

Re: Go 1.9.1 and Go 1.8.4 are released

#16
post #5

If we installed with brew how long for 1.9.1 to propagate there?

Go is really easy to install manually. Just download from the official golang.org website.

Only multiply this effort times all the software people say this for, and now you have to manually remember to update.

There’s a reason people use package managers.

Re: Go 1.9.1 and Go 1.8.4 are released

#17
post #16

Earlier quoted context omitted.

Go is really easy to install manually. Just download from the official golang.org website.

Only multiply this effort times all the software people say this for, and now you have to manually remember to update. There’s a reason people use package managers.

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.

Re: Go 1.9.1 and Go 1.8.4 are released

#19
post #16

Earlier quoted context omitted.

Only multiply this effort times all the software people say this for, and now you have to manually remember to update. There’s a reason people use package managers.

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.

Re: Go 1.9.1 and Go 1.8.4 are released

#20

Earlier quoted context omitted.

> 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 co…

I feel like Go sailed way past Y when http://www.cvedetails.com/cve/CVE-2017-3204/ happened.

Golang doesn't have SSH in the standard library.
Post reply on HN