3 ms·

Ah yes, the git gut method of software engineering, an endless font of teaching opportunities from being a bottomless well of fuckups. Especially unhelpful whe

Ah yes, the git gut method of software engineering, an endless font of teaching opportunities from being a bottomless well of fuckups. Especially unhelpful when the dynamic sql is legit.

jkaplowitz 3y ago
I didn’t say you had to be magic about it in the way of git gut, no. One can for example hook up a static analyzer to your GitHub and configure it to complain if there are any sql calls that can’t be automatically verified as free from interpolation of potentially unsafe data unless those dynamic calls are marked with a comment annotation as having been individually verified by a human as definitely not interpolating potentially unsafe data. I suspect such an analyzer may already exist as a SaaS offering. If nobody lies about those annotations, a static analyzer can handle the common cases. If you have a human faking such annotations, whichever motivation causes them to do that would create other security issues even with the ORM. And the analyzer could even handle some kinds of dynamic sql depending on how aware it is of your programming language and type system and what markings you’re willing to apply to functions and/or data with potentially unsafe and/or safe origins. Being vague only in the service of generality here since the specifics vary so much by company. If there is no SaaS service for this, maybe one ought to exist.
Capricorn2481 3y ago
Humans make mistakes and we can't rely on them not to make mistakes in software development, yes. But preventing SQL injection is not really an "oopsie.". It's a fairly easy thing to spot and prevent, and none of the code I've ever reviewed had a SQL injection bug in it because string interpolation looks completely different from parametrized queries. I have no problems with ORMs, but you make it sound like it's as easy for a SQL injection bug to go into production code as a memory bug in C. You'd have to actively be fucking up at that point, and if a Junior dev does it, it's a 5 minute talk and they'll never do it again.

Ah yes, the git gut method of software engineering, an endless font of teaching opportunities from being a bottomless well of fuckups. Especially unhelpful when the dynamic sql is legit.

jkaplowitz 3y ago

I didn’t say you had to be magic about it in the way of git gut, no. One can for example hook up a static analyzer to your GitHub and configure it to complain if there are any sql calls that can’t be automatically verified as free from interpolation of potentially unsafe data unless those dynamic calls are marked with a comment annotation as having been individually verified by a human as definitely not interpolating potentially unsafe data. I suspect such an analyzer may already exist as a SaaS offering. If nobody lies about those annotations, a static analyzer can handle the common cases. If you have a human faking such annotations, whichever motivation causes them to do that would create other security issues even with the ORM. And the analyzer could even handle some kinds of dynamic sql depending on how aware it is of your programming language and type system and what markings you’re willing to apply to functions and/or data with potentially unsafe and/or safe origins. Being vague only in the service of generality here since the specifics vary so much by company. If there is no SaaS service for this, maybe one ought to exist.

Capricorn2481 3y ago

Humans make mistakes and we can't rely on them not to make mistakes in software development, yes. But preventing SQL injection is not really an "oopsie.". It's a fairly easy thing to spot and prevent, and none of the code I've ever reviewed had a SQL injection bug in it because string interpolation looks completely different from parametrized queries. I have no problems with ORMs, but you make it sound like it's as easy for a SQL injection bug to go into production code as a memory bug in C. You'd have to actively be fucking up at that point, and if a Junior dev does it, it's a 5 minute talk and they'll never do it again.