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

[Benjamin Jakimow]

Thanks for bringing this up, Hannes,

We were completely taken aback by the red security warning button.

In principle, we appreciate the idea of running checks before uploading 
a plugin. These tests also showed us many parts where we can and will 
improve our plugins.

In some cases, however, it remains questionable whether a red button 
warning is necessary. For example the use of `exec` to run user-defined 
Python code. We have many cases where this is explicitly desired. For 
example to allow users to modify scikit-learn pipelines, or use numpy 
arrays to adjust array values before they get plotted.

As users can run Python code in the QGIS Python shell, why should this 
not not be allowed in plugins as well? An idea could be a separate flag 
for plugins that allow Python code inputs, so that Bandit no longer 
flags this as an issue at it is intended.

Greetings,
Benjamin



On 23.04.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

-- 
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/20260424/e3955c0e/attachment-0001.bin>