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

[Matthias Kuhn]

On 12/19/2016 03:04 PM, Alessandro Pasotti wrote:
> On Mon, Dec 19, 2016 at 1:21 PM, Matthias Kuhn <matthias at opengis.ch
> <mailto: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

Are you confident that a no-binary policy is a good indication for
license issues?

License issues can also be triggered by other material like a
copyrighted images or even incompatible open source code (CDDL [1]).

On the other hand, if we have the code uploaded to our plugin service,
the chance is bigger that we realize missing source files and can
communicate with the author.

Regards
Matthias

[1]
https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License

> 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.