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

Luigi Pirelli luipir at gmail.com
Mon Dec 19 06:26:08 PST 2016 

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

**************************************************************************************************
* 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 <apasotti at gmail.com> wrote:
> On Mon, Dec 19, 2016 at 1:21 PM, 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
>
>
>
> 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 <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.
>> _______________________________________________
>> 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
>
>
>
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it

More information about the Qgis-developer mailing list