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

[Benjamin Jakimow]

Dear all,

another example is the use of `exec` in justified cases (Bandit B102)

We have plugins in which scientific users are able to use Python and 
Numpy code to modify their data. This allows them to quickly check the 
effects of their code changes and, if necessary, incorporate them later 
into their own Python/NumPy data crunching code. Python is the 
Domain-Specific-Language of choice, but similar to running it in the 
QGIS Python shell, we need to call exec to run it in our plugin.

Replacing `compile` + `exec` with, let's say QGIS Field Expressions as a 
domain-specific language, is technically not feasible, as we cannot 
modify multidimensional arrays with it and it's harder to transfer into 
other workflows.

It would therefore be helpful if such cases could be marked as 
“explicitly requested” if a reason is provided. Similar to what we know 
from other app stores ("this app requires access of your camera"), the 
QGIS plugin repository may provide information like "this plugin 
requires to execute arbitrary code".

Greetings,
Benjamin

On 19.06.26 09:49, Johannes Kröger (WhereGroup) via QGIS-Developer wrote:
> 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
> 
> _______________________________________________
> 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

-- 
Dr. Benjamin Jakimow
Earth Observation Lab | Geography Department | Humboldt-Universität zu 
Berlin

e-mail: benjamin.jakimow at geo.hu-berlin.de

phone:  +49 (0) 30 2093 45846
mobile: +49 (0) 157 5656 8477

mail:   Unter den Linden 6 | 10099 Berlin | Germany
matrix: @jakimowb:hu-berlin.de
web:    https://eolab.geographie.hu-berlin.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4284 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260619/62245665/attachment-0001.bin>