<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 30/11/2024 à 16:51, Even Rouault a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:80153cf4-00df-4f88-b7f3-17da0d2b7859@spatialys.com">
<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>
</blockquote>
yes, totally. <br>
<blockquote type="cite"
cite="mid:80153cf4-00df-4f88-b7f3-17da0d2b7859@spatialys.com">
<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>
</blockquote>
<p>Also true, and up to now, QGIS's project and developpers managed
to avoid such overhead in pre studies that cost more than the fix
itself. <br>
</p>
<p>My point is about debates we already had previously about
hypothetical attack scenarios. For instance, we know that through
python scripting, or qgis project vector, we have a wide exposure
surface and we could spend years digging into all the possible
exploits, whereas QGIS is a desktop tool almost granted all the
privileges of the account. Hardening the desktop part against all
those exploits would probably lead to propose to go toward a
sandboxed QGIS more than tracking every possible exploit. <br>
A critical issue in a dependency is a no brainer to me. A
customer raising real world attack scenario is also a no brainer.
But discussing all potential theoritical attacks in a generalist
desktop tool is kind of like exploring the galaxy. However,
hardening our core classes is more delimited. <br>
</p>
<p>Dependencies issues mainly is in the packager's hands. What we
can improve there is catch CVE's before users reach to us and be
proactive. <br>
</p>
<blockquote type="cite"
cite="mid:80153cf4-00df-4f88-b7f3-17da0d2b7859@spatialys.com">
<p><span> </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>
</blockquote>
<p>A global unique risk assessment is infeasible at QGIS's project
level I think. It is of the responsability of the user to evaluate
its criticity. My point was to warn about the fact that we have
on the security list some IT departement that show no sign of
maturity on this question, and ask for true and perfect security.
This is a fact we have to take into account when explaining our
future security strategy. Our target is a bit different than if
QGIS was PostgreSQL in terms of persons we talk to. <br>
</p>
<p>Cheers!<br>
</p>
<blockquote type="cite"
cite="mid:80153cf4-00df-4f88-b7f3-17da0d2b7859@spatialys.com">
<p><span> </span></p>
<span>
</span>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com"
moz-do-not-send="true">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>
</blockquote>
<div id="grammalecte_menu_main_button_shadow_host"
style="width: 0px; height: 0px;"></div>
</body>
</html>