[Qgis-psc] Blog post for trusted plugins

[Paolo Cavallini]

Hi all,
any further comments? Can we finalize this?
All the best.

Il 21/08/2016 19:29, Paolo Cavallini ha scritto:
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160822/3d4d6d7c/attachment.sig>