[Qgis-developer] About my plugins ...

[Even Rouault]

Le dimanche 16 octobre 2016 15:00:21, Tim Sutton a écrit :
> Hi
> 
> In addition to Martin and Nathan's great replies I can add:
> > On 16 Oct 2016, at 6:26 PM, Geo DrinX <geodrinx at gmail.com> wrote:
> > 
> > 
> > [Set up] an automatic procedure (antivirus, automatic control sources to
> > figure out harmful instructions, etc.) that warns the existence of
> > problems.
> 
> This was the first option we looked in to. Do you know of some good tools
> for detecting malicious code in python? It is a hard problem to solve and
> simple things like preventing shell calls are not productive or effective.

I wondered about the same recently for GDAL since I've introduced the 
possibility to write pixel functions in Python in a VRT file ( 
http://gdal.org/gdal_vrttut.html#gdal_vrttut_derived_python ) and wanted to 
have a way to know if they were safe enough or not to be executed by default. 
Sean Gillies pointed to me the following :
"""I found http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html
to be a good intro to the risks of eval'ing untrusted Python code.
Mentioned in there is a notable attempt to make a secure subset of Python
called "pysandbox", but its developer has since declared it "broken by
design": https://lwn.net/Articles/574215/."""
So the conclusion is that sandboxing Python is not believed to be possible, at 
least with the traditionnal CPython interpreter. It appears that PyPy has some 
sandboxing mechanism ( http://doc.pypy.org/en/latest/sandbox.html ) although 
that would probably very tricky to use in the QGIS context (not to mention the 
changes required to use PyPy!). You cannot even trust calls to the native C++ 
QGIS API to be safe in themselves. I'm pretty sure they could be abused to do 
evil things.

> In the end we decided to take a social approach to peer review (which is a
> completely different thing to censorship). By the way I am not averse to
> some limited censorship of plugins if they go against our code of conduct
> [1] and diversity statement [2] for example, I would support banning them.
> I think any reasonable community would expect that of us....
> 
> [1]
> https://www.qgis.org/en/site/getinvolved/governance/codeofconduct/codeofco
> nduct.html [2]
> https://www.qgis.org/en/site/getinvolved/governance/codeofconduct/diversit
> ystatement.html
> 
> 
> A case in point might be a plugin aimed at belittling a particular ethnic
> group or gender identification or which otherwise promotes intolerance.
> Thankfully such a situation has never arisen. Our friendly non-combative
> community is something that makes the QGIS community a joy to participate
> in. Lets try to keep that in mind whilst having this discussion too and
> focus on practical, achievable solutions if you have concern

Another thing to remember is the recent attempts at spamming OSGeo Trac 
instances. Opening the plugin catalog without control would lead to all sort 
of abuses.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com