[Qgis-psc] AGM: plugins vote

Alessandro Pasotti apasotti at gmail.com
Thu Apr 9 01:51:27 PDT 2020


On Thu, Apr 9, 2020 at 10:24 AM Denis Rouzaud <denis.rouzaud at gmail.com> wrote:
>
>
>
> Le jeu. 9 avr. 2020 à 08:48, Alessandro Pasotti <apasotti at gmail.com> a écrit :
>>
>> Hi,
>>
>> Sorry, but I didn't understand what's the real issue here: the
>> no-binary policy was enforced on the official plugins repo in order
>> to:
>> - make sure we don't have to host huge plugins to store/upload and download
>> - make sure we can inspect what's inside a plugin (for years we
>> discussed about doing more automatic validation on the python code
>> looking for malicious code)
>>
>> There are actually a really simple workaround for whoever wanted to
>> distribute plugins with binaries, viruses, windows95 DLLs etc.:
>>
>> - 1 download and install your forbidden binaries directly from your
>> plugin right after your plugin is installed
>>
>> Or, a slightly more complicated solution:
>
>
> are you serious ? ;)
> isn't it a proof, that it's completely useless to try to enforce rules?
> or should there be a rule that prevent plugins from adding additional repos?
>

Did you read the first paragraph?

Let me rephrase it: the primary reason to forbid binaries was to not
store/upload/download large zips, the secondary reason was to be able
to check for malicious code hosted on our official repo.

There is no way we can avoid that a plugin does malicious things after
it is installed, it's Python and it can do anything and if it
downloads a virus at least it won't be hosted on the official repo.

That said I really cannot see a safe option. I won't advise to accept
the possibility that inside the zips hosted in the official repo there
is a possibly dangerous binary.

There is no perfect solution here because we lack the workforce to
check all plugin's code, the original policy was the best effort and
no-binary allows us to check what the code does in case we have
doubts, with a binary it would be just impossible.



>>
>>
>> - 1 make your own repo (it's trivial, believe me, there are ton of
>> recipes with dockers, python implementations, simple scripts etc.)
>> - 2 make a legitimate plugin that
>>    - 2.1 add your repo to the QGIS list of repos
>>    - 2.2 installs the forbidden plugin which contains your binaries
>> - 3 upload the legitimate plugin on the official repo
>> - 4 profit!
>>
>>
>> Cheers
>>
>>
>>
>> On Thu, Apr 9, 2020 at 7:37 AM Matthias Kuhn <matthias at opengis.ch> wrote:
>> >
>> > Hi Alessandro,
>> >
>> > Thank you for jumping in and also for including https://plugins.qgis.org/publish/ in the discussion.
>> >
>> > For clarity: currently "no binaries" is listed as a requirement while "cross platform" is a recommendation.
>> >
>> > Regards
>> > Matthias
>> >
>> > On 4/8/20 6:01 PM, Alessandro Pasotti wrote:
>> >
>> > The no-binary policy in the official repository has been enforced and listed since day 1 , see https://plugins.qgis.org/publish/
>> >
>> > I'm not sure if the other rule about cross-platform has been written down somewhere, I've always taken that one for granted.
>> >
>> > I see no problems if a plug-in does its post-installation downloads though.
>> >
>> > Just my two cents.
>> >
>> >
>> >
>> > On Wed, Apr 8, 2020, 17:44 Matthias Kuhn <matthias at opengis.ch> wrote:
>> >>
>> >> Hi Paolo
>> >>
>> >> On 4/8/20 4:55 PM, Paolo Cavallini wrote:
>> >> > Hi Matthias,
>> >> >
>> >> > Il 08/04/20 16:32, Matthias Kuhn ha scritto:
>> >> >> Hi Paolo,
>> >> >>
>> >> >> Thanks for moving forward and writing some reasoning.
>> >> >>
>> >> >> I would like to change the wording "current situation" and "status quo
>> >> >> committee" in these texts. This suggests that there has been a conscious
>> >> >> decision by a committee like the PSC. I'd rather describe it as a
>> >> >> "currently unclear situation".
>> >> > the current situation is not unclear. I think it is fair to give a
>> >> > minimal context, describing how things are running since many years;
>> >> > "current situation" sounds very neutral to me.
>> >> > Maybe someone can suggest a more neutral wording?
>> >> I still think this was mostly a vision of individuals and not a general
>> >> perception of how it is/should be handled. I was *very* surprised to
>> >> hear that this is the current situation and I think it was and is
>> >> unclear to others too. I also wouldn't be surprised to find a couple of
>> >> binary wheels and plugins which are not cross-platform - but nobody ever
>> >> noticed - in the repository.
>> >> > I though about the name to give to the "non-pro" committee. I avoided
>> >> > "against committee", because it sounds ugly to me, and gives a negative
>> >> > impression.
>> >> > Perhaps we can skip the problem just replacing "* committee" with "We"?
>> >> > Thanks for the suggestion.
>> >> > Cheers.
>> >>
>> >> I'm fine with dumping the term "pro committee" formulation. But that's
>> >> not the point.
>> >>
>> >> My main point is that "the status quo" as listed is not as clear to
>> >> everyone as described in the text. Or is it really that clear to
>> >> everyone? I would love to hear some other opinions of community
>> >> representatives and PSC members on this.
>> >>
>> >> Matthias
>> >>
>> >> _______________________________________________
>> >> Qgis-psc mailing list
>> >> Qgis-psc at lists.osgeo.org
>> >> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>
>>
>>
>> --
>> Alessandro Pasotti
>> w3:   www.itopen.it
>> _______________________________________________
>> Qgis-psc mailing list
>> Qgis-psc at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/qgis-psc



-- 
Alessandro Pasotti
w3:   www.itopen.it



More information about the Qgis-psc mailing list