Julien Cabieces <[email protected]> writes: > Hi, > >> How is this different from telling the scanner to ignore it? It seems >> like laundering input via steps the scanner doesn't follow. > > It's not that much different I agree, but I least you have to spend a > few minutes to think how you could fix (if possible) this security > issue. If you just have to write #noseq, I'm afraid it would be the easy > way to solve any security issues and the scanner would become completely > useless. > > I think we could: > - accept the #noseq for now > - think and document appropriate ways to fix every type of issue nicely > (adding parameters for > executeSql for instance) > - Point plugin developers to this documentation when there are security > issues (or code contains #noseq) > - disable #noseq for each issue type individually when there is an > alternative (and after a long enough periode of time)
I see the big issue as defining what properties this is intended to achieve, or if it's just trying to avoid dangerous, unintended, bugs. I think overriding the scanner should be done by someone other than the plugin author, based on a belief that the code is safe and the scanner is wrong. Waiving your own warnings seems unsound. _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
