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