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

[Julien Cabieces]

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



> Hi, I'm having this security issue with Bandit and cannot publish my
> plugin. But the executeSql() does not take separate parameters. What
> would be the proper solution here?
>
>
> Possible SQL injection vector through string-based query construction.
> 104             q = f'DELETE FROM imaer_metadata WHERE key = \'{key}\';'
> 105             self.conn.executeSql(q)
>
>
> (Instead of putting # nosec behind the lines as explained here:
> https://lists.osgeo.org/pipermail/qgis-developer/2026-June/068337.html
> )
>
> Regards,
> Raymond
>
>
> On 4/23/26 14:58, Johannes Kröger (WhereGroup) via QGIS-Developer wrote:
>> Hi,
>> the plugins repository now *publicly* denounces plugins when its
>> security scan has flagged something.
>> I use the word "denounce" aggressively here because as a plugin
>> developer it is not nice to have plugins *which do not actually have
>> security issues* brandished insecure with a BIG RED WARNING, losing
>> trust of their users.
>> The rules are not perfect and at least for plugins where I have
>> insight the false positive rate is higher than the correct flags...
>> For example it flags any requests.get() call without a timeout. The
>> worst that can happen is a hanging QGIS, big whoop...
>> It also flags hashes as secrets and I fail to see how this is
>> helpful for plugins that are *already published and accessible*.
>> Please revert the public display of this badge for now. If it is
>> planned to publicly flag existing plugin versions, give developers
>> ample time to review, fix or dispute the findings.
>> Sorry for the aggressive tone but this was unexpected and is very
>> unpleasant to deal with.
>> I do think that the scanning and potential blocking of new versions
>> is a great feature (thank you for it!) but the retrospective
>> scanning with public display without human validation is not.
>> Cheers, Hannes
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 

Julien Cabieces
Senior Developer at Oslandia
julien.cabieces at oslandia.com