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