On Mon, Dec 19, 2016 at 3:26 PM, Luigi Pirelli <[email protected]> wrote:
> Hi Alessandro > > this can be radical, but has the positive effect to introduce a "best > practice" to develop plugins with external binary dependencies... I > would agree, but what else respect that plugins that now have already > binaries and were accepted? Should be modified! > > Last case from some minutes ago is this just approved plugin with a > jar included https://github.com/enricofer/QgisODK/tree/master/pyxform/ > odk_validate > that came from a nother external foss project. > > Because everyone have to modify it's plugin to move to qgis3 => we > could leave proposal 1) for 2.x and proposal 2) for qgis3.0 giving > time to adapt the plugin to downloading binary from external repo. > > cheers > Luigi Pirelli > > I've just checked on the plugins site where somebody (I believe Paolo) wrote a policy: ... does not contain architecture-dependant binaries ... As I said, I'm in favour of a source-only policy, there are easy technical solutions to download binaries after installation if a plugin requires them and hosting on our plugin site binary blobs that we cannot inspect doesn't look a good idea to me. > ************************************************************ > ************************************** > * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com > * LinkedIn: https://www.linkedin.com/in/luigipirelli > * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli > * GitHub: https://github.com/luipir > * Mastering QGIS 2nd Edition: > * https://www.packtpub.com/big-data-and-business- > intelligence/mastering-qgis-second-edition > ************************************************************ > ************************************** > > > On 19 December 2016 at 15:04, Alessandro Pasotti <[email protected]> > wrote: > > On Mon, Dec 19, 2016 at 1:21 PM, Matthias Kuhn <[email protected]> > wrote: > >> > >> So, the security concern is, that there might be malicious code in > >> there? In case of the sourcecode provided alongside the binary, assuming > >> that potentially the binary might not match the provided code? > >> > >> Possibilities I see: > >> > >> 1) Trust was also the reason for introducing the "trusted author" flag. > >> So maybe we could just build on the same fundament (e.g. require > >> sourcecode always to be present, trust "trusted authors" that their > >> binary matches the code, show a carefully worded warning, that the > >> plugin contains binary libraries provided by "X" and that the user > >> should only install this plugin if he fully trusts "X".). > >> > >> 2) The other way I see is to completely prohibit shipping binaries > >> through our own plugin server. Accepting that plugin devs start to ship > >> their plugins over other infrastructures which results in more > >> fragmentation. > >> > >> 3) Or the third way of offering "code review and signing services" but > >> that will be a lot of work to put into place, maintain and result in a > >> system which is exclusionary to small providers. > >> > >> 4) Or putting our own "build servers" into place, where you can upload > >> source code, the server will compile it and this way make sure, that > >> code and binary match. But given that we have already been dealing with > >> java and cython this morning, and that there are a bazillion other > >> languages out there, that's not gonna be easy. > >> > >> 5) And finally have an official statement that plugins can be shipped > >> through the official repo but that plugins should download compiled libs > >> from a 3rd party page. > >> > >> I would propose to keep the barrier low, given that the security gain by > >> any of the systems is actually very low (except for a very restrictive > >> implementation of 3) which is also maintenance expensive). We probably > >> have to accept that we do not have the power to prevent anything bad > >> happening. > >> > >> Personally I would just go a pragmatic way of 1) delegating trust to the > >> authors and keep plugins on our infrastructure, where we can also nicely > >> ask people to also upload the code to comply with the GPL. > >> > >> Regards > >> Matthias > > > > > > > > I think that the original intention for source-only plugins was: > > > > 1. make sure that there were no proprietary binary blobs > > 2. security > > > > The second is theoretical since I don't think that we are checking all > > plugins source code line by line, but we could do that if we wanted. > > > > Since we have around 1K plugins and this problems arised two or three > times > > in the last 7 years (and one of those was in fact an attempt to introduce > > proprietary code) I'd stick with the current rule n. 2. > > > > If an author really needs to ship binaries, they can be shipped ship > through > > its own repo or he could make a downloader function inside a > bootstrapping > > plugin. > > > > > > > > > >> > >> > >> On 12/19/2016 12:49 PM, Luigi Pirelli wrote: > >> > In this case the problem is security > >> > > >> > code is available and compiled for most used platforms... but hard to > >> > certify the content of the so/dll. > >> > > >> > any opinion? > >> > Luigi Pirelli > >> > > >> > > >> > ************************************************************ > ************************************** > >> > * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com > >> > * LinkedIn: https://www.linkedin.com/in/luigipirelli > >> > * Stackexchange: http://gis.stackexchange.com/ > users/19667/luigi-pirelli > >> > * GitHub: https://github.com/luipir > >> > * Mastering QGIS 2nd Edition: > >> > * > >> > https://www.packtpub.com/big-data-and-business- > intelligence/mastering-qgis-second-edition > >> > > >> > ************************************************************ > ************************************** > >> > > >> > > >> > On 19 December 2016 at 09:40, Matthias Kuhn <[email protected]> > wrote: > >> >> Hi all > >> >> > >> >> What's the main goal? Code availability? Security? Platform > >> >> independency? > >> >> Just curious. > >> >> > >> >> All the best > >> >> Matthias > >> >> > >> >> On December 19, 2016 9:25:29 AM GMT+01:00, Luigi Pirelli > >> >> <[email protected]> > >> >> wrote: > >> >>> > >> >>> Hi Pedro, > >> >>> > >> >>> Nothing personal, your case is a common case due the fact to many > >> >>> cases where to integrate external executables or shared objects. > >> >>> > >> >>> we can have a way to certificate this binary (e.g. signing process > but > >> >>> could become harder develop plugins, checksums). In the meantime, I > >> >>> strongly suggest to a have a two phase plugin. A first phase that > >> >>> prepare running environment downloading so or dll from someware with > >> >>> the user consensous, and then the running phase. > >> >>> > >> >>> in this way you can facilitate users to access plugin thanks to qgis > >> >>> repo, and turn around plugin limitations that community gave for > user > >> >>> security. > >> >>> > >> >>> regards > >> >>> Luigi Pirelli > >> >>> > >> >>> > >> >>> > >> >>> ************************************************************ > ************************************** > >> >>> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT > com > >> >>> * LinkedIn: https://www.linkedin.com/in/luigipirelli > >> >>> * Stackexchange: > >> >>> http://gis.stackexchange.com/users/19667/luigi-pirelli > >> >>> * GitHub: https://github.com/luipir > >> >>> * Mastering QGIS 2nd Edition: > >> >>> * > >> >>> > >> >>> https://www.packtpub.com/big-data-and-business- > intelligence/mastering-qgis-second-edition > >> >>> > >> >>> > >> >>> ************************************************************ > ************************************** > >> >>> > >> >>> > >> >>> On 19 December 2016 at 08:25, Pedro Camargo <[email protected] > > > >> >>> wrote: > >> >>>> > >> >>>> Hi Luigi and Paolo, > >> >>>> > >> >>>> I corrected the problems you pointed out with > AequilibraE > >> >>>> and > >> >>>> > >> >>>> re-uploaded it. > >> >>>> > >> >>>> Luigi's concern with malicious code is a very valid one, and I > would > >> >>>> actually appreciate to have a manner to have it checked. However, > I > >> >>>> would > >> >>>> appreciate if we could find a solution that does not prevent us > from > >> >>>> having > >> >>>> plugins that are compiled. > >> >>>> > >> >>>> As Luigi pointed out, the code is written in Cython to increase > >> >>>> performance > >> >>>> of the software, but it is still 5.5x slower than the proprietary > >> >>>> software > >> >>>> that I used as a benchmark. In a nutshell, if it cannot be > compiled, > >> >>>> it > >> >>>> will > >> >>>> never fly. So I would ask you guys to be considerate of this > point. > >> >>>> > >> >>>> My concerns might not even be valid, and I do apologize if that is > >> >>>> the > >> >>>> case. > >> >>>> I just must admit that, as an amateur software developer, I miss > >> >>>> some of > >> >>>> the > >> >>>> jargon used here when talking about more technical issues on > >> >>>> software > >> >>>> development. > >> >>>> > >> >>>> Cheers, > >> >>>> Pedro > >> >>>> > >> >>>> On Mon, Dec 19, 2016 at 7:18 AM, Luigi Pirelli > >> >>>> <[email protected]> wrote: > >> >>>>> > >> >>>>> > >> >>>>> Hi List > >> >>>>> > >> >>>>> The Binary problem (?): > >> >>>>> In this recently added plugin I can find cython modules > precompiled > >> >>>>> in > >> >>>>> forms odf pyd, or so. (and relative cython code) > >> >>>>> Following the presentation in: > >> >>>>> https://www.youtube.com/watch?v=zz3jbM_JBTo > >> >>>>> I understand that the reason is performance, but how to prevent > >> >>>>> loading malicious shared objects? > >> >>>>> > >> >>>>> * probably we should start to plan a safe infrastructure to allow > >> >>>>> uploading plugin with compiled modules... any idea other than a > >> >>>>> simple > >> >>>>> checksum? > >> >>>>> > >> >>>>> The license problem (?): > >> >>>>> other question is regarding the cython algorithm. I can read in > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> https://github.com/AequilibraE/AequilibraE/blob/ > master/aequilibrae/paths/AoN.pyx#L23 > >> >>>>> "Codes for route ennumeration, DAG construction and Link nesting > >> >>>>> were > >> >>>>> written by Pedro Camargo (2013) and have all their rights > reserved > >> >>>>> to > >> >>>>> the author" > >> >>>>> > >> >>>>> Obviously the author has right reserved, an in the same code the > >> >>>>> author refer to the LICENSE.txt that is a standard GPL license: > >> >>>>> here: > >> >>>>> > >> >>>>> > >> >>>>> https://github.com/AequilibraE/AequilibraE/blob/ > master/aequilibrae/paths/AoN.pyx#L18 > >> >>>>> and here: > >> >>>>> https://github.com/AequilibraE/AequilibraE/blob/ > master/LICENSE.TXT > >> >>>>> > >> >>>>> how should we have to read the "right reserved" sencence by the > >> >>>>> author? > >> >>>>> > >> >>>>> regards > >> >>>>> Luigi Pirelli > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> ************************************************************ > ************************************** > >> >>>>> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo > DOT > >> >>>>> com > >> >>>>> * LinkedIn: https://www.linkedin.com/in/luigipirelli > >> >>>>> * Stackexchange: > >> >>>>> http://gis.stackexchange.com/users/19667/luigi-pirelli > >> >>>>> * GitHub: https://github.com/luipir > >> >>>>> * Mastering QGIS 2nd Edition: > >> >>>>> * > >> >>>>> > >> >>>>> > >> >>>>> https://www.packtpub.com/big-data-and-business- > intelligence/mastering-qgis-second-edition > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> ************************************************************ > ************************************** > >> >>>>> > >> >>>>> > >> >>>>> On 18 December 2016 at 14:28, <[email protected]> wrote: > >> >>>>>> > >> >>>>>> > >> >>>>>> Plugin AequilibraE approval by pcav. > >> >>>>>> The plugin version "[1102] AequilibraE 0.3.3" is now approved > >> >>>>>> Link: http://plugins.qgis.org/plugins/AequilibraE/ > >> >>>>>> ________________________________ > >> >>>>>> > >> >>>>>> Qgis-developer mailing list > >> >>>>>> [email protected] > >> >>>>>> List info: http://lists.osgeo.org/mailman/listinfo/qgis- > developer > >> >>>>>> Unsubscribe: > >> >>>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer > >> >>> > >> >>> > >> >>> ________________________________ > >> >>> > >> >>> Qgis-developer mailing list > >> >>> [email protected] > >> >>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > >> >>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer > >> >> > >> >> > >> >> -- > >> >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > >> _______________________________________________ > >> Qgis-developer mailing list > >> [email protected] > >> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > >> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer > > > > > > > > > > -- > > Alessandro Pasotti > > w3: www.itopen.it > -- Alessandro Pasotti w3: www.itopen.it
_______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
