Live data from Hacker News

Go Language – Web Application Secure Coding Practices

checkmarx.gitbooks.io

51–55 of 55 posts

Re: Go Language – Web Application Secure Coding Practices

#51
People who are not happy with the current content may contribute to make it better. This is an open source and collaborative work. There is obviously room for improvement. But instead of spitting in the soup, provide merge requests or issues. This book is shared for free. If everybody is giving a little of its time to make it better, then we may get a really usefull and informative book. It's a huge work to write a book.

See here how to contribute : https://checkmarx.gitbooks.io/go-scp/content/howto-contribut...

Re: Go Language – Web Application Secure Coding Practices

#52
post #46
post #10

Earlier quoted context omitted.

I'm not sure how `fmt.Printf("%s\n", i) // invalid type` is really that "scary". Expecting the compiler to introspect that Printf's `...interface{}` argument's first value is incorrect, even though `i` does fulfill the stated parameter's type, is a FAR more scary thought.

The important thing here is, that fmt.Printf is just a function which takes a string and a variable amount of interface{} parameters. There is nothing in the language spec which creates a type correlation. the "%s" denotes a string parameter to print is solely some inner working of the Printf function. Yes, you can special case fmt.Printf, as some compilers do, but given the standard go vet tool, I rather think it be…

That's exactly my point. Special casing the compilation of 1 specific set of functions is a scary concept, esp. as the tool that can check the types is already in the go toolchain, AND there are plenty of edge cases that can't be caught anyways, so it can create a false sense of security.

Re: Go Language – Web Application Secure Coding Practices

#54
post #52
post #46

Earlier quoted context omitted.

The important thing here is, that fmt.Printf is just a function which takes a string and a variable amount of interface{} parameters. There is nothing in the language spec which creates a type correlation. the "%s" denotes a string parameter to print is solely some inner working of the Printf function. Yes, you can special case fmt.Printf, as some compilers do, but given the standard go vet tool, I rather think it be…

That's exactly my point. Special casing the compilation of 1 specific set of functions is a scary concept, esp. as the tool that can check the types is already in the go toolchain, AND there are plenty of edge cases that can't be caught anyways, so it can create a false sense of security.

Ah, had not quite caught your point as you had phrased it (and that by the time I answered your post was difficult to read for me, as for some downvotes it was printed in a very light font). Then we fully agree.

Re: Go Language – Web Application Secure Coding Practices

#55
post #27

Don't read it, always start with using a good framework. It will do everything for you

Hi homakov, given your experience with security, could you please expand on _why_ we should not this particular guide? I do understand why we should start with using a good framework, and I have so far felt that reading guides also help us understand things to be aware of.

Because just reading a book or tutorial won't give you enough info to be comfortable with all terms there. For hobby or if you have spare time - yes go ahead, for practical business needs - waste of time. Good framework handles most of them better, and if it doesn't, it's not good one. So step 1 is always framework. Optional 2 is tutorials.
Post reply on HN