Hi, On Sat, Apr 12, 2014 at 12:36 PM, Joao S. O. Bueno <gwidion@xxxxxxxxx> wrote: > Just for the record, I second all of Jehan's concerns - > Although I don't think the "GIMP authenticated server" should be the only > possible way to install managed plug-ins: > > Users should be given an option to change the plug-in server to > "unofficial" ones. > They just should be very clearly warned on > doing so that they will be then installing any random binary. > (changing the server does not have to be an easy task). Yes you are right. Maybe rather than just changing, they could be given the opportunity to add "additional" plug-in servers. The same way you can add several sources of package repositories in a package management system for your OS. This way the "official" server would be the only one with some kind of limited warranty. We could still not take full responsibility for this, but we could at least say a plug-in present in our official server passed our basic security tests. That would also mean that the official server could afford to be slower for code review when we are still looking for contributors, since users have the option to manually set third party servers, which may be faster or have other focus. > Even if most people find we should make it difficult-as-in-recompiling to > change I don't think it is necessary for the addition of third party servers to be made too difficult (and in particular having to recompile is over and in practice means that a normal user will never be able to do it, but it would be made easy only to scammers). It could just be a UI preference. As long as we display proper warnings "at your own risk" because unreviewed plug-ins can simply do anything to a user's machine. Also if we decided to use branding for protection of users, I would say that a third party build can be named GIMP if and only if the only plug-in server active by default if the official one. If you build GIMP by adding any third party server, without telling the user about it, it can be a scam risk because the user would not have had the original warning (hence would feel safe while one may not be). So you cannot be named GIMP anymore. Anyway very good idea Joao. :-) Jehan > the plug-in·server, maybe the other assets can have less strict rules. > > > js > -><- > > > > On 11 April 2014 05:31, Jehan Pagès <jehan.marmottard@xxxxxxxxx> wrote: > >> Hi, >> >> On Fri, Apr 11, 2014 at 7:13 PM, Ingo Lütkebohle <iluetkeb@xxxxxxxxx> >> 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 <iluetkeb@xxxxxxxxx> >> 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.marmottard@xxxxxxxxx> >> >> wrote: >> >>> >> >>> Hi, >> >>> >> >>> On Thu, Apr 10, 2014 at 4:06 PM, scl <scl.gplus@xxxxxxxxx> 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@xxxxxxxxx >> >>> > 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@xxxxxxxxx >> >>> 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@xxxxxxxxx >> 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@xxxxxxxxx > 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@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
