It is no about implementation but the concept itself. As soon as there will be an easy way how to provide GRASS GIS processing as a service, somebody will run it without understanding all security ramifications of allowing any input into GRASS. Securing GRASS code would be nice, but so far we are short on high level developers who could do it. I'm not voting against anyone making easy to run GRASS via WPS or REST, I just want to be sure that lack security against various remote threats is kept in mind.
Māris. 2017-05-25 11:24 GMT+03:00 Blumentrath, Stefan <stefan.blumentr...@nina.no>: > Seen this: https://bitbucket.org/huhabla/open-graas? > Cheers > Stefan > ________________________________________ > Von: grass-dev [grass-dev-boun...@lists.osgeo.org] im Auftrag von Maris > Nartiss [maris....@gmail.com] > Gesendet: Donnerstag, 25. Mai 2017 09:42 > An: Pietro > Cc: GRASS developers list > Betreff: Re: [GRASS-dev] Implement a REST API for GRASS > > I assume that both are equally dangerous. My opinion is that GRASS GIS > should not be exposed to any non trustable users, as various smaller > and larger bugs are too common. Unless, of course, it runs inside a > throw-away VM. > > 2017-05-25 10:33 GMT+03:00 Pietro <peter.z...@gmail.com>: >> Dear Māris, >> >> On Wed, May 24, 2017 at 8:52 PM, Maris Nartiss <maris....@gmail.com> wrote: >>> >>> GRASS GIS code has never been developed with security in mind. I would >>> not suggest to run it in a non-trustable environment. >> >> >> Do you think that expose some GRASS modules through a REST API can be more >> dangerous than exposing the same modules through a WPS service? Why? >> >> Pietro > _______________________________________________ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
