Le dimanche 16 octobre 2016 15:00:21, Tim Sutton a écrit :
> In addition to Martin and Nathan's great replies I can add:
> > On 16 Oct 2016, at 6:26 PM, Geo DrinX <geodr...@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
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
> 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
>  and diversity statement  for example, I would support banning them.
> I think any reasonable community would expect that of us....
> nduct.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
Spatialys - Geospatial professional services
Qgis-developer mailing list
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer