Sorry, this entry is only available in French.

The “Security project for QGIS” is now public ! Pledge now !

The goal of this project is to mutualize funding to improve QGIS security to the highest levels.

Oslandia and other involved partners, especially OPENGIS.ch are OpenSource “pure players” and main contributors to QGIS. This project is an initiative by Oslandia and is endorsed by the QGIS.org association. We work closely with the community of developers, users and stakeholders of QGIS. This project involves QGIS core committers willing to advance QGIS security.

Global context

New regulations like NIS2 and CRA in Europe, as well as other international or local regulations will be activated within the next couple of years. They require software and software producers to improve their cybersecurity practices. OpenSource softwares, while usually having a special treatment, are concerned too. Estimated costs of CRA impact on an opensource project amounts to +30%.

As for QGIS, we consider that the project stays 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 is one of their primary concerns, and that they are willing to see the QGIS project move forward in this area as soon as possible. QGIS faces the risk of IT departments blocking QGIS installations if they consider the project not having enough consideration for security.

Also, requests to [email protected] have grown significantly.

Project goals

Oslandia, with other partners and backed by clients and end-users, launch the “Security project for QGIS” : we identified key topics where security improvements can be achieved, classified them, and created work packages to work on, with budget estimations.

• The main goal is simple : raise the cybersecurity level for the QGIS project
• Fulfill cybersecurity requirements from regulations and end-users
• Make QGIS an example of security-aware OpenSource project, helping other OSGeo projects to improve

While QGIS and QGIS server are the main components on which this project focus, improving QGIS security as a whole also needs to consider underlying libraries ( e.g. GDAL/OGR, PROJ, GEOS…).

This project is a specific effort to raise the level of security of QGIS. Maintaining security in the long term will need further efforts, and we encourage you to sponsor QGIS.org, becoming a sustaining member of QGIS.

Memory safety, signing binaries, supply chain management, contributing processes, plugin security, cybersecurity audits and much more topics are included in this project. You can see all items as well as work packages on the dedicated website :

https://security.qgis.oslandia.com

Project organization – Pledge !

Any organization interested in improving QGIS security can contribute to funding the project. We are looking for an estimated total amount of 670K€, divided into 3 work packages Pledge now !

Once funded, Oslandia and partners will start working on Work Package 1 in 2025. 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.

We will deliver improvements in 2025 and until 2027. You can see the full list of topics, work packages and estimated budget on the project’s dedicated page : security.qgis.oslandia.com . You are invited to participate, but also to help spread the word and recruit other contributors !

We want to especially thank Orange France for being a long-time supporter of OpenSource in general and QGIS particularly, and the first backer of the Security Project for QGIS !

Should you have any question, or need further material to convince other stakeholders, get in touch !

Sorry, this entry is only available in French.

According to the definition of software quality given by french Wikipedia

An overall assessment of quality takes into account external factors, directly observable by the user, as well as internal factors, observable by engineers during code reviews or maintenance work.

I have chosen in this article to only talk about the latter. The quality of software and more precisely QGIS is therefore not limited to what is described here. There is still much to say about:

• Taking user feedback into account,
• the documentation writing process,
• translation management,
• interoperability through the implementation of standards,
• the extensibility using API,
• the reversibility and resilience of the open source model…

These are subjects that we care a lot and deserve their own article.

I will focus here on the following issue: QGIS is free software and allows anyone with the necessary skills to modify the software. But how can we ensure that the multiple proposals for modifications to the software contribute to its improvement and do not harm its future maintenance?

Self-discipline

All developers contributing to QGIS code doesn’t belong to the same organization. They don’t all live in the same country, don’t necessarily have the same culture and don’t necessarily share the same interests or ambitions for the software. However, they share the awareness of modifying a common good and the desire to take care of it.

This awareness transcends professional awareness, the developer not only has a responsibility towards his employer, but also towards the entire community of users and contributors to the software.

This self-discipline is the foundation of the quality of the contributions of software like QGIS.

However, to err is human and it is essential to carry out checks for each modification proposal.

Automatic checks

With each modification proposal (called Pull Request or Merge Request), the QGIS GitHub platform automatically launches a set of automatic checks.

Example of proposed modification

Result of automatic checks on a modification proposal

The first of these checks is to build QGIS on the different systems on which it is distributed (Linux, Windows, MacOS) by integrating the proposed modification. It is inconceivable to integrate a modification that would prevent the application from being built on one of these systems.

The tests

The first problem posed by a proposed modification is the following “How can we be sure that what is going to be introduced does not break what already exists?”

To validate this assertion, we rely on automatic tests. This is a set of micro-programs called tests, which only purpose is to validate that part of the application behaves as expected. For example, there is a test which validates that when the user adds an entry in a data layer, then this entry is then present in the data layer. If a modification were to break this behavior, then the test would fail and the proposal would be rejected (or more likely corrected).

This makes it possible in particular to avoid regressions (they are very often called non-regression tests) and also to qualify the expected behavior.

There are approximately 1.3 Million lines of code for the QGIS application and 420K lines of test code, a ratio of 1 to 3. The presence of tests is mandatory for adding functionality, therefore the quantity of test code increases with the quantity of application code.

In blue the number of lines of code in QGIS, in red the number of lines of tests

There are currently over 900 groups of automatic tests in QGIS, most of which run in less than 2 seconds, for a total execution time of around 30 minutes.

We also see that certain parts of the QGIS code – the most recent – are better covered by the tests than other older ones. Developers are gradually working to improve this situation to reduce technical debt.

Code checks

Analogous to using a spell checker when writing a document, we carry out a set of quality checks on the source code. We check, for example, that the proposed modification does not contain misspelled words or “banned” words, that the API documentation has been correctly written or that the modified code respects certain formal rules of the programming language.

We recently had the opportunity to add a check based on the clang-tidy tool. The latter relies on the Clang compiler. It is capable of detecting programming errors by carrying out a static analysis of the code.

Clang-tidy is, for example, capable of detecting “narrowing conversions”.

Example of detecting “narrowing conversions”

In the example above, Clang-tidy detects that there has been a “narrowing conversion” and that the value of the port used in the network proxy configuration “may” be corrupted. In this case, this problem was reported on the QGIS issues platform and had to be corrected.

At that time, clang-tidy was not in place. Its use would have made it possible to avoid this anomaly and all the steps which led to its correction (exhaustive description of the issue, multiple exchanges to be able to reproduce it, investigation, correction, review of the modification), meaning a significant amount of human time which could thus have been avoided.

Peer review

A proposed modification that would validate all of the automatic checks described above would not necessarily be integrated into the QGIS code automatically. In fact, its code may be poorly designed or the modification poorly thought out. The relevance of the functionality may be doubtful, or duplicated with another. The integration of the modification would therefore potentially cause a burden for the people in charge of the corrective or evolutionary maintenance of the software.

It is therefore essential to include a human review in the process of accepting a modification.

This is more of a rereading of the substance of the proposal than of the form. For the latter, we favor the automatic checks described above in order to simplify the review process.

Therefore, human proofreading takes time, and this effort is growing with the quantity of modifications proposed in the QGIS code. The question of its funding arises, and discussions are in progress. The QGIS.org association notably dedicates a significant part of its budget to fund code reviews.

More than 100 modification proposals were reviewed and integrated during the month of December 2023. More than 30 different people contributed. More than 2000 files have been modified.

Therefore the wait for a proofreading can sometimes be long. It is also often the moment when disagreements are expressed. It is therefore a phase which can prove frustrating for contributors, but it is an important and rich moment in the community life of a free project.

To be continued !

As a core QGIS developer, and as a pure player OpenSource company, we believe it is fundamental to be involved in each step of the contribution process.

We are investing in the review process, improving automatic checks, and in the QGIS quality process in general. And we will continue to invest in these topics in order to help make QGIS a long-lasting and stable software.

If you would like to contribute or simply learn more about QGIS, do not hesitate to contact us at [email protected] and consult our QGIS support proposal.