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

[johannes.kroeger at wheregroup.com]

Hi Lova,

thanks for the super swift response and for removing the badge from 
public view. I agree that it is properly the best approach to only show 
it to the owners and staff.

If a public badge is planned, I would suggest a long introduction period 
during which plugin authors have time to check and update their plugins 
before a badge is shown.
Maybe it would be enough only show it for new uploads and leave the old 
versions unchecked and unlabeled as before.

All the best, Hannes

Am 2026-04-23 16:03, schrieb Lova Andriarimalala:
> Hi Johannes,
> 
> Thanks for raising this issue.
> 
> 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.
> 
> 
> Could we just hide the badge from public view and show it only for the
> plugin author/maintainer and, eventually, for staff/superusers? This
> feature was requested by Etienne (
> https://github.com/qgis/QGIS-Plugins-Website/issues/267), but I think
> making it publicly visible wasn't really part of the scope in this case 
> (so
> sorry for that). We could always show it in public view later when the
> checks reflect user cases.
> 
> 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*.
> 
> 
> That's correct, and we are aware that there are some teething problems 
> with
> the ruleset. I would be great if you could please raise an issue at
> https://github.com/qgis/QGIS-Plugins-Website/issues about which case 
> you
> think should be addressed by the checks.
> Please also note that we have just published a blog article about the
> plugin checks implementation at
> https://blog.qgis.org/2026/04/23/plugin-repository-security-enhancements/.
> 
> Best regards,
> 
> Lova Andriarimalala
> 
> 
> *QGIS Full Stack Developer   *
> *T *: +27(0) 87 809 2702          *E *: lova at kartoza.com          *W* :
> kartoza.com
> 
> 
> 
> *This email and any attachments are confidential and intended solely 
> for
> the use of the individual or entity to whom they are addressed. If you 
> *
> *have received this email in error, please notify the sender 
> immediately
> and delete it from your system. Unauthorised use, disclosure, or 
> copying*
> *of the contents is prohibited.*
> 
> 
> On Thu, 23 Apr 2026 at 15:59, Johannes Kröger (WhereGroup) via
> QGIS-Developer <qgis-developer at lists.osgeo.org> 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
>>