[Qgis-developer] About my plugins ...

Nyall Dawson nyall.dawson at gmail.com
Mon Oct 17 03:41:11 PDT 2016


On 17 October 2016 at 20:20, Geo DrinX <geodrinx at gmail.com> wrote:
> Ok, I will try to be more clear (compatibly with my bad English).
>
> Look at this:  https://goo.gl/WR8LVF
>
> In this project, since now, they (public administration) are using QGIS.
> But, they have today BIG PROBLEMS with crashes.
>
> In the next version of the system, the NEED to have a secure program (and
> possibly open source).
>
> QGIS now is NOT secure.     I explained enough  ?
> Now you understand what's at stake?


I'll just throw this up here for reference:

https://groups.google.com/d/msg/mapinfo-l/ugLeZ9zgyJg/7Bu5-NFozxMJ

That's not even loading python code, just loading a TAB data file into
the program! ;)


Nyall



>
>
> I hope so.    Now somebody wants to see with me how to make sure QGIS
> decently ?
>
> Thank you
>
> Geo
>
> 2016-10-17 11:56 GMT+02:00 Matthias Kuhn <matthias at opengis.ch>:
>>
>> Hi all,
>>
>> I like the *idea* of sandboxing.
>>
>> And we all know and agree it's a complex topic. Hard to impossible to
>> get right (let's admit also that security is always something gray and
>> not black and white - unless the network plug is removed and the room
>> isolated with tin foil). This on the other hand doesn't mean that there
>> are some approaches which are just wrong by design.
>>
>> There is also the question about the level on which sandboxing should
>> happen. E.g. distributing the app with flatpak and relying on its portal
>> mechanism [1] might at one point in the future be a way to get sandboxing.
>>
>> One can also run the app inside some other virtualized environment or
>> even separate physical machine already now for isolation.
>>
>> Maybe Pypy is a way to get there as well from the python side. I don't
>> know. But Nathan is absolutely right that the API offered by Qt builds a
>> big attack surface for which someone has to first bring up a sensible
>> idea for how to lock attackers down without restricting possibilities
>> offered for plugins. Or how to safely decide if running code from
>> external shared libs like the processing lwgeom provider does [2] is
>> something safe to do or not.
>>
>> If someone seriously wants to follow this route:
>>
>> Be prepared to work with specialists in this area and do serious
>> research about possibilities and feasibility first.
>>
>> Be prepared to maintain a separate distribution of QGIS with restricted
>> python access and reduced plugin functionality.
>>
>> Be prepared to get a very big sponsor to back the effort.
>>
>> Matthias
>>
>> [1] https://github.com/flatpak/flatpak/wiki/Portals
>> [2] https://plugins.qgis.org/plugins/processinglwgeomprovider/
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer


More information about the Qgis-developer mailing list