Re: [Gimp-developer] Fwd: Gimp Registry Future
Hi, Richard Hughes wrote a specification to add meta-information to plugins: http://blogs.gnome.org/hughsie/2014/06/11/application-addons-in-gnome-software/ I think this could be useful for Gimp plugins and the Gimp Registry. Regards Tobias 2014-04-13 21:57 GMT+02:00 scl scl.gp...@gmail.com: On 9.4.2014 at 5:42 PM Ingo Lütkebohle wrote: If anybody could put up a wiki page for that, that'd be great. Does The GIMP have a wiki? Hi, I've just created that page, see http://wiki.gimp.org/index.php/Hacking:Plugin_registry 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
I've added a link to this interesting page on http://wiki.gimp.org/wiki/Hacking:Plugin_registry Ed J -Original Message- From: Tobias Jakobs Sent: Thursday, June 12, 2014 10:28 AM To: scl Cc: gimp-developer Subject: Re: [Gimp-developer] Fwd: Gimp Registry Future Hi, Richard Hughes wrote a specification to add meta-information to plugins: http://blogs.gnome.org/hughsie/2014/06/11/application-addons-in-gnome-software/ I think this could be useful for Gimp plugins and the Gimp Registry. Regards Tobias 2014-04-13 21:57 GMT+02:00 scl scl.gp...@gmail.com: On 9.4.2014 at 5:42 PM Ingo Lütkebohle wrote: If anybody could put up a wiki page for that, that'd be great. Does The GIMP have a wiki? Hi, I've just created that page, see http://wiki.gimp.org/index.php/Hacking:Plugin_registry 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 ___ 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
Hi Sven (and GIMP developers), '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. And now it is possible, as of Gimp-Perl 2.30_05 (http://search.cpan.org/~etj/Gimp-2.30_05/). Please take a look at http://wiki.gimp.org/index.php/Hacking:Plugin_registry which has been updated with observations from making the Gimp-Perl registry viewer (which also allows installing, currently only of script-fu scripts), and ideas for the future. Best regards, Ed J Gimp-Perl guy ___ 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
On 9.4.2014 at 5:42 PM Ingo Lütkebohle wrote: If anybody could put up a wiki page for that, that'd be great. Does The GIMP have a wiki? Hi, I've just created that page, see http://wiki.gimp.org/index.php/Hacking:Plugin_registry 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
Hi, On Sat, Apr 12, 2014 at 12:36 PM, Joao S. O. Bueno gwid...@gmail.com 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.marmott...@gmail.com wrote: 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
On 04/12/2014 02:36 AM, Joao S. O. Bueno 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). I don't think supporting unofficial servers would be very useful as long as it is still possible to install plugins manually as it is done now, since people who would know how to switch servers would definitely know how do that too... Gimp's plug-in distribution model should be closer to Mozilla's than to Apple or Android. All in all the root problem is the initial trustable source. If you download Gimp from the official site it's OK (assuming you are using HTTPS to connect to it). But then most of the Linux users get their Gimp (as well as several plugins) from the distro repository, or a more recent version from an Ubuntu PPA or its equivalent for other distros. Many Window users download Partha's packages (that come with built-in plug-ins) and there are also a couple of trusted sources for OSX (including Partha's). Forum users are often warned about dodgy sources, but unfortunately they come to the forum after the download (GimpShop is obviously making many misled converts since Adobe's policy changes). Last, for the average user out there, binary, Scheme or Python have about the same degree of readability. ___ 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
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. Other than that, the whole searching and browsing UI is likely far from trivial as you suggest. cheers On Fri, Apr 11, 2014 at 3:08 AM, Jehan Pagès jehan.marmott...@gmail.comwrote: 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.)
Re: [Gimp-developer] Fwd: Gimp Registry Future
Oh, and just to clarify, I also mean that effort for *authors* should be taken into account. 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. Other than that, the whole searching and browsing UI is likely far from trivial as you suggest. cheers On Fri, Apr 11, 2014 at 3:08 AM, Jehan Pagès jehan.marmott...@gmail.comwrote: 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
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
Re: [Gimp-developer] Fwd: Gimp Registry Future
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
Re: [Gimp-developer] Fwd: Gimp Registry Future
Can be taken - but a web(designer/developer) need good specs before starting this task. There are plenty of CMS'es on the wild - most of them with many ready-made modules Joomla / Word Press/ CMSMS - they are the easy to implement (and not hard to modify). Drupal is solid and well documented for peoples who need to develop plugins on their own - especially security things... ...but before any choice to be considered - a solid set of specifications must be set (I presume there is a kind of governance on Gimp Registry - which can finalize this thing) once the goal is point by point on paper - would be quite simple to choose from already existing platforms. 2014-04-08 19:41 GMT+03:00 scl scl.gp...@gmail.com: On 8.4.2014 at 10:44 AM ingo wrote: Gimp Registry Future Dear Registry Users, I have maintained the registry for over 15 years now, and for the last couple of years we have had an excellent team of co-maintainers who took on a lot of the work. However, there are some much needed improvements which are hard to carry out based on the current platform, and the work due to abuse is growing. We cannot continue this on our own, unfortunately. In particular, we really need better search and categorization functionality, and would also like to integrate the registry more tightly with The GIMP, such that downloading and installing plug-ins becomes more straightforward. This new structure should also help combat abuse much more effectively. This is no longer just a web-development issue, but much more a plug-in development task. Therefore, I would like to ask /you/ for some help with that. 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. Ideally, it should also be able to display and acquire meta-data, such as ratings, permissions required, etc. Any takers? cheers, Ingo ___ 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
2014-04-09 13:04 GMT+02:00 SorinN nemes.so...@gmail.com: Can be taken - but a web(designer/developer) need good specs before starting this task. There are plenty of CMS'es on the wild - most of them with many ready-made modules Joomla / Word Press/ CMSMS - they are the easy to implement (and not hard to modify). Drupal is solid and well documented for peoples who need to develop plugins on their own - especially security things... I think, if Ingo is talking about plugins, he is talking about Gimp plugins and not about plugins in CMS systems. Regards Tobias ___ 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
.. I think, if Ingo is talking about plugins, he is talking about Gimp plugins and not about plugins in CMS systems. Regards ..and I mean Drupal plugins for developing / improving the functionality of the actual gimp registry website - BTW - we all know that gimp plungin registry is about GIMP plugins the main topic was about web platform - what can be done to improving the security, anti spam measures and general functionality. 2014-04-09 14:35 GMT+03:00 Tobias Jakobs tobias.jak...@gmail.com: 2014-04-09 13:04 GMT+02:00 SorinN nemes.so...@gmail.com: Can be taken - but a web(designer/developer) need good specs before starting this task. There are plenty of CMS'es on the wild - most of them with many ready-made modules Joomla / Word Press/ CMSMS - they are the easy to implement (and not hard to modify). Drupal is solid and well documented for peoples who need to develop plugins on their own - especially security things... I think, if Ingo is talking about plugins, he is talking about Gimp plugins and not about plugins in CMS systems. Regards Tobias ___ 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
Alexander, the Registry currently has support for uploading binary plugins, so those could be downloaded over the interface as well. How the binary plugins arrive in the registry is a different issue. I don't have much to offer on that front, because I can't compile for Windows and Mac OS X. However, I could say that if we create an API-interface, downloading and compiling a lot of plugins could probably be automated. cheers On Wed, Apr 9, 2014 at 1:51 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Wed, Apr 9, 2014 at 3:27 PM, Ingo Lütkebohle wrote: Regarding the server-side, my preference would be to keep Drupal right now. We can fairly easily expose the existing database through the Services module (see https://drupal.org/project/services). Once we have a clear interface, changing either side should be possible at a later stage. Personally, I'm mostly concerned about binary plugins. We support Windows, Linux, ans Mac OS X. A plugin written in C should be available for all three systems. Alexandre ___ 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 ___ 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
On Wed, Apr 9, 2014 at 3:57 PM, Ingo Lütkebohle wrote: Alexander, the Registry currently has support for uploading binary plugins, so those could be downloaded over the interface as well. How the binary plugins arrive in the registry is a different issue. I don't have much to offer on that front, because I can't compile for Windows and Mac OS X. However, I could say that if we create an API-interface, downloading and compiling a lot of plugins could probably be automated. It's a wee bit more complicated. Think of e.g. security concerns. Sure, you can sit down and analyze the code of every submitted plugin, but this solution is not scalable, and a scalable solution (as in automated check for exploits) is likely to be expensive. Which brings us back to the same old question about money and human resources. Alexandre ___ 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
Hi! 2014-04-09 14:14 GMT+02:00 Alexandre Prokoudine alexandre.prokoud...@gmail.com: On Wed, Apr 9, 2014 at 3:57 PM, Ingo Lütkebohle wrote: Alexander, the Registry currently has support for uploading binary plugins, so those could be downloaded over the interface as well. It's a wee bit more complicated. Think of e.g. security concerns. Sure, you can sit down and analyze the code of every submitted plugin, but this solution is not scalable, and a scalable solution (as in automated check for exploits) is likely to be expensive. But this is not a new problem. If you at the moment download anything from the registry and install it, it could destroy your system. This should not stop us from improving it. Regards Tobias ___ 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
On 09.04.2014 14:43, Tobias Jakobs wrote: It's a wee bit more complicated. Think of e.g. security concerns. Sure, you can sit down and analyze the code of every submitted plugin, but this solution is not scalable, and a scalable solution (as in automated check for exploits) is likely to be expensive. But this is not a new problem. If you at the moment download anything from the registry and install it, it could destroy your system. This should not stop us from improving it. Part of the problem right now is that there is no coordinated effort to get official binaries for plug-ins assigned to these - so any binary done by anyone and either uploaded a a separate entity or linked in the comments/questions is happily accepted and downloaded be the users. -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
On 09.04.2014 14:51, Alexandre Prokoudine wrote: The expected effect of that will be a huge increase of deployed extensions and, as a consequence, an increased interest to GIMP from people who write exploits. My concern is how this interest can realistically be handled, because we shall be paying for a better technology with an increased reputation risk. The idea here is to cut down the number of people who may contribute binaries, from about everyone right now to individuals who are reasonably well-known and accepted within their respective communities (for example, the various IRC channels or forums around GIMP). -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
Hi Sven - It is nice to read this - I am very interested in having it working on the client side - that is, a GIMP plug-in that could make one-click download of plug-ins, scripts and other resources (brushes, tool settings, gradients and so on). Having an API SPEC for the registry would be something great, because if the current implementation is found lacking in some aspects, it could later be changed with relative little pain, provided the API is respected. We could build-up something that would allow users with different roles (that is, system known to individuals who are reasonably well-known and accepted within their respective communities ) who can sign plug-ins, resources, and we should mostly try to get the build of plug-in binaries for windows and mac, and possibly even some distributions, automated in some form (Jenkins can do the building for testing purposes, I suppose we could fetch the binaries it generates in some form?). To get working going on the registry API itself, maybe we could start work on it in a wiki page, and in a later state consolidate that into a more stable document that can be rendered into code. Regards, js -- On 9 April 2014 09:57, Michael Schumacher schum...@gmx.de wrote: On 09.04.2014 14:51, Alexandre Prokoudine wrote: The expected effect of that will be a huge increase of deployed extensions and, as a consequence, an increased interest to GIMP from people who write exploits. My concern is how this interest can realistically be handled, because we shall be paying for a better technology with an increased reputation risk. The idea here is to cut down the number of people who may contribute binaries, from about everyone right now to individuals who are reasonably well-known and accepted within their respective communities (for example, the various IRC channels or forums around GIMP). -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
On Wed, Apr 9, 2014 at 7:42 PM, Ingo Lütkebohle wrote: If anybody could put up a wiki page for that, that'd be great. Does The GIMP have a wiki? wiki.gimp.org :-P P.S. Also, there is no such application as The GIMP anymore, for years :) Alexandre ___ 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
P.S. Also, there is no such application as The GIMP anymore, for years :) so i've been told many times, but finger memory dies hard ;-) -- 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
Are we trying to reinvent a package manager here? A lot of the issues I could see coming up have already been addressed by apt/yum/etc - would adapting one of these be a better approach than reinventing the wheel? This would facilitate curating a list of trusted/mature plug-ins, experimental ones, and an everything list (and ones not hosted on the registry), manage dependencies/conflicts, get descriptions, get updates, compile from source, etc. I've written (and hacked on) a few plugins, but I'm not volunteering for this - just wondering if the problem (and problems it creates) has been largely solved already. Seth On Wed, Apr 9, 2014 at 10:42 AM, Ingo Lütkebohle iluet...@gmail.com wrote: I would suggest going with a basic REST api (i.e., GET/POST/PUT), which then means we only have to think about the data format. That's a more difficult discussion, of course. If anybody could put up a wiki page for that, that'd be great. Does The GIMP have a wiki? On Wed, Apr 9, 2014 at 3:20 PM, Joao S. O. Bueno gwid...@gmail.com wrote: Hi Sven - It is nice to read this - I am very interested in having it working on the client side - that is, a GIMP plug-in that could make one-click download of plug-ins, scripts and other resources (brushes, tool settings, gradients and so on). Having an API SPEC for the registry would be something great, because if the current implementation is found lacking in some aspects, it could later be changed with relative little pain, provided the API is respected. We could build-up something that would allow users with different roles (that is, system known to individuals who are reasonably well-known and accepted within their respective communities ) who can sign plug-ins, resources, and we should mostly try to get the build of plug-in binaries for windows and mac, and possibly even some distributions, automated in some form (Jenkins can do the building for testing purposes, I suppose we could fetch the binaries it generates in some form?). To get working going on the registry API itself, maybe we could start work on it in a wiki page, and in a later state consolidate that into a more stable document that can be rendered into code. Regards, js -- On 9 April 2014 09:57, Michael Schumacher schum...@gmx.de wrote: On 09.04.2014 14:51, Alexandre Prokoudine wrote: The expected effect of that will be a huge increase of deployed extensions and, as a consequence, an increased interest to GIMP from people who write exploits. My concern is how this interest can realistically be handled, because we shall be paying for a better technology with an increased reputation risk. The idea here is to cut down the number of people who may contribute binaries, from about everyone right now to individuals who are reasonably well-known and accepted within their respective communities (for example, the various IRC channels or forums around GIMP). -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ 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 ___ 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
On 09.04.2014 18:03, Seth Burgess wrote: Are we trying to reinvent a package manager here? A lot of the issues I could see coming up have already been addressed by apt/yum/etc - would adapting one of these be a better approach than reinventing the wheel? If there is one that can be shipped with GIMP, doesn't interfere with the one of the system, and works on all platforms? -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ 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
Re: [Gimp-developer] Fwd: Gimp Registry Future
On Wed, Apr 9, 2014 at 12:06 PM, Michael Schumacher schum...@gmx.de wrote:
On 09.04.2014 18:03, Seth Burgess wrote:
Are we trying to reinvent a package manager here? A lot of the issues I
could see coming up have already been addressed by apt/yum/etc - would
adapting one of these be a better approach than reinventing the wheel?
If there is one that can be shipped with GIMP, doesn't interfere with
the one of the system, and works on all platforms?
For now, ignoring security concerns and focusing on the server client
architecture I think this would best be served using JSON. The client
plugin manager plugin can be written in Python. The server should talk
JSON because python has better JSON support than XML (or is at least easier
to work with in my opinion although python does have good XML support). By
better I meant ease to develop with.
For the server side API there should be filters on accessing the API.
For example I interact with the Jenkins API regularly and it has JSON
filters through a [GET argument tree][1]. The API should be able to filter
based on platform and language as well as other information. The
serverside API should also allow GET arguments for filtering what results
are returned.
Examples of possible filters (of which I can think of off the top of my
head):
* id: a unique ID to identify a plugin (an incrementing int should suffice)
* platform architecture: 32-bit/64-bit/any
* platform: Windows/Mac/Linux/any
* Language (or type of plugin): scheme/python/binary
* tree: similar to tree in Jenkins where elements can be limited on exactly
what is returned. A good example would be using the tree to filter just
the name, version, and description of the plugin only.
The API should use pagination and likely have GET options for per_page and
page (e.g. ?per_page=20page=3). Maybe there should be a limit for
per_page which limits how much is allowed to be returned at once as a
maximum. This way the size of the request can be limited for the server
and plugins. The plugin manager can iterate across pages. Alternatively
for the initial plugin listing there can be a per_page=all and the tree can
be used to filter out all information except for name, version, and
description (or just the name and version). That could look something like
this... ?per_page=alltree=name,version,desc.
The Jenkins tree filter also handles structures in a sane manner. Take for
example the following JSON.
{
id: 1,
name: my-plugin,
version: 0.0.1,
info: [
{
author: Sam Gleske,
displayName: my plugin,
desc: This is my plugin
}
],
source_url: http://url-to-source/my-plugin_0.0.1.tar.gz;
}
And let's say we send a GET request to the plugin server with the following
arguments: ?per_page=alltree=name,version,info[displayName,desc] .
per_page=all would theoretically return all plugins in the API with
information filtered by tree. As a result of the GET request the server
would respond with...
{
name: my-plugin,
version: 0.0.1,
info: [
{
displayName: my plugin,
desc: This is my plugin
}
]
}
This is essentially how the tree filter in Jenkins works and I think it
would benefit the plugin registry on limiting the size of the payload
returned based on the request. By doing that the plugin manager can
initially request basic information, and if the user wants to see
additional info about the plugin then the plugin manager can make an
additional request. The plugin can then create the following request.
?id=1 and the server responds with the full payload of everything
associated with the plugin ID (or the payload can be filtered with tree).
SAM
[1]:
http://developer-blog.cloudbees.com/2013/05/taming-jenkins-json-api-with-depth-and.html
___
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
Re: [Gimp-developer] Fwd: Gimp Registry Future
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. 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] Fwd: Gimp Registry Future
On 8.4.2014 at 10:44 AM ingo wrote: Gimp Registry Future Dear Registry Users, I have maintained the registry for over 15 years now, and for the last couple of years we have had an excellent team of co-maintainers who took on a lot of the work. However, there are some much needed improvements which are hard to carry out based on the current platform, and the work due to abuse is growing. We cannot continue this on our own, unfortunately. In particular, we really need better search and categorization functionality, and would also like to integrate the registry more tightly with The GIMP, such that downloading and installing plug-ins becomes more straightforward. This new structure should also help combat abuse much more effectively. This is no longer just a web-development issue, but much more a plug-in development task. Therefore, I would like to ask /you/ for some help with that. 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. Ideally, it should also be able to display and acquire meta-data, such as ratings, permissions required, etc. Any takers? cheers, Ingo ___ 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
