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

[Alessandro Pasotti]

On Mon, Dec 19, 2016 at 3:19 PM, Matthias Kuhn <matthias at opengis.ch> wrote:

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


Of course not, but if we have a binary blob we cannot check what's inside.


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



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