<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 19, 2016 at 3:19 PM, Matthias Kuhn <span dir="ltr"><<a href="mailto:matthias@opengis.ch" target="_blank">matthias@opengis.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/19/2016 03:04 PM, Alessandro Pasotti wrote:<br>
> On Mon, Dec 19, 2016 at 1:21 PM, Matthias Kuhn <<a href="mailto:matthias@opengis.ch">matthias@opengis.ch</a><br>
</span><div><div class="h5">> <mailto:<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>
<br>
</div></div>Are you confident that a no-binary policy is a good indication for<br>
license issues?<br></blockquote><div><br></div><div><br>Of course not, but if we have a binary blob we cannot check what's inside.<br><br></div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
License issues can also be triggered by other material like a<br>
copyrighted images or even incompatible open source code (CDDL [1]).<br>
<br>
On the other hand, if we have the code uploaded to our plugin service,<br>
the chance is bigger that we realize missing source files and can<br>
communicate with the author.<br>
<br>
Regards<br>
Matthias<br>
<br>
[1]<br>
<a href="https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/<wbr>Common_Development_and_<wbr>Distribution_License</a><br>
<div class="HOEnZb"><div class="h5"><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<br>
> times in the last 7 years (and one of those was in fact an attempt to<br>
> introduce 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<br>
> through its own repo or he could make a downloader function inside a<br>
> bootstrapping plugin.<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Alessandro Pasotti<br>w3:   <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div>
</div></div>