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

Alessandro Pasotti apasotti at gmail.com
Mon Dec 19 06:33:48 PST 2016 

On Mon, Dec 19, 2016 at 3:26 PM, Luigi Pirelli <luipir at gmail.com> 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 <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
>



-- 
Alessandro Pasotti
w3:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20161219/385af60e/attachment-0001.html>

More information about the Qgis-developer mailing list