[Qgis-psc] The security project for QGIS

[Even Rouault]

Vincent,

excellent, and ambitious, initiative.

A few points (they don't necessarily need to all be addressed at that 
earlier stage):

- Regarding putting in place static code analysis (A.1) or dynamic code 
analysis (B.1), does that cover only putting into places the tools & 
automation, or also addressing issues that are raised? There's a huge 
difference in terms of effort. For a project of the size of QGIS I would 
expect about 1000+ issues (1.7 MLoC * 1 defect per thousand line of code 
= 1700)  raised for each new analysis tool added. A lot are 5-minute 
type of fix by knowledgeable developers. Some can be really hard to fix, 
requiring API or design changes. A very rough estimate could be that it 
is a 1 man-year level of effort to address 90% of the issues reported, 
per analyzer added.

- Regarding dynamic analysis, thinking in particular to something like 
ossfuzz, I agree this enters the "difficulty: hard" since it requires 
static linking (at least last time I checked). And that also requires 
writing dedicated test programs for fuzzing purposes, exercising 
different part of QGIS, like parsing project files, or other identified 
attack surfaces etc.

- Regarding hardening processes (thinking to items like Developer 
Certificate of Origin or Access management systems for developers), 
there's the risk of making QGIS contribution too hard to to the point 
where it could deter new contributors, particularly if they contribute 
on their personal time. Our current processes with a strong CI might 
already discourage the less motivated ones. Some difficult balance to 
find here.

- Regarding raw pointer elimination, that's going to be hard indeed. The 
main obstacle I see is that the QT API itself does not use use smart 
pointers. So the bug surface will move at the boundary where QGIS smart 
pointers are converted to raw pointers (misuse of .get() vs .release()). 
Smart pointers also doesn't make code memory safe per se, there are 
still lots of opportunities to shoot yourself in the foot, so the title 
"Make Code Memory Safe" is probably too ambitious. It could only 
achieved by using a language like Rust. I didn't look at the maturity of 
the Rust bindings for QT ;-)

- I see GDAL, PROJ, GEOS being mentioned in the scope of the initiative. 
What are your thoughts regarding this? My assessment is that PROJ and 
GEOS have a low to medium attack surface from a security point of view. 
By its own nature (reading hundreds of file formats), GDAL one has a 
huge one obviously. I'd tend to think we are rather in a good shape 
though, having taken steps for many years putting in place static & 
dynamic analysis, and fixing most issues. That's a never ending fight 
though. Regarding fuzzing, I know that some drivers are in blind spots 
of fuzzing tools since they would require dedicated fuzzers to be 
written to exercice them. Not to mention that vulnerabilities might 
belong to lower level components, some of which have no 
willingness/capacity to address such issues or even consider contributed 
fixes.

- I don't know if it is a real risk or if I'm a bit paranoid, but one 
side effect of displaying a focus on security could be that "parasite" 
actors, thinking here to bug bounty chasers, developers of new analysis 
tools, could see QGIS as a new playground for their feats, so the 
security team might be overwhelmed by reports of varying relevance and 
quality...

Even


Le 29/11/2024 à 11:12, Vincent Picavet via QGIS-PSC a écrit :
> Hi PSC,
>
> Oslandia will be launching soon the "Security project for QGIS". I 
> explain the project in details below.
>
> New European regulations like NIS2 and CRA, as well as other 
> international or local regulations ( e.g. CISA ) will be activated 
> within the next couple of years. They require software and software 
> producers to rise their cybersecurity practices. OpenSource softwares, 
> while usually having a special treatment, are concerned too.
>
> As for QGIS, we consider that we are behind what would be sufficient 
> to comply with these regulations. We also do not fulfill requirements 
> coming from our end-users, in terms of overall software quality 
> regarding security, processes in place to ensure trust in the supply 
> chain, and overall security culture in the project.
>
> We have been discussing this topic with clients having large 
> deployments of QGIS and QGIS server, and they stressed the issue, 
> stating that cybersecurity was one of their primary concerns, and that 
> they are willing to see the QGIS project move forward in this area as 
> soon as possible.
>
> Oslandia, with other partners and backed by some of its clients, 
> intends to launch the "Security project for QGIS" soon : we identified 
> key topics where improvements can be done, classified them, and 
> created work packages to work on, with budget estimations. We intend 
> to do a call for funding for this project, in order to get actual 
> improvements over 2025 and 2026.
>
> We intend to work closely with the QGIS community, QGIS.org, 
> interested partners and users. Part of the work are improvements over 
> the current system, other require changes to processes or developer's 
> habits. Working closely with the user and developer's community to 
> raise our security awareness is fully part of the project.
>
> You can see the current draft of the proposal here :
> https://pad.oslandia.net/vas3e9TUTQKJVSjTseVXrQ?both#
>
> Please do not share this URL publicly, as it is still a draft, and 
> will be moved to an official web page soon.
>
> We know that this is an ambitious project, and that some parts will be 
> difficult to achieve, but we think that QGIS cannot ignore the current 
> trend in cybersecurity enforcement, and we know that regulations and 
> clients requirements will force us to move forward anyway. Planning 
> ahead and taking the issue seriously with the right amount of 
> resources and efforts seems a better way to go than being constrained 
> to do things in a hurry later on.
>
> We intend to launch the project soon, as some clients want to be able 
> to fund it on 2024 budgets, and start working as early as January. We 
> will first have a direct approach to potential funders and partners 
> though, before making a public call for funding ( most probably before 
> end of 2024 ).
>
> Sponsors for this project will be QGIS users directly funding the 
> project.
>
> Partners for this project will be :
> - organizations officially supporting the project and help communicate 
> and raise funds
> - organizations contributing time, effort, expertise to help the project
> - subcontractors for parts of the project
>
> As for subcontracting, some items are already identified and dedicated 
> to partners, most of them will still have to be defined after.
>
> As for now, apart from Oslandia, OPENGIS.ch is already an official 
> partner.
>
> We wanted to let the PSC / QGIS.org know about the project before 
> enlarging the audience, so that :
> - A. you can give us feedback on the project globally, and the content 
> specifically
> - B. raise any questions you would like to be answered privately or 
> publicly
> - C. indicate your thoughts on how QGIS.org would want to be 
> integrated into the project
> - D. validate project name, logo and URL
>
> As for C, we will state clearly that this project is not a QGIS.org 
> initiative, but a project initiated by Oslandia and partners. QGIS.org 
> could be a partner though, and we would be pleased if it is, but it is 
> clearly not mandatory. Your decision, without any pressure ( can be 
> later on too ).
> As for budget as well, we do not ask for any contribution from 
> QGIS.org, but QGIS.org could allocate some funding, either as sponsor 
> for items already included in work packages, or for additional 
> complimentary items ( I would rather opt for this option, e.g. 
> everything related to external reviews, community meetings, legal 
> stuff…).
> Also, we will recommend for any sponsor willing to contribute less 
> than 5000€, to fund QGIS.org instead through donations, as we do not 
> want to deal with small contributions for this project ( admin burden 
> too high ).
>
> As for D, what we need from PSC ASAP is a validation for us to be 
> allowed to use the following :
> - the project name "Security project for QGIS". Note that we avoided 
> naming it "QGIS Security project", to better identify that the project 
> is not initiated by QGIS.org. As said above, we will be clear in the 
> project presentation about affiliation.
> - the project logo 
> : https://pad.oslandia.net/uploads/68ed0fc7-a6e3-4a93-8b6a-34ba2335c7dc.png
> - the url we intend to use : security.qgis.oslandia.com . Again, it 
> makes no doubt on affiliation.
>
> Should you have any remark on these items, do not hesitate to raise them.
>
> Next step are :
> - [x] contact QGIS PSC to present the initiative
> - [ ] integrate feedbacks into the project presentation
> - [ ] finish project presentation material
> - [ ] contact some more potential partners
> - [ ] get first pledges from users for WP1
> - [ ] launch public call for funding
>
> I am available to discuss the matter, do not hesitate to contact me 
> for further info or discussion.
>
> Best regards,
> Vincent
>
>
>
-- 
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.