On Mon, Dec 19, 2016 at 3:19 PM, Matthias Kuhn <[email protected]> wrote:
> On 12/19/2016 03:04 PM, Alessandro Pasotti wrote: > > On Mon, Dec 19, 2016 at 1:21 PM, Matthias Kuhn <[email protected] > > <mailto:[email protected]>> 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
_______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
