[QGIS-Developer] Existing plugin versions should not be marked with "security issues"
Lova Andriarimalala
lova at kartoza.com
Thu Apr 23 07:03:11 PDT 2026
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260423/bbdcc547/attachment.htm>
More information about the QGIS-Developer
mailing list