[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