What feels missing from this discussion is stepping back and considering why we have escurity rules and the extent to which users are supposed to be protected from bad behavior by plugins. plugins execute code with the user's privileges, essentially creating https://en.wikipedia.org/wiki/Confused_deputy_problem
It seems there is some intent to have a semi-/mostly-sandbox, where plugins can operate within qgis on the user's data, but not extend to operating system actions that could remove or write other files. A check that is misfiring because it doesn't (can't) understand that code, such as when static analysis says that the SQL arguments are ok, is one thing. But saying "it's ok for this plugin to run arbitrary commands" raises the question of what policy did we want, does the plugin meet it, and if not why are we saying that's ok. It starts to feel like perl's taint method; running a command the user entered is one thing, vs one that came from elsewhere. Perhaps instead of failing plugins and then a culture of ignoring valid results, we should allow annotations of two kinds; A) true scanning false positive (where the scanner is wrong), and B) "the scanner is right but [because] we are deciding the situation is ok", leading to red: scanner failed, not published yellow: at least one type B annotation green: no type B annotations But, it might be that there could be code in the plugin that could escape the sandbox, that wasn't scanned for. I may be off base, but it feels like we're debating the big policy at the micro level based on perceived desired outcomes and deciding to be comfortable with specific plugin behavior because it's useful. (Note that leaving all the doors unlocked is more convenient!) _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
