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_expressionsI 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 [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
-- Dr. Benjamin JakimowEarth Observation Lab | Geography Department | Humboldt-Universität zu Berlin
e-mail: [email protected] 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/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 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
