[Qgis-developer] Plugin [1152] QgisODK approval notification.

[noreply]

Plugin QgisODK approval by pcav.
The plugin version "[1152] QgisODK 1.1" is now approved
Link: http://plugins.qgis.org/plugins/QgisODK/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Travis failure after introducing spell-checking

[Matthias Kuhn]

Hi Alex,

This should be fixed with 4c43c1f [1]

Caching should be fixed as well for faster testing feedback

Bests
Matthias

[1]
https://github.com/qgis/QGIS/pull/3836/commits/4c43c1f364909adc587aab2377a773101e8d0d22


On 19/12/16 20:07, Alexander Bruy wrote:
> Hi all,
>
> looks like recently introduced spell-checking on Travis leads to
> reporting failures
> even if there are no build errors and all tests passed. This happens
> with PR which
> delete files, see for example
> https://travis-ci.org/qgis/QGIS/builds/184481431#L1400 or
> https://travis-ci.org/qgis/QGIS/builds/185214040#L1401
>

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Luigi Pirelli]

Hi Enrico,

the fact that you weren't aware of a binary in your plugin give me
more reasons to propose an restrictive approach! I agree with you that
in some cases have binaries is a necessity, btw it's not complex to
design the plugin with a setup step.
I agree with Enrico and I continue thinking that we can have a loose
but explicit control by the user documenting any binary available in
the plugin (solution 1).

regards
Luigi Pirelli

**
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
* 
https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
**


On 19 December 2016 at 21:47, Enrico Ferreguti  wrote:
> I wasn't aware to have an executable between my plugin sources.
> In my case I have just removed it from the pyxform library as QgisODK plugin
> does not require XForm validation and resubmit it to the repository.
> But I think that if a library has an open source origin, a corresponding
> licence, and is shared with a community should be normally accepted in a
> qgis plugin bundle even if containing compiled binaries. We have to think
> that gis is computationally intensive and a software like QGis is suited to
> integrate different tools.
> So I think that is not so useful for QGis users to strictly fulfil the "no
> executable" policy. Protecting in this way QGis global stability we could
> lose many opportunities, leaving them to proprietary systems much more
> uninhibited.
>
> Best Regards
> Enrico Ferreguti
>
>
> 2016-12-19 18:44 GMT+01:00 Pedro Venâncio :
>>
>> Hi,
>>
>>
>>>
>>> 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.
>>>
>>>
>>
>> Crayfish plugin uses this approach
>> http://www.lutraconsulting.co.uk/products/crayfish/wiki
>>
>> It download the binary libraries when installing the plugin from QGIS
>> repository.
>>
>> Best regards,
>> Pedro
>>
>>
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Enrico Ferreguti]

I wasn't aware to have an executable between my plugin sources.
In my case I have just removed it from the pyxform library as QgisODK
plugin does not require XForm validation and resubmit it to the repository.
But I think that if a library has an open source origin, a corresponding
licence, and is shared with a community should be normally accepted in a
qgis plugin bundle even if containing compiled binaries. We have to think
that gis is computationally intensive and a software like QGis is suited to
integrate different tools.
So I think that is not so useful for QGis users to strictly fulfil the "no
executable" policy. Protecting in this way QGis global stability we could
lose many opportunities, leaving them to proprietary systems much more
uninhibited.

Best Regards
Enrico Ferreguti


2016-12-19 18:44 GMT+01:00 Pedro Venâncio :

> Hi,
>
>
>
>> 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.
>>
>>
>>
> Crayfish plugin uses this approach http://www.lutraconsulting.co.
> uk/products/crayfish/wiki
>
> It download the binary libraries when installing the plugin from QGIS
> repository.
>
> Best regards,
> Pedro
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Travis failure after introducing spell-checking

[Alexander Bruy]

Hi all,

looks like recently introduced spell-checking on Travis leads to
reporting failures
even if there are no build errors and all tests passed. This happens
with PR which
delete files, see for example
https://travis-ci.org/qgis/QGIS/builds/184481431#L1400 or
https://travis-ci.org/qgis/QGIS/builds/185214040#L1401

-- 
Alexander Bruy
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Pedro Venâncio]

Hi,



> 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.
>
>
>
Crayfish plugin uses this approach
http://www.lutraconsulting.co.uk/products/crayfish/wiki

It download the binary libraries when installing the plugin from QGIS
repository.

Best regards,
Pedro
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Fwd: [Qt5] Compilation problems on windows

[alisovenko]

Hi!
I have a similar problem.
I try to build master qgis with qt 7.5.1 (windows 10 msvc 2013 and 2015).
But have Multiple errors and can not to build qgis:

qgis_core.lib(qgis_core.dll) : error LNK2005: "public: __thiscall
QVector::QVector(class QVector const &)" already defined in qgsgraph.obj [...] 
sgraph.obj
[E:\dev\nextgis.qgis\qgis-master-build\src\analysis\qgis_analysis.vcxproj] 
qgis_core.lib(qgis_core.dll) : error LNK2005: "public: __thiscall
QVector::~QVector(void)"
(??1?$QVector@VQVariantQAE@XZ already defined in qgsgraph.obj [...] 
qgis_core.lib(qgis_core.dll) : error LNK2005: "public: class QVector & __thiscall QVector::operator=(class
QVector const &)" (??4?$QVector@VQVariantQAEAAV0@ABV0@ 
@Z) already defined in qgsgraph.obj [...] 
qgis_core.lib(qgis_core.dll) : error LNK2005: "public: __thiscall
QVector::QVector(void)"
(??0?$QVector@VQVariantQAE@XZ) already defined in qgsgraph.obj [...] 

Maybe you know how to get rid of the error?




--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Fwd-Qt5-Compilation-problems-on-windows-tp5295744p5300521.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [1148] Potential Slope Failure approval notification.

[noreply]

Plugin Potential Slope Failure approval by pcav.
The plugin version "[1148] Potential Slope Failure 0.3 Experimental" is now 
approved
Link: http://plugins.qgis.org/plugins/PotentialSlopeFailure/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Matthias Kuhn]

On 12/19/2016 03:33 PM, Alessandro Pasotti wrote:
> On Mon, Dec 19, 2016 at 3:26 PM, Luigi Pirelli  > wrote:
> 
> Hi Alessandro
> 
> this can be radical, but has the positive effect to introduce a "best
> practice" to develop plugins with external binary dependencies... I
> would agree, but what else respect that plugins that now have already
> binaries and were accepted? Should be modified!
> 
> Last case from some minutes ago is this just approved plugin with a
> jar included
> https://github.com/enricofer/QgisODK/tree/master/pyxform/odk_validate 
> 
> that came from a nother external foss project.
> 
> Because everyone have to modify it's plugin to move to qgis3 => we
> could leave proposal 1) for 2.x and proposal 2) for qgis3.0 giving
> time to adapt the plugin to downloading binary from external repo.
> 
> cheers
> Luigi Pirelli
> 
> 
> 
> I've just checked on the plugins site where somebody (I believe Paolo)
> wrote a policy:
> 
> ...
> does not contain architecture-dependant binaries
> ...

... which in the two cases here (cython and java) shouldn't be triggered
because both are architecture independent.

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

If that doesn't sound like a good idea, I'm not sure it's better to
prefer a (silent) download of "some binaries" from "somewhere" in the net.
Just for reference, as far as I know, python wheels also allows
uploading pre-compiled binaries to their repo.
But I might also just be missing the point.

Matthias
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [1152] QgisODK unapproval notification.

[noreply]

Plugin QgisODK unapproval by pcav.
The plugin version "[1152] QgisODK 1.0" is now unapproved
Link: http://plugins.qgis.org/plugins/QgisODK/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Luigi Pirelli]

Hi Alessandro

this can be radical, but has the positive effect to introduce a "best
practice" to develop plugins with external binary dependencies... I
would agree, but what else respect that plugins that now have already
binaries and were accepted? Should be modified!

Last case from some minutes ago is this just approved plugin with a
jar included 
https://github.com/enricofer/QgisODK/tree/master/pyxform/odk_validate
that came from a nother external foss project.

Because everyone have to modify it's plugin to move to qgis3 => we
could leave proposal 1) for 2.x and proposal 2) for qgis3.0 giving
time to adapt the plugin to downloading binary from external repo.

cheers
Luigi Pirelli

**
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
* 
https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
**


On 19 December 2016 at 15:04, Alessandro Pasotti  wrote:
> On Mon, Dec 19, 2016 at 1:21 PM, Matthias Kuhn  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
> 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.
>
>
>
>
>>
>>
>> On 12/19/2016 12:49 PM, Luigi Pirelli wrote:
>> > In this case the problem is security
>> >
>> > code is available and compiled for most used platforms... but hard to
>> > certify the content of the so/dll.
>> >
>> > any opinion?
>> > Luigi Pirelli
>> >
>> >
>> > **
>> > * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
>> > * LinkedIn: https://www.linkedin.com/in/luigipirelli
>> > * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
>> > * GitHub: https://github.com/luipir
>> > * Mastering QGIS 2nd Edition:
>> > *
>> > 

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

[Alessandro Pasotti]

On Mon, Dec 19, 2016 at 3:19 PM, Matthias Kuhn  wrote:

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

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

[Matthias Kuhn]

On 12/19/2016 03:04 PM, Luigi Pirelli wrote:
> I also agree, pragmatic solution 1) leave to the user to trust. => a
> big orange message warning the user!
> 
> btw I would add some requirements for plugin devs. e.g list at least
> the following points:
> 
> 1) the reason to have compiled parts (I had to look for a foss4g
> presentation to knwow the reason)
> 2) the list of shared or executable (I casually discovered them)
> 3) the link to the source code (in the plugin or external)... I had to
> grep the code to understand that code was available.
> 4) guide to build. This can be optional, but I would trust more a user
> that expose how to reproduce the build.
> 5) checksums x plugin version
> 
> All these info can be contained in the plugin homepage in a standard
> way (template). In this way we don't have to add tags in metadata
> other than "BEWARE binary inside!"
> 
> opinions?
> Luigi Pirelli

This sounds very reasonable to me.

Thank you
Matthias
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [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  > 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.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Alessandro Pasotti]

On Mon, Dec 19, 2016 at 1:21 PM, Matthias Kuhn  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
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.





>
> On 12/19/2016 12:49 PM, Luigi Pirelli wrote:
> > In this case the problem is security
> >
> > code is available and compiled for most used platforms... but hard to
> > certify the content of the so/dll.
> >
> > any opinion?
> > Luigi Pirelli
> >
> > 
> **
> > * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
> > * LinkedIn: https://www.linkedin.com/in/luigipirelli
> > * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
> > * GitHub: https://github.com/luipir
> > * Mastering QGIS 2nd Edition:
> > * https://www.packtpub.com/big-data-and-business-
> intelligence/mastering-qgis-second-edition
> > 
> **
> >
> >
> > On 19 December 2016 at 09:40, Matthias Kuhn  wrote:
> >> Hi all
> >>
> >> What's the main goal? Code availability? Security? Platform
> independency?
> >> Just curious.
> >>
> >> All the best
> >> Matthias
> >>
> >> On December 19, 2016 9:25:29 AM GMT+01:00, Luigi Pirelli <
> lui...@gmail.com>
> >> wrote:
> >>>
> >>> Hi Pedro,
> >>>
> >>> Nothing personal, your case is a common case due the fact to many
> >>> cases where to integrate external executables or shared objects.
> >>>
> >>> we can have a way to certificate this binary (e.g. signing process but
> >>> could become harder develop plugins, checksums). In the meantime, I
> >>> strongly suggest to a have a two phase plugin. A first phase that
> >>> prepare running environment downloading so or dll from someware with
> >>> the user consensous, and then the running phase.
> >>>
> >>> in this way you can facilitate users to access plugin thanks to qgis
> >>> repo, and turn around plugin limitations that community gave for user
> >>> security.
> >>>
> >>> regards
> >>> Luigi Pirelli
> >>>
> >>>
> >>> 
> **
> >>> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
> >>> * LinkedIn: 

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

[Luigi Pirelli]

I also agree, pragmatic solution 1) leave to the user to trust. => a
big orange message warning the user!

btw I would add some requirements for plugin devs. e.g list at least
the following points:

1) the reason to have compiled parts (I had to look for a foss4g
presentation to knwow the reason)
2) the list of shared or executable (I casually discovered them)
3) the link to the source code (in the plugin or external)... I had to
grep the code to understand that code was available.
4) guide to build. This can be optional, but I would trust more a user
that expose how to reproduce the build.
5) checksums x plugin version

All these info can be contained in the plugin homepage in a standard
way (template). In this way we don't have to add tags in metadata
other than "BEWARE binary inside!"

opinions?
Luigi Pirelli

**
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
* 
https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
**


On 19 December 2016 at 13:21, Matthias Kuhn  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
>
> On 12/19/2016 12:49 PM, Luigi Pirelli wrote:
>> In this case the problem is security
>>
>> code is available and compiled for most used platforms... but hard to
>> certify the content of the so/dll.
>>
>> any opinion?
>> Luigi Pirelli
>>
>> **
>> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
>> * LinkedIn: https://www.linkedin.com/in/luigipirelli
>> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
>> * GitHub: https://github.com/luipir
>> * Mastering QGIS 2nd Edition:
>> * 
>> https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
>> **
>>
>>
>> On 19 December 2016 at 09:40, Matthias Kuhn  wrote:
>>> Hi all
>>>
>>> What's the main goal? Code availability? Security? Platform independency?
>>> Just curious.
>>>
>>> All the best
>>> Matthias
>>>
>>> On December 19, 2016 9:25:29 AM GMT+01:00, Luigi Pirelli 
>>> wrote:

 Hi Pedro,

 Nothing personal, your case is a common case due the fact to many
 cases where to integrate external executables or shared objects.

 we can have a way to certificate this binary (e.g. signing process but
 could become harder 

[Qgis-developer] Plugin [1148] Potential Slope Failure approval notification.

[noreply]

Plugin Potential Slope Failure approval by pcav.
The plugin version "[1148] Potential Slope Failure 0.1 Experimental" is now 
approved
Link: http://plugins.qgis.org/plugins/PotentialSlopeFailure/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [1152] QgisODK approval notification.

[noreply]

Plugin QgisODK approval by pcav.
The plugin version "[1152] QgisODK 1.0" is now approved
Link: http://plugins.qgis.org/plugins/QgisODK/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Matthias Kuhn]

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

On 12/19/2016 12:49 PM, Luigi Pirelli wrote:
> In this case the problem is security
> 
> code is available and compiled for most used platforms... but hard to
> certify the content of the so/dll.
> 
> any opinion?
> Luigi Pirelli
> 
> **
> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
> * LinkedIn: https://www.linkedin.com/in/luigipirelli
> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
> * GitHub: https://github.com/luipir
> * Mastering QGIS 2nd Edition:
> * 
> https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
> **
> 
> 
> On 19 December 2016 at 09:40, Matthias Kuhn  wrote:
>> Hi all
>>
>> What's the main goal? Code availability? Security? Platform independency?
>> Just curious.
>>
>> All the best
>> Matthias
>>
>> On December 19, 2016 9:25:29 AM GMT+01:00, Luigi Pirelli 
>> wrote:
>>>
>>> Hi Pedro,
>>>
>>> Nothing personal, your case is a common case due the fact to many
>>> cases where to integrate external executables or shared objects.
>>>
>>> we can have a way to certificate this binary (e.g. signing process but
>>> could become harder develop plugins, checksums). In the meantime, I
>>> strongly suggest to a have a two phase plugin. A first phase that
>>> prepare running environment downloading so or dll from someware with
>>> the user consensous, and then the running phase.
>>>
>>> in this way you can facilitate users to access plugin thanks to qgis
>>> repo, and turn around plugin limitations that community gave for user
>>> security.
>>>
>>> regards
>>> Luigi Pirelli
>>>
>>>
>>> **
>>> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
>>> * LinkedIn: https://www.linkedin.com/in/luigipirelli
>>> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
>>> * GitHub: https://github.com/luipir
>>> * Mastering QGIS 2nd Edition:
>>> *
>>> https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
>>>
>>> **
>>>
>>>
>>> On 19 December 2016 at 08:25, Pedro Camargo 
>>> wrote:

  Hi Luigi and Paolo,

 I corrected the problems you pointed out with AequilibraE and

 re-uploaded it.

  Luigi's concern with malicious code is a very valid one, and I would
  actually appreciate to have a manner to have it checked. However, I
 would
  appreciate if we could find a solution that does not prevent us from
 having
  plugins that are compiled.

  

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

[Nathan Woodrow]

I think we have to put a level of trust in here.  If the source is
available (ship it with the plugin please) and the user is trustworthy I
don't see a lot of harm here.

It's not ideal to have binary downloads however there are some use cases
for that so I would hate to not allow it when the rest is still valid e.g
valid license etc.

On Mon, Dec 19, 2016 at 9:49 PM, Luigi Pirelli  wrote:

> In this case the problem is security
>
> code is available and compiled for most used platforms... but hard to
> certify the content of the so/dll.
>
> any opinion?
> Luigi Pirelli
>
> 
> **
> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
> * LinkedIn: https://www.linkedin.com/in/luigipirelli
> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
> * GitHub: https://github.com/luipir
> * Mastering QGIS 2nd Edition:
> * https://www.packtpub.com/big-data-and-business-
> intelligence/mastering-qgis-second-edition
> 
> **
>
>
> On 19 December 2016 at 09:40, Matthias Kuhn  wrote:
> > Hi all
> >
> > What's the main goal? Code availability? Security? Platform independency?
> > Just curious.
> >
> > All the best
> > Matthias
> >
> > On December 19, 2016 9:25:29 AM GMT+01:00, Luigi Pirelli <
> lui...@gmail.com>
> > wrote:
> >>
> >> Hi Pedro,
> >>
> >> Nothing personal, your case is a common case due the fact to many
> >> cases where to integrate external executables or shared objects.
> >>
> >> we can have a way to certificate this binary (e.g. signing process but
> >> could become harder develop plugins, checksums). In the meantime, I
> >> strongly suggest to a have a two phase plugin. A first phase that
> >> prepare running environment downloading so or dll from someware with
> >> the user consensous, and then the running phase.
> >>
> >> in this way you can facilitate users to access plugin thanks to qgis
> >> repo, and turn around plugin limitations that community gave for user
> >> security.
> >>
> >> regards
> >> Luigi Pirelli
> >>
> >>
> >> 
> **
> >> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
> >> * LinkedIn: https://www.linkedin.com/in/luigipirelli
> >> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
> >> * GitHub: https://github.com/luipir
> >> * Mastering QGIS 2nd Edition:
> >> *
> >> https://www.packtpub.com/big-data-and-business-
> intelligence/mastering-qgis-second-edition
> >>
> >> 
> **
> >>
> >>
> >> On 19 December 2016 at 08:25, Pedro Camargo 
> >> wrote:
> >>>
> >>>  Hi Luigi and Paolo,
> >>>
> >>> I corrected the problems you pointed out with AequilibraE
> and
> >>>
> >>> re-uploaded it.
> >>>
> >>>  Luigi's concern with malicious code is a very valid one, and I would
> >>>  actually appreciate to have a manner to have it checked. However, I
> >>> would
> >>>  appreciate if we could find a solution that does not prevent us from
> >>> having
> >>>  plugins that are compiled.
> >>>
> >>>  As Luigi pointed out, the code is written in Cython to increase
> >>> performance
> >>>  of the software, but it is still 5.5x slower than the proprietary
> >>> software
> >>>  that I used as a benchmark. In a nutshell, if it cannot be compiled,
> it
> >>> will
> >>>  never fly. So I would ask you guys to be considerate of this point.
> >>>
> >>>  My concerns might not even be valid, and I do apologize if that is the
> >>> case.
> >>>  I just must admit that, as an amateur software developer, I miss some
> of
> >>> the
> >>>  jargon used here when talking about more technical issues on software
> >>>  development.
> >>>
> >>>  Cheers,
> >>>  Pedro
> >>>
> >>>  On Mon, Dec 19, 2016 at 7:18 AM, Luigi Pirelli
> >>>  wrote:
> 
> 
>   Hi List
> 
>   The Binary problem (?):
>   In this recently added plugin I can find cython modules precompiled
> in
>   forms odf pyd, or so. (and relative cython code)
>   Following the presentation in:
>  https://www.youtube.com/watch?v=zz3jbM_JBTo
>   I understand that the reason is performance, but how to prevent
>   loading malicious shared objects?
> 
>   * probably we should start to plan a safe infrastructure to allow
>   uploading plugin with compiled modules... any idea other than a
> simple
>   checksum?
> 
>   The license problem (?):
>   other question is regarding the cython algorithm. I can read in
> 
> 
>  https://github.com/AequilibraE/AequilibraE/blob/
> master/aequilibrae/paths/AoN.pyx#L23
>   "Codes for route ennumeration, DAG 

Re: [Qgis-developer] XYZ tile servers

[Paolo Cavallini]

Il 19/12/2016 13:00, Tim Sutton ha scritto:

> It would be nice to bundle a bunch of these 'out the box' and have a
> setting (enabled by default) to add one to a new project as the first
> layer by default. It would be a good resolution to the issue of having
> the first user impression being a blank page with not much indication of
> how to start looking at spatial data

+1, it would be a very nice treat for our users
I rmemeber this suggestion has been put forward already, maybe it was
suggested to ask the service first, not to generate too much traffic
without their consent.
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] XYZ tile servers

[Tim Sutton]

Hi

> On 19 Dec 2016, at 7:26 AM, Paolo Cavallini  wrote:
> 
> Il 18/12/2016 22:06, Etienne Trimaille ha scritto:
>> Hi,
>> 
>> The URL 'https://maps.wikimedia.org/osm-intl/{z}/{x}/{y}.png' works
>> perfectly for me.
> 
> Thanks Etienne, Saber. Confirmed, I had to remove `$`.
> For the record, another couple of nice ones:
> http://c.tile.stamen.com/watercolor/{z}/{x}/{y}.jpg
> http://c.tiles.wmflabs.org/hillshading/{z}/{x}/{y}.png 
> 

It would be nice to bundle a bunch of these 'out the box' and have a setting 
(enabled by default) to add one to a new project as the first layer by default. 
It would be a good resolution to the issue of having the first user impression 
being a blank page with not much indication of how to start looking at spatial 
data

Regards

Tim

> All the best.
> -- 
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

—










Tim Sutton

Co-founder: Kartoza
Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

Kartoza is a merger between Linfiniti and Afrispatial

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Luigi Pirelli]

In this case the problem is security

code is available and compiled for most used platforms... but hard to
certify the content of the so/dll.

any opinion?
Luigi Pirelli

**
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
* 
https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
**


On 19 December 2016 at 09:40, Matthias Kuhn  wrote:
> Hi all
>
> What's the main goal? Code availability? Security? Platform independency?
> Just curious.
>
> All the best
> Matthias
>
> On December 19, 2016 9:25:29 AM GMT+01:00, Luigi Pirelli 
> wrote:
>>
>> Hi Pedro,
>>
>> Nothing personal, your case is a common case due the fact to many
>> cases where to integrate external executables or shared objects.
>>
>> we can have a way to certificate this binary (e.g. signing process but
>> could become harder develop plugins, checksums). In the meantime, I
>> strongly suggest to a have a two phase plugin. A first phase that
>> prepare running environment downloading so or dll from someware with
>> the user consensous, and then the running phase.
>>
>> in this way you can facilitate users to access plugin thanks to qgis
>> repo, and turn around plugin limitations that community gave for user
>> security.
>>
>> regards
>> Luigi Pirelli
>>
>>
>> **
>> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
>> * LinkedIn: https://www.linkedin.com/in/luigipirelli
>> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
>> * GitHub: https://github.com/luipir
>> * Mastering QGIS 2nd Edition:
>> *
>> https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
>>
>> **
>>
>>
>> On 19 December 2016 at 08:25, Pedro Camargo 
>> wrote:
>>>
>>>  Hi Luigi and Paolo,
>>>
>>> I corrected the problems you pointed out with AequilibraE and
>>>
>>> re-uploaded it.
>>>
>>>  Luigi's concern with malicious code is a very valid one, and I would
>>>  actually appreciate to have a manner to have it checked. However, I
>>> would
>>>  appreciate if we could find a solution that does not prevent us from
>>> having
>>>  plugins that are compiled.
>>>
>>>  As Luigi pointed out, the code is written in Cython to increase
>>> performance
>>>  of the software, but it is still 5.5x slower than the proprietary
>>> software
>>>  that I used as a benchmark. In a nutshell, if it cannot be compiled, it
>>> will
>>>  never fly. So I would ask you guys to be considerate of this point.
>>>
>>>  My concerns might not even be valid, and I do apologize if that is the
>>> case.
>>>  I just must admit that, as an amateur software developer, I miss some of
>>> the
>>>  jargon used here when talking about more technical issues on software
>>>  development.
>>>
>>>  Cheers,
>>>  Pedro
>>>
>>>  On Mon, Dec 19, 2016 at 7:18 AM, Luigi Pirelli
>>>  wrote:


  Hi List

  The Binary problem (?):
  In this recently added plugin I can find cython modules precompiled in
  forms odf pyd, or so. (and relative cython code)
  Following the presentation in:
 https://www.youtube.com/watch?v=zz3jbM_JBTo
  I understand that the reason is performance, but how to prevent
  loading malicious shared objects?

  * probably we should start to plan a safe infrastructure to allow
  uploading plugin with compiled modules... any idea other than a simple
  checksum?

  The license problem (?):
  other question is regarding the cython algorithm. I can read in


 https://github.com/AequilibraE/AequilibraE/blob/master/aequilibrae/paths/AoN.pyx#L23
  "Codes for route ennumeration, DAG construction and Link nesting were
  written by Pedro Camargo (2013) and have all their rights reserved to
  the author"

  Obviously the author has right reserved, an in the same code the
  author refer to the LICENSE.txt that is a standard GPL license:
  here:

 https://github.com/AequilibraE/AequilibraE/blob/master/aequilibrae/paths/AoN.pyx#L18
  and here:
  https://github.com/AequilibraE/AequilibraE/blob/master/LICENSE.TXT

  how should we have to read the "right reserved" sencence by the author?

  regards
  Luigi Pirelli



 

[Qgis-developer] Plugin [1126] Geoscopio Search approval notification.

[noreply]

Plugin Geoscopio Search approval by pcav.
The plugin version "[1126] Geoscopio Search 0.3" is now approved
Link: http://plugins.qgis.org/plugins/geoscopio_search/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [995] dzetsaka : Classification tool approval notification.

[noreply]

Plugin dzetsaka : Classification tool approval by pcav.
The plugin version "[995] dzetsaka : Classification tool 2.1.2" is now approved
Link: http://plugins.qgis.org/plugins/dzetsaka/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Build master QGIS with qt5 windows.

[alisovenko]

Hello!

I try to build master qgis with qt 7.5.1 (windows 10 msvc 2013).

qgis_analysis target building end with LINK error:

qgis_core.lib(qgis_core.dll) : error LNK2005: "public: __thiscall
QVector::QVector(class QVector const &)" already defined in qgsgraph.obj [...] 
sgraph.obj
[E:\dev\nextgis.qgis\qgis-master-build\src\analysis\qgis_analysis.vcxproj]
qgis_core.lib(qgis_core.dll) : error LNK2005: "public: __thiscall
QVector::~QVector(void)"
(??1?$QVector@VQVariantQAE@XZ already defined in qgsgraph.obj [...] 
qgis_core.lib(qgis_core.dll) : error LNK2005: "public: class QVector & __thiscall QVector::operator=(class
QVector const &)" (??4?$QVector@VQVariantQAEAAV0@ABV0@
@Z) already defined in qgsgraph.obj [...] 
qgis_core.lib(qgis_core.dll) : error LNK2005: "public: __thiscall
QVector::QVector(void)"
(??0?$QVector@VQVariantQAE@XZ) already defined in qgsgraph.obj [...] 

What could be the reason?



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Build-master-QGIS-with-qt5-windows-tp5300438.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [995] dzetsaka : Classification tool approval notification.

[noreply]

Plugin dzetsaka : Classification tool approval by pcav.
The plugin version "[995] dzetsaka : Classification tool 2.1.2" is now approved
Link: http://plugins.qgis.org/plugins/dzetsaka/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin [618] Processing BEAM and SNAP algorithm Provider approval notification.

[Paolo Cavallini]

Il 19/12/2016 09:50, Luigi Pirelli ha scritto:
> Hi
> 
> the same as in previous plugin, there is a compiled java class in this plugin
> 
> https://github.com/DHI-GRAS/processing_gpf/blob/GW-A_dev/processing_beam_java/listBeamBands.class

Thanks, same treatment.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [618] Processing BEAM and SNAP algorithm Provider approval notification.

[noreply]

Plugin Processing BEAM and SNAP algorithm Provider approval by pcav.
The plugin version "[618] Processing BEAM and SNAP algorithm Provider 1.2.2" is 
now unapproved
Link: http://plugins.qgis.org/plugins/processing_gpf/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [618] Processing BEAM and SNAP algorithm Provider approval notification.

[noreply]

Plugin Processing BEAM and SNAP algorithm Provider approval by pcav.
The plugin version "[618] Processing BEAM and SNAP algorithm Provider 1.1.3" is 
now unapproved
Link: http://plugins.qgis.org/plugins/processing_gpf/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [618] Processing BEAM and SNAP algorithm Provider approval notification.

[noreply]

Plugin Processing BEAM and SNAP algorithm Provider approval by pcav.
The plugin version "[618] Processing BEAM and SNAP algorithm Provider 1.3.1" is 
now unapproved
Link: http://plugins.qgis.org/plugins/processing_gpf/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [618] Processing BEAM and SNAP algorithm Provider approval notification.

[noreply]

Plugin Processing BEAM and SNAP algorithm Provider approval by pcav.
The plugin version "[618] Processing BEAM and SNAP algorithm Provider 1.3.0" is 
now unapproved
Link: http://plugins.qgis.org/plugins/processing_gpf/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [618] Processing BEAM and SNAP algorithm Provider approval notification.

[noreply]

Plugin Processing BEAM and SNAP algorithm Provider approval by pcav.
The plugin version "[618] Processing BEAM and SNAP algorithm Provider 1.2.1" is 
now unapproved
Link: http://plugins.qgis.org/plugins/processing_gpf/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [618] Processing BEAM and SNAP algorithm Provider unapproval notification.

[noreply]

Plugin Processing BEAM and SNAP algorithm Provider unapproval by pcav.
The plugin version "[618] Processing BEAM and SNAP algorithm Provider 1.4.0" is 
now unapproved
Link: http://plugins.qgis.org/plugins/processing_gpf/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [618] Processing BEAM and SNAP algorithm Provider approval notification.

[noreply]

Plugin Processing BEAM and SNAP algorithm Provider approval by pcav.
The plugin version "[618] Processing BEAM and SNAP algorithm Provider 1.1.2" is 
now unapproved
Link: http://plugins.qgis.org/plugins/processing_gpf/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [995] dzetsaka : Classification tool approval notification.

[noreply]

Plugin dzetsaka : Classification tool approval by pcav.
The plugin version "[995] dzetsaka : Classification tool 2.1.2" is now approved
Link: http://plugins.qgis.org/plugins/dzetsaka/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Matthias Kuhn]

Hi Pedro,

No, I just wanted to understand exactly, what the problems with compiled
code (in general) are. With a clear problem statement it's easier to
discuss a solution - and you can hopefully continue to ship your plugin
through the plugin infrastructure.

Matthias

On 12/19/2016 09:42 AM, Pedro Camargo wrote:
> Hi Matthias,
> 
> Was the question directed to me?
> 
> If so, my objective is to make the code as efficient as possible (by
> having it in Cython) and available in as many platforms as possible.
> 
> Cheers,
> Pedro
> 
> On Mon, Dec 19, 2016 at 6:40 PM, Matthias Kuhn  > wrote:
> 
> Hi all
> 
> What's the main goal? Code availability? Security? Platform
> independency?
> Just curious.
> 
> All the best
> Matthias
> 
> On December 19, 2016 9:25:29 AM GMT+01:00, Luigi Pirelli
> > wrote:
> 
> Hi Pedro,
> 
> Nothing personal, your case is a common case due the fact to many
> cases where to integrate external executables or shared objects.
> 
> we can have a way to certificate this binary (e.g. signing
> process but
> could become harder develop plugins, checksums). In the meantime, I
> strongly suggest to a have a two phase plugin. A first phase that
> prepare running environment downloading so or dll from someware with
> the user consensous, and then the running phase.
> 
> in this way you can facilitate users to access plugin thanks to qgis
> repo, and turn around plugin limitations that community gave for
> user
> security.
> 
> regards
> Luigi Pirelli
> 
> 
> **
> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo
> DOT com
> * LinkedIn: https://www.linkedin.com/in/luigipirelli
> 
> * Stackexchange:
> http://gis.stackexchange.com/users/19667/luigi-pirelli
> 
> * GitHub: https://github.com/luipir
> * Mastering QGIS 2nd Edition:
> *
> 
> https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
> 
> 
> 
> **
> 
> 
> On 19 December 2016 at 08:25, Pedro Camargo
> > wrote:
> 
> Hi Luigi and Paolo,
> 
> I corrected the problems you pointed out with AequilibraE and
> re-uploaded it.
> 
> Luigi's concern with malicious code is a very valid one, and
> I would
> actually appreciate to have a manner to have it checked.
> However, I would
> appreciate if we could find a solution that does not prevent
> us from having
> plugins that are compiled.
> 
> As Luigi pointed out, the code is written in Cython to
> increase performance
> of the software, but it is still 5.5x slower than the
> proprietary software
> that I used as a benchmark. In a nutshell, if it cannot be
> compiled, it will
> never fly. So I would ask you guys to be considerate of this
> point.
> 
> My concerns might not even be valid, and I do apologize if
> that is the case.
> I just must admit that, as an amateur software developer, I
> miss some of the
> jargon used here when talking about more technical issues on
> software
> development.
> 
> Cheers,
> Pedro
> 
> On Mon, Dec 19, 2016 at 7:18 AM, Luigi Pirelli
> > wrote:
> 
> 
> Hi List
> 
> The Binary problem (?):
> In this recently added plugin I can find cython modules
> precompiled in
> forms odf pyd, or so. (and relative cython code)
> Following the presentation in:
> https://www.youtube.com/watch?v=zz3jbM_JBTo
> 
> I understand that the reason is performance, but how to
> prevent
> loading malicious shared objects?
> 
> * probably we should start to plan a safe infrastructure
> to allow
> uploading plugin with compiled modules... any idea other
> than a simple
> 

Re: [Qgis-developer] Plugin [618] Processing BEAM and SNAP algorithm Provider approval notification.

[Luigi Pirelli]

Hi

the same as in previous plugin, there is a compiled java class in this plugin

https://github.com/DHI-GRAS/processing_gpf/blob/GW-A_dev/processing_beam_java/listBeamBands.class

regards
Luigi Pirelli

**
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
* 
https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
**


On 16 December 2016 at 18:22,   wrote:
>
> Plugin Processing BEAM and SNAP algorithm Provider approval by pcav.
> The plugin version "[618] Processing BEAM and SNAP algorithm Provider 1.4.0" 
> is now approved
> Link: http://plugins.qgis.org/plugins/processing_gpf/
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Pedro Camargo]

Hi Matthias,

Was the question directed to me?

If so, my objective is to make the code as efficient as possible (by having
it in Cython) and available in as many platforms as possible.

Cheers,
Pedro

On Mon, Dec 19, 2016 at 6:40 PM, Matthias Kuhn  wrote:

> Hi all
>
> What's the main goal? Code availability? Security? Platform independency?
> Just curious.
>
> All the best
> Matthias
>
> On December 19, 2016 9:25:29 AM GMT+01:00, Luigi Pirelli 
> wrote:
>
>> Hi Pedro,
>>
>> Nothing personal, your case is a common case due the fact to many
>> cases where to integrate external executables or shared objects.
>>
>> we can have a way to certificate this binary (e.g. signing process but
>> could become harder develop plugins, checksums). In the meantime, I
>> strongly suggest to a have a two phase plugin. A first phase that
>> prepare running environment downloading so or dll from someware with
>> the user consensous, and then the running phase.
>>
>> in this way you can facilitate users to access plugin thanks to qgis
>> repo, and turn around plugin limitations that community gave for user
>> security.
>>
>> regards
>> Luigi Pirelli
>>
>> **
>> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
>> * LinkedIn: https://www.linkedin.com/in/luigipirelli
>> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
>> * GitHub: https://github.com/luipir
>> * Mastering QGIS 2nd Edition:
>> * 
>> https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
>> **
>>
>>
>> On 19 December 2016 at 08:25, Pedro Camargo  wrote:
>>
>>>  Hi Luigi and Paolo,
>>>
>>> I corrected the problems you pointed out with AequilibraE and
>>>
>>> re-uploaded it.
>>>
>>>  Luigi's concern with malicious code is a very valid one, and I would
>>>  actually appreciate to have a manner to have it checked. However, I would
>>>  appreciate if we could find a solution that does not prevent us from having
>>>  plugins that are compiled.
>>>
>>>  As Luigi pointed out, the code is written in Cython to increase performance
>>>  of the software, but it is still 5.5x slower than the proprietary software
>>>  that I used as a benchmark. In a nutshell, if it cannot be compiled, it 
>>> will
>>>  never fly. So I would ask you guys to be considerate of this point.
>>>
>>>  My concerns might not even be valid, and I do apologize if that is the 
>>> case.
>>>  I just must admit that, as an amateur software developer, I miss some of 
>>> the
>>>  jargon used here when talking about more technical issues on software
>>>  development.
>>>
>>>  Cheers,
>>>  Pedro
>>>
>>>  On Mon, Dec 19, 2016 at 7:18 AM, Luigi Pirelli
>>>  wrote:
>>>

  Hi List

  The Binary problem (?):
  In this recently added plugin I can find cython modules precompiled in
  forms odf pyd, or so. (and relative cython code)
  Following the presentation in: https://www.youtube.com/watch?v=zz3jbM_JBTo
  I understand that the reason is performance, but how to prevent
  loading malicious shared objects?

  * probably we should start to plan a safe infrastructure to allow
  uploading plugin with compiled modules... any idea other than a simple
  checksum?

  The license problem (?):
  other question is regarding the cython algorithm. I can read in

  
 https://github.com/AequilibraE/AequilibraE/blob/master/aequilibrae/paths/AoN.pyx#L23
  "Codes for route ennumeration, DAG construction and Link nesting were
  written by Pedro Camargo (2013) and have all their rights reserved to
  the author"

  Obviously the author has right reserved, an in the same code the
  author refer to the LICENSE.txt that is a standard GPL license:
  here:
  
 https://github.com/AequilibraE/AequilibraE/blob/master/aequilibrae/paths/AoN.pyx#L18
  and here:
  https://github.com/AequilibraE/AequilibraE/blob/master/LICENSE.TXT

  how should we have to read the "right reserved" sencence by the author?

  regards
  Luigi Pirelli


  
 **
  * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
  * LinkedIn: https://www.linkedin.com/in/luigipirelli
  * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
  * GitHub: https://github.com/luipir
  * Mastering QGIS 2nd Edition:
  *
  
 https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition

  
 

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

[Matthias Kuhn]

Hi all

What's the main goal? Code availability? Security? Platform independency?
Just curious.

All the best
Matthias

On December 19, 2016 9:25:29 AM GMT+01:00, Luigi Pirelli  
wrote:
>Hi Pedro,
>
>Nothing personal, your case is a common case due the fact to many
>cases where to integrate external executables or shared objects.
>
>we can have a way to certificate this binary (e.g. signing process but
>could become harder develop plugins, checksums). In the meantime, I
>strongly suggest to a have a two phase plugin. A first phase that
>prepare running environment downloading so or dll from someware with
>the user consensous, and then the running phase.
>
>in this way you can facilitate users to access plugin thanks to qgis
>repo, and turn around plugin limitations that community gave for user
>security.
>
>regards
>Luigi Pirelli
>
>**
>* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
>* LinkedIn: https://www.linkedin.com/in/luigipirelli
>* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
>* GitHub: https://github.com/luipir
>* Mastering QGIS 2nd Edition:
>*
>https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
>**
>
>
>On 19 December 2016 at 08:25, Pedro Camargo 
>wrote:
>> Hi Luigi and Paolo,
>>
>>I corrected the problems you pointed out with AequilibraE
>and
>> re-uploaded it.
>>
>> Luigi's concern with malicious code is a very valid one, and I would
>> actually appreciate to have a manner to have it checked. However, I
>would
>> appreciate if we could find a solution that does not prevent us from
>having
>> plugins that are compiled.
>>
>> As Luigi pointed out, the code is written in Cython to increase
>performance
>> of the software, but it is still 5.5x slower than the proprietary
>software
>> that I used as a benchmark. In a nutshell, if it cannot be compiled,
>it will
>> never fly. So I would ask you guys to be considerate of this point.
>>
>> My concerns might not even be valid, and I do apologize if that is
>the case.
>> I just must admit that, as an amateur software developer, I miss some
>of the
>> jargon used here when talking about more technical issues on software
>> development.
>>
>> Cheers,
>> Pedro
>>
>> On Mon, Dec 19, 2016 at 7:18 AM, Luigi Pirelli 
>wrote:
>>>
>>> Hi List
>>>
>>> The Binary problem (?):
>>> In this recently added plugin I can find cython modules precompiled
>in
>>> forms odf pyd, or so. (and relative cython code)
>>> Following the presentation in:
>https://www.youtube.com/watch?v=zz3jbM_JBTo
>>> I understand that the reason is performance, but how to prevent
>>> loading malicious shared objects?
>>>
>>> * probably we should start to plan a safe infrastructure to allow
>>> uploading plugin with compiled modules... any idea other than a
>simple
>>> checksum?
>>>
>>> The license problem (?):
>>> other question is regarding the cython algorithm. I can read in
>>>
>>>
>https://github.com/AequilibraE/AequilibraE/blob/master/aequilibrae/paths/AoN.pyx#L23
>>> "Codes for route ennumeration, DAG construction and Link nesting
>were
>>> written by Pedro Camargo (2013) and have all their rights reserved
>to
>>> the author"
>>>
>>> Obviously the author has right reserved, an in the same code the
>>> author refer to the LICENSE.txt that is a standard GPL license:
>>> here:
>>>
>https://github.com/AequilibraE/AequilibraE/blob/master/aequilibrae/paths/AoN.pyx#L18
>>> and here:
>>> https://github.com/AequilibraE/AequilibraE/blob/master/LICENSE.TXT
>>>
>>> how should we have to read the "right reserved" sencence by the
>author?
>>>
>>> regards
>>> Luigi Pirelli
>>>
>>>
>>>
>**
>>> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT
>com
>>> * LinkedIn: https://www.linkedin.com/in/luigipirelli
>>> * Stackexchange:
>http://gis.stackexchange.com/users/19667/luigi-pirelli
>>> * GitHub: https://github.com/luipir
>>> * Mastering QGIS 2nd Edition:
>>> *
>>>
>https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
>>>
>>>
>**
>>>
>>>
>>> On 18 December 2016 at 14:28,   wrote:
>>> >
>>> > Plugin AequilibraE approval by pcav.
>>> > The plugin version "[1102] AequilibraE 0.3.3" is now approved
>>> > Link: http://plugins.qgis.org/plugins/AequilibraE/
>>> > ___
>>> > Qgis-developer mailing list
>>> > Qgis-developer@lists.osgeo.org
>>> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> > Unsubscribe:

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

[Pedro Camargo]

I understand, Luigi.

Will the plug-in be authorized while I create this process?  Or do I need
to create it before the plugin goes back online?

Cheers,
Pedro

On Mon, Dec 19, 2016 at 6:25 PM, Luigi Pirelli  wrote:

> Hi Pedro,
>
> Nothing personal, your case is a common case due the fact to many
> cases where to integrate external executables or shared objects.
>
> we can have a way to certificate this binary (e.g. signing process but
> could become harder develop plugins, checksums). In the meantime, I
> strongly suggest to a have a two phase plugin. A first phase that
> prepare running environment downloading so or dll from someware with
> the user consensous, and then the running phase.
>
> in this way you can facilitate users to access plugin thanks to qgis
> repo, and turn around plugin limitations that community gave for user
> security.
>
> regards
> Luigi Pirelli
>
> 
> **
> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
> * LinkedIn: https://www.linkedin.com/in/luigipirelli
> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
> * GitHub: https://github.com/luipir
> * Mastering QGIS 2nd Edition:
> * https://www.packtpub.com/big-data-and-business-
> intelligence/mastering-qgis-second-edition
> 
> **
>
>
> On 19 December 2016 at 08:25, Pedro Camargo 
> wrote:
> > Hi Luigi and Paolo,
> >
> >I corrected the problems you pointed out with AequilibraE and
> > re-uploaded it.
> >
> > Luigi's concern with malicious code is a very valid one, and I would
> > actually appreciate to have a manner to have it checked. However, I would
> > appreciate if we could find a solution that does not prevent us from
> having
> > plugins that are compiled.
> >
> > As Luigi pointed out, the code is written in Cython to increase
> performance
> > of the software, but it is still 5.5x slower than the proprietary
> software
> > that I used as a benchmark. In a nutshell, if it cannot be compiled, it
> will
> > never fly. So I would ask you guys to be considerate of this point.
> >
> > My concerns might not even be valid, and I do apologize if that is the
> case.
> > I just must admit that, as an amateur software developer, I miss some of
> the
> > jargon used here when talking about more technical issues on software
> > development.
> >
> > Cheers,
> > Pedro
> >
> > On Mon, Dec 19, 2016 at 7:18 AM, Luigi Pirelli  wrote:
> >>
> >> Hi List
> >>
> >> The Binary problem (?):
> >> In this recently added plugin I can find cython modules precompiled in
> >> forms odf pyd, or so. (and relative cython code)
> >> Following the presentation in: https://www.youtube.com/watch?
> v=zz3jbM_JBTo
> >> I understand that the reason is performance, but how to prevent
> >> loading malicious shared objects?
> >>
> >> * probably we should start to plan a safe infrastructure to allow
> >> uploading plugin with compiled modules... any idea other than a simple
> >> checksum?
> >>
> >> The license problem (?):
> >> other question is regarding the cython algorithm. I can read in
> >>
> >> https://github.com/AequilibraE/AequilibraE/blob/
> master/aequilibrae/paths/AoN.pyx#L23
> >> "Codes for route ennumeration, DAG construction and Link nesting were
> >> written by Pedro Camargo (2013) and have all their rights reserved to
> >> the author"
> >>
> >> Obviously the author has right reserved, an in the same code the
> >> author refer to the LICENSE.txt that is a standard GPL license:
> >> here:
> >> https://github.com/AequilibraE/AequilibraE/blob/
> master/aequilibrae/paths/AoN.pyx#L18
> >> and here:
> >> https://github.com/AequilibraE/AequilibraE/blob/master/LICENSE.TXT
> >>
> >> how should we have to read the "right reserved" sencence by the author?
> >>
> >> regards
> >> Luigi Pirelli
> >>
> >>
> >> 
> **
> >> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
> >> * LinkedIn: https://www.linkedin.com/in/luigipirelli
> >> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
> >> * GitHub: https://github.com/luipir
> >> * Mastering QGIS 2nd Edition:
> >> *
> >> https://www.packtpub.com/big-data-and-business-
> intelligence/mastering-qgis-second-edition
> >>
> >> 
> **
> >>
> >>
> >> On 18 December 2016 at 14:28,   wrote:
> >> >
> >> > Plugin AequilibraE approval by pcav.
> >> > The plugin version "[1102] AequilibraE 0.3.3" is now approved
> >> > Link: http://plugins.qgis.org/plugins/AequilibraE/
> >> > ___
> >> > Qgis-developer mailing list
> >> > 

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

[Luigi Pirelli]

Hi Pedro,

Nothing personal, your case is a common case due the fact to many
cases where to integrate external executables or shared objects.

we can have a way to certificate this binary (e.g. signing process but
could become harder develop plugins, checksums). In the meantime, I
strongly suggest to a have a two phase plugin. A first phase that
prepare running environment downloading so or dll from someware with
the user consensous, and then the running phase.

in this way you can facilitate users to access plugin thanks to qgis
repo, and turn around plugin limitations that community gave for user
security.

regards
Luigi Pirelli

**
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
* 
https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
**


On 19 December 2016 at 08:25, Pedro Camargo  wrote:
> Hi Luigi and Paolo,
>
>I corrected the problems you pointed out with AequilibraE and
> re-uploaded it.
>
> Luigi's concern with malicious code is a very valid one, and I would
> actually appreciate to have a manner to have it checked. However, I would
> appreciate if we could find a solution that does not prevent us from having
> plugins that are compiled.
>
> As Luigi pointed out, the code is written in Cython to increase performance
> of the software, but it is still 5.5x slower than the proprietary software
> that I used as a benchmark. In a nutshell, if it cannot be compiled, it will
> never fly. So I would ask you guys to be considerate of this point.
>
> My concerns might not even be valid, and I do apologize if that is the case.
> I just must admit that, as an amateur software developer, I miss some of the
> jargon used here when talking about more technical issues on software
> development.
>
> Cheers,
> Pedro
>
> On Mon, Dec 19, 2016 at 7:18 AM, Luigi Pirelli  wrote:
>>
>> Hi List
>>
>> The Binary problem (?):
>> In this recently added plugin I can find cython modules precompiled in
>> forms odf pyd, or so. (and relative cython code)
>> Following the presentation in: https://www.youtube.com/watch?v=zz3jbM_JBTo
>> I understand that the reason is performance, but how to prevent
>> loading malicious shared objects?
>>
>> * probably we should start to plan a safe infrastructure to allow
>> uploading plugin with compiled modules... any idea other than a simple
>> checksum?
>>
>> The license problem (?):
>> other question is regarding the cython algorithm. I can read in
>>
>> https://github.com/AequilibraE/AequilibraE/blob/master/aequilibrae/paths/AoN.pyx#L23
>> "Codes for route ennumeration, DAG construction and Link nesting were
>> written by Pedro Camargo (2013) and have all their rights reserved to
>> the author"
>>
>> Obviously the author has right reserved, an in the same code the
>> author refer to the LICENSE.txt that is a standard GPL license:
>> here:
>> https://github.com/AequilibraE/AequilibraE/blob/master/aequilibrae/paths/AoN.pyx#L18
>> and here:
>> https://github.com/AequilibraE/AequilibraE/blob/master/LICENSE.TXT
>>
>> how should we have to read the "right reserved" sencence by the author?
>>
>> regards
>> Luigi Pirelli
>>
>>
>> **
>> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
>> * LinkedIn: https://www.linkedin.com/in/luigipirelli
>> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
>> * GitHub: https://github.com/luipir
>> * Mastering QGIS 2nd Edition:
>> *
>> https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
>>
>> **
>>
>>
>> On 18 December 2016 at 14:28,   wrote:
>> >
>> > Plugin AequilibraE approval by pcav.
>> > The plugin version "[1102] AequilibraE 0.3.3" is now approved
>> > Link: http://plugins.qgis.org/plugins/AequilibraE/
>> > ___
>> > Qgis-developer mailing list
>> > Qgis-developer@lists.osgeo.org
>> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer