Hi, On Fri, Apr 11, 2014 at 7:13 PM, Ingo Lütkebohle <iluet...@gmail.com> wrote: > Oh, and just to clarify, I also mean that effort for *authors* should be > taken into account.
Ok well I understood everything until your "clarification". What effort for which authors? > On Fri, Apr 11, 2014 at 9:11 AM, Ingo Lütkebohle <iluet...@gmail.com> wrote: >> >> Jehan, >> >> I wholeheartedly support your concerns, but I would advise trying to think >> of ways of approaching this in a simpler way. If the registry can support >> you in that, let me know. Well some things can be simplified for the first release, like code reviews as I said. But some things can't, in my opinion. In particular, we absolutely need to secure the plugin provenance (secure channel, signing or any other method) and we absolutely can't automatically install any binary, with executable rights, generated by any random person on the internet. For me, there could be absolutely no discussion about it. That's about respecting our community, but also about responsibility. The risks to have malwares are too big, especially for a program as well known, hence spread, as GIMP. We all know this. As you said yourself, the registry is receiving more and more abuse. That's an open door for spam, scam, and much worse. We even have more and more fake GIMP going on nowaydays on the web, and even on some app stores (very recently there was such a case, and Michael had to ask for the fake app to be taken down). We seem to be told on the mailing list of a scam involving GIMP every few weeks, and that's without counting all the ones we never hear about. So allowing to install any random, unreviewed and uncontrolled executable, which can be run under the user's rights from our official build? That's like creating a backdoor, a big security breach into a user's data and system. So no, I don't think there can be much simpler way to this problem. Note that of course, as a developer, I would first develop a basic system without much security for quick feature test. But the finale released system must have all the security in place, when dealing with such a dangerous feature. >> Other than that, the whole searching and browsing UI is likely far from >> trivial as you suggest. Yes you are right. I did not mean to imply all the rest was just easy stuff (though I mistakenly said so). UI and search algorithm are also important and difficult (as always). But I still meant to say that for this specific feature, the security should be taken very seriously. It just seems to me that your original call (which I saw, has been relayed by some websites as gimpusers.com) seems to completely overlook this side, which I think is primordial. Jehan >> cheers >> >> >> >> On Fri, Apr 11, 2014 at 3:08 AM, Jehan Pagès <jehan.marmott...@gmail.com> >> wrote: >>> >>> Hi, >>> >>> On Thu, Apr 10, 2014 at 4:06 PM, scl <scl.gp...@gmail.com> wrote: >>> > Hi, >>> > >>> > it's interesting to see what interest such a post can trigger ;-) >>> > To be honest, it wasn't me who started the discussion, I just forwarded >>> > Ingo's call to the mailing list. >>> > >>> > 'GIMP is easily user-extendable, by ‘one-click’ installation of >>> > plug-ins.' is a part of our product-vision and as far as I remember >>> > there have already been many ideas on this topic, dating back to 2003. >>> > >>> > For both the registry and GIMP the situation changes: >>> > Registry: from some or many users who know and use the registry to >>> > potentially every user who can access it conveniently from GIMP. These >>> > are millions. >>> > GIMP: From a standalone application that uses mostly local data to >>> > an application with tighter access to an online service. >>> > >>> > I think before we start losing ourselves prematurely in implementation >>> > details like programming language and data formats we should clarify >>> > the overall picture first: >>> > - What are the concrete requirements: functional and nonfunctional >>> > requirements, >>> > - user interaction, >>> > - overall technical architecture and integration into GIMP, >>> > - reuse of existing solutions like package managers, >>> > - who will also care in future for the registry and the plug-in >>> > manager? >>> > - Integration into the Jenkins builds and manpower to handle this. >>> > >>> > Examples for functional requirements: >>> > * installing only plug-ins or also other assets, >>> > * curation/quality assurance of provided assets, >>> > * metadata of the assets, >>> > * search and filter functionality. >>> > >>> > Examples for nonfunctional requirements: >>> > * performance: be fluent, also with a slow internet connection, >>> > * security, protection against abuse, >>> > * scalability (how many users will access the registry at one time or >>> > at maximum), >>> > * target platform, >>> > * maintainability (even with our given low resources). >>> > >>> > Perhaps it would - depending on our resources - first be better to cut >>> > down the registry to the necessary part we can handle, e.g. to remove >>> > the functionality that causes spam and start with a little >>> > thing in GIMP, like a clickable link to open the registry in a >>> > browser and easy to find assets folders in the Preferences. >>> >>> All this topic is one I am myself very interested too, and I actually >>> have been thinking about it for 6 months. >>> If we had been a Gsoc mentor organization this year, I was even hoping >>> we could find a student willing to kickstart such a plugin management >>> infrastructure (this was in my personal list of gsoc ideas meant to be >>> merged with the rest: >>> http://wiki.gimp.org/index.php/User:Jehan/Hacking:GSoC/2014/Ideas ). >>> >>> Now if someone wants to take care of this, I am all for not >>> overworking myself. :-) Otherwise, I would likely tackle the issue >>> properly in a several months. I am currently farming alpacas :P thus >>> in the impossibility to focus on such an important problem, but in end >>> of May I will be much more dedicated to GIMP again (though I have >>> several GIMP-related priorities at this time, before even thinking >>> about a plugin management system). >>> >>> Now before I become silent again, I will still raise what I believe >>> are much important problems than any technical issues: security and >>> responsibilities of the GIMP project. If that had been a gsoc project, >>> I would have given most of the technicalities to the student and would >>> have taken care of security personally. >>> Basically having a website where anyone can upload anything and anyone >>> else is fully responsible for checking oneself and installing manually >>> is one thing. But providing a plugin management system, released >>> together and integrated with GIMP, which would download and install on >>> the user's behalf, and even auto-update plugins is a completely >>> different matter. If not mistaken, there is no proper sandbox for GIMP >>> plugins, so they are technically executables that GIMP runs and which >>> can do many kinds of nasty stuff. We suddenly have a much more bigger >>> responsibility: >>> >>> - We must not accept anything without at the very least a minimum of >>> check. Ideally we would need security analysis programs to >>> automatically review each and every code uploaded (calls to third >>> party URIs, attempt to access networks, system calls which are likely >>> not normal in a GIMP plugins, etc.), then technical-minded >>> contributors to review codes of any suspicious plugin (being the case >>> when the previous automatic review did pick up some strange patterns) >>> for any funny story (scam, attacks, using your computer as a ghost >>> machine, etc.). We could of course start with a self-managed community >>> (abuse button, vote system, etc.) until some admin steps in to install >>> code review scripts, and enough users step in into code review duty. >>> Many Free Software started their plugin management this way. >>> Though obviously even with such a community system, I would feel fine >>> only with at least a minimum of check. >>> >>> - We should definitely not accept uploaded binaries. For me, this is >>> an absolute *no*. Binaries are black boxes. What it means is not that >>> C plugins should be forbidden but that the C plugin devs should upload >>> their source code *only*. And we should have compilation systems >>> running on our servers to compile C code for at least each of the 3 >>> main platforms, both 32 and 64bits. That's already 6 compilation >>> processes to take care of (and we still forget some platforms like BSD >>> or Solaris!). >>> That is very cumbersome. But I will absolutely never condone >>> automatically uploading then installing binary executables into user's >>> computers, coming from any random dude on the planet. >>> >>> - Users should always be able to see the code which is running on >>> their computer. So even for binary plugins, we must at all time keep >>> the codes, and keep them available to users. I don't speak about >>> licenses. I obviously prefer Free Software licenses, and if it were >>> only me to decide, I'd accept only FLOSS plugins. But if ever many >>> people were ok to accept non-Free plugins in the system, I would not >>> mind *as long as* we can still see the code. A cool stuff about this >>> could be to even provide git repositories for plugin developers >>> (Wordpress does this for instance, and that's very nice). >>> >>> - Obviously a basic stuff should be that we must sign every plugin, or >>> they must come through secure channels (SSL/TLS signed), or even both. >>> Now this said, this is Free Software, and anyone can come in and >>> compile GIMP after changing URIs to their personal server and modify >>> public keys to match their own. Then users would trust a scam plugin >>> that one thinks signed. That's a problem which can't really be easily >>> fixed. One way is legal. During LGM, the topic of branding has been >>> several times raised, and that could be used to this effect. We could >>> effectively forbid any third party compilation to be called "GIMP" >>> according to some criteria. One of the criteria would be that they >>> cannot change the plugin servers and any security key that we put in >>> place for user safety. >>> >>> In any case, when I read: >>> « >>> Specifically, we need a plug-in which could access a back-end database >>> over the Internet, carry out queries, receive data in XML or JSON >>> format, download plug-ins, and install them automatically. >>> » >>> For me, it feels like a joke. That's the easy part. That's the obvious >>> side and that can be coded in just a few dozen minutes. But there is >>> so much more. A system which does only this part, I would never want >>> it to be a part of released GIMP. If we want to do this (and I want to >>> do it!), then we must do it well. >>> >>> Or maybe we don't mean a system part of the official GIMP release. And >>> in this case, do as you want. :P >>> But for something official, you have above the minimum I would care >>> about for this to happen. >>> Have fun all! >>> >>> Jehan >>> >>> P.S.: also to be properly done, such a system would not be only about >>> downloading and installing. It should also be about managing! That >>> means that a proper manifest format must be specified to keep track of >>> installed plugins. This would allow proper listing, uninstallation, >>> auto-updating, etc. because currently the plugin management is manual >>> and thus very messy. This is not as important as the security part of >>> course. But if I were to do this, I would still want to include such >>> considerations from the start because that would change a lot GIMP >>> usage. >>> >>> > Kind regards, >>> > >>> > Sven >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > gimp-developer-list mailing list >>> > List address: gimp-developer-list@gnome.org >>> > List membership: >>> > https://mail.gnome.org/mailman/listinfo/gimp-developer-list >>> > List archives: https://mail.gnome.org/archives/gimp-developer-list >>> _______________________________________________ >>> gimp-developer-list mailing list >>> List address: gimp-developer-list@gnome.org >>> List membership: >>> https://mail.gnome.org/mailman/listinfo/gimp-developer-list >>> List archives: https://mail.gnome.org/archives/gimp-developer-list >> >> >> >> >> -- >> Ingo Lütkebohle, Dr.-Ing. >> Machine Learning and Robotics Lab, IPVS, Universität Stuttgart >> >> http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle >> +49-711-685-88350 >> >> PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B > > > > > -- > Ingo Lütkebohle, Dr.-Ing. > Machine Learning and Robotics Lab, IPVS, Universität Stuttgart > http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle > +49-711-685-88350 > > PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
