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

[Johannes Kröger (WhereGroup)]

Hi everyone,

the actual issue here is that the scan does not know the full context 
and rightfully suggests that a *possible* issue exists.
Isn't the #noseq tag exactly the correct mechanism to solve this? If the 
human knows that something looks like an issue, but they are sure it is 
not an issue, then they should be able to mark it.

You can even annotate the line with the exact test that you want to 
skip, e.g.:

... #noseq B806
... #noseq hardcoded_sql_expressions

I strongly disagree with making the code more complicated and harder to 
read, just to make the scanner not see potential issues. Functionally, 
that would just be obfuscation or distraction. The code would be as 
"insecure" as before, just less obviously so to both the scanner and the 
human.

Parameter support for executeSql would be great! In the meantime I can 
recommend psycopg's https://www.psycopg.org/docs/sql.html#module-usage / 
https://www.psycopg.org/psycopg3/docs/api/sql.html#module-usage , it's 
verbose but fairly straightforward.

Cheers, Hannes

On 6/18/26 10:56, Julien Cabieces via QGIS-Developer wrote:
> Hi all,
>
> One way to fix it is to add a "execute_sql" function that wraps the call
> to executeSql
>
> def execute_sql(self, sql, *params):
>      sql = sql.format(*params)
>      self.conn.executeSql(q)
>
> It's just another workaround, but I'd say it's still better than #noseq
> IMHO, being able to just write #noseq on every line that raise security
> error makes the security scan quite useless. We should probably remove
> the #noseq possibility in the long term.
>
> The good way to go would be to adapt our API so executeSql takes
> parameters.
>
> I don't think this warning is irrelevant. If you take some input from
> the user, there is a possibility of user injection. In this
> case, there is maybe no strong harm but there is no way to automatically
> decide if it's harmful or not.
>
> Regards,
> Julien