<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Paolo<div class=""><br class=""></div><div class="">I did a pass over to mainly make it a little easier to read. Here is my edited version. My comments follow after:</div><div class=""><br class=""></div><div class="">-----</div><div class=""><br class="">The core team of QGIS strives hard to provide the most advanced and<br class="">user friendly GIS for free use by everyone. As a corollary, we are very<br class="">careful about security, both of our source code and of the installers,<br class="">using state of the art technology and practices to ensure no malicious<br class="">or dangerous code ever hits end users.<br class=""><br class="">The vast majority of our plugins (listed in <a href="http://plugins.qgis.org/" class="">http://plugins.qgis.org/</a> and<br class="">inside your copy of QGIS) are however developed by third parties, either<br class="">individuals, companies, and institutions. As such, they are outside our<br class="">direct control, and might represent a security risk. We are convinced<br class="">the risk is small, because of many factors including the "many eyes"<br class="">principle (the code is visible to everybody, and in use by thousands of<br class="">people), but cannot exclude it the possibility that someone tries to inject malicious code into a plugin.<br class=""><br class="">In order to improve the situation, we looked into the opportunity of<br class="">implementing automatic tools to scan plugins, before their publication,<br class="">and spot potential problems. This approach would be very difficult and costly, and<br class="">easy to circumvent. <br class=""><br class="">We decided therefore to implement a simple yet robust approach to<br class="">security, based on the best available evidence: trust based on personal<br class="">knowledge. The current implementation therefore lists all plugins by<br class="">well known members of the QGIS community, that regularly meet twice a<br class="">year on the QGIS developer meetings, and are in almost daily contact<br class="">with the core team, as "trusted". All the rest (and there are wonderful,<br class="">reliable, robust, and useful plugins in the list) miss the "trusted"<br class="">label. We would like to stress this point, does not mean that they are<br class="">not trusted, but only that we cannot reasonably guarantee they are.<br class=""><br class="">Of course, we would be delighted if a side effect of this choice would<br class="">be to stimulate a more active involvement of plugin developers in the<br class="">community. All plugin developers are therefore invited to join us at one<br class="">of the next developer meetings (AKA HackFest).</div><div class=""><br class=""></div><div class="">---------</div><div class=""><br class=""></div><div class="">I agree with Anita - I don't think that attending Hackfest meetings is a fair requirement. If it is someone we know well via other channels (e.g. Mathieu Pellerin) I think we could quite comfortable give them trusted status.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">"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."</div><div class=""><br class=""></div><div class="">What do you think?</div><div class=""><br class=""></div><div class="">Regards</div><div class=""><br class=""></div><div class="">Tim</div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class="">On 18 Aug 2016, at 7:48 PM, Paolo Cavallini <<a href="mailto:cavallini@faunalia.it" class="">cavallini@faunalia.it</a>> wrote:<br class=""><br class="">Il 18/08/2016 19:33, Giovanni Manghi ha scritto:<br class=""><br class=""><blockquote type="cite" class="">could someone then please tag as trusted<br class=""><br class=""><a href="http://plugins.qgis.org/plugins/postgis_geoprocessing/" class="">http://plugins.qgis.org/plugins/postgis_geoprocessing/</a><br class="">http://plugins.qgis.org/plugins/ntv2_transformations/<br class=""></blockquote><br class="">Done, thanks Giovanni.<br class=""><br class="">-- <br class="">Paolo Cavallini - <a href="http://www.faunalia.eu" class="">www.faunalia.eu</a><br class="">QGIS & PostGIS courses: <a href="http://www.faunalia.eu/training.html" class="">http://www.faunalia.eu/training.html</a><br class="">_______________________________________________<br class="">Qgis-psc mailing list<br class=""><a href="mailto:Qgis-psc@lists.osgeo.org" class="">Qgis-psc@lists.osgeo.org</a><br class="">http://lists.osgeo.org/mailman/listinfo/qgis-psc<br class=""></blockquote><br class=""><div class=""><span><img height="65" width="59" apple-inline="yes" id="B5CDA2B7-5430-4077-A577-A3550242FF9A" apple-width="yes" apple-height="yes" src="cid:879A6E78-CA46-47B2-AA0E-1810BD833229" class=""></span><br class=""><br class=""><br class="">---<br class=""><br class="">Tim Sutton<br class="">QGIS Project Steering Committee Chair<br class=""><a href="mailto:tim@qgis.org" class="">tim@qgis.org</a><br class=""><br class=""><br class=""><br class=""></div><br class=""></div></body></html>