<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi All, <br>
</p>
<p>this is definitely a topic we should address seriously, thanks
for raising it Vincent. <br>
</p>
<p>I took some time to really read the text and understand it. I
made a short summary [0] , and found some news on the law-making
process. </p>
<p>The current text is a major threat for the whole FOSS ecosystem.
<br>
</p>
<p>As for QGIS, the main text clearly embeds any data processing
tool, but Annex 3 is not explicitly mentioning our activity field
in the list of critical products. It is not a good reason not to
act, all this is a bit fuzzy, and we will be in all cases flooded
with user messages about our CE certification, just as we are
seeing this growing from various countries (US for instance) <br>
</p>
<p>From what I see, the linux fundation, the FSF, also started to
work on this, GitHub too. At this stage, the trilogue between the
commission, the parliament and the conceal are starting and let
some minor room for improvement. The parliament proposal an
amended version that is way better [2]. <br>
</p>
<p>It is indeed a bit late for the vote happening today at the
parliament, so finger's crossed for this one, but I am not sure
their will be any debate possible today. <br>
</p>
<p>A this stage, We indeed need to push QGIS.org and OSGEO to the
ITRE committee [3] that will occur this autumn to make exemption
to real FOSS projects. They will have to move, many requirements
are utopic and break the classical CVE coordination process. We
also can forecast that the control authorities will be overloaded
with the massive impacts of the current text. <br>
</p>
<p>IMO, whatever happens on this front, we will have to push towards
a better security process, because US federal already make it
mandatory to use certified tools. IT departements are not
comfortable with FOSS and we have to at least describe our process
(that was on my todo list for the website).</p>
<p>Even if QGIS desktop is a desktop tool, I think there is a lot of
work to do. Just one example, default setup for connecting to
datasource is not warning enough users that password can leak in
plain text in project files, we might want to disable it by
default, or dig these options deeper in the UI. <br>
</p>
<p>An automatic update process would probably something we will have
to fund. The time frame is 42 months starting from the adoption
of the text and being certified CE.</p>
<p>i'd be happy to help on this front. Vincent, could you also
provide some help ?<br>
</p>
<p><br>
</p>
<p>[3]
<a class="moz-txt-link-freetext" href="https://www.europarl.europa.eu/committees/fr/itre/home/members">https://www.europarl.europa.eu/committees/fr/itre/home/members</a> <br>
</p>
<p>[1]
<a class="moz-txt-link-freetext" href="https://github.blog/2023-07-12-no-cyber-resilience-without-open-source-sustainability/">https://github.blog/2023-07-12-no-cyber-resilience-without-open-source-sustainability/</a>
<br>
</p>
<p> <a class="moz-txt-link-freetext" href="https://linuxfoundation.eu/cyber-resilience-act">https://linuxfoundation.eu/cyber-resilience-act</a></p>
<p> <br>
</p>
<p>[2]
<a class="moz-txt-link-freetext" href="https://www.europarl.europa.eu/meetdocs/2014_2019/plmrep/COMMITTEES/ITRE/DV/2023/07-19/11-CA_CRA_EN.pdf">https://www.europarl.europa.eu/meetdocs/2014_2019/plmrep/COMMITTEES/ITRE/DV/2023/07-19/11-CA_CRA_EN.pdf</a><br>
</p>
<p>[0] ---------------------------</p>
<p>Summary by Régis on the basis of the current submitted text<br>
</p>
<p><br>
</p>
<p><a class="moz-txt-link-freetext" href="https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022PC0454">https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022PC0454</a><br>
<br>
<br>
<br>
We will be submitted explicitly in clause [10]:<br>
(10)In order <br>
not to hamper innovation or research, free and open-source
software developed or supplied outside the course of a commercial
activity should not be covered by this Regulation. This is<br>
in particular the case for software, including its source code
and modified versions, that is openly shared and freely
accessible, usable, <br>
modifiable and redistributable. In the context of software, a
commercial activity might be characterized not only by charging a
price for a product, but also by charging a price for technical
support services, by providing a software platform through which
the manufacturer monetises other services, or by the use of
personal data for reasons other than exclusively for <br>
improving the security, compatibility or interoperability of the
software.<br>
<br>
<a class="moz-txt-link-freetext" href="https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022PC0454">https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52022PC0454</a><br>
<br>
<br>
<br>
## Are we a critical product ? art 6 chapt. 2 <br>
<br>
the cybersecurity-related functionality of the product with
digital elements, and whether the product with digital elements
has at least one of following attributes:<br>
<br>
(i)it is designed to run with elevated privilege or manage
privileges;<br>
<br>
(ii)it has direct or privileged access to networking or computing
resources;<br>
<br>
(iii)it is designed to control access to data or operational
technology;<br>
<br>
(iv)it performs a function critical to trust, in particular
security functions such as network control, endpoint security, and
network protection.<br>
<br>
(b)the intended use in sensitive environments, including in
industrial settings or by essential entities of the type referred
to in the Annex [Annex I] to the Directive [Directive XXX/XXXX
(NIS2)];<br>
<br>
(c)the intended use of performing critical or sensitive functions,
such as processing of personal data;<br>
<br>
(d)the potential extent of an adverse impact, in particular in
terms of its intensity and its ability to affect a plurality of
persons;<br>
<br>
(e)the extent to which the use of products with digital elements
has already caused material or non-material loss or disruption or
has given rise to significant concerns in relation to the
materialisation of an adverse impact.<br>
<br>
<br>
_IMO any data management tool falls into this category. Even
worse, i think any desktop tool falls into (ii)_ <br>
_However, the Annex III doesn't list anything alike QGIS is doing,
either desktop or web. We might argue that we are not in the list_<br>
<br>
<br>
<br>
## What are we submitted to exaclty ? <br>
<br>
- CE marking will be mandatory<br>
- this must be done following an auto control process. UE state
members will conduct random audits. <br>
- 42 months of transitional period <br>
- each Member state will design a monitoring authority<br>
- each member State will design a certifying authority<br>
- the European agency is ENISA , which coordinates the work at
european level<br>
- Fees can go up to 15 Million euros or 2.5% of the mondial
turnover<br>
- fees depend on Member state and not europe. <br>
<br>
## Requirements (cherry picked)<br>
<br>
- products must be delivered without any known vulnerability.
_this sound like somewhat utopic_ <br>
- products must log internal events to allow auditing of modified
data, network access . _utopic too_<br>
- vulnerabilities must be fixed by security updates , if
applicable by automatic updates and user notifications incentives.
_sounds reasonable_<br>
- we must list our CVEs. _sounds feasable with code scanner tools.
Should we also scan dependencies ? Probably yes._ <br>
- fix issues with no delay _sounds utopic, but I think if we deal
with higer priority and adress issues, that should be enough given
the fuzzy interpretation we can expect_<br>
- disclose immediatly fixed vulnerabilities. _sounds inline with
our practices_<br>
- have a formal process for cve raising (mail adress etc )<br>
- go towards a system making security updates easy and fast. This
raises again the long standing issue of automatic updates. <br>
- administrative burden of UE conformity declaration. It doesn't
look like something recurrent. <br>
<br>
## Questions<br>
<br>
- compatibility with GNU licence and impact that costs are relying
on the user and not the developpers ?<br>
<br>
- if we should go<br>
<br>
<br>
## How to act ? <br>
<br>
### Raise our voice in every possible channel :<br>
<br>
- <a class="moz-txt-link-freetext" href="https://linuxfoundation.eu/cyber-resilience-act">https://linuxfoundation.eu/cyber-resilience-act</a><br>
- discord channel <a class="moz-txt-link-freetext" href="https://discord.com/invite/g5FzSx2hRY">https://discord.com/invite/g5FzSx2hRY</a><br>
<br>
- [ ] petitions on behalf of qgis.org , osgeo, individual<br>
<br>
<br>
<br>
<br>
</p>
<br>
<div id="grammalecte_menu_main_button_shadow_host" style="width:
0px; height: 0px;"></div>
</body>
</html>