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 :

On 8.4.2014 at 10:44 AM 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

Hi,

I understand and support your request for a clear specification, but would say that it is something to be discussed jointly. I wouldn't presume to "demand" anything of a client-side developer. This would be more of a talk, where we see what's possible easily, what would be more effort, etc. It would be ideal if there would be a person who has an own interest in this, and can propose solutions.

I guess the overall idea is to have the functionality of the current web-based registry but without discussions/comments. We could keep data entry on the web-site for a while, and have the plug-in do query and download/install only.

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.

cheers

On Wed, Apr 9, 2014 at 1:04 PM, SorinN wrote:

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 :

On 8.4.2014 at 10:44 AM 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

Ingo Ltkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universitt 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

2014-04-09 13:04 GMT+02:00 SorinN :

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

On Wed, Apr 9, 2014 at 3:27 PM, Ingo Ltkebohle 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

..

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 :

2014-04-09 13:04 GMT+02:00 SorinN :

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

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.prokoudine@gmail.com> wrote:

On Wed, Apr 9, 2014 at 3:27 PM, Ingo Ltkebohle 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 Ltkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universitt 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

On Wed, Apr 9, 2014 at 3:57 PM, Ingo Ltkebohle 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

Hi!

2014-04-09 14:14 GMT+02:00 Alexandre Prokoudine < alexandre.prokoudine@gmail.com>:

On Wed, Apr 9, 2014 at 3:57 PM, Ingo Ltkebohle 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

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

On Wed, Apr 9, 2014 at 4:43 PM, 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.

Exactly. You need to 1) go, 2) find, 3) download, 4) find out, how to install, 5) install.

Whereas the proposed system suggests taking away steps 1), 3) and 4).

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.

This should not stop us from improving it.

I wasn't even implying that.

Alexandre

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

Interesting issue. Not directly related to my inquiry, but certainly something to be considered.

I guess we have two issues: 1) Malicious binary packagers who insert exploits into otherwise harmless plugins and 2) malicious plug-in authors, who code exploits right in. Moreover, I don't think we can expect code reviews to occur.

As Michael already said, one goal of the new structure is that we only let "trusted" developers and/or packagers in. Of course, this only moves the problem to deciding who is trusted, and I guess we can expect that mistakes will be made.

In my opinion, this is really an issue of the gimp's security architecture in general, but one whose risk could be increased because of the relative ease of installing new plug-ins.

Sandboxing might be a possibility. In the old times, plug-ins used to be executed as separate processes, so app-armor and similar approaches would be applicable.

On Wed, Apr 9, 2014 at 2:51 PM, Alexandre Prokoudine < alexandre.prokoudine@gmail.com> wrote:

On Wed, Apr 9, 2014 at 4:43 PM, 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.

Exactly. You need to 1) go, 2) find, 3) download, 4) find out, how to install, 5) install.

Whereas the proposed system suggests taking away steps 1), 3) and 4).

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.

This should not stop us from improving it.

I wasn't even implying that.

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 Ltkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universitt 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 Ltkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universitt 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

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 -> 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

What are the current statistics of uploaded scripts/plugins? It might help us to formulate a plan if we knew a little better what the current state of influx is. (Are we seeing ~5 uploads a week? 10? 20?).

Also, I'm of the opinion that the registry, whatever it ends up becoming, should be focused on the task of hosting the plugins/scripts. Right now there is a sort of forum module bolted on (which is clumsy and hard to use in Drupal, imo). Do we intend the site to also be a forum? Do we just want the ability to comment on specific plugins/scripts?

Ideally, I think it would be nice to see a single-purpose page focused on the scripts/plugins only. (If we think we want to institute a forum for other purposes, perhaps it could be broken out into a separate discussion for consideration?).

My gut feeling is that we are not getting overwhelmed with the number of submissions to the site, and it's something that might be reasonably handled by a few volunteers to vet the entries (and yes, I am volunteering to help with this if we go this route).

There would be a nasty workload up front porting old entries, but after that I think things would calm down to a reasonable workload.

On Wed, Apr 9, 2014 at 8:20 AM, Joao S. O. Bueno 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 -> 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

pat david
http://blog.patdavid.net

darn gmail default ;-)

---------- Forwarded message ---------- From: Ingo Ltkebohle
Date: Wed, Apr 9, 2014 at 5:16 PM
Subject: Re: [Gimp-developer] Fwd: Gimp Registry Future To: Pat David

Answers below.

On Wed, Apr 9, 2014 at 4:42 PM, Pat David wrote:

What are the current statistics of uploaded scripts/plugins? It might help us to formulate a plan if we knew a little better what the current state of influx is. (Are we seeing ~5 uploads a week? 10? 20?).

It varies a bit, of course, but 10 is a good ballpark figure, when counting both plugins and scripts.

However... We get about one user registered every five minutes. That is, between 200 and 300 users a day. And those are the *successful* registrations, i.e., those that pass the text analysis and the captcha.

Also, I'm of the opinion that the registry, whatever it ends up becoming, should be focused on the task of hosting the plugins/scripts. Right now there is a sort of forum module bolted on (which is clumsy and hard to use in Drupal, imo). Do we intend the site to also be a forum? Do we just want the ability to comment on specific plugins/scripts?

The forum functionality would be stripped, as I am told that there are other good venues for such things.

That said, we should be aware of the fact that commenting on plugins was sort of an accident (Drupal has comments on anything by default), but proved unexpectedly popular. I guess having both the plugin download and a feedback function in the same place was fairly compelling. A replacement should take that into account, and offers an easily accessible feedback method that redirects people to the appropriate place.

My gut feeling is that we are not getting overwhelmed with the number of submissions to the site, and it's something that might be reasonably handled by a few volunteers to vet the entries (and yes, I am volunteering to help with this if we go this route).

Well... Yes, I agree, but that's a bit besides the point. This is not about replacing the back-end. We can replace the back-end at our leisure, of course, if people want that, but its working right now.

I am talking about replacing the *front-end*, to integrate things more tightly with the gimp, and improve the user experience. This was a request that Michael Schumacher made, for example, and that others have also made in the past.

cheers

Ingo Ltkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universitt 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 Ltkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universitt 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

On Wed, Apr 9, 2014 at 7:18 PM, Ingo Ltkebohle wrote:

However... We get about one user registered every five minutes. That is, between 200 and 300 users a day. And those are the *successful* registrations, i.e., those that pass the text analysis and the captcha.

Isn't https://drupal.org/project/spambot supposed to help by checking emails against StopForumSpam's database?

Alexandre

On Wed, Apr 9, 2014 at 10:18 AM, Ingo Ltkebohle wrote:

It varies a bit, of course, but 10 is a good ballpark figure, when counting both plugins and scripts.

In that case, if the intention is to focus on the scripts/plugins more than anything else, then I feel this might be a reasonable number for a small team to handle manually.

However... We get about one user registered every five minutes. That is, between 200 and 300 users a day. And those are the *successful* registrations, i.e., those that pass the text analysis and the captcha.

This seems to be the root of the spam problem - would we need to have user accounts in the future? If we move forward for integration, I think curated content with no user accounts might be a better option? (Not sure here, just getting ideas on paper)

The forum functionality would be stripped, as I am told that there are other good venues for such things.

That said, we should be aware of the fact that commenting on plugins was sort of an accident (Drupal has comments on anything by default), but proved unexpectedly popular. I guess having both the plugin download and a feedback function in the same place was fairly compelling. A replacement should take that into account, and offers an easily accessible feedback method that redirects people to the appropriate place.

Again, this appears to really be the root of the problem. We could certainly try allowing comments again on whatever new system (or mod of the old) occurs.

Well... Yes, I agree, but that's a bit besides the point. This is not about replacing the back-end. We can replace the back-end at our leisure, of course, if people want that, but its working right now.

I am talking about replacing the *front-end*, to integrate things more tightly with the gimp, and improve the user experience. This was a request that Michael Schumacher made, for example, and that others have also made in the past.

I agree that this would be fantastic - integration would certainly be a fantastic path moving forward! It would just make sense to clean house overall first to make sure everything was solid before attempting to hook into GIMP in this fashion (plus - Alexandre makes a good point about support across all the OS's/bit-depths.

Perhaps a first attempt should be to look at scripts, as they are usually able to run across OS's without a problem (at least script-fu)?

pat david
http://blog.patdavid.net

On 09.04.2014 17:18, Ingo Ltkebohle wrote:

However... We get about one user registered every five minutes. That is, between 200 and 300 users a day. And those are the *successful* registrations, i.e., those that pass the text analysis and the captcha.

I think we can discard 90% of those as spammers, if not more.

And any contributor of plug-ins and scripts can easily be asked to go through a more elaborate process - e.g. provide some background, past works/contributions to forums, ...

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD

On Wed, Apr 9, 2014 at 5:26 PM, Alexandre Prokoudine < alexandre.prokoudine@gmail.com> wrote:

On Wed, Apr 9, 2014 at 7:18 PM, Ingo Ltkebohle wrote:

However... We get about one user registered every five minutes. That is, between 200 and 300 users a day. And those are the *successful* registrations, i.e., those that pass the text analysis and the captcha.

Isn't https://drupal.org/project/spambot supposed to help by checking emails against StopForumSpam's database?

We currently use Mollom, which also checks the e-mail address. We never tried module before, but I would be surprised. Spammers are fast...

cheers

Ingo Ltkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universitt 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

I think we can discard 90% of those as spammers, if not more.

Probably 99%...

And any contributor of plug-ins and scripts can easily be asked to go

through a more elaborate process - e.g. provide some background, past works/contributions to forums, ...

Yes, that would be the idea. Contributors would have to undergo a signup process. That sign-up process would be manual (and labour-intensive, most likely, but there you).

In fact, that's probably what we're gonna do right away, anyway, regardless of how the plug-in comes along. That means bye-bye comments and forums, but I'm afraid that's just unavoidable.

Ingo Ltkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universitt 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

I am _not_ a developer, just a translator, please be kind ;-)

My 2(4?) cents:

Plugins are (almost all) not translated. This, when comes to integrate GIMP with some plugins, bring the translated GIMP into a mess of translated and untranslated menus and functions.

1) I think that a "good GIMP plugins guide & template" should be taken into account in order to obtain a professional GIMP plugin registry

2) Some "good plugins guidelines" should be written _and_ enforced as it happens with Linux modules

3) GIMP plugins, should be grouped into some git repo somewhere

4) that repo should contain only actively supported plugins

now shoot me :-)

Marco Ciampa

"L'utopia sta all'orizzonte. Mi avvicino  di due passi, lei si allontana
di due  passi. Faccio dieci  passi e  l'orizzonte si allontana  di dieci
passi.  Per quanto cammini, non la raggiunger  mai. A cosa serve
l'utopia? A questo: serve a camminare."              Eduardo Galeano

+--------------------+
| Linux User  #78271 |
| FSFE fellow   #364 |
+--------------------+

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 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 -> 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 Ltkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universitt 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

On Wed, Apr 9, 2014 at 7:42 PM, Ingo Ltkebohle 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

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 Ltkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universitt 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

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 Ltkebohle 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 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 -> 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 Ltkebohle, Dr.-Ing.
Machine Learning and Robotics Lab, IPVS, Universitt 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

On 09.04.2014 17:42, Ingo Ltkebohle wrote:

If anybody could put up a wiki page for that, that'd be great. Does The GIMP have a wiki?

Yes, as Alexandre has mentioned already. And it is also not "The GIMP", only "GIMP". For ages :)

P.S. I think everyone is subscribed to the list, no need for CC:s

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD

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

On Wed, Apr 9, 2014 at 12:06 PM, Michael Schumacher 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=20&page=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=all&tree=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=all&tree=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

To better understand what I mean about tree see the following URLs.

https://ci.jenkins-ci.org/api/json?pretty=true&tree=jobs[name,url]

versus

https://ci.jenkins-ci.org/api/json?pretty=true

SAM

On Wed, Apr 9, 2014 at 2:24 PM, Sam Gleske wrote:

On Wed, Apr 9, 2014 at 12:06 PM, Michael Schumacher 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=20&page=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=all&tree=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=all&tree=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

Hi,

On Thu, Apr 10, 2014 at 4:06 PM, scl 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

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 wrote:

Hi,

On Thu, Apr 10, 2014 at 4:06 PM, scl 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

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 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 wrote:

Hi,

On Thu, Apr 10, 2014 at 4:06 PM, scl 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

Hi,

On Fri, Apr 11, 2014 at 7:13 PM, Ingo Lütkebohle 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 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 wrote:

Hi,

On Thu, Apr 10, 2014 at 4:06 PM, scl 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

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).

Even if most people find we should make it difficult-as-in-recompiling to change
the plug-in·server, maybe the other assets can have less strict rules.

js -> wrote:

Hi,

On Fri, Apr 11, 2014 at 7:13 PM, Ingo Lütkebohle 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

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@gmail.com>

wrote:

Hi,

On Thu, Apr 10, 2014 at 4:06 PM, scl 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

Hi,

On Sat, Apr 12, 2014 at 12:36 PM, 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).

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 -> wrote:

Hi,

On Fri, Apr 11, 2014 at 7:13 PM, Ingo Lütkebohle 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

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@gmail.com>

wrote:

Hi,

On Thu, Apr 10, 2014 at 4:06 PM, scl 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

_______________________________________________ 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

Hi Jehan,

Am 12.04.2014 um 12:57 schrieb Jehan Pags :

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.

Doesnt this conflict with the GPL? Lets assume, I take the GIMP sources and add my own plugin server which offers only precompiled OS X binaries, how is that different to the current situation where I provide those plugins already installed in the application bundle? Am I forced to name my bundle different?

If you build
GIMP by adding any third party server, without telling the user about it, it can be a scam risk because

of course this _might_ be a risk, IMO its the same sort of risk as if you install some precompiled binary plugin from one the uncounted Linux distributions.

the user would not have had the
original warning (hence would feel safe while one may not be).

OTOH, if one provides his own plugin server repository, such a message in the official GIMP will discredit the non-official version as a possible security risk only because of some other kind of distribution.

To make this clearer, Ill give some example. Think of the current situation on OS X. The stock GIMP bundle from gimp.org is not code signed. AFAIK this is because one has to have a paid Apple developer account to get a code signing certificate and currently no one wants to pay the annual fee. Now, to bypass the warning a user will get if he installs this unsigned application, hes advised to turn off this security check in OS Xs System Preferences. Hhmm, IMO not a good advice in the sense of security.

Now, as you know, I provide a compiled GIMP application bundle with many third party plugins. My application bundle _is_ code signed. Should I display a warning, that if if a user wants to install the stock GIMP hes doing it at his own risk, because he gets advised to turn off a security feature of his operating system? How would the core developer team feel about this?

Dont get me wrong, code signing is a very useful feature. But forcing third party developers to use only _one_ specific distribution path or otherwise getting discredited as a possible security risk is not a good move. Even Apple lets you sign your code to pass the code signing test on first launch and still let you distribute your applications however you want.

Simone Karin

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.

Hi Simone,

On Sun, Apr 13, 2014 at 12:44 AM, Simone Karin Lehmann wrote:

Hi Jehan,

Am 12.04.2014 um 12:57 schrieb Jehan Pagès :

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.

Doesn’t this conflict with the GPL? Let’s assume, I take the GIMP sources and add my own plugin server which offers only precompiled OS X binaries, how is that different to the current situation where I provide those plugins already installed in the application bundle? Am I forced to name my bundle different?

No this is not a conflict with GPL. The code is still GPL and we cannot prevent anyone from reusing, modifying, and distributing it. Nor are we willing to (at least in my case, but I think, in the case of other contributors too). I deeply like FLOSS and would not want to change this in any way.

Trademark is something else and is completely parallel to code. This is about usage of "names". You can still use GIMP code and do whatever you want with it (provided that follows GPL, of course, like no proprietary relicensing), but then you cannot say it is GIMP anymore. It is "something else", a fork. So it should be called differently. Someone can still make a scam with GIMP code and we won't be able to tell him anything about the usage of our code (well a judge could, but not license-related :p), but at least we could tell one not to name the scam after GIMP and use its popularity. That's very common in Free Software. Linux does it (http://www.linuxfoundation.org/about/linux-foundation-trademark-usage-guidelines), Mozilla too, and about this there is the very famous story of why Firefox is *not* named Firefox in Debian (which is a major Linux distribution!):
http://en.wikipedia.org/wiki/Mozilla_Corporation_software_rebranded_by_the_Debian_project And so on. I believe most of the big projects does trademark damage control. GIMP is one of the very few that don't do it yet.

Note that I don't like trademarking and any legal stuff in general. I so much prefer the kind of half-hippy state we are in. But we have to admit that abuses are getting a little out of control (as said earlier, many scams are trying to use GIMP name), and in the absence of other solution (but we are welcoming any other proposal), this one is not worse than others. As I said though, that's "damage control". The goal is not to kill third party build (we are Free Software, and by such, bound to have third party builds), only to decide at which point we cannot approve build differences anymore. At which point a patched build cannot be considered "GIMP" anymore.

This is more about trust. Some people trust "us" ("us" being a very vague concept of the many contributors who met, discussed and agreed to do things a certain way over the years), they trust our decision and what we approve of. Someone using the name surrounded by such trust for a completely different agenda without going through the common consensus and usual discussion with the rest of the community could be seen as "deceiving" people. And that's not necessarily in a bad way, like for a scam. That can be for acceptable reasons (the Debian case is interesting. Apparently they did not care about waiting for Mozilla approval first for patching Firefox). But that still is a different program in the end.
Because yes I understand why you ask. You have a build quite different in several aspects and it could be a problem if we go with branding control (I don't know at all if we will! Note that's only supposition), I have no idea how this would end up for you. But as said above, this does not have to be seen as a bad thing necessarily. If ever a trademark conflict prevented a third party modified build to be called GIMP, that is still in effect a close fork from GIMP, and you can still say it. Simply it would have to be named differently because that is in effect different and can be confusing to users too. IceWeasel (the Firefox rebranded by Debian) has its own popularity too and many people are proud to say they use it (even though everyone knows and there is no secret about the fact that it is mostly a Firefox rebranded, but potentially with slight differences here and there).

I'd say that's a choice. If a contributor really don't want to play the game of sharing contributions, discussing, arguing even, and coming to compromises with one's own ideas, well one choose to be on its own.
And I know that's frustrating, for all of us! I would love to see everything go my way and each and every of my whims being immediately accepted and implemented by me or someone else. Also agreeing all together is slow. To have something actually happens takes time. I would have time to implement specific features 4 times myself in the meantime instead of arguing about details! But I know also that I need the others and that I couldn't make GIMP what it is without all the other contributors. So I can't just drop everyone else and go my own way. So I feel it is only fair that if someone was to decide and go one's own way, this is not GIMP anymore. One can't have both at the same time: GIMP (as a community software made by *many*) and full power of decision (self-led project where you are the only boss).

If you build
GIMP by adding any third party server, without telling the user about it, it can be a scam risk because

of course this _might_ be a risk, IMO it’s the same sort of risk as if you install some precompiled binary plugin from one the uncounted Linux distributions.

Not at all! The distributions you are talking about do exactly what I meant. First of all, they don't accept binary uploads from random dude. I don't know if you ever contributed a package to any Linux distribution: you don't upload any kind of binary; you only write down the information on how to build from source in a spec file. You can add last minute *separate* patches, but that's it; you don't provide the main code (it is taken from the actual source), so any change you'd try to do on the code is easily reviewed by your peers. And the finale binaries are built by the distribution servers.

As for the original source itself, well the package maintainer won't review the whole code if that's a very famous plug-in, I guess (you probably don't review G'mic. It has its own many developers and contributors), but you would review some plug-in coming from nowhere. Especially if the package has been provided by a one-time contributor.

Linux distrib's package managements are pretty safe, and indeed imply "no binary upload", "signing" (try to install a package from an unknown source: you'll have a warning about the risk, and you can continue or cancel) and "peer review", just as I want. So no, the risks are very low. And that's exactly the kind of low risk that I would want to provide if we were to provide easy plug-in management.

the user would not have had the
original warning (hence would feel safe while one may not be).

OTOH, if one provides his own plugin server repository, such a message in the ‚official‘ GIMP will discredit the ‚non-official‘ version as a possible security risk only because of some other kind of distribution.

Well we can't vouch for everyone, especially if we don't know them. If they really want to have the approval from GIMP, they can as well contribute and improve the main plugin repository. Now there may be reasons at times when you just cant to do this, and they can be fine reasons. When this happens, there is nothing we can do. We don't know what is "behind the servers" of this person. We have no idea what is being done to provided plugins: are they modified before installation? Are ads added? Are spyware added? Anything bad done? In most case, of course that is not the case, and a third party repository is perfectly fine. But we just don't know. How can we vouch for them?

The person has to build one's own community, one's own public trust. If this person does not want to share with us and trust us, we cannot share back the trust given to the GIMP. This is only about trust networking.
And that's not a discredit from anyone. That's just a fact: we don't know, so there is a risk "as far as we know".

Also most software and distributions are similar: when third party repositories are possible, there will be people making them. They are not discredited (at the opposite if the possibility to make them was given to the community!) but the original project cannot vouch for them. And they'll always tell it: there is a risk, the project cannot check what is there, this is "untrusted", etc.

If I look at Ubuntu's PPA for instance, before the installation procedure, it is written: "You can update your system with unsupported packages from this untrusted PPA by [...]". When reading details: "Important: The contents of Personal Package Archives are not checked or monitored. You install software from them at your own risk. " But still that does not prevent users to install software from PPA. :-)

To make this clearer, I’ll give some example. Think of the current situation on OS X. The stock GIMP bundle from gimp.org is not code signed. AFAIK this is because one has to have a paid Apple developer account to get a code signing certificate and currently no one wants to pay the annual fee. Now, to bypass the warning a user will get if he installs this unsigned application, he’s advised to turn off this security check in OS X’s System Preferences. Hhmm, IMO not a good advice in the sense of security.

Now, as you know, I provide a compiled GIMP application bundle with many third party plugins. My application bundle _is_ code signed. Should I display a warning, that if if a user want’s to install the stock GIMP he’s doing it at his own risk, because he get’s advised to turn off a security feature of his operating system? How would the core developer team feel about this?

Well I don't know. First a question: so are you saying that our current official OSX packages (the ones available on our ftp server and mirrors) are not signed? That's a honest question, I have no idea (and because I'm going to sleep now, I won't connect on IRC to ask this). Well if that is really the case, I'd say we need some contributor willing to pay for it (or use one's existing one). You, maybe? Then we would be able to sign GIMP and any reviewed and compiled-on-our-server plugin.

I mean, GIMP is a community project. There is no duty from us to anyone. We all work on what we like. I happen to not use OSX. So I can't take care of this side. And if it happens that apparently no OSX developer in the whole world seem to care enough about GIMP to sign it for us, well... what can we do? It seems that there is not enough love from the OSX world to GIMP. Why don't you contribute by signing the official GIMP then, if that is to improve security for users? Why would the solution be to not sign anything instead? That does not look very logical to me (and the right solution looks much simpler).

Don’t get me wrong, code signing is a very useful feature. But forcing third party developers to use only _one_ specific distribution path or otherwise getting discredited as a possible security risk is not a good move. Even Apple let’s you sign your code to pass the code signing test on first launch and still let you distribute your applications however you want.

Ok I think you misunderstood. Nobody proposed to force anything. And with the previous discussion (which is just this: a discussion, not even a line of code. Also note well that I don't talk in the name of GIMP or anything. Just to make sure. I talk in my personal name as a single contributor, giving one's opinion on a matter), we were even saying we could very well allow third party repositories. And people would most likely still be able to install plug-ins the old way if they find some code lying on a forum, or websites listing plugins like the current registry.gimp.org. Simply we cannot take responsibility for them. Anyone can write a fake GIMP plugin which does very harmful stuff. So if a plugin does not pass through our slightly safer and controlled procedure (not 100%, but at least some automatic code review, then human code review if automatic code reviews digged up strange stuff, then community voting/commenting once the plugin is out, etc.), there is a risk, and we say it. That's it. Nothing more. There is no discredit. We hate nobody and at the opposite, we would really love people to come to us. We just can't vouch for black boxes.

A comparison for the end: What you are asking here is that if a complete stranger, hidden under a mask and a cape, brings a black box with a strange tic-tac sound inside and asks us to give the box to one of our friend, we should say "yes of course no prob". Then we go to our friend, who trusts us of course, and tell him "hey that's cool stuff, open it!".

Of course maybe that was just a very cool man with trendy clothes, and he just offers awesome clocks around. But I don't know this. So I can't vouch for this unknown masked guy. If I am very nice, at best this second scenario would likely happen: I would take the box with a stick and tell my friend "this strange masked guy gave me this ticking box for you. Well... be careful. Maybe that's not dangerous, but I definitely don't know. Decide at your own risk what you do with it." That's the "accept unsigned plugins and repositories but with warnings" scenario.
On the other hand, if the stranger comes to me and we open the box together, and we can actually see the extra cool clock in it, and he let me rebuild the clock and close the box myself to be sure. Then I'll be much more confident to tell my friend "hey that's a cool clock inside. I checked." This one is the "go through the official plugin repository and follow its rules" scenario.

That's all I'm saying. Nothing more. Nothing about wanting to discredit anyone. :-)

Jehan

Simone Karin
_______________________________________________ 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

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 :

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

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 :

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