<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>| We will have to clarify a priority grid, taking account of the
real exposure. </p>
<p>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.</p>
<p>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 (C<span>VE 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.<br>
</span></p>
<p><span>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)<br>
</span></p>
<span style="white-space: pre-wrap">
</span>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
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.</pre>
</body>
</html>