QEP 336: Trusted Projects and Folders

[m-kuhn]

This QEP documents the introduction of a "trusted projects and folders" concept within QGIS.
The focus of this is to increase the security of QGIS by giving users a middle ground between "always accept" allowing code execution and "one time accept" allowing code execution.

This way, users that work in an environment where there are some folders within which projects with "trusted" executable contents are present (typically: an admin managed shared network drive, a project within the local documents/my_fancy_projet folder) will have the possibility to perpetually trust contents within these folders and will no longer get security warnings when opening these but will still receive security warnings when they receive a project by mail.

Based on earlier feedback: alternatives that are NOT in the scope of this:

• Hashing of files: QGIS projects can change quite often (e.g. extents changed), if we trust specific file hashes we again increase the frequency of showing warnings to users
• Cryptography/digital signatures: while adding even more security, this requires managing trusted identities and is an elevated entry barrier and therefore out of scope

Thanks for your feedback 🙏

[nyalldawson]

For reader reference -- there were some concerns raised against the earlier version of this QEP (see #296)

[nyalldawson]

@m-kuhn how would trust be stored? Would this just be storing paths inside a QSettings value? If so, how would we prevent malicious plugins/scripts from manipulating this value?

I'd personally like to see more technical detail included in this proposal -- currently it's only showing the interface, but I think for a security related proposal like this we need to know exactly how things will be handled from a technical perspective in order to make an informed vote.

I'm concerned that this is potentially going to be something which appears to add a level of security for users, but is too limited in scope and circumstances where it can be safely used to have much widespread value.

[Guts]

It looks like the VS Code mechanism, right? Well, it's an interesting idea I guess even if I find those "trusted folders" message more dev friendly than user friendly.

[3nids]

@m-kuhn how would trust be stored? Would this just be storing paths inside a QSettings value? If so, how would we prevent malicious plugins/scripts from manipulating this value?

If there is a malicious plugin enabled already, then it has probably or more direct attack possible rather than trusting a specific folder? It can run any code directly.

Also, for the record, the current situation is that running Macro is asked or not depending on a setting already (Qgis::PythonEmbeddedMode::Ask). So a plugin can already set this today.

To me, this QEP just makes the current situation a bit nicer and would make Macro really usable at project level (since if you don't want to be prompted all the time, you need to Always accept them).

I think we have 3 options than can live next to each other:

• trusting folders/project as described in the QEP (trough settings as it is now)
• checking a hash of the code content of the project (to be discussed if that's in scope)
• advanced signing (out of scope)

[m-kuhn]

Thanks for the comment @nyalldawson, I have worked on adding more details.
The list of trusted paths will be stored in QSettings, this is the same place where the current mode is already stored (including "always execute"). In your described attack vector (malicious plugins/scripts), someone will already have the possibility to execute code on the target system. In this scenario it's too late already and having write access to this setting is one of our smaller problems.

@Guts I'm very open to rewording proposals

[m-kuhn]

@3nids

• trusting folders/project as described in the QEP (trough settings as it is now)
• checking a hash of the code content of the project (to be discussed if that's in scope)
• advanced signing (out of scope)

check the latest version (pushed few minutes ago) which added some content around this. Checking a hash is added as a stretch goal, cryptography is out of scope (would IMHO need a dedicated new QEP answering questions that come with such an implementation)

[anitagraser]

Thank you for submitting your proposal to the 2025 QGIS Grant Programme. The 2 week discussion period ends today. At the end of the discussion, the proposal author has to provide a 3-line pitch of their proposal for the voter information material. (For an example from last year check qgis/PSC#58 (comment))

[m-kuhn]

@nyalldawson does the updated version provide the details you were looking for?

[anitagraser]

@nyalldawson could you please have a look? I'd like to wrap up the discussion phase and send out the announcement

[nyalldawson]

@m-kuhn
I don't understand how QgsProject::embeddedCode() will be used. Will this be used initially ONLY to determine that the list is non-empty and that the project has embedded code?

In any case, I won't stand in the way of this proposal. I trust (heh) your work and know you'll follow best effort possible in implementing this.

[m-kuhn]

@m-kuhn I don't understand how QgsProject::embeddedCode() will be used. Will this be used initially ONLY to determine that the list is non-empty and that the project has embedded code?

This would be the MVP, but the stretch goal to also show the code snippets to the user in the decision process is very likely feasible already in an initial implementation.

It's also something that can be used to recheck at runtime. Imagine a newly opened project with no permissions, when the user accepts e.g. project properties, this check can be used to determine if it's necessary to show a request for permissions dialog.

[nyalldawson]

To kick off the formal technical votes I'll add my +1

[3nids]

+1

[alexbruy]

+1

[nirvn]

+1