[Qgis-psc] The security project for QGIS
Even Rouault
even.rouault at spatialys.com
Sat Nov 30 07:51:55 PST 2024
| We will have to clarify a priority grid, taking account of the real
exposure.
That part is really hard. If the issue is a CVE in a dependency of QGIS,
the CVE comes with a risk assessment (accurate or not), that can be used
to determine the urgency with which you want to re-issue a new binary
with the updated fixed dependency.
If the report is about some defect within the QGIS code base, like a
use-after-free or a double-free, you basically need to be a black hat
hacker (or their nice version "cybersecurity expert") to know if it is
exploitable or not. That is spend weeks trying to create an exploit. In
general it will be much faster to fix the issue than arguing about its
potential criticity. I believe the Linux Kernel CNA (CVE numbering
authority) which is handled by kernel developers has just chosen to
consider that any bug is exploitable out of caution, and issue a massive
amount of CVEs, which is criticized by downstream "consumers" of CVEs
(Linux distro vendors) as an overwhelming load for them, but their
analysis was exactly the above: they'd spend way more time trying to
figure out the actual criticity, and possibly getting it wrong.
What I'm saying is that doing extensive backports of fixes that might
not be strictly needed could cost much less than a true risk analysis of
the impact of a defect, for which probably nobody connected with the
project has expertise (personally I don't, even on the code bases on
which I'm intimately familiar with)
--
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20241130/ddb6ef5f/attachment.htm>
More information about the QGIS-PSC
mailing list