I also agree, pragmatic solution 1) leave to the user to trust. => a big orange message warning the user!
btw I would add some requirements for plugin devs. e.g list at least the following points: 1) the reason to have compiled parts (I had to look for a foss4g presentation to knwow the reason) 2) the list of shared or executable (I casually discovered them) 3) the link to the source code (in the plugin or external)... I had to grep the code to understand that code was available. 4) guide to build. This can be optional, but I would trust more a user that expose how to reproduce the build. 5) checksums x plugin version All these info can be contained in the plugin homepage in a standard way (template). In this way we don't have to add tags in metadata other than "BEWARE binary inside!" opinions? 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 13:21, 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 > > 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
