For record these vulnerabilities got assigned CVE-2017-15041 and CVE-2017-15042. Any packages using the affected component "net/smtp" needs to be rebuild with the fixed version of Go, in order to pick up the fix. Updates has been submitted in to Fedora 26,27,Rawhide(they are not in build root-override) also I'm considering backport to f25(go1.7). https://bodhi.fedoraproject.org/updates/FEDORA-2017-f4fc897e8f and https://bodhi.fedoraproject.org/updates/FEDORA-2017-6f1b90dbb7
karma is as always welcomed :),
JC
Upstream release notes follow.
----- Forwarded Message ----- From: "Chris Broadfoot" cbro@golang.org To: "golang-nuts" golang-nuts@googlegroups.com Sent: Wednesday, October 4, 2017 10:33:32 PM Subject: [golang-dev] [security] Go 1.8.4 and Go 1.9.1 are released
Hi gophers,
Two security-related issues were recently reported. To address this issue, we have just released Go 1.8.4 and Go 1.9.1.
We recommend that all users update to one of these releases (if you're not sure which, choose Go 1.9.1).
The issues addressed by these releases are:
By nesting a git checkout inside another version control repository, it was possible for an attacker to trick the “go get” command into executing arbitrary code. The go command now refuses to use version control checkouts found inside other version control systems, with an exception for git submodules (git inside git). The issue is tracked as https://golang.org/issue/22125 (Go 1.8.4) and https://golang.org/issue/22131 (Go 1.9.1). Fixes are linked from the issues. Thanks to Simon Rawet for the report.
In the smtp package, PlainAuth is documented as sending credentials only over authenticated, encrypted TLS connections, but it was changed in Go 1.1 to also send credentials on non-TLS connections when the remote server advertises that PLAIN authentication is supported. The change was meant to allow use of PLAIN authentication on localhost, but it has the effect of allowing a man-in-the-middle attacker to harvest credentials. PlainAuth now requires either TLS or a localhost connection before sending credentials, regardless of what the remote server claims. This issue is tracked as https://golang.org/issue/22134 (Go 1.8.4) and https://golang.org/issue/22133 (Go 1.9.1). Fixes are linked from the issues. Thanks to Stevie Johnstone for the report.
Downloads are available at https://golang.org/dl for all supported platforms.
Cheers, Chris (on behalf of the Go team)
On 10/09/2017 04:36 AM, Jakub Cajka wrote:
For record these vulnerabilities got assigned CVE-2017-15041 and CVE-2017-15042. Any packages using the affected component "net/smtp" needs to be rebuild with the fixed version of Go, in order to pick up the fix.
Oof. Do we have any tools right now for working out whether direct or transitive dependencies of packages we maintain are affected, so we know if we need to push a rebuild? (Speaking only for myself, I have 31 packages that don't directly import net/smtp, but I can't speak to any of the packages they pull in.)
It seems like a standard library CVE almost demands a mass golang rebuild, if we want to be safe (in the absence of automated tooling to make targeted rebuilds possible). The reality is, maintainers are going to miss this message and not rebuild, or not do the necessary legwork to know if they need to rebuild.) :(
On Mon, 9 Oct 2017 13:58:48 -0700 Ed Marshall esm@logic.net wrote:
On 10/09/2017 04:36 AM, Jakub Cajka wrote:
For record these vulnerabilities got assigned CVE-2017-15041 and CVE-2017-15042. Any packages using the affected component "net/smtp" needs to be rebuild with the fixed version of Go, in order to pick up the fix.
Oof. Do we have any tools right now for working out whether direct or transitive dependencies of packages we maintain are affected, so we know if we need to push a rebuild? (Speaking only for myself, I have 31 packages that don't directly import net/smtp, but I can't speak to any of the packages they pull in.)
It seems like a standard library CVE almost demands a mass golang rebuild, if we want to be safe (in the absence of automated tooling to make targeted rebuilds possible). The reality is, maintainers are going to miss this message and not rebuild, or not do the necessary legwork to know if they need to rebuild.) :(
That would be a nice and decent tool. I personally use a shell function of ```bash imports() { go list -f '{{.Name}} {{.ImportPath}} {{range .Imports}} {{.}}{{end}}' ${@:2} }
```
so that in a project `imports ./...` will print the imports of the recursive paths, but that does not extend to every import of even stdlib. Though that could be possible by some fancier shell work.
vb
golang@lists.fedoraproject.org
-
Ed Marshall -
Jakub Cajka -
Vincent Batts