A partial answer is banning reflect in a callstack, but that's
heavy-handed. I could traverse up to a "safesql.ReflectOk on the stack
On Wednesday, February 7, 2018 at 2:54:13 PM UTC-8, Andy Jackson wrote:
>
> I realize that private functions of another package are not reachable by
> reflection, but I'm looking for a way to ensure a public
> interface-or-struct's function can be fully back-traced statically.
>
> An interface function like
> Query(sql string, args ...interface{}) Result
> is an SQL injection risk if it can be called via reflection. This includes
> the sqlx library simply being part of a program.
>
> My goal: to enhance SafeSQL to fully backtrace and know certainly that
> there are no SQL injection risks.
>
> Alternative: I can add a comment to the functions I write:
> // Reflection Calls Disallowed
>
> But compiler assurance of this would be nice.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
