Hi
> On 10 Jul 2018, at 08:03, Richard Duivenvoorde <rdmaili...@duif.net> wrote: > > On 07/10/2018 06:15 AM, shiva reddy wrote: >> I don't think so. Since all plugins goes through approval mechanism, I >> think it is not unsafe. Rather increase the plugin user base. >> Even if we want to not allow this .In that case, We should have >> mechanism by which QGIS itself does installation of external >> dependencies based on approved plugin's metadata. >> It will ease the life of plugin developers for sure. >> >> Shiva > >> Just taking a step back here -- is this something we actually want to >> support/allow in plugins? >> >> Seems to me like it opens the door for all sorts of security issues. >> >> Nyall > > @shiva: the 'approval mechanism' is done by humans, and a lot of work, > as there are a lot of dev releasing small changes of their plugins... > So I would not count on that for security. > We have been talking about running some (security) rules over the plugin > sources before approval, but... nobody implemented it yet. And when we do I think we will probably be chasing our tails a lot…. > > @nyall: as I said earlier in this thread, we have been talking about > adding the pip-command in the metadata.txt. That is better, yes? Doesn’t that just move the issue to a different place. The fact is you can put anything you like in PyPi including some nefarious module that does rm -rf on your file system, then just pull it in from the metadata.txt requirements list and run it. So I dont think we gain anything. > > I agree with you, Shiva's way has some security issues, but I was > thinking that we could do a grep on the sources of a plugin > automatically, to search for the subprocess line, and check if something > else then pip is called? > It IS a friendly way of installing (well, as we keep it in user space...). > If we could make it being installed in a QGIS Virtual Env or even in a > venv per plugin that would be safer? There are many other valid uses of using subprocess (e.g. running some gdal command) so I don’t think that gains us much either. The venv thing we discussed in the past there are issues (Martin can fill in blanks here too as he was part of the discussion): * For a true ’sandbox for plugins’ solution, the QGIS python interpreter and the one used by the plugin need to be the same otherwise you cannot use the API. * Plugins should be able to use code from each other and build on each other (e.g. processing plugins) so they should be able to import each other’s modules. Or maybe we should make a rule that we dont support this. * Env’s should be per-plugin so that two plugins could have different listed dependency versions which goes against the above point I think the whole thing is too messy other than perhaps having one global (or one per profile) based venv with has system modules included from QGIS python lib. My preferred solution is till to in time to refine the plugins to ‘official’ and ‘unofficial’ plugins. Official plugins would undergo some formal (paid? Manual?) detailed code review and are accepted as safe. Apple does this in their walled garden (no doubt with lots of automation) and though many FOSS people complain about walled gardens, there are valid, good reasons for their existence. We could also provide the ‘Wild West’ garden for unofficial / unreviewed plugins so that nobody loses out… Regards Tim > > Others? > > Regards, > > Richard Duivenvoorde > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org <mailto:QGIS-Developer@lists.osgeo.org> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > <https://lists.osgeo.org/mailman/listinfo/qgis-developer> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > <https://lists.osgeo.org/mailman/listinfo/qgis-developer> — Tim Sutton Co-founder: Kartoza Ex Project chair: QGIS.org Visit http://kartoza.com <http://kartoza.com/> to find out about open source: Desktop GIS programming services Geospatial web development GIS Training Consulting Services Skype: timlinux IRC: timlinux on #qgis at freenode.net
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
