[Qgis-developer] Plugin [1102] AequilibraE approval notification.

Luigi Pirelli luipir at gmail.com
Mon Dec 19 06:04:12 PST 2016 

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 <matthias at opengis.ch> 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 <matthias at opengis.ch> 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 <luipir at gmail.com>
>>> 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 <veigacamargo at gmail.com>
>>>> 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
>>>>> <luipir at gmail.com> 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,  <noreply at qgis.org> 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
>>>>>>>  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
>>>
>>>
>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

More information about the Qgis-developer mailing list