Gosec SAST scan results

[russsaidwords]

I am likely going to use websocketd to rewrite some projects. As part of the process, I pulled the code and ran it through the Gosec scanner. Below are the results.

Results: [/go/src/lcf-gitlab-up.lle.rochester.edu/redwards/websocketd/libwebsocketd/http.go:13] - G504 (CWE-327): Blocklisted import net/http/cgi: Go versions < 1.6.3 are vulnerable to Httpoxy attack: (CVE-2016-5386) (Confidence: HIGH, Severity: MEDIUM) 12: "net/http" 13: "net/http/cgi" 14: "net/textproto" [/go/src/lcf-gitlab-up.lle.rochester.edu/redwards/websocketd/libwebsocketd/websocket_endpoint.go:52] - G104 (CWE-703): Errors unhandled. (Confidence: HIGH, Severity: LOW) 51: } 52: w.Close() // could need error handling 53: [/go/src/lcf-gitlab-up.lle.rochester.edu/redwards/websocketd/libwebsocketd/process_endpoint.go:94] - G104 (CWE-703): Errors unhandled. (Confidence: HIGH, Severity: LOW) 93: func (pe *ProcessEndpoint) Send(msg []byte) bool { 94: pe.process.stdin.Write(msg) 95: return true [/go/src/lcf-gitlab-up.lle.rochester.edu/redwards/websocketd/libwebsocketd/process_endpoint.go:37] - G104 (CWE-703): Errors unhandled. (Confidence: HIGH, Severity: LOW) 36: // for some processes this is enough to finish them... 37: pe.process.stdin.Close() 38: [/go/src/lcf-gitlab-up.lle.rochester.edu/redwards/websocketd/libwebsocketd/process_endpoint.go:34] - G104 (CWE-703): Errors unhandled. (Confidence: HIGH, Severity: LOW) 33: terminated := make(chan struct{}) 34: go func() { pe.process.cmd.Wait(); terminated <- struct{}{} }() 35: Summary: Gosec : 2.9.5 Files : 15 Lines : 2063 Nosec : 0 Issues : 5

It's easy to disregard the G504 as we're not using Go < v1.6.3. The G104's are slightly harder to ignore. I didn't see a CONTRIBUTING.md file or a template for new issues, so I'm sorry if this doesn't fit how you want to receive information. My Go is slightly rusty or I would also be contributing a pull request - as it is, I'll have to read over the project a few times before I feel comfortable adding in appropriate error handling myself, so I was hoping someone more familiar could take a look, but if no one does I think I can eventually get around to it myself.

Thanks for your efforts here, this project and it's contributors are much appreciated!

[asergeyev]

Thanks for the report, I will get to it eventually or someone would PR before me, handling should not be too hard to add except in last case where error needs to be logged/ignored.

(The leak of forked sub processes might be possible there but it happens as last resort of waiting for process to be killed, nothing else websocket can do to at that state if OS fails to do that and properly signal back)