[Qgis-psc] Blog post for trusted plugins

[Paolo Cavallini]

Hi all,

thanks for comments. Answars to specific points:
* I do not think we are saying one is *forced* to come, just that we
have to know and trust him personally; I tried to clarify this below; if
the wording is not clear enough, could someone suggest a better one?
* as for the security issue, are really in such a weak situation? If so,
I agree with Tim suggestion
* trusted author vs trusted plugin: I agree in princple; I'm not quite
sure how to convey the idea through the plugin manager (it looks weird
to me reading "Trusted author" in the heading of the plugin); if someone
comes up with a nice implementation, it's a +1 from me; otherwise, maybe
the current explanation below could be enough

Based on the comments, I can suggest a few more changes:

===

The core team of QGIS strives hard to provide the most advanced and
user friendly GIS for free use by everyone. As a corollary, we are very
careful about security, both of our source code and of the installers,
using state of the art technology and practices to ensure no malicious
or dangerous code ever hits end users.

The vast majority of our plugins (listed in http://plugins.qgis.org/ and
inside your copy of QGIS) are however developed by third parties, either
individuals, companies, and institutions. As such, they are outside our
direct control, and might represent a security risk. We are convinced
the risk is small, because of many factors including the "many eyes"
principle (the code is visible to everybody, and in use by thousands of
people), but cannot exclude it the possibility that someone tries to
inject malicious code into a plugin.

In order to improve the situation, we looked into the opportunity of
implementing automatic tools to scan plugins, before their publication,
and spot potential problems. This approach would be essentially
impossible and costly, and easy to circumvent.

We decided therefore to implement a simple yet robust approach to
security, based on the best available evidence: trust based on personal
knowledge. The current implementation therefore lists all plugins by
well known members of the QGIS community, that regularly meet twice a
year on the QGIS developer meetings, and are in almost daily contact
with the core team, as "trusted". All the rest (and there are wonderful,
reliable, robust, and useful plugins in the list) miss the "trusted"
label. We would like to stress this point, does not mean that they are
not trusted, but only that we cannot reasonably guarantee they are.

Of course, we would be delighted if a side effect of this choice would
be to stimulate a more active involvement of plugin developers in the
community. All plugin developers are therefore invited to join us at one
of the next developer meetings (AKA HackFest), or anyway become a
recognized, active memebr of the community, so they can be integrated as
"trusted" plugin developers.

---------

I am also quite nervous about some of the statements about how much due
diligence we due in terms of security checking. Maybe we could remove
the first two paragraphs above and just use more generic phrasing like:

"In the core QGIS project, every line of code that gets committed is
subject to peer review when contributed by a non code developer. This
gives us an opportunity to identify and correct inadvertent or
intentional security issues that a developer my introduce to the code
base. By contrast, all of the plugins that are published via the QGIS
plugin repository are reviewed by the plugin developers themselves and
we don't have good insight into how much due diligence is applied to
plugin code management."



-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html