[QGIS-Developer] Existing plugin versions should not be marked with "security issues"

[Greg Troxel]

Julien Cabieces <julien.cabieces at oslandia.com> 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.