[QGIS-Developer] Existing plugin versions should not be marked with "security issues"

[Greg Troxel]

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!)